LinuxQuestions.org - [SOLVED] Requests for -current (20151216)

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Requests for -current (20151216) (https://www.linuxquestions.org/questions/slackware-14/requests-for-current-20151216-a-4175561577/)

Requests for -current (20151216)

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.

Dammit. I broke slackpkg. Until Pat gets a fix out, here it is:
Open /usr/libexec/slackpkg/core-functions.sh
Go to line #282
You should see this:

Code:

to the closest mirror and is very slow.\n\"

Make it this:

Code:

to the closest mirror and is very slow.\n"

Sincerest apologies for not keeping the stuff in my pending tree in sync with the stuff on my testing system. :(

EDIT: Fixed now; hopefully nobody even got a broken package :-)

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.

xfce4-power-manager (1.5 version) support Upower-0.9.23

http://archive.xfce.org/src/xfce/xfc...r-manager/1.5/

it compil perfectly, but i don't have laptop, for testing correctly.

Oops sorry ;)

xfce4-power-manager (1.5 version) support Upower-0.99.3

http://archive.xfce.org/src/xfce/xfc...r-manager/1.5/

it compil perfectly, but i don't have laptop, for testing correctly.

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.

Since the old thread is locked i will repost here.
sunet.se mirrors should be removed from /etc/slackpkg/mirrors since they don't host linux distributions any more and the links are dead.
http://www.linuxquestions.org/questi...4/#post5426031
http://www.linuxquestions.org/questi...ml#post5456931

I will ask for it again: FluidSynth added, and SDL_mixer rebuilt against it.

Quote:

a/sysvinit-scripts-2.0-noarch-25.txz: Rebuilt.

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.

Cheers

Quote:

Originally Posted by ReaperX7 (Post 5464971)

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).

Quote:

Originally Posted by ivandi (Post 5465121)

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.

That's a valid point...

After a few minutes of play there is now a politely worded 'nag' screen for the electricsheep screensaver, top left corner:

Code:

please update to latest client from www.electricsheep.org

Currently (sic) we have v2.7b11 while v2.7b33 is available online. I confess I have not yet investigated the newer version...

Nice upgrades from changelog "Wed Dec 16 04:21:07 UTC 2015", thank you.

Can you upgrade these softwares as well?

at 3.1.12 --> 3.1.16
diffstat 1.53 --> 1.60
enscript 1.6.5.2 --> 1.6.6
joe 3.7 --> 4.1
lsof 4.83 --> 4.89
rpm 4.10.0 --> 4.12.0.1
soma 2.8.5 --> 2.10.4
sysstat 9.0.6.1 --> 11.0.8

http://anonscm.debian.org/cgit/collab-maint/at.git
ftp://invisible-island.net/diffstat
http://ftp.gnu.org/gnu/enscript
http://sourceforge.net/projects/joe-editor
ftp://sunsite.ualberta.ca/pub/Mirror/lsof
http://rpm.org
http://dawoodfall.net/slackbuilds/noversion/soma
http://sebastien.godard.pagesperso-orange.fr (sysstat)