[gentoo-dev] where to put *.pm files
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
[gentoo-dev] Bashrc mini HOWTO
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
Re: [gentoo-dev] RFC: slight deunofficialisation of Unofficial Gentoo Development Guide
On Sun, 22 May 2005 09:35:42 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: | I'd like to move the Unofficial Gentoo Development Guide [1] onto my | devspace [2]. This could be construed as weakening its unofficial | status (despite the title and the footers), so I'm asking for comments | first rather than simply doing it. Since no-one complained, it's now at: http://dev.gentoo.org/~ciaranm/devmanual/ I have some Apache redirect voodoo in place on the old host, so hopefully you'll get automagically 301ed as necessary. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgplaXfAN2Gmy.pgp Description: PGP signature
[gentoo-dev] pdflib-6 might not work with everything
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Earlier today, I added pdflib-6 to the tree. Some of you may need to accommodate this in your ebuilds. I just wanted you to be aware, so if you got reports of things related to it suddenly breaking, you'd have a clue. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFClEPGXVaO67S1rtsRAj+mAKCVKMCLZt2lmxIT4/1MK8XOc/YLEgCg3nyQ SZ9FM0II9rmldqmbbjQxB5w= =WKuf -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] i have an idea ! (erescue) ro-overlays
On Tue, 2005-05-24 at 14:11 -0700, Jim Northrup wrote: 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. If you use genkernel to build your kernel, then you will have a usable initrd with lvm2/evms/dmraid (via --lvm2, --evms, or --dmraid) capabilities and tools for rescuing your system. This is only good for filesystem rescue, though. It won't help you if you emerge a bad copy of binutils or gcc. -- 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] Re: Pinboard of outdated ports
On Tue, 2005-05-24 at 14:12 -0700, Donnie Berkholz wrote: -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... The idea behind the program was to extend it to all architectures. I'm sure every architecture has at least one or two users that provide very good feedback and are willing to help, but aren't necessarily able to dedicate the time to being a full-fledged arch developer. An AT basically has elevated privileges in bugzilla, allowing them to make changes to bugs to allow their respective developers to get work done easier and quicker. http://www.gentoo.org/proj/en/base/amd64/tests/index.xml?part=1chap=1 This idea really should be extended, as it seems to have had very positive results with the amd64 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] root:root and fbsd
On Sunday 22 May 2005 10:49, Diego 'Flameeyes' Petten wrote:
Hi,
ok another problem for Gentoo/FreeBSD project :P
Currently there are a few places where, to fix permissions of files,
the ebuilds does a chown -R root:root ${D} or something similar.
Unfortunately such a command is invalid on G/FBSD because there's no
root group, instead wheel group has GID=0.
So I was wondering for a solution for this problem: we have a $USERLAND
variable which can be used to select the way the chown must be done, if
chown root:root or chown root:wheel; I think both BSD and Darwin
userland prefers root:wheel above root:root, so maybe adding a function
in eutils which fixes the permissions based on the current $USERLAND
value is enough...
Comments?
Why not change the stuff to
chown -R 0:0 ${D}
That way it is user proof. The master accounts allways have id's 0:0 but
user's might decide to change their names.
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net
pgpVZxaKB1YbU.pgp
Description: PGP signature
Re: [gentoo-dev] where to put *.pm files
Yes the program looks in @INC for the modules and no the name of the program is not mainprog.pl. How can I put the two modules in the @INC the gentoo way. I saw that there is a perl eclass, but I am not sure how to use it correctly. I will file a Bug when the program works. Or should I already file a bug? Until now I have submitted several ebuilds and patches but none made it into the portage tree On Wednesday 25 May 2005 11:12, Michael Cummings wrote: Well, first off, how does the program look for the perl modules? If it isn't suggesting that you place them in your @INC, then it is most likely loading them directly. So it all depends on how the main script (please tell me it isn't really called mainprog.pl) tries to load those modules as to the best place to put them. /me waits for the bug report for this one On Wednesday 25 May 2005 02:06 am, Rene Zbinden wrote: 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 -- cheers, reen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] i have an idea ! (erescue) ro-overlays
overall I'm quite pleased with genkernel and have relegated much tedium to its functions over time. perhaps it's a worthy mule for more responsibility. I have mirror volumes which have survived almost 8 years with 2nd and third generation drives, motherboard, and architecture (32-64 bit). in those years, the newer revs which don't jump up and bite me in the ass probably go unnoticed.. abstractly speaking, the clearest working example of what breaks is oft-times a recent kernel on a recent install disk. slopping an install disk on a modern hard-drive consumes but a gnat's real-estate. using a symlink foundation does a pretty good job of allowing emerge to over-write the static known-good binaries with dynamics, but occasionally the gcc and/or libc is a repeatable failure and having the ro overlay handy allows wholesale excision of the broken installs, esp on young architectures. for whatever reasons, I pack my cd-rom drive bays with hard drives, and install with a cd-rom hanging off the side of the case tethered by its cables... right about the time its a bootable system the cd- rom comes off and the box is tucked into some crawl-space or other behind desks, shelves, etc. and hopefully forgotten. On May 25, 2005, at 6:32 AM, Chris Gianelloni wrote: On Tue, 2005-05-24 at 14:11 -0700, Jim Northrup wrote: 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. If you use genkernel to build your kernel, then you will have a usable initrd with lvm2/evms/dmraid (via --lvm2, --evms, or --dmraid) capabilities and tools for rescuing your system. This is only good for filesystem rescue, though. It won't help you if you emerge a bad copy of binutils or gcc. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bashrc mini HOWTO
Chris White wrote:
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
I gave this a quick look, and aren't you talking about bash scripts in
general rather then .bashrc files using /etc/portage/bashrc as reference
for this document.
Also I can't see the real use , that's why I started reading then
quickly scanned through it .. and now I'm writting this email ..
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] test, please ignore
Have been having trouble with the mailing lists... -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpKwfWYVHHcs.pgp Description: PGP signature
Re: [gentoo-dev] where to put *.pm files
Rene Zbinden [EMAIL PROTECTED] wrote: 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? Is this a package that is currently on CPAN? If so, I have a relatively useful skeleton for writing CPAN ebuilds. I was able to install several CPAN packages this way. In the ebuild, you'll need to edit or delete any line marked with XXX, but that will likely be all you need to get it to work. Let me know if anything needs more explanation. http://www.haell.com/~wyrm/works/comp/env/prgmmg/perl/skel_cpan.tbz2 -- Batou: Hey, Major... You ever hear of human rights? Kusanagi: I understand the concept, but I've never seen it in action. --Ghost in the Shell pgpU2keZbb9Rj.pgp Description: PGP signature
Re: [gentoo-dev] where to put *.pm files
Drake Wyrm wrote: Is this a package that is currently on CPAN? If so, I have a relatively useful skeleton for writing CPAN ebuilds. I was able to install several CPAN packages this way. In the ebuild, you'll need to edit or delete any line marked with XXX, but that will likely be all you need to get it to work. Let me know if anything needs more explanation. Do you know about g-cpan.pl ? -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
[gentoo-dev] baselayout-1.11.12-r2 request for testers
yes, it's finally that time ... after months of hearing us say 'we want to get new baselayout stable asap', we're serious so can people please try out baselayout-1.11.12-r2+ and see if they notice any regressions ? the 'best' tests are simply rebooting and seeing if your system comes up :) common gotchas: - many config options have moved from /etc/rc.conf into /etc/conf.d/ files - /etc/hostname and /etc/*domainname have been moved into /etc/conf.d/ files - the net scripts have been completely rewritten thanks to UberLord ... old config styles should work fine, but it's best if you update your /etc/conf.d/net syntax ... just review /etc/conf.d/net.example or this URL: http://dev.gentoo.org/~uberlord/net-book/ somethings to note ... regressions with lvm/lvm2/evms will not be considered ... they have had all their code forked into the respective packages and thus are no longer part of baselayout ... bugs with those packages should be taken up with their respective maintainers -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bashrc mini HOWTO
Alec Warner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonas Geiregat wrote: snip ChrisWhite I gave this a quick look, and aren't you talking about bash scripts in general rather then .bashrc files using /etc/portage/bashrc as reference for this document. Also I can't see the real use , that's why I started reading then quickly scanned through it .. and now I'm writting this email .. normal bash scripts aren't sourced by portage when ebuilds are being processed. Only PORTAGE_BASHRC ( current /etc/portage/bashrc ) is sourced. Thus you can do cool stuff like print debug info, over-ride default functions, and otherwise other fun stuff that normally would be a complete PITA, especially if you don't know portage internals well. No such file on my system, is that the reason why I should use the cvs version of portage, so the new version will source /etc/portage/bashrc when it comes out of cvs ? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQpT+LmzglR5RwbyYAQKXWQ/+KjdNLnZlokuD2rKPXwgsYRzeLpmZtMs5 Qm7k+gakIuO9tMlbnYFUm5vaZxif+IaPDWeMRSpshOWA94G7kTx22bytMc7axu5J xlIrVjajHip96nHrGYNklETUEtbt9tm+1nLYpoLAjfejXby2QnTd8+GANaZ1Lqwz SzgJA6IYNXtIk6Xu6mZE0V+Fpizmflvii+UueviwH9+UzKR6SKrYjZmBTU5NAjGv uy4kcTMNkl3LZMKu5P9yKV3NYOX0YABrgxpfhtbgZJsBC4a2a3Y8XLymmKcTeMUS AIP1o6V/h+dWfU9H5PuQsYvBsmfMK06thWTAZF411FFZLXk+HhKo9De0nQvkaM9H P+P5UwXgEdlJLk7k2oq1eE09klDRegzZGEVs6mcxk9b6qQ9d8ub/8IUB1Fv68PwI 62lngdKNw7BND1IRwBuyNXD1JOoUHYZuSO1CHyraneij5NunSiwqwLl8sbqsXmqJ riuvaIuWPce37CS3Pmg55eh42aW8ikHpjusDMmSAGh8ffsdW6ogHi4sHwBMMDpEf c2/ybSZU5cK13csDaPPcaadhNZWPXFOs1pLphOfCoe+3ia0W2cjQruI1jdL2CG2y nO7NYLmUZ50xELvawmEPXKu76O6qbV0JB2J2SKFgAExV+GXFSGdpPoZiLyLWnSMF 6r8juJ5CpeE= =W3Pe -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bashrc mini HOWTO
On Thursday 26 May 2005 07:47, Jonas Geiregat wrote: Alec Warner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonas Geiregat wrote: snip ChrisWhite I gave this a quick look, and aren't you talking about bash scripts in general rather then .bashrc files using /etc/portage/bashrc as reference for this document. Also I can't see the real use , that's why I started reading then quickly scanned through it .. and now I'm writting this email .. normal bash scripts aren't sourced by portage when ebuilds are being processed. Only PORTAGE_BASHRC ( current /etc/portage/bashrc ) is sourced. Thus you can do cool stuff like print debug info, over-ride default functions, and otherwise other fun stuff that normally would be a complete PITA, especially if you don't know portage internals well. Not knowning portage internals well means that this file should be off limits. No such file on my system, is that the reason why I should use the cvs version of portage, so the new version will source /etc/portage/bashrc when it comes out of cvs ? You need to create it yourself. Regards, Jason Stubbs pgpMowMIfrw3A.pgp Description: PGP signature
[gentoo-dev] Re: KDE 3.4 visibility support disabled
Marcus D. Hanwell posted [EMAIL PROTECTED], excerpted below, on Wed, 25 May 2005 17:48:20 +0100: I have just committed a fix to kde.eclass and kde-meta.eclass that disables visibility support in KDE 3.4 (thanks to FlameEyes for the patches). This was a new feature in KDE 3.4 which has caused at least one obvious bug, and possibly others that are less obvious[1]. [note the cross-posting] That isn't going to kill it for gcc-4.0.1-snapshots, right, only gcc-3.4? I'll be rather unhappy if the speed increases I've been attributing to that visibility support under gcc4, disappear! =8^( -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: KDE 3.4 visibility support disabled
[just to make sure that everybody will hear that] On Thursday 26 May 2005 01:37, Duncan wrote: That isn't going to kill it for gcc-4.0.1-snapshots, right, only gcc-3.4? I'll be rather unhappy if the speed increases I've been attributing to that visibility support under gcc4, disappear! =8^( It will be *completely* disabled. -fvisibility=hidden *must not* be used if the project isn't supposed to use only its own code without linking to other libraries, as that kills the RTTI stuff. It's not a fault in GCC, it's a fault in the way -fvisibility=hidden was used by KDE. KDE 3.5 and 4 will have the right visibility support enabled just for KDE stuff instead of messing around with QT and other libraries which doesn't use that consistently. Please note that every try to use -fvisibility=hidden in CFLAGS will result in *great* problems which won't be supported at all. -- Diego Flameeyes Pettenò Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpcxrWaJLq7g.pgp Description: PGP signature
Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: | yes, it's finally that time ... after months of hearing us say 'we want to get | new baselayout stable asap', we're serious | | so can people please try out baselayout-1.11.12-r2+ and see if they notice any | regressions ? the 'best' tests are simply rebooting and seeing if your | system comes up :) | | common gotchas: | - many config options have moved from /etc/rc.conf into /etc/conf.d/ files | - /etc/hostname and /etc/*domainname have been moved into /etc/conf.d/ files | - the net scripts have been completely rewritten thanks to UberLord ... old | config styles should work fine, but it's best if you update | your /etc/conf.d/net syntax ... just review /etc/conf.d/net.example or this | URL: http://dev.gentoo.org/~uberlord/net-book/ | | somethings to note ... | regressions with lvm/lvm2/evms will not be considered ... they have had all | their code forked into the respective packages and thus are no longer part of | baselayout ... bugs with those packages should be taken up with their | respective maintainers | -mike booted for me on ~x86 no raid/lvm/lvm2/evms to help you there hope this helps -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFClQ7TUpKYMelfdYERAk15AJ0fiaIuY8cGjezr0br0p3NRC6fAIgCghtBt 8nGxZXiQT1/nMrFq0uy/QRY= =eznV -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Pinboard of outdated ports
Chris Gianelloni wrote: On Tue, 2005-05-24 at 14:44 -0600, R Hill wrote: Really? What does such a team do? They do exactly what is said above. They test ebuilds that are submitted. They also test patches and just about anything else that goes into bugzilla. Basically, they are a group of people that own a certain architecture that are willing to possibly destroy their machines in the name of the greater good of QA and Gentoo. Well, I already destroy my machine on a weekly basis in the name of what does this do, but I think I could fit some Gentoo-goodness in there. If there is an x86 team formed, count me in. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-amd64] Re: KDE 3.4 visibility support disabled
On Thursday 26 May 2005 02:37, Duncan wrote: Marcus D. Hanwell posted [EMAIL PROTECTED], excerpted below, on Wed, 25 May 2005 17:48:20 +0100: I have just committed a fix to kde.eclass and kde-meta.eclass that disables visibility support in KDE 3.4 (thanks to FlameEyes for the patches). This was a new feature in KDE 3.4 which has caused at least one obvious bug, and possibly others that are less obvious[1]. [note the cross-posting] That isn't going to kill it for gcc-4.0.1-snapshots, right, only gcc-3.4? I'll be rather unhappy if the speed increases I've been attributing to that visibility support under gcc4, disappear! =8^( That's going to kill it everywhere, gcc4 included. The way KDE uses hidden visibility is itself broken - not gcc. Until that's fixed, we're disabling visibility support in kde. (There was a separate bug in gcc itself which got fixed, which may have confused some people...) -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpECtup7r5X8.pgp Description: PGP signature
Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers
Paul Varner wrote: On Wed, 2005-05-25 at 18:20 -0400, Mike Frysinger wrote: yes, it's finally that time ... after months of hearing us say 'we want to get new baselayout stable asap', we're serious so can people please try out baselayout-1.11.12-r2+ and see if they notice any regressions ? the 'best' tests are simply rebooting and seeing if your system comes up :) Works fine here on a fairly basic ~x86 desktop. Regards, Paul Hi, Using mostly stable system with some (baselayout incl.) testing packages. Migration went OK, except for a warning about missing /etc/init.d/serial. See commented entries for serial in my /etc/inittab file, will check. Otherwise it all works. Rumen smime.p7s Description: S/MIME Cryptographic Signature
