[gentoo-dev] Bashrc mini HOWTO

[Chris White]

Hi guys,

Well, I was working on my bashrc one day and thought, "gee, would be 
nice for other people to know what the heck is going on too!".  Well, I decided 
to go ahead and do that :P.  So, here we go, a mini bashrc HOWTO (note this 
only works on the latest stable of portage.  You go grab cvs head and try this, 
you can kiss yer but goodbye! :D).

HOW DOES IT WORK

if [ -f "${PORTAGE_BASHRC}" ]; then
source "${PORTAGE_BASHRC}"

This little code in ebuild.sh pretty much sums it up.  Basically, when 
ebuild.sh is run with various ebuild stages (unpack, compile, postinst, etc.. 
etc.. etc.), it sources the bashrc file (located in /etc/portage/bashrc), 
giving it the exact same environment as ebuild.sh has.  So, your bashrc file 
pretty much ends up like a mini ebuild.  Now that we've explained that, let's 
get down and dirty.

LET'S USE IT

case "$*"  in
# stay really quiet here.
depend) : ;;
*)
[ "$*" = "compile" ] && package-pre-compile
[ "$*" = "postinst" ] && package-post-install
;;
esac

Here's some sample code for my small bashrc file.  This is something I pulled 
from solar's bashrc and adjusted it a bit.  "$*" is all parameters passed to 
the program.  This means the ebuild stage in this particular case.  So 
package-pre-compile is run when the compile stage is hit, and 
package-post-install is run when the postinst stage is hit.  Here, depend is 
silenced, as ebuilds get depend'ed a LOT, things get kind of noisy.  Now that 
we know what stages we can run stuff at, let's see what we can do with 
environmental variables.

ENVIRONMENTAL VARIABLES

Well, first off portage is kind of restrictive.  That said, anything you need 
to pull from /usr/bin  you're probably going to have to add it to PATH:

package-post-install() {
PATH=$PATH:/usr/sbin:/usr/bin:/bin:/sbin

As such.  If you have program not found errors, chances are you didn't do this. 
 So now, what about FEATURES.  That's right,  you can actually use FEATURES as 
well to cook up some nice stuff.  In my case, I had portage update the whatis 
database when it's done installing.  This is nice because I'm horribly lazy and 
wouldn't have the guts to do it manually/add a cron job.  Here we go:

if has whatis ${FEATURES} && test -x 
/usr/sbin/makewhatis ; then
echo "*** whatis enabled.  Updating the whatis 
database..."
# update the whatis database
`makewhatis -u`
fi
}

Alright so, remember how I said that bashrc is a mini-ebuild?  Note how you can 
use the same "has" command that ebuilds can.  This is because we're being 
sourced from ebuild.sh, and therefore have all its functions.  What does that 
mean?  That means you get this:

addread
addwrite
adddeny
addpredict
esyslog
use
usev
useq
has
hasv
hasq
has_version
portageq
best_version
use_with
use_enable
diefunc
check_KV
keepdir
unpack
strip_duplicate_slashes
all the stuff described in man 5 ebuild (too lazy to list here)
killparent
remove_path_entry
do_newdepend
inherit (yes.. you can inherit eclasses.. weird ain't it...)
debug-print-function
debug-print-section

And you also notice FEATURES.  It can even do all the nifty portage variables 
too (default and in /etc/make.conf).  So that's it, with this nice little touch 
you can do cool customizations to the portage process, without messing with 
portage code ;).

Chris White
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] where to put *.pm files

[Rene Zbinden]

Hi 

I am writing a new ebuild. The program contains a perlscript (mainprog.pl) 
which needs two perl modules like (module1.pm module2.pm)

I will put mainprog.pl in /usr/bin but where do I put the two modules. Shall I 
put them in /usr/share/programename and put that to the perl path?

-- 
cheers,
reen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Maintaining an ebuild

[Fredrik Tolf]

On Wed, 2005-05-25 at 02:34 +0200, Jonas Geiregat wrote:
> Fredrik Tolf wrote:
> >The thing is, I've got a li'l program of mine that I'd like to have in
> >portage. I've written an ebuild and all (which works with
> >PORTDIR_OVERLAY), but I have no idea if I can maintain it myself in
> >portage (and, in that case, how I would acquire the permission for that)
> >or if I have to ask someone on the inside to do it for me (and, in that
> >case, who I should ask).
> Not really a FAQ but you can find the answer here :
> http://www.gentoo.org/doc/en/ebuild-submit.xml

Exactly what I was looking for. Thanks!

Fredrik Tolf


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Maintaining an ebuild

[Jonas Geiregat]

Fredrik Tolf wrote:

