[gentoo-dev] Re: Resignation
Tach Tim, 0x2B859DE3 (PGP-PK-ID) Tim Yamin schrieb: > So long, and thanks for all the fish... Even I hope you rethink it... V-Li -- Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3 http://www.gnupg.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] CFLAGS paragraph submission for the GWN
On 10/8/06, Lionel Bouton <[EMAIL PROTECTED]> wrote: Here's a draft of a paragraph discussing CFLAGS-related problems. This is the result of a discussion I started on gentoo-dev. Thanks to all devs who gave feedback this should bring some food for thought to GWN readers. Hi Lionel, Thanks for writing this up, great job. Nitpicking spelling and grammar points to follow ;) configurability that are hallmarks of the http://www.gentoo.org/main/en/about.xml> Gentoo experience. Extra space before "Gentoo" here. for most users. There's usually very little benefit, high risks and much time spent on frustating tuning that could be enjoyed doing far more interesting things. "frustating" should be "frustrating" Example of this are : Should be plural: "Examples" -fforce-addr and -fweb break regularly on x86 with video libraries or graphic processing apps which use hand-optimised ASM. -fweb may be safe on amd64 but like above no guarantees "optimised" should be "optimized" For example -ffast-math is added by the xmame/xmess ebuilds on most architectures even tho you SHOULD NOT put it in your CFLAGS. "tho" should be "though" -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] CFLAGS paragraph submission for the GWN
Here's a draft of a paragraph discussing CFLAGS-related problems. This is the result of a discussion I started on gentoo-dev. Thanks to all devs who gave feedback this should bring some food for thought to GWN readers. --- Draft BEGIN --- CFLAGS Being able to tune CFLAGS is part of the user control and extreme configurability that are hallmarks of the http://www.gentoo.org/main/en/about.xml> Gentoo experience. Being in control brings both benefits and problems. CFLAGS tuning is not an exception. We would like to remind you that using anything beyond -O2 -fomit-frame-pointer -march/-mcpu/-mtune in CFLAGS or CXXFLAGS (and -mieee, -mabi etc. on selected archs that tell you to do this), and using anything at all in LDFLAGS or ASFLAGS, is usually not worth it for most users. There's usually very little benefit, high risks and much time spent on frustating tuning that could be enjoyed doing far more interesting things. The recent upgrade to gcc-4.1.1 for x86 and amd64 users changed the CFLAGS landscape. Users that spent some time tuning their CFLAGS with gcc-3.4.6 might find out that an upgrade to gcc-4.1.1 leaves them with an unstable system. Example of this are : nss_ldap stopped working with -ffast-math (-ffast-math is often misused and must be considered a dangerous flag) -fvisibility-inlines-hidden still breaks some code -ftree-loop-linear now breaks in gcc-4.1 (at least with mesa) -ftree-vectorize is known to be broken in gcc-4.1 (at least for x86 and ppc, there are fewer problems reported by amd64 users but no guarantees) -fforce-addr and -fweb break regularly on x86 with video libraries or graphic processing apps which use hand-optimised ASM. -fweb may be safe on amd64 but like above no guarantees There are known-to-be-broken flags for all GCC versions that you want to check for too: -fvisibility=hidden -frename-registers (may be safe on amd64, at your own risks) -ftracer -D_FILE_OFFSET_BITS=64 -msse -mmmx -m3dnow (no need for them on amd64, there are wrapped up by -march=k8/nocona/... and safely used there) -W -mfpmath=sse,387 -malign-double Users with unsupported CFLAGS might want to return to safe CFLAGS (see warning above) if recent updates caused them stability problems. On the other hand, more adventurous users might want to experiment with CFLAGS that didn't work properly with gcc-3.4.6... As always, the user is in control (and the gun pointed to their feet is in his/her hand). Final notes: The gcc man page contains warnings for some unsafe optimization options. You should read it carefully when you experiment with CFLAGS or upgrade GCC on a CFLAGS-customized Gentoo. Some options that are unsafe in the system-wide CFLAGS might be added automatically in some ebuilds if the developper deems them safe (by redefining CFLAGS or using append-flags of the flag-o-matic eclass). For example -ffast-math is added by the xmame/xmess ebuilds on most architectures even tho you SHOULD NOT put it in your CFLAGS. You might get an idea of the stability issues of a specific optimization option by running: find /usr/portage -name '*.ebuild'| xargs grep -- '-'. It takes quite some time, but might be enlightening: look for the 'filter-flags'. --- Draft END --- Lionel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Jeffrey Gardner (je_fro)
On Friday, 6 October 2006 14:57, Petteri Räty wrote: > It's my pleasure to introduce to you Jeffrey "je_fro" Gardner, the > latest addition joining to help out with the scientific packages. Another biochemist joins the team! Welcome, Jeffrey. Cheers, -- Olivier Fisette (ribosome) Gentoo Linux Developer Scientific applications, Developer relations pgpCBW706Qk52.pgp Description: PGP signature
Re: [gentoo-dev] New Developer: Timothy Redaelli (drizzt)
Petteri Räty wrote: > It's my pleasure to introduce to you Timothy "drizzt" Redaelli, the > latest addition joining to help out with the Gentoo/FreeBSD effort. I have to say, good taste in books. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
Danny van Dyk wrote: I for one favour a more flattened profiles/ and a way to mark a profile as 'not standalone', similar to a deprecated file, that isn't inherited, to stop users biting their own asses. The following sample is not complete, but should give the right impressions. By 'not standalone', I assume you mean "this profile does not work by itself, and is only meant to be inherited by other profiles". If that's not what you meant, we also need something that does that :) profiles +-obsolete, which contains the "old cascaded profiles". Let's remove | the current obsolete/ contents. Doing this will break portage for people who are using "old cascaded profiles". Portage would freak out if there wasn't a profile where there was one before, and there wouldn't be a way to do a 'deprecated' file to tell them about the new ones. +-default-linux, minimal default useflags here | | | +-linux-2.4, would be handy for x86 :-) amd64 has no supported 2.4 | kernel. | +-hardened, minimal default useflags here | +-default-bsd, minimal default useflags here | | | +fbsd, inherits default-bsd/ | +-base | | | +amd64, inherits base/ | +-releases | +-2006.1, does not inherit anything, stuff like "nptl nptlonly" here | +-amd64-linux, inherits default-linux/, base/amd64; "standalone" | +-amd64-hardened, inherits hardened, base/amd64; "standalone" | +-amd64-fbsd, inherits default-bsd/fbsd/, base/amd64; "standalone" This is a hot shot and I'm waiting for comments. Wolf? Agaffney? I can't really comment on the structure, since I don't really do much with profiles myself (no gentoo-x86 commit access). I'm prepared to do the work here and, as this new layout would take some time, it should be done in a seperate repository for the time being. Not necessary. It can just be a separate directory tree under profiles/ much like default-linux/ was created for cascaded profiles originally, and they can all be marked as deprecated or something. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: "Go asphyxiate on a phallus" -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resignation
Donnie Berkholz wrote: Tim Yamin wrote: Lately however, the "fun" and the motivation just hasn't been there for the reasons I've outlined above; it's finally taken its toll, and I believe the time to move onto new projects and ventures has finally come for me. I would like to wish all of you the very best, and would like to thank all of you who have (and haven't) made my time here so enjoyable. Tim, Thanks for all of the hard work you've put into Gentoo. I know it isn't always appreciated, so I want to make sure you know how valuable you've been. I couldn't have said it better myself. Good luck with everything. Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Alon Bar-Lev (alonbl)
Christian Heim wrote: Its my pleasure to introduce to you Alon "alonbl" Bar-Lev, the latest addition joining to help out with the crypto herd. He hails from Israel (hrm, they don't have cities down there ?). So far it looks like Alon is completely constrained to his computer, he doesn't have any other hobbies nor life. Oh, great, I'm not alone here anymore :) Welcome! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resignation
Tim Yamin wrote: > So long, and thanks for all the fish... Tim, I'm very sad to see you leave Gentoo. All the best for your future endeavors and do keep in touch. Regards, -- Shyam Mani | <[EMAIL PROTECTED]> docs-team | http://gdp.gentoo.org devrel | http://devrel.gentoo.org GPG Key| 0xFDD0E345 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
Hi Danny, On 10/8/06, Danny van Dyk <[EMAIL PROTECTED]> wrote: I for one favour a more flattened profiles/ and a way to mark a profile as 'not standalone', similar to a deprecated file, that isn't inherited, to stop users biting their own asses. The following sample is not complete, but should give the right impressions. The Seeds project could do something like this: +-Seeds | +-amd64-lamp, inherits releases/2006.1/amd64-hardened and adds lamp specific useflags/packages. But i lack knowledge here. Stuart? I think Seeds could work with a structure like that. Best regards, Stu -- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Jeffrey Gardner (je_fro)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 6 Oct 2006, Petteri Räty wrote: It's my pleasure to introduce to you Jeffrey "je_fro" Gardner, the latest addition joining to help out with the scientific packages. Welcome Jeffrey, and happy sci-bug-fixing ;) cheers, Markus - -- Markus Dittrich (markusle) Gentoo Linux Developer Scientific applications -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFKQirxlRwCwb7k40RAo0fAJ9P4V++9YZnIa25ErMu5bl8bAWGqwCfasQH 9C8MWcwFXNSImUxid5D3eFI= =81E9 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
Am Sonntag, 8. Oktober 2006 12:05 schrieb Stuart Herbert: > Hi Zac, > > On 10/8/06, Zac Medico <[EMAIL PROTECTED]> wrote: > > I'm only proposing that we add support to portage now because it > > seems like it will be useful in the future. How and when people > > make use of this support does not concern me much. > > > > Zac > > I believe that multiple parent support would be useful for the Seeds > project; it would allow the LAMP Developer Desktop (for example) to > inherit from both the generic 2006.1/x86 profile and the LAMP Server > profile. Well, once we have that support the structure of profiles will radically change. The following is also something I'd like to be done while i'm in council. This is why i asked Zac to send the RFC to gentoo-dev. Thanks Zac :-) I for one favour a more flattened profiles/ and a way to mark a profile as 'not standalone', similar to a deprecated file, that isn't inherited, to stop users biting their own asses. The following sample is not complete, but should give the right impressions. profiles +-obsolete, which contains the "old cascaded profiles". Let's remove | the current obsolete/ contents. | +-default-linux, minimal default useflags here | | | +-linux-2.4, would be handy for x86 :-) amd64 has no supported 2.4 | kernel. | +-hardened, minimal default useflags here | +-default-bsd, minimal default useflags here | | | +fbsd, inherits default-bsd/ | +-base | | | +amd64, inherits base/ | +-releases | +-2006.1, does not inherit anything, stuff like "nptl nptlonly" here | +-amd64-linux, inherits default-linux/, base/amd64; "standalone" | +-amd64-hardened, inherits hardened, base/amd64; "standalone" | +-amd64-fbsd, inherits default-bsd/fbsd/, base/amd64; "standalone" This is a hot shot and I'm waiting for comments. Wolf? Agaffney? I'm prepared to do the work here and, as this new layout would take some time, it should be done in a seperate repository for the time being. The Seeds project could do something like this: +-Seeds | +-amd64-lamp, inherits releases/2006.1/amd64-hardened and adds lamp specific useflags/packages. But i lack knowledge here. Stuart? Danny -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New Developer: Timothy Redaelli (drizzt)
It's my pleasure to introduce to you Timothy "drizzt" Redaelli, the latest addition joining to help out with the Gentoo/FreeBSD effort. He hails from Milan, Italy. He currently works as an embedded programmer using ASM/C. It probably doesn't come as a surprise to anyone that he was mentored by Flameeyes and is the latest addition to his minions. Timothy is skilled in system work, setting up and securing servers. He is a staff member of GUFI (Gruppo Utenti FreeBSD Italia) and FreeSBIE (FreeBSD LiveCD) and he maintains some packages of FreeBSD. So please welcome drizzt and give him the usual warm welcome. -- Petteri Räty (betelgeuse) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Leave of Absence
On Sun, Oct 08, 2006 at 12:33:30AM -0400, Alec Warner wrote: > I killed my dev box somehow and due to recent meandering thoughts in my > head I've decided not to buy replacement parts. This in turn affects my > ability to do Gentoo work; so I have decided to take a leave of absence. > It's kind of been in my mind for while. > > Treecleaners, I will talk to you a bit about some thoughts I had. > > Devrel, this is your notice of my leave greater than 60 days. > > I will be reading e-mail, but prolly won't be present on IRC often. > > I'm hoping to finish strong in my last semester at school, the choices > for post-graduation are looking like a full time job or JET; if the > latter I will probably resign at that point since I know I won't have > time to contribute much here anymore. > Thanks for the notice, I hope to see you around from time to time. And good luck with graduation and post-graduation. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resignation
Seeing you go under these circumstances really worries me. Perhaps you want to reconsider it - if not: All the best! 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 pgpIebpqWuMLk.pgp Description: PGP signature
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
Hi Zac, On 10/8/06, Zac Medico <[EMAIL PROTECTED]> wrote: I'm only proposing that we add support to portage now because it seems like it will be useful in the future. How and when people make use of this support does not concern me much. Zac I believe that multiple parent support would be useful for the Seeds project; it would allow the LAMP Developer Desktop (for example) to inherit from both the generic 2006.1/x86 profile and the LAMP Server profile. I'm not saying we'd definitely end up going that way, but it would be something worth testing when the time comes. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
On Saturday 07 October 2006 23:04, Zac Medico wrote: > Should we add multiple inheritance support now? yes -mike pgpJagfj7FpY3.pgp Description: PGP signature
