Re: [gentoo-dev] RFC: EAPI cheat sheet for your desktop
On Tue, 2009-03-31 at 18:48 +, Ferris McCormick wrote: On Tue, 2009-03-31 at 19:21 +0200, Christian Faulhammer wrote: Hi everyone, with EAPI 3 confusion about what is in which EAPI may increase, although appendix E of the PMS is quite helpful here. Anyway, something handy to put on your desk is my little EAPI leaflet which gives you all important (in my eyes) information in one leaf. Have a look at URL:http://v-li.de/temp/eapi_cheatsheet.pdf, print it, fold it and tell me if you like or not (and especially what exactly). V-Li I like it. It's useful to me, at least, and I like having this information available where I can find it in case I need it. +1 /haubi/ -- Michael Haubenwallner Gentoo on a different level
[gentoo-dev] Re: Please review: prefix.eclass
Hi, Donnie Berkholz dberkh...@gentoo.org: On 12:59 Fri 27 Mar , Fabian Groffen wrote: This eclass facilitates in some of the needs of the Gentoo Prefix project. For now it provides the 'eprefixify' function, which is often used in Gentoo Prefix ebuilds to incorporate the used offset prefix into files. It's great to see you moving toward folding this back into the main tree! My only comment is that eprefixify could really use a better name because that one sounds really awkward. How about doprefix, or something else? To install a prefix file? Like doman, dobin. :) 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
[gentoo-dev] Re: Small change: Global USE flag nsplugin
Hi, Jan Kundrát j...@gentoo.org: Christian Faulhammer wrote: Ok. What about: Build media plugin for browsers supporting the Netscape plugin architecture such as www-client/mozilla-firefox Build media plugin for browsers supporting the Netscape plugin architecture (that is almost any modern browser) Thanks. Very similar description used. 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
[gentoo-dev] Monthly Gentoo Council Reminder for April
This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every GLEP *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
2009/4/1 Mike Frysinger vap...@gentoo.org: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. I would like the Council to discuss the matter of Portage repeatedly changing behaviour in ebuild-visible ways without an EAPI bump or even an announcement that anything changed. Notable examples include .lzma support in unpack (bug 207193), the change in pkg_* phase ordering (bug 222721) and the preservation of timestamps during merge (bug 264130). It is quite frustrating to spend considerable effort determining Portage's behaviour and matching it in Paludis, only to find a few months later that Portage changed and now users are getting broken packages if not broken systems because ebuilds are starting to rely on the new rules. (The /really/ hilarious part is that certain people then accuse /us/ of being uncooperative and not caring about compatibility.) This needs to be dealt with if Gentoo is ever going to take the idea of PMS, or indeed EAPI itself, at all seriously.
Re: [gentoo-dev] Preserving mtimes for EAPI3
On Tue, 31 Mar 2009, Michael Haubenwallner wrote:
On Mon, 2009-03-30 at 19:14 +0200, Ulrich Mueller wrote:
1. Record two timestamps:
before calling pkg_setup, timestamp1;
after src_install has completed, timestamp2.
2. After src_install and before merging (the exact time would be
implementation dependent), scan ${D} for files having
mtime timestamp1 or mtime timestamp2.
Update their mtimes to timestamp1 or timestamp2, respectively.
3. Otherwise (i.e. for files with timestamp1 = mtime = timestamp2),
preserve modification times when merging ${D} to ${ROOT}.
Or, even shorter: The basic idea is to preserve the mtimes from ${D}
when merging. Except for old mtimes which will be advanced to the
time when the build process began. (And mtimes from the future will
also be fixed, but this case should normally not occur.)
But from discussions in #-dev I conclude that several people would be
happier if just mtimes from ${D} were preserved. In fact, this is the
current Portage and Pkgcore behaviour.
One could think about making step 1 and 2 of above procedure optional
(which was what I had originally in mind, see [1]). Then there would
be no need to change anything in Portage and Pkgcore. Or Portage could
control it via FEATURES, giving the user the choice.
Maybe this could be done somehow like this, with 'merge time'
calculation for each file based on above steps 1.-3.:
* When a to-be-merged file does not exist before, set mtime to
'merge time'.
* When a to-be-merged file does exist already, and its content
does not change, take the mtime from the already existing file.
* When a to-be-merged file does exist already, and its content
does change, set mtime to 'merge time'.
Unfortunately, this will not work. Looking at Lisp again, it may lead
to a fasl file older than the corresponding lisp (imagine that there
could be only a comment change in the source, and the compiled file
would be identical). Also setting mtime to merge time will break
some packages (see bug 83877 [2] for an example).
Maybe this should be done for header files only, or with some black- or
whitelisting mechanisms, or for files which have mtime'build time'?
Too complicated, for my taste.
Ulrich
[1] https://bugs.gentoo.org/show_bug.cgi?id=264130#c12
[2] https://bugs.gentoo.org/show_bug.cgi?id=83877
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On , 01 Apr 2009, Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Since EAPI 3 is on the agenda already, I would ask the council to consider inclusion of mtime preservation (see bug 264130, and the thread Preserving mtimes for EAPI3 in this ML). The proposal comes in two variations (to be decided upon): a) mtimes fixup and preservation of mtimes when merging are both mandatory. (This would require changes in all package managers.) b) mtimes fixup is optional, preservation of mtimes is mandatory. (This wouldn't require any immediate changes in Portage and Pkgcore.) Ulrich
Re: [gentoo-dev] RFC: EAPI cheat sheet for your desktop
On Wednesday 01 April 2009 11:37:58 Michael Haubenwallner wrote: On Tue, 2009-03-31 at 18:48 +, Ferris McCormick wrote: On Tue, 2009-03-31 at 19:21 +0200, Christian Faulhammer wrote: Hi everyone, with EAPI 3 confusion about what is in which EAPI may increase, although appendix E of the PMS is quite helpful here. Anyway, something handy to put on your desk is my little EAPI leaflet which gives you all important (in my eyes) information in one leaf. Have a look at URL:http://v-li.de/temp/eapi_cheatsheet.pdf, print it, fold it and tell me if you like or not (and especially what exactly). V-Li I like it. It's useful to me, at least, and I like having this information available where I can find it in case I need it. +1 /haubi/ +1 . Very handy :) -- Markos Chandras (hwoarang) Gentoo Linux Developer Qt/KDE/Sunrise/Sound Web: http://hwoarang.silverarrow.gr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: EAPI cheat sheet for your desktop
On Tue, 31 Mar 2009, Christian Faulhammer wrote: Have a look at URL:http://v-li.de/temp/eapi_cheatsheet.pdf, print it, fold it and tell me if you like or not (and especially what exactly). The Gentoo store should have a coffee mug with this. ;-) Ulrich
Re: [gentoo-portage-dev] Google SoC and cache sync
Zac Medico wrote: The way that I imagine the cache sync idea should be implemented is like paludis's unavailable repository which uses of tarball to distribute package metadata[1]. The tarball approach that they use seems pretty reasonable. However, it would probably also be nice to be able to use a protocol such as rsync to download the metadata/cache/ directory from the same URI which is used to fetch the ebuilds themselves (maybe paludis supports this already, I don't know). You're offering two different ideas here, right? The unavailable repository method, and the method using the metadata/cache/ directory? If so, it makes sense to me to take the metadata/cache/ directory route, since, as you said, multiple repositories aren't yet supported in portage. At first I was thinking I could contact the guy who might be working on multiple repository support this summer and work with him to some extent... but the unavaliable repository solution would basically be dependent on/building off of multiple repository support, and it seems like building off of something that isn't fully built would be a bad idea. And to clarify: the goal of the project is to modify portage so that instead of fetching all of the ebuilds in the portage tree (or in an overlay) upon a sync, portage only fetches the metadata and cache info (via the metadata/cache/ directory) of the tree, and the ebuilds of packages that are already installed (packages found in the world file?) And then, additional ebuilds would be fetched only when they are needed? Or will only metadata/cache/ be fetched upon sync, and then all ebuilds will be fetched only when they are needed? Am I completely oversimplifying the project? Thanks so much for your help, Emma On Tue, Mar 31, 2009 at 6:41 PM, Zac Medico zmed...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Emma Strubell wrote: Hi all. So, I'd love to do Google's Summer of Code with you guys. I was perusing the list of ideas on the Gentoo wiki, and the cache sync idea seems pretty interesting, especially since it concerns the overall speed of portage, including search, which of course I've already started some work on. However, there is no contact person associated with that project! I figured I'd come here before going to #gentoo-soc to see if anyone is interested in mentoring me on this project, since it seemed like a few of you might be interested. The way that I imagine the cache sync idea should be implemented is like paludis's unavailable repository which uses of tarball to distribute package metadata[1]. The tarball approach that they use seems pretty reasonable. However, it would probably also be nice to be able to use a protocol such as rsync to download the metadata/cache/ directory from the same URI which is used to fetch the ebuilds themselves (maybe paludis supports this already, I don't know). In order for the clients to be able to download the metadata/cache/ directory, first that directory has to be populated (as is done on gentoo's master rsync server). I'm currently working on a tool called 'egencache' that overlay maintainers will be able to use in order to populate the metadata/cache/ directory [2]. It will be included in the next portage release. Before we implement something like unavailable repository for portage, first we'll have to add multiple repository support, and that's a decent sized project of it's own. Somebody has mentioned interest in multiple repository support on the gentoo-soc list [3], but they haven't submitted a proposal to http://socghop.appspot.com yet. [1] http://paludis.pioto.org/configuration/repositories/unavailable.html [2] http://bugs.gentoo.org/show_bug.cgi?id=261377 [3] http://archives.gentoo.org/gentoo-soc/msg_e383863a6748e367e13fe53b092f3908.xml - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAknSnA4ACgkQ/ejvha5XGaO6tACgjzAsoXP0cJd0Vr1vJxU2CvLQ JtwAn2Sj+GxLyyRpOIdbejPirCljmF2c =k5u1 -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Google SoC and cache sync
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: Emma Strubell wrote: And to clarify: the goal of the project is to modify portage so that instead of fetching all of the ebuilds in the portage tree (or in an overlay) upon a sync, portage only fetches the metadata and cache info (via the metadata/cache/ directory) of the tree, and the ebuilds of packages that are already installed (packages found in the world file?) And then, additional ebuilds would be fetched only when they are needed? The problem with fetching the ebuilds separately is that the remote repository might have changed. So, it's not a very reliable approach unless there is some kind of guarantee that the remote repository will provide a window of time during which older ebuilds that have already been removed from the main tree can still be downloaded. In order to accomplish this, you'd essentially have to devise a new source package format which can be downloaded as a single file (something like a source rpm file that an rpm based distro would provide). Expanding on this a bit... if you were going to pack an ebuild into a single file, you would need to include the eclasses which it inherits and also any patches that are included with it in cvs. If the eclasses are included in this way, each source package will contain a redundant copy of the inherited eclasses. Despite this redundancy, you might still have a net decrease in bandwidth usage since you'd only have to download the source packages that you actually want to build. If you are going to implement something like this, I imagine that you'd create a tool which would pack an ebuild into a source package and optionally sign it with a digital signature. Source packages would be uploaded to a server which would serve them along with a metadata cache file that clients would download for use in dependency calculations (similar to how $PKGDIR/Packages is currently used for binary packages). - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAknUT0oACgkQ/ejvha5XGaPmugCfVs0I4a15trwTgLnPwBac2xOj wI0AoInp1Jf6yaYV5rNvU2EXHbZ30AkS =tNrz -END PGP SIGNATURE-
