SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
First of all, this does not mean that a release is imminent - like many of you, I definitely think that -current is shaping up quite nicely right now and is getting close to release quality, but of course, that's not my decision (and I can always find "just one more thing" to add/upgrade/whatever) :-)
I've already got these queued up for consideration:
* bluez-5.x, sbc, blueman-2.0.x, Cython (build dep for blueman)
* polkit-0.113 and polkit-gnome-0.105 -- these are quite different and thus may not make the cut. They're working well here but it wouldn't hurt to get some more testing; if anyone's interested, mail me and I'll provide links.
* upower 0.99.3 ?? This has a minor (IMHO) regression with respect to 0.9.23, but we would get a maintained version instead of an abandoned-by-upstream branch. The regression is basically this: upower-0.9.23 advised whether suspend/hibernate was possible itself, i.e. apps like xfce4-power-manager asked upower if it was possible and then invoked the suspend/hibernate by some means (in the case of xfpm, via pm-(suspend|hibernate)). That ability was removed from upower, so now ConsoleKit2 handles that side of things. However, CK2 only implemented a check for whether the hardware is *capable* of suspend/hibernate, which means that there is *not* a check for whether hibernate is actually *possible* - i.e. is there enough swap space available? The result is that in e.g. xfce, the hibernate option is always present in the logout dialog if the system is capable of hibernating, even though the system may not have enough swap space to do so (in my case, there is zero swap space). Is this a sufficient regression to avoid upower-0.99.3? Alternatively, does someone with more time want to grab the code from upower-0.99.3 and make whatever changes are needed to merge it into upstream CK2 (assuming license compatibility) and do a pull request with them? I glanced over it, and it looks relatively trivial to do for someone competent (I think even I can do it, so competence isn't necessarily a requirement ;-) - I just don't have time at the moment). If so, there's already an open issue there on the CK2 github page - just reference that in your PR. I'll be happy to test and add a Signed-Off-By on the PR if you'd like.
EDIT: upower-0.99.3 is out of the running for this cycle - it's fine with xfce, but kde is not. Maybe next time. :-)
pprkut has these things queued up already:
* iftop libevent libodfgen mpg123 sqlite taglib wavpack
We already know that PAM is desired by some and not by others. This is not a place to discuss it or give pros/cons of either, as those are pretty much known too. Whether it's ever been or is currently under consideration is not my place to say, but I will point out that every time there's a new flame fest about it, none of us want to touch it again for a while. Let that be a point of education.
Last edited by rworkman; 12-19-2015 at 11:16 PM.
Reason: Updates are public! :-D
I have a question, to the new gcc5.3
there was an ABI change in libstdc++, and the new ABI should be default on, except it was changed.
so I would expect to see more packages rebuilded.
Or is it turned off? This would be not so cool because that would mean that shipped C++ library is not ISO standard compatible, that's why sting and list where changed.
and will be incompatible with the rest of the world because I expect the rest of the world to switch to ISO standard implementation as soon as it is default from the compiler, which is with gcc5.3
I would like to see the certwatch cronjob in openssl patched, as it stands it does basically nothing, as it only looks for regular files in /etc/ssl/certs, while the directory is populated by symlinks to /usr/share/ca-certificates.
Code:
--- certwatch.new 2015-12-02 23:02:37.000000000 +0100
+++ certwatch 2015-12-12 23:57:11.566226350 +0100
@@ -83,8 +83,9 @@
fi
done
-find $CERTDIR -type f -maxdepth 1 | while read certfile ; do
- if [ "$certfile" != "/etc/ssl/certs/ca-certificates.crt" ]; then
+find $CERTDIR \( -type f -o -type l \) -maxdepth 1 | while read certfile ; do
+ if [ "$certfile" != "$CERTDIR/ca-certificates.crt" ]; then
+ certfile="$(realpath "$certfile")"
certfilebase="$(basename "$certfile")"
inform=PEM
echo "$certfile" | grep -q -i '\.net$'
Robby, avoid upower-0.99.3. It breaks the desktop completely last I tried it. Icons literally were a mess. It's built solely for systemd-logind usage. The real problem is pm-utils. The pm-utils, upower, and xfce4-power-manager all have some cyclical dependencies so you have to rebuild each package a few times to match the dependencies correctly. The problem is, if pm-utils isn't dependency matched to upower and xfce4-power-manager isn't built for upower and pm-utils, it tends to start misbehaving.
This is actually a package I've had to rebuild even in 14.1 because it was targeting an older dependency library.
Upower-0.9.23 should work fine with sysvinit utility based or derived without issue.
I still suggest support out of the box for old music tracker files including libmodplug and rebuilding audaciuous-plugins against it. Someone also mentioned gstreamer rebuild agains libmodplug for the same reason.
rc.S: If executable, start rc.cgmanager.
rc.6: If executable, stop rc.cgmanager.
Running cgmanager from rc.S doesn't make sense to me. Switching to runlevel 1 will kill it and switching back to runlevel 3 won't start it. It is a d-bus controlled daemon and should be run in rc.M after rc.messagebus.
Robby, avoid upower-0.99.3. It breaks the desktop completely last I tried it. Icons literally were a mess.
That's a local system issue caused by not recompiling something, most likely xfce4-settings.
Quote:
It's built solely for systemd-logind usage. The real problem is pm-utils.
Nope. pm-utils is just a set of scripts, and they do what they do regardless of upower.
Quote:
The pm-utils, upower, and xfce4-power-manager all have some cyclical dependencies so you have to rebuild each package a few times to match the dependencies correctly. The problem is, if pm-utils isn't dependency matched to upower and xfce4-power-manager isn't built for upower and pm-utils, it tends to start misbehaving.
There is at least one, and maybe two, actual problem(s) with upower-0.99.3. The handwaving above is not one of them.
Quote:
This is actually a package I've had to rebuild even in 14.1 because it was targeting an older dependency library.
I don't understand the expectation here - my (realistic IMHO) expectation is that recompiles will be needed. Why would you expect otherwise?
Quote:
Upower-0.9.23 should work fine with sysvinit utility based or derived without issue.
Agreed, but that's not the issue. It also has at least one bug here that is a showstopper for me (and will be for others who depend on that particular feature), and while I've managed to backport a patch from master to fix one of the bugs, at least one remains. More importantly, the 0.9.23 branch is simply not maintained, so fixes to things like blacklisting hid devices and enhancing support for multiple batteries won't make it there (and backporting multiple battery support is not trivial - I tried).
Running cgmanager from rc.S doesn't make sense to me.
The lxc guys (cgmanager devs) suggested that it should be started when the cgroups stuff is set up, which is done in rc.S, so that's why it was started there.
Quote:
Switching to runlevel 1 will kill it and switching back to runlevel 3 won't start it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.