[gentoo-dev] Packages up for grabs
Due to permanent lack of time, I'm unable to properly maintain the packages below. Feel free to take them over. I'll remove myself from metadata.xml in 14 days. app-admin/389-admin-console app-admin/389-console app-admin/389-ds-console app-admin/aws-as-tools app-admin/aws-elb-tools app-admin/aws-iam-tools app-admin/aws-rds-tools app-emulation/edumips64 dev-java/idm-console-framework dev-libs/389-adminutil dev-libs/mozldap dev-libs/svrcore dev-perl/perl-mozldap net-nds/389-admin net-nds/389-ds-base net-libs/libgrss www-apache/mod_nss www-apps/389-dsgw x11-apps/ardesia x11-apps/spotlighter x11-apps/python-whiteboard x11-apps/whyteboard x11-drivers/cwiid -- Fabio Erculiani
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On May 31, 2014 8:42 PM, Robin H. Johnson robb...@gentoo.org wrote: On Fri, May 30, 2014 at 06:10:40PM +0300, Samuli Suominen wrote: I can't find anyone with access that actually replies to mails, pings, ... to genkernel repository for: https://bugs.gentoo.org/show_bug.cgi?id=461828 I'll p.mask it on amd64 profiles if noone replies soon :( My excuse is AFK baby, literally sleeping on me right now, and not even 2 months old. I saw floppym's original comment opening the bug, but none of the followups due to baby eating my life. I'll apply this patch later today if I have a chance, but I do agree with the general sentiment of this thread that the kernel configs NEED to get out of genkernel; so that arches can touch them at will, and other initramfs/kernel build tools can start to use them. In the absence of any other prompt complaints, I'll create a kernel-configs repo, and move the configs there. It would be better if those would be put in individual source pkgs in a way that they can be picked up by genkernel. Kernel config belongs to kernel pkgs, pretty much like init scripts or config files belong to their own project pkgs. The one thing that WILL have to be maintained in genkernel still, and in-sync with kernel changes, are the modules_load files, esp when new common stuff is added to the kernel (disk controllers filesystems most commonly). -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Sat, May 31, 2014 at 9:06 PM, Robin H. Johnson robb...@gentoo.org wrote: No, I don't agree that kernel configs belong to kernel packages. In general, barring the crazy option explosion, these are meant to be stock working configs that should in combination with ANY kernel package, produce a working kernel. Then you are just moving the problem around. I believe that kernel configs should be provided by their own kernel packages (and there are some, not just gentoo-sources) because it is much easier to keep them in sync on every new release and deal with each version separately if/as needed (including testing!). How are you dealing with config var name changes between different kernel versions or just different pkgs then? You cannot possibly support all kernel versions for all kernel pkgs available in tree with just one single config file in a sane, clean and maintainable way, hoping that a change in this file will not affect previous or future kernel releases. How are you going to test your config changes against old kernel pkgs? Each test is quite expensive to run. Good luck with that :-) [...] -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 -- Fabio Erculiani
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
configs should have never gotten into genkernel in the first place. it's each kernel pkg (or even version) that owns a valid config of itself. I am part of genkernel@ but I have no will nor time to fix it. And when I have, I'd rather work on genkernel-next, that comes with a much more readable initramfs code (that I managed to rewrite myself). Wiping the whole config files has been on my agenda for very long time already. On Fri, May 30, 2014 at 6:32 PM, Rich Freeman ri...@gentoo.org wrote: On Fri, May 30, 2014 at 1:02 PM, Ben Kohler bkoh...@gmail.com wrote: As nice at it sounds to just DROP these configs, that option is not really feasible considering the way we currently use genkernel in our handbook. Relying on the kernel's own defconfig, genkernel all will NOT produce the same mostly-usable-on-any-hardware result that we now rely on. Considering that the configs are more generically useful than genkernel, having them separately maintained sort-of makes sense. Then genkernel is a kernel build/install/initramfs tool, not a config management tool. I'd stick them someplace where any dev can get to them, and separate them from the genkernel functional code base. As far as who takes care of them goes - I suggest that this stuff comes out of the devmanual unless somebody steps up to take care of them. Those who take care of them become those who want to keep them around. You can't toss out a tool and ask for it to be a recommendation but point to others that you think need to maintain its configuration. Rich -- Fabio Erculiani
Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)
On Mon, Jan 13, 2014 at 10:15 AM, C. Bergström cbergst...@pathscale.com wrote: On 01/13/14 03:43 PM, Alexander Berntsen wrote: Where I work uses pkgcore[1], but not the areas which are generally beneficial to the whole community. (We use it as part of a web application to handle testsuites which have build dependencies.) We can blah blah about performance of resolving package dependencies all day long, [...] Not sure about what you mean with blah blah. But given the amount of both disk caches (metadata, vdb cache) and memory caches (the in-memory aux_db cache that portage loads using pickle (it's a dict) takes like 70-100Mb of RAM on an average desktop system), Portage can still take *minutes* to calculate the merge queue of a pkg with all its deps satisfied. Ironically, launching the same emerge command twice, will take more or less the same time. Yeah, this is probably bad design... -- Fabio Erculiani
Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)
On Mon, Jan 13, 2014 at 5:49 PM, Alec Warner anta...@gentoo.org wrote: [...] This is not meant to imply that portage is always fast; there are plenty of other modules (such as the aforementioned backtracking) that can take a long time to find solutions. That is partially why you see Tomwij turning off that feature. It is helpful for users cause it can automatically find solutions for users that are otherwise unsolvable (and thus avoids the user having to find a solution to the depgraph manually.) Yeah, correct. But it would be nice if Portage backtrack_depgraph() would memoize (asynchronously serializing to disk, for instance) partial results for later use. AFAIR, last time I checked, it wasn't doing that. Also, it would be nice if the aux_db cache of the vdb could be stored in a sqlite3 db rather than in RAM. This dict is consuming a huge cut of memory for little reason (a single vdb.dbapi.match() can eat 100MB of RAM). We know how Python deals with freed memory... Sigh... -A -- Luis Ressel ara...@aixah.de GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD -- Fabio Erculiani
[gentoo-dev] Doing and then undoing slotmoves
Hi, 6 days ago gienah committed a bunch of slotmoves for the haskell glib/gtk stuff [1], basically moving the pkgs to slot 0 (from slot 2). This was done in file 4Q-2013. It turns out that the same gienah moved those pkgs to slot 2 (from slot 0) in 2Q-2013 [2]. I have never seen something like that and this generated an interesting bug in entropy (well, I fixed it...). What I am asking is quite simple though. Is this allowed? Should the previous slotmove be removed? Thanks, [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/updates/4Q-2013?view=log [2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/updates/2Q-2013?r1=1.1r2=1.2 -- Fabio Erculiani
Re: [gentoo-dev] Doing and then undoing slotmoves
On Wed, Dec 18, 2013 at 1:13 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: [ snip ] Finally, do we have a good way now to automate checks against this? The current PMS spec, as you quoted, allows one way moves only. For this reason, I guess that simulating the updates twice should result in no applicable updates on the second pass, unless a circular dependency is found. Assuming that the simulation step is more or less constant time (is it?), this could only take O(2n), O(n) normalized. I implemented something along these lines in entropy and it spotted the faulty slotmove lines. Paweł -- Fabio Erculiani
Re: [gentoo-dev] Re: [gentoo-user] OpenRc-0.12 is coming soon
On Fri, Aug 16, 2013 at 4:09 PM, Markos Chandras hwoar...@gentoo.org wrote: On 14 August 2013 16:43, Keith Dart ke...@dartworks.biz wrote: Re , William Hubbs said: All, This message is an announcement and a reminder. OpenRc-0.12 will be introduced to the portage tree in the next few days. If you are using ~arch OpenRc, the standard disclaimer applies: remember that you might be subject to breakage. I just got around to upgrading to it. When I did my /etc/conf.d/net file disappeared, and my network interface would not come up. There is not even a sample net file any more. I had to manually add it back, using a syntax I found on the wiki site. The package is now masked (openrc-0.12) because quite a few people lost their net configs I wonder if this has to do with bug #462674 which was about to generate a disaster on one of my old servers as well. Thankfully, the net config was stored in a local git repo and I just had to reset the its state to HEAD. Now I need to go sacrifice a cow to Linus to demonstrate my gratitude. So yep, ~arch being *this* broken is not so nice -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -- Fabio Erculiani
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 1:49 AM, Patrick Lauer patr...@gentoo.org wrote: Seeing the noise in #gentoo from people getting whacked in the kidney by the systemd sidegrade ... that's a very optimistic decision. Yes it is, because our policy has always been to follow upstream as much as possible. So your sarcasm is not fun. It'll cause lots of pain for users that suddenly can't start lvm properly and other nasty landmines hidden in the upgrade path. By stabilizing this early you're causing lots of extra work for others. How much time did you spend on trying to make GNOME 3.8 work with openrc? Because I spent so much that I ended up suggesting the GNOME team to require systemd. And systemd is the only thing that at this time, properly works with current and future GNOME releases. And GNOME 3.8 is at this time, only fully working with systemd (fully: if you don't think you need to be able to shutdown your computer and have proper session management... well, I'd remove the fully word myself.) Moreover, the lvm problem is caused by a very ancient and ill decision about doing what upstream tells you to avoid: have mdev in the initramfs and udev on the final pivot rooted system. This was just looking for troubles but the smarties at the time decided that they knew better... And now, tadam, the bug is served... People can use genkernel-next, which comes with _proper_ udev support (see --udev). I hope you understand that some of us will be very rude and just suggest to unmerge gnome on all support requests as it now moves outside our support range ... Have a nice day, Patrick -- Fabio Erculiani
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 4:10 PM, Alon Bar-Lev alo...@gentoo.org wrote: On Thu, Aug 8, 2013 at 5:01 PM, Fabio Erculiani lx...@gentoo.org wrote: Moreover, the lvm problem is caused by a very ancient and ill decision about doing what upstream tells you to avoid: have mdev in the initramfs and udev on the final pivot rooted system. This was just looking for troubles but the smarties at the time decided that they knew better... And now, tadam, the bug is served... People can use genkernel-next, which comes with _proper_ udev support (see --udev). I won't comment about the entire gnome monolithic windows like, vendor controlled system that we cooperate with. But the above statement is way too much... there should be nothing wrong in having mdev during boot. initramfs should be simple as possible and busybox provides this functionality well. The problem is in udev not in any other component, that probably expects now to run first and have total control over the boot process. I hope eudev does not suffer from this. If genkernel will start using udev instead of busybox, it will probably be the last day of me use it. Fellow developer, let me tell you one thing, go clone the git repo and see how --udev is implemented and realize that mdev is still supported as it was before. I am just waiting for the point in which you claim that systemd should be run at initramfs, because of the dependency lock-in, so you have almost the entire system within initramfs. While it may have several advantages, there is no pressing need in supporting systemd in the initramfs for now. Regards, Alon -- Fabio Erculiani
Re: [gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them
Some time ago I was also thinking about writing a test framework for testing live images through kvm. Of course I didn't manage to find time to try to arrange something in the end, but the idea is still popping up in my mind every now and then. -- Fabio Erculiani
Re: [gentoo-dev] Running tests using virtualx.eclass should be allowed to be forced to run in virtual X always
On Fri, Jul 19, 2013 at 1:40 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: [...] And non-deterministic tests are stupid, useless, broken tests. Amen. Even though there is that 1% of cases in where you want to have non-deterministic tests. For instance, if you want to run the same test thousands of times and randomly pick an initial state to see if you spot a scenario in where you have problems (concurrency problems)... :-) Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ -- Fabio Erculiani
Re: [gentoo-dev] Proper distribution integration of kernel *-sources, patches and configuration.
On Tue, Jul 2, 2013 at 9:36 AM, Sergei Trofimovich sly...@gentoo.org wrote: [ sorry, a lot to quote ] What upstream do you plan to report bugs when user possibly mixes all of it in one mess? Each of those is known to be unstable. The mix is just a disaster. Is gentoo's kernel team able to resolve user's OOpsen? ### ... and configuration. ### This problem is not only visible for patches, but also in the config. Insane :] Meet CONFIG_DEVTMPFS; forget to enable it, greet a failing boot. We're telling users to enable it in some places, in the handbook it's a single line you must read, on the Wiki it's kind of missing unless you are luckily on the right page, on the Quick Install book it is missing too. Forbid users install udev to ROOT=/ if running kernel does not support devtmpfs (easy to check by /proc/filesystems) No. As explained multiple times, this check is not reliable and doesn't work (chroot, binpkgs, containers without kernel, and so on...). Making sure that the user doesn't build an unbootable kernel is the way to go. -- Sergei -- Fabio Erculiani
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
I believe that end users would benefit more from kernel binary ebuilds (ebuilds building an actual kernel with an official config), rather than all this. -- Fabio Erculiani
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
On Mon, Jul 1, 2013 at 9:59 PM, Pacho Ramos pa...@gentoo.org wrote: El lun, 01-07-2013 a las 21:55 +0200, Fabio Erculiani escribió: I believe that end users would benefit more from kernel binary ebuilds (ebuilds building an actual kernel with an official config), rather than all this. I don't see them exclusionary, look different issues to me :/ (with completely different solutions I think) Of course I'm not saying that they're not orthogonal. OTOH I believe that the complexity of supporting something like this (the original proposal) is not linear. However, I don't see any problem with people implementing it btw... it's their time. -- Fabio Erculiani
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
On Mon, Jul 1, 2013 at 10:14 PM, Markos Chandras hwoar...@gentoo.org wrote: [...] It's really scary to have the BFQ in a stable gentoo-sources ebuild. BFQ is not that scary, it's just an iosched (and it's quite easy to write an iosched), what could possibly go wrong? Jokes apart, I've been using it in production for almost 2 years now (can't remember exactly). -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -- Fabio Erculiani
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
On Mon, Jul 1, 2013 at 10:24 PM, Christoph Junghans ott...@gentoo.org wrote: 2013/7/1 Fabio Erculiani lx...@gentoo.org: I believe that end users would benefit more from kernel binary ebuilds (ebuilds building an actual kernel with an official config), rather than all this. +1 The binary use flag for sys-kernel/*-sources in Funtoo implements exactly that. [OT] And why should you throw kernel sources at people as well? Separate pkgs is much better. I don't want to have kernel sources on my servers (for the same reason I don't want to have a compiler, and I've been able to sort this out as well). [/OT] Sorry for the OT. -- Fabio Erculiani -- Christoph Junghans http://dev.gentoo.org/~ottxor/ -- Fabio Erculiani
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
On Mon, Jul 1, 2013 at 11:26 PM, Anthony G. Basile bluen...@gentoo.org wrote: I'm pretty sure I hit a genuine deadlock with it. I've been trying to reproduce with debugging on but nothing yet. But, having said that: BFQ [Experimtental] This introduced an experimental io scheduler. Have fun with it, but don't dare use it in production else we will laugh. Don't trust outdated documentation. http://algo.ing.unimo.it/people/paolo/disk_sched/sources.php There is nothing about it in the latest BFQ patchset. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA -- Fabio Erculiani
Re: [gentoo-dev] eselect init
For me, the big selling points of eselect-init are: 1. as release engineer, i can prepare images that use either systemd or openrc (at present time these are the two supported options) and do it reliably, programmatically. 2. as distro maintainer, i can roll out a migration path from openrc to systemd (or vice versa). The properties of this migration path I am looking for are reliability and atomicity. Basically, once you move logind/consolekit detection to runtime (and believe it or not, many upstream just get it wrong), and have feature parity in the systemd units available (wrt openrc initscripts), switching over is a matter of 2 (soon 1) commands. Both of them are quite important, because there are scenarios in where systemd fits better than openrc, and scenarios in where openrc is a better fit (older kernels, production system with custom init scripts that are not worth the porting, etc). Making the switch between openrc and systemd easy is a big win (for both developers, distro maintainers, users) and makes Gentoo more attractive, but this is another topic... -- Fabio Erculiani
Re: [gentoo-dev] eselect init
Fix the reason why the wrapper got broken then. If the wrapper broke, it is most likely a symptom of a bigger problem. I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit (or /bin/sysvinit?), anyway... -- Fabio Erculiani
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
The final outcome I would love to see is that everybody eventually graduates from kindergarten :-) And perhaps introduce a culture-fit score in the recruiting, mentoring process. -- Fabio Erculiani
Re: [gentoo-dev] eselect init
There is a new version of eselect-init in the systemd-love overlay to play with. The new version saw the following major changes: - the /sbin/init (aka the symlink that eselect-init handles) can be changed to whatever one wants through make.conf [1] (this is a compile time option, as documented in the eclass) - only init is currently handled by eselect-init, which is now using a very small wrapper POSIX shell script to redirect the calls to the currently running init [2] - the wrapper and its code paths are now documented in the eselect-init eclass [2] [3] You need systemd and sysvinit from the same overlay for it to work. If you intend to use switch between systemd to openrc (and vice versa), make sure to install the rest of the packages in that overlay. At the moment, if you want to switch, you also need to use eselect-settingsd. However, I am planning to drop eselect-settingsd: openrc-settingsd and systemd share the same settingsd dbus interface while they call different executables, systemd initializes its dbus services without relying on dbus activation, so the Exec= part of the service descriptor file is currently set to /bin/false, this rings a bell :D, because it is possible to replace /bin/false with a script that starts the respective services when dbus activation is used (which means that systemd hasn't booted the system). This would make possible to remove the blocker dependency in openrc-settingsd and systemd somehow. [1] https://github.com/Sabayon/systemd-love/commit/ced29311348a81a2573b030b1316f1c3a0335c5b [2] https://github.com/Sabayon/systemd-love/commit/9eea3ff713c8fa0391e7b1bfa494d533dc21c0be [3] https://github.com/Sabayon/systemd-love/blob/master/eclass/eselect-init.eclass -- Fabio Erculiani
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
Thanks for the offer, I appreciate it, but I have to decline this time. -- Fabio Erculiani
Re: [gentoo-dev] Re: Re: eselect init
On Sun, Jun 2, 2013 at 8:20 PM, Steven J. Long sl...@rathaus.eclipse.co.uk wrote: [...] The whole symlink/boot/fallback thing is simply a waste of technical effort. And blanket your opinion and you didn't comment a week ago, so I don't have to deal with the substance of your points don't change that. Waste? We have multiple use cases for that as stated in several places (here, bugzilla, IRC, etc). If such use cases are of no interest for you, then you shouldn't be bothered. Please, make a better case next time. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-) -- Fabio Erculiani
Re: [gentoo-dev] Re: Making systemd more accessible to normal users
Good news. I've been able to make logind work with OpenRC and GNOME 3.6 (which means that GNOME 3.8 can work as well). Disclaimer: I use systemd as device manager. I don't know if my logind (there is a bug about it) works with udev without further hacking. See: https://plus.google.com/u/0/107663298003289209275/posts/TxjqZkniR9f Now, the problem is that, as I wrote before, we're more and more drifting away from what upstream is supporting. Today the source of all our troubles is just GNOME, I am afraid that tomorrow it will expand beyond it. There are technical advantages for both distro makers and desktop environment makers in using systemd (besides the disadvantages). For instance, having a centralized tool for collecting system and user logs is certainly something that would make our job easier, having working (or mostly working) init scripts provided directly by upstream projects would reduce our maintenance burden in the long run. Anyway, I'm not trying to convince anybody in using either init systems, I am just suggesting that you should try both and decide yourself. Which translated, is the same goal as making systemd more accessible to you. -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. And now that GNOME 3.8 is out, the game starts over again: logind is a hard requirement, logind is part of systemd, starting logind (which replaces consolekit) is not that trivial as you may think (and is the thing I started to work on anyway). And if this wasn't enough, it means that if you want GNOME 3.8, you need to get logind, which may or not may get included in our udev ebuild and if it won't, it means that you will be forced to use systemd as device manager if you want GNOME 3.8, which is believe it or not, the thing that Ubuntu did. The problem will only increase in size as the clock moves. And (and!) how does all this fit together with eudev? If the idea is to either put logind in udev (thus, not creating a separate logind ebuild), it means that eudev is already a dead end for GNOME users, unless the eudev team is going to provide logind as well. I don't want to start a flamewar here, I was the one who called Lennart software lennartware, but science is science, and a reality check had to be done: at some near point in the future, our users will be forced to replace udev/eudev with systemd. Like it. Or not. While I successfully use both openrc and systemd, I _do_ think that (and expect to see) more and more users (and developers) will be switching to systemd. Is there anything we can do? Besides being prepared, I don't think so. Do we control upstreams? No, sorry. So what do we want to do then? Isolate from the rest of the world? (It's not a sarcastic question). I hope that everybody does their own reality check. -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 8, 2013 at 5:26 PM, Ben de Groot yng...@gentoo.org wrote: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. This sounds really wrong (tm) to me. It took me two weeks to kill that silly systemd-units pkg. All the distros around here do install systemd units with their packages and I believe that the council has already spoken about this. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Ben de Groot schrieb: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. Note that a similar thing is already done with the selinux policy packages. Upstreams will _DO_ ship systemd units at some point in future. It's a completely different thing. Don't compare oranges to apples. Mostly the complaints against adding systemd units are that it would unnecessarily clutter non-systemd installs. Users who complain are told to set INSTALL_MASK but that is somewhat unwieldy. Cluttering a system by just installing 4kb files? The council has spoken. If you don't like the decision, I am sorry. I can say the same for init scripts, they are freaking cluttering my system and they're all over. Or perhaps all these man pages, I don't need man pages locally but still most ebuilds do install them. What do we do? Let's be serious here. A separate package for the unit file would solve this problem nicely. No, it will generate a gazillion of other problems. Like conflicts arising every single day, just to name one. Is that hard to do it right, as everybody else in this world does, and move on? Another option would be to add a dounit command to a future EAPI (like doinitd today) and make portage install them unless FEATURES=nounit (like nodoc/noinfo/noman today). Why all this mess!? Best regards, Chí-Thanh Christopher Nguyễn -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 8, 2013 at 5:49 PM, Ben de Groot yng...@gentoo.org wrote: On 8 May 2013 23:39, Fabio Erculiani lx...@gentoo.org wrote: On Wed, May 8, 2013 at 5:26 PM, Ben de Groot yng...@gentoo.org wrote: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. This sounds really wrong (tm) to me. It took me two weeks to kill that silly systemd-units pkg. All the distros around here do install systemd units with their packages and I believe that the council has already spoken about this. It sounds more wrong to me to be asking normal package maintainers to test and maintain unit files, while they don't use systemd themselves, nor have it installed. Nor would most of our users need this. Nobody is asking maintainers to test units. The systemd team is responsible for them. And I believe the council has only spoken out against using a useflag for installing such files. Afaik they haven't spoken out against a systemd-units package. Please refer me to their decision if I'm wrong. I was referring to that. We never mentioned a possible systemd-units package in any council meeting I believe. I hardly believe that the systemd team would accept such choice. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin -- Fabio Erculiani
[gentoo-dev] Re: Making systemd more accessible to normal users
Tracker bug: https://bugs.gentoo.org/show_bug.cgi?id=468898 -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
On Sat, May 4, 2013 at 12:42 PM, Luca Barbato lu_z...@gentoo.org wrote: On 05/01/2013 12:04 PM, Fabio Erculiani wrote: PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. Amen With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Alternatively, we should migrate to dracut. [unrelated] Do you have more insights about this part? mdev MUST work, lots of thin recovery options are based on busybox. Scenario: - you have an initramfs with mdev, your pivot_chroot system runs udev. - you have a LVM volume group, containing the lvm volume for / and /home, and perhaps you also have swap on another volume. - you boot using the current genkernel initramfs, which uses mdev and comes with lvm support The initramfs code activates your lvm volumes, lvm itself may or not may be compiled with udev support. In the former case, nothing gets written onto /run/udev (and devtmpfs), in the latter case, lvm writes metadata that are useful to lvm itself to udev. mdev is not udev, doesn't deal with udev rules so the metadata is either pristine or completely unavailable. busybox switches root and the boot starts: you obviously have lvm compiled with udev there, since you're using udev (or systemd-udevd, or gudev). The lvm there is either unable to find valid metadata so it doesn't automatically activate the volumes (note: /home does not get activated by the initramfs code) or, until some time ago but now defaulted to off, lvm itself creates the device nodes (which should have been created by udev + udev rules if lvm is compiled with udev support). If it's not enough, our current genkernel initramfs code (I fixed this as well, it's in the systemd-love overlay) doesn't mount --move /run to /newroot before switching root, so /run/udev is not ported over, which means that even if mdev would have been able to do do all the udev magic, things wouldn't work anyway. Long story short, we should: 1) give up with cross compiler support in genkernel, which has been anyway in a broken state for ages. Nobody is using it anyway. 2) make possible to optionally use udev in the initramfs (compiling just for it is a pita and the trend here [dracut and others do this] is to copy udevd from the system) 3) default to udev? - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. Sounds sensible. Also, I forgot that I wrote a NetworkManager patch that makes it able to detect logind/consolekit at runtime. It works and is in the systemd-love overlay (it's a git format-patch patch). - openrc-settingsd needs to support eselect-settingsd, which makes possible to switch the settingsd implementation at runtime, between openrc and systemd. This also removes the silly conflict between openrc-settingsd and systemd friends. Would make sense merge init and settingsd in a single eselect or at least make so switching init would warn if the settingsd doesn't match? They are really two separate things, even though I agree that it should be made even easier. I don't think it's hard though. - genkernel should at least support plymouth (work in progress my side) Looking forward to it. I should have something ready soon. - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). Hopefully we might have a gsoc student volunteering to make a runscript/lsb-script/systemd-unit compiler and a small abstraction so we write a single init.d script and generate what's needed. Probably we might even support pure-runit that way with minimal effort. It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). See above. The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate
Re: [gentoo-dev] Making systemd more accessible to normal users
On Sat, May 4, 2013 at 3:05 PM, Fabio Erculiani lx...@gentoo.org wrote: Scenario: - you have an initramfs with mdev, your pivot_chroot system runs udev. - you have a LVM volume group, containing the lvm volume for / and /home, and perhaps you also have swap on another volume. - you boot using the current genkernel initramfs, which uses mdev and comes with lvm support The initramfs code activates your lvm volumes, lvm itself may or not may be compiled with udev support. In the former case, nothing gets written onto /run/udev (and devtmpfs), in the latter case, lvm writes metadata that are useful to lvm itself to udev. mdev is not udev, doesn't deal with udev rules so the metadata is either pristine or completely unavailable. busybox switches root and the boot starts: you obviously have lvm compiled with udev there, since you're using udev (or systemd-udevd, or gudev). The lvm there is either unable to find valid metadata so it doesn't automatically activate the volumes (note: /home does not get activated by the initramfs code) or, until some time ago but now defaulted to off, lvm itself creates the device nodes (which should have been created by udev + udev rules if lvm is compiled with udev support). If it's not enough, our current genkernel initramfs code (I fixed this as well, it's in the systemd-love overlay) doesn't mount --move /run to /newroot before switching root, so /run/udev is not ported over, which means that even if mdev would have been able to do do all the udev magic, things wouldn't work anyway. Long story short, we should: 1) give up with cross compiler support in genkernel, which has been anyway in a broken state for ages. Nobody is using it anyway. 2) make possible to optionally use udev in the initramfs (compiling just for it is a pita and the trend here [dracut and others do this] is to copy udevd from the system) 3) default to udev? I just forgot the tricky part. If future lvm versions are going to use udev more extensively (for eg: storing more critical metadata in it), the net result will be that mdev won't work anymore. This is why I wrote that lvm is working by miracle for now. mdev is not future proof wrt lvm support. -- Fabio Erculiani -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert flop...@gentoo.org wrote: If you manually write your own configuration for GRUB2, it is no more convoluted than for GRUB Legacy. If you use grub-mkconfig to generate a configuration file, you can append the init option by setting GRUB_CMDLINE_LINUX=init=/usr/lib/systemd/systemd in /etc/default/grub. Not all the Gentoo users are as skilled as you (a developer). Having a programmatic, bootloader agnostic way to swap /sbin/init is useful for the reasons I explained. Yet I haven't read any solid reason not to do that. Either way, it's pretty simple. If it's that simple, why on earth do we have all the eselect modules we have!? Extra modules: audicle Manage /usr/bin/audicle audio engine bashcomp Manage contributed bash-completion scripts binutils Manage installed versions of sys-devel/binutils blas Manage installed BLAS implementations bzimage Switch bzImage default kernel by updating /boot/bzImage symlink cblas Manage installed CBLAS implementations cdparanoiaManage /usr/bin/cdparanoia implementation chuck Manage /usr/bin/chuck audio engine ctags Manage /usr/bin/ctags implementations ecj Manage ECJ targets editorManage the EDITOR environment variable emacs Manage /usr/bin/emacs version env Manage environment variables set in /etc/env.d/ esd Select esound daemon or wrapper etags Manage /usr/bin/etags implementations fontconfigManage fontconfig /etc/fonts/conf.d/ symlinks gnat Manage the installed gnat compilers gnome-shell-extensionsManage default settings for systemwide GNOME Shell extensions infinalityManage the /etc/fonts/infinality/conf.d symlink java-nsplugin Manage the Java plugin for Netscape-like Browsers java-vm Manage the Java system and user VM kernelManage the /usr/src/linux symlink lapackManage installed LAPACK implementations lcdfilter Manage the /etc/env.d/99lcdfilter symlink lightdm Switch between LightDM greeters localeManage the LANG environment variable maven Manage Maven targets mesa Manage the OpenGL driver architecture used by media-libs/mesa miniaudicle Manage /usr/bin/miniAudicle audio engine modules Query eselect modules mpg123Manage /usr/bin/mpg123 implementation mpost Manage /usr/bin/mpost implementations news Read Gentoo (GLEP 42) news items notify-send Manage /usr/bin/notify-send implementation nxserver Manages the configuration of NX servers oodictManage the configuration of dictionaries for OpenOffice.Org. openclManage the OpenCL implementation used by your system openglManage the OpenGL implementation used by your system package-manager Manage the PACKAGE_MANAGER environment variable pager Manage the PAGER environment variable pdftexManage /usr/bin/pdftex implementations php Manage php installations pinentry Manage /usr/bin/pinentry implementation postgresqlManage active PostgreSQL client applications and libraries profile Manage the make.profile symlink pythonManage Python symlinks qtgraphicssystem Manage the system-wide active Qt Graphics System rails Manage Ruby on Rails versions rcManage /etc/init.d scripts in runlevels ruby Manage Ruby symlinks settingsd Switch between settingsd implementations shManage /bin/sh (POSIX shell) implementations sndpeek Manage /usr/bin/sndpeek audio engine sysvinit Switch between sysvinit implementations timidity Select default system patchset for TiMidity++ unisonManage /usr/bin/unison versions vdr-pluginManage VDR plugins viManage /usr/bin/vi implementations visualManage the VISUAL environment variable wxwidgets Manage the system default wxWidgets profile. xvmc Manage the XvMC implementation used by your system Why aren't we telling people to just edit config files!? -- Fabio Erculiani
[gentoo-dev] Making systemd more accessible to normal users
PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Alternatively, we should migrate to dracut. - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. - openrc-settingsd needs to support eselect-settingsd, which makes possible to switch the settingsd implementation at runtime, between openrc and systemd. This also removes the silly conflict between openrc-settingsd and systemd friends. - genkernel should at least support plymouth (work in progress my side) - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). All this would come with no cost for the current openrc state (actually, my initramfs speed improvements patches in genkernel.git also benefit openrc). If Gentoo is about choice, we should give our users the right to choose between the init system they like the most. It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) - we give the users the right to choose without driving them nuts with weird emerge-fu. - we make possible to support new init systems in future, and even specific init wrappers (bootchart anyone?) - we prepare the path towards a painless migration from consolekit (deprecated for long time now) to logind (we probably need to fork it off the systemd pkg -- upstream projects are _dropping_ consolekit support right now!) - we put back some fun into Gentoo If you want to see a working implementation of my systemd-love efforts, just go download [1] and see things working yourself. [1] http://www.sabayon.org/release/press-release-sabayon-1304 [2] https://github.com/Sabayon/systemd-love [3] For instance: https://bugs.gentoo.org/show_bug.cgi?id=465236 [4] useless crap: https://bugs.gentoo.org/show_bug.cgi?id=399615 Cheers, -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 1, 2013 at 12:50 PM, Pacho Ramos pa...@gentoo.org wrote: El mié, 01-05-2013 a las 12:04 +0200, Fabio Erculiani escribió: [...] - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). [...] Can't them be stolen from other distros running systemd? Sure, Arch and Fedora repositories are a good source. [...] The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. I am unable to find exact advantage of changing init system without rebooting :/, what is the advantage of booting with an init.d and shutting down with a different one? No, you don't boot with A and shutdown with B. B is loaded by the kernel at the next boot. Switching init system is the only way to roll out a migration path, among other things I already wrote about on the eselect-sysvinit bug. The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) Are udev and systemd-udev-part really equivalent? I mean, since they are maintained by different people downstream, I am not sure if there would be differences in how udev from udev ebuild and udev from systemd ebuild will behave. This needs investigation. Best regards and thanks for your work! -- Fabio Erculiani
Re: [gentoo-dev] Re: Making systemd more accessible to normal users
On Wed, May 1, 2013 at 2:54 PM, Steven J. Long sl...@rathaus.eclipse.co.uk wrote: On Wed, May 01, 2013 at 12:04:00PM +0200, Fabio Erculiani wrote: PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. That's great: well done :-) Can I just check: what about people not using consolekit nor logind? This has nothing to do with it. If you don't want consolekit nor logind just USE=-consolekit -systemd. It looks like you haven't clear what I'm writing about, though. It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. I don't think you help yourself by making that kind of remark: when I read those bugs I see some valid concerns being raised, which you just ignore. For instance, wrt nonsensical blockers I too would like to know some examples, as was queried in comment 27 [3]. In fact it was the first thing that came to mind when reading your post, as I thought where possible things were just installed for systemd (such as unit files) even when the user is not using it. Have you ever tried to fully migrate to systemd from openrc? Clearly not. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so Again, what about people not using consolekit, nor logind, with no intention of ever installing systemd? I've got nothing against this so long as it is guaranteed not to break my pam setup. As-is I feel *very* wary of a change that unconditionally requires a 'pam_systemd.so'. Please note I am not hostile to your aims: I am merely seeking reassurance. Do you know how pam works? And did you understand the meaning of my words? Do you know what optional means in this context? - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Why is that such a miracle? openrc has worked with lvm since the beginning afair, and is both clean, portable C, and modular. Do you know how LVM and udev and systemd interact wrt volumes activation? Alternatively, we should migrate to dracut. - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. Sounds reasonable; since I don't use it, that can't affect me in any case. My goal wrt openrc is to keep the current level of support and just make systemd users' life easier. - openrc-settingsd needs to support eselect-settingsd, which makes possible to switch the settingsd implementation at runtime, between openrc and systemd. This also removes the silly conflict between openrc-settingsd and systemd friends. - genkernel should at least support plymouth (work in progress my side) - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). All this would come with no cost for the current openrc state (actually, my initramfs speed improvements patches in genkernel.git also benefit openrc). If Gentoo is about choice, we should give our users the right to choose between the init system they like the most. I must be missing something as I thought they already had that choice. Please, write about something you actually manage to _know_. And also, please do read my post title. This is not a flamewar topic, I want to discuss about improving the systemd experience. From reading the bug, the only pro of your approach is that the user does not have to edit the kernel command-line to try out a new init. Initially, you tried to sell this as lowering the bar which is actually a con afaic: if someone is trying to run Gentoo and is incapable of dealing with the kernel command-line, it's likely they won't be able to install it; they certainly won't be able to maintain it, ime. Later, we get the some EFI bootloaders don't allow it. Could you elaborate on how a system we install grub to, won't allow us to change anything? I am not doubting you: I just think we need more explanation of the exact context where we can install Gentoo, but not a bootloader. Being Gentoo does not absolutely mean that we have to craft watches and play VHS with the tongue every time we want to do something. Making things easy is an orthogonal concept! It looks like there is some consensus on the effort of making systemd more accessible, Sure there is: there's also
Re: [gentoo-dev] Making systemd more accessible to normal users
There is no tracker yet. But it may be very well materialize at some point. -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 1, 2013 at 9:52 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 5/1/13 3:04 AM, Fabio Erculiani wrote: As far as I read the bug, Mike (vapier) is doing the right thing. Distros doing lots of custom changes can only add more chaos to the picture. We are a distribution, we have our own goals, thus we change the code to better integrate with our ecosystem. That's part of the game. If we don't want to do that, we shouldn't be running a distro in the first place. Have you reached out to relevant upstreams? If they refuse to make changes, that's a different story. So far I think it's reasonable to go to upstreams first. For just a symlink swap and some file moves? (re: sysvinit) We don't need to bless upstream first for such small changes. Paweł -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 2, 2013 at 5:26 AM, Kent Fredric kentfred...@gmail.com wrote: [snip] Against, the symlink may introduce parts that are breakable, like if user messes up and places the destination of the symlink on a different partition ( shouldn't be a problem, but might be ), or if you're doing an initird that has init baked into it, you'd have to regenerate that initrd after changing the symlink ( I think, maybe not, its probably not even a problem, its just something I'd have to check ) eselect-sysvinit handles symlink swapping among files in /sbin/init.d. So you cannot run into partitioning issues directly. And also, if for whatever reason systemd becomes unbootable it might be slightly hard to boot with the right init if you can't change kernel parameters during boot time. The same happens if you change the boot arguments and reboot. This is not something eselect-sysvinit is supposed to solve. But anyway, eselect-sysvinit is a marginal thing and can be supported by just providing a more experimental, perhaps masked, sysvinit ebuild. I am more concerned about the rest of the story. But noted, those last 2 against reasons are edge cases, where the arguments for it are majority cases, so collectively I'm still in favour of the eselect + symlinks approach. -- Kent -- Fabio Erculiani
Re: [gentoo-dev] [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?
On Fri, Apr 12, 2013 at 10:41 PM, Tom Wijsman tom...@gentoo.org wrote: Hello everyone Attached you will find the various changes I plan to apply to kernel-2.eclass after a week if there are no objections, feel free to take a look at them. A summary of the changes: - Added a warning after the variables that modifying other variables in the eclass is not supported, there is a chance that we will not fix resulting bugs. Fixes bug #421721. Why? Just to annoy people who have successfully used kernel-2.eclass until now, and in my case for half a decade (or even more)? If you need help with maintaining the current eclass functionality, I'd be more than happy. I don't really want to fork it myself :-). [..] - Kernel sources and (gen)patches now use xz instead of bz2. Fixes bug #421721. As I said in the bug, next time you plan a migration like that, it would be nice to send an heads up on the ML beforehand. Like you did in this case, but actually, _beforehand_ and not ~one month later. [...] Have a nice day. :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -- Fabio Erculiani
Re: [gentoo-dev] [fyi] lddtree magic
It looks like you're not using a standard style guide for Python but rather this one [1]. I suggest you to use something closer to PEP8. [1] https://code.google.com/p/google-styleguide/ -- Fabio Erculiani
Re: [gentoo-dev] [fyi] lddtree magic
On Wed, Apr 10, 2013 at 5:33 PM, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 10 April 2013 06:04:00 Fabio Erculiani wrote: It looks like you're not using a standard style guide for Python but rather this one [1]. I suggest you to use something closer to PEP8. no Good arguments! As usual I'd say. -mike -- Fabio Erculiani
Re: [gentoo-dev] [fyi] lddtree magic
On Wed, Apr 10, 2013 at 6:32 PM, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 10 April 2013 12:42:14 Fabio Erculiani wrote: On Wed, Apr 10, 2013 at 5:33 PM, Mike Frysinger wrote: On Wednesday 10 April 2013 06:04:00 Fabio Erculiani wrote: It looks like you're not using a standard style guide for Python but rather this one [1]. I suggest you to use something closer to PEP8. no Good arguments! As usual I'd say. sorry, but i didn't think stating the obvious was necessary. i authored the entire tool, and the one maintaining the code, so yes, i get the liberty to use whatever coding style pleases me. you provide no reasoning whatsoever as to why PEP8 is better. i doubt the style choice is going make any difference whatsoever to contributions for people including yourself. I guess that you're new to Python then. Anyway, mine was just an advice, yours was just the same old rude answer. don't like it ? fork it and write your own. -mike -- Fabio Erculiani
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
I am starting to believe that this is yet another good reason for having official ebuilds building binaries off gentoo-sources through genkernel. Pretty much the same I do in Sabayon since 2007. -- Fabio Erculiani
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Tue, Feb 12, 2013 at 7:47 PM, Pacho Ramos pa...@gentoo.org wrote: El mar, 12-02-2013 a las 19:43 +, Fabio Erculiani escribió: I am starting to believe that this is yet another good reason for having official ebuilds building binaries off gentoo-sources through genkernel. Pretty much the same I do in Sabayon since 2007. I think shouldn't have any problems on providing them also as an alternative, the problem is who would maintain that builds (as I guess Sabayon is using different sources than gentoo and, then, probably not all chosen options for Sabayon will work on Gentoo :/) If the goal is providing a general purpose kernel that's based on genpatches (plus BFQ and aufs3) and could be used in official live images, the current sabayon kernels could work just fine for Gentoo. They are coming directly from Linus' (or gregkh for stable releases) git repo. Upstreaming sabayon-kernel.eclass and kernel binary ebuilds is something I'd be interested in, as long as other devs here are willing to help me out as well. But I don't want to go off-topic too much. -- Fabio Erculiani
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, Feb 10, 2013 at 4:49 PM, Dirkjan Ochtman d...@gentoo.org wrote: On Sun, Feb 10, 2013 at 4:05 PM, Pacho Ramos pa...@gentoo.org wrote: I agree as I have also needed to google and search in forums to get proper firmware installed in the past in some machines :/ +1 from me; I've had a few machines break on kernel upgrades because I didn't have the proper firmware installed (I guess older kernel sources came with the firmware?). This is another problem, namely dependency level problem. I don't see how having kernel sources ebuilds providing /lib/firmware would fix any of the listed issues without causing other side effects. For starters, if kernel sources provide /lib/firmware, how do you deal with file collisions? Cheers, Dirkjan -- Fabio Erculiani
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
Well done! Binary packages is now broken :-/ ## SPM: post-install phase * ERROR: x11-misc/bumblebee-3.0.1-r2 failed (postinst phase): * README.gentoo wasn't created at src_install! * * Call stack: * ebuild.sh, line 93: Called pkg_postinst * environment, line 2080: Called readme.gentoo_pkg_postinst * environment, line 2230: Called readme.gentoo_print_elog * environment, line 2245: Called die * The specific snippet of code: * die README.gentoo wasn't created at src_install!; * * If you need support, post the output of `emerge --info '=x11-misc/bumblebee-3.0.1-r2'`, * the complete build log and the output of `emerge -pqv '=x11-misc/bumblebee-3.0.1-r2'`. * The complete build log is located at '/var/tmp/entropy/packages/amd64/5/x11-misc_bumblebee-3.0.1-r2_0.tbz2/portage/x11-misc/bumblebee-3.0.1-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/entropy/packages/amd64/5/x11-misc_bumblebee-3.0.1-r2_0.tbz2/portage/x11-misc/bumblebee-3.0.1-r2/temp/environment'. * Working directory: '/var/tmp/entropy/packages/amd64/5/x11-misc_bumblebee-3.0.1-r2_0.tbz2/portage/x11-misc/bumblebee-3.0.1-r2' * S: '/var/tmp/entropy/packages/amd64/5/x11-misc_bumblebee-3.0.1-r2_0.tbz2/portage/x11-misc/bumblebee-3.0.1-r2/work/bumblebee-3.0.1' -- Fabio Erculiani
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
No FILESDIR nor T in pkg_* phases please! -- Fabio Erculiani
Re: [gentoo-dev] splashutils needs a maintainer
On Mon, Jan 28, 2013 at 7:26 PM, Pacho Ramos pa...@gentoo.org wrote: El lun, 28-01-2013 a las 00:25 +0100, Alex Legler escribió: Then, looks like no alternative is in good shape on Gentoo. What is Sabayon using? They look to have plymouth ebuilds in their overlay (but not in for-gentoo one, then, it probably has some incompatibility Gentoo :/) Officially, we have always used fbsplash + splashutils. I have no experience with dracut/plymouth though. -- Fabio Erculiani
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
I am starting to think that the real problem is that Gentoo does not have ebuilds for building kernels (binary kernels). At that point, it would be easy to add USE flags and virtual packages to solve the config check problem at the dependencies level once and for all. -- Fabio Erculiani
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
What I always wondered is why we have ebuilds for every kind of binary except for kernels, yet we build official kernels with official configs for our livecds. -- Fabio Erculiani
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Thu, Jan 24, 2013 at 1:10 AM, Robin H. Johnson robb...@gentoo.org wrote: On Wed, Jan 23, 2013 at 12:32:40PM +, Fabio Erculiani wrote: I hope this is going to be binary package manager friendly. In Sabayon for instance, kernel sources are not even installed and at the same time, /proc/config.gz may not even be available. There were some corner cases in where pkg_setup failed because this kernel config check stuff was trying to be smarter than the user. That was before we made it possible to have CONFIG_CHECK=~FOO without /proc/config.gz, for the bugs you yourself submitted, and I fixed years ago. I would expect that ALL Sabayon users would have CONFIG_CHECK_FATAL=0, because they run your kernel (if you have your kernel in a package, maybe even distribute a file that triggers it, so anybody else with their own kernel still has the default CONFIG_CHECK_FATAL=1). But we cannot assume that the environment in where packages are built is the same as the environment in where packages are installed and run. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 -- Fabio Erculiani
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
I hope this is going to be binary package manager friendly. In Sabayon for instance, kernel sources are not even installed and at the same time, /proc/config.gz may not even be available. There were some corner cases in where pkg_setup failed because this kernel config check stuff was trying to be smarter than the user. -- Fabio Erculiani
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
I think that the problem is that it is trying to be smart when it's not really possible (unless you want to cover all the corner cases, which is a pain). -- Fabio Erculiani
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
In my humble opinion, the real question is: why systemd got merged into udev? I would love to hear a clear technical reason for that. -- Fabio Erculiani
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
It depends on who is actually laughing I'd say. just my 0.01c. -- Fabio Erculiani
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Wed, Sep 5, 2012 at 2:06 AM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31-08-2012 20:46, Ciaran McCreesh wrote: snip Also, we're getting rather a lot of *DEPEND variables here... If we're making people make major changes to their deps, which for HDEPEND we definitely would be, then the it's expensive since people would have to redo their deps argument against a combined DEPENDENCIES variable goes out of the window, so we should rethink that too. I have to agree with Ciaran, instead of multiplying DEPEND variables, it's probably time we move to a single DEPENDENCIES variable. So, let's say that I only want to apply a filter function against the buildtime dependencies, in that case I'd need to parse *all* the dependencies anyway? The complexity would become: O((b + r + p) * P) b = amount of buildtime dependencies r = amount of runtime dependencies p = amount of post-dependencies P = amount of packages i need to apply the filter to Instead of just: O(b * P) It sounds like a good dis-optimization. Some pkgs have really long list of *DEPEND. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQRpeVAAoJEC8ZTXQF1qEP/UgQALd+7oqAODQA5bXdyqV+Qix+ mDN66c/6UO4VS2dyhfCEyA3osJzFS4u6mIuR7uFpXoKXGGs+MYdl7EG9C0k48zUu YLCDD56oyk6wACxBk7EHWVql1rvFoFemMUw5YUVq71w3FU9hrpBi/DXKsoAlCRyw 4B2p6t8p6efll3vzbcz7M0LZseiox4GBTFCrtxR5zwgvx3b0gKvgU1Pv+AT3SBQK J3IOxb09GSLCJKo56+iDHGuS5RwBBmdWP9l3+AdbjR2LoQ05f8o8a7/geg1Qqg/Z gVVSo4WDN2kIDJOvCBuXuo95a0KKFt/zUgfwjsqe02fRu2mDiWAju4L6vk2WE316 4yfMULI6HrVUk3ra+O4ZW7eoOuRvPVDpr4vyCVetFe4bx+zmlo/CmzOg/2teMyoc rlMvOigR/4D+wxX7mbw/0fwZ5tVUbZ2pkdEhKetlpDe+xbWY0LhaczKdizwF7BrT d+BeazPGWBP/muY0s3VDu3KV/3TRS0tME8GRsDevA9nCfA2plU0ZmmZnTB69tLc+ /dgdexHhc3IuA5eMObwOfSK6r9Jozlrv09TDvb6kHXm+0kqhV/W/aaS1qT4Bjlxd psMjf9lSJHLcXuhtOz9OW4qmhp4BGCA8Rgeoq25Yw8E2eH0abvDbHR5U7u1hEpnQ j6rJ0fZ27tfbMecd5i8b =Zv/I -END PGP SIGNATURE- -- Fabio Erculiani
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Wed, Sep 5, 2012 at 12:44 PM, Rich Freeman ri...@gentoo.org wrote: On Wed, Sep 5, 2012 at 3:19 AM, Fabio Erculiani lx...@gentoo.org wrote: The complexity would become: O((b + r + p) * P) b = amount of buildtime dependencies r = amount of runtime dependencies p = amount of post-dependencies P = amount of packages i need to apply the filter to Instead of just: O(b * P) Well, actually, in both cases the complexity is O(n), assuming you only need to make a constant number of passes through the deps per package. The whole point of O notation is that it is about how it scales, not how long it takes. An O(n) algorithm can actually be slower than an O(n^n) algorithm even on a large dataset. However, the key is that at some point if the dataset gets large enough the O(n) algorithm will always become faster. I tend to agree with Cirian though - the time for some code to run through the dependencies array and do something isn't going to be very high. If a piece of code has to do it many times there is nothing that says the package manager can't index it. I don't want to diverge (again) from the main topic, but I think that you're just oversimplifying it. If you consider parsing an ebuild something hidden behind a lot of abstraction layers, O(n) vs O(n/2) is a big difference, even if both, normalized, are still O(n). And I would never design an API which assumes that O(n/2) equals to O(n), because you don't know how that is going to be used in upper layers, today, tomorrow and in 5 years. Rich -- Fabio Erculiani
[gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
Hi, this is actually a fork of the HDEPEND thread (sorry for having diverged that much there). As I wrote in the other thread, the problem with PDEPEND is that there are two (or more) semantics: - PDEPENDs used as suggestions but yet being considered in the depgraph and actually installed. Usually suggestion PDEPENDs are just packages providing extra features, not strictly required for the package to work at all. - PDEPENDs used for breaking dependency cycles (no problem with that). That is why I'd like to propose to introduce SDEPEND, with the following, simple, semantics: dependencies listed in SDEPEND are not required at build time nor strictly at runtime and they just enable more features in the installed application. There can be use? literals and by default, PMS should not pull them in in the dependencies calculation if not specifically asked (through argument or configuration file or else -- like it happens with binpkgs and --with-bdeps). A bunch of advantages over GLEP 62: - Simplicity (really, as in KISS). SDEPENDs are easier to understand and deal with, both at PMS (code) and user levels. They are also straightforward to use in ebuilds (dev) and through emerge (user). [1] - The USE flags meaning doesn't really get stretched introducing obscure, unknown and dangerous possible side effects when deployed in the real(tm) world. I understand that there is some level of risk with SDEPENDs as well, but we've seen them already in Exherbo and they seem to work fine there (I've been told this). - Doesn't preclude the implementation of GLEP 62 anyway. SDEPENDs are just suggested dependencies after all! - No need to introduce funky cache invalidation logic for PMS aggressively using caching at several layers of their stack and that guarantee a consistent depgraph for the installed pkgs repository as well [2]. - Fixes the dissociative identity disorder of PDEPEND ;-). Disadvantages: - If SDEPEND contains USE flags, these are written in stone and cannot be changed without a rebuild. This is generally fine for source packages, a bit less for binpkgs, but not really a big deal IMO. - Not as elastic as GLEP 62 USE flags, but neither *DEPENDs are - mgorny will hate me (eheheheh) Discuss. [1] It took me more than 5 minutes to understand how GLEP 62 works in practice and this is not really good to me, for a simple feature like this. [2] From GLEP 62 page: and it is not strictly required that a package manager must ensure that the dependency graph is still consistent afterwards. -- Fabio Erculiani
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, Sep 2, 2012 at 4:57 PM, hasufell hasuf...@gentoo.org wrote: Why not introduce a global useflag such as suggested-deps which complies with GLEP 62 meaning it will be in IUSE_RUNTIME. How do you manage to fix the PDEPEND identity disorder problem then? Teaching devs to move to GLEP 62 is much harder than just telling them to move dep strings to more appropriate locations. Moreover, your solution just makes the USE flags abuse situation worse: there are packages that use USE flags just to include extra, optional packages in the dependencies... See USE=bluetooth in net-misc/networkmanager for example (this is what I mean with USE flags abuse, actually). I'm not saying that SDEPEND is the best one-size-fits-all solution but you may agree that's the simplest and most effective one. -- Fabio Erculiani
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, Sep 2, 2012 at 5:23 PM, Michał Górny mgo...@gentoo.org wrote: On Sun, 2 Sep 2012 17:09:22 +0200 Fabio Erculiani lx...@gentoo.org wrote: On Sun, Sep 2, 2012 at 4:57 PM, hasufell hasuf...@gentoo.org wrote: Why not introduce a global useflag such as suggested-deps which complies with GLEP 62 meaning it will be in IUSE_RUNTIME. How do you manage to fix the PDEPEND identity disorder problem then? Teaching devs to move to GLEP 62 is much harder than just telling them to move dep strings to more appropriate locations. Much harder? So, devs today don't know how USE flags work? Or do you implying that devs should know bare technical details of package manager implementation? Or is it just an-ass argument to support an ass-thesis? For instance, the amount of devs still improperly using pkg_setup for build-time stuff, after years that they've been told to not do that, is a good example of how, while we're great, we tend to be resilient to change. This goes beyond software engineering, this is about psychology. The more one thing is simple, the faster is recognized and properly used by people. Not to mention that I am one of the PMS writers here (Entropy cough), and I know how much harder implementing runtime-switchable USE flags is, compared to a simple SDEPEND solution. Moreover, your solution just makes the USE flags abuse situation worse: there are packages that use USE flags just to include extra, optional packages in the dependencies... See USE=bluetooth in net-misc/networkmanager for example (this is what I mean with USE flags abuse, actually). No, it fixes it. It enables those packages to use the same solution, fixing its downsides. It looks like it just tries to workaround the issue, not fix it to its roots (PDEPEND is ill!). I'm not saying that SDEPEND is the best one-size-fits-all solution but you may agree that's the simplest and most effective one. pkg_postinst() is simpler. USE flags are simple and very effective, yet incorrect. Could you tell me how would you plan to implement so API to read suggested dependencies from pkg_postinst() output? I understand that being API-friendly is not really the best feature of Portage and ebuilds in general (one reason why our PackageKit backend is a bit sucky) but this is not a good reason to keep doing things like they've been always done. (Information printed at pkg_postinst() is another interesting problem, wrt API consumers, and this includes PackageKit, but I don't want to drift away too much from the topic). An effective SDEPEND implementation is definitely nowhere close to simple. Nor is presenting those dependencies to users. As I mentioned above, I know what it simple and what not, from a Software Engineering point of view. And SDEPENDs are much simpler than GLEP 62, and GLEP 62 does not fix the PDEPEND issue because individuals will keep using it because at the end of the day, it is order of magniture simpler than obscure new variables and USE flags. As a rule of thumb, simple always shines over the complex and convoluted in the long run. -- Best regards, Michał Górny Peace love! -- Fabio Erculiani
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: and we have worked out all the difficulties. Please elaborate. What difficulties? What did you implement other than plain SDEPEND? With what features? Lots of detail missing. Having said that, if we're going with suggested dependencies for EAPI 5 (which I strongly suspect won't happen, since we seem to be wanting EAPI 5 now rather than in several years time...) then there's a lot more to getting it right than is mentioned in the original post, and it needs to be written up properly. Well, this depends on the quality of the PMS architecture, I am not familiar with Paludis tho. I don't remember to have listed anything about what needs to be done at the implementation level actually, nor I really wanted to. I always use the 5 minutes rule of thumb strategy to understand the complexity of proposals: if it takes me more than 5 minutes to understand it, then users (!= devs) will have to go through the same or more wtf-period. And the probability of them giving up / getting sick / ignoring it is linear with the wtf-period. -- Ciaran McCreesh -- Fabio Erculiani
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, Sep 2, 2012 at 9:04 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 2 Sep 2012 20:46:19 +0200 Fabio Erculiani lx...@gentoo.org wrote: On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: and we have worked out all the difficulties. Please elaborate. What difficulties? What did you implement other than plain SDEPEND? With what features? Lots of detail missing. The big issues you're ignoring: And you call them big issues? Ah, the you're ignoring part looks a bit arrogant, are you short with arguments ;-) ? -- Ciaran McCreesh -- Fabio Erculiani
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
s/with/on/ -- Fabio Erculiani
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
I like this as well. However, since we're going to introduce a *DEPEND split, how about splitting PDEPEND as well? As far as I've seen, PDEPEND has two (or more?) different meanings: - advisory (for instance, informing users about plugins) - cycle-breaking to help the dependency solver Would it be possible to add support for ODEPEND (as in optional dependencies -- I don't really care about the variable name) as well? This would be quite beneficial under certain circumstances. One of these is when ebuilds are shipped with PDEPENDs which are not required at runtime nor for cycle-breaking... Another scenario in where ODEPEND would be nice to have is with systemd init files pulled in by USE=systemd (and generally use? ( sys-apps/systemd ) in *DEPEND). Providing full systemd support for all the packages without forcing users to have it installed, given that openrc is the de-facto standard init system in Gentoo (and we don't have any openrc? ( sys-apps/openrc )), would be a nice features for binpkg repos. Users could then choose to enable or disable ODEPEND during dependencies calculation via make.conf or argv. I don't want to diverge too much from the HDEPEND discussion, but I think that if we're going to split *DEPEND, it might be a good opportunity to do it right _once_ and _for all_. -- Fabio Erculiani
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Fri, Aug 31, 2012 at 11:58 PM, Zac Medico zmed...@gentoo.org wrote: For optional dependencies, I'm pretty happy with the runtime-switchable USE flags proposal: https://gist.github.com/2945569 runtime-switchable USE flags for optional dependencies o.O? It sounds like using a spoon to eat spaghetti to me. I think SDEPEND is a much simpler approach to the issue, why introducing a new kind of USE flags to address what really belongs to *DEPEND? -- Thanks, Zac -- Fabio Erculiani
Re: [gentoo-dev] ebuild laziness and binpkg overhead
Anything build-time related should not be placed into pkg_setup (I am pointing the finger to those build-related die() that are breaking binpkgs support). There's src_prepare() and src_configure() nowadays. -- Fabio Erculiani
Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)
We may want to see if it's possible to make each ( pull push ) transaction mutually exclusive one another (forcing repoman as git wrapper and playing with git hooks? I don't know). At first sight, it looks like a simple starvation problem, and there are several anti-starvation protocols out there, the problem is if these protocols can be applied to the git workflow. Just brain-dumping... -- Fabio Erculiani
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Please kill CVS with fire! I've been waiting for this since 2009. -- Fabio Erculiani
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 9:37 PM, Arun Raghavan ford_pref...@gentoo.org wrote: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. The difference is that while Git is much faster, comes with a very low WTF/secs rate and really forces you to do things the right way, other L*e software is not and I agree with you on this. my 0.02c ;-) -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME) -- Fabio Erculiani
Re: [gentoo-dev] Remove eclass/ChangeLog
On Tue, May 22, 2012 at 11:01 AM, Michael Weber x...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/20/2012 03:55 PM, Andreas K. Huettel wrote: Am Sonntag 20 Mai 2012, 15:30:45 schrieb Nirbheek Chauhan: On Sun, May 20, 2012 at 6:55 PM, Michał Górny mgo...@gentoo.org wrote: I will repeat once again: autogenerate them. +1 for this, seriously. +1 and consider profiles/**/package.mask, too. and how about getting rid of echangelog and just have it autogenerated as well? Or even better, how about giving up with cvs once for all? - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+7VfAACgkQknrdDGLu8JAClQD/SVh+bstPurUReBipvCeGPYfE ZIGHcSs8Wt7HH0dy/YcA/iB2TRcd3BlcVy4O6v5wmf52s4UtCNnpYOL+RpD3O/in =uZ6k -END PGP SIGNATURE- -- Fabio Erculiani
Re: [gentoo-dev] Do we need games group and all that game prefixes?
I second that. simplicity = win. -- Fabio Erculiani
Re: [gentoo-dev] Re: RFC: Enable FEATURES=config-protect-if-modified by default?
I implemented this feature in Entropy long time ago (2009 iirc) and enabled it by default as well. We never had a single issue. Users seem quite happy about it. So yeah, go for it! -- Fabio Erculiani
Re: [gentoo-dev] Re: RFC: Enable FEATURES=config-protect-if-modified by default?
On Wed, May 16, 2012 at 11:36 AM, Eray Aslan e...@gentoo.org wrote: On 2012-05-16 12:13 PM, Andreas K. Huettel wrote: make.conf(5) man page: This causes the CONFIG_PROTECT behavior to be skipped for files that have not been modified since they were installed. +1 very good idea Hmm, does that mean that when a default changes in (or some new setting is added to) an app config file, I'll get no prompt and no warning assuming I go with the default settings in the app? That presumes that the new default or the new setting does not break my setup. That is a big assumption. Generally, several PMS (I think apt does it as well) make this assumption: if config file C owned by package P has never been modified, meaning that md5 or whatever is the same, the old C of P was fine, so is the new C. On the other hand, if the old C has been modified, then the above assumption is not valid. This also helps a lot in the scenario where critical configuration files are not updated before reboot, which might result in an unbootable system (ouch!). Even if we go with enabling it by default, please have a news item so that one can turn it off if necessary. Even then, new installs will have to remember to turn it off. -- Eray Aslan e...@gentoo.org -- Fabio Erculiani
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On Thu, May 10, 2012 at 9:55 PM, Markos Chandras hwoar...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I sincerely hope someone has hacked into your account and he is writing on your behalf. This sort of trash talk does not belong to a public Gentoo mailing list. Make a constructive criticism if you really need to rant about software that nobody forces you to use. No, this was really me. Forgive me for the rant, but the problem here is real and no, the alternative would be either giving up with the Linux stack or living with unreliable, overengineered software. I don't see any other viable alternative. Just answer my question, what is going to happen the day udev will require systemd in order to work properly? On a side note, I find it quite odd to be accused of trash talking by Linux Kernel people. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJPrB0WAAoJEPqDWhW0r/LCFGYQAJiKzJ6RUYrkCswRBeWFk9Vn 6kOybbC9nn8LgQuoSjlNXWQ2jm5qqYEWhwzmFJMaeYJ7vpaVNL9nDTslloiXiw46 2dEjBUyXzmx90VIAvAvos3lec2C45vHXUYwjCp8VfwIfL+syPfb0wIXIn+RETAHg 2c4vyPRvv145zCPRkdF/b0GV4ai6JozRTrUOn2dobEs2SaqadqY4cw5uj1P47Msd Jezdz4MaPUPf16q0CoK6yi4U0jkzEqGtJbinHT4ib9PMhYX8WXjJtLloaBiQk01l bKNJWOAMIEpWK6dD2rko5pY4igS9ccbFCLlEDnELQBSHXDGAmarmGRlN6C/qVasY 019n3fSUsLt+kMeH2WgfmmXViyBgPeQxMY0E4HVkV+ztwNp3by8gG3jtuQeX+Kij WaECR/2/DwUTU+kLLkkEa2FZSrg8xwG3Ty5SpCAVQWcJIn3L1tziD58kt1DtpJjs jt0bV1eT2JnxL4v7GopxUI55n4bmqqzRP7SebkK4B7AOlae1fxjukqpNC6s6oTgc CBoWiJ7DkRbcTk+ww+MF+xUCmYrqPFlf8aQ8+j16LogaTCeV09QIhAqUKkcQB8Lx k6gGD6H5elPsYDm1gP/wBe1WEe6zLXDLd6LFiEYKHjyiznGDs1BAEk0oJMbob5I3 HbAYiBP8P7D7FBosO7oj =INQn -END PGP SIGNATURE- -- Fabio Erculiani
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
I foresee a new udev fork then. If udev is going to end up like avahi is, this is *highly* probable. With avahi is ... I actually mean, one single tarball blob depending on the whole world and its solar system and galaxy. Please stop throwing lennartware at people. FailAudio has been enough, thanks. -- Fabio Erculiani
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
I think expressing my own opinion about Lennart-made software is my right, after all. Firstly, it's almost impossible nowadays to avoid including avahi, systemd and pulseaudio into a desktop distro so, there is no real choice. This issue became a sensible matter for those users who for instance, wanted to have a silly mp3 player working without going through the PA nonsense, really missing the old ALSA-oh-it-was-always-working days. If you want to bring complexity but you end up not being able to handle it, then you're not a really good engineer, IMHO. Having said that, I also wonder where's the lovely modularity the various *nix platforms had. If this is the actual direction of Linux Foundation, Redhat and Canonical, I am worried that Linux would end up being an OSX-wannabe. Of course, I am not only bringing my personal opinion here, but the one of the majority of users I've been talking with. I am not against changes, I am actually in favor of them, but only when they really make sense and solve problems, which it doesn't seem the case lately. I didn't want to offend anyone, but just having fun (sigh) of IMHO bad design decisions. -- Fabio Erculiani
[gentoo-dev] unsafe use of gtk-query-immodules
Like it happened with gtk-pixbuf-query-loaders, gtk-query-immodules is
used in an unsafe way as well.
There are several reasons that could make gtk-query-immodules fail at
runtime (SIG*, missing sonames, etc).
Using it this way is really wrong (and you know why ;-) ):
gtk-query-immodules ${ROOT}/.../gtk.immodules
The affected pkgs are:
app-emulation/emul-linux-x86-gtklibs
app-i18n/atokx2
app-i18n/atokx3
app-i18n/fcitx
app-i18n/gtkimprime
app-i18n/ibus
app-i18n/im-canna
app-i18n/im-freewnn
app-i18n/imhangul
app-i18n/im-ja
app-i18n/scim
app-i18n/scim-bridge
app-i18n/uim
app-i18n/x-unikey
x11-libs/gtk+
and should be fixed.
--
Fabio Erculiani
http://lxnay.com
Re: [gentoo-dev] unsafe use of gtk-query-immodules
On Wed, Apr 25, 2012 at 5:53 PM, Mike Frysinger vap...@gentoo.org wrote: isn't this what bugzilla is for ? reporting bugs ? -mike Tracker Bug 413529 already filed. -- Fabio Erculiani
Re: [gentoo-dev] RFC: Application name in metadata.xml
Markos, there are also webapps. -- Fabio Erculiani http://lxnay.com
Re: [gentoo-dev] media-video/nvidia-settings is orphan for a long time
Somebody reworked nvidia-drivers and nvidia-settings ebuilds 2 years ago and left them in (IMHO) quite debatable state. See bug #336088. The ebuild should be cleaned up and either renamed or actually fixed. nvidia-settings doesn't contain the nvidia-settings application, which is kinda funny. -- Fabio Erculiani
[gentoo-dev] RFC: Application name in metadata.xml
I think this is not the first time it's been discussed here, but maybe I'm wrong. Other distros associate a more user-friendly package name (application name) to packages. Say, they bind libreoffice-writer to LibreOffice Writer in package metadata. How about expanding metadata.xml (adding to its .dtd) to also support this? It would be nice to show this info in GUI package managers instead of the actual, and ugly (for the newbies), CP or CPV. It would be just a small addition that would make a big diff. So? -- Fabio Erculiani
Re: [gentoo-dev] RFC: Application name in metadata.xml
On Sat, Feb 11, 2012 at 2:27 PM, Michał Górny mgo...@gentoo.org wrote: On Sat, 11 Feb 2012 14:00:38 +0100 Fabio Erculiani lx...@gentoo.org wrote: I think this is not the first time it's been discussed here, but maybe I'm wrong. Other distros associate a more user-friendly package name (application name) to packages. Say, they bind libreoffice-writer to LibreOffice Writer in package metadata. How about expanding metadata.xml (adding to its .dtd) to also support this? It would be nice to show this info in GUI package managers instead of the actual, and ugly (for the newbies), CP or CPV. It would be just a small addition that would make a big diff. I think we already expand the name in DESCRIPTION whenever it is ambiguous. DESCRIPTION != Application Name Description is way too long, and sometimes, it even overflows 80 chars limit (I recall there was a suggested limit for it, and it is 80 chars -- that's why we have long-description in metadata.xml). Could you please mention some Gentoo examples which would benefit from the proposed change? As I wrote, GUI Package Managers or Web frontends to Portage (package browsers). Example image, taken from Ubuntu SC, showing application names: http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/08/Selection_008.jpeg -- Best regards, Michał Górny Cheers, -- Fabio Erculiani
Re: [gentoo-dev] We need *you* for a USE=selinux dependency
On Mon, Dec 5, 2011 at 4:04 AM, Brian Harring ferri...@gmail.com wrote: [..] While it appears that way, it's not actually true; RDEPEND is what the pkg requires to be able to be usable, not what is required to merge it. [...] Correct, I didn't want to be so picky on the explanation. -- Fabio Erculiani
Re: [gentoo-dev] We need *you* for a USE=selinux dependency
On Sun, Dec 4, 2011 at 9:35 PM, Sven Vermeulen sw...@gentoo.org wrote: [...] The dependency must be on both levels, because the SELinux module must be installed before the package is installed (and in theory, RDEPEND could trigger an installation afterwards): during the installation phase, Portage labels the files on the system (which would get wrong labels if the module isn't installed yet[1]). Also, DEPEND isn't sufficient due to binary package support requirements. Wkr, Sven Vermeulen [1] I am aware that Portage currently installs RDEPEND before the package itself, but that might change in the future and other package managers might exhibit different behavior. I haven't really understood what you mean with RDEPENDs being scheduled after. RDEPEND must be always scheduled before the pkg requiring it, changing this behaviour would have disruptive effects on all the PMS out there (OTOH I think I haven't gotten the point actually?). I guess portage may schedule it in arbitrary order if the RDEPEND dep itself is satisfied already (this would mean that you explicitly pulled it in), and this is the only case I can think of. If you need to schedule a dep install at some point, you should rather use PDEPEND, but if the same is required earlier in the schedule, well, you're flooked. -- Fabio Erculiani http://lxnay.com
Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible
On Sat, Nov 5, 2011 at 11:27 AM, Nirbheek Chauhan nirbh...@gentoo.org wrote:
Is there a way to output the verbose log to build.log, but show the
shortened log to the terminal? The non-verbose build is quite useful
for seeing the actual warnings as they fly by rather than the entire
gcc/libtool command, which is often mostly noise.
And writing to std{out,err} is expensive! ;-)
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
--
Fabio Erculiani
http://lxnay.com
Re: [gentoo-dev] linux-info.eclass: check_extra_config requires a configured kernel
Anything using /proc/config.gz is broken. For the following reasons: 1) could be not available (CONFIG not enabled) 2) doesn't reflect the kernel you're compiling against (chrooted env, multiple kernels on the system, etc) -- Fabio Erculiani
Re: [gentoo-dev] linux-info.eclass: check_extra_config requires a configured kernel
pkg_setup() is shared between binpkgs and srcpkgs, and often it ends
up containing stuff that should be rather placed into
src_{prepare,configure,whatever}.
--
Fabio Erculiani
http://lxnay.com
Re: [gentoo-dev] linux-info.eclass: check_extra_config requires a configured kernel
On Fri, Nov 4, 2011 at 10:18 PM, Robin H. Johnson robb...@gentoo.org wrote: On Fri, Nov 04, 2011 at 04:11:42PM +0100, Fabio Erculiani wrote: On Fri, Nov 4, 2011 at 3:46 PM, Mike Gilbert flop...@gentoo.org wrote: It is good that we warn users about this when they install the package, but I don't think the ebuild should die. I've always found ebuilds dying at kernel config checks really annoying. Checking kernel features at build time (if we die) is broken and should be banned IMO: You're going off on a tangent. The ONLY time that kernel config checks are fatal is when you're building kernel modules, and the module will fail to compile unless there is a .config and suitable options set. And that is bad anyway, because it doesn't work as expected when the package is merged from tbz2, there are no kernel sources installed and multiple kernels are on the same system (and perhaps you are using a package manager that properly supports multiple installed kernel module packages). chromium is using the fatal mode of CONFIG_CHECK wrongly. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -- Fabio Erculiani http://lxnay.com
Re: [gentoo-dev] linux-info.eclass: check_extra_config requires a configured kernel
On Fri, Nov 4, 2011 at 11:12 PM, Robin H. Johnson robb...@gentoo.org wrote: On Fri, Nov 04, 2011 at 11:02:18PM +0100, Fabio Erculiani wrote: The ONLY time that kernel config checks are fatal is when you're building kernel modules, and the module will fail to compile unless there is a .config and suitable options set. And that is bad anyway, because it doesn't work as expected when the package is merged from tbz2, there are no kernel sources installed and multiple kernels are on the same system (and perhaps you are using a package manager that properly supports multiple installed kernel module packages). I said when you're building. When you're merging from binpkg, you're not building... Correct :-) -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -- Fabio Erculiani http://lxnay.com
[gentoo-dev] gdk-pixbuf-query-loaders usage in tree
gdk-pixbuf-query-loaders has a long history of segfaults.
Not to blame anybody here, but still segfaults there can happen quite easily.
A nice example is:
export __GL_NO_DSO_FINALIZER=1
$ gdk-pixbuf-query-loaders
When nvidia.ko is in use.
The __GL_NO_DSO_FINALIZER is a hack that made buggy nvidia-drivers (or
buggy gl threads usage?) work.
The problem with our ebuilds is that everybody did something like this
(in pkg_postinst):
gdk-pixbuf-query-loaders ${ROOT}usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
1) exit status is not even considered
2) output redirection truncates the destination file as soon as the
executable is spawned
This is very bad, because in case of segfaults, loaders.cache is
totalled, resulting in gtk+ apps dying miserably.
Please don't do that, never ever. We don't live in a perfect world.
x11-libs/gdk-pixbuf got fixed already.
Others affected:
app-emulation/emul-linux-x86-gtklibs
gnome-base/librsvg
media-libs/libwmf
others?
--
Fabio Erculiani
http://lxnay.com
[gentoo-dev] [RFC] virtual/polkit-agent virtual pkg
We have actually 3 polkit agent implementations in Portage: gnome-extra/polkit-gnome lxde-base/lxpolkit sys-auth/polkit-kde-agent I guess a virtual is required. Just a simple example, gnome-extra/nm-applet requires a polkit auth agent (not present in RDEPEND atm -- bug!) in order to handle wifi passwords, etc. But the same applet can be used in both GNOME and LXDE, making lxpolkit a better choice over polkit-gnome for the latter. My proposal is to create a virtual pkg listing all the polkit auth agent implementations and make pkgs depend on it. -- Fabio Erculiani
[gentoo-dev] genkernel unionfs
Hi, straight question. Is there anybody out there using genkernel-based kernels+initramfs and unionfs? The support inside genkernel is rotting and it would be nice to have it removed and replaced by aufs2, and by dm-snapshot afterwards (thanks to likewhoa for the advice). Cheers, -- Fabio Erculiani http://lxnay.com
Re: [gentoo-dev] net-zope maintenance
On Sat, Aug 13, 2011 at 12:37 PM, Dirkjan Ochtman d...@gentoo.org wrote: Hi there, media-libs/FusionSound for whatever reason blocks net-zope/zodb probably file collisions. IIRC i've been hit by that long time ago. There should be also a bug about it. Cheers, Dirkjan -- Fabio Erculiani
Re: [gentoo-dev] The fun of being a PDEPEND
On Thu, Aug 11, 2011 at 7:36 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 10 Aug 2011 23:14:22 +0200 Fabio Erculiani lx...@gentoo.org wrote: I've intermittently spent my last two days trying to figure out a weird bug on Entropy dependency resolution algorithm (which is actually just a simple topological sorting out of a digraph) You can't use a naive topological sort to do dependency resolution. RDEPEND-RDEPEND cycles are legal and common. Yes, they're legal and common but they can likely generate build failures. Entropy always tried to strictly follow PMS (bugs apart). Given the same document, about PDEPEND it says something like this: there is no guarantee that a PDEPEND gets installed at a certain, specified point during the schedule, if not specifically listed as RDEPEND by some package. The problem here is that Portage enforces the same rule by trying to schedule the PDEPEND as soon as possible, which leads ebuild writers to think to have gotten the deps order right. In simple words, it doesn't seem that Portage itself follows PMS or PMS is detailed enough. Portage *tries*. There's no guarantee that it will succeed. If you need a particular ordering, you can't use PDEPEND. If something's there only because of a PDEPEND, there are absolutely no guarantees whatsoever as to when it will get resolved; PDEPEND imposes absolutely no reliable conditions upon ordering. Any ebuild assuming otherwise should be fixed. Given your definition of PDEPEND, jdom stuff should get fixed. No matter what Portage/Paludis quirks do. Purely as a quality of implementation issue, scheduling a PDEPEND reasonably soon after (or even before) the package requiring it may be a good idea, simply because users may get confused if when they try to install a bunch of things and one of those things gets installed long before related packages. But you can't rely upon that happening. But since this can lead to failures, the correct behaviour must get defined by PMS. Otherwise everybody will go implementing schedulers as they like most. (Incidentally, one could also argue that package manglers should always try to come up with the most perverse legal ordering possible for any situation. That way bugs will be identified much more quickly. Part of the problem with Portage is that it has so many tricks and so little error checking that broken things quite often appear to work.) Bad design is bad design. And there is no excuse. My feeling is that since Portage is actually able to figure out the correct order by just using tricks like the ASAP, and even though PMS doesn't say anything about that, the issue is considered minor. I would rather see PMS clarify the correct behaviour of schedulers with respect to PDEPEND. -- Ciaran McCreesh -- Fabio Erculiani
Re: [gentoo-dev] The fun of being a PDEPEND
On Thu, Aug 11, 2011 at 8:31 AM, Zac Medico zmed...@gentoo.org wrote: The ASAP behavior seems relatively optimal, which makes it difficult to argue that ebuild maintainers should have to go to the trouble of creating virtuals and updating reverse dependencies. Yes it is and I agree, but the point here is that PMS doesn't say anything about it. It seems like your setting up an ongoing conflict with ebuild maintainers if you don't implement the ASAP behavior. Isn't it worth your trouble to implement the ASAP behavior, just to get them out of your hair? No it's not, but I would have the matter clarified first, and perhaps eventually fixed by updating PMS documentation. OTOH, I think that the gray area should be cleared out by clearly stating what is legal or not in an updated EAPI. Isn't that reasonable? It's already been allowed for years, so a new EAPI would only make sense if your taking away the ASAP behavior, which seems like a step backwards. Given the push-back that you're likely to get from ebuild developers over time, I think you're much better off if you just implement the ASAP behavior. I would rather want to see it becoming mandatory by PMS, also. But beside the ASAP, do you agree that there is still a dependency issue? -- Thanks, Zac -- Fabio Erculiani
Re: [gentoo-dev] The fun of being a PDEPEND
The case which triggered my attention was actually
app-office/libreoffice with USE=java. pkg_setup (through
java-utils-2.eclass java-pkg_switch-vm [1]) expects to find a
functional JDK environment, even though jdom-jaxen is not required as
RDEPEND by anything inside java eclasses and libreoffice ebuild,
because in fact, it's only declared as PDEPEND (in order to have the
circularity sorted out).
Given this real-world example, the ASAP feature makes possible to have
jdom-jaxen pulled in, in time, even if it's not something that is
required to PMS-compliant PMs.
So? A few options:
1. implement the ASAP feature in Entropy and live with broken dependencies
2. live with broken dependencies
3. Fix the broken dependencies
4. Fix the broken dependencies and have PMS defining rules for
scheduling PDEPENDs.
[1] depend-java-query --get-vm ${JAVA_PKG_NV_DEPEND:-${DEPEND}}
expects to find a sane JDK environment.
--
Fabio Erculiani
http://lxnay.com
Re: [gentoo-dev] The fun of being a PDEPEND
On Thu, Aug 11, 2011 at 10:24 AM, Ulrich Mueller u...@gentoo.org wrote: On Thu, 11 Aug 2011, Fabio Erculiani wrote: Generally, you cannot rely on any dependency (outside of the system set) being present in pkg_setup: http://dev.gentoo.org/~ulm/pms/head/pms.html#x1-720008 Ulrich You may want to comment on bug #378741 -- Fabio Erculiani http://lxnay.com
[gentoo-dev] The fun of being a PDEPEND
I've intermittently spent my last two days trying to figure out a weird bug on Entropy dependency resolution algorithm (which is actually just a simple topological sorting out of a digraph) due to an user reporting me a problem occurring during app-office/libreoffice pkg_setup phase. The problem is actually two problems, but anyways, to make it short (since it's not the topic here), bug #206024 is also a reason why I've been hit by all this mess. Entropy always tried to strictly follow PMS (bugs apart). Given the same document, about PDEPEND it says something like this: there is no guarantee that a PDEPEND gets installed at a certain, specified point during the schedule, if not specifically listed as RDEPEND by some package. The problem here is that Portage enforces the same rule by trying to schedule the PDEPEND as soon as possible, which leads ebuild writers to think to have gotten the deps order right. In simple words, it doesn't seem that Portage itself follows PMS or PMS is detailed enough. Try to ask your fellow developers this question: what is a PDEPEND? And you will get several different answers. The fact is, at least among us, it's still unclear what a PDEPEND is and how it behaves, also given the fact that other PMs strictly following the specifications end up generating wrong merge schedules. There are two main interpretations of what a PDEPEND is: 1. a way to fix circular dependecies (actually, it's wrong because there is no guarantee on the scheduling) 2. a way to have some handy packages being pulled in at some point (audacious plugins?) Who is this poor little PDEPEND? I think it's time to take action and fix the gray area around PDEPENDs, or at least clarify the fact to us developers. -- Fabio Erculiani
