[gentoo-dev] Proposal: disable python and perl USE flags in profile
Following advise from https://bugs.gentoo.org/show_bug.cgi?id=250179, I'm bringing it here. -- regards MM -- Wygraj telefon komorkowy! Sprawdz http://link.interia.pl/f1fc0
Re: [gentoo-dev] app-admin/eselect needs YOUR help
On 14:46 Sun 07 Dec , Ciaran McCreesh wrote: On Sat, 6 Dec 2008 23:44:40 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: I hadn't heard of it before, thanks for the ref. What was the reason for forking the codebase? It gets pretty annoying to copy across useful changes, especially while eselect is stuck in svn. Ease of getting things done. Going through Gentoo requires finding a Gentoo maintainer, endless bikeshed arguments about how to implement things like the new alternatives framework and then months of waiting for approval. Open and public debate about the right way to do things does take longer, and it's something you certainly participate in quite frequently so I'm surprised to hear you badmouth it when it comes to your own ideas. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgphLRVTIHiGS.pgp Description: PGP signature
Re: [gentoo-dev] app-admin/eselect needs YOUR help
On Monday, 08. December 2008 17:37:42 Donnie Berkholz wrote: Open and public debate about the right way to do things does take longer, and it's something you certainly participate in quite frequently so I'm surprised to hear you badmouth it when it comes to your own ideas. It's not about Ciaran's (or anyone's ideas). We openly and publicly discuss such things in Exherbo, too. Not endlessly, though, but we get to an actual decision in a much shorter timeframe. Of course, Ciaran plays along the Gentoo way of either discussing things till a) people are sufficiently annoyed about the length of the thread to stop reading it at all (the normal procedure), b) the council decides to postpone the decision to the next meeting during which it gets postponed to the next meeting (and so on) or c) it's being decided that it's not needed (only to discover half a year later that an issue has to be worked around again because the real solution was treated in the way of a) or b)). :-) So this is not badmouthing but dealing with the facts of Gentoo. Best regards, Wulf signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] app-admin/eselect needs YOUR help
(I'm replying to Ciaran's email, but my reply is for Donnie too) El lun, 08-12-2008 a las 17:44 +, Ciaran McCreesh escribió: On Mon, 8 Dec 2008 08:37:42 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: Open and public debate about the right way to do things does take longer, and it's something you certainly participate in quite frequently so I'm surprised to hear you badmouth it when it comes to your own ideas. Open and public debate requires two or more well informed parties who are seeking to reach the best solution regardless of who proposed it, and a deciding body who are prepared to go for the best solution even if it isn't universally popular. This sometimes happens with Gentoo, but unfortunately all too often it's one of these instead: [long rant] It's simpler. An alternatives framework was discussed openly and publicly through @exherbo-dev. Discussing Exherbo development through @gentoo-dev is impractical for both Gentoo and Exherbo. Now, some Exherbo devs came up with an eselect fork, and Ciaran pointed out in this thread that it could be useful for people looking for improving eselect. Anything else is irrelevant here. Regards, -- Santiago Moisés Mola Jabber: [EMAIL PROTECTED] | GPG: AAD203B5 signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] app-admin/eselect needs YOUR help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 8 Dec 2008 17:44:34 + Ciaran McCreesh [EMAIL PROTECTED] wrote: None of the people involved in the decision to fork eselect rather than work on it for Gentoo are anything except entirely in favour of open and public debate. It's just that they don't exactly have a positive experience of that happening within Gentoo... so if that's your opinion about how debates are handled inside gentoo, why did you post it on a gentoo mailing list? - -- nikos roussos pgp: 1AFCC7D3 [ http://autoverse.net/ ] -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk9Z3AACgkQJx/21xr8x9NavgCfdZ/Avj3W0JenLplbR5tKIVvn HPIAoNwTTDgUXfwTZsQpSzhTaJg1uVXb =9AfJ -END PGP SIGNATURE-
Re: [gentoo-dev] app-admin/eselect needs YOUR help
On Mon, 8 Dec 2008 20:28:58 +0200 nikos roussos [EMAIL PROTECTED] wrote: On Mon, 8 Dec 2008 17:44:34 + Ciaran McCreesh [EMAIL PROTECTED] wrote: None of the people involved in the decision to fork eselect rather than work on it for Gentoo are anything except entirely in favour of open and public debate. It's just that they don't exactly have a positive experience of that happening within Gentoo... so if that's your opinion about how debates are handled inside gentoo, why did you post it on a gentoo mailing list? Because I don't think Gentoo is a lost cause. A lot of Gentoo's problems are fixable. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] app-admin/eselect needs YOUR help
On Mon, Dec 8, 2008 at 6:44 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 8 Dec 2008 08:37:42 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: Open and public debate about the right way to do things does take longer, and it's something you certainly participate in quite frequently so I'm surprised to hear you badmouth it when it comes to your own ideas. Open and public debate requires two or more well informed parties who are seeking to reach the best solution regardless of who proposed it, and a deciding body who are prepared to go for the best solution even if it isn't universally popular. This sometimes happens with Gentoo, but unfortunately all too often it's one of these instead: * A good proposal gets a few incorrect objections from people who don't understand it and aren't prepared to put in the effort to become well informed. The Council then uses these objections as an excuse to sit on the proposal and do nothing for months, because making a decision is harder than maintaining the status quo. * A good proposal gets a whole load of silly, trivial and nonsensical objections from sockpuppeting trolls who don't like the people who came up with the proposal (or sometimes from sockpuppeting trolls who suspect that the person who came up with the proposal once spoke to the cousin of a cleaner who once worked for the nephew of someone who said that the proposal looked sensible...). The Council do not dismiss these objections because they don't want to risk upsetting anyone. * A good proposal comes along. Its proof of concept implementation is done using a project that is considered by some to risk upsetting the status quo. A bunch of people who are involved in the proposal get fired. * A proposal gets implemented without the debate. It's either a lousy proposal that we're then stuck with, or a decent proposal that has a few flaws that could have been addressed. This is the kind of 'open and public debate' one would expect from a failing government trying to cling to power for a few more years or a middle-management-heavy corporation on its last legs. It's fine if you want to repaint the bikeshed a slightly nicer shade of magenta, but it's a real nuisance for anything serious. None of the people involved in the decision to fork eselect rather than work on it for Gentoo are anything except entirely in favour of open and public debate. It's just that they don't exactly have a positive experience of that happening within Gentoo... -- Ciaran McCreesh Reminds me so much of http://tieguy.org/blog/2008/12/05/the-linux-desktops-change-problem/
Re: [gentoo-dev] app-admin/eselect needs YOUR help
On Mon, Dec 8, 2008 at 9:49 AM, Wulf C. Krueger [EMAIL PROTECTED] wrote: On Monday, 08. December 2008 17:37:42 Donnie Berkholz wrote: Open and public debate about the right way to do things does take longer, and it's something you certainly participate in quite frequently so I'm surprised to hear you badmouth it when it comes to your own ideas. It's not about Ciaran's (or anyone's ideas). We openly and publicly discuss such things in Exherbo, too. Not endlessly, though, but we get to an actual decision in a much shorter timeframe. Of course, Ciaran plays along the Gentoo way of either discussing things till a) people are sufficiently annoyed about the length of the thread to stop reading it at all (the normal procedure), b) the council decides to postpone the decision to the next meeting during which it gets postponed to the next meeting (and so on) or c) it's being decided that it's not needed (only to discover half a year later that an issue has to be worked around again because the real solution was treated in the way of a) or b)). :-) So this is not badmouthing but dealing with the facts of Gentoo. s/Gentoo/Any 'large' organization with little or no management/ it turns out this is a problem in a number of other organizations; hopefully Gentoo will get better at addressing them. -Alec Best regards, Wulf
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libIDL: libIDL-0.8.10.ebuild
On Sun, Dec 7, 2008 at 4:50 PM, Mart Raudsepp [EMAIL PROTECTED] wrote: On P, 2008-12-07 at 12:07 +, Mike Frysinger (vapier) wrote: vapier 08/12/07 12:07:53 Modified: libIDL-0.8.10.ebuild ChangeLog entires are mandatory without any exceptions for stabilizations. Don't touch packages I co-maintain without a ChangeLog entry if it's not a whitespace change. etc for any other packages I'll skip replies on this time. Please get the idea. also mandatory for p.g.o, just modify your wrapper to call echangelog $commitmsg, can't take you more than a minute (your arm and sh machines have perl installed right?). -Alec Log: arm/sh stable (Portage version: 2.2_rc17/cvs/Linux 2.6.27.8 x86_64) Revision ChangesPath 1.9 dev-libs/libIDL/libIDL-0.8.10.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/libIDL/libIDL-0.8.10.ebuild?rev=1.9view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/libIDL/libIDL-0.8.10.ebuild?rev=1.9content-type=text/plain diff : http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/libIDL/libIDL-0.8.10.ebuild?r1=1.8r2=1.9 Index: libIDL-0.8.10.ebuild === RCS file: /var/cvsroot/gentoo-x86/dev-libs/libIDL/libIDL-0.8.10.ebuild,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- libIDL-0.8.10.ebuild 22 Mar 2008 03:57:44 - 1.8 +++ libIDL-0.8.10.ebuild 7 Dec 2008 12:07:53 - 1.9 @@ -1,6 +1,6 @@ # Copyright 1999-2008 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/dev-libs/libIDL/libIDL-0.8.10.ebuild,v 1.8 2008/03/22 03:57:44 dang Exp $ +# $Header: /var/cvsroot/gentoo-x86/dev-libs/libIDL/libIDL-0.8.10.ebuild,v 1.9 2008/12/07 12:07:53 vapier Exp $ inherit eutils gnome2 @@ -9,7 +9,7 @@ LICENSE=LGPL-2 SLOT=0 -KEYWORDS=alpha amd64 ~arm hppa ia64 ~mips ppc ppc64 ~sh sparc x86 ~x86-fbsd +KEYWORDS=alpha amd64 arm hppa ia64 ~mips ppc ppc64 sh sparc x86 ~x86-fbsd IUSE= RDEPEND==dev-libs/glib-2.4 -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio
Re: [gentoo-dev] app-admin/eselect needs YOUR help
On Mon, 2008-12-08 at 12:56 -0800, Alec Warner wrote: On Mon, Dec 8, 2008 at 9:49 AM, Wulf C. Krueger [EMAIL PROTECTED] wrote: On Monday, 08. December 2008 17:37:42 Donnie Berkholz wrote: Open and public debate about the right way to do things does take longer, and it's something you certainly participate in quite frequently so I'm surprised to hear you badmouth it when it comes to your own ideas. It's not about Ciaran's (or anyone's ideas). We openly and publicly discuss such things in Exherbo, too. Not endlessly, though, but we get to an actual decision in a much shorter timeframe. Of course, Ciaran plays along the Gentoo way of either discussing things till a) people are sufficiently annoyed about the length of the thread to stop reading it at all (the normal procedure), b) the council decides to postpone the decision to the next meeting during which it gets postponed to the next meeting (and so on) or c) it's being decided that it's not needed (only to discover half a year later that an issue has to be worked around again because the real solution was treated in the way of a) or b)). :-) So this is not badmouthing but dealing with the facts of Gentoo. s/Gentoo/Any 'large' organization with little or no management/ it turns out this is a problem in a number of other organizations; hopefully Gentoo will get better at addressing them. -Alec Interesting (and valid) point. Perhaps this argues for more (or more active) mamagement. Best regards, Wulf Regards, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposal: disable python and perl USE flags in profile
On Monday 08 of December 2008 11:34:21 Maciej Mrozowski wrote: Following advise from https://bugs.gentoo.org/show_bug.cgi?id=250179, I'm bringing it here. Hm, i totally don't agree with the original comment from the bug. Many people get use of those two flags without even noticing it. There is bunch of good soft, that take advantages of perl modules or python bindings/wrappers. For servers it may be nagios-plugins with bunch of perl scripts for hosts monitoring or at least nice DBD::mysql. So, maybe it's better to disable such flags on your system if you don't like them - that's why you are using Gentoo, aren't you? -- Cheers, Dawid Węgliński
[gentoo-dev] EAPI 2 policy for portage tree
Hi, I like to write about an observation about gentoo, I made the past weeks, which does frustrate me personally a little bit, mainly because it makes administration a bit harder for me. It could be considered as an issue or as yet another case of When you play with unstable packages, you're on your own.. It's about EAPI 2 and maybe it isn't worth changing anything with portage 2.1.6 on the way, but I guess, with future EAPI's such a situation could be repeated, so maybe there's interest in discussing it. If I'm to late and missed the discussion, I apologize for the spam. This mail is about EAPI usage in the portage tree. Let me describe it, with what happened today: I'm running a mostly stable system (91 of 1255 installed packages are unstable), but I test here and there some packages. On of the packages, which I installed and is currently masked unstable, is dev-util/cmake-2.6.2. I use it on a daily basis and happy with it so far. Today, while updating, portage wanted to downgrade cmake to the stable release, due to all cmake 2.6.x version masked by EAPI 2. The cmake-2.6.2 ebuild was updated to use EAPI 2 (along with fixing a bug). My rule of thumb is to only use unstable on none system packages after checking, what can go wrong with the unstable package and if I can afford the worst case. Generally I consider portage to be a no-go as unstable package. So I'm in the situation, where I used cmake-2.6.2 on a daily basis and like to continue, but I can't with the current state of tree and my policies (more precisely: I can't keep current stable portage and cmake-2.6.2). My solution to the problem, was to copy the ebuild in /var/db/pkg to my local overlay and I'm fine with it for now. The drawback of this workaround is, I could miss important fixes, like security fixes. This isn't the first issue I had with EAPI 2, but they were until now always upgrades to new version or new packages, so I abandoned and stayed with the current version or didn't install the package at all and wait for stable portage with EAPI 2 support. Up till now I could always do without those packages, but if I needed one necessarily, I guess, I would have backported the ebuild to a older EAPI, rather than upgrading portage. What I don't want to say, is that EAPI 2 should be blocked, rather the contrary, I look forward to EAPI 2, but from my perspective, in the particular case of cmake described above, I rather had added a new revision (cmake-2.6.2-r1) with EAPI 2 and the fix and wouldn't touch the cmake-2.6.2 ebuild. This has the advantage, that people with a setup like mine can continue to use, what they already use and work on the cmake ebuild can continue in the new revision. If the new revision fixes a security issue, one can mask the old version, with a message with bug telling this. So persons like me know, that they have to decide, what to do. Certainly one can have a different approach (like the one, that the maintainer of cmake took), which I do accept and what I descriped would be my solution. So this is about, if the current policy for using EAPI 2 in the tree is really good or it should be improved, when introducing future EAPI's, where portage supporting that EAPI is still unstable. My proposal would be, to only use new EAPI with a new version or revision and also let the last non new EAPI version for unstable packages in the tree. This would allow users of that unstable package with stable portage to not downgrade or maintain their local version or forced to upgrade portage. This would be a start. I guess, I'm not the only one, having such a setup and it prevent user's like me testing unstable packages. I need my PC on a daily basis, I can't afford, having it to reinstall, only because I played with unstable software. That's why I'm strict, when it comes to system packages or important packages to me (and I have to congratulate the gentoo devs for their work, my system just works like a charm and I'm very happy with gentoo, only hardware failures could make me headaches). So what I expect, is to find out, if setups like mine can or should be somehow supported. I'm fine, when the outcome is, that I won't be supported, then I know and should rethink my strategy to manage my gentoo boxes. With kind regards, Jean-Marc Hengen, a happy gentoo user
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 01:00 +0100, Jean-Marc Hengen wrote: So this is about, if the current policy for using EAPI 2 in the tree is really good or it should be improved, when introducing future EAPI's, where portage supporting that EAPI is still unstable. My proposal would be, to only use new EAPI with a new version or revision and also let the last non new EAPI version for unstable packages in the tree. This would allow users of that unstable package with stable portage to not downgrade or maintain their local version or forced to upgrade portage. This would be a start. I guess, I'm not the only one, having such a setup and it prevent user's like me testing unstable packages. I need my PC on a daily basis, I can't afford, having it to reinstall, only because I played with unstable software. That's why I'm strict, when it comes to system packages or important packages to me (and I have to congratulate the gentoo devs for their work, my system just works like a charm and I'm very happy with gentoo, only hardware failures could make me headaches). So what I expect, is to find out, if setups like mine can or should be somehow supported. I'm fine, when the outcome is, that I won't be supported, then I know and should rethink my strategy to manage my gentoo boxes. As a arch developer and mostly stable user, I also find this very frustrating. I'd like to go further and ask that for the next EAPI change, we only allow ebuilds using it into the tree once a version of portage that supports it has gone stable. And then, not make any ebuild with the new EAPI stable for 60 more days so that the new EAPI related code in portage can be tested properly. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Mon, 08 Dec 2008 19:09:50 -0500 Olivier Crête [EMAIL PROTECTED] wrote: I'd like to go further and ask that for the next EAPI change, we only allow ebuilds using it into the tree once a version of portage that supports it has gone stable. And then, not make any ebuild with the new EAPI stable for 60 more days so that the new EAPI related code in portage can be tested properly. The can be tested properly phase is when it's in ~arch... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 00:11 +, Ciaran McCreesh wrote: On Mon, 08 Dec 2008 19:09:50 -0500 Olivier Crête [EMAIL PROTECTED] wrote: I'd like to go further and ask that for the next EAPI change, we only allow ebuilds using it into the tree once a version of portage that supports it has gone stable. And then, not make any ebuild with the new EAPI stable for 60 more days so that the new EAPI related code in portage can be tested properly. The can be tested properly phase is when it's in ~arch... That also means that to pull a significant number of ebuilds it forces mostly everyone to test it.. and that part is annoying.. The testing should be two phased, the first for regression (against existing ebuilds), and once thats stable, then we can test with new ebuilds... -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 00:29 +, Ciaran McCreesh wrote: On Mon, 08 Dec 2008 19:25:44 -0500 Olivier Crête [EMAIL PROTECTED] wrote: The testing should be two phased, the first for regression (against existing ebuilds), and once thats stable, then we can test with new ebuilds... Uh, regression testing's handled by the package manager's extensive set of unit tests, which can cover this with targetted accuracy with much more reliability than making sure random ebuilds still work. We all know that portage doesn't have an extensive testing suite... And that test suites can't cover all the cases that the whole tree does... What you're suggesting here is making everyone wait four more months for no increase in safety. I'm not suggesting waiting any longer, just not pushing ebuilds into the tree until we have a stable enough version of portage that handles them (and if we do, then lets mark it as stable..). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Proposal: add a compiler-version entry to pkg db
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, today I hit this annoyance, because my laptop hung in the middle of an 'emerge -e @world' (checking that my world set compiles with gcc-4.3... stopped at ~ 300 of 700 :S ) I was looking for an entry in /var/db/pkg/cat/pkg/ that could have told me the compiler used to build the package, but couldn't find any. indeed it would be a fairly useful feature to have, both for testing purposes, and for user's everyday maintenance. please criticize this with anything constructive you can think of. thanks - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk9v14ACgkQV/B5axfzrPucugCfRN51KpJZ/HYCYA3v/Z2lAhaf 8eUAniZONnbWtN4f5CblJzaxEMbFWI3m =4l7H -END PGP SIGNATURE-
Re: [gentoo-dev] Proposal: disable python and perl USE flags in profile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dawid Węgliński wrote: On Monday 08 of December 2008 11:34:21 Maciej Mrozowski wrote: Following advise from https://bugs.gentoo.org/show_bug.cgi?id=250179, I'm bringing it here. Hm, i totally don't agree with the original comment from the bug. Many people get use of those two flags without even noticing it. There is bunch of good soft, that take advantages of perl modules or python bindings/wrappers. For servers it may be nagios-plugins with bunch of perl scripts for hosts monitoring or at least nice DBD::mysql. So, maybe it's better to disable such flags on your system if you don't like them - that's why you are using Gentoo, aren't you? David, in the cases you mention, there's also the option to enable those use flags through IUSE defaults or if we're talking exclusively about server packages, thorough the server profiles. As explained in the bug, at least the python use flag means very heavy and *problematic* deps for KDE. As the current USE_ORDER prevents -use flags from working on ebuilds, any flag set by the profile requires users to manually disable it in /etc/portage/package.use[/*]. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk9wiUACgkQcAWygvVEyAIfhACcCh6yMzzeSUah06AlRJ94iqnz +DUAn1j5hCIgig0EQQUF2Oa8zWJjnQbW =c+oh -END PGP SIGNATURE-
Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db
Federico Ferri wrote: Hello, today I hit this annoyance, because my laptop hung in the middle of an 'emerge -e @world' (checking that my world set compiles with gcc-4.3... stopped at ~ 300 of 700 :S ) Consider using emerge --keep-going next time. I was looking for an entry in /var/db/pkg/cat/pkg/ that could have told me the compiler used to build the package, but couldn't find any. indeed it would be a fairly useful feature to have, both for testing purposes, and for user's everyday maintenance. But the idea isn't that bad imfo. Maybe save the output of emerge --info in general and it could be easily made available for bug filing. If it was a while since you emerged the package your emerge --info could now be different from the merge time and now for example reflect your use flags. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI 2 policy for portage tree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Mon, 08 Dec 2008 19:25:44 -0500
Olivier Crête [EMAIL PROTECTED] wrote:
The can be tested properly phase is when it's in ~arch...
That also means that to pull a significant number of ebuilds it forces
mostly everyone to test it.. and that part is annoying..
If you don't like it, don't run ~arch.
I have to agree with Ciaran on this one.
Furthermore, it's unrealist and to an extent unfair to impose
limitations on ~arch ebuilds because of arch users. Gentoo should
support arch users, but that doesn't mean making sure ~arch ebuilds
work for arch users. When a arch user opts to use an ~arch ebuild,
he/she does so at his own risk.
About replacing EAPI-{0,1} ebuilds with EAPI-2 ebuilds, I can agree
with the proposal, although one can pick earlier versions/revisions from
http://sources.gentoo.org/viewcvs.py/gentoo-x86/
- --
Regards,
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkk9zYcACgkQcAWygvVEyAKEmQCfblj0GaZSITsF6/L0PvZVBLyA
1QsAoIote0hbzetNbcrPvWUpTuIOPITW
=XnAf
-END PGP SIGNATURE-
Re: [gentoo-dev] Proposal: disable python and perl USE flags in profile
Maciej Mrozowski wrote: Following advise from https://bugs.gentoo.org/show_bug.cgi?id=250179, I'm bringing it here. I think this is probably a good idea after EAPI 2 is stable and we eliminate built_with_use usage from the tree. I think having stuff build out of the box instead of dying in the middle of emerge outweighs pulling in some extra stuff with default settings. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal: disable python and perl USE flags in profile
If one has built a system with the default python and perl USE flags, what steps would be necessary to remove all packages and dependencies after removing them from the USE declarations? Jorge Manuel B. S. Vicetto wrote: Dawid WgliDski wrote: On Monday 08 of December 2008 11:34:21 Maciej Mrozowski wrote: Following advise from https://bugs.gentoo.org/show_bug.cgi?id=250179, I'm bringing it here. Hm, i totally don't agree with the original comment from the bug. Many people get use of those two flags without even noticing it. There is bunch of good soft, that take advantages of perl modules or python bindings/wrappers. For servers it may be nagios-plugins with bunch of perl scripts for hosts monitoring or at least nice DBD::mysql. So, maybe it's better to disable such flags on your system if you don't like them - that's why you are using Gentoo, aren't you? David, in the cases you mention, there's also the option to enable those use flags through IUSE defaults or if we're talking exclusively about server packages, thorough the server profiles. As explained in the bug, at least the python use flag means very heavy and *problematic* deps for KDE. As the current USE_ORDER prevents -use flags from working on ebuilds, any flag set by the profile requires users to manually disable it in /etc/portage/package.use[/*].
Re: [gentoo-dev] Proposal: disable python and perl USE flags in profile
Nathan Zachary wrote: If one has built a system with the default python and perl USE flags, what steps would be necessary to remove all packages and dependencies after removing them from the USE declarations? After kicking 'em out of make.conf, run emerge -pvtuDN world (the N is important; it tells emerge to look for USE flag changes). Once you've rebuilt your packages, then you can run emerge -p --depclean. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal: disable python and perl USE flags in profile
H, that's what I assumed, but I run into problems with the depclean: Dependencies could not be completely resolved due to the following required packages not being installed: =virtual/perl-Compress-Zlib-1.14 required by dev-perl/Archive-Zip-1.23 =virtual/perl-ExtUtils-ParseXS-1.02 required by perl-core/Module-Build-0.28.08 =virtual/perl-ExtUtils-CBuilder-0.15 required by perl-core/Module-Build-0.28.08 =virtual/perl-Archive-Tar-1.09 required by perl-core/Module-Build-0.28.08 Have you forgotten to run `emerge --update --newuse --deep world` prior to depclean? It may be necessary to manually uninstall packages that no longer exist in the portage tree since it may not be possible to satisfy their dependencies. Also, be aware of the --with-bdeps option that is documented in `man emerge`. Thanks for the information Josh. Josh Saddler wrote: Nathan Zachary wrote: If one has built a system with the default python and perl USE flags, what steps would be necessary to remove all packages and dependencies after removing them from the USE declarations? After kicking 'em out of make.conf, run emerge -pvtuDN world (the N is important; it tells emerge to look for USE flag changes). Once you've rebuilt your packages, then you can run emerge -p --depclean.
Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db
While at it, it might be useful to have someghing like compiler-use file ( like package.use) for per-package compiler version and FLAGS to be used. It is annoying to have emerge -eD world fail because some package requires specific compiler version or because gcc-3.4 can't be compiled with -march=barcelona or with -combine CFLAGS... There should also be an option for the user to match compiler with compiler version, used to compile some other package. Perhaps with naming full name of the package instead of compiler name and version string in some file, like /etc/portage/package-infra.use or something like that. That approach could also be used for selecting specific version of perl/python/ruby/autotools/whatnot. ederico Ferri wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, today I hit this annoyance, because my laptop hung in the middle of an 'emerge -e @world' (checking that my world set compiles with gcc-4.3... stopped at ~ 300 of 700 :S ) I was looking for an entry in /var/db/pkg/cat/pkg/ that could have told me the compiler used to build the package, but couldn't find any. indeed it would be a fairly useful feature to have, both for testing purposes, and for user's everyday maintenance. please criticize this with anything constructive you can think of. thanks - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk9v14ACgkQV/B5axfzrPucugCfRN51KpJZ/HYCYA3v/Z2lAhaf 8eUAniZONnbWtN4f5CblJzaxEMbFWI3m =4l7H -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Monday 08 December 2008 06:00:10 pm Jean-Marc Hengen wrote: snip This mail is about EAPI usage in the portage tree. Let me describe it, with what happened today: I'm running a mostly stable system (91 of 1255 installed packages are unstable), but I test here and there some packages. On of the packages, which I installed and is currently masked unstable, is dev-util/cmake-2.6.2. I use it on a daily basis and happy with it so far. Today, while updating, portage wanted to downgrade cmake to the stable release, due to all cmake 2.6.x version masked by EAPI 2. The cmake-2.6.2 ebuild was updated to use EAPI 2 (along with fixing a bug). My rule of thumb is to only use unstable on none system packages snip With kind regards, Jean-Marc Hengen, a happy gentoo user The problem is not that an EAPI 2 supporting portage is unstable or that he is using a ~arch version of one particular package, but the during a bugfix the maintainer moved the ebuild to EAPI 2 without a version bump forcing Jean-Marc to downgrade to the stable version. The question on policy is, can a maintainer upgrade an ebuild to the latest EAPI while doing some other bugfixing without a version bump? My personal opinion on this matter is pick one of the following: 1) perform the bugfix without a version bump and remain at the current EAPI version 2) perform the bugfix with a version bump and remain at the current EAPI version 3) perform the bugfix with a version bump and upgrade to the latest EAPI Options 1 and 2 are how most updates are done, the user can mask the latest version or upgrade. Option 3 allows the user to continue using the previous version while they decide to update to a portage version that supports the new EAPI. I would prefer that option 3 be made policy because I run several ~arch packages that either don't have a stable version (kradio) or have a feature that I need (gentoo-sources), and will not be pushed to stable immediately for various reasons from lack of maintainer time to everybody says it conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, and xorg).
[gentoo-dev] Re: EAPI 2 policy for portage tree
Olivier Crête [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 08 Dec 2008 19:43:42 -0500: I'm not suggesting waiting any longer, just not pushing ebuilds into the tree until we have a stable enough version of portage that handles them (and if we do, then lets mark it as stable..). FWIW this ~arch user's perspective: AFAIK, the policy is now that no EAPI is allowed to pass where the corresponding version of portage is, stability-wise. That means, if a portage supporting that EAPI is only available in overlays, ebuilds/ eclasses supporting it must also remain in overlays -- they can't be added to the tree. (It's worth mentioning here that overlays aren't restricted to portage features at all, some use features not in portage, period, only in one of the other PMs.) Once a portage supporting that EAPI is in the tree, hard-masked for testing, ebuilds using it may also be in the tree, but also hard-masked. Once a portage supporting that EAPI is in ~arch for testing, then ebuilds using it can likewise move to ~arch for testing, but they can't go stable yet. Only after a portage supporting a particular EAPI is stable can an ebuild requiring that EAPI stabilize as well. Note that in the above there's NOTHING stating that an ebuild that's in ~arch for testing, cannot switch to an EAPI only likewise in ~arch for testing. It's quite possible that such an ebuild still in ~arch will be found to work better with features only in a new EAPI, and it's quite legitimate in my opinion to change the ~arch ebuild (still testing, remember) to require it, as long as a version of portage with support is already in ~arch as well. Of course, by doing so the maintainer accepts that he may not stabilize that ebuild until the supporting portage goes stable as well, but if that's the case, there should be nothing blocking an existing ~arch ebuild from being modified to require an existing ~arch portage, both of them still being in ~arch testing, after all. If people want to play with a few ~arch packages here or there, while most of the system stays arch/stable, fine, but the choice and results of the choice should both be their responsibility. Maintaining devs shouldn't have to worry about changing an ebuild that after all is still in ~arch, if they judge it will ultimately make for a more stable ebuild headed into stable. -- 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