>Hi List!
>
>This is probably a FAQ, but I really couldn't find the answer. I've
>STFW'd, RTFM'd and RTFDeveloper's Handbook, but I still have no answer.
>
>The thing is, I've got a li'l program of mine that I'd like to have in
>portage. I've written an ebuild and all (which works with
>PORTDIR_OVERLAY), but I have no idea if I can maintain it myself in
>portage (and, in that case, how I would acquire the permission for that)
>or if I have to ask someone on the inside to do it for me (and, in that
>case, who I should ask).
>
>Flame me all you want, but please point out where it says at the same
>time. ;-)
>
>Fredrik Tolf
>
>
>  
>
Not really a FAQ but you can find the answer here :
http://www.gentoo.org/doc/en/ebuild-submit.xml
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Maintaining an ebuild

[Fredrik Tolf]

Hi List!

This is probably a FAQ, but I really couldn't find the answer. I've
STFW'd, RTFM'd and RTFDeveloper's Handbook, but I still have no answer.

The thing is, I've got a li'l program of mine that I'd like to have in
portage. I've written an ebuild and all (which works with
PORTDIR_OVERLAY), but I have no idea if I can maintain it myself in
portage (and, in that case, how I would acquire the permission for that)
or if I have to ask someone on the inside to do it for me (and, in that
case, who I should ask).

Flame me all you want, but please point out where it says at the same
time. ;-)

Fredrik Tolf


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] i have an idea ! (erescue) ro-overlays

[Stuart Longland]

Mike Frysinger wrote:
> On Tuesday 24 May 2005 06:34 pm, Jim Northrup wrote:
> 
>>of course bb is a space-saver, but i find myself turning the room upside
>>down for full-static versions of tar, nc and fileutils
> 
> 
> bb is static and it supports tar, nc, and many fileutils ;)
> -mike

If only a little crippled in functionality compared to their full
equivalents... :-)

Although for what BusyBox is... it's a great tool.
-- 
+-+
| Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org |
| Atomic Linux Project -oOo-http://atomicl.berlios.de |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| I haven't lost my mind - it's backed up on a tape somewhere |
+-+


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Pinboard of outdated ports

[Homer Parker]

On Tue, 2005-05-24 at 14:44 -0600, R Hill wrote:
> > What we really need is to have the AT program extended from just
> amd64
> > to every arch, including x86 (which desperately needs an arch team).
> 
> Really?  What does such a team do?

Glad you asked ;) 



-- 
Homer Parker
Gentoo/AMD64 Arch Tester Operational Lead
[EMAIL PROTECTED]


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] i have an idea ! (erescue) ro-overlays

[Mike Frysinger]

On Tuesday 24 May 2005 06:34 pm, Jim Northrup wrote:
> of course bb is a space-saver, but i find myself turning the room upside
> down for full-static versions of tar, nc and fileutils

bb is static and it supports tar, nc, and many fileutils ;)
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] i have an idea ! (erescue) ro-overlays

[Jim Northrup]

Mike Frysinger wrote:


On Tuesday 24 May 2005 05:11 pm, Jim Northrup wrote:
 


but a CF-based or initrd root available when /lib goes to hell is
an absolute must for supporting fault tolerance.
   



do you mean like the disk underneath /lib is blown to crap or a bad glibc is 
merged ?


if the latter, then the new busybox can help ... just boot with init=/bin/bb 
and you should have plenty of tools to recover with

-mike
 


great advice.

I've learned whenever md or devfs rework occurs, or the **/sbin tools 
get rev'd, its foolish to proceed without a rescue nearby.


of course bb is a space-saver, but i find myself turning the room upside 
down for full-static versions of tar, nc and fileutils


Jim
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] root:root and fbsd

[Mike Frysinger]

On Tuesday 24 May 2005 04:26 pm, Diego 'Flameeyes' Pettenò wrote:
> On Sunday 22 May 2005 11:09, Stuart Longland wrote:
> > Why not just use `chmod -R 0:0 ${D}`?  That should have the desired
> > effect?
>
> Yes that will have so that should be good for all systems. For me that is
> ok... nobody disagrees?

only other idea i'd consider is having portage scan $D before each merge 
looking for files owned by group portage ?  or perhaps making an eutils func 
for people to invoke ...

but this is probably just as much cruft as the get_root_group() idea ... i 
imagine if someone comes up with a reason down the road why using gid 0 is a 
bad idea, they'll let us know and we can review this again

Diego: feel free to commit the wheel -> 0 group change
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Pinboard of outdated ports

[Johannes Weiner]

> I whipped up this site because the herds I'm in have a gazillion
> packages:
> http://gentooexperimental.org/meatoo/
> 
> It needs some work but it'd be easy to send out mail to
> subscribers by herd or maintainer email instead of subscribing to
> dozens of individual freshmeat packages. Or when the command-line
> tool is done you can check whenever you want by herd name.

This is even cooler than the pinboard idea. Nice one!

-- 
Today is Prickle-Prickle, the 71st day of Discord in the YOLD 3171


