Re: [gentoo-user] Re: udev (viable) alternatives ?
On 10/11/14 13:04, Tanstaafl wrote: On 9/26/2014 1:04 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 25/09/14 22:03, James wrote: I'd be better of with a fresh install of lilblue + musl + eudev is what you are really saying here? that's the only usecase for eudev currently, yes, otherwise you have no reason to switch Hi Samuli, So, is the above still true? Yes, it's still true, there is no reason to change away from sys-fs/udev except for sys-libs/musl use, and even then, I'd be happy to accept musl compability patches for sys-fs/udev's ebuild, but the sys-libs/musl maintainer decided to put his work to sys-fs/eudev instead. So unless some user does the work for him... I wouldn't worry about it at all, there is no way *sys-fs/udev ebuild* will ever need systemd. There might be a news item later, with instructions on moving to something else, but that's not something we are even planning at the moment, so sys-fs/udev is still the de facto proper upstream /dev manager.
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 11/11/14 07:20, Walter Dnes wrote: On Mon, Nov 10, 2014 at 05:48:49PM +0200, Samuli Suominen wrote I wouldn't worry about it at all, there is no way *sys-fs/udev ebuild* will ever need systemd. There might be a news item later, with instructions on moving to something else, but that's not something we are even planning at the moment, so sys-fs/udev is still the de facto proper upstream /dev manager. What worries me is that Lennart has been able to get modifications done to the kernel, e.g. kdbus. I know this'll sound paranoid, but how long before he pushes a patch that requires systemd to run the linux kernel? I expect systemd-udevd to be migrated into kdbus, which means libudev, libgudev-1.0 and the systemd-udevd binary itself will likely need the libsystemd-bus library, which we will then package and ship together with sys-fs/udev Or if systemd-udevd binary starts requiring a running service of some of the systemd services, then we will make those available as well and run the from the udev-init-scripts, or possibly even adjust sys-apps/openrc to compensate for the inadequaties Just trying to say, that even with kdbus pending, I'm not worried at all - Samuli
Re: [gentoo-user] glibc-2.20 and intel microcode
On 11/11/14 05:49, micro...@fedoraproject.org wrote: I've finnally detected the root cause of glibc-2.20 broken my system: glibc-2.20 start using TLX instruction which is disabled by microcode update. disabling microcode update brings my system back to live! so, there is either a bug in CPU , nor glibc has borken CPU feature detection. See, http://bugs.gentoo.org/show_bug.cgi?id=528712 It's likely you are hitting a kernel bug
Re: [gentoo-user] mpeg4ip - replacement
On 25/10/14 02:40, Joseph wrote: Which application replaced mpeg4ip ? I'm trying to streem mpeg4 video and in the past I was using mpeg4ip but I can not find it. -- Joseph media-video/gpac has extended mpeg4 support media-libs/libmp4v2 with USE=utils has command lines utilities media-video/atomicparsley or media-video/atomicparsley-wez and of course, ffmpeg, libav, mplayer, ... when mpeg4ip was removed in favour of the new (read: maintained) libmp4v2 googlecode project, these were the replacements, and users were able to accomplish whatever mpeg4ip did with them thanks, samuli
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 26/09/14 11:22, Canek Peláez Valdés wrote: On Fri, Sep 26, 2014 at 3:07 AM, Neil Bothwick n...@digimed.co.uk wrote: On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote: I buy machines with one ethernet interface. What I find particularly annoying is this doublespeak about calling it predictable. Before the change, it was predicatbly eth0. Now, it's different on every different model. It's not doublespeak, the interfaces are named exactly according to where they are on the PCI bus. If you had two interfaces, they show up to the kernel in random order by time and sometimes eth0/eth1 are nto the same they were before the reboot. That may be true for PCI devices but not for USB ones. If you unplug a USB device and plug it back into the same port, it will get a different device number. The naming is more predictable, but it's not there yet. That doesn't sound right. If unplugging a USB net device and plugging it again *in the same port* results in a different device *name*, then it is a bug and should be reported; the description of the algorithm in [1] sounds like it should get always the same name for the same port, unless I'm misunderstanding something. Regards. [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n51 I've seen this happening once on a cheap laptop with a stripped down BIOS I can't even recall brand for, it had a kludge in the BIOS settings for hotplugging, turning it off, allowed the port to remain same, turning it on, some machine specific code gets executed and the kernel interprets the same port as different port Bad hardware, bad hardware settings, maybe missing exception for that particular hardware type in the code that determines the name... I'm not sure, I don't have the machine anymore - Samuli
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 26/09/14 11:47, Samuli Suominen wrote: On 26/09/14 11:22, Canek Peláez Valdés wrote: On Fri, Sep 26, 2014 at 3:07 AM, Neil Bothwick n...@digimed.co.uk wrote: On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote: I buy machines with one ethernet interface. What I find particularly annoying is this doublespeak about calling it predictable. Before the change, it was predicatbly eth0. Now, it's different on every different model. It's not doublespeak, the interfaces are named exactly according to where they are on the PCI bus. If you had two interfaces, they show up to the kernel in random order by time and sometimes eth0/eth1 are nto the same they were before the reboot. That may be true for PCI devices but not for USB ones. If you unplug a USB device and plug it back into the same port, it will get a different device number. The naming is more predictable, but it's not there yet. That doesn't sound right. If unplugging a USB net device and plugging it again *in the same port* results in a different device *name*, then it is a bug and should be reported; the description of the algorithm in [1] sounds like it should get always the same name for the same port, unless I'm misunderstanding something. Regards. [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n51 I've seen this happening once on a cheap laptop with a stripped down BIOS I can't even recall brand for, it had a kludge in the BIOS settings for hotplugging, turning it off, allowed the port to remain same, turning it on, some machine specific code gets executed and the kernel interprets the same port as different port Bad hardware, bad hardware settings, maybe missing exception for that particular hardware type in the code that determines the name... I'm not sure, I don't have the machine anymore - Samuli Later kernels *can mark interfaces predictable in a new form of metadata*, and udev = 209 can pick that information up, and then it won't do anykind of userspace renaming on it, since kernel has declared the interface name to be steady...predictable...always same, so I hope we are moving towards kernel assigning predictable names for all drivers and we can get rid of the userspace renaming of interfaces all together at some point I really believe this is a task for the kernel to provide predictable names, and all this userspace renaming is just a bandage we can hopefully soon rip off - Samuli
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 26/09/14 19:47, David W Noon wrote: On Fri, 26 Sep 2014 12:04:47 +0300, Samuli Suominen (ssuomi...@gentoo.org) wrote about Re: [gentoo-user] Re: udev (viable) alternatives ? (in 54252c2f.1030...@gentoo.org): [snip] Later kernels *can mark interfaces predictable in a new form of metadata*, and udev = 209 can pick that information up, and then it won't do anykind of userspace renaming on it, since kernel has declared the interface name to be steady...predictable...always same, so I hope we are moving towards kernel assigning predictable names for all drivers and we can get rid of the userspace renaming of interfaces all together I hope these kernel-assigned interface names are configurable, as I have been naming the interfaces on my machines with *mnemonic* names for many years now. [These are names like inet and lan for interfaces that connect the machine to the Internet or my LAN.] I certainly do not want to go back to eth0 and the like -- or worse still, udev's predictable names -- as these are not mnemonic in any way. Later kernel marks some drivers interface names predictable or stable, not sure which word is best to use here, and then udev won't rename it by default to anything. The kernel assigned name could be anything, and I doubt it's in the eth* namespace And they can still be renamed by custom rules, that won't change, it's just that they won't get renamed by *default* anymore
Re: [gentoo-user] Re: /dev/ttyUSB* group changed from uucp to root?
On 26/09/14 20:59, Mike Gilbert wrote: On Fri, Sep 26, 2014 at 12:12 PM, Grant Edwards grant.b.edwa...@gmail.com wrote: Which sets the group to 0 (root). The weird thing is that I don't know where that file came from. Dong an equery belongs doesn't show it belonging to any package. I do have dev-embedded/openocd installed, but it doesn't own that file... But, doing an emerge -C openocd removed the file /lib64/udev/rules.d/99-openocd.rules. udev rules get installed to /lib/udev/rules.d, not /lib64/udev/rules.d. Most Gentoo systems have a symlink at /lib pointing at /lib64, but equery does not look at this. It only looks at the contents of /var/db/pkg/*/*/CONTENTS, which would contain lib instead of lib64. That's why latest portage-utils supports: # qfile -b -v 99-openocd.rules The new -b argument allows to skip the directory. - Samuli
Re: [gentoo-user] udev (viable) alternatives ?
On 25/09/14 18:25, James wrote: Ok, So I have used eudev before, without issue before. Things are moving along so now I see an udev-215 upgrade to udev-261 on a system running lxde. I intend to migrate this system to lxqt in the next few weeks, after I build up a new workstation. So changing from udev-215 to eudev-1.10-r2 is as simple as unmerging the former and emerging the latter ? The sytem is not tweaked very much and still running a 3.13.6 kernel, for now. Any other caveats (short term) on switching udev to eudev? no support for kernel side predictable interface names where the naming should *really* be happening, eudev will always rename your interfaces with or without USE=rule-generator to be explicit, eudev will ignore /lib/udev/hwdb.d/20-net-ifname.hwdb, eudev will rename interfaces marked as predictable by the kernel metadata, as in, eudev doesn't contain this commit: http://cgit.freedesktop.org/systemd/systemd/commit/network/99-default.link?id=04b67d49254d956d31bcfe80340fb9df7ed332d3 in fact, from what I last checked, eudev's networking is at same level with udev-208, from time before the .link support at all eudev is really useful only for sys-libs/musl users at this time, but you are free to experiment with it! - Samuli
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 25/09/14 22:03, James wrote: Samuli Suominen ssuominen at gentoo.org writes: Any other caveats (short term) on switching udev to eudev? in fact, from what I last checked, eudev's networking is at same level with udev-208, from time before the .link support at all ah, back when ethernet defaulted to eth0 not enp5s0 ? nope, 208 was back when 80-net-name-slot.rules predictable rules were used which ignored kernel metadata for predictable networking i.e. the insufficient implementatition, which got replaced by 99-default.link and 80-net-link-setup.rules what you are referring is the buggy pre-udev-197 networking, which you can unfortunately still get with USE=rule-generator, it will keep renaming your interfaces despite kernel telling not to, so kernel drivers that mark eth0 as stable, might get renamed to eg. eth1 if you have 2 cards it's really messy, only 209 (and higher) handles things right, the new .link setup, with kernel naming support eudev is really useful only for sys-libs/musl users at this time, but you are free to experiment with it! so lilblue (Anthony's amd64 hardened gentoo) is the only candidate I can think of with musl? So I choose this, then profile must be set to: (eslect profile list): [16] hardened/linux/musl/amd64 I'd be better of with a fresh install of lilblue + musl + eudev is what you are really saying here? that's the only usecase for eudev currently, yes, otherwise you have no reason to switch
Re: [gentoo-user] emerge output: [ebuild UD ]
On 17/09/14 03:01, Michael Orlitzky wrote: On 09/16/2014 03:14 PM, Alan McKinnon wrote: For some reason xfce-power-manager-1.3.1 does not satisfy what the local install needs but 1.3.0 does. So portage wants to make it so. Version 1.3.1 was removed from the tree, leaving only 1.3.0 to satisfy XFCE_PLUGINS=battery/brightness. That's not it. Portage doesn't work like that. It's because he specifically keyworded 1.3.1 in package.keywords, instead using something smart like: xfce-extra/xfce4-power-manager- To get latest non-live version.
Re: [gentoo-user] emerge output: [ebuild UD ]
On 17/09/14 16:16, Alexander Kapshuk wrote: On Wed, Sep 17, 2014 at 9:27 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 17/09/14 03:01, Michael Orlitzky wrote: On 09/16/2014 03:14 PM, Alan McKinnon wrote: For some reason xfce-power-manager-1.3.1 does not satisfy what the local install needs but 1.3.0 does. So portage wants to make it so. Version 1.3.1 was removed from the tree, leaving only 1.3.0 to satisfy XFCE_PLUGINS=battery/brightness. That's not it. Portage doesn't work like that. It's because he specifically keyworded 1.3.1 in package.keywords, instead using something smart like: xfce-extra/xfce4-power-manager- To get latest non-live version. I'm not necessarily after the most recent non-live version of the package. I just didn't want lvm2 pulled in as my current setup has no use for it. What would you recommend doing, leave things as they are, or keyword the stanza you suggested? Thanks. Notice that I said _non_-live and the char in the line. I would use the stanza (as you said) because if 1.4.0 is not stabilized before something like 1.4.1 is added to tree, and 1.4.0 gets deleted, you are facing the same problem all over again. As in, xfce-extra/xfce4-power-manager- with the means I want latest non-live version.
Re: [gentoo-user] [OT] Linus Torvalds on systemd
On 17/09/14 23:43, Volker Armin Hemmann wrote: Am 17.09.2014 um 21:52 schrieb Canek Peláez Valdés: On Wed, Sep 17, 2014 at 2:27 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 17.09.2014 um 21:02 schrieb Canek Peláez Valdés: On Wed, Sep 17, 2014 at 1:36 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [snip] Now you use this to advertise for systemd? Systemd fanbois are becoming more and more desperate. So, systemd is used (or it has been announced that is going to be used) by default in all the major distributions, is available and working great in Gentoo, and many Gentoo users and developers use it happily. So, yeah, we are *really* desperate, obviously. Thanks for the laugh. Regards. you will stop laughing when redhatpoettering abandon systemd because it is 'fundamentally broken' and must be replaced with something else. Probably as soon as everybody got used to it. And if I guess correctly, pulseaudio will be the driving force behind it. Because history loves repetition. Sure Volker, whatever you say. I'm willing to bet the future stability of my desktop and server machines that your doomsday-scenario will not happen. Actually, I'm already betting on it. What are you willing to bet? Again, thanks for the laughs. You are a funny guy. Regards. I am not betting anything. But I want you to think about something: devfs was the best thing since sliced bread. As soon as everybody used it, it was broken and replaced. There was no problem with this development. hal was the best thing since sliced bread. As soon as everybody used it, it was broken and abandoned. That's untrue. HAL was responsibly replaced with UDisks. As in, when Gentoo got rid of sys-apps/hal, we made sure everything was ported to UDisks or that unported applications that were removed with sys-apps/hal, had a direct replacement available. It was a logical development, that's all. *kit? The same. FUD.
Re: [gentoo-user] Re: [OT] Linus Torvalds on systemd
On 18/09/14 03:12, Alec Ten Harmsel wrote: Mark David Dumlao wrote: The code is out there. Freely available. Both systemd and sysvinit. If you wanted to measure both, you could, literally, in the time it took since you first posted in this thread till now you could have measured several times and left mean comments about whichever system you hated the most. Unfortunately, the systemd guys keep screaming that systemd is faster, and burden of proof is on the party that's claiming something. It's not James'/Volker's responsibility to prove that systemd isn't faster. That said, you guys need to stop flaming. If anything, it's easy to dislike SysVInit because the init scripts it uses are piles of bash, compared to a Systemd init script that has a handful of systemd config. Is systemd starting to encompass too much? I think so, but who cares? If we want an init manager that reads systemd-like files but doesn't do anything else (hostnamectl, logging, udev, etc.), I guess we'll have to make one. Alec Notably Gentoo has never used entire SysV, only the init part, not the /etc.d/rc.d part So this POSIX sh script's are coming from dedicated *Gentoo* project, which is sys-apps/openrc Just clarifying
Re: [gentoo-user] Re: [OT] Linus Torvalds on systemd
On 18/09/14 07:52, Samuli Suominen wrote: Notably Gentoo has never used entire SysV, only the init part, not the /etc.d/rc.d part I meant /etc/rc.d of course. Typing error. Sorry.
Re: [gentoo-user] xscreensaver - error missing bc
On 14/09/14 18:46, Joseph wrote: I get a strange error when trying to emerge xscreensaver checking for bc... no configure: error: Your system doesn't have bc, which has been a standard part of Unix since the 1970s. Come back when your vendor has grown a clue. What is bc? It's calculator application and it's listed as a dependency in the xscreensaver ebuild in the official Portage tree: ssuominen@null ~/gentoo-x86/x11-misc/xscreensaver $ grep sys-devel/bc *.ebuild xscreensaver-5.29.ebuild:sys-devel/bc xscreensaver-5.30.ebuild:sys-devel/bc So no way to emerge xscreensaver without having sys-devel/bc getting installed first.
Re: [gentoo-user] blocker between openrc and procps
On 24/08/14 13:40, meino.cra...@gmx.de wrote:
J. Roeleveld jo...@antarean.org [14-08-24 12:36]:
On 24 August 2014 11:23:34 CEST, meino.cra...@gmx.de wrote:
Alan McKinnon alan.mckin...@gmail.com [14-08-24 10:32]:
On 24/08/2014 04:30, meino.cra...@gmx.de wrote:
hi,
How can I resolve this blocker:
(sys-process/procps-3.3.9::gentoo, installed) pulled in by
sys-process/procps required by (dev-db/mysql-5.5.39::gentoo,
installed)
sys-process/procps required by @system
(sys-apps/openrc-0.13.1::gentoo, ebuild scheduled for merge)
pulled in by
sys-apps/openrc required by @system
sys-apps/openrc required by @selected
sys-apps/openrc required by (virtual/service-manager-0::gentoo,
installed)
=sys-apps/openrc-0.12 required by
(net-misc/netifrc-0.2.2::gentoo, ebuild scheduled for merge)
Thank you very much in advance for any help!
There is no blocker there
--
Alan McKinnon
alan.mckin...@gmail.com
Hi Alan,
sorry, I missed some lines of text:
[blocks B ] sys-process/procps-3.3.9-r2
(sys-process/procps-3.3.9-r2 is blocking sys-apps/openrc-0.13.1)
Total: 109 packages (108 upgrades, 1 new), Size of downloads: 1,107,696
kB
Fetch Restriction: 1 package (1 unsatisfied)
Conflict: 2 blocks (1 unsatisfied)
Fetch instructions for dev-java/java-sdk-docs-1.7.0.60:
* Please download jdk-7u60-apidocs.zip from
*
http://www.oracle.com/technetwork/java/javase/documentation/java-se-7-doc-download-435117.html
* (agree to the license) and place it in /usr/portage/distfiles
* If you find the file on the download page replaced with a higher
* version, please report to the bug 67266 (link below).
* If emerge fails because of a checksum error it is possible that
* the upstream release changed without renaming. Try downloading the
file
* again (or a newer revision if available). Otherwise report this to
* http://bugs.gentoo.org/67266 and we will make a new revision.
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(sys-process/procps-3.3.9::gentoo, installed) pulled in by
sys-process/procps required by (dev-db/mysql-5.5.39::gentoo, installed)
sys-process/procps required by @system
(sys-apps/openrc-0.13.1::gentoo, ebuild scheduled for merge) pulled in
by
sys-apps/openrc required by @system
sys-apps/openrc required by @selected
sys-apps/openrc required by (virtual/service-manager-0::gentoo,
installed)
=sys-apps/openrc-0.12 required by (net-misc/netifrc-0.2.2::gentoo,
ebuild scheduled for merge)
Best regards,
mcc
Update procps to a later version.
Or update mysql if that specifically want that version.
--
Joost
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Procps is already at its newest version.
No, it's not.
eix -I procps
[I] sys-process/procps
Available versions: 3.3.6 3.3.8-r2 3.3.9 ~3.3.9-r1 ~3.3.9-r2 {+ncurses
nls selinux static-libs systemd test unicode}
3.3.9-r2 latest.
Installed versions: 3.3.9(03:38:35 08/24/14)(ncurses nls unicode
-static-libs -test)
3.3.9, not 3.3.9-r2, installed.
As in, you need to upgrade to 3.3.9-r2 to use openrc-0.13, because older
than 3.3.9-r2 have broken config file
reading, and won't work properly with openrc-0.13
So, simple solution:
# emerge -1 =sys-process/procps-3.3.9-r2
Re: [gentoo-user] Execute udev rule before net.* scripts
On 24/08/14 15:59, Grant wrote:
I'm trying to define names for my USB network interfaces keyed on the
interface location instead of the interface MAC address. This udev
rule renames one of them:
SUBSYSTEM==net, KERNEL==enp3s0u1, NAME=net0
But it doesn't work automatically at boot, I have to execute 'udevadm
trigger --action=add'. How can I execute that before the net.*
scripts at boot?
- Grant
I'm not 100% convinced that's the right syntax to use. See,
https://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=4chap=2#doc_chap4
Using your Own Names
Code Listing 4.2: Setting the lan0 name for the current eth0 interface
# vim /etc/udev/rules.d/76-net-name-use-custom.rules
# Second one uses ID_NET_NAME_PATH information, and 76- number to be between
# 75-net-*.rules and 80-net-*.rules
SUBSYSTEM==net, ACTION==add, ENV{ID_NET_NAME_PATH}==enp3s0u1, NAME=net0
Re: [gentoo-user] Execute udev rule before net.* scripts
On 24/08/14 20:05, Tom H wrote: On Sun, Aug 24, 2014 at 8:59 AM, Grant emailgr...@gmail.com wrote: I'm trying to define names for my USB network interfaces keyed on the interface location instead of the interface MAC address. This udev rule renames one of them: SUBSYSTEM==net, KERNEL==enp3s0u1, NAME=net0 But it doesn't work automatically at boot, I have to execute 'udevadm trigger --action=add'. How can I execute that before the net.* scripts at boot? enp3s0u1 isn't a kernel name; it's an ID_NET_NAME_PATH attribute. That's what came to my mind too, that's why I instructed him away from it. - Samuli
Re: [gentoo-user] re: sys-fs/lvm2 question
On 23/08/14 09:53, Canek Peláez Valdés wrote: On Sat, Aug 23, 2014 at 1:47 AM, Alexander Kapshuk alexander.kaps...@gmail.com wrote: On 08/22/2014 10:36 PM, Canek Peláez Valdés wrote: On Fri, Aug 22, 2014 at 1:56 PM, Alexander Kapshuk alexander.kaps...@gmail.com wrote: As I updated my system today, I noticed that 'sys-fs/lvm2' got updated amongst other packages as well. I don't use LVM on my system. If I understand it correctly, 'sys-fs/lvm2' is a required dependency for 'sys-fs/udisks/udisks-1.0.5-r1': equery d sys-fs/lvm2 * These packages depend on sys-fs/lvm2: sys-block/parted-3.1-r1 (device-mapper ? =sys-fs/lvm2-2.02.45) sys-boot/grub-2.00_p5107-r2 (device-mapper ? =sys-fs/lvm2-2.02.45) sys-fs/udisks-1.0.5-r1 (=sys-fs/lvm2-2.02.66) sys-fs/udisks-2.1.3 (cryptsetup ? sys-fs/lvm2[udev(+)]) equery -q u sys-block/parted | grep device-mapper -device-mapper equery -q u sys-boot/grub | grep device-mapper -device-mapper equery -q u '=sys-fs/udisks-1.0.5-r1' -debug +nls -remote-access $ equery -q u '=sys-fs/udisks-2.1.3' | grep cryptsetup -cryptsetup /usr/portage/sys-fs/udisks/udisks-1.0.5-r1.ebuild:17,24 COMMON_DEPEND==dev-libs/dbus-glib-0.100 snip =sys-fs/lvm2-2.02.66 What are my options, if I were to remove 'sys-fs/lvm2' altogether? Remove sys-fs/udisks:0, which depends unconditionally on LVM2; also, it's on life support, AFAIR. sys-fs/udisks:2 is actively maintained and it depends only conditionally on LVM2. What would you recommend doing about it? What does depend on sys-fs/udisks? What's the output from equery d sys-fs/udisks? Most applications switched to udisks-2, but some are still stuck with udisks-1 (XMBC, now Kodi, comes to mind). If an application that you absolutely need requires sys-fs/udisks:0, then you will need LVM2 also. Regards. Looks like I've got a couple of apps that do require udisks-1 to run: equery d sys-fs/udisks * These packages depend on sys-fs/udisks: gnome-base/gvfs-1.20.2 (udisks ? =sys-fs/udisks-1.97:2) gvfs depends on sys-fs/udisk:2, so this one doesn't need udisks-1. xfce-extra/xfce4-power-manager-1.3.0 (udisks ? sys-fs/udisks:0) What does xfce4-power-manager uses udisks for? You could try to emerge it with USE=-udisks and see if you miss some functionality. If you don't, you can get rid of udisks-1 and LVM2. Regards. xfce4-power-manager-1.3.0 and older uses UDisks 1.x for controlling disk spinning, like to reduce it xfce4-power-manager-1.3.1 and higher removed UDisks 1.x dependency and the spindown feature, supposedly it had issues and doesn't work with SSD anyway... anyways, upstream decision to not use udisks anymore so, i recommend upgrading to 1.3.1, adding it to package.keywords if required thanks, samuli
Re: [gentoo-user] a question about updating process
On 29/07/14 14:50, Alan McKinnon wrote: On 29/07/2014 13:45, behrouz khosravi wrote: Thanks every one. I guess I got it know ! And I must say that the way Gentoo is working now, is simple, no doubts. And I am surprised to hear that Gentoo is so strict to follow upstream. I guess it makes it the most vanilla flavored, And I really like it ! It also makes the Gentoo dev's life so much easier. For sure :) You do not want to get into maintaining custome patchsets for everything under the sun the way Ubuntu and RedHat do it And as a user, I wouldn't want some distribution maintainer messing with my packages in such a fundamental way (specially if there is an active upstream for it) I'd rather be made aware directly if some packages upstream decides to, for example, remove an feature from it, so I can then make informed decision like switch to another package
Re: [gentoo-user] modules.devname not found...
On 29/07/14 20:22, Neil Bothwick wrote:
On Tue, 29 Jul 2014 18:25:15 +0200, Jarry wrote:
* Creating list of required static device nodes for the current
kernel... Warning: /lib/modules/3.12.21-gentoo-r1/modules.devname not
found - ignor
What does it mean and how can I get rid of it?
By creating the missing file :)
Strange is, I do not have this message on any other system
(and I installed them the same way). All are updated, using
the same kernel. None of them is using modules, none of them
has /lib/modules/3.12.21-gentoo-r1/modules.devname and none
of them complains. Except this new one...
/lib/modules/${uname -r)/modules.devname is created by depmod -a.
Right, and if he is using monolitic kernel with CONFIG_MODULES=n in
kernel /usr/src/linux/.config,
with no modules at all, then he should remove 'kmod-static-nodes' init
script from the runlevels
to silence the warning
That is, if that's really true, otherwise use `depmod -a`
- Samuli
Re: [gentoo-user] Regular user can't mount/unmount mtpfs; root is OK
On 25/07/14 09:36, Walter Dnes wrote: On Fri, Jul 25, 2014 at 08:07:10AM +0300, Samuli Suominen wrote Install gnome-base/gvfs with USE=gphoto2 mtp and then use gvfs-mount to mount the device, because gvfs-mount will make use of your PolicyKit with ConsoleKit or systemd-logind authorization that allows mounting as a *local* and *normal* user. Then you don't need the mtpfs command, any group, any custom udev rules, ... Pulling in gnome-base/gvfs and media-libs/libgphoto2 isn't that big an issue. The question is... will I be able to mount from a straight text console, especially when X is not running? Semi-long answer Yes, if you have /etc/init.d/consolekit in your default runlevel, and sys-auth/consolekit built with USE=pam and sys-auth/pambase built with USE=consolekit, you get a PAM module called pam_ck_connector.so So, when you login to text console, pam_ck_connector.so kicks in and will tell PolicyKit you are a local user, it will show up in `ck-list-sessions` command as active = TRUE -line Then, when you run gvfs-mount from text console, it will query PolicyKit if you are allowed or not, and you are, since pam_ck_connector.so has done the job Short answer: Yes, everything related works from command line outside of X as well - Samuli
Re: [gentoo-user] Regular user can't mount/unmount mtpfs; root is OK
On 25/07/14 12:35, Samuli Suominen wrote: On 25/07/14 09:36, Walter Dnes wrote: On Fri, Jul 25, 2014 at 08:07:10AM +0300, Samuli Suominen wrote Install gnome-base/gvfs with USE=gphoto2 mtp and then use gvfs-mount to mount the device, because gvfs-mount will make use of your PolicyKit with ConsoleKit or systemd-logind authorization that allows mounting as a *local* and *normal* user. Then you don't need the mtpfs command, any group, any custom udev rules, ... Pulling in gnome-base/gvfs and media-libs/libgphoto2 isn't that big an issue. The question is... will I be able to mount from a straight text console, especially when X is not running? Semi-long answer Yes, if you have /etc/init.d/consolekit in your default runlevel, and sys-auth/consolekit built with USE=pam and sys-auth/pambase built with USE=consolekit, you get a PAM module called pam_ck_connector.so So, when you login to text console, pam_ck_connector.so kicks in and will tell PolicyKit you are a local user, it will show up in `ck-list-sessions` command as active = TRUE -line Then, when you run gvfs-mount from text console, it will query PolicyKit if you are allowed or not, and you are, since pam_ck_connector.so has done the job Short answer: Yes, everything related works from command line outside of X as well - Samuli ...and if you want to be able to use it as non-local user like via ssh from text console, then it needs /etc/polkit-1/rules.d/ file like 10-mtp.rules to give authozation there are examples for writing .rules if you google around, sorry I don't have time to go into that now
Re: [gentoo-user] Regular user can't mount/unmount mtpfs; root is OK
On 24/07/14 07:59, Walter Dnes wrote: I sent this a day or 2 ago, but it doesn't show up on the list for me. Apologies to anyone seeing a duplicate. I'm a total noobie at mtpfs/FUSE. My excellent adventure started yesterday when I got a clearout 7 tablet, and took a sample photo, and tried mounting the tablet... no /dev/sdb to be found anywhere. I went to Mr. Google for help, and found out that MTP is the new and improved way of doing things. So I installed mtpfs. It works great for root, but a regular user can't mount the tablet. The mtpfs command immediately returns to the command prompt, with no error message or any other info. The tablet is not mounted... [d531][waltdnes][~] mtpfs ~/tablet [d531][waltdnes][~] Before anyone asks... 1) Yes, I have enabled FUSE in the kernel. At first I hadn't, but I got a big red warning when I tried compiling mtpfs. I tweaked and rebuilt the kernel, and rebooted, then built mtpfs. 2) Yes, I am a member of plugdev... [d531][root][~] grep plugdev /etc/group plugdev:x:247:waltdnes,user2 3) This PC uses mdev rather than udev. Could that be the problem? I've figured out a kludge to get around it. This involves issuing a few commands as root. I've added them into a file in /etc/sudoers.d/ but I'd really rather prefer a cleaner solution. [d531][root][~] mtpfs -o allow_other /home/waltdnes/tablet Device 0 (VID=0bb4 and PID=2008) is UNKNOWN. Please report this VID/PID and the device model to the libmtp development team Android device detected, assigning default bug flags When I was finished, I tried... [d531][waltdnes][~] fusermount -u tablet fusermount: entry for /home/waltdnes/tablet not found in /etc/mtab I had to unmount as root... [d531][root][~] fusermount -u /home/waltdnes/tablet I experienced similar problems with simple-mtpfs, so that's not a solution either. Any ideas? Install gnome-base/gvfs with USE=gphoto2 mtp and then use gvfs-mount to mount the device, because gvfs-mount will make use of your PolicyKit with ConsoleKit or systemd-logind authorization that allows mounting as a *local* and *normal* user. Then you don't need the mtpfs command, any group, any custom udev rules, ...
Re: [gentoo-user] =media-gfx/blender-2.71 use flag constraints
On 08/07/14 09:23, List Reader wrote: Hello, I don't fully understand this packages use flag constraints. emerge -pqv =media-gfx/blender-2.71 http://bpaste.net/show/445090/ emerge --info =media-gfx/blender-2.71 http://bpaste.net/show/445091/ I have keyworded =dev-lang/python-3.4.0 in package.accept_keywords, but python_targets_python3_4 is still disabled. Do I need to manually install =dev-lang/python-3.4.0 in another slot? Thank you It means you have to add 'media-gfx/blender python_single_target_python3_4' to /etc/portage/package.use to enable Python 3.4 for this package
Re: [gentoo-user] Re: Systemd upower
On 05/06/14 08:23, Mick wrote: On Wednesday 04 Jun 2014 23:27:05 Samuli Suominen wrote: On 05/06/14 01:14, »Q« wrote: On Tue, 03 Jun 2014 22:06:07 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: The good news is that the version of upower prior to this decision still works fine and likely will for ages to come. That code has been bundled into a new package upower-pm-utils. Anyone that feels like doing it can now step up to the plate and continue the work upower was doing earlier. I don't understand the development status of upower-pm-utils. Is there someone either upstream or with Gentoo committed to maintaining it? No, nobody is actively working on it, it's the abandoned upstream git branch that used to be master before 0.99.0's release: Current sys-power/upower-pm-utils is same as latest code from http://cgit.freedesktop.org/upower/log/?h=0.9 And last commit is 2013 I might backport some fixes from git master over at some point later, but I won't do any promises Or is it a git branch created just to meet the current needs of non-systemd Gentoo users? It's to be considered as a temporary solution for applications that need the Hibernate and Suspend functionality from UPower for non-systemd users, applications like mate-session-manager, lxsession, uevt, and so forth Migrating to =sys-power/upower-0.99.0 is the recommended path to take if at all possible. It's possible for eg. Xfce users, because Xfce in ~arch integrated sys-power/pm-utils support directly for Hibernate and Suspend Also, GNOME 3.12 requires 0.99.0 Hi Samuli, Are you saying that as things stand it is a matter of time before a gentoo user will have to switch from openrc to systemd, if they want/need to continue using sleep and hibernate? For those tasks you mentioned... ...if other desktops don't migrate like Xfce, then something like: Switching to a) systemd, OR b) switching to Xfce (direct pm-utils support in session and power managers), OR c) switching to command line pm-* utilities directly from pm-utils ...might be inevitable And if Linux kernel does changes that break pm-utils, which haven't had a single commit since 2010 in upstream repository: Switching to a) systemd, OR, b) wait, no other possibilities Yes, that's really how poor the situation is, and don't shoot me, I'm only the messenger :-) - Samuli
Re: [gentoo-user] Re: Systemd upower
On 05/06/14 12:03, Mick wrote: On Thursday 05 Jun 2014 08:25:30 Samuli Suominen wrote: On 05/06/14 08:23, Mick wrote: Are you saying that as things stand it is a matter of time before a gentoo user will have to switch from openrc to systemd, if they want/need to continue using sleep and hibernate? For those tasks you mentioned... ...if other desktops don't migrate like Xfce, then something like: Switching to a) systemd, OR b) switching to Xfce (direct pm-utils support in session and power managers), OR c) switching to command line pm-* utilities directly from pm-utils ...might be inevitable And if Linux kernel does changes that break pm-utils, which haven't had a single commit since 2010 in upstream repository: Switching to a) systemd, OR, b) wait, no other possibilities Yes, that's really how poor the situation is, and don't shoot me, I'm only the messenger :-) Thanks Samuli, I don't shoot people, especially when they try to help me! :-) I use enlightenment on most machines and KDE on a couple of desktops, so I guess these would be the only two desktops that may be an issue for me. However, I had forgotten about the pm-* commands. I just tried: pm-is-supported --suspend-hybrid and didn't get anything ... what am I missing? null ssuominen # pm-is-supported --suspend null ssuominen # echo $? 0 null ssuominen # pm-is-supported --hibernate null ssuominen # echo $? 0 null ssuominen # pm-is-supported --suspend-hybrid null ssuominen # echo $? 0 see `man pm-is-supported`, this particular command is silent, and only returns return codes, and 0 means it succeeded - Samuli
Re: [gentoo-user] Systemd upower
On 05/06/14 14:11, Rich Freeman wrote: On Thu, Jun 5, 2014 at 2:34 AM, Greg Woodbury redwo...@gmail.com wrote: Unfortunately, the advocates and implementers made some major political choices when they (apparently deliberately) chose to put the systemd stuff in /usr/lib instead of /lib. It was pointed out that this abrogated certain parts of the FHS, forced those who would like to adopt it to *not* being able to continue using their machines they way they wished to (I.e. they had to choose between several potentially major changes to do so -- don't have a separate /usr or be forced to use a kernel initrd/initramfs method in order to do so.) My understanding is that the systemd developers intend for systemd to not be installed in /usr unless /lib and so on are symlinks to their counterparts in /usr (ie the /usr-merge is completed). Correct. As in, if you git clone system repository, and run ./autogen.sh on it, it will recommend options that will put systemd to /, not /usr And multiple systemd upstream developers think it's an bad idea to install systemd to /usr if the /usr-merge is not complete, Kay, Lennart, and others have said it out loud on ML and #systemd, Freenode So, it's entirely Gentoo systemd maintainers decision to install into /usr even without the /usr-merge I think the reason so much stuff is migrating to /usr is the sense that keeping things split up is becoming more hassle than it is worth due to all the vertical integration. If you have a bluetooth keyboard then you're going to be hard-pressed to use your system without /usr mounted. That is the standard example, but the sense is that this is the way the wind is blowing. Virtually every distro out there uses an initramfs anyway - we're a bit of an aberration in that it seems that using an initramfs is rare among Gentoo users. Just look at an initramfs as the new root filesystem. There really isn't anything you could do with a shell without /usr mounted that you can't do with a shell in an initramfs. That'd be accurate.
Re: [gentoo-user] Re: Systemd upower
On 05/06/14 13:47, Tom Wijsman wrote: On Thu, 5 Jun 2014 06:23:38 +0100 Mick michaelkintz...@gmail.com wrote: Are you saying that as things stand it is a matter of time before a gentoo user will have to switch from openrc to systemd, if they want/need to continue using sleep and hibernate? For them to have support for sleep and hibernate, someone needs to develop / maintain it in order to adapt to kernel API changes; as long as the only one doing this is systemd, you'll work towards only it being supported there in the future. Correct, and to name an example, pm-utils is still using the old wireless stack and 'wireless-utils' instead of 'iw' As in, pm-utils is using kernel options that are marked as DEPRECATED in the menuconfig, and DEPRECATED means they are going away at some point So it won't be long the package is broken for every machine that has wireless card I'm sure there are multiple other examples available, but this one pops up to mind immediately
Re: [gentoo-user] Systemd upower
On 05/06/14 14:39, Dutch Ingraham wrote: On 06/04/2014 08:02 PM, Samuli Suominen wrote: Gentoo doesn't have write access to ::mate-overlay, it's completely unofficial Gentoo developers are just as much users as you are for ::mate-overlay Enough said - Samuli Sorry, but this isn't just a MATE overlay problem. Once I made your suggested changes, the MATE mask change requests disappeared. What I did get was XFCE mask requirements: [snip] The following mask changes are necessary to proceed: (see package.unmask in the portage(5) man page for more details) # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =xfce-base/xfce4-session-4.10.1-r1 # required by virtual/udev-208-r2 # required by sys-power/upower-0.9.23-r3 # required by xfce-base/xfce4-session-4.10.1-r1[udev] # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =sys-apps/systemd-212-r5 # required by sys-apps/systemd-212-r5[-vanilla] # required by sys-power/upower-0.9.23-r3 # required by xfce-base/xfce4-session-4.10.1-r1[udev] # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =sys-apps/gentoo-systemd-integration-4 [snip] I had already emerge - C'd those two XFCE applications because, early in this process an equery depends upower had shown them to be dependent upon upower even after emerging upower-pm-utils. I have no confidence at this point that my particular problem is reasonably solvable, as I have been caught in this circle for three days now. There is no need to mask any Xfce packages, in fact, masking them would cause more blockers. So that output would be bogus, as it would include the wrong Xfce masks, and futhermore it's only end of the output, so it wouldn't tell the necessary information required for solving it anyway. Remove anykind of Xfce masks and post complete output, and don't forget to use the --tree flag (-t) to see what is pulling in what. That is, if you still want help solving the issue. - Samuli
Re: [gentoo-user] Systemd upower
On 05/06/14 15:17, Dutch Ingraham wrote: On 06/05/2014 08:00 AM, Samuli Suominen wrote: On 05/06/14 14:39, Dutch Ingraham wrote: On 06/04/2014 08:02 PM, Samuli Suominen wrote: Gentoo doesn't have write access to ::mate-overlay, it's completely unofficial Gentoo developers are just as much users as you are for ::mate-overlay Enough said - Samuli Sorry, but this isn't just a MATE overlay problem. Once I made your suggested changes, the MATE mask change requests disappeared. What I did get was XFCE mask requirements: [snip] The following mask changes are necessary to proceed: (see package.unmask in the portage(5) man page for more details) # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =xfce-base/xfce4-session-4.10.1-r1 # required by virtual/udev-208-r2 # required by sys-power/upower-0.9.23-r3 # required by xfce-base/xfce4-session-4.10.1-r1[udev] # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =sys-apps/systemd-212-r5 # required by sys-apps/systemd-212-r5[-vanilla] # required by sys-power/upower-0.9.23-r3 # required by xfce-base/xfce4-session-4.10.1-r1[udev] # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =sys-apps/gentoo-systemd-integration-4 [snip] I had already emerge - C'd those two XFCE applications because, early in this process an equery depends upower had shown them to be dependent upon upower even after emerging upower-pm-utils. I have no confidence at this point that my particular problem is reasonably solvable, as I have been caught in this circle for three days now. There is no need to mask any Xfce packages, in fact, masking them would cause more blockers. So that output would be bogus, as it would include the wrong Xfce masks, and futhermore it's only end of the output, so it wouldn't tell the necessary information required for solving it anyway. Remove anykind of Xfce masks and post complete output, and don't forget to use the --tree flag (-t) to see what is pulling in what. That is, if you still want help solving the issue. - Samuli I I've removed the XFCE masks. Note that mate-power-manager is masked. I see you didn't follow the recommendation of getting rid of the ::mate-overlay because I'm still seeing mate-base/mate::mate-overlay and more in the output I don't know how we could possible get forward if you don't follow-up on the already suggested instructions, no wonder you've been running circles. Uninstall mate-overlay, emerge -C mate mate-power-manager mate-session-manager and anything else you have installed from there. Let Portage pull them back in from the actual Portage tree.
Re: [gentoo-user] Systemd upower
On 04/06/14 15:15, Daniel Troeder wrote: Am 04.06.2014 13:22, schrieb Daniel Troeder: Am 04.06.2014 06:05, schrieb Samuli Suominen: On 04/06/14 05:17, Dutch Ingraham wrote: No, sys-fs/udev is not masked, but an update is indicated in the emerge above. That's a good catch, the MATE stuff is from the overlay. Unfortunately, the xfce stuff is not, so even if the overlay currency was an issue, I'll still be showing some dependencies. Try re-emerging on un-emerging the offending packages, like xfce4-session and xfce4-power-manager, it has helped some people, to refresh the .ebuild copy that is installed with the .ebuild copy from Portage - Samuli Thanks - that fixed it for me: # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager xfce-extra/xfce4-systemload-plugin # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager xfce-extra/xfce4-systemload-plugin Greetings Daniel BTW: I also had to unmerge gnome-base/gnome-control-center and gnome-base/gnome-settings-daemon and mask all gnome-* 3.10 Yes, GNOME 3.12 is the first desktop in Portage that is forcing =sys-power/upower-0.99.0, therefore GNOME 3.12 can't be installed together with sys-power/upower-pm-utils It's expected that more and more packages will start requiring =sys-power/upower-0.99.0, so this sys-power/upower-pm-utils, is to be considered as a temporary solution, specially considering it has no upstream anymore So, if package you need sys-power/upower-pm-utils for, doesn't migrate it's code like Xfce did and directly use sys-power/pm-utils, so that it allows 0.99.0 installation, the package is bound to die That's the whole point of this requirement for manual intervention of user, he needs to make an informed decision what route he wants to go -- like extreme route, such as switching desktops from LXDE to Xfce, and such (This reply is not directly aimed at you, but to whole thread, just trying to raise public awareness, because maybe it will get someone to actually contribute some code to improve the situation) - Samuli
Re: [gentoo-user] Systemd upower
On 04/06/14 15:21, Tanstaafl wrote: On 6/3/2014 1:08 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Jun 3, 2014 at 11:48 AM, Tanstaafl tansta...@libertytrek.org wrote: On 6/3/2014 11:10 AM, Canek Peláez Valdés can...@gmail.com wrote: Maybe. The thing is, this is going to keep happening, as more and more infrastructure migrates towards systemd. Perhaps a news item everytime it happens is unrealistic? Weren't you the one saying that those of us who were voicing concerns that systemd proponents were ultimately wanting to FORCE systemd on everyone were just scare-mongering conspiracy theorists? Who is forcing anything? I was specifically referring to your comment that: The thing is, this is going to keep happening, as more and more infrastructure migrates towards systemd. That comment right there - specifically the word *infrastructure* - screams to me 'we intend to take over the world'. And yes, as devs get lazier (decide to rely on systemd rather than build it to work independently of the init system), this will in fact result in *users* (read: those lacking the skills to code every program out there to work without systemd) eventually being *forced* to switch to systemd. You can still install GNOME without systemd from Portage using the USE=openrc-force (which needs to be unmasked using /etc/portage/profile/use.mask line like -openrc-force) And nobody is ever forced to do anything within Open Source, you always have the option to contibute code, or donate money to get someone else contribute the code Calling volunteers who work without paycheck lazy is just bad behavior That is simply the reality. You can ignore it if you like, but it doesn't change it. Forced is forced. That's what you and many others don't seem to understand: systemd is a *BETTER* implementation for basically *ALL* the hodgepodge of solutions that we had before in our plumbing layer. Time will tell, and you may even be right. The problem is, average users really don't have a way to prove this to themselves, all we see is the wailing and gnashing of teeth as stuff constantly *breaks* that *never* broke before. Nothing has been broken so far yet. People are just facing hard realities and noticing some packages have been abandoned for years, even before systemd became popular as it is now. You can't blame systemd, upower, and other developers for ditching such outdated code and using what they like as they code it for their application. - Samuli
Re: [gentoo-user] Systemd upower
On 04/06/14 15:58, Rich Freeman wrote: On Wed, Jun 4, 2014 at 8:21 AM, Tanstaafl tansta...@libertytrek.org wrote: And yes, as devs get lazier (decide to rely on systemd rather than build it to work independently of the init system), this will in fact result in *users* (read: those lacking the skills to code every program out there to work without systemd) eventually being *forced* to switch to systemd. That is simply the reality. You can ignore it if you like, but it doesn't change it. Forced is forced. Well, if your goal is to persuade people to change, I'd suggest taking that to the upower mailing list, since they're the ones who added the systemd requirement. General misconseption here, let me clarify a bit. Instead, UPower upstream simply dropped unmaintained pm-utils code since pm-utils has been abandoned for years and nobody picked it up during these years. So, UPower didn't add any systemd requiring code, they simply dropped Hibernate/Suspend capability, and left it to other programs (such as systemd). Notice how UPower 0.99.0 doesn't have anykind of systemd dependency. The package simply, by design, isn't a package that does Hibernate/Suspend anymore. Fact that OpenRC doesn't have Hibernate/Suspend support is due to problem in our end, nobody is working on such code for OpenRC, like there are people working on such code for systemd. The only thing Samuli did was give non-systemd users a workaround for an upstream problem, and the news clarifying this came out a bit late. I generally intend to switch over to systemd, but I for one would love for there to be the option to use alternatives. Simply wishing that won't make it happen, and since i don't really intend to use the alternatives it is a bit hard to get the motivation to help fork the world. That's just the way the wind seems to be blowing these days. Rich You are right as for rest of the mail goes. Nobody can possible expect me to suddently come up with Hibernate/Suspend patch for OpenRC myself. I can state that I have no plans to work on anything like that without getting paid for it, and propably not even then, as I suspect it would be too big task for me to take up. I have no intentions in picking up pm-utils maintainership either. I have no idea how people will do Hibernate/Suspend in the future without systemd, I suspect it will get harder and harder. If I were to buy a new laptop today, I'd propably install systemd on it, to get up-to-date code for those tasks. So yeah, only working with what upstreams provide as a distribution maintainer/packager, and people shouldn't try to dump this somehow on me. Fact that they have some fallback, like upower-pm-utils at all, is something they should be grateful instead. (I hope I didn't mess up quoting in this mail.)
Re: [gentoo-user] Systemd upower
On 04/06/14 16:47, Neil Bothwick wrote: On Wed, 04 Jun 2014 08:21:51 -0400, Tanstaafl wrote: And yes, as devs get lazier (decide to rely on systemd rather than build it to work independently of the init system), Reusing existing, proven code is not laziness, it is efficiency. Yes, they could code their own version, but all the time they spend coding and testing it will not be spent on the actual project, we all end up with an inferior product. Also, by adding to the software the uses systemd, or any other underlying code, the number of users/testers of that code increases. You seem to think the Upower devs simply decided to use systemd instead of doing it themselves. In fact, they were always using code, from either systemd or pm-utils. The fact that development stopped on pm-utils is neither the fault of the Upower or systemd people. They were reduced to a choice of one and you blame them for making the wrong choice? Well said.
Re: [gentoo-user] Systemd upower
On 04/06/14 20:11, Dutch Ingraham wrote:
On 06/04/2014 07:22 AM, Daniel Troeder wrote:
Am 04.06.2014 06:05, schrieb Samuli Suominen:
On 04/06/14 05:17, Dutch Ingraham wrote:
No, sys-fs/udev is not masked, but an update is indicated in the
emerge above. That's a good catch, the MATE stuff is from the overlay.
Unfortunately, the xfce stuff is not, so even if the overlay currency
was an issue, I'll still be showing some dependencies.
Try re-emerging on un-emerging the offending packages, like
xfce4-session and xfce4-power-manager,
it has helped some people, to refresh the .ebuild copy that is installed
with the .ebuild copy from
Portage
- Samuli
Thanks - that fixed it for me:
# emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
# emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
Greetings
Daniel
Unfortunately, this doesn't work for me. So let me re-cap: I have
4. masked virtual/udev-208-r2; that has not worked.
First, remove that mask. Masking it will certainly cause more blockers,
than solve them.
[ebuild N~] mate-extra/mate-power-manager-1.6.3::mate-overlay
USE=applet policykit -gnome-keyring -man {-test} 0 kB
[ebuild N~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
USE=ipv6 -debug -systemd 0 kB
see ::mate-overlay, it's presumably broken or outdated. stop using the
overlay and use MATE from Portage instead.
or you can mask the packages from overlay, the syntax is like:
/etc/portage/package.mask
mate-extra/mate-power-manager::mate-overlay
mate-base/mate-session-manager::mate-overlay
- Samuli
Re: [gentoo-user] Power management
On 04/06/14 21:44, Peter Humphrey wrote: Hello list, The current debate over upower and upower-pm-utils has got me thinking (yes, I know): is it possible to install Gentoo on a desktop or a mini-server without any PM at all? Of course. It's USE=-upower to make.conf and couple of /etc/portage/package.use entries, like for example 'xfce-base/xfce4-session -udev', as in, some packages use the generic USE flag 'udev' for pulling upower (which is, essentially, a udev helper) You may have to avoid some meta packages, like gnome-base/gnome, which are too greedy with their dependencies - Samuli
Re: [gentoo-user] Power management
On 04/06/14 22:27, Samuli Suominen wrote: On 04/06/14 21:44, Peter Humphrey wrote: Hello list, The current debate over upower and upower-pm-utils has got me thinking (yes, I know): is it possible to install Gentoo on a desktop or a mini-server without any PM at all? Of course. It's USE=-upower to make.conf and couple of /etc/portage/package.use entries, like for example 'xfce-base/xfce4-session -udev', as in, some packages use the generic USE flag 'udev' for pulling upower (which is, essentially, a udev helper) You may have to avoid some meta packages, like gnome-base/gnome, which are too greedy with their dependencies - Samuli This hint is meant for the too greedy meta packages: You can also create /etc/portage/profile/package.provided file with a entry like: sys-power/upower-0.9.23 Notice that the syntax of package.provided is different from other package.foo files, and it doesn't have the = in front, so it's really '$category/$package-$version' That will tell Portage you have UPower installed, where as you really don't - Samuli
Re: [gentoo-user] Re: Systemd upower
On 05/06/14 01:14, »Q« wrote: On Tue, 03 Jun 2014 22:06:07 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: The good news is that the version of upower prior to this decision still works fine and likely will for ages to come. That code has been bundled into a new package upower-pm-utils. Anyone that feels like doing it can now step up to the plate and continue the work upower was doing earlier. I don't understand the development status of upower-pm-utils. Is there someone either upstream or with Gentoo committed to maintaining it? No, nobody is actively working on it, it's the abandoned upstream git branch that used to be master before 0.99.0's release: Current sys-power/upower-pm-utils is same as latest code from http://cgit.freedesktop.org/upower/log/?h=0.9 And last commit is 2013 I might backport some fixes from git master over at some point later, but I won't do any promises Or is it a git branch created just to meet the current needs of non-systemd Gentoo users? It's to be considered as a temporary solution for applications that need the Hibernate and Suspend functionality from UPower for non-systemd users, applications like mate-session-manager, lxsession, uevt, and so forth Migrating to =sys-power/upower-0.99.0 is the recommended path to take if at all possible. It's possible for eg. Xfce users, because Xfce in ~arch integrated sys-power/pm-utils support directly for Hibernate and Suspend Also, GNOME 3.12 requires 0.99.0 - Samuli
Re: [gentoo-user] Systemd upower
On 05/06/14 02:15, Dutch Ingraham wrote:
On 06/04/2014 03:17 PM, Samuli Suominen wrote:
On 04/06/14 20:11, Dutch Ingraham wrote:
On 06/04/2014 07:22 AM, Daniel Troeder wrote:
Am 04.06.2014 06:05, schrieb Samuli Suominen:
On 04/06/14 05:17, Dutch Ingraham wrote:
No, sys-fs/udev is not masked, but an update is indicated in the
emerge above. That's a good catch, the MATE stuff is from the overlay.
Unfortunately, the xfce stuff is not, so even if the overlay currency
was an issue, I'll still be showing some dependencies.
Try re-emerging on un-emerging the offending packages, like
xfce4-session and xfce4-power-manager,
it has helped some people, to refresh the .ebuild copy that is installed
with the .ebuild copy from
Portage
- Samuli
Thanks - that fixed it for me:
# emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
# emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
Greetings
Daniel
Unfortunately, this doesn't work for me. So let me re-cap: I have
4. masked virtual/udev-208-r2; that has not worked.
First, remove that mask. Masking it will certainly cause more blockers,
than solve them.
[ebuild N~] mate-extra/mate-power-manager-1.6.3::mate-overlay
USE=applet policykit -gnome-keyring -man {-test} 0 kB
[ebuild N~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
USE=ipv6 -debug -systemd 0 kB
see ::mate-overlay, it's presumably broken or outdated. stop using the
overlay and use MATE from Portage instead.
or you can mask the packages from overlay, the syntax is like:
/etc/portage/package.mask
mate-extra/mate-power-manager::mate-overlay
mate-base/mate-session-manager::mate-overlay
- Samuli
Thanks everybody for your help. I've made the further suggested
changes, but I remain with the three hard blocks.
I've now spent about 7 hours over the last two days on this issue (about
2x the fresh install time), when all I wanted to do was a routine
update. I've reworked a large part of my system, adding a new
package.mask file and populating it with six packages.
I suppose its now time for an uninstall. Kind of disappointing; we are
told Gentoo is about choices, and in fact that's true. I made the
choice to use a pure openRC system. The last 7 hours of free time,
though, was spent trying, and ultimately failing, to correct a problem
not chosen, not wanted, and not invited.
The sine qua non is unarguably systemd. Even though my choice was to
not deploy it, apparently it takes a significant time commitment and/or
developer-level knowledge to choose to not use it. Quite the inelegant
end to my once-trusty OS.
Gentoo doesn't have write access to ::mate-overlay, it's completely
unofficial
Gentoo developers are just as much users as you are for ::mate-overlay
Enough said
- Samuli
Re: [gentoo-user] Systemd upower
On 05/06/14 02:25, Alon Bar-Lev wrote:
On Thu, Jun 5, 2014 at 2:15 AM, Dutch Ingraham s...@gmx.us wrote:
On 06/04/2014 03:17 PM, Samuli Suominen wrote:
On 04/06/14 20:11, Dutch Ingraham wrote:
On 06/04/2014 07:22 AM, Daniel Troeder wrote:
Am 04.06.2014 06:05, schrieb Samuli Suominen:
On 04/06/14 05:17, Dutch Ingraham wrote:
No, sys-fs/udev is not masked, but an update is indicated in the
emerge above. That's a good catch, the MATE stuff is from the overlay.
Unfortunately, the xfce stuff is not, so even if the overlay currency
was an issue, I'll still be showing some dependencies.
Try re-emerging on un-emerging the offending packages, like
xfce4-session and xfce4-power-manager,
it has helped some people, to refresh the .ebuild copy that is installed
with the .ebuild copy from
Portage
- Samuli
Thanks - that fixed it for me:
# emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
# emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
Greetings
Daniel
Unfortunately, this doesn't work for me. So let me re-cap: I have
4. masked virtual/udev-208-r2; that has not worked.
First, remove that mask. Masking it will certainly cause more blockers,
than solve them.
[ebuild N~] mate-extra/mate-power-manager-1.6.3::mate-overlay
USE=applet policykit -gnome-keyring -man {-test} 0 kB
[ebuild N~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
USE=ipv6 -debug -systemd 0 kB
see ::mate-overlay, it's presumably broken or outdated. stop using the
overlay and use MATE from Portage instead.
or you can mask the packages from overlay, the syntax is like:
/etc/portage/package.mask
mate-extra/mate-power-manager::mate-overlay
mate-base/mate-session-manager::mate-overlay
- Samuli
Thanks everybody for your help. I've made the further suggested
changes, but I remain with the three hard blocks.
I've now spent about 7 hours over the last two days on this issue (about
2x the fresh install time), when all I wanted to do was a routine
update. I've reworked a large part of my system, adding a new
package.mask file and populating it with six packages.
I suppose its now time for an uninstall. Kind of disappointing; we are
told Gentoo is about choices, and in fact that's true. I made the
choice to use a pure openRC system. The last 7 hours of free time,
though, was spent trying, and ultimately failing, to correct a problem
not chosen, not wanted, and not invited.
The sine qua non is unarguably systemd. Even though my choice was to
not deploy it, apparently it takes a significant time commitment and/or
developer-level knowledge to choose to not use it. Quite the inelegant
end to my once-trusty OS.
You are right, all I can say is that I am sorry we treat users like
that. We forget that our task is to ease deployment of upstream
projects to end users. What we experience is only the start of the
mess of having two separate contradictory layouts within stable tree,
without decent profile setups to protect users from pulling layout
they are not interested in.
We? The ::mate-overlay maintainers? You are involved in the
::mate-overlay development then?
Re: [gentoo-user] Systemd upower
On 05/06/14 03:22, Alon Bar-Lev wrote: This effected stable tree of Gentoo as well, pulling undesired different layout into stable is something that should have been avoided. It is about time we split the profiles, systemd is not option for people who runs openrc. Indeed, I support the idea of having separate systemd profiles too, could have simply dropped a package.mask entry in base/ then, and then counter-effected it in systemd profiles - Samuli
Re: [gentoo-user] re: sys-power/upower-pm-utils
On 03/06/14 14:30, J. Roeleveld wrote: Sounds like Samuli is being a pr*ck by forcing systemd on everyone now. A proper solution would have been to have the upower ebuild select systemd as a dependency ONLY when the systemd useflag is set. And depend on upower-pm-utils when it is not set. -- Joost First of all, you should check your tone and secondly, you are clearly not understanding the situation as you are oversimplifying a complex situation. For example, Xfce works on non-systemd systems with any of these UPower versions, so forcing upower-pm-utils with USE=-systemd would simply be bogus. If you are looking for a system that decides everything for you, and doesn't give you options what to install, you are propably better off using some binary distribution with smaller set of possibilities.
Re: [gentoo-user] re: sys-power/upower-pm-utils
On 03/06/14 14:48, J. Roeleveld wrote: Then the dependencies should have been fixed prior to making this stable. And that's exactly what happened.
Re: [gentoo-user] Systemd upower
On 03/06/14 18:10, Canek Peláez Valdés wrote: Maybe a news item explaining the switch of upower would help those who haven't blundered into this yet. Maybe. The thing is, this is going to keep happening, as more and more infrastructure migrates towards systemd. Perhaps a news item everytime it happens is unrealistic? I would expect Gentoo users to search for viable solutions by themselves, or asking for ways to solve it in the proper channels (like Silvio did). Yes, thank you. That's exactly how I've seen the situation, but am I expecting too much from our users? (I think I'll be forced to write up some minimal news item just to shut up the loud minority who can't be bothered to do anything themselfs, like even read package ChangeLogs if they stumble upon something manual.)
Re: [gentoo-user] Systemd upower
On 04/06/14 05:17, Dutch Ingraham wrote: No, sys-fs/udev is not masked, but an update is indicated in the emerge above. That's a good catch, the MATE stuff is from the overlay. Unfortunately, the xfce stuff is not, so even if the overlay currency was an issue, I'll still be showing some dependencies. Try re-emerging on un-emerging the offending packages, like xfce4-session and xfce4-power-manager, it has helped some people, to refresh the .ebuild copy that is installed with the .ebuild copy from Portage - Samuli
Re: [gentoo-user] Re: bluez 5 not connecting
On 28/05/14 21:42, Mick wrote: Hmm ... am I alone in this quest? See here, http://bugs.gentoo.org/show_bug.cgi?id=505362
Re: [gentoo-user] The writing on the wall ... sys-apps/util-linux
On 16/05/14 10:34, Mick wrote: I got this message after an update: * Messages for package sys-apps/util-linux-2.24.1-r2: * The mesg/wall/write tools have been disabled due to USE=-tty-helpers. I understand that wall has been moved from sys-apps/sysvinit to sys-apps/util- linux, but I am not sure why USE=-tty-helpers is disabled as a default. I couldn't find anything mentioning this in gentoo-dev, but this could just be my poor searching skills. Does anyone know? Because upstream util-linux disables tty-helpers by default regarding it's ./configure --help, as they are not deemed important commands - Samuli
Re: [gentoo-user] udev or Gentoo issue?
On 15/05/14 02:59, Grant wrote:
I'm having a problem starting the USB network interfaces properly on
one of my systems. I brought the problem to the udev list and they're
indicating that it's a Gentoo problem:
https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
Should I file a bug?
- Grant
Like pointed out in the upstream thread, it's either wrongly built
net-misc/dhcpcd (should be with USE=udev)
and if not using dhcpcd, it might be a bug in net-misc/netifrc's
/etc/init.d/net.lo depend() { } section --
it's possible it's missing dependency that forces /etc/init.d/udev start
first, specially if OpenRC is using parallel
startup
So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
OR bug in dependencies of netifrc's net.lo script
I'm starting two interfaces, one that uses dhcpcd and one that does
not. Both fail to start in the default runlevel until they are
hotplugged later. I do have dhcpcd built with USE=udev. The string
udev does not occur in /etc/init.d/net.lo so maybe that's the
problem? Please confirm that I should file a Gentoo bug for this.
- Grant
Try adding 'after udev' to net.lo's depend() { } section and see if that
helps, if it does, file a bug
saying so.
I added it like this and rebooted:
depend()
{
after udev
but the result was the same. I also have udev and udev-mount in the
sysinit runlevel.
It was more of an educated guess than 100% accurate knowledge. I can't
think of an another
way to force netifrc to behave, since it's not coded in C, and it can't
link to libudev, so...
However since you say *both*, even the one with dhcpcd fail to start,
before filing that bug,
see if disabling netifrc hotplugging works:
# ln -s /dev/null /etc/udev/rules.d/90-network.rules
Will that disable interface renaming or hotplugging? The system with
the issue is remote and if the interfaces aren't renamed or if
hotplugging doesn't happen then I won't be able to access the system
for up to 24 hours. That's fine and I'm happy to test stuff like this
anyway but I don't think this particular test will be informative
because:
It will disable the hotplugging, it means you *must* have the net.*
stuff added
to the default to runlevel yourself, like eg.
# rc-update add net.foobar default
They're in the default runlevel:
# rc-update|grep net.enp
net.enp0s20u2u1 | default
net.enp0s20u2u2 | default
I can disable hotplugging with rc_hotplug in rc.conf. Hotplugging is
actually disabled by default there and my network interfaces won't
start automatically that way.
I'm not 100% sure the rc_hotplug will also disable the 90-network.rules
triggered
interface hotplugging
Don't count on that
- Samuli
Re: [gentoo-user] udev or Gentoo issue?
On 14/05/14 15:42, Grant wrote:
I'm having a problem starting the USB network interfaces properly on
one of my systems. I brought the problem to the udev list and they're
indicating that it's a Gentoo problem:
https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
Should I file a bug?
- Grant
Like pointed out in the upstream thread, it's either wrongly built
net-misc/dhcpcd (should be with USE=udev)
and if not using dhcpcd, it might be a bug in net-misc/netifrc's
/etc/init.d/net.lo depend() { } section --
it's possible it's missing dependency that forces /etc/init.d/udev start
first, specially if OpenRC is using parallel
startup
So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
OR bug in dependencies of netifrc's net.lo script
I'm starting two interfaces, one that uses dhcpcd and one that does
not. Both fail to start in the default runlevel until they are
hotplugged later. I do have dhcpcd built with USE=udev. The string
udev does not occur in /etc/init.d/net.lo so maybe that's the
problem? Please confirm that I should file a Gentoo bug for this.
- Grant
Try adding 'after udev' to net.lo's depend() { } section and see if that
helps, if it does, file a bug
saying so.
I added it like this and rebooted:
depend()
{
after udev
but the result was the same. I also have udev and udev-mount in the
sysinit runlevel.
It was more of an educated guess than 100% accurate knowledge. I can't
think of an another
way to force netifrc to behave, since it's not coded in C, and it can't
link to libudev, so...
However since you say *both*, even the one with dhcpcd fail to start,
before filing that bug,
see if disabling netifrc hotplugging works:
# ln -s /dev/null /etc/udev/rules.d/90-network.rules
Will that disable interface renaming or hotplugging? The system with
the issue is remote and if the interfaces aren't renamed or if
hotplugging doesn't happen then I won't be able to access the system
for up to 24 hours. That's fine and I'm happy to test stuff like this
anyway but I don't think this particular test will be informative
because:
It will disable the hotplugging, it means you *must* have the net.*
stuff added
to the default to runlevel yourself, like eg.
# rc-update add net.foobar default
Re: [gentoo-user] udev or Gentoo issue?
On 14/05/14 15:42, Grant wrote:
I'm having a problem starting the USB network interfaces properly on
one of my systems. I brought the problem to the udev list and they're
indicating that it's a Gentoo problem:
https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
Should I file a bug?
- Grant
Like pointed out in the upstream thread, it's either wrongly built
net-misc/dhcpcd (should be with USE=udev)
and if not using dhcpcd, it might be a bug in net-misc/netifrc's
/etc/init.d/net.lo depend() { } section --
it's possible it's missing dependency that forces /etc/init.d/udev start
first, specially if OpenRC is using parallel
startup
So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
OR bug in dependencies of netifrc's net.lo script
I'm starting two interfaces, one that uses dhcpcd and one that does
not. Both fail to start in the default runlevel until they are
hotplugged later. I do have dhcpcd built with USE=udev. The string
udev does not occur in /etc/init.d/net.lo so maybe that's the
problem? Please confirm that I should file a Gentoo bug for this.
- Grant
Try adding 'after udev' to net.lo's depend() { } section and see if that
helps, if it does, file a bug
saying so.
I added it like this and rebooted:
depend()
{
after udev
hmm, try need udev instead of after udev, I keep forgetting their
difference
within parallel startup
Re: [gentoo-user] udev or Gentoo issue?
On 13/05/14 16:50, Grant wrote:
I'm having a problem starting the USB network interfaces properly on
one of my systems. I brought the problem to the udev list and they're
indicating that it's a Gentoo problem:
https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
Should I file a bug?
- Grant
Like pointed out in the upstream thread, it's either wrongly built
net-misc/dhcpcd (should be with USE=udev)
and if not using dhcpcd, it might be a bug in net-misc/netifrc's
/etc/init.d/net.lo depend() { } section --
it's possible it's missing dependency that forces /etc/init.d/udev start
first, specially if OpenRC is using parallel
startup
So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
OR bug in dependencies of netifrc's net.lo script
- Samuli
Re: [gentoo-user] udev or Gentoo issue?
On 13/05/14 16:58, Samuli Suominen wrote:
On 13/05/14 16:50, Grant wrote:
I'm having a problem starting the USB network interfaces properly on
one of my systems. I brought the problem to the udev list and they're
indicating that it's a Gentoo problem:
https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
Should I file a bug?
- Grant
Like pointed out in the upstream thread, it's either wrongly built
net-misc/dhcpcd (should be with USE=udev)
and if not using dhcpcd, it might be a bug in net-misc/netifrc's
/etc/init.d/net.lo depend() { } section --
it's possible it's missing dependency that forces /etc/init.d/udev start
first, specially if OpenRC is using parallel
startup
So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
OR bug in dependencies of netifrc's net.lo script
- Samuli
Or possibly you have the net.* stuff in wrong runlevels that makes them
start
too early?
There could also be a problem regarding netifrc's udev hotplugging, you can
disable it altogether by:
# ln -s /dev/null /etc/udev/rules.d/90-network.rules
The symlink to /dev/null in /etc/udev/rules.d/90-network.rules makes
/lib/udev/rules.d/90-network.rules
no-op. Notice this 90-network.rules is also part of net-misc/netifrc, so
don't make the mistake of
assuming this is a bug in any of udev, eudev or systemd
- Samuli
Re: [gentoo-user] udev or Gentoo issue?
On 14/05/14 03:18, Grant wrote:
I'm having a problem starting the USB network interfaces properly on
one of my systems. I brought the problem to the udev list and they're
indicating that it's a Gentoo problem:
https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18840.html
Should I file a bug?
- Grant
Like pointed out in the upstream thread, it's either wrongly built
net-misc/dhcpcd (should be with USE=udev)
and if not using dhcpcd, it might be a bug in net-misc/netifrc's
/etc/init.d/net.lo depend() { } section --
it's possible it's missing dependency that forces /etc/init.d/udev start
first, specially if OpenRC is using parallel
startup
So not really a udev bug, rather a misconfiguration in dhcpcd USE flags
OR bug in dependencies of netifrc's net.lo script
I'm starting two interfaces, one that uses dhcpcd and one that does
not. Both fail to start in the default runlevel until they are
hotplugged later. I do have dhcpcd built with USE=udev. The string
udev does not occur in /etc/init.d/net.lo so maybe that's the
problem? Please confirm that I should file a Gentoo bug for this.
- Grant
Try adding 'after udev' to net.lo's depend() { } section and see if that
helps, if it does, file a bug
saying so.
It was more of an educated guess than 100% accurate knowledge. I can't
think of an another
way to force netifrc to behave, since it's not coded in C, and it can't
link to libudev, so...
However since you say *both*, even the one with dhcpcd fail to start,
before filing that bug,
see if disabling netifrc hotplugging works:
# ln -s /dev/null /etc/udev/rules.d/90-network.rules
And if that helps, then file a bug saying so.
One or the another, bug is propably needed in anycase.
Re: [gentoo-user] Why is udev now having USE (-openrc%*)
On 10/05/14 09:43, Mick wrote: On Friday 09 May 2014 23:25:06 Neil Bothwick wrote: On Fri, 9 May 2014 21:56:45 +0100, Mick wrote: What is the meaning of this change? [ebuild U ] sys-fs/udev-212-r1 [208] USE=acl firmware-loader gudev introspection kmod -doc (-selinux) -static-libs (-openrc%*) 2,660 kB It means the openrc USE flag is no longer used. From the Changelog: Punt USE=openrc and always pull in sys-fs/udev-init-scripts to match behavior of sys-apps/systemd's ebuild. Thanks Neil, Does this mean that openrc and systemd are now aligned with regards to udev related init-scripts? It only means udev-init-scripts is now always pulled in as a dependency, with no functionality changes whatsoever Just ignore it, and move on
Re: [gentoo-user] cpufrequtils can't find expected /sys/devices/system/cpu/cpufreq
cpufreqd, cpufrequtils are both dead packages for years now, it's propably cpupower you want instead, the only package getting updated for constantly changing paths in /sys On 24/04/14 09:27, Walter Dnes wrote: I'm finishing up on installing Gentoo on a laptop. I tried testing cpufrequtils, and ran into problems... [aa1][root][/usr/src/linux] /etc/init.d/cpufrequtils start * Caching service dependencies ... [ ok ] * Running cpufreq-set --governor conservative -- ... /usr/libexec/cpufrequtils-change.sh: line 26: cd: /sys/devices/system/cpu/cpufreq: No such file or directory [ !! ] * ERROR: cpufrequtils failed to start I found some promising-looking threads on forums.gentoo.org, but the forum gives... phpBB : Critical Error Could not connect to the database ...so that wasn't any help. Am I missing some kernel setting? Note that I'me running mdev instead of udev. Could that be the problem?
[gentoo-user] Stabilization of netifrc-0.2.2, extra testers wanted
Extra testers requested for netifrc-0.2.2 stabilization, also, if you know a reason this shouldn't go stable, like regression from 0.1, speak up now. See, http://bugs.gentoo.org/507070 (I'm purposely special casing this package over others like this.) - Samuli
Re: [gentoo-user] Stabilization of netifrc-0.2.2, extra testers wanted
On 08/04/14 04:27, Michael Orlitzky wrote: On 04/07/2014 04:08 PM, Samuli Suominen wrote: Extra testers requested for netifrc-0.2.2 stabilization, also, if you know a reason this shouldn't go stable, like regression from 0.1, speak up now. See, http://bugs.gentoo.org/507070 (I'm purposely special casing this package over others like this.) The bug says be careful!, but what sort of trouble should we expect? I don't think you should really expect anything, it's just that we have no intrested in breaking peoples networking... Personally I'm worried about users with alternative /bin/sh symlinks, pointing to something else than bash, like to dash, but that worry could be misguided too. - Samuli
Re: [gentoo-user] CONFIG_USB_SUSPEND: is not set when it should be
On 19/03/14 04:22, Joseph wrote: I'm getting a message from sys-fs/udisks ERROR: setup CONFIG_USB_SUSPEND: is not set when it should be. WARN: setup I checked my kernel config there is not such options: CONFIG_USB_SUSPEND It's only checked for older kernels than 3.10 by the 'kernel_is lt 3 10' version check in the ebuild: $ grep SUSPEND *.ebuild udisks-1.0.5.ebuild:kernel_is lt 3 10 CONFIG_CHECK+= ~USB_SUSPEND #331065, #477278 udisks-2.1.3.ebuild:kernel_is lt 3 10 CONFIG_CHECK+= ~USB_SUSPEND #331065, #477278 And you can use / button in kernel's menuconfig to search for it However, it's propably time to upgrade kernel into something newer than 3.9'ish?
Re: [gentoo-user] python-updater: updating cracklib forever...
http://bugs.gentoo.org/503648 for stabilization of 2.9.1 which has been migrated to the new python eclasses, should solve many of the python related cracklib problems
Re: [gentoo-user] more bluetooth troubles with 5.14
On 03/03/14 21:21, cov...@ccs.covici.com wrote: Mick michaelkintz...@gmail.com wrote: On Sunday 02 Mar 2014 13:05:10 cov...@ccs.covici.com wrote: I don't even have any /etc/bluetooth/rfcomm.conf. What do you have in your /etc/conf.d/bluetooth? This is mine: = # Bluetooth configuraton file # Bind rfcomm devices (allowed values are true and false) RFCOMM_ENABLE=true # Config file for rfcomm RFCOMM_CONFIG=/etc/bluetooth/rfcomm.conf = Also, /etc/init.d/bluetooth has a dependency on rfcomm, so it starts it first. I need rfcomm for tethering, but I don't know if it is necessary for your needs. Is your rfcomm running? I did pair, trust and connect with bluetoothctl. Are you using bluetooth5 -- I never had these problems till the upgrade to 5. The device is pretty close to the computer and it does show up on the scan from hcitool. No, my bluetooth devices are rather ancient, so I don't know if my set up would work with blutooth 5.0 and in any case I don't seem to have bluetoothctl. Which program provides it now? I can't fine bluez-utils in portage. I think they may have changed things, in bluetooth 4, I think there was a separate package, now all seems to be in bluez package. Maybe hcidump is still separate. If you have bluez 4, the agent is simple-agent and would not work on 5 -- they changed the apis. correct, bluez-utils was part of bluez 3
Re: [gentoo-user] custom boost in /usr/local = problem with libkolabxml, libixion
On 01/03/14 13:23, Kacper Kopczyński wrote: Hello list, I've installed newest boost into /usr/local - it's a custom installation and not via emerge/portage. Today, after upgrading system, I've found that I need to use emerge --update --newuse --deep --with-bdeps=y @world to rebuild some dependencies. In the process of recompiling I first noticed this strange thing: checking for Boost headers version = 1.36.0... yes checking for Boost's header version... 1_55 Portage installed boost is 1.52, my custom installed one is 1.55. Then after a few seconds I saw this: x86_64-pc-linux-gnu-g++ -DPACKAGE_NAME=\libixion\ -DPACKAGE_TARNAME=\libixion\ -DPACKAGE_VERSION=\0.5.0\ -DPACKAGE_STRING=\libixion\ 0.5.0\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\libixion\ -DVERSION=\0.5.0\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -DHAVE_STDLIB_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BOOST=1 -DHAVE_BOOST_UNORDERED_MAP_HPP=1 -DHAVE_MDDS_RECTANGLE_SET_HPP=1 -DHAVE_MDDS_MIXED_TYPE_MATRIX_HPP=1 -DHAVE_MDDS_MULTI_TYPE_VECTOR_TRAIT_HPP=1 -DHAVE_BOOST_SYSTEM_ERROR_CODE_HPP=1 -DHAVE_BOOST_THREAD_HPP=1 -DHAVE_BOOST_PROGRAM_OPTIONS_HPP=1 -I. -I../include -I../lib/libixion/libixion.la -D_REENTRANT -DMDDS_HASH_CONTAINER_BOOST -D__IXION_BUILDING_DLL -g -Os -fvisibility=hidden -O2 -pipe -march=native -c -o ixion_sorter-sort_input_parser.o `test -f 'sort_input_parser.cpp' || echo './'`sort_input_parser.cpp /bin/sh ../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -Wl,-O1 -Wl,--as-needed -o ixion-parser ixion_parser-ixion_parser.o ixion_parser-model_parser.o libixion/libixion-0.6.la -lboost_thread-mt -lboost_system-mt -pthread -lboost_program_options-mt libtool: link: x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -Wl,-O1 -Wl,--as-needed -o .libs/ixion-parser ixion_parser-ixion_parser.o ixion_parser-model_parser.o -pthread libixion/.libs/libixion-0.6.so -lboost_thread-mt -lboost_system-mt -lboost_program_options-mt -pthread libixion/.libs/libixion-0.6.so: undefined reference to `boost::thread::start_thread_noexcept()' libixion/.libs/libixion-0.6.so: undefined reference to `boost::thread::join_noexcept()' collect2: error: ld returned 1 exit status make[2]: *** [ixion-parser] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/var/tmp/portage/dev-libs/libixion-0.5.0/work/libixion-0.5.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/dev-libs/libixion-0.5.0/work/libixion-0.5.0/src' make: *** [all-recursive] Error 1 * ERROR: dev-libs/libixion-0.5.0::gentoo failed (compile phase): ...so it failed because it tried to use my custom boost... I think. To be sure that this is because of this I moved /usr/local/lib and /usr/local/include to /root and another compilation of this library went fine. After doing so I runned revdep-rebuild and it had to recompile libkolabxml because it was linked to boost in /usr/local/lib. So here is my question: If libreoffice does need boost to compile, and I compiled libreoffice after I installed boost to /usr/local, then why it was able to use correct version of boost (from /usr not /usr/local)? Libreoffice is just an example - there are many other programs that depend on boost, and the boost.thread library is very popular one. libkolabxml at version 1.0.1 libixion at version 0.5.0 Should I create a bug for these two libraries or this is expected behaviour? -- Kacper Kopczyński There are multiple factors in play, some per package ./configure scripts add -I/usr/local/include so that headers are picked up from there by default, if compiler alone doesn't have that in it's default search path already. There are -L/usr/local/lib added by some, and /usr/local/lib in /etc/ld.so.conf What I'm really trying to say is that you can't install boost safely into /usr/local/lib and include, but you should put it in it's own directory outside of compilers or ld.so's scope, like for example, /home/username/boost, and then when you want something to use it, point the package to search it from there using package specific configure flags and environment variables like LD_LIBRARY_PATH, PKG_CONFIG_PATH, and so forth Bottom line is, It's not a bug you can file to Gentoo's bugzilla, it is expected behavior
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 28/02/14 08:47, Stroller wrote: On Wed, 26 February 2014, at 8:29 pm, Walter Dnes waltd...@waltdnes.org wrote: … * Netscape (under AOL) aimed at becoming a pseudo-OS on top of Windows. We know how that turned out. You appear to be underestimating it - whilst the AOL suite was hated by many of those forced to use it (I guess in the late 90's or early 00's), it is / was so massively popular with grannies that it is still available today. Dial-up division is still AOL's most profitable division, earning them $500m per year,[1] and I would attribute the popularity of the AOL desktop suite to this. I've seen this profitability attributed to misinformed customers who don't know they no-longer need AOL now they have DSL, but having been told by a number of people that all they want out of their computer is their AOL, I find it had to agree with that characterisation. AOL's desktop suite has certainly not been a failure for the company. Stroller. [1] http://www.technobuffalo.com/2013/02/18/aol-dial-up-profits/ This must be a US -only thing since I've never even heard of AOL desktop/suite before, even while lived through the 90's and the bulletin board times (as being a SysOp myself ;-)
Re: [gentoo-user] Peeve - finding kernel config options
On 27/02/14 19:24, Dan Johansson wrote: On 26.02.2014 22:24, Poison BL. wrote: On Wed, Feb 26, 2014 at 2:58 PM, Tanstaafl tansta...@libertytrek.org wrote: Hello all, This is for those of use who to choose to roll our kernels by hand... So, am I missing something? Given the most recent gentoo news item: # eselect news read 10 2014-02-25-udev-upgrade Title Upgrade to =sys-fs/udev-210 AuthorSamuli Suominen ssuomi...@gentoo.org Posted2014-02-25 Revision 1 The options CONFIG_FHANDLE and CONFIG_NET are now required in the kernel. Whenever kernel config options are provided like this, it would be nice if time was taken to provide the path to where they are found. I had to find the first one (CONFIG_FHANDLE) by: 1. grepping .config, seeing it wasn't enabled, 2. running make menuconfig and searching for 'FHANDLE', 3. seeing it is located in 'General setup', 4. scouring the General setup options, finding no 'FHANLDE' anywhere, 5. finding something in all lowercase named 'open by fhanlde syscalls', 6. enabling this option, saving the modified config, 7. confirming it is now enabled by grepping .config again Sheesh. Really? Would be nice if the news item had something like CONFIG_FHANDLE (General setup 'open by fhandle syscalls') and CONFIG_NET (still don't know which one this is??) Wackadoo... When I search FHANDLE in menuconfig I get: │ Symbol: FHANDLE [=y] │ Type : boolean │ Prompt: open by fhandle syscalls │ Location: │ (1) - General setup │ Defined at init/Kconfig:235 │ Selects: EXPORTFS [=y] │ Selected by: GENTOO_LINUX_INIT_SYSTEMD [=y] GENTOO_LINUX [=y] GENTOO_LINUX_UDEV [=y] This clearly states that the prompt you're looking for is a line that says open by fhandle syscalls under General setup Sure, it's not the absolute simplest interface (i.e. it doesn't give a 'enable this' in the search results) but it does give all the necessary information about a given option to find it (as well as dependencies and their current states, etc). The most likely reason the news item doesn't list the specific prompt text (or even the category) is that, across even sub release versions of the kernel those are prone to change (and, at times, drastically) while the actual CONFIG_name option tends to be fairly static through time once it exists (even when superseded by new toys, i.e. older IDE/ATA/ATAPI options vs newer PATA options). But if you press 1 in the example above you will jump directly to the menu item. Clue -- (1) Regards, Seriously, I've known / for years and have had no issues finding anything myself, but this small information is still news to me. Nice one. - Samuli
Re: [gentoo-user] Peeve - finding kernel config options
On 27/02/14 21:49, Samuli Suominen wrote: On 27/02/14 19:24, Dan Johansson wrote: On 26.02.2014 22:24, Poison BL. wrote: On Wed, Feb 26, 2014 at 2:58 PM, Tanstaafl tansta...@libertytrek.org wrote: Hello all, This is for those of use who to choose to roll our kernels by hand... So, am I missing something? Given the most recent gentoo news item: # eselect news read 10 2014-02-25-udev-upgrade Title Upgrade to =sys-fs/udev-210 AuthorSamuli Suominen ssuomi...@gentoo.org Posted2014-02-25 Revision 1 The options CONFIG_FHANDLE and CONFIG_NET are now required in the kernel. Whenever kernel config options are provided like this, it would be nice if time was taken to provide the path to where they are found. I had to find the first one (CONFIG_FHANDLE) by: 1. grepping .config, seeing it wasn't enabled, 2. running make menuconfig and searching for 'FHANDLE', 3. seeing it is located in 'General setup', 4. scouring the General setup options, finding no 'FHANLDE' anywhere, 5. finding something in all lowercase named 'open by fhanlde syscalls', 6. enabling this option, saving the modified config, 7. confirming it is now enabled by grepping .config again Sheesh. Really? Would be nice if the news item had something like CONFIG_FHANDLE (General setup 'open by fhandle syscalls') and CONFIG_NET (still don't know which one this is??) Wackadoo... When I search FHANDLE in menuconfig I get: │ Symbol: FHANDLE [=y] │ Type : boolean │ Prompt: open by fhandle syscalls │ Location: │ (1) - General setup │ Defined at init/Kconfig:235 │ Selects: EXPORTFS [=y] │ Selected by: GENTOO_LINUX_INIT_SYSTEMD [=y] GENTOO_LINUX [=y] GENTOO_LINUX_UDEV [=y] This clearly states that the prompt you're looking for is a line that says open by fhandle syscalls under General setup Sure, it's not the absolute simplest interface (i.e. it doesn't give a 'enable this' in the search results) but it does give all the necessary information about a given option to find it (as well as dependencies and their current states, etc). The most likely reason the news item doesn't list the specific prompt text (or even the category) is that, across even sub release versions of the kernel those are prone to change (and, at times, drastically) while the actual CONFIG_name option tends to be fairly static through time once it exists (even when superseded by new toys, i.e. older IDE/ATA/ATAPI options vs newer PATA options). But if you press 1 in the example above you will jump directly to the menu item. Clue -- (1) Regards, Seriously, I've known / for years and have had no issues finding anything myself, but this small information is still news to me. Nice one. - Samuli Someone just pointed out to me at IRC this was introduced only at Linux = 3.8'ish (he wasn't entirely sure) So, it's relatively new, I suppose that'd explain it
Re: [gentoo-user] Peeve - finding kernel config options
On 27/02/14 22:33, Neil Bothwick wrote: On Thu, 27 Feb 2014 18:24:50 +0100, Dan Johansson wrote: But if you press 1 in the example above you will jump directly to the menu item. Clue -- (1) Damn you, why didn't you let us in on this secret year ago? because Linux 3.8'ish wasn't released year ago yet? :p
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16/02/14 18:41, Alan McKinnon wrote: On 16/02/2014 17:46, Tanstaafl wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc I don't know much about systemd, I do know openrc. Thus far, the only real actual benefit I have seen of systemd that is a real issue that really affects me is consolekit. It's not exactly the best piece of software out there, comparable to HAL and how it was replaced by udev. So systemd replaces and fixes consolekit by providing logind. ConsoleKit works just fine for the features it advertises to have, where as HAL never did, so I really don't know what you are referring to?
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16/02/14 23:28, Alan McKinnon wrote: On 16/02/2014 20:11, Samuli Suominen wrote: On 16/02/14 18:41, Alan McKinnon wrote: On 16/02/2014 17:46, Tanstaafl wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc I don't know much about systemd, I do know openrc. Thus far, the only real actual benefit I have seen of systemd that is a real issue that really affects me is consolekit. It's not exactly the best piece of software out there, comparable to HAL and how it was replaced by udev. So systemd replaces and fixes consolekit by providing logind. ConsoleKit works just fine for the features it advertises to have, where as HAL never did, so I really don't know what you are referring to? It's a poor design. It's also unmaintained currently. How long has it been since Debian decided to go with systemd? Like, three? So, up until three days ago I would have disagreed since despite original upstream ditching ConsoleKit, it was still being maintained by Debian and Gentoo maintainers (me) and last release, 0.4.6, was in fact a result of that. But still, the fact that there is no more active development, doesn't mean it's obsolete. It still works fine as it ever did and there has been no need to cut any of it's features for any reason. Since logind works only on systemd, ConsoleKit is nothing less than what dhcp-client is to dhcpcd. So, it's definately not 'deprecated', or 'obsolete'. I call it 'mature'. Many BSDs still use it, and with Xfce upstream including a OpenBSD developer, and Xfce's commitment to keeping it working with BSDs in otherway too, I'm not worried about it becoming one of these nasty words of 'unmaintained', 'deprecated', 'obsolete' and co. even if I didn't do the legwork myself. So no, we don't get to blame ConsoleKit for any of this what has been happening. Take my word for it, it's not going to go anywhere from Portage anyday soon. But OK, it's a bit off-topic to this thread, I'm just getting ugly itch when people are so eager to call it anything else than mature despite it still working fine. - Samuli
Re: [gentoo-user] [poll] What is your session state?
On 10/02/14 00:43, walt wrote:
Recent threads about consolekit vs logind(systemd) have made me curious, so
I've been studying...
A few of us have had recent problems with things like plugging USB sticks,
which once worked transparently but now require root privileges.
I've discovered that my own such problems are caused by this:
$loginctl show-session 1 (I have only one session, cleverly named '1')
Id=1
Timestamp=Sun 2014-02-09 07:18:32 PST
TimestampMonotonic=389744251
VTNr=1
TTY=/dev/tty1
Remote=no
Service=login
Scope=session-1.scope
Leader=426
Audit=1
Type=tty
Class=user
Active=no = should be 'yes'
State=online === should be 'active'
Users of consolekit, don't feel neglected. You should try this instead:
$ck-list-sessions
Session1:
unix-user = '1001'
realname = '(null)'
seat = 'Seat2'
session-type = ''
active = FALSE(correct because I'm ssh'd into a remote box)
x11-display = ':0'
x11-display-device = '/dev/tty2'
display-device = '/dev/tty1'
remote-host-name = ''
is-local = FALSE
on-since = '2014-02-09T22:00:10.750312Z'
login-session-id = '1'
Canek explained that the reason my session is not 'active' is that I'm
not using a Display Manager (gdm kdm lightdm), which talks to logind or
consolekit and vouches for my physical presence at the local keyboard.
However, when I do the same thing on arch linux (as a virtualbox guest)
I see that my session (running gnome) is 'active' and I have no trouble
powering off the virtual machine as an unprivileged user.
Any ideas how I can fix it?
BTW, this helped me to understand some of the buzzwords I used above:
http://www.freedesktop.org/wiki/Software/systemd/multiseat/
sys-auth/pambase with USE=consolekit or USE=systemd brings in
pam_ck_connector.so (ConsoleKit) or pam_systemd.so (systemd)
is required in login to get the initial active session:
ConsoleKit or systemd-logind starts during boot - user logins to tty1
- PAM triggers pam_ck_connector.so or pam_systemd.so - and now you
have one
initial session, second one is started after 'startx' and the
login-session-id is the key knowing it's the same user now in X11,
instead of console since
it changes the first session inactive (since it knows you now started
X11 and are no longer in console) and activates the newly started one in X11
however display managers with *built-in* CK or logind support are
special, and more straightforward and directly talk to CK or logind, and
thus, work
somewhat more easily by skipping many possible problems
maybe you can somehow do it with GDM so that remote session shows
active, i don't know about that, but what you can do is write your own
polkit
rules like:
Put the following content to file: /etc/polkit-1/rules.d/51-local.rules
polkit.addAdminRule(function(action, subject) {
return [unix-group:wheel];
});
Now users in group wheel should be able to do anything, this is also
in man 8 polkit
Re: [gentoo-user] Re: KDE slow / console-kit-daemon POLKIT_IS_AUTHORITY failed
On 19/01/14 23:31, Neil Bothwick wrote: On Sat, 18 Jan 2014 23:45:00 +, Mick wrote: This thread confused me. I have this in my system and I have not changed the permissions from when it was installed: ls -la /usr/libexec/dbus-daemon-launch-helper -rws--x--- 1 root messagebus 322984 Jun 22 2013 /usr/libexec/dbus-daemon- launch-helper Is the suid bit dangerous and if so what is the alternative? Should there be a bug filed on it? I think what Samuli was trying to say was that the suid bit is dangerous if you give global execute permissions to the file, because then anyone exactly. my bad with the wording earlier.
Re: [gentoo-user] ttyS0 - ownership as root:dialout
On 20/01/14 18:45, Alan McKinnon wrote: On 01/20/14 18:30, Joseph wrote: After upgrade to systemd my /dev/ttyS0 shows up as: root:dialout ownership and permission 600 When I change as root manually to: chown uucp:dialout /dev/ttyS0 chmod 666 /dev/ttyS0 after restart it goes back to previous setting: root:dialout 600 How to change it? My VituralBox complain and will not start with owner: root:dialout /dev/ttyS0 It's a udev rule. Mine looks like this, tweak yours $ grep -r uucp /lib/udev/rules.d/ /lib/udev/rules.d/50-udev-default.rules:KERNEL==tty[A-Z]*[0-9]|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*, GROUP=uucp You'd put your file in /etc/udev/rules.d/, not in /lib/ as above, that's the as-shipped location for defaults right, we change 'dialout' to 'uucp' within sys-fs/udev's ebuild because it has always been uucp in Gentoo. the dialout group is Fedora thing. looks like systemd's ebuild is failing to do so :/
Re: [gentoo-user] Re: KDE slow / console-kit-daemon POLKIT_IS_AUTHORITY failed
On 16/01/14 19:39, Neil Bothwick wrote: On Thu, 16 Jan 2014 10:19:22 -0600, Canek Peláez Valdés wrote: Helmut is still using consolekit. Are you still using consolekit? Yes, it's the default for kdm so it is enabled on both computers. I don't think it will be the default for much longer; it's unmaintained code which sooner or later will start to bitrot. Unless someone steps in and starts taking care of it. Quite likely, but for now it is the default and in use on both systems in question. I have no idea if consolekit is relevant here, but Canek has been telling us that consolekit is abandonware and we should stop depending on it. That's part of the drive to put everything in systemd, which I do not use. Fact is, nobody is maintaining ck; from its homepage[1]: ConsoleKit is currently not actively maintained. The focus has shifted to the built-in seat/user/session management of Software/systemd called systemd-logind! That's what I was paraphrasing above. I checked the latest status on that page before replying. That message has been there for months; in general ck kinda still works, although it never really solved the problem of properly tracking user sessions, which is why everybody involved with it quickly jumped ship to logind, where the problem is properly solved. The issue for many is that logind is so closely tied to systemd. However, as the interfaces in the stack evolves, unmaintained code like ck will simply stop to work. ConsoleKit uses dbus heavily, and with the introduction of kdbus[2] and the inevitable changes that will happen to dbus, combined with nobody taking care of ck, I don't think it will keep working much longer. That's a reasonable prediction. Ubuntu and Debian (now that is seriously discussing which modern init system to use) have been discussing an alternative, API compatible implementation of logind, but I don't know if it has got nowhere. I think that has more future than ck, but again, nobody (AFAIK) has stepped in and do the heavy coding. Leaving aside my concerns about systemd, I am not happy with the all eggs in one basket direction things seem to be taking. Whatever happened to tolls doing one job and doing it well? Independently, though, I think is safe to say that ConsoleKit is a dead end. In the future, most probably. but right now it is the preferred option for KDM. Right, only GDM (the display manager for GNOME) has dropped ConsoleKit support so far, that I know, in versions 3.8 and later So other than GNOME, ConsoleKit is still a go -- thus, compatible with OpenRC based system For KDE it might be something else than dbus-glib that needs a recompile, I'd imagine something like kdelibs or polkit-kde-agent, or both It could be something else too, but setting the suid bit on dbus-daemon-launch-helper is stupidest idea ever, that *really* allows anyone to gain root However if you run a machine with single user and no open ports on the machine whatsoever, the attack vector is propably very small, but I still wouldn't do it - Samuli
Re: [gentoo-user] Do I require static nodes?
On 27/11/13 12:22, Daniel Pielmeier wrote: 2013/11/27 Chris Stankevitz chrisstankev...@gmail.com mailto:chrisstankev...@gmail.com Hello, Portage recently told me this: * You need to add kmod-static-nodes to the sysinit runlevel for * kernel modules to have required static nodes! * Run this command: * rc-update add kmod-static-nodes sysinit Will you please help me parse this statement? Interpretation A: * You need to add kmod-static-nodes to the sysinit runlevel Interpretation B: * If your kernel modules require static nodes, then you need to add * kmod-static-nodes to the sysinit runlevel Q1: Is it A or B (or C...)? Q2: If it's B, then how do I determine whether or not my kernel modules require static nodes? I also had trouble to interpret the message and because I was lazy I just added the kmod-static-nodes to the sysinit runlevel. After searching a bit I found that this was added due to bug #477856, but reading this as well as the release notes for kmod I am still not sure if this is needed in any case or just if there is a modular kernel etc. I am cc'ing one of the kmod maintainers maybe he can explain what is meant exactly. @Samuli: You have added the elog message to kmod-14-r1. Can you please give some more information about when kmod-static-nodes is required to be in the sysinit runlevel? Thanks in advance. If you have, for example, fuse as a kernel module, then you need kmod-static-nodes in sysinit to get /dev/fuse and such Also, if you have ALSA drivers like snd_seq_... as modules, then you need kmod-static-nodes in sysinit to get /dev/snd/seq to appear with correct permissions So leaving kmod-static-nodes out, on a system that has modules, can be dangerous because it's very hard to know offhand whatkind of /dev entries the modules will create, those two I mentioned are just the 2 most common cases, there are hundreds of cases more Adding it to sysinit runlevel on a system with modules is recommended (if not even mandatory) And adding it to sysinit runlevel on a system with NO modules whatsoever is also safe, then the init script will simply do nothing and you can ignore anykind of [!!] it might print on boot So you can leave it out, if you use static kernel with NO modules whatsover, if you REALLY want to supress one [!!] cosmetic error during boot that takes like no time whatsover to the boot time So basically... just always add it... It's automatically added for new installs already...
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 21/10/13 05:34, Walter Dnes wrote: On Sun, Oct 20, 2013 at 05:03:51PM +0300, Samuli Suominen wrote That's a bridge we will cross when there is a bridge to be crossed, but from top of my head: We will maintain a minimal patchset that reverts the offending code. As in, that's nothing to be worried about before it happens. That's not always possible, e.g. GNOME 3.8. Yes, but it was Gentoo Gnome Teams decision to keep packaging Gnome after they (I mean, GNOME upstream) introduced systemd hard dependency instead of switching to eg. MATE, or helping out with Xfce, etc, and sticking to the distribution default (OpenRC) And then it's yours (I mean, users) decision to keep on using Gnome despite of it As we were talking about core, like kernel and part of the userland boot process, I'm just trying to say that Gnome is not important part of the core system, it's just one of the desktops among others, despite of it's past (and current) popularity Now I have to admit I'm biased, I used to use GNOME 2.x in past but I've been with Xfce for years now, so I can only imagine what hardcore GNOME users think of all this, if the same thing happened to Xfce, I'd very very much pissed off -- to a point I'd rip out whole systemd support out of the code and package it with limited functionality rather than introducing systemd harddep
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 21/10/13 08:31, Daniel Campbell wrote: On 10/20/2013 09:34 PM, Walter Dnes wrote: On Sun, Oct 20, 2013 at 05:03:51PM +0300, Samuli Suominen wrote That's a bridge we will cross when there is a bridge to be crossed, but from top of my head: We will maintain a minimal patchset that reverts the offending code. As in, that's nothing to be worried about before it happens. That's not always possible, e.g. GNOME 3.8. I think that's an exception to the rule. I mean, upstream deliberately chose to depend on systemd/logind and whatnot. In such a situation there's literally no way to fix it without a fork, and I doubt Gentoo as an organization is interested in that. well said
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 20/10/13 09:34, Daniel Campbell wrote: On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote: Am 19.10.2013 17:02, schrieb Daniel Campbell: On 10/17/2013 11:27 PM, Mark David Dumlao wrote: https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign Not sure if I read that just right... but since nobody is doing cgroup management besides systemd, in practice the cgroups implementation in Linux wasn't very consistent. So since systemd is doing it, their work is helping shape the kernel's cgroups api? Interesting... From my perspective it looks like systemd developers are trying to push their ideas into the kernel, almost like they intend to merge systemd *with* the kernel. from what I read in the article cgroups are a mess and are cleaned up anyway. The only real user of cgroups at the moment is systemd. Others are welcome to make use of cgroups too. But in the current state nobody blames them for not jumping in. No complaints here in improving something, but consider the source is all I'm saying. If systemd is the only implementation of cgroups and their developers are working on cgroup support in the kernel, it spells calamity given their history of evangelism and zealotry. well, going over some old ml threads on fedora mailing lists all I could find was that Poettering and Sievers DID listen and DID make changes if the demand was high enough. Sure, I dislike systemd. Sure what happened with udev was a dick move. But their 'zealotry' is a lot less developed than the zealotry of those who exploded about using an 'init-thingy' in the future. I'd say their zealotry is less loud and more persistent. Their way is best, UNIX (and its philosophy) is outmoded, people are thinking 30 years behind where we are, etc etc etc. Those who have separate /usr and blame systemd for pushing them to use an initramfs aren't seeing the real problem (upstreams not putting things where they belong, FHS no longer *really* being worked on, generally just the filesystem being played with like a toy) I truly wish I understood why a single userland program and its developers are being given the keys to an entire subsystem of the kernel. they aren't. Of the people who have committed to the cgroup subsystem of the kernel, how many are not members of the systemd, GNOME, or Red Hat projects? I'll let that speak for itself. Their changes to udev have proven to be a headache for users, yes? which ones? Persistent NIC naming, for starters. The former maintainer's idea to merge with systemd (which was influenced by Mr. Poettering in the first place) when the two are completely separate pieces of software that do two completely different jobs, and various other troubles with udev 175 that one can Google for and find tons of results. I can't find anything that would be true. Can you point out some? A lot of FUD[1] and outright lies coming from people, who, for example, don't like systemd. [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt I know for a fact udev-208 is a full replacement for udev-171 in terms that both work on same kernels, same libcs, and so forth. That's why 171 is no longer in Portage, because it's completely useless from users (and developers) point of view. Adjusting some configs and enabling some kernel options that have been around for a long time is just part of normal maintenance process, that's what we have admins for.
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 20/10/13 12:24, Daniel Campbell wrote: On 10/20/2013 02:37 AM, Samuli Suominen wrote: On 20/10/13 09:34, Daniel Campbell wrote: On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote: Am 19.10.2013 17:02, schrieb Daniel Campbell: On 10/17/2013 11:27 PM, Mark David Dumlao wrote: https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign Not sure if I read that just right... but since nobody is doing cgroup management besides systemd, in practice the cgroups implementation in Linux wasn't very consistent. So since systemd is doing it, their work is helping shape the kernel's cgroups api? Interesting... From my perspective it looks like systemd developers are trying to push their ideas into the kernel, almost like they intend to merge systemd *with* the kernel. from what I read in the article cgroups are a mess and are cleaned up anyway. The only real user of cgroups at the moment is systemd. Others are welcome to make use of cgroups too. But in the current state nobody blames them for not jumping in. No complaints here in improving something, but consider the source is all I'm saying. If systemd is the only implementation of cgroups and their developers are working on cgroup support in the kernel, it spells calamity given their history of evangelism and zealotry. well, going over some old ml threads on fedora mailing lists all I could find was that Poettering and Sievers DID listen and DID make changes if the demand was high enough. Sure, I dislike systemd. Sure what happened with udev was a dick move. But their 'zealotry' is a lot less developed than the zealotry of those who exploded about using an 'init-thingy' in the future. I'd say their zealotry is less loud and more persistent. Their way is best, UNIX (and its philosophy) is outmoded, people are thinking 30 years behind where we are, etc etc etc. Those who have separate /usr and blame systemd for pushing them to use an initramfs aren't seeing the real problem (upstreams not putting things where they belong, FHS no longer *really* being worked on, generally just the filesystem being played with like a toy) I truly wish I understood why a single userland program and its developers are being given the keys to an entire subsystem of the kernel. they aren't. Of the people who have committed to the cgroup subsystem of the kernel, how many are not members of the systemd, GNOME, or Red Hat projects? I'll let that speak for itself. Their changes to udev have proven to be a headache for users, yes? which ones? Persistent NIC naming, for starters. The former maintainer's idea to merge with systemd (which was influenced by Mr. Poettering in the first place) when the two are completely separate pieces of software that do two completely different jobs, and various other troubles with udev 175 that one can Google for and find tons of results. I can't find anything that would be true. Can you point out some? A lot of FUD[1] and outright lies coming from people, who, for example, don't like systemd. [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt I know for a fact udev-208 is a full replacement for udev-171 in terms that both work on same kernels, same libcs, and so forth. That's why 171 is no longer in Portage, because it's completely useless from users (and developers) point of view. Adjusting some configs and enabling some kernel options that have been around for a long time is just part of normal maintenance process, that's what we have admins for. Do you know the design consequences of opt-in versus opt-out? I'll keep this short: When evolving a codebase, new behavior for core parts of the system should not be pushed or forced on users. If you must, keep the old behavior around as a default and allow users to try the new thing by explicitly opting in. The new naming in whichever udev started the mess did it the exact opposite (and wrong) way. It's not forced upon you. You received a news item that had instructions on howto assign names you want, like lan0, internet1, wireless3, and so forth. And it also described howto turn off udev from completely renaming the devices, to keep kernel assigned names. What they did was they dropped the *broken* feature called 'persistent rule_generator' which never worked correctly, and in race conditions still flipped eth0 - eth1 around -- that was a *security* flaw that *needed* to go. It would have gone even without providing the alternative of providing biosdevname -like new name optionality to the users. Kernel and kernel drivers are designed in a way it's not supported to flip in-place kernel names and udev tried to workaround that. https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html While editing and updating configs is a normal part of system maintenance, turning a system on its head and screwing it out of network accessibility until the new default
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 20/10/13 13:47, Daniel Campbell wrote: On 10/20/2013 04:55 AM, Samuli Suominen wrote: On 20/10/13 12:24, Daniel Campbell wrote: On 10/20/2013 02:37 AM, Samuli Suominen wrote: On 20/10/13 09:34, Daniel Campbell wrote: On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote: Am 19.10.2013 17:02, schrieb Daniel Campbell: On 10/17/2013 11:27 PM, Mark David Dumlao wrote: https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign Not sure if I read that just right... but since nobody is doing cgroup management besides systemd, in practice the cgroups implementation in Linux wasn't very consistent. So since systemd is doing it, their work is helping shape the kernel's cgroups api? Interesting... From my perspective it looks like systemd developers are trying to push their ideas into the kernel, almost like they intend to merge systemd *with* the kernel. from what I read in the article cgroups are a mess and are cleaned up anyway. The only real user of cgroups at the moment is systemd. Others are welcome to make use of cgroups too. But in the current state nobody blames them for not jumping in. No complaints here in improving something, but consider the source is all I'm saying. If systemd is the only implementation of cgroups and their developers are working on cgroup support in the kernel, it spells calamity given their history of evangelism and zealotry. well, going over some old ml threads on fedora mailing lists all I could find was that Poettering and Sievers DID listen and DID make changes if the demand was high enough. Sure, I dislike systemd. Sure what happened with udev was a dick move. But their 'zealotry' is a lot less developed than the zealotry of those who exploded about using an 'init-thingy' in the future. I'd say their zealotry is less loud and more persistent. Their way is best, UNIX (and its philosophy) is outmoded, people are thinking 30 years behind where we are, etc etc etc. Those who have separate /usr and blame systemd for pushing them to use an initramfs aren't seeing the real problem (upstreams not putting things where they belong, FHS no longer *really* being worked on, generally just the filesystem being played with like a toy) I truly wish I understood why a single userland program and its developers are being given the keys to an entire subsystem of the kernel. they aren't. Of the people who have committed to the cgroup subsystem of the kernel, how many are not members of the systemd, GNOME, or Red Hat projects? I'll let that speak for itself. Their changes to udev have proven to be a headache for users, yes? which ones? Persistent NIC naming, for starters. The former maintainer's idea to merge with systemd (which was influenced by Mr. Poettering in the first place) when the two are completely separate pieces of software that do two completely different jobs, and various other troubles with udev 175 that one can Google for and find tons of results. I can't find anything that would be true. Can you point out some? A lot of FUD[1] and outright lies coming from people, who, for example, don't like systemd. [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt I know for a fact udev-208 is a full replacement for udev-171 in terms that both work on same kernels, same libcs, and so forth. That's why 171 is no longer in Portage, because it's completely useless from users (and developers) point of view. Adjusting some configs and enabling some kernel options that have been around for a long time is just part of normal maintenance process, that's what we have admins for. Do you know the design consequences of opt-in versus opt-out? I'll keep this short: When evolving a codebase, new behavior for core parts of the system should not be pushed or forced on users. If you must, keep the old behavior around as a default and allow users to try the new thing by explicitly opting in. The new naming in whichever udev started the mess did it the exact opposite (and wrong) way. It's not forced upon you. You received a news item that had instructions on howto assign names you want, like lan0, internet1, wireless3, and so forth. And it also described howto turn off udev from completely renaming the devices, to keep kernel assigned names. What they did was they dropped the *broken* feature called 'persistent rule_generator' which never worked correctly, and in race conditions still flipped eth0 - eth1 around -- that was a *security* flaw that *needed* to go. It would have gone even without providing the alternative of providing biosdevname -like new name optionality to the users. Kernel and kernel drivers are designed in a way it's not supported to flip in-place kernel names and udev tried to workaround that. https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html Like I mentioned in a prior e-mail, the change didn't affect me when
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 20/10/13 17:01, Tanstaafl wrote: On 2013-10-20 9:02 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 20/10/13 13:47, Daniel Campbell wrote: Like I mentioned in a prior e-mail, the change didn't affect me when it was pushed, and doesn't affect me now. I did recently have to reinstall Gentoo, however (note, going from testing to stable isn't fun ;p), and noticed it when I found Gentoo ships with systemd-udev instead of eudev. Yep, no plans on changing the default sys-fs/udev to anything else, no reason to. To be clear - you are saying that the new default init system for a new gentoo install is systemd? No, I'm saying the default /dev manager in Gentoo has been sys-fs/udev and will be sys-fs/udev When did this happen? I thought that OpenRC was still the default? It is. Perhaps the next time I need to install Gentoo, I'll find a way to get eudev on there before even the first proper boot and avoid the problem altogether. It's true that sys-fs/eudev restored the *broken* rule_generator from old sys-fs/udev, you can get it by USE=rule-generator. But it's lot saner to keep using sys-fs/udev and just write custom rules to rename interfaces based on MACs to like lan*, internet* so all in all, currently, using sys-fs/eudev doesn't make sense unless you are experimenting/developing for it. The problem with this is, what happens if (or maybe *when*?) the systemd maintainers make a change that then breaks udev for anything but systemd? That's a bridge we will cross when there is a bridge to be crossed, but from top of my head: We will maintain a minimal patchset that reverts the offending code. As in, that's nothing to be worried about before it happens.
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 20/10/13 17:01, Tanstaafl wrote: It's true that sys-fs/eudev restored the *broken* rule_generator from old sys-fs/udev, you can get it by USE=rule-generator. But it's lot saner to keep using sys-fs/udev and just write custom rules to rename interfaces based on MACs to like lan*, internet* so all in all, currently, using sys-fs/eudev doesn't make sense unless you are experimenting/developing for it. The problem with this is, what happens if (or maybe *when*?) the systemd maintainers make a change that then breaks udev for anything but systemd? To continue my previous reply. That has already happened once. That's why we implemented /dev tmpfiles.d support for OpenRC 0.12, that's why =sys-apps/kmod-15 is now requiring =sys-apps/openrc-0.12. So it's case-by-case basis.
Re: [gentoo-user] re: automounting removable drives
On 08/10/13 20:19, Alexander Kapshuk wrote: On 10/07/2013 11:45 PM, victor romanchuk wrote: On 10/07/2013 11:36 PM, Alexander Kapshuk wrote: Thanks for your responses. I'm sorry I forgot to mention that I do have xfce4-mount-plugin installed. box0=; equery list '*xfce*'|grep mount xfce-extra/xfce4-mount-plugin-0.6.4 But I still can't auto-mount my removable drives. So I thought that perhaps some further configuration had to be done. That question still remains, how do I do it? Thanks. hi, you need to emerge just one package: xfce-extra/thunar-volman (it may pull some dependencies); it does what you asked for victor Thanks for your response. To save further confusion, which is something I should have done right from the word go, here's a list of all the xfce packages I have installed on my system: box0=; equery list '*xfce*' * Searching for *xfce* ... [IP-] [ ] dev-util/xfce4-dev-tools-4.10.0:0 [IP-] [ ] x11-terms/xfce4-terminal-0.4.8:0 [IP-] [ ] x11-themes/gtk-engines-xfce-3.0.1-r200:0 [IP-] [ ] x11-themes/gtk-engines-xfce-3.0.1-r300:3 [IP-] [ ] xfce-base/libxfce4ui-4.10.0:0 [IP-] [ ] xfce-base/libxfce4util-4.10.0:0 [IP-] [ ] xfce-base/xfce4-appfinder-4.10.0-r1:0 [IP-] [ ] xfce-base/xfce4-meta-4.10:0 [IP-] [ ] xfce-base/xfce4-panel-4.10.0-r1:0 [IP-] [ ] xfce-base/xfce4-session-4.10.0-r1:0 [IP-] [ ] xfce-base/xfce4-settings-4.10.0:0 [IP-] [ ] xfce-extra/xfce4-mixer-4.10.0:0 [IP-] [ ] xfce-extra/xfce4-mount-plugin-0.6.4:0 [IP-] [ ] xfce-extra/xfce4-notifyd-0.2.2:0 [IP-] [ ] xfce-extra/xfce4-sensors-plugin-1.2.5:0 [IP-] [ ] xfce-extra/xfce4-weather-plugin-0.8.3:0 [IP-] [ ] xfce-extra/xfce4-xkb-plugin-0.5.4.3:0 xfce-base/thunar needs to have USE=udev enabled and xfce-extra/thunar-volman must be installed i don't see thunar-volman in your list there futhermore authorization from polkit/consolekit must be working, so you must see 'active = TRUE' line when you run `ck-list-sessions` in your Xfce's Terminal as a normal user, see this thread (first post of it): http://forums.gentoo.org/viewtopic-t-858965-start-0.html and like said, xfce4-mount-plugin is irrelevant, and `mount` command shouldn't be used at all for udisks maintained removable devices, instead `udisksctl mount` should be used as a normal user if you really want to mount from commandline
Re: [gentoo-user] re: automounting removable drives
On 08/10/13 21:55, Alexander Kapshuk wrote: On 10/08/2013 09:21 PM, Samuli Suominen wrote: On 08/10/13 20:19, Alexander Kapshuk wrote: On 10/07/2013 11:45 PM, victor romanchuk wrote: On 10/07/2013 11:36 PM, Alexander Kapshuk wrote: Thanks for your responses. I'm sorry I forgot to mention that I do have xfce4-mount-plugin installed. box0=; equery list '*xfce*'|grep mount xfce-extra/xfce4-mount-plugin-0.6.4 But I still can't auto-mount my removable drives. So I thought that perhaps some further configuration had to be done. That question still remains, how do I do it? Thanks. hi, you need to emerge just one package: xfce-extra/thunar-volman (it may pull some dependencies); it does what you asked for victor Thanks for your response. To save further confusion, which is something I should have done right from the word go, here's a list of all the xfce packages I have installed on my system: box0=; equery list '*xfce*' * Searching for *xfce* ... [IP-] [ ] dev-util/xfce4-dev-tools-4.10.0:0 [IP-] [ ] x11-terms/xfce4-terminal-0.4.8:0 [IP-] [ ] x11-themes/gtk-engines-xfce-3.0.1-r200:0 [IP-] [ ] x11-themes/gtk-engines-xfce-3.0.1-r300:3 [IP-] [ ] xfce-base/libxfce4ui-4.10.0:0 [IP-] [ ] xfce-base/libxfce4util-4.10.0:0 [IP-] [ ] xfce-base/xfce4-appfinder-4.10.0-r1:0 [IP-] [ ] xfce-base/xfce4-meta-4.10:0 [IP-] [ ] xfce-base/xfce4-panel-4.10.0-r1:0 [IP-] [ ] xfce-base/xfce4-session-4.10.0-r1:0 [IP-] [ ] xfce-base/xfce4-settings-4.10.0:0 [IP-] [ ] xfce-extra/xfce4-mixer-4.10.0:0 [IP-] [ ] xfce-extra/xfce4-mount-plugin-0.6.4:0 [IP-] [ ] xfce-extra/xfce4-notifyd-0.2.2:0 [IP-] [ ] xfce-extra/xfce4-sensors-plugin-1.2.5:0 [IP-] [ ] xfce-extra/xfce4-weather-plugin-0.8.3:0 [IP-] [ ] xfce-extra/xfce4-xkb-plugin-0.5.4.3:0 xfce-base/thunar needs to have USE=udev enabled and xfce-extra/thunar-volman must be installed i don't see thunar-volman in your list there futhermore authorization from polkit/consolekit must be working, so you must see 'active = TRUE' line when you run `ck-list-sessions` in your Xfce's Terminal as a normal user, see this thread (first post of it): http://forums.gentoo.org/viewtopic-t-858965-start-0.html and like said, xfce4-mount-plugin is irrelevant, and `mount` command shouldn't be used at all for udisks maintained removable devices, instead `udisksctl mount` should be used as a normal user if you really want to mount from commandline Thanks. thunar/thunar-valman seem to be installed on my system as well: equery list '*thunar*' * Searching for *thunar* ... [IP-] [ ] xfce-base/thunar-1.6.2:0 [IP-] [ ] xfce-extra/thunar-volman-0.8.0:0 'ck-list-sessions' when run as a regular user returns: ** Message: Failed to connect to the D-Bus daemon: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory The post covers also this, it looks like you have forgot to add 'dbus' and 'consolekit' to the runlevels: # rc-update add consolekit default # rc-update add dbus default # /etc/init.d/consolekit start That will start dbus and ConsoleKit on boot as required, the system instances. Then there is the user instances, also covered by the post. For example, running Xfce using `startx` from text console: ~/.xinitrc file in your home directory has the content of: exec startxfce4 --with-ck-launch And then you can run $ startx But like said, this is all covered by the forums post. It's like a checklist.
Re: [gentoo-user] re: automounting removable drives
On 07/10/13 00:01, Frank Steinmetzger wrote: On Sun, Oct 06, 2013 at 07:01:09PM +0300, Alexander Kapshuk wrote: I want to be able auto-mount removable drives. I'm running xfce: box0=; equery list xfce-base/xfce4-meta * Searching for xfce4-meta in xfce-base ... [IP-] [ ] xfce-base/xfce4-meta-4.10:0 and kernel: box0=; uname -a Linux box0 3.10.7-gentoo-r1 #1 SMP Sat Oct 5 23:57:58 EEST 2013 i686 Intel(R) Pentium(R) Dual CPU T3400 @ 2.16GHz GenuineIntel GNU/Linux Is udisks the only avenue available to me, as shown here?: http://wiki.gentoo.org/wiki/Udisks I only use XFCE very sporadically, but I remember missing that feature at first, too. IIRC, you lack xfce-extra/xfce4-mount-plugin which is not part of the basic meta installation. wrong. xfce4-mount-plugin is a plug-in to define manual mount points and do manual mounting.
Re: [gentoo-user] LVM2+mdraid5+LUKS+systemd (was Re: LVM2+mdraid+systemd)
On 23/09/13 17:37, Canek Peláez Valdés wrote: On Sep 23, 2013 6:01 AM, Tanstaafl tansta...@libertytrek.org mailto:tansta...@libertytrek.org wrote: Man... watching this discussion just makes me want to avoid systemd like the plague/all the more... Please don't top post. Please disable HTML from your mail client when posting to mailing lists. It looks very ugly.
Re: [gentoo-user] trouble downgrading systemd and virtual/udev
On 26/09/13 04:30, Canek Peláez Valdés wrote: On Wed, Sep 25, 2013 at 5:24 PM, gottl...@nyu.edu wrote: I want to downgrade systemd from 207-r2 to 204 (highest stable). I currently have virtual/udev-206-r2 installed, which prevents systemd-204. OK. So I need to downgrade virtual/udev to 200. I thought emerge -1 =virtual/udev-200 =sys-apps/systemd-204 would do it. But this failed (see below) and suggested masking might help. So I added package.mask/systemd, which contains =virtual/udev-201 =sys-apps/systemd-205 and then issued the same emerge as above. But this also failed (see below). What incantation do I need? Don't mask anything, just make sure that systemd (both virtual/ and sys-apps/) is not on package.keywords. Then uninstall virtual/udev, downgrade systemd (just emerge sys-apps/systemd) and then emerge again virtual/udev. The correct version should be emerged. Nothing in the tree (AFAICS) depends on =virtual/udev-206, so it shoud be fine. wrong. =sys-apps/hwids-20130717-r1 requires =virtual/udev-206 Regards
Re: [gentoo-user] looking for a couple of systemd units
On 27/08/13 09:24, Canek Peláez Valdés wrote: On Tue, Aug 27, 2013 at 1:10 AM, cov...@ccs.covici.com wrote: Canek Peláez Valdés can...@gmail.com wrote: On Mon, Aug 26, 2013 at 11:06 PM, Canek Peláez Valdés can...@gmail.com wrote: On Mon, Aug 26, 2013 at 10:52 PM, cov...@ccs.covici.com wrote: Hi. I am looking for a couple of systemd units which I have not been able to find -- one for mailman and one for innd which is a shell script by itself. Thanks in advance for any suggestions. I use this one in production for mailman with Gentoo: [Unit] Description=Mailman mailing list service After=network.target [Service] Type=forking ExecStart=/usr/lib/mailman/bin/mailmanctl -s start ExecStop=/usr/lib/mailman/bin/mailmanctl stop User=mailman Group=mailman [Install] WantedBy=multi-user.target I don't have any for innd. If innd is the one from net-nntp/inn, then the following should work: [Unit] Description=The Internet News daemon Documentation=man:innd(8) ConditionPathExists=/var/run/news [Service] Type=simple ExecStart=/usr/lib/news/bin/rc.news ExecStop=/usr/lib/news/bin/rc.news stop User=news Group=news [Install] WantedBy=multi-user.target If the binary rc.news forks itself (and there is no option to force it to run in the foreground), use Type=forking. The former is preferred over the latter. Also, to guarantee that the directory /var/run/news always is present, add the following to a new file /etc/tmpfiles.d/innd.conf: d/var/run/news 0755 news news 10d - You can replace 10d with - (hypen), so the directory is never cleaned automatically. If you try this unit and it works as expected, please let us know. OK, thanks again. I have one question which this brings up -- and this applies to openrc as well -- I never have let it migrate /var/run to /run and /var/lock likewise because I have directories in those which are owned by various users, etc. and the packages themselves almost never create such -- is putting things in /etc/tmpfiles.d the correct way to fix this? tmpfiles.d is from systemd: http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html However, I think OpenRC developers were thinking about supporting it. I don't know if that actually happened. openrc-0.11.8 already had initial tmpfiles support, but it's very buggy however ~arch has now openrc-0.12, you could say, complete tmpfiles support and it's already being used at production level packages like sys-apps/kmod's kmod-static-nodes init script so the same tmpfiles systemd uses, will work fine on openrc-0.12 too, long as tmpfiles.setup is in the boot runlevel... - Samuli
Re: [gentoo-user] Re: Advice needed regarding udisks
On 24/08/13 08:39, Grant wrote: Just saying you should be using `udisksctl` command instead of the now obsolete `udisks` command udisksctl command = new udisks 2 udisks command = old udisks 1 OK, but first I need to figure out how to get gvfs to use udisks instead of gdu. by emerging gnome-base/gvfs from ~arch with USE=udev udisks the stable gnome-base/gvfs is not compatible with UDisks 2.1 but by upgrading gnome-base/gvfs on stable to ~arch version with USE=udev udisks is then again not compatible all the way with GNOME 2.x, so that's why it's still in ~arch If I keyword gvfs I get into trouble because gobject-introspection wants dev-libs/glib-2.33 and gvfs wants =dev-libs/glib-2.36. - Grant So? Obviously I meant to say 'keyword gvfs *and it's dependencies* from ~arch if you want to use USE=udev udisks' So that means bunch gobject-introspection, gobject-introspection-common, glib, and likely some others too, Portage will them you about them
Re: [gentoo-user] Re: Advice needed regarding udisks
On 20/08/13 09:21, Grant wrote: This is actually a portage question. How can I install udisks-2 in a way that will fix this problem? I'm confused by how to handle the slotting behavior. I think the issue here is that we are not understanding what the problem is. It happens with an application in particular, or with a desktop environment? It happens when you try to umount the device, or when you disconnect it from the computer? Do you loose data in the camera, or when transferring photos to your computer? Or is only that you don't like the error reported? When trying to eject a USB camera in thunar in xfce4, the error appears and the device does not umount. Here is a command that also produces the error: [ ... ] Just saying you should be using `udisksctl` command instead of the now obsolete `udisks` command udisksctl command = new udisks 2 udisks command = old udisks 1 OK, but first I need to figure out how to get gvfs to use udisks instead of gdu. - Grant by emerging gnome-base/gvfs from ~arch with USE=udev udisks the stable gnome-base/gvfs is not compatible with UDisks 2.1 but by upgrading gnome-base/gvfs on stable to ~arch version with USE=udev udisks is then again not compatible all the way with GNOME 2.x, so that's why it's still in ~arch
Re: [gentoo-user] re: xfce4-sensors-plugin pulling in nvidia-settings
On 22/08/13 22:03, Alexander Kapshuk wrote: On 08/22/2013 09:59 PM, Yuri K. Shatroff wrote: As I figured in the package's changelog, some work on it is being done by Samuli Suominen ssuomi...@gentoo.org. He is also on this list, so I guess he could get involved as soon as he reads the list. Understood. Thanks. Let's wait and hear from Samuli Suominen then. Because the separate nvidia-settings package also ships a library which isn't installed by nvidia-drivers package: $ qfile -b libXNVCtrl.a media-video/nvidia-settings (/usr/lib64/libXNVCtrl.a) And it's being used by xfce4-sensors-plugin, if you extract the tarball and look inside file configure.in, you'll see: NVIDIA_LIBS=-lX11 -lXext -lXNVCtrl ^ - See here, libXNVCtrl.a used
Re: [gentoo-user] re: xfce4-sensors-plugin pulling in nvidia-settings
On 22/08/13 22:22, Alexander Kapshuk wrote: What course of action would you recommend taking with regard to my original post? I'm not sure if I understand your problem but... Looks like nvidia-drivers-319.32 was stabilized without stabilizing nvidia-settings-319.32 together with it. You can file a bug at http://bugs.gentoo.org/ and request stabilization of nvidia-settings-319.32 to match the current stable nvidia-drivers. You can also temporarily add entry to /etc/portage/package.keywords like ~media-video/nvidia-settings-319.32 Anyway I wouldn't worry about it too much, they have been going in different cycles for years and I don't ever remembering anyone reporting an actual bug about it (other than what I just suggested, people get confused by non-matching version numbers, ask questions, and end up filing stabilization request ;-)
Re: [gentoo-user] Re: Advice needed regarding udisks
On 17/08/13 22:00, Grant wrote: This is actually a portage question. How can I install udisks-2 in a way that will fix this problem? I'm confused by how to handle the slotting behavior. I think the issue here is that we are not understanding what the problem is. It happens with an application in particular, or with a desktop environment? It happens when you try to umount the device, or when you disconnect it from the computer? Do you loose data in the camera, or when transferring photos to your computer? Or is only that you don't like the error reported? When trying to eject a USB camera in thunar in xfce4, the error appears and the device does not umount. Here is a command that also produces the error: [ ... ] Just saying you should be using `udisksctl` command instead of the now obsolete `udisks` command udisksctl command = new udisks 2 udisks command = old udisks 1
Re: [gentoo-user] about LIBRARY_PATH
On 12/08/13 05:49, 东方巽雷 wrote: It seems that this variable is hard-code by gcc.I cannot change it any more.When I use gcc -m32 to compile a 32bit program,gcc is looking for /usr/lib rather than /usr/lib32.But in my system,/usr/lib is a symlink to /usr/lib64.The real 32bit librarys is in /usr/lib32.The linker is always complaining about i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-pc-linux-gnux32/4.7.3/../../../../lib/crt1.o' is You have a x32 system? incompatible with i386 output..Why does it not search /usr/lib32?
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/13 13:19, Tanstaafl wrote: On 2013-08-11 2:38 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 11/08/13 21:13, Neil Bothwick wrote: There was a blocker (small b) because virtual/udev needed sys-fs/udev and that gave a blocker that uninstalled eudev. I believe it's 'b' if user doesn't have sys-fs/eudev in /var/lib/portage/world, but 'B' if he does As in, difference is soft and hard blocker depending if the wanted implementation is recorded in the world file or not Well, in my opinion, that just seems wrong. Why does it prefer udev, if *neither* is in the world file? Because it's the default in virtual/udev (/usr/portage/virtual/udev/udev-206-r2.ebuild) As in, sys-fs/udev is the default of Gentoo In my opinion, it should be a 'B' blocker in both cases. It absolutely should not automatically uninstall eudev and install udev, potentially leaving the system in an unbootable state. Portage doesn't work like that. If you step outside of the defaults, you need to record them in your world. It's sort of the logical step to do. But... as long as the conflict is there (for those who actually look for such things) and I can deal with it appropriately - ie, if a small b blocker and it wants to remove eudev and install udev, I just wait until ... Hmmm... so is it eudev that would need to be updated to 'fix' this? Or virtual/udev? Or both? When new version of sys-fs/udev is released with incompabilities with sys-fs/eudev, then new virtual version is created and dependencies inside of it set to compatible versions And if there is no compatible version available, then the version is set to non-existing future-version number that /will be/ compatible with it Which is exactly what happened earlier and will happen again - Samuli
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/13 14:37, hasufell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2013 05:01 AM, Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli * you are not telling the whole story about what happened and why the fork came into life in the first place. It's not as simple as you seem True, I didn't mention people were needlessly unwilling to join the Gentoo udev team despite being invited to. to suggest. There were good reasons at that point. Some changes were merged by udev upstream and there are still more differences than you point out. That has been discussed numerous of times. * claiming that eudev didn't improve anything is wrong and can be proven I can easily prove eudev is nothing but udev and deleted code, plus restored broken 'rule generator', plus useless kept static nodes creation which was moved to kmod, plus needlessly changed code for uclibc support -- uclibc now has the functions udev needs. * that eudev is behind udev most of the time is correct * that it causes tons of breakage for users... well, I don't know, not for me since almost the beginning * eudev will not be treecleaned until the gentoo devs who maintain it agree (at best, it may be masked) and even if eudev will be obsolete at some point, then it has been a success * I don't understand why you add those rants all over different mailing lists. I have seen it numerous of times and your precision about explaining the situation does not improve. If you think that people need to be warned about eudev, then you should provide a reason to mask it or drop it back to ~arch. Anything else is not constructive and causes confusion. True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. - Samuli
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/13 15:17, Tanstaafl wrote: On 2013-08-12 8:06 AM, Samuli Suominen ssuomi...@gentoo.org wrote: True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. It is solving the problem of *when* (not if - if the words I have read from the systemd maintainers can be taken at face value) the systemd maintainers decide to pull the plug on the ability to have a systemd-less udev... Then we will carry a minimal patchset on top of sys-fs/udev that will keep it working without systemd for long as it's sustainable. And at this point it's pointless to talk of forking yet, it should be done only when it's required. - Samuli
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/13 15:19, Alon Bar-Lev wrote: On Mon, Aug 12, 2013 at 3:17 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-08-12 8:06 AM, Samuli Suominen ssuomi...@gentoo.org wrote: True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. It is solving the problem of *when* (not if - if the words I have read from the systemd maintainers can be taken at face value) the systemd maintainers decide to pull the plug on the ability to have a systemd-less udev... Correct. And because that we endorse it. Look what happened with the logind. They made it clear from the start that logind is not going to work for non-systemd and that Ubuntu is doing something utter crazy. We were going to ride with that horse at the expense of Ubuntu folks for a while, but dropped the effort as futile. Now Ubuntu is stuck at logind-204 and it's unclear what will they do next. Don't try to twist it into anything it's not, it's not comparable w/ udev.
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/13 15:38, Alon Bar-Lev wrote: On Mon, Aug 12, 2013 at 3:33 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 12/08/13 15:17, Tanstaafl wrote: On 2013-08-12 8:06 AM, Samuli Suominen ssuomi...@gentoo.org wrote: True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. It is solving the problem of *when* (not if - if the words I have read from the systemd maintainers can be taken at face value) the systemd maintainers decide to pull the plug on the ability to have a systemd-less udev... Then we will carry a minimal patchset on top of sys-fs/udev that will keep it working without systemd for long as it's sustainable. And at this point it's pointless to talk of forking yet, it should be done only when it's required. It is done ahead so it won't be too late, as you say... eudev is minimal patch set over systemd. Someone should have forked the logind as well ahead, so the whole gmone discussion was irrelevant. It's not too late to fork logind in anyway, it's down to 204 in git and then review commits from there up to current w/ the required patches Ubuntu carries for non-systemd operation (yes, logind from 204 never worked without patching either but the patches were just a lot less than what 206 would need). But nobody has been willing to do the work. It was propably for the best we didn't ever adopt it at all since it's not sane to package software you can't then keep maintained. - Samuli
Re: [gentoo-user] Moving from old udev to eudev
On 12/08/13 16:39, hasufell wrote: On 08/12/2013 02:06 PM, Samuli Suominen wrote: On 12/08/13 14:37, hasufell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2013 05:01 AM, Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli * you are not telling the whole story about what happened and why the fork came into life in the first place. It's not as simple as you seem True, I didn't mention people were needlessly unwilling to join the Gentoo udev team despite being invited to. That's a bit unrelated. It wasn't just about the gentoo ebuild. That's all it was. to suggest. There were good reasons at that point. Some changes were merged by udev upstream and there are still more differences than you point out. That has been discussed numerous of times. * claiming that eudev didn't improve anything is wrong and can be proven I can easily prove eudev is nothing but udev and deleted code, plus restored broken 'rule generator', plus useless kept static nodes creation which was moved to kmod, plus needlessly changed code for uclibc support -- uclibc now has the functions udev needs. Wonder why udev upstream merged back changes if it was all that bad. Merged back what changes? That'd be news to me. I think you might be confusing something. * that eudev is behind udev most of the time is correct * that it causes tons of breakage for users... well, I don't know, not for me since almost the beginning * eudev will not be treecleaned until the gentoo devs who maintain it agree (at best, it may be masked) and even if eudev will be obsolete at some point, then it has been a success * I don't understand why you add those rants all over different mailing lists. I have seen it numerous of times and your precision about explaining the situation does not improve. If you think that people need to be warned about eudev, then you should provide a reason to mask it or drop it back to ~arch. Anything else is not constructive and causes confusion. True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. Who lied? Let's rephrase lying with FUD for correctness.
Re: [gentoo-user] sys-auth/consolekit-0.4.6 just sits there.
On 11/08/13 20:12, Dale wrote: I notice this starts but never does anything. I end up doing a ctrl c to stop it. I tried with two different versions of portage so I don't think it is portage itself. But it is. It's either Portage, or Python it's using itself. But it's not about sys-auth/consolekit for sure. I would grab that output and show it to people at #gentoo-portage in Freenode IRC for clue.
