[gentoo-dev] Re: 'mad' vs 'mp3' USE flags
Zac Medico [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 14 Jul 2006 13:24:26 -0700: Per-package use.mask is not here for another year and in the mean time I needed a working solution, this is it. It think we can have it sooner than another year. There are lots of fixes in 2.1.1_pre and I'd like to close the merge window pretty soon so that it can be stabilized. I'll work on a patch for package.use and package.use.mask so that we should be able to have it in a stable 2.1.1 release within a month or two. PMFJI but don't we have to keep compatibility with old versions for a year (well, from my read, I believe the precedent is 10 months) after the change hits stable, or did the discussion I remember reading a bit of decide say 6 months was enough? Even if EAPI is used, previous policy would have put it nearly a year from now, as EAPI was only introduced with 2.1.0, or was it backported? I've seen discussion of both points above, but no definitive policy changes. If I've missed the decisions, others may have as well, so maybe others will find the answers helpful too. -- 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] Dying on some CFLAGS instead of filtering them.
On 7/9/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: Basically, if you're using daft CFLAGS you're on your own. Some ebuilds might filter them, some ebuilds might die and some ebuilds might let them through. Developers are under no obligation to add code to save users from their own stupidity, but they might do so if you ask nicely. Please re-read all the words in the previous messages. What I would like to discuss is not about helping users, but about making our job easier. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
On 7/11/06, Ryan Hill [EMAIL PROTECTED] wrote: Their phrase, not mine. ;) I think the idea is you should be able to emerge -e world and walk away and not have anything interrupt the process thus requiring the user interact with the system. Well yes, but an ebuild that dies, whatever the reason, hasn't much to do with interactivity. If a package is known not to work with a certain flag, being able to emerge it won't change the fact that it doesn't run. If a package is known to not work with a certain flag it should be filtered so it does run. What will follow isn't only for you. You guys are focusing on the die/filter alternative. Maybe you haven't noticed but I have never stated that I'd prefer ebuilds to die or filter. What I wanted to discuss is can't we do something globally to avoid these bugs coming in, so that we can focus on something else. I don't care yet if it's filtering or dying. And never did I talk about educating the masses. Do you mean for ebuilds that knowingly break with -ftracer, or for everything? There are packages that expect to be built with certain flags; not -ftracer, but others. Fex, libao needs -ffast-math ;). Also, what about ebuilds that do use -fprofile, like gcc itself? I know toolchain.eclass strips all flags, I'm just using it as an example. I explained I was talking about a global system, with a possibility for ebuilds/users that wanted/needed it to opt out. It's much easier to unblock --fast-math for libao than going through idontknowhowmany bugs about the same number of packages that break with --fast-math, for example. If you mean just for packages that break with certain flags then absolutely. But such a mechanism would have to be maintained for every different GCC version, since -fprofile might not invoke -ftracer in every version, and indeed some versions might not even recognize -fno-tracer and bail with an error. Let's count together the number of GCC versions we should really care about. 3.4, 4.1, any others ? Mad props to the bug-wranglers, but I don't think it'll be a cakewalk to automate this in any sane way. Automate what ? Right, but how are people supposed to learn something is dangerous if all the sharp edges have been filed off? And how can you decide which flags are bad and good on a global level when for the most part compiler parameters are akin to black magic? Since when is being a learning tool one of the goals of Gentoo ? Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On Sat, 15 Jul 2006 13:54:52 +0200 Denis Dupeyron [EMAIL PROTECTED] wrote: | On 7/9/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: | Basically, if you're using daft CFLAGS you're on your own. Some | ebuilds might filter them, some ebuilds might die and some ebuilds | might let them through. Developers are under no obligation to add | code to save users from their own stupidity, but they might do so | if you ask nicely. | | Please re-read all the words in the previous messages. What I would | like to discuss is not about helping users, but about making our job | easier. If you want your job to be easier, just INVALID any bug that comes in with daft CFLAGS... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: 'mad' vs 'mp3' USE flags
Duncan wrote: Zac Medico [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 14 Jul 2006 13:24:26 -0700: Per-package use.mask is not here for another year and in the mean time I needed a working solution, this is it. It think we can have it sooner than another year. There are lots of fixes in 2.1.1_pre and I'd like to close the merge window pretty soon so that it can be stabilized. I'll work on a patch for package.use and package.use.mask so that we should be able to have it in a stable 2.1.1 release within a month or two. PMFJI but don't we have to keep compatibility with old versions for a year (well, from my read, I believe the precedent is 10 months) after the change hits stable, or did the discussion I remember reading a bit of decide say 6 months was enough? Even if EAPI is used, previous policy would have put it nearly a year from now, as EAPI was only introduced with 2.1.0, or was it backported? I've seen discussion of both points above, but no definitive policy changes. If I've missed the decisions, others may have as well, so maybe others will find the answers helpful too. EAPI support was in for the 2.0.X version of portage, released on Dec. 1st 2005. Generally we wait 6 months (one release cycle) for new features. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
Denis Dupeyron wrote: Well yes, but an ebuild that dies, whatever the reason, hasn't much to do with interactivity. Fine. Call it the don't-kill-the-emerge-for-silly-reasons philosophy if you like. I personally don't prefer it, but a lot of people think it's a good idea. What will follow isn't only for you. You guys are focusing on the die/filter alternative. Maybe you haven't noticed but I have never stated that I'd prefer ebuilds to die or filter. What I wanted to discuss is can't we do something globally to avoid these bugs coming in, so that we can focus on something else. I don't care yet if it's filtering or dying. And never did I talk about educating the masses. Well, your first two questions asked whether ebuilds should die rather than filter, and what other flags ebuilds should die on, so go figure that we're talking about filtering and dying. :o Is there a way to do this globally across X architectures and Y GCC versions with Z number of flags across 11191 packages? That's not even taking into account multiple flags and their influence on each other. Trying to find and filter every combination of the above is like trying to make a list of every single thing on earth you shouldn't stick up your nose. It doesn't work that way. You just say hey, don't stick things up your nose. if you do, you live with the consequences. Once in a while someone decides not to listen and does something stupid. We all laugh at them, and go about our day. I explained I was talking about a global system, with a possibility for ebuilds/users that wanted/needed it to opt out. It's much easier to unblock --fast-math for libao than going through idontknowhowmany bugs about the same number of packages that break with --fast-math, for example. You're missing my point. Flags that are harmful to some codebases are beneficial or even essential to others. This is my question to you: tell me how you're going decide what options are going to be blacklisted when all of them have a specific purpose and use, however corner-case that use could be. There are no bad and good flags. There are broken flags, of course. Every GCC release we get to guess which ones don't work right any more. ;) What it sounds like you're interested in is a whitelist. We already have strip-flags (see setup-allowed-flags in flag-o-matic.eclass). Turning that on globally however would incite rioting. I suppose a way to match flag and GCC version number against a list of known broken flags (ie. _not_ flags that can break things, but flags that are broken themselves. note the difference.) wouldn't be too bad. It's generally known that, say, -frename-registers is broken in 4.0 or -fnew-ra in 3.x just doesn't work. The number wouldn't be too high. Still, I don't know if it would be worth it. It's still much easier just to fix breakage if it happens, and INVALID anyone who files ricer bugs. Let's count together the number of GCC versions we should really care about. 3.4, 4.1, any others ? 2.95.3, 3.1.1, 3.2.2, 3.2.3, 3.3.2, 3.3.5, 3.3.6, 3.4.1, 3.4.4, 3.4.5, 3.4.6, 4.0.2, 4.1.0, 4.1.1, 4.2, 4.3, 4.x, 5.x, and etc. You wouldn't propose a short-term solution that doesn't include all compilers supported by Gentoo, would you? ;) Yes, minor bumps have changed flag behaviour in the past. Mad props to the bug-wranglers, but I don't think it'll be a cakewalk to automate this in any sane way. Automate what ? Whatever this vague global mechanism you're talking about that's supposed to end CFLAG bugs, save us so much time, and prevent users from ever doing stupid things. I mean, if it wasn't automagickal, how would it be any different than what we're doing now? Since when is being a learning tool one of the goals of Gentoo ? ... I can't reply to this without being rude, so I'll leave it alone. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Making procfs mount as nosuid,noexec by default
Hi, The local root exploit-of-the-week would have been unable to run if our users systems had /proc mounted with nosuid and/or noexec It would be worthwhile considering making this a default. What are people's thoughts? Additional testing of this change would be appreciated (just ensure that nothing breaks). To do it as a one off: # mount -o remount,nosuid,noexec /proc To make it more permanent, /etc/fstab has: proc/proc procdefaults0 0 Change to: proc/proc procnosuid,noexec 0 0 Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Hiatus
Hi all, As some of you already know, I will be taking a hiatus from Gentoo starting this weekend. While I am gone, the mobile herd is pretty much left without active developers. Uberlord and phreak have already adopted some of the more critical ebuilds, but quite a few are still orphaned as seen in this report from 'herdstat -dp brix': Developer: Henrik Brix Andersen (brix) Email: [EMAIL PROTECTED] Packages(31):app-doc/gimp-help app-laptop/ibam app-laptop/laptop-mode-tools app-laptop/radeontool app-laptop/tp_smapi dev-embedded/avr-libc dev-embedded/avrdude dev-tex/dk-bib dev-tex/memoir media-gfx/gimp net-misc/radvd net-wireless/gkismet net-wireless/hostap-driver net-wireless/hostap-utils net-wireless/hostapd net-wireless/ipw3945-ucode net-wireless/irda-utils net-wireless/madwifi-ng net-wireless/madwifi-ng-tools net-wireless/madwifi-old net-wireless/madwifi-old-tools net-wireless/ussp-push net-wireless/wispy-tools sys-apps/pcmcia-cs sys-apps/pcmcia-cs-cis sys-apps/pcmcia-cs-modules sys-apps/pcmcia-cs-pnptools sys-apps/pcmciautils sys-kernel/linux-docs x11-misc/gromit x11-plugins/gkrellm-wifi Hopefully someone will step up and adopt the remaining ebuilds. I will, of course, be available for answering questions about these ebuilds through e-mail and IRC. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] FreeBSD since 6.1-RELEASE pgp96cWJbL6PK.pgp Description: PGP signature
[gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
Ryan Hill wrote: 2.95.3, 3.1.1, 3.2.2, 3.2.3, 3.3.2, 3.3.5, 3.3.6, 3.4.1, 3.4.4, 3.4.5, 3.4.6, My bad, 3.2.2 is masked for everyone ATM. --de. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making procfs mount as nosuid,noexec by default
On Sat, 2006-07-15 at 13:41 -0400, Ned Ludd wrote: On Sat, 2006-07-15 at 17:45 +0100, Daniel Drake wrote: Hi, The local root exploit-of-the-week would have been unable to run if our users systems had /proc mounted with nosuid and/or noexec It would be worthwhile considering making this a default. What are people's thoughts? I mailed Mike about this very thing a month ago. Pretty sure it should be showing up in an upcoming baselayout. But yeah it's a good idea for the nosuid part anyway. Not 100% sure about the noexec part as that might break upx which calls /proc/self/exe as part of it's decompresser routines. Tested it using a and it seems safe across the board. upx,busybox and other multicall binaries seem quite content. Linus also recently suggested that the same be done in the kernel directly via the proc_fill_super() function. This seems like an ideal route to go for us as it would get inherited by all the existing users who wont notice the change in the default fstab file. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making procfs mount as nosuid,noexec by default
On Saturday 15 July 2006 13:41, Ned Ludd wrote: On Sat, 2006-07-15 at 17:45 +0100, Daniel Drake wrote: The local root exploit-of-the-week would have been unable to run if our users systems had /proc mounted with nosuid and/or noexec It would be worthwhile considering making this a default. What are people's thoughts? I mailed Mike about this very thing a month ago. Pretty sure it should be showing up in an upcoming baselayout. But yeah it's a good idea for the nosuid part anyway. Not 100% sure about the noexec part as that might break upx which calls /proc/self/exe as part of it's decompresser routines. this will be in baselayout-1.12.2+ -mike pgpmAsZg73PIb.pgp Description: PGP signature
Re: [gentoo-dev] Making procfs mount as nosuid,noexec by default
Daniel Drake wrote: Hi, The local root exploit-of-the-week would have been unable to run if our users systems had /proc mounted with nosuid and/or noexec It would be worthwhile considering making this a default. What are people's thoughts? Additional testing of this change would be appreciated (just ensure that nothing breaks). To do it as a one off: # mount -o remount,nosuid,noexec /proc To make it more permanent, /etc/fstab has: proc/procprocdefaults0 0 Change to: proc/procprocnosuid,noexec0 0 Thanks, Daniel Daniel, Turns out that yesterday after we talked about this. I've been running one of my boxes like that for ages. So far so good. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On Tue, Jul 11, 2006 at 06:07:11PM +0200, Wernfried Haas wrote: On Tue, Jul 11, 2006 at 12:50:12PM +0200, Jose Luis Rivero (YosWinK) wrote: I would like to nominate kloeri (Bryan Østergaard) to the council if he has enough free time and if his devrel lead position (where his work is priceless) doesn't block the nomination. Damn, i wanted to do that for a few days already and now you beat me to it. ;-) cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org I'll be happy to accept the nomination, noting that I can't participate in any kind of appeals board if any devrel decision is ever appealed to the council. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Hiatus
On Sat, Jul 15, 2006 at 08:25:45PM +0200, Henrik Brix Andersen wrote: net-wireless/wispy-tools I'll take this one, since I have the hardware. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpNO3jx1zHQD.pgp Description: PGP signature
Re: [gentoo-dev] Future developer
On 30/06/06, Paul de Vrieze [EMAIL PROTECTED] wrote: I'm proud to announce the arival of a future developer. His name is Tom. He arived last monday on 10:22 am (UTC+02). I and my wife will take care of mentoring him to full developership ;-). In the meantime, he's got his own album on http://www.cs.ru.nl/~pauldv/tom/ Paul ps. If I'm a bit away these days, it is due to me being preoccupied with my mentoring task. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net I forgot to say that you could call your daughter Jennifer because you could name her Jen two. George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 'mad' vs 'mp3' USE flags
On Friday 14 July 2006 11:09, Diego 'Flameeyes' Pettenò wrote: On Friday 14 July 2006 16:43, Chris Gianelloni wrote: While it is a working solution, it isn't necessarily a sensible one. You can take over xine-lib and fix it however you prefer. As this, as well as any other idea you can find, is just an HACK until portage devs implements the per-package use.mask that i asked WAY before 2.1 release, but was then left OUT of the freeze and thus of the featureset we can use 6 months from now, I REFUSE to change the behaviour. /me humps angry over worked flameeyes -mike pgp8xnHpdzbVK.pgp Description: PGP signature
Re: [gentoo-dev] arch-cruft in use.mask makes me angry
On Tuesday 04 July 2006 21:54, Mike Frysinger wrote: can someone remind me why our arch USE flags are in an opt-out system rather than opt-in ? patch attached ... no complaints, i'll merge it in a day or two :p -mike pgpkf9VkbsyOW.pgp Description: PGP signature cleanup-arch-use-mask.patch.bz2 Description: BZip2 compressed data
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Saturday 08 July 2006 11:58, Ciaran McCreesh wrote: On Sat, 8 Jul 2006 11:50:47 -0400 Mike Frysinger [EMAIL PROTECTED] | 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. hmm, fair enough -mike pgp7wu6ebOq04.pgp Description: PGP signature
Re: [gentoo-dev] Future developer
George Prowse wrote: I forgot to say that you could call your daughter Jennifer because you could name her Jen two. George ...and a rimshot is heard fading in the distance. Congrats, Paul! ^_^ -- 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