pgpaHQ9J8Npmv.pgp
Description: PGP signature

Re: [gentoo-dev] i have an idea ! (erescue) ro-overlays

[Mike Frysinger]

On Tuesday 24 May 2005 05:11 pm, Jim Northrup wrote:
> but a CF-based or initrd root available when /lib goes to hell is
> an absolute must for supporting fault tolerance.

do you mean like the disk underneath /lib is blown to crap or a bad glibc is 
merged ?

if the latter, then the new busybox can help ... just boot with init=/bin/bb 
and you should have plenty of tools to recover with
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Pinboard of outdated ports

[Diego 'Flameeyes' Pettenò]

On Tuesday 24 May 2005 23:12, Donnie Berkholz wrote:
> Except for all the areas lacking these arch testers...
Better avoid messing with it if ATs are missing... you fool up the results of 
a query based on those keywords.

Until ATs are just amd64-only, better avoid using that keyword elsewhere... 
another keyword can be useful, in case.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/



pgpVxIxrTeJS9.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Pinboard of outdated ports

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Diego 'Flameeyes' Pettenò wrote:
> On Tuesday 24 May 2005 22:44, R Hill wrote:
> 
>>I like this.  It could probably be done through keywording, and in fact
>>the keywords are already there (ebuild and tested)[1].
> 
> TESTED is not something a simple user should ever use.
> That's used by Arch Tester to let developers know they have tried it 
> themselves.
> Users *must not* use that keyword.

Except for all the areas lacking these arch testers...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCk5iuXVaO67S1rtsRAlKqAJwKDeDj1yMVlZy0wpuXS5KFqubVSwCeNFhy
Nrn9XGfl2nINu0lMXyRDDAk=
=1Ngd
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] i have an idea ! (erescue) ro-overlays

[Jim Northrup]

I had smashing success migratingraid volumes to a new motherboard by 
building a readonly loopback boot-cd rootfs volume, and using


cp -sr /mnt/rescue /mnt/newroot

before building stage2,3;  with minor /etc grumbling, the system 
bootstrapped flawlessly while still borrowing a few sensitive static 
utils where combinations of kernel, gcc and libc could otherwise wreak havoc


I'm very happy with new GUID-based volume mounting and more stable raid 
tools, but a CF-based or initrd root available when /lib goes to hell is 
an absolute must for supporting fault tolerance.



Chris Gianelloni wrote:


On Tue, 2005-05-17 at 10:33 -0700, Donnie Berkholz wrote:
 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Gianelloni wrote:
   


A much better approach would be for there to be a rescue build,
completely independent of the stages, since it doesn't need to mirror
them in any way.  It should be extracted (self-extracted?) to something
like /rescue and executed from there, being completely self-contained.
This keeps it from stomping on system files and breaking
collision-protect or doing anything else nasty like hosing configuration
files (ever made the mistake of extracting a stage onto a live
filesystem?) when unpacked.
 


This sounds a lot like saying, use an initrd, but when you pivot roots
to the live filesystem, leave it mounted somewhere.
   



Kinda... This wouldn't require a reboot, though.  When the user is done,
they simply rm -rf /rescue and their system is clean again.
 

  
--

gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Pinboard of outdated ports

[Diego 'Flameeyes' Pettenò]

On Tuesday 24 May 2005 22:44, R Hill wrote:
> I like this.  It could probably be done through keywording, and in fact
> the keywords are already there (ebuild and tested)[1].
TESTED is not something a simple user should ever use.
That's used by Arch Tester to let developers know they have tried it 
themselves.
Users *must not* use that keyword.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/



pgpvoottU6f58.pgp
Description: PGP signature

[gentoo-dev] Re: Pinboard of outdated ports

[R Hill]

Chris Gianelloni wrote:

I dunno if it's really big work to have a look at one site to see if
there are ebuilds you missed when they were updated.
It was not my intention to make really more work. It was just to find a faster
way for outdated ebuilds getting updated.



There is really only one way to do this.  Figure out how to give the
developers more time to develop.


Right.  I think most maintainers keep on top of what's happening with 
their charges.  It's not that they've missed the fact that a new version 
has been released, it's that they haven't had the time to bump it yet. 
This might be less true for pkgs that don't have a single maintainer but 
are covered by a herd, but even in that case it's a matter of having 
time, not being oblivious that there's an update.



Having to search through bugs.gentoo.org, plus some external site, would
increase the time needed to find packages in need of upgrade, as some
will be filed as bugs, which would need to be resolved, so they would
have to be searched for *anyway* in bugzilla.

The most productive thing you could do, would be to figure out a simple
way of testing ebuilds, marking them as tested, and assigning them to
the proper parties quicker than is being done now.


