Re: [gentoo-dev] eselect-compiler updates and unmasking
Saturday, 3. June 2006 06:33, Donnie Berkholz Ви написали: Jeremy Huddleston wrote: Couple of questions: 1) Can it handle non-gcc compilers? If so, how? 2) Can it handle different languages being set to different compilers? For example, use Intel's Fortran compiler but GCC for everything else. If neither of those are possible now, I would like to look into fixing this. Thanks, Donnie Well, incidentally I was working on toolchainasing gnat (a gcc based Ada compiler, basically just another frontend) and pestered toolchain people on irc regarding similar matters. Basically it came down to: toolchain.eclass and eselect-compiler are not for stuff not in gcc, so I had to create my own ones (gnatbuild.eclass and eselect-gnat), a bit simpler versions actually :). I could not inherit toolchain.eclass either, only copy the relevant parts of it.. A due notice: this was discussed already like half a year ago (although when I announced progress here on -dev no comments followed), so if the things have chaged since then I will be interested to know too.. George -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Bugday today (late reminder)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey everyone :-) So, here we go again, seems like I almost forgot it again, but in case you missed it, it's bugday again today :-) We will be aiming to have the new website only for next bugday, so things will start to be more interresting :-) I know it's a pretty late announcement, but hey, it's still saturday :-) Bjarke -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEgX+EO+Ewtpi9rLERAm85AJ9VwjcEqUb73hJLNK8SJLcp7dAIqQCfeLjZ q/Y9RtVj+3a6fM5X5fTmG1s= =e+7r -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Addition of a USE_EXPAND-Variable LIRC_DRIVERS and general cleanup of app-misc/lirc
Hi! If nobody objects I will add LIRC_DRIVERS to USE_EXAPAND tomorrow (sunday 2006/06/04). This will replace as much as possible from the up to now used dirty hack LIRC_OPTS=--with-driver=serial --with-trasmitter --with-irq=4 in make.conf. The --with-driver part will be moved to LIRC_DRIVERS. The name need not to be LIRC_DRIVERS, tell me if you have a better name for it (LIRC_RECEIVERS is another possibility). The other (binary flag) settings will be moved to normal use-flags (--with-transmitter --without-soft-carrier). The only problematic things that will perhaps stay in LIRC_OPTS are things like --with-port=378. But I think most of these settings can also be changed at module-load-time. Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] QA subproject, TreeCleaners
I propose a new QA subproject, the TreeCleaners. This is a delicate subject for some developers, other developers don't care, and yet others want the cruft in the tree removed. The Tree Cleaning project's main goal is to identify broken and unmaintained packages in the tree and either get them fixed or mask and remove them. Criteria: 1. Packages slated for removal must have no active maintainer. This is accomplished by looking in the package's metadata.xml for the maintainer tag. The maintainer tag must contain an active (non-retired) developer or team. The tree cleaners will maintain a list of ebuilds assigned to maintainer-needed; this list may end up on the web similar to Debian's WNPP[1]. A package with missing metadata.xml is assumed to be unmaintained. 2. Packages slated for removal must have open bugs filled against them. It is not the policy of the QA team nor this subproject to remove packages because they have no maintainer. There are plenty of completely working packages in the tree with no maintainer; we are not trying to remove those. 3. Packages slated for removal with simple to fix bugs may be fixed by the tree cleaners if a project member elects to do so. Many of the bugs are relatively minor ( depend fixes, revbumps, etc ) and could be done by someone given a bit of time. This isn't meant as a means to perpetually keep crap in the tree, moreso that in some cases minor bugs against a package are not grounds for removal. 4. Preferably packages slated for removal shall have a dead or unresponsive upstream. An upstream that isn't interested in maintenance means more work for Gentoo in keeping the package up to date. For packages that already lack a maintainer in Gentoo, a dead upstream means there is no developer and no upstream for a package; aka no one to do the work. A dead upstream is not *required* however, crap ebuilds for packages with an active upstream are still valid to be removed if there are major bugs filed against them. 5. Packages slated for removal shall have a last rites e-mail sent to the gentoo-dev mailing list. There will be no packages disappearing randomly out of the tree due to the tree cleaner project members. Transparency is key here, both on bugs, in package.mask, and on the mailing list. developers and users both need to know what is going on. 6. Packages slated for removal shall have a 30 day period in package.mask prior to removal. This is tree cleaner policy, and it's one that I hope other developers will adopt. I've seen things pmasked and removed after a week, a couple of days, or just pmasked and never removed. The 30 day period allows everyone using the package to see the masking message and the corresponding bug when they use portage. Questions and Comments are welcome, as always. -Alec Warner [1] http://www.debian.org/devel/wnpp/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] User Relations Co-lead
On Sat, Jun 03, 2006 at 02:05:42AM +0100, Christel Dahlskjaer wrote: It is my pleasure to inform you that after much discussion I can announce that Joshua Jackson (tsunam) has come onboard to act as my co-lead in Userrel[1]. Yay! Congrats, tsunam :) Wish him luck, I suspect he will need it! You suspect he will need luck for what? a) for being co-lead with you b) for being co-lead for Userrel c) all of above ;) No matter what the intention was - good luck :) Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgp7zf6CU1ZbU.pgp Description: PGP signature
Re: [gentoo-dev] QA subproject, TreeCleaners
On Sat, Jun 03, 2006 at 10:43:39AM -0400, Alec Warner wrote: Questions and Comments are welcome, as always. Sounds like it will be a lot of work - but it a job that really needs to be done on a regular basis, imho. I would be happy to see such a subproject being launched. The rules you stated in your email sounds good to me. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpbL6Mg8B9AE.pgp Description: PGP signature
Re: [gentoo-dev] User Relations Co-lead
On Sat, 03 Jun 2006 02:05:42 +0100 Christel Dahlskjaer [EMAIL PROTECTED] wrote: It is my pleasure to inform you that after much discussion I can announce that Joshua Jackson (tsunam) has come onboard to act as my co-lead in Userrel[1]. Will that result in dramatic increase of anime smilies in Gentoo environment? ^_^ -- Andrej Ticho Kacian ticho at gentoo dot org Gentoo Linux Developer - net-mail, antivirus, sound, x86 signature.asc Description: PGP signature
Re: [gentoo-dev] QA subproject, TreeCleaners
Alec Warner [EMAIL PROTECTED] said: I propose a new QA subproject, the TreeCleaners. Questions and Comments are welcome, as always. This has my support. Hopefully it will help us get rid of a lot of cruft that hasn't been touched in ages and doesn't even work. Thanks, -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgp6Szf3Zvd7h.pgp Description: PGP signature
Re: [gentoo-dev] User Relations Co-lead
On Saturday 03 June 2006 17:40, Andrej Kacian wrote: Will that result in dramatic increase of anime smilies in Gentoo environment? Of course, else we'll be all angry _ .. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpacyU9qGsqO.pgp Description: PGP signature
Re: [gentoo-dev] QA subproject, TreeCleaners
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: I propose a new QA subproject, the TreeCleaners. [snip] +1 on this idea - -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Developer Relations Gentoo Recruitment Lead Gentoo Infrastructure GPG: 0094 7F06 913E 78D6 F1BB 06BA D0AD D125 A797 C7A7 === -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEgb0X0K3RJaeXx6cRAoC0AJ4lDDWuihZQn6WO/PRqK8SWp9iM/QCeMtdK S+XxHe9L0Ll99Pjvl+9kmnk= =cIXB -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA subproject, TreeCleaners
+1 from me, too. I also want to offer my help to this project, so ping me if needed. Kind regards, DerCorny -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Carl - Carl Analyzes Rsync Logfiles v0.4
Hi! I've cleaned up the source of my logfile analyser (and delinted it alot). Also, it's now a Python distutils compatible distribution and I've even included an Ebuild for gentoo systems (in the unlikely case any of you has use for that ;)). It's available here: http://www.schwarzvogel.de/software-misc.shtml Checksums: MD5: 1979641096c005126ee316aab227e13a dist/carl-0.4.tar.gz SHA1: 1c54baa6435f6e5a411d7b6e7da56726dbc65814 dist/carl-0.4.tar.gz As soon as I find the time, it may also be available by svn. Have fun with it and don't hesitate to report bugs. Regards, Tobias admin of rsync5.de PS: For code clarity the obfuscation-mode is gone. If anyone really needs it, drop me a line and I'll see what I can do. pgp3KsfiBHs5E.pgp Description: PGP signature
Re: [gentoo-dev] User Relations Co-lead
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Of course it will! \^.^/ You can't go wrong with the anime smily faces _. Thanks for the luck, I know I'll need it Andrej Kacian wrote: Will that result in dramatic increase of anime smilies in Gentoo environment? ^_^ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEge8nSENan+PfizARAk+hAJ92wZvimaJkzzVpigSUhGq0eHxP9ACfcpzA 522ChEUc/GSw6OcDFrAtxkg= =A5Ur -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA subproject, TreeCleaners
Alec Warner wrote: The maintainer tag must contain an active (non-retired) developer or team. Minor wording issue - what about ...developer or a properly functional team? Just in case all members of the team die... Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: QA subproject, TreeCleaners
Alec Warner [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 03 Jun 2006 10:43:39 -0400: 6. Packages slated for removal shall have a 30 day period in package.mask prior to removal. This is tree cleaner policy, and it's one that I hope other developers will adopt. I've seen things pmasked and removed after a week, a couple of days, or just pmasked and never removed. The 30 day period allows everyone using the package to see the masking message and the corresponding bug when they use portage. What about changing this to a minimum 30 day period after dev-list last rites notification prior to removal, a minimum 3 day period between dev-list notification and masking, and a minimum 2 week period in package.mask. The idea should be obvious, provide a bit of time after notification before masking, as anyone stepping up in this period will minimize disruption to the tree, while maintaining a reasonable post mask period and a minimum 30 day overall period. This is based on the various notifications and varied timings I've seen here, as the proposal in general seems to be as well. Both would standardize things a bit, but this change would minimize disruption to the tree if someone stepped up before masking. Either way, good idea; a betterment of Gentoo, I agree. -- 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 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Addition of a USE_EXPAND-Variable LIRC_DRIVERS and general cleanup of app-misc/lirc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Schwarzott wrote: The --with-driver part will be moved to LIRC_DRIVERS. The name need not to be LIRC_DRIVERS, tell me if you have a better name for it (LIRC_RECEIVERS is another possibility). LIRC_DEVICE? most of the USE_EXPAND stuff seems to be named for the device rather than the driver. eg. ALSA_CARDS, VIDEO_CARDS, INPUT_DEVICES. - --de. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEgk9oyrvh8ZIy7KURAplPAJ97WJyvmKKTWQ39AclFNdikcJ6hqgCg2Kdu 84bIAHmgSKm+eIbUr+Z3uf4= =zLy4 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: User Relations Co-lead
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christel Dahlskjaer wrote: It is my pleasure to inform you that after much discussion I can announce that Joshua Jackson (tsunam) has come onboard to act as my co-lead in Userrel[1]. Uh-oh. - --de. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEglBDyrvh8ZIy7KURAvOdAKCIp1Jx5tsxSD9UYx7ND4jo9Bss0gCeLwen NDU3WfKZ6gWWJ2sUs2dMVRk= =6Mmb -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: eselect-compiler updates and unmasking
Donnie Berkholz [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 02 Jun 2006 21:33:58 -0700: Jeremy Huddleston wrote: I finally had a few free cycles, so I fixed up the eselect-compiler ebuild to better handle the transition from gcc-config and updated toolchain.eclass to better work with multilib. I've had a bunch of help from the amd64 devs/testers/users[] Couple of questions: 1) Can it handle non-gcc compilers? If so, how? 2) Can it handle different languages being set to different compilers? For example, use Intel's Fortran compiler but GCC for everything else. If neither of those are possible now, I would like to look into fixing this. I've been one of the testing users... Taking into account George's reply, it's not now directly possible, but the infrastructure is now there, and could be built upon with appropriate eclasses, to be inherited by the ebuild for your compiler of choice (or by manually tweaking the config files in /etc/eselect/compiler), at least for (1) non-gcc compilers. A lot of the support for gcc is actually in toolchain.eclass, but George mentions other compilers should use separate eclasses. (That part I'm just repeating from his post.) Different languages going to different compilers is somewhat more problematic. One could switch the whole compiler set to merge just the single package in the other language, then switch back, but there's no current provision for directing different languages to different places at the same time, and adding that would be to my understanding complex enough to be a project for eselect-compiler-3.x. I just remembered a bug I think I filed on portage last year (yes, #108393), that's related and AFAIK still needs resolution... It's only a potential blocker for distcc users, of which I'm not one, so I haven't the foggiest if it's serious enough to hold up unmasking of eselect-compiler or not. I know the portage warning referenced in comment #9 is still there with portage-2.1-rc4 (and obviously, gcc-config is installed, but portage is looking in the old gcc-config location, see the bug for discussion): $emerge --info !!! Relying on the shell to locate gcc, this may break !!! DISTCC, installing gcc-config and setting your current gcc !!! profile will fix this Portage 2.1_rc4 [snip] http://bugs.gentoo.org/show_bug.cgi?id=108393 eradicator is already CCed and has commented on the bug, but what discussions have occurred beyond that, or anything beyond what's on the bug and in the portage warning related to distcc, I don't know. I did just cc lisa (distcc maintainer) on the bug, so we'll see. I have a feeling distcc users wouldn't be very happy if unmasking this broke them. =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 -- gentoo-dev@gentoo.org mailing list
[gentoo-portage-dev] Re: 2.1-rc3-r5 extraneous but (I think) harmless message?
Alec Warner [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 02 Jun 2006 20:21:35 -0400: Looking at the code I'd guess you'd never noticed, I don't see any commits in treewalk lately, it should occur for all packages. Thanks. At least if one considers it a bug, it's an old one, and as I said, appears harmless other than the misleading display. Therefore, better to let sleeping dogs sleep, for 2.1 anyway. -- 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 -- gentoo-portage-dev@gentoo.org mailing list
