Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
Zeerak Mustafa Waseem wrote: On Sun, Mar 07, 2010 at 09:08:14PM -0600, Ryan Hill wrote: A stable user who doesn't want python 3 installed shouldn't have it forced on them. If something is pulling in python-3 then that package needs to have its dependencies fixed. IIRC Portage isn't greedy wrt. SLOTs like it was before (unless you use @installed) so it shouldn't be pulled in by anything that doesn't require it. +1 on that. If your program is only tested with python-2 or has regressions with python-3 (e.g. performance loss), a maintainer can and should mark that package as python-2 only. For new systems, the only must have python user i can think of is portage. And that has an explicit USE=python3 and as Zac outlined takes DEPEND-pains to ensure python-2.* is pulled in if available. So you're starting with python-2.* and every program not explicitly pulling in python-3.* should be happy with that. I think that is being said is, due to python 3 being unnecessary for majority of users, due to a small number of applications actually using it, it should be in ~arch. You're actually damning most of the tree to be ~arch, if that's the criterion for stable. Of course an application that depends on python 3, but is entirely stable should not be marked testing (to my reckoning at least). I think the best way to go about it is to set python-3 in ~arch. These are contradicting statements. Repoman will and should kill anyone attempting to do that. All [R,]DEPENDS of an ebuild must be stable, if that ebuild is to be marked stable, too. So b/c i still can't understand what's so horrible about python-3 going into stable (even if p.mask'ed, if that's the consensus), my vote goes to mark it stable already. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
Matti Bickel dixit (2010-03-08, 10:39): A stable user who doesn't want python 3 installed shouldn't have it forced on them. If something is pulling in python-3 then that package needs to have its dependencies fixed. IIRC Portage isn't greedy wrt. SLOTs like it was before (unless you use @installed) so it shouldn't be pulled in by anything that doesn't require it. +1 on that. If your program is only tested with python-2 or has regressions with python-3 (e.g. performance loss), a maintainer can and should mark that package as python-2 only. For new systems, the only must have python user i can think of is portage. And that has an explicit USE=python3 and as Zac outlined takes DEPEND-pains to ensure python-2.* is pulled in if available. So you're starting with python-2.* and every program not explicitly pulling in python-3.* should be happy with that. I think that is being said is, due to python 3 being unnecessary for majority of users, due to a small number of applications actually using it, it should be in ~arch. You're actually damning most of the tree to be ~arch, if that's the criterion for stable. Of course an application that depends on python 3, but is entirely stable should not be marked testing (to my reckoning at least). I think the best way to go about it is to set python-3 in ~arch. These are contradicting statements. Repoman will and should kill anyone attempting to do that. All [R,]DEPENDS of an ebuild must be stable, if that ebuild is to be marked stable, too. So b/c i still can't understand what's so horrible about python-3 going into stable (even if p.mask'ed, if that's the consensus), my vote goes to mark it stable already. Sorry guys if I missed something crucial in this lengthy thread, but from what I'm understanding: if python-3 goes stable (and unmasked): - it is a separate, slotted version - it generally shouldn't get pulled in (current portage non-greedy behaviour on slots) - if it does get pulled in by, say, and old portage version, or a package with badly defined deps, it shouldn't do any harm because it will just sit quietly in its slot and old packages will still compile/run against (already installed) python-2.x or not? PS. one thing I realize I may be missing is the /usr/bin/python symlink and the /usr/bin/python-wrapper to which it points. Will the default change to python31 upon python-3 installation? best, -- [a] pgpQJOsKfpDsQ.pgp Description: PGP signature
[gentoo-dev] Low hanging bug fruit patterns
Hello! There are a few patterns for potentially low hanging fruits among Gentoo bugs: SRC_URI errors Missing depencies ... What else? Anything you look after repeatedly that doesn't take days to get it fixed? Sebastian
Re: [gentoo-dev] Low hanging bug fruit patterns
On Mon, 08 Mar 2010 11:06:40 +0100 Sebastian Pipping sp...@gentoo.org wrote: There are a few patterns for potentially low hanging fruits among Gentoo bugs: SRC_URI errors Missing depencies (Sorry for answering a developer targeted question while I'm not one.) - Minor version bumps (After examination what upstream changed and after confirmation with mantainer, if any.) And perhaps also: - Stable requests - New ebuilds Robert -- Robert Cernansky E-mail: hslis...@zoznam.sk Jabber: h...@jabber.sk
Re: [gentoo-dev] Low hanging bug fruit patterns
On Monday 08 March 2010 12:06:40 Sebastian Pipping wrote: Hello! There are a few patterns for potentially low hanging fruits among Gentoo bugs: SRC_URI errors Missing depencies ... What else? Anything you look after repeatedly that doesn't take days to get it fixed? Sebastian Documentation installation There are few packages that call missing documents on dodoc commands -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org
[gentoo-dev] Re: Re: Python 3.1: Stabilization and news item
mån 2010-03-08 klockan 10:53 +0100 skrev Antoni Grzymala: Sorry guys if I missed something crucial in this lengthy thread, but from what I'm understanding: if python-3 goes stable (and unmasked): - it is a separate, slotted version - it generally shouldn't get pulled in (current portage non-greedy behaviour on slots) - if it does get pulled in by, say, and old portage version, or a package with badly defined deps, it shouldn't do any harm because it will just sit quietly in its slot and old packages will still compile/run against (already installed) python-2.x or not? PS. one thing I realize I may be missing is the /usr/bin/python symlink and the /usr/bin/python-wrapper to which it points. Will the default change to python31 upon python-3 installation? best, AFAICS you are right (and that is also why I have a hard time understanding the flames here, are people so against fixing the deps in their packages and/or filing bugs and/or contacting devrel about those maintainers who refuse to fix their packages?). about your ps: pyhon-3 is absolutely harmless in its current form, and that is partly because it does not take over the role as the system python unless you do something stupid/uninformed.
Re: [gentoo-dev] Re: Re: Python 3.1: Stabilization and news item
On 8.3.2010 16.23, Peter Hjalmarsson wrote: AFAICS you are right (and that is also why I have a hard time understanding the flames here, are people so against fixing the deps in their packages and/or filing bugs and/or contacting devrel about those maintainers who refuse to fix their packages?). There's some history with the original author that contributes to people being negative about this. This is not the first thread about python-3 and many feel that it's being forced on them when they have no use for it (but the forcing part doesn't match reality that much any more as has been shown). I don't think anyone is against fixing the deps but who takes the job of reviewing them all? Regards, Petteri
Re: [gentoo-dev] Low hanging bug fruit patterns
On Seg, 2010-03-08 at 11:06 +0100, Sebastian Pipping wrote: Hello! There are a few patterns for potentially low hanging fruits among Gentoo bugs: SRC_URI errors Missing depencies ... What else? Anything you look after repeatedly that doesn't take days to get it fixed? Sebastian * Missing/crappy ebuild USE flag description on metadata. That is something, I think, that always help users. There is nothing worse than rebuilding a entire package just because the USE flag purpose was not what we think it was. Regards, -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] Low hanging bug fruit patterns
Sebastian Pipping sp...@gentoo.org said: Hello! There are a few patterns for potentially low hanging fruits among Gentoo bugs: SRC_URI errors Missing depencies ... What else? Anything you look after repeatedly that doesn't take days to get it fixed? What is this even in reference to? Its not at all clear what you are trying to do. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com signature.asc Description: Digital signature
[gentoo-dev] Reorganizing handling of target specific profiles (Was: Split desktop profile patches news item for review)
Hello, On Thu, 2010-03-04 at 16:52 +0200, Theo Chatzimichos wrote: Hello I have managed to split the desktop profile to gnome and kde submenus. The result can be found in kde-crazy overlay (not in layman) [1] I think this whole approach of adding yet more subprofiles is highly suboptimal. You are wanting to add at least 28 more subprofiles (the number would reach the 80s if including hardened/mips, etc), whereas we just had a sort-of discussion on how we have too many of them already at http://archives.gentoo.org/gentoo-dev/msg_be393426980d12f341cabccfe5ab10aa.xml Instead I think we should be improving eselect profile to support multiple inheriting /etc/make.profile files in a user friendly fashion, and in the end removing 249 subprofiles, instead of adding 28+. Also, even after doing the addition of kde/gnome subprofiles, users would like a better eselect profile for multi-inheriting, if they use both GNOME and KDE on the same system (using both once in a while, or multiple users on the same machine), as gnome/kde specific USE flags would be only in their separate subprofiles then, and you want both. So what I believe should be done instead of adding yet more subprofiles is improving eselect profile to have good support for multi-inheriting /etc/make.profile With at least portage, one can have /etc/make.profile/ be a directory, which is basically a user created profile in its own right, whereas with the symlink to profile directory method, the toplevel profile used is simply one in $PORTDIR/profiles/. Through that one can do a multi-inheriting profile, so you could have a parent file in there, with the following contents: /usr/portage/profiles/default/linux/amd64/10.0 /usr/portage/profiles/targets/desktop And you would effectively have the same as a symlink pointing to /usr/portage/profiles/default/linux/amd64/10.0/desktop Now as targets/ don't really do anything more than add USE flags to the global set or package.use, we could support adding targets to the basic release set for an arch with eselect profile, so one could add both a future gnome and a kde target, if desired. Or even also server flags as well, if so desired by the user. And that without having to have all those subprofiles per-arch/per-release profiles. Once users are converted over to that method, there's no need for all the target specific subprofiles we currently have. This at the last count was 249 subprofiles for all the per-arch desktop/, server/ and developer/ subprofiles, and we could remove them all, or simply phase out when the 10.0 release phases out, replaced with a new release that doesn't have the desktop/server/developer subprofiles in the first place - giving a good migration and phase-out point. So the steps for implementing this would be something like the following: * Improve eselect profile to have user friendly support for multi-inheriting /etc/make.profile/, possibly special casing targets/ as an add-on option/flag sort of thing. * Test and stabilize the eselect-profile with those features * Introduce the new gnome/kde targets and reorganize things. I would suggest a new directory for this, that can have the options that eselect-profile allows to add-on easily. For example basic-desktop, gnome, kde, gentoo-developer, server, and so on - internally we can inherit things as desired in there as an implementation detail (gnome and kde can inherit from basic-desktop). Even adding lxde and xfce targets is fine and simple, they can just inherit basic-desktop and users don't need to find out that to get a target suitable for xfce, they would have to go with the broad desktop or basic-desktop target. If targets is the best directory name for it, then that's fine too. The current ones can be moved away to somewhere else, atomically with tweaking all the inherits from default/ and hardened/ profiles at the same time. * Possibly have a new release set, that has no subprofiles from the start, and can be accompanied with all the news and awareness raising it takes to get users use this new method. * All the things I forgot about. * Eventually phase out completely the previous exponentially increasing subprofiles mess. 3) Profit. Obviously I doubt to have time to work on it personally. I hope the guys pushing for adding even more subprofiles can pick up this idea and implement it, if discussion gives consensus this is a good way forward. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://blogs.gentoo.org/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Low hanging bug fruit patterns
On 03/08/10 18:08, Mark Loeser wrote: What is this even in reference to? Its not at all clear what you are trying to do. Okay, sorry. I was wondering what classes of bugs there are that are - reoccuring (therefore beloning to a class or pattern) - relatively easy to fix - ideally suited for non-maintainer updates, i.e. stuff where the original maintainer just won't mind that you touched his ebuild, even if he feels more or less like its owner From such patterns I expect: - to find candidates more easy when I myself want to fix something within limited time - raising awareness on these bugs in hope other feel motivated to look outr and fix for some of those, too. - use these patterns to find future bugday candidates A bit clearer now? Sebastian
Re: [gentoo-dev] Low hanging bug fruit patterns
On 03/08/10 14:27, Markos Chandras wrote: Documentation installation There are few packages that call missing documents on dodoc commands any idea how to find all these bugs? sebastian
Re: [gentoo-dev] Low hanging bug fruit patterns
On 03/08/10 14:13, Róbert Čerňanský wrote: On Mon, 08 Mar 2010 11:06:40 +0100 Sebastian Pipping sp...@gentoo.org wrote: There are a few patterns for potentially low hanging fruits among Gentoo bugs: SRC_URI errors Missing depencies (Sorry for answering a developer targeted question while I'm not one.) happy to have your input. - Minor version bumps (After examination what upstream changed and after confirmation with mantainer, if any.) needs good care and a little luck, but still, yes. - Stable requests only if you're an arch tester. - New ebuilds that's a tough one too, because it's often not a good idea to pull something into the tree, e.g. when you don't use it yourself on a regular basis. i have done that before, but i think twice by now. sebastian
Re: [gentoo-dev] Low hanging bug fruit patterns
On Monday 08 March 2010 05:06:40 Sebastian Pipping wrote: There are a few patterns for potentially low hanging fruits among Gentoo bugs: work with the bugday guys to get this incorporated into their documentation SRC_URI errors Missing depencies ... What else? incorrect LICENSE / HOMEPAGE -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Moving packages to dev-vcs
On 04-03-2010 22:08:06 +0100, Sebastian Pipping wrote:
3. Remove
=
- Remove package dev-util/${PN} from CVS (as in [2])
cd dev-util
cvs rm -Rf ${PN}
cvs ci -m dev-util/${PN}: Remove (renamed to dev-vcs/${PN}) ${PN}
^
- Remove any traces of dev-util/${PN} in profiles/
Please take masks for packages you move into account for /all/ profiles.
--
Fabian Groffen
Gentoo on a different level
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
On Fri, Mar 05, 2010 at 04:19:36PM -0800, Zac Medico wrote: 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 According to this, we can fix all of the dependencies in the tree then stabilize python3 without having any issues, so I would vote for this route, because it still oinsures that the stable tree will work together. William pgpNaLSlmgYgl.pgp Description: PGP signature
[gentoo-dev] Re: Reorganizing handling of target specific profiles (Was: Split desktop profile patches news item for review)
mån 2010-03-08 klockan 19:13 +0200 skrev Mart Raudsepp: Instead I think we should be improving eselect profile to support multiple inheriting /etc/make.profile files in a user friendly fashion, and in the end removing 249 subprofiles, instead of adding 28+. I vote for this one. A profile being a only contains what is interesting for that profile, and you can stash together some profiles into your own cocktail. Yeah, I know it sounds horrible, but it would still be better then to only be able to focus on one small set. For example if I am using the GNOME DE, and have someone other also using my computer, but who really wants to use KDE. Should I have to find out what from the KDE profile to enable in my env to make my GNOME-profile also tingle for KDE? I think having a set of base profiles for toolchains and alike (i.e. default, hardened) would be good. Then be able to add for example desktop/gnome or server and/or selinux profiles on top would be interesting. This also for maintainers, as for example PeBenito can focus on the selinux part of the profiles, and do not have to keep up to date with which hardened-compilers are currently masked/unmasked.
Re: [gentoo-dev] Re: Reorganizing handling of target specific profiles (Was: Split desktop profile patches news item for review)
Hehe, http://dev.gentoo.org/~antarus/essays/mixin-profiles.txt -rw-r--r-- 1 antarus users 2653 Jun 4 2006 mixin-profiles.txt -A On Mon, Mar 8, 2010 at 2:40 PM, Peter Hjalmarsson x...@rymdraket.net wrote: mån 2010-03-08 klockan 19:13 +0200 skrev Mart Raudsepp: Instead I think we should be improving eselect profile to support multiple inheriting /etc/make.profile files in a user friendly fashion, and in the end removing 249 subprofiles, instead of adding 28+. I vote for this one. A profile being a only contains what is interesting for that profile, and you can stash together some profiles into your own cocktail. Yeah, I know it sounds horrible, but it would still be better then to only be able to focus on one small set. For example if I am using the GNOME DE, and have someone other also using my computer, but who really wants to use KDE. Should I have to find out what from the KDE profile to enable in my env to make my GNOME-profile also tingle for KDE? I think having a set of base profiles for toolchains and alike (i.e. default, hardened) would be good. Then be able to add for example desktop/gnome or server and/or selinux profiles on top would be interesting. This also for maintainers, as for example PeBenito can focus on the selinux part of the profiles, and do not have to keep up to date with which hardened-compilers are currently masked/unmasked.
Re: [gentoo-dev] Low hanging bug fruit patterns
On Mon, 08 Mar 2010 14:13:30 +0100 Róbert Čerňanský hslis...@zoznam.sk wrote: - Minor version bumps (After examination what upstream changed and after confirmation with mantainer, if any.) The stuff you put in brackets is exactly the sort of stuff that tends to make version bumps hard to fix. You would first have to determine what major/minor means, on a per package-version basis, so these aren't really as trivial to fix as (non) package maintainer as a minor version change might suggest. Also, any version bump is a splendid occasion on which to revise the ebuild (introduce missing features, check for novel QA issues, move up an EAPI to cut out a few build phases, review COPYING to make sure the LICENSE variable is still OK, figure out that one slight syntax change might serve to fix a compilation error with a newer-toolchain-than-you-use). So I generally don't regard a version bump as a low hanging fruit, as you might end up painfully ignoring the wasps' nest hanging directly beside it. jer
Re: [gentoo-dev] Reorganizing handling of target specific profiles (Was: Split desktop profile patches news item for review)
On Mon, Mar 08, 2010 at 07:13:20PM +0200, Mart Raudsepp wrote: Hello, On Thu, 2010-03-04 at 16:52 +0200, Theo Chatzimichos wrote: Hello I have managed to split the desktop profile to gnome and kde submenus. The result can be found in kde-crazy overlay (not in layman) [1] I think this whole approach of adding yet more subprofiles is highly suboptimal. You are wanting to add at least 28 more subprofiles (the number would reach the 80s if including hardened/mips, etc), whereas we just had a sort-of discussion on how we have too many of them already at http://archives.gentoo.org/gentoo-dev/msg_be393426980d12f341cabccfe5ab10aa.xml Instead I think we should be improving eselect profile to support multiple inheriting /etc/make.profile files in a user friendly fashion, and in the end removing 249 subprofiles, instead of adding 28+. Consider me to be a huge fan of this idea. I'm already using it with my managed-portage system that I posted some months ago. Beware that some of the non-Portage PMs don't behave quite right with it yet. ferringb was working on fixing pkgcore with I had noted to him with the profiles. I'm not sure about Paludis off the top of my head. We'd be saving at least 655 inodes on disk (in an rsync copy of the tree, add another 1k inodes for a CVS checkout). -- 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
[gentoo-dev] Google Summer of Code 2010
Hey folks, We're applying to be in Google's 2010 Summer of Code, and we need your project ideas! If you've got a todo list a mile long and no chance of ever getting to them all, now's your chance to have someone else spend a summer working full-time on your idea. We're looking for things that would be suitable for an undergrad CS student who has little to no experience working on Gentoo but good programming skills. They should be a reasonably cohesive medium-scale project (so, not all open bugs assigned to kde@). You can put your ideas to the ideas page [1]. Please add them by this Friday because they will help our chances of getting into this year's Summer of Code. We should know whether we're in by March 18. At that point, developers, please let me know whether you're interested in mentoring for this year's program. 1. http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2010_ideas -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com