I like this.  It could probably be done through keywording, and in fact 
the keywords are already there (ebuild and tested)[1].  They just never 
get used. ;)  Maybe raising people's (user's) awareness of their 
existence and how to use them properly would help.  I'd be willing to 
write up a Bugzilla user-guide if there's any interest in it; I've been 
meaning to write one for the wiki/forum anyways.


As for what happens after a ebuild is tested, I see a couple options. 
Devs can always just keep doing what they do now and just use the tested 
keyword as a handy at-a-glance reference.  Or, you could implement the 
Bugzilla request system[2][3] to allow a tester to flag a bug ready for 
review by a developer.  I think this would both improve the turn-around 
time on bumps and save some time for the devs by letting them know that 
any such request both has an ebuild attached and that ebuild has been 
tested by the community.  Adding a review request flag does add a little 
more complexity to the process of using bugzilla, but with proper user 
documentation I think the benefit will outweigh the cost.



What we really need is to have the AT program extended from just amd64
to every arch, including x86 (which desperately needs an arch team).


Really?  What does such a team do?

--de.


[1]https://bugs.gentoo.org/describekeywords.cgi
[2]http://www.bugzilla.org/features/#rs
[3]https://bugzilla.mozilla.org/flag-help.html

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] root:root and fbsd

[Diego 'Flameeyes' Pettenò]

On Sunday 22 May 2005 11:09, Stuart Longland wrote:
> Why not just use `chmod -R 0:0 ${D}`?  That should have the desired effect?
Yes that will have so that should be good for all systems. For me that is 
ok... nobody disagrees?

If it's ok... Mike commit the eclass so that sys-devel/gcc will works (quite) 
out of the box :)

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/



pgpp7GSeUDtU6.pgp
Description: PGP signature

Re: [gentoo-dev] Gentoo Conference - Call for ideas

[Nathaniel McCallum]

Donnie Berkholz wrote:


* Improving the desktop "experience" -- how, what, when?


Gentopia?

Nathaniel

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Conference - Call for ideas

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Corey Shields wrote:
> On Tuesday 24 May 2005 10:25 am, Donnie Berkholz wrote:
> 
>>* Improving the desktop "experience" -- how, what, when?
> 
> 
> You gonna be there to do this one?   ;)

I wish I could, but I don't think I can get that much vacation. My
wedding's also in August, and I'm taking a couple of weeks off for that
and a honeymoon.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCk2k/XVaO67S1rtsRAlv5AKCXhcQDvLJPAOvZn4t9i/5DENV6DACfe5SU
He6G+7bOVe0U7FDRt3wY2AY=
=LSMM
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Conference - Call for ideas

[Corey Shields]

On Tuesday 24 May 2005 10:25 am, Donnie Berkholz wrote:
> * Improving the desktop "experience" -- how, what, when?

You gonna be there to do this one?   ;)

Thanks for the input!

-- 
Corey Shields
Gentoo Linux Infrastructure Team and Devrel Team
Gentoo Foundation Board of Trustees
http://www.gentoo.org/~cshields


pgpiRs7DW7rHe.pgp
Description: PGP signature

Re: [gentoo-dev] problem with first ebuild

[Mike Frysinger]

On Tuesday 24 May 2005 01:17 pm, Jonas Geiregat wrote:
> The problem is with the install -g root -o root -m 755 scheme etc ..
> command, it seems to run fine but at the end nothing is installed 

the problem is the silly install command

your binary is being installed as '/bin' not as '/bin/scheme'

you can fix this by patching the makefile to do a `install -d $(DESTDIR)/bin` 
before trying to install the binary, or you can change it to do:
install -o root -g root -m 755 scheme -D $(DESTDIR)/bin/scheme

or you can be lazy and add a `dodir /bin/` before the `make install`, but 
that's weak :P

side note, there's no reason to install scheme into /bin ... it should go 
into /usr/bin
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] problem with first ebuild

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jonas Geiregat wrote:
> The problem is with the install -g root -o root -m 755 scheme etc ..
> command, it seems to run fine but at the end nothing is installed 

If you're manually running the install command, you might need to state
that you're installing it to ${D}.

> If I patch the source myself and run make && make
> DESTDIR=/home/jonas/bin install; everything works fine ...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCk2QSXVaO67S1rtsRAr8HAKCowsc+L9YshT3ag38ZKt7UlG9qGwCg31AR
r8nSMIgv4UYECxUizIL+6ds=
=Z8s+
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo Conference - Call for ideas

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Corey Shields wrote:
> The question I have is what kind of content would you like to see?  This may 
> turn into a call for participation later, but right now we are trying to get 
> a feel for what topics people would be interested in hearing and talking 
> about.

The usual cool stuff. =)

* Gentoo on tiny (embedded) systems, or as a build-root for them
* Gentoo on huge systems -- big iron, clusters, etc.
* Gentoo on servers -- how to make it work, progress toward stable etc.
* Improving the desktop "experience" -- how, what, when?
* Where is Gentoo going? Where has it been? What have we learned on the way?
* Gentoo-based distributions -- can we work together?
* Jobs doing Gentoo -- where are they, what are they, how do I get one?

