public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] ebuild question
@ 2001-08-05 15:50 Craig Joly
  2001-08-05 17:07 ` Daniel Robbins
  0 siblings, 1 reply; 56+ messages in thread
From: Craig Joly @ 2001-08-05 15:50 UTC (permalink / raw
  To: Gentoo Developers

Has it ever been suggested to add an src_configure() section to the
ebuild file?  It would be useful to be able to type
"ebuild foo.ebuild configure" and then look at the generated
makefiles.

Craig



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2001-08-05 15:50 Craig Joly
@ 2001-08-05 17:07 ` Daniel Robbins
  0 siblings, 0 replies; 56+ messages in thread
From: Daniel Robbins @ 2001-08-05 17:07 UTC (permalink / raw
  To: gentoo-dev

On Sun, Aug 05, 2001 at 04:01:11PM -0600, Craig Joly wrote:

> Has it ever been suggested to add an src_configure() section to the ebuild
> file?  It would be useful to be able to type "ebuild foo.ebuild configure"
> and then look at the generated makefiles.

Yes, this has been suggested many times.  Right now, it's all done in
src_compile() as you know.  Moving it to its own function would require fixing
all our existing Makefiles, I think.  Well, I can probably retrofit that
feature; when I have time, I'll see what I can do.

-- 
Daniel Robbins					<drobbins@gentoo.org>
Chief Architect/President			http://www.gentoo.org 
Gentoo Technologies, Inc.			



^ permalink raw reply	[flat|nested] 56+ messages in thread

* [gentoo-dev] ebuild question
@ 2002-02-07  3:44 Edward Muller
  2002-02-07  4:43 ` Tod M Neidt
  0 siblings, 1 reply; 56+ messages in thread
From: Edward Muller @ 2002-02-07  3:44 UTC (permalink / raw
  To: gentoo-dev

I need to build new oaf, ORBIT & bonobo ebuilds for the current builds.
I was looking at the current ORBit-0.5.13 ebuild and found the
followings types of lines:

...
docinto idl
...

What is docinto. I can't seem to find the script in /usr/lib/portage/bin
and a look at the developer docs on the website didn't mention docinto.
Is it an old script? Is it undocumented (and if, so why and where is it
kept?) Or did I miss something?



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2002-02-07  3:44 Edward Muller
@ 2002-02-07  4:43 ` Tod M Neidt
  0 siblings, 0 replies; 56+ messages in thread
From: Tod M Neidt @ 2002-02-07  4:43 UTC (permalink / raw
  To: gentoo-dev

On Wed, 2002-02-06 at 21:44, Edward Muller wrote:
> I need to build new oaf, ORBIT & bonobo ebuilds for the current builds.
> I was looking at the current ORBit-0.5.13 ebuild and found the
> followings types of lines:
> 
> ...
> docinto idl
> ...
> 
> What is docinto. I can't seem to find the script in /usr/lib/portage/bin
> and a look at the developer docs on the website didn't mention docinto.
> Is it an old script? Is it undocumented (and if, so why and where is it
> kept?) Or did I miss something?
> 
Hi!

docinto is an internal function of /usr/sbin/ebuild.sh

If you run across a something lke that in an ebuild that isn't in
/usr/lib/portage/bin in can often be found in /usr/sbin/ebuild.sh

Hope that helps,

tod




^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2002-04-17  5:21 Richard Jackson
@ 2002-04-17  5:02 ` Jared H. Hudson
  2002-04-17  6:05   ` Richard Jackson
  0 siblings, 1 reply; 56+ messages in thread
From: Jared H. Hudson @ 2002-04-17  5:02 UTC (permalink / raw
  To: gentoo-dev

> Should I compile all 4 of them? Yes doing this would take some bash magic but 
> not too much. If I should do all four of them what naming convention should I 
> use for the differant executables? Some thing like nethackQt nethackGnome?

I would say yes, do this. If you need an example, look at: 
app-editors/vim for example, it builds a GUI version and a non-GUI version.

It's really not that hard. The way I would lay it out is:

# handle use options common to all types
use foo && myconf="$myconf --enable-foo"
use foo2 && myconf="$myconf --enable-foo2"

# handle first possible build type
if [ "`use gnome`" ];
then
	./configure --prefix=/usr --host=$CHOST \
	--mandir=/usr/share/man --enable-gtk --enable-gnome $myconf \
	|| die "gnome & gtk configure failed"
	emake || die "gnome & gtk make failed"

	mv src/foo src/gfoo
fi

# handle second possible build type
if [ "`use kde`" ];
then
	./configure --prefix=/usr --host=$CHOST \
	--mandir=/usr/share/man --enable-qt --enable-kde $myconf \
	|| die "kde & qt configure failed"
	emake || die "kde & qt make failed"

	mv src/foo src/kfoo
fi

# handle normal build type
./configure --prefix=/usr --host=$CHOST \
--mandir=/usr/share/man $myconf \
|| die "normal configure failed"
emake || die "normal make failed"


My example may not be perfect, but you get the idea (I hope)

-Jared H.

> 
> Should I just pick one of them and compile that one? What if I pick the one 
> the user doesn't want?
> 
> Should I force some user interaction with the build process? Other words ask 
> them which one they want? I don't really like this option myself.
> 
> And now even more questions. 
> On instalation of the above should I create menu items in KDE and GNOME if the 
> user has them? And a side question to that is it seems that KDE does not 
> automaticly include the GNOME apps but GNOME does automaticly include he KDE 
> apps so if I'm doing a KDE build should I add it to the GNOME menu if they 
> have it. And the reverse if I'm doing a GNOME build should I add that to the 
> KDE menus?
> 
> Any thoughts on the above would be helpfull.
> Thanks
> Richard Jackson
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev




^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2002-04-17  6:05   ` Richard Jackson
@ 2002-04-17  5:21     ` Jared H. Hudson
  0 siblings, 0 replies; 56+ messages in thread
From: Jared H. Hudson @ 2002-04-17  5:21 UTC (permalink / raw
  To: gentoo-dev

I would not use the vim ebuild as a good example of a ebuild to learn 
from. It's harder to understand than most and does a lot of things most 
ebuilds don't need to do. But I would use it as an example of how to 
build to things at the same time, like your case requires.

-Jared H.

Richard Jackson wrote:
> On Wednesday 17 April 2002 12:02 am, Jared H. Hudson wrote:
> 
>>>Should I compile all 4 of them? Yes doing this would take some bash magic
>>>but not too much. If I should do all four of them what naming convention
>>>should I use for the differant executables? Some thing like nethackQt
>>>nethackGnome?
>>
>>I would say yes, do this. If you need an example, look at:
>>app-editors/vim for example, it builds a GUI version and a non-GUI version.
>>
>>It's really not that hard. The way I would lay it out is:
>>
>># handle use options common to all types
>>use foo && myconf="$myconf --enable-foo"
>>use foo2 && myconf="$myconf --enable-foo2"
>>
>># handle first possible build type
>>if [ "`use gnome`" ];
>>then
>>	./configure --prefix=/usr --host=$CHOST \
>>	--mandir=/usr/share/man --enable-gtk --enable-gnome $myconf \
>>
>>	|| die "gnome & gtk configure failed"
>>
>>	emake || die "gnome & gtk make failed"
>>
>>	mv src/foo src/gfoo
>>fi
>>
>># handle second possible build type
>>if [ "`use kde`" ];
>>then
>>	./configure --prefix=/usr --host=$CHOST \
>>	--mandir=/usr/share/man --enable-qt --enable-kde $myconf \
>>
>>	|| die "kde & qt configure failed"
>>
>>	emake || die "kde & qt make failed"
>>
>>	mv src/foo src/kfoo
>>fi
>>
>># handle normal build type
>>./configure --prefix=/usr --host=$CHOST \
>>--mandir=/usr/share/man $myconf \
>>
>>|| die "normal configure failed"
>>
>>emake || die "normal make failed"
>>
>>
>>My example may not be perfect, but you get the idea (I hope)
>>
> 
> Kinda of what I was looking at doing. The differance is that basicly I have to 
> have a clean source directory for each step because you have to modify the 
> make files as nethack does not use automake so I have a patch for each option 
> that has to be applied to the clean sources. And of couse each of them will 
> install on top of the other when you get to the install process so I was 
> looking at handling that myself so things would be done right as far as each 
> version goes that is. It is kinda of a pain but doable. I will take a look at 
> the vim ebuild though as I'm still not real strait on some of the vars used 
> in the ebuild files. I gues I need to reread the howto again. 
> 
> Richard jackson
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev




^ permalink raw reply	[flat|nested] 56+ messages in thread

* [gentoo-dev] ebuild question
@ 2002-04-17  5:21 Richard Jackson
  2002-04-17  5:02 ` Jared H. Hudson
  0 siblings, 1 reply; 56+ messages in thread
From: Richard Jackson @ 2002-04-17  5:21 UTC (permalink / raw
  To: gentoo-dev

I have a ebuild script question. I'm working on adding Qt 3 to nethack. I 
think I saw a post at one point that someone else was doing this as well. 
Either way I'm going to do this as an educational experance. When I have it 
clean I will track down the other person working on it and see if they want 
what I have done. If not I will just calk it up to experance. I picked this 
one becase it has some uniqe issues and I thought if I could get this one 
right then the experance will help latter on.

Now to the question. 

Nethack is uniqe in that it can be compiled many differant ways 
1) Console - This is currently the only option
2) Qt 3 or 2 - I have this one pretty much done using Qt 3.
3) X11 
4) KDE
5) Gnome

The problem with this is that what it looks to be doing is compiling in 
support for Console and one widget set into one executable. And I can't seem 
to beable to get all 5 options to work at one time witch I kinda figured it 
wouldn't. So lets say the user has this in his/her USE statment:
USE="qt x11 kde gnome"

How would I go about handling the compile? 

Should I compile all 4 of them? Yes doing this would take some bash magic but 
not too much. If I should do all four of them what naming convention should I 
use for the differant executables? Some thing like nethackQt nethackGnome?

Should I just pick one of them and compile that one? What if I pick the one 
the user doesn't want?

Should I force some user interaction with the build process? Other words ask 
them which one they want? I don't really like this option myself.

And now even more questions. 
On instalation of the above should I create menu items in KDE and GNOME if the 
user has them? And a side question to that is it seems that KDE does not 
automaticly include the GNOME apps but GNOME does automaticly include he KDE 
apps so if I'm doing a KDE build should I add it to the GNOME menu if they 
have it. And the reverse if I'm doing a GNOME build should I add that to the 
KDE menus?

Any thoughts on the above would be helpfull.
Thanks
Richard Jackson


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2002-04-17  5:02 ` Jared H. Hudson
@ 2002-04-17  6:05   ` Richard Jackson
  2002-04-17  5:21     ` Jared H. Hudson
  0 siblings, 1 reply; 56+ messages in thread
From: Richard Jackson @ 2002-04-17  6:05 UTC (permalink / raw
  To: gentoo-dev

On Wednesday 17 April 2002 12:02 am, Jared H. Hudson wrote:
> > Should I compile all 4 of them? Yes doing this would take some bash magic
> > but not too much. If I should do all four of them what naming convention
> > should I use for the differant executables? Some thing like nethackQt
> > nethackGnome?
>
> I would say yes, do this. If you need an example, look at:
> app-editors/vim for example, it builds a GUI version and a non-GUI version.
>
> It's really not that hard. The way I would lay it out is:
>
> # handle use options common to all types
> use foo && myconf="$myconf --enable-foo"
> use foo2 && myconf="$myconf --enable-foo2"
>
> # handle first possible build type
> if [ "`use gnome`" ];
> then
> 	./configure --prefix=/usr --host=$CHOST \
> 	--mandir=/usr/share/man --enable-gtk --enable-gnome $myconf \
>
> 	|| die "gnome & gtk configure failed"
>
> 	emake || die "gnome & gtk make failed"
>
> 	mv src/foo src/gfoo
> fi
>
> # handle second possible build type
> if [ "`use kde`" ];
> then
> 	./configure --prefix=/usr --host=$CHOST \
> 	--mandir=/usr/share/man --enable-qt --enable-kde $myconf \
>
> 	|| die "kde & qt configure failed"
>
> 	emake || die "kde & qt make failed"
>
> 	mv src/foo src/kfoo
> fi
>
> # handle normal build type
> ./configure --prefix=/usr --host=$CHOST \
> --mandir=/usr/share/man $myconf \
>
> || die "normal configure failed"
>
> emake || die "normal make failed"
>
>
> My example may not be perfect, but you get the idea (I hope)
>
Kinda of what I was looking at doing. The differance is that basicly I have to 
have a clean source directory for each step because you have to modify the 
make files as nethack does not use automake so I have a patch for each option 
that has to be applied to the clean sources. And of couse each of them will 
install on top of the other when you get to the install process so I was 
looking at handling that myself so things would be done right as far as each 
version goes that is. It is kinda of a pain but doable. I will take a look at 
the vim ebuild though as I'm still not real strait on some of the vars used 
in the ebuild files. I gues I need to reread the howto again. 

Richard jackson


^ permalink raw reply	[flat|nested] 56+ messages in thread

* [gentoo-dev] ebuild question
@ 2002-04-18  6:13 Avi Schwartz
  2002-04-18  6:59 ` George Shapovalov
  2002-04-18  7:15 ` Tod M Neidt
  0 siblings, 2 replies; 56+ messages in thread
From: Avi Schwartz @ 2002-04-18  6:13 UTC (permalink / raw
  To: Gentoo Dev

I am trying to create an ebuild for wingide.  I have couple of problems
I trying to solve here: 

1. The name of the archive is wingide-1.1.3-1.tar.gz.  I tried to call
the ebuild file wingide-1.1.3-1.ebuild but ebuild doesn't like it since
it thinks there are two version numbers.  So I changed the name to
wingide-1.1.3-r1.ebuild and I am sticking the -1 in the code: 

SRC_URI="ftp://ftp.wingide.com/pub/wingide/${PV}/${P}-1.tar.gzftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/macro-bugfix-all-${PV}-1.tar         ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/print-bugfix-all-${PV}-1.tar         ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/reuse-app-instance-all-${PV}-1.tar" 

Is this an acceptable practice? The problem with this is that if they
come out with a -2 version, it will not be enough to rename the ebuild
file (although the bug fix files are breaking this anyway).

BTW, PV and ${D} are not documented in the developers HOWTO.  What else
is missing? 

2. Wingide comes with its own installation program which can be
controlled through the command line.  When its archive is expanded, it
creates a wingide-1.1.3-1 directory in which there is the installation
program and the program files.  Ho do I point to the installation
program?  I tried the following ${WORKDIR}/${P}-1/wing-install.py, is
this correct? 

3. The parameters it expects are the installation directory and binary
directory: 

    ${WORKDIR}/${P}-1/wing-install.py  \ 
        --winghome ${D}/usr/lib/wingide \ 
        --bin-dir ${D}/usr/bin 

again, does this make sense? 

4. Another problem I am having is that I see the following messages when
doing the install: 

>>> Install wingide-1.1.3-r1 into
/var/tmp/portage/wingide-1.1.3-r1/image/ category avi 

but when I look at the image directory I see that it didn't install a
thing. 

5. The last 3 files are archives that have to be extracted over the root
installation directory which will be ${D}/usr/lib/wingide.  Again, how
does one achieve this?

6.  The compile stage extracts all 4 files while I realy want only the
main file to be extracted since the other 3 need to be extracted over
the installed file.  Is there a way to control this?  I tried to put my
own code in src_compile(), but ebuild goes ahead and extracts the
archives before executing my code.

7. When the wingide archive is extracted, besides the installation
program there is another tar file extracted which containsall the files.
Another possibility for the installation of the main wingide archive is
to just extract this archive into ${D}/usr/lib.  The question is, do I
have to create ${D}/usr/lib if it doesn't exist yet or will ebuild do it
for me?

Thanks,
Avi
-- 
Avi Schwartz
avi@CFFtechnologies.com



^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2002-04-18  6:13 Avi Schwartz
@ 2002-04-18  6:59 ` George Shapovalov
  2002-04-18  7:15 ` Tod M Neidt
  1 sibling, 0 replies; 56+ messages in thread
From: George Shapovalov @ 2002-04-18  6:59 UTC (permalink / raw
  To: gentoo-dev

Hi

It is hard to answer many of these questions without seeing the package and 
ebuild. However I'll try.

On Wednesday 17 April 2002 23:13, Avi Schwartz wrote:
> I am trying to create an ebuild for wingide.  I have couple of problems
> I trying to solve here:
>
> 1. The name of the archive is wingide-1.1.3-1.tar.gz.  I tried to call
> the ebuild file wingide-1.1.3-1.ebuild but ebuild doesn't like it since
> it thinks there are two version numbers.  So I changed the name to
> wingide-1.1.3-r1.ebuild and I am sticking the -1 in the code:
[skipped]
> Is this an acceptable practice? The problem with this is that if they
> come out with a -2 version, it will not be enough to rename the ebuild
> file (although the bug fix files are breaking this anyway).
At least this is what you can find in some ebuilds. And it seems to be the 
easiest way to go around here. You also would probably want to set your 
${S}=${WORKDIR}/${P}-1.

>
> BTW, PV and ${D} are not documented in the developers HOWTO.  What else
> is missing?
I hope I finally will get some time to update this part of instructions. I was 
going to prepare the list of all vars portage generates when it parses ebuild 
and link to it from the existing ebuild composition howto. I would appreciate 
suggestion on what else should be covered.

>
> 2. Wingide comes with its own installation program which can be
> controlled through the command line.  When its archive is expanded, it
> creates a wingide-1.1.3-1 directory in which there is the installation
> program and the program files.  Ho do I point to the installation
> program?  I tried the following ${WORKDIR}/${P}-1/wing-install.py, is
> this correct?
Does it work? In order to check this you can issue ebuild 
wingide-1.1.3-1.ebuild unpack and then go to 
/var/tmp/portage/wingide-1.1.3-1/work and see what goes where.

>
> 3. The parameters it expects are the installation directory and binary
> directory:
>
>     ${WORKDIR}/${P}-1/wing-install.py  \
>         --winghome ${D}/usr/lib/wingide \
>         --bin-dir ${D}/usr/bin
>
> again, does this make sense?
Is this analog of configure script or of make install?
You do not want anything that gets compiled or somehow setup to get an idea 
that it lives under ${D}. However you do want it to be installed under ${D}.

> 5. The last 3 files are archives that have to be extracted over the root
> installation directory which will be ${D}/usr/lib/wingide.  Again, how
> does one achieve this?
what about this?
cd ${D}/usr/lib/wingide
tar xzpf file 

> 6.  The compile stage extracts all 4 files while I really want only the
> main file to be extracted since the other 3 need to be extracted over
> the installed file.  Is there a way to control this?  I tried to put my
> own code in src_compile(), but ebuild goes ahead and extracts the
> archives before executing my code.
Are you talking about unpack or compile stage? When the files are extracted?
You might need to provide src_unpack function to do custom stuff.

> 7. When the wingide archive is extracted, besides the installation
> program there is another tar file extracted which containsall the files.
> Another possibility for the installation of the main wingide archive is
> to just extract this archive into ${D}/usr/lib.  The question is, do I
> have to create ${D}/usr/lib if it doesn't exist yet or will ebuild do it
> for me?
I think you do. I am not totally clear on what are you trying to achieve here 
though. Besides this is you who tells ebuild what to do and if the dir was 
not created  by the package installation scripts ebuild will not know to 
create it on itself.
BTW, is this a prebuilt package or can it be compiled (the last one is always 
preferable). Is this a WingIDE by any chance? Is this a (time-limited) demo 
version? I think the users are required to register on the site when 
downloading the product (in order to get the license). You will most likely 
have to do something about it (I am not really sure on the status of this 
package). At present you can ask users to download the package themselves and 
put it under /usr/portage/distfiles before proceeding. It may change in 
(probably already near) future when licensing stuff is handled in portage.

George


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2002-04-18  6:13 Avi Schwartz
  2002-04-18  6:59 ` George Shapovalov
@ 2002-04-18  7:15 ` Tod M Neidt
  1 sibling, 0 replies; 56+ messages in thread
From: Tod M Neidt @ 2002-04-18  7:15 UTC (permalink / raw
  To: gentoo-dev

Hi!

On Thu, 2002-04-18 at 01:13, Avi Schwartz wrote:
> I am trying to create an ebuild for wingide.  I have couple of problems
> I trying to solve here: 
> 
> 1. The name of the archive is wingide-1.1.3-1.tar.gz.  I tried to call
> the ebuild file wingide-1.1.3-1.ebuild but ebuild doesn't like it since
> it thinks there are two version numbers.  So I changed the name to
> wingide-1.1.3-r1.ebuild and I am sticking the -1 in the code: 

I would name the ebuild: wingide-1.1.3.1.ebuild

You then have two options:

1.  Hardcode the actual tarball name, i.e.

MYP=${PN}-1.1.3-1

2. Munge ${P} for the same result, i.e.

#Grab least significant version number
LSV=${PV##*.)
#Grab the rest
MYPV=${PV%.*}
#add the lsv back on
MYPV=${MYPV}-${LSV}
MYP=${PN}-{MYPV}

There might be a more elegant munge, but that should work (although you
should test it if you use it)

Either way, use ${MYP} and ${MYPV} in the SRC_URI where you would
normally use ${P} and ${PV}.

Method number 2 (the munge) makes the ebuild version independent.

SRC_URI="ftp://ftp.wingide.com/pub/wingide/${PV}/${MYP}.tar.gz

ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/macro-bugfix-all-${MYPV}.tar etc"
SRC_URI="ftp://ftp.wingide.com/pub/wingide/${PV}/${P}-1.tar.gzftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/macro-bugfix-all-${PV}-1.tar         ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/print-bugfix-all-${PV}-1.tar         ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/reuse-app-instance-all-${PV}-1.tar" 



> 
> SRC_URI="ftp://ftp.wingide.com/pub/wingide/${PV}/${P}-1.tar.gzftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/macro-bugfix-all-${PV}-1.tar         ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/print-bugfix-all-${PV}-1.tar         ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/reuse-app-instance-all-${PV}-1.tar" 
> 
> Is this an acceptable practice? The problem with this is that if they
> come out with a -2 version, it will not be enough to rename the ebuild
> file (although the bug fix files are breaking this anyway).
> 
> BTW, PV and ${D} are not documented in the developers HOWTO.  What else
> is missing? 

Please see 'man 5 ebuild', but note that the syntax of the ebuild
example is stale. Use /usr/portage/skel.ebuild as a syntax and style
example.
> 
> 2. Wingide comes with its own installation program which can be
> controlled through the command line.  When its archive is expanded, it
> creates a wingide-1.1.3-1 directory in which there is the installation
> program and the program files.  Ho do I point to the installation
> program?  I tried the following ${WORKDIR}/${P}-1/wing-install.py, is
> this correct? 
> 
> 3. The parameters it expects are the installation directory and binary
> directory: 
> 
>     ${WORKDIR}/${P}-1/wing-install.py  \ 
>         --winghome ${D}/usr/lib/wingide \ 
>         --bin-dir ${D}/usr/bin 
> 
> again, does this make sense? 

I assume that this is in src_compile?

Set S=${WORKDIR}/${MYP}

When src_compile is called ${S} is the current working directory so 

wing-install.py \
    --winghome ${D}/usr/lib/wingide \
    --bin-dir ${D}/usr/bin \
    || die 

should be sufficient (i assume you don't need an obligatory 'python' in
front of wing-install.py)



> 
> 4. Another problem I am having is that I see the following messages when
> doing the install: 
> 
> >>> Install wingide-1.1.3-r1 into
> /var/tmp/portage/wingide-1.1.3-r1/image/ category avi 
> 
> but when I look at the image directory I see that it didn't install a
> thing

Two guesses

1. you need an '=' after you flags above

2.  The wing-install isn't smart enough to check if the directory exists
before trying to copy which doesn't tend to work very well, might need a

dodir /usr/lib/wingide
dodir /usr/bin

before trying to install
. 
> 
> 5. The last 3 files are archives that have to be extracted over the root
> installation directory which will be ${D}/usr/lib/wingide.  Again, how
> does one achieve this?
I'm not follwing you :( Oh wait, are they patches? or something similiar

> 
> 6.  The compile stage extracts all 4 files while I realy want only the
> main file to be extracted since the other 3 need to be extracted over
> the installed file.  Is there a way to control this?  I tried to put my
> own code in src_compile(), but ebuild goes ahead and extracts the
> archives before executing my code

Without looking at the package myself, I would just be guessing probably
badly :)  Ok are you talking about the other files sownloaded from
SRC_URI?  If so, you probably want to perform this in the src_unpack
function which is executed before src_compile. again see 'man 5 ebuild'
.
> 
> 7. When the wingide archive is extracted, besides the installation
> program there is another tar file extracted which containsall the files.
> Another possibility for the installation of the main wingide archive is
> to just extract this archive into ${D}/usr/lib.  The question is, do I
> have to create ${D}/usr/lib if it doesn't exist yet or will ebuild do it
> for me?
see above

Hope that helps,

tod




^ permalink raw reply	[flat|nested] 56+ messages in thread

* [gentoo-dev] ebuild question
@ 2002-07-26 14:54 John Matthews
  0 siblings, 0 replies; 56+ messages in thread
From: John Matthews @ 2002-07-26 14:54 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

I finally got a Crystal Space ebuild that I can deal with. Unf. there is
one step I need assistance with.

When issuing a "make install", the system looks at either the default
destination directory or the one you set. I've been trying
/usr/local/crystal and if I use that, then "make install" gets a sandbox
violation. If, however, I use ${D}/usr/local/crystal then it installs
but right before that step it rewrites the cs-config script (like
sdl-config, gtk-config, etc.) to say that the location of the CS libs
and headers is /var/tmp/portage/crystal-0.94-r2/image//usr/local/crystal
(or something like that, I don't have it in front of me right now). Of
course, that'll be a bogus location when the package is actually
installed.

Do I need to do some sed magic to fix that somehow, by twiddling with
the cs-config file that's been installed in the image? Or is there some
sort of standard clever way to get around this problem with
non-./configure-style packages?

Random other info:
Meanwhile, I'm still in a position where I can't build optimized builds
with gcc 3.x and I can't use assembler at all. I've been told that CS
requires a special version of nasm or something like that, but haven't
found a direct reference for what works yet. Building a debug build with
no assembler gets me a working install image, I believe, on gcc 3.x and
gcc 2.95.

Regards and thanks,
matt

-- 
Matt Matthews     \ ph: 919.660.2811        \ Use GNU/Linux  _o) w00t
Duke Univ., Postdoc\ jvmatthe@math.duke.edu  \____________   /\\
Dept. of Mathematics\ http://www.math.duke.edu/~jvmatthe/ \ _\_V

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2002-11-26 21:27 Per Wigren
@ 2002-11-26 21:23 ` Dan Armak
  2002-11-27  0:03   ` Per Wigren
  0 siblings, 1 reply; 56+ messages in thread
From: Dan Armak @ 2002-11-26 21:23 UTC (permalink / raw
  To: gentoo-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 26 November 2002 23:27, Per Wigren wrote:
> Hi!
>
> I'm making an ebuild for GOBO 3.0 (http://www.gobosoft.com), but I still
> have to finetune the install()-part of the ebuild... The problem is that it
> takes about 4 hours (!!) to compile, and everytime I make a small change it
> will rebuild the tmp-dir and recompile...
>
> How can I tell "ebuild install" that it should NOT do that? Just do the
> install-part without recompiling for another 4 hours, even if I just
> changed the ebuild...

Adding 'noauto' to FEATURES in make.conf should do that.

- -- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://www.gentoo.org/~danarmak/danarmak-gpg-public.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE94+Y0UI2RQ41fiVERAh+sAJ0WeWXa6/UKzVoTA73OhgxAGMfZdACeO+11
0iKADHqMggUmade67gVO7bY=
=BQcb
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* [gentoo-dev] ebuild question
@ 2002-11-26 21:27 Per Wigren
  2002-11-26 21:23 ` Dan Armak
  0 siblings, 1 reply; 56+ messages in thread
From: Per Wigren @ 2002-11-26 21:27 UTC (permalink / raw
  To: gentoo-dev

Hi!

I'm making an ebuild for GOBO 3.0 (http://www.gobosoft.com), but I still have 
to finetune the install()-part of the ebuild... The problem is that it takes 
about 4 hours (!!) to compile, and everytime I make a small change it will 
rebuild the tmp-dir and recompile...

How can I tell "ebuild install" that it should NOT do that? Just do the 
install-part without recompiling for another 4 hours, even if I just changed 
the ebuild...

Regards
Per Wigren


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2002-11-26 21:23 ` Dan Armak
@ 2002-11-27  0:03   ` Per Wigren
  0 siblings, 0 replies; 56+ messages in thread
From: Per Wigren @ 2002-11-27  0:03 UTC (permalink / raw
  To: danarmak, gentoo-dev

Tuesday 26 November 2002 22:23 skrev Dan Armak:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday 26 November 2002 23:27, Per Wigren wrote:
> > Hi!
> >
> > I'm making an ebuild for GOBO 3.0 (http://www.gobosoft.com), but I still
> > have to finetune the install()-part of the ebuild... The problem is that
> > it takes about 4 hours (!!) to compile, and everytime I make a small
> > change it will rebuild the tmp-dir and recompile...
> >
> > How can I tell "ebuild install" that it should NOT do that? Just do the
> > install-part without recompiling for another 4 hours, even if I just
> > changed the ebuild...
>
> Adding 'noauto' to FEATURES in make.conf should do that.

Yes that's it! Thanks a lot!

// Per Wigren

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* [gentoo-dev] ebuild question
@ 2003-05-30 11:15 MAL
  2003-05-30 11:29 ` Alastair Tse
  0 siblings, 1 reply; 56+ messages in thread
From: MAL @ 2003-05-30 11:15 UTC (permalink / raw
  To: gentoo-dev

gucharmap didn't have an uptodate ebuild, so I thought I'd put one 
together, but..

The configure/Makefile for gucharmap-0.6.1 attempts to rebuild the GTK 
input module cache file during install.  Obviously portage catches this, 
so what's the best way to handle this?

It basically executes:

gtk-query-immodules-2.0 > /etc/gtk-2.0/gtk.immodules


The possibilities I can see are:

a) possibly portage has a function to specify that access to 
/etc/gtk-2.0/gtk.immodules is allowed.

or

b) I provide a patch to the sources to stop this happening, then do it 
myself in the ebuild after install.


Any other ideas? What's best?

Cheers,
MAL


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-05-30 11:15 MAL
@ 2003-05-30 11:29 ` Alastair Tse
  2003-05-30 14:22   ` MAL
  0 siblings, 1 reply; 56+ messages in thread
From: Alastair Tse @ 2003-05-30 11:29 UTC (permalink / raw
  To: MAL; +Cc: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

On Fri, 2003-05-30 at 12:15, MAL wrote:

> a) possibly portage has a function to specify that access to 
> /etc/gtk-2.0/gtk.immodules is allowed.

Thats a no no. Unless there is absolutely no way to patch that
behaviour.

> b) I provide a patch to the sources to stop this happening, then do it 
> myself in the ebuild after install.

You have to patch that part out and make sure you can produce the same
effect during pkg_postinst() and also reverse the effect when you do
pkg_postrm() (if possible.) You need to test it pretty well to make sure
pkg_postinst() and pkg_postrm() works as expected, esp in regards
prefixing paths with ${ROOT} when writing files, etc.

Cheers,

Alastair



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-05-30 11:29 ` Alastair Tse
@ 2003-05-30 14:22   ` MAL
  2003-05-30 14:33     ` Alastair Tse
  2003-05-30 14:39     ` Seemant Kulleen
  0 siblings, 2 replies; 56+ messages in thread
From: MAL @ 2003-05-30 14:22 UTC (permalink / raw
  To: Alastair Tse; +Cc: gentoo-dev

Alastair Tse wrote:
> On Fri, 2003-05-30 at 12:15, MAL wrote:
> 
> 
>>a) possibly portage has a function to specify that access to 
>>/etc/gtk-2.0/gtk.immodules is allowed.
> 
> 
> Thats a no no. Unless there is absolutely no way to patch that
> behaviour.
> 
> 
>>b) I provide a patch to the sources to stop this happening, then do it 
>>myself in the ebuild after install.
> 
> 
> You have to patch that part out and make sure you can produce the same
> effect during pkg_postinst() and also reverse the effect when you do
> pkg_postrm() (if possible.) You need to test it pretty well to make sure
> pkg_postinst() and pkg_postrm() works as expected, esp in regards
> prefixing paths with ${ROOT} when writing files, etc.

Thanks for the info, see what you think:

http://bugs.gentoo.org/show_bug.cgi?id=21953

Is it better to upload an ebuild as a .tar.bz2 with digests, patches 
etc. all included?

Cheers,
MAL


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-05-30 14:22   ` MAL
@ 2003-05-30 14:33     ` Alastair Tse
  2003-05-30 14:40       ` Todd Berman
  2003-05-30 14:39     ` Seemant Kulleen
  1 sibling, 1 reply; 56+ messages in thread
From: Alastair Tse @ 2003-05-30 14:33 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

On Fri, 2003-05-30 at 15:22, MAL wrote:
> Is it better to upload an ebuild as a .tar.bz2 with digests, patches 
> etc. all included?

Ebuilds should not be attached as tar.bz2, they should be in text/plain.
It's actually written in the Ebuils Contribution Guide somewhere, and
also one of the most common problems with ebuild submission as I listed
in my ebuild mistakes list
(http://cvs.gentoo.org/~liquidx/ebuildmistakes.html).

Cheers,
-- 
Alastair 'liquidx' Tse
 >> Gentoo Developer
 >> http://www.liquidx.net/ | http://cvs.gentoo.org/~liquidx/
 >> GPG Key : http://cvs.gentoo.org/~liquidx/liquidx_gentoo_org.asc
 >> FingerPrint : 579A 9B0E 43E8 0E40 EE93  BB1C 38CE 1C7B 3907 14F6


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-05-30 14:22   ` MAL
  2003-05-30 14:33     ` Alastair Tse
@ 2003-05-30 14:39     ` Seemant Kulleen
  2003-05-30 15:09       ` Seemant Kulleen
  1 sibling, 1 reply; 56+ messages in thread
From: Seemant Kulleen @ 2003-05-30 14:39 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]


> Is it better to upload an ebuild as a .tar.bz2 with digests, patches 
> etc. all included?
> 
> Cheers,
> MAL


Yes, except for the digests. No self-respecting dev would simply add a submitted digest (no offence to you, personally). 


-- 
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux					http://www.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-05-30 14:33     ` Alastair Tse
@ 2003-05-30 14:40       ` Todd Berman
  2003-05-30 14:55         ` Jon Portnoy
  0 siblings, 1 reply; 56+ messages in thread
From: Todd Berman @ 2003-05-30 14:40 UTC (permalink / raw
  To: gentoo-dev

Not to generate useless traffic, but I feel it is very important to
reiterate this.

Please, please, please attach your ebuilds to bugzilla as text/plain and
as single files. Two common errors I have seen plenty are attaching a
.tar.gz or .tar.bz2, or, and more of a problem for me, are the text
files attached, but set as an octet stream so the viewer wont kick in.

This cant be stressed enough as the 'proper' way to submit an ebuild if
you want to see it committed as fast as possible.

And as an aside, maybe zhen or whoever maintains bugs.g.o can set
text/plain as the default file upload, because i assume plenty of people
just forget to change it.

--Todd

On Fri, 2003-05-30 at 10:33, Alastair Tse wrote:
> On Fri, 2003-05-30 at 15:22, MAL wrote:
> > Is it better to upload an ebuild as a .tar.bz2 with digests, patches 
> > etc. all included?
> 
> Ebuilds should not be attached as tar.bz2, they should be in text/plain.
> It's actually written in the Ebuils Contribution Guide somewhere, and
> also one of the most common problems with ebuild submission as I listed
> in my ebuild mistakes list
> (http://cvs.gentoo.org/~liquidx/ebuildmistakes.html).
> 
> Cheers,


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-05-30 14:40       ` Todd Berman
@ 2003-05-30 14:55         ` Jon Portnoy
  2003-05-30 15:08           ` MAL
  0 siblings, 1 reply; 56+ messages in thread
From: Jon Portnoy @ 2003-05-30 14:55 UTC (permalink / raw
  To: Todd Berman; +Cc: gentoo-dev

On Fri, May 30, 2003 at 10:40:09AM -0400, Todd Berman wrote:
> Not to generate useless traffic, but I feel it is very important to
> reiterate this.
> 
> Please, please, please attach your ebuilds to bugzilla as text/plain and
> as single files. Two common errors I have seen plenty are attaching a
> .tar.gz or .tar.bz2, or, and more of a problem for me, are the text
> files attached, but set as an octet stream so the viewer wont kick in.
> 
> This cant be stressed enough as the 'proper' way to submit an ebuild if
> you want to see it committed as fast as possible.
> 
> And as an aside, maybe zhen or whoever maintains bugs.g.o can set
> text/plain as the default file upload, because i assume plenty of people
> just forget to change it.
> 
> --Todd
> 
> On Fri, 2003-05-30 at 10:33, Alastair Tse wrote:
> > On Fri, 2003-05-30 at 15:22, MAL wrote:
> > > Is it better to upload an ebuild as a .tar.bz2 with digests, patches 
> > > etc. all included?
> > 
> > Ebuilds should not be attached as tar.bz2, they should be in text/plain.
> > It's actually written in the Ebuils Contribution Guide somewhere, and
> > also one of the most common problems with ebuild submission as I listed
> > in my ebuild mistakes list
> > (http://cvs.gentoo.org/~liquidx/ebuildmistakes.html).
> > 
> > Cheers,
> 
> 

Just to throw in a "me too" - it drives me absolutely nuts when people 
don't submit ebuilds as plain text. Patches et al should also be plain 
text. It's much easier for me to review it that way and will definitely 
get your ebuild processed faster.


-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-05-30 14:55         ` Jon Portnoy
@ 2003-05-30 15:08           ` MAL
  0 siblings, 0 replies; 56+ messages in thread
From: MAL @ 2003-05-30 15:08 UTC (permalink / raw
  To: gentoo-dev; +Cc: Jon Portnoy, tberman

Jon Portnoy wrote:
> On Fri, May 30, 2003 at 10:40:09AM -0400, Todd Berman wrote:
> 
>>Not to generate useless traffic, but I feel it is very important to
>>reiterate this.
>>
>>Please, please, please attach your ebuilds to bugzilla as text/plain and
>>as single files. Two common errors I have seen plenty are attaching a
>>.tar.gz or .tar.bz2, or, and more of a problem for me, are the text
>>files attached, but set as an octet stream so the viewer wont kick in.
>>
>>This cant be stressed enough as the 'proper' way to submit an ebuild if
>>you want to see it committed as fast as possible.
>>
>>And as an aside, maybe zhen or whoever maintains bugs.g.o can set
>>text/plain as the default file upload, because i assume plenty of people
>>just forget to change it.
> 
> Just to throw in a "me too" - it drives me absolutely nuts when people 
> don't submit ebuilds as plain text. Patches et al should also be plain 
> text. It's much easier for me to review it that way and will definitely 
> get your ebuild processed faster.

ok ok people.. if you look at the bug, you'll see that I submitted them 
as text, and set the mime type too... I just then wondered if people 
liked to see a .tar.bz2 _as well_

Has anyone actually looked at the ebuild yet? :p
It's my first submission and I'd like to know if I've gone about it the 
right way, (in regards to updating the gtk2 input module cache).

Cheers ppl,
MAL


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-05-30 14:39     ` Seemant Kulleen
@ 2003-05-30 15:09       ` Seemant Kulleen
  0 siblings, 0 replies; 56+ messages in thread
From: Seemant Kulleen @ 2003-05-30 15:09 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

On Fri, 30 May 2003 07:39:49 -0700
Seemant Kulleen <seemant@gentoo.org> wrote:

> 
> > Is it better to upload an ebuild as a .tar.bz2 with digests, patches 
> > etc. all included?
> > 
> > Cheers,
> > MAL
> 
> 
> Yes, except for the digests. No self-respecting dev would simply add a submitted digest (no offence to you, personally). 

Sorry, not to be misleading -- don't attach tarballs, and don't attach digests.  Tarballs are annoying, digests are useless.

-- 
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux					http://www.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 56+ messages in thread

* [gentoo-dev] ebuild question
@ 2003-05-30 15:17 William Hubbs
  2003-05-30 15:27 ` Grant Goodyear
  0 siblings, 1 reply; 56+ messages in thread
From: William Hubbs @ 2003-05-30 15:17 UTC (permalink / raw
  To: Gentoo Developers

Hi all,

I am working on an ebuild for sus ( http://pdg.uow.edu.au/sus/).

This program doesn't use autoconf.  It just has a makefile which must be edited to set up the locations files should be installed.  What is the best way to handle this?  I can think of two options -- use sed to edit the file, or generate a patch.

Thanks,

William


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-05-30 15:17 William Hubbs
@ 2003-05-30 15:27 ` Grant Goodyear
  2003-05-31  3:00   ` Georgi Georgiev
  0 siblings, 1 reply; 56+ messages in thread
From: Grant Goodyear @ 2003-05-30 15:27 UTC (permalink / raw
  To: Gentoo Developers

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

On Fri, 2003-05-30 at 11:17, William Hubbs wrote:
> Hi all,
> 
> I am working on an ebuild for sus ( http://pdg.uow.edu.au/sus/).
> 
> This program doesn't use autoconf.  It just has a makefile which must be edited to set up the locations files should be installed.  What is the best way to handle this?  I can think of two options -- use sed to edit the file, or generate a patch.

A patch is one more file that you have to maintain, so sed is generally
preferred if it's not too ugly.

-g2boojum-
-- 
Grant Goodyear <g2boojum@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-05-30 15:27 ` Grant Goodyear
@ 2003-05-31  3:00   ` Georgi Georgiev
  0 siblings, 0 replies; 56+ messages in thread
From: Georgi Georgiev @ 2003-05-31  3:00 UTC (permalink / raw
  To: Gentoo Developers

On 30/05/2003 at 11:27:21(-0400), Grant Goodyear used 1.0Kbytes just to say:
> On Fri, 2003-05-30 at 11:17, William Hubbs wrote:
> > Hi all,
> > 
> > I am working on an ebuild for sus ( http://pdg.uow.edu.au/sus/).
> > 
> > This program doesn't use autoconf.  It just has a makefile which must be
> > edited to set up the locations files should be installed.  What is the best
> > way to handle this?  I can think of two options -- use sed to edit the
> > file, or generate a patch.
> 
> A patch is one more file that you have to maintain, so sed is generally
> preferred if it's not too ugly.

Maybe it would be easy enough to set the necessary makefile macros on the
command-line. i.e.

make PREFIX="$D" CFLAGS="...."

etc.


-- 
 /^^^^^^^^^^^^^^^^^^^^^^^^^^^\/^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\
/ Georgi Georgiev    (-<     / Computer programmers do it byte  \
\ chutz@chubaka.net  /\   .o)\ by byte.                         /
/ +81(90)6266-1163  V_/_ |(/)/                                  \
\___________________________/\__________________________________/

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* [gentoo-dev] ebuild question
@ 2003-06-10 14:25 MAL
  2003-06-10 15:40 ` [gentoo-dev] A nice idea to improve portage MooktaKiNG
  2003-06-12 11:34 ` [gentoo-dev] ebuild question Amiel Martin
  0 siblings, 2 replies; 56+ messages in thread
From: MAL @ 2003-06-10 14:25 UTC (permalink / raw
  To: gentoo-dev

I'm writing an ebuild for ZoneMinder, and I have a few problems/queries..

The program is a bunch of php and a few cgi apps.  After configuring, 
the package asks you to run a perl script which interactively asks you 
for initial configuration, then updates the .php files with this info. 
'make install' then installs the .php files into your document root, 
(and the cgi into your cgi-bin dir).

Now, I don't want to break the non-interactivity of portage, but I can't 
just leave an 'einfo' message to the user after install, asking them to 
run the perl script, because this must be done before install.

So, do I either:

* Use expect to answer the perl script's questions with some sensible 
defaults, then leave a message to the user on how to change these 
defaults after install, (in which case, should I add expect to the 
DEPEND line?)

* Re-package the software entirely, (there is a compiled part and a 
non-compiled php part.. maybe separate the php part out).  I'm kinda 
loathed to do this, as it seems like unnecessary maintenance.

* Modify the perl script to automatically set certain defaults.


Additionally, what do I do about the location of apache, and the 
user/group to set the php files as? :)
I noticed the recent eclass submission, but I'm assuming I can't use 
that just yet, so /home/httpd/htdocs and apache:apache ?

Cheers,
MAL


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* [gentoo-dev] A nice idea to improve portage
  2003-06-10 14:25 [gentoo-dev] ebuild question MAL
@ 2003-06-10 15:40 ` MooktaKiNG
  2003-06-10 16:07   ` Matthew Kennedy
                     ` (2 more replies)
  2003-06-12 11:34 ` [gentoo-dev] ebuild question Amiel Martin
  1 sibling, 3 replies; 56+ messages in thread
From: MooktaKiNG @ 2003-06-10 15:40 UTC (permalink / raw
  To: gentoo-dev

I think it would be better if portage included a README file for
each ebuild.

This i belive is very important becuase gentoo is a bit different
from a normal linux.

Like when installing a mod_php you run the command:

ebuild .../mod_php config

after installtion.

See when i installed this first i had know idea.

I know i know. there are some text at the end of the emerge that
says what you should do.

But when your doind multiple emerge's one after the other and you
leave gentoo todo its thing. You don't see the text.

So if there was a nice README file that explain the 'extra' setting
needed on each dir in portage then it would make things a LOT easier
and would be very helpful.

If this already exists please ignore this email.

-------------------------------------------------
Please wait while you are redirected to my signature......

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] A nice idea to improve portage
  2003-06-10 15:40 ` [gentoo-dev] A nice idea to improve portage MooktaKiNG
@ 2003-06-10 16:07   ` Matthew Kennedy
  2003-06-10 18:05   ` John Robinson
  2003-06-11 11:52   ` [gentoo-dev] Readme files for portage (was: A nice idea to improve portage) Svyatogor
  2 siblings, 0 replies; 56+ messages in thread
From: Matthew Kennedy @ 2003-06-10 16:07 UTC (permalink / raw
  To: gentoo-dev

"MooktaKiNG" <Mooktakim@hotmail.com> writes:

> I think it would be better if portage included a README file for
> each ebuild.
>

I think this is a good idea.  Many ebuilds already include a
REAME.Gentoo which contains extra information.  Its possible that
this is not used consistently though.

Matt

-- 
Matthew Kennedy
Gentoo Linux Developer

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] A nice idea to improve portage
  2003-06-10 15:40 ` [gentoo-dev] A nice idea to improve portage MooktaKiNG
  2003-06-10 16:07   ` Matthew Kennedy
@ 2003-06-10 18:05   ` John Robinson
  2003-06-10 20:20     ` Philippe Lafoucrière
  2003-06-10 21:56     ` MooktaKiNG
  2003-06-11 11:52   ` [gentoo-dev] Readme files for portage (was: A nice idea to improve portage) Svyatogor
  2 siblings, 2 replies; 56+ messages in thread
From: John Robinson @ 2003-06-10 18:05 UTC (permalink / raw
  To: gentoo-dev

> I know i know. there are some text at the end of the emerge that
> says what you should do.
> 
> But when your doind multiple emerge's one after the other and you
> leave gentoo todo its thing. You don't see the text.
> 
> So if there was a nice README file that explain the 'extra' setting
> needed on each dir in portage then it would make things a LOT easier
> and would be very helpful.

Honestly, I think I'd much prefer if portage just queued all of those
messages and displayed them at the end of the emerge. If that
information was in a README, you'd have to go, find, and read the README
for every package and dependency that you install. That's a lot of work.
Since portage is supposed to be non-interactive, it shouldn't assume
that you're gonna stick around watching the terminal while it does its
thing. ;)

- John

-- 

Love justice; desire mercy.


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] A nice idea to improve portage
  2003-06-10 18:05   ` John Robinson
@ 2003-06-10 20:20     ` Philippe Lafoucrière
  2003-06-11  3:18       ` Luke Graham
  2003-06-10 21:56     ` MooktaKiNG
  1 sibling, 1 reply; 56+ messages in thread
From: Philippe Lafoucrière @ 2003-06-10 20:20 UTC (permalink / raw
  To: strider; +Cc: gentoo-dev


> Honestly, I think I'd much prefer if portage just queued all of those
> messages and displayed them at the end of the emerge. If that
> information was in a README, you'd have to go, find, and read the README
> for every package and dependency that you install. That's a lot of work.
> Since portage is supposed to be non-interactive, it shouldn't assume
> that you're gonna stick around watching the terminal while it does its
> thing. ;)


Hmmm both are good ideas !! Why don't add some README files, that are displayed 
(instead of queued) at the end of an emerge ?


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] A nice idea to improve portage
  2003-06-10 21:56     ` MooktaKiNG
@ 2003-06-10 21:42       ` Zach Forrest
  2003-06-10 23:26         ` Kumba
  0 siblings, 1 reply; 56+ messages in thread
From: Zach Forrest @ 2003-06-10 21:42 UTC (permalink / raw
  To: gentoo-dev

You could also have "logmessages" FEATURE (in make.conf) that, if 
enabled, logged the output of einfo, etc.

MooktaKiNG wrote:
> But i usually start an emerge and then do && halt
> 
> This shutsdown gentoo after the emerge.
> 
> Its still the same problem.
> 
> But why can't we have both?
> 
> A readme should not me too hard. The person who makes the actual
> ebuild just types a small README to explain stuff. Thats all.
> 
> 
> 
>>>I know i know. there are some text at the end of the emerge that
>>>says what you should do.
>>>
>>>But when your doind multiple emerge's one after the other and you
>>>leave gentoo todo its thing. You don't see the text.
>>>
>>>So if there was a nice README file that explain the 'extra'
>>>setting
>>>needed on each dir in portage then it would make things a LOT
>>>easier
>>>and would be very helpful.
>>
>>Honestly, I think I'd much prefer if portage just queued all of
>>those
>>messages and displayed them at the end of the emerge. If that
>>information was in a README, you'd have to go, find, and read the
>>README
>>for every package and dependency that you install. That's a lot of
>>work.
>>Since portage is supposed to be non-interactive, it shouldn't assume
>>that you're gonna stick around watching the terminal while it does
>>its
>>thing. ;)
>>
>>- John
>>
>>--
>>
>>Love justice; desire mercy.
>>
>>
>>--
>>gentoo-dev@gentoo.org mailing list
>>
>>
> 
> 
> 
> -------------------------------------------------
> Please wait while you are redirected to my signature......
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
> 


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] A nice idea to improve portage
  2003-06-10 18:05   ` John Robinson
  2003-06-10 20:20     ` Philippe Lafoucrière
@ 2003-06-10 21:56     ` MooktaKiNG
  2003-06-10 21:42       ` Zach Forrest
  1 sibling, 1 reply; 56+ messages in thread
From: MooktaKiNG @ 2003-06-10 21:56 UTC (permalink / raw
  To: gentoo-dev

But i usually start an emerge and then do && halt

This shutsdown gentoo after the emerge.

Its still the same problem.

But why can't we have both?

A readme should not me too hard. The person who makes the actual
ebuild just types a small README to explain stuff. Thats all.


>> I know i know. there are some text at the end of the emerge that
>> says what you should do.
>>
>> But when your doind multiple emerge's one after the other and you
>> leave gentoo todo its thing. You don't see the text.
>>
>> So if there was a nice README file that explain the 'extra'
>> setting
>> needed on each dir in portage then it would make things a LOT
>> easier
>> and would be very helpful.
>
> Honestly, I think I'd much prefer if portage just queued all of
> those
> messages and displayed them at the end of the emerge. If that
> information was in a README, you'd have to go, find, and read the
> README
> for every package and dependency that you install. That's a lot of
> work.
> Since portage is supposed to be non-interactive, it shouldn't assume
> that you're gonna stick around watching the terminal while it does
> its
> thing. ;)
>
> - John
>
> --
>
> Love justice; desire mercy.
>
>
> --
> gentoo-dev@gentoo.org mailing list
>
>


-------------------------------------------------
Please wait while you are redirected to my signature......

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] A nice idea to improve portage
  2003-06-10 21:42       ` Zach Forrest
@ 2003-06-10 23:26         ` Kumba
  0 siblings, 0 replies; 56+ messages in thread
From: Kumba @ 2003-06-10 23:26 UTC (permalink / raw
  To: Zach Forrest; +Cc: gentoo-dev

Zach Forrest wrote:

> You could also have "logmessages" FEATURE (in make.conf) that, if 
> enabled, logged the output of einfo, etc.

Actually, this feature already exists.  If PORT_LOGDIR is defined to a 
location in /etc/make.conf, then portage will log all output to the 
specified location.

--Kumba


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] A nice idea to improve portage
  2003-06-10 20:20     ` Philippe Lafoucrière
@ 2003-06-11  3:18       ` Luke Graham
  2003-06-11  5:10         ` Bill Kenworthy
  0 siblings, 1 reply; 56+ messages in thread
From: Luke Graham @ 2003-06-11  3:18 UTC (permalink / raw
  To: gentoo-dev

On Wed, 11 Jun 2003 06:20 am, Philippe Lafoucrière wrote:
> > Honestly, I think I'd much prefer if portage just queued all of those
> > messages and displayed them at the end of the emerge. If that
> > information was in a README, you'd have to go, find, and read the README
> > for every package and dependency that you install. That's a lot of work.
> > Since portage is supposed to be non-interactive, it shouldn't assume
> > that you're gonna stick around watching the terminal while it does its
> > thing. ;)
>
> Hmmm both are good ideas !! Why don't add some README files, that are
> displayed (instead of queued) at the end of an emerge ?

emerge <stuff> >output 2>&1
less output

-- 
luke

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] A nice idea to improve portage
  2003-06-11  3:18       ` Luke Graham
@ 2003-06-11  5:10         ` Bill Kenworthy
  0 siblings, 0 replies; 56+ messages in thread
From: Bill Kenworthy @ 2003-06-11  5:10 UTC (permalink / raw
  To: Luke Graham; +Cc: list gentoo-dev

Have them added to /var/log/emerge.log so they are there for posterity
as well ... I think this would be a great enhancement.

BillK


On Wed, 2003-06-11 at 11:18, Luke Graham wrote:
> On Wed, 11 Jun 2003 06:20 am, Philippe Lafoucrière wrote:
> > > Honestly, I think I'd much prefer if portage just queued all of those
> > > messages and displayed them at the end of the emerge. If that
> > > information was in a README, you'd have to go, find, and read the README
> > > for every package and dependency that you install. That's a lot of work.
> > > Since portage is supposed to be non-interactive, it shouldn't assume
> > > that you're gonna stick around watching the terminal while it does its
> > > thing. ;)
> >
> > Hmmm both are good ideas !! Why don't add some README files, that are
> > displayed (instead of queued) at the end of an emerge ?
> 
> emerge <stuff> >output 2>&1
> less output
-- 
Bill Kenworthy <billk@iinet.net.au>


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] Readme files for portage (was: A nice idea to improve portage)
  2003-06-11 10:37     ` MooktaKiNG
@ 2003-06-11 10:10       ` Michael Cummings
  2003-06-11 10:44         ` Paul de Vrieze
                           ` (2 more replies)
  0 siblings, 3 replies; 56+ messages in thread
From: Michael Cummings @ 2003-06-11 10:10 UTC (permalink / raw
  To: MooktaKiNG; +Cc: gentoo-dev

On Wed, Jun 11, 2003 at 11:37:02AM +0100, MooktaKiNG wrote:
> Another good reason to have a README is becuase sometimes people
> want to know more about a program. Without having to install it.
> 
> If they can learn about the program before they install. They are
> more aware of how hard/easy the installtion is.

I thought that was one of the reasons the source URL shows up in a
search. It's how I've always checked to see what a package does. README
files, imo, are great in theory but put additional maintenance strain on
a dev. Just my two euros,

Mike

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] Readme files for portage (was: A nice idea to  improve portage)
  2003-06-11 11:52   ` [gentoo-dev] Readme files for portage (was: A nice idea to improve portage) Svyatogor
@ 2003-06-11 10:37     ` MooktaKiNG
  2003-06-11 10:10       ` Michael Cummings
  0 siblings, 1 reply; 56+ messages in thread
From: MooktaKiNG @ 2003-06-11 10:37 UTC (permalink / raw
  To: gentoo-dev

Another good reason to have a README is becuase sometimes people
want to know more about a program. Without having to install it.

If they can learn about the program before they install. They are
more aware of how hard/easy the installtion is.

Or when your trying to help someone. You don't know what that
program does. You read the README. Then you get someidea. Now your
in a much better position to help then before.



> I think it's a greÁt idea. Unfortunately most discussion till now
> was around outputing
> the the info to some log and so on. However the suggestion (which I
> was going to
> make anyway) is much broader. The only pease of information portage
> helds about
> every package is a short description line.
>
> That's ok, if you know what the package does. Know imagine a
> situation when you
> do emerge --pretend something and you get a list packages, some of
> which you have
> no idea about. It would be very useful if you could read a readme
> file for them to see
> what they are actually doing.
>
> Having a readme would also be very useful in many other cases, when
> you want to get
> some info on the package, without going to their web site.
>
> On Tue, 10 Jun 2003 16:40:12 +0100 (BST)
> "MooktaKiNG" <Mooktakim@hotmail.com> wrote:
>
>> I think it would be better if portage included a README file for
>> each ebuild.
>>
>> This i belive is very important becuase gentoo is a bit different
>> from a normal linux.
>>
>> Like when installing a mod_php you run the command:
>>
>> ebuild .../mod_php config
>>
>> after installtion.
>>
>> See when i installed this first i had know idea.
>>
>> I know i know. there are some text at the end of the emerge that
>> says what you should do.
>>
>> But when your doind multiple emerge's one after the other and you
>> leave gentoo todo its thing. You don't see the text.
>>
>> So if there was a nice README file that explain the 'extra'
>> setting
>> needed on each dir in portage then it would make things a LOT
>> easier
>> and would be very helpful.
>>
>> If this already exists please ignore this email.
>>
>> -------------------------------------------------
>> Please wait while you are redirected to my signature......
>>
>> --
>> gentoo-dev@gentoo.org mailing list
>>
>>
>
>
> --
> Sergey Kuleshov <svyatogor@gentoo.org>
> Let the Force be with us!
>
> --
> gentoo-dev@gentoo.org mailing list
>
>


-------------------------------------------------
Please wait while you are redirected to my signature......

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] Readme files for portage (was: A nice idea to improve portage)
  2003-06-11 10:10       ` Michael Cummings
@ 2003-06-11 10:44         ` Paul de Vrieze
  2003-06-11 13:24         ` [gentoo-dev] " D. Tuinstra
  2003-06-11 17:06         ` [gentoo-dev] " MooktaKiNG
  2 siblings, 0 replies; 56+ messages in thread
From: Paul de Vrieze @ 2003-06-11 10:44 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 889 bytes --]

On Wednesday 11 June 2003 12:10, Michael Cummings wrote:
> On Wed, Jun 11, 2003 at 11:37:02AM +0100, MooktaKiNG wrote:
> > Another good reason to have a README is becuase sometimes people
> > want to know more about a program. Without having to install it.
> >
> > If they can learn about the program before they install. They are
> > more aware of how hard/easy the installtion is.
>
> I thought that was one of the reasons the source URL shows up in a
> search. It's how I've always checked to see what a package does. README
> files, imo, are great in theory but put additional maintenance strain on
> a dev. Just my two euros,
>

Most probably the upcomming herds system will introduce a metadata file that 
also includes the possibility for a long description.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.cs.kun.nl/~pauldv

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 56+ messages in thread

* [gentoo-dev] Readme files for portage (was: A nice idea to improve portage)
  2003-06-10 15:40 ` [gentoo-dev] A nice idea to improve portage MooktaKiNG
  2003-06-10 16:07   ` Matthew Kennedy
  2003-06-10 18:05   ` John Robinson
@ 2003-06-11 11:52   ` Svyatogor
  2003-06-11 10:37     ` MooktaKiNG
  2 siblings, 1 reply; 56+ messages in thread
From: Svyatogor @ 2003-06-11 11:52 UTC (permalink / raw
  To: gentoo-dev

I think it's a greаt idea. Unfortunately most discussion till now was around outputing
the the info to some log and so on. However the suggestion (which I was going to
make anyway) is much broader. The only pease of information portage helds about
every package is a short description line. 

That's ok, if you know what the package does. Know imagine a situation when you
do emerge --pretend something and you get a list packages, some of which you have
no idea about. It would be very useful if you could read a readme file for them to see
what they are actually doing.

Having a readme would also be very useful in many other cases, when you want to get
some info on the package, without going to their web site.

On Tue, 10 Jun 2003 16:40:12 +0100 (BST)
"MooktaKiNG" <Mooktakim@hotmail.com> wrote:

> I think it would be better if portage included a README file for
> each ebuild.
> 
> This i belive is very important becuase gentoo is a bit different
> from a normal linux.
> 
> Like when installing a mod_php you run the command:
> 
> ebuild .../mod_php config
> 
> after installtion.
> 
> See when i installed this first i had know idea.
> 
> I know i know. there are some text at the end of the emerge that
> says what you should do.
> 
> But when your doind multiple emerge's one after the other and you
> leave gentoo todo its thing. You don't see the text.
> 
> So if there was a nice README file that explain the 'extra' setting
> needed on each dir in portage then it would make things a LOT easier
> and would be very helpful.
> 
> If this already exists please ignore this email.
> 
> -------------------------------------------------
> Please wait while you are redirected to my signature......
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
> 


-- 
Sergey Kuleshov <svyatogor@gentoo.org>
Let the Force be with us!

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* [gentoo-dev] Re: Readme files for portage (was: A nice idea to improve portage)
  2003-06-11 10:10       ` Michael Cummings
  2003-06-11 10:44         ` Paul de Vrieze
@ 2003-06-11 13:24         ` D. Tuinstra
  2003-06-11 15:47           ` oford
  2003-06-11 17:06         ` [gentoo-dev] " MooktaKiNG
  2 siblings, 1 reply; 56+ messages in thread
From: D. Tuinstra @ 2003-06-11 13:24 UTC (permalink / raw
  To: gentoo-dev

Michael Cummings wrote:

> On Wed, Jun 11, 2003 at 11:37:02AM +0100, MooktaKiNG wrote:
>> Another good reason to have a README is becuase sometimes people
>> want to know more about a program. Without having to install it.
>> 
>> If they can learn about the program before they install. They are
>> more aware of how hard/easy the installtion is.
> 
> I thought that was one of the reasons the source URL shows up in a
> search. It's how I've always checked to see what a package does.
> README files, imo, are great in theory but put additional
> maintenance strain on a dev. Just my two euros,
> 
> Mike

As I see the original proposal, it was to give users essential
post-install information regarding any further steps they need to
take. This kind of information is different from pre-emerge info
that a user uses to decide the desirability of a package.

Pre-emerge info
---------------
Still, a small README could be valuable in some situations. For
example: "This package is included in portage for backwards
compatability for systems that have to interoperate with
MegaCruft's General Ledger FPS. If you don't have to do this you
may wish to consider <KDE-alternate> or <GNOME-alternate>. They
provide the same features within a modern UI, don't hog the CPU,
and don't require you to do manual post-emerge steps. And BTW, the
official site is a pathetic mass of marketing-speak, go to the
user-group page at <URL> instead." This shouldn't be too much of a
dev burden if it's optional and intended to communicate info that
wouldn't be found on an official web page.

A pre-emerge README feature runs the risk of encouraging
editorializing (as above :-), but hey, as long as its kept
reasonable that's part of the fun.

Post-emerge info
----------------
I'm all for it. My wish list: append each package's message to a
file named something like "emerge_messages_<timestamp>". These
would be stored in a standard location relative to the user running
emerge. At the end of the emerge, if the file is empty portage
deletes it and no mention is made of it. If the file is nonempty,
portage displays a standard message directing the user to read it.

Two new emerge commands: 'einfomsg' to write a string to the message
file; 'einfocat' to cat a file to it.

Messages written to the file should be no more than ~25 lines of
text each, with some standard header (e.g., line of dashes, ebuild
name, line of dashes). If 25 lines isn't enough room, the message
should direct the user to more instructions in
/usr/share/doc/<package>.

  --Dwight Tuinstra




--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] Re: Readme files for portage (was: A nice idea to improve portage)
  2003-06-11 13:24         ` [gentoo-dev] " D. Tuinstra
@ 2003-06-11 15:47           ` oford
  0 siblings, 0 replies; 56+ messages in thread
From: oford @ 2003-06-11 15:47 UTC (permalink / raw
  To: D. Tuinstra; +Cc: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 2928 bytes --]

On Wed, 2003-06-11 at 08:24, D. Tuinstra wrote:
> Michael Cummings wrote:
> 
> > On Wed, Jun 11, 2003 at 11:37:02AM +0100, MooktaKiNG wrote:
> >> Another good reason to have a README is becuase sometimes people
> >> want to know more about a program. Without having to install it.
> >> 
> >> If they can learn about the program before they install. They are
> >> more aware of how hard/easy the installtion is.
> > 
> > I thought that was one of the reasons the source URL shows up in a
> > search. It's how I've always checked to see what a package does.
> > README files, imo, are great in theory but put additional
> > maintenance strain on a dev. Just my two euros,
> > 
> > Mike
> 
> As I see the original proposal, it was to give users essential
> post-install information regarding any further steps they need to
> take. This kind of information is different from pre-emerge info
> that a user uses to decide the desirability of a package.
> 
> Pre-emerge info
> ---------------
> Still, a small README could be valuable in some situations. For
> example: "This package is included in portage for backwards
> compatability for systems that have to interoperate with
> MegaCruft's General Ledger FPS. If you don't have to do this you
> may wish to consider <KDE-alternate> or <GNOME-alternate>. They
> provide the same features within a modern UI, don't hog the CPU,
> and don't require you to do manual post-emerge steps. And BTW, the
> official site is a pathetic mass of marketing-speak, go to the
> user-group page at <URL> instead." This shouldn't be too much of a
> dev burden if it's optional and intended to communicate info that
> wouldn't be found on an official web page.
> 
> A pre-emerge README feature runs the risk of encouraging
> editorializing (as above :-), but hey, as long as its kept
> reasonable that's part of the fun.
> 
> Post-emerge info
> ----------------
> I'm all for it. My wish list: append each package's message to a
> file named something like "emerge_messages_<timestamp>". These
> would be stored in a standard location relative to the user running
> emerge. At the end of the emerge, if the file is empty portage
> deletes it and no mention is made of it. If the file is nonempty,
> portage displays a standard message directing the user to read it.
> 
> Two new emerge commands: 'einfomsg' to write a string to the message
> file; 'einfocat' to cat a file to it.
> 
> Messages written to the file should be no more than ~25 lines of
> text each, with some standard header (e.g., line of dashes, ebuild
> name, line of dashes). If 25 lines isn't enough room, the message
> should direct the user to more instructions in
> /usr/share/doc/<package>.

It should also state which ebuild it belongs to in a very prominent
place.  I know it sounds obvious but that kind of detail is important :)

-- 
Owen Ford <oford@ev1.net>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] Readme files for portage (was: A nice idea to  improve portage)
  2003-06-11 10:10       ` Michael Cummings
  2003-06-11 10:44         ` Paul de Vrieze
  2003-06-11 13:24         ` [gentoo-dev] " D. Tuinstra
@ 2003-06-11 17:06         ` MooktaKiNG
  2 siblings, 0 replies; 56+ messages in thread
From: MooktaKiNG @ 2003-06-11 17:06 UTC (permalink / raw
  To: gentoo-dev

the URL is a great info to have. However some program have been
modified to suite gentoo. and this is the reason why i think there
should be a readme.

I don't think it too much extra work.

If you think about it. It's just a small portion of the time it
takes to make the actual ebuild.
I do appreciate what people do here, building ebuils and all.

I haven't does this yet. Gonna try to make one in the future i hope.

> On Wed, Jun 11, 2003 at 11:37:02AM +0100, MooktaKiNG wrote:
>> Another good reason to have a README is becuase sometimes people
>> want to know more about a program. Without having to install it.
>>
>> If they can learn about the program before they install. They are
>> more aware of how hard/easy the installtion is.
>
> I thought that was one of the reasons the source URL shows up in a
> search. It's how I've always checked to see what a package does.
> README
> files, imo, are great in theory but put additional maintenance
> strain on
> a dev. Just my two euros,
>
> Mike
>
> --
> gentoo-dev@gentoo.org mailing list
>
>


-------------------------------------------------
Please wait while you are redirected to my signature......

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-06-10 14:25 [gentoo-dev] ebuild question MAL
  2003-06-10 15:40 ` [gentoo-dev] A nice idea to improve portage MooktaKiNG
@ 2003-06-12 11:34 ` Amiel Martin
  1 sibling, 0 replies; 56+ messages in thread
From: Amiel Martin @ 2003-06-12 11:34 UTC (permalink / raw
  To: MAL; +Cc: gentoo-dev

What Ive seen in other ebuilds is a file with the default options
that just gets sent to the "interactive setup script via stin. (ie no need
for expect)

take a look at /usr/portage/app-games/freecraft/freecraft-1.18.ebuild
and /usr/portage/app-games/freecraft/files/setup.input

cat ${FILESDIR}/setup.input | ./setup || die "setup failed"

nothing offical, just my observations


-AMiel




On Tue, 10 Jun 2003, MAL wrote:

I'm writing an ebuild for ZoneMinder, and I have a few problems/queries..

The program is a bunch of php and a few cgi apps.  After configuring, 
the package asks you to run a perl script which interactively asks you 
for initial configuration, then updates the .php files with this info. 
'make install' then installs the .php files into your document root, 
(and the cgi into your cgi-bin dir).

Now, I don't want to break the non-interactivity of portage, but I can't 
just leave an 'einfo' message to the user after install, asking them to 
run the perl script, because this must be done before install.

So, do I either:

* Use expect to answer the perl script's questions with some sensible 
defaults, then leave a message to the user on how to change these 
defaults after install, (in which case, should I add expect to the 
DEPEND line?)

* Re-package the software entirely, (there is a compiled part and a 
non-compiled php part.. maybe separate the php part out).  I'm kinda 
loathed to do this, as it seems like unnecessary maintenance.

* Modify the perl script to automatically set certain defaults.


Additionally, what do I do about the location of apache, and the 
user/group to set the php files as? :)
I noticed the recent eclass submission, but I'm assuming I can't use 
that just yet, so /home/httpd/htdocs and apache:apache ?

Cheers,
MAL


--
gentoo-dev@gentoo.org mailing list


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* [gentoo-dev] ebuild question
@ 2003-09-19 14:57 Philippe Lafoucrière
  2003-09-19 15:03 ` Georgi Georgiev
  2003-09-19 15:05 ` Thomas de Grenier de Latour
  0 siblings, 2 replies; 56+ messages in thread
From: Philippe Lafoucrière @ 2003-09-19 14:57 UTC (permalink / raw
  To: Gentoo-dev

warning : noob question...

I've made an ebuild for the new plastik theme for KDE. When emerging, I
have some warnings like this :

/usr/sbin/ebuild.sh: line 108: /dev/stdout: Permission denied

Any idea ?

here's the ebuild :




# Copyright 1999-2003 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# $Header:$

inherit kde
need-kde 3.1

DESCRIPTION="Plastik is a widget style and window decoration for KDE
3.x."
HOMEPAGE="http://www.kde-look.org/content/show.php?content=7559"
SRC_URI="http://www.kdelook.org/content/files/7559-${P}.tar.gz"

LICENSE="GPL-2"
SLOT="0"
DEPEND="kde-base/kdebase"
KEYWORDS="x86 ~ppc ~sparc ~alpha"
RESTRICT="nomirror"

pkg_postinst(){
        ewarn "HOW TO USE THIS THEME FOR KDE:"
        einfo ""
        einfo "Open the KDE-Menu and start the Control Center."
        einfo "Select \"Look and Feel\"."
        einfo "Select \"Style\" if the package you installed was a
style, or"
        einfo "select \"Theme Manager\" if the package you installed was
a theme."
        einfo "Select your theme or style."
        einfo "Click \"Apply\""
        einfo ""
        einfo "Have fun! :-)"
}


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-09-19 14:57 Philippe Lafoucrière
@ 2003-09-19 15:03 ` Georgi Georgiev
  2003-09-19 15:12   ` Philippe Lafoucrière
  2003-09-19 15:05 ` Thomas de Grenier de Latour
  1 sibling, 1 reply; 56+ messages in thread
From: Georgi Georgiev @ 2003-09-19 15:03 UTC (permalink / raw
  To: Gentoo-dev

On 19/09/2003 at 16:57:27(+0200), Philippe Lafoucrière used 1.2K just to say:
> warning : noob question...
> 
> I've made an ebuild for the new plastik theme for KDE. When emerging, I
> have some warnings like this :
> 
> /usr/sbin/ebuild.sh: line 108: /dev/stdout: Permission denied
> 
> Any idea ?

I get this error when I don't have a /dev/stdout file. For example emerging in
a chrooted environment, that doesn't have a /dev mounted. I also get it on a
system where I don't have devfsd installed. Doesn't hurt that much, though.

-- 
 /   Georgi Georgiev    / Treaties are like roses and young girls --    /
\     chutz@gg3.net    \  they last while they last. -- Charles        \
 /  +81(90)6266-1163    / DeGaulle                                      /

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-09-19 14:57 Philippe Lafoucrière
  2003-09-19 15:03 ` Georgi Georgiev
@ 2003-09-19 15:05 ` Thomas de Grenier de Latour
  2003-09-19 15:15   ` Philippe Lafoucrière
  1 sibling, 1 reply; 56+ messages in thread
From: Thomas de Grenier de Latour @ 2003-09-19 15:05 UTC (permalink / raw
  To: gentoo-dev

En réponse à Philippe Lafoucrière <lafou@wanadoo.fr>:

> /usr/sbin/ebuild.sh: line 108: /dev/stdout: Permission denied

Small portage bug, nothing to worry about.
http://bugs.gentoo.org/show_bug.cgi?id=27306

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-09-19 15:03 ` Georgi Georgiev
@ 2003-09-19 15:12   ` Philippe Lafoucrière
  2003-09-19 15:26     ` Georgi Georgiev
  0 siblings, 1 reply; 56+ messages in thread
From: Philippe Lafoucrière @ 2003-09-19 15:12 UTC (permalink / raw
  To: Gentoo-dev


> I get this error when I don't have a /dev/stdout file. For example emerging in
> a chrooted environment, that doesn't have a /dev mounted. I also get it on a
> system where I don't have devfsd installed. Doesn't hurt that much, though.

$ ll /dev/stdout 
lr-xr-xr-x    1 root     root            4 Sep 19 09:17 /dev/stdout ->
fd/1


$ ll /dev/fd/1   
lrwx------    1 root     root           64 Sep 19 17:10 /dev/fd/1 ->
/dev/pts/3

ll /dev/pts/3 
crw--w----    1 gravis   tty      136,   3 Sep 19 17:10 /dev/pts/3

its own by gravis (my username). It's probably an access problem. Should
I submit a bug report for this ?


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-09-19 15:05 ` Thomas de Grenier de Latour
@ 2003-09-19 15:15   ` Philippe Lafoucrière
  0 siblings, 0 replies; 56+ messages in thread
From: Philippe Lafoucrière @ 2003-09-19 15:15 UTC (permalink / raw
  To: Thomas de Grenier de Latour; +Cc: Gentoo-dev


> Small portage bug, nothing to worry about.
> http://bugs.gentoo.org/show_bug.cgi?id=27306

k thank you :)


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2003-09-19 15:12   ` Philippe Lafoucrière
@ 2003-09-19 15:26     ` Georgi Georgiev
  0 siblings, 0 replies; 56+ messages in thread
From: Georgi Georgiev @ 2003-09-19 15:26 UTC (permalink / raw
  To: Gentoo-dev

On 19/09/2003 at 17:12:41(+0200), Philippe Lafoucri鑽e used 0.6K just to say:
> 
> > I get this error when I don't have a /dev/stdout file. For example emerging in
> > a chrooted environment, that doesn't have a /dev mounted. I also get it on a
> > system where I don't have devfsd installed. Doesn't hurt that much, though.
> 
> $ ll /dev/stdout 
> lr-xr-xr-x    1 root     root            4 Sep 19 09:17 /dev/stdout ->
> fd/1
> 
> 
> $ ll /dev/fd/1   
> lrwx------    1 root     root           64 Sep 19 17:10 /dev/fd/1 ->
> /dev/pts/3
> 
> ll /dev/pts/3 
> crw--w----    1 gravis   tty      136,   3 Sep 19 17:10 /dev/pts/3
> 
> its own by gravis (my username). It's probably an access problem. Should
> I submit a bug report for this ?

I didn't get the idea of your post.... This cannot be a permissions problem,
because:

$ ll /dev/fd
lr-xr-xr-x    1 root     root           13 Sep 17 00:43 /dev/fd -> /proc/self/fd
$ ll /proc/self
lrwxrwxrwx    1 root     root           64 Sep 20 00:14 /proc/self -> 18278

You get the idea. The /dev/fd link always points to the file descriptors of the
process looking at that directory. For example

chutz@lion chutz $ ll /dev/fd/
total 0
lrwx------    1 chutz    users          64 Sep 20 00:22 0 -> /dev/pts/1
lrwx------    1 chutz    users          64 Sep 20 00:22 1 -> /dev/pts/1
lrwx------    1 chutz    users          64 Sep 20 00:22 2 -> /dev/pts/1
lr-x------    1 chutz    users          64 Sep 20 00:22 3 -> /proc/18381/fd

chutz@lion chutz $ ll /dev/fd/ 7>&1
total 0
lrwx------    1 chutz    users          64 Sep 20 00:22 0 -> /dev/pts/1
lrwx------    1 chutz    users          64 Sep 20 00:22 1 -> /dev/pts/1
lrwx------    1 chutz    users          64 Sep 20 00:22 2 -> /dev/pts/1
lr-x------    1 chutz    users          64 Sep 20 00:22 3 -> /proc/18382/fd
lrwx------    1 chutz    users          64 Sep 20 00:22 7 -> /dev/pts/1

chutz@lion chutz $ find /dev/fd/
/dev/fd/
/dev/fd/0
/dev/fd/1
/dev/fd/2
/dev/fd/3
/dev/fd/4

chutz@lion chutz $ echo /dev/fd/*
/dev/fd/0 /dev/fd/1 /dev/fd/2 /dev/fd/255 /dev/fd/3

The /dev/fd link is maintained by devfsd.

-- 
(    Georgi Georgiev   (  If only one could get that wonderful feeling (
 )    chutz@gg3.net     ) of accomplishment without having to           )
(   +81(90)6266-1163   (  accomplish anything.                         (

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* [gentoo-dev] ebuild question
@ 2005-03-03  3:40 pepone pepone
  2005-03-03  3:47 ` Jeremy Hanmer
  0 siblings, 1 reply; 56+ messages in thread
From: pepone pepone @ 2005-03-03  3:40 UTC (permalink / raw
  To: gentoo-dev

Hello I ´m trying to create a new ebuild for Ice (Internet Comunication Engine)
       http://www.zeroc.com

       this is my first ebuild and i want know how in my ebuild can
detect the version of a  program that is installed in the system

the problem is that in order to suscefuly compile my package i need to
export DB_FLAGS  and DB_IFLAGS acording to the db version that is instaled
in the system

thanks in adavantage

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2005-03-03  3:40 pepone pepone
@ 2005-03-03  3:47 ` Jeremy Hanmer
  2005-03-03 10:26   ` Aaron Walker
  0 siblings, 1 reply; 56+ messages in thread
From: Jeremy Hanmer @ 2005-03-03  3:47 UTC (permalink / raw
  To: gentoo-dev

you should be able to use the has_version function.  More details at  
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml? 
part=2&chap=1




On Mar 2, 2005, at 7:40 PM, pepone pepone wrote:

> Hello I ´m trying to create a new ebuild for Ice (Internet  
> Comunication Engine)
>        http://www.zeroc.com
>
>        this is my first ebuild and i want know how in my ebuild can
> detect the version of a  program that is installed in the system
>
> the problem is that in order to suscefuly compile my package i need to
> export DB_FLAGS  and DB_IFLAGS acording to the db version that is  
> instaled
> in the system
>
> thanks in adavantage
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2005-03-03  3:47 ` Jeremy Hanmer
@ 2005-03-03 10:26   ` Aaron Walker
  2005-03-03 20:23     ` Jeremy Hanmer
  0 siblings, 1 reply; 56+ messages in thread
From: Aaron Walker @ 2005-03-03 10:26 UTC (permalink / raw
  To: gentoo-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Hanmer wrote:
> you should be able to use the has_version function.  More details at 
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml? part=2&chap=1

has_version only returns 0 or 1 depending whether the package is installed or
not, so it's useless in this case.  best_version would be a better alternative,
however that alone won't solve the problem.

Read about best_version in the ebuild(5) manual page.  After you're done with
that, read about the versionator eclass in the versionator.eclass(5) manual
page (may have to emerge portage-manpages).  You'll probably have to use a
combination of both to do what you're trying to achieve.

HTH

- --
printk(KERN_EMERG "PCI: Tell willy he's wrong
");
        linux-2.6.6/arch/parisc/kernel/pci.c

Aaron Walker <ka0ttic@gentoo.org>
[ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCJuZhC3poscuANHARAno+AJ0S4wl1FnzHKuKSeNj92CBKMsOpogCgmhrR
9lSrUePKgaiEePdqlNVZpaM=
=bznu
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2005-03-03 10:26   ` Aaron Walker
@ 2005-03-03 20:23     ` Jeremy Hanmer
  2005-03-04  0:42       ` Aaron Walker
  0 siblings, 1 reply; 56+ messages in thread
From: Jeremy Hanmer @ 2005-03-03 20:23 UTC (permalink / raw
  To: gentoo-dev


On Mar 3, 2005, at 2:26 AM, Aaron Walker wrote:
>
> has_version only returns 0 or 1 depending whether the package is 
> installed or
> not, so it's useless in this case.  best_version would be a better 
> alternative,
> however that alone won't solve the problem.

That's all that's really needed since all you'd care about in this 
instance is the existance of one of 2 or 3 major versions.  Just look 
for >=sys-libs-4.0 then 3.0 and so-on, compiling for the first one you 
find.

> Read about best_version in the ebuild(5) manual page.  After you're 
> done with
> that, read about the versionator eclass in the versionator.eclass(5) 
> manual
> page (may have to emerge portage-manpages).  You'll probably have to 
> use a
> combination of both to do what you're trying to achieve.
>
> HTH
>
> - --
> printk(KERN_EMERG "PCI: Tell willy he's wrong
> ");
>         linux-2.6.6/arch/parisc/kernel/pci.c
>
> Aaron Walker <ka0ttic@gentoo.org>
> [ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | 
> web-apps ]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (GNU/Linux)
>
> iD8DBQFCJuZhC3poscuANHARAno+AJ0S4wl1FnzHKuKSeNj92CBKMsOpogCgmhrR
> 9lSrUePKgaiEePdqlNVZpaM=
> =bznu
> -----END PGP SIGNATURE-----
> --
> gentoo-dev@gentoo.org mailing list
>

--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

* Re: [gentoo-dev] ebuild question
  2005-03-03 20:23     ` Jeremy Hanmer
@ 2005-03-04  0:42       ` Aaron Walker
  0 siblings, 0 replies; 56+ messages in thread
From: Aaron Walker @ 2005-03-04  0:42 UTC (permalink / raw
  To: gentoo-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Hanmer wrote:
> 
> On Mar 3, 2005, at 2:26 AM, Aaron Walker wrote:
> 
>>
>> has_version only returns 0 or 1 depending whether the package is
>> installed or
>> not, so it's useless in this case.  best_version would be a better
>> alternative,
>> however that alone won't solve the problem.
> 
> 
> That's all that's really needed since all you'd care about in this
> instance is the existance of one of 2 or 3 major versions.  Just look
> for >=sys-libs-4.0 then 3.0 and so-on, compiling for the first one you
> find.

That would be the incorrect way of going about it.  As I said in my previous
post, use versionator.eclass.  One call to best_version and one call to
get_major_version is all that's needed.

- --
Love America -- or give it back.

Aaron Walker <ka0ttic@gentoo.org>
[ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCJ678C3poscuANHARAn1hAKDGWTixj9QVHjCMLgzLu75yLmywbgCfT1+h
YlWOglosHIp5XrbfHE/u4XA=
=VZ1q
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 56+ messages in thread

end of thread, other threads:[~2005-03-04  0:42 UTC | newest]

Thread overview: 56+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-06-10 14:25 [gentoo-dev] ebuild question MAL
2003-06-10 15:40 ` [gentoo-dev] A nice idea to improve portage MooktaKiNG
2003-06-10 16:07   ` Matthew Kennedy
2003-06-10 18:05   ` John Robinson
2003-06-10 20:20     ` Philippe Lafoucrière
2003-06-11  3:18       ` Luke Graham
2003-06-11  5:10         ` Bill Kenworthy
2003-06-10 21:56     ` MooktaKiNG
2003-06-10 21:42       ` Zach Forrest
2003-06-10 23:26         ` Kumba
2003-06-11 11:52   ` [gentoo-dev] Readme files for portage (was: A nice idea to improve portage) Svyatogor
2003-06-11 10:37     ` MooktaKiNG
2003-06-11 10:10       ` Michael Cummings
2003-06-11 10:44         ` Paul de Vrieze
2003-06-11 13:24         ` [gentoo-dev] " D. Tuinstra
2003-06-11 15:47           ` oford
2003-06-11 17:06         ` [gentoo-dev] " MooktaKiNG
2003-06-12 11:34 ` [gentoo-dev] ebuild question Amiel Martin
  -- strict thread matches above, loose matches on Subject: below --
2005-03-03  3:40 pepone pepone
2005-03-03  3:47 ` Jeremy Hanmer
2005-03-03 10:26   ` Aaron Walker
2005-03-03 20:23     ` Jeremy Hanmer
2005-03-04  0:42       ` Aaron Walker
2003-09-19 14:57 Philippe Lafoucrière
2003-09-19 15:03 ` Georgi Georgiev
2003-09-19 15:12   ` Philippe Lafoucrière
2003-09-19 15:26     ` Georgi Georgiev
2003-09-19 15:05 ` Thomas de Grenier de Latour
2003-09-19 15:15   ` Philippe Lafoucrière
2003-05-30 15:17 William Hubbs
2003-05-30 15:27 ` Grant Goodyear
2003-05-31  3:00   ` Georgi Georgiev
2003-05-30 11:15 MAL
2003-05-30 11:29 ` Alastair Tse
2003-05-30 14:22   ` MAL
2003-05-30 14:33     ` Alastair Tse
2003-05-30 14:40       ` Todd Berman
2003-05-30 14:55         ` Jon Portnoy
2003-05-30 15:08           ` MAL
2003-05-30 14:39     ` Seemant Kulleen
2003-05-30 15:09       ` Seemant Kulleen
2002-11-26 21:27 Per Wigren
2002-11-26 21:23 ` Dan Armak
2002-11-27  0:03   ` Per Wigren
2002-07-26 14:54 John Matthews
2002-04-18  6:13 Avi Schwartz
2002-04-18  6:59 ` George Shapovalov
2002-04-18  7:15 ` Tod M Neidt
2002-04-17  5:21 Richard Jackson
2002-04-17  5:02 ` Jared H. Hudson
2002-04-17  6:05   ` Richard Jackson
2002-04-17  5:21     ` Jared H. Hudson
2002-02-07  3:44 Edward Muller
2002-02-07  4:43 ` Tod M Neidt
2001-08-05 15:50 Craig Joly
2001-08-05 17:07 ` Daniel Robbins

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox