Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On Sun, May 24, 2009 at 9:28 PM, Tiziano Müller dev-z...@gentoo.org wrote: Am Sonntag, den 24.05.2009, 20:04 +0200 schrieb lx...@sabayonlinux.org: And then it's a pm thing. So the person you want to talk about it is zmedico. And zmedico told me to start discussing here. -- Tiziano Müller Gentoo Linux Developer, Council Member 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 -- Fabio Erculiani signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: Accessibility on our release media
Andrew Gaffney wrote: On 05/24/2009 05:32 AM, Roy Bamford wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009.05.24 02:44, William Hubbs wrote: [snip] Random reply to thread William Hubbs gentoo accessibility team lead willi...@gentoo.org Put all the downloads for a minimal gentoo install into dial up context. You need the minimal CD, the stage 3, the portage snapshot, a bootloader and a kernel. An extra 20Mb in that total size is trivial. Having done a few remote installs for blind users dropping into #gentoo, I understand the frustration that lack of accessibility causes. Please add accessibility to Gentoo install media and help our users to help themselves. Since my only real argument against it (size) has been effectively shot down, if someone does all the testing/patching and provides a nice, neat little package for releng (me, basically) to integrate, we'll do it. I just don't have the time/inclination to do it myself. Hasn't William already submitted that to bugzilla? I can't remember the number but I am sure he will be helpful. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] better support for binary packages
Good morning, I want to talk about improved binary package support for Gentoo. About 1-2 months ago there already was a discussion about this on gentoo-soc@ and on bugzilla [1]. If I remember correctly, there were no devs involved in the discussion, so I thought I'll post my thoughts here. I know, that Gentoo is a source-based distribution or meta-distribution, and I don't want to make Gentoo another Fedora or Ubuntu, but I think there are some things we can learn from them. The current situation: Binary packages are (usually) stored in /usr/portage/packages/$category/$package-$version.tbz2. The package consists of the real binary package and the metadata (combined using xpak or whatever). Problems I see with this: 1) If a binary package is built because it needs to be linked against a new library, because the USE-flags change or because the ebuild changes without a revision bump, the old binary package is overwritten. This also means that there is no support to store multiple packages with different USE-flags without, well, using different directories. 2) To find out which USE-flags a package is built with, one needs to download the package and look at the metadata. Today I discoveres a file called Packages which looks like a metadata cache, but I did not find more information about it (only tried man portage). So, how can we address this? First we should do something about 2), I think: I want to propost the following scheme: Binary packages are stored in $arch/$description/$category/$package/$package-$version-$ev-$use-$bv.tbz2. $arch: This is x86, ppc or whatever you put into ACCEPT_KEYWORDS minus the '~'. It does not make sense to make a distinction here. $description: Something like pentium3, core2quad, G4, or whatever. Pentium3-uclibc, Pentium3-solaris-prefix are also possible. $category, $package and $version should be clear. $ev: The ebuild version. See below. $bv: The binary version. See below. $use: The USE-flags. See below. About ebuild version, USE-flags and binary version: I would like to encode the USE-flags into the filename. This enables us to have binary packages of the same version built with different USE-flags in the same repository. Some wanted to have this in the directory, some say it is ok to have it in the xpak only and some prefer the Packages-like file. I think, USE-flags can be set per package and therefore should be stored per package, not per $description or whatever. Having it only in the xpak allows no distinction between multiple binary packages, same version, differen USE-flags and the same is true for the Packages file. This would also be created, downloaded all the time and so on. Therefore I think the cleanest solution is having USE-flags in the filename. There are different methods to store it there. a) A checksum (of the USE-flags, the USE-flag string, the ebuild and the USE-flag string, whatever). b) List the enabled USE-flags in the filename, use a) if the string gets too long. c) Use a packed binary vector. I don't like a), because it is not easily reversible. You could always download the Packages file or the binary package and look into the xpak metadata, but that's too much effort. b) also has the problems i mentioned for a). Also, you'd need some system to distinguish ebuilds with the same version but different USE-flags. You also need that for c), so b) has no advantages ofer c) in my eyes. For c) I think of the following: Sort the USE-flags in some defined way (ASCII code, whatever) and make a vector with a 1 for every enabled USE-flag and a 0 for every disabled USE-flag. Compress that vector: If you use HEX code, you need 1 character for every 4 bits, but it should be possible to find 64 different characters, then you need 1 character for every 6 bits. PHP has 106 USE.flags, that would make a USE-string with about 18-27 characters. Packages with lots of USE-expand stuff like languages would need more, but not too much, I think. Problems: The string might get long, you get big problems with USE-flag renames, USE-flag additions or removals. That's where the ebuild version is needed. Or not. We have 3 possibilities: a) Change policy: USE-flag changes in an ebuild need a version bump. b) Use a checksum of the ebuild. c) Use the version given by the version control system. The problem with a) is, that is a change in policy and probably hard to do. Increasing the revision for a (trivial) change leads to a lot of unnecessary rebuilds for users. It also means, that USE-flag changes in eclasses are difficult, the eclass should probably copied over to a new name with version and only ebuilds with a new version (revision) are allowed to use it. The problem with b) is, that it is not ordered. You don't know, which is the newest version. If you have an ebuild with a version where there is no binary package for, it gets difficult/ugly. c) also has problems: When using cvs, there are versions easily available. The same is true for svn, but lots of
Re: [gentoo-dev] better support for binary packages
This is what I am doing in Sabayon, creating a new layer over Portage = Entropy. I'm almost done, just need to work out some documentation and apidocs. http://gitweb.sabayon.org/?p=entropy.git;a=summary -- Fabio Erculiani signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On So, 2009-05-24 at 20:04 +0200, lx...@sabayonlinux.org wrote: [...] app-admin/equo (sabayon overlay -- Entropy Framework client) supports the postfix @repository to let users force the installation of a package from a specific repository. @ is used by Portage for sets. Paludis has been using ::repo for repo dependencies for years. Why not go with the established syntax? I wrote postfix not prefix. Sets use @ prefix. Your @ is still a prefix for the repository name. For usability's sake, please don't do this. I can imagine users getting confused over the different meanings of the @ sign. I do not want to trigger a discussion like the one PHP had when choosing namespace separators, but we got the :: established in Paludis and Paludis is used by way more Gentoo people than equo. So it only seems logical to me to use the wider-known and at the same time ambiguity-free operator. Alex signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: Accessibility on our release media
On Sunday 24 of May 2009 01:14:57 Andrew Gaffney wrote: On 05/23/2009 05:56 PM, Mounir Lamouri wrote: William Hubbs wrote: [snip] My question for the group is, how do you feel about speech software being on our minimal cd as well as our live cd? I agree, it should be in our minimal and live CD's. There is no reason to consider blind persons out of the minimal CD. The real issue here is the size. If these additional packages plus all of the alsa modules add 20MB to the minimal CD, it's just not worth it. It's not minimal anymore. Is it the problem with those additional ~20MiB? If it's about not fitting anymore on minimal release media - then it's not the problem - it will still be able to fit on ~128MB memory sticks and 3,5 ~210MB cd's. And if it's going to make Gentoo accessible for those handicapped in some way - why not? (Not sure how they actually manage to set up Gentoo with no monitor - even with speech engine on terminal - I just couldn't - most respect for them). -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On Mon, May 25, 2009 at 3:43 PM, Alex Legler a...@gentoo.org wrote: On So, 2009-05-24 at 20:04 +0200, lx...@sabayonlinux.org wrote: [...] app-admin/equo (sabayon overlay -- Entropy Framework client) supports the postfix @repository to let users force the installation of a package from a specific repository. @ is used by Portage for sets. Paludis has been using ::repo for repo dependencies for years. Why not go with the established syntax? I wrote postfix not prefix. Sets use @ prefix. Your @ is still a prefix for the repository name. Yeah but emerge @overlay would be obviously illegal. So your argument is a bit pointless ;) For usability's sake, please don't do this. I can imagine users getting confused over the different meanings of the @ sign. I do not want to trigger a discussion like the one PHP had when choosing namespace separators, but we got the :: established in Paludis and Paludis is used by way more Gentoo people than equo. :: C++/PHP/whatever separator has nothing to do with the purpose of @overlay. Paludis is not a Gentoo project and doesn't follow Gentoo features validation rules. So is Entropy. If Paludis has its own syntax it doesn't automatically mean that Gentoo Portage *has to* follow it. I prefer a more democratic way = discussing here. So it only seems logical to me to use the wider-known and at the same time ambiguity-free operator. Alex -- Fabio Erculiani signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
lx...@sabayonlinux.org wrote: On Mon, May 25, 2009 at 3:43 PM, Alex Legler a...@gentoo.org wrote: On So, 2009-05-24 at 20:04 +0200, lx...@sabayonlinux.org wrote: [...] app-admin/equo (sabayon overlay -- Entropy Framework client) supports the postfix @repository to let users force the installation of a package from a specific repository. @ is used by Portage for sets. Paludis has been using ::repo for repo dependencies for years. Why not go with the established syntax? I wrote postfix not prefix. Sets use @ prefix. Your @ is still a prefix for the repository name. Yeah but emerge @overlay would be obviously illegal. So your argument is a bit pointless ;) For usability's sake, please don't do this. I can imagine users getting confused over the different meanings of the @ sign. I do not want to trigger a discussion like the one PHP had when choosing namespace separators, but we got the :: established in Paludis and Paludis is used by way more Gentoo people than equo. :: C++/PHP/whatever separator has nothing to do with the purpose of @overlay. Personally I think the PHP namespace syntax issue is a very good analogy. There's an established syntax, even if it's not a written standard, already used in a very similar situation, and that should be taken into account. Paludis is not a Gentoo project and doesn't follow Gentoo features validation rules. So is Entropy. If Paludis has its own syntax it doesn't automatically mean that Gentoo Portage *has to* follow it. I prefer a more democratic way = discussing here. As far as I can see, a discussion is happening. You started a discussion here and others mentioned that there is a specific syntax already used for this by a very similar application. You appear to be the only one who's arguing against that syntax. As a user, I have to agree that using @ for multiple purposes, even if it can't be applied to the same purposes in different locations, is potentially confusing, even if not just plain silly. As a side note, I think I've read somewhere that it may in the future be possible to specify sets in package.* (which I assume would be done using the @set-name syntax), but can't remember where off-hand. This may have just been a suggestion, but if it ever is implemented, it would surely add to the confusion. AllenJB So it only seems logical to me to use the wider-known and at the same time ambiguity-free operator. Alex
Re: [gentoo-dev] better support for binary packages
lx...@sabayonlinux.org wrote: This is what I am doing in Sabayon, creating a new layer over Portage = Entropy. I'm almost done, just need to work out some documentation and apidocs. http://gitweb.sabayon.org/?p=entropy.git;a=summary Only problem with entropy is that it doesn't work nice with portage. -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
AllenJB wrote: As a side note, I think I've read somewhere that it may in the future be possible to specify sets in package.* (which I assume would be done using the @set-name syntax), but can't remember where off-hand. This may have just been a suggestion, but if it ever is implemented, it would surely add to the confusion. AllenJB Is this the location you are talking about? r...@smoker / # ls -al /etc/portage/sets/ total 21 drwxrwsr-x 2 root portage 128 Apr 22 19:04 . drwxr-xr-x 7 root portage 536 May 21 00:53 .. -rw-r--r-- 1 root portage 1353 Feb 23 04:49 dk-kde -rw-r--r-- 1 root portage 6453 Apr 22 19:04 dk-kde-full -rw-r--r-- 1 root portage 6795 Apr 17 21:59 rebuild r...@smoker / # I already have a couple of those in use with Portage 2.2_rc33. If you are talking about something else, please ignore. Dale :-) :-)
Re: [gentoo-dev] better support for binary packages
On Mon, May 25, 2009 at 5:47 PM, Ben de Groot yng...@gentoo.org wrote: lx...@sabayonlinux.org wrote: This is what I am doing in Sabayon, creating a new layer over Portage = Entropy. I'm almost done, just need to work out some documentation and apidocs. http://gitweb.sabayon.org/?p=entropy.git;a=summary Only problem with entropy is that it doesn't work nice with portage. You are wrong. From entropy 0.95+ all works fine, the only problem previous releases had was with Portage world file being filled incorrectly (emaint --fix world does it, but I am sure you know this). http://gitweb.sabayon.org/?p=entropy.gita=searchh=HEADst=commits=portage Regards, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __ -- Fabio Erculiani signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Baselayout 2 stabilisation todo
Hi, Doug Goldstein car...@gentoo.org: On Fri, May 22, 2009 at 5:17 AM, Christian Faulhammer fa...@gentoo.org wrote: Hi, I'd like to collect some things we need to do before Baselayout 2 and OpenRC can go stable. Up to now I have: * eselect 1.1 stable (current RC3) for the support in the rc module * a newer splashutils stable * documentation updates (http://bugs.gentoo.org/213988, thanks Jeremy) What else? As some of you might foresee, this can be as hard as a major GCC stabilisation, so it must be well-planned and organised. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ The only reason why OpenRC has not come up for stabilization by it's maintainers is the fact that everytime there's a new version readied for release, on the horizon there's new incompatible changes being planned for the next version. The OpenRC maintainers in Gentoo have always chosen to wait until OpenRC settles down a little bit. Now with the plan to drop support for certain features (ADSL and PPP support in the networking code), it's going to rewrite more Gentoo people to step up to develop and maintain this code. After having seen vapier speaking about stabilisation on -core we had a discussion about the wanted news item, which i posted for review. Before the todo mail, I wrote to the maintainers (Roy and base-system) some days in advance, with only a reaction from Roy. If you're volunteering for this position, Christian, I'll happily step down and allow you to maintain this. I would also discuss this with zzam and vapier, the other 2 maintainers of OpenRC. All I want to do is help with the stabilisation...which I though is nigh. 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] better support for binary packages
lx...@sabayonlinux.org wrote: On Mon, May 25, 2009 at 5:47 PM, Ben de Groot yng...@gentoo.org wrote: lx...@sabayonlinux.org wrote: This is what I am doing in Sabayon, creating a new layer over Portage = Entropy. I'm almost done, just need to work out some documentation and apidocs. http://gitweb.sabayon.org/?p=entropy.git;a=summary Only problem with entropy is that it doesn't work nice with portage. You are wrong. From entropy 0.95+ all works fine, the only problem previous releases had was with Portage world file being filled incorrectly (emaint --fix world does it, but I am sure you know this). http://gitweb.sabayon.org/?p=entropy.gita=searchh=HEADst=commits=portage That's funny, as I just installed Sabayon 4.1 KDE version the other day, and did an equo world update. After that I wanted to install quassel, but as the version in equo is ancient, I went for emerge. That wanted to install qt-core and some other qt packages, which obviously were already installed as deps for KDE. The emerge failed with a file collision of qt-core (the newly emerged package with the previous binary package). I then turned to the #sabayon irc channel and was told: yngwin ok, so you can't just mix equo and emerge? Azerthoth yngwin honestly you can, but you better have a real firm grip on how both package systems work, and be willing to brick your system yngwin well, i know portage, i dont know equo yet Azerthoth equo is preferred barring that, converting the system to portage only, but mixing the two can be really tricky Azerthoth not saying you will brick your system, just saying that the odds increase exponentially I would love Sabayon to be Gentoo with binary support, that would have worked well on my laptop. But if mixing the package managers is so problematic, that's just not worth the trouble for me. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
Re: [gentoo-dev] Baselayout 2 stabilisation todo
On Saturday 23 May 2009, Roy Marples wrote: Basically as Doug said, each OpenRC version comes with a few big chances. Well not massive as in your box will break now, but just a different spin on how things should work. OpenRC-0.5 will have the biggest re-spin to date - net.lo (net.eth0 etc) is considered deprecated. If future changes of this magnitude are still expected, I wonder if we want to go stable with OpenRC anytime soon. I do not intend to hinder fast progress and design changes in OpenRC in any way, but if its design is not considered final, I suggest we do not make it the default recommandation for our users. Marking it stable might also be contraproductive for upstream since revised configurations need to stay supported a lot longer than they would had they been used only by ~arch users. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On Monday 25 May 2009, lx...@sabayonlinux.org wrote: On Mon, May 25, 2009 at 3:43 PM, Alex Legler a...@gentoo.org wrote: On So, 2009-05-24 at 20:04 +0200, lx...@sabayonlinux.org wrote: [...] app-admin/equo (sabayon overlay -- Entropy Framework client) supports the postfix @repository to let users force the installation of a package from a specific repository. @ is used by Portage for sets. Paludis has been using ::repo for repo dependencies for years. Why not go with the established syntax? I wrote postfix not prefix. Sets use @ prefix. Your @ is still a prefix for the repository name. Yeah but emerge @overlay would be obviously illegal. So your argument is a bit pointless ;) # emerge --update lsof @system versus # emerge --update l...@system would have completely different meanings. This is what I would dislike about the '@' character. I'm ok with :: though. If we use repo_name as the overlay identifier, we must rethink how layman-global.txt is currently handled. Many overlays in there have that file missing, and some have different identifiers than what layman displays as their name. Is this specifier stored and considered on future dependency calculations (e.g. updates, dependencies of other ebuilds on the package that was installed via @overlay)? Where is it stored, how is it displayed to the user in emerge/eix output? Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] better support for binary packages
On Mon, May 25, 2009 at 7:20 PM, Ben de Groot yng...@gentoo.org wrote: lx...@sabayonlinux.org wrote: On Mon, May 25, 2009 at 5:47 PM, Ben de Groot yng...@gentoo.org wrote: lx...@sabayonlinux.org wrote: This is what I am doing in Sabayon, creating a new layer over Portage = Entropy. I'm almost done, just need to work out some documentation and apidocs. http://gitweb.sabayon.org/?p=entropy.git;a=summary Only problem with entropy is that it doesn't work nice with portage. You are wrong. From entropy 0.95+ all works fine, the only problem previous releases had was with Portage world file being filled incorrectly (emaint --fix world does it, but I am sure you know this). http://gitweb.sabayon.org/?p=entropy.gita=searchh=HEADst=commits=portage That's funny, as I just installed Sabayon 4.1 KDE version the other day, and did an equo world update. After that I wanted to install quassel, but as the version in equo is ancient, I went for emerge. That wanted to install qt-core and some other qt packages, which obviously were already installed as deps for KDE. The emerge failed with a file collision of qt-core (the newly emerged package with the previous binary package). This is gentoo-dev and you are OFF TOPIC. Btw, that's weird, because on 4.1 I have: mars / # qlist -ICv | grep qt- x11-libs/qt-3.3.8b x11-libs/qt-4.5.0 x11-libs/qt-assistant-4.5.0 x11-libs/qt-core-4.5.0 x11-libs/qt-dbus-4.5.0 x11-libs/qt-gui-4.5.0 x11-libs/qt-opengl-4.5.0 x11-libs/qt-qt3support-4.5.0 x11-libs/qt-script-4.5.0 x11-libs/qt-sql-4.5.0 x11-libs/qt-svg-4.5.0 x11-libs/qt-test-4.5.0 x11-libs/qt-webkit-4.5.0 x11-libs/qt-xmlpatterns-4.5.0 and emerging quassel works as expected. I then turned to the #sabayon irc channel and was told: yngwin ok, so you can't just mix equo and emerge? Azerthoth yngwin honestly you can, but you better have a real firm grip on how both package systems work, and be willing to brick your system yngwin well, i know portage, i dont know equo yet Azerthoth equo is preferred barring that, converting the system to portage only, but mixing the two can be really tricky Azerthoth not saying you will brick your system, just saying that the odds increase exponentially This is told to newbies who mess with USE flags. Since binary is a static world. I would love Sabayon to be Gentoo with binary support, that would have worked well on my laptop. But if mixing the package managers is so problematic, that's just not worth the trouble for me. And this made me definitely wonder about this email :) Next time, please post Sabayon specific stuff on our ML/com. channels. Regards, Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __ -- Fabio Erculiani signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
lx...@sabayonlinux.org wrote: Adding @overlay atoms/deps postfix support could really make life easier, especially because forcing specific atoms in *DEPEND hoping that these will be always pulled in from the same overlay is not something reliable, as you already know. No. This is a terrible idea. The solution is to *fix the overlays*, not force the user to intervene and fix things himself. Conflicting overlay issues turn up on the Gentoo forums (check Unsupported Software), and in pretty much all cases, once the maintainer(s) of the overlay(s) are contacted about the issue, the overlays are quickly fixed so that the next update sorts out the user's tree. Users should *not *have to take steps to fix overlay blocks and breaks ahead of time; that should be the overlay maintainer's job, not the poor end user. Comments are welcome, flames are not. On that note, I'd like to offer a friendly word of caution, in the interests of us all talking together and working through the ideas presented in your threads. In your last visit to our mailing list (http://thread.gmane.org/gmane.linux.gentoo.devel/55180), you stated that you'd like to make some sweeping changes to Gentoo, then you started telling the developers why they all sucked ahead of time for not implementing said ideas. And then you kept telling developers that they sucked throughout the rest of the replies. You expressed unwillingness to work with Gentoo developers through our admittedly long recruitment process, instead wanting to push your changes to our tree directly. There wasn't very much accomplished on either side at the end of that debacle, except some hurt feelings. It seems that the discussions you're having in the binary packages and overlay threads are already heading the same direction, and I for one don't want that to happen. Telling people they're not allowed to express disagreement is counterproductive.[1][2] [1] http://thread.gmane.org/gmane.linux.gentoo.devel/61555/focus=61568 [2] http://thread.gmane.org/gmane.linux.gentoo.devel/61530/focus=61560 So, folks, just take it easy. We don't have to accept every suggestion offered to the list, nor do we have to reject it out of hand. Thanks. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Baselayout 2 stabilisation todo
Robert Buchholz wrote: On Saturday 23 May 2009, Roy Marples wrote: Basically as Doug said, each OpenRC version comes with a few big chances. Well not massive as in your box will break now, but just a different spin on how things should work. OpenRC-0.5 will have the biggest re-spin to date - net.lo (net.eth0 etc) is considered deprecated. If future changes of this magnitude are still expected, I wonder if we want to go stable with OpenRC anytime soon. I do not intend to hinder fast progress and design changes in OpenRC in any way, but if its design is not considered final, I suggest we do not make it the default recommandation for our users. Let us be clear on one point - net.lo and friends are still somewhat supported upstream, just no future development will take place on them. The network script is just the preferred default as it makes my life a lot easier and places the support burden onto the maintainers of the various utils needed to be used directly. It's also a lot faster :) I don't expect any more userland changes before the move to OpenRC-1.0 There are two features on the cards - rc events [1] and feature removal for space limited embedded systems (basically dependecy is only used to order scripts on initial startup, reducing /sbin/rc and /sbin/runscript to shell stubs the aim on saving 75k on the binary size. Marking it stable might also be contraproductive for upstream since revised configurations need to stay supported a lot longer than they would had they been used only by ~arch users. If there is a real drive to make OpenRC stable then I suggest that I roll openrc-0.5.0 out sometime this week and try to roll rc events into 0.6.0, the embedded stubs into 0.7.0 and we'll go from there. I know that Cardoe has been busy in RL of late and I've never pressed or been pressed into considering it stable. However, real bug reports and new feature implementations have slowed somewhat, so either it's Ready For Stable or no-ones using it. Thanks Roy
[gentoo-dev] Re: Baselayout 2 stabilisation todo
Hi, Roy Marples r...@marples.name: If there is a real drive to make OpenRC stable then I suggest that I roll openrc-0.5.0 out sometime this week and try to roll rc events into 0.6.0, the embedded stubs into 0.7.0 and we'll go from there. Sounds fine to me. I don't want to press anything, just some kind of plan would be fine so we can work towards a goal. I know that Cardoe has been busy in RL of late and I've never pressed or been pressed into considering it stable. However, real bug reports and new feature implementations have slowed somewhat, so either it's Ready For Stable or no-ones using it. I am using it productively on many systems even before the split-off to OpenRC. And bringing such a crucial piece of software to stable is a hard task. I have some experience in working with the surroundings from some GCC stabilisations so I can lend a hand here and be a pathfinder in stableland to prepare everything there. 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] better support for binary packages
lx...@sabayonlinux.org wrote: lx...@sabayonlinux.org wrote: This is what I am doing in Sabayon, creating a new layer over Portage = Entropy. I'm almost done, just need to work out some documentation and apidocs. http://gitweb.sabayon.org/?p=entropy.git;a=summary Next time, please post Sabayon specific stuff on our ML/com. channels. Sure, so let's keep entropy out of the discussion. -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
Robert Buchholz wrote: # emerge --update lsof @system versus # emerge --update l...@system would have completely different meanings. This is what I would dislike about the '@' character. I'm ok with :: though. I agree the :: looks like the better option here. If we use repo_name as the overlay identifier, we must rethink how layman-global.txt is currently handled. Many overlays in there have that file missing, and some have different identifiers than what layman displays as their name. I think layman should simply start to use the repo_name as identifier. That should result in less confusion, I'd think. Overlays that miss the repo_name file are broken and should be fixed, and should be ignored until they are. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On Monday 25 May 2009, Ben de Groot wrote: Robert Buchholz wrote: If we use repo_name as the overlay identifier, we must rethink how layman-global.txt is currently handled. Many overlays in there have that file missing, and some have different identifiers than what layman displays as their name. I think layman should simply start to use the repo_name as identifier. That should result in less confusion, I'd think. Overlays that miss the repo_name file are broken and should be fixed, and should be ignored until they are. Unfortunately, that value is not known until the repository is checked out. Doing that on every list operation would be too much overhead. We do need a script to verify the layman list, nevertheless. (Don't look at me for this! :-) Robert signature.asc Description: This is a digitally signed message part.
[gentoo-dev] New feature for python eclass for review
I wrote support to the python eclass to make sure python version used to
install has support for needed use flags. With current EAPIs I can't
think of a way to do this without a pkg_setup check but feel free to
surprise me.
Regards,
Petteri
Index: python.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/python.eclass,v
retrieving revision 1.54
diff -u -r1.54 python.eclass
--- python.eclass 30 Oct 2008 05:21:46 - 1.54
+++ python.eclass 25 May 2009 20:47:37 -
@@ -14,8 +14,11 @@
if [[ -n ${NEED_PYTHON} ]] ; then
- DEPEND==dev-lang/python-${NEED_PYTHON}
+ PYTHON_ATOM==dev-lang/python-${NEED_PYTHON}
+ DEPEND=${PYTHON_ATOM}
RDEPEND=${DEPEND}
+else
+ PYTHON_ATOM=dev-lang/python
fi
__python_eclass_test() {
@@ -59,6 +62,78 @@
__python_version_extract $PYVER_ALL
}
+# @ECLASS-VARIABLE: PYTHON_USE_WITH
+# @DESCRIPTION:
+# Set this to a space separated list of use flags
+# the python slot in use must be built with.
+
+# @ECLASS-VARIABLE: PYTHON_USE_WITH_OR
+# @DESCRIPTION:
+# Set this to a space separated list of use flags
+# of which one must be turned on for the slot of
+# in use.
+
+# @ECLASS-VARIABLE: PYTHON_USE_WITH_OPT
+# @DESCRIPTION:
+# Set this if you need to make either PYTHON_USE_WITH or
+# PYTHON_USE_WITH_OR atoms conditional under a use flag.
+
+# @FUNCTION: python_pkg_setup
+# @DESCRIPTION:
+# Makes sure PYTHON_USE_WITH or PYTHON_USE_WITH_OR listed use flags
+# are respected. Only exported if one of those variables is set.
+if ! has ${EAPI} 0 1 [[ -n ${PYTHON_USE_WITH} || -n ${PYTHON_USE_WITH_OR}
]]; then
+ python_pkg_setup_fail() {
+ eerror ${1}
+ die ${1}
+ }
+
+ python_pkg_setup() {
+ [[ ${PYTHON_USE_WITH_OPT} ]] use !${PYTHON_USE_WITH_OPT}
return
+
+ python_version
+ local failed
+ local pyatom=dev-lang/python:${PYVER}
+
+ for use in ${PYTHON_USE_WITH}; do
+ if ! has_version ${pyatom}[${use}]; then
+ python_pkg_setup_fail \
+ Please rebuild ${pyatom} with use
flags: ${PYTHON_USE_WITH}
+ fi
+ done
+
+ for use in ${PYTHON_USE_WITH_OR}; do
+ if has_version ${pyatom}[${use}]; then
+ return
+ fi
+ done
+
+ if [[ ${PYTHON_USE_WITH_OR} ]]; then
+ python_pkg_setup_fail \
+ Please rebuild ${pyatom} with one of:
${PYTHON_USE_WITH_OR}
+ fi
+ }
+
+ EXPORT_FUNCTIONS pkg_setup
+
+ if [[ ${PYTHON_USE_WITH} ]]; then
+ PYTHON_USE_WITH_ATOM=${PYTHON_ATOM}[${PYTHON_USE_WITH/ /,}]
+ elif [[ ${PYTHON_USE_WITH_OR} ]]; then
+ PYTHON_USE_WITH_ATOM=|| (
+ for use in ${PYTHON_USE_WITH_OR}; do
+ PYTHON_USE_WITH_ATOM=
+ ${PYTHON_USE_WITH_ATOM}
+ ${PYTHON_ATOM}[${use}]
+ done
+ PYTHON_USE_WITH_ATOM=${PYTHON_USE_WITH_ATOM} )
+ fi
+ if [[ ${PYTHON_USE_WITH_OPT} ]]; then
+ PYTHON_USE_WITH_ATOM=${PYTHON_USE_WITH_OPT}? (
${PYTHON_USE_WITH_ATOM} )
+ fi
+ DEPEND=${PYTHON_USE_WITH_ATOM}
+ RDEPEND=${PYTHON_USE_WITH_ATOM}
+fi
+
# @FUNCTION: python_disable_pyc
# @DESCRIPTION:
# Tells python not to automatically recompile modules to .pyc/.pyo
signature.asc
Description: OpenPGP digital signature
Gentoo Security Project Summary -- was Re: [gentoo-dev] Project summaries
Gentoo Security Project Summary Short Summary: The Security Team is up and running, but we are dealing with numerous tasks and a high load in daily maintenance. Fresh blood is not only appreciated, but needed to continue the luxury of Security Support we currently have. We have too many open bugs, too many undrafted GLSAs that are eventually sent too slow, and a lot of channels to monitor. There are some bugs that need extensive amount of work to be resolved. The Security Team is also developing applications to support our workflow and user's systems, such as improvements to glsa-check and our DTD, a new Ruby on Rails application to draft GLSAs and an application to coordinate Kernel security support and check local systems. == Personal changes == === Lead Election === Since the last election had been longer than a year ago, we held a new election during the first two weeks of May. It was determined unanimously that Pierre-Yves Rofes (py) and Robert Buchholz (rbu) will be the new French-German duo that is our Team Leads. We would like to publicly thank Raphael Marichez (falco) and Matthias Geerdsen (vorlon) for doing the job the years past. They were both not available for another term. === Additions to the team === Alex Legler (a3li) recently joined the Security Team. However we still need more people helping with the daily maintenance work. This call for help applies to both developers and users. For more details on how to join the Security team, see: http://www.gentoo.org/proj/en/security/ Or, more specifically: http://www.gentoo.org/security/en/padawans.xml http://www.gentoo.org/security/en/coordinator_guide.xml http://www.gentoo.org/security/en/vulnerability-policy.xml http://www.gentoo.org/security/en/bug-searching.xml == Maintenance == === Bugs and GLSAs === We have reached new highs in the number of open bugs and the length it takes all of us to resolve them. A shortness in Gentoo developers in general and on our team is leading to three issues: (1) Security bugs are not resolved by ebuild maintainers Some security bumps are staying open for weeks with teams not responding to pings. Even issues that could be resolved before being public (what we call embargoed bugs) are not resolved due to maintainers not being responsive on such bugs. In fairness, I have to note this is limited to only some herds and not architectures. Architectures and in particular their Arch Security Liaisons are doing their job in a reliable and timely fashion. (2) GLSAs are delayed We're slow! We are sorry. I feel this is a great disappointment especially in those cases where maintainers and arch teams are doing a fast job and we take 4 weeks to write the accompanying GLSA. I see potential for improvement with the GLSAMaker rewrite described below. Contributors to GLSA writing are greatly welcome. (3) Security Team is not resolving bugs either In the past, we have been conducting simple version bumps ourselves or have masked vulnerable ebuilds. Currently, doing other people's jobs in the security process is mostly on hold as we have a hard time struggling to cope with our part of the job. === Documentation update === We actually updated our existing documentation to reflect more of our security process. Isn't that awesome? Read our project pages to find out more: http://www.gentoo.org/proj/en/security/ === GLSA dtd and glsa-check === We have been discussing changes to the GLSA DTD for ages now. There's few people interested in the subject and I have been slacking on it. I have picked up glsa-check maintenance recently and we will announce changes to the DTD to the dev lists as soon as they are fully drafted. Since the GLSA format is supported in all package managers, the change will be announced at least 6 weeks before going live. Oh, and glsa-check will see some bugs fixed, I hope. And support for UTF-8. And support for mask-glsas. Hmm.. anyone else here to help? glsa-check changes in 0.2.4: http://sources.gentoo.org/viewcvs.py/gentoolkit/branches/gentoolkit-0.2.4/src/glsa-check/ glsa-check changes in trunk (0.3): http://sources.gentoo.org/viewcvs.py/gentoolkit/trunk/gentoolkit/ New DTD proposals: http://git.goodpoint.de/?p=glsa-check.git;a=tree;h=refs/heads/glsa-2 == Feature extensions == === GLSAMaker === The GLSAMaker is a web application that we use to draft, comment on and refine GLSAs. It allows for the export of the GLSA texts and XML files you might know from gentoo-announce or /usr/portage/metadata/glsa. The application is considered helpful by all of us, however its shortcomings require to duplicate some work that could be automated and its usability makes working with it less fun than it could be and slows our work down quite a bit. Alex Legler (a3li) and Pierre-Yves Rofes (p-y) are currently working on a rewrite that covers the current functionality and extensions to ease the workflow dramatically by integrating metadata from Portage, Bugzilla, the CVE database and Secunia. We are
[gentoo-dev] Re: better support for binary packages
lx...@sabayonlinux.org posted fv50wm3klntqyetcw4uyaxe124vaj_fire...@mail.gmail.com, excerpted below, on Mon, 25 May 2009 12:16:06 +0200: This is what I am doing in Sabayon, creating a new layer over Portage = Entropy. I'm almost done, just need to work out some documentation and apidocs. http://gitweb.sabayon.org/?p=entropy.git;a=summary Agreed. Gentoo is in general a from-source metadistribution. There's limited support for binary packages in at least one of the package managers (portage), but honestly, that's not what Gentoo's best at, and I don't believe that will ever change without making it significantly worse at what it IS best at now, the normal from-source Gentoo we know and love. Better to leave the serious distribution level binary repackaging to the Gentoo-based distributions like Sabayon. Let them do what they do best, and let Gentoo continue doing what it does best. By definition, binary packaging isn't broken and doesn't need fixed, as that's not part of what defines Gentoo, so don't fix what ain't broken! =:^) That said, I could envision an eselect like binary profile switcher, that subject to settings in a config file, changes USE flags, CFLAGS, gcc- configs an appropriate gcc version, etc, changing PKGDIR appropriately as well, so one could easily enough create as many binary profiles as desired and as the use case dictated. It's likely various reasonably large Gentoo deployments are already doing something like this as it could certainly be scripted, but an emergable package to make it easy for ordinary joe Gentoo user would be useful, and I believe appreciated by many. (Here, I'd put it to use when testing new gcc versions, making it easy to swap out PKGDIRs and revert to the old version either per-package or system-wide, if the new version was breaking too much.) So here: No to the whole big complicated let's fix Gentoo binaries thing. There's already Gentoo-based binary solutions like Sabayon for those so interested, and I can't see Gentoo doing better than they're doing, at least not without breaking the from-source that Gentoo's good at. But yes to anyone interested in developing a nice new binary profile switcher to make managing binary package sets easier for those Gentoo admins that would find such a thing useful. Whether they then start making those profiles public and whether anyone else chooses to use them is entirely up to the individual admins whose systems would be affected. -- 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
[gentoo-dev] Regarding Gentoo CDs and accessibility sizes
Hello, I'm afraidd I'm not seeing the size issues. Adding Speech to a LiveCD should not effect the operations of the minimal installation CDs that much. However, one thing I would suggest is to please be aware of two things: 1. Make sure that some boot prompt exists for users to activate the LiveCD speech output. I.e. Gentoo speech That kind of thing. 2. Lynx and other browsers with Speakup usually need some configuration, along with Irssi. You can't just open Irssi right off the shelf and expect speech-access to it. Regards, --Keith
Re: [gentoo-dev] Regarding Gentoo CDs and accessibility sizes
On 05/25/2009 07:44 PM, Keith Hinton wrote: Hello, I'm afraidd I'm not seeing the size issues. Adding Speech to a LiveCD should not effect the operations of the minimal installation CDs that much. However, one thing I would suggest is to please be aware of two things: 1. Make sure that some boot prompt exists for users to activate the LiveCD speech output. I.e. Gentoo speech That kind of thing. 2. Lynx and other browsers with Speakup usually need some configuration, along with Irssi. You can't just open Irssi right off the shelf and expect speech-access to it. Why do you keep creating new threads just to interject your random opinion about some other existing thread? Have you ever participated in a mailing list? This isn't IM/IRC. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] Regarding Gentoo CDs and accessibility sizes
Andrew Gaffney wrote: On 05/25/2009 07:44 PM, Keith Hinton wrote: Hello, I'm afraidd I'm not seeing the size issues. Adding Speech to a LiveCD should not effect the operations of the minimal installation CDs that much. However, one thing I would suggest is to please be aware of two things: 1. Make sure that some boot prompt exists for users to activate the LiveCD speech output. I.e. Gentoo speech That kind of thing. 2. Lynx and other browsers with Speakup usually need some configuration, along with Irssi. You can't just open Irssi right off the shelf and expect speech-access to it. Why do you keep creating new threads just to interject your random opinion about some other existing thread? Have you ever participated in a mailing list? This isn't IM/IRC. Let's try to be more polite please. I do agree that creating a new thread wasn't warranted in this case but we can get the point across a little better. People need to start with something and many times they make mistakes. Regards, Petteri signature.asc Description: OpenPGP digital signature