That's all I can think of in a couple of minutes.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCk2N3XVaO67S1rtsRAjSxAKDKO8X3aRGVmGeNEXMJ+RPPUrtyvQCg3zNE
1od6HqWg3NXzePjYCs5LTtQ=
=q3Oq
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] problem with first ebuild

[Jonas Geiregat]

Hi,

I've presented this problem already to 2 developers, both of them where
unable to help me.

I hope I can find a solution on this list.

I've created my first ebuild, I've included the ebuild script the patch
and the output of the emerge tinyscheme command.

The problem is with the install -g root -o root -m 755 scheme etc ..
command, it seems to run fine but at the end nothing is installed 

If I patch the source myself and run make && make
DESTDIR=/home/jonas/bin install; everything works fine ...

I find it a really odd problem..

Regards Jonas
# Copyright 2000-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

inherit eutils

DESCRIPTION="Lightweight scheme interpreter"
HOMEPAGE="http://tinyscheme.sourceforge.net";
SRC_URI="http://tinyscheme.sourceforge.net/tinyscheme-1.35.tar.gz";

LICENSE="BSD"
SLOT="0"
KEYWORDS="~ppc"
IUSE=""

DEPEND=""
RDEPEND=""

src_unpack() {
unpack ${A}  || die
cd ${S}
epatch ${FILESDIR}/${P}-make-install.patch
}

src_compile() {
emake || die
}

src_install() {
echo ${D}
make DESTDIR=${D} install || die
}

Calculating dependencies ...done!
>>> emerge (1 of 1) dev-scheme/tinyscheme-1.35 to /
>>> md5 files   ;-) tinyscheme-1.35.ebuild
>>> md5 files   ;-) files/digest-tinyscheme-1.35
>>> md5 files   ;-) files/tinyscheme-1.35-make-install.patch
>>> md5 src_uri ;-) tinyscheme-1.35.tar.gz
>>> Unpacking source...
>>> Unpacking tinyscheme-1.35.tar.gz to /var/tmp/portage/tinyscheme-1.35/work
 * Applying tinyscheme-1.35-make-install.patch ...  
[ ok ]
>>> Source unpacked.
gcc -fpic  -I. -c -g -Wno-char-subscripts -O -DSUN_DL=1 -DUSE_DL=1 -DUSE_MATH=0 
-DUSE_ASCII_NAMES=0   scheme.c
gcc -fpic  -I. -c -g -Wno-char-subscripts -O -DSUN_DL=1 -DUSE_DL=1 -DUSE_MATH=0 
-DUSE_ASCII_NAMES=0   dynload.c
dynload.c:24:1: warning: "SUN_DL" redefined
:11:1: warning: this is the location of the previous definition
gcc  -shared  -o libtinyscheme.so  scheme.o  dynload.o   -ldl
ar crs libtinyscheme.a scheme.o  dynload.o
gcc -fpic  -o scheme -g -Wno-char-subscripts -O scheme.o  dynload.o   -ldl
>>> Test phase [not enabled]: dev-scheme/tinyscheme-1.35

>>> Install tinyscheme-1.35 into /var/tmp/portage/tinyscheme-1.35/image/ 
>>> category dev-scheme
/var/tmp/portage/tinyscheme-1.35/image/
install -o root -g root -m 755 scheme 
/var/tmp/portage/tinyscheme-1.35/image//bin
man:
prepallstrip:
strip: powerpc-unknown-linux-gnu-strip --strip-unneeded
strip: powerpc-unknown-linux-gnu-strip --strip-unneeded
   bin
>>> Completed installing tinyscheme-1.35 into 
>>> /var/tmp/portage/tinyscheme-1.35/image/

>>> Merging dev-scheme/tinyscheme-1.35 to /
!!! /bin
>>> /bin
>>> Safely unmerging already-installed instance...
--- makefile.b  2003-01-07 20:01:04.0 +0100
+++ makefile2005-05-24 17:00:36.773034840 +0200
@@ -28,6 +28,7 @@
 OUT = -o $@ 
 RM= -rm -f
 AR= ar crs
+DESTDIR=/usr
  
 # Linux 
 LD = gcc 
@@ -82,3 +83,6 @@
 tags: TAGS 
 TAGS: $(TAGS_SRCS) 
etags $(TAGS_SRCS) 
+
+install:
+   install -o root -g root -m 755 scheme$(EXE_EXIT) $(DESTDIR)/bin 

Re: [gentoo-dev] Pinboard of outdated ports

[Rob Cakebread]

Tom Martin wrote:


Maybe it would be better to tell maintainers to just subscribe to
projects on freshmeat?


