Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Thu, 4 Mar 2010 19:22:41 +0100 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Python 3 is a new major version of Python and is intentionally incompatible with Python 2. Many external modules have not been ported yet to Python 3, so currently Python 3.1 should not be set as main active version of Python. Setting Python 3.1 as main active version of Python is currently unsupported. When it will change, a separate news item will be created to notify users. So nothing uses it yet, and it's completely incompatible with 90% of the numerous python/pygtk apps already on my system, so it'll just sit there, SLOTted, doing nothing but taking up more space on my very limited SSD, while Python 2.6 is the version that's actually in use by every single app. Currently Python 3.1 should *NOT* be set as [the] main active version of Python. (emphasis and grammar fix mine) So . . . why the heck are you stabilizing it? Please don't spam me or the other users by sticking us with a useless new version. Leave it in ~arch -- it's not at all necessary to force the upgrade by stabilizing it. We're completely dependent on the hundreds of upstream Python-coded projects to switch on their timetable. Forcing a useless Python version to be the default in Gento doesn't force *them* to write 3.x-compatible code. signature.asc Description: PGP signature
Re: [gentoo-dev] Split desktop profile patches news item for review
On Thu, 4 Mar 2010 16:52:50 +0200 Theo Chatzimichos tampak...@gentoo.org wrote: I'll give three days max for the suggestions here etc, and then I'll proceed in creating the news item. So I guess it will be committed in a week max. Thanks Feel free to submit some documentation patches now that all our docs are #...@ed. Thanks. signature.asc Description: PGP signature
Re: [gentoo-dev] Add NGINX_MODULES to USE_EXPAND
Hi Tiziano, i already implemented it in my overlay too, but it seems you have done more DEPEND research ;-) at first i had NGINX_MODULES with stuff like http_rewrite and mail_pop3 in my ebuild. then i found an ebuild on bugzilla which just used rewrite and pop3 not caring about the http or mail prefix. i don't have a preference, so your approach is totally fine too. are you interested in taking care of nginx too? i just took over maintainance from djc ... Greetings, Bene On Thu, Mar 4, 2010 at 10:27 PM, Tiziano Müller dev-z...@gentoo.org wrote: Hi Benedikt Did you look at the nginx ebuild in my overlay? I already created an ebuild with USE flags for the different features and with USE_EXPANDable flags in mind. Even though there are only 3 mail modules I'd prefer two USE_EXPAND vars: NGINX_HTTP_MODULES and NGINX_MAIL_MODULES, since upstream makes a difference between http-modules and mail-modules. Cheers, Tiziano Am Donnerstag, den 04.03.2010, 21:27 +0100 schrieb Benedikt Böhm: Hi all, i'd like to add NGINX_MODULES to USE_EXPAND. If there are no objections i will commit it end of the week. Thanks, Bene -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30
[gentoo-dev] Re: Python 3.1: Stabilization and news item
Ben de Groot posted on Thu, 04 Mar 2010 23:56:46 +0100 as excerpted: Personally I am recommending people to locally mask python-3*. I think we should consider to add it to our package.mask, unless we can find some other solution. I am not against it being marked stable, but I am against having it pulled in on systems that don't need it. ++ I've package masked python3 here. There are some things I like being leading, even bleeding edge on. Python isn't one of them. When some package I want to merge wants python-3 and isn't going to take python-2 (or if I decide I want to learn python, since one might as well learn 3 at this point if they're learning), /then/ I'll consider unmasking it. Until then, or at least for quite some time yet if that doesn't happen, there's no reason I need the additional complications of python-3 problems on my system. I'd say the same goes for most users. -- 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
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Fri, Mar 5, 2010 at 09:25, Joshua Saddler nightmo...@gentoo.org wrote: So . . . why the heck are you stabilizing it? Because 'stable' denotes that it works as intended, that it can be installed easily, etc. All of these are true now for python3. There are applications being written for it. We want to package those too. I'm fine with people masking it, and maybe we should make that easier somehow, but 3.x should definitely be stable. We're completely dependent on the hundreds of upstream Python-coded projects to switch on their timetable. Forcing a useless Python version to be the default in Gento doesn't force *them* to write 3.x-compatible code. It will *NOT* under this proposal be the default. Please formulate more carefully if you want to make an argument. Cheers, Dirkjan
[gentoo-dev] Re: Moving packages to dev-vcs
Hi, Serkan Kaba ser...@gentoo.org: I'm hitting a repoman failure repoman: dev-vcs is not an official category. Skipping QA checks in this directory. Please ensure that you add dev-vcs to /home/firari/Desktop/çalışma/gentoo/gentoo-x86/profiles/categories if it is a new category. - After hitting it for the first time I updated the whole profiles dir and still failing It is in profiles/categories, so everything should be fine. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Fri, 5 Mar 2010 10:10:00 +0100 Dirkjan Ochtman d...@gentoo.org wrote: Because 'stable' denotes that it works as intended, that it can be installed easily, etc. All of these are true now for python3. There are applications being written for it. We want to package those too. I'm fine with people masking it, and maybe we should make that easier somehow, but 3.x should definitely be stable. It does *not* work as intended. Here, since your selective quoting missed every point I made, lemme make 'em again: Python 3 is a new major version of Python and is intentionally incompatible with Python 2. Many external modules have not been ported yet to Python 3, so currently Python 3.1 should not be set as main active version of Python. Setting Python 3.1 as main active version of Python is currently unsupported. When it will change, a separate news item will be created to notify users. So nothing uses it yet, and it's completely incompatible with 90% of the numerous python/pygtk apps already on my system, so it'll just sit there, SLOTted, doing nothing but taking up more space on my very limited SSD, while Python 2.6 is the version that's actually in use by every single app. Like I said before, like it says *in the news item*, stuff does not work with it. How does that qualify as works as intended when it will not work with all my packages that use Python? If you believe stabilizing a package should be done in a vacuum, in an idealized world where no other package cares about another, then congrats, you're on the right track. Currently Python 3.1 should *NOT* be set as [the] main active version of Python. This is in the friggin' news item itself. If it should not be used, then don't force stable users to install it. It will *NOT* under this proposal be the default. Please formulate more carefully if you want to make an argument. If it's stable, then users get it by default, assuming they run the stable tree. They install a recent stage3, build their system, run emerge -uD world. Bam, a useless version of Python is now installed. Nothing on their systems will use it, so it's bloat. but 3.x should definitely be stable No one has said yet why this is. So . . . direct question, gimme a direct answer: why? signature.asc Description: PGP signature
[gentoo-dev] Re: Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
ons 2010-03-03 klockan 17:46 +0200 skrev Petteri Räty: On 03/03/2010 02:47 PM, Ciaran McCreesh wrote: On Wed, 03 Mar 2010 09:47:37 +0100 Tomáa Chvátal scarab...@gentoo.org wrote: Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. since when? Since ever. If you change eclass abi you need to rename it. No, that's not been the case 'since ever' at all. It used to be that if you changed or removed a function, you just had to make sure you didn't break anything. This was made more complicated by the way that eclasses in the tree were used for removing installed packages too, which is no longer an issue. You can't fix all possible overlays so you can only start removing functions that are used for installations if we decide we don't care about overlays. Regards, Petteri I have start to question why should we care about overlays more then the actual portage tree? Take for example the kernel or Xorg. They give themselves a period of time to clean up their own code (i.e. kernel-modules, xorg-drivers) and then they release it as stable and tell users/distributors to upgrade. They do not wait for nVidia/AMD/other out-of-tree drivers/modules to catch up. Now if we say we have someone managing an overlay, and this person do miss this warning/die for half an year, then I would say they have nott done their homework and they are on their own. I do not see why we should wait unreasonable long periods of time because there may be someone broken somewhere. How long does Ubuntu wait for PPAs to catch up or do they expect the managers of the PPAs to actually follow development? How about Fedora?
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Fri, Mar 5, 2010 at 10:41, Joshua Saddler nightmo...@gentoo.org wrote: Python 3 is a new major version of Python and is intentionally incompatible with Python 2. Many external modules have not been ported yet to Python 3, so currently Python 3.1 should not be set as main active version of Python. Setting Python 3.1 as main active version of Python is currently unsupported. When it will change, a separate news item will be created to notify users. So nothing uses it yet, and it's completely incompatible with 90% of the numerous python/pygtk apps already on my system, so it'll just sit there, SLOTted, doing nothing but taking up more space on my very limited SSD, while Python 2.6 is the version that's actually in use by every single app. Like I said before, like it says *in the news item*, stuff does not work with it. How does that qualify as works as intended when it will not work with all my packages that use Python? Because it's a frigging major revision that breaks some backwards compatibility! Currently Python 3.1 should *NOT* be set as [the] main active version of Python. This is in the friggin' news item itself. If it should not be used, then don't force stable users to install it. I don't want to force stable users to install it. I *do* however want to install it as part of the stable tree on some of my servers. And I don't think it's sensible that I have to force it to be stable somehow, I want my packagers to say, hey, we checked this and it should just work (for the intended purpose, which is NOT running code written for python2). If it's stable, then users get it by default, assuming they run the stable tree. They install a recent stage3, build their system, run emerge -uD world. Bam, a useless version of Python is now installed. Nothing on their systems will use it, so it's bloat. I agree that that's bad, but I do not agree that not stabilizing it is the right solution. No one has said yet why this is. So . . . direct question, gimme a direct answer: why? Because in my opinion stable means that the people who package this are stating that hey, we did some testing with this, it works with all of the other packages you have installed that want to use it. It does not mean everyone should have it installed, which is what it appears you think it means. Cheers, Dirkjan
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On 03/05/2010 01:41 AM, Joshua Saddler wrote: If it's stable, then users get it by default, assuming they run the stable tree. They install a recent stage3, build their system, run emerge -uD world. Bam, a useless version of Python is now installed. Nothing on their systems will use it, so it's bloat. In portage-2.1.7.x (current stable), there is support for pseudo-version-ranges in dependencies. This allows you use a dependency like dev-lang/python-3 in a package that doesn't support python3, and that will prevent it from getting pulled into the dependency graph. If a package that supports python3 gets pulled into the depedency graph, then either it's the user's responsibility to mask it or else we could provide the ability to disable python3 support with a USE flag setting. -- Thanks, Zac
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Fri, 5 Mar 2010 10:56:23 +0100 Dirkjan Ochtman d...@gentoo.org wrote: No one has said yet why this is. So . . . direct question, gimme a direct answer: why? Because in my opinion stable means that the people who package this are stating that hey, we did some testing with this, it works with all of the other packages you have installed that want to use it. Aaaand none of my packages that are installed want to use it. That's what I'm sayin'. Maybe if I ran ~arch they'd ask for Python 3.x, but I run stable, so *nothing* wants to use it. Every other stable user is in the same situation. You seem to be ignoring us, the stable users, in favor of rushing 3.x out of ~arch, like that makes some kind of perceived problem go away. It does not mean everyone should have it installed, which is what it appears you think it means. Yet that's the net effect -- everyone *will* have it installed. . . unless folks start getting crafty with pseudo version ranges, as Zac mentioned. signature.asc Description: PGP signature
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Fri, Mar 5, 2010 at 11:14, Joshua Saddler nightmo...@gentoo.org wrote: Aaaand none of my packages that are installed want to use it. That's what I'm sayin'. Maybe if I ran ~arch they'd ask for Python 3.x, but I run stable, so *nothing* wants to use it. Every other stable user is in the same situation. You seem to be ignoring us, the stable users, in favor of rushing 3.x out of ~arch, like that makes some kind of perceived problem go away. I *am* a stable user, and I do want to install python3 (without having to override keywords -- because my packager, the gentoo python team, says it works!). I recognize the cruft problem, but I don't think keeping things in unstable is the right solution for solving it, because they should IMO be orthogonal. Yet that's the net effect -- everyone *will* have it installed. . . unless folks start getting crafty with pseudo version ranges, as Zac mentioned. I guess we'll have to do that then. Cheers, Dirkjan
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Friday 05 of March 2010 11:22:18 Dirkjan Ochtman wrote: I *am* a stable user, and I do want to install python3 (without having to override keywords -- because my packager, the gentoo python team, says it works!). I recognize the cruft problem, but I don't think keeping things in unstable It's testing :) Now on more serious note, ideally python could be treated just like any other non-leaf package (in dependency tree), just like library. In such case it's completely reasonable to stabilize the newest version of such 'library', especially when it's slotted and doesn't conflict in any way with the rest. However, because of being used by package manager, python is leaf application really and it's going to be immediately pulled for everyone. It would be nice if portage didn't automatically pull newest available packages with new SLOTs unless explicitly referenced in dependencies. That would have certainly caused python 3 stabilization to be a non issue. (@Zac is this greedy/non-greedy' behaviour you've talking some time ago?) Hmm, but that would also prevent automatic KDE 4.x - 4.y updates.. -- regards MM
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On 03/05/2010 03:09 AM, Maciej Mrozowski wrote: Now on more serious note, ideally python could be treated just like any other non-leaf package (in dependency tree), just like library. In such case it's completely reasonable to stabilize the newest version of such 'library', especially when it's slotted and doesn't conflict in any way with the rest. However, because of being used by package manager, python is leaf application really and it's going to be immediately pulled for everyone. It won't be pulled in by sys-apps/portage dependencies which look like this: || ( dev-lang/python:2.8 dev-lang/python:2.7 dev-lang/python:2.6 =dev-lang/python-3 ) If you already have python:2.6 installed then it will not pull in a new slot. It would be nice if portage didn't automatically pull newest available packages with new SLOTs unless explicitly referenced in dependencies. That would have certainly caused python 3 stabilization to be a non issue. (@Zac is this greedy/non-greedy' behaviour you've talking some time ago?) Hmm, but that would also prevent automatic KDE 4.x - 4.y updates.. In portage-2.1.7.x (current stable), there is support for pseudo-version-ranges in dependencies. This allows you use a dependency like dev-lang/python-3 in a package that doesn't support python3, and that will prevent it from getting pulled into the dependency graph. If a package that supports python3 gets pulled into the depedency graph, then either it's the user's responsibility to mask it or else we could provide the ability to disable python3 support with a USE flag setting. -- Thanks, Zac
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On 5 March 2010 12:24, Zac Medico zmed...@gentoo.org wrote: It won't be pulled in by sys-apps/portage dependencies which look like this: || ( dev-lang/python:2.8 dev-lang/python:2.7 dev-lang/python:2.6 =dev-lang/python-3 ) If you already have python:2.6 installed then it will not pull in a new slot. That means we would need to fix all packages that depend on python to use this style of dependency notation. Or do some eclass magic with NEED_PYTHON for example. And of course anyone with an unslotted dev-lang/python in their world file will still pull the useless version. Another possible solution is to rename the package to a unique string like dev-lang/python3, tho I agree that is sub-optimal. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Split desktop profile patches news item for review
On 5 March 2010 09:28, Joshua Saddler nightmo...@gentoo.org wrote: Feel free to submit some documentation patches now that all our docs are #...@ed. Thanks. No need for the drama, my friend. A couple of more choices in profiles does not fuck up all our docs. Some clarification will need to be added to docs that refer to the desktop profile, yes. That's a good point. Let's start identifying which docs need updating. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On 5 March 2010 04:18, Graham Murray gra...@gmurray.org.uk wrote: Is there not a third, maybe obvious, solution to circular dependencies on initial install? 3. Include one or both of the packages in the stage tarball. None of the packages involved (gtk+, cups and poppler) is in any shape or form essential, so you will have a very hard time convincing people that this is the best solution. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Re: [gentoo-dev-announce] Lastrite: games-fps/openarena
On 4 March 2010 19:17, Victor Ostorga vosto...@gentoo.org wrote: 0.8.5 was released on february 23, 2010 and the patch at bug 255453 seems to work fine. Please don't remove one of the greatest open source games. So step up and maintain it! Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Re: Moving packages to dev-vcs
repoman was referencing the main tree for that (or maybe the overlays additionally) and the issue was fixed when I syced. 2010/3/5 Christian Faulhammer fa...@gentoo.org: Hi, Serkan Kaba ser...@gentoo.org: I'm hitting a repoman failure repoman: dev-vcs is not an official category. Skipping QA checks in this directory. Please ensure that you add dev-vcs to /home/firari/Desktop/çalışma/gentoo/gentoo-x86/profiles/categories if it is a new category. - After hitting it for the first time I updated the whole profiles dir and still failing It is in profiles/categories, so everything should be fine. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/
Re: [gentoo-dev] Split desktop profile patches news item for review
On Friday 05 March 2010 14:57:32 Ben de Groot wrote: On 5 March 2010 09:28, Joshua Saddler nightmo...@gentoo.org wrote: Feel free to submit some documentation patches now that all our docs are #...@ed. Thanks. No need for the drama, my friend. A couple of more choices in profiles does not fuck up all our docs. Some clarification will need to be added to docs that refer to the desktop profile, yes. That's a good point. Let's start identifying which docs need updating. Cheers, I maintain the KDE docs, so I'll update them. I'll also send a doc patch for the gnome and xorg docs. I already blogged about it, and will write the news item. I suppose those are more than enough. Thanks for pointing that out -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt Teams blog.tampakrap.gr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-dev-announce] Lastrite: games-fps/openarena
On Friday 05 March 2010 15:17:06 Ben de Groot wrote: On 4 March 2010 19:17, Victor Ostorga vosto...@gentoo.org wrote: 0.8.5 was released on february 23, 2010 and the patch at bug 255453 seems to work fine. Please don't remove one of the greatest open source games. So step up and maintain it! Cheers, games herd already maintains that package . At least this is what I see on metadata.xml -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-dev-announce] Lastrite: games-fps/openarena
On 5 March 2010 15:22, Markos Chandras hwoar...@gentoo.org wrote: On Friday 05 March 2010 15:17:06 Ben de Groot wrote: So step up and maintain it! games herd already maintains that package . At least this is what I see on metadata.xml Nominally, yes. But if a package has open QA and security bugs and patches that have not been reviewed or even commented upon by the maintainer(s) for over 6 months, then you can't consider that package actually maintained. So for this package to remain in the tree, someone needs to step up and actually maintain it. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
[gentoo-dev] Maintainership of sci-misc/boinc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi fellows, as I am no longer using boinc myself I am going to step back from its maintainership. Since it is not exactly easy package I ask for some dev who is using it and willing to play with it. (I can give you my tarball creation script at least :P) So anyone, would be sad to have such popular thing without maintainer? (for the record there is open stable bug waiting on cuda packages to be stabled, YAY :]) Cheers Tomas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuRHmAACgkQHB6c3gNBRYdb1wCgtIbwZBYmQ/8BUHR8V95+JBSZ FocAn2gloXYN3PYAPZMosL6gK8lUsE6C =IRdU -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] Lastrite: games-fps/openarena
On Friday 05 March 2010 17:06:21 Ben de Groot wrote: On 5 March 2010 15:22, Markos Chandras hwoar...@gentoo.org wrote: On Friday 05 March 2010 15:17:06 Ben de Groot wrote: So step up and maintain it! games herd already maintains that package . At least this is what I see on metadata.xml Nominally, yes. But if a package has open QA and security bugs and patches that have not been reviewed or even commented upon by the maintainer(s) for over 6 months, then you can't consider that package actually maintained. So for this package to remain in the tree, someone needs to step up and actually maintain it. Cheers, I assume that only members of QA can actually step up and fix the problem. Otherwise the games heard will complain that random devs are touching their packages. I just assume that but I am not willing to step into their territory and this is why I asked permission to touch the bug ( see my last comment on the bug ) -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
[gentoo-dev] VCS tools in need for a maintainer
Hello! All of these tools had maintainer-needed in metadata.xml when I checked yesterday: dev-util/aegis dev-util/archway dev-util/cvsspam dev-util/guilt dev-util/stgit dev-util/svk dev-util/svnmailer If anyone feels like adopting one or two of these: properly moving them over to the dev-vcs category would be good thing to do first. Please let us know if you do. Sebastian
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On 2010.03.04 02:17, Dale wrote: [snip] Let just think of it this way. I have to reinstall say from a dead hard drive. I have copies of my make.conf and world file. I install my new drive, download the tarball and unpack it. I copy over make.conf and world. Naturally cups will be enabled. Then I sync and start to update. Isn't that circular dependency still going to be there? After all, this is how I install Gentoo even if from scratch. I set my USE line before I start to emerge or update. It seems to me, in my situation, this would not solve much. Maybe I am incorrect in that. Dale :-) :-) Dale, That's not a new install as per the handbook. Neither are you a new user as you have a premade make.conf and world file and some experience with Gentoo. Put yourself in the place of a brand new Gentoo user doing his/her first install. It needs to just work out of the box, one way or another, without forums posts or calls for help in #gentoo about circular dependences. That's not just cups - thats all circular dependencies. -- Regards, Roy Bamford (Neddyseagoon) an member of gentoo-ops forum-mods trustees pgpZf1YNq8AHp.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Lastrite: games-fps/openarena
On 5 March 2010 16:23, Markos Chandras hwoar...@gentoo.org wrote: I assume that only members of QA can actually step up and fix the problem. Otherwise the games heard will complain that random devs are touching their packages. I just assume that but I am not willing to step into their territory and this is why I asked permission to touch the bug ( see my last comment on the bug ) Obviously, if there is a nominal maintainer, you should contact him/her/them. But in cases like this, where open bugs show low or no activity, there is often no problem stepping on any toes. What I usually do is mail the maintainer or herd to which it is assigned, and ask if there are any objections to fixing it. If no objections are raised within a reasonable timeframe (depending on the seriousness of the bug), I would go ahead. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Moving packages to dev-vcs
On Thu, 04 Mar 2010 22:08:06 +0100
Sebastian Pipping sp...@gentoo.org wrote:
4. Notify
=
- Report back problems with this process
- Mail fellow maintainers of dev-util/${PN} about the move
- If ${PN} is a big one (Subversion, Git, you know the list)
- Update documentation (now or open a bug at least, please)
- Drop sp...@g.o. a mail to update references in Layman
- (Notify users and developers through Planet Gentoo?)
This step should probably include correcting all open bug
reports' Summaries to point to the new category, so that CAT/PN can be
found using the simple search interface.
Regards,
jer
Re: [gentoo-dev] Moving packages to dev-vcs
On 03/05/10 18:10, Jeroen Roovers wrote: 4. Notify = [..] This step should probably include correcting all open bug reports' Summaries to point to the new category, so that CAT/PN can be found using the simple search interface. Good catch. Thanks for fixing those on monotone (and others I guess). Sebastian
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On 5 March 2010 12:24, Zac Medico zmed...@gentoo.org wrote: It won't be pulled in by sys-apps/portage dependencies which look like this: || ( dev-lang/python:2.8 dev-lang/python:2.7 dev-lang/python:2.6 =dev-lang/python-3 ) If you already have python:2.6 installed then it will not pull in a new slot. That means we would need to fix all packages that depend on python to use this style of dependency notation. Or do some eclass magic with NEED_PYTHON for example. And of course anyone with an unslotted dev-lang/python in their world file will still pull the useless version. Then they shouldn't have dev-lang/python in their world file then should they. Or should we start putting special magic rules around everywhere. Hell i'm sure I have useless crap in my world file, you don't see be bitching about being forced to upgrade some package I never use. If it is in there then it is my responsibility, not yours. Guys you should remember that we like to call gentoo a metadistribution [1]. Our users should be taking an active role in the maintenance of the own distro what we should be doing is saying yes we have determined this package to be stable. The news item should tell users they can safely mask python:3 if they wish. The only concern I have is all the []dev-lang/python [R]DEPENDs there are in the tree. They should be fixed to either be slotted or a dependency range. Thank god this will never happen again now that we have slot deps right? :| Alistair. [1] http://www.gentoo.org/main/en/about.xml [2] and by this I mean looking to see what packages are going to be installed and whether they really want to install them.
Re: [gentoo-dev] Split desktop profile patches news item for review
On Fri, Mar 05, 2010 at 03:46:50PM +0200, Theo Chatzimichos wrote: On Friday 05 March 2010 14:57:32 Ben de Groot wrote: On 5 March 2010 09:28, Joshua Saddler nightmo...@gentoo.org wrote: Feel free to submit some documentation patches now that all our docs are #...@ed. Thanks. No need for the drama, my friend. A couple of more choices in profiles does not fuck up all our docs. Some clarification will need to be added to docs that refer to the desktop profile, yes. That's a good point. Let's start identifying which docs need updating. Cheers, I maintain the KDE docs, so I'll update them. I'll also send a doc patch for the gnome and xorg docs. I already blogged about it, and will write the news item. I suppose those are more than enough. Thanks for pointing that out -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt Teams blog.tampakrap.gr How about the Handbook? As far as I remember you're asked to choose a profile :-) I can file a bug it needs to be done :-) Just let me know -- Zeerak Waseem pgptqnvLfw0uA.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Friday 05 March 2010 17:12:23 Roy Bamford wrote: That's not a new install as per the handbook. Neither are you a new user as you have a premade make.conf and world file and some experience with Gentoo. Put yourself in the place of a brand new Gentoo user doing his/her first install. It needs to just work out of the box, one way or another, without forums posts or calls for help in #gentoo about circular dependences. That's not just cups - thats all circular dependencies. Brand new gentoo user goes throu handbook - reads set up USE variables in make.conf and does it according to his/her needs following use.*.desc. If gentoo was new to me i *would* enter cups as i use printers often at work. -- Cheers Dawid Węgliński
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
El vie, 05-03-2010 a las 19:03 +0100, Dawid Węgliński escribió: On Friday 05 March 2010 17:12:23 Roy Bamford wrote: That's not a new install as per the handbook. Neither are you a new user as you have a premade make.conf and world file and some experience with Gentoo. Put yourself in the place of a brand new Gentoo user doing his/her first install. It needs to just work out of the box, one way or another, without forums posts or calls for help in #gentoo about circular dependences. That's not just cups - thats all circular dependencies. Brand new gentoo user goes throu handbook - reads set up USE variables in make.conf and does it according to his/her needs following use.*.desc. If gentoo was new to me i *would* enter cups as i use printers often at work. +1 I did it (I mean, add some commonly used USE flags) in all my Gentoo installations, and I would add cups for sure (since printing is used every day in most machines I use and administrate). Leio pointed some messages ago about the possibility of splitting some poppler parts to fix this circular dep issue, what is the problem with that option? The suggestion is not about splitting every poppler part in tons of ebuilds, but simply split poppler in the minimum needed to fix this problem (sorry if I missed the reply, I haven't followed discussion too deeply :-( ) Thanks and best regards signature.asc Description: Esta parte del mensaje está firmada digitalmente
[gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
Peter Hjalmarsson posted on Fri, 05 Mar 2010 10:54:23 +0100 as excerpted: I have start to question why should we care about overlays more then the actual portage tree? Take for example the kernel or Xorg. They give themselves a period of time to clean up their own code (i.e. kernel-modules, xorg-drivers) and then they release it as stable and tell users/distributors to upgrade. They do not wait for nVidia/AMD/other out-of-tree drivers/modules to catch up. Now if we say we have someone managing an overlay, and this person do miss this warning/die for half an year, then I would say they have nott done their homework and they are on their own. I do not see why we should wait unreasonable long periods of time because there may be someone broken somewhere. While I didn't mention overlays in my earlier reply, that's exactly why I proposed four months each in warning and die, before removal altogether. That gives the once-per-quarter updaters a bit of extra time to catch it at each stage, and if they've not done so by four or even eight months out... waiting a full year, or two, or three... isn't necessarily going to help matters much. Besides, if they're /that/ far behind the main tree, what sort of overlay maintainer are they anyway? Hardly one that should be basing on Gentoo, which has always been a rolling distribution. -- 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
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
On Monday 01 March 2010 00:30:01 Mike Frysinger wrote: thought i disabled this ... oh well, fixed now -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: News item for removal of 2008.0 and old hardened profiles
On Thursday 04 March 2010 11:08:52 Samuli Suominen wrote: Attached you can find the news item for up coming profile cleanup. do profiles really need to be culled this often ? we used to let the tail run longer and no one complained. it's easier to upgrade an old system when the current profile is sane than having to create one from scratch because the new profile uses features not actively available. i.e. let's set a limit of like 3 years on profiles -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [rfc] making autotools.eclass depends flexible
sometimes i have optional patches (ignoring the patches should always be
applied) where autotools should be run. always inheriting autotools is
currently annoying because it always adds the related dependencies. USE based
inherits are obviously out.
so unless there's some burgeoning standard i'm not aware of, below is what i
have in mind. packages set AUTOTOOLS_AUTO_DEPEND to no before inheriting
autotools.eclass and that allows them to put ${AUTOTOOLS_DEPEND} behind a USE
flag in their own DEPEND string.
--- autotools.eclass8 Feb 2010 11:04:01 - 1.92
+++ autotools.eclass5 Mar 2010 18:09:54 -
@@ -46,10 +46,20 @@ if [[ -n ${WANT_AUTOCONF} ]] ; then
esac
export WANT_AUTOCONF
fi
-DEPEND=${_automake_atom}
- ${_autoconf_atom}
-[[ ${CATEGORY}/${PN} != sys-devel/libtool ]] DEPEND=${DEPEND}
=sys-devel/libtool-2.2.6b
+
+AUTOTOOLS_DEPEND=${_automake_atom} ${_autoconf_atom}
+[[ ${CATEGORY}/${PN} != sys-devel/libtool ]]
AUTOTOOLS_DEPEND=${AUTOTOOLS_DEPEND}
=sys-devel/libtool-2.2.6b
RDEPEND=
+
+# @ECLASS-VARIABLE: AUTOTOOLS_AUTO_DEPEND
+# @DESCRIPTION:
+# Set to 'no' to disable automatically adding to DEPEND. This lets
+# ebuilds former conditional depends by using ${AUTOTOOLS_DEPEND} in
+# their own DEPEND string.
+if [[ ${AUTOTOOLS_AUTO_DEPEND} != no ]] ; then
+ DEPEND=${AUTOTOOLS_AUTO_DEPEND}
+fi
+
unset _automake_atom _autoconf_atom
# @ECLASS-VARIABLE: AM_OPTS
-mike
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: Split desktop profile patches news item for review
Zeerak Mustafa Waseem posted on Fri, 05 Mar 2010 18:59:39 +0100 as excerpted: How about the Handbook? As far as I remember you're asked to choose a profile :-) I can file a bug it needs to be done :-) Just let me know That's part 1 (installing), chapter 6 (base system), section 6.b. (portage), heading Choosing the right profile. The handbook (at least the amd64 handbook I checked, presumably they're pretty much the same in this regard) now says to use eselect profile, so as long as it's listing the correct choices, the examples and details don't matter quite so much. However, the examples/details do mention desktop and server profiles (plus no-multilib for amd64) as alternates to the generic arch profile, so they /could/ be changed to additionally mention kde and gnome. But with eselect profile doing the heavy lifting already, I'd not call it critical. But be sure that eselect is getting the correct listing... for all archs. =:^) -- 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
Re: [gentoo-dev] Re: Split desktop profile patches news item for review
On Friday 05 March 2010 21:01:09 Duncan wrote: Zeerak Mustafa Waseem posted on Fri, 05 Mar 2010 18:59:39 +0100 as excerpted: How about the Handbook? As far as I remember you're asked to choose a profile :-) I can file a bug it needs to be done :-) Just let me know That's part 1 (installing), chapter 6 (base system), section 6.b. (portage), heading Choosing the right profile. The handbook (at least the amd64 handbook I checked, presumably they're pretty much the same in this regard) now says to use eselect profile, so as long as it's listing the correct choices, the examples and details don't matter quite so much. However, the examples/details do mention desktop and server profiles (plus no-multilib for amd64) as alternates to the generic arch profile, so they /could/ be changed to additionally mention kde and gnome. But with eselect profile doing the heavy lifting already, I'd not call it critical. But be sure that eselect is getting the correct listing... for all archs. =:^) I could submit a handbook patch too, but I guess the important thing is to make it known to people that are already using the desktop profile. Still, a small reference can be made to handbook, but just a small one, as people that are going to install KDE or GNOME should refer the relevant installation guides. I don't know, Nightmorph has the final word, so I will wait for instructions. BTW, did anyone test it? -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt Teams blog.tampakrap.gr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Split desktop profile patches news item for review
On Friday 05 March 2010 07:57:32 Ben de Groot wrote: On 5 March 2010 09:28, Joshua Saddler nightmo...@gentoo.org wrote: Feel free to submit some documentation patches now that all our docs are #...@ed. Thanks. No need for the drama, my friend. A couple of more choices in profiles does not fuck up all our docs. Some clarification will need to be added to docs that refer to the desktop profile, yes. That's a good point. Let's start identifying which docs need updating. i dont think he's throwing up drama. he's just posting a friendly reminder that any documents referencing profiles are out of date. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On Wednesday 03 March 2010 03:47:37 Tomáš Chvátal wrote: Dne 3.3.2010 08:52, Ryan Hill napsal(a): On Wed, 03 Mar 2010 08:52:55 +0200 Petteri Räty wrote: On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote: Members of Gentoo Python Project have agreed to deprecate the following functions in EAPI =2: - python_version() - python_mod_exists() - python_tkinter_exists() - distutils_python_version() - distutils_python_tkinter() These functions are already banned in EAPI =3. 1. In this week, these functions will start printing deprecation warnings in older EAPIs. 2. On 2010-07-01, these functions will start calling die(). (If any ebuilds in gentoo-x86 still call any of these functions on 2010-07-01, then addition of calls to die() will be delayed.) 3. On 2011-01-01, these functions will be removed. Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. ?! since when? Since ever. If you change eclass abi you need to rename it. erm, no. being anal about eclass removal is only because of the breakage that occurred with installed packages. functions that get used at build time are free to be deprecated on the fly. Arfrever has a sane set of steps that should ease transition of everything in tree. anything out of tree (overlays) that dont adapt deserve to die anyways. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Split desktop profile patches news item for review
On Fri, Mar 05, 2010 at 07:01:09PM +, Duncan wrote: Zeerak Mustafa Waseem posted on Fri, 05 Mar 2010 18:59:39 +0100 as excerpted: How about the Handbook? As far as I remember you're asked to choose a profile :-) I can file a bug it needs to be done :-) Just let me know That's part 1 (installing), chapter 6 (base system), section 6.b. (portage), heading Choosing the right profile. The handbook (at least the amd64 handbook I checked, presumably they're pretty much the same in this regard) now says to use eselect profile, so as long as it's listing the correct choices, the examples and details don't matter quite so much. However, the examples/details do mention desktop and server profiles (plus no-multilib for amd64) as alternates to the generic arch profile, so they /could/ be changed to additionally mention kde and gnome. But with eselect profile doing the heavy lifting already, I'd not call it critical. But be sure that eselect is getting the correct listing... for all archs. =:^) -- 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 Agreed, I wouldn't call it a critical thing to edit, however having heard With so many people confused about profiles as it is, in regards both to the forums and the irc channels, I'd say it should be a priority to make a mention of it. Perhaps something akin to There are KDE and Gnome specific profiles geared towards each of these desktop environment, should you use another lighter environment the base profile should contain all necessary settings. :-) -- Zeerak Waseem pgpohfbPlLAxh.pgp Description: PGP signature
[gentoo-dev] Re: Python 3.1: Stabilization and news item
Zac Medico posted on Fri, 05 Mar 2010 03:24:29 -0800 as excerpted: On 03/05/2010 03:09 AM, Maciej Mrozowski wrote: Now on more serious note, ideally python could be treated just like any other non-leaf package (in dependency tree), just like library. In such case it's completely reasonable to stabilize the newest version of such 'library', especially when it's slotted and doesn't conflict in any way with the rest. However, because of being used by package manager, python is leaf application really and it's going to be immediately pulled for everyone. It won't be pulled in by sys-apps/portage dependencies which look like this: || ( dev-lang/python:2.8 dev-lang/python:2.7 dev-lang/python:2.6 =dev-lang/python-3 ) If you already have python:2.6 installed then it will not pull in a new slot. Won't emerge -aNuD pull it in anyway, even in a new slot, since portage says it can use it? I know I use that, so I'm always updated all the way thru the system, not just at the leaves. I know it did for me on ~arch, the reason I have it masked. So, as has already been proposed, why not stable it, while at the same time masking it, with an appropriate masking message explaining that it is stable, but we're just preventing the majority of folks from pulling it in, since they don't need it yet? That way, those who want/need it can unmask it the usual way, and everyone can continue as the were... at least until the first package requiring python-3 only comes along. Realistically, how long is that likely to be? Otherwise, what about a news item saying it's to be stabilized, and warning people that don't think they want or need it to put it in package.mask themselves? That would seem to be about the best compromise I can see ATM. -- 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
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Sat, Mar 06, 2010 at 06:23:03AM +1300, Alistair Bush wrote: [...] Guys you should remember that we like to call gentoo a metadistribution [1]. Our users should be taking an active role in the maintenance of the own distro [...] As a user I have to thank you very much for this statement. These are exactly my thoughts whenever these lengthy discussions about changing some default setting crop up. The main reason I love gentoo is because it makes it easy to have everything my way. (Un)masking something is as simple as adding one line in /etc/portage/package.(un)mask, so I only marginally care about whether something is stable, testing or even package masked. As a side remark to all those who argue themselves to death in the cups useflag in default profile thread: The same applies to disabling and enabling useflags ;) Well I guess I should go back into hiding now. Regards, Andy pgpW5AE9gMdzR.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
chrome://messenger/locale/messengercompose/composeMsgs.properties: El vie, 05-03-2010 a las 19:03 +0100, Dawid Węgliński escribió: On Friday 05 March 2010 17:12:23 Roy Bamford wrote: That's not a new install as per the handbook. Neither are you a new user as you have a premade make.conf and world file and some experience with Gentoo. Put yourself in the place of a brand new Gentoo user doing his/her first install. It needs to just work out of the box, one way or another, without forums posts or calls for help in #gentoo about circular dependences. That's not just cups - thats all circular dependencies. Brand new gentoo user goes throu handbook - reads set up USE variables in make.conf and does it according to his/her needs following use.*.desc. If gentoo was new to me i *would* enter cups as i use printers often at work. +1 I did it (I mean, add some commonly used USE flags) in all my Gentoo installations, and I would add cups for sure (since printing is used every day in most machines I use and administrate). Leio pointed some messages ago about the possibility of splitting some poppler parts to fix this circular dep issue, what is the problem with that option? The suggestion is not about splitting every poppler part in tons of ebuilds, but simply split poppler in the minimum needed to fix this problem (sorry if I missed the reply, I haven't followed discussion too deeply :-( ) Thanks and best regards This is what I am saying. *IF* cups were some little known or obscure USE flag, one could make the argument that it would not be set until later on. I started with Gentoo over 6 years ago. I had only used anything Linux for a few months. I knew what cups was. Even tho I was new to Linux when I first installed Mandrake, I knew I had a printer. It was a old used one at the time but I still had a printer. I wanted that printer to work. Mandrake picked that up for me, Gentoo is not that way. I have to pick that up, not the OS. I am also saying that this needs a long term fix. I'm thinking a long term fix like happened with the blocks issue. If in the short term this USE flag ha to be removed, then fine. It's doesn't really fix anything is my opinion. If a user turns that flag on as is in the docs, the problem is still there. This is why we need a long term fix. This may take a good while, months, year, who knows. This just should not be called fixed when the problem is still there. Please don't just remove the USE flag and forget the reason it happened. This is Gentoo. I'm proud to tell people I use it. I want it to stay on top of the pile not fall to the bottom. Dale :-) :-)
[gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On Fri, 05 Mar 2010 13:12:36 +0200 Petteri Räty betelge...@gentoo.org wrote: Because there is so little benefit from removing old functions. What is so bad about having them grouped at the bottom of the file inside a deprecated section? Because then people use them. Don't ask me why. I have things I deprecated over two years ago still being used by a dozen ebuilds bumped within the last three months. You should be familiar with this behaviour wrt. built_with_use. So, when I'm making changes I still have to maintain the deprecated stuff. If I really want to get rid of it, then I have to break it. Replace the whole thing with a eerror like any of our deprecated eclasses. At that point, I would rather just remove the function or eclass than curate a museum of dead interfaces. But I suppose that's a personal quirk -- I hate having old unused code around. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Moving packages to dev-vcs
On 03/04/10 23:11, Brian Harring wrote: Random sidenote, anyone looked at using an alternate vcs to do the work, then proxy it back? Specifically thinking of workflow like svk (or in this case hg cvs, https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS ). The reason I ask is that via building the work up outside of cvs, then proxying the add/remove/modifications back into it, it should be possible to minimize the window of cvs breakage down to bare minimum while still getting the same level of QA validation for the changes. Assuming the person using such a tool - is fluent in using such tool (to at least compensate extra abstraction. with plain CVS you at least know for sure what's happening) - is manually doing extra commits for manifest fixes (like repoman commit would do for him otherwise) Sebastian
[gentoo-dev] Re: Python 3.1: Stabilization and news item
On Fri, 5 Mar 2010 13:37:28 +0100 Ben de Groot yng...@gentoo.org wrote: On 5 March 2010 12:24, Zac Medico zmed...@gentoo.org wrote: It won't be pulled in by sys-apps/portage dependencies which look like this: || ( dev-lang/python:2.8 dev-lang/python:2.7 dev-lang/python:2.6 =dev-lang/python-3 ) If you already have python:2.6 installed then it will not pull in a new slot. That means we would need to fix all packages that depend on python to use this style of dependency notation. Or do some eclass magic with NEED_PYTHON for example. Or PYTHON_DEPEND? http://www.gentoo.org/proj/en/Python/developersguide.xml -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Monday 01 of March 2010 22:24:56 Ben de Groot wrote: For some reason beyond my understanding, we have the cups useflag enabled by default in profiles. This has started to generate circular dependencies, at least for desktop profile users (gtk - cups - poppler - gtk). I propose we no longer enable the cups useflag. poppler[utils] are just pdfto*sth converters, and they're most likely pure runtime depedencies for net-print/cups. Could someone from printing herd verify? If so, then it's sufficient to fix cups dependencies (move poppler[utils] from COMMON_DEPEND to PDEPEND) and problem solved. If no, I can split off utils from poppler - with CMake it's effortless. -- regards MM
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On Friday 05 March 2010 15:14:33 Ryan Hill wrote: On Fri, 05 Mar 2010 13:12:36 +0200 Petteri Räty wrote: Because there is so little benefit from removing old functions. What is so bad about having them grouped at the bottom of the file inside a deprecated section? Because then people use them. Don't ask me why. I have things I deprecated over two years ago still being used by a dozen ebuilds bumped within the last three months. You should be familiar with this behaviour wrt. built_with_use. So, when I'm making changes I still have to maintain the deprecated stuff. If I really want to get rid of it, then I have to break it. Replace the whole thing with a eerror like any of our deprecated eclasses. At that point, I would rather just remove the function or eclass than curate a museum of dead interfaces. But I suppose that's a personal quirk -- I hate having old unused code around. indeed ... and to take it further, ive seen devs inclined to leave ebuilds alone even after they were told point blank the funcs were deprecated and going away. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On 5 March 2010 21:51, Maciej Mrozowski reave...@gmail.com wrote: poppler[utils] are just pdfto*sth converters, and they're most likely pure runtime depedencies for net-print/cups. Could someone from printing herd verify? If so, then it's sufficient to fix cups dependencies (move poppler[utils] from COMMON_DEPEND to PDEPEND) and problem solved. From looking at the cups ebuild there is a configure option, so I don't think it's that straightforward, but there might be a solution here. If no, I can split off utils from poppler - with CMake it's effortless. We just rejoined the split poppler into one package again. So if you are going to split it up again, you will have some explaining to do to our users. I would like to prevent splitting, and see if we can fix maybe the cups ebuild instead. Or maybe the gtk+ maintainers want to split up their package... I understand they like that sort of thing. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] RFC: News item for removal of 2008.0 and old hardened profiles
On 05/03/2010 18:54, Mike Frysinger wrote: On Thursday 04 March 2010 11:08:52 Samuli Suominen wrote: Attached you can find the news item for up coming profile cleanup. do profiles really need to be culled this often ? we used to let the tail run longer and no one complained. it's easier to upgrade an old system when the current profile is sane than having to create one from scratch because the new profile uses features not actively available. i.e. let's set a limit of like 3 years on profiles -mike I think I have mostly upgraded my machines, but I completely agree - I sometimes let some old virtual machines sit unbooted for a year and then suddenly want to use them and bring them up to date and occasionally this can be a right old pain in the derrier... Surely 4 months is too short a warning for profiles which can easily be simply left to rot instead?
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
On 03/05/2010 11:26 AM, Duncan wrote: Zac Medico posted on Fri, 05 Mar 2010 03:24:29 -0800 as excerpted: On 03/05/2010 03:09 AM, Maciej Mrozowski wrote: Now on more serious note, ideally python could be treated just like any other non-leaf package (in dependency tree), just like library. In such case it's completely reasonable to stabilize the newest version of such 'library', especially when it's slotted and doesn't conflict in any way with the rest. However, because of being used by package manager, python is leaf application really and it's going to be immediately pulled for everyone. It won't be pulled in by sys-apps/portage dependencies which look like this: || ( dev-lang/python:2.8 dev-lang/python:2.7 dev-lang/python:2.6 =dev-lang/python-3 ) If you already have python:2.6 installed then it will not pull in a new slot. Won't emerge -aNuD pull it in anyway, even in a new slot, since portage says it can use it? I know I use that, so I'm always updated all the way thru the system, not just at the leaves. No, it won't. To prove it, I've just tested with a stable stage3 containing portage-2.1.7.x. Here are the steps: 1) extract stable stage3 and chroot into it 2) mkdir /etc/portage echo dev-lang/python ~* /etc/portage/package.keywords 3) Run `emerge -pu --deep=1 portage`: These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] sys-apps/sandbox-1.6-r2 [2.2] [ebuild UD] app-shells/bash-4.0_p35 [4.0_p37] [ebuild U ] dev-lang/python-2.6.4-r1 [2.6.4] If you try `emerge -puD world` then you will see dev-lang/python-3.1.1-r1 pulled in by the unspecific dev-lang/python atoms in the cracklib and libxml2 dependencies. However, in portage-2.1.7.x (current stable), there is support for pseudo-version-ranges in dependencies. This allows you use a dependency like dev-lang/python-3 in a package that doesn't support python3, and that will prevent it from getting pulled into the dependency graph. -- Thanks, Zac
[gentoo-dev] Re: RFC: News item for removal of 2008.0 and old hardened profiles
Ed W posted on Fri, 05 Mar 2010 23:33:43 + as excerpted: I think I have mostly upgraded my machines, but I completely agree - I sometimes let some old virtual machines sit unbooted for a year and then suddenly want to use them and bring them up to date and occasionally this can be a right old pain in the derrier... Surely, if you've let it go for a year, it's about as easy to reinstall from a new stage-3 as it is to try to update from where you are? At least that's a reasonably tested path, while trying to upgrade from a year out isn't going to be well tested at all. Plus, with the weekly stage-3 builds, you're pretty much up-to-date on at least the core packages, as soon as you've unpacked the stage-3. Sure, you then have to rebuild with your personally selected C(XX)FLAGS/USEflags to get the customization that most of us run Gentoo for, but at least you're working with relatively recent and well-tested versions, not trying a virtually untraveled and untested upgrade path, so if there /are/ any problems, they're very likely to be happening to others as well, and there will be answers out there ready to be applied, something that's not necessarily the case with year- out tree-only upgrades, as there may have been several upgrades in the mean time, with most folks tackling one at a time, and very few waiting a year and trying to handle all at once. -- 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
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On 03/05/2010 10:14 PM, Ryan Hill wrote: Because then people use them. Don't ask me why. I have things I deprecated over two years ago still being used by a dozen ebuilds bumped within the last three months. You should be familiar with this behaviour wrt. built_with_use. So, when I'm making changes I still have to maintain the deprecated stuff. built_with_use isn't using eerror and it wasn't scanned by repoman so unless you read the whole ebuild you could miss it when bumping. If we have devs ignoring eerrors out of the ebuild, then we should rather get rid of them. It's much harder to spot you are using a deprecated function when it doesn't exist at all as then the error message during emerge doesn't stand out in any form. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] [Last Rites] net-p2p/pysoulseek
# Ryan Hill dirtye...@gentoo.org (05 March 2010) # No release since 2004, succeeded by nicotine+ # Removal April 5, 2010 - bug #307971 net-p2p/pysoulseek -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Moving packages to dev-vcs
On 03/05/2010 07:18 PM, Sebastian Pipping wrote: On 03/05/10 18:10, Jeroen Roovers wrote: 4. Notify = [..] This step should probably include correcting all open bug reports' Summaries to point to the new category, so that CAT/PN can be found using the simple search interface. Good catch. Thanks for fixing those on monotone (and others I guess). Sebastian After the move is done could you please come up with a list of all the things you needed to take into account and then work with me for example to get it included in devmanual. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [rfc] making autotools.eclass depends flexible
On 03/05/2010 08:59 PM, Mike Frysinger wrote:
sometimes i have optional patches (ignoring the patches should always be
applied) where autotools should be run. always inheriting autotools is
currently annoying because it always adds the related dependencies. USE based
inherits are obviously out.
so unless there's some burgeoning standard i'm not aware of, below is what i
have in mind. packages set AUTOTOOLS_AUTO_DEPEND to no before inheriting
autotools.eclass and that allows them to put ${AUTOTOOLS_DEPEND} behind a USE
flag in their own DEPEND string.
What we use in Java is JAVA_PKG_OPT_USE to declare what use flag the
DEPENDs should be under. This approach doesn't allow the ebuild
maintainer to forget adding the depends.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-portage-dev] VCS used for development of portage
On 03/05/10 04:58, Zac Medico wrote: http://git.goodpoint.de/?p=portage.git;a=summary NOTE: Do not use it for development, yet - it's a demo! It looks very nice to me. I noticed that it preserved continuity when branches got moved around, so the history seems like it will be fully intact. Great job! Still, maybe we should not jump on this version yet: - with svn2git we could split it to several repositories easily (see [1] for status you on related experiments) - neither svn2git nor git-svn seem to support proper conversion of changes to svn:ignore Summer of code could help about the latter: http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2010_ideas#Add_support_for_svn:ignore_to_svn2git But pushing the conversion further into the future could also be a trade-off reducing efficiency and the number of contributions. I don't feel like proposing anything on that matter at the moment. With that said: what do you and Robin think? Sebastian [1] http://bugs.gentoo.org/show_bug.cgi?id=196025#c41
Re: [gentoo-portage-dev] VCS used for development of portage
On Fri, Mar 05, 2010 at 04:33:14PM +0100, Sebastian Pipping wrote: I don't feel like proposing anything on that matter at the moment. With that said: what do you and Robin think? Here's a related question. Did the previous CVS - SVN question generate the svn:ignore files from .cvsignore, or simply discard them? In either case, I'm starting to wonder if the change is just trivial enough to get done in svn2git or git-svn directly. I think other properties are already there. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
