[SOLVED] Requests for -current (20151216)

gmgf · 07-01-2017, 04:50 AM

I have the latest release of gcr and gnome-keyring, installed here since longtime, without problem here, but......

for Consolekit, it seem you have merged all patch who are present in the 1.0.2 version, i think this update is just cosmetic.

gmgf · 07-01-2017, 07:27 AM

It seem gegl-0.3* is just needed by gnome-photos actually, it is not a part of slackware.

gegl-0.2 and gegl-0.3 may cohabit like gtk+2 and 3, but gegl-0.3, is not needed in slackware at the moment.

gmgf · 07-01-2017, 08:03 AM

Fedora have many patch for gegl-0.2,

Among them, a CVE fix:
http://pkgs.fedoraproject.org/cgit/rpms/gegl.git/tree/

It seems that babl, can be updated, tested here, it seem that this update no affect gimp:

https://download.gimp.org/pub/babl/0...0.1.28.tar.bz2

DarkVision · 07-01-2017, 08:30 AM

Quote:

Originally Posted by gmgf

maybe it's better to add this new option in the SlackBuild: (--enable-auto-setup-driverless).

Note sure if i got this right for cups-filters, but in this post one of the debian package maintainers mentioned that you have to set this 'default' option manually in the cups-browsed.conf.

gmgf · 07-01-2017, 08:54 AM

Quote:

Originally Posted by DarkVision

Note sure if i got this right for cups-filters, but in this post one of the debian package maintainers mentioned that you have to set this 'default' option manually in the cups-browsed.conf.

Ok, no problem

davjohn · 07-01-2017, 11:02 AM

Could support for kernel rootflags parameter be added to mkinitrd, please ?

Code:

--- init.org    2017-05-08 01:45:53.000000000 +0200
+++ init        2017-07-01 15:40:59.606980534 +0200
@@ -129,6 +129,9 @@
     rootfs=*|rootfstype=*)
       ROOTFS=$(echo $ARG | cut -f2 -d=)
     ;;
+    rootflags=*)
+      ROOTFLAGS=$(echo $ARG | cut -f2- -d=)
+    ;;
     waitforroot=*|rootdelay=*)
       WAIT=$(echo $ARG | cut -f2 -d=)
     ;;
@@ -312,7 +315,7 @@
   # Switch to real root partition:
   /sbin/udevadm settle --timeout=10
   echo 0x0100 > /proc/sys/kernel/real-root-dev
-  mount -o ro -t $ROOTFS $ROOTDEV /mnt
+  mount -o ro${ROOTFLAGS:+,$ROOTFLAGS} -t $ROOTFS $ROOTDEV /mnt
   
   if [ ! -r /mnt/sbin/init ]; then
     echo "ERROR:  No /sbin/init found on rootdev (or not mounted).  Trouble ahead."

and also support for Btrfs in busybox:

Code:

--- busybox-dot-config.1.20.x.org       2016-06-08 21:48:15.000000000 +0200
+++ busybox-dot-config.1.20.x   2017-07-01 15:39:40.082984313 +0200
@@ -613,7 +613,7 @@
 # Filesystem/Volume identification
 #
 CONFIG_FEATURE_VOLUMEID_EXT=y
-# CONFIG_FEATURE_VOLUMEID_BTRFS is not set
+CONFIG_FEATURE_VOLUMEID_BTRFS=y
 CONFIG_FEATURE_VOLUMEID_REISERFS=y
 CONFIG_FEATURE_VOLUMEID_FAT=y
 CONFIG_FEATURE_VOLUMEID_HFS=y

rworkman · 07-01-2017, 09:57 PM

Quote:

Originally Posted by gmgf

I have the latest release of gcr and gnome-keyring, installed here since longtime, without problem here, but......

Aha - I found it:

Code:

 * 3.18.x removes the builtin GnuPG agent. Distributions
   should instead package and enable the agent gnupg 2.1.6+ or
   pinentry 0.9.5+ which interact well with GNOME, GNOME Shell
   and allow caching of passphrases via libsecret.

So we should be fine with upgrading those now since we now have gnupg2-2.1.x in the tree.

Quote:

for Consolekit, it seem you have merged all patch who are present in the 1.0.2 version, i think this update is just cosmetic.

We didn't merge my patch to check for adequate swap space before hibernate, because upower already does that, and we have to use upower for now. Once plasma5 goes in, we can update to newer upower, let CK2 handle suspend/hibernate, and at that point we'll *need* newer CK2. There's a lot of work going on upstream there to emulate the logind interfaces too...

Alien Bob · 07-02-2017, 02:37 AM

Quote:

Originally Posted by rworkman

There's a lot of work going on upstream there to emulate the logind interfaces too...

ConsoleKit2 has the complete logind d-bus API implemented already, and therefore KWin is going to add equal support to CK2 along with systemd-logind. The proposed patch provided by Eric Koegel (CK2 developer) is here: https://phabricator.kde.org/D6291

gmgf · 07-02-2017, 02:54 AM

OK, Robby, I was wrong version, it is the 1.0.1 version of consolekit2 that integrates most of the patches of your package

atelszewski · 07-02-2017, 07:12 AM

Hi,

Quote:

Originally Posted by rworkman