I whipped up this site because the herds I'm in have a gazillion
packages:
http://gentooexperimental.org/meatoo/

It needs some work but it'd be easy to send out mail to
subscribers by herd or maintainer email instead of subscribing to
dozens of individual freshmeat packages. Or when the command-line
tool is done you can check whenever you want by herd name.


--
Rob Cakebread
Gentoo Linux Developer
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x96BA679B
Key fingerprint = 5E1A 57A0 0FA6 939D 3258  8369 81C5 A17B 96BA 679B
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Pinboard of outdated ports

[Diego 'Flameeyes' Pettenò]

On Tuesday 24 May 2005 16:47, Tom Martin wrote:
> Maybe it would be better to tell maintainers to just subscribe to
> projects on freshmeat?
That doesn't work too well usually.
Unfortunately I have at least two packages I maintain (one directly, one as 
video herd) which I'm subscribed to but sends the freshmeat emails just after 
one or two weeks.
I usually subscribe to sf.net/berlios.de notify when present, if not, their 
own mailing lists, rss feed and if nothing is there, I just cycle through 
some of them every two days.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/



pgp1RKsN2bTqG.pgp
Description: PGP signature

Re: [gentoo-dev] Pinboard of outdated ports

[Tom Martin]

On Tue, May 24, 2005 at 12:47:51AM +0200, Johannes Weiner <[EMAIL PROTECTED]> 
wrote:
> On Mon, May 23, 2005 at 08:46:51PM +0100, Tom Martin wrote:
> > On Mon, May 23, 2005 at 07:11:38PM +0200, Johannes Weiner <[EMAIL 
> > PROTECTED]> wrote:
> > >   * More staff needed
> > > Despite the autodeletion of uptodate packages there has to be
> > > someone attending the list. Remove real spam or uptodate packages
> > > where the targetversion is principally right but not in the correct 
> > > format, so the autodeletion doesn't match.
> > 
> > How does it fit in with metadata.xml, and the maintainers and herds
> > listed therein?
> 
> I don't get the context. Why metadata.xml? And why maintainers and herds
> listed?

Well, if this just creates an entry to the list with no mention of the
email address of the maintainer, if given in metadata.xml, then it's
pretty pointless in my opinion as no-one but the maintainer could/should
bump software unless you've got a go-ahead from the maintainer or there
are exceptional circumstances.

My request is that when a new entry is added to the list, the software
used checks the package's metadata.xml and includes the herd and
maintainer on the list. If there is a maintainer specified, it sends an
email to the maintainer.

Maybe it would be better to tell maintainers to just subscribe to
projects on freshmeat?

Hope that makes sense now,
Tom

-- 
Tom Martin, http://dev.gentoo.org/~slarti
AMD64, net-mail, shell-tools, vim, recruiters
Gentoo Linux


pgp3tqNx5PEdD.pgp
Description: PGP signature

Re: [gentoo-dev] Gentoo Conference - Call for ideas

[Chris Gianelloni]

On Tue, 2005-05-24 at 06:27 -0700, Peter Johanson wrote:
> Things I'd love to hear talks on:
> * liveCD/releng process - I have a basic understanding of catalyst, stage 
> building, whatever, but hearind the shpeel from someone involved.

HA!  Lucky for you none of us are on the west coast... ;]

I *might* be able to make it out for LWE:SF, but it is rather doubtful,
since I just bought a house.  Other than myself, only rocket and tgall
are in the USA, and I'm not aware of either of them going to be in
attendance.

We're also working on catalyst 2.0, which should come out right about
that time, which has become a near complete rewrite of catalyst, so lots
of things will have changed.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Pinboard of outdated ports

[Chris Gianelloni]

On Tue, 2005-05-24 at 07:26 +0200, Johannes Weiner wrote:
> > What it seems like you're doing here is saying more work for the
> > developers is fine, if it makes things easier for the users. (Developers
> > will just cvs up, which is likely faster than dealing with a web interface.)
> 
> I dunno if it's really big work to have a look at one site to see if
> there are ebuilds you missed when they were updated.
> It was not my intention to make really more work. It was just to find a faster
> way for outdated ebuilds getting updated.

There is really only one way to do this.  Figure out how to give the
developers more time to develop.

Having to search through bugs.gentoo.org, plus some external site, would
increase the time needed to find packages in need of upgrade, as some
will be filed as bugs, which would need to be resolved, so they would
have to be searched for *anyway* in bugzilla.

The most productive thing you could do, would be to figure out a simple
way of testing ebuilds, marking them as tested, and assigning them to
the proper parties quicker than is being done now.

What we really need is to have the AT program extended from just amd64
to every arch, including x86 (which desperately needs an arch team).

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] evms && lvm && lvm2 && device-mapper && raid ninjas wanted

[Chris Gianelloni]

