Re: [gentoo-dev] Re: Gentoo activity graphs
060709 Diego 'Flameeyes' Petten? wrote: On Sunday 09 July 2006 01:10, Duncan wrote: An interesting observation was that of all the FLOSS projects, perhaps only Debian had successfully crossed the line from medium to large. but they have maintainers that often does not know what their work is and screw things up very bad: unstable and experimental they call them. It's a badly neglected aspect of business studies that there is an optimal size for any organisation, some bigger than others. In the area of public transport, our own local TTC performs well only because it has a tradition of very good management democratic control. One reason so much of the British railway system was closed 1955-70 was that the unified nationalised (1948) organisation BR was too big for its management to keep up with, so they dumped all the local bits. There have been any number of corporate mergers which went too far. This is an underlying principle of human behaviour which Gentoo should accept never measure success by how big it's getting. Also it sb very careful how it integrates new devs: mentoring is much more important than tests. Another basic human need is to take breaks. Some recent sudden departures might have been avoided, if devs took regular vacations as an accepted norm. The average age for Gentoo devs seems to be about 25 , which means there's lots of energy, but a bit too little experience. As someone who's been around longer than that (smile), I haven't seen anything seriously wrong with the way Gentoo does things. Open debate, democratic votes some basic tolerance solve most problems the occasional guy who doesn't fit in can be bidden a friendly goodbye. -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Pending Removal of $KV
On Mon, Jun 19, 2006 at 11:13:33AM +, Alec Warner [EMAIL PROTECTED] wrote: Portage currently exports $KV as the current kernel version. We detect this by attempting to mess around with the things in /usr/src/linux (.config, make files, etc...) This is duplicating the superb efforts of the kernel team and of linux-info eclass. As such I would like to deprecate $KV in favor of using linux-info eclass. I don't see the need for portage to export $KV into the environment for all packages. There are a few packages left that use this. There will be a tracker bug shortly. Mostly this mail is just a heads up ;) I've been after this for quite a long time (I opened a bug but cant seem to find it) as not only is it horrifically broken, it also should never have been the job of portage internals anyways. $KV is currently being exported by linux-info purely for legacy support and as such I would like to suggest that if these ebuilds inherit linux-info as well as use $KV, then it should not require any maintainer changes. Anything I can do to encourage this move please let me know, and many thanks for raising this again. Best Regards, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgppBTaSFSiXx.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] Resignation
On Tue, Jun 27, 2006 at 03:21:49PM +0200, Andrej Kacian [EMAIL PROTECTED] wrote: On Tue, 27 Jun 2006 13:07:45 +0200 Enrico Weigelt [EMAIL PROTECTED] wrote: As I have been swamped with emails, private messages and phone calls from certain people, I will retract my resignation for the final time. I'm fairly new to Gentoo, but I'd like to help. So, what shall I do ? You can start by not hijacking mailing list threads. Or am I the only one failing to see how is this connected to Jory's (retracted) resignation ? Having not yet read the rest of this thread I'm sorry if this is going to repeat anything else thats being said, however... This is a prime example of one of the reasons which is making people leave gentoo, either as a developer or as a user. Having someone email to show their appreciation for peoples work and equally as important to also be willing to commit their own time to help as well being shot down with such an ignorant comment is upsetting to say the least. I suggest the next time someone wants to offer their help you think twice before you flame for off-topic. However, on that note... Enrico, Please find some reading on the subject here: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=2 If you need any further help please feel free to join IRC and ask in #gentoo-userrel Best Regards, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpdrA1OgQFtA.pgp Description: PGP signature
Re: [gentoo-dev] new herd: vdr - topic reanimated
Hi! As the situation now has changed I would like to discuss this one more. Since one week we (hd_brummy and me) have changed our Gentoo VDR Project (http://www.gentoo.org/proj/en/desktop/video/vdr/index.xml) to an official subproject of desktop/video. Now the situation is as follows: Most packages have historically either a) one of us or b) both as a maintainer and the herd media-tv as fallback. c) The newest ebuilds have herd media-tv and [EMAIL PROTECTED] (projects mail-address) as maintainer. We now think that this should be unified. Our ideal would be having the concept of a sub-herd. The best realizable alternatives we can think of are: c) herd media-tv and [EMAIL PROTECTED] (projects mail-address) as maintainer. d) create an own herd vdr. What do you think of that? Zzam -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org pgpA9Hp26uXpb.pgp Description: PGP signature
Re: [gentoo-dev] Off with your heads!
On Thu, 2006-07-06 at 20:46 -0600, Steve Dibb wrote: @devs, If your blog is being aggregated on Planet Gentoo / Universe, it's time to send us a copy of your smiling face. I'm putting out a request for some hackergotchis. Really, you don't want just a few of us to have all the fun, do you? Here's mine. Daniel dang.png Description: PNG image signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Portage: missing pieces
Molle Bestefich wrote: The current situation is very annoying for users that update often, and also makes Portage mostly unusable for automatic server upgrades After unmerging mono-tools so Portage could finally run a whole update, it stopped halfway through because of this bug: http://bugs.gentoo.org/show_bug.cgi?id=132122 I noticed that several users have commented with a relevant complaint: GCC-4.x is required by the ebuild, but no information is ever conveyed to the end user about this fact. The ebuild does not have a dependency on GCC-4.x. Try reading the bug - users are basically being shoved off with an arrogant silence and a stamp on their forehead saying INVALID. Nothing personal against Jakub Moc who probably has a lot to do, but the handling of relevant issues raised in the bugzilla is just unacceptable. What's the state of Portage and Gentoo in general? Is there not enough hands to do a proper job? Or is it just that none of the devs see what's wrong because bugs are wrongly being closed marked INVALID such as the above when they're in fact not? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] helping out - how?
I'd like to take a stab at maintainership (or at least fixing) an unmaintained ebuild. What versioning system do you guys use (CVS?), and what's the URL for checking out ebuilds? (I was thinking that I'd conjure up a patch and submit it here so someone with commit access can put it in.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
Molle Bestefich wrote: I noticed that several users have commented with a relevant complaint: GCC-4.x is required by the ebuild, but no information is ever conveyed to the end user about this fact. The ebuild does not have a dependency on GCC-4.x. No, it's not. gcc-3.4.x *is* required. That versions (or later) is *stable* everywhere where xine-lib is stable. Try reading the bug - users are basically being shoved off with an arrogant silence and a stamp on their forehead saying INVALID. Nothing personal against Jakub Moc who probably has a lot to do, but the handling of relevant issues raised in the bugzilla is just unacceptable. Dependency on a particular gcc version will solve exactly nothing. Having that version installed doesn't mean you are really *using* it. You won't be automagically switched to 3.4.x when upgrading from 3.3.x, you won't be automatically switched to gcc 4.x when upgrading from 3.4.x http://www.gentoo.org/doc/en/gcc-upgrading.xml What's the state of Portage and Gentoo in general? Is there not enough hands to do a proper job? Or is it just that none of the devs see what's wrong because bugs are wrongly being closed marked INVALID such as the above when they're in fact not? How about the you finally upgrade your outdated gcc, as asked over and over again? gcc-3.3.x is dead, unsupported upstream, we won't be fixing any bugs there. Hard to understand? Apparently, I guess... Thanks for your rant. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Portage: missing pieces
On Sun, 09 Jul 2006 21:37:47 +0200 Jakub Moc [EMAIL PROTECTED] wrote: | Molle Bestefich wrote: | I noticed that several users have commented with a relevant | complaint: GCC-4.x is required by the ebuild, but no information is | ever conveyed to the end user about this fact. The ebuild does not | have a dependency on GCC-4.x. | | No, it's not. gcc-3.4.x *is* required. That versions (or later) is | *stable* everywhere where xine-lib is stable. Not true. According to the 2006.0 x86 profile, for example, you're required to have =sys-devel/gcc-3.3.4-r1. There is no requirement that 3.4 be installed. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On Sun, 09 Jul 2006 22:10:48 +0200 Jakub Moc [EMAIL PROTECTED] wrote: | Not true. According to the 2006.0 x86 profile, for example, you're | required to have =sys-devel/gcc-3.3.4-r1. There is no requirement | that 3.4 be installed. | | Yeah, that's not what I've been talking about at all, what's your | point? I was saying that gcc-3.4 and better is stable everywhere | where it's needed. How does it change that 3.3 is dead as a nail in a | lamproom door and users should switch to something that we actually | can support? Tradition for toolchain stuff has always been that anything allowed by the profile is considered acceptable for general use. So, if users shouldn't be using 3.3, the profile should be changed to say so. Until then there's no obligation to upgrade. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Jakub Moc wrote: Try reading the bug - users are basically being shoved off with an arrogant silence and a stamp on their forehead saying INVALID. Nothing personal against Jakub Moc who probably has a lot to do, but the handling of relevant issues raised in the bugzilla is just unacceptable. Dependency on a particular gcc version will solve exactly nothing. Having that version installed doesn't mean you are really *using* it. You won't be automagically switched to 3.4.x when upgrading from 3.3.x, you won't be automatically switched to gcc 4.x when upgrading from 3.4.x Yes ok. So the user has to both merge the new version, and switch to it. Either way, the end user is not getting told what should be done, instead Portage just breaks, which is exactly what all the complaints are about. How about the you finally upgrade your outdated gcc, as asked over and over again? gcc-3.3.x is dead, unsupported upstream, we won't be fixing any bugs there. Hard to understand? Apparently, I guess... I've never been told so, I have no clue what you are talking about. Thanks for your rant. What kind of reply do you expect to get from such crap? Thanks for being an asshole? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On 7/9/06, Molle Bestefich [EMAIL PROTECTED] wrote: Try reading the bug - users are basically being shoved off with an arrogant silence and a stamp on their forehead saying INVALID. *Sigh*. You really should post to -user first. The expectation here is that when a new version of gcc is stabilized, that users will upgrade to that in a reasonable amount of time, and use that (by selecting it with gcc-config) for compiling all new updates. FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th. The devs can *not* be expected to verify that all software in portage builds with all versions of gcc in portage. For example, there is still an ebuild for gcc-2.95.3! But that is _not_ to be used for compiling new updates. The alternative here is that old versions of gcc disappear from portage, but that causes a problem for those who need those versions for some reason, such as compiling non-gentoo software. Nothing personal against Jakub Moc who probably has a lot to do, but the handling of relevant issues raised in the bugzilla is just unacceptable. What, exactly, do you find unacceptable in Your gcc version is outdated and unsupported? I suppose portage could be enhanced to have a is_gcc_version_supported() check, but I'm not sure how useful that would be. What's the state of Portage and Gentoo in general? Is there not enough hands to do a proper job? Or is it just that none of the devs see what's wrong because bugs are wrongly being closed marked INVALID such as the above when they're in fact not? If you want to test compiling every version of every package in portage with all 21 versions (16 if you assume all -rX versions are compatible, or /only 9/ if you only consider stable x86 versions) of gcc that are currently in portage, and submit patches when things fail, go ahead. BTW, your patches cannot remove the ability to use improvements that are only available in newer stable versions of gcc, such as -fvisibility=hidden. -Richard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: helping out - how?
Ioannis Aslanidis wrote: You'd rather fill in a bug report and submit the patch in the bug. Not in this list, definitely. Oh, ok. Never mind then, I fear I'd be spending way too much time fighting with Jakub trying to get the ebuild in the tree. I'll just drop it. (Nothing personal, I just don't think it would work out, heh.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] helping out - how?
On 7/9/06, Molle Bestefich [EMAIL PROTECTED] wrote: I'd like to take a stab at maintainership (or at least fixing) an unmaintained ebuild. What versioning system do you guys use (CVS?), and what's the URL for checking out ebuilds? bugs.gentoo.org is where this kind of work is done. -Richard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Dying on some CFLAGS instead of filtering them.
Dear devs, In bug #139412, I ask Paul de Vriese why he thinks python should die on --fast-math instead of just filtering it. Here's his answer : Denis, quite simple. -ffast-math is broken and short-sighted for a global flag. Filtering gives the shortsighted message that it works globally, while it is not suited for any package not specifically tested for it. As it breaks python, dieing makes people understand that it does not work on python. It is better than the alternative of not looking for it at all. This, for me, triggers 3 questions that are gentoo-dev@ material : 1) Should all ebuilds that currently filter --fast-math die on its presence instead of filtering it ? 2) If yes, are there any other flags that ebuilds should die on ? 3) Suppose that -ftracer, for example, is one of those, and knowing that enabling -fprofile-use enables -ftracer, shouldn't ebuilds also die on use of -fprofile-use ? It's only an example, this situation will exist for other pairs of flags. The hidden question behind these three is : shouldn't we have a something that enables us to safely handle this kind of situations ? Like some kind of system- and/or architecture-wide flag mask that could be overriden by the ebuild and/or the user (at his own risk) ? This could potentialy reduce the number of bugs that poor old bugzie has to cope with, and simplify ebuild writing and maintenance. If we already have such a thing, I'm sure you guys know where the cluebat is... But in any case, questions 1), 2) and 3) still need to be answered. Denis. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Portage: missing pieces
Richard Fish wrote: The expectation here is that when a new version of gcc is stabilized, that users will upgrade to that in a reasonable amount of time, and use that (by selecting it with gcc-config) for compiling all new updates. FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th. I don't see how that information is conveyed to the user. Portage shouts about upgrading to a new profile from time to time, but it never tells anyone to upgrade GCC. Perhaps it should, if that's what the devs expect people to do. The devs can *not* be expected to verify that all software in portage builds with all versions of gcc in portage. Of course not. The alternative here is that old versions of gcc disappear from portage, but that causes a problem for those who need those versions for some reason, such as compiling non-gentoo software. Yes, ok. That's a bad alternative. Thus it seems that there's no appropriate mechanism to handle new GCC versions in Portage, which again makes sense wrt. the complaints. Nothing personal against Jakub Moc who probably has a lot to do, but the handling of relevant issues raised in the bugzilla is just unacceptable. What, exactly, do you find unacceptable in Your gcc version is outdated and unsupported? Nothing? I find it unacceptable that the bug is marked INVALID when it clearly describes a relevant issue. As far as I can tell, the complaints are about Portage being unable to handle GCC upgrades gracefully for end users. You could perhaps argue that the issue started out as why do I get this error message and ended up being why doesn't Portage handle GCC upgrades gracefully, which is of course a slightly different thing. But it should be clear to anyone reading the bug what the real issue is. I'm even willing to bet that if I create a new bug describing the Portage issue, with no mention of the specific xine ebuild, it will get closed as a duplicate of this bug anyway. I've got case studies proving that this is what happens, heh. I suppose portage could be enhanced to have a is_gcc_version_supported() check, but I'm not sure how useful that would be. If that would enable ebuild maintainers to flag xine as requiring 3.4 for compilation, then that would definitely solve the issue described in the bug. I'd say that's _very useful_ to the end user. You could argue that only a couple of people has spent the time to create a bugzilla login and lodge a complaint in the bug, but there's probably more out there. We can count the duplicates in a couple of months and see ;-). And as newer GCC features are used throughout, the situation will probably happen more in the future. What's the state of Portage and Gentoo in general? Is there not enough hands to do a proper job? Or is it just that none of the devs see what's wrong because bugs are wrongly being closed marked INVALID such as the above when they're in fact not? If you want to test compiling every version of every package in portage with all 21 versions (16 if you assume all -rX versions are compatible, or /only 9/ if you only consider stable x86 versions) of gcc that are currently in portage, and submit patches when things fail, go ahead. That won't be necessary. Things mostly works, and when they don't, users file a bug like the aforementioned one, which should result in that particular ebuild getting fixed, instead of the bug being marked INVALID. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for some CD/DVD-recording applications
Lars Weiler wrote: app-cdr/dvdrtools: Same reason. No need to use this fork of cdrtools-1.11... This is a lot more more than a add DVD writing support fork - they have changed much more than that, and they have an interesting list of objectives. It's a much saner version of cdrtools. Please don't remove it unless you have confirmed with upstream that they have lost interest and nobody is developing it. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: helping out - how?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Molle Bestefich wrote: Ioannis Aslanidis wrote: You'd rather fill in a bug report and submit the patch in the bug. Not in this list, definitely. Oh, ok. Never mind then, I fear I'd be spending way too much time fighting with Jakub trying to get the ebuild in the tree. I'll just drop it. (Nothing personal, I just don't think it would work out, heh.) Nonsense. Jacub's a big pussy cat who gets stressed out a bit and needs a vacation ;) Does the package your thinking of have a specific category set (for instance, maybe unmaintained specifically, but falls under a broad category that the bug could go to?). As others have (and will) comment, posting patches on this is flamebait of the worst kind. Hope to see you on bugzie, I know I for one welcome bugs that come with their own patch solutions :) - -- - -o()o-- Michael Cummings |#gentoo-dev, #gentoo-perl Gentoo Perl Dev|on irc.freenode.net Gentoo/SPARC Gentoo/AMD64 GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E - -o()o-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEsYFjq1ztTp5/Ti4RAkrvAJ9P0fEqHkyLszQ1w+SB/5NM2iD2VACffyjs 7fPxvNbvDql3O8VyOBkOwJw= =yGyY -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sun, 09 Jul 2006 22:10:48 +0200 Jakub Moc [EMAIL PROTECTED] wrote: | Not true. According to the 2006.0 x86 profile, for example, you're | required to have =sys-devel/gcc-3.3.4-r1. There is no requirement | that 3.4 be installed. | | Yeah, that's not what I've been talking about at all, what's your | point? I was saying that gcc-3.4 and better is stable everywhere | where it's needed. How does it change that 3.3 is dead as a nail in a | lamproom door and users should switch to something that we actually | can support? Tradition for toolchain stuff has always been that anything allowed by the profile is considered acceptable for general use. So, if users shouldn't be using 3.3, the profile should be changed to say so. Until then there's no obligation to upgrade. Then it seems like that 2006.0 x86 profile should be updated (without waiting for 2006.1 to be released). Dunno if other arches have to run such legacy gcc versions, but the logical thing is to point to 3.4.x instead on x86. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEsYLBrsJQqN81j74RAidcAKCGdhpAiObclSZuwR8Heod1wqK9yQCgmI16 ax6u8GA7z9GQEkdqErq8xD4= =0VzK -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: helping out - how?
What versioning system do you guys use (CVS?), and what's the URL for checking out ebuilds? bugs.gentoo.org is where this kind of work is done. There's already an existing but unmaintained ebuild. That's what I wanted to check out, so I could modify it and submit a diff -u. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: helping out - how?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Molle Bestefich wrote:
What versioning system do you guys use (CVS?),
and what's the URL for checking out ebuilds?
bugs.gentoo.org is where this kind of work is done.
There's already an existing but unmaintained ebuild.
That's what I wanted to check out, so I could modify it and submit a
diff -u.
What's in cvs is what you --sync to your desktop. You just need to
submit the patch on bugs.g.o - there is nothing more in cvs than what
you get when you emerge sync ('cept maybe timeliness of your mirror)
- --
- -o()o--
Michael Cummings |#gentoo-dev, #gentoo-perl
Gentoo Perl Dev|on irc.freenode.net
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E
- -o()o--
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.4 (GNU/Linux)
iD8DBQFEsYgzq1ztTp5/Ti4RAp01AJ9i12x6rWQ1ENUHvBE7T4nKKhzUMQCggQ5M
oSCqQEhtOsXAKPO1IyBTOjI=
=9EeP
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
Denis Dupeyron wrote: In bug #139412, I ask Paul de Vriese why he thinks python should die on --fast-math instead of just filtering it. Here's his answer : Denis, quite simple. -ffast-math is broken and short-sighted for a global flag. Filtering gives the shortsighted message that it works globally, while it is not suited for any package not specifically tested for it. As it breaks python, dieing makes people understand that it does not work on python. It is better than the alternative of not looking for it at all. Ebuilds shouldn't die on anything according to the non-interactive portage philosophy. I don't know how official that philosophy is though. This, for me, triggers 3 questions that are gentoo-dev@ material : 1) Should all ebuilds that currently filter --fast-math die on its presence instead of filtering it ? No, that would be a major pain in the ass for anyone wanting to use -fast-math, which does have legitimate uses. 2) If yes, are there any other flags that ebuilds should die on ? There's a million, and they're constantly changing. For example, -frename-registers is generally safe on GCC 3.4, broken in 4.0, and enabled by default on 4.1. 3) Suppose that -ftracer, for example, is one of those, and knowing that enabling -fprofile-use enables -ftracer, shouldn't ebuilds also die on use of -fprofile-use ? It's only an example, this situation will exist for other pairs of flags. The hidden question behind these three is : shouldn't we have a something that enables us to safely handle this kind of situations ? Like some kind of system- and/or architecture-wide flag mask that could be overriden by the ebuild and/or the user (at his own risk) ? This could potentialy reduce the number of bugs that poor old bugzie has to cope with, and simplify ebuild writing and maintenance. Users playing with CFLAGS get to keep the pieces. Trying to dummy-proof the system doesn't help anyone but the dummies. ;) --de. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new herd: vdr - topic reanimated
Matthias Schwarzott wrote: What do you think of that? c is simpler. I like it. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Off with your heads!
On 09/07/06, Daniel Gryniewicz [EMAIL PROTECTED] wrote: On Thu, 2006-07-06 at 20:46 -0600, Steve Dibb wrote: @devs, If your blog is being aggregated on Planet Gentoo / Universe, it's time to send us a copy of your smiling face. I'm putting out a request for some hackergotchis. Really, you don't want just a few of us to have all the fun, do you? Here's mine. Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4-ecc0.1.6 (GNU/Linux) iD8DBQBEsUpeomPajV0RnrERAua3AJsEph/EP9EWa977KpeZVnkrz/wYeQCdFajI l2+K9sqkqkMkzTifNf4D4EU= =nIE2 -END PGP SIGNATURE- Could we have a localised one like Gnome as well? http://www.uk.gnome.org/planet/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new herd: vdr - topic reanimated
On Monday 10 July 2006 02:25, Luca Barbato wrote: c is simpler. I like it. Yes, of course if _all wranglers_ respected metadata, instead of stopping to herd tag and assigning to that even when a particular maintainer is listed. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpe2GF5WZw0k.pgp Description: PGP signature
Re: [gentoo-dev] new herd: vdr - topic reanimated
On Mon, Jul 10, 2006 at 04:36:55AM +0200, Diego 'Flameeyes' Petten?? wrote: On Monday 10 July 2006 02:25, Luca Barbato wrote: c is simpler. I like it. Yes, of course if _all wranglers_ respected metadata, instead of stopping to herd tag and assigning to that even when a particular maintainer is listed. Actually, this isn't that simple at the moment. There are packages that directly list me as the maintainer, but I want bugs for them assigned to the herd by default - so that the other folk in the herd can find them quickly. Perhaps this could be alleviated with an explicit assign-to field in package metadata? At the same time, it should have an explicit cc-to field, for cases where the maintainer is not in the herd. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpgAFtIKpWNk.pgp Description: PGP signature
[gentoo-portage-dev] glsa-check wrong
glsa-check returns errorlevels 255 which results in shell being unable to parse it (anything greater 255 is 0). --- /usr/bin/glsa-check.orig2006-06-03 15:29:37.0 +0200 +++ /usr/bin/glsa-check 2006-07-09 19:29:36.0 +0200 @@ -223,6 +223,8 @@ if verbose: sys.stderr.write(emergecmd+\n) exitcode = os.system(emergecmd) + if exitcode 255: + exitcode = exitcode 8 if exitcode: sys.exit(exitcode) myglsa.inject() -- radoslaw. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] glsa-check wrong
On Sun, 2006-07-09 at 19:34 +0200, Radoslaw Stachowiak wrote: glsa-check returns errorlevels 255 which results in shell being unable to parse it (anything greater 255 is 0). I've opened Bug #139804 to track this. Regards, Paul -- gentoo-portage-dev@gentoo.org mailing list