We didn't merge my patch to check for adequate swap space before hibernate, because upower already does that

Is the check really needed?

Some time ago (I'm on Slackware 14.2) I removed this check from upower with the following patch:

Code:

--- src/up-daemon.c.orig	2013-10-18 16:41:24.000000000 +0200
+++ src/up-daemon.c	2016-12-25 19:10:03.929000687 +0100
@@ -623,13 +623,9 @@
 
 	if (daemon->priv->kernel_can_hibernate) {
 		waterline = up_backend_get_used_swap (daemon->priv->backend);
-		if (waterline < UP_DAEMON_SWAP_WATERLINE) {
-			g_debug ("enough swap to for hibernate");
-			return TRUE;
-		} else {
-			g_debug ("not enough swap to hibernate");
-			return FALSE;
-		}
+		(void) waterline;
+
+		return TRUE;
 	}
 
 	return FALSE;

I then activate/deactivate the swap by means of pm-utils hook:

Code:

$ cat /etc/pm/sleep.d/01swap 
#!/bin/sh

if   [ "$1" = hibernate -o "$1" = suspend ]; then
  swapon -v $(blkid -t TYPE=swap -o device)
elif [ "$1" = thaw      -o "$1" = resume  ]; then
  swapoff -v -a
fi

My objective is to have the swap disabled during normal system operation and use it only for hibernation.

But my point here is actually something different.
The kernel itself checks if the swap is available and refuses to hibernate if it isn't.
So in my opinion the upower check is redundant.

I tested it:

Code:

$ echo -n disk > /sys/power/state
-su: echo: write error: No such device

Code:

$ dmesg
[..]
[17265.721232] PM: thaw of devices complete after 88.795 msecs
[17265.721430] PM: Cannot find swap device, try swapon -a.
[17265.721431] PM: Cannot get swap writer
[..]

--
Best regards,
Andrzej Telszewski

rworkman · 07-02-2017, 03:27 PM

The point of the check in upower/CK2 is this: rather than allow the option to hibernate, which then fails, don't show the option at all if it can't succeed.

atelszewski · 07-02-2017, 04:06 PM

Hi,

Quote:

Originally Posted by rworkman

The point of the check in upower/CK2 is this: rather than allow the option to hibernate, which then fails, don't show the option at all if it can't succeed.

Yes, that's correct.
(Although I have re-implemented xfce4-session-logout for my use case too ;-)).

--
Best regards,
Andrzej Telszewski

Didier Spaier · 07-03-2017, 12:16 AM

In the NEWS:

Code:

GNU grep NEWS                                    -*- outline -*-

* Noteworthy changes in release 3.1 (2017-07-02) [stable]

** Improvements

  grep '[0-9]' is now just as fast as grep '[[:digit:]]' when run
  in a multi-byte locale.  Before, it was several times slower.

** Changes in behavior

  Context no longer excludes selected lines omitted because of -m.
  For example, 'grep "^" -m1 -A1' now outputs the first two input
  lines, not just the first line.  This fixes a glitch that has been
  present since -m was added in grep 2.5.

  The following changes affect only MS-Windows platforms.  First, the
  --binary (-U) option now governs whether binary I/O is used, instead
  of a heuristic that was sometimes incorrect.  Second, the
  --unix-byte-offsets (-u) option now has no effect on MS-Windows too.

Reminder: -m and -A are GNU extensions.

Oh and I am not sure about the improvement, as in UTF-8 the digits 0-9 are coded with one byte anyway. Maybe for UCS-2 or UTF-16 or UTF-32? But the former is deprecated, and who uses the other ones?

Yes, Big5 encodes 0-8 with double byte encoding still widely in use. Honestly I didn't check how the digits 0-9 are encoded in the many other encodings used in East Asia.

Download links:
ftp://ftp.gnu.org/gnu/grep/grep-3.1.tar.xz
ftp://ftp.gnu.org/gnu/grep/grep-3.1.tar.xz.sig

audriusk · 07-03-2017, 02:01 AM

Quote:

Originally Posted by Didier Spaier

Code:

  grep '[0-9]' is now just as fast as grep '[[:digit:]]' when run
  in a multi-byte locale.  Before, it was several times slower.

Oh and I am not sure about the improvement, as in UTF-8 the digits 0-9 are coded with one byte anyway. Maybe for UCS-2 or UTF-16 or UTF-32? But the former is deprecated, and who uses the other ones?

I read it differently: if the locale being used is multi-byte (e.g. LANG=fr_FR.utf8), then [0-9] is as fast as [[:digit:]], regardless of text encoding.

Didier Spaier · 07-03-2017, 02:21 AM

Quote:

Originally Posted by audriusk

I read it differently: if the locale being used is multi-byte (e.g. LANG=fr_FR.utf8), then [0-9] is as fast as [[:digit:]], regardless of text encoding.

I am not sure that the word locale be properly used in the README. I see nothing in the POSIX specification that defines a multi-byte locale.

Does the quoted sentence means that e.g. with LANG set to fr_FR.utf8 instead of fr_FR writing [0-9] was slower than writing [[:digit:]] before this release? Maybe. I didn't check. What puzzles me is that the digits 0-9 are coded with one byte in both cases (which is true for the whole ASCII character set).