Re: [gentoo-user] Systemd upower
On Mon, 9 Jun 2014 18:43:04 + Alan Mackenzie a...@muc.de wrote: Hello, Rick, thanks for the reply. [... cut all the emerge output, quotes and text in between ...] What the heck is going on, when a package management system can't even make a decision on which version of perl to use, and stick to that decision? And it can only be described as a bug, that the gobbledegook (no parents that aren't satisfied by other packages in this slot) passes for a supposedly informative message. Anyhow, thanks indeed for the help. Maybe, someday in the distant future, I'll succeed in updating my Gentoo system after all. To start with, please avoid using -p (--pretend); sometimes emerge will continue regardless of what is displayed, which can help you forward. Though, that still might imply that you need to resolve that output. A very first thing you'll notice is that the Perl conflict seems to suggest that there is an old Perl version installed and a new Perl version scheduled to be merged. When you do a merge of an individual package, it won't consider the reverse dependencies of Perl and therefore it will result in a conflict instead of upgrading the reverse dependencies of Perl. A solution to this is to upgrade your entire system (@world) such that your entire system is in a consistent and upgraded state; however, this only is a way forward as long as it doesn't bring up a conflict. So ... In order to proceed here, you have to unmerge sys-power/upower (which you've already done) and mask sys-power/upower as well as sys-apps/systemd (yet to do), then an `emerge -auvDNt @world` should help you forward; if not, its output can help you bring it forward. If there is a mention about backtracking, try --backtrack=9001 or so; also, if it still tries to bring in sys-power/upower then you might have an overlay that attempts to do this (sync and/or contact author). As a result of the unmerge and mask, it picks upower-pm-utils for you. Have a great evening! You too. -- 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 Tue, Jun 03, 2014 at 05:11:32PM +0200, Silvio Siefke wrote:
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.
I do this:
emerge --unmerge upower
emerge -1vp sys-power/upower-pm-utils
, and I still get portage threatening to merge that other init system:
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-python/lxml-3.3.5 USE=threads -beautifulsoup3 -doc
-examples PYTHON_TARGETS=python2_7 python3_3 -python3_2 (-python3_4) 3,387 kB
[ebuild N ] sys-apps/systemd-212-r5:0/2 USE=acl filecaps
firmware-loader gudev introspection kmod pam policykit python seccomp -audit
-cryptsetup -doc -gcrypt -http (-kdbus) -lzma -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 2,659 kB
[ebuild N ] sys-apps/gentoo-systemd-integration-4 52 kB
[ebuild N ] virtual/libgudev-208 USE=introspection -static-libs
ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild N ] sys-power/upower-pm-utils-0.9.23 USE=introspection -doc
-ios 416 kB
[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/systemd (sys-apps/systemd is blocking
sys-fs/udev-208)
Total: 5 packages (5 new), Size of downloads: 6,513 kB
Conflict: 2 blocks (2 unsatisfied)
Would somebody please help me sort this out. What am I doing wrong?
Where is systemd coming from? I look in upower-pm-utils-0.9.23.ebuild,
and the only reference to systemd seems to be right at the beginning:
EAPI=5
inherit eutils systemd
(, plus a couple of inconsequential references near the end.) I'm not
quite sure exactly what inherit means here, but the FM (man (5) ebuild)
says:
Inherit is portage's maintenance of extra classes of functions that
are external to ebuilds and provided as inheritable capabilities and
data. They define functions and set data types as drop-in replacements,
expanded, and simplified routines for extremely common tasks to
streamline the build process. Call to inherit cannot depend on conditions
which can vary in given ebuild. Specification of the eclasses contains
only their name and not the .eclass extension. Also note that the
inherit statement must come before other variable declarations unless
these variables are used in global scope of eclasses.
, which, being vague, leaves me still unsure what inherit means. ;-(
Is there any documentation anywhere of what inherit actually DOES?
What am I doing wrong?
Thanks for help Nice Day
Silvio
--
Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Systemd upower
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/09/2014 11:34 AM, Alan Mackenzie wrote:
On Tue, Jun 03, 2014 at 05:11:32PM +0200, Silvio Siefke wrote:
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.
I do this:
emerge --unmerge upower
emerge -1vp sys-power/upower-pm-utils
, and I still get portage threatening to merge that other init system:
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-python/lxml-3.3.5 USE=threads -beautifulsoup3 -doc
-examples PYTHON_TARGETS=python2_7 python3_3 -python3_2 (-python3_4) 3,387
kB
[ebuild N ] sys-apps/systemd-212-r5:0/2 USE=acl filecaps
firmware-loader gudev introspection kmod pam policykit python seccomp -audit
-cryptsetup -doc -gcrypt -http (-kdbus) -lzma -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 2,659 kB
[ebuild N ] sys-apps/gentoo-systemd-integration-4 52 kB
[ebuild N ] virtual/libgudev-208 USE=introspection -static-libs
ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild N ] sys-power/upower-pm-utils-0.9.23 USE=introspection
-doc -ios 416 kB
[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/systemd (sys-apps/systemd is blocking
sys-fs/udev-208)
Total: 5 packages (5 new), Size of downloads: 6,513 kB
Conflict: 2 blocks (2 unsatisfied)
It would be helpful to build with --tree so we can get some idea of what
is depending on systemd.
Would somebody please help me sort this out. What am I doing wrong?
Where is systemd coming from? I look in upower-pm-utils-0.9.23.ebuild,
and the only reference to systemd seems to be right at the beginning:
EAPI=5
inherit eutils systemd
This is pulling in an eclass to use it's code in the ebuild. You can
see them in /usr/portage/eclass/*.eclass
Thanks,
Zero
(, plus a couple of inconsequential references near the end.) I'm not
quite sure exactly what inherit means here, but the FM (man (5) ebuild)
says:
Inherit is portage's maintenance of extra classes of functions that
are external to ebuilds and provided as inheritable capabilities and
data. They define functions and set data types as drop-in replacements,
expanded, and simplified routines for extremely common tasks to
streamline the build process. Call to inherit cannot depend on conditions
which can vary in given ebuild. Specification of the eclasses contains
only their name and not the .eclass extension. Also note that the
inherit statement must come before other variable declarations unless
these variables are used in global scope of eclasses.
, which, being vague, leaves me still unsure what inherit means. ;-(
Is there any documentation anywhere of what inherit actually DOES?
What am I doing wrong?
Thanks for help Nice Day
Silvio
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTld5hAAoJEKXdFCfdEflKeOAQAIcjAiB4F8B8j79Nfe0OPdV6
S2s3k1gjTomWzBEp5HMmVUEwzNkdOxoKE/1nOg+joodfTRuDb3KqzmD90ExoQbyU
goU9Fs80RjkJgNorh3Qv5M84QrtOmtUyny0lBb4n6yzpaJCjjSrXoWhknE8lntvu
U/0KhqeDLmLpPtoSYy/dxaLNxqbPUvIPkIwmumlRWzHrxOhfWiXPiFNzZ1U2ZEwi
BwK2+rO00RAcsN00w4JIUimtJhhCNE4pjIUrErJXGdBRmB7zn4JTaBsfS0K6VyP3
8GPWpBNb+pAdeGz+sKfwvarH+/g1FvK6WY6SPw/d7jdO673IOLXgacY9MyL7IfrW
7olBIq8LFs3B/oC2btDu96RcEGKJ5ghiTiLBbnRV9NezbPxRN9XX5iPnDMqFv/o2
+xFKQkeGtDDAu9BaBHg09cQZOdZi8XoqquzIJNvqqqFUMimk43fLChX1/itc28P6
q6Kj2VV8vIE6HeSmN9KAG/5XuYEvZkDGbuS92SJ4L7n7DvK1IXgmM1cKJQku0C7L
VSM5GLYhKw0G0k8wRaJO/h32N7yGLCuaxiJ9kg2PpipSSDhPYDsGv+58ulAsS27a
kcDjP44lL8TRt9bHAVcNr45R5GDvh28TLF6I8K8nvwAM+77hSglzlEKS8EsYVxDF
PKpH/jfaqC9GzaweE0hr
=QIFF
-END PGP SIGNATURE-
Re: [gentoo-user] Systemd upower
On 06/09/2014 06:34 PM, Alan Mackenzie wrote:
On Tue, Jun 03, 2014 at 05:11:32PM +0200, Silvio Siefke wrote:
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.
I do this:
emerge --unmerge upower
emerge -1vp sys-power/upower-pm-utils
, and I still get portage threatening to merge that other init system:
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-python/lxml-3.3.5 USE=threads -beautifulsoup3 -doc
-examples PYTHON_TARGETS=python2_7 python3_3 -python3_2 (-python3_4) 3,387
kB
[ebuild N ] sys-apps/systemd-212-r5:0/2 USE=acl filecaps
firmware-loader gudev introspection kmod pam policykit python seccomp -audit
-cryptsetup -doc -gcrypt -http (-kdbus) -lzma -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 2,659 kB
[ebuild N ] sys-apps/gentoo-systemd-integration-4 52 kB
[ebuild N ] virtual/libgudev-208 USE=introspection -static-libs
ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild N ] sys-power/upower-pm-utils-0.9.23 USE=introspection
-doc -ios 416 kB
[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/systemd (sys-apps/systemd is blocking
sys-fs/udev-208)
Total: 5 packages (5 new), Size of downloads: 6,513 kB
Conflict: 2 blocks (2 unsatisfied)
Would somebody please help me sort this out. What am I doing wrong?
Where is systemd coming from? I look in upower-pm-utils-0.9.23.ebuild,
and the only reference to systemd seems to be right at the beginning:
EAPI=5
inherit eutils systemd
(, plus a couple of inconsequential references near the end.) I'm not
quite sure exactly what inherit means here, but the FM (man (5) ebuild)
says:
Inherit is portage's maintenance of extra classes of functions that
are external to ebuilds and provided as inheritable capabilities and
data. They define functions and set data types as drop-in replacements,
expanded, and simplified routines for extremely common tasks to
streamline the build process. Call to inherit cannot depend on conditions
which can vary in given ebuild. Specification of the eclasses contains
only their name and not the .eclass extension. Also note that the
inherit statement must come before other variable declarations unless
these variables are used in global scope of eclasses.
, which, being vague, leaves me still unsure what inherit means. ;-(
Is there any documentation anywhere of what inherit actually DOES?
What am I doing wrong?
Thanks for help Nice Day
Silvio
Can you please verify that:
(1). sys-power/upower is gone by running this:
equery l (that's a lower case 'l') sys-power/upower
(2). sys-power/upower-pm-utils has been installed:
equery l sys-power/upower-pm-utils
(3). the 'p' flag does not actually install anything:
emerge(1)
--pretend (-p)
Instead of actually performing the merge, simply
display what
*would* have been installed if --pretend weren't used.
So if step 2 results in the negative, you may want to run the command
line without the 'p' flag, like so:
emerge -av1 sys-power/upower-pm-utils
Re: [gentoo-user] Systemd upower
Hello, Rick, thanks for the reply.
On Mon, Jun 09, 2014 at 12:18:41PM -0400, Rick Zero_Chaos Farina wrote:
On 06/09/2014 11:34 AM, Alan Mackenzie wrote:
I do this:
emerge --unmerge upower
emerge -1vp sys-power/upower-pm-utils
, and I still get portage threatening to merge that other init system:
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-python/lxml-3.3.5 USE=threads -beautifulsoup3
-doc -examples PYTHON_TARGETS=python2_7 python3_3 -python3_2
(-python3_4) 3,387 kB
[ebuild N ] sys-apps/systemd-212-r5:0/2 USE=acl filecaps
firmware-loader gudev introspection kmod pam policykit python seccomp
-audit -cryptsetup -doc -gcrypt -http (-kdbus) -lzma -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 2,659 kB
[ebuild N ] sys-apps/gentoo-systemd-integration-4 52 kB
[ebuild N ] virtual/libgudev-208 USE=introspection -static-libs
ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild N ] sys-power/upower-pm-utils-0.9.23 USE=introspection
-doc -ios 416 kB
[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/systemd (sys-apps/systemd is blocking
sys-fs/udev-208)
Total: 5 packages (5 new), Size of downloads: 6,513 kB
Conflict: 2 blocks (2 unsatisfied)
It would be helpful to build with --tree so we can get some idea of what
is depending on systemd.
OK. emerge -1vpt sys-power/upower-pm-utils gives me:
These are the packages that would be merged, in reverse order:
Calculating dependencies ... done!
[ebuild N ] sys-power/upower-pm-utils-0.9.23 USE=introspection -doc
-ios 416 kB
[ebuild N ] virtual/libgudev-208 USE=introspection -static-libs
ABI_X86=(64) (-32) (-x32) 0 kB
[nomerge ] virtual/libgudev-208 USE=introspection -static-libs
ABI_X86=(64) (-32) (-x32)
[nomerge ] sys-apps/systemd-212-r5:0/2 USE=acl filecaps
firmware-loader gudev introspection kmod pam policykit python seccomp -audit
-cryptsetup -doc -gcrypt -http (-kdbus) -lzma -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
[ebuild N ] sys-apps/gentoo-systemd-integration-4 52 kB
[ebuild N ]sys-apps/systemd-212-r5:0/2 USE=acl filecaps
firmware-loader gudev introspection kmod pam policykit python seccomp -audit
-cryptsetup -doc -gcrypt -http (-kdbus) -lzma -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 2,659 kB
[ebuild N ] dev-python/lxml-3.3.5 USE=threads -beautifulsoup3
-doc -examples PYTHON_TARGETS=python2_7 python3_3 -python3_2 (-python3_4)
3,387 kB
[blocks B ] sys-apps/systemd (sys-apps/systemd is blocking
sys-fs/udev-208)
[blocks B ] sys-fs/udev (sys-fs/udev is blocking
sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
Total: 5 packages (5 new), Size of downloads: 6,513 kB
Conflict: 2 blocks (2 unsatisfied)
. Taking a hint from the emerge man page, and adding --update, I get:
These are the packages that would be merged, in reverse order:
Calculating dependencies ... done!
[ebuild N ] sys-power/upower-pm-utils-0.9.23 USE=introspection -doc
-ios 416 kB
[ebuild N ] virtual/libgudev-208 USE=introspection -static-libs
ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild U ] sys-fs/udev-212-r1 [208] USE=acl firmware-loader gudev
introspection kmod -doc (-selinux) -static-libs (-openrc%*) ABI_X86=(64)
(-32) (-x32) 2,660 kB
[ebuild U ]sys-apps/hwids-20140317 [20130915.1] USE=udev 1,585 kB
[ebuild U ]sys-apps/kmod-17 [15] USE=python%* tools zlib -debug
-doc -lzma -static-libs (-openrc%*) PYTHON_TARGETS=python2_7%* python3_3%*
-python3_2% (-python3_4) 1,450 kB
Total: 5 packages (3 upgrades, 2 new), Size of downloads: 6,110 kB
, which seems like what I wanted in the first place.
Then again, I call
emerge -1vpuND --color y --tree sys-power/upower-pm-utils 21 | less -F
, things go pear shaped again, with:
These are the packages that would be merged, in reverse order:
Calculating dependencies . .. ..
done!
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
dev-lang/perl:0
(dev-lang/perl-5.16.3::gentoo, ebuild scheduled for merge) pulled in by
=dev-lang/perl-5.16 required by (dev-perl/XML-Parser-2.410.0::gentoo,
installed)
Apologies - WAS: Re: [gentoo-user] Systemd upower
On 6/4/2014 9:47 AM, Neil Bothwick n...@digimed.co.uk wrote: You seem to think the Upower devs simply decided to use systemd instead of doing it themselves. In fact, they were always using code, from either systemd or pm-utils. The fact that development stopped on pm-utils is neither the fault of the Upower or systemd people. They were reduced to a choice of one and you blame them for making the wrong choice? Actually, I wasn't talking about upower specifically, I was talking about this whole slippery slope that is systemd - but you are right, and I absolutely apologize for my comment about 'lazy devs', and most of my other negative comments. I still don't like the way systemd seems to be devouring everything to the point that it is apparently inevitable that it will become the default init system for all linux system. But I also admit that this is more just personal bias against Lennart/Kay/etc and all things related to them, all coming just from the many threads I've read, and also just fear of change in general (being that I am *not* a programmer, and am *not* capable of doing anything about this myself, regardless of if I would have the time or not). So, I will absolutely cease and desist denigrating systemd, at least until such time as I can speak from direct personal experience. First question: is there a decent guide to installing a gentoo system from scratch using systemd as the init system? Second question: is there a decent guide to how to switch from OpenRC to systemd? Third question: is there a decent guide on how to switch from systemd back to OpenRC, if I encounter any serious problems on a production box? Thanks, and again, my apologies for starting another flame-fest, and especially for basically abandoning the thread afterwards (busy week last week)...
Re: Apologies - WAS: Re: [gentoo-user] Systemd upower
On Sun, Jun 8, 2014 at 1:26 PM, Tanstaafl tansta...@libertytrek.org wrote: First question: is there a decent guide to installing a gentoo system from scratch using systemd as the init system? I've done this a few times on VMs. Just follow the handbook, but skip steps about configuring hostname/timezone/locale/etc since systemd does this (but do set up locale.gen). Then follow the systemd install guide. If you follow both guides to completion you won't hurt anything, but you'll just end up configuring some things twice (but systemd does migrate some of your settings over). Second question: is there a decent guide to how to switch from OpenRC to systemd? Yes, the systemd wiki page is the best place to go for this. It is pretty straightfoward. The only thing I'd do differently is just use networkd. The guide doesn't include that yet. cat /etc/systemd/network/dhcp.network [Match] Name=en* [Network] DHCP=yes --- end file --- (as long as you keep the extension you can call that file whatever you want, and if your interface doesn't match that glob you can tweak it) Also, if you have any network filesystems be sure to set the _netdev option in fstab. Third question: is there a decent guide on how to switch from systemd back to OpenRC, if I encounter any serious problems on a production box? For the most part you can just change the init setting on your kernel line to switch back and forth. You'll end up using udev packaged with systemd, but for the most part that shouldn't cause too many problems. Oh, if you're using dracut there is a chance it won't realize you aren't running systemd in your kernel and that could cause some issues (I was getting some of that before I intended to cut over to systemd in my last migration, but I didn't mess with it for long). Just keep in mind that immediately following the migration you won't have any services enabled. That means no network, no sshd, etc. Starting that stuff up is pretty easy, but it is just like having a fresh OpenRC install. Rich
Re: [gentoo-user] Systemd upower
On 06/04/2014 11:11 AM, Canek Peláez Valdés wrote:
On Wed, Jun 4, 2014 at 5:28 AM, Greg Woodbury redwo...@gmail.com wrote:
To see this as only freedom for the developer is part of an attitude
shift over the years that only lessens the overall usefulness of Linux
and FOSS. It does, in fact, push quite a few folk I know away from the
Linux arena. It is, to use a political analogy, like the people who
claim there is not any real difference between *any* opposing
political movements -- that neglects taking into account a great deal of
technical and historical details.
I have no idea what do you mean by the last paragraph. This is not a
political discusion (although many would like to see it that way). It
is a *technical* discusion, and therefore there is no real discusion:
the general consensus is that systemd is the technological superior
alternative.
It is a discussion about technological things, yes, but the art of
dealing with other people *is* politics [1].
Systemd *may* well be technologically superior in terms of having a
better method of doing things. (It certainly makes adding items to the
mix easier than re-doing all the numbering in SysVinit.)
Unfortunately, the advocates and implementers made some major political
choices when they (apparently deliberately) chose to put the systemd
stuff in /usr/lib instead of /lib. It was pointed out that this
abrogated certain parts of the FHS, forced those who would like to adopt
it to *not* being able to continue using their machines they way they
wished to (I.e. they had to choose between several potentially major
changes to do so -- don't have a separate /usr or be forced to use a
kernel initrd/initramfs method in order to do so.)
These were not mere technical choices, but highly political/social
choices. Early on, the violation of the principle of least surprise
could have been easily fixed by simply correcting the placement of
things from /usr back to / but the developers doing the work *chose* not
to see it as a mistake or poor choice, and steadfastly refused to accept
corrections or patches to improve the work by fixing what many saw as a
mistake.
That placement error was not the only social/political mistake they made
either. Other suggestions and improvements were offered and were
ignored or rejected in rather flammable verbiage.
As it happens, some of the parties involved work for companies that
actually pay them to do work on Linux and FOSS, and have leveraged that
role to the fullest.
I occasionally think about forking projects and fixing some of the
things I think are the most egregious fsck-ups in some of them, but then
I really look at what I'm doing and what I enjoy doing, and realize that
I won't get enough (emotional?) reward for giving up time in other
significant parts of my life.
And that's your right, and it's fine. But let *other* developers
choose whatever technologies they want to choose, and (consequently)
drop support for obsolete technologies like pm-utils.
Actually, that is not the objection. Developers do and have always done
that, but often observed much more concern with a) letting folks who use
their stuff know what they were doing, and b) giving a bit more lead
time when introducing major changes.
That's the reason for this whole thread: developers chose the
technological superior alternative; saying that the reason for that is
that there is cabals and conspiracies is blatant ignorance (in the
best case), or spreading FUD (in the worst case).
Or help Samuli to maintain upower-pm-utils; that would be *much* more
helpful than spreding FUD about cabals and conspiracies.
There is no need for me to invent Fear, Uncertainty, and Doubt -- the
folks involved are doing quite well on their own.
I never said you invented it. I say you are spreading it, and I
still think that's the case.
Also, history (for
those not doomed to repeat it [1]) provides all that is required to make
calling it a cabal [TINC - there is no cabal![2]] There never was a
Usenet Backbone Cabal in any formal sense, but there was plenty of
semi-(un)coordinated activity -- based largely on shared ideals -- that
gave that appearance. {I was there when Usenet/Netnews was invented,
closely observing, making minor and not-so-minor contributions, and was
responsible for some of the cabal-like activities.}
Great; so any kind of group work semi-(un)coordinated can be called
a cabal, and it has no (inherent) negative connotation. Then the Linux
Kernel developers is a Cabal; the GNOME devs is a Cabal; the KDE ones
are also a Cabal; and of course the Gentoo Developers who *oppose*
systemd is a Cabal, and so are the ones that *support* systemd.
Mo, you misunderstand. TINC is/was a humorous reminder that there was
NOT a real cabal, but merely the appearance of one in the minds of
those not involved in the day-to-day operations of real systems and
networks. The human mind sees patterns and invents
Re: [gentoo-user] Systemd upower
On Wed, 04 Jun 2014 19:15:22 -0400 Dutch Ingraham s...@gmx.us wrote: Thanks everybody for your help. I've made the further suggested changes, but I remain with the three hard blocks. Can you provide the emerge output of the following command? emerge --tree --unordered-diplay -uDNv @world This makes it more clear what pulls in systemd. Once you know that, you can mask the chain and use an alternative; other than that, MATE is in the Portage tree and therefore you can remove the MATE overlay to avoid running into unnecessary blockers. This happening has nothing to do with Gentoo or systemd; around four years ago the development of pm-utils stopped, which causes UPower to nowadays take a decision. This results in the following scenarios: 1. If you need pm-utils, you either need to switch to the upower-pm-utils fork or to systemd; 2. If you don't need pm-utils, you either need to a) upgrade to upower-0.99 once reverse dependencies support it and it is stabilized (this has no dependency on systemd); b) switch to upower-pm-utils despite not needing pm-utils; c) switch to systemd. Gentoo reflects that decision as magic can't happen from one day to the other; while trying to keep a fork upower-pm-utils alive as long as it can be kept working given the manpower, kernel API and so on... -- 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 Thu, 5 Jun 2014 00:27:28 +0100 Neil Bothwick n...@digimed.co.uk wrote: On Wed, 04 Jun 2014 19:15:22 -0400, Dutch Ingraham wrote: I suppose its now time for an uninstall. Kind of disappointing; we are told Gentoo is about choices, and in fact that's true. I made the choice to use a pure openRC system. The last 7 hours of free time, though, was spent trying, and ultimately failing, to correct a problem not chosen, not wanted, and not invited. ...and not of Gentoo's doing. You are trying to blame Gentoo for a problem arising from an overlay. A more productive use of your time would be to inform the overlay's maintainers about your problem and request a fix, which may well be a simple ebuild tweak. It has been fixed two days ago; so, Ingraham needs to sync the overlay: https://github.com/Sabayon/mate-overlay/commit/0e4acf73e81083d87d43e2a0b0be2b959f1e6a78 A news item was put out that it was being migrated to the Portage tree: https://github.com/Sabayon/mate-overlay/blob/master/metadata/news/2014-02-21-portage-import/2014-02-21-portage-import.en.txt And they are now planning to retire the overlay to make people switch: https://github.com/Sabayon/mate-overlay/issues/76 -- 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 Thu, 05 Jun 2014 02:34:49 -0400 Greg Woodbury redwo...@gmail.com wrote: On 06/04/2014 11:11 AM, Canek Peláez Valdés wrote: It is a discussion about technological things, yes, but the art of dealing with other people *is* politics [1]. Politics are also about dealing with power, not alone people; it is possible to give a robot a lot of power, that doesn't imply that the creator or buyer of that robot has power. The robot will have its own will; that will isn't necessarily depending on what people tell the robot to do, but also on what the robot will percept from nature. This then all boils down to the nature's will; there may be a person, robot or server with a lot of power, but one day the power of nature decides. Systemd *may* well be technologically superior in terms of having a better method of doing things. (It certainly makes adding items to the mix easier than re-doing all the numbering in SysVinit.) Unfortunately, the advocates and implementers made some major political choices when they (apparently deliberately) chose to put the systemd stuff in /usr/lib instead of /lib. It was pointed out that this abrogated certain parts of the FHS, forced those who would like to adopt it to *not* being able to continue using their machines they way they wished to (I.e. they had to choose between several potentially major changes to do so -- don't have a separate /usr or be forced to use a kernel initrd/initramfs method in order to do so.) This is the power of putting things in such places against the power of the FHS; Gentoo uses its power to allow parts of these powers to exist, as Gentoo does not consider the Filesystem Hierarchy Standard to be an authoritative standard, although much of our policy coincides with it.. http://devmanual.gentoo.org/general-concepts/filesystem You note how it abrogates part of the power of the FHS, but you don't mention its consequences and how Gentoo deals with those consequences; this highlights a power, instead of how that power affects people. So, yes, eventually politics deal with people; but it does so through means of dealing with power, only looking at the power or only looking at the people deceives one from the total picture. Look at both instead. These were not mere technical choices, but highly political/social choices. Early on, the violation of the principle of least surprise could have been easily fixed by simply correcting the placement of things from /usr back to / but the developers doing the work *chose* not to see it as a mistake or poor choice, and steadfastly refused to accept corrections or patches to improve the work by fixing what many saw as a mistake. Where did we agree with the power of the principle of least surprise? What kind of surprise towards the users are we talking about? Short term surprise? Long term surprise? How does that affect our users? It can be a mistake in the short term, but that doesn't make it one in the long term; things work out well, it seems, where is the problem? That placement error was not the only social/political mistake they made either. Other suggestions and improvements were offered and were ignored or rejected in rather flammable verbiage. This paragraph misses a reference to the mistakes and verbiage. As it happens, some of the parties involved work for companies that actually pay them to do work on Linux and FOSS, and have leveraged that role to the fullest. Some people give up on money, to reach something else in their life; Hey, honey, I don't want you to move to Silicon Valley; stay with me.. Actually, that is not the objection. Developers do and have always done that, but often observed much more concern with a) letting folks who use their stuff know what they were doing, and b) giving a bit more lead time when introducing major changes. The road map concept exists for that purpose; however, a lot of developers don't use such thing or use it in some other way (TODOs, bugs that capture feature requests and important changes, ...); what is however a more used concept are change logs, where these kind of things are mentioned. But can users track all upstream's major changes? Mo, you misunderstand. TINC is/was a humorous reminder that there was NOT a real cabal, but merely the appearance of one in the minds of those not involved in the day-to-day operations of real systems and networks. The human mind sees patterns and invents explanations when there is not enough information available. There is no reason to ascribe to malice that which is adequately explained by ignorance or stupidity (willful ignorance.) This leaves out possibilities; a possible explanation doesn't make it a factual true explanation of the matter at hand, like how you've mentioned mistakes and verbiage above. It might be true to you, because you might have these references; it could also be a possibility to you, because you think you saw such pattern but can't bring it back up;
Re: [gentoo-user] Systemd upower
On Thu, Jun 5, 2014 at 2:34 AM, Greg Woodbury redwo...@gmail.com wrote: Unfortunately, the advocates and implementers made some major political choices when they (apparently deliberately) chose to put the systemd stuff in /usr/lib instead of /lib. It was pointed out that this abrogated certain parts of the FHS, forced those who would like to adopt it to *not* being able to continue using their machines they way they wished to (I.e. they had to choose between several potentially major changes to do so -- don't have a separate /usr or be forced to use a kernel initrd/initramfs method in order to do so.) My understanding is that the systemd developers intend for systemd to not be installed in /usr unless /lib and so on are symlinks to their counterparts in /usr (ie the /usr-merge is completed). That has been the subject of some debate for Gentoo. I think the reason so much stuff is migrating to /usr is the sense that keeping things split up is becoming more hassle than it is worth due to all the vertical integration. If you have a bluetooth keyboard then you're going to be hard-pressed to use your system without /usr mounted. That is the standard example, but the sense is that this is the way the wind is blowing. Virtually every distro out there uses an initramfs anyway - we're a bit of an aberration in that it seems that using an initramfs is rare among Gentoo users. Just look at an initramfs as the new root filesystem. There really isn't anything you could do with a shell without /usr mounted that you can't do with a shell in an initramfs. Rich
Re: [gentoo-user] Systemd upower
On 05/06/14 14:11, Rich Freeman wrote: On Thu, Jun 5, 2014 at 2:34 AM, Greg Woodbury redwo...@gmail.com wrote: Unfortunately, the advocates and implementers made some major political choices when they (apparently deliberately) chose to put the systemd stuff in /usr/lib instead of /lib. It was pointed out that this abrogated certain parts of the FHS, forced those who would like to adopt it to *not* being able to continue using their machines they way they wished to (I.e. they had to choose between several potentially major changes to do so -- don't have a separate /usr or be forced to use a kernel initrd/initramfs method in order to do so.) My understanding is that the systemd developers intend for systemd to not be installed in /usr unless /lib and so on are symlinks to their counterparts in /usr (ie the /usr-merge is completed). Correct. As in, if you git clone system repository, and run ./autogen.sh on it, it will recommend options that will put systemd to /, not /usr And multiple systemd upstream developers think it's an bad idea to install systemd to /usr if the /usr-merge is not complete, Kay, Lennart, and others have said it out loud on ML and #systemd, Freenode So, it's entirely Gentoo systemd maintainers decision to install into /usr even without the /usr-merge I think the reason so much stuff is migrating to /usr is the sense that keeping things split up is becoming more hassle than it is worth due to all the vertical integration. If you have a bluetooth keyboard then you're going to be hard-pressed to use your system without /usr mounted. That is the standard example, but the sense is that this is the way the wind is blowing. Virtually every distro out there uses an initramfs anyway - we're a bit of an aberration in that it seems that using an initramfs is rare among Gentoo users. Just look at an initramfs as the new root filesystem. There really isn't anything you could do with a shell without /usr mounted that you can't do with a shell in an initramfs. That'd be accurate.
Re: [gentoo-user] Systemd upower
On 06/04/2014 08:02 PM, Samuli Suominen wrote:
On 05/06/14 02:15, Dutch Ingraham wrote:
On 06/04/2014 03:17 PM, Samuli Suominen wrote:
On 04/06/14 20:11, Dutch Ingraham wrote:
On 06/04/2014 07:22 AM, Daniel Troeder wrote:
Am 04.06.2014 06:05, schrieb Samuli Suominen:
On 04/06/14 05:17, Dutch Ingraham wrote:
No, sys-fs/udev is not masked, but an update is indicated in the
emerge above. That's a good catch, the MATE stuff is from the overlay.
Unfortunately, the xfce stuff is not, so even if the overlay currency
was an issue, I'll still be showing some dependencies.
Try re-emerging on un-emerging the offending packages, like
xfce4-session and xfce4-power-manager,
it has helped some people, to refresh the .ebuild copy that is installed
with the .ebuild copy from
Portage
- Samuli
Thanks - that fixed it for me:
# emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
# emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
Greetings
Daniel
Unfortunately, this doesn't work for me. So let me re-cap: I have
4. masked virtual/udev-208-r2; that has not worked.
First, remove that mask. Masking it will certainly cause more blockers,
than solve them.
[ebuild N~] mate-extra/mate-power-manager-1.6.3::mate-overlay
USE=applet policykit -gnome-keyring -man {-test} 0 kB
[ebuild N~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
USE=ipv6 -debug -systemd 0 kB
see ::mate-overlay, it's presumably broken or outdated. stop using the
overlay and use MATE from Portage instead.
or you can mask the packages from overlay, the syntax is like:
/etc/portage/package.mask
mate-extra/mate-power-manager::mate-overlay
mate-base/mate-session-manager::mate-overlay
- Samuli
Thanks everybody for your help. I've made the further suggested
changes, but I remain with the three hard blocks.
I've now spent about 7 hours over the last two days on this issue (about
2x the fresh install time), when all I wanted to do was a routine
update. I've reworked a large part of my system, adding a new
package.mask file and populating it with six packages.
I suppose its now time for an uninstall. Kind of disappointing; we are
told Gentoo is about choices, and in fact that's true. I made the
choice to use a pure openRC system. The last 7 hours of free time,
though, was spent trying, and ultimately failing, to correct a problem
not chosen, not wanted, and not invited.
The sine qua non is unarguably systemd. Even though my choice was to
not deploy it, apparently it takes a significant time commitment and/or
developer-level knowledge to choose to not use it. Quite the inelegant
end to my once-trusty OS.
Gentoo doesn't have write access to ::mate-overlay, it's completely
unofficial
Gentoo developers are just as much users as you are for ::mate-overlay
Enough said
- Samuli
Sorry, but this isn't just a MATE overlay problem. Once I made your
suggested changes, the MATE mask change requests disappeared. What I
did get was XFCE mask requirements:
[snip]
The following mask changes are necessary to proceed:
(see package.unmask in the portage(5) man page for more details)
# required by xfce-base/xfce4-meta-4.10
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils
=xfce-base/xfce4-session-4.10.1-r1
# required by virtual/udev-208-r2
# required by sys-power/upower-0.9.23-r3
# required by xfce-base/xfce4-session-4.10.1-r1[udev]
# required by xfce-base/xfce4-meta-4.10
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils
=sys-apps/systemd-212-r5
# required by sys-apps/systemd-212-r5[-vanilla]
# required by sys-power/upower-0.9.23-r3
# required by xfce-base/xfce4-session-4.10.1-r1[udev]
# required by xfce-base/xfce4-meta-4.10
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils
=sys-apps/gentoo-systemd-integration-4
[snip]
I had already emerge - C'd those two XFCE applications because, early
in this process an equery depends upower had shown them to be
dependent upon upower even after emerging upower-pm-utils. I have
no confidence at this point that my particular problem is reasonably
solvable, as I have been caught in this circle for three days now.
Re: [gentoo-user] Systemd upower
On 05/06/14 14:39, Dutch Ingraham wrote: On 06/04/2014 08:02 PM, Samuli Suominen wrote: Gentoo doesn't have write access to ::mate-overlay, it's completely unofficial Gentoo developers are just as much users as you are for ::mate-overlay Enough said - Samuli Sorry, but this isn't just a MATE overlay problem. Once I made your suggested changes, the MATE mask change requests disappeared. What I did get was XFCE mask requirements: [snip] The following mask changes are necessary to proceed: (see package.unmask in the portage(5) man page for more details) # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =xfce-base/xfce4-session-4.10.1-r1 # required by virtual/udev-208-r2 # required by sys-power/upower-0.9.23-r3 # required by xfce-base/xfce4-session-4.10.1-r1[udev] # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =sys-apps/systemd-212-r5 # required by sys-apps/systemd-212-r5[-vanilla] # required by sys-power/upower-0.9.23-r3 # required by xfce-base/xfce4-session-4.10.1-r1[udev] # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =sys-apps/gentoo-systemd-integration-4 [snip] I had already emerge - C'd those two XFCE applications because, early in this process an equery depends upower had shown them to be dependent upon upower even after emerging upower-pm-utils. I have no confidence at this point that my particular problem is reasonably solvable, as I have been caught in this circle for three days now. There is no need to mask any Xfce packages, in fact, masking them would cause more blockers. So that output would be bogus, as it would include the wrong Xfce masks, and futhermore it's only end of the output, so it wouldn't tell the necessary information required for solving it anyway. Remove anykind of Xfce masks and post complete output, and don't forget to use the --tree flag (-t) to see what is pulling in what. That is, if you still want help solving the issue. - Samuli
Re: [gentoo-user] Systemd upower
On 06/05/2014 05:40 AM, Tom Wijsman wrote:
On Wed, 04 Jun 2014 19:15:22 -0400
Dutch Ingraham s...@gmx.us wrote:
Thanks everybody for your help. I've made the further suggested
changes, but I remain with the three hard blocks.
Can you provide the emerge output of the following command?
emerge --tree --unordered-diplay -uDNv @world
This makes it more clear what pulls in systemd.
Once you know that, you can mask the chain and use an alternative;
other than that, MATE is in the Portage tree and therefore you can
remove the MATE overlay to avoid running into unnecessary blockers.
This happening has nothing to do with Gentoo or systemd; around four
years ago the development of pm-utils stopped, which causes UPower to
nowadays take a decision. This results in the following scenarios:
1. If you need pm-utils, you either need to switch to the
upower-pm-utils fork or to systemd;
2. If you don't need pm-utils, you either need to
a) upgrade to upower-0.99 once reverse dependencies support it
and it is stabilized (this has no dependency on systemd);
b) switch to upower-pm-utils despite not needing pm-utils;
c) switch to systemd.
Gentoo reflects that decision as magic can't happen from one day to
the other; while trying to keep a fork upower-pm-utils alive as long as
it can be kept working given the manpower, kernel API and so on...
Here's the output you requested, Tom:
dutch@gentoo ~ $ emerge --tree --unordered-display --pretend -uDNv @world
These are the packages that would be merged:
Calculating dependencies... done!
[nomerge ] virtual/shadow-0
[nomerge ] sys-apps/shadow-4.1.5.1-r1 USE=acl cracklib nls pam
-audit (-selinux) -skey -xattr
[nomerge ] virtual/pam-0
[nomerge ]sys-libs/pam-1.1.6-r2 USE=berkdb cracklib nls
-audit -debug -nis (-selinux) {-test} -vim-syntax
[nomerge ] sys-auth/pambase-20120417-r3 USE=consolekit
cracklib sha512 -debug -gnome-keyring -minimal -mktemp -pam_krb5
-pam_ssh -passwdqc (-selinux) -systemd
[nomerge ] sys-auth/consolekit-0.4.6 USE=acl pam policykit
-debug -doc (-selinux) -systemd-units {-test}
[nomerge ] sys-auth/polkit-0.112-r1 USE=introspection nls
pam -examples -gtk -kde (-selinux) -systemd
[nomerge ]dev-libs/gobject-introspection-1.38.0
USE=-cairo -doctool {-test} PYTHON_SINGLE_TARGET=python2_7
PYTHON_TARGETS=python2_7
[nomerge ] virtual/pkgconfig-0
[nomerge ] dev-util/pkgconfig-0.28 USE=-hardened
-internal-glib
[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
[nomerge ]app-text/docbook-xml-dtd-4.1.2-r6:4.1.2
[nomerge ] app-text/build-docbook-catalog-1.19.1
[nomerge ] sys-apps/util-linux-2.24.1-r2
USE=bash-completion cramfs ncurses nls pam suid udev unicode -caps
-cytune -fdformat -python (-selinux) -slang -static-libs {-test}
-tty-helpers PYTHON_SINGLE_TARGET=python2_7 -python3_2 -python3_3
(-python3_4) PYTHON_TARGETS=python2_7 python3_3 -python3_2 (-python3_4)
[ebuild U ] virtual/udev-208-r2 [208-r1] USE=gudev
-introspection -static-libs (-kmod%*) (-selinux%) ABI_X86=(64) (-32)
(-x32) 0 kB
[ebuild N ]virtual/libudev-208:0/1
USE=-static-libs ABI_X86=(64) (-32) (-x32) 0 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-libs/libseccomp-2.1.1
USE=-static-libs 111 kB
[ebuild N#] sys-apps/gentoo-systemd-integration-4
52 kB
[nomerge ] mate-base/mate-1.6.0::mate-overlay USE=extras
(-bluetooth)
[ebuild N#] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
USE=ipv6 -debug -systemd 0 kB
[ebuild N ] sys-power/upower-0.9.23-r3 USE=introspection -doc
-ios 0 kB
[ebuild N#] mate-extra/mate-power-manager-1.6.3::mate-overlay
USE=applet policykit -gnome-keyring -man {-test} 0 kB
[nomerge ] mate-base/mate-panel-1.6.1::mate-overlay
USE=introspection -networkmanager
[ebuild R ~]x11-libs/libmatewnck-1.6.1:1::mate-overlay
[1.6.1:0::gentoo] USE=introspection startup-notification (-X%*) 0 kB
[nomerge ] app-text/mate-document-viewer-1.6.2-r1 USE=dbus djvu
introspection ps -caja -debug -dvi -gnome-keyring -t1lib -tiff -xps
[nomerge ] app-text/libspectre-0.2.7 USE=-debug -doc
-static-libs
[nomerge ]app-text/ghostscript-gpl-9.10-r2 USE=X bindist
cups dbus djvu -gtk -idn -static-libs LINGUAS=-de
Re: [gentoo-user] Systemd upower
On 06/05/2014 08:00 AM, Samuli Suominen wrote:
On 05/06/14 14:39, Dutch Ingraham wrote:
On 06/04/2014 08:02 PM, Samuli Suominen wrote:
Gentoo doesn't have write access to ::mate-overlay, it's completely
unofficial
Gentoo developers are just as much users as you are for ::mate-overlay
Enough said
- Samuli
Sorry, but this isn't just a MATE overlay problem. Once I made your
suggested changes, the MATE mask change requests disappeared. What I
did get was XFCE mask requirements:
[snip]
The following mask changes are necessary to proceed:
(see package.unmask in the portage(5) man page for more details)
# required by xfce-base/xfce4-meta-4.10
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils
=xfce-base/xfce4-session-4.10.1-r1
# required by virtual/udev-208-r2
# required by sys-power/upower-0.9.23-r3
# required by xfce-base/xfce4-session-4.10.1-r1[udev]
# required by xfce-base/xfce4-meta-4.10
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils
=sys-apps/systemd-212-r5
# required by sys-apps/systemd-212-r5[-vanilla]
# required by sys-power/upower-0.9.23-r3
# required by xfce-base/xfce4-session-4.10.1-r1[udev]
# required by xfce-base/xfce4-meta-4.10
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# problems with systemd, upower shift to upower.pm.utils
=sys-apps/gentoo-systemd-integration-4
[snip]
I had already emerge - C'd those two XFCE applications because, early
in this process an equery depends upower had shown them to be
dependent upon upower even after emerging upower-pm-utils. I have
no confidence at this point that my particular problem is reasonably
solvable, as I have been caught in this circle for three days now.
There is no need to mask any Xfce packages, in fact, masking them would
cause more blockers.
So that output would be bogus, as it would include the wrong Xfce masks,
and futhermore it's only end of
the output, so it wouldn't tell the necessary information required for
solving it anyway.
Remove anykind of Xfce masks and post complete output, and don't forget
to use the --tree flag (-t) to see
what is pulling in what.
That is, if you still want help solving the issue.
- Samuli
I I've removed the XFCE masks. Note that mate-power-manager is masked.
Here's the output without them:
dutch@gentoo ~ $ emerge --tree --unordered-display --pretend -uDNv @world
These are the packages that would be merged:
Calculating dependencies... done!
[nomerge ] xfce-extra/thunar-volman-0.8.0 USE=-debug -libnotify
[nomerge ] xfce-base/libxfce4util-4.10.1 USE=-debug
[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
[nomerge ]app-text/docbook-xml-dtd-4.1.2-r6:4.1.2
[nomerge ] app-text/build-docbook-catalog-1.19.1
[nomerge ] sys-apps/util-linux-2.24.1-r2
USE=bash-completion cramfs ncurses nls pam suid udev unicode -caps
-cytune -fdformat -python (-selinux) -slang -static-libs {-test}
-tty-helpers PYTHON_SINGLE_TARGET=python2_7 -python3_2 -python3_3
(-python3_4) PYTHON_TARGETS=python2_7 python3_3 -python3_2 (-python3_4)
[nomerge ] sys-libs/pam-1.1.6-r2 USE=berkdb cracklib nls
-audit -debug -nis (-selinux) {-test} -vim-syntax
[nomerge ]sys-auth/pambase-20120417-r3 USE=consolekit
cracklib sha512 -debug -gnome-keyring -minimal -mktemp -pam_krb5
-pam_ssh -passwdqc (-selinux) -systemd
[nomerge ] sys-auth/consolekit-0.4.6 USE=acl pam
policykit -debug -doc (-selinux) -systemd-units {-test}
[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-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-libs/libseccomp-2.1.1
USE=-static-libs 111 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
[nomerge ] net-print/gutenprint-5.2.9 USE=nls readline -cups
-foomaticdb -gimp -gtk -ppds -static-libs
[nomerge ] app-text/ghostscript-gpl-9.10-r2 USE=X bindist cups
dbus djvu -gtk -idn -static-libs LINGUAS=-de -ja -ko -zh_CN -zh_TW
[nomerge ] net-print/cups-1.7.1-r1 USE=X acl dbus pam ssl
threads zeroconf -debug -gnutls -java
Re: [gentoo-user] Systemd upower
On 05/06/14 15:17, Dutch Ingraham wrote: On 06/05/2014 08:00 AM, Samuli Suominen wrote: On 05/06/14 14:39, Dutch Ingraham wrote: On 06/04/2014 08:02 PM, Samuli Suominen wrote: Gentoo doesn't have write access to ::mate-overlay, it's completely unofficial Gentoo developers are just as much users as you are for ::mate-overlay Enough said - Samuli Sorry, but this isn't just a MATE overlay problem. Once I made your suggested changes, the MATE mask change requests disappeared. What I did get was XFCE mask requirements: [snip] The following mask changes are necessary to proceed: (see package.unmask in the portage(5) man page for more details) # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =xfce-base/xfce4-session-4.10.1-r1 # required by virtual/udev-208-r2 # required by sys-power/upower-0.9.23-r3 # required by xfce-base/xfce4-session-4.10.1-r1[udev] # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =sys-apps/systemd-212-r5 # required by sys-apps/systemd-212-r5[-vanilla] # required by sys-power/upower-0.9.23-r3 # required by xfce-base/xfce4-session-4.10.1-r1[udev] # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =sys-apps/gentoo-systemd-integration-4 [snip] I had already emerge - C'd those two XFCE applications because, early in this process an equery depends upower had shown them to be dependent upon upower even after emerging upower-pm-utils. I have no confidence at this point that my particular problem is reasonably solvable, as I have been caught in this circle for three days now. There is no need to mask any Xfce packages, in fact, masking them would cause more blockers. So that output would be bogus, as it would include the wrong Xfce masks, and futhermore it's only end of the output, so it wouldn't tell the necessary information required for solving it anyway. Remove anykind of Xfce masks and post complete output, and don't forget to use the --tree flag (-t) to see what is pulling in what. That is, if you still want help solving the issue. - Samuli I I've removed the XFCE masks. Note that mate-power-manager is masked. I see you didn't follow the recommendation of getting rid of the ::mate-overlay because I'm still seeing mate-base/mate::mate-overlay and more in the output I don't know how we could possible get forward if you don't follow-up on the already suggested instructions, no wonder you've been running circles. Uninstall mate-overlay, emerge -C mate mate-power-manager mate-session-manager and anything else you have installed from there. Let Portage pull them back in from the actual Portage tree.
Re: [gentoo-user] Systemd upower
On Thu, 05 Jun 2014 08:11:31 -0400 Dutch Ingraham s...@gmx.us wrote: [nomerge ] mate-base/mate-1.6.0::mate-overlay You are still using the MATE overlay, which wasn't synced up with the latest changes; make layman sync, but if you want to be really sure just remove the overlay from layman and use MATE from the Portage tree. [ebuild N#] mate-base/mate-session-manager-1.6.1-r1::mate-overlay [ebuild N ] sys-power/upower-0.9.23-r3 Don't mask MATE, it causes more blockers; mate-base/mate requires it. As you can see above, your old checkout of the MATE overlay pulls in sys-power/upower; the MATE in the portage tree doesn't do this as it allows upower-pm-utils to satisfy this, I think this has also been fixed up in the MATE overlay recently which a sync could solve. [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) [blocks B ] sys-fs/udev (sys-fs/udev is blocking sys-apps/gentoo-systemd-integration-4, sys-apps/systemd-212-r5) Fixing what was said above, for MATE (maybe XFCE too), will fix it ... (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) ... as well as this; this last thing points out that something is still pulling in upower, that's due to the old MATE overlay checkout. The MATE overlay plans to retire itself in less than a week from now. https://github.com/Sabayon/mate-overlay/issues/76 If you need help with switching to MATE in the Portage tree, feel free to let me know; this migration is supposed to go very fluent, so, removing the overlay from layman should work out well. -- 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
Sent:Thursday, June 05, 2014 at 8:18 AM From:Samuli Suominen ssuomi...@gentoo.org To:gentoo-user@lists.gentoo.org Subject:Re: [gentoo-user] Systemd upower On 05/06/14 15:17, Dutch Ingraham wrote: On 06/05/2014 08:00 AM, Samuli Suominen wrote: On 05/06/14 14:39, Dutch Ingraham wrote: On 06/04/2014 08:02 PM, Samuli Suominen wrote: Gentoo doesnt have write access to ::mate-overlay, its completely unofficial Gentoo developers are just as much users as you are for ::mate-overlay Enough said - Samuli Sorry, but this isnt just a MATE overlay problem. Once I made your suggested changes, the MATE mask change requests disappeared. What I did get was XFCE mask requirements: [snip] The following mask changes are necessary to proceed: (see package.unmask in the portage(5) man page for more details) # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =xfce-base/xfce4-session-4.10.1-r1 # required by virtual/udev-208-r2 # required by sys-power/upower-0.9.23-r3 # required by xfce-base/xfce4-session-4.10.1-r1[udev] # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =sys-apps/systemd-212-r5 # required by sys-apps/systemd-212-r5[-vanilla] # required by sys-power/upower-0.9.23-r3 # required by xfce-base/xfce4-session-4.10.1-r1[udev] # required by xfce-base/xfce4-meta-4.10 # required by @selected # required by @world (argument) # /etc/portage/package.mask: # problems with systemd, upower shift to upower.pm.utils =sys-apps/gentoo-systemd-integration-4 [snip] I had already emerge - Cd those two XFCE applications because, early in this process an equery depends upower had shown them to be dependent upon upower even after emerging upower-pm-utils. I have no confidence at this point that my particular problem is reasonably solvable, as I have been caught in this circle for three days now. There is no need to mask any Xfce packages, in fact, masking them would cause more blockers. So that output would be bogus, as it would include the wrong Xfce masks, and futhermore its only end of the output, so it wouldnt tell the necessary information required for solving it anyway. Remove anykind of Xfce masks and post complete output, and dont forget to use the --tree flag (-t) to see what is pulling in what. That is, if you still want help solving the issue. - Samuli I Ive removed the XFCE masks. Note that mate-power-manager is masked. I see you didnt follow the recommendation of getting rid of the ::mate-overlay because Im still seeing mate-base/mate::mate-overlay and more in the output I dont know how we could possible get forward if you dont follow-up on the already suggested instructions, no wonder youve been running circles. Uninstall mate-overlay, emerge -C mate mate-power-manager mate-session-manager and anything else you have installed from there. Let Portage pull them back in from the actual Portage tree. Samuli - thanks for your response. I had already done the emerge -C mate-power-manager and mate-session. I did not uninstall the overlay because equery depends upower showed no remaining dependencies. I will give it a go and try and convert from the overlay to the portage repository.
Re: [gentoo-user] Systemd upower
Sent:Thursday, June 05, 2014 at 8:31 AM From:Tom Wijsman tom...@gentoo.org To:gentoo-user@lists.gentoo.org Subject:Re: [gentoo-user] Systemd upower On Thu, 05 Jun 2014 08:11:31 -0400 Dutch Ingraham s...@gmx.us wrote: [nomerge ] mate-base/mate-1.6.0::mate-overlay You are still using the MATE overlay, which wasnt synced up with the latest changes; make layman sync, but if you want to be really sure just remove the overlay from layman and use MATE from the Portage tree. [ebuild N #] mate-base/mate-session-manager-1.6.1-r1::mate-overlay [ebuild N ] sys-power/upower-0.9.23-r3 Dont mask MATE, it causes more blockers; mate-base/mate requires it. As you can see above, your old checkout of the MATE overlay pulls in sys-power/upower; the MATE in the portage tree doesnt do this as it allows upower-pm-utils to satisfy this, I think this has also been fixed up in the MATE overlay recently which a sync could solve. [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) [blocks B ] sys-fs/udev (sys-fs/udev is blocking sys-apps/gentoo-systemd-integration-4, sys-apps/systemd-212-r5) Fixing what was said above, for MATE (maybe XFCE too), will fix it ... (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) ... as well as this; this last thing points out that something is still pulling in upower, thats due to the old MATE overlay checkout. The MATE overlay plans to retire itself in less than a week from now. https://github.com/Sabayon/mate-overlay/issues/76 If you need help with switching to MATE in the Portage tree, feel free to let me know; this migration is supposed to go very fluent, so, removing the overlay from layman should work out well. -- 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 Thanks, Tom. I have actually looked, ever since you began your work on the portage version of MATE, for some guidance on how to transfer from the overlay to the general portage repository, but, and maybe I just didnt look hard enough, I never found the proper guidance for making that switch. If you could point me to the proper command set to make the switch, Id appreciate it.
Re: [gentoo-user] Systemd upower
On Thu, 5 Jun 2014 16:15:11 +0200 Dutch Ingraham s...@gmx.us wrote: If you could point me to the proper command set to make the switch, I'd appreciate it. Remove the overlay (`layman -d mate`) and then do a world upgrade. It is as simple as that, as it'll upgrade all those packages to the versions that are in the Portage tree; if not, please let me know. Good luck and thank you in advance. -- 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 Thursday 05 Jun 2014 15:15:11 Dutch Ingraham wrote: htmlhead/headbodydiv style=font-family: Verdana;font-size: 12.0px;divnbsp; divnbsp; div name=quoted-contentnbsp;/div div name=quoted-contentIf you could point me to the proper command set to make the switch, I#39;d appreciate it./div /div /div /div/div/body/html Please see if you can switch off HTML when posting to this list. Check man layman, the delete command is: layman -d overlay -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Systemd upower
On 06/05/2014 11:40 AM, Tom Wijsman wrote: On Thu, 5 Jun 2014 16:15:11 +0200 Dutch Ingraham s...@gmx.us wrote: If you could point me to the proper command set to make the switch, I'd appreciate it. Remove the overlay (`layman -d mate`) and then do a world upgrade. It is as simple as that, as it'll upgrade all those packages to the versions that are in the Portage tree; if not, please let me know. Good luck and thank you in advance. OK Tom, I'll try that tonight. Thanks to everyone who offered solutions, and especially to TomWij and Samuli for their extra effort. For my future reference, could someone point me to the documentation that provides for the situation where an application installed under layman is migrated to the portage tree? I understand now the procedure seems simple, but without that information, I wouldn't ordinarily just presume such a simple fix (kudos to the portage devs/maintainers)(I certainly would have done it long ago when Tom first populated the tree). I have checked the following sources and find nothing but how to install and work with overlays, but only the command above for removing one - nothing on migration: Gentoo Overlays User's Guide, the Gentoo wikis on overlays and layman, the layman, portage, and emerge manpages, and the Gentoo Handbook. Thanks again for all the help.
Re: [gentoo-user] Systemd upower
On 06/03/2014 10:05 PM, Canek Peláez Valdés wrote:
On Tue, Jun 3, 2014 at 8:37 PM, Greg Woodbury redwo...@gmail.com wrote:
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.
I was a developer for more years than I really care to remember. I
still try to contribute in ways and areas that I'm not so out-of-date with.
Furthermore, it is a two-way street (as I see it.) The developers write
things they find interesting and enjoyable to work on, and users use
things that are interesting and work well. For many, seeing other folks
use what they have written provides a significant measure of the
enjoyment derived from the exercise.
To see this as only freedom for the developer is part of an attitude
shift over the years that only lessens the overall usefulness of Linux
and FOSS. It does, in fact, push quite a few folk I know away from the
Linux arena. It is, to use a political analogy, like the people who
claim there is not any real difference between *any* opposing
political movements -- that neglects taking into account a great deal of
technical and historical details.
I occasionally think about forking projects and fixing some of the
things I think are the most egregious fsck-ups in some of them, but then
I really look at what I'm doing and what I enjoy doing, and realize that
I won't get enough (emotional?) reward for giving up time in other
significant parts of my life.
Or help Samuli to maintain upower-pm-utils; that would be *much* more
helpful than spreding FUD about cabals and conspiracies.
There is no need for me to invent Fear, Uncertainty, and Doubt -- the
folks involved are doing quite well on their own. Also, history (for
those not doomed to repeat it [1]) provides all that is required to make
calling it a cabal [TINC - there is no cabal![2]] There never was a
Usenet Backbone Cabal in any formal sense, but there was plenty of
semi-(un)coordinated activity -- based largely on shared ideals -- that
gave that appearance. {I was there when Usenet/Netnews was invented,
closely observing, making minor and not-so-minor contributions, and was
responsible for some of the cabal-like activities.}
The mere coinage of terms like Lennertware, whether or not deserved,
show that there is a widespread awareness that some developers, in my
opinion, have over developed egos. [3]
It is all so trite to say become a developer and DO something instead
of complaining but it is not a realistic thing to say when the
problems are getting so large and interconnected. Furthermore, it
denigrates and devalues the pseudo-democratic processes that FOSS and
Linux have worked for years to nurture.
[1] Those who forget history are doomed to repeat it.
(paraphrase of George Santayana)
[2] See, for starters:
http://http://en.wikipedia.or/wiki/Backbone_cabal
[3] All Gods have feet of clay.
source uncertain.
(perhaps a reference to Ozymandias?
--
G.Wolfe Woodbury
{once upon a time AKA ...!duke!ggw}
Re: [gentoo-user] Systemd upower
Am 04.06.2014 06:05, schrieb Samuli Suominen: On 04/06/14 05:17, Dutch Ingraham wrote: No, sys-fs/udev is not masked, but an update is indicated in the emerge above. That's a good catch, the MATE stuff is from the overlay. Unfortunately, the xfce stuff is not, so even if the overlay currency was an issue, I'll still be showing some dependencies. Try re-emerging on un-emerging the offending packages, like xfce4-session and xfce4-power-manager, it has helped some people, to refresh the .ebuild copy that is installed with the .ebuild copy from Portage - Samuli Thanks - that fixed it for me: # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager xfce-extra/xfce4-systemload-plugin # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager xfce-extra/xfce4-systemload-plugin Greetings Daniel -- Get my PGP key at: * http://keyserver.ubuntu.com:11371/pks/lookup?op=getsearch=0x837FB8B5BB9D4887 * $ gpg --recv-keys --keyserver keyserver.ubuntu.com 0xBB9D4887 signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Systemd upower
Am 04.06.2014 13:22, schrieb Daniel Troeder: Am 04.06.2014 06:05, schrieb Samuli Suominen: On 04/06/14 05:17, Dutch Ingraham wrote: No, sys-fs/udev is not masked, but an update is indicated in the emerge above. That's a good catch, the MATE stuff is from the overlay. Unfortunately, the xfce stuff is not, so even if the overlay currency was an issue, I'll still be showing some dependencies. Try re-emerging on un-emerging the offending packages, like xfce4-session and xfce4-power-manager, it has helped some people, to refresh the .ebuild copy that is installed with the .ebuild copy from Portage - Samuli Thanks - that fixed it for me: # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager xfce-extra/xfce4-systemload-plugin # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager xfce-extra/xfce4-systemload-plugin Greetings Daniel BTW: I also had to unmerge gnome-base/gnome-control-center and gnome-base/gnome-settings-daemon and mask all gnome-* 3.10 -- Get my PGP key at: * http://keyserver.ubuntu.com:11371/pks/lookup?op=getsearch=0x837FB8B5BB9D4887 * $ gpg --recv-keys --keyserver keyserver.ubuntu.com 0xBB9D4887 signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Systemd upower
On 6/3/2014 1:08 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Jun 3, 2014 at 11:48 AM, Tanstaafl tansta...@libertytrek.org wrote: On 6/3/2014 11:10 AM, Canek Peláez Valdés can...@gmail.com wrote: Maybe. The thing is, this is going to keep happening, as more and more infrastructure migrates towards systemd. Perhaps a news item everytime it happens is unrealistic? Weren't you the one saying that those of us who were voicing concerns that systemd proponents were ultimately wanting to FORCE systemd on everyone were just scare-mongering conspiracy theorists? Who is forcing anything? I was specifically referring to your comment that: The thing is, this is going to keep happening, as more and more infrastructure migrates towards systemd. That comment right there - specifically the word *infrastructure* - screams to me 'we intend to take over the world'. And yes, as devs get lazier (decide to rely on systemd rather than build it to work independently of the init system), this will in fact result in *users* (read: those lacking the skills to code every program out there to work without systemd) eventually being *forced* to switch to systemd. That is simply the reality. You can ignore it if you like, but it doesn't change it. Forced is forced. That's what you and many others don't seem to understand: systemd is a *BETTER* implementation for basically *ALL* the hodgepodge of solutions that we had before in our plumbing layer. Time will tell, and you may even be right. The problem is, average users really don't have a way to prove this to themselves, all we see is the wailing and gnashing of teeth as stuff constantly *breaks* that *never* broke before.
Re: [gentoo-user] Systemd upower
On Tue, 03 Jun 2014 22:17:21 -0400 Dutch Ingraham s...@gmx.us wrote: That's a good catch, the MATE stuff is from the overlay. MATE 1.6 is stable in the Portage tree, MATE 1.8 is testing in the Portage tree; both had their upower dependencies fixed up days ago. -- 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 04/06/14 15:15, Daniel Troeder wrote: Am 04.06.2014 13:22, schrieb Daniel Troeder: Am 04.06.2014 06:05, schrieb Samuli Suominen: On 04/06/14 05:17, Dutch Ingraham wrote: No, sys-fs/udev is not masked, but an update is indicated in the emerge above. That's a good catch, the MATE stuff is from the overlay. Unfortunately, the xfce stuff is not, so even if the overlay currency was an issue, I'll still be showing some dependencies. Try re-emerging on un-emerging the offending packages, like xfce4-session and xfce4-power-manager, it has helped some people, to refresh the .ebuild copy that is installed with the .ebuild copy from Portage - Samuli Thanks - that fixed it for me: # emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager xfce-extra/xfce4-systemload-plugin # emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager xfce-extra/xfce4-systemload-plugin Greetings Daniel BTW: I also had to unmerge gnome-base/gnome-control-center and gnome-base/gnome-settings-daemon and mask all gnome-* 3.10 Yes, GNOME 3.12 is the first desktop in Portage that is forcing =sys-power/upower-0.99.0, therefore GNOME 3.12 can't be installed together with sys-power/upower-pm-utils It's expected that more and more packages will start requiring =sys-power/upower-0.99.0, so this sys-power/upower-pm-utils, is to be considered as a temporary solution, specially considering it has no upstream anymore So, if package you need sys-power/upower-pm-utils for, doesn't migrate it's code like Xfce did and directly use sys-power/pm-utils, so that it allows 0.99.0 installation, the package is bound to die That's the whole point of this requirement for manual intervention of user, he needs to make an informed decision what route he wants to go -- like extreme route, such as switching desktops from LXDE to Xfce, and such (This reply is not directly aimed at you, but to whole thread, just trying to raise public awareness, because maybe it will get someone to actually contribute some code to improve the situation) - Samuli
Re: [gentoo-user] Systemd upower
On Wed, Jun 4, 2014 at 8:21 AM, Tanstaafl tansta...@libertytrek.org wrote: And yes, as devs get lazier (decide to rely on systemd rather than build it to work independently of the init system), this will in fact result in *users* (read: those lacking the skills to code every program out there to work without systemd) eventually being *forced* to switch to systemd. That is simply the reality. You can ignore it if you like, but it doesn't change it. Forced is forced. Well, if your goal is to persuade people to change, I'd suggest taking that to the upower mailing list, since they're the ones who added the systemd requirement. All anybody at Gentoo did was fork it and provide an alternative. The fiasco was the result of it being unclear that the option existed. However, the general trend I've seen is that when people complain to upstreams that they don't want them to depend on systemd, upstream tends to tell them to go make their own upstream. So, instead they complain on lists that don't ban them, like this one. It doesn't really fix anything though - it just gets everybody upset and often results in misdirected anger. The only thing Samuli did was give non-systemd users a workaround for an upstream problem, and the news clarifying this came out a bit late. I generally intend to switch over to systemd, but I for one would love for there to be the option to use alternatives. Simply wishing that won't make it happen, and since i don't really intend to use the alternatives it is a bit hard to get the motivation to help fork the world. That's just the way the wind seems to be blowing these days. Rich
Re: [gentoo-user] Systemd upower
On 04/06/14 15:21, Tanstaafl wrote: On 6/3/2014 1:08 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Jun 3, 2014 at 11:48 AM, Tanstaafl tansta...@libertytrek.org wrote: On 6/3/2014 11:10 AM, Canek Peláez Valdés can...@gmail.com wrote: Maybe. The thing is, this is going to keep happening, as more and more infrastructure migrates towards systemd. Perhaps a news item everytime it happens is unrealistic? Weren't you the one saying that those of us who were voicing concerns that systemd proponents were ultimately wanting to FORCE systemd on everyone were just scare-mongering conspiracy theorists? Who is forcing anything? I was specifically referring to your comment that: The thing is, this is going to keep happening, as more and more infrastructure migrates towards systemd. That comment right there - specifically the word *infrastructure* - screams to me 'we intend to take over the world'. And yes, as devs get lazier (decide to rely on systemd rather than build it to work independently of the init system), this will in fact result in *users* (read: those lacking the skills to code every program out there to work without systemd) eventually being *forced* to switch to systemd. You can still install GNOME without systemd from Portage using the USE=openrc-force (which needs to be unmasked using /etc/portage/profile/use.mask line like -openrc-force) And nobody is ever forced to do anything within Open Source, you always have the option to contibute code, or donate money to get someone else contribute the code Calling volunteers who work without paycheck lazy is just bad behavior That is simply the reality. You can ignore it if you like, but it doesn't change it. Forced is forced. That's what you and many others don't seem to understand: systemd is a *BETTER* implementation for basically *ALL* the hodgepodge of solutions that we had before in our plumbing layer. Time will tell, and you may even be right. The problem is, average users really don't have a way to prove this to themselves, all we see is the wailing and gnashing of teeth as stuff constantly *breaks* that *never* broke before. Nothing has been broken so far yet. People are just facing hard realities and noticing some packages have been abandoned for years, even before systemd became popular as it is now. You can't blame systemd, upower, and other developers for ditching such outdated code and using what they like as they code it for their application. - Samuli
Re: [gentoo-user] Systemd upower
On 04/06/14 15:58, Rich Freeman wrote: On Wed, Jun 4, 2014 at 8:21 AM, Tanstaafl tansta...@libertytrek.org wrote: And yes, as devs get lazier (decide to rely on systemd rather than build it to work independently of the init system), this will in fact result in *users* (read: those lacking the skills to code every program out there to work without systemd) eventually being *forced* to switch to systemd. That is simply the reality. You can ignore it if you like, but it doesn't change it. Forced is forced. Well, if your goal is to persuade people to change, I'd suggest taking that to the upower mailing list, since they're the ones who added the systemd requirement. General misconseption here, let me clarify a bit. Instead, UPower upstream simply dropped unmaintained pm-utils code since pm-utils has been abandoned for years and nobody picked it up during these years. So, UPower didn't add any systemd requiring code, they simply dropped Hibernate/Suspend capability, and left it to other programs (such as systemd). Notice how UPower 0.99.0 doesn't have anykind of systemd dependency. The package simply, by design, isn't a package that does Hibernate/Suspend anymore. Fact that OpenRC doesn't have Hibernate/Suspend support is due to problem in our end, nobody is working on such code for OpenRC, like there are people working on such code for systemd. The only thing Samuli did was give non-systemd users a workaround for an upstream problem, and the news clarifying this came out a bit late. I generally intend to switch over to systemd, but I for one would love for there to be the option to use alternatives. Simply wishing that won't make it happen, and since i don't really intend to use the alternatives it is a bit hard to get the motivation to help fork the world. That's just the way the wind seems to be blowing these days. Rich You are right as for rest of the mail goes. Nobody can possible expect me to suddently come up with Hibernate/Suspend patch for OpenRC myself. I can state that I have no plans to work on anything like that without getting paid for it, and propably not even then, as I suspect it would be too big task for me to take up. I have no intentions in picking up pm-utils maintainership either. I have no idea how people will do Hibernate/Suspend in the future without systemd, I suspect it will get harder and harder. If I were to buy a new laptop today, I'd propably install systemd on it, to get up-to-date code for those tasks. So yeah, only working with what upstreams provide as a distribution maintainer/packager, and people shouldn't try to dump this somehow on me. Fact that they have some fallback, like upower-pm-utils at all, is something they should be grateful instead. (I hope I didn't mess up quoting in this mail.)
Re: [gentoo-user] Systemd upower
On Wed, 04 Jun 2014 08:21:51 -0400, Tanstaafl wrote: And yes, as devs get lazier (decide to rely on systemd rather than build it to work independently of the init system), Reusing existing, proven code is not laziness, it is efficiency. Yes, they could code their own version, but all the time they spend coding and testing it will not be spent on the actual project, we all end up with an inferior product. Also, by adding to the software the uses systemd, or any other underlying code, the number of users/testers of that code increases. You seem to think the Upower devs simply decided to use systemd instead of doing it themselves. In fact, they were always using code, from either systemd or pm-utils. The fact that development stopped on pm-utils is neither the fault of the Upower or systemd people. They were reduced to a choice of one and you blame them for making the wrong choice? -- Neil Bothwick Theory and practice are the same in theory, but different in practice signature.asc Description: PGP signature
Re: [gentoo-user] Systemd upower
On 04/06/14 16:47, Neil Bothwick wrote: On Wed, 04 Jun 2014 08:21:51 -0400, Tanstaafl wrote: And yes, as devs get lazier (decide to rely on systemd rather than build it to work independently of the init system), Reusing existing, proven code is not laziness, it is efficiency. Yes, they could code their own version, but all the time they spend coding and testing it will not be spent on the actual project, we all end up with an inferior product. Also, by adding to the software the uses systemd, or any other underlying code, the number of users/testers of that code increases. You seem to think the Upower devs simply decided to use systemd instead of doing it themselves. In fact, they were always using code, from either systemd or pm-utils. The fact that development stopped on pm-utils is neither the fault of the Upower or systemd people. They were reduced to a choice of one and you blame them for making the wrong choice? Well said.
Re: [gentoo-user] Systemd upower
On Wed, Jun 4, 2014 at 5:28 AM, Greg Woodbury redwo...@gmail.com wrote:
On 06/03/2014 10:05 PM, Canek Peláez Valdés wrote:
On Tue, Jun 3, 2014 at 8:37 PM, Greg Woodbury redwo...@gmail.com wrote:
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.
I was a developer for more years than I really care to remember. I
still try to contribute in ways and areas that I'm not so out-of-date with.
Good for you. Now, imagine you don't only contribute, but that you
actually *maintain* (as in, *you* are in charge) of project X. And
then you see that project X is so much easier to maintain if you
depend on project Y. So you make project Y a hard dependency of
project X.
And then a bunch of people who don't really know how to maintain code,
start yelling at you because you made project X dependant on project
Y. And they *demand* of you that you should not depend on Y, but they
don't provide the code to do it,
Will you drop dependency on project Y, even if it makes your life as a
maintainer several times easier?
Furthermore, it is a two-way street (as I see it.) The developers write
things they find interesting and enjoyable to work on, and users use
things that are interesting and work well. For many, seeing other folks
use what they have written provides a significant measure of the
enjoyment derived from the exercise.
That does not contradicts anything I have said.
To see this as only freedom for the developer is part of an attitude
shift over the years that only lessens the overall usefulness of Linux
and FOSS. It does, in fact, push quite a few folk I know away from the
Linux arena. It is, to use a political analogy, like the people who
claim there is not any real difference between *any* opposing
political movements -- that neglects taking into account a great deal of
technical and historical details.
I have no idea what do you mean by the last paragraph. This is not a
political discusion (although many would like to see it that way). It
is a *technical* discusion, and therefore there is no real discusion:
the general consensus is that systemd is the technological superior
alternative.
I occasionally think about forking projects and fixing some of the
things I think are the most egregious fsck-ups in some of them, but then
I really look at what I'm doing and what I enjoy doing, and realize that
I won't get enough (emotional?) reward for giving up time in other
significant parts of my life.
And that's your right, and it's fine. But let *other* developers
choose whatever technologies they want to choose, and (consequently)
drop support for obsolete technologies like pm-utils.
That's the reason for this whole thread: developers chose the
technological superior alternative; saying that the reason for that is
that there is cabals and conspiracies is blatant ignorance (in the
best case), or spreading FUD (in the worst case).
Or help Samuli to maintain upower-pm-utils; that would be *much* more
helpful than spreding FUD about cabals and conspiracies.
There is no need for me to invent Fear, Uncertainty, and Doubt -- the
folks involved are doing quite well on their own.
I never said you invented it. I say you are spreading it, and I
still think that's the case.
Also, history (for
those not doomed to repeat it [1]) provides all that is required to make
calling it a cabal [TINC - there is no cabal![2]] There never was a
Usenet Backbone Cabal in any formal sense, but there was plenty of
semi-(un)coordinated activity -- based largely on shared ideals -- that
gave that appearance. {I was there when Usenet/Netnews was invented,
closely observing, making minor and not-so-minor contributions, and was
responsible for some of the cabal-like activities.}
Great; so any kind of group work semi-(un)coordinated can be called
a cabal, and it has no (inherent) negative connotation. Then the Linux
Kernel developers is a Cabal; the GNOME devs is a Cabal; the KDE ones
are also a Cabal; and of course the Gentoo Developers who *oppose*
systemd is a Cabal, and so are the ones that *support* systemd.
So you yourself are saying that calling out a Cabal of systemd
proponents have no meaning at all whatsoever, because *EVERYTHING* is
a Cabal.
The mere coinage of terms like Lennertware, whether or not deserved,
show that there is a widespread awareness that some developers, in my
opinion, have over developed egos. [3]
Yeah, please go
Re: [gentoo-user] Systemd upower
On Wed, Jun 4, 2014 at 7:21 AM, Tanstaafl tansta...@libertytrek.org wrote: On 6/3/2014 1:08 PM, Canek Peláez Valdés can...@gmail.com wrote: [ ... ] Who is forcing anything? I was specifically referring to your comment that: The thing is, this is going to keep happening, as more and more infrastructure migrates towards systemd. That comment right there - specifically the word *infrastructure* - screams to me 'we intend to take over the world'. Well, yeah; that has been the objective from day 1. That systemd is used by default by almost all Linux users and distributions. Nobody has ever claimed anything on the contrary. And we are pretty advanced in that objective, by the way. That doesn't mean that anything is being force on anyone. SysV is still available, and so it is OpenRC, and so it is pm-utils (although it's been 5 years since last updated). Go on and use them if you want. Oh, you want *someone else* to do that work for you? Sorry, is not going to happen. You want that ALL the infrastructure to keep working with something else besides systemd? Go on and make it work with OpenRC, pm-utils, ConsoleKit and HAL. Oh, you want *someone else* to do that work for you? Sorry, not gonna happen. If the people *IN CHARGE* of the infrastructure decides to use systemd, they are not forcing nothing on no one. They are taking *their code* and making it better by using the technologically superior option. And yes, as devs get lazier (decide to rely on systemd rather than build it to work independently of the init system), Really? They are lazy? That means is easy to not rely on systemd, right? So go on and make their projects not to rely on systemd, if it is so easy. this will in fact result in *users* (read: those lacking the skills to code every program out there to work without systemd) eventually being *forced* to switch to systemd. NO THEY ARE NOT. Really, almost *all* the code we Linux users get to use is a freakin' *GIFT*, and the developers responsible for it decide to use A BETTER OPTION (like systemd is), and some people have the *audacity* to call that forcing them something? THE CODE IS FREE, for all the meanings of the word free. Therefore, there is no forcing of NOTHING on NO ONE. There can't be. Seriously, I haven't ever said what I'm about to say, but I'm getting really tired of this same old discussion about some users thinking they have the right to tell developers what they can or can't use in their code. You want your Linux to behave like the Unices of the 70's? Forget it; that train is gone. Linux (as in mainstream) is going to use systemd everywhere, from embedded to big iron, and that is for the best. If you want a 70's-like Unix, go on and install FreeBSD. That is simply the reality. You can ignore it if you like, but it doesn't change it. Forced is forced. No, it's a reality you invented in your head. Take the code and do wonders with it; is free. Oh, you can't? Then you are not being forced anything; you are just unable to make the things work like you want. That's totally different. That's what you and many others don't seem to understand: systemd is a *BETTER* implementation for basically *ALL* the hodgepodge of solutions that we had before in our plumbing layer. Time will tell, and you may even be right. The problem is, average users really don't have a way to prove this to themselves, all we see is the wailing and gnashing of teeth as stuff constantly *breaks* that *never* broke before. Really, Tanstaafl? Because in this list I usually see the *SAME* small group of people complaining about systemd. From time to time some new systemd user asks about some issues they found, but for the most part they (with the list help) solve those issues. And the world goes on. Users didn't abandoned Fedora, OpenSuse, Arch, Debian nor Ubuntu en masse when they decided to switch to systemd. There were complains, sure; but now it seems to have calmed down. Most systemd users (wether they chose to use systemd or their distributions did it for them) seem to be happy. And guess what? They will not abandon Gentoo if it ever decides to switch to systemd. Although I'm pretty sure a small (tiny, really) number of fundamentalist users will go to *BSD. And that's their choice. Perhaps you should consider doing that? And I'm saying that with all due respect; but be aware that on *BSD, the developers there also make their own decisions. If you want your systemd *exactly* the way you want it, you have to write it yourself. Nobody is going to do it for you. 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/04/2014 07:22 AM, Daniel Troeder wrote:
Am 04.06.2014 06:05, schrieb Samuli Suominen:
On 04/06/14 05:17, Dutch Ingraham wrote:
No, sys-fs/udev is not masked, but an update is indicated in the
emerge above. That's a good catch, the MATE stuff is from the overlay.
Unfortunately, the xfce stuff is not, so even if the overlay currency
was an issue, I'll still be showing some dependencies.
Try re-emerging on un-emerging the offending packages, like
xfce4-session and xfce4-power-manager,
it has helped some people, to refresh the .ebuild copy that is installed
with the .ebuild copy from
Portage
- Samuli
Thanks - that fixed it for me:
# emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
# emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
Greetings
Daniel
Unfortunately, this doesn't work for me. So let me re-cap: I have
1. removed upower and installed upower-pm-utils; that did not work;
2. masked first gentoo-systemd-integration, which didn't work, then
masked systemd as well; that hasn't worked;
3. ran equery depends upower and removed the remaining
upower-dependent MATE and XFCE packages; that has not worked;
4. masked virtual/udev-208-r2; that has not worked.
I am still left with:
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 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 U ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 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)
[ebuild N ] xfce-base/xfce4-session-4.10.1-r1 USE=nls udev
xscreensaver -debug -systemd 0 kB
[ebuild N ] mate-base/mate-applets-1.6.2-r1 USE=X ipv6 policykit
-networkmanager PYTHON_SINGLE_TARGET=python2_7 (-python2_6)
PYTHON_TARGETS=python2_7 (-python2_6) 0 kB
[ebuild N~] mate-extra/mate-power-manager-1.6.3::mate-overlay
USE=applet policykit -gnome-keyring -man {-test} 0 kB
[ebuild N~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
USE=ipv6 -debug -systemd 0 kB
[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: 13 packages (2 upgrades, 8 new, 3 reinstalls, 1 uninstall), Size
of downloads: 45,580 kB
Conflict: 4 blocks (3 unsatisfied)
Does anyone have any further suggestions?
Re: [gentoo-user] Systemd upower
Am Wed, 04 Jun 2014 16:08:02 +0300 schrieb Samuli Suominen ssuomi...@gentoo.org: [...] So yeah, only working with what upstreams provide as a distribution maintainer/packager, and people shouldn't try to dump this somehow on me. Fact that they have some fallback, like upower-pm-utils at all, is something they should be grateful instead. [...] I'm grateful! In fact, since I have this opportunity: thank you and all the other devs for your hard work, and for withstanding insufferable users :) . -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup signature.asc Description: PGP signature
Re: [gentoo-user] Systemd upower
On Wednesday 04 June 2014 20:28:22 Marc Joliet wrote: I'm grateful! In fact, since I have this opportunity: thank you and all the other devs for your hard work, and for withstanding insufferable users :) . [AOL] Me too. [/AOL] -- Regards Peter
Re: [gentoo-user] Systemd upower
On 04/06/14 20:11, Dutch Ingraham wrote:
On 06/04/2014 07:22 AM, Daniel Troeder wrote:
Am 04.06.2014 06:05, schrieb Samuli Suominen:
On 04/06/14 05:17, Dutch Ingraham wrote:
No, sys-fs/udev is not masked, but an update is indicated in the
emerge above. That's a good catch, the MATE stuff is from the overlay.
Unfortunately, the xfce stuff is not, so even if the overlay currency
was an issue, I'll still be showing some dependencies.
Try re-emerging on un-emerging the offending packages, like
xfce4-session and xfce4-power-manager,
it has helped some people, to refresh the .ebuild copy that is installed
with the .ebuild copy from
Portage
- Samuli
Thanks - that fixed it for me:
# emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
# emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
Greetings
Daniel
Unfortunately, this doesn't work for me. So let me re-cap: I have
4. masked virtual/udev-208-r2; that has not worked.
First, remove that mask. Masking it will certainly cause more blockers,
than solve them.
[ebuild N~] mate-extra/mate-power-manager-1.6.3::mate-overlay
USE=applet policykit -gnome-keyring -man {-test} 0 kB
[ebuild N~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
USE=ipv6 -debug -systemd 0 kB
see ::mate-overlay, it's presumably broken or outdated. stop using the
overlay and use MATE from Portage instead.
or you can mask the packages from overlay, the syntax is like:
/etc/portage/package.mask
mate-extra/mate-power-manager::mate-overlay
mate-base/mate-session-manager::mate-overlay
- Samuli
Re: [gentoo-user] Systemd upower
On 06/04/2014 03:17 PM, Samuli Suominen wrote:
On 04/06/14 20:11, Dutch Ingraham wrote:
On 06/04/2014 07:22 AM, Daniel Troeder wrote:
Am 04.06.2014 06:05, schrieb Samuli Suominen:
On 04/06/14 05:17, Dutch Ingraham wrote:
No, sys-fs/udev is not masked, but an update is indicated in the
emerge above. That's a good catch, the MATE stuff is from the overlay.
Unfortunately, the xfce stuff is not, so even if the overlay currency
was an issue, I'll still be showing some dependencies.
Try re-emerging on un-emerging the offending packages, like
xfce4-session and xfce4-power-manager,
it has helped some people, to refresh the .ebuild copy that is installed
with the .ebuild copy from
Portage
- Samuli
Thanks - that fixed it for me:
# emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
# emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
Greetings
Daniel
Unfortunately, this doesn't work for me. So let me re-cap: I have
4. masked virtual/udev-208-r2; that has not worked.
First, remove that mask. Masking it will certainly cause more blockers,
than solve them.
[ebuild N~] mate-extra/mate-power-manager-1.6.3::mate-overlay
USE=applet policykit -gnome-keyring -man {-test} 0 kB
[ebuild N~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
USE=ipv6 -debug -systemd 0 kB
see ::mate-overlay, it's presumably broken or outdated. stop using the
overlay and use MATE from Portage instead.
or you can mask the packages from overlay, the syntax is like:
/etc/portage/package.mask
mate-extra/mate-power-manager::mate-overlay
mate-base/mate-session-manager::mate-overlay
- Samuli
Thanks everybody for your help. I've made the further suggested
changes, but I remain with the three hard blocks.
I've now spent about 7 hours over the last two days on this issue (about
2x the fresh install time), when all I wanted to do was a routine
update. I've reworked a large part of my system, adding a new
package.mask file and populating it with six packages.
I suppose its now time for an uninstall. Kind of disappointing; we are
told Gentoo is about choices, and in fact that's true. I made the
choice to use a pure openRC system. The last 7 hours of free time,
though, was spent trying, and ultimately failing, to correct a problem
not chosen, not wanted, and not invited.
The sine qua non is unarguably systemd. Even though my choice was to
not deploy it, apparently it takes a significant time commitment and/or
developer-level knowledge to choose to not use it. Quite the inelegant
end to my once-trusty OS.
Re: [gentoo-user] Systemd upower
On Thu, Jun 5, 2014 at 2:15 AM, Dutch Ingraham s...@gmx.us wrote:
On 06/04/2014 03:17 PM, Samuli Suominen wrote:
On 04/06/14 20:11, Dutch Ingraham wrote:
On 06/04/2014 07:22 AM, Daniel Troeder wrote:
Am 04.06.2014 06:05, schrieb Samuli Suominen:
On 04/06/14 05:17, Dutch Ingraham wrote:
No, sys-fs/udev is not masked, but an update is indicated in the
emerge above. That's a good catch, the MATE stuff is from the overlay.
Unfortunately, the xfce stuff is not, so even if the overlay currency
was an issue, I'll still be showing some dependencies.
Try re-emerging on un-emerging the offending packages, like
xfce4-session and xfce4-power-manager,
it has helped some people, to refresh the .ebuild copy that is installed
with the .ebuild copy from
Portage
- Samuli
Thanks - that fixed it for me:
# emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
# emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
Greetings
Daniel
Unfortunately, this doesn't work for me. So let me re-cap: I have
4. masked virtual/udev-208-r2; that has not worked.
First, remove that mask. Masking it will certainly cause more blockers,
than solve them.
[ebuild N~] mate-extra/mate-power-manager-1.6.3::mate-overlay
USE=applet policykit -gnome-keyring -man {-test} 0 kB
[ebuild N~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
USE=ipv6 -debug -systemd 0 kB
see ::mate-overlay, it's presumably broken or outdated. stop using the
overlay and use MATE from Portage instead.
or you can mask the packages from overlay, the syntax is like:
/etc/portage/package.mask
mate-extra/mate-power-manager::mate-overlay
mate-base/mate-session-manager::mate-overlay
- Samuli
Thanks everybody for your help. I've made the further suggested
changes, but I remain with the three hard blocks.
I've now spent about 7 hours over the last two days on this issue (about
2x the fresh install time), when all I wanted to do was a routine
update. I've reworked a large part of my system, adding a new
package.mask file and populating it with six packages.
I suppose its now time for an uninstall. Kind of disappointing; we are
told Gentoo is about choices, and in fact that's true. I made the
choice to use a pure openRC system. The last 7 hours of free time,
though, was spent trying, and ultimately failing, to correct a problem
not chosen, not wanted, and not invited.
The sine qua non is unarguably systemd. Even though my choice was to
not deploy it, apparently it takes a significant time commitment and/or
developer-level knowledge to choose to not use it. Quite the inelegant
end to my once-trusty OS.
You are right, all I can say is that I am sorry we treat users like
that. We forget that our task is to ease deployment of upstream
projects to end users. What we experience is only the start of the
mess of having two separate contradictory layouts within stable tree,
without decent profile setups to protect users from pulling layout
they are not interested in.
Alon
Re: [gentoo-user] Systemd upower
On Wed, 04 Jun 2014 19:15:22 -0400, Dutch Ingraham wrote: I suppose its now time for an uninstall. Kind of disappointing; we are told Gentoo is about choices, and in fact that's true. I made the choice to use a pure openRC system. The last 7 hours of free time, though, was spent trying, and ultimately failing, to correct a problem not chosen, not wanted, and not invited. ...and not of Gentoo's doing. You are trying to blame Gentoo for a problem arising from an overlay. A more productive use of your time would be to inform the overlay's maintainers about your problem and request a fix, which may well be a simple ebuild tweak. -- Neil Bothwick ...and that is how we know the Earth to be banana-shaped. signature.asc Description: PGP signature
Re: [gentoo-user] Systemd upower
On 05/06/14 02:15, Dutch Ingraham wrote:
On 06/04/2014 03:17 PM, Samuli Suominen wrote:
On 04/06/14 20:11, Dutch Ingraham wrote:
On 06/04/2014 07:22 AM, Daniel Troeder wrote:
Am 04.06.2014 06:05, schrieb Samuli Suominen:
On 04/06/14 05:17, Dutch Ingraham wrote:
No, sys-fs/udev is not masked, but an update is indicated in the
emerge above. That's a good catch, the MATE stuff is from the overlay.
Unfortunately, the xfce stuff is not, so even if the overlay currency
was an issue, I'll still be showing some dependencies.
Try re-emerging on un-emerging the offending packages, like
xfce4-session and xfce4-power-manager,
it has helped some people, to refresh the .ebuild copy that is installed
with the .ebuild copy from
Portage
- Samuli
Thanks - that fixed it for me:
# emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
# emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
Greetings
Daniel
Unfortunately, this doesn't work for me. So let me re-cap: I have
4. masked virtual/udev-208-r2; that has not worked.
First, remove that mask. Masking it will certainly cause more blockers,
than solve them.
[ebuild N~] mate-extra/mate-power-manager-1.6.3::mate-overlay
USE=applet policykit -gnome-keyring -man {-test} 0 kB
[ebuild N~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
USE=ipv6 -debug -systemd 0 kB
see ::mate-overlay, it's presumably broken or outdated. stop using the
overlay and use MATE from Portage instead.
or you can mask the packages from overlay, the syntax is like:
/etc/portage/package.mask
mate-extra/mate-power-manager::mate-overlay
mate-base/mate-session-manager::mate-overlay
- Samuli
Thanks everybody for your help. I've made the further suggested
changes, but I remain with the three hard blocks.
I've now spent about 7 hours over the last two days on this issue (about
2x the fresh install time), when all I wanted to do was a routine
update. I've reworked a large part of my system, adding a new
package.mask file and populating it with six packages.
I suppose its now time for an uninstall. Kind of disappointing; we are
told Gentoo is about choices, and in fact that's true. I made the
choice to use a pure openRC system. The last 7 hours of free time,
though, was spent trying, and ultimately failing, to correct a problem
not chosen, not wanted, and not invited.
The sine qua non is unarguably systemd. Even though my choice was to
not deploy it, apparently it takes a significant time commitment and/or
developer-level knowledge to choose to not use it. Quite the inelegant
end to my once-trusty OS.
Gentoo doesn't have write access to ::mate-overlay, it's completely
unofficial
Gentoo developers are just as much users as you are for ::mate-overlay
Enough said
- Samuli
Re: [gentoo-user] Systemd upower
On 05/06/14 02:25, Alon Bar-Lev wrote:
On Thu, Jun 5, 2014 at 2:15 AM, Dutch Ingraham s...@gmx.us wrote:
On 06/04/2014 03:17 PM, Samuli Suominen wrote:
On 04/06/14 20:11, Dutch Ingraham wrote:
On 06/04/2014 07:22 AM, Daniel Troeder wrote:
Am 04.06.2014 06:05, schrieb Samuli Suominen:
On 04/06/14 05:17, Dutch Ingraham wrote:
No, sys-fs/udev is not masked, but an update is indicated in the
emerge above. That's a good catch, the MATE stuff is from the overlay.
Unfortunately, the xfce stuff is not, so even if the overlay currency
was an issue, I'll still be showing some dependencies.
Try re-emerging on un-emerging the offending packages, like
xfce4-session and xfce4-power-manager,
it has helped some people, to refresh the .ebuild copy that is installed
with the .ebuild copy from
Portage
- Samuli
Thanks - that fixed it for me:
# emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
# emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
Greetings
Daniel
Unfortunately, this doesn't work for me. So let me re-cap: I have
4. masked virtual/udev-208-r2; that has not worked.
First, remove that mask. Masking it will certainly cause more blockers,
than solve them.
[ebuild N~] mate-extra/mate-power-manager-1.6.3::mate-overlay
USE=applet policykit -gnome-keyring -man {-test} 0 kB
[ebuild N~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
USE=ipv6 -debug -systemd 0 kB
see ::mate-overlay, it's presumably broken or outdated. stop using the
overlay and use MATE from Portage instead.
or you can mask the packages from overlay, the syntax is like:
/etc/portage/package.mask
mate-extra/mate-power-manager::mate-overlay
mate-base/mate-session-manager::mate-overlay
- Samuli
Thanks everybody for your help. I've made the further suggested
changes, but I remain with the three hard blocks.
I've now spent about 7 hours over the last two days on this issue (about
2x the fresh install time), when all I wanted to do was a routine
update. I've reworked a large part of my system, adding a new
package.mask file and populating it with six packages.
I suppose its now time for an uninstall. Kind of disappointing; we are
told Gentoo is about choices, and in fact that's true. I made the
choice to use a pure openRC system. The last 7 hours of free time,
though, was spent trying, and ultimately failing, to correct a problem
not chosen, not wanted, and not invited.
The sine qua non is unarguably systemd. Even though my choice was to
not deploy it, apparently it takes a significant time commitment and/or
developer-level knowledge to choose to not use it. Quite the inelegant
end to my once-trusty OS.
You are right, all I can say is that I am sorry we treat users like
that. We forget that our task is to ease deployment of upstream
projects to end users. What we experience is only the start of the
mess of having two separate contradictory layouts within stable tree,
without decent profile setups to protect users from pulling layout
they are not interested in.
We? The ::mate-overlay maintainers? You are involved in the
::mate-overlay development then?
Re: [gentoo-user] Systemd upower
On Thu, Jun 5, 2014 at 3:07 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
On 05/06/14 02:25, Alon Bar-Lev wrote:
On Thu, Jun 5, 2014 at 2:15 AM, Dutch Ingraham s...@gmx.us wrote:
On 06/04/2014 03:17 PM, Samuli Suominen wrote:
On 04/06/14 20:11, Dutch Ingraham wrote:
On 06/04/2014 07:22 AM, Daniel Troeder wrote:
Am 04.06.2014 06:05, schrieb Samuli Suominen:
On 04/06/14 05:17, Dutch Ingraham wrote:
No, sys-fs/udev is not masked, but an update is indicated in the
emerge above. That's a good catch, the MATE stuff is from the overlay.
Unfortunately, the xfce stuff is not, so even if the overlay currency
was an issue, I'll still be showing some dependencies.
Try re-emerging on un-emerging the offending packages, like
xfce4-session and xfce4-power-manager,
it has helped some people, to refresh the .ebuild copy that is installed
with the .ebuild copy from
Portage
- Samuli
Thanks - that fixed it for me:
# emerge -C xfce-base/xfce4-session xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
# emerge -uND xfce-base/xfce4-meta xfce-extra/xfce4-power-manager
xfce-extra/xfce4-systemload-plugin
Greetings
Daniel
Unfortunately, this doesn't work for me. So let me re-cap: I have
4. masked virtual/udev-208-r2; that has not worked.
First, remove that mask. Masking it will certainly cause more blockers,
than solve them.
[ebuild N~] mate-extra/mate-power-manager-1.6.3::mate-overlay
USE=applet policykit -gnome-keyring -man {-test} 0 kB
[ebuild N~] mate-base/mate-session-manager-1.6.1-r1::mate-overlay
USE=ipv6 -debug -systemd 0 kB
see ::mate-overlay, it's presumably broken or outdated. stop using the
overlay and use MATE from Portage instead.
or you can mask the packages from overlay, the syntax is like:
/etc/portage/package.mask
mate-extra/mate-power-manager::mate-overlay
mate-base/mate-session-manager::mate-overlay
- Samuli
Thanks everybody for your help. I've made the further suggested
changes, but I remain with the three hard blocks.
I've now spent about 7 hours over the last two days on this issue (about
2x the fresh install time), when all I wanted to do was a routine
update. I've reworked a large part of my system, adding a new
package.mask file and populating it with six packages.
I suppose its now time for an uninstall. Kind of disappointing; we are
told Gentoo is about choices, and in fact that's true. I made the
choice to use a pure openRC system. The last 7 hours of free time,
though, was spent trying, and ultimately failing, to correct a problem
not chosen, not wanted, and not invited.
The sine qua non is unarguably systemd. Even though my choice was to
not deploy it, apparently it takes a significant time commitment and/or
developer-level knowledge to choose to not use it. Quite the inelegant
end to my once-trusty OS.
You are right, all I can say is that I am sorry we treat users like
that. We forget that our task is to ease deployment of upstream
projects to end users. What we experience is only the start of the
mess of having two separate contradictory layouts within stable tree,
without decent profile setups to protect users from pulling layout
they are not interested in.
We? The ::mate-overlay maintainers? You are involved in the
::mate-overlay development then?
This effected stable tree of Gentoo as well, pulling undesired
different layout into stable is something that should have been
avoided. It is about time we split the profiles, systemd is not option
for people who runs openrc.
Re: [gentoo-user] Systemd upower
On 05/06/14 03:22, Alon Bar-Lev wrote: This effected stable tree of Gentoo as well, pulling undesired different layout into stable is something that should have been avoided. It is about time we split the profiles, systemd is not option for people who runs openrc. Indeed, I support the idea of having separate systemd profiles too, could have simply dropped a package.mask entry in base/ then, and then counter-effected it in systemd profiles - Samuli
Re: [gentoo-user] Systemd upower
On Wed, Jun 4, 2014 at 8:46 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 05/06/14 03:22, Alon Bar-Lev wrote: This effected stable tree of Gentoo as well, pulling undesired different layout into stable is something that should have been avoided. It is about time we split the profiles, systemd is not option for people who runs openrc. Indeed, I support the idea of having separate systemd profiles too, could have simply dropped a package.mask entry in base/ then, and then counter-effected it in systemd profiles There is apparently an interest in building a profile which doesn't install openrc (which still needs some work), so you might eventually get your wish. Rich
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
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] 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] 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] 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] 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] 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
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] 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
