[gentoo-dev] gentoo-news repository
Some devs have complained about the directory structure in the gentoo-news being too complicated. News item files are currently found in a third-level subdirectory: /MM/-MM-DD-itemname/ On the rsync side the year and month subdirs are absent: metadata/news/-MM-DD-itemname/ After discussion with zmedico (who is maintaining the repo-rsync script) I propose to remove the month subdirs at least, and possibly also the year dirs. This change would be invisible to users, who see only the rsync side. Opinions? Ulrich
Re: [gentoo-dev] gentoo-news repository
On Thu, Oct 8, 2009 at 12:08, Ulrich Mueller u...@gentoo.org wrote: Opinions? Sounds good, although it could get a bit crowded if we remove /, unless we remove really old items (like = 2 years old). -- Alex || wired
Re: [gentoo-dev] gentoo-news repository
On Thursday 08 October 2009 13:57:40 Alex Alexander wrote: On Thu, Oct 8, 2009 at 12:08, Ulrich Mueller u...@gentoo.org wrote: Opinions? Sounds good, although it could get a bit crowded if we remove /, unless we remove really old items (like = 2 years old). Crowded? I don't think so :) The number of news items is quite small, so I think we can afford having them all in the same folder -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sound/Sunrise] Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] gentoo-news repository
On Thu, Oct 8, 2009 at 14:07, Markos Chandras hwoar...@gentoo.org wrote: Crowded? I don't think so :) The number of news items is quite small, so I think we can afford having them all in the same folder I'm assuming devs will eventually pick this feature up and use it more often :) But yeah, as long as someone cleans up *really* old items, it shouldn't be a problem. -- Alex || wired
Re: [gentoo-dev] gentoo-news repository
Alex Alexander wrote: On Thu, Oct 8, 2009 at 14:07, Markos Chandras hwoar...@gentoo.org wrote: Crowded? I don't think so :) The number of news items is quite small, so I think we can afford having them all in the same folder I'm assuming devs will eventually pick this feature up and use it more often :) But yeah, as long as someone cleans up *really* old items, it shouldn't be a problem. I was planning to ask this already but now is a good time too. Last time we tried to remove a news item the client broke. Has the client since been fixed and in stable long enough to presume that most users have upgraded? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] gentoo-news repository
On Thu, 08 Oct 2009 15:29:25 +0300 Petteri Räty betelge...@gentoo.org wrote: I was planning to ask this already but now is a good time too. Last time we tried to remove a news item the client broke. Has the client since been fixed and in stable long enough to presume that most users have upgraded? No (under certain specific circumstances), but... https://bugs.gentoo.org/show_bug.cgi?id=287887 -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] gentoo-news repository
On Thu, 08 Oct 2009, Petteri Räty wrote: I was planning to ask this already but now is a good time too. Last time we tried to remove a news item the client broke. Has the client since been fixed and in stable long enough to presume that most users have upgraded? The news module in eselect-1.2.3 (which is being stabilised and is also included in the 10.0 release) doesn't fail any more if a news item was removed. See also bug 287887 [1] for a discussion how removed items should be handled. Ulrich [1] http://bugs.gentoo.org/show_bug.cgi?id=287887
Re: [gentoo-dev] Stabilization of Python 3.1
2009-09-20 20:46:17 Nirbheek Chauhan napisał(a): On Sun, Sep 20, 2009 at 11:57 PM, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: There is a difference between Python scripts and Python modules. Yes, I'm well aware of the difference between them. [snip] Python modules shouldn't have shebang. Python modules are intended to be imported from Python scripts or other Python modules. Any shebang in a Python module is ignored, when this module is imported using 'import' statement. You forget that the search path for both installs is different, and hence modules installed for python-3 cannot be found/used by scripts using python-2; which results in the dependency hell; which was the basis for my whole argument. When both Python 2 and Python 3 are installed, then Python modules, which support both Python 2 and Python 3, are automatically installed for both Python 2 and Python 3. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
Marijn Schouten (hkBst) wrote: Petteri Räty wrote: I wrote a script to check which ebuilds use built_with_use and have keywords in never versions making the ebuild unused. This means that neither arch or ~arch users are likely to install the ebuild. The script and the list of ebuilds is attached. I plan on removing all these ebuilds two weeks from now unless a reason is given why not to. If you see an ebuild on the list that should be kept, please migrate it to EAPI 2. If you need assistance in migrating, I can help. With these gone built_with_use usage will be down to about 600: I have some ebuilds on the list: plt-scheme, stklos, lilypond. I usually clean up unused ebuilds some time after a new version has gone stable. Anyway my question is: what is the point of removing unused versions in the proposed manner? If the newer version is not ported to EAPI 2 and also uses built_with_use what do we gain? Even if it is already ported, do we gain anything by the propsed removal? Are all unused ebuilds evil? It saves my time when removing built_with_use from packages that still have active versions using it. Many packages are also unmaintained so the versions with built_with_use don't get removed without doing something like this. If built_with_use is to be eliminated from the tree I propose that effort is directed towards porting and stabling ebuilds that still use it. After the stable version has begun using EAPI 2 use deps, then all uses of built_with_use in other versions can be considered obsolete and those ebuilds can be removed in one fell sweep if need be. It will be eliminated eventually. I am in the process of doing so but as you can see from the numbers it takes quite a lot of work to get rid of them. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
Stelian Ionescu wrote: On Tue, 2009-09-29 at 16:32 +0300, Petteri Räty wrote: I wrote a script to check which ebuilds use built_with_use and have keywords in never versions making the ebuild unused. This means that neither arch or ~arch users are likely to install the ebuild. The script and the list of ebuilds is attached. I plan on removing all these ebuilds two weeks from now unless a reason is given why not to. If you see an ebuild on the list that should be kept, please migrate it to EAPI 2. If you need assistance in migrating, I can help. With these gone built_with_use usage will be down to about 600: built_with_use shouldn't be removed until EAPI=3 gets approved because currently there's no good way to emulate --missing true|false|die yes, I can use something like this in sbcl: || ( sys-libs/glibc-2.6[nptl] =sys-libs/glibc-2.6 ) but not all its use cases may be this simple Even this is wrong because: betelge...@pena ~ $ portageq metadata / ebuild sys-libs/glibc-2.2.5-r10 IUSE nls For most packages old versions are not kept around so just doing =cat/foo-X.Y[use] is fine and EAPI 3 is not needed. I haven't come across a case that couldn't be done with EAPI 2 yet. Granted the atoms can be a bit cleaner with EAPI 3 but considering how much zmedico slacks in implementing it, it's best to do migrating now with EAPI 2 than EAPI 3 in the far future. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
On Thu, Oct 8, 2009 at 4:34 PM, Petteri Räty betelge...@gentoo.org wrote: Stelian Ionescu wrote: On Tue, 2009-09-29 at 16:32 +0300, Petteri Räty wrote: I wrote a script to check which ebuilds use built_with_use and have keywords in never versions making the ebuild unused. This means that neither arch or ~arch users are likely to install the ebuild. The script and the list of ebuilds is attached. I plan on removing all these ebuilds two weeks from now unless a reason is given why not to. If you see an ebuild on the list that should be kept, please migrate it to EAPI 2. If you need assistance in migrating, I can help. With these gone built_with_use usage will be down to about 600: built_with_use shouldn't be removed until EAPI=3 gets approved because currently there's no good way to emulate --missing true|false|die yes, I can use something like this in sbcl: || ( sys-libs/glibc-2.6[nptl] =sys-libs/glibc-2.6 ) but not all its use cases may be this simple Even this is wrong because: betelge...@pena ~ $ portageq metadata / ebuild sys-libs/glibc-2.2.5-r10 IUSE nls For most packages old versions are not kept around so just doing =cat/foo-X.Y[use] is fine and EAPI 3 is not needed. I haven't come across a case that couldn't be done with EAPI 2 yet. Granted the atoms can be a bit cleaner with EAPI 3 but considering how much zmedico slacks in implementing it, it's best to do migrating now with EAPI 2 than EAPI Comments like these are not acceptable. Zac works his tail off on portage. Please refrain from such comments in the future. -Jeremy 3 in the far future. Regards, Petteri
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
Jeremy Olexa wrote: On Thu, Oct 8, 2009 at 4:34 PM, Petteri Räty betelge...@gentoo.org wrote: Stelian Ionescu wrote: On Tue, 2009-09-29 at 16:32 +0300, Petteri Räty wrote: I wrote a script to check which ebuilds use built_with_use and have keywords in never versions making the ebuild unused. This means that neither arch or ~arch users are likely to install the ebuild. The script and the list of ebuilds is attached. I plan on removing all these ebuilds two weeks from now unless a reason is given why not to. If you see an ebuild on the list that should be kept, please migrate it to EAPI 2. If you need assistance in migrating, I can help. With these gone built_with_use usage will be down to about 600: built_with_use shouldn't be removed until EAPI=3 gets approved because currently there's no good way to emulate --missing true|false|die yes, I can use something like this in sbcl: || ( sys-libs/glibc-2.6[nptl] =sys-libs/glibc-2.6 ) but not all its use cases may be this simple Even this is wrong because: betelge...@pena ~ $ portageq metadata / ebuild sys-libs/glibc-2.2.5-r10 IUSE nls For most packages old versions are not kept around so just doing =cat/foo-X.Y[use] is fine and EAPI 3 is not needed. I haven't come across a case that couldn't be done with EAPI 2 yet. Granted the atoms can be a bit cleaner with EAPI 3 but considering how much zmedico slacks in implementing it, it's best to do migrating now with EAPI 2 than EAPI Comments like these are not acceptable. Zac works his tail off on portage. Please refrain from such comments in the future. -Jeremy He has said himself that he is not especially interested in implementing EAPI 3 so slack at least to me seems like a good term. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
On čtvrtek 08 Říjen 2009, 23:34:10 Petteri Räty wrote: Even this is wrong because: Hi ... betelge...@pena ~ $ portageq metadata / ebuild sys-libs/glibc-2.2.5-r10 IUSE nls For most packages old versions are not kept around so just doing =cat/foo-X.Y[use] is fine and EAPI 3 is not needed. I haven't come across a case that couldn't be done with EAPI 2 yet. Granted the atoms can be a bit cleaner with EAPI 3 but considering how much zmedico slacks in implementing it, it's best to do migrating now with EAPI 2 than EAPI 3 in the far future. This is not exactly nice of you. And taking in account that you are actualy the council member it makes me feel not entirely happy. If we just simply take look onto this: http://cia.vc/stats/author/zmedico/ we can count that Zac commit something into portage every 3 hours. It does not look entirely like slacking... So you are basicaly proposing that maintaining the current codebase and improving what we already have is less important than providing new features, that is also not good. Just my 2 cents Tomas
Re: [gentoo-dev] Unused ebuild built_with_use cleanup
On Friday 09 October 2009 00:22:26 Petteri Räty wrote: across a case that couldn't be done with EAPI 2 yet. Granted the atoms can be a bit cleaner with EAPI 3 but considering how much zmedico slacks in implementing it, it's best to do migrating now with EAPI 2 than EAPI Comments like these are not acceptable. Zac works his tail off on portage. Please refrain from such comments in the future. -Jeremy He has said himself that he is not especially interested in implementing EAPI 3 so slack at least to me seems like a good term. I'm not sold on it either. Most devs barely know the difference between different EAPIs (just extrapolating from the many questions I see e.g. on IRC) (and I think they shouldn't have to know because we should be using one EAPI only, but that's just my random opinion) Most ebuilds are still EAPI0 - rough count gives me: EAPI 0 - 19654 EAPI 1 - 1651 EAPI 2 - 5497 And that's with all the forced migrations for features like use-deps or the removal of built_with_use. So unless there's some strongly needed features there's no need for it. I can't remember any feature in the EAPI 3 list that really looked useful to me, so not adding it now now now doesn't bother me at all. Just causes more confusion for no real benefit. So who cares if it is delayed by a few timeunits, there's much more important stuff to do.