On Mon, 2005-05-23 at 23:38 -0400, Mike Frysinger wrote:
> could people who have experience with the following topics:
> - evms
> - lvm
> - lvm2
> - device-mapper
> - raid
> 
> kindly review the open bugs in bugzilla about each topic ?  we few baselayout 
> maintainers dont really use these technologies so we need feedback/patches 
> from people who actually do
> 
> notes:
> we dont care about baselayout-1.9.x (current stable) or really any version < 
> baselayout-1.11.12 ... the reason is that with 1.11.12 we've forked out all 
> the code into addon modules so that the 'maintainers' of these packages can 
> update the code themselves as they see fit ... i guess one of the problems is 
> that we dont have any real maintainers for these packages :)

I know that rocket does a good bit with this stuff, but he's /away for
another week on his honeymoon.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Gentoo Conference - Call for ideas

[Peter Johanson]

On Mon, May 23, 2005 at 09:09:00PM -0700, Corey Shields wrote:
> 
> Greetings!
> 
> We have secured a location and date for a Gentoo developer conference to 
> correspond with the timing of LWE in San Francisco.  The date will be Friday, 
> August 12th.  Global Netoptex (netoptex.com), one of Gentoo's infrastructure 
> sponsors, has offered space in their facility to host the conference.  This 
> is only 5 blocks from the Moscone center, making it convenient for people who 
> will be in town for LWE that week.

Excellent! I'm hoping to fly my *ss out to the left coast this year to
make LWE: SF.

> 
> Once available, seating and registration will be limited to the space we 
> have, 
> but we are also working on the possibility of webcasting the sessions.
> 
> The question I have is what kind of content would you like to see?  This may 
> turn into a call for participation later, but right now we are trying to get 
> a feel for what topics people would be interested in hearing and talking 
> about.

Things I'd love to hear talks on:
* liveCD/releng process - I have a basic understanding of catalyst, stage 
building, whatever, but hearind the shpeel from someone involved.
* Portage development - What new features are coming up, maybe details of some 
of the internals of portage, whatever.

If people want to hear me blab, I could do something on any of the mono
related stuff I work on.

-pete

-- 
Peter Johanson
<[EMAIL PROTECTED]>
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Pinboard of outdated ports

[David Stanek]

On Tue, May 24, 2005 at 07:26:49AM +0200, Johannes Weiner wrote:
> > What it seems like you're doing here is saying more work for the
> > developers is fine, if it makes things easier for the users. (Developers
> > will just cvs up, which is likely faster than dealing with a web interface.)
> 
> I dunno if it's really big work to have a look at one site to see if
> there are ebuilds you missed when they were updated.
> It was not my intention to make really more work. It was just to find a faster
> way for outdated ebuilds getting updated.

If it is difficult for the users, maybe it needs to be documented
better. Might be as simple as a "Report old ebuild" links on the
Bugzilla homepage. Somehow I don't think it is all that difficult
though.

To make a clean separation for other Bugzilla content a new
Component may be added. This should ease an searching issues as long
as the users searching are aware of the new component. But then we'd
probably still see a bunch of confused, headless chickens running
around squaking "ebuilds, old ebuilds".

-- 
David Stanek
www.roninds.net

GPG keyID #6272EDAF on http://pgp.mit.edu
Key fingerprint = 8BAA 7E11 8856 E148 6833  655A 92E2 3E00 6272 EDAF


pgp1w7iYtHEec.pgp
Description: PGP signature

Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Michael Haubenwallner]

Argh, yes, sure (should always make proof of concept :).

So there's another new variable needed to contain "/home/haubi".
Could HOME be used (this currently points to the portage-defined empty
homedir) ?

My suggestions if not: IHOME, INSTALL_HOME, HOMEDIR, TARGETDIR, HOMETARGET,
...

~haubi

- Original Message -
From: "Ciaran McCreesh" <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
| Variables to be set by portage:
| PREFIX="/home/haubi"
| AFFIX="home/haubi/" (not used here)

Hrm. So what do we use for finding out where our non-home deps are
installed then?



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Brian Harring]

On Tue, May 24, 2005 at 11:07:54AM +0100, Ciaran McCreesh wrote:
> On Tue, 24 May 2005 11:53:30 +0200 "Michael Haubenwallner"
> <[EMAIL PROTECTED]> wrote:
> | Variables to be set by portage:
> | PREFIX="/home/haubi"
> | AFFIX="home/haubi/" (not used here)
> 
> Hrm. So what do we use for finding out where our non-home deps are
> installed then?
add a bash func that abuses the ebd pipes to query 
portage directly.  
get_installed_prefix ${atom} might fly, although naming/ironing out 
semantics is required.
~brian


pgp3BQNKv9m2m.pgp
Description: PGP signature

Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Ciaran McCreesh]

