[gentoo-dev] Summary and future of Gentoo stats server/client
Hello again! Today 19:00 UTC is "firm pencils down" for Gentoo Google Summer of Code. That means .. we enter the phase where you should *join me* with development. Looking at http://soc.gentooexperimental.org/projects/stats/issues there is a more work to do (and will always be), both Gentoo-specific stuff, as well as cross-distro free software domination stuff. To name a few: - Paludis support - Generation of graphs - PackageMap integration Especially in the end I had to focus on really essential stuff, otherwise there would be no test instance running to try out by now. However, we did move from we-really-should-have-stats to fork-yeah-we-have-stats. A quick-export of the documentation with overview on deliverables is currently up here: http://www.hartwork.org/gsoc2009/gentoo_gsoc_2009.html (The containing folder is served with index purposely.) So: - Yes, there is more work to do - No, I will not run and stop working on it - Yes, I will get back to the ebuild quizes - Yes, I will keep pushing Smolt and PackageMap Last but not least there are a few people that I would like to say "thanks" to (in hopefully alphabetic order): Platinum section Robert Buchholz Fabian Groffen Andy Kittner Robin H. Johnson Mike McGrath Zac Medico Marat Radchenko Gold section Luca Barbato Aaron Bauman Daniel Buschke Hans de Graaff Tobias Klausmann Justin Lecher Sebastián Magrí Victor Ostorga Sebastian Schuberth Florian Steinel Markus Ullmann I hope I didn't forget anybody. Now please _really_ have a look at http://www.hartwork.org/gsoc2009/gentoo_gsoc_2009.html if you haven't done so before. If you have any questions or complaints please let me know. See you, Sebastian
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-08-16 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-08-16 23h59 UTC. Removals: net-misc/d4x2009-08-10 08:40:45 ssuominen perl-core/IO-Compress-Base 2009-08-10 13:04:51 tove perl-core/IO-Compress-Bzip2 2009-08-10 13:04:51 tove perl-core/IO-Compress-Zlib 2009-08-10 13:04:51 tove perl-core/IO-Zlib 2009-08-10 13:04:51 tove virtual/perl-IO-Compress-Base 2009-08-10 13:07:21 tove virtual/perl-IO-Compress-Bzip2 2009-08-10 13:07:26 tove virtual/perl-IO-Compress-Zlib 2009-08-10 13:07:27 tove virtual/perl-Compress-Zlib 2009-08-10 13:07:28 tove perl-core/Compress-Zlib 2009-08-10 13:08:43 tove dev-perl/parent 2009-08-10 21:51:53 tove dev-perl/Parse-CPAN-Meta2009-08-10 21:51:54 tove x11-drivers/synaptics 2009-08-13 13:35:05 remi x11-drivers/xf86-input-calcomp 2009-08-13 13:35:06 remi x11-drivers/xf86-input-digitaledge 2009-08-13 13:35:06 remi x11-drivers/xf86-input-dmc 2009-08-13 13:35:06 remi x11-drivers/xf86-input-dynapro 2009-08-13 13:35:06 remi x11-drivers/xf86-input-elo2300 2009-08-13 13:35:06 remi x11-drivers/xf86-input-jamstudio2009-08-13 13:35:07 remi x11-drivers/xf86-input-magellan 2009-08-13 13:35:08 remi x11-drivers/xf86-input-magictouch 2009-08-13 13:35:08 remi x11-drivers/xf86-input-microtouch 2009-08-13 13:35:08 remi x11-drivers/xf86-input-palmax 2009-08-13 13:35:08 remi x11-drivers/xf86-input-spaceorb 2009-08-13 13:35:08 remi x11-drivers/xf86-input-summa2009-08-13 13:35:09 remi x11-drivers/xf86-input-tek4957 2009-08-13 13:35:09 remi x11-drivers/xf86-input-ur98 2009-08-13 13:35:09 remi dev-util/freeride 2009-08-14 09:11:43 graaff media-sound/mppenc 2009-08-14 17:34:29 ssuominen dev-python/pyxfce 2009-08-15 07:02:35 ssuominen Additions: dev-perl/ExtUtils-XSpp 2009-08-10 12:05:31 tove perl-core/IO-Zlib 2009-08-10 13:14:30 tove virtual/perl-i18n-langtags 2009-08-10 19:24:23 tove virtual/perl-Package-Constants 2009-08-10 19:42:06 tove virtual/perl-Filter 2009-08-10 19:53:39 tove perl-core/parent2009-08-10 21:17:40 tove dev-libs/gf2x 2009-08-10 21:17:50 bicatali virtual/perl-parent 2009-08-10 21:21:03 tove perl-core/Parse-CPAN-Meta 2009-08-10 21:22:45 tove virtual/perl-Parse-CPAN-Meta2009-08-10 21:26:54 tove net-misc/cnetworkmanager2009-08-11 09:16:52 dagger dev-php5/pecl-ssh2 2009-08-11 17:11:32 hanno games-rpg/lure 2009-08-11 22:52:58 mr_bones_ x11-misc/shutter2009-08-12 09:24:29 hwoarang app-cdr/qmultirecord2009-08-12 19:07:49 ssuominen virtual/eject 2009-08-12 19:22:15 ssuominen media-libs/celt 2009-08-13 00:00:05 tgurr dev-libs/tinyxml2009-08-13 02:26:57 ssuominen app-admin/eselect-audicle 2009-08-13 21:30:41 cedk media-plugins/alsaequal 2009-08-15 20:06:33 ssuominen media-sound/pitchtune 2009-08-15 20:26:41 ssuominen dev-perl/Set-Object 2009-08-15 20:51:21 tove x11-themes/gtk-engines-nodoka 2009-08-16 11:45:49 a3li dev-libs/libnfc 2009-08-16 14:18:29 ikelos app-text/cuneiform 2009-08-16 15:35:24 pva app-text/yagf 2009-08-16 15:46:30 pva games-util/vispatch 2009-08-16 22:39:56 mr_bones_ -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-misc/d4x,removed,ssuominen,2009-08-10 08:40:45 perl-core/IO-Compress-Base,removed,tove,2009-08-10 13:04:51 perl-core/IO-Compress-Bzip2,removed,tove,2009-08-10 13:04:51 perl-core/IO-Compress-Zlib,removed,tove,2009-08-10 13:04:51 perl-core/IO-Zlib,removed,tove,2009-08-10 13:04:51 virtual/perl-IO-Compress-Base,removed,tove,2009-08-10 13:07:21 virtual/perl-IO-Compress-Bzip2,removed,tove,2009-08-10 13:07:26 virtual/perl-IO-Compress-Zlib,removed,tove,2009-08-10 13:07:27 virtual/perl-Compress-Zlib,removed,tove,2009-08-10 13:07:28 perl-core/Compress-Zlib,removed,tove,2009-08-10 13:08:43 dev-perl/parent,removed,tove,2009-08-10 21:51:53 dev-perl/Parse-CPAN-Meta,removed,tove,2009-08-10 21:
[gentoo-dev] Re: Re: Re: Re: stacking profile.bashrc?
Zac Medico wrote: > Steven J Long wrote: >> Zac Medico wrote: >> >>> Steven J Long wrote: Yeah sounds right. Perhaps a per-category bashrc split (both for usual /etc/portage case and for overlays) might also be useful? (Overlay admin can always test PN should the need arise.) >>> Maybe that's more in the domain of eclasses (or some sort of elibs >>> is they don't need to change metadata), in cases when it's easy >>> enough to inherit whichever ones are needed. >>> >> Well the directory-based approach is for network/overlay admins or >> downstream distros to tweak stuff without needing to edit and digest >> ebuilds in a local overlay. JavaJake wanted to split the actual phases, >> so we have a directory per-phase, which can ofc easily be done with a bit >> of BASH or shell-script from the existing bashrc. This seems more useful >> for end-user admins (whether local or network.) > > That seems like a reasonable use-case for per-phase sourcing. > Yeah, not something I see myself using a lot but I can see the attraction for an end-user. (Standard technique is to only run scripts/include config if they are marked executable.) OFC the utility is limited, as ferringb outlined many moons ago [1], since the only variables available for an external as opposed to source'd scriptlet are those exposed in the process environment. I guess that argues for just sourcing those? Dunno, some input from javaJake would be good here, eh? ;) [1] recommended for anyone who wants more insight into why we have bashrc the way we do: http://www.mail-archive.com/gentoo-portage-dev%40lists.gentoo.org/msg00544.html >> For an overlay, from what I've seen in my limited exposure to the issue, >> there is more of a need for influencing metadata, eg IUSE. .. That ties >> in more with the next point; although as you say it could be done by >> inheritance from an eclass, again that potentially involves editing the >> ebuild. > > Note that any changes to ebuild metadata generation mean changes in > metadata cache validation. For example, if you want to modify ebuild > metadata from profile.bashrc, then you have to make sure to > invalidate metadata cache any time the profile.bashrc is modified. Is there some sort of issue with mtime checks that isn't dealt with via git's technique of a config-flag for coarser-grained checks? (I'm all for stricter digest based checking as well, but it seems odd we can't use the mtime to key off, at least by default.) > If such a change affects all ebuilds in the repo, it can be time > consuming to regenerate all of the metadata cache. Also, if the > cache validation mechanism isn't robust enough, users will > experience annoying issues with stale cache. Certainly seems to be room to play with cache generation, or better to allow overlay to distribute a per-repo cache. That could be rsync'ed alongside the standard vcs-managed files, to avoid the hit of storing it in the vcs. Might be worth considering a git digest as one of the types? >> With the existing bashrc capability end-users can do all this ourselves; >> it'd just be nice to be able to do it in overlays, and for what we >> already have to be specified since it applies to both pkgcore and >> portage, and has done for several years. > > We might want to have two separate bashrcs. One that's per-phase, > and another one that's only sourced once. If it's only sourced once > then it might allow you to make more radical changes that you > couldn't otherwise make without breaking uninstall phases in some way. > That sounds nice; we have clear exemplars of use-case for each one. We're really looking at two types: metadata-only and user (use latest version whenever we're called, and don't save in binpkg) with policy enforced for tree or overlay. You mentioned in #-portage that per-phase execution is no longer used, wrt how overlays would only be executing bashrc at start. I take it we can still test $EBUILD_PHASE? (Sorry if I've misunderstood what you were saying.) >>> Current portage bashrc support allows $EBUILD_PHASE conditionals, >>> but I think in the long term we may want to drop that in favor of >>> function hooks that are sourced only once. The $EBUILD_PHASE >>> conditional approach just seems somewhat clumsy in comparison >>> (sourcing the bashrc during every phase might also be considered >>> inefficient/ugly). >> >> My only concern here is that changes the admin makes, eg in >> post_pkg_postinst, won't be reflected in uninstalling a package which was > > I assume you mean post_pkg_postrm, since post_pkg_postinst is never > executed during uninstall. Er yeah, sorry was tired and tidying up before holiday. > Well, it is for the replacing package, if > there is one, but that should have the latest environment anyway (at > least, assuming it's not a binary package). > Yeah binary packages were the other concern. >> installed before the change. For the DEPEND phase, as in IUSE >> modification, that's not
[gentoo-dev] Re: Re: Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Ciaran McCreesh wrote: > On Thu, 13 Aug 2009 19:22:16 +0100 > Steven J Long wrote: >> > PMS accurately reflects the Portage documentation and the commit >> > message that introduced the feature -- it's purely for use >> > in /etc/portage/, which is beyond the scope of PMS. >> > >> If it's pre-EAPI it's part of EAPI '0'. That you neglected to >> document it, for whatever reason, is irrelevant. > > No, it's not part of EAPI 0. If it's a feature that is pre-PMS, it's part of EAPI-0. The definition is flexible, presumably to avoid this kind of runaround. > It's an accident. If you'd like another > example of an accident, Portage won't complain if you stick garbage in > certain metadata keys; this does not mean PMS should say that it's > legal to put garbage in metadata keys. > That's irrelevant and you know it, apart from being one of your usual political digs at portage. >> > It is not the business of PMS to enforce undocumented features >> It's not undocumented, as you just pointed out above. > > Using it in the tree is undocumented. But it's not an "undocumented feature" is it? > Using it in user configuration is beyond the scope of PMS. Define 'user' >> > that Portage supports only by accident >> Oh, so now you know the minds of the portage developers? > > Yes. No, you clearly do not, as this shows: > I know that they said when adding the directory feature that it > was for use in user configuration files. That's what the commit message > said, and that's what the documentation patch said. The documentation > change explicitly only allowed the feature in user configuration, not > the tree. > > Had the feature intended to be tree-usable, the documentation change > would have said so. > Thanks for explaining what "the Portage documentation and the commit message" means. And yeah, you can read it. Well done. It *does not* mean you know what future directions might have been envisaged. >> > and that aren't used in the tree. >> >> Circular argument, don't you think? It's not in-tree so we won't put >> it in PMS. It's not in PMS, so it's not allowed in-tree. > > That's only a circular argument if you snip out the rest of the > sentence. > Nonsense. You gave the fact that it's not used in the tree as a reason not to put it in PMS, did you not? I merely addressed it separately, since it is a distinct semantic component. >> I'd like to ask the Council to consider whether EAPI development has >> not in fact supplanted a large part of the GLEP process (specifically >> the technical aspects to do with ebuild development.) As such, >> insisting on all discussion on bugzilla is in fact a subversion of >> the original process that people have agreed upon. > > Moving the discussion to bugzilla was the Council's decision, not mine. > Yes, well, I didn't ask you. I asked the Council to consider the broader picture, which is their role, since effectively GLEPs are now only for non-technical things, or might as well be, since all future ebuild directions are EAPI by definition. Having wider input (which is what this list is for) might avoid future blind-alleys. Nevertheless, I'm sure they'll take your valuable insight under consideration, as well as the history and any lobbying that might have gone on at the time, assuming they were around and haven't suppressed the memory. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: Re: Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Le 18/08/2009 03:30, Steven J Long a écrit : [snip] Steven, This thread was dead for more than 4 days. Yet you pick it up and you try to pick a fight with Ciaran. I for one am tired of your behavior on this list and I will not hesitate to contact UserRel to get you out of this list if you don't settle down and start acting like an adult. Now step away from this thread. Thanks Rémi
