Re: [gentoo-user] technical review of systemd
On Sat, Feb 22, 2014 at 6:16 PM, thegee...@thegeezer.net wrote: OK so because of how much time has been spent arguing about systemd with little technical content, i've spent some time on the freedesktop site reading Lennart's blog and also going through the source to find answers to my questions about the socket activator. i've also been going through the man pages of netctl too and am horrified at the lack of what i would call enterprise features. networkd (netctl is just the command-line front-end) is not intended for enterprise; it's for little servers where you only need static IPs or simple bridges. For desktops/laptops, you are supposed to keep using NetworkManager/connman/whatever you used before. For complex network setups, you need *a* network manager (not necessarily NetworkManager). this is by no means a definitive list. I just thought that i would share what i had found. please correct me if i am wrong in any of these. please add to the list for technical items only. I find it a very impartial and objective review; thank you very much! thanks! pros 1.very modular, everything can be disabled though not removed 2.socket based activator allows restart of services with no service interruption 3.if activator.c is used for this, then the code is actually pretty clean using supplied sd-daemon.c simplifies sockets for daemons and also adds extra watchdog features 4.can disable socket based activation according to Canek, but i can't find how. You use a .service unit file instead of a .socket unit file. That's it. thanks good to know that is all you need For OpenSSH, for example, you can enable sshd.service[1], and then the SSH daemon works as it does in OpenRC. If you instead enable sshd.socket[2], then the daemon will start on demand. You don't have to *disable* anything; you choose how do you want to use your services (if the services provide both ways, like OpenSSH does). 5.fschecking mounts and logging output (though how for corrupt / notsure) Corrupt filesystems or logs? logs. currently if fsck runs anywhere on boot i get zero log about what was done, so i prefer to do this on a running system. / is obviously special, so this is a pro that fsck is logged, but of course if / has issue i'm not sure what systemd would do other than drop you to emergency 6.auto-gettys allows for lower numbered X windows by default for e.g. multiseat and dynamic serial ttys 7.clever logging, including from nspawned containers' logs and distributed for enterprise 8.nspawning using filename namespaces 9.systemctl kill service -- killing service and all forks and spawn cgtop -- top with cgroups 10.much easier to define resource limitations per service cons 1.new tools to learn, new gotchas to learn. 2.yet to go through systemd source to find out how modular or not it is. While it tries to be modular where it can, systemd prefers simple code and integrated solutions. Modularity is not going to be one of its strong points. 3.not clear how the socket activator works, the code activator.c appears to be to _test_ activation only, with activator code being elsewhere. if it is used then you would have one process running for each port it is virtually listened to. It's been a while since I've read the source code, but it isn't in src/activate/activate.c[3]? ok so it does look like it would have a systemd-activate process for each socket being activated on behalf of a service. that makes me feel better than one process doing all of them. perhaps someone using service activation can do a 'ps aux' to confirm? 4./etc/machine-id because hostname and node id in the cluster of your choice are not enough. The idea is that machine-id is as unique as reasonable to ask. I'm not overly happy with it, too, but that's the justification. Imagine thousands of virtual machines running services, and you want to coalesce all their journal logs in a central server. With machine-id, you don't need to worry even to change the default localhost for your throwaway VMs, you can detect the different logs immediately (machine-id should be generated at OS install time; for rolling distros, I think they generate it if when installing systemd is not available.) 5./fsck.options gives more options than autoforceskip on reboot 6.requiring logging tools in rescue cds in order to view logs Yeah, that's a drag. However, you *can* run rsyslog (or syslog-ng) alongside the journal, and have the best of both worlds. Or you can automatically send the journal logs to a central server designed for that purpose only. 7.chroots no longer work. forcing use of nspawn to ensure environment set up correctly. I'm sorry, chroot doesn't work? First time I heard about it. While systemd-nspawn is a gazillion times better than a simple chroot, you *can* still use a chroot if you so desire. Where did you found that chroot doesn't works? agreed nspawn is better due to
Re: [gentoo-user] Multiple package instances ..... Help me understand this emerge error, please.
On Sun, Feb 23, 2014 at 01:32:36AM +0100, waben...@gmail.com wrote: Am Samstag, 22.02.2014 um 21:15 What do I have to do to get this thing emerged? Thanks! Sometimes it is helpful to increase the backtrack value. Some weeks ago I had a similar problem and could I solve it with emerge --backtrack=100 ... Thanks for the suggestion. Unfortunately, it didn't help. :-( -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Multiple package instances ..... Help me understand this emerge error, please.
Hi, Alan. On Sun, Feb 23, 2014 at 12:06:15AM +0200, Alan McKinnon wrote: On 22/02/2014 23:15, Alan Mackenzie wrote: Hi, Gentoo. I've just tried an emerge -puND world, after a shockingly long interval. I got the error message: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: , etc. To simplify the problem, I tried to emerge an individual package identified in that message, and tried emerge -p libpng. I got the same message, with this: ### !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: media-libs/libpng:0 (media-libs/libpng-1.5.17-r1::gentoo, installed) pulled in by media-libs/libpng:0/0= required by (x11-libs/cairo-1.12.14-r4::gentoo, installed) =media-libs/libpng-1.4:0/0= required by (app-editors/emacs-24.3-r2::gentoo, installed) media-libs/libpng:0/0= required by (media-libs/libwebp-0.3.1::gentoo, installed) media-libs/libpng:0/0= required by (net-print/cups-filters-1.0.36-r1::gentoo, installed) media-libs/libpng:0/0= required by (kde-base/kdelibs-4.11.2-r1::gentoo, installed) media-libs/libpng:0/0= required by (dev-qt/qtgui-4.8.5-r1::gentoo, installed) media-libs/libpng:0/0= required by (app-text/poppler-0.24.3::gentoo, installed) (and 3 more with the same problems) (media-libs/libpng-1.6.8::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) ### Clearly, I'm trying to update libpng-1.5.17 to libpng-1.6.8. What does this portion of the message mean: media-libs/libpng:0/0= ^ ? Is it somehow telling me that cairo and friends require the currently installed version, whatever that is? Where is this format documented? I couldn't find anything about it in the Gentoo handbook, and not in the emerge man page either. What do I have to do to get this thing emerged? Thanks! You've hit the dreaded sub-slot (a new portage feature). It causes no end of trouble as so few people know how it really works, but it's intended to replace @preserved-rebuild by DoingItRite and finally make revdep-rebuild obsolete. It's documented in man 5 ebuild under these headings: Atom Slots Sub Slots Atom Slot Operators SLOT Thanks! I know what :0/0= means, now. libpng:0/0 is libpng SLOT 0 which has been around since EAPI1 and SUBSLOT 0 which is new. Take cairo which is one of your deps. In the ebuild: RDEPEND= media-libs/libpng:0= eix libpng shows: (0)1.5.15 1.5.17-r1 (~)1.6.6(0/16) (~)1.6.7(0/16) 1.6.8(0/16) (~)1.6.9(0/16) That shows libpng-1.5.* have slot/subslot 0/0 and libpng-1.6.* have slot/subslot 0/16 where presumably 16 is shorthand for 1.6 in the version Now read those headings in the man page, you will find this gem: = Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will break unless a matching package with slot and sub-slot equal to the slot and sub-slot of the best installed version at the time the package was installed is available. Examples: dev-libs/icu:= dev-lang/perl:= dev-libs/glib:= in other words, even though libpng-1.5.17-r1 and libpng-1.6.8 are in the same SLOT, nevertheless cairo will break if you upgrade libpng that way. OK. Or expressed another way in language from before sub-slots, cairo will stop working properly after the emerge world until you run revdep-rebuild and fix and the borkage I wouldn't have a problem with that. Trouble is, emerge won't merge libpng because of this conflict. The world update wants to upgrade libpng as a new stable version is available but portage won't do it as it will break packages that use libpng. Yes. All my hosts here are up to date so I can't reproduce your problem: - is portage up to date runnign latest version in your tree? Update that first (always a good idea anyway) Yes: I've got portage-2.2.7, having synched my portage yesterday and checked with emerge -s. - are you sure that's an emerge failure and not just a convoluted info message? Perhaps post the entire emerge output. I tried it again without the -p, and got the same output. I think this is a portage bug. At the very least, it's poor documentation. I've reported the situation to bugs.gentoo.org, bug #502236. Thanks for the help. -- Alan McKinnon alan.mckin...@gmail.com -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Multiple package instances ..... Help me understand this emerge error, please.
Hi, Mick. On Sat, Feb 22, 2014 at 11:32:42PM +, Mick wrote: On Saturday 22 Feb 2014 22:06:15 Alan McKinnon wrote: On 22/02/2014 23:15, Alan Mackenzie wrote: Hi, Gentoo. I've just tried an emerge -puND world, after a shockingly long interval. I got the error message: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: , etc. To simplify the problem, I tried to emerge an individual package identified in that message, and tried emerge -p libpng. I got the same message, with this: # ## !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: media-libs/libpng:0 (media-libs/libpng-1.5.17-r1::gentoo, installed) pulled in by media-libs/libpng:0/0= required by (x11-libs/cairo-1.12.14-r4::gentoo, installed) =media-libs/libpng-1.4:0/0= required by (app-editors/emacs-24.3-r2::gentoo, installed) media-libs/libpng:0/0= required by (media-libs/libwebp-0.3.1::gentoo, installed) media-libs/libpng:0/0= required by (net-print/cups-filters-1.0.36-r1::gentoo, installed) media-libs/libpng:0/0= required by (kde-base/kdelibs-4.11.2-r1::gentoo, installed) media-libs/libpng:0/0= required by (dev-qt/qtgui-4.8.5-r1::gentoo, installed) media-libs/libpng:0/0= required by (app-text/poppler-0.24.3::gentoo, installed) (and 3 more with the same problems) (media-libs/libpng-1.6.8::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) # ## Clearly, I'm trying to update libpng-1.5.17 to libpng-1.6.8. What does this portion of the message mean: media-libs/libpng:0/0= ^ ? Is it somehow telling me that cairo and friends require the currently installed version, whatever that is? Where is this format documented? I couldn't find anything about it in the Gentoo handbook, and not in the emerge man page either. What do I have to do to get this thing emerged? Thanks! You've hit the dreaded sub-slot (a new portage feature). It causes no end of trouble as so few people know how it really works, but it's intended to replace @preserved-rebuild by DoingItRite and finally make revdep-rebuild obsolete. It's documented in man 5 ebuild under these headings: Atom Slots Sub Slots Atom Slot Operators SLOT libpng:0/0 is libpng SLOT 0 which has been around since EAPI1 and SUBSLOT 0 which is new. Take cairo which is one of your deps. In the ebuild: RDEPEND= media-libs/libpng:0= eix libpng shows: (0)1.5.15 1.5.17-r1 (~)1.6.6(0/16) (~)1.6.7(0/16) 1.6.8(0/16) (~)1.6.9(0/16) That shows libpng-1.5.* have slot/subslot 0/0 and libpng-1.6.* have slot/subslot 0/16 where presumably 16 is shorthand for 1.6 in the version Now read those headings in the man page, you will find this gem: = Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will break unless a matching package with slot and sub-slot equal to the slot and sub-slot of the best installed version at the time the package was installed is available. Examples: dev-libs/icu:= dev-lang/perl:= dev-libs/glib:= in other words, even though libpng-1.5.17-r1 and libpng-1.6.8 are in the same SLOT, nevertheless cairo will break if you upgrade libpng that way. Or expressed another way in language from before sub-slots, cairo will stop working properly after the emerge world until you run revdep-rebuild and fix and the borkage The world update wants to upgrade libpng as a new stable version is available but portage won't do it as it will break packages that use libpng. All my hosts here are up to date so I can't reproduce your problem: - is portage up to date runnign latest version in your tree? Update that first (always a good idea anyway) - are you sure that's an emerge failure and not just a convoluted info message? Perhaps post the entire emerge output. I can't recall how I got out of this, but by instinct I would probably unmerge libpng, emerge world and then @preserved-rebuild and revdep-rebuild. I've reported the situation to bugs.gentoo.org (#502236), so I'll wait and see what comes back before I change my current portage state. -- Regards, Mick -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Monday 17 Feb 2014 07:01:53 Yuri K. Shatroff wrote: 17.02.2014 00:19, Canek Peláez Valdés пишет: On Sun, Feb 16, 2014 at 1:00 PM, Yuri K. Shatroff yks-...@yandex.ru wrote: [ snip ] Isn't there too many if you believe and if you agree? A church of systemd? ;) As I said to Tanstaafl, it gets kind of philosophical. Even religious. Technically, systemd is the obvious superior choice, and that's why the TC voted for it in Debian (read the discussion). Oh I have read so many discussions already... :) To me, systemd's technical superiority is far not obvious. Just another init system would be, but as long as systemd is much more that one, I can't say that. It should NOT be compared to OpenRC / upstart alone, rather to a whole bunch of tools it replaces, and probably even those it's ambitious to replace. I wonder why all systemd's fancy stuff hasn't yet been integrated into any existing init system, because of theoretical impossibility or just practical uselessness? If it's practically useless, why so many distributions keep choosing it? Why GNOME started using it? Well, I said that technical superiority matters little for maintainers; what matters is money. If I'd write some super-puper fancy init system and kernel replacement, who would be interested? It's not the time of Linus' rise, now you don't deal with USENET freaks, but with Intel, RedHat and other billionaire corps. Do you have the guts and means to keep up with competitors, even not about kernel/init subsystems, but a user app like mailer/browser/messenger... A kernel subsystem requires much more technical competence to maintain and is far more critical for functioning, so much more important here is not any 'technical superiority' but simply resources, human and financial, spared if using RH-maintained systemd. Actually why not do the daemon management, logging, cron etc in the Linux kernel itself? It's obvious, and we even have a perfect example of kernel-integrated graphics around -- `guess the OS name`. It also has much in common with systemd; Believe us it's the best OS, Believe us it provides loads of features, Agree with having binary logs etc. All the software is libre; with only that any comparison to Microsoft becomes moot. Once you mentioned technical superiority, let's compare other stuff technically too. :) A competent approach for choosing software for a task is answering the questions: 1. Is the software standards-compliant? 2. Does the software have an alternative compatible implementation? 3. Is the software developed to achieve a certain, concrete goal? 4. Does the software achieve the goal? 5. Does the software achieve the goal gracefully? 6. Does the software have a clear perspective and view what it will be like? 7. Is the software developed and maintained by a reliable company or group? That's *your* approach. It's certainly not my approach: I don't care if Emacs is standards-compliant (whatever that means for a text editor); I don't care if Inkscape has an alternative compatible implementation; and for the rest of your questions, my answer would be yes. You don't care about Emacs and Inkscape but do you care the same nought about e.g. /bin/cp, /bin/mv etc? Do you care that your browser talks HTTP rather than SHiTP? Do you care that once after a couple of years your systems get unmaintained and unmaintainable because the software on them becomes a load of bashed up crap which only a world's head lennart can deal with? Well, you'll say that red hat tralala, but we've seen the rise and fall of many giants e.g. Sun with their once 'technically superior' Solaris and SPARCs, well one can name many I just don't have time, also we seen MySQL bought by Oracle, and all. Nothing is eternal, and it's (Again!) quite not always technical matters that matters. AFAICT, with systemd there's by far one yes. The other answers are dubious if just plain no. From your point of view. I'd personally share Alan McKinnon's POV: there's no real reason to switch to systemd since the present init systems serve pretty well and the benefit, if any, isn't worth the adaptation threshold. That's fine; you don't have to use systemd. But if (as an extreme and unlikely example), Gentoo decided to switch exclusively to systemd, then either someone willing and able would need to come out ant start maintaining the alternatives, or then you should do it. At present, no. But the trend is clear. That's how free software works. Actually, free software (one you don't pay for) works like any other software you pay for. You probably wanted to say that's how the OSS model works but it's getting less and less true. The OSS model in many cases retains only its open source. Take MySQL, take KDE, take GNOME. Who cares about users? We do what we deem feasible regardless if you like it or not. Don't
[gentoo-user] Compiles take much longer than in the past
Hey list, I'm observing on this olde Centrino laptop that emerges take much, much longer for certain packages than they did in the past. There was a bigger update on 25. Jan (the first since 20. Oct) and another one on 22. Feb. Examples can be found at the bottom, they show increases from 15 to more than 100 percent. It's not with every package and there's always some fluctuation of course as packet versions get bigger. But I really noticed it when I was rebuilding gcc. Usually on bigger updates, I let it sit in the corner for the day, not using it, since it's a puny single-core. I'm using the same CXXFLAGS on my netbook, where gcc also took a step up from 4.6 to 4.7 (increas by 200%), so it's inherent in the version upgrade. OTOH, the first gcc-4.7 installation in the Centrino took only half as long as any of the following. (On a sidenote, a 64 bit crossdev gcc on the netbook -- same version and same useflags as world's -- took 51 minutes, whereas the system compiler needed 2h 40. What gives?) Can you give me an insight based on the little knowledge I can provide about the environment? My usual CXXFLAGS are -O2 -march=native -fomit-frame-pointer -pipe. At some point in the past I added -fno-unwind-tables -fno-asynchronous-unwind-tables. My browser history tells me that I was researching that on 25. October 2013. And recently I experimented with -mpfmath=sse, but when gcc wouldn't build with that on the Netbook, I removed it again yesterday. I removed the extra CXXFLAGS yesterday and rebuilt gcc twice over last night, but the results aren't as hoped. Example compile times (output of qlop -g, with the installed versions added by me) gcc: Sat Apr 27 20:06:24 2013: 5338u seconds # 4.6.3 gcc: Sun Oct 20 21:05:53 2013: 7878u seconds # 4.7.3-r1 gcc: Sun Jan 26 06:18:34 2014: 7274u seconds # 4.7.3-r1 with USE=fortran until here (profile default), and probably introducing fno-...-tables gcc: Sat Feb 22 22:58:16 2014: 15814u seconds # 4.7.3-r1 did some stuff while compiling - not pure compile time. But from here USE=-fortran gcc: Sun Feb 23 05:05:02 2014: 12952u seconds # 4.7.3-r1 removed -fno-unwind-tables -fno-asynchronous-unwind-tables -mpfmath=sse gcc: Sun Feb 23 09:50:35 2014: 13118u seconds # 4.7.3-r1 mc: Sun Apr 28 05:58:04 2013: 218u seconds # 4.8.7 mc: Sun Jan 26 08:37:50 2014: 238u seconds # 4.8.9 mc: Sun Feb 23 03:41:36 2014: 586u seconds # 4.8.11 php: Sun Jan 26 08:42:19 2014: 1994u seconds # 5.5.7 php: Sat Feb 1 16:37:25 2014: 2321u seconds # 5.5.7 php: Sun Feb 23 08:42:49 2014: 4037u seconds # 5.5.9 qtcore: Tue Jul 16 23:28:28 2013: 1424u seconds # 4.8.4-r5 qtcore: Mon Oct 21 00:23:09 2013: 1518u seconds # 4.8.5 qtcore: Sat Jan 25 23:34:12 2014: 2097u seconds # 4.8.5-r1 openssl: Sun Apr 28 00:54:07 2013: 378u seconds # 1.0.1c openssl: Mon Oct 21 13:21:48 2013: 404u seconds # 1.0.1e-r1 openssl: Sat Jan 25 21:41:01 2014: 546u seconds # 1.0.1f xorg-server: Sun Apr 28 05:37:58 2013: 430u seconds # 1.13.4 xorg-server: Mon Oct 21 15:24:02 2013: 501u seconds # 1.14.3 xorg-server: Sun Jan 26 16:48:22 2014: 544u seconds # 1.14.3-r2 gegl: Wed Jul 17 19:59:39 2013: 204u seconds # 0.1.6 gegl: Mon Oct 21 16:43:45 2013: 239u seconds # 0.2.0-r2 gegl: Sat Feb 1 17:31:07 2014: 273u seconds # 0.2.0-r2 git: Sun Apr 28 06:37:01 2013: 228u seconds # 1.8.1.5 git: Mon Oct 21 16:47:44 2013: 226u seconds # 1.8.1.5-r1 git: Sun Jan 26 00:36:17 2014: 314u seconds # 1.8.3.2-r1 kopete: Fri Sep 13 07:16:13 2013: 1495u seconds # 4.11.1 kopete: Mon Oct 21 23:29:32 2013: 1531u seconds # 4.11.2 kopete: Sat Feb 1 05:36:00 2014: 2025u seconds # 4.11.2-r1 kmail: Fri Sep 13 09:15:12 2013: 2015u seconds # 4.11.1 kmail: Tue Oct 22 02:20:00 2013: 2059u seconds # 4.11.2 kmail: Sat Feb 1 07:46:49 2014: 2489u seconds # 4.11.2-r1 portage: Wed Jul 17 01:26:02 2013: 55u seconds # 2.1.12 portage: Thu Sep 12 18:08:27 2013: 72u seconds # 2.2.1 portage: Sat Jan 25 19:12:30 2014: 126u seconds # 2.2.7 curl: Thu Sep 12 21:55:12 2013: 201u seconds # 7.31.0 curl: Sat Jan 25 22:26:28 2014: 259u seconds # 7.34.0-r1 curl: Sat Feb 22 20:17:06 2014: 608u seconds # 7.35.0 # Possible did some other stuff at the same time. qtsql: Mon Oct 21 05:12:27 2013: 124u seconds # 4.8.5 qtsql: Sun Jan 26 00:54:54 2014: 522u seconds # 4.8.5 qtdbus: Mon Oct 21 04:44:45 2013: 194u seconds # 4.8.5 qtdbus: Sun Jan 26 01:03:36 2014: 223u seconds # 4.8.5 lcms: Sat Jan 25 21:50:07 2014: 85u seconds # 2.5 lcms: Sat Feb 1 11:55:35 2014: 81u seconds # 2.5 lcms: Sat Feb 22 21:15:26 2014: 196u seconds # 2.5-r1 json-c: Sat Sep 8 21:39:56 2012: 30u seconds # 0.9 json-c: Sat Jan 25 21:12:03 2014: 58u seconds # 0.11 json-c: Sat Feb 22 21:13:33 2014: 113u seconds # 0.11 -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. I am not half as intelligent as you are! signature.asc Description: Digital signature
Re: [gentoo-user] Multiple package instances ..... Help me understand this emerge error, please.
On 23/02/2014 14:13, Alan Mackenzie wrote: - are you sure that's an emerge failure and not just a convoluted info message? Perhaps post the entire emerge output. I tried it again without the -p, and got the same output. I think this is a portage bug. At the very least, it's poor documentation. I've reported the situation to bugs.gentoo.org, bug #502236. Thanks for the help. I don't think you have a portage bug as such (other than the sloppy bizarre output messages that are going into recent versions). I think we have bug in an ebuild, probably a maintainer that doesn't quite know how to navigate these new subslots waters, One of the other replies suggested to unmerge libpng, emerge it back, and continue with emerge world, @preserved-rebuild, revdep-rebuild. Chances are this will work around the issue and let you update everything. There *is* a chance some package(s) won't work with or won't compile with libpng[1] and you'll have to unwind things again. If this happens that will be valuable info to add the entry at bgo [1] This happened to me at least once before, I had to package.mask the latest version of the library until the tree sorted itself out. IIRC, it was libpng then too! -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Multiple package instances ..... Help me understand this emerge error, please.
Hello, Alan. On Sun, Feb 23, 2014 at 05:22:15PM +0200, Alan McKinnon wrote: On 23/02/2014 14:13, Alan Mackenzie wrote: - are you sure that's an emerge failure and not just a convoluted info message? Perhaps post the entire emerge output. I tried it again without the -p, and got the same output. I think this is a portage bug. At the very least, it's poor documentation. I've reported the situation to bugs.gentoo.org, bug #502236. Thanks for the help. I don't think you have a portage bug as such (other than the sloppy bizarre output messages that are going into recent versions). I think we have bug in an ebuild, probably a maintainer that doesn't quite know how to navigate these new subslots waters, OK. This is a bit philosophical. The way I see it is even if the main bug is in the libpng ebuild, portage should have a way of protecting itself against whatever is in the ebuild. Currently it's wedged. One of the other replies suggested to unmerge libpng, emerge it back, and continue with emerge world, @preserved-rebuild, revdep-rebuild. I'll wait a few days on the response to the bug report, just in case somebody wants me to probe the current state. Chances are this will work around the issue and let you update everything. There *is* a chance some package(s) won't work with or won't compile with libpng[1] and you'll have to unwind things again. If this happens that will be valuable info to add the entry at bgo [1] This happened to me at least once before, I had to package.mask the latest version of the library until the tree sorted itself out. IIRC, it was libpng then too! Surely package management shouldn't be this difficult? -- Alan McKinnon alan.mckin...@gmail.com -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] libpng slot usage
Hello, I am trying to compile fltk-1.1.10 both using an ebuild from [1] and with just the downloaded source. I think this version needs libpng 1.2 which is installed in one of the slots. Using the source code and cmake with FLTK_USE_SYSTEM_PNG off it complies fine. I can see that it automatically points the libs to /usr/lib64/libpng12.so.0. The ebuild does not use cmake, it uses autoconf/automake which is also suported. I tried to build the code this way with --disable/enable-localpng with no luck. The problem is the used png.h file. Which is /usr/include/png.h which points to /usr/include/libpng16/png.h but I need the one from version 1.2. I thought slots would allow to have both versions of the library and use them but only one include file is present: $ equery f libpng:1.2 * Searching for libpng:1.2 ... * Contents of media-libs/libpng-1.2.50-r1: /usr /usr/lib64 /usr/lib64/libpng12.so.0 /usr/share /usr/share/doc /usr/share/doc/libpng-1.2.50-r1 /usr/share/doc/libpng-1.2.50-r1/CHANGES.bz2 /usr/share/doc/libpng-1.2.50-r1/README.bz2 /usr/share/doc/libpng-1.2.50-r1/TODO.bz2 Any idea on how to solve this problem? Some how it should be possible maybe not using the system lib like I did with cmake but I can't figure it out how to do it with autoconf/automake. Thank you, Quim [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/fltk/fltk-1.1.10.ebuild?view=log
Re: [gentoo-user] Multiple package instances ..... Help me understand this emerge error, please.
On 23/02/2014 18:13, Alan Mackenzie wrote: Hello, Alan. On Sun, Feb 23, 2014 at 05:22:15PM +0200, Alan McKinnon wrote: On 23/02/2014 14:13, Alan Mackenzie wrote: - are you sure that's an emerge failure and not just a convoluted info message? Perhaps post the entire emerge output. I tried it again without the -p, and got the same output. I think this is a portage bug. At the very least, it's poor documentation. I've reported the situation to bugs.gentoo.org, bug #502236. Thanks for the help. I don't think you have a portage bug as such (other than the sloppy bizarre output messages that are going into recent versions). I think we have bug in an ebuild, probably a maintainer that doesn't quite know how to navigate these new subslots waters, OK. This is a bit philosophical. The way I see it is even if the main bug is in the libpng ebuild, portage should have a way of protecting itself against whatever is in the ebuild. Currently it's wedged. I know what you mean. emerge doesn't work, therefore the system is broken. One of the other replies suggested to unmerge libpng, emerge it back, and continue with emerge world, @preserved-rebuild, revdep-rebuild. I'll wait a few days on the response to the bug report, just in case somebody wants me to probe the current state. Chances are this will work around the issue and let you update everything. There *is* a chance some package(s) won't work with or won't compile with libpng[1] and you'll have to unwind things again. If this happens that will be valuable info to add the entry at bgo [1] This happened to me at least once before, I had to package.mask the latest version of the library until the tree sorted itself out. IIRC, it was libpng then too! Surely package management shouldn't be this difficult? Indeed. yum is not this difficult. apt is not this difficult. FreeBSD ports are not this difficult. [Windows OTOH often is this difficult]. The big difference is those are binary distros so they have a somewhat stable and predictable base. Gentoo is not, Gentoo's base is whatever emerge finds happens to be there. All the complexity, new features and weird verbose messages in portage are not there to make things work, they are there to detect problems when it doesn't work and prevent problem situations from going into the works in the first place. Personally, I think portage has gone too far and the complex solutions are causing problems that are worse than what they attempt to solve. Amzing solutions (like sub-slots) aren't really much use in the real world if the package maintainers use them incorrectly, right? Well that's my 2c. I was quite happy with revdep-rebuild -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] banshee installation without systemd
Hello, after reading the thread about systemd somebody mentioned sys-fs/eudev. I decided used because I had systemd only to used udev and unmerge systemd. Now I can't use Banshee which I use as my music player because of the next dependency tree: banshee - gnome-base/gnome-settings-daemon - sys-apps/gentoo-systemd-integration - sys-apps/systemd and systemd can't be used because it conflicts with eudev. Is there anyway to avoid emerge systemd in this case? Thank you, Quim
Re: [gentoo-user] Multiple package instances ..... Help me understand this emerge error, please.
Mick, You do realize that blind bottom posting is far WORSE than blind top-posting (done here intentionally to make a point), don't you? Please trim your posts. On 2014-02-22 6:32 PM, Mick michaelkintz...@gmail.com wrote: On Saturday 22 Feb 2014 22:06:15 Alan McKinnon wrote: On 22/02/2014 23:15, Alan Mackenzie wrote: Hi, Gentoo. I've just tried an emerge -puND world, after a shockingly long interval. I got the error message: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: , etc. To simplify the problem, I tried to emerge an individual package identified in that message, and tried emerge -p libpng. I got the same message, with this: # ## !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: media-libs/libpng:0 (media-libs/libpng-1.5.17-r1::gentoo, installed) pulled in by media-libs/libpng:0/0= required by (x11-libs/cairo-1.12.14-r4::gentoo, installed) =media-libs/libpng-1.4:0/0= required by (app-editors/emacs-24.3-r2::gentoo, installed) media-libs/libpng:0/0= required by (media-libs/libwebp-0.3.1::gentoo, installed) media-libs/libpng:0/0= required by (net-print/cups-filters-1.0.36-r1::gentoo, installed) media-libs/libpng:0/0= required by (kde-base/kdelibs-4.11.2-r1::gentoo, installed) media-libs/libpng:0/0= required by (dev-qt/qtgui-4.8.5-r1::gentoo, installed) media-libs/libpng:0/0= required by (app-text/poppler-0.24.3::gentoo, installed) (and 3 more with the same problems) (media-libs/libpng-1.6.8::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) # ## Clearly, I'm trying to update libpng-1.5.17 to libpng-1.6.8. What does this portion of the message mean: media-libs/libpng:0/0= ^ ? Is it somehow telling me that cairo and friends require the currently installed version, whatever that is? Where is this format documented? I couldn't find anything about it in the Gentoo handbook, and not in the emerge man page either. What do I have to do to get this thing emerged? Thanks! You've hit the dreaded sub-slot (a new portage feature). It causes no end of trouble as so few people know how it really works, but it's intended to replace @preserved-rebuild by DoingItRite and finally make revdep-rebuild obsolete. It's documented in man 5 ebuild under these headings: Atom Slots Sub Slots Atom Slot Operators SLOT libpng:0/0 is libpng SLOT 0 which has been around since EAPI1 and SUBSLOT 0 which is new. Take cairo which is one of your deps. In the ebuild: RDEPEND= media-libs/libpng:0= eix libpng shows: (0)1.5.15 1.5.17-r1 (~)1.6.6(0/16) (~)1.6.7(0/16) 1.6.8(0/16) (~)1.6.9(0/16) That shows libpng-1.5.* have slot/subslot 0/0 and libpng-1.6.* have slot/subslot 0/16 where presumably 16 is shorthand for 1.6 in the version Now read those headings in the man page, you will find this gem: = Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will break unless a matching package with slot and sub-slot equal to the slot and sub-slot of the best installed version at the time the package was installed is available. Examples: dev-libs/icu:= dev-lang/perl:= dev-libs/glib:= in other words, even though libpng-1.5.17-r1 and libpng-1.6.8 are in the same SLOT, nevertheless cairo will break if you upgrade libpng that way. Or expressed another way in language from before sub-slots, cairo will stop working properly after the emerge world until you run revdep-rebuild and fix and the borkage The world update wants to upgrade libpng as a new stable version is available but portage won't do it as it will break packages that use libpng. All my hosts here are up to date so I can't reproduce your problem: - is portage up to date runnign latest version in your tree? Update that first (always a good idea anyway) - are you sure that's an emerge failure and not just a convoluted info message? Perhaps post the entire emerge output. I can't recall how I got out of this, but by instinct I would probably unmerge libpng, emerge world and then @preserved-rebuild and revdep-rebuild.
Re: [gentoo-user] Multiple package instances ..... Help me understand this emerge error, please.
On Sunday 23 Feb 2014 17:25:18 Tanstaafl wrote: Mick, You do realize that blind bottom posting is far WORSE than blind top-posting (done here intentionally to make a point), don't you? Please trim your posts. Sorry for this, I wasn't being lazy. I usually do trim my posts, except for cases where I think that the original post is still of value. Since my answer merely provided a work around with an uncertain outcome, I thought that I should leave in the OP's analysis in case some one more learned than I could chime in. This would also save the OP bumping his post in case it became lost in the thread. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Multiple package instances ..... Help me understand this emerge error, please.
On 2014-02-23 12:42 PM, Mick michaelkintz...@gmail.com wrote: On Sunday 23 Feb 2014 17:25:18 Tanstaafl wrote: You do realize that blind bottom posting is far WORSE than blind top-posting (done here intentionally to make a point), don't you? Please trim your posts. Sorry for this, I wasn't being lazy. I usually do trim my posts, except for cases where I think that the original post is still of value. Since my answer merely provided a work around with an uncertain outcome, I thought that I should leave in the OP's analysis in case some one more learned than I could chime in. This would also save the OP bumping his post in case it became lost in the thread. My main point being, in a case like that, blind TOP-posting would be a much better choice. There actually are cases where blind top-posting is the best option.
Re: [gentoo-user] technical review of systemd
On Sun, Feb 23, 2014 at 5:06 AM, thegee...@thegeezer.net wrote: [ snip ] Corrupt filesystems or logs? logs. currently if fsck runs anywhere on boot i get zero log about what was done, so i prefer to do this on a running system. / is obviously special, so this is a pro that fsck is logged, but of course if / has issue i'm not sure what systemd would do other than drop you to emergency Mmmmh; centurion ~ # journalctl /usr/lib/systemd/systemd-fsck -b -- Logs begin at Tue 2013-09-24 13:39:03 CDT, end at Sun 2014-02-23 11:37:30 CST. -- Feb 18 23:49:16 centurion systemd-fsck[1047]: Centurion: clean, 1054301/3389904 files, 10171017/13533184 blocks Feb 18 23:49:17 centurion systemd-fsck[1531]: Data: clean, 308819/30531584 files, 105744823/122096390 blocks Feb 18 23:49:17 centurion systemd-fsck[1568]: Files: clean, 509045/9773056 files, 20704341/39072470 blocks I mean; my file systems were clean, but if some output was generated, it would be there. I don't think I understand what do you mean by zero log? It's been a while since I've read the source code, but it isn't in src/activate/activate.c[3]? ok so it does look like it would have a systemd-activate process for each socket being activated on behalf of a service. that makes me feel better than one process doing all of them. perhaps someone using service activation can do a 'ps aux' to confirm? It is one instance of systemd-activate for each socket; I don't have any socket activated service waiting for the first connection at this moment, but it's obvious from the source code, I believe. It waits in a loop for a connection, if specified it accepts it, and then launches the service. [ snip ] 7.chroots no longer work. forcing use of nspawn to ensure environment set up correctly. I'm sorry, chroot doesn't work? First time I heard about it. While systemd-nspawn is a gazillion times better than a simple chroot, you *can* still use a chroot if you so desire. Where did you found that chroot doesn't works? agreed nspawn is better due to the filesystem namespaces. chroot itself works, but the environment doesn't so it is effectively broken. full explaination from lennart's blog [5] This is quite old so i don't know if this has been fixed, seems unlikely based on what he described Oh, I see. Yeah; you cannot longer start a service inside a chroot; but in the blog post you cited [5], there is a recipe to launch a chroot inside a unit file, working around this limitation. And, if you are running systemd and want jailed services, systemd-nspawn works so much better. For non service-start-up-and-management stuff (for example, boot from a non-systemd LiveCD and emerge something you forgot that you need), chroot still works. So, there is a workaround if you want to keep using chroot for jailed services, and there's a better alternative. [ snip ] networkd (again, netctl is the command-line front-end) is not for enterprise networks; on the contrary, is for the trivial cases. For example, in a little web server I administer I have: $ cat /etc/systemd/system/network.service [Unit] Description=Static network service After=local-fs.target Before=network.target Documentation=man:ifconfig(8) Documentation=man:route(8) [Service] Type=oneshot RemainAfterExit=yes ExecStart=/bin/ifconfig enp2s12 192.168.1.2 broadcast 192.168.1.255 netmask 255.255.255.0 up ExecStart=/bin/route add default gw 192.168.1.1 enp2s12 [Install] WantedBy=multi-user.target (Yeah, I know, I should switch to ip, I'm sorry, I haven't had the time yet). I'm going to get rid of this trivial network.service unit file when 209 (or better 210) hits Gentoo. Cases like this are the use-cases for networkd. what i don't understand is if you look at how openRC does it, it only really cares about up/down events and the /etc/conf.d/net is very comprehensive, in part because it passes everything to iproute2 to handle, the only thing i can't do without an additional shell script is tc qdiscs. i don't need or want a network manager, just need something that applies confs on startup / stop of interfaces. I'm a little surprised that there isn't an iproute2 .service file reading through your example, in fact this is preferrable to me than using a network manager but using iproute2. I would rather you keep this example in, and have this shown on the wiki or somewhere as this neatly resolves my network concern. Mmmh. Maybe I wasn't clear; in your case, it seems that iproute2+OpenRC *is* your network manager. Perhaps at some point networkd will gain the ability to use iproute2 (or even absorb it), but right now is only for tiny little setups. 10.strange gotchas: /tmp being tmpfs using up to 50% ram. unless mounted in fstab That doesn't have nothing to do with systemd: from man:mount(8): Mount options for tmpfs size=nbytes Override default maximum size of the filesystem. The size is given in bytes, and rounded
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, Feb 23, 2014 at 7:35 AM, Mick michaelkintz...@gmail.com wrote: [ snip ] I am not sure if people object to the Lennart-way of messing up Linux, under the blessings of RHL, or if they just don't like the immediate outcome. Actually, most people that actually *try* using systemd and reads how it works have no problems with it, and of those there are many (like me) who actually quite like it. Essentially, in his arrogance Lennart only needs to code things the way *he* sees as useful or expedient to him and his pay masters. In doing so he throws the *nix way of developing software out of the window and creates a convenient for him monolith. Wherever he can't be bothered to do a neat and versatile job he makes his own arguably option-limiting decisions and thus we have arrived to today's flavour of systemd-udev-pulseaudio-gnome and whatever else he will try to weld in tomorrow. He found like minds in Sievers et al and money from RHL helped them get there. And he also found like minds in some of the kernel developers, and some people from OpenSUSE, and Arch, and Debian, and Gentoo, and even Ubuntu, and old Linux gurus like Keith Packard and Neil Brown[1]. It ain't pretty and architecturally does not follow the *nix design principles, but as Canek says, those who can code better should step up to the plate and redesign systemd as it should have been done from the start for the benefit of Linux, without making the design compromises that Lennart has decided suit him. I don't know if forking systemd is easy, but no one has so far decided to do so. I don't think forking would attract much developers. Writing something new trying to follow the*nix design principles, but being modern and with the same features (all of them optional, of course) of systemd will have more chances; although I think it will fail because most of the people that can code better actually like the systemd design, and would prefer to contribute to it. And if you found enough of this mythical good-coders, good luck defining what it means the*nix design principles. Given the title of this thread I fear that those of us who can't code, will increasingly find our choices becoming limited, because more and more functionality is hacked inextricably into systemd and friends. It's probably too early to call if Gentoo will remain one of the few options in Linux that do not use systemd, but decisions taken upstream (for example initrd for separate /usr) are affecting some us already. First of all, Gentoo uses systemd if the user so desires (like I do). Secondly, no one has proposed (AFAIK) systemd as the default init system for Gentoo, and I don't think no one will in the short term future. And to finish, the fact is that people are using systemd because it works, the design if good (it can be improved, of course; everything can), and it has attracted a really large flock of talented developers around it. No other option offers any interest for people trying to develop new cool things and design new standards; the only similar (albeit much more limited in scope) alternative was Upstart, and I personally don't think it will be maintained for much longer, except for bugs and security vulnerabilities; it will have no new features. In general the people not wanting to use systemd don't even care about its features; they only want the good old SysV (or OpenRC here in Gentoo), and that nobody touches their systems. Since OpenRC is the default in Gentoo, and I don't think that will change anytime soon, they can have that. Regards. [1] http://lwn.net/Articles/584176/ -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] banshee installation without systemd
On Sun, Feb 23, 2014 at 11:02 AM, Fox halfsocial...@gmail.com wrote: Hello, after reading the thread about systemd somebody mentioned sys-fs/eudev. I decided used because I had systemd only to used udev and unmerge systemd. Now I can't use Banshee which I use as my music player because of the next dependency tree: banshee - gnome-base/gnome-settings-daemon - sys-apps/gentoo-systemd-integration - sys-apps/systemd and systemd can't be used because it conflicts with eudev. Knowing the exact versions in the dependency chain would be useful. Is there anyway to avoid emerge systemd in this case? gnome-base/gnome-settings-daemon 3.8.x and 3.10.x have the (quite unsupported) openrc-force USE flag. Set it, and it will force gsd to be used with OpenRC, so you don't need to depend on systemd. Be aware, this is totally unsupported; from /usr/portage/profiles/use.local.desc: gnome-base/gnome-settings-daemon:openrc-force - Skip systemd dependency (#480336), enabling this flag will become your setup to be fully unsupported by upstream and downstream Gnome team. Do not try to enable it unless completely needed So, if something breaks, you get to keep both pieces. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Multiple package instances ..... Help me understand this emerge error, please.
I remember having past a similar problem by this steps: unmerge it. try to update and write the offered package choices on corresponding files, i.e: *.mask/use. update it with --newuse option. Doesn't work, try first installing the aforementioned package and then update. It's actually not a bug, per say, but a short-coming of portage Gentoo should look at. Since this is my first post and in the general user group I have to mention that I hate that G logo. Even Larry rocks it cooler than that. Not that it is pretty ugly, it doesn't even connotate a G. On 23 February 2014 19:50, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-23 12:42 PM, Mick michaelkintz...@gmail.com wrote: On Sunday 23 Feb 2014 17:25:18 Tanstaafl wrote: You do realize that blind bottom posting is far WORSE than blind top-posting (done here intentionally to make a point), don't you? Please trim your posts. Sorry for this, I wasn't being lazy. I usually do trim my posts, except for cases where I think that the original post is still of value. Since my answer merely provided a work around with an uncertain outcome, I thought that I should leave in the OP's analysis in case some one more learned than I could chime in. This would also save the OP bumping his post in case it became lost in the thread. My main point being, in a case like that, blind TOP-posting would be a much better choice. There actually are cases where blind top-posting is the best option. -- GÜLVER, Kerem (+9-05303175062) On 23 February 2014 14:13, Alan Mackenzie a...@muc.de wrote: Hi, Alan. On Sun, Feb 23, 2014 at 12:06:15AM +0200, Alan McKinnon wrote: On 22/02/2014 23:15, Alan Mackenzie wrote: Hi, Gentoo. I've just tried an emerge -puND world, after a shockingly long interval. I got the error message: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: , etc. To simplify the problem, I tried to emerge an individual package identified in that message, and tried emerge -p libpng. I got the same message, with this: ### !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: media-libs/libpng:0 (media-libs/libpng-1.5.17-r1::gentoo, installed) pulled in by media-libs/libpng:0/0= required by (x11-libs/cairo-1.12.14-r4::gentoo, installed) =media-libs/libpng-1.4:0/0= required by (app-editors/emacs-24.3-r2::gentoo, installed) media-libs/libpng:0/0= required by (media-libs/libwebp-0.3.1::gentoo, installed) media-libs/libpng:0/0= required by (net-print/cups-filters-1.0.36-r1::gentoo, installed) media-libs/libpng:0/0= required by (kde-base/kdelibs-4.11.2-r1::gentoo, installed) media-libs/libpng:0/0= required by (dev-qt/qtgui-4.8.5-r1::gentoo, installed) media-libs/libpng:0/0= required by (app-text/poppler-0.24.3::gentoo, installed) (and 3 more with the same problems) (media-libs/libpng-1.6.8::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) ### Clearly, I'm trying to update libpng-1.5.17 to libpng-1.6.8. What does this portion of the message mean: media-libs/libpng:0/0= ^ ? Is it somehow telling me that cairo and friends require the currently installed version, whatever that is? Where is this format documented? I couldn't find anything about it in the Gentoo handbook, and not in the emerge man page either. What do I have to do to get this thing emerged? Thanks! You've hit the dreaded sub-slot (a new portage feature). It causes no end of trouble as so few people know how it really works, but it's intended to replace @preserved-rebuild by DoingItRite and finally make revdep-rebuild obsolete. It's documented in man 5 ebuild under these headings: Atom Slots Sub Slots Atom Slot Operators SLOT Thanks! I know what :0/0= means, now. libpng:0/0 is libpng SLOT 0 which has been around since EAPI1 and SUBSLOT 0 which is new. Take cairo which is one of your deps. In the ebuild: RDEPEND= media-libs/libpng:0= eix libpng shows: (0)1.5.15 1.5.17-r1 (~)1.6.6(0/16) (~)1.6.7(0/16) 1.6.8(0/16) (~)1.6.9(0/16) That shows libpng-1.5.* have slot/subslot 0/0 and libpng-1.6.* have slot/subslot 0/16 where presumably 16 is shorthand for 1.6 in the version Now read those headings in the man page, you will find this gem: = Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will break unless a matching package with
[gentoo-user] Re: flashcards?
Edward M edwardm.gentoo.java at live.com writes: I'm looking for an application to create flashcards for study. Hello, You may want to take a look at anki. app-misc/anki Thanks, I'll give it a test drive James
[gentoo-user] Re: Multiple package instances ..... Help me understand this emerge error, please.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Alan, The easiest method may be to parse the error given: On 02/23/2014 07:13 AM, Alan Mackenzie wrote: ### !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: media-libs/libpng:0 (media-libs/libpng-1.5.17-r1::gentoo, installed) pulled in by media-libs/libpng:0/0= required by (x11-libs/cairo-1.12.14-r4::gentoo, installed) =media-libs/libpng-1.4:0/0= required by (app-editors/emacs-24.3-r2::gentoo, installed) media-libs/libpng:0/0= required by (media-libs/libwebp-0.3.1::gentoo, installed) media-libs/libpng:0/0= required by (net-print/cups-filters-1.0.36-r1::gentoo, installed) media-libs/libpng:0/0= required by (kde-base/kdelibs-4.11.2-r1::gentoo, installed) media-libs/libpng:0/0= required by (dev-qt/qtgui-4.8.5-r1::gentoo, installed) media-libs/libpng:0/0= required by (app-text/poppler-0.24.3::gentoo, installed) (and 3 more with the same problems) (media-libs/libpng-1.6.8::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) ### Each of the packages listed will need to be rebuilt with libpng, so try listing them explicitly on the same emerge command (note that `emerge -uD @world` lists them implicitly, so doing that sometimes will work when a single package fails). For example, you may be able to get # emerge --oneshot media-libs/libpng:0/16 x11-libs/cairo app-editors/emacs \ media-libs/libwebp net-print/cups-filters kde-base/kdelibs dev-qt/qtgui \ app-text/poppler to work, or to give you the 3 more with the same problems, which can then be added to the command line and rebuilt. Because you didn't tell portage that it was allowed to rebuild packages not listed on the command line, portage refused to update the package you *did* list, because it would break those other packages. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTCmzBAAoJELHSF2kinlg4uJ4P/3bRC7UMRGWDrCFEYrlcKWAQ 74LtaAmKXfE75cwb2NtN7tyDM3mDlD2JTG89m9aQp340v2HuH3H7W9nM8MsCqm/g 8/7rv1pViO6GdjzKLnWc0KsFrKCcVsc9r11+0KWRT45y21x92XCiecX/Hb0uDOEN U83xESg8BSrpm/ZNpdtzlZaOjwIYTOlIRvRYGvUeR8oZpTXOzvp8fmlIftp8SDAb ywHRMQ1EDb2qZxb+qO4TBrFRbH2za5aktT6oRo7mEs4DmtTBpE5SFXqqwpEEZgHV N42VprrPdfpqm4x/xOE+s3vYyg4uJaQIyPJKj5AibKpJq0iBl1Q2+/aLxkENVW5l DuJETmlQ4P1SOPmlDdgaV8+EQjjLEBp48chj1eGg0XfE8pljydIqqj3f7xpaWHbD Cay2Rqs2mL4UXeUEdAundGyc9XRlqfD6uag1QGSOZN+hgMRJhVpCt8SyMWOiwBZ1 uUp5G0iQaw8YlXDt/3xvraeGsOXf1kzuAApKWjLzsLRObBzOfPia3IGIB4wX5VDS 0rX+/4LSDNYICbQL0oDFOkN/5vCtGGOMfqkuwv0XLdNoMybYhbPwYsKWjj5sO0Cx Sj9OdQY+bnDhicIHxebniqv//LbCurZLyNywJEf7qlal/mVj+GBF6yZl4RA+lBQv 4uHdr+ZFoKvzdzL6hldZ =O4Qv -END PGP SIGNATURE-
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 23/02/2014 20:18, Canek Peláez Valdés wrote: I don't think forking would attract much developers. Writing something new trying to follow the*nix design principles, but being modern and with the same features (all of them optional, of course) of systemd will have more chances; although I think it will fail because most of the people that can code better actually like the systemd design, and would prefer to contribute to it. And if you found enough of this mythical good-coders, good luck defining what it means the*nix design principles. I've been wondering about this concept of the*nix design principles... I've now concluded it's a myth, much like invisible pink unicorns. Is it like the kernel? A huge monolithic chunk of code with support for modules? Is it like X11? A huge monolithic chunk of code that has a bizarre build system for years, and took something like 5 years of hard work to get it modular? And is 20 years behind the times? And *still* requires devs to jump through hoops to get a rendered image through a compositor and back up the the GPU? Is it like perl? Support every possible way to do something if it remotely makes sense to do it, no matter how bizarre the syntax? Is it like python? Pick ONE way to do it and stick with it dammit! Is it like php? Do whatever you feel like? Is it like command line text processing tools that only do one narrow thing well? [1] Is it like bash? I can't find a decent description of how bash came to be except it's like Vogons - wasn't designed and didn't evolve, it just sort of ... congealed Not to rain on anyone's parade, but there's a prize of 40 internets up for the first person who can clearly and unambiguously define Unix design principles with specificity so that it is globally applicable. Best I can come up with is Use common sense and build stuff that can be used and maintained which is wonderfully descriptive but really sucks as a definition. [1] For lack of a better term, let's just call systemd here a system controller. What is this ONE thing a system controller should do and do it well? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Multiple package instances ..... Help me understand this emerge error, please.
On Sun, 23 Feb 2014 18:59:14 +0200, Alan McKinnon wrote: Personally, I think portage has gone too far and the complex solutions are causing problems that are worse than what they attempt to solve. Amzing solutions (like sub-slots) aren't really much use in the real world if the package maintainers use them incorrectly, right? Well that's my 2c. I was quite happy with revdep-rebuild I wasn't because it relied on your system being broken before it could do anything useful. @preserved-rebuild on the other hand was a perfectly acceptable solution. It didn't break things but kept them working until you could re-emerge the affected packages at a time t suit. Sub-slots are not only complex, they force rebuilds of packages at a time of their choosing, not mine. I'd rather not put all my other updates on hold because sub-slots decide that e-emerging the current versions of libreoffice and chromium is more important (thanks icu!). -- Neil Bothwick There is never enough beer, sex or disk space! signature.asc Description: PGP signature
Re: [gentoo-user] banshee installation without systemd
On 02/23/2014 07:25 PM, Canek Peláez Valdés wrote: On Sun, Feb 23, 2014 at 11:02 AM, Fox halfsocial...@gmail.com wrote: Hello, after reading the thread about systemd somebody mentioned sys-fs/eudev. I decided used because I had systemd only to used udev and unmerge systemd. Now I can't use Banshee which I use as my music player because of the next dependency tree: banshee - gnome-base/gnome-settings-daemon - sys-apps/gentoo-systemd-integration - sys-apps/systemd and systemd can't be used because it conflicts with eudev. Knowing the exact versions in the dependency chain would be useful. Is there anyway to avoid emerge systemd in this case? gnome-base/gnome-settings-daemon 3.8.x and 3.10.x have the (quite unsupported) openrc-force USE flag. Set it, and it will force gsd to be used with OpenRC, so you don't need to depend on systemd. Be aware, this is totally unsupported; from /usr/portage/profiles/use.local.desc: gnome-base/gnome-settings-daemon:openrc-force - Skip systemd dependency (#480336), enabling this flag will become your setup to be fully unsupported by upstream and downstream Gnome team. Do not try to enable it unless completely needed So, if something breaks, you get to keep both pieces. Regards. Ok, thanks for the advise.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, Feb 23, 2014 at 4:32 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On 23/02/2014 20:18, Canek Peláez Valdés wrote: I don't think forking would attract much developers. Writing something new trying to follow the*nix design principles, but being modern and with the same features (all of them optional, of course) of systemd will have more chances; although I think it will fail because most of the people that can code better actually like the systemd design, and would prefer to contribute to it. And if you found enough of this mythical good-coders, good luck defining what it means the*nix design principles. I've been wondering about this concept of the*nix design principles... I've now concluded it's a myth, much like invisible pink unicorns. Exactly. Is it like the kernel? A huge monolithic chunk of code with support for modules? Is it like X11? A huge monolithic chunk of code that has a bizarre build system for years, and took something like 5 years of hard work to get it modular? And is 20 years behind the times? And *still* requires devs to jump through hoops to get a rendered image through a compositor and back up the the GPU? Is it like perl? Support every possible way to do something if it remotely makes sense to do it, no matter how bizarre the syntax? Is it like python? Pick ONE way to do it and stick with it dammit! Is it like php? Do whatever you feel like? Is it like command line text processing tools that only do one narrow thing well? [1] Is it like bash? I can't find a decent description of how bash came to be except it's like Vogons - wasn't designed and didn't evolve, it just sort of ... congealed Not to rain on anyone's parade, but there's a prize of 40 internets up for the first person who can clearly and unambiguously define Unix design principles with specificity so that it is globally applicable. Best I can come up with is Use common sense and build stuff that can be used and maintained which is wonderfully descriptive but really sucks as a definition. I reached a similar conclusion; Unix principles is, basically, whatever good idea you can have for a particular problem. Therefore, almost anything under the sun can be reasonably argued to be following Unix principles. In particular, all of the examples you listed. Unix principles says nothing, means nothing, and helps even less to design anything. Almost all the people criticizing systemd or Wayland are Unix *users*, not *developers*. Most Unix/Linux *developers* (not package maintainers) actually like the changes introduced by systemd and/or Wayland; of those who not, most of them at least *understand* why a change was necessary (and long overdue). A minority oppose those changes vehemently; but at this point, I'm starting to question if that opposition has technical foundations, or if it's just a gut reaction to an specific set of developers and/or companies. [1] For lack of a better term, let's just call systemd here a system controller. What is this ONE thing a system controller should do and do it well? Control the system? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sunday 23 Feb 2014 22:32:32 Alan McKinnon wrote: On 23/02/2014 20:18, Canek Peláez Valdés wrote: I don't think forking would attract much developers. Writing something new trying to follow the*nix design principles, but being modern and with the same features (all of them optional, of course) of systemd will have more chances; although I think it will fail because most of the people that can code better actually like the systemd design, and would prefer to contribute to it. And if you found enough of this mythical good-coders, good luck defining what it means the*nix design principles. I've been wondering about this concept of the*nix design principles... Well, I'm no authority on this since I can't code, but here's a starter for 10: http://www.faqs.org/docs/artu/ch01s06.html http://people.fas.harvard.edu/~lib113/reference/unix/co-unix4.html http://en.wikipedia.org/wiki/Unix_philosophy I've now concluded it's a myth, much like invisible pink unicorns. Is it like the kernel? A huge monolithic chunk of code with support for modules? I would think that although the kernel has grown over the years, it has not done so like systemd. You can still *not* build modules you don't need in your kernel. Is it like X11? A huge monolithic chunk of code that has a bizarre build system for years, and took something like 5 years of hard work to get it modular? And is 20 years behind the times? And *still* requires devs to jump through hoops to get a rendered image through a compositor and back up the the GPU? The X11 devs saw the error of their ways and ended up breaking up the big monolithic Xorg code and releasing it as a modular package since X11 7.0, if I recall right. Is it like perl? Support every possible way to do something if it remotely makes sense to do it, no matter how bizarre the syntax? Is it like python? Pick ONE way to do it and stick with it dammit! Is it like php? Do whatever you feel like? Is it like command line text processing tools that only do one narrow thing well? [1] Is it like bash? I can't find a decent description of how bash came to be except it's like Vogons - wasn't designed and didn't evolve, it just sort of ... congealed Designing a programming language is not exactly parallel with designing an OS, although similarities exist (e.g. re-use code where you can and don't re- invent the wheel). Not to rain on anyone's parade, but there's a prize of 40 internets up for the first person who can clearly and unambiguously define Unix design principles with specificity so that it is globally applicable. The Unix design philosophy may not be globally applicable, but has served Linux well over the years. Lennart has de facto introduced a different way of developing his Linux code, which to others and me seems more restrictive. I am not saying that his coding is poor (I'm not qualified to judge), or that systemd is wholesale bad. But, is this a whole new design paradigm in the development of Linux that we should applaud and follow, or just a mistake borne out of ignorance/arrogance/expedience? Time will tell. [1] For lack of a better term, let's just call systemd here a system controller. What is this ONE thing a system controller should do and do it well? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, Feb 23, 2014 at 5:12 PM, Mick michaelkintz...@gmail.com wrote: [ snip ] Well, I'm no authority on this since I can't code, My point exactly. but here's a starter for 10: http://www.faqs.org/docs/artu/ch01s06.html Funny you mention this; the second definition is by Robert Pike, who later said: Not only is UNIX dead, it's starting to smell really bad. http://people.fas.harvard.edu/~lib113/reference/unix/co-unix4.html You can hear in [2] the best response to the famous quote by Henry Spencer (Those who don't understand UNIX are doomed to reinvent it, poorly.): Those who don't understand UNIX are condemned to quote Henry Spencer. And that's the point; the people doing this changes *obviously understand Unix*. They understand it so well that they are able to look at it honestly, beyond dogma or articles of faith, and see its downsides, so they can try to fix them. http://en.wikipedia.org/wiki/Unix_philosophy This reminds me of the people that quote from religious books to argue about anything non theological. The rules and sound bites in the links you provide are there to summarize rules of thumb; they are NOT scripture, and they are certainly NOT the only way to get a technically good program that is easily maintainable. In other words, you can ignore most of them, or just following them to a point, and anyway end up with a sound design and a technically great program that is easy to maintain and extend. The people with coding experience (or most of them anyway) understand this; we are not a religion, we don't have prophets that speak the undeniably truth. We have highly skilled developers who can have opposing views on how to design and implement many different ideas, and that doesn't (necessarily) means that any of them are wrong. There are many ways to solve a problem of sets of problems. Having Emacs doesn't mean vi is wrong, nor having GNOME means KDE is wrong, nor the other way around. I've now concluded it's a myth, much like invisible pink unicorns. Is it like the kernel? A huge monolithic chunk of code with support for modules? I would think that although the kernel has grown over the years, it has not done so like systemd. You can still *not* build modules you don't need in your kernel. This has nothing to do with Unix principles; it's just that someone willing and able implemented the different options. Is it like X11? A huge monolithic chunk of code that has a bizarre build system for years, and took something like 5 years of hard work to get it modular? And is 20 years behind the times? And *still* requires devs to jump through hoops to get a rendered image through a compositor and back up the the GPU? The X11 devs saw the error of their ways and ended up breaking up the big monolithic Xorg code and releasing it as a modular package since X11 7.0, if I recall right. The X11 devs decided that X11 is crap, and therefore they are working now in Wayland. Yes, Wayland is basically written by the same people who maintains X.org. Again, see [2], it's pretty awesome. Is it like perl? Support every possible way to do something if it remotely makes sense to do it, no matter how bizarre the syntax? Is it like python? Pick ONE way to do it and stick with it dammit! Is it like php? Do whatever you feel like? Is it like command line text processing tools that only do one narrow thing well? [1] Is it like bash? I can't find a decent description of how bash came to be except it's like Vogons - wasn't designed and didn't evolve, it just sort of ... congealed Designing a programming language is not exactly parallel with designing an OS, although similarities exist (e.g. re-use code where you can and don't re- invent the wheel). I'm pretty sure there are lots of people who vehemently believe that the Unix principles can apply to everything, even programming languages. You would be cataloged as an heretic for saying that is not exactly parallel. Not to rain on anyone's parade, but there's a prize of 40 internets up for the first person who can clearly and unambiguously define Unix design principles with specificity so that it is globally applicable. The Unix design philosophy may not be globally applicable, but has served Linux well over the years. No; what has served Linux is to have developers willing and able to write the necessary code, following whatever design they decide is the correct one. Lennart has de facto introduced a different way of developing his Linux code, which to others and me seems more restrictive. First of all, it's not only Lennart; the systemd repo has (literally) dozens of contributors with write access. Second of all, calling restrictive the tightly integrated approach, is exactly as constructive as calling anarchic the loosely integrated one. Like Unix principles, it means nothing and it says nothing. I am not saying that his coding is poor (I'm not qualified to judge), or that systemd is wholesale
[gentoo-user] Re: libpng slot usage
On Sun, 23 Feb 2014 17:54:07 +0100, Fox halfsocial...@gmail.com wrote: Hello, I am trying to compile fltk-1.1.10 both using an ebuild from [1] and with just the downloaded source. I think this version needs libpng 1.2 which is installed in one of the slots. Using the source code and cmake with FLTK_USE_SYSTEM_PNG off it complies fine. I can see that it automatically points the libs to /usr/lib64/libpng12.so.0. The ebuild does not use cmake, it uses autoconf/automake which is also suported. I tried to build the code this way with --disable/enable-localpng with no luck. The problem is the used png.h file. Which is /usr/include/png.h which points to /usr/include/libpng16/png.h but I need the one from version 1.2. I thought slots would allow to have both versions of the library and use them but only one include file is present: $ equery f libpng:1.2 * Searching for libpng:1.2 ... * Contents of media-libs/libpng-1.2.50-r1: /usr /usr/lib64 /usr/lib64/libpng12.so.0 /usr/share /usr/share/doc /usr/share/doc/libpng-1.2.50-r1 /usr/share/doc/libpng-1.2.50-r1/CHANGES.bz2 /usr/share/doc/libpng-1.2.50-r1/README.bz2 /usr/share/doc/libpng-1.2.50-r1/TODO.bz2 Any idea on how to solve this problem? Some how it should be possible maybe not using the system lib like I did with cmake but I can't figure it out how to do it with autoconf/automake. Thank you, Quim [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/fltk/fltk-1.1.10.ebuild?view=log The libpng slots, apart from 0, only install the shared library files, not the headers. They are intended for compatibility with old binaries for which no source code is available, not for building new software. Afaik the common opinion is that different libpng versions are mostly source compatible, and minor patching to other things is preferable to inventing a non-standard way to make the libpng implementation switchable at build-time. Is there a reason you can not use fltk-1.1.10-r2.ebuild [1] in stead, which incorporates a patch [2] for libpng-1.5 (which probably still works with 1.6), as well as various other fixes? 1: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/fltk/fltk-1.1.10-r2.ebuild 2: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/fltk/files/fltk-1.1.10-libpng15.patch -- eroen signature.asc Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 24/02/2014 01:12, Mick wrote: On Sunday 23 Feb 2014 22:32:32 Alan McKinnon wrote: On 23/02/2014 20:18, Canek Peláez Valdés wrote: I don't think forking would attract much developers. Writing something new trying to follow the*nix design principles, but being modern and with the same features (all of them optional, of course) of systemd will have more chances; although I think it will fail because most of the people that can code better actually like the systemd design, and would prefer to contribute to it. And if you found enough of this mythical good-coders, good luck defining what it means the*nix design principles. I've been wondering about this concept of the*nix design principles... Well, I'm no authority on this since I can't code, but here's a starter for 10: http://www.faqs.org/docs/artu/ch01s06.html http://people.fas.harvard.edu/~lib113/reference/unix/co-unix4.html I really like documents like this, all airy-fairy and giving the impression that the whole design was worked out nicely in advance. It wasn't. the doc even quotes this fellow who had nothing to do with the doc itself: Those who don't understand UNIX are doomed to reinvent it, poorly. --Henry Spencer Let me tell you how Unix was designed, how the whole thing took shape once KR had gotten C pretty much stabilized. It is most apparent in IO error handling in early designs and it goes like this: We don't do error handling. We don't even try and deal with it at the point it occurred, we just chuck it back up the stack, essentially giving them message stuff it, I'm not dealing with this. You called me, you fix it. Doesn't sound like good design does it? Sounds more like do whatever you think you can get away with. Good design in this area gives you something conceptually along the lines of try...catch...finally (with possibly some work done to avoid throwing another exception in the finally). Unix error design does this: exit some arb number and an error message is in $@ if you feel like looking for it Strangely, this approach is exactly why Unix took off and got such widespread adoption throughout the 70s. An engineer will understand that a well-thought out design that is theoretically correct requires an underlying design that is consistent. In the 70s, hardware consistency was a joke - every installation was different. Consistent error handling would severely limit the arches this new OS could run on. By taking a Stuff it, you deal with it coz I'm not! approach, the handling was fobbed off to a higher layer that was a) not really able to deal with it and b) at least in a position to try *something*. By ripping out the theoretical correctness aspects, devs were left with something that actually could compile and run. You had to bolt on your own fancy bits to make it reliable but eventually over time these things too stabilized into a consistent pattern (mostly by hardware vendors going bankrupt and their stuff leaving the playing field) And so we come to what Unix design probably really is: You do what you have to to get the job done, the simpler the better, but I'm not *really* gonna hold you to that. I still don't like what Lennart has done with this project, but I also fail to see what design principle he has violated. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: banshee installation without systemd
On Sun, 23 Feb 2014 18:02:01 +0100, Fox halfsocial...@gmail.com wrote:
Hello,
after reading the thread about systemd somebody mentioned
sys-fs/eudev. I decided used because I had systemd only to used udev
and unmerge systemd.
Now I can't use Banshee which I use as my music player because of the
next dependency tree:
banshee
- gnome-base/gnome-settings-daemon
- sys-apps/gentoo-systemd-integration
- sys-apps/systemd
and systemd can't be used because it conflicts with eudev.
Is there anyway to avoid emerge systemd in this case?
Thank you,
Quim
On a system running ~amd64 with eudev/openrc:
eroen@falcon ~ $ emerge -pv media-sound/banshee
=gnome-base/gnome-settings-daemon-2.32.1-r2
These are the packages that would be merged, in order:
Calculating dependencies . . ... done!
[ebuild N ] media-sound/banshee-2.6.1 USE=aac bpm cdda encode mtp {test}
udev web -daap -doc -ipod -karma -youtube 3,246 kB
[ebuild N ] dev-dotnet/gtk-sharp-beans-2.14.0 21 kB
[ebuild N ] dev-dotnet/gtk-sharp-gapi-2.12.10:2 USE=-debug 1,601 kB
[ebuild NS]sys-devel/automake-1.10.3:1.10 [1.9.6-r3:1.9, 1.11.6:1.11,
1.12.6:1.12, 1.13.4:1.13, 1.14.1:1.14] 936 kB
[ebuild N ]dev-lang/mono-3.2.3 USE=nls -debug -doc -minimal
-pax_kernel -xen 0 kB
[ebuild N ] dev-dotnet/libgdiplus-2.10.9-r1 USE=cairo 0 kB
[ebuild N ] dev-dotnet/glib-sharp-2.12.10:2 USE=-debug 0 kB
[ebuild N ] dev-dotnet/gtk-sharp-2.12.10:2 USE=-debug 0 kB
[ebuild N ]dev-dotnet/atk-sharp-2.12.10:2 USE=-debug 0 kB
[ebuild N ]dev-dotnet/gdk-sharp-2.12.10:2 USE=-debug 0 kB
[ebuild N ] dev-dotnet/pango-sharp-2.12.10:2 USE=-debug 0 kB
[ebuild N ] dev-dotnet/gio-sharp-0.3 88 kB
[ebuild N ] dev-dotnet/gkeyfile-sharp-0.1 20 kB
[ebuild N ] media-plugins/gst-plugins-taglib-0.10.31:0.10 0 kB
[ebuild N ] dev-dotnet/dbus-sharp-0.7.0-r1 125 kB
[ebuild N ] media-plugins/gst-plugins-soundtouch-0.10.23:0.10 0 kB
[ebuild N ] media-libs/libsoundtouch-1.8.0 USE=sse2 -static-libs 104
kB
[ebuild N ] dev-dotnet/gconf-sharp-2.24.2:2 USE=-debug 412 kB
[ebuild N ] dev-dotnet/gnome-sharp-2.24.2:2 USE=-debug 0 kB
[ebuild N ]dev-dotnet/art-sharp-2.24.2:2 USE=-debug 0 kB
[ebuild N ]dev-dotnet/gnomevfs-sharp-2.24.2:2 USE=-debug 0 kB
[ebuild N ] dev-dotnet/glade-sharp-2.12.10:2 USE=-debug 0 kB
[ebuild N ] net-libs/webkit-gtk-2.2.5-r200:2 USE=egl gstreamer jit
opengl {test} webgl (-aqua) -coverage -debug -geoloc -gles2 -introspection
-libsecret -spell 9,181 kB
[ebuild N ] media-plugins/gst-plugins-lame-0.10.19:0.10 0 kB
[ebuild N ] dev-dotnet/dbus-sharp-glib-0.5.0 94 kB
[ebuild N ] gnome-base/gnome-settings-daemon-2.32.1-r2 USE=libnotify
-debug -policykit -pulseaudio -smartcard 1,327 kB
[ebuild N ] gnome-base/libgnomekbd-2.32.0-r1 USE={test} 402 kB
[ebuild N ] gnome-base/gnome-desktop-2.32.1-r2:2 USE=-debug
-license-docs PYTHON_TARGETS=python2_7 -python2_6 1,596 kB
[ebuild N ] dev-dotnet/notify-sharp-0.4.0_pre20090305 USE=-doc 78 kB
[ebuild N ] dev-dotnet/taglib-sharp-2.1.0.0 503 kB
[ebuild N ] media-plugins/gst-plugins-gio-0.10.36:0.10 0 kB
[ebuild N ] dev-dotnet/mono-addins-0.6.2 USE=gtk 330 kB
[ebuild N ] dev-dotnet/gudev-sharp-0.1 101 kB
Total: 33 packages (32 new, 1 in new slot), Size of downloads: 20,155 kB
For ease of upgrades, you might want to add
=gnome-base/gnome-settings-daemon-3
in /etc/portage/package.mask rather than specifying it with a specific
version on the command line.
--
eroen
signature.asc
Description: PGP signature
Re: [gentoo-user] Re: banshee installation without systemd
On Sun, Feb 23, 2014 at 7:31 PM, eroen er...@falcon.eroen.eu wrote: On Sun, 23 Feb 2014 18:02:01 +0100, Fox halfsocial...@gmail.com wrote: Hello, after reading the thread about systemd somebody mentioned sys-fs/eudev. I decided used because I had systemd only to used udev and unmerge systemd. Now I can't use Banshee which I use as my music player because of the next dependency tree: banshee - gnome-base/gnome-settings-daemon - sys-apps/gentoo-systemd-integration - sys-apps/systemd and systemd can't be used because it conflicts with eudev. Is there anyway to avoid emerge systemd in this case? Thank you, Quim On a system running ~amd64 with eudev/openrc: eroen@falcon ~ $ emerge -pv media-sound/banshee =gnome-base/gnome-settings-daemon-2.32.1-r2 [ snip emerge output ] For ease of upgrades, you might want to add =gnome-base/gnome-settings-daemon-3 in /etc/portage/package.mask rather than specifying it with a specific version on the command line. That solution is a dead end. GNOME 2 is being removed from the tree[1]. Regards. [1] http://blogs.gentoo.org/eva/2014/02/16/the-future-of-gnome-2/ -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, Feb 24, 2014 at 03:07:09AM +0200, Alan McKinnon wrote We don't do error handling. We don't even try and deal with it at the point it occurred, we just chuck it back up the stack, essentially giving them message stuff it, I'm not dealing with this. You called me, you fix it. The developer is not going to be psychic to the point of knowing what the user *WANTED* to do, years after the code was written... or which different users were expecting which different outcomes. E.g. if portage encounters a problem during a build, do you *REALLY* want it to jump in and randomly patch source code and/or makefiles to get it working? NO!!! You want it to halt, with an informative error message, possibly including suggestions for corrective action. If I mistakenly tell a system to do B, really meaning do A, that's my fault. If I tell it to do A, and it decides to do B, I will be extremely p'd off. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-user] Re: banshee installation without systemd
On Sun, 23 Feb 2014 19:47:55 -0600, Canek Peláez Valdés can...@gmail.com wrote: On Sun, Feb 23, 2014 at 7:31 PM, eroen er...@falcon.eroen.eu wrote: On Sun, 23 Feb 2014 18:02:01 +0100, Fox halfsocial...@gmail.com wrote: Hello, after reading the thread about systemd somebody mentioned sys-fs/eudev. I decided used because I had systemd only to used udev and unmerge systemd. Now I can't use Banshee which I use as my music player because of the next dependency tree: banshee - gnome-base/gnome-settings-daemon - sys-apps/gentoo-systemd-integration - sys-apps/systemd and systemd can't be used because it conflicts with eudev. Is there anyway to avoid emerge systemd in this case? Thank you, Quim On a system running ~amd64 with eudev/openrc: eroen@falcon ~ $ emerge -pv media-sound/banshee =gnome-base/gnome-settings-daemon-2.32.1-r2 [ snip emerge output ] For ease of upgrades, you might want to add =gnome-base/gnome-settings-daemon-3 in /etc/portage/package.mask rather than specifying it with a specific version on the command line. That solution is a dead end. GNOME 2 is being removed from the tree[1]. Regards. [1] http://blogs.gentoo.org/eva/2014/02/16/the-future-of-gnome-2/ You probably mean temporary. The expression dead end would imply it makes future migration more difficult in some way. One would hope (mostly for their image's sake) the gnome team does not remove gnome-settings-daemon-2 until at least one of cinnamon-settings-daemon and mate-settings-daemon are included in gentoo proper. -- eroen signature.asc Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, Feb 23, 2014 at 8:10 PM, Walter Dnes waltd...@waltdnes.org wrote: On Mon, Feb 24, 2014 at 03:07:09AM +0200, Alan McKinnon wrote We don't do error handling. We don't even try and deal with it at the point it occurred, we just chuck it back up the stack, essentially giving them message stuff it, I'm not dealing with this. You called me, you fix it. The developer is not going to be psychic to the point of knowing what the user *WANTED* to do, years after the code was written... or which different users were expecting which different outcomes. E.g. if portage encounters a problem during a build, do you *REALLY* want it to jump in and randomly patch source code and/or makefiles to get it working? NO!!! You want it to halt, with an informative error message, possibly including suggestions for corrective action. But in Unix you usually don't halt, you set errno and go on your merry way. If I mistakenly tell a system to do B, really meaning do A, that's my fault. If I tell it to do A, and it decides to do B, I will be extremely p'd off. I don't see what does that have to do with any of Alan's points. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: banshee installation without systemd
On Sun, Feb 23, 2014 at 8:11 PM, eroen er...@falcon.eroen.eu wrote: On Sun, 23 Feb 2014 19:47:55 -0600, Canek Peláez Valdés can...@gmail.com wrote: On Sun, Feb 23, 2014 at 7:31 PM, eroen er...@falcon.eroen.eu wrote: On Sun, 23 Feb 2014 18:02:01 +0100, Fox halfsocial...@gmail.com wrote: Hello, after reading the thread about systemd somebody mentioned sys-fs/eudev. I decided used because I had systemd only to used udev and unmerge systemd. Now I can't use Banshee which I use as my music player because of the next dependency tree: banshee - gnome-base/gnome-settings-daemon - sys-apps/gentoo-systemd-integration - sys-apps/systemd and systemd can't be used because it conflicts with eudev. Is there anyway to avoid emerge systemd in this case? Thank you, Quim On a system running ~amd64 with eudev/openrc: eroen@falcon ~ $ emerge -pv media-sound/banshee =gnome-base/gnome-settings-daemon-2.32.1-r2 [ snip emerge output ] For ease of upgrades, you might want to add =gnome-base/gnome-settings-daemon-3 in /etc/portage/package.mask rather than specifying it with a specific version on the command line. That solution is a dead end. GNOME 2 is being removed from the tree[1]. Regards. [1] http://blogs.gentoo.org/eva/2014/02/16/the-future-of-gnome-2/ You probably mean temporary. The expression dead end would imply it makes future migration more difficult in some way. Call it temporary if you want to. The point is that gnome-settings-daemon 2.x has been unmaintained for years now. One would hope (mostly for their image's sake) the gnome team does not remove gnome-settings-daemon-2 until at least one of cinnamon-settings-daemon and mate-settings-daemon are included in gentoo proper. Nobody cares about any team image, I suppose. They are all volunteers. If you want cinnamon-sd or mate-sd to get into the tree, help out. Don't assume someone is going to do it for you. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, Feb 24, 2014 at 9:07 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 24/02/2014 01:12, Mick wrote: On Sunday 23 Feb 2014 22:32:32 Alan McKinnon wrote: On 23/02/2014 20:18, Canek Peláez Valdés wrote: I don't think forking would attract much developers. Writing something new trying to follow the*nix design principles, but being modern and with the same features (all of them optional, of course) of systemd will have more chances; although I think it will fail because most of the people that can code better actually like the systemd design, and would prefer to contribute to it. And if you found enough of this mythical good-coders, good luck defining what it means the*nix design principles. I've been wondering about this concept of the*nix design principles... Well, I'm no authority on this since I can't code, but here's a starter for 10: http://www.faqs.org/docs/artu/ch01s06.html http://people.fas.harvard.edu/~lib113/reference/unix/co-unix4.html I really like documents like this, all airy-fairy and giving the impression that the whole design was worked out nicely in advance. It wasn't. the doc even quotes this fellow who had nothing to do with the doc itself: Those who don't understand UNIX are doomed to reinvent it, poorly. --Henry Spencer Let me tell you how Unix was designed, how the whole thing took shape once KR had gotten C pretty much stabilized. It is most apparent in IO error handling in early designs and it goes like this: We don't do error handling. We don't even try and deal with it at the point it occurred, we just chuck it back up the stack, essentially giving them message stuff it, I'm not dealing with this. You called me, you fix it. Doesn't sound like good design does it? Sounds more like do whatever you think you can get away with. Good design in this area gives you something conceptually along the lines of try...catch...finally (with possibly some work done to avoid throwing another exception in the finally). Unix error design does this: exit some arb number and an error message is in $@ if you feel like looking for it Strangely, this approach is exactly why Unix took off and got such widespread adoption throughout the 70s. An engineer will understand that a well-thought out design that is theoretically correct requires an underlying design that is consistent. In the 70s, hardware consistency was a joke - every installation was different. Consistent error handling would severely limit the arches this new OS could run on. By taking a Stuff it, you deal with it coz I'm not! approach, the handling was fobbed off to a higher layer that was a) not really able to deal with it and b) at least in a position to try *something*. By ripping out the theoretical correctness aspects, devs were left with something that actually could compile and run. You had to bolt on your own fancy bits to make it reliable but eventually over time these things too stabilized into a consistent pattern (mostly by hardware vendors going bankrupt and their stuff leaving the playing field) And so we come to what Unix design probably really is: You do what you have to to get the job done, the simpler the better, but I'm not *really* gonna hold you to that. *slow clap* -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [ ] up to you [x] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, Feb 23, 2014 at 9:20 PM, Canek Peláez Valdés can...@gmail.com wrote: On Sun, Feb 23, 2014 at 8:10 PM, Walter Dnes waltd...@waltdnes.org wrote: On Mon, Feb 24, 2014 at 03:07:09AM +0200, Alan McKinnon wrote We don't do error handling. We don't even try and deal with it at the point it occurred, we just chuck it back up the stack, essentially giving them message stuff it, I'm not dealing with this. You called me, you fix it. The developer is not going to be psychic to the point of knowing what the user *WANTED* to do, years after the code was written... or which different users were expecting which different outcomes. E.g. if portage encounters a problem during a build, do you *REALLY* want it to jump in and randomly patch source code and/or makefiles to get it working? NO!!! You want it to halt, with an informative error message, possibly including suggestions for corrective action. But in Unix you usually don't halt, you set errno and go on your merry way. Actually, from everything I've seen (and it's at least true throughout what I've worked with in glibc) you *do* stop dead in your tracks, set errno, and return some (hopefully indicative of a possible error) value. In the case of standalone executables rather than library calls, you stop where you are, if you're feeling generous you output something to stderr on the way out the door, then exit(errno). The process that called *you* then goes on its merry way, handling your response of Hey, something went wrong. Good luck. however it chooses, if it chooses to. If I mistakenly tell a system to do B, really meaning do A, that's my fault. If I tell it to do A, and it decides to do B, I will be extremely p'd off. I don't see what does that have to do with any of Alan's points. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México It ties a bit into the above, really. Concise, job specific tools that do one thing and do them well, and don't try to magic up a guess of what they think the user *wants* when it can't give what the user *specifically* asked for are going to be a lot less destructive than tools that *do* try to guess and go on their merry way (when they're wrong) than simply handing the situation back to the user (not necessarily the end user, just the user that asked for that tool, and asked it to do that one job), who knows their particular circumstances, as well as what they want in that instance. I'll add in a very specific note that I'm not chiming in on the topic of systemd itself, as I've yet to play with it anywhere. I'm just chiming in on the go on your merry way part. The caller goes on their merry way, not the called. All that aside, your side of the discussions on systemd have, at least, made me curious enough to throw together a vm to play with sometime this week when I get time. -- Poison [BLX] Joshua M. Murphy
[gentoo-user] RAID 1 vs RAID 0 - Read perfonmance
Hi. I am again, with a similar question to previous. I want to install RAID on SSD's. Comparing THEORETICALLY, RAID0 (stripe) vs RAID1 (mirrior). The performance would be something like this: n= number of disks reads: raid1: n*2 raid0: n*2 writes: raid1: n raid0: n*2 But, in real life, the reads from raid 0 doesn't work at all, because if you use chunk size from 4k, and you need to read just 2kb (most binary files, txt files, etc..). the read speed should be just of n. On the other side, I read over the net, that kernel don't support multithread reads on raid1. So, the read speed will be just n. Always. ¿It is true? Anyway, my question is. ¿Who have the best read speed for the day to day? I'm not asking about reads off large files. I'm just asking in the normal use. Opening firefox, X, regular files, etc.. I can't find the guide definitive. It allways are talking about theoretically performance, or about real life but without benchmarks or reliable data. Having a RAID0 with SSD, and following [2] on SSD Stripe Optimization should I have the same speed as an RAID1? My question is because i'm between. 4 disks raid1, or RAID10 (I want redundancy anyway..). And as raid 10 = 1+ 0. I need to know raid0 performance to take a choice... I don't need write speed, just read. ¿Anyone knows the true about this? ¿Somebody tried this? Thanx a lot.!! Bytes! ;) [1]http://www.pcstats.com/articleview.cfm?articleid=890page=5 [2] http://www.overclock.net/t/484367/guide-all-you-ever-wanted-to-know-about-raid
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
24.02.2014 05:07, Alan McKinnon wrote: [ ...] We don't do error handling. We don't even try and deal with it at the point it occurred, we just chuck it back up the stack, essentially giving them message stuff it, I'm not dealing with this. You called me, you fix it. Doesn't sound like good design does it? Sounds more like do whatever you think you can get away with. Good design in this area gives you something conceptually along the lines of try...catch...finally (with possibly some work done to avoid throwing another exception in the finally). try...catch...finally *does* leave error handling to *the caller*. It only provides a more object-oriented way to error handling. It *does not* *handle* errors. Unix error design does this: exit some arb number and an error message is in $@ if you feel like looking for it Please, propose a more sound design? Take e.g. jQuery where all errors are handled by the library, it sometimes takes ages to debug why it doesn't work as expected, after a while you eagerly figure why error handling *should* be done by the caller, and the only thing the callee can do reliably is pass an error message upstream. Good error messages (and error codes, or error class hierarchy) are a different problem, but I haven't seen a more proof solution yet. Strangely, this approach is exactly why Unix took off and got such widespread adoption throughout the 70s. An engineer will understand that a well-thought out design that is theoretically correct requires an underlying design that is consistent. In the 70s, hardware consistency was a joke - every installation was different. Consistent error handling would severely limit the arches this new OS could run on. By taking a Stuff it, you deal with it coz I'm not! approach, the handling was fobbed off to a higher layer that was a) not really able to deal with it and b) at least in a position to try *something*. By ripping out the theoretical correctness aspects, devs were left with something that actually could compile and run. You had to bolt on your own fancy bits to make it reliable but eventually over time these things too stabilized into a consistent pattern (mostly by hardware vendors going bankrupt and their stuff leaving the playing field) And so we come to what Unix design probably really is: You do what you have to to get the job done, the simpler the better, but I'm not *really* gonna hold you to that. A good design is based on: - consistency - isolation and substitution of components - component reuse - thorough documentation (a free interpretation of [1]) This almost always leads to many simple components, and that is what's called Unix design principles AFAIU. The problem of Unix is that it doesn't follow Unix design principles any more. But it doesn't invalidate *the principles*. I still don't like what Lennart has done with this project, but I also fail to see what design principle he has violated. As per [1], I fail to see what design principle he has followed. [1] http://en.wikipedia.org/wiki/Software_design#Design_concepts -- Regards, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
24.02.2014 02:32, Alan McKinnon wrote: On 23/02/2014 20:18, Canek Peláez Valdés wrote: I don't think forking would attract much developers. Writing something new trying to follow the*nix design principles, but being modern and with the same features (all of them optional, of course) of systemd will have more chances; although I think it will fail because most of the people that can code better actually like the systemd design, and would prefer to contribute to it. And if you found enough of this mythical good-coders, good luck defining what it means the*nix design principles. I've been wondering about this concept of the*nix design principles... I've now concluded it's a myth, much like invisible pink unicorns. I may not be an authority, too. But please allow me to refute your arguments. Is it like the kernel? A huge monolithic chunk of code with support for modules? It ain't. No monolithic chunk of code, it's configurable. Is it like X11? A huge monolithic chunk of code that has a bizarre build system for years, and took something like 5 years of hard work to get it modular? And is 20 years behind the times? And *still* requires devs to jump through hoops to get a rendered image through a compositor and back up the the GPU? It's grown to that, but in the beginning it was (striving to be) a clean system doing generally one thing (graphical client/server) and doing it well. [1] It's not X11 devs' fault that GPUs and all that multidisplay/ multimedia stuff don't work well with client/server arch because they were designed for some other, you know which, OS. I assume if the GPU vendors had their specs opened 20 years ago, some wayland-like stuff would have been ready near that time. Is it like perl? Support every possible way to do something if it remotely makes sense to do it, no matter how bizarre the syntax? Perl (I suppose you know what it stands for) is great (probably the greatest) for what it was invented for: text manipulation/analysis. It could have been a good replacement for many things like awk, sed, tr etc. if the author were less ambitious to conquer the world with Perl. Is it like python? Pick ONE way to do it and stick with it dammit! You misquoted. The phrase is: there should be one—and preferably only one—obvious way to do it, *one* meaning 'at least one', complemented with *should be* and *obvious*. Is it like php? Do whatever you feel like? Php was a Unix design? LOL. Php wasn't a design at all. It was just another personal home pages perl script. Is it like command line text processing tools that only do one narrow thing well? [1] Perfectly well. Is it like bash? I can't find a decent description of how bash came to be except it's like Vogons - wasn't designed and didn't evolve, it just sort of ... congealed Bash or sh? What about ksh, csh, zsh etc? Well, a shell actually does two things: interactive shell and scripting. Let's ponder on how they can be separated? Not to rain on anyone's parade, but there's a prize of 40 internets up for the first person who can clearly and unambiguously define Unix design principles with specificity so that it is globally applicable. A truism: There's nothing globally applicable. Best I can come up with is Use common sense and build stuff that can be used and maintained which is wonderfully descriptive but really sucks as a definition. Something like this, but neither is it globally applicable. [1] For lack of a better term, let's just call systemd here a system controller. What is this ONE thing a system controller should do and do it well? An init daemon generally does one thing well. [1] http://en.wikipedia.org/wiki/X11#Principles -- Regards, Yuri K. Shatroff
Re: [gentoo-user] RAID 1 vs RAID 0 - Read perfonmance
On 24/02/2014 06:27, Facundo Curti wrote: Hi. I am again, with a similar question to previous. I want to install RAID on SSD's. Comparing THEORETICALLY, RAID0 (stripe) vs RAID1 (mirrior). The performance would be something like this: n= number of disks reads: raid1: n*2 raid0: n*2 writes: raid1: n raid0: n*2 But, in real life, the reads from raid 0 doesn't work at all, because if you use chunk size from 4k, and you need to read just 2kb (most binary files, txt files, etc..). the read speed should be just of n. While the workload does matter, that's not really how it works. Be aware that Linux implements read-ahead (defaulting to 128K):- # blockdev --getra /dev/sda 256 That's enough to populate 32 pages in pagecache, given that PAGESIZE is 4K on i386/am64. On the other side, I read over the net, that kernel don't support multithread reads on raid1. So, the read speed will be just n. Always. ¿It is true? No, it is not true. Read balancing is implemented in RAID-1. Anyway, my question is. ¿Who have the best read speed for the day to day? I'm not asking about reads off large files. I'm just asking in the normal use. Opening firefox, X, regular files, etc.. For casual usage, it shouldn't make any difference. I can't find the guide definitive. It allways are talking about theoretically performance, or about real life but without benchmarks or reliable data. Having a RAID0 with SSD, and following [2] on SSD Stripe Optimization should I have the same speed as an RAID1? I would highly recommend conducting your own benchmarks. I find sysbench to be particularly useful. My question is because i'm between. 4 disks raid1, or RAID10 (I want redundancy anyway..). And as raid 10 = 1+ 0. I need to know raid0 performance to take a choice... I don't need write speed, just read. In Linux, RAID-10 is not really nested because the mirroring and striping is fully integrated. If you want the best read performance with RAID-10 then the far layout is supposed to be the best [1]. Here is an example of how to choose this layout: # mdadm -C /dev/md0 -n 4 -l 10 -p f2 /dev/sda /dev/sdb /dev/sdc /dev/sdd Note, however, that the far layout will exhibit worse performance than the near layout if the array is in a degraded state. Also, it increases seek time in random/mixed workloads but this should not matter if you are using SSDs. --Kerin [1] http://neil.brown.name/blog/20040827225440
