Re: [gentoo-dev] Re: [rfc] layman storage location (again)
On Sun, Jan 17, 2010 at 12:55 AM, Sebastian Pipping sp...@gentoo.org wrote: On 01/16/10 23:46, Benedikt Böhm wrote: One thing all you /usr naggers forget is, that /var cannot be shared read-only via nfs (or bind mounts in case of virtual servers). Why is that? Please tell more. Maybe you should actually read the FHS. You can of course share specific subdirectories of /var read-only and still be compliant, but /usr is specifically designed to be completely shareable read-only.
Re: [gentoo-dev] adding a modification timestamp to the installed pkgs database (vdb)
2010/1/12 Brian Harring ferri...@gmail.com: There's no discussion because Brian refuses to address any comments on the proposal and just says we should do it anyway, and if you want it done properly instead, do it yourself. This is a bit of bullshit, per the norm. There is plenty of discussion- the problem is you don't like the direction it's gone. You want a whole new vdb- I don't oppose that. However I'm not interested in trying to standardize a new vdb format into PMS, at least not yet. No, I want a decent cache proposal that lets package managers know what's changed, not one that sometimes (but not always) might let package managers know when some things have changed, but not what's changed and not what they can still assume. Your argument can basically be summed up as don't do the minimal tweak, do the whole new vdb with defined caches that all can share. No, I want the well defined caches that all can share. The daft thing about this is that you're ignoring one core transition issue w/ vdb2- if someone did create a vdb2, they still would need a synchronization mechanism (one quite similar to what I'm proposing). If you replace VDB, you need a well defined cache mechanism. So let's do that bit now. 1) portage/pkgcore support the PMS defined vdb2 while paludis doesn't 2) portage/pkgcore are invoked modifying the livefs; vdb1, vdb2 is updated. 3) paludis is invoked. vdb1 is updated, vdb2 is not 4) portage and pkgcore now cannot rely upon vdb2, since vdb1 now contains extra modifications due to paludis not supporting vdb2. No, we'd not do it that way. If we're ditching VDB, the only sane way to do it is to ditch it with an rm -fr when creating the new layout. Keeping two sets of data around is going to lead to breakage no matter how well we do things. Summarizing; the synchronization primitive is needed for any future vdb2 No. A *proper* cache validation mechanism is needed. What you're suggesting isn't enough to use for anything at all. Summing it up; what ciaran wants is reliant on what I'm proposing, No, what I want in the long term is reliant upon implementing a decent cache setup in the short term. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [rfc] layman storage location (again)
2010/1/15 Sebastian Pipping sp...@gentoo.org: By default layman currently stores overlays into /usr/local/portage/layman (was /usr/portage/local/layman before that). As of bug 253725 [1] that's not without problems. I would like to get it right with the next switch. I realise this is a lost cause, but... Repositories are databases, so /var/db/ is your friend. -- Ciaran McCreesh
Re: [gentoo-dev] adding a modification timestamp to the installed pkgs database (vdb)
2010/1/17 Tobias Klausmann klaus...@gentoo.org: No, we'd not do it that way. If we're ditching VDB, the only sane way to do it is to ditch it with an rm -fr when creating the new layout. Keeping two sets of data around is going to lead to breakage no matter how well we do things. Please also provide a downgrade path, i.e. a way to go back from the new DB version to the current one should it be necessary (if there is no such path, Murphy will see to it that the new format breaks in interesting[0] ways). That probably wouldn't be possible. One of the reasons we want to ditch VDB is to allow multiple slots of the same cat/pkg-ver to be installed in parallel (which is in turn necessary to allow some of the more hideous dynamic slot abuses that people are after). VDB doesn't support that, so you probably won't be able to go back once you've started using new features. *shrug* all of this is years off, anyway. It's at least EAPI 5 territory. We can work all this out later if EAPI 4 ever happens. -- Ciaran McCreesh
Re: [gentoo-dev] Re: adding a modification timestamp to the installed pkgs database (vdb)
2010/1/17 Christian Faulhammer fa...@gentoo.org: Ciaran McCreesh ciaran.mccre...@googlemail.com: As much as you love to have the new and shiny VDB2, it is far off. Prototyping and drafting implementations would be great to have some base where we can discuss on (in a civil manner). So having this timestamp would be a good way to prepare a sane migration path. No, it wouldn't. Brian's proposal a) would be of no use whatsoever for VDB2 migration, and b) would not be used by VDB2. Having a *decent* cache validation mechanism is a good idea; having a half-baked one is a waste of time. -- Ciaran McCreesh
[gentoo-dev] LibGL.la removal news item for =eselect-opengl-1.1.1-r2 going stable
Howdy guys, please review the attached file and suggest updates to in. I was asked for this thing going stable due to its being dependency of new nvidia-drivers. Also this thing is probably blocker for the bug on eselect-opengl i just opened: http://bugs.gentoo.org/show_bug.cgi?id=301271 Cheers Tomáš Chvátal Gentoo Linux Developer [KDE/Overlays/QA/X11] E-Mail : scarab...@gentoo.org GnuPG FP: 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587 GnuPG ID: 03414587 Title: Removal of libGL.la Author: Tomáš Chvátal scarab...@gentoo.org Content-Type: text/plain Posted: 2010-01-20 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: app-admin/eselect-opengl-1.1.1-r2 Eselect-opengl package now strips the libGL.la file. This file was broken and thus we proceeded with its removal. It brings slight inconvenience on you fellow users. After emerging the new version =app-admin/eselect-opengl-1.1.1-r2 please emerge one more package dev-util/lafilefixer and use it for fixing all various compilation issues by running as root: # lafilefixer --just-fixit Note that not-running this command will bring you compilation issues so you should really pay attention to this message and act upon it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [rfc] layman storage location (again)
Am Samstag 16 Januar 2010 19:26:04 schrieb Sebastian Pipping: On 01/16/10 13:56, Ben de Groot wrote: anybody objecting to /var/layman ? I like that. it seems that /var/layman is the only location nobody has objected to, yet. i plan to go with that atm. /var/lib/layman is my second favorite. again, any objections? sebastian +1 -- Lars Wendler (Polynomial-C) Gentoo Staffer and bug-wrangler signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] LibGL.la removal news item for =eselect-opengl-1.1.1-r2 going stable
2010/1/17 Paweł Hajdan, Jr. phajdan...@gentoo.org: I wonder why the affected package (eselect-opengl) couldn't run lafilefixer itself. It's mandatory for all users, and would save a lot of frustration. Indeed. You can simply have this version of eselect-opengl depend on lafilefixer and run it in pkg_postinst. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] [rfc] layman storage location (again)
On 01/17/10 10:01, Ciaran McCreesh wrote: I realise this is a lost cause, but... Repositories are databases, so /var/db/ is your friend. Right, that's a way you can see it. Does anyone _strongly_ prefer /var/db/layman over /var/layman ? Sebastian
Re: [gentoo-dev] LibGL.la removal news item for =eselect-opengl-1.1.1-r2 going stable
On 1/17/10 6:57 PM, Vaeth wrote: On Sun, 17 Jan 2010, Paweł Hajdan, Jr. wrote: I wonder why the affected package (eselect-opengl) couldn't run lafilefixer itself. It's mandatory for all users, and would save a lot of frustration. It is not mandatory: You could as well re-emerge the affected packages (shown by revdep-rebuild) which is a much cleaner solution, since it does not break the portage database like lafilefixer does. I see. To be more precise, I meant something must be done to have a not-broken system. Please: When you run tools which break checksums/dates of the database, give the user the possibility to decide whether he really wants this. Good point, I didn't realize that. However, I'd rather fix the tool (for example to update the portage database). Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] LibGL.la removal news item for =eselect-opengl-1.1.1-r2 going stable
On 01/17/10 18:20, Paweł Hajdan, Jr. wrote: Please: When you run tools which break checksums/dates of the database, give the user the possibility to decide whether he really wants this. Good point, I didn't realize that. However, I'd rather fix the tool (for example to update the portage database). Nope, that's a bad idea unless you plan to implement such feature for portage, paludis and pkgcore (and possibly other package managers). So use revdep-rebuild (longer but correct solution) or lafilefixer (quicker but introduces other problems). -- Krzysiek Pawlik nelchael at gentoo.org key id: 0xBC51 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] LibGL.la removal news item for =eselect-opengl-1.1.1-r2 going stable
On 1/17/10 7:28 PM, Krzysiek Pawlik wrote: On 01/17/10 18:20, Paweł Hajdan, Jr. wrote: Please: When you run tools which break checksums/dates of the database, give the user the possibility to decide whether he really wants this. Good point, I didn't realize that. However, I'd rather fix the tool (for example to update the portage database). Nope, that's a bad idea unless you plan to implement such feature for portage, paludis and pkgcore (and possibly other package managers). So use revdep-rebuild (longer but correct solution) or lafilefixer (quicker but introduces other problems). Hmm... last time I tried revdep-rebuild for that problem it either didn't notice something was wrong, or couldn't finish without manual assistance. How about fixing lafilefixer in an other way: it knows which .la files are broken. Instead of changing their contents, it can re-emerge the packages they belong to. But then it probably can't be run automatically by the ebuild (nested emerges). On the other hand, I really wonder how useful the checksums in portage db really are. It includes config files which are frequently modified. It also doesn't include config files the administrator has to create. So for example for verifying system integrity is seems useless to me. I'd expect only a limited group of users caring about the checksum database, and the majority of affected users caring about the update to just work (which running lafilefixer --just-fixit automatically would buy us). Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] LibGL.la removal news item for =eselect-opengl-1.1.1-r2 going stable
Please: When you run tools which break checksums/dates of the database, give the user the possibility to decide whether he really wants this. Good point, I didn't realize that. However, I'd rather fix the tool (for example to update the portage database). On the other hand, I really wonder how useful the checksums in portage db really are. It includes config files which are frequently modified. It also doesn't include config files the administrator has to create. So for example for verifying system integrity is seems useless to me. I'd expect only a limited group of users caring about the checksum database, and the majority of affected users caring about the update to just work (which running lafilefixer --just-fixit automatically would buy us). http://trac.mcs.anl.gov/projects/bcfg2/wiki/Gentoo Section Package Verification Issues contains one example of why checksums should be consistent.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
Ben de Groot yng...@gentoo.org said: I think we have a bigger problem with packages that have a maintainer, at least nominally, but said maintainer does not actually maintain the package anymore. full ack. i was thinking that maybe we need an 'easy-fix' team, which can do all the easy fixes, which have been laying around for way too long and which aparently are easy to fix (ie. only waiting for somebody to commit)... the details would stil have to be thought through, but anything which improves the felt responsitivity for our users can only be good. Did you know: Gentoo is dying! ;-) kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [rfc] layman storage location (again)
Ciaran McCreesh ciaran.mccre...@googlemail.com said: I realise this is a lost cause, but... Repositories are databases, so /var/db/ is your friend. i like it. Closely followed by /var/lib/layman... wikipedia says in http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard /var/lib/ State information. Persistent data modified by programs as they run, e.g., databases, packaging system metadata, etc. /var/layman i dislike due to this sentence in the FHS: Applications must generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication[...] IMHO layman does not qualify. i am not religious on these things, however. kind regards Thilo signature.asc Description: This is a digitally signed message part.
[gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
With GLEP 42 and proper logging of e* messages I think we shouldn't
annoy users any more with ebeep or epause so attached is a patch only
defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
keep these around for EAPI 3? If not I will apply the attached patch.
Regards,
Petteri
Index: eutils.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v
retrieving revision 1.328
diff -u -r1.328 eutils.eclass
--- eutils.eclass 10 Jan 2010 15:58:58 - 1.328
+++ eutils.eclass 17 Jan 2010 20:37:05 -
@@ -19,6 +19,8 @@
DESCRIPTION=Based on the ${ECLASS} eclass
+if has ${EAPI:-0} 0 1; then
+
# @FUNCTION: epause
# @USAGE: [seconds]
# @DESCRIPTION:
@@ -49,6 +51,8 @@
fi
}
+fi
+
# @FUNCTION: ecvs_clean
# @USAGE: [list of dirs]
# @DESCRIPTION:
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Election for the Gentoo Council empty seat results (council200912)
Hello fellow devs, users and Gentoo community, in this election we received 87 valid ballots from a total of 260 voters, which means we had a 33.462% turnout. Without much ado, Tomas Chvatal (scarabeus) was elected to the council. The full ranked list for this election is: scarabeus patrick wired tanderson dev-zero _reopen_nominations Let me congratulate Tomas and thank all nominees for running in the election as well as all Gentoo Developers that participated in the election by casting their vote. The master ballot[1] and the full result sheet[2] are attached to this mail and will also be accessible shortly under the elections project space. The personal confirmation emails should have arrived by now. If you don't get it soon, please email the elections[3] team. Thanks to Robin for the technical support and to my fellow election officials Roy and Alec for running this election :) ge [1] - http://www.gentoo.org/proj/en/elections/council/2009/master-council200912.txt [2] - http://www.gentoo.org/proj/en/elections/council/2009/council-200912-results.txt [3] - electi...@gentoo.org For the election officials, -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections - confirmation 2765 - wired tanderson patrick scarabeus dev-zero _reopen_nominations - confirmation 2dea - dev-zero patrick wired tanderson scarabeus _reopen_nominations - confirmation 2e6e - patrick scarabeus dev-zero wired tanderson _reopen_nominations - confirmation 30a4 - scarabeus dev-zero tanderson wired _reopen_nominations patrick - confirmation 05cd - tanderson scarabeus patrick wired dev-zero _reopen_nominations - confirmation 3d38 - patrick tanderson dev-zero wired scarabeus _reopen_nominations - confirmation 3dbe - wired scarabeus tanderson _reopen_nominations - confirmation 3e23 - scarabeus wired patrick _reopen_nominations - confirmation 40e5 - scarabeus dev-zero tanderson wired _reopen_nominations patrick - confirmation 42ef - dev-zero wired _reopen_nominations scarabeus tanderson patrick - confirmation 47c7 - scarabeus patrick wired _reopen_nominations tanderson dev-zero - confirmation 49a2 - scarabeus patrick wired dev-zero tanderson _reopen_nominations - confirmation 0774 - _reopen_nominations dev-zero patrick wired scarabeus tanderson - confirmation 4f16 - dev-zero scarabeus wired tanderson _reopen_nominations patrick - confirmation 4fab - scarabeus wired patrick _reopen_nominations dev-zero tanderson - confirmation 0806 - scarabeus dev-zero wired _reopen_nominations tanderson patrick - confirmation 505e - tanderson dev-zero wired scarabeus _reopen_nominations patrick - confirmation 52aa - patrick wired scarabeus tanderson _reopen_nominations dev-zero - confirmation 085e - dev-zero tanderson _reopen_nominations wired scarabeus patrick - confirmation 5453 - tanderson dev-zero _reopen_nominations wired scarabeus patrick - confirmation 560d - _reopen_nominations scarabeus dev-zero patrick wired tanderson - confirmation 59ff - patrick scarabeus wired dev-zero tanderson - confirmation 5a1c - scarabeus _reopen_nominations patrick wired dev-zero tanderson - confirmation 5af0 - scarabeus _reopen_nominations wired tanderson patrick dev-zero - confirmation 5e3d - patrick tanderson scarabeus wired _reopen_nominations dev-zero - confirmation 5e4a - dev-zero tanderson scarabeus patrick wired _reopen_nominations - confirmation 09f4 - patrick scarabeus tanderson wired _reopen_nominations dev-zero - confirmation 65d9 - wired scarabeus patrick _reopen_nominations tanderson dev-zero - confirmation 6894 - wired scarabeus tanderson dev-zero _reopen_nominations patrick - confirmation 6ba9 - wired patrick scarabeus tanderson dev-zero _reopen_nominations - confirmation 6c41 - patrick _reopen_nominations tanderson dev-zero scarabeus wired - confirmation 70de - scarabeus patrick _reopen_nominations - confirmation 72e4 - dev-zero scarabeus tanderson _reopen_nominations wired patrick - confirmation 7479 - tanderson patrick dev-zero scarabeus wired _reopen_nominations - confirmation 748a - scarabeus dev-zero wired tanderson patrick _reopen_nominations - confirmation 7be3 - scarabeus patrick tanderson _reopen_nominations wired dev-zero - confirmation 0c6c - tanderson dev-zero _reopen_nominations wired scarabeus patrick - confirmation 7c7c - patrick _reopen_nominations scarabeus wired
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On 01/17/2010 03:20 PM, Thilo Bangert wrote: Ben de Grootyng...@gentoo.org said: I think we have a bigger problem with packages that have a maintainer, at least nominally, but said maintainer does not actually maintain the package anymore. full ack. i was thinking that maybe we need an 'easy-fix' team, which can do all the easy fixes, which have been laying around for way too long and which aparently are easy to fix (ie. only waiting for somebody to commit)... I think this is a good idea. Alternatively, perhaps if we just make a policy that it is acceptable for a dev to touch a package and leave it with QA problems, as long as it ends up with no more QA problems than it started with. Of course, devs are encouraged to fix QA problems whenever they can. This way devs will be more willing to make small fixes that generally improve the distro without being worried about being chewed out because they didn't go through the package with a fine-tooth comb looking for issues. That will at least get poorly-maintained packages trending in the right direction. Along with that I think we need to address the problem of packages that list a maintainer but which aren't maintained. Perhaps a solution would be to have some way to periodically ping maintainers to confirm they're still looking at a package. That could take many forms - a simple one would be to ask the maintainer to touch the metadata.xml file or something like that (obviously the manipulation has to be something that is noticed by CVS). On the other hand we don't want needless churn. Then an automated process can ping maintainers if they haven't done this, and after a delay the package would be set to maintainer-wanted. Actively-maintained projects would be allowed to use automation to keep packages they track marked fresh. However, the project does then become accountable for actually maintaining them. This would go along with an (unwritten but already in place) policy that anybody listed as a maintainer has to actually maintain the package, with consequences for not doing so to some defined standard. This standard would not be zero-bugs, but certainly anything real flagged by repoman or a violation of a written QA policy would be expected to be cleaned up in a timely manner. The goal is to make the maintainer field meaningful. Then we could figure out a policy for maintainer-wanted builds. My feeling is that as long as they build, don't have security issues, and don't have QA issues that genuinely get in the way of some Gentoo initiative, they can stay around. Once any of the above ceases to be the case they're announced on-list and then treecleaned. The bottom line though is that we can write all the rules we want - ultimately Gentoo needs warm bodies to fix bugs. No amount of process will get around that. What process can do for us, however, is to increase visibility of issues so that QA doesn't waste time hunting down inactive devs and so that people running servers or whatever can tell if a package is actively maintained.
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 17.1.2010 21:38, Petteri Räty napsal(a): With GLEP 42 and proper logging of e* messages I think we shouldn't annoy users any more with ebeep or epause so attached is a patch only defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to keep these around for EAPI 3? If not I will apply the attached patch. Regards, Petteri ++ should really not be used. Actualy i think since it is just eclass call we could make it not used anywhere in ebuilds, and then mark the functions as deprecated and just return true. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktTd5wACgkQHB6c3gNBRYdHegCfZfD7r0aQUBH+ObWdjNvIDYAt IE4AnjY655N8l7HwY4qZPh4Ms3pY8g4H =5kRF -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On Sunday 17 January 2010 15:20:46 Thilo Bangert wrote: Ben de Groot yng...@gentoo.org said: I think we have a bigger problem with packages that have a maintainer, at least nominally, but said maintainer does not actually maintain the package anymore. full ack. i was thinking that maybe we need an 'easy-fix' team, which can do all the easy fixes, which have been laying around for way too long and which aparently are easy to fix (ie. only waiting for somebody to commit)... when the bug wranglers re-assign to maintainer-needed, have them tag it with SIMPLE or something -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
On Sunday 17 January 2010 20:38:48 Petteri Räty wrote: With GLEP 42 and proper logging of e* messages I think we shouldn't annoy users any more with ebeep or epause so attached is a patch only defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to keep these around for EAPI 3? If not I will apply the attached patch. The eclass-manpages comments should be updated too.
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
On Sunday 17 January 2010 16:12:29 David Leverton wrote: On Sunday 17 January 2010 20:38:48 Petteri Räty wrote: With GLEP 42 and proper logging of e* messages I think we shouldn't annoy users any more with ebeep or epause so attached is a patch only defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to keep these around for EAPI 3? If not I will apply the attached patch. The eclass-manpages comments should be updated too. you mean you should re-emerge it on your system -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] how to indicate co-maintainers welcome?
Sebastian Pipping [snip] said: [snip] i chose maintainer-wanted to indicate that co-maintainers and non-maintainer-bumps are welcome. what valid means can i use to send such a message, instead? i dont know of any. i generally assume all packages are looking for more maintainers, but that assumption may be as invalid as yours (having maintainer-wan...@gentoo.org as maintainer in metadata.xml to indicate the above). kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
Mike Frysinger vap...@gentoo.org said: On Sunday 17 January 2010 15:20:46 Thilo Bangert wrote: Ben de Groot yng...@gentoo.org said: I think we have a bigger problem with packages that have a maintainer, at least nominally, but said maintainer does not actually maintain the package anymore. full ack. i was thinking that maybe we need an 'easy-fix' team, which can do all the easy fixes, which have been laying around for way too long and which aparently are easy to fix (ie. only waiting for somebody to commit)... when the bug wranglers re-assign to maintainer-needed, have them tag it with SIMPLE or something no - i wasn't talking about maintainer-needed bugs. it is my impression, that many apparently maintained packages have simple bugs lingering for extended periods of time. Fx. users reporting bugs AND supplying fixes, ready to be committed. i dont want to step on anyones toes, which is why this may need to be put in place carefully - but i do think it would improve average quality of the tree. the easy stuff, that is maintainer-needed is done regularly by a number of people. of course, easy stuff is different for different people. the SIMPLE keyword would definitively work, though. can somebody add it to bugzilla? thanks Thilo -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] how to indicate co-maintainers welcome?
On Sunday 17 January 2010 17:12:27 Thilo Bangert wrote: Sebastian Pipping [snip] said: [snip] i chose maintainer-wanted to indicate that co-maintainers and non-maintainer-bumps are welcome. what valid means can i use to send such a message, instead? i dont know of any. i generally assume all packages are looking for more maintainers, but that assumption may be as invalid as yours (having maintainer-wan...@gentoo.org as maintainer in metadata.xml to indicate the above). ive seen people use a description tag in their maintainer tag with basically feel free to make changes to this -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-01-17 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2010-01-17 23h59 UTC. Removals: app-i18n/ibus-table-additional 2010-01-13 13:52:38 matsuu app-i18n/ibus-table-jyutping2010-01-13 13:53:46 matsuu app-i18n/ibus-table-wubi2010-01-13 13:56:02 matsuu app-i18n/ibus-table-xinhua 2010-01-13 13:56:02 matsuu app-i18n/ibus-table-zhengma 2010-01-13 13:56:03 matsuu app-i18n/ibus-table-stroke5 2010-01-13 13:56:03 matsuu app-i18n/ibus-table-erbi2010-01-13 13:57:32 matsuu app-i18n/ibus-table-wu 2010-01-13 13:57:33 matsuu app-i18n/ibus-table-yong2010-01-13 13:57:33 matsuu app-i18n/ibus-table-zhuyin 2010-01-13 13:57:34 matsuu app-i18n/ibus-table-ziranma 2010-01-13 13:57:34 matsuu net-im/pyotr2010-01-13 18:08:57 hanno net-p2p/dc-qt 2010-01-15 13:17:52 ssuominen net-p2p/qtella 2010-01-15 13:17:53 ssuominen dev-libs/qsa2010-01-15 13:20:08 ssuominen app-dicts/vdict 2010-01-15 13:21:32 ssuominen app-dicts/vdict-en-vi 2010-01-15 13:21:33 ssuominen app-dicts/vdict-fr-vi 2010-01-15 13:21:33 ssuominen app-dicts/vdict-vi-en 2010-01-15 13:21:34 ssuominen app-dicts/vdict-vi-fr 2010-01-15 13:21:34 ssuominen www-client/rabbitticker 2010-01-15 13:23:30 ssuominen x11-libs/kylixlibs3-borqt 2010-01-15 13:24:30 ssuominen app-i18n/scim-qtimm 2010-01-15 14:11:27 ssuominen app-doc/dox 2010-01-15 14:12:17 ssuominen app-text/kbedic 2010-01-15 14:13:18 ssuominen virtual/ghostscript 2010-01-16 09:29:22 pva dev-embedded/scratchbox-toolchain-cs2009q1 2010-01-17 18:58:00 ayoy media-libs/jpeg-compat 2010-01-17 21:37:58 ssuominen Additions: dev-texlive/texlive-fontutils 2010-01-11 03:16:31 aballier dev-texlive/texlive-langarabic 2010-01-11 03:19:18 aballier dev-texlive/texlive-langlatvian 2010-01-11 03:25:12 aballier dev-texlive/texlive-langlithuanian 2010-01-11 03:25:30 aballier dev-texlive/texlive-luatex 2010-01-11 03:31:20 aballier dev-util/eggy 2010-01-11 21:34:59 hwoarang sys-fs/unionfs-fuse 2010-01-12 00:44:17 sping dev-perl/Devel-NYTProf 2010-01-12 08:52:33 tove dev-perl/Throwable 2010-01-12 12:45:52 tove dev-ruby/samuel 2010-01-12 13:58:07 flameeyes dev-ruby/right_http_connection 2010-01-12 14:07:07 flameeyes dev-ruby/fakefs 2010-01-12 15:46:28 flameeyes games-board/gnome-hearts2010-01-12 17:45:09 mr_bones_ dev-ruby/mini_magick2010-01-13 13:10:18 flameeyes app-i18n/ibus-table-code2010-01-13 13:30:59 matsuu app-i18n/ibus-table-latin 2010-01-13 13:31:52 matsuu app-i18n/ibus-table-xingma 2010-01-13 13:35:04 matsuu app-i18n/ibus-table-yinma 2010-01-13 13:36:22 matsuu net-im/python-otr 2010-01-13 18:03:59 hanno kde-misc/kcheckgmail2010-01-14 14:41:43 ssuominen dev-ruby/rexical2010-01-15 14:01:54 flameeyes media-gfx/aewan 2010-01-15 21:32:38 pva net-misc/dnetstats 2010-01-16 12:25:45 hwoarang net-analyzer/netwatch 2010-01-16 12:46:11 hwoarang sys-fs/treesize 2010-01-16 12:59:59 hwoarang dev-python/execnet 2010-01-17 16:02:41 grozin
Re: [gentoo-dev] [rfc] layman storage location (again)
On 01/17/10 21:31, Thilo Bangert wrote: /var/layman i dislike due to this sentence in the FHS: Applications must generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication[...] isn't a package tree somehow having system-wide implications? i'm not really sure about /var/db - doesn't seem to be in FHS. is a package tree a database? current ranking through my eyes: 1) /var/layman con: adds folder to /var, maybe should not 2) /var/db/laymancon: you tell me 3) /var/lib/layman con: not really /var/lib-style data sebastian
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
2010/1/17 Thilo Bangert bang...@gentoo.org: no - i wasn't talking about maintainer-needed bugs. it is my impression, that many apparently maintained packages have simple bugs lingering for extended periods of time. Fx. users reporting bugs AND supplying fixes, ready to be committed. i dont want to step on anyones toes, which is why this may need to be put in place carefully - but i do think it would improve average quality of the tree. What about something like: if a bug has been open for 2 months without any apparent maintainer activity, anyone can step in and commit a fix? Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] [rfc] layman storage location (again)
On Sunday 17 January 2010 15:31:26 Thilo Bangert wrote: Ciaran McCreesh ciaran.mccre...@googlemail.com said: I realise this is a lost cause, but... Repositories are databases, so /var/db/ is your friend. i like it. Closely followed by /var/lib/layman... wikipedia says in http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard /var/lib/ State information. Persistent data modified by programs as they run, e.g., databases, packaging system metadata, etc. /var/layman i dislike due to this sentence in the FHS: Applications must generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication[...] while i think portage/layman should have their tree split up better, i dont think this particular argument applies considering portage (and any overlays it uses) absolutely has system-wide implications ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On 01/17/2010 08:23 PM, Ben de Groot wrote: What about something like: if a bug has been open for 2 months without any apparent maintainer activity, anyone can step in and commit a fix? How about - anybody at any time can at their discretion post a comment in a bug asking if there are objections to committing a fix. If there is no reply from the maintainer/project/etc in two days go ahead and do it. Do check devaway first to see if it makes sense to wait a little longer, and use discretion on the more critical packages.
Re: [gentoo-dev] [rfc] layman storage location (again)
On Mon, 18 Jan 2010, Sebastian Pipping wrote: isn't a package tree somehow having system-wide implications? i'm not really sure about /var/db - doesn't seem to be in FHS. is a package tree a database? This depends on your definition of database. At least some parts of the tree (like the files/ dirs) at not very database-like. current ranking through my eyes: 1) /var/layman con: adds folder to /var, maybe should not 2) /var/db/laymancon: you tell me 3) /var/lib/layman con: not really /var/lib-style data I still think that it should be close to the portage tree, therefore in /usr. But if you go for /var then take /var/layman. Ulrich
Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay
(I'm resending this email as the original apparently did not make it to the list, although Thomas probably received it) Hi Thomas, I'm replying to the original thread below to allow those who have missed it to have the full context. On Sun, Aug 16, 2009 at 5:37 AM, Thomas Sachau to...@gentoo.org wrote: Let me introduce a nice project, which was started by some users: Since the emul-linux-x86-* packages for 32bit libs for amd64 users are neither easy to maintain nor up-to-date, some users started to implement an eclass, which allows to build requested libs with additional 32bit support. Later i joined them and helped them improving it a bit, but it was and still is mainly their project, they do the main work keeping this overlay up-to-date. Also this overlay is a nice idea to drop emul-linux-x86-* packages, it either requires continual work or modification of many ebuilds in main tree to support this in long term. To avoid this, i took the original multilib portage patch from kanaka, adjusted it to the current portage code and added the ideas and code from the eclass version. The result is now a portage, which is able to build any ebuild with additional 32bit lib support. The current main regression are ebuilds and eclasses, which do not support this (e.g. perl modules and mysql). If anyone is interested: -for the eclass version, which is mainly maintained by users and is mainly intended to only replace the emul-linux-x86-* package: just add it via layman -a multilib (it should be pretty stable and mostly working). -for the portage version: It is also in the multilib overlay, but in a different branch called portage-multilib. To use this, you should read the instructions at [1] (doc/portage-multilib-instructions). This one should also mainly work, but there is probably a good amount of packages in the main tree, which may refuse to work with it. Bugreports: preferred way is #gentoo-multilib-overlay at irc.freenode.org, but we also have an alias, where you can contact us: multi...@g.o [1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib -- Thomas Sachau Gentoo Linux Developer I have already explained that I think it's a wonderful project and I definitely would like to see it in the tree sooner rather than later. There was a discussion on the council alias where everybody who participated seemed to like it too. However the consensus was that the project wasn't mature enough (I will let the other, more technical, council members comment on that). There are still open questions on this here thread, there is a request for low-level documentation and a high-level doc is also required (make it a request from me if you want), a preliminary PMS patch is needed, possibly a devmanual patch too, etc... I'm not saying we're asking you to do all this alone because this isn't how a collaborative project like Gentoo should work. We have resources and they are at everybody's disposition. We (I) will help you coordinate that effort if you need/want it. I have noted somewhere that you are concerned about having to do an EAPI bump and were trying to work around that. I understand your concerns and would tend to agree with you since in the past these things were not addressed smoothly and timely enough. This council showed however that we were ready to change plans and create EAPI bumps when needed [1]. If multilib is ready before or at the same time as prefix we can add multilib to EAPI3. If not, well, we will bump as needed by multilib or any worthy project/enhancement anyway. There is no point carving (the former) EAPI3 into stone and having it block everything else due to its implementation taking longer than anticipated. Also, there is no good reason for doing things the wrong way. If an EAPI bump is needed for multilib then let's just do it. I will personally see to putting this EAPI bump on the agenda when multilib is ready. And I'm convinced that at that time my fellow council members will simply vote yes. As you have noticed on the portage irc channel I discussed the maintenance of your branch with Zac. He has agreed to help you with that, and I understand that's your main concern at the moment. It appears that the portage repo is in the process of being converted to git [2] and this should make it a lot easier. I suggest you talk to Zac directly about this. Still on this subject, I will put the question of whether we should add this new multilib to the portage 2.2 branch or something more experimental on the agenda for the next meeting. I will also add multilib as a topic for the open floor discussion. Feel free to contact me in private if you have any question or need help with the above requests. I will do my best to assist you. Denis. [1] http://www.gentoo.org/proj/en/council/meeting-logs/20091207-summary.txt [2] https://bugs.gentoo.org/show_bug.cgi?id=196025#c34 and further
[gentoo-dev] Re: RFC: don't define ebeep and epause in eutils in EAPI 3
* Mike Frysinger vap...@gentoo.org: On Sunday 17 January 2010 16:12:29 David Leverton wrote: On Sunday 17 January 2010 20:38:48 Petteri Räty wrote: With GLEP 42 and proper logging of e* messages I think we shouldn't annoy users any more with ebeep or epause so attached is a patch only defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to keep these around for EAPI 3? If not I will apply the attached patch. The patch only defines these functions for EAPI=0 and EAPI=1. The eclass-manpages comments should be updated too. you mean you should re-emerge it on your system I think he means that the patch should modify @DESCRIPTION too.
[gentoo-portage-dev] [PATCH] Add support to Mercurial SCM in bin/repoman
This patch adds support to the Mercurial SCM [1] in repoman.
[1] - http://mercurial.selenic.com/
Best Regards,
--
Rafael Goncalves Martins
http://rafaelmartins.eng.br
Index: bin/repoman
===
--- bin/repoman (revision 15200)
+++ bin/repoman (working copy)
@@ -486,11 +486,13 @@
vcs = git
elif os.path.isdir(os.path.join(portdir_overlay, .bzr)):
vcs = bzr
+elif os.path.isdir(os.path.join(portdir_overlay, .hg)):
+ vcs = hg
vcs_local_opts = repoman_settings.get(REPOMAN_VCS_LOCAL_OPTS, ).split()
vcs_global_opts = repoman_settings.get(REPOMAN_VCS_GLOBAL_OPTS)
if vcs_global_opts is None:
- if vcs not in [git, bzr]:
+ if vcs not in [git, bzr, hg]:
vcs_global_opts = -q
else:
vcs_global_opts =
@@ -932,6 +934,11 @@
bzrstatus = os.popen(bzr status -S .).readlines()
mychanged = [ ./ + elem.split()[-1:][0].split('/')[-1:][0] for elem in bzrstatus if elem and elem[1:2] == M ]
mynew = [ ./ + elem.split()[-1:][0].split('/')[-1:][0] for elem in bzrstatus if elem and ( elem[1:2] == NK or elem[0:1] == R ) ]
+elif vcs == hg:
+ mychanged = os.popen(hg status --no-status --modified .).readlines()
+ mychanged = [./ + elem.rstrip() for elem in mychanged]
+ mynew = os.popen(hg status --no-status --added .).readlines()
+ mynew = [./ + elem.rstrip() for elem in mynew]
if vcs:
new_ebuilds.update(x for x in mynew if x.endswith(.ebuild))
@@ -1092,9 +1099,13 @@
s = s[s.rfind(\n) + 1:]
fails[file.UTF8].append(%s/%s: line %i, just after: '%s' % (checkdir, y, line, s))
- if vcs == git and check_ebuild_notadded:
- myf = os.popen(git ls-files --others %s % \
- (portage._shell_quote(checkdir_relative),))
+ if vcs in (git, hg) and check_ebuild_notadded:
+ if vcs == git:
+ myf = os.popen(git ls-files --others %s % \
+(portage._shell_quote(checkdir_relative),))
+ if vcs == hg:
+ myf = os.popen(hg status --no-status --unknown %s % \
+(portage._shell_quote(checkdir_relative),))
for l in myf:
if l[:-1][-7:] == .ebuild:
stats[ebuild.notadded] += 1
@@ -1259,7 +1270,7 @@
# It will be generated on server side from scm log,
# before package moves to the rsync server.
# This is needed because we try to avoid merge collisions.
- if vcs not in ( git, ) and ChangeLog not in checkdirlist:
+ if vcs not in ( git, hg ) and ChangeLog not in checkdirlist:
stats[changelog.missing]+=1
fails[changelog.missing].append(x+/ChangeLog)
@@ -1977,6 +1988,15 @@
raise # TODO propogate this
except:
err(Error retrieving bzr info; exiting.)
+ if vcs == hg:
+ myunadded = os.popen(hg status --no-status --unknown .).readlines()
+ myunadded = [./ + elem.rstrip() for elem in myunadded]
+
+ # Mercurial doesn't handle manually deleted files as removed from
+ # the repository, so the user need to remove them before commit,
+ # using hg remove [FILES]
+ mydeleted = os.popen(hg status --no-status --deleted .).readlines()
+ mydeleted = [./ + elem.rstrip() for elem in mydeleted]
myautoadd=[]
@@ -2002,6 +2022,8 @@
print((git add + .join(myautoadd)+))
elif vcs == bzr:
print((bzr add + .join(myautoadd)+))
+ elif vcs == hg:
+print((hg add + .join(myautoadd)+))
retval=0
else:
if vcs == cvs:
@@ -2012,6 +2034,8 @@
retval=os.system(git add + .join(myautoadd))
elif vcs == bzr:
retval=os.system(bzr add + .join(myautoadd))
+ elif vcs == hg:
+retval=os.system(hg add + .join(myautoadd))
if retval:
writemsg_level(!!! Exiting on %s (shell) error code: %s\n % \
(vcs, retval), level=logging.ERROR, noiselevel=-1)
@@ -2026,6 +2050,15 @@
print()
sys.exit(1)
+ if vcs == hg and mydeleted:
+ print(red(!!! The following files are removed manually from your local tree but are not))
+ print(red(!!! removed from the repository. Please remove them, using \hg remove [FILES]\.))
+ for x in mydeleted:
+ print( ,x)
+ print()
+ print()
+ sys.exit(1)
+
if vcs == cvs:
mycvstree = cvstree.getentries(./, recursive=1)
mychanged = cvstree.findchanged(mycvstree, recursive=1, basedir=./)
@@ -2084,8 +2117,16 @@
myremoved = [ ./ + elem.split()[-3:-2][0].split('/')[-1:][0] for elem in bzrstatus if elem and ( elem[1:2] == K or elem[0:1] == R ) ]
# Bazaar expands nothing.
+ if vcs == hg:
+ mychanged = os.popen(hg status --no-status --modified .).readlines()
+ mychanged = [./ + elem.rstrip() for elem in mychanged]
+ mynew = os.popen(hg status --no-status --added .).readlines()
+ mynew = [./ + elem.rstrip() for elem in mynew]
+ myremoved = os.popen(hg status --no-status --removed .).readlines()
+ myremoved = [./ + elem.rstrip() for elem in myremoved]
+
if vcs:
- if not (mychanged or mynew or myremoved):
+ if not (mychanged or mynew or myremoved or (vcs == hg and mydeleted)):
print(green(RepoMan sez:), \Doing nothing is not always good for QA.\)
print()
print((Didn't find any changed files...))
@@ -2101,7 +2142,7 @@
mymanifests.add(f)
[gentoo-portage-dev] Re: [PATCH] Add support to Mercurial SCM in bin/repoman
I'm re-sending the patch, with a small fix. Please disregard the previous patch.
Sorry.
--
Rafael Goncalves Martins
http://rafaelmartins.eng.br
Index: bin/repoman
===
--- bin/repoman (revision 15200)
+++ bin/repoman (working copy)
@@ -486,11 +486,13 @@
vcs = git
elif os.path.isdir(os.path.join(portdir_overlay, .bzr)):
vcs = bzr
+elif os.path.isdir(os.path.join(portdir_overlay, .hg)):
+ vcs = hg
vcs_local_opts = repoman_settings.get(REPOMAN_VCS_LOCAL_OPTS, ).split()
vcs_global_opts = repoman_settings.get(REPOMAN_VCS_GLOBAL_OPTS)
if vcs_global_opts is None:
- if vcs not in [git, bzr]:
+ if vcs not in [git, bzr, hg]:
vcs_global_opts = -q
else:
vcs_global_opts =
@@ -932,6 +934,11 @@
bzrstatus = os.popen(bzr status -S .).readlines()
mychanged = [ ./ + elem.split()[-1:][0].split('/')[-1:][0] for elem in bzrstatus if elem and elem[1:2] == M ]
mynew = [ ./ + elem.split()[-1:][0].split('/')[-1:][0] for elem in bzrstatus if elem and ( elem[1:2] == NK or elem[0:1] == R ) ]
+elif vcs == hg:
+ mychanged = os.popen(hg status --no-status --modified .).readlines()
+ mychanged = [./ + elem.rstrip() for elem in mychanged]
+ mynew = os.popen(hg status --no-status --added .).readlines()
+ mynew = [./ + elem.rstrip() for elem in mynew]
if vcs:
new_ebuilds.update(x for x in mynew if x.endswith(.ebuild))
@@ -1092,9 +1099,13 @@
s = s[s.rfind(\n) + 1:]
fails[file.UTF8].append(%s/%s: line %i, just after: '%s' % (checkdir, y, line, s))
- if vcs == git and check_ebuild_notadded:
- myf = os.popen(git ls-files --others %s % \
- (portage._shell_quote(checkdir_relative),))
+ if vcs in (git, hg) and check_ebuild_notadded:
+ if vcs == git:
+ myf = os.popen(git ls-files --others %s % \
+(portage._shell_quote(checkdir_relative),))
+ if vcs == hg:
+ myf = os.popen(hg status --no-status --unknown %s % \
+(portage._shell_quote(checkdir_relative),))
for l in myf:
if l[:-1][-7:] == .ebuild:
stats[ebuild.notadded] += 1
@@ -1259,7 +1270,7 @@
# It will be generated on server side from scm log,
# before package moves to the rsync server.
# This is needed because we try to avoid merge collisions.
- if vcs not in ( git, ) and ChangeLog not in checkdirlist:
+ if vcs not in ( git, hg ) and ChangeLog not in checkdirlist:
stats[changelog.missing]+=1
fails[changelog.missing].append(x+/ChangeLog)
@@ -1977,6 +1988,15 @@
raise # TODO propogate this
except:
err(Error retrieving bzr info; exiting.)
+ if vcs == hg:
+ myunadded = os.popen(hg status --no-status --unknown .).readlines()
+ myunadded = [./ + elem.rstrip() for elem in myunadded]
+
+ # Mercurial doesn't handle manually deleted files as removed from
+ # the repository, so the user need to remove them before commit,
+ # using hg remove [FILES]
+ mydeleted = os.popen(hg status --no-status --deleted .).readlines()
+ mydeleted = [./ + elem.rstrip() for elem in mydeleted]
myautoadd=[]
@@ -2002,6 +2022,8 @@
print((git add + .join(myautoadd)+))
elif vcs == bzr:
print((bzr add + .join(myautoadd)+))
+ elif vcs == hg:
+print((hg add + .join(myautoadd)+))
retval=0
else:
if vcs == cvs:
@@ -2012,6 +2034,8 @@
retval=os.system(git add + .join(myautoadd))
elif vcs == bzr:
retval=os.system(bzr add + .join(myautoadd))
+ elif vcs == hg:
+retval=os.system(hg add + .join(myautoadd))
if retval:
writemsg_level(!!! Exiting on %s (shell) error code: %s\n % \
(vcs, retval), level=logging.ERROR, noiselevel=-1)
@@ -2026,6 +2050,15 @@
print()
sys.exit(1)
+ if vcs == hg and mydeleted:
+ print(red(!!! The following files are removed manually from your local tree but are not))
+ print(red(!!! removed from the repository. Please remove them, using \hg remove [FILES]\.))
+ for x in mydeleted:
+ print( ,x)
+ print()
+ print()
+ sys.exit(1)
+
if vcs == cvs:
mycvstree = cvstree.getentries(./, recursive=1)
mychanged = cvstree.findchanged(mycvstree, recursive=1, basedir=./)
@@ -2084,8 +2117,16 @@
myremoved = [ ./ + elem.split()[-3:-2][0].split('/')[-1:][0] for elem in bzrstatus if elem and ( elem[1:2] == K or elem[0:1] == R ) ]
# Bazaar expands nothing.
+ if vcs == hg:
+ mychanged = os.popen(hg status --no-status --modified .).readlines()
+ mychanged = [./ + elem.rstrip() for elem in mychanged]
+ mynew = os.popen(hg status --no-status --added .).readlines()
+ mynew = [./ + elem.rstrip() for elem in mynew]
+ myremoved = os.popen(hg status --no-status --removed .).readlines()
+ myremoved = [./ + elem.rstrip() for elem in myremoved]
+
if vcs:
- if not (mychanged or mynew or myremoved):
+ if not (mychanged or mynew or myremoved or (vcs == hg and mydeleted)):
print(green(RepoMan sez:), \Doing nothing is not always good for QA.\)
print()
print((Didn't find any changed files...))
@@ -2101,7 +2142,7 @@
mymanifests.add(f)
else:
Re: [gentoo-portage-dev] Re: [PATCH] Add support to Mercurial SCM in bin/repoman
On Sun, Jan 17, 2010 at 08:46:24PM -0200, Rafael Martins wrote: I'm re-sending the patch, with a small fix. Please disregard the previous patch. Might I suggest breaking classes out for each syncer rather then continuing the huge and nasty giant if/elif ? Certainly would make it easier to maintain and extend. ~harring pgp1sq0N3UIDH.pgp Description: PGP signature
