Re: [gentoo-user] How to extend the tmux status 'title' for each pane or window
On Monday 02 Jun 2014 15:17:10 Stroller wrote: On Sat, 31 May 2014, at 4:22 pm, Mick michaelkintz...@gmail.com wrote: I am using tmux and find it convenient especially for managing remote sessions, but I have noticed that the commands running in a session shown at the bottom right hand side, within the status line, are too short. Can I extend the number of characters to be able to see more of the command being run at any time? I only see a *maximum* length option in the manpage - presumably because tmux allocates as much space as possible to the left and right statuses, but space must be consumed by the window titles in the middle. Is it possible you can give the right hand side more room by reducing the maximum of the left? I'm interested to know what you're displaying on the right - it's been so long since I set up tmux, I can't remember what the defaults are. Could you possibly post the output of `tmux show -g status-right`, please? I have: $ tmux show -g | grep -E 'status-[lr]' status-left #[fg=blue]#T status-left-attr none status-left-bg default status-left-fg default status-left-length 20 status-right #[fg=blue][#S] status-right-attr none status-right-bg default status-right-fg default status-right-length 40 $ Thanks Stroller, On the left status bar I see this: [0] 0:bash* with one window open. As I create more windows it adds to it like so: [0] 0:bash 1:bash- 2:bash* The right hand side shows the prompt, or command being run, but not all of it if it is too long. This is the output you requested: $ tmux show -g status-right status-right #22T %H:%M %d-%b-%y and this are the equivalent settings to yours: $ tmux show -g | grep -E 'status-[lr]' status-left [#S] status-left-attr none status-left-bg default status-left-fg default status-left-length 10 status-right #22T %H:%M %d-%b-%y status-right-attr none status-right-bg default status-right-fg default status-right-length 40 I don't have a ~/.tmux.conf yet. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Demise of Truecrypt - surprised I haven't seen t his discussed here yet?
Am 01.06.2014 14:31, schrieb Tanstaafl: Wow, I've been mostly offline for a few days, and this morning when playing catch up on the news, learned that Truecrypt, one of my all time favorite apps, is no more. Well, considering the fact that Linux comes with its own bunch of encrytion possibilities on its own, the demise of TrueCrypt on Linux is neglectable. Some people in Switzerland want to take over development, for further information take a look at www.truecrypt.ch. And then there's tc-play, a free implementation of TrueCrypt based on dm-crypt (https://github.com/bwalex/tc-play), which allows reading and creating TrueCrypt volumes on your own. It just lacks a good GUI so far. Cryptsetup since 1.6 supports reading the TrueCrypt on disk format. And zuluCrypt is a frontend to cryptsetup and tcplay, which acts as a GUI for those. So no loss at all if TrueCrypt would really cease to exist.
[gentoo-user] re: sys-power/upower-pm-utils
Howdy, Just wanted to make sure I read the change logs shown below correctly. So far, I've been using sys-power/upower. Attempting to update sys-power/upower seems to require sys-apps/systemd to be pulled in as a dependency, which I don't want to do. If I understand the change log below correctly, I should uninstall sys-power/upower and install sys-power/upower-pm-utils instead. Is that right? Thanks. equery c sys-power/upower-pm-utils *upower-pm-utils-0.9.23 (26 May 2014) 26 May 2014; Samuli Suominen ssuomi...@gentoo.org +upower-pm-utils-0.9.23.ebuild, +files/upower-pm-utils-0.9.23-clamp_percentage_for_overfull_batt.patch, +files/upower-pm-utils-0.9.23-create-dir-runtime.patch, +files/upower-pm-utils-0.9.23-fix-segfault.patch: Initial commit of upower 0.9 git branch for use with sys-power/pm-utils because upower master git branch removed support for it. Right now this is a copy of =sys-power/upower-0.9.23-r2 without USE=systemd because sys-apps/systemd users will be moving to =sys-power/upower-0.99. equery c sys-power/upower|sed -n '1,/instead/p' *upower-0.9.23-r3 (02 Jun 2014) 02 Jun 2014; Samuli Suominen ssuomi...@gentoo.org +upower-0.9.23-r3.ebuild: Leave 0.9.23-r3 with --disable-deprecated for sys-apps/systemd users. Users who want UPower with sys-power/pm-utils support will want to emerge =sys-power/upower-pm-utils-0.9.23 instead.
Re: [gentoo-user] re: sys-power/upower-pm-utils
On Tuesday, June 03, 2014 11:59:07 AM Alexander Kapshuk wrote: Howdy, Just wanted to make sure I read the change logs shown below correctly. So far, I've been using sys-power/upower. Attempting to update sys-power/upower seems to require sys-apps/systemd to be pulled in as a dependency, which I don't want to do. If I understand the change log below correctly, I should uninstall sys-power/upower and install sys-power/upower-pm-utils instead. Is that right? Thanks. equery c sys-power/upower-pm-utils *upower-pm-utils-0.9.23 (26 May 2014) 26 May 2014; Samuli Suominen ssuomi...@gentoo.org +upower-pm-utils-0.9.23.ebuild, +files/upower-pm-utils-0.9.23-clamp_percentage_for_overfull_batt.patch, +files/upower-pm-utils-0.9.23-create-dir-runtime.patch, +files/upower-pm-utils-0.9.23-fix-segfault.patch: Initial commit of upower 0.9 git branch for use with sys-power/pm-utils because upower master git branch removed support for it. Right now this is a copy of =sys-power/upower-0.9.23-r2 without USE=systemd because sys-apps/systemd users will be moving to =sys-power/upower-0.99. equery c sys-power/upower|sed -n '1,/instead/p' *upower-0.9.23-r3 (02 Jun 2014) 02 Jun 2014; Samuli Suominen ssuomi...@gentoo.org +upower-0.9.23-r3.ebuild: Leave 0.9.23-r3 with --disable-deprecated for sys-apps/systemd users. Users who want UPower with sys-power/pm-utils support will want to emerge =sys-power/upower-pm-utils-0.9.23 instead. 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
Re: [gentoo-user] re: sys-power/upower-pm-utils
On Tue, 03 Jun 2014 11:30:11 + J. Roeleveld jo...@antarean.org wrote: Sounds like Samuli is being a pr*ck by forcing systemd on everyone now. Which is a lot better than to have it break by the lack thereof. A proper solution would have been to have the upower ebuild select systemd as a dependency ONLY when the systemd useflag is set. And who is going to maintain all that. And depend on upower-pm-utils when it is not set. The usage of a USE flag should not control runtime dependencies when the package does not link to it. Doing so will create extra configuration for the package and re-compilation for no underlying file change on disk. This should be avoided and instead can be conveyed to the user via post install messages if needed. http://devmanual.gentoo.org/general-concepts/use-flags -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-user] re: sys-power/upower-pm-utils
On Tuesday, June 03, 2014 11:39:39 AM Tom Wijsman wrote: On Tue, 03 Jun 2014 11:30:11 + J. Roeleveld jo...@antarean.org wrote: Sounds like Samuli is being a pr*ck by forcing systemd on everyone now. Which is a lot better than to have it break by the lack thereof. A proper solution would have been to have the upower ebuild select systemd as a dependency ONLY when the systemd useflag is set. And who is going to maintain all that. And depend on upower-pm-utils when it is not set. The usage of a USE flag should not control runtime dependencies when the package does not link to it. Doing so will create extra configuration for the package and re-compilation for no underlying file change on disk. This should be avoided and instead can be conveyed to the user via post install messages if needed. http://devmanual.gentoo.org/general-concepts/use-flags Then the dependencies should have been fixed prior to making this stable. I do not use Gnome and don't want systemd. I use KDE, which does not depend on systemd. Some of the packages, however, do depend on upower. Supposedly these would work the upower-pm-utils. I would expect the dependency to be fixed before marking this stable or the solution I mentioned to be implemented. -- Joost
Re: [gentoo-user] Demise of Truecrypt - surprised I haven't seen t his discussed here yet?
On 6/3/2014 3:17 AM, Marc Stürmer m...@marc-stuermer.de wrote: So no loss at all if TrueCrypt would really cease to exist. Which totally misses the point of *how* it happened. But never mind... it was definitely off-topic for gentoo.
Re: [gentoo-user] re: sys-power/upower-pm-utils
On Tuesday 03 June 2014 11:48:22 J. Roeleveld wrote: Then the dependencies should have been fixed prior to making this stable. Actually, though it may be marked as stable, it isn't, by which I mean that I can't emerge -uaDvN world today - I get udev and systemd blocking each other. I ran another sync and tried again, but that wasn't the cause. Usually I fix blockages like this by removing the offending package and updating world, but that didn't help here. To be specific, this is what I did: 1. emerge -C sys-fs/udev-212 virtual/libgudev virtual/udev virtual/libudev sys-power/upower 2. added -systemd to make.conf USE flags 3. emerge -uaDvN world 4. got these blocks (I've switched word-wrap off for this): [blocks B ] sys-fs/udev (sys-fs/udev is blocking sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4) [blocks B ] sys-apps/gentoo-systemd-integration (sys-apps/gentoo-systemd-integration is blocking sys-fs/udev-212-r1) [blocks B ] sys-apps/systemd (sys-apps/systemd is blocking sys-fs/udev-212-r1) Total: 17 packages (4 upgrades, 11 new, 1 in new slot, 1 reinstall), Size of downloads: 149,100 kB Conflict: 3 blocks (3 unsatisfied) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (sys-fs/udev-212-r1::gentoo, ebuild scheduled for merge) pulled in by =sys-fs/udev-208-r1:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,gudev,introspection?,static-libs?] (=sys-fs/udev-208-r1:0/0[abi_x86_64(-),gudev]) required by (virtual/libgudev-208::gentoo, ebuild scheduled for merge) =sys-fs/udev-208 required by (virtual/udev-208-r2::gentoo, ebuild scheduled for merge) =sys-fs/udev-208:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,static-libs?] (=sys-fs/udev-208:0/0[abi_x86_64(-)]) required by (virtual/libudev-208::gentoo, ebuild scheduled for merge) (sys-apps/systemd-212-r5::gentoo, ebuild scheduled for merge) pulled in by =sys-apps/systemd-200 required by (sys-power/upower-0.9.23-r3::gentoo, ebuild scheduled for merge) =sys-apps/systemd-207 required by (sys-apps/gentoo-systemd-integration-4::gentoo, ebuild scheduled for merge) Looks like there are still a few wrinkles to sort out yet. -- Regards Peter
Re: [gentoo-user] re: sys-power/upower-pm-utils
On Tue, Jun 3, 2014 at 7:30 AM, J. Roeleveld jo...@antarean.org wrote: On Tuesday, June 03, 2014 11:59:07 AM Alexander Kapshuk wrote: Just wanted to make sure I read the change logs shown below correctly. So far, I've been using sys-power/upower. Attempting to update sys-power/upower seems to require sys-apps/systemd to be pulled in as a dependency, which I don't want to do. If I understand the change log below correctly, I should uninstall sys-power/upower and install sys-power/upower-pm-utils instead. Is that right? Thanks. 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. Sounds like the original poster had the right answer. Starting a systemd flamewar is not helpful. emerge -1 sys-power/upower-pm-utils should fix this. However, this probably should have been a news item before going into the stable tree... Rich
Re: [gentoo-user] re: sys-power/upower-pm-utils
It is marked stable. Otherwise it wouldn't cause blockers because it attempts to force an installation of systemd. -- Joost On 3 June 2014 12:06:26 CEST, Peter Humphrey pe...@prh.myzen.co.uk wrote: On Tuesday 03 June 2014 11:48:22 J. Roeleveld wrote: Then the dependencies should have been fixed prior to making this stable. Actually, though it may be marked as stable, it isn't, by which I mean that I can't emerge -uaDvN world today - I get udev and systemd blocking each other. I ran another sync and tried again, but that wasn't the cause. Usually I fix blockages like this by removing the offending package and updating world, but that didn't help here. To be specific, this is what I did: 1. emerge -C sys-fs/udev-212 virtual/libgudev virtual/udev virtual/libudev sys-power/upower 2. added -systemd to make.conf USE flags 3. emerge -uaDvN world 4. got these blocks (I've switched word-wrap off for this): [blocks B ] sys-fs/udev (sys-fs/udev is blocking sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4) [blocks B ] sys-apps/gentoo-systemd-integration (sys-apps/gentoo-systemd-integration is blocking sys-fs/udev-212-r1) [blocks B ] sys-apps/systemd (sys-apps/systemd is blocking sys-fs/udev-212-r1) Total: 17 packages (4 upgrades, 11 new, 1 in new slot, 1 reinstall), Size of downloads: 149,100 kB Conflict: 3 blocks (3 unsatisfied) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (sys-fs/udev-212-r1::gentoo, ebuild scheduled for merge) pulled in by =sys-fs/udev-208-r1:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,gudev,introspection?,static-libs?] (=sys-fs/udev-208-r1:0/0[abi_x86_64(-),gudev]) required by (virtual/libgudev-208::gentoo, ebuild scheduled for merge) =sys-fs/udev-208 required by (virtual/udev-208-r2::gentoo, ebuild scheduled for merge) =sys-fs/udev-208:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,static-libs?] (=sys-fs/udev-208:0/0[abi_x86_64(-)]) required by (virtual/libudev-208::gentoo, ebuild scheduled for merge) (sys-apps/systemd-212-r5::gentoo, ebuild scheduled for merge) pulled in by =sys-apps/systemd-200 required by (sys-power/upower-0.9.23-r3::gentoo, ebuild scheduled for merge) =sys-apps/systemd-207 required by (sys-apps/gentoo-systemd-integration-4::gentoo, ebuild scheduled for merge) Looks like there are still a few wrinkles to sort out yet. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] re: sys-power/upower-pm-utils
On Tue, Jun 3, 2014 at 7:13 AM, J. Roeleveld jo...@antarean.org wrote: It is marked stable. Otherwise it wouldn't cause blockers because it attempts to force an installation of systemd. The issue isn't really that upower requires systemd so much as that portage can't figure out that it makes more sense in this case to switch to upower-pm-utils. Sure, you could satisfy the dependency graph by switching from udev to systemd, but portage doesn't have any way to know that doing this is a huge change to the system vs just switching to the alternative upower. It is just trying to find a set of packages that satisfy the dependencies and the solution it settled on works, and is the preferred solution since kdelibs lists upower first. The real solution here is better communication. There is a blurb going into the next GMN, but it doesn't mention stable users, and obviously the timing isn't right. Rich
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] Demise of Truecrypt - surprised I haven't seen t his discussed here yet?
On Tuesday 03 Jun 2014 11:00:17 Tanstaafl wrote: On 6/3/2014 3:17 AM, Marc Stürmer m...@marc-stuermer.de wrote: So no loss at all if TrueCrypt would really cease to exist. Which totally misses the point of *how* it happened. But never mind... it was definitely off-topic for gentoo. With a secret development team in play we are verging on conspiracy theory territory, but could it be related to this latest announcement and Cryptolocker? http://www.symantec.com/connect/blogs/international-takedown-wounds-gameover-zeus-cybercrime-network PS. I don't know how Cryptolocker works, but it reads as if it is a filesystem level, rather than block device level encryption tool. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Systemd upower
Hello,
mean this i must install now systemd? What can do when i not want systemd.
The system what i have is good, i want not change to systemd.
[ebuild U ~] sys-devel/gettext-0.19 [0.18.3.2] USE=acl cxx ncurses nls
openmp -cvs -doc -emacs -git -java -static-libs 16,221 kB
[ebuild R] dev-libs/glib-2.38.2-r1:2 USE=(mime%*) -debug (-fam)
(-selinux) -static-libs -systemtap {-test} -utils -xattr
PYTHON_TARGETS=python2_7 (-python2_6) 0 kB
[ebuild N ] sys-apps/systemd-208-r3:0/1 USE=acl filecaps firmware-loader
gudev introspection kmod pam policykit python tcpd -audit -cryptsetup -doc
-gcrypt -http -lzma -qrcode (-selinux) {-test} -vanilla -xattr
PYTHON_SINGLE_TARGET=python2_7 -python3_2 -python3_3
PYTHON_TARGETS=python2_7 python3_3 -python3_2 2,335 kB
[ebuild N ] sys-apps/gentoo-systemd-integration-2 51 kB
[ebuild N ] sys-power/upower-0.9.23-r3 USE=introspection -doc -ios 0 kB
[blocks B ] sys-fs/udev (sys-fs/udev is blocking sys-apps/systemd-208-r3)
[blocks B ] sys-apps/gentoo-systemd-integration
(sys-apps/gentoo-systemd-integration is blocking sys-fs/udev-212-r1)
[blocks B ] sys-apps/systemd (sys-apps/systemd is blocking
sys-fs/udev-212-r1)
Thank you for help Nice Day
Silvio
Re: [gentoo-user] How to extend the tmux status 'title' for each pane or window
On Tue, 3 June 2014, at 6:59 am, Mick michaelkintz...@gmail.com wrote:
…
I have:
…
status-left #[fg=blue]#T
…
status-right #[fg=blue][#S]
…
Thanks Stroller,
On the left status bar I see this:
[0] 0:bash*
with one window open. As I create more windows it adds to it like so:
[0] 0:bash 1:bash- 2:bash*
The right hand side shows the prompt, or command being run, but not all of it
if it is too long.
…
status-left [#S]
…
status-right #22T %H:%M %d-%b-%y
It looks to me like I've merely swapped left and right panes because,
presumably, I thought it looked better that way.
And I've removed the clock - that's one way you could reclaim some screen
space.
I seem to be a little tired, and not fully functional, right now, but you could
do this (for example), like this:
tmux set -g status-right #22T
The relevant section of the man page is:
status-left string
Display string to the left of the status bar. string
will be passed through strftime(3) before being used. By
default, the session name is shown. string may contain
any of the following special character sequences:
Character pairReplaced with
#(shell-command) First line of the command's
output
#[attributes] Colour or attribute change
#HHostname of local host
#hHostname of local host without
the domain name
#FCurrent window flag
#ICurrent window index
#DCurrent pane unique identifier
#PCurrent pane index
#SSession name
#TCurrent pane title
#WCurrent window name
##A literal ‘#’
As I say, I don't seem to be firing on all cylinders right now, but it doesn't
look to me like the commands being run are shown where you say they are, not
on the far right, at least.
I think they're shown in the *middle* section of the status bar.
Where above you have said your display shows:
[0] 0:bash 1:bash- 2:bash*
Then the first 0, in square brackets, indicates the name of the current
session. Try this by opening a new terminal and running `tmux new-s -s
test_sess`.
I think that bash is the name of the command being run in each of your
sessions.
You might like to try running the attached countdown.pl script and see how the
command being run is displayed.
HTH,
Stroller.
#!/usr/bin/perl
use 5.010 ;
my $i = 5 ; while ($i 0) {
say $i-- ; sleep 1;
}
$i=5 ; while ($i 0) {
$0=The_coundown_of_doom_$i ; sleep 1 ; $i-- ;
}
Re: [gentoo-user] Systemd upower
On Tue, Jun 3, 2014 at 9:14 AM, Silvio Siefke siefke_lis...@web.de wrote:
Hello,
mean this i must install now systemd? What can do when i not want systemd.
The system what i have is good, i want not change to systemd.
[ebuild U ~] sys-devel/gettext-0.19 [0.18.3.2] USE=acl cxx ncurses nls
openmp -cvs -doc -emacs -git -java -static-libs 16,221 kB
[ebuild R] dev-libs/glib-2.38.2-r1:2 USE=(mime%*) -debug (-fam)
(-selinux) -static-libs -systemtap {-test} -utils -xattr
PYTHON_TARGETS=python2_7 (-python2_6) 0 kB
[ebuild N ] sys-apps/systemd-208-r3:0/1 USE=acl filecaps
firmware-loader gudev introspection kmod pam policykit python tcpd -audit
-cryptsetup -doc -gcrypt -http -lzma -qrcode (-selinux) {-test} -vanilla
-xattr PYTHON_SINGLE_TARGET=python2_7 -python3_2 -python3_3
PYTHON_TARGETS=python2_7 python3_3 -python3_2 2,335 kB
[ebuild N ] sys-apps/gentoo-systemd-integration-2 51 kB
[ebuild N ] sys-power/upower-0.9.23-r3 USE=introspection -doc -ios 0
kB
[blocks B ] sys-fs/udev (sys-fs/udev is blocking
sys-apps/systemd-208-r3)
[blocks B ] sys-apps/gentoo-systemd-integration
(sys-apps/gentoo-systemd-integration is blocking sys-fs/udev-212-r1)
[blocks B ] sys-apps/systemd (sys-apps/systemd is blocking
sys-fs/udev-212-r1)
If I understood correctly, you need to:
emerge -C sys-power/upower
emerge -1v sys-power/upower-pm-utils
and then update world as usual.
The changes in upower does not make systemd mandatory, but you need to
switch from upower (which now has systemd as a hard dependency) to
upower-pm-utils (which depends on the unmaintined pm-utils).
Regards.
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México
[gentoo-user] Re: sys-power/upower-pm-utils
On Tue, 3 Jun 2014 07:19:00 -0400 Rich Freeman ri...@gentoo.org wrote: On Tue, Jun 3, 2014 at 7:30 AM, J. Roeleveld jo...@antarean.org wrote: On Tuesday, June 03, 2014 11:59:07 AM Alexander Kapshuk wrote: Just wanted to make sure I read the change logs shown below correctly. So far, I've been using sys-power/upower. Attempting to update sys-power/upower seems to require sys-apps/systemd to be pulled in as a dependency, which I don't want to do. If I understand the change log below correctly, I should uninstall sys-power/upower and install sys-power/upower-pm-utils instead. Is that right? Thanks. emerge -1 sys-power/upower-pm-utils should fix this. On my system, using -1 would lead to it being cleaned by --depclean eventually. kdelibs has an optional (USE flag-controlled) dependency on upower, but not on upower-pm-utils. But upower-pm-utils does seem to be a drop-in replacement for upower, as far as KDE is concerned. However, this probably should have been a news item before going into the stable tree... That would have been nice.
[gentoo-user] Re: sys-power/upower-pm-utils
On Tue, 03 Jun 2014 11:30:11 + J. Roeleveld jo...@antarean.org wrote: Sounds like Samuli is being a pr*ck by forcing systemd on everyone now. AIUI from https://forums.gentoo.org/viewtopic-t-992290.html, no one is maintaining systemd-independent power management anywhere upstream any more. As of now, the upower 0.9 git branch still serves non-systemd users, but without any guarantee that will continue. Meanwhile, Samuli is giving us udev without systemd, not something he'd spend his time on if his goal were to force systemd on everyone.
Re: [gentoo-user] Systemd upower
On Tuesday 03 June 2014 09:29:35 Canek Peláez Valdés wrote: If I understood correctly, you need to: emerge -C sys-power/upower emerge -1v sys-power/upower-pm-utils and then update world as usual. That worked for me - thanks Canek. Portage no longer tries to break a blockage circle, and even though upower-pm-utils is emerged with -1, emerge -c doesn't want to remove it. Maybe a news item explaining the switch of upower would help those who haven't blundered into this yet. The changes in upower does not make systemd mandatory, but you need to switch from upower (which now has systemd as a hard dependency) to upower-pm-utils (which depends on the unmaintined pm-utils). -- Regards Peter
Re: [gentoo-user] Systemd upower
On Tue, Jun 3, 2014 at 9:52 AM, Peter Humphrey pe...@prh.myzen.co.uk wrote: On Tuesday 03 June 2014 09:29:35 Canek Peláez Valdés wrote: If I understood correctly, you need to: emerge -C sys-power/upower emerge -1v sys-power/upower-pm-utils and then update world as usual. That worked for me - thanks Canek. Portage no longer tries to break a blockage circle, and even though upower-pm-utils is emerged with -1, emerge -c doesn't want to remove it. Good to know; I don't use OpenRC, so this doesn't affect me, and I have no way to test the proposed solution. 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). Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
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 Tue, 3 Jun 2014 09:29:35 -0500 Canek Peláez Valdés can...@gmail.com wrote: If I understood correctly, you need to: emerge -C sys-power/upower emerge -1v sys-power/upower-pm-utils and then update world as usual. Yes is correct, i has find out after read ebuilds from the packages which need upower. Thanks for help Nice Day Silvio
Re: [gentoo-user] re: sys-power/upower-pm-utils
On 06/03/2014 02:19 PM, Rich Freeman wrote: Sounds like the original poster had the right answer. Starting a systemd flamewar is not helpful. emerge -1 sys-power/upower-pm-utils should fix this. However, this probably should have been a news item before going into the stable tree... Rich Thanks for your reply. Quick question though. What's the benefit of using '-1' there? So the package doesn't get added to the world list? Or are there some extra benefits? Thanks.
[gentoo-user] Re: Systemd upower
On Tue, 03 Jun 2014 18:14:56 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: (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.) I figured out what I wanted to do (uninstall upower, install upower-pm-utils) by reading the changelogs, but I don't know what my other options were. Could I have stuck with upower, letting it pull in systemd, without messing up openrc? ISTM as long as openrc is Gentoo's default init system, it would be nice to have a news item outline all the available paths for openrc users every time something like this happens.
Re: [gentoo-user] re: sys-power/upower-pm-utils
On Tue, 03 Jun 2014 18:26:48 +0300, Alexander Kapshuk wrote: Quick question though. What's the benefit of using '-1' there? So the package doesn't get added to the world list? Or are there some extra benefits? That is more than sufficient benefit. Having upower-pm-utils in @world could cause problems later on. For example, if you later decide to switch to systemd, you'll get a blocker on upower because upower-pm-utils is in @world. @world should contain only what YOU use, anything else is a dependency and should be left to portage to handle. -- Neil Bothwick RAM = Rarely Adequate Memory signature.asc Description: PGP signature
Re: [gentoo-user] Systemd upower
On 03/06/2014 16:29, Canek Peláez Valdés wrote:
On Tue, Jun 3, 2014 at 9:14 AM, Silvio Siefke siefke_lis...@web.de wrote:
Hello,
mean this i must install now systemd? What can do when i not want systemd.
The system what i have is good, i want not change to systemd.
[ebuild U ~] sys-devel/gettext-0.19 [0.18.3.2] USE=acl cxx ncurses nls
openmp -cvs -doc -emacs -git -java -static-libs 16,221 kB
[ebuild R] dev-libs/glib-2.38.2-r1:2 USE=(mime%*) -debug (-fam)
(-selinux) -static-libs -systemtap {-test} -utils -xattr
PYTHON_TARGETS=python2_7 (-python2_6) 0 kB
[ebuild N ] sys-apps/systemd-208-r3:0/1 USE=acl filecaps
firmware-loader gudev introspection kmod pam policykit python tcpd -audit
-cryptsetup -doc -gcrypt -http -lzma -qrcode (-selinux) {-test} -vanilla
-xattr PYTHON_SINGLE_TARGET=python2_7 -python3_2 -python3_3
PYTHON_TARGETS=python2_7 python3_3 -python3_2 2,335 kB
[ebuild N ] sys-apps/gentoo-systemd-integration-2 51 kB
[ebuild N ] sys-power/upower-0.9.23-r3 USE=introspection -doc -ios 0
kB
[blocks B ] sys-fs/udev (sys-fs/udev is blocking
sys-apps/systemd-208-r3)
[blocks B ] sys-apps/gentoo-systemd-integration
(sys-apps/gentoo-systemd-integration is blocking sys-fs/udev-212-r1)
[blocks B ] sys-apps/systemd (sys-apps/systemd is blocking
sys-fs/udev-212-r1)
If I understood correctly, you need to:
emerge -C sys-power/upower
emerge -1v sys-power/upower-pm-utils
and then update world as usual.
The changes in upower does not make systemd mandatory, but you need to
switch from upower (which now has systemd as a hard dependency) to
upower-pm-utils (which depends on the unmaintined pm-utils).
Regards.
That is correct. There is a vocal debate going on in -dev right now
about this and a proposed news item is in the works. here's the current
proposed item which might change but at least explains what is going on:
Do note that emerging upower-pm-utils (what you should do is you want to
keep things the way they were) needs upower to be unmerged first. That
part isn't mentioned in the news item, but portage lets you know real
quick anyway. i.e. upower-pm-utils replaces current upower to restore
old upower feature set
==
UPower discontinued hibernate and suspend support in favor of systemd.
Because of this, we have created a compability package at
sys-power/upower-pm-utils which will give you the old UPower with
sys-power/pm-utils support back.
Some desktops have integrated the sys-power/pm-utils support directly
to their code, like Xfce, and as a result, they work also with the new
UPower as expected.
All non-systemd users are recommended to choose between:
# emerge --noreplace 'sys-power/upower-pm-utils'
or
# emerge --noreplace '=sys-power/upower-0.99.0'
However, all systemd users are recommended to stay with sys-power/upower.
===
--
Alan McKinnon
alan.mckin...@gmail.com
Re: [gentoo-user] Systemd upower
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?
Re: [gentoo-user] re: sys-power/upower-pm-utils
On 06/03/2014 06:46 PM, Neil Bothwick wrote: On Tue, 03 Jun 2014 18:26:48 +0300, Alexander Kapshuk wrote: Quick question though. What's the benefit of using '-1' there? So the package doesn't get added to the world list? Or are there some extra benefits? That is more than sufficient benefit. Having upower-pm-utils in @world could cause problems later on. For example, if you later decide to switch to systemd, you'll get a blocker on upower because upower-pm-utils is in @world. @world should contain only what YOU use, anything else is a dependency and should be left to portage to handle. Understood. Thanks.
Re: [gentoo-user] Systemd upower
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? pm-utils has been unmaintained FOR FIVE YEARS. Any project that decides to stop using it is making just the right decision; UPower just did the correct thing. And systemd had *nothing* to do with it, except for providing a better, more reliable alternative. 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. Since systemd provides a better alternative for everything in the stack just above the kernel, more and more projects (probably) will start using it exclusively. That is no systemd's fault; they just worked in a good, integrated solution. Why any project will want to support multiple alternatives for the same functionality, if systemd provides the better one, and almost no distribution works without it? Perhaps if somebody wrote the code they'll do it, but almost all programmers who know what they are doing refuse to work with anything else than systemd You don't like it? Go ahead and take maintainership of pm-utils. Fork UPower. Make better replacements for the components that systemd provides. There is no conspiracy here (although for *SURE* there are scare-mongering conspiracy theorists); there is only developers working in the best possible implementation for our plumbing layer, and other developers realizing that, in Linux at least, supporting anything besides systemd is a freakin' waste of time and resources. Again; you don't like it? Then do something about it instead of posting in *-user lists. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] Demise of Truecrypt - surprised I haven't seen t his discussed here yet?
On Jun 2, 2014, at 18:29, J. Roeleveld jo...@antarean.org wrote: On Monday, June 02, 2014 04:23:07 PM Matti Nykyri wrote: On Jun 2, 2014, at 17:52, J. Roeleveld jo...@antarean.org wrote: On Monday, June 02, 2014 03:23:03 PM Matti Nykyri wrote: On Jun 2, 2014, at 16:40, J. Roeleveld jo...@antarean.org wrote: On Monday, June 02, 2014 07:28:53 AM Rich Freeman wrote: On Mon, Jun 2, 2014 at 6:56 AM, Neil Bothwick n...@digimed.co.uk wrote: On Mon, 02 Jun 2014 05:27:44 -0500, Dale wrote: The second option does sound what I am looking for. Basically, if I log out but leave my computer on, leave home, some crook/NSA type breaks in and tries to access something or steals my whole puter, they would just get garbage for data. That seems to fit the second option best. If they steal your computer they will have to power it off, unless you are kind enough to leave them a large enough UPS to steal along with it, so any encryption will be equally effective. If you're worried about casual thieves then just about any kind of properly-implemented encryption will stop them. If you're worried about a government official specifically tasked with retrieving your computer, my understanding is that it is SOP these days to retrieve your computer without powering it off for just this reason. They won't use your UPS to do it. Typically they remove the plug just far enough to expose the prongs, slide in a connector that connects it to a UPS, and then they pull it out the rest of the way now powered by the UPS. See something like: http://www.cru-inc.com/products/wiebetech/hotplug_field_kit/ Hmm... Those are nice, but can be easily built yourself with an off-the-shelf UPS. Presumably somebody who is determined will also have the means to retrieve the contents of RAM once they seize your computer. Besides directlly accessing the memory bus I think most motherboards are not designed to be secure against attacks from PCI/firewire/etc. Hmm... add something to auto-shutdown the computer when a hotplug event occurs on any of the internal ports and remove support for unused ports from the kernel. I wonder how they'd keep a computer from initiating a shutdown procedure or causing a kernel panic when it looses (wireless) connection to another device that is unlikely to be moved when powered up? Well i have a switch in the door of the server room. It opens when you open the door. That signals the kernel to wipe all the encryption keys from kernel memory. Without the keys there is no access to the disks. After that another kernel is executed which wipes the memory of the old kernel. If you just pull the plug memory will stay in its state for an unspecified time. You don't happen to have a howto on how to set that up? Well i have a deamon running and a self made logic device in COM-port. Very simple. It has a single serial-parallel converter to do simple IO. Currently it just controls one relay that powers the network-devices. I actually meant the software side: - How to wipe the keys and then wipe the whole memory. The dm-crypt module inside kernel provides a crypt_wipe_key function that wipes the memory portion that holds the key. It also invalidates the key, so that no further writes to the drive can occur. Suspending the device prior is recommended: dmsetup suspend /dev/to-device dmsetup message /dev/to-device 0 key wipe When you boot into your kernel you can setup a crash kernel inside your memory. The running kernel will not touch this area so you can be certain that there is no confidential data inside. Then you just wipe the area of the memory of the original kernel after you have executed your crash kernel. So I do this by opening /dev/mem in the crash kernel and then mmap every page you need to wipe. I use the memset to wipe the page. Begin from physical address where your original kernel is located and walk the way up. Skip the portion where you crash kernel is! Crash kernel location is in your kernel cmdline and the location of the original kernel in your kernel config. I consoder this setup quite secure. Makes me wonder what it is you are protecting your server from. :) Well just a hobby. I wanted to play with electronics. The server controls my heating, locks of the house, lights, airconditioning, fire-alarm and burglar-alarm. Gentoo-powered house... I would keep the system controlling all that off the internet with only a null-modem cable to an internet-connected server using a custom protocol. Anything that doesn't match the protocol initiates a full lock-down of the house. ;) But it is much more convenient to control everything from you phone via internet. Just have everything setup in a secure manner. Anyways it's easier for a common burglar to break the window then to hack the server! And you can not steal the stereos by hacking the server ;) -- -Matti
Re: [gentoo-user] Demise of Truecrypt - surprised I haven't seen t his discussed here yet?
On Tuesday, June 03, 2014 09:53:58 PM Matti Nykyri wrote: On Jun 2, 2014, at 18:29, J. Roeleveld jo...@antarean.org wrote: I actually meant the software side: - How to wipe the keys and then wipe the whole memory. The dm-crypt module inside kernel provides a crypt_wipe_key function that wipes the memory portion that holds the key. It also invalidates the key, so that no further writes to the drive can occur. Suspending the device prior is recommended: dmsetup suspend /dev/to-device dmsetup message /dev/to-device 0 key wipe Thank you for this, wasn't aware of those yet. Does this also work with LUKS encrypted devices? When you boot into your kernel you can setup a crash kernel inside your memory. The running kernel will not touch this area so you can be certain that there is no confidential data inside. Then you just wipe the area of the memory of the original kernel after you have executed your crash kernel. So I do this by opening /dev/mem in the crash kernel and then mmap every page you need to wipe. I use the memset to wipe the page. Begin from physical address where your original kernel is located and walk the way up. Skip the portion where you crash kernel is! Crash kernel location is in your kernel cmdline and the location of the original kernel in your kernel config. Hmm.. this goes beyond me. Will need to google on this to see if I can find some more. Unless you know a good starting URL? I would keep the system controlling all that off the internet with only a null-modem cable to an internet-connected server using a custom protocol. Anything that doesn't match the protocol initiates a full lock-down of the house. ;) But it is much more convenient to control everything from you phone via internet. Just have everything setup in a secure manner. Anyways it's easier for a common burglar to break the window then to hack the server! And you can not steal the stereos by hacking the server ;) Perhaps, but I would have added security shutters to all the windows and doors which are also controlled by the same system. Smashing a window wouldn't help there. Especially if the only way to open those is by getting the server (which by then went into a full lock-down) to open them... Now only to add a halo fire suppression system to the server room and all you need to do is find a way to dispose of the mess ;) -- Joost
Re: [gentoo-user] Demise of Truecrypt - surprised I haven't seen t his discussed here yet?
On Jun 4, 2014, at 0:05, J. Roeleveld jo...@antarean.org wrote: On Tuesday, June 03, 2014 09:53:58 PM Matti Nykyri wrote: On Jun 2, 2014, at 18:29, J. Roeleveld jo...@antarean.org wrote: I actually meant the software side: - How to wipe the keys and then wipe the whole memory. The dm-crypt module inside kernel provides a crypt_wipe_key function that wipes the memory portion that holds the key. It also invalidates the key, so that no further writes to the drive can occur. Suspending the device prior is recommended: dmsetup suspend /dev/to-device dmsetup message /dev/to-device 0 key wipe Thank you for this, wasn't aware of those yet. Does this also work with LUKS encrypted devices? Yes. Well LUKS is just a binary header that contains all the necessary setups for a secure disk encryption. If you don't use LUKS you must do all the steps it does by your self. From kernel point of view it does not see LUKS at all. When cryptsetup setups a LUKS drive in device-mapper it gives it only the portion of the drive behind the LUKS-header. LUKS is just a good way of storing your setup (cipher, master key etc...). There is a really good article about LUKS, but i failed to find it now. When you boot into your kernel you can setup a crash kernel inside your memory. The running kernel will not touch this area so you can be certain that there is no confidential data inside. Then you just wipe the area of the memory of the original kernel after you have executed your crash kernel. So I do this by opening /dev/mem in the crash kernel and then mmap every page you need to wipe. I use the memset to wipe the page. Begin from physical address where your original kernel is located and walk the way up. Skip the portion where you crash kernel is! Crash kernel location is in your kernel cmdline and the location of the original kernel in your kernel config. Hmm.. this goes beyond me. Will need to google on this to see if I can find some more. Unless you know a good starting URL? Didn't find a good one either. Will continue searching. There are many ways to do it though. Through the kernel or just write your own program that runs all by it self... Like memtest86. In its source there is everything you need to wipe the memory. But that is more advanced then doing it via kernel interface in my opinion.. I would keep the system controlling all that off the internet with only a null-modem cable to an internet-connected server using a custom protocol. Anything that doesn't match the protocol initiates a full lock-down of the house. ;) But it is much more convenient to control everything from you phone via internet. Just have everything setup in a secure manner. Anyways it's easier for a common burglar to break the window then to hack the server! And you can not steal the stereos by hacking the server ;) Perhaps, but I would have added security shutters to all the windows and doors which are also controlled by the same system. Smashing a window wouldn't help there. Especially if the only way to open those is by getting the server (which by then went into a full lock-down) to open them... Now only to add a halo fire suppression system to the server room and all you need to do is find a way to dispose of the mess ;) Lol. -M
Re: [gentoo-user] Demise of Truecrypt - surprised I haven't seen t his discussed here yet?
Am 03.06.2014 12:00, schrieb Tanstaafl: So no loss at all if TrueCrypt would really cease to exist. Which totally misses the point of *how* it happened. How it happened is strange and you can make many theories about it. The more interesting question about it for sure is: why did many people trust such an anonymous development team at all?
Re: [gentoo-user] Systemd upower
On 03/06/2014 18:48, Tanstaafl 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? I don't think that is what is happening here. The upower devs decided to stop inventing their own wheel wrt hibernate/suspend and instead use the code for the same purpose that is in systemd, lower down the stack. In some way this makes sense, much like if you had your own hand-rolled ssl code and decided to drop it in favour of linking with openssl. The bad news is that upower was the last project actively working on hibernate/suspend outside of systemd, so it can look like conspiracy theory. 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. Perhaps it really is a case of projects are migrating to systemd because there's an advantage to doing so and makes a dev's life easier. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Systemd upower
On 03/06/2014 19:08, Canek Peláez Valdés wrote: Who is forcing anything? pm-utils has been unmaintained FOR FIVE YEARS. Any project that decides to stop using it is making just the right decision; UPower just did the correct thing. And systemd had *nothing* to do with it, except for providing a better, more reliable alternative. 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. weak attempt to inject humour and lighten the thread mood This whole systemd thing looks awfully like the switch from a hosts file to DNS so many years ago. On the one had a hosts file worked and you could throw vi at it. On the other hand this DNS thing could be evil and we'd have to hand control over to insert name of nebulous party here. Trouble is, a host file is an awful solution and really just does everything badly. Much like shell init scripts. We all, sysadmins and devs alike, agree that consistent interfaces are a very good idea, so we pick a standard and stick with it. And yet, strangely, there's so much resistance to doing just that with early user space. I'm not a systemd user, but I do find this whole thing quite funny :-) /weak attempt to inject humour and lighten the thread mood -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Systemd upower
Am 03.06.2014 22:14, schrieb Alan McKinnon: This whole systemd thing looks awfully like the switch from a hosts file to DNS so many years ago. Not really. What many people bothers about systemd is that it is getting more and more a) a hard dependancy for software projects, e.g. like GNOME, although there's no such thing like systemd e.g. on FreeBSD, (MATE instead tries to be init system agnostic), making it harder to port and b) that systemd seems to be on a track to reinvent the wheel or so more and more. They are really working on their own DHCP server and client at the moment, also their own NTP client. Some people coined the term Lennartware for it, because it's from Lennart Poettering, like also pulseaudio and avahi. Some people are already joking that it wants to become the next Emacs. Even Linus Torvalds himself ranted about the attitude of systemd's developers at the beginning of May this year.
Re: [gentoo-user] Demise of Truecrypt - surprised I haven't seen t his discussed here yet?
On Tue, Jun 03, 2014 at 10:53:15PM +0300, Matti Nykyri wrote: On Jun 4, 2014, at 0:05, J. Roeleveld jo...@antarean.org wrote: On Tuesday, June 03, 2014 09:53:58 PM Matti Nykyri wrote: On Jun 2, 2014, at 18:29, J. Roeleveld jo...@antarean.org wrote: I actually meant the software side: - How to wipe the keys and then wipe the whole memory. The dm-crypt module inside kernel provides a crypt_wipe_key function that wipes the memory portion that holds the key. It also invalidates the key, so that no further writes to the drive can occur. Suspending the device prior is recommended: dmsetup suspend /dev/to-device dmsetup message /dev/to-device 0 key wipe Thank you for this, wasn't aware of those yet. Does this also work with LUKS encrypted devices? Yes. Well LUKS is just a binary header that contains all the necessary setups for a secure disk encryption. If you don't use LUKS you must do all the steps it does by your self. From kernel point of view it does not see LUKS at all. When cryptsetup setups a LUKS drive in device-mapper it gives it only the portion of the drive behind the LUKS-header. LUKS is just a good way of storing your setup (cipher, master key etc...). There is a really good article about LUKS, but i failed to find it now. Begin by reading these: tomb.dyne.org/Luks_on_disk_format.pdf http://clemens.endorphin.org/TKS1-draft.pdf http://clemens.endorphin.org/nmihde/nmihde-A4-os.pdf These contain very good info about LUKS and disk encryption. The last one is probably a bit ruff one. http://clemens.endorphin.org/cryptography - a good one. I strongly suggest to dig into disk encryption before implementing it! When you boot into your kernel you can setup a crash kernel inside your memory. The running kernel will not touch this area so you can be certain that there is no confidential data inside. Then you just wipe the area of the memory of the original kernel after you have executed your crash kernel. So I do this by opening /dev/mem in the crash kernel and then mmap every page you need to wipe. I use the memset to wipe the page. Begin from physical address where your original kernel is located and walk the way up. Skip the portion where you crash kernel is! Crash kernel location is in your kernel cmdline and the location of the original kernel in your kernel config. Hmm.. this goes beyond me. Will need to google on this to see if I can find some more. Unless you know a good starting URL? Didn't find a good one either. Will continue searching. Here are few pages: http://naveengopala-embeddedlinux.blogspot.fi/2012/01/reading-physical-mapped-memory-using.html http://stackoverflow.com/questions/647783/direct-memory-access-in-linux and mmap man-page for sure... It is really straight forward... just mmap the page you want and erase it. You will just need to know what addresses to mmap and what not. Do it one page at a time and always align. The memory should not contain very sensitive data on how to access your disks if you wipe the keys. There are many ways to do it though. Through the kernel or just write your own program that runs all by it self... Like memtest86. In its source there is everything you need to wipe the memory. But that is more advanced then doing it via kernel interface in my opinion.. I would keep the system controlling all that off the internet with only a null-modem cable to an internet-connected server using a custom protocol. Anything that doesn't match the protocol initiates a full lock-down of the house. ;) But it is much more convenient to control everything from you phone via internet. Just have everything setup in a secure manner. Anyways it's easier for a common burglar to break the window then to hack the server! And you can not steal the stereos by hacking the server ;) Perhaps, but I would have added security shutters to all the windows and doors which are also controlled by the same system. Smashing a window wouldn't help there. Especially if the only way to open those is by getting the server (which by then went into a full lock-down) to open them... Now only to add a halo fire suppression system to the server room and all you need to do is find a way to dispose of the mess ;) Lol. -M -- -Matti
Re: [gentoo-user] Systemd upower
On 03/06/2014 23:01, Marc Stürmer wrote: Am 03.06.2014 22:14, schrieb Alan McKinnon: This whole systemd thing looks awfully like the switch from a hosts file to DNS so many years ago. Not really. What many people bothers about systemd is that it is getting more and more a) a hard dependancy for software projects, e.g. like GNOME, although there's no such thing like systemd e.g. on FreeBSD, (MATE instead tries to be init system agnostic), making it harder to port and b) that systemd seems to be on a track to reinvent the wheel or so more and more. They are really working on their own DHCP server and client at the moment, also their own NTP client. Some people coined the term Lennartware for it, because it's from Lennart Poettering, like also pulseaudio and avahi. Some people are already joking that it wants to become the next Emacs. Even Linus Torvalds himself ranted about the attitude of systemd's developers at the beginning of May this year. I am very familiar with all of that, along with every other regular here - the topic has been discussed to death here repeatedly[1] Also, please don't assign all the evils of the free software world to Lennart. systemd is a large team comprising many more persons than just Lennart. Now, ranting about Lennart ain't gonna solve nuthin'. Writing code will. The systemd devs have an itch to scratch and they are scratching it by writing code. I don't see too many other folks writing anything like the same amount of code and yet for those that want to counter systemd, that is the only thing that will. So where's the alternative code? It's not in SysVinit. For the record, I'm not a systemd fan, I actually run it nowhere. FWIW, I agree with Lennart's ideas as they have sound technical merit in principle. It's his implementation I don't like. Incidentally, what exactly is wrong with systemd writing a dhcp server client, and an ntp client? Is that project prohibited from writing such software? Are they not allowed to do it? Does it break legal laws? Is there an NDA or non-compete clause in the mix that I'm not aware of? Because they are the only things that could stop systemd from writing such code; without such prohibitions they are free to spend their time doing whatever they damn well please and if that means yet another dhcp implementation, so be it. Let's take that argument a little further: Paul Vixie wrote a dhcp package. Per your logic, it would then not beOK for Roy Marples to write dhcpcd. but he did, and no-one is complaining. I can predict the likely response - systemd will bundle their dhcp and ntp code. So what? It's their time and effort, they are free to choose to spend it how they wish. And you are equally free to write something better if you so choose. [1] For the purpose of this exercise, lets assign a value of more than 10 to repeatedly -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: What happened to Qt 5?
On Sun, 01 Jun 2014 18:11:11 -0400 cov...@ccs.covici.com wrote: James wirel...@tampabay.rr.com wrote: john jdm at jdm.myzen.co.uk writes: lxqt is up and running in Gentoo. It's listed in packages. The only problem I had was emerging lxqt-panel but just had to change a use flag of lxqt-panel from quicklauch to -quicklaunch and it emerged. No problems with anything else and desktop is good. Wow! Did you do a fresh install or convert from lxde? If yuo converted, do you like it better? Was the conversion easy? Does your usb device auto-discovery/mount thingie work? Did you use the lxqt-meta package? got a list of files/configs you have to customize? useful docs or a wiki? I'm still fairly new to the whole lx** thing... But I love the light resource footprint! Maybe I should put it on a non-essential machine first? your thoughts and suggestions are welcome. When I tried to emerge lx-qt-neta, it only wanted to emerge qt4 packages, even though I said use=qt5, how can I get it to emerge qt5 as well, or are they mutually exclusive? I emerge -vp lxqt-meta and it gave me an output of masked packages which I populated /etc/portage/package.accept_keywords eg =lxqt-base/lxqt-panel-0.7.0-r1 ~amd64 etc Then emerge emerge lxqt-meta again. It only depends on qt4 packages though. Not sure about qt5 as I believe this is not available in standard packages yet. I can only see qt versions 4.8.5 in portage. Perhaps the use flag is for future functionality. Or you may need to use an overlay to get qt5. I did not use lxde before but razor. Its very similar to this. -- John D Maunder
Re: [gentoo-user] Systemd upower
On Tue, Jun 3, 2014 at 4:40 PM, Alan McKinnon alan.mckin...@gmail.com wrote: [...] Incidentally, what exactly is wrong with systemd writing a dhcp server client, and an ntp client? Is that project prohibited from writing such software? Are they not allowed to do it? Does it break legal laws? Is there an NDA or non-compete clause in the mix that I'm not aware of? Because they are the only things that could stop systemd from writing such code; without such prohibitions they are free to spend their time doing whatever they damn well please and if that means yet another dhcp implementation, so be it. Alan, thanks for succinctly putting why is absurd to complain about someone else's desire to write whatever code she desires to write. And to sharing it to the world! The HORROR! How *DARE* they to release their code? For free! Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] Systemd upower
On Wed, Jun 4, 2014 at 12:59 AM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Jun 3, 2014 at 4:40 PM, Alan McKinnon alan.mckin...@gmail.com wrote: [...] Incidentally, what exactly is wrong with systemd writing a dhcp server client, and an ntp client? Is that project prohibited from writing such software? Are they not allowed to do it? Does it break legal laws? Is there an NDA or non-compete clause in the mix that I'm not aware of? Because they are the only things that could stop systemd from writing such code; without such prohibitions they are free to spend their time doing whatever they damn well please and if that means yet another dhcp implementation, so be it. Alan, thanks for succinctly putting why is absurd to complain about someone else's desire to write whatever code she desires to write. And to sharing it to the world! The HORROR! How *DARE* they to release their code? For free! Once again, you do not understand the claim. If a user of Gentoo chooses to use non systemd profile, it means that we need to make sure systemd will not be a valid option, ever. In this case, if it is to disable the upower USE flag, or to provide alternative, block newer version, whatever make it possible to have a system working without systemd. systemd should not be visible at any time, nor its implications. Alon
Re: [gentoo-user] Systemd upower
On Tue, 03 Jun 2014 23:01:20 +0200, Marc Stürmer wrote: Even Linus Torvalds himself ranted about the attitude of systemd's developers at the beginning of May this year. Linus rants about everything and everyone, usually at least twice, once for and once against. It proves nothing beyond Linus is still Linus. -- Neil Bothwick GOTO: (n.) an efficient and general way of controlling a program, much despised by academics and others whose brains have been ruined by overexposure to Pascal. signature.asc Description: PGP signature
Re: [gentoo-user] Systemd upower
On 04/06/2014 00:06, Alon Bar-Lev wrote: On Wed, Jun 4, 2014 at 12:59 AM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Jun 3, 2014 at 4:40 PM, Alan McKinnon alan.mckin...@gmail.com wrote: [...] Incidentally, what exactly is wrong with systemd writing a dhcp server client, and an ntp client? Is that project prohibited from writing such software? Are they not allowed to do it? Does it break legal laws? Is there an NDA or non-compete clause in the mix that I'm not aware of? Because they are the only things that could stop systemd from writing such code; without such prohibitions they are free to spend their time doing whatever they damn well please and if that means yet another dhcp implementation, so be it. Alan, thanks for succinctly putting why is absurd to complain about someone else's desire to write whatever code she desires to write. And to sharing it to the world! The HORROR! How *DARE* they to release their code? For free! Once again, you do not understand the claim. If a user of Gentoo chooses to use non systemd profile, it means that we need to make sure systemd will not be a valid option, ever. In this case, if it is to disable the upower USE flag, or to provide alternative, block newer version, whatever make it possible to have a system working without systemd. systemd should not be visible at any time, nor its implications. Alon Alon, You need to read the massive thread on -dev about this and understand the technical reason why portage is doing something strange. I'm not going to give you opinion or rant here, I'm going to give you fact: Nobody is shoving systemd down anyone's throat because that is not what the portage code did. UPower removed their support for pm-utils (unmaintained for 5 years) and now support that same functionality provided by systems. UPower has the right to make that call. Samuli picked up that this is an issue for non-systemd users - they will not have the ability to suspend/hiberate. So a package was created called upower-pm-utils which contains the pm-utils code prior to the UPower change. If you want UPower to work as it always did for you, simply unmerge upower and merge upower-pm-utils. To have suspend/hibernate done the systmed way, just leave UPower installed and let portage do it's thing. Now, this is where the snag comes in. Portage sees you have UPower and you now need pm functionality, and portage needs to merge something to fill that dependency. Because of the way the code works, portage finds UPower+systemd first always, and decides to use that. It's software, not a human, so it doesn't question your decision and proceeds. It's analogous to having a virtual - if you don't tell portage which one to use, it picks the first. You tell portage which one you want by installing it, and portage is happy with that. Should there have been some USE flag-type solution to definitely indicate your choice? Sounds good in practice but in this case it's not a good idea (see the -dev thread for reasons why). Besides, this is a transitional phase and things will change again in a month. It's really not worth the effort to set up a USE for one package for a month. Those are the facts as laid out by our Gentoo devs and those facts do not support a conspiracy theory. Summary; You yourself do not want systemd. OK. Here's how to not get it in this case: emerge -C upower emerge -1 upower-pm-utils -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Systemd upower
On 04/06/2014 00:59, Neil Bothwick wrote: On Tue, 03 Jun 2014 23:01:20 +0200, Marc Stürmer wrote: Even Linus Torvalds himself ranted about the attitude of systemd's developers at the beginning of May this year. Linus rants about everything and everyone, usually at least twice, once for and once against. It proves nothing beyond Linus is still Linus. He *did* rant about Gnome not giving him choices about middle clicking on the window frame and rejecting his patch to do that, so he switched to KDE. Then he ranted about KDE giving the users too much choice with weird config dialogues and not getting their shit together to fix actual bugs, so he switched to Gnome. I eagerly anticipate Linus' switch to E17. Oops sorry, make that E19. So Linus is still Linus? Yep, that's how I see it too. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Systemd upower
On Tue, Jun 3, 2014 at 5:06 PM, Alon Bar-Lev alo...@gentoo.org wrote: On Wed, Jun 4, 2014 at 12:59 AM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Jun 3, 2014 at 4:40 PM, Alan McKinnon alan.mckin...@gmail.com wrote: [...] Incidentally, what exactly is wrong with systemd writing a dhcp server client, and an ntp client? Is that project prohibited from writing such software? Are they not allowed to do it? Does it break legal laws? Is there an NDA or non-compete clause in the mix that I'm not aware of? Because they are the only things that could stop systemd from writing such code; without such prohibitions they are free to spend their time doing whatever they damn well please and if that means yet another dhcp implementation, so be it. Alan, thanks for succinctly putting why is absurd to complain about someone else's desire to write whatever code she desires to write. And to sharing it to the world! The HORROR! How *DARE* they to release their code? For free! Once again, you do not understand the claim. It is you who does not understand how software workds. See Alan response. If a user of Gentoo chooses to use non systemd profile, it means that we need to make sure systemd will not be a valid option, ever. Again, you don't understand how software works: this has nothing to do with profiles, it has to do with the fact that UPower now relies on systemd, and therefore people who has UPower installed now, *by default*, require systemd. If they don't want systemd, there is a way to do it, but it requires manual intervention since they now need to first uninstall UPower. In this case, if it is to disable the upower USE flag, or to provide alternative, block newer version, whatever make it possible to have a system working without systemd. It is provided: emerge -C upower emerge -1v upower-pm-utils It has to be done manually, though; otherwise you step on systemd users. systemd should not be visible at any time, nor its implications. Nobody is here to deal with other people's OCD. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] Systemd upower
On Tue, Jun 3, 2014 at 6:07 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On 04/06/2014 00:59, Neil Bothwick wrote: On Tue, 03 Jun 2014 23:01:20 +0200, Marc Stürmer wrote: Even Linus Torvalds himself ranted about the attitude of systemd's developers at the beginning of May this year. Linus rants about everything and everyone, usually at least twice, once for and once against. It proves nothing beyond Linus is still Linus. He *did* rant about Gnome not giving him choices about middle clicking on the window frame and rejecting his patch to do that, so he switched to KDE. Then he ranted about KDE giving the users too much choice with weird config dialogues and not getting their shit together to fix actual bugs, so he switched to Gnome. I eagerly anticipate Linus' switch to E17. Oops sorry, make that E19. So Linus is still Linus? Yep, that's how I see it too. At some point, someone is going to ask Linus point blank what does he think about systemd. I would not be surprised if he says it's a great idea. I would neither be surprised if he says it's a terrible idea. And then some weeks/months/years later, he *will* say the opposite. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] Systemd upower
On 6/3/2014 16:13, Canek Peláez Valdés wrote: On Tue, Jun 3, 2014 at 5:06 PM, Alon Bar-Lev alo...@gentoo.org wrote: On Wed, Jun 4, 2014 at 12:59 AM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Jun 3, 2014 at 4:40 PM, Alan McKinnon alan.mckin...@gmail.com wrote: [...] Incidentally, what exactly is wrong with systemd writing a dhcp server client, and an ntp client? Is that project prohibited from writing such software? Are they not allowed to do it? Does it break legal laws? Is there an NDA or non-compete clause in the mix that I'm not aware of? Because they are the only things that could stop systemd from writing such code; without such prohibitions they are free to spend their time doing whatever they damn well please and if that means yet another dhcp implementation, so be it. Alan, thanks for succinctly putting why is absurd to complain about someone else's desire to write whatever code she desires to write. And to sharing it to the world! The HORROR! How *DARE* they to release their code? For free! Once again, you do not understand the claim. It is you who does not understand how software workds. See Alan response. If a user of Gentoo chooses to use non systemd profile, it means that we need to make sure systemd will not be a valid option, ever. Again, you don't understand how software works: this has nothing to do with profiles, it has to do with the fact that UPower now relies on systemd, and therefore people who has UPower installed now, *by default*, require systemd. If they don't want systemd, there is a way to do it, but it requires manual intervention since they now need to first uninstall UPower. In this case, if it is to disable the upower USE flag, or to provide alternative, block newer version, whatever make it possible to have a system working without systemd. It is provided: emerge -C upower emerge -1v upower-pm-utils It has to be done manually, though; otherwise you step on systemd users. systemd should not be visible at any time, nor its implications. Nobody is here to deal with other people's OCD. Regards. FWIW, on my system, I had to mask sys-apps/gentoo-systemd-integration for it to merge the udev update w/o trying to pull in systemd, et al. i didn't deep dive on what was trying to pull that in, but masking it (plus a ton of other stuff I have masked) prevented portage from trying to build a systemd based system.
Re: [gentoo-user] Systemd upower
On Wed, 4 Jun 2014 01:06:52 +0300 Alon Bar-Lev alo...@gentoo.org wrote: Once again, you do not understand the claim. If a user of Gentoo chooses to use non systemd profile, it means that we need to make sure systemd will not be a valid option, ever. There is no such thing as a non systemd profile on Gentoo at the moment; you have .../systemd profiles, which are specializations of the more generic case ... which you can fill in with gnome or kde. So, I'm here running this agnostic MATE with a make.profile symlink that doesn't point to a .../systemd profile; what is remarkable, is that systemd is a valid option in this case. Similarly, if I pick a .../systemd profile; what is remarkable, is that OpenRC is also a valid option in that case. For there to be a make sure systemd will not be a valid option, ever there would have to be a .../no-systemd profile or something like that; in such profile, one could then mask anything that tries to pull in systemd and not have to deal with further transitions later on. Splitting up profiles this way becomes a pain to maintain; other than that, it is also a controversial way to go about it given that a no-... type of profile hasn't been commonly used before yet. In this train of thoughts Funtoo mix-ins could help to do it more clean. http://www.funtoo.org/Flavors_and_Mix-ins But until we've got something, we've got to accept that other options remain valid choices; profiles are just there, well, to ensure a particular choice is properly supported without further implications. In this case, if it is to disable the upower USE flag, or to provide alternative, block newer version, whatever make it possible to have a system working without systemd. systemd should not be visible at any time, nor its implications. Alon It is easy to make such a statement, but it is hard to make it happen; upstreams change over time, which makes such implications happen sooner or later in one place or the other. Which becomes visible over time... The manpower that we have to keep implications away are limited; to make a change to those implications, one could write code as suggested. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-user] Systemd upower
On 06/03/2014 07:24 PM, Jim Burwell wrote:
FWIW, on my system, I had to mask sys-apps/gentoo-systemd-integration
for it to merge the udev update w/o trying to pull in systemd, et al. i
didn't deep dive on what was trying to pull that in, but masking it
(plus a ton of other stuff I have masked) prevented portage from trying
to build a systemd based system.
OK - I have followed the advice given in eselect news read; I have
also followed the advice on this and the related thread today and
uninstalled sys-power/upower and installed
sys-power/upower-pm-utils. That didn't work. Then, given the above,
I have masked (first) sys-apps/gentoo-systemd-integration and when
that had no effect, masked sys-apps/systemd.
I am still hard-blocked out of updating:
Calculating dependencies... done!
[ebuild N ] sys-libs/libseccomp-2.1.1 USE=-static-libs 111 kB
[ebuild r U ] app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE=-doc
-examples -static-libs {-test} 7,484 kB
[ebuild R] dev-libs/glib-2.38.2-r1:2 USE=mime%* -debug (-fam)
(-selinux) -static-libs -systemtap {-test} -utils -xattr ABI_X86=(64)
(-32) (-x32) PYTHON_TARGETS=python2_7 (-python2_6) 0 kB
[ebuild R ~] x11-libs/libmatewnck-1.6.1:1::mate-overlay
[1.6.1:0::gentoo] USE=introspection startup-notification (-X%*) 0 kB
[ebuild rR] net-print/cups-filters-1.0.53 USE=dbus foomatic jpeg
-perl -png -static-libs -tiff -zeroconf 0 kB
[ebuild U ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 kB
[ebuild N#] sys-apps/systemd-212-r5:0/2 USE=acl filecaps
firmware-loader kmod pam policykit seccomp -audit -cryptsetup -doc
-gcrypt -gudev -http -introspection (-kdbus) -lzma -python -qrcode
(-selinux) (-ssl) {-test} -vanilla -xattr ABI_X86=(64) (-32) (-x32)
PYTHON_SINGLE_TARGET=python2_7 -python3_2 -python3_3
PYTHON_TARGETS=python2_7 python3_3 -python3_2 0 kB
[ebuild N#] sys-apps/gentoo-systemd-integration-4 52 kB
[ebuild N ] virtual/libudev-208:0/1 USE=-static-libs
ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild U ] virtual/udev-208-r2 [208-r1] USE=gudev -introspection
-static-libs (-kmod%*) (-selinux%) ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild N ] sys-power/upower-0.9.23-r3 USE=introspection -doc
-ios 0 kB
[uninstall ] sys-power/upower-pm-utils-0.9.23 USE=introspection
-doc -ios
[blocks b ] sys-power/upower (sys-power/upower is blocking
sys-power/upower-pm-utils-0.9.23)
[blocks B ] sys-apps/systemd (sys-apps/systemd is blocking
sys-fs/udev-212-r1)
[blocks B ] sys-apps/gentoo-systemd-integration
(sys-apps/gentoo-systemd-integration is blocking sys-fs/udev-212-r1)
[blocks B ] sys-fs/udev (sys-fs/udev is blocking
sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
Total: 11 packages (3 upgrades, 5 new, 3 reinstalls, 1 uninstall), Size
of downloads: 45,580 kB
Conflict: 4 blocks (3 unsatisfied)
I'm not sure what else to mask/uninstall/reinstall at this point. Any
suggestions?
Re: [gentoo-user] Systemd upower
On Tue, Jun 3, 2014 at 7:58 PM, Dutch Ingraham s...@gmx.us wrote:
On 06/03/2014 07:24 PM, Jim Burwell wrote:
FWIW, on my system, I had to mask sys-apps/gentoo-systemd-integration
for it to merge the udev update w/o trying to pull in systemd, et al. i
didn't deep dive on what was trying to pull that in, but masking it
(plus a ton of other stuff I have masked) prevented portage from trying
to build a systemd based system.
OK - I have followed the advice given in eselect news read; I have
also followed the advice on this and the related thread today and
uninstalled sys-power/upower and installed
sys-power/upower-pm-utils. That didn't work. Then, given the above,
I have masked (first) sys-apps/gentoo-systemd-integration and when
that had no effect, masked sys-apps/systemd.
I am still hard-blocked out of updating:
Calculating dependencies... done!
[ebuild N ] sys-libs/libseccomp-2.1.1 USE=-static-libs 111 kB
[ebuild r U ] app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE=-doc
-examples -static-libs {-test} 7,484 kB
[ebuild R] dev-libs/glib-2.38.2-r1:2 USE=mime%* -debug (-fam)
(-selinux) -static-libs -systemtap {-test} -utils -xattr ABI_X86=(64)
(-32) (-x32) PYTHON_TARGETS=python2_7 (-python2_6) 0 kB
[ebuild R ~] x11-libs/libmatewnck-1.6.1:1::mate-overlay
[1.6.1:0::gentoo] USE=introspection startup-notification (-X%*) 0 kB
[ebuild rR] net-print/cups-filters-1.0.53 USE=dbus foomatic jpeg
-perl -png -static-libs -tiff -zeroconf 0 kB
[ebuild U ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 kB
[ebuild N#] sys-apps/systemd-212-r5:0/2 USE=acl filecaps
firmware-loader kmod pam policykit seccomp -audit -cryptsetup -doc
-gcrypt -gudev -http -introspection (-kdbus) -lzma -python -qrcode
(-selinux) (-ssl) {-test} -vanilla -xattr ABI_X86=(64) (-32) (-x32)
PYTHON_SINGLE_TARGET=python2_7 -python3_2 -python3_3
PYTHON_TARGETS=python2_7 python3_3 -python3_2 0 kB
[ebuild N#] sys-apps/gentoo-systemd-integration-4 52 kB
[ebuild N ] virtual/libudev-208:0/1 USE=-static-libs
ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild U ] virtual/udev-208-r2 [208-r1] USE=gudev -introspection
-static-libs (-kmod%*) (-selinux%) ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild N ] sys-power/upower-0.9.23-r3 USE=introspection -doc
-ios 0 kB
[uninstall ] sys-power/upower-pm-utils-0.9.23 USE=introspection
-doc -ios
[blocks b ] sys-power/upower (sys-power/upower is blocking
sys-power/upower-pm-utils-0.9.23)
[blocks B ] sys-apps/systemd (sys-apps/systemd is blocking
sys-fs/udev-212-r1)
[blocks B ] sys-apps/gentoo-systemd-integration
(sys-apps/gentoo-systemd-integration is blocking sys-fs/udev-212-r1)
[blocks B ] sys-fs/udev (sys-fs/udev is blocking
sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
Total: 11 packages (3 upgrades, 5 new, 3 reinstalls, 1 uninstall), Size
of downloads: 45,580 kB
Conflict: 4 blocks (3 unsatisfied)
I'm not sure what else to mask/uninstall/reinstall at this point. Any
suggestions?
Something is pulling upower. You need to find out what; supposedly
everything in the tree already should handle upower-pm-utils as a
upower replacement.
Perhaps try to sync again?
Regards.
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México
Re: [gentoo-user] Systemd upower
On 06/03/2014 11:14 AM, Samuli Suominen wrote: 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.) If someone is going to change the basic rules and expectations of a system in radical ways it is *not* unreasonable to expect that change to be explained in an easy-to-find way (and not buried in a changelog.) -- G.Wolfe Woodbury
Re: [gentoo-user] Systemd upower
On 06/03/2014 01:08 PM, Canek Peláez Valdés wrote: Who is forcing anything? pm-utils has been unmaintained FOR FIVE YEARS. Any project that decides to stop using it is making just the right decision; UPower just did the correct thing. And systemd had *nothing* to do with it, except for providing a better, more reliable alternative. 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. snip There is no conspiracy here (although for *SURE* there are scare-mongering conspiracy theorists); there is (sic) only developers working in the best possible implementation for our plumbing layer, and other developers realizing that, in Linux at least, supporting anything besides systemd is a freakin' waste of time and resources. Again; you don't like it? Then do something about it instead of posting in *-user lists. You are certainly keen in pressing your *opinions* here there and everywhere. Sure, systemd is a more elegant solution than the patchworks that have been applied several times to the original SysV concept. However, the implementors and advocates of systemd have stepped on the concerns and violated certain basic freedoms of many folks in their zeal to see their vision become predominate. -- G.Wolfe Woodbury
Re: [gentoo-user] Systemd upower
On 06/03/2014 09:08 PM, Canek Peláez Valdés wrote:
On Tue, Jun 3, 2014 at 7:58 PM, Dutch Ingraham s...@gmx.us wrote:
On 06/03/2014 07:24 PM, Jim Burwell wrote:
FWIW, on my system, I had to mask sys-apps/gentoo-systemd-integration
for it to merge the udev update w/o trying to pull in systemd, et al. i
didn't deep dive on what was trying to pull that in, but masking it
(plus a ton of other stuff I have masked) prevented portage from trying
to build a systemd based system.
OK - I have followed the advice given in eselect news read; I have
also followed the advice on this and the related thread today and
uninstalled sys-power/upower and installed
sys-power/upower-pm-utils. That didn't work. Then, given the above,
I have masked (first) sys-apps/gentoo-systemd-integration and when
that had no effect, masked sys-apps/systemd.
I am still hard-blocked out of updating:
Calculating dependencies... done!
[ebuild N ] sys-libs/libseccomp-2.1.1 USE=-static-libs 111 kB
[ebuild r U ] app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE=-doc
-examples -static-libs {-test} 7,484 kB
[ebuild R] dev-libs/glib-2.38.2-r1:2 USE=mime%* -debug (-fam)
(-selinux) -static-libs -systemtap {-test} -utils -xattr ABI_X86=(64)
(-32) (-x32) PYTHON_TARGETS=python2_7 (-python2_6) 0 kB
[ebuild R ~] x11-libs/libmatewnck-1.6.1:1::mate-overlay
[1.6.1:0::gentoo] USE=introspection startup-notification (-X%*) 0 kB
[ebuild rR] net-print/cups-filters-1.0.53 USE=dbus foomatic jpeg
-perl -png -static-libs -tiff -zeroconf 0 kB
[ebuild U ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 kB
[ebuild N#] sys-apps/systemd-212-r5:0/2 USE=acl filecaps
firmware-loader kmod pam policykit seccomp -audit -cryptsetup -doc
-gcrypt -gudev -http -introspection (-kdbus) -lzma -python -qrcode
(-selinux) (-ssl) {-test} -vanilla -xattr ABI_X86=(64) (-32) (-x32)
PYTHON_SINGLE_TARGET=python2_7 -python3_2 -python3_3
PYTHON_TARGETS=python2_7 python3_3 -python3_2 0 kB
[ebuild N#] sys-apps/gentoo-systemd-integration-4 52 kB
[ebuild N ] virtual/libudev-208:0/1 USE=-static-libs
ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild U ] virtual/udev-208-r2 [208-r1] USE=gudev -introspection
-static-libs (-kmod%*) (-selinux%) ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild N ] sys-power/upower-0.9.23-r3 USE=introspection -doc
-ios 0 kB
[uninstall ] sys-power/upower-pm-utils-0.9.23 USE=introspection
-doc -ios
[blocks b ] sys-power/upower (sys-power/upower is blocking
sys-power/upower-pm-utils-0.9.23)
[blocks B ] sys-apps/systemd (sys-apps/systemd is blocking
sys-fs/udev-212-r1)
[blocks B ] sys-apps/gentoo-systemd-integration
(sys-apps/gentoo-systemd-integration is blocking sys-fs/udev-212-r1)
[blocks B ] sys-fs/udev (sys-fs/udev is blocking
sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
Total: 11 packages (3 upgrades, 5 new, 3 reinstalls, 1 uninstall), Size
of downloads: 45,580 kB
Conflict: 4 blocks (3 unsatisfied)
I'm not sure what else to mask/uninstall/reinstall at this point. Any
suggestions?
Something is pulling upower. You need to find out what; supposedly
everything in the tree already should handle upower-pm-utils as a
upower replacement.
Perhaps try to sync again?
Regards.
Thanks, Canek.
I did re-sync, with the same results. I also ran a equery depends
upower with the following result:
dutch@gentoo ~ $ sudo equery depends upower
* These packages depend on upower:
mate-base/mate-applets-1.6.2-r1 (=sys-power/upower-0.9.4)
(sys-power/upower-0.99)
mate-base/mate-session-manager-1.6.1-r1 (=sys-power/upower-0.9.0)
mate-extra/mate-power-manager-1.6.3 (=sys-power/upower-0.9.1)
xfce-base/xfce4-session-4.10.1-r1 (udev ? sys-power/upower-0.99)
xfce-extra/xfce4-power-manager-1.2.0-r2 (sys-power/upower-0.99)
dutch@gentoo ~ $
But as you said, upower-pm-utils should be handling these
dependencies. Is anyone else having these problems with MATE or XFCE?
Re: [gentoo-user] Systemd upower
On 06/03/2014 09:48 PM, Dutch Ingraham wrote:
On 06/03/2014 09:08 PM, Canek Peláez Valdés wrote:
On Tue, Jun 3, 2014 at 7:58 PM, Dutch Ingraham s...@gmx.us wrote:
On 06/03/2014 07:24 PM, Jim Burwell wrote:
FWIW, on my system, I had to mask sys-apps/gentoo-systemd-integration
for it to merge the udev update w/o trying to pull in systemd, et al. i
didn't deep dive on what was trying to pull that in, but masking it
(plus a ton of other stuff I have masked) prevented portage from trying
to build a systemd based system.
OK - I have followed the advice given in eselect news read; I have
also followed the advice on this and the related thread today and
uninstalled sys-power/upower and installed
sys-power/upower-pm-utils. That didn't work. Then, given the above,
I have masked (first) sys-apps/gentoo-systemd-integration and when
that had no effect, masked sys-apps/systemd.
I am still hard-blocked out of updating:
Calculating dependencies... done!
[ebuild N ] sys-libs/libseccomp-2.1.1 USE=-static-libs 111 kB
[ebuild r U ] app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE=-doc
-examples -static-libs {-test} 7,484 kB
[ebuild R] dev-libs/glib-2.38.2-r1:2 USE=mime%* -debug (-fam)
(-selinux) -static-libs -systemtap {-test} -utils -xattr ABI_X86=(64)
(-32) (-x32) PYTHON_TARGETS=python2_7 (-python2_6) 0 kB
[ebuild R ~] x11-libs/libmatewnck-1.6.1:1::mate-overlay
[1.6.1:0::gentoo] USE=introspection startup-notification (-X%*) 0 kB
[ebuild rR] net-print/cups-filters-1.0.53 USE=dbus foomatic jpeg
-perl -png -static-libs -tiff -zeroconf 0 kB
[ebuild U ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 kB
[ebuild N#] sys-apps/systemd-212-r5:0/2 USE=acl filecaps
firmware-loader kmod pam policykit seccomp -audit -cryptsetup -doc
-gcrypt -gudev -http -introspection (-kdbus) -lzma -python -qrcode
(-selinux) (-ssl) {-test} -vanilla -xattr ABI_X86=(64) (-32) (-x32)
PYTHON_SINGLE_TARGET=python2_7 -python3_2 -python3_3
PYTHON_TARGETS=python2_7 python3_3 -python3_2 0 kB
[ebuild N#] sys-apps/gentoo-systemd-integration-4 52 kB
[ebuild N ] virtual/libudev-208:0/1 USE=-static-libs
ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild U ] virtual/udev-208-r2 [208-r1] USE=gudev -introspection
-static-libs (-kmod%*) (-selinux%) ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild N ] sys-power/upower-0.9.23-r3 USE=introspection -doc
-ios 0 kB
[uninstall ] sys-power/upower-pm-utils-0.9.23 USE=introspection
-doc -ios
[blocks b ] sys-power/upower (sys-power/upower is blocking
sys-power/upower-pm-utils-0.9.23)
[blocks B ] sys-apps/systemd (sys-apps/systemd is blocking
sys-fs/udev-212-r1)
[blocks B ] sys-apps/gentoo-systemd-integration
(sys-apps/gentoo-systemd-integration is blocking sys-fs/udev-212-r1)
[blocks B ] sys-fs/udev (sys-fs/udev is blocking
sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
Total: 11 packages (3 upgrades, 5 new, 3 reinstalls, 1 uninstall), Size
of downloads: 45,580 kB
Conflict: 4 blocks (3 unsatisfied)
I'm not sure what else to mask/uninstall/reinstall at this point. Any
suggestions?
Something is pulling upower. You need to find out what; supposedly
everything in the tree already should handle upower-pm-utils as a
upower replacement.
Perhaps try to sync again?
Regards.
Thanks, Canek.
I did re-sync, with the same results. I also ran a equery depends
upower with the following result:
dutch@gentoo ~ $ sudo equery depends upower
* These packages depend on upower:
mate-base/mate-applets-1.6.2-r1 (=sys-power/upower-0.9.4)
(sys-power/upower-0.99)
mate-base/mate-session-manager-1.6.1-r1 (=sys-power/upower-0.9.0)
mate-extra/mate-power-manager-1.6.3 (=sys-power/upower-0.9.1)
xfce-base/xfce4-session-4.10.1-r1 (udev ? sys-power/upower-0.99)
xfce-extra/xfce4-power-manager-1.2.0-r2 (sys-power/upower-0.99)
dutch@gentoo ~ $
But as you said, upower-pm-utils should be handling these
dependencies. Is anyone else having these problems with MATE or XFCE?
Do you have newer sys-fs/udev masked by chance? What version do you have
installed? I noticed the MATE stuff is in an overlay, so it might take a
bit longer for them to make things right.
Re: [gentoo-user] Systemd upower
On Tue, Jun 3, 2014 at 8:37 PM, Greg Woodbury redwo...@gmail.com wrote: On 06/03/2014 01:08 PM, Canek Peláez Valdés wrote: Who is forcing anything? pm-utils has been unmaintained FOR FIVE YEARS. Any project that decides to stop using it is making just the right decision; UPower just did the correct thing. And systemd had *nothing* to do with it, except for providing a better, more reliable alternative. 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. snip There is no conspiracy here (although for *SURE* there are scare-mongering conspiracy theorists); there is (sic) only developers (Sorry; I'm not a native English writer). working in the best possible implementation for our plumbing layer, and other developers realizing that, in Linux at least, supporting anything besides systemd is a freakin' waste of time and resources. Again; you don't like it? Then do something about it instead of posting in *-user lists. You are certainly keen in pressing your *opinions* here there and everywhere. Well, I also did what I could to help systemd in Gentoo get to its currently state. Certainly I did not *just* complained on this mailing list about why I could not use systemd and uninstall OpenRC; I helped make it happen. And it worked. Sure, systemd is a more elegant solution than the patchworks that have been applied several times to the original SysV concept. Glad to see you recognize that. However, the implementors and advocates of systemd have stepped on the concerns and violated certain basic freedoms of many folks in their zeal to see their vision become predominate. Oh FFS. What freedoms have you had violated? The freedom to mandate what other developers should write, or what packages they can use as hard dependencies? You never had that freedom. That's the developer freedom; if you want some of that, become a developer. Or help Samuli to maintain upower-pm-utils; that would be *much* more helpful than spreding FUD about cabals and conspiracies. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] Systemd upower
On Tue, Jun 3, 2014 at 8:48 PM, Dutch Ingraham s...@gmx.us wrote:
On 06/03/2014 09:08 PM, Canek Peláez Valdés wrote:
On Tue, Jun 3, 2014 at 7:58 PM, Dutch Ingraham s...@gmx.us wrote:
On 06/03/2014 07:24 PM, Jim Burwell wrote:
FWIW, on my system, I had to mask sys-apps/gentoo-systemd-integration
for it to merge the udev update w/o trying to pull in systemd, et al. i
didn't deep dive on what was trying to pull that in, but masking it
(plus a ton of other stuff I have masked) prevented portage from trying
to build a systemd based system.
OK - I have followed the advice given in eselect news read; I have
also followed the advice on this and the related thread today and
uninstalled sys-power/upower and installed
sys-power/upower-pm-utils. That didn't work. Then, given the above,
I have masked (first) sys-apps/gentoo-systemd-integration and when
that had no effect, masked sys-apps/systemd.
I am still hard-blocked out of updating:
Calculating dependencies... done!
[ebuild N ] sys-libs/libseccomp-2.1.1 USE=-static-libs 111 kB
[ebuild r U ] app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE=-doc
-examples -static-libs {-test} 7,484 kB
[ebuild R] dev-libs/glib-2.38.2-r1:2 USE=mime%* -debug (-fam)
(-selinux) -static-libs -systemtap {-test} -utils -xattr ABI_X86=(64)
(-32) (-x32) PYTHON_TARGETS=python2_7 (-python2_6) 0 kB
[ebuild R ~] x11-libs/libmatewnck-1.6.1:1::mate-overlay
[1.6.1:0::gentoo] USE=introspection startup-notification (-X%*) 0 kB
[ebuild rR] net-print/cups-filters-1.0.53 USE=dbus foomatic jpeg
-perl -png -static-libs -tiff -zeroconf 0 kB
[ebuild U ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 kB
[ebuild N#] sys-apps/systemd-212-r5:0/2 USE=acl filecaps
firmware-loader kmod pam policykit seccomp -audit -cryptsetup -doc
-gcrypt -gudev -http -introspection (-kdbus) -lzma -python -qrcode
(-selinux) (-ssl) {-test} -vanilla -xattr ABI_X86=(64) (-32) (-x32)
PYTHON_SINGLE_TARGET=python2_7 -python3_2 -python3_3
PYTHON_TARGETS=python2_7 python3_3 -python3_2 0 kB
[ebuild N#] sys-apps/gentoo-systemd-integration-4 52 kB
[ebuild N ] virtual/libudev-208:0/1 USE=-static-libs
ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild U ] virtual/udev-208-r2 [208-r1] USE=gudev -introspection
-static-libs (-kmod%*) (-selinux%) ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild N ] sys-power/upower-0.9.23-r3 USE=introspection -doc
-ios 0 kB
[uninstall ] sys-power/upower-pm-utils-0.9.23 USE=introspection
-doc -ios
[blocks b ] sys-power/upower (sys-power/upower is blocking
sys-power/upower-pm-utils-0.9.23)
[blocks B ] sys-apps/systemd (sys-apps/systemd is blocking
sys-fs/udev-212-r1)
[blocks B ] sys-apps/gentoo-systemd-integration
(sys-apps/gentoo-systemd-integration is blocking sys-fs/udev-212-r1)
[blocks B ] sys-fs/udev (sys-fs/udev is blocking
sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
Total: 11 packages (3 upgrades, 5 new, 3 reinstalls, 1 uninstall), Size
of downloads: 45,580 kB
Conflict: 4 blocks (3 unsatisfied)
I'm not sure what else to mask/uninstall/reinstall at this point. Any
suggestions?
Something is pulling upower. You need to find out what; supposedly
everything in the tree already should handle upower-pm-utils as a
upower replacement.
Perhaps try to sync again?
Regards.
Thanks, Canek.
I did re-sync, with the same results. I also ran a equery depends
upower with the following result:
dutch@gentoo ~ $ sudo equery depends upower
* These packages depend on upower:
mate-base/mate-applets-1.6.2-r1 (=sys-power/upower-0.9.4)
(sys-power/upower-0.99)
mate-base/mate-session-manager-1.6.1-r1 (=sys-power/upower-0.9.0)
mate-extra/mate-power-manager-1.6.3 (=sys-power/upower-0.9.1)
xfce-base/xfce4-session-4.10.1-r1 (udev ? sys-power/upower-0.99)
xfce-extra/xfce4-power-manager-1.2.0-r2 (sys-power/upower-0.99)
dutch@gentoo ~ $
But as you said, upower-pm-utils should be handling these
dependencies. Is anyone else having these problems with MATE or XFCE?
If, as Michael says, you are using MATE from an overlay, then it will
take a while for all of them to sync with the new
upower/upower-pm-utils dichotomy.
Regards.
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México
[gentoo-user] udev/systemd-blocker
Hi, while updateing I got this blocker: (sys-fs/udev-212-r1::gentoo, installed) pulled in by =sys-fs/udev-208-r1:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,gudev,introspection?,static-libs?] (=sys-fs/udev-208-r1:0/0[abi_x86_64(-),gudev]) required by (virtual/libgudev-208::gentoo, ebuild scheduled for merge) =sys-fs/udev-208 required by (virtual/udev-208-r2::gentoo, ebuild scheduled for merge) sys-fs/udev required by @selected =sys-fs/udev-208:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,static-libs?] (=sys-fs/udev-208:0/0[abi_x86_64(-)]) required by (virtual/libudev-208::gentoo, ebuild scheduled for merge) (sys-apps/systemd-212-r5::gentoo, ebuild scheduled for merge) pulled in by =sys-apps/systemd-200 required by (sys-power/upower-0.9.23-r3::gentoo, ebuild scheduled for merge) =sys-apps/systemd-207 required by (sys-apps/gentoo-systemd-integration-4::gentoo, ebuild scheduled for merge) Since both udev and systemd seem to me vitalimportant fo rthe health of the system I better want to ask how to proceed in this case...?? Best regards, mcc
Re: [gentoo-user] Systemd upower
On 06/03/2014 09:57 PM, Michael Cook wrote:
On 06/03/2014 09:48 PM, Dutch Ingraham wrote:
On 06/03/2014 09:08 PM, Canek Peláez Valdés wrote:
On Tue, Jun 3, 2014 at 7:58 PM, Dutch Ingraham s...@gmx.us wrote:
On 06/03/2014 07:24 PM, Jim Burwell wrote:
FWIW, on my system, I had to mask
sys-apps/gentoo-systemd-integration
for it to merge the udev update w/o trying to pull in systemd, et
al. i
didn't deep dive on what was trying to pull that in, but masking it
(plus a ton of other stuff I have masked) prevented portage from
trying
to build a systemd based system.
OK - I have followed the advice given in eselect news read; I have
also followed the advice on this and the related thread today and
uninstalled sys-power/upower and installed
sys-power/upower-pm-utils. That didn't work. Then, given the above,
I have masked (first) sys-apps/gentoo-systemd-integration and when
that had no effect, masked sys-apps/systemd.
I am still hard-blocked out of updating:
Calculating dependencies... done!
[ebuild N ] sys-libs/libseccomp-2.1.1 USE=-static-libs 111 kB
[ebuild r U ] app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE=-doc
-examples -static-libs {-test} 7,484 kB
[ebuild R] dev-libs/glib-2.38.2-r1:2 USE=mime%* -debug (-fam)
(-selinux) -static-libs -systemtap {-test} -utils -xattr ABI_X86=(64)
(-32) (-x32) PYTHON_TARGETS=python2_7 (-python2_6) 0 kB
[ebuild R ~] x11-libs/libmatewnck-1.6.1:1::mate-overlay
[1.6.1:0::gentoo] USE=introspection startup-notification (-X%*) 0 kB
[ebuild rR] net-print/cups-filters-1.0.53 USE=dbus foomatic jpeg
-perl -png -static-libs -tiff -zeroconf 0 kB
[ebuild U ] net-print/foomatic-db-4.0.20140105 [4.0.20120831]
37,935 kB
[ebuild N#] sys-apps/systemd-212-r5:0/2 USE=acl filecaps
firmware-loader kmod pam policykit seccomp -audit -cryptsetup -doc
-gcrypt -gudev -http -introspection (-kdbus) -lzma -python -qrcode
(-selinux) (-ssl) {-test} -vanilla -xattr ABI_X86=(64) (-32) (-x32)
PYTHON_SINGLE_TARGET=python2_7 -python3_2 -python3_3
PYTHON_TARGETS=python2_7 python3_3 -python3_2 0 kB
[ebuild N#] sys-apps/gentoo-systemd-integration-4 52 kB
[ebuild N ] virtual/libudev-208:0/1 USE=-static-libs
ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild U ] virtual/udev-208-r2 [208-r1] USE=gudev -introspection
-static-libs (-kmod%*) (-selinux%) ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild N ] sys-power/upower-0.9.23-r3 USE=introspection -doc
-ios 0 kB
[uninstall ] sys-power/upower-pm-utils-0.9.23 USE=introspection
-doc -ios
[blocks b ] sys-power/upower (sys-power/upower is blocking
sys-power/upower-pm-utils-0.9.23)
[blocks B ] sys-apps/systemd (sys-apps/systemd is blocking
sys-fs/udev-212-r1)
[blocks B ] sys-apps/gentoo-systemd-integration
(sys-apps/gentoo-systemd-integration is blocking sys-fs/udev-212-r1)
[blocks B ] sys-fs/udev (sys-fs/udev is blocking
sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
Total: 11 packages (3 upgrades, 5 new, 3 reinstalls, 1 uninstall), Size
of downloads: 45,580 kB
Conflict: 4 blocks (3 unsatisfied)
I'm not sure what else to mask/uninstall/reinstall at this point. Any
suggestions?
Something is pulling upower. You need to find out what; supposedly
everything in the tree already should handle upower-pm-utils as a
upower replacement.
Perhaps try to sync again?
Regards.
Thanks, Canek.
I did re-sync, with the same results. I also ran a equery depends
upower with the following result:
dutch@gentoo ~ $ sudo equery depends upower
* These packages depend on upower:
mate-base/mate-applets-1.6.2-r1 (=sys-power/upower-0.9.4)
(sys-power/upower-0.99)
mate-base/mate-session-manager-1.6.1-r1 (=sys-power/upower-0.9.0)
mate-extra/mate-power-manager-1.6.3 (=sys-power/upower-0.9.1)
xfce-base/xfce4-session-4.10.1-r1 (udev ? sys-power/upower-0.99)
xfce-extra/xfce4-power-manager-1.2.0-r2 (sys-power/upower-0.99)
dutch@gentoo ~ $
But as you said, upower-pm-utils should be handling these
dependencies. Is anyone else having these problems with MATE or XFCE?
Do you have newer sys-fs/udev masked by chance? What version do you have
installed? I noticed the MATE stuff is in an overlay, so it might take a
bit longer for them to make things right.
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.
Re: [gentoo-user] udev/systemd-blocker
On Tue, Jun 3, 2014 at 9:11 PM, meino.cra...@gmx.de wrote: Hi, while updateing I got this blocker: (sys-fs/udev-212-r1::gentoo, installed) pulled in by =sys-fs/udev-208-r1:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,gudev,introspection?,static-libs?] (=sys-fs/udev-208-r1:0/0[abi_x86_64(-),gudev]) required by (virtual/libgudev-208::gentoo, ebuild scheduled for merge) =sys-fs/udev-208 required by (virtual/udev-208-r2::gentoo, ebuild scheduled for merge) sys-fs/udev required by @selected =sys-fs/udev-208:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,static-libs?] (=sys-fs/udev-208:0/0[abi_x86_64(-)]) required by (virtual/libudev-208::gentoo, ebuild scheduled for merge) (sys-apps/systemd-212-r5::gentoo, ebuild scheduled for merge) pulled in by =sys-apps/systemd-200 required by (sys-power/upower-0.9.23-r3::gentoo, ebuild scheduled for merge) =sys-apps/systemd-207 required by (sys-apps/gentoo-systemd-integration-4::gentoo, ebuild scheduled for merge) Since both udev and systemd seem to me vitalimportant fo rthe health of the system I better want to ask how to proceed in this case...?? Did you tried the following? emerge -C sys-power/upower emerge -1v sys-power/upower-pm-utils And then trying the update again? Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] udev/systemd-blocker
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/04/2014 12:11 PM, meino.cra...@gmx.de wrote: while updateing I got this blocker: In short, sys-power/upower has changed to no longer support the unmaintained sys-power/pm-tools and instead depend on systemd. To remain using upower with pm-utils (and not requiring systemd components), run `emerge -C sys-power/upower emerge -1 sys-power/upower-pm-utils` then run your update as per normal. If you prefer, you could install systemd (note that having it installed doesn't necessarily mean you use systemd as your init system) - see [1]. For more information on what's happening, see the Systemd upower thread currently being discussed in this mailing list. - -wraeth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlOOgpoACgkQXcRKerLZ91nRKAD+O0Q7hbKnCYPBv8GFXFXpoBwr r2S0chVyvRk16VwkuIEA/3jHrush+7yt+DEY4R7Drxol+MGwSW604a0OBv7ZeDNo =yqX0 -END PGP SIGNATURE-
Re: [gentoo-user] udev/systemd-blocker
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/04/2014 12:21 PM, wraeth wrote: If you prefer, you could install systemd (note that having it installed doesn't necessarily mean you use systemd as your init system) - see [1]. May help if I include my reference links... :| [1] - https://wiki.gentoo.org/wiki/Systemd - -wraeth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlOOgxsACgkQXcRKerLZ91n73QD/Wg/SmdpNSRV++lBSqs73FjjN CtqWMPgbSXmyMD50w8sA/0Dpv6nyPqf8r/1Q8z87fzOm26HfK6IMCFbaAe0d2azc =Ffy/ -END PGP SIGNATURE-
Re: [gentoo-user] udev/systemd-blocker
wraeth wra...@wraeth.id.au [14-06-04 04:24]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/04/2014 12:21 PM, wraeth wrote: If you prefer, you could install systemd (note that having it installed doesn't necessarily mean you use systemd as your init system) - see [1]. May help if I include my reference links... :| [1] - https://wiki.gentoo.org/wiki/Systemd - -wraeth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlOOgxsACgkQXcRKerLZ91n73QD/Wg/SmdpNSRV++lBSqs73FjjN CtqWMPgbSXmyMD50w8sA/0Dpv6nyPqf8r/1Q8z87fzOm26HfK6IMCFbaAe0d2azc =Ffy/ -END PGP SIGNATURE- Hi, thanks to you all! :) I overlocked the 'upower'-thingy in the blockers list...sorry... Have a nice day! Best regards, mcc
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
