Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 19:04, Harald van Dijk wrote: I hope this is specific enough: toolchain.eclass revision 1.234 (separating ssp/... from vanilla) log message: ssp/pie/htb have their own USE flags sep from vanilla, so people can utilize those when in fact the old USE=vanilla behaviour is unavailable now. You have never (as far as I know) answered whether it was intended to keep the old behaviour as an option, and if it wasn't, why the log message is what it is. well i cant answer it if you havent asked it ... me not answering you on irc when i'm not around does not constitute being ignored and anyone who relies on irc in this respect really needs to learn more about irc I also mentioned it in a bugzilla comment, though admittedly not as a question there. (The gcc 2 bug, I think.) Bugzilla comments are safe to assume read, right? the log message looks pretty clear to me, i dont see this hidden message you're referring to the ssp/pie/htb patches have their own USE flags so separating them from USE=vanilla makes perfect sense ... I'm not disagreeing with that, but removing an older option is not just providing more choices. now you can do: gentoo patches + ssp gentoo patches + nossp vanilla + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla + ssp vanilla + stub whereas before you only had the option of: gentoo patches + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... But I'm not asking for USE=vanilla to disable SSP completely, I'm only asking for USE=vanilla nossp to disable it. nossp is already explicitly documented as NOT FOR GENERAL USE, too. this is also the reason i havent added USE=vanilla to glibc, too many users would simply break their boxes No complaints there. :) -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 19:04, Harald van Dijk wrote: the ssp/pie/htb patches have their own USE flags so separating them from USE=vanilla makes perfect sense ... I'm not disagreeing with that, but removing an older option is not just providing more choices. now you can do: gentoo patches + ssp gentoo patches + nossp vanilla + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla + ssp vanilla + stub whereas before you only had the option of: gentoo patches + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... But I'm not asking for USE=vanilla to disable SSP completely, I'm only asking for USE=vanilla nossp to disable it. nossp is already explicitly documented as NOT FOR GENERAL USE, too. No offence, but you are being very unreasonable in this thread. The fact that you can get what you are after, even though its not entirely supported, should be enough for you, especially for the fact that you are not clueless. You should remember that somebody at the end of the day have to sacrifice time and effort to fix bugs, and especially with something as complex as gcc, the more variables, the more effort it is going to be. And as Mike is relatively the only person currently who seems to maintain gcc, it should be his prerogative to decided that he get too much spam without the stubs. And you should really know by now that being documented as NOT FOR GENERAL USE will still not stop more than enough users to waste his time in telling them not to disable SSP with vanilla if they don't know what they are doing. Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. For the fact that we do not support vanilla gcc - I assume this is a gcc built by yourself - this truly is really unfair of you to expect it. The 'contract' we usually have with upstream, is that if we apply patches to their software, we will be the first tier in the support chain. Now you want to run gcc which was not modified by us to fix the known hangups in how we do things - or save us time for that matter, and you still want us to support it - or at least make life easier for us by not leaving gaping holes that cost us maintenance time? Am I the only one feeling that this is really selfish/absurd thinking since you have such an hackle in what we do, to not research, debug, and file thus your own bugs with http://gcc.gnu.org/bugzilla/ ? The alternative to this that you seem to ignore, is that you can start helping maintaining gcc (I am sure Mike will appreciate help with Halcy0n gone as well, and me not having that much time currently). And of course promising so long as the stubs do not get applied with nossp, that you will handle all breakage in that area. Although I do not know if its still really fair to expect Jakub et ell to sacrifice time to process the bugs, and get them to you if its related to something failing due to the missing stubs. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Nominations open for the Gentoo Council 2007
Alexandre Buisse [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 08 Jul 2006 01:30:45 +0200: Encouraged by this email and hoping that it is ok to do so, I will nominate myself. Now you gotta post a reply, accepting (or declining g) the nomination! =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-dev] Last rites for some CD/DVD-recording applications
Hello, I would like to remove those packages from portage: app-cdr/cdrecord-prodvd: Functionality of DVD-burning is now officially included in app-cdr/cdrtools. app-cdr/dvdrtools: Same reason. No need to use this fork of cdrtools-1.11... virtual/cdrtools: With the remove of dvdrtools there is no longer a need for this virtual. app-cdr/xcdroast: A nice rustical application, which reminds me to my first CD-burnings on Linux... But there was no upstream update within 2,5 years. Also there are now a lot of other gtk2-based applications which are bettter than xcdrtools. rox-extra/roxiso: Unmaintained package, but it depends on app-cdr/cdrecord-prodvd. On the other hand, I just installed it, and it fails to start due to a missing library... It seems that all rox-packages are unmaintained now, as the maintainers resigned or are not available. All packages are in package.mask. I will remove then in 30 days when there is no good reason to keep them. Regards, Lars -- Lars Weiler [EMAIL PROTECTED] +49-171-1963258 Gentoo Linux PowerPC: Strategical Lead and Release Engineer Gentoo Infrastructure : CVS Administrator Gentoo Foundation : Trustee pgp5U2lomB3UO.pgp Description: PGP signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 2006-07-07 at 15:18 -0500, Tushar Teredesai wrote: On 7/7/06, Ned Ludd [EMAIL PROTECTED] wrote: You want a pure 100% vanilla(POS) non working toolchain then go download it and compile it yourself. You will soon see why things exist the way they do.. LFS http://www.linuxfromscratch.org/lfs has always been based on a vanilla toolchain. Never ran into issues. Of course, we do apply upstream patches when needed. They patch gcc as needed also. http://www.linuxfromscratch.org/hlfs/ -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 2006-07-07 at 23:09 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 03:57:51PM -0400, Ned Ludd wrote: On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote: Keep pushing this and the only thing you will end up with is the vanilla flag being removed all together.. Is that a threat? If not, is there a reason behind this? Yes.. When users or devs complain non stop when they don't understand something it leaves us with a few choices. 1) put up with people not having a clue. 2) remove the option so they can't bitch about it. Option #1 is not fun as it pushes the hand on #2 Option 3: Enlighten me. I have explained why I feel the way I do, so if there's some big flaw in my understanding, please do correct it. Sigh... I'm not going to sit here and bicker with you. At the end of the day here is what matters.. Your giving Mike a hard time on the most vital of all programs in this distro and that just sucks so please stop and just be happy that the toolchain works as well as it does. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Sat, Jul 08, 2006 at 11:27:57AM +0200, Martin Schlemmer wrote: On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 19:04, Harald van Dijk wrote: the ssp/pie/htb patches have their own USE flags so separating them from USE=vanilla makes perfect sense ... I'm not disagreeing with that, but removing an older option is not just providing more choices. now you can do: gentoo patches + ssp gentoo patches + nossp vanilla + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla + ssp vanilla + stub whereas before you only had the option of: gentoo patches + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... But I'm not asking for USE=vanilla to disable SSP completely, I'm only asking for USE=vanilla nossp to disable it. nossp is already explicitly documented as NOT FOR GENERAL USE, too. No offence, but you are being very unreasonable in this thread. The fact that you can get what you are after, even though its not entirely supported, should be enough for you, especially for the fact that you are not clueless. You should remember that somebody at the end of the day have to sacrifice time and effort to fix bugs, and especially with something as complex as gcc, the more variables, the more effort it is going to be. And as Mike is relatively the only person currently who seems to maintain gcc, it should be his prerogative to decided that he get too much spam without the stubs. Sorry, but how much mail he gets does not affect one bit which behaviour is better, it only helps understand why the lesser behaviour could be chosen by reasonable people anyway. (Regardless of which behaviour is the lesser one.) And I don't harass anyone about -- it's been a very long time since I even mentioned any problems like this, and if nothing is done after this thread dies, I'll likely be quiet about it for a long time again -- so please don't act like I do. And you should really know by now that being documented as NOT FOR GENERAL USE will still not stop more than enough users to waste his time in telling them not to disable SSP with vanilla if they don't know what they are doing. I guess that's a fair point. Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. For the fact that we do not support vanilla gcc - I assume this is a gcc built by yourself - Actually, I meant gcc built with the vanilla flag here, as opposed to pure official GCC, which I already stated is unsupported earlier. this truly is really unfair of you to expect it. The 'contract' we usually have with upstream, is that if we apply patches to their software, we will be the first tier in the support chain. Now you want to run gcc which was not modified by us to fix the known hangups in how we do things - or save us time for that matter, and you still want us to support it - or at least make life easier for us by not leaving gaping holes that cost us maintenance time? Differences between official GCC and Gentoo's GCC are 1) fixed bugs, and 2) added features. (Assuming no patches are broken.) I think it's reasonable to not rely on the existence of those added features. You seem to think I think it's reasonable to not rely on bugs being fixed. No problem there, I don't. Besides, I said it's unfortunate that vanilla GCC (either one) is unsupported, not that it must be. My other problem, that vanilla GCC is different from Gentoo's GCC with the vanilla flag (plus maybe nossp/nopie/...), can be handled without requiring support for it from anyone. Am I the only one feeling that this is really selfish/absurd thinking since you have such an hackle in what we do, to not research, debug, and file thus your own bugs with http://gcc.gnu.org/bugzilla/ ? I actually do file bugs there when I run into them. The alternative to this that you seem to ignore, is that you can start helping maintaining gcc (I am sure Mike will appreciate help with Halcy0n gone as well, and me not having that much time currently). Since I'm more interested in vanilla GCC, I think there's little to help maintain from Gentoo's side (support in ebuilds, and possibly the build process, that's it). If that's something you think help would be good for anyway, though, sure, if I can. And of course promising so long as the stubs do
Re: [gentoo-dev] Last rites for some CD/DVD-recording applications
On Sat, 8 Jul 2006 13:09:29 +0200 Lars Weiler [EMAIL PROTECTED] wrote: app-cdr/xcdroast: A nice rustical application, which reminds me to my first CD-burnings on Linux... But there was no upstream update within 2,5 years. Also there are now a lot of other gtk2-based applications which are bettter than xcdrtools. If there's nothing actually broken with xcdroast, why remove it? It does provide a cd-burning app for those who want something with few dependencies. Are there other CD-burning apps that don't depend on qt or gtk2?gre hmm; I notice it wants cdrecord-prodvd for dvd writing - will it not use the newer app-cdr/cdrtools to support DVDs (perhaps with the -n option to not check the tool version)? Presumably the newer cdrtools is backwards-compatible with the cdrecord-prodvd command line options? -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo activity graphs
Alin Nastac wrote: I find active devs metric a useful one.Until a year ago, the number of active devs was linearly rising, but in last year we seem to hit a ceil (175) - either recruiter team is understaffed or our organization reached the maximum number of individuals who can work together without stepping (too much) on each other toes. Anyway, a thing is certain... Gentoo didn't loosed dev's attention. Was it on planet.g.o where i read something about Dunbar's number[1]? A highly interesting subject and it might be possible that the Monkeyspheres of Gentoo devs do not overlap sufficiently. There is only one solution to this problem: You need to go out and get drunk together! ;) [1] http://en.wikipedia.org/wiki/Dunbar%27s_number -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for some CD/DVD-recording applications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin F. Quinn wrote: On Sat, 8 Jul 2006 13:09:29 +0200 Lars Weiler [EMAIL PROTECTED] wrote: app-cdr/xcdroast: A nice rustical application, which reminds me to my first CD-burnings on Linux... But there was no upstream update within 2,5 years. Also there are now a lot of other gtk2-based applications which are bettter than xcdrtools. If there's nothing actually broken with xcdroast, why remove it? It does provide a cd-burning app for those who want something with few dependencies. Are there other CD-burning apps that don't depend on qt or gtk2?gre Just my opinion too. Or what if just preserve it for nostalgic purposes? :-) /me used it as my first GUI CD-burn application - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEr6H5dZ42PGEF17URAmAQAKDN7Mrm4dqTrCSiw6qokPLsCFXA9wCgyHzM db5+X3xVQjitm+Dpo1AybJk= =4zAO -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for some CD/DVD-recording applications
On Sat, 2006-07-08 at 14:11 +0200, Kevin F. Quinn wrote: On Sat, 8 Jul 2006 13:09:29 +0200 Lars Weiler [EMAIL PROTECTED] wrote: app-cdr/xcdroast: A nice rustical application, which reminds me to my first CD-burnings on Linux... But there was no upstream update within 2,5 years. Also there are now a lot of other gtk2-based applications which are bettter than xcdrtools. If there's nothing actually broken with xcdroast, why remove it? It does provide a cd-burning app for those who want something with few dependencies. Are there other CD-burning apps that don't depend on qt or gtk2?gre hmm; I notice it wants cdrecord-prodvd for dvd writing - will it not use the newer app-cdr/cdrtools to support DVDs (perhaps with the -n option to not check the tool version)? Presumably the newer cdrtools is backwards-compatible with the cdrecord-prodvd command line options? I've talked with Lars we will keep xcdroast for a bit. Instead we will remove simplecdrx that i will mask now. The upstream is dead for years and there's not need to keep it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for some CD/DVD-recording applications
* Roy Bamford [EMAIL PROTECTED] [06/07/08 12:46 +0100]: app-cdr/dvdrtools provides the format utility to format DVD+RW media prior to mkudffs on them. Where has that functionality gone ? I can't find any 'format' option to dvdrecord. But probably you want cdrwtool from sys-fs/udftools? Regards, Lars pgpSw9zQud2lE.pgp Description: PGP signature
Re: [gentoo-dev] Last rites for some CD/DVD-recording applications
* Luis Medinas [EMAIL PROTECTED] [06/07/08 13:33 +0100]: I've talked with Lars we will keep xcdroast for a bit. Instead we will remove simplecdrx that i will mask now. The upstream is dead for years and there's not need to keep it. But we keep xcdroast only when you patch it, so that it does not need cdrecord-prodvd for burning DVDs. And no, starting with -n does not work. Maximum size is 703MB per disk. Regards, Lars -- Lars Weiler [EMAIL PROTECTED] +49-171-1963258 Gentoo Linux PowerPC: Strategical Lead and Release Engineer Gentoo Infrastructure : CVS Administrator Gentoo Foundation : Trustee pgpmUDCkMo8eB.pgp Description: PGP signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Sat, 2006-07-08 at 13:51 +0200, Harald van Dijk wrote: On Sat, Jul 08, 2006 at 11:27:57AM +0200, Martin Schlemmer wrote: On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 19:04, Harald van Dijk wrote: like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... But I'm not asking for USE=vanilla to disable SSP completely, I'm only asking for USE=vanilla nossp to disable it. nossp is already explicitly documented as NOT FOR GENERAL USE, too. No offence, but you are being very unreasonable in this thread. The fact that you can get what you are after, even though its not entirely supported, should be enough for you, especially for the fact that you are not clueless. You should remember that somebody at the end of the day have to sacrifice time and effort to fix bugs, and especially with something as complex as gcc, the more variables, the more effort it is going to be. And as Mike is relatively the only person currently who seems to maintain gcc, it should be his prerogative to decided that he get too much spam without the stubs. Sorry, but how much mail he gets does not affect one bit which behaviour is better, it only helps understand why the lesser behaviour could be chosen by reasonable people anyway. (Regardless of which behaviour is the lesser one.) And I don't harass anyone about -- it's been a very long time since I even mentioned any problems like this, and if nothing is done after this thread dies, I'll likely be quiet about it for a long time again -- so please don't act like I do. Actually it does if it cuts back his time by a very large percentage so that he cannot do the other things he wants/needs to. I assume this was the case if he added that in the first place, and still refuse to change it. Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. For the fact that we do not support vanilla gcc - I assume this is a gcc built by yourself - Actually, I meant gcc built with the vanilla flag here, as opposed to pure official GCC, which I already stated is unsupported earlier. Hmm, thought I might have had it a tad wrong. I still though do not understand what the whole fuss is about stubs for some 5 flags. (which is what you are left with with USE=vanilla nossp currently if my memory is correct). Maybe read down a bit before replying here. this truly is really unfair of you to expect it. The 'contract' we usually have with upstream, is that if we apply patches to their software, we will be the first tier in the support chain. Now you want to run gcc which was not modified by us to fix the known hangups in how we do things - or save us time for that matter, and you still want us to support it - or at least make life easier for us by not leaving gaping holes that cost us maintenance time? Differences between official GCC and Gentoo's GCC are 1) fixed bugs, and 2) added features. (Assuming no patches are broken.) I think it's reasonable to not rely on the existence of those added features. I think its reasonable to no force the feature on you, but add the stubs if it became a maintenance headache. I am pretty sure it was not toolchain who brought the whole situation about in the first place. You can however fix the tree to make sure it will fully build without those flags, and then talk to Mike again about removing them. I am sure he might be more willing if it will not steal his time again. You seem to think I think it's reasonable to not rely on bugs being fixed. No problem there, I don't. Not at all. I thought you think its reasonable to just keep loading work on other people - or possible did not see that that would have been the end result. More about this to the end. Besides, I said it's unfortunate that vanilla GCC (either one) is unsupported, not that it must be. My other problem, that vanilla GCC is different from Gentoo's GCC with the vanilla flag (plus maybe nossp/nopie/...), can be handled without requiring support for it from anyone. From the length of this email, and you not wanting to see the reasoning, or not having started to fix the tree so that your wish can be full filled, It rather sounded like you did demand it. Or this was at least the impression I got. Also once again I do not see what the big issue with the stubs is. You keep making a big issue out of it without giving concrete examples or serious issues it is causing. The problem was there before they were added, and not due to
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Saturday 08 July 2006 02:20, Harald van Dijk wrote: I also mentioned it in a bugzilla comment, though admittedly not as a question there. (The gcc 2 bug, I think.) Bugzilla comments are safe to assume read, right? the gcc2 bug has a lot of things in there i need to review/merge so it's in my little TODO box like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... But I'm not asking for USE=vanilla to disable SSP completely, I'm only asking for USE=vanilla nossp to disable it. nossp is already explicitly documented as NOT FOR GENERAL USE, too. well, vanilla is marked the same way, yet people use it ;) but as i said, i'll add 'use vanilla || apply_stub' logic once 4.1.x goes stable, just no sooner -mike pgpSz5fZ8qFvV.pgp Description: PGP signature
Re: [gentoo-dev] Last rites for some CD/DVD-recording applications
060708 Lars Weiler wrote: I would like to remove those packages from portage: app-cdr/xcdroast: A nice rustical application, which reminds me to my first CD-burnings on Linux. But there was no upstream update within 2,5 years. Also there are now a lot of other gtk2-based applications which are bettter than xcdrtools. All packages are in package.mask. I will remove then in 30 days when there is no good reason to keep them. Please keep Xcdroast in Portage: I use it it has no bugs AFAIK. No recent updates ? -- that applies to many packages in Portage. Better tools ? -- please name them give reasons. Thanks as always for your volunteer labor. -- ,, 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] Last rites for some CD/DVD-recording applications
On 2006.07.08 13:59, Lars Weiler wrote: * Roy Bamford [EMAIL PROTECTED] [06/07/08 12:46 +0100]: app-cdr/dvdrtools provides the format utility to format DVD+RW media prior to mkudffs on them. Where has that functionality gone ? I can't find any 'format' option to dvdrecord. But probably you want cdrwtool from sys-fs/udftools? Regards, Lars Lars, My mistake - sorry for wasting your time. app-cdr/dvd+rw-tools provides the format command. sys-fs/udftools provides the file system for the formatted DVD+RW. Regards, Roy Bamford -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for July
On Saturday 01 July 2006 03:34, Mike Frysinger wrote: This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday once a month), same bat channel (#gentoo-council @ irc.freenode.net) ! we're pushing this to the 3rd due to it being a better time for some of us (blame me :P) -mike pgpQZXwJlYeKH.pgp Description: PGP signature
Re: [gentoo-dev] Last rites for some CD/DVD-recording applications
* Roy Bamford [EMAIL PROTECTED] [06/07/08 14:57 +0100]: My mistake - sorry for wasting your time. app-cdr/dvd+rw-tools provides the format command. sys-fs/udftools provides the file system for the formatted DVD+RW. No problem. And we will kepp dvd+rw-tools for sure. Regards, Lars -- Lars Weiler [EMAIL PROTECTED] +49-171-1963258 Gentoo Linux PowerPC: Strategical Lead and Release Engineer Gentoo Infrastructure : CVS Administrator Gentoo Foundation : Trustee pgpD8krDHAt4k.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Sat, 8 Jul 2006 11:50:47 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: | and i was saying in the namespaced solution you wouldnt need to | use.mask things because $ARCH_CPU_FEATURES would be set by users in | the make.conf ... if they go setting $WRONGARCH_CPU_FEATURES in | make.conf, well i say that's their own fault ;) Mm, repoman wouldn't like that. DEPEND=x86_cpu_features_sse2? ( dev-lang/nasm ) KEYWORDS=x86 sparc splat! -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
(Not commenting on the whole message, just parts.) On Sat, Jul 08, 2006 at 03:46:24PM +0200, Martin Schlemmer wrote: You can however fix the tree to make sure it will fully build without those flags, and then talk to Mike again about removing them. I am sure he might be more willing if it will not steal his time again. I ask again: would such patches be accepted? (Mike stated he would remove stubs once GCC 4.1 is stable -- thanks -- so users wouldn't run into problems often regardless.) Vanilla, Gentoo patched - they all have bugs which bugzilla have more than enough of in. Ah yes, I see some that definitely apply to USE=vanilla builds. I'll see if there's anything I can understand. :) OK, maybe I was just too dense to see it before, or maybe you kept dancing around the issue. To put it clear (or try at least), your whole issue currently is that you cannot use a 'Vanilla' gcc (ie without the stubs) to build everything in the tree ? No, being able to use vanilla GCC as Gentoo's system compiler would be a nice addition, and if it's agreed as a good idea I don't mind helping out with getting it working, but I can live without it. And not as much the stubs them selfs ? Being able to check software for unofficial compiler flags is for some cases a must. I repeat: two separate issues. They keep getting mixed up here. I think you understood wrongly. If the stubs were to be just removed say tomorrow, and breakage in the tree is still of such an extend that bugs starts to flood in again, its not just you that will have to read the mail. If the user is clueless, then Jakub have to reassign the bug to either toolchain or the package maintainer. If he could not determine it was due to the missing CFLAG, The error is very clear: cc1: error: unrecognized command line option -fno-stack-protector Maybe I have a little bit more confidence in people, sorry if that's misplaced. :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for some CD/DVD-recording applications
Philip Webb wrote: Please keep Xcdroast in Portage: I use it it has no bugs AFAIK. It depends on cdrecord-prodvd, which means that it will have to be converted to use the new cdrtools if it's to continue being useful since cdrecord-prodvd is being masked (and some time thereafter, removed). No recent updates ? -- that applies to many packages in Portage. Not having recent updates is one thing, but with a dead upstream, there is no place to send security patches or bug fixes or add new functionality as needed, etc. (Unless of course, someone were to fork the current codebase and pick up where they left off.) Better tools ? -- please name them give reasons. There is K3b (a Qt app), Graveman (a GTK2 app), NeroLinux (GTK+ 1.x, non-Free), GnomeBaker (GTK2/GNOME) and probably several others which provide the same functionality yet are actively maintained and supported with a proper upstream. My $0.02... -- Peter Gordon (codergeek42) Gentoo Forums Global Moderator GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 signature.asc Description: OpenPGP digital signature
[gentoo-dev] [ALERT] USE flag changes
I'm touching ebuilds that IUSE=tcltk, just like I did with IUSE=qt. tcltk is being broken into tcl and tk USE flags... finally.. it was something that needed to happen ages ago but I'm finally getting around to it. So this is your notice. http://bugs.gentoo.org/show_bug.cgi?id=17808 http://bugs.gentoo.org/show_bug.cgi?id=137785 -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
Harald van Dijk wrote: If the stubs were to be just removed say tomorrow, and breakage in the tree is still of such an extend that bugs starts to flood in again, its not just you that will have to read the mail. If the user is clueless, then Jakub have to reassign the bug to either toolchain or the package maintainer. If he could not determine it was due to the missing CFLAG, The error is very clear: cc1: error: unrecognized command line option -fno-stack-protector Maybe I have a little bit more confidence in people, sorry if that's misplaced. :) Erm, yeah I can recognize the error, but it's really not very productive to dupe the bugs over and over again. Killing the stubs breaks glibc compile [1] and it breaks perl compile [2] as well. [1] http://bugs.gentoo.org/show_bug.cgi?id=101471 [2] http://bugs.gentoo.org/show_bug.cgi?id=106965 I don't really see how is this a good idea to break two pretty critical packages for users that have no clue what USE=vanilla does w/ gcc. -- 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
[gentoo-dev] Last rites for media-gfx/fbi
Hello, I have just added media-gfx/fbi to package.mask and will remove it from the tree in about 30 days. The program is no longer developed upstream in its original form. Instead, it is now a part of the 'fbida' project, which provides a bunch of simple applications for viewing and editing images. fbida is available as media-gfx/fbida. Best regards. -- Michal JanuszewskiGentoo Linux Developer cell: +48504917690 http://people.gentoo.org/spock/ JID: [EMAIL PROTECTED] freenode: #gentoo-dev, #gentoo-pl pgpztSimqYo4Z.pgp Description: PGP signature
[gentoo-dev] Re: Gentoo activity graphs
Marco Matthies [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 08 Jul 2006 14:14:11 +0200: Alin Nastac wrote: Until a year ago, the number of active devs was linearly rising, but in last year we seem to hit a ceil (175) Was it on planet.g.o where i read something about Dunbar's number[1]? A highly interesting subject and it might be possible that the Monkeyspheres of Gentoo devs do not overlap sufficiently. There is only one solution to this problem: You need to go out and get drunk together! ;) [1] http://en.wikipedia.org/wiki/Dunbar%27s_number 'Twas on this list IIRC, perhaps a week ago. An interesting observation was that of all the FLOSS projects, perhaps only Debian had successfully crossed the line from medium to large. It does seem common around here to criticise them for constant politics and being almost stuck, sometimes, but that's one thing they've done that few others have managed. Whatever their problems, they must be doing /something/ that works. That of course leads to the question of when and how they did it. It was before my time in FLOSS I believe, but perhaps something can be learned by going back and examining the Debian history at that time. Did they nudge it for awhile and then something changed and they were suddenly able to expand, or did they cross the 200 developer line as if it wasn't there? If the former, perhaps we can learn from what changed. If the latter, it might be tougher. Then there's the question of whether it's even worth it on the merits. Certainly, it would seem Gentoo has a higher efficiency level, doing with 200 roughly what it takes them 2000 (I believe) to do. Sure, they aren't as limited, but 10 times? Hardly! -- 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
Re: [gentoo-dev] Re: Gentoo activity graphs
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. It does seem common around here to criticise them for constant politics and being almost stuck, sometimes, but that's one thing they've done that few others have managed. Yes but at the same time they have maintainers that often does not know what their work is, and screw things up very bad (unstable and experimental are what they call them, but really a bit of user-caring wouldn't be bad from their part). Examples at hand? Amarok 1.4.0 was added with ruby as suggested dependency that resulted in lots of users in #amarok to ask why lyrics didn't work. Amarok 1.4.1 seems to have been added with the same error, and without the properly patched xine-lib to play flac files (that I tried to advertise as much as I could). So I'm not sure if what they do, their policies and the quizzes and the other stuff they require to join debian work. Most likely they work to discourage people more interested in actual work than bureaucracy. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpBrKSLqpRB4.pgp Description: PGP signature
[gentoo-dev] Re: Portage: missing pieces
Richard Fish writes: Unfortunately the Gentoo dev's have taken the rather unusual step of _breaking the tree_ due to a security problem. Thanks for the info. I would really wish that there was some mechanism in place to make sure that the tree was never broken. The current situation is very annoying for users that update often, and also makes Portage mostly unusable for automatic server upgrades :-(. 1. Unmerge both mono-tools and gecko-sharp. That did the trick. I'll have to remerge it later when/if the tree gets fixed... Thanks! (I see now that it was just me that didn't understand how to use --tree, which makes much of this conversation off-topic... Sorry about that!) [1] http://bugs.gentoo.org/show_bug.cgi?id=137665 I'm thinking that a Subversion pre-commit hook to secure integrity of the Portage tree would be cool. The changes listed in the bug above would have to be committed atomically, or it wouldn't get through the integrity check. Perhaps there could be a staging area in the form of a branch where the hypothetical integrity checker wouldn't run. Ho hum, wishful thinking. -- gentoo-dev@gentoo.org mailing list