On Tue, 24 May 2005 11:53:30 +0200 "Michael Haubenwallner"
<[EMAIL PROTECTED]> wrote:
| Variables to be set by portage:
| PREFIX="/home/haubi"
| AFFIX="home/haubi/" (not used here)

Hrm. So what do we use for finding out where our non-home deps are
installed then?

| Where should additional documents (seen in current
| vim-plugin_src_install) go to ?

I'd suggest that you try something like gkrellm plugins -- there're some
nice subtleties with vim plugins to do with docs tag generation that
will require patching vim itself for things to work properly.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgp97sHPV1oVS.pgp
Description: PGP signature

Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Michael Haubenwallner]

Ok, no separate glep for home installation:

So i need some clues how to install plugins into home - attached is some
ebuild patch sample (actually not a diff output) how i would try to start
with vim-plugins.eclass, as a discussion base.

Variables to be set by portage:
PREFIX="/home/haubi"
AFFIX="home/haubi/" (not used here)
INSTALL_TARGET_TYPE="home" (value is found in the SUPPORTS
metadata-variable)
This is a new variable which needs a better name, or even a portage-function
for querying the install target type, which comes from the
'emerge --target home' bit by Brian Harring.

Is it confusing when PREFIX contains home-dirs - should another variable
name be used for home-dir, or should PREFIX/AFFIX be renamed - suggestions ?

Where should additional documents (seen in current vim-plugin_src_install)
go to ?
Can `id -un`:`id -gn` (maybe wrapped by some portage function, using glep 27
for non-home-target) be used to set the owner of the files ?

~haubi


begin 666 vim-plugins-home.patch
M("!V:6TM<&QU9VEN7W-R8U]I;G-T86QL*"D@>PHM(" @("!L;V-A;"!F"BL@
M(" @(&QO8V%L(&[EMAIL PROTECTED]U-]('Q\(&1I92 B8VAM;V0@
M9F%I;&5D(@HM(" @("!F:6YD("[EMAIL PROTECTED](@("=P;W)T86=E)R M97AE
M8R!C:&]W;B!R;V]T("=[?2<@[EMAIL PROTECTED]'[EMAIL 
PROTECTED]&EE(")C:&]W;B!F86EL960B"BT@
M(" @(&9I;F0@)'M3?2 M9W)O=7 @)W!O&5C(&-H9W)P(')O
M;W0@)WM])R!<.R!\?"!D:64@(F-H9W)P(&9A:6QE9"(**R @(" @9FEN9" D
M>U-]("UU&5C(&-H9W)P("(D>V=R;W5P?2(@)WM])R!<
M.R!\?"!D:64@(F-H9W)P(&9A:6QE9"(*(" @(" @965N9" D/PH**'-N:7!P
[EMAIL PROTECTED]&AE(&1O8W5M96YT871I;VXI"@HM(" @("!D;V1IU-]("1[1'TO=7-R+W-H87)E+W9I;2]V:6UF:6QE
MV1EV1E

Re: [gentoo-dev] evms && lvm && lvm2 && device-mapper && raid ninjas wanted

[Benjamin Smee]

heya,

On Mon, 2005-05-23 at 23:38 -0400, Mike Frysinger wrote:
> could people who have experience with the following topics:
> - evms
> - lvm
> - lvm2
> - device-mapper
> - raid
> 
> kindly review the open bugs in bugzilla about each topic ?  we few baselayout 
> maintainers dont really use these technologies so we need feedback/patches 
> from people who actually do

I will have a look.

> notes:
> we dont care about baselayout-1.9.x (current stable) or really any version < 
> baselayout-1.11.12 ... the reason is that with 1.11.12 we've forked out all 
> the code into addon modules so that the 'maintainers' of these packages can 
> update the code themselves as they see fit ... i guess one of the problems is 
> that we dont have any real maintainers for these packages :)

I would be happy to help out with these packages as I have lvm2 + raid +
dm-crypt on almost all of my machines.

regards,

Benjamin Smee
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Wireless driver / firmware ebuilds & wireless-tools

[Allen Parker]

On 5/23/05, Stroller <[EMAIL PROTECTED]> wrote:
a 
> But in any case, the functionality contained in wpa_supplicant covers
> my arguments, and I apologise for not being aware of it.
> 
> Stroller

Since you were the only person that is not a gentoo dev to post on
this topic, I will give you an acceptable sequence of events, as I
believe that this medium wasn't the proper venue for your particular
complaint:
1. emerge an irc client of your preference
2. connect to irc.freenode.net
3. join #gentoo-laptop
4. have this discussion over a period of minutes instead of days, and off-list
5. keep other people on the list from becoming annoyed with your
refusal to accept a given answer.
6. if you *really* have a problem accepting the given answer, read
gentoo's policies with regards to ebuilds, then, if you *still* have
issue, take it up with devrel.

infowolfe via irc.freenode.net

-- 
gentoo-dev@gentoo.org mailing list