Bug#755434: pmount: please support exfat filesystem (via fuse)

[Vincent Danjean]

Le 04/05/2024 à 17:32, Jakub Wilk a écrit :

* Vincent Danjean , 2016-12-25 23:36:

++    { "exfat", "nosuid,nodev,user,quiet,nonempty", 1, "077", 
",iocharset=%s",",fmask=%04o,dmask=%04o"},


This doesn't work for me.
In dmesg I see:

     exfat: Unknown parameter 'quiet'



I forgot this bug for a long time since I'm using exfat SDcard/USBkey with 
pmount when it is required. But looking at my package:
$ apt-cache policy pmount
pmount:
  Installé : 0.9.99-alpha-1.2
  Candidat : 0.9.99-alpha-1.2
 Table de version :
 *** 0.9.99-alpha-1.2 100
100 /var/lib/dpkg/status
 0.9.23-7.1 500
500 http://deb.debian.org/debian testing/main amd64 Packages
500 http://deb.debian.org/debian unstable/main amd64 Packages

It is a local package. So I looked where I build my packages and found a git 
tree initially cloned from
git://git.debian.org/git/pmount/pmount-debian.git (of course, the site does not 
exist anymore).
I was using a new upstream version (0.9.99-alpha) whose packaging had been 
prepared by Vincent Fourmond
and I locally applied this patch on top of it:
$ git diff origin/master
diff --git a/debian/changelog b/debian/changelog
index 3e17503..4a5f7cb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+pmount (0.9.99-alpha-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * fix options for exfat (remove unsupported 'quiet' option)
+
+ -- Vincent Danjean   Sun, 18 Jul 2021 11:52:26 +0200
+
+pmount (0.9.99-alpha-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * support exfat filesystem (via fuse) (Closes: #755434)
+
+ -- Vincent Danjean   Sun, 25 Dec 2016 23:18:39 +0100
+
 pmount (0.9.99-alpha-1) experimental; urgency=low

   * New upstream experimental release, bringing in a lot of new features:
diff --git a/debian/patches/02-exfat-support.diff 
b/debian/patches/02-exfat-support.diff
new file mode 100644
index 000..d73af98
--- /dev/null
+++ b/debian/patches/02-exfat-support.diff
@@ -0,0 +1,11 @@
+Add support for exfat
+--- a/src/fs.c
 b/src/fs.c
+@@ -23,6 +23,7 @@
+ { "iso9660", "nosuid,nodev,user", 1, NULL, ",iocharset=%s" },
+ { "vfat", "nosuid,nodev,user,quiet,shortname=mixed", 1, "077",
+   ",iocharset=%s",",fmask=%04o,dmask=%04o"},
++{ "exfat", "nosuid,nodev,user", 1, "077", 
",iocharset=%s",",fmask=%04o,dmask=%04o"},
+ { "hfsplus", "nosuid,nodev,user", 1, NULL, 0 },
+ { "hfs", "nosuid,nodev,user", 1, "077", NULL,
+   ",file_umask=%04o,dir_umask=%04o"},
diff --git a/debian/patches/series b/debian/patches/series
index e706419..f1ac0f2 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 01-man-plugdev.diff
+02-exfat-support.diff

Looking at the dates, I see that origin/master was done by Vincent Fourmond on 
2011-03-25
I created a (local) package with the patch in this bug report on 2016-12-25
and I updated it on 2021-07-18 by removing the "quiet" and "nonempty" options.

  Regards,
Vincent

PS: it seems that 0.9.99-alpha never enters unstable. The changelog is saying:

diff --git a/ChangeLog b/ChangeLog
index 1dd34dd..8dcca5d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,22 @@
+0.9.99-alpha
+
+- EXPERIMENTAL RELEASE, use at your own risks !
+- introducing a new /etc/pmount.conf file in which potentially
+  security-weak operations can be allowed:
+  * running fsck
+  * mounting while not physically logged (that was the default)
+  * loopback device mounting
+- pulling in new Russian translation from Rosetta
+- now checking if root can open the device before attempting any
+  mount, to avoid very long hangs on "no medium found" and the like.
+- whitelisting the "firewire" bus as a hotplug bus.
+
+
+  As noticed above, this is an experimental release. Please use with
+  care: even if the parsing of configuration files should be safe, it
+  has not been extensively tried.
+
+
 0.9.23
 ---
 - fix a security hole (see CVE-2010-2192 for more

Bug#1068762: bookworm-pu: package oar/2.5.9-1+deb12u1

[Vincent Danjean]

  Hi,

  Do you need more information in order to allow us or not to proceed with a 
oar stable update?
Please, let us known.

  Best regards,
Vincent

Bug#1069849: publickey auth does not work when GSSAPI is also used

[Vincent Danjean]

Package: openssh-server
Version: 1:8.4p1-5+deb11u3
Severity: important
X-Debbugs-Cc: vdanj...@debian.org

  Hi,

  In an kerberos environment, I'm gradually migrating machines from
bullseye to bookworm. Doing this, I observe a regression concerning
openssh-server.

  Openssh is configurated to allow kerberos authentification.
sshd_config has the following lines:
GSSAPIAuthentication yes
GSSAPIKeyExchange yes
GSSAPIStoreCredentialsOnRekey yes
and ssh_config has the following lines:
Host *
GSSAPIDelegateCredentials yes
GSSAPIKeyExchange yes
GSSAPITrustDNS yes

  When trying to log from a kerberos account into a remote local
(non kerberos) account with a public key, it works on bulleyes machines,
but on bookworm machines, I got the following error:
$ ssh -v -l remote-local-login bookworm-machine
[...]
OpenSSH_9.2p1 Debian-2+deb12u2, OpenSSL 3.0.11 19 Sep 2023
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/local.conf
debug1: /etc/ssh/ssh_config.d/local.conf line 6: Applying options for *
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to bookworm-machine.domain.fr [10.0.0.3] port 22.
debug1: Connection established.
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_rsa type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_rsa-cert type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ecdsa type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ecdsa_sk-cert type 
-1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ed25519 type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ed25519_sk type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_ed25519_sk-cert 
type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_xmss type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_xmss-cert type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_dsa type -1
debug1: identity file /home/domain.fr/kerberos-user/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.2p1 
Debian-2+deb12u2
debug1: compat_banner: match: OpenSSH_9.2p1 Debian-2+deb12u2 pat OpenSSH* 
compat 0x0400
debug1: Authenticating to bookworm-machine.domain.fr:22 as 'remote-local-login'
debug1: load_hostkeys: fopen /home/domain.fr/kerberos-user/.ssh/known_hosts2: 
No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or 
directory
debug1: Offering GSSAPI proposal: 
gss-group14-sha256-toWM5Slw5Ew8Mqkay+al2g==,gss-group16-sha512-toWM5Slw5Ew8Mqkay+al2g==,gss-nistp256-sha256-toWM5Slw5Ew8Mqkay+al2g==,gss-curve25519-sha256-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha256-eipGX3TCiQSrx573bT1o1Q==,gss-group16-sha512-eipGX3TCiQSrx573bT1o1Q==,gss-nistp256-sha256-eipGX3TCiQSrx573bT1o1Q==,gss-curve25519-sha256-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: gss-group14-sha256-toWM5Slw5Ew8Mqkay+al2g==
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: Calling gss_init_sec_context
debug1: Delegating credentials
debug1: Received GSSAPI_COMPLETE
debug1: Calling gss_init_sec_context
debug1: Delegating credentials
debug1: Rekey has happened - updating saved versions
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: get_agent_identities: agent returned 1 keys
debug1: Will attempt key: kerberos-u...@domain.fr@di3937su RSA 
SHA256:LVQ9Rw8lBcFd5DPN0NXfU8Heo2+7sBrEhzkTdNgcDVA agent
debug1: Will attempt key: /home/domain.fr/kerberos-user/.ssh/id_rsa
debug1: Will attempt key: /home/domain.fr/kerberos-user/.ssh/id_ecdsa
debug1: Will attempt key: /home/domain.fr/kerberos-user/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/domain.fr/kerberos-user/.ssh/id_ed25519
debug1: Will attempt key: /home/domain.fr/kerberos-user/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/domain.fr/kerberos-user/.ssh/id_xmss
debug1: Will attempt key: 

Bug#1068762: bookworm-pu: package oar/2.5.9-1+deb12u1

[Vincent Danjean]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: o...@packages.debian.org, pierre.ney...@free.fr
Control: affects -1 + src:oar
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
The oar package is suffering several issues in bookworm.
The root cause is that we forgot to update it in time with the release 
schedule, so the version in bookworm is the one in bullseye.

The testing version is a new upstream version (that fixes the following 
problems and also has other improvments)

We would like you to allow us to fix the following problems in stable:
- one of the package is a php program that does not work with php8 (bug 
#1068444)
- adduser >= 3.130 (ie the one in bookworm) changes the way adduser's 
--disabled-(login|password) options work.
  So, a fix when creating users is required (note: this bug appears only on 
fresh oar install, not on upgrade) (bug #1068713)
- a binary package (oar-web-status) is missing a dependency on libcgi-fast-perl 
(bug #1068711)

Note that #1068444 and #1068713 are fixed in testing for a long time (since the 
upload of 2.5.10-1)
#1068711 has just been noticed, with a upload in unstable a few minutes ago (in 
2.5.10-2)

[ Impact ]
Without this upload:
- the draw-gantt webapp does not work at all in bookworm (php8 incompatibility)
- new installation of oar system cannot submit jobs (until the password field 
in /etc/shadow is manually fixed)
- libcgi-fast-perl must be manually installed if oar-web-status is to be used
  (this last bug is often hidden: if oar-restful-api is also installed, then 
the libcgi-fast-perl is installed)

[ Tests ]
Manual tests has been conducted upstream (and fixes have been in upstream 
2.5.10 for a long time)

[ Risks ]
Modifications seems trivial and, except for the dependencies, used on 
production systems for several months.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
See previous explainations and debdiff.

  Regards
Vincent
diff -Nru oar-2.5.9/debian/changelog oar-2.5.9/debian/changelog
--- oar-2.5.9/debian/changelog  2021-01-11 16:44:43.0 +0100
+++ oar-2.5.9/debian/changelog  2024-04-10 14:02:42.0 +0200
@@ -1,3 +1,16 @@
+oar (2.5.9-1+deb12u1) bookworm; urgency=medium
+
+  [ Pierre Neyron ]
+  * Fix Drawgantt-SVG with php8 (Closes: #1068444)
+- create_function does not exists anymore
+- static methods must be declared as such
+  * Fix the oar user creation on new install (locked otherwise) (Closes:
+#1068713)
+  * oar-web-status: add missing dependency to libcgi-fast-perl (Closes:
+#1068711)
+
+ -- Vincent Danjean   Wed, 10 Apr 2024 14:02:42 +0200
+
 oar (2.5.9-1) unstable; urgency=medium
 
   * New release
diff -Nru oar-2.5.9/debian/patches/drawgantt-svg_fixes_for_php_8.patch 
oar-2.5.9/debian/patches/drawgantt-svg_fixes_for_php_8.patch
--- oar-2.5.9/debian/patches/drawgantt-svg_fixes_for_php_8.patch
1970-01-01 01:00:00.0 +0100
+++ oar-2.5.9/debian/patches/drawgantt-svg_fixes_for_php_8.patch
2024-04-10 14:02:42.0 +0200
@@ -0,0 +1,45 @@
+[drawgantt-svg] Fixes for PHP 8
+
+Backported from upstream 2.5.10
+
+Fix fatal errors occuring with PHP8:
+- The create_function function is REMOVED as of PHP 8.0.0. 
(https://www.php.net/manual/en/function.create-function.php)
+- Non-static methods Shuffle::Init() and Shuffle::get_int() cannot be called 
statically. Need to make them static.
+
+From: Pierre Neyron 
+
+diff --git 
a/sources/visualization_interfaces/DrawGantt-SVG/drawgantt-svg.php.in 
b/sources/visualization_interfaces/DrawGantt-SVG/drawgantt-svg.php.in
+index 5fd3b636..e24d3faa 100644
+--- a/sources/visualization_interfaces/DrawGantt-SVG/drawgantt-svg.php.in
 b/sources/visualization_interfaces/DrawGantt-SVG/drawgantt-svg.php.in
+@@ -269,10 +269,10 @@ function date2px($date) {
+ // class to compute colors for jobs
+ class Shuffle {
+ protected static $singleton;
+-function init($shuffle_instance) {
++static function init($shuffle_instance) {
+ self::$singleton = $shuffle_instance;
+ }
+-function get_int($job) {
++static function get_int($job) {
+ if (self::$singleton === null) {
+ self::init(new Shuffle());
+ }
+@@ -603,7 +603,7 @@ class Resource {
+   if ($this->type == $CONF['resource_group_level']) {
+ $first_resource_base = true;
+   }
+-  usort($this->children, create_function('$a,$b','return $b->cmp($a);'));
++  usort($this->children, function($a,$b) { return $b->cmp($a); });
+   foreach ($this->children as $child) {
+ $h += $child->svg_hierarchy($x+$CONF['hierarchy_resource_width'], 
$y+$h, $labels);
+   }
+@@ -650,7 +650,7 @@ class Resource {
+   }
+ }
+ foreach ($states as $value => $date_we

Bug#1061130: sssd-common: not using alternatives for idmap-plugin

[Vincent Danjean]

Package: sssd-common
Version: 2.8.2-4
Severity: normal

  Hi,

  sssd-common provides /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so
that needs to be manually symlinked from /etc/cifs-utils/idmap-plugin
if we want to use it.
  However, cifs-utils provides /usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so
that it installs as /etc/cifs-utils/idmap-plugin with the
Debian alternative system:
# update-alternatives --list idmap-plugin
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so
# update-alternatives --display idmap-plugin
idmap-plugin - auto mode
  link best version is /usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so
  link currently points to /usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so
  link idmap-plugin is /etc/cifs-utils/idmap-plugin
  slave idmap-plugin.8.gz is /usr/share/man/man8/idmap-plugin.8.gz
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - priority 40
  slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz


  As sssd-common does not use the alternative system,
each times cifs-utils is upgraded (security, ...),
the /etc/cifs-utils/idmap-plugin is recreated to
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so
(via /etc/alternatives/idmap-plugin).

  So sssd-common should also use the alternative system,
probably with a priority below 40 (so that cifs-utils
version would still be the defaut as currently),
but allowing an admin sys to permanently change this.

  Regards,
Vincent


-- System Information:
Debian Release: trixie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel

Kernel: Linux 6.6.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sssd-common depends on:
ii  adduser  3.137
ii  libc-ares2   1.25.0-1
ii  libc62.37-13
ii  libdbus-1-3  1.14.10-4
ii  libdhash10.6.2-2+b1
ii  libglib2.0-0 2.78.3-1
ii  libgssapi-krb5-2 1.20.1-5
ii  libini-config5   0.6.2-2+b1
ii  libkeyutils1 1.6.3-2+b2
ii  libkrb5-31.20.1-5
pn  libldap-2.4-2
ii  libldap-2.5-02.5.13+dfsg-5+b2
ii  libldb2  2:2.8.0+samba4.19.4+dfsg-2
ii  libnfsidmap1 [libnfsidmap2]  1:2.6.4-3
ii  libnl-3-200  3.7.0-0.2+b1
ii  libnl-route-3-2003.7.0-0.2+b1
pn  libnss-sss   
ii  libp11-kit0  0.25.3-4
pn  libpam-sss   
ii  libpam0g 1.5.2-9.1+b1
ii  libpcre2-8-0 10.42-4
ii  libpcre3 2:8.39-15
ii  libpopt0 1.19+dfsg-1
ii  libref-array10.6.2-2+b1
ii  libselinux1  3.5-1+b2
pn  libsemanage1 
ii  libsemanage2 3.5-1+b2
ii  libssl1.11.1.1w-0+deb11u1
ii  libssl3  3.1.4-2
pn  libsss-certmap0  
pn  libsss-idmap0
pn  libsss-nss-idmap0
ii  libsystemd0  255.2-4
ii  libtalloc2   2.4.1-2
ii  libtdb1  1.4.9-2
ii  libtevent0   0.15.0-1
pn  libunistring2
ii  libunistring51.1-2
ii  python3  3.11.6-1
pn  python3-sss  

Versions of packages sssd-common recommends:
ii  bind9-dnsutils  1:9.19.19-1
ii  bind9-host  1:9.19.19-1
pn  libnss-sss  
pn  libpam-sss  

Versions of packages sssd-common suggests:
ii  apparmor 3.0.12-1+b2
pn  libsss-sudo  
pn  sssd-tools   

Bug#1058925: sudo: typo in NEWS.Debian

[Vincent Danjean]

Package: sudo
Version: 1.9.14p2-1
Severity: minor
Tags: patch

  Hi,

  The NEWS.Debian file talks about "sssd, ssdh-ldap and libsss-sudo"
packages instead of "sssd, sssd-ldap and libsss-sudo" I think.

  Regards,
Vincent

-- System Information:
Debian Release: trixie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel

Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sudo depends on:
ii  init-system-helpers  1.66
ii  libaudit11:3.1.1-1+b1
ii  libc62.37-13
ii  libpam-modules   1.5.2-9.1
ii  libpam0g 1.5.2-9.1
ii  libselinux1  3.5-1+b1
ii  zlib1g   1:1.3.dfsg-3

sudo recommends no packages.

sudo suggests no packages.

-- Configuration Files:
/etc/sudoers [Errno 13] Permission non accordée: '/etc/sudoers'
/etc/sudoers.d/README [Errno 13] Permission non accordée: 
'/etc/sudoers.d/README'

-- no debconf information

Bug#913431: Debian Installer Bullseye RC 2 release

[Vincent Danjean]

  Hi,

Le 24/04/2023 à 21:49, Emanuele Rocca a écrit :

   Let me know if this is ok for you. As d-i is already in RC, if
you prefer, I can revert the longint2human part that modifies
some information, and only keep the human2longint that adds
some new input that were forbidden before (no change for what
was already accepted). The longint2human part can be added after
the release if you think it is too intrusive (or if it must be
adapted)


I think splitting the patch as you suggest is a good idea. The longint2human
part is quite a large change, let's do that after Bookworm.


Ok. So, now, MR 6 only have the human2longint part.
The longint2human is in MR 7 (only the last commit must be picked up,
the others are the ones in MR 6)

  Regards,
Vincent

Bug#913431: Debian Installer Bullseye RC 2 release

[Vincent Danjean]

  Hi Philip,

  I made a push request[1] but I missed the fact that it fails.
It was due to the tests being run with sh(dash) instead of bash or
busybox sh.
  So, I just fixed the code so that it works with any of these 3 shells
and I update the testsuite. Now, all the tests pass on salsa.

  Let me know if this is ok for you. As d-i is already in RC, if
you prefer, I can revert the longint2human part that modifies
some information, and only keep the human2longint that adds
some new input that were forbidden before (no change for what
was already accepted). The longint2human part can be added after
the release if you think it is too intrusive (or if it must be
adapted)

  Regards
Vincent

[1] https://salsa.debian.org/installer-team/partman-base/-/merge_requests/6



Le 27/03/2023 à 02:07, Philip Hands a écrit :

Hi Vincent,

I've applied your patch and pushed it to to salsa (my fork) to get it
built by CI ... which failed, because of the use of ${X/...} and
${X:...}, which it seems busybox doesn't like.

So I've changed that code, and added a couple of other tweaks, as you
can see here:

   https://salsa.debian.org/philh/partman-base/-/commits/bug/913431

Perhaps you can look at the result, and check that it still does what
you intended, and pick anything you like out of the rest.

>

BTW the working pipeline build includes the creation of a mini-ISO image
(once one kicks branch2repo into action), that should allow this code to
be tested in D-I:

   
https://salsa.debian.org/installer-team/debian-installer/-/jobs/4087808/artifacts/file/public/gtk-mini.iso

HTH

Cheers, Phil.

Bug#913431: Debian Installer Bullseye RC 2 release

[Vincent Danjean]

  Hi Philip,

Le 27/03/2023 à 02:07, Philip Hands a écrit :

Hi Vincent,

I've applied your patch and pushed it to to salsa (my fork) to get it
built by CI ... which failed, because of the use of ${X/...} and
${X:...}, which it seems busybox doesn't like.

So I've changed that code, and added a couple of other tweaks, as you
can see here:

   https://salsa.debian.org/philh/partman-base/-/commits/bug/913431

Perhaps you can look at the result, and check that it still does what
you intended, and pick anything you like out of the rest.


  There were a problem: "expr substr" requires the 'length' argument
(it is optional for the ${s:..} construct)
  So, I restarted from my previous work (as said in the bug report just
before your message, I already saw that ${X:...} and ${X/...} do not
work), switch from "cut -c ..." to "expr substr ..." [with all arguments]
and applied some of your tweaks.
  The resulting state can be seen here:
https://salsa.debian.org/vdanjean/partman-base/-/tree/bug/913431-tested


BTW the working pipeline build includes the creation of a mini-ISO image
(once one kicks branch2repo into action), that should allow this code to
be tested in D-I:

   
https://salsa.debian.org/installer-team/debian-installer/-/jobs/4087808/artifacts/file/public/gtk-mini.iso


  I made my tests as suggested by Emanuele Rocca, i.e. by overwriting
the modified file (base.sh) during the installation before running the
partition step.
  I confirm I successfully created partition and LVM LV with power-of-two
units.

  I noticed that "human2longint" is ready to handle numbers with spaces in it
(such as 30 000 kB), but "valid_human" does not accept them (no spaces but
before the unit). I not sure if this is intended or not.

  Thanks you very much for your feedback
Vincent



HTH

Cheers, Phil.

Bug#913431: Debian Installer Bullseye RC 2 release

[Vincent Danjean]

Le 26/03/2023 à 18:38, Emanuele Rocca a écrit :

Hi Vincent,

On 2023-03-24 11:03, Vincent Danjean wrote:

However, I did not rebuild all the installer packages to generate a
new installer and test it in real conditions.


I haven't had the time to test your patch yet, but there's a hack I'd
like to share to test things in d-i without rebuilding anything.


Thank you very much for the tip. I see later that you can also
just go to the second console and type the "wget ..." instruction
here (before (re)starting the partitioning).
  This allows me to fix my patch: ${str:start:end} is not available
in the installer context, nor is ${str// /} to remove space.
I used 'cut' and 'tr' to do the job.

  With this updated patch, I successfully created plain (GPT)
partition in MiB and GiB (plain and fractional) and also
LVM LV in GiB (plain and fractional) with the Debian Installer
Bookworm Alpha 2 release (amd64 and i386 netinst CD images)
  The only 'bug' (but it should be present before) is that
the first partition for whose I asked a size of 128MiB gets
a size of 127MiB, probably due to the fact that the start
of the partition has been aligned to the first MiB (ie 1024kiB)

  Moreover, the tests I provide now also pass within the
installer (run the 'tests' script with the "di" argument to
avoid the script to try to run 'bc'). Both outputs (in d-i and
in a 'normal' machine) have the same md5sum (on amd64 and i386)

  So, I think I've done all what I can.

  Regards,
Vincent


diff --git a/lib/base.sh b/lib/base.sh
index d38e101e..08cfec55 100644
--- a/lib/base.sh
+++ b/lib/base.sh
@@ -313,9 +313,125 @@ longint2human () {
 	printf "%i%s%i %s\n" $int $deci $frac $suffix
 }
 
+substr() {
+	local s="$1"
+	local start="$2" # first is 0
+	local size="$3"
+
+	if [ -n "$3" ]; then
+		echo "$s" | cut -c $(($start + 1))-$(($start + $size))
+	else
+		echo "$s" | cut -c $(($start + 1))-
+	fi
+}
+
+longmult() {
+	local a="$1" # no size limit
+	local b="$2" # <= 2^30
+
+	local carry=0
+	local endres=""
+	local partres
+	local enda
+
+	while [ "${#a}" -gt 6 ]; do
+		enda="$(substr "$a" $((${#a} - 6)))"
+		a="${a%$enda}"
+		partres="$(expr "$enda" '*' "$b" + "$carry")"
+		if [ "${#partres}" -gt 6 ]; then
+			carry="$(substr "$partres" 0 $((${#partres} - 6)))"
+			endres="${partres#$carry}$endres"
+		else
+			partres="00$partres"
+			carry=0
+			endres="$(substr "$partres" $((${#partres} - 6)))$endres"
+		fi
+	done
+	partres="$(expr "$a" '*' "$b" + "$carry")"
+	echo "$partres$endres"
+}
+
+longadd() {
+	local a="$1" # no size limit
+	local b="$2" # <= 2^60
+
+	local carry="$b"
+	local endres=""
+	local partres
+	local enda
+
+	while [ "${#a}" -gt 15 ]; do
+		enda="$(substr "$a" $((${#a} - 15)))"
+		a="${a%$enda}"
+		partres="$(expr "$enda" + "$carry")"
+		if [ "${#partres}" -gt 15 ]; then
+			carry="$(substr "$partres" 0 $((${#partres} - 15)))"
+			endres="${partres#$carry}$endres"
+		else
+			partres="000$partres"
+			echo "${a}$(substr "$partres" $((${#partres} - 15)))$endres"
+			return
+		fi
+	done
+	partres="$(expr "$a" + "$carry")"
+	echo "$partres$endres"
+}
+
+human2longint_binary_unit() {
+	local int="$1"
+	local frac="$2"
+	local powbase="$3" # 1 <= powbase <= 6
+	# must return "$int.$frac * 1024^$powbase"
+	# contraints :
+	# - no floating point operation
+	# - no computed values above 2^63-1
+	# - expr has no exponentiation
+	# - bash arithmetics consider that 0-leading numbers are octal
+
+	# max of useful decimals when converting: powbase*10
+	# next ones, when multipled by 1024^powbase, would be <1
+	# so no need to take into account to many decimals
+	frac="$(substr "$frac" 0 $((powbase * 10 )))"
+	local longint="${int}${frac}"
+	longint="$(substr "$longint" $(expr "$longint" : '0*' || true))" # remove leading 0
+	[ "$longint" ] || {
+		echo 0
+		return
+	}
+	while [ "$powbase" -gt 3 ]; do
+		longint="$(longmult "$longint" "$((1024**3))")"
+		powbase=$(( $powbase - 3 ))
+	done
+	longint="$(longmult "$longint" "$((1024**$powbase))")"
+
+	if [ -z "$frac" ]; then
+		# no fractional part, just return the result
+		echo "$longint"
+		return
+	fi
+	# non-null fractional part.
+	# longint must be divided by 10^length(frac)
+	local posfrac="$(( 

Bug#913431: Debian Installer Bullseye RC 2 release

[Vincent Danjean]

Le 23/03/2023 à 12:01, Vincent Danjean a écrit :

Le 23/03/2023 à 11:41, Vincent Danjean a écrit :

   Hi,

Le 23/03/2023 à 10:06, Emanuele Rocca a écrit :

There is (now) a function in partman-base called valid_human [1] which
checks if the partition size specified by the user is valid. Probably
when you first wrote the patch this wasn't the case.

That function needs to be modified as well to accept GiB and friends.


  Here is a new patch. There are several improvments:
- when using power-of-ten units, all decimals are taken into account
  (not just the 4 first ones)
- human2longint was concatenating the 5 first arguments. Now it
  concatenates all its arguments (not sure about this part, this is
  a two-lines modification that can easily be reverted
- bigger decimal number are handled (in fact, there are no size limits)
- power-of-two units are accepted and handled
- Peta and Exa units are added

  This patch is using both 'expr' (from busybox) and bash arithmetic
that both are limited to 2^64 (signed) integers (even on 32-bits
platforms, I checked on i386). Both were already used previously.

  To be relatively sure of my code, I wrote a series of test.
It is in the tar.gz file. Just unpack it and run 'make' in it.
For each check, it compares:
- the new implementation and a (local) implementation based on
  'bc' that uses no-size-limit integer operations
  It prints 'OK' if both are the same and else NACK
  (in practice, there are no NACKs)
- if previously OK, it compares to the old implementation.
  - 'OK:' means that both (old and new) implementation returns the
same thing
  - 'OK+': means that they differ.
If there is no 'previously' at the end of the line,
  it means that the old implementation was not handling this case
  (all power-of-two units and the new Peta and Exa prefix)
else
  it means that the old implementation was returning another value
  (seen just after the "previouly: " text)
  Here, you find better precision (more decimals taken into account)
  or wrong results (negative by overflow, etc.)
All these tests are run within the busybox shell and with the busybox
tools added in front of the PATH.

However, I did not rebuild all the installer packages to generate a
new installer and test it in real conditions.

  I hope the patch can be reviewed and applied for the next release.

  Regards
Vincent

diff --git a/lib/base.sh b/lib/base.sh
index d38e101e..492732bf 100644
--- a/lib/base.sh
+++ b/lib/base.sh
@@ -313,9 +313,115 @@ longint2human () {
 	printf "%i%s%i %s\n" $int $deci $frac $suffix
 }
 
+longmult() {
+	local a="$1" # no size limit
+	local b="$2" # <= 2^30
+
+	local carry=0
+	local endres=""
+	local partres
+	local enda
+
+	while [ "${#a}" -gt 6 ]; do
+		enda="${a:$((${#a} - 6))}"
+		a="${a%$enda}"
+		partres="$(expr "$enda" '*' "$b" + "$carry")"
+		if [ "${#partres}" -gt 6 ]; then
+			carry="${partres:0:$((${#partres} - 6))}"
+			endres="${partres#$carry}$endres"
+		else
+			partres="00$partres"
+			carry=0
+			endres="${partres:$((${#partres} - 6))}$endres"
+		fi
+	done
+	partres="$(expr "$a" '*' "$b" + "$carry")"
+	echo "$partres$endres"
+}
+
+longadd() {
+	local a="$1" # no size limit
+	local b="$2" # <= 2^60
+
+	local carry="$b"
+	local endres=""
+	local partres
+	local enda
+
+	while [ "${#a}" -gt 15 ]; do
+		enda="${a:$((${#a} - 15))}"
+		a="${a%$enda}"
+		partres="$(expr "$enda" + "$carry")"
+		if [ "${#partres}" -gt 15 ]; then
+			carry="${partres:0:$((${#partres} - 15))}"
+			endres="${partres#$carry}$endres"
+		else
+			partres="000$partres"
+			echo "${a}${partres:$((${#partres} - 15))}$endres"
+			return
+		fi
+	done 
+	partres="$(expr "$a" + "$carry")"
+	echo "$partres$endres"
+}
+
+human2longint_binary_unit() {
+	local int="$1"
+	local frac="$2"
+	local powbase="$3" # 1 <= powbase <= 6
+	# must return "$int.$frac * 1024^$powbase"
+	# contraints :
+	# - no floating point operation
+	# - no computed values above 2^63-1
+	# - expr has no exponentiation
+	# - bash arithmetics consider that 0-leading numbers are octal
+
+	# max of useful decimals when converting: powbase*10
+	# next ones, when multipled by 1024^powbase, would be <1
+	# so no need to take into account to many decimals
+	frac="${frac:0:$((powbase * 10 ))}"
+	local longint="${int}${frac}"
+	longint="${longint:$(expr "$longint" : '0*' || true)}" # remove leading 0
+	[ "$longint" ] || {
+		echo 0
+		return
+	}
+	while [ "$powbase"

Bug#913431: Debian Installer Bullseye RC 2 release

[Vincent Danjean]

Le 23/03/2023 à 11:41, Vincent Danjean a écrit :

   Hi,

Le 23/03/2023 à 10:06, Emanuele Rocca a écrit :

Hi Vincent,

On 2021-06-20 10:54, Vincent Danjean wrote:

Would someone give a feedback to the (old) patch proposed
in #913431 in order to be able to also use power-of-two units
in the Debian Installer?


It took a while, sorry about that. :)

There is (now) a function in partman-base called valid_human [1] which
checks if the partition size specified by the user is valid. Probably
when you first wrote the patch this wasn't the case.

That function needs to be modified as well to accept GiB and friends.


   This would be very easy (just add a 'i?' when it can be added).
Before rewriting the patch, I would like to be sure there is no
big flaw. In particular, to handle power-of-two units, I'm using
the 'expr' command, as bash arithmetic uses only limited integers
whereas expr uses gmp:
$ echo $((40 * 10 * 10 * 1000 + 1))
7458848197692096513
$ expr 40 '*' 10 '*' 10 '*' 1000 + 1
401

Can you confirm me that using 'expr' in the installer context is ok?


After a quick check with the 11.5.0 installer (I already have it
in a VM), expr is available in the installer, but it is not using
gmp. So, in the installer context:
$ expr 40 '*' 10 '*' 10 '*' 1000 + 1
7458848197692096513

So it means that, in the installer context, with bash or expr, there would
be a limit of about a few Exa bytes when using power-of-two units
(nothing would change for decimal units)
The limit would be exactly 9223372036854775807 bytes, that is about
9,22 EB or 7,99 EiB.

Would this be a acceptable limit or not ? I'm not sure as I already
manage storages with a few PiB nowadays.

  Regards
Vincent



   Regards
     Vincent


[1] 
https://salsa.debian.org/installer-team/partman-base/-/blob/master/lib/base.sh#L373

Bug#913431: Debian Installer Bullseye RC 2 release

[Vincent Danjean]

  Hi,

Le 23/03/2023 à 10:06, Emanuele Rocca a écrit :

Hi Vincent,

On 2021-06-20 10:54, Vincent Danjean wrote:

Would someone give a feedback to the (old) patch proposed
in #913431 in order to be able to also use power-of-two units
in the Debian Installer?


It took a while, sorry about that. :)

There is (now) a function in partman-base called valid_human [1] which
checks if the partition size specified by the user is valid. Probably
when you first wrote the patch this wasn't the case.

That function needs to be modified as well to accept GiB and friends.


  This would be very easy (just add a 'i?' when it can be added).
Before rewriting the patch, I would like to be sure there is no
big flaw. In particular, to handle power-of-two units, I'm using
the 'expr' command, as bash arithmetic uses only limited integers
whereas expr uses gmp:
$ echo $((40 * 10 * 10 * 1000 + 1))
7458848197692096513
$ expr 40 '*' 10 '*' 10 '*' 1000 + 1
401

Can you confirm me that using 'expr' in the installer context is ok?

  Regards
Vincent


[1] 
https://salsa.debian.org/installer-team/partman-base/-/blob/master/lib/base.sh#L373

Bug#1033343: ITP: libstoragedisplay-perl -- Collect and display storages on Linux machines

[Vincent Danjean]

Package: wnpp
Severity: wishlist
Owner: Vincent Danjean 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libstoragedisplay-perl
  Version : 1.2.3
  Upstream Contact: Vincent Danjean 
* URL : https://metacpan.org/release/StorageDisplay
* License : Artistic or GPL-1+ (Perl)
  Programming Lang: Perl
  Description : Collect and display storages on Linux machines

 This program can be used to collect data about storage state on
 local and remote machine, and then to generate a DOT file
 the is a graphical representation of the storage state.
 .
 Data collecting requires only perl (and its basic modules) and a
 shell account with sudo rights.
 .
 DOT file generation requires more perl modules (the recommended
 ones), but this can be done on another machine.

Bug#1025701: ovmf: does not recognise virtio-scsi controller

[Vincent Danjean]

Le 06/03/2023 à 16:01, Vincent Danjean a écrit :

   So, an upgrade path seems possible, but it is not easy to find.
If you have a bullseye VM booting with OVMF_CODE.fd on a SCSI disk,
you have to:
1) change OVMF_CODE.fd into OVMF_CODE_4M.secboot.fd (or to another variant) in 
the XML
2) remove (rename?) the _VARS.fd file
3) manually boot the VM from the UEFI shell
4) re-install grub ("grub-install efi")


  As a side note, only the VirtIO SCSI controler is supported by
OVMF_CODE_4M.*, not lsilogic (that is the default for the
hypervisor with virt-manager/libvirt).
  But this is probably #1016359

  Regards,
Vincent

Bug#1025701: ovmf: does not recognise virtio-scsi controller

[Vincent Danjean]

  Hi,

  I come back to this bug.

Le 07/12/2022 à 22:26, dann frazier a écrit :

Thanks for opening this new issue! As I mentioned in #1016359, I had
no problems booting a VM w/ virtio-scsi in sid, so this seems like it
may be config-specific. Can you provide me with a way to reproduce
this - e.g. your libvirt XML?


  I think I found additionnal informations. It seems the bug is not
really in the ovmf software, but in the upgrade path.

  I retried today to upgrade ovmf to 2022.11-6. Then, my VM becomes
unable to boot and the SCSI Disk does not appear anymore (only the
SATA CDROM (empty) is visible) in the UEFI Boot Manager.
  See ovmf-2022-11-6.png
  I tried both with the Virtio SCSI contrôler and the lsilogic one.
In both cases, the disk is not visible at all in the UEFI shell
or UEFI Boot Manager.

  Downgrading ovmf to 2020.11-2+deb11u1 fixes these problems.
The disk is then visible in the UEFI Boot Manager (see
ovmf-2020.11-2+deb11u1.png)


  As you said that you succeeded to boot, I then tried to create
a new VM (using the same file for the HD, so taking care to never
boot both VM at the same time) with the new ovmf package.
  It works! More exactly, the HD is visible in the UEFI Boot Manager
and the UEFI shell (as FS0). From the latter, typing:
FS0:
cd efi
cd debian
shimx64.efi
allows me to boot my system.

  So, I come back to my first (old) VM and try to spot the
differences. It comes to the fact that the old VM is using
/usr/share/OVMF/OVMF_CODE.fd
and the new is using
/usr/share/OVMF/OVMF_CODE_4M.secboot.fd
[probably other OVMF_CODE_4M.* should also work, not tested]
And when creating new VM, virt-manager only proposes
OVMF_CODE_4M.*, not OVMF_CODE.* (whereas still present in the ovmf package)

  In my old VM in virt-manager, I used the XML editor to change
"OVMF_CODE.fd" into "OVMF_CODE_4M.secboot.fd"
  At this time, the VM does not boot anymore at all (no UEFI Bios
screen, only a message saying that the video is not initialized yet).
I went to /var/lib/libvirt/qemu/nvram and removed (renamed)
the nvram VARS file.
  This time, it works, the (old) VM boot and the UEFI Shell
shows my SCSI disk (and the nvram VARS file has been recreated, bigger).
  I booted manually from the UEFI shell, then I ran
"grub-install efi", and, at next boot, my VM started
correctly.

$ sudo ls -l /var/lib/libvirt/qemu/nvram/
-rw--- 1 libvirt-qemu libvirt-qemu 540672  6 mars  15:26 debian11_VARS.fd
-rw--- 1 libvirt-qemu libvirt-qemu 131072 20 sept.  2020 
visio_VARS-2023-03-06.fd
-rw--- 1 libvirt-qemu libvirt-qemu 540672  6 mars  15:29 visio_VARS.fd

The first is the new VM (that I will destroy)
The next one is a rename of VARS file of the old VM
The last one is the one created when booting the old VM with the new ovmf 4M 
(four times bigger)

  So, an upgrade path seems possible, but it is not easy to find.
If you have a bullseye VM booting with OVMF_CODE.fd on a SCSI disk,
you have to:
1) change OVMF_CODE.fd into OVMF_CODE_4M.secboot.fd (or to another variant) in 
the XML
2) remove (rename?) the _VARS.fd file
3) manually boot the VM from the UEFI shell
4) re-install grub ("grub-install efi")

  I do not know if something can be done for this path to be
easier, but, at the very least, it should be documented.
Perhaps, it may also be possible to get an error message
- if the VM boot on a SCSI disk with OVMF_CODE.*
- if the OVMF_CODE_4M.* code finds a *_VARS.fd related to OVMF_CODE.*

  Regards,
Vincent

Bug#1031802: libvirt-daemon-driver-lxc: Incorrect dependencies

[Vincent Danjean]

Package: libvirt-daemon-driver-lxc
Version: 9.0.0-1
Severity: important

After doing a partial upgrade of my system (i.e. only libvirt-daemon
with its required dependencies), libvirtd refused to start.
In systemd journal, I can see:

févr. 23 00:53:32 eyak libvirtd[3010536]: internal error: Failed to load module 
'/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_lxc.so': 
/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_lxc.so: 
undefined symbol: fuse_new_31, version FUSE_3.1

Upgrading libfuse3-3 from 3.12.0-1 to 3.14.0-2 fixed the problem.
libvirt-daemon-driver-lxc should bump its dependency on libfuse3-3.
For now, there is:
Depends: [...] libfuse3-3 (>= 3.2.3) [...]

If this dependency is automaticcaly generated, then it probably
means there is a bug in the libfuse3-3 package (its shlibs file)

  Regards
Vincent


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libvirt-daemon-driver-lxc depends on:
ii  libblkid1   2.38.1-4
ii  libc6   2.36-6
ii  libcap-ng0  0.8.3-1+b2
ii  libfuse3-3  3.14.0-2
ii  libgcc-s1   12.2.0-10
ii  libglib2.0-02.74.2-1
ii  libtirpc3   1.3.3+ds-1
ii  libvirt-daemon  9.0.0-1
ii  libvirt09.0.0-1

libvirt-daemon-driver-lxc recommends no packages.

libvirt-daemon-driver-lxc suggests no packages.

-- no debconf information

Bug#1029990: ath: phy1: DMA failed to stop in 10 ms

[Vincent Danjean]

Package: src:linux
Version: 6.0.12-1~bpo11+1
Severity: normal

I've spurious problems with my atheros PCIE card.
It is used with hostapd to provide wifi AP.
Sometime, the client do not succeed to connect to internet.
In the log, I can observe the following lines. It seems that
most (all?) of the time, they are preceeded by:

[...]
Jan 29 17:08:33 aya kernel: [573587.069575] ath: phy1: DMA failed to stop in 10 
ms AR_CR=0x0024 AR_DIAG_SW=0x0220 DMADBG_7=0x6040
Jan 29 17:08:33 aya kernel: [573587.470696] ath: phy1: DMA failed to stop in 10 
ms AR_CR=0x0024 AR_DIAG_SW=0x0220 DMADBG_7=0x6040
Jan 29 17:21:29 aya kernel: [574363.908459] DMAR: DRHD: handling fault status 
reg 2
Jan 29 17:21:29 aya kernel: [574363.908465] DMAR: [DMA Read NO_PASID] Request 
device [72:00.0] fault addr 0xfe721000 [fault reason 0x06] PTE Read access is 
not set
Jan 29 17:21:30 aya kernel: [574364.294048] ath: phy1: DMA failed to stop in 10 
ms AR_CR=0x0024 AR_DIAG_SW=0x0220 DMADBG_7=0x62c0
Jan 29 17:21:30 aya kernel: [574364.681674] ath: phy1: DMA failed to stop in 10 
ms AR_CR=0x0024 AR_DIAG_SW=0x0220 DMADBG_7=0x6040
Jan 29 17:21:31 aya kernel: [574365.099751] ath: phy1: DMA failed to stop in 10 
ms AR_CR=0x0024 AR_DIAG_SW=0x0220 DMADBG_7=0x6040
[...]
=> see how a bunch of "ath: phy1: DMA failed to stop in 10 ms" are
just following two "DMAR: ..." lines (and this pattern is recurent).

  I was using this PCIE card without any problems for several years.
The errors occured when I changed my tower for a more recent processor
and motherboard. The disk (software and system config) have been
kept.
  I suspect interraction between the atheros driver and the iommu
(DMAR), the latter was not available on my previous processor.

  Do you have some ideas about which kernel options I can try ?
Note that iommu is not used on this machine for now, but I plan
to use it now that the processor support it (several kvm virtual
machines are running, I would like to manage some hardware
directly in some VM)

  Regards,
Vincent

PS: the BIOS is up-to-date (with already two upgrades for one month)

-- Package-specific info:
** Version:
Linux version 6.0.0-0.deb11.6-amd64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP PREEMPT_DYNAMIC Debian 6.0.12-1~bpo11+1 (2022-12-19)

** Command line:
BOOT_IMAGE=/vmlinuz-6.0.0-0.deb11.6-amd64 root=/dev/mapper/aya+raid1-root ro 
apparmor=0 md-degraded=no quiet security=

** Not tainted

** Kernel log:
[574483.465710] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x6040
[574483.875469] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x6040
[574484.285468] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x6040
[574484.694685] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x8040
[574485.104566] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x8040
[574485.522817] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x6040
[574485.923393] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x6040
[574486.333154] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x6040
[574486.742990] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x8040
[574487.161219] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x8040
[574487.562174] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x8040
[574487.971704] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x8040
[574488.381286] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x6040
[574488.790844] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x6040
[574489.200428] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x6040
[574489.618794] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x6040
[574490.019559] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x8040
[574490.429334] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x8040
[574490.840061] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x6040
[574491.257437] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x6040
[574491.657950] ath: phy1: DMA failed to stop in 10 ms AR_CR=0x0024 
AR_DIAG_SW=0x0220 DMADBG_7=0x6040

Bug#1029222: lvm2: pvmove keeps opened filehandles on unused PV

[Vincent Danjean]

Package: lvm2
Version: 2.03.11-2.1
Severity: wishlist

  Hi,

  On a machine, I've two VG (aya+raid1 and aya+raid6).
While a pvmove was in progress in aya+raid6, I tried
to remove an unused PV in aya+raid1.
vgreduce worked correctly
pvremove also worked correctly
but, as the PV was a RAID1 mdadm volume, I did not
succeed into stopping it due to pvmove having an
open file descriptor on it:

# vgreduce aya+raid1 /dev/md/aya-raid1-B
  Removed "/dev/md123" from volume group "aya+raid1"
# pvremove /dev/md/aya-raid1-B
  Labels on physical volume "/dev/md/aya-raid1-B" successfully wiped.
# mdadm -S /dev/md/aya-raid1-B
mdadm: failed to stop array /dev/md/aya-raid1-B: Device or resource busy
   Perhaps a running process, mounted filesystem or active volume group?
# lsof /dev/md/aya-raid1-B
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/2001/gvfs
  Output information may be incomplete.
lsof: WARNING: can't stat() fuse.portal file system /run/user/2001/doc
  Output information may be incomplete.
COMMANDPID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pvmove  688244 root   64r   BLK  9,123  0t0  573 /dev/md/../md123

  Looking at fd of pvmove, we can see:
# ls -l /proc/688244/fd
total 0
lrwx-- 1 root root 64 Jan 19 20:19 0 -> /dev/pts/25
lrwx-- 1 root root 64 Jan 19 20:19 1 -> /dev/pts/25
lrwx-- 1 root root 64 Jan 19 20:19 2 -> /dev/pts/25
lrwx-- 1 root root 64 Jan 19 20:19 3 -> 'socket:[15831408]'
lr-x-- 1 root root 64 Jan 19 22:42 42 -> /dev/sde1
lrwx-- 1 root root 64 Jan 19 22:42 5 -> /dev/md119
lr-x-- 1 root root 64 Jan 19 22:42 59 -> /dev/md118
lr-x-- 1 root root 64 Jan 19 22:42 62 -> /dev/md121
lr-x-- 1 root root 64 Jan 19 22:42 63 -> /dev/md122
lr-x-- 1 root root 64 Jan 19 22:42 64 -> /dev/md123
lr-x-- 1 root root 64 Jan 19 22:42 65 -> /dev/md124
lr-x-- 1 root root 64 Jan 19 22:42 66 -> /dev/md125
lrwx-- 1 root root 64 Jan 19 22:42 7 -> /dev/md120
lrwx-- 1 root root 64 Jan 19 22:42 8 -> /dev/md126
lrwx-- 1 root root 64 Jan 19 22:42 9 -> /dev/md127

Starting from the fifth (sde1 and the following ones),
they are all the PV present this system.

The four opened 'rw' (i.e. md119, md120, md126 and md127)
are the one in the VG where the pvmove is running (even
if only md127 and md120 are concerned by the pvmove)

All the others are PV from the other VG (not concerned by
the running pvmove). They are opened 'ro' only. But this
prevent to do some things with them : if it is a disk
partition, it cannot be removed (the kernel tells us it
cannot reload the new partition table). If it is a RAID
block as here, the mdadm RAID cannot be stopped.

It seems to me that there is no reason to keep an
opened file descriptor on PV of other VG when running
the pvmove. And it would be even better if only involved
PV in the involved VG would be locked (but there is
perhaps reason to do so here).

Note: the workaround is easy: just wait the end of the pvmove.

  Regards
Vincent

-- System Information:
Debian Release: 11.6
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'oldstable-updates'), (500, 'oldstable'), (200, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.175-2.1
ii  dmsetup   2:1.02.175-2.1
ii  init-system-helpers   1.60
ii  libaio1   0.3.112-9
ii  libblkid1 2.36.1-8+deb11u1
ii  libc6 2.31-13+deb11u5
ii  libdevmapper-event1.02.1  2:1.02.175-2.1
ii  libedit2  3.1-20191231-2+b1
ii  libselinux1   3.1-3
ii  libsystemd0   247.3-7+deb11u1
ii  libudev1  247.3-7+deb11u1
ii  lsb-base  11.1.0

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.9.0-1

lvm2 suggests no packages.

Bug#1025701: ovmf: does not recognise virtio-scsi controller

[Vincent Danjean]

  Hi,

Le 07/12/2022 à 22:26, dann frazier a écrit :

On Wed, Dec 7, 2022 at 10:36 AM Vincent Danjean  wrote:

   ovmf in sid does not allow one to boot over a virtio-scsi contrôleur.
My disques are not seen anymore (not even in the EFI menus).
Downgrading to 2020.11-2+deb11u1 fixes the issue.


Thanks for opening this new issue! As I mentioned in #1016359, I had
no problems booting a VM w/ virtio-scsi in sid, so this seems like it
may be config-specific. Can you provide me with a way to reproduce
this - e.g. your libvirt XML?


Here is.

  Regards,
Vincent



  visio
  d76aaa5d-3ffd-45c7-9803-3c1edcf57dc4
  
http://libosinfo.org/xmlns/libvirt/domain/1.0;>
  http://debian.org/debian/10"/>

  
  4194304
  4194304
  2
  
hvm
/usr/share/OVMF/OVMF_CODE.fd
/var/lib/libvirt/qemu/nvram/visio_VARS.fd

  
  



  
  
  



  
  destroy
  restart
  destroy
  


  
  
/usr/bin/qemu-system-x86_64

  
  
  
  


  
  
  
  
  


  


  



  
  
  


  
  
  


  
  


  
  
  


  
  
  


  
  
  


  
  
  


  
  
  


  
  
  


  


  


  
  
  


  
  
  
  


  

  


  


  
  


  
  


  




  
  


  



  
  


  


  


  


  


  


  /dev/urandom
  

  

Bug#1016359: more info

[Vincent Danjean]

  Hi,

Le 07/12/2022 à 17:13, Thorsten Glaser a écrit :

OK. I’ll leave the lead for that to Vincent, but feel free to
keep me in Cc on that one; I probably can dig a little deeper
in the failing build with a bit more time.


I filled a new bug: #1025701

  Regards
Vincent

Bug#1025701: ovmf: does not recognise virtio-scsi controller

[Vincent Danjean]

Package: ovmf
Version: 2022.11-1
Severity: normal

  Hi,

  I was thinking my bug was #1016359, but with the additionnal
info, it is a different one. So, I'm opening this bug as asked.

  ovmf in sid does not allow one to boot over a virtio-scsi contrôleur.
My disques are not seen anymore (not even in the EFI menus).
Downgrading to 2020.11-2+deb11u1 fixes the issue.

  Regards,
Vincent

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#1016359: ovmf: does not recognise SCSI controllers

[Vincent Danjean]

  Hi,

  I can confirm that virtio-scsi does not work anymore
(and that this is indeed really annoying).

  A simple workaround: just downgrade ovmf to the bullseye version

  Regards
Vincent

Bug#1023609: [Pkg-samba-maint] Bug#1023609: smbclient does not work with kerberos ccache of KEYRING: type

[Vincent Danjean]

Le 08/11/2022 à 10:51, Michael Tokarev a écrit :

07.11.2022 23:54, Vincent Danjean wrote:
..

As I'm only using the client part (the AD is managed by Microsoft
products in my case), do you have some advises about how to modify
debian/rules,control to (locally) build the samba package with MIT?


Are you really so serious about using the in-kernel ccache?


I did not find another way to make cifs automount with kerberos working.
Using FILE: ccache does not work because credential are required for
the initial mount (done be autofs), and not only for the latter accesses
(that are done in the user context with its kerberos ticket as I'm
using the multiuser,sec=krb5).
  For the initial mount by autofs, I'm using cruid=${UID} to do it
on behalf of the initiating user with its kerberos credentials.
But with FILE: ccache, the exact filename is not known.

  Another workaround would be to have a fixed (by user) FILE:filename
but I did not test if that would work with multiple parallel sessions
of the same user on the same machine (and some long, non-interactive
sessions started with k5start)

  So, for cifs automount, I need
1) that the cifs mount with the cruid=${UID} be able to find the
   kerberos ticket of the user with the ${UID} uid.
   I'm currently using KEYRING: for that
2) that the smbclient be able to list the available shares with
   the credentials of the user with the ${UID} uid
   ("smbclient -gL server")
   => I'm trying to solve that by trying to recompiling smbclient
   with MIT in order to also use the KEYRING: ccache

Changing the AD or the CIFS server (allowing the machine to do the
"smbclient -gL server" without auth or with the host keytab) is not
really an option. The people in charge of the AD won't want to change
such things in the AD for the small group doing HPC on linux in the
big structure using mainly windows (it is already very difficult to
just get some groups we need...)


I suppose there will be :
- a few build dependencies to change (quickly looking, I see nothing
   about heimdal?)
- a few configure options to tweek
   I should be able to find the options to add such as
   --with-system-mitkrb5
   (and --with-experimental-mit-ad-dc just to pass the compilation?)
   but what should be disabled?
   Or which binary packages should I disable/remove ?

   I would be very pleased if you can give me a few hints.


I'd have to take a look at this.  So far I've no idea how large
this project would be and what'll be needed.

Actually, I had a thought like this for quite some time, to try
the MIT kerberos samba build.  Myself, I don't know much about the
two kerberos implementations and less so about their usage in
samba. What I do know is that redhat/fedora uses mit-kerberos builds
of samba for quite some time, their build instructions removes whole
thord_party/heimdal directory as the very first step to ensure this
stuff is never used by samba build.  So it might be interesting to
take a look there.

For now I have other stuff to do but this is definitely in my todo list.

An additional data point: with samba, you have to rely on your own
basically, since for many things, there's no one to assist you.


  Thank you for your feedback. Perhaps, the first thing I will do
will be to get the fedora smbclient binary (with its libraries)
just to check that my use case would be successful.
  In any case, I will report here the progress I do if any.

  Regards,
Vincent

Bug#1023609: smbclient does not work with kerberos ccache of KEYRING: type

[Vincent Danjean]

Le 07/11/2022 à 18:58, Andrew Bartlett a écrit :

On Mon, 2022-11-07 at 16:45 +0100, Vincent Danjean wrote:

- smbclient does not handle ccache using the kernel keyring
   Perhaps this is due to samba using heimdal kerberos implementation?


That is all this is.  An MIT build would work, but that isn't a supported way 
to build the AD DC at this time.


As I'm only using the client part (the AD is managed by Microsoft
products in my case), do you have some advises about how to modify
debian/rules,control to (locally) build the samba package with MIT?

I suppose there will be :
- a few build dependencies to change (quickly looking, I see nothing
  about heimdal?)
- a few configure options to tweek
  I should be able to find the options to add such as
  --with-system-mitkrb5
  (and --with-experimental-mit-ad-dc just to pass the compilation?)
  but what should be disabled?
  Or which binary packages should I disable/remove ?

  I would be very pleased if you can give me a few hints.

  Regards
Vincent


Andrew Bartlett

Bug#1023609: smbclient does not work with kerberos ccache of KEYRING: type

[Vincent Danjean]

Package: smbclient
Version: 2:4.16.6+dfsg-5~bpo11+1
Severity: normal

  Hi,

  I'm trying to use smbclient with kerberos login, for example to
get the list of shares with somthing like:

smbclient -N --use-kerberos=required -gL samba-server.example.org

If using the FILE: ccache, it works.
If using a KEYRING: ccache, it does not work.

And the --use-krb5-ccache option does not seems to be taken into account

$ export KRB5CCNAME=FILE:/tmp/ccache_file
$ rm $KRB5CCNAME 
rm: cannot remove 'FILE:/tmp/ccache_file': No such file or directory
$ kinit
Password for XXX@XXX:
$ smbclient -N --use-kerberos=required --use-krb5-ccache=FILE:/tmp/ccache_file 
-gL samba-server.example.org
[... list of shares ...]
$ smbclient -N --use-kerberos=required -gL samba-server.example.org
[... list of shares ...]
$ smbclient -N --use-kerberos=required --use-krb5-ccache=FILE:/non-existant -gL 
samba-server.example.org
[... list of shares ...] <- probably a fail-back to KRB5CCNAME
$ export KRB5CCNAME=FILE:/non-existant
$ smbclient -N --use-kerberos=required -gL samba-server.example.org
gensec_spnego_client_negTokenInit_step: Could not find a suitable mechtype in 
NEG_TOKEN_INIT
session setup failed: NT_STATUS_INVALID_PARAMETER
$ smbclient -N --use-kerberos=required --use-krb5-ccache=FILE:/tmp/ccache_file 
-gL samba-server.example.org
gensec_spnego_client_negTokenInit_step: Could not find a suitable mechtype in 
NEG_TOKEN_INIT
session setup failed: NT_STATUS_INVALID_PARAMETER
$ smbclient -N --use-kerberos=required --use-krb5-ccache=/tmp/ccache_file -gL 
samba-server.example.org
gensec_spnego_client_negTokenInit_step: Could not find a suitable mechtype in 
NEG_TOKEN_INIT
session setup failed: NT_STATUS_INVALID_PARAMETER
$ export KRB5CCNAME=KEYRING:persistent:`id -u`:krb_ccache
$ kinit
Password for XXX@XXX:
$ smbclient -N --use-kerberos=required -gL samba-server.example.org
gensec_spnego_client_negTokenInit_step: Could not find a suitable mechtype in 
NEG_TOKEN_INIT
session setup failed: NT_STATUS_INVALID_PARAMETER
$ smbclient -N --use-kerberos=required --use-krb5-ccache=$KRB5CCNAME -gL 
samba-server.example.org
gensec_spnego_client_negTokenInit_step: Could not find a suitable mechtype in 
NEG_TOKEN_INIT
session setup failed: NT_STATUS_INVALID_PARAMETER


klist and other kerberos-enabled tools (such as ssh) work correctly
when KRB5CCNAME is set to FILE:... but also to KEYRING:...

So, from my experiments, it seems:
- the --use-krb5-ccache is never used (at least when KRB5CCNAME is set)
  [it was not the goal of this bug report, but I see it when trying my commands]
- smbclient does not handle ccache using the kernel keyring
  Perhaps this is due to samba using heimdal kerberos implementation?

  Regards,
Vincent


-- System Information:
Debian Release: 11.5
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-0.bpo.3-amd64 (SMP w/6 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages smbclient depends on:
ii  libarchive13  3.4.3-2+deb11u1
ii  libbsd0   0.11.3-1
ii  libc6 2.31-13+deb11u4
ii  libgnutls30   3.7.1-5+deb11u2
ii  libpopt0  1.18-2
ii  libreadline8  8.1-1
ii  libsmbclient  2:4.16.6+dfsg-5~bpo11+1
ii  libtalloc22.3.3-4~bpo11+1
ii  libtevent00.11.0-1~bpo11+1
ii  samba-common  2:4.16.6+dfsg-5~bpo11+1
ii  samba-libs2:4.16.6+dfsg-5~bpo11+1

smbclient recommends no packages.

Versions of packages smbclient suggests:
ii  cifs-utils   2:7.0-2~bpo11+1
pn  heimdal-clients  

-- no debconf information

Bug#950518: gssproxy: segfault when debug is enabled

[Vincent Danjean]

  Hi,

Le 22/09/2022 à 09:47, Simon Josefsson a écrit :

Hi.

I can't reproduce this with 0.8.2-2 nor recent 0.9.1-1, can you show me
your other /etc/gssproxy/*.conf?  I suspect they are triggering
something.  See my attempt to reproduce your problem below.


  I do not try with 0.9.1-1 (that I would need to backport).
But I'm using 0.8.2-2 from stable and the problem is still here:

root@ge132116vm-1:/etc/gssproxy# tail -v -n +1 /etc/gssproxy/*.conf
==> /etc/gssproxy/24-nfs-server.conf <==
[service/nfs-server]
  mechs = krb5
  socket = /run/gssproxy.sock
  cred_store = keytab:/etc/krb5.keytab
  trusted = yes
  kernel_nfsd = yes
  euid = 0

==> /etc/gssproxy/99-nfs-client.conf <==
[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
  #cred_store = ccache:FILE:/tmp/krb5cc_%U
  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0

==> /etc/gssproxy/gssproxy.conf <==
[gssproxy]
debug=true
debug_level=2
root@ge132116vm-1:/etc/gssproxy# /etc/init.d/gssproxy restart
Restarting gssproxy (via systemctl): gssproxy.service.
root@ge132116vm-1:/etc/gssproxy# systemctl status gssproxy
● gssproxy.service - GSSAPI Proxy Daemon
 Loaded: loaded (/lib/systemd/system/gssproxy.service; enabled; vendor 
preset: enabled)
Drop-In: /etc/systemd/system/gssproxy.service.d
 └─restart.conf
 Active: activating (auto-restart) (Result: protocol) since Thu 2022-09-22 
16:09:54 CEST; 3s ago
Process: 3360781 ExecStart=/usr/sbin/gssproxy -D (code=exited, 
status=0/SUCCESS)
CPU: 29ms
root@ge132116vm-1:/etc/gssproxy# tail /var/log/syslog
Sep 22 16:10:04 ge132116vm-1 systemd[1]: Failed to start GSSAPI Proxy Daemon.
Sep 22 16:10:09 ge132116vm-1 systemd[1]: gssproxy.service: Scheduled restart 
job, restart counter is at 4.
Sep 22 16:10:09 ge132116vm-1 systemd[1]: Stopped GSSAPI Proxy Daemon.
Sep 22 16:10:09 ge132116vm-1 systemd[1]: Starting GSSAPI Proxy Daemon...
Sep 22 16:10:09 ge132116vm-1 gssproxy[3360833]: [2022/09/22 14:10:09]: Debug 
Enabled (level: 2)
Sep 22 16:10:09 ge132116vm-1 systemd[1]: gssproxy.service: New main PID 3360834 
does not exist or is a zombie.
Sep 22 16:10:09 ge132116vm-1 gssproxy[3360834]: [2022/09/22 14:10:09]: Client 
[2022/09/22 14:10:09]: (/usr/sbin/gssproxy) [2022/09/22 14:10:09]:  connected 
(fd = 10)[2022/09/22 14:10:09]:  (pid = 3360834) (uid = 0) (gid = 0)
Sep 22 16:10:09 ge132116vm-1 kernel: [3550475.471227] gssproxy[3360834]: 
segfault at 0 ip 7fe129f9d53a sp 7fff41a19460 error 4 in 
libselinux.so.1[7fe129f97000+19000]
Sep 22 16:10:09 ge132116vm-1 kernel: [3550475.471274] Code: bf 01 00 00 00 31 ed e9 
2e ff ff ff 4c 89 ff e8 6c 9b ff ff eb a2 66 2e 0f 1f 84 00 00 00 00 00 41 55 41 54 
55 53 48 83 ec 08 <48> 8b 2f 48 8b 7d 00 48 85 ff 74 05 e8 45 9b ff ff 48 c7 45 
00 00
Sep 22 16:10:21 ge132116vm-1 icinga2[4156100]: [2022-09-22 16:10:21 +0200] 
information/RemoteCheckQueue: items: 0, rate: 0/s (12/min 60/5min 180/15min);
root@ge132116vm-1:/etc/gssproxy# systemctl cat gssproxy
# /lib/systemd/system/gssproxy.service
[Unit]
Description=GSSAPI Proxy Daemon
# GSSPROXY will not be started until syslog is
After=syslog.target
Before=nfs-secure.service nfs-secure-server.service

[Service]
Environment=KRB5RCACHEDIR=/var/lib/gssproxy/rcache
ExecStart=/usr/sbin/gssproxy -D
# These two should be used with traditional UNIX forking daemons
# consult systemd.service(5) for more details
Type=forking
PIDFile=/var/run/gssproxy.pid
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/gssproxy.service.d/restart.conf
[Service]
RemainAfterExit=no
GuessMainPID=yes
Restart=on-failure
RestartSec=5s


  Removing the debug* line from /etc/gssproxy/gssproxy.conf allows
gssproxy to start.

Note: the machine is an NFS client, but not an NFS server.
And commenting out the NFS server conf file fix the problem:

root@ge132116vm-1:/etc/gssproxy# tail -v -n +1 /etc/gssproxy/*.conf
==> /etc/gssproxy/24-nfs-server.conf <==
#[service/nfs-server]
#  mechs = krb5
#  socket = /run/gssproxy.sock
#  cred_store = keytab:/etc/krb5.keytab
#  trusted = yes
#  kernel_nfsd = yes
#  euid = 0

==> /etc/gssproxy/99-nfs-client.conf <==
[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
  #cred_store = ccache:FILE:/tmp/krb5cc_%U
  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0

==> /etc/gssproxy/gssproxy.conf <==
[gssproxy]
debug=true
debug_level=2
root@ge132116vm-1:/etc/gssproxy# /etc/init.d/gssproxy restart
Restarting gssproxy (via systemctl): gssproxy.service.
root@ge132116vm-1:/etc/gssproxy# systemctl status gssproxy
● gssproxy.service - GSSAPI Proxy Daemon
 Loaded: loaded (/lib/systemd/system/gssproxy.service; enabled; vendor 

Bug#959190: gssproxy: Log flooded by gssproxy

[Vincent Danjean]

Le 22/09/2022 à 11:21, Simon Josefsson a écrit :

Hi

I'm trying to understand this bug report -- my reading is that there is
excessive debug messages in the log, but they go away if you disable
debug logging.  Is that right?  I think that is expected, and also that
debug logging is disabled by default.  Am I missing something here?


Yes: I'm using the default setup when I get these messages.
I do *not* explicitely enable debug.

I'm assuming that, under default log level, only errors to be fixed
are reported. Or, even if there are some 'notice' messages, they are
reasonable and they do not fill /var/log.

I'm afraid that, by disabling explicitely all logs, I will then miss
real errors that won't be reported anymore by gssproxy.

If I've time, I will patch and recompile gssproxy in order to know
which accounts/users are generating these logs.

  Regards
Vincent


/Simon

Bug#1020312: usrmerge: systemd file disappearing

[Vincent Danjean]

Le 20/09/2022 à 11:41, Luca Boccassi a écrit :

Most of the issues would crop up when actually attempting to move
things,


Interrupting a running upgrade is always problematic. Lots of
packages are then in broken state (half installed). Apt has
difficulties to recover from such a situation. Sometimes, it
needs additional packages requiring a working network
(but network-manager can be broken at this point...)


so a dry-run would be a lot of work and provide little benefits
I think.


The goal of the dry-run would be to be run *before* the
upgrade start (with the debconf framework) so that the
admin can fix any conflict situation described by your
matrix when they still have a working system.

The other "solution" is to do an upgrade in two-stage
1) install usrmerge
2) do the real upgrade
So, a kind of do-release-upgrade (as Ubuntu has)


To be thorough you'd have to replicate the filesystem
somewhere else and try it there first, but that requires a huge amount
of disk space and a lot of time too,


I do not understand this argument. While would we need
to replicate the FS? I'm just thinking to explore the
FS (/lib, ...) and check there is no conflicts as listed
in your matrix.


so it doesn't seem worth it, given
in 5+ years on multiple distros this is the first case we've seen.

I think what we should add is debsums -c before/after, and fail if
something is not right, so that there's an immediate and clear error
plus recovery step presented. I've sent a patch to Marco for this.


debsums is very long to be run on a big system or on a system
with old (magnetic) disks. Running it twice would lead
to a very long installation time of usrmerge.


But I'm glad we figured out what went wrong, as it was a very puzzling
case. With my systemd maintainer hat on: you shouldn't move these files
away to /etc. Units shipped in /usr|/lib are fixed vendor-provided
files, and must not be modified. Local modifications should instead
happen on /etc or /run. I strongly advise to fix that on your system.
(of course we still need usrmerger to support the generic case, that
goes without saying)


You do not understand my goal. I never modified files in
/etc/conffiles-out-etc/ These are the unmodified file shipped
in /lib/systemd/system.
My goal in putting them here is that they are tracked by
etckeeper, so that I can easily see their modifications during
an upgrade. It happens a few times that this help me to
quickly revert a change I do not want for my system for the
default settings. In this cases, the fix goes to
/etc/systemd/system/ as it should. Being able to look at
the history of these default configuration files is really a
good point for me (hence this change done on several of
my machines)

  Regards,
Vincent

Bug#1020312: usrmerge: systemd file disappearing

[Vincent Danjean]

  Hi,

Le 20/09/2022 à 04:22, Marco d'Itri a écrit :

Indeed, this should be handled. Let's have a look at the code:

[...]

In your case the expected outcome should have been a failure instead,
because /lib/systemd/system/ was a link which did not point to
/usr/lib/systemd/system/ :

 fatal("Both $n and /usr$n exist");


  So yes, I should have been informed before rebooting. My
upgrade should have been interrupted.

  However, I'm not really pleased with the fact that a key package
of the upgrade can fail on unusual but valid cases. When it appends
in a dist-upgrade, the resulting state is often a mess to recover
from (less than the one I suffered, but still really annoying).

  What about:
1) adding a --dry-mode to /usr/lib/usrmerge/convert-usrmerge
   that report about conflicts but do not change anything on
   the FS
2) embedding and using convert-usrmerge in dry-mode from the
   debconf script.
   Put a low warning notice if the script fail due to missing
   dependencies (perl, perl modules, ...)
   Put a high warning notice if the script detect a conflict

This would allows one to stop the conversion in case of strange
layout in the FS before the upgrade start.

  Regards,
Vincent

Bug#1020312: usrmerge: systemd file disappearing

[Vincent Danjean]

Le 20/09/2022 à 01:39, Luca Boccassi a écrit :

Thanks for the logs, it looks like it's only file under
/lib/systemd/system/ that went missing - can you find them anywhere
else on the system?


Now that you point out this, it recalls me that years ago,
I moved /lib/systemd/system/ to /etc/conffiles-out-etc/lib/systemd/system
(so that the systemd configuration files are correctly tracked by etckeeper)
and I put a /lib/systemd/system -> /etc/conffiles-out-etc/lib/systemd/system
symlink.

So, I'm downgrading the severity. But as it is allowed
to create symlinks to other part of the disk for directory,
usrmerge should handle this case (or, at least, give a
preeminent message about a strange situation)



vdanjean@eyak:~$ diff -r /etc/conffiles-out-etc/lib/systemd/system/ 
/lib/systemd/system/
Only in /etc/conffiles-out-etc/lib/systemd/system/: cgroupfs-mount.service
Only in /lib/systemd/system/: drkonqi-coredump-processor@.service
Only in /etc/conffiles-out-etc/lib/systemd/system/: 
gitlab-ci-multi-runner.service
Only in /etc/conffiles-out-etc/lib/systemd/system/: osspd.service
Only in /lib/systemd/system/: pam_namespace.service
Only in /lib/systemd/system/: pcscd.service
Only in /lib/systemd/system/: pcscd.socket
Only in /etc/conffiles-out-etc/lib/systemd/system/: 
pulseaudio-enable-autospawn.service
Only in /etc/conffiles-out-etc/lib/systemd/system/: screen-cleanup.service
diff -r /etc/conffiles-out-etc/lib/systemd/system/speech-dispatcherd.service 
/lib/systemd/system/speech-dispatcherd.service
1c1
< # Copyright (C) 2018 Samuel Thibault 
---
> # Copyright (C) 2018, 2022 Samuel Thibault 
23c23
< ExecStart=/usr/bin/speech-dispatcher -d --pid-file 
/run/speech-dispatcher/speech-dispatcher.pid
---
> ExecStart=/usr/bin/speech-dispatcher -d -t 0 --pid-file 
/run/speech-dispatcher/speech-dispatcher.pid
Only in /etc/conffiles-out-etc/lib/systemd/system/: sudo.service
vdanjean@eyak:~$ ls /etc/conffiles-out-etc/lib/systemd/system/ | wc -l
468
vdanjean@eyak:~$ ls /lib/systemd/system/ | wc -l
466
vdanjean@eyak:~$

I try to explain the difference:

Files previously in /usr/lib/...
Only in /lib/systemd/system/: drkonqi-coredump-processor@.service
Only in /lib/systemd/system/: pam_namespace.service
Only in /lib/systemd/system/: pcscd.service
Only in /lib/systemd/system/: pcscd.socket

Package not reinstalled
Only in /etc/conffiles-out-etc/lib/systemd/system/: 
gitlab-ci-multi-runner.service

Removed packages
Only in /etc/conffiles-out-etc/lib/systemd/system/: osspd.service
Only in /etc/conffiles-out-etc/lib/systemd/system/: 
pulseaudio-enable-autospawn.service

Files not removed on package upgrade?
Only in /etc/conffiles-out-etc/lib/systemd/system/: cgroupfs-mount.service
Only in /etc/conffiles-out-etc/lib/systemd/system/: screen-cleanup.service




Directories are merged recursively if they exist in both hierarchies,
so I guess you had something that installs files in
/usr/lib/systemd/system/ and something went horribly wrong somewhere.
We don't delete files, so I'm thinking they might have been moved to
the wrong place.

We can add debsums -c before/after the conversion, so that if this
happens again there's a clear message immediately. But this is very
strange, I've never seen this reported in Debian or Ubuntu in ~5 years.


  If I understand, the bug occurs when a directory exists
in both / and /usr and the directory in / is in fact a
symlink to another directory elsewhere. Not a classical
situation indeed, but it can exists...

  Regards,
Vincent

Bug#1020312: usrmerge: systemd file disappearing

[Vincent Danjean]

Le 20/09/2022 à 01:11, Vincent Danjean a écrit :

   Hi,

Le 19/09/2022 à 23:49, Luca Boccassi a écrit :

Are you sure the problem was not there beforehand?


Yes. Due to the numerous missing files, I'm sure the problem
comes from the apt upgrade. The FS is in a good state (no
corruption) with nearly 9GB free (so no out-of-space problem).
  My system was perfectly booting and working before.

  Note that usrmerge has really run: I see this package that
would be newly installed before starting the upgrade (and
I read its bug page and the links to the TC decisions because
initially I did not want to merge my /usr).
  So, I run 'ls /' in a terminal before and after the upgrade
and I saw the changes. Now:
vdanjean@eyak:~$ ls -l / | grep -- '->'
lrwxrwxrwx   1 root root  7 19 sept. 21:34 bin -> usr/bin
lrwxrwxrwx   1 root root 30 12 sept. 18:44 initrd.img -> 
boot/initrd.img-5.19.0-1-amd64
lrwxrwxrwx   1 root root 30 12 sept. 18:44 initrd.img.old -> 
boot/initrd.img-5.18.0-4-amd64
lrwxrwxrwx   1 root root  7 19 sept. 21:34 lib -> usr/lib
lrwxrwxrwx   1 root root  9 19 sept. 21:34 lib32 -> usr/lib32
lrwxrwxrwx   1 root root  9 19 sept. 21:34 lib64 -> usr/lib64
lrwxrwxrwx   1 root root 10 19 sept. 21:34 libx32 -> usr/libx32
lrwxrwxrwx   1 root root  8 19 sept. 21:34 sbin -> usr/sbin
lrwxrwxrwx   1 root root 27 12 sept. 18:44 vmlinuz -> 
boot/vmlinuz-5.19.0-1-amd64
lrwxrwxrwx   1 root root 27 12 sept. 18:44 vmlinuz.old -> 
boot/vmlinuz-5.18.0-4-amd64
vdanjean@eyak:~$


   I will re-run debsums (it seems that the "|&" polute the output
a litle bit, I want to be sure I reinstalled all required packages)


Missing files are sent to stderr by debsums, hence the mess
in my initial log.
After a rerun of debsums, I will have to reinstall
gitlab-ci-multi-runner but I need to manually download it
(it is not a package from Debian). All the others seem now
correct.

  Regards
Vincent



   I also put in attachement the dpkg log file (I do not see anything
special when I've done the initial "apt upgrade")
First is my "apt upgrade"
At 21:56, there is my "apt install --reinstall systemd"
At 22:19, I upgraded pipewire (not done before because this requires the 
removal of pulseaudio)
At 23:52, I reinstalled some package from the rescue system
At 00:18, I installed debsums
At 00:46, I reinstalled all problematic packages

   Regards,
     Vincent

Bug#1020312: usrmerge: systemd file disappearing

[Vincent Danjean]

Package: usrmerge
Version: 30+nmu2
Severity: serious
Justification: break other packages upgrades

When I upgraded my system to current unstable, usrmerge has
been pulled-in due to the init-system-helpers dependency.
But one package fails to upgrade (fetchmail) due to
/lib/systemd/system/sysinit.target missing.
Reinstalling the systemd package fixes the problem.

Feel free to reassign to systemd if you think the problem
comes from it but usrmerge is my first guess (without any
specific evidence)

Note that systemd does *not* upgrade today (see at the end
of the commands)

vdanjean@eyak:~$ sudo apt upgrade
[...]
Paramétrage de fetchmail (6.4.33-2) ...
insserv: warning: current stop runlevel(s) (empty) of script `fetchmail' 
overrides LSB defaults (0 1 6).
Failed to restart fetchmail.service: Unit sysinit.target not found.
invoke-rc.d: initscript fetchmail, action "restart" failed.
○ fetchmail.service - LSB: init-Script for system wide fetchmail daemon
 Loaded: loaded (/etc/init.d/fetchmail; generated)
 Active: inactive (dead)
   Docs: man:systemd-sysv-generator(8)

sept. 19 20:27:35 eyak systemd[1]: Starting LSB: init-Script for system wide 
fetchmail daemon...
sept. 19 20:27:35 eyak fetchmail[2556]: Not starting fetchmail daemon, disabled 
via /etc/default/fetchmail.
sept. 19 20:27:35 eyak systemd[1]: Started LSB: init-Script for system wide 
fetchmail daemon.
sept. 19 21:35:02 eyak systemd[1]: Stopping LSB: init-Script for system wide 
fetchmail daemon...
sept. 19 21:35:02 eyak fetchmail[22013]: Not starting fetchmail daemon, 
disabled via /etc/default/fetchmail.
sept. 19 21:35:02 eyak systemd[1]: fetchmail.service: Deactivated successfully.
sept. 19 21:35:02 eyak systemd[1]: Stopped LSB: init-Script for system wide 
fetchmail daemon.
dpkg: erreur de traitement du paquet fetchmail (--configure) :
 installed fetchmail package post-installation script subprocess returned error 
exit status 1
Des erreurs ont été rencontrées pendant l'exécution :
 fetchmail
vdanjean@eyak:~$ sudo systemctl cat fetchmail
# /run/systemd/generator.late/fetchmail.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/fetchmail
Description=LSB: init-Script for system wide fetchmail daemon
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=network-online.target
After=remote-fs.target
After=mail-transport-agent.target
After=postfix.service
After=exim4.service
After=nss-lookup.target
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/fetchmail start
ExecStop=/etc/init.d/fetchmail stop
vdanjean@eyak:~$ sudo systemctl restart fetchmail
Failed to restart fetchmail.service: Unit sysinit.target not found.
vdanjean@eyak:~$ sudo systemctl status sysinit.target
● sysinit.target
 Loaded: not-found (Reason: Unit sysinit.target not found.)
 Active: active since Mon 2022-09-19 20:27:32 CEST; 1h 16min ago
  Until: Mon 2022-09-19 20:27:32 CEST; 1h 16min ago

sept. 19 20:27:32 eyak systemd[1]: Reached target System Initialization.
vdanjean@eyak:~$ sudo systemctl daemon-reexec 
vdanjean@eyak:~$ sudo systemctl status sysinit.target
● sysinit.target
 Loaded: not-found (Reason: Unit sysinit.target not found.)
 Active: active since Mon 2022-09-19 20:27:32 CEST; 1h 17min ago
  Until: Mon 2022-09-19 20:27:32 CEST; 1h 17min ago

sept. 19 20:27:32 eyak systemd[1]: Reached target System Initialization.
vdanjean@eyak:~$ dpkg -S sysinit.target
udev: /lib/systemd/system/sysinit.target.wants/systemd-udevd.service
systemd: /lib/systemd/system/sysinit.target.wants/systemd-sysctl.service
systemd: /lib/systemd/system/sysinit.target.wants/dev-hugepages.mount
systemd: /lib/systemd/system/sysinit.target.wants/systemd-random-seed.service
systemd: /lib/systemd/system/sysinit.target.wants/systemd-sysusers.service
systemd: /lib/systemd/system/sysinit.target.wants/veritysetup.target
systemd: 
/lib/systemd/system/sysinit.target.wants/systemd-machine-id-commit.service
udev, systemd: /lib/systemd/system/sysinit.target.wants
udev: /lib/systemd/system/sysinit.target.wants/systemd-udev-trigger.service
systemd: /lib/systemd/system/sysinit.target.wants/systemd-journald.service
systemd: /lib/systemd/system/sysinit.target.wants/systemd-update-utmp.service
systemd: /lib/systemd/system/sysinit.target.wants/sys-kernel-debug.mount
systemd: /lib/systemd/system/sysinit.target.wants/sys-kernel-config.mount
systemd: /lib/systemd/system/sysinit.target
systemd: /lib/systemd/system/sysinit.target.wants/dev-mqueue.mount
systemd: /lib/systemd/system/sysinit.target.wants/sys-fs-fuse-connections.mount
systemd: 
/lib/systemd/system/sysinit.target.wants/systemd-ask-password-console.path
systemd: /lib/systemd/system/sysinit.target.wants/systemd-binfmt.service
systemd: 

Bug#1019425: dkms 3.0.6-2 not signing modules

[Vincent Danjean]

Package: dkms
Version: 3.0.6-2
Followup-For: Bug #1019425
Control: tags -1 patch

  The dkms script has several flaw that forbid module signing:
- Debian, contrary to ubuntu, does not have kmodsign
  sign-file from the kernel should be directly used
- the script logic was wrong (if [[ -x "$(command -v XXX) ]]; then XXX missing 
; fi => this is the reverse)
- debian update-secureboot-policy does not accept/use the --new-key and 
--enroll-key options (contrary to ubuntu?)

  So, here is the patch I applied to dkms on my system in order to get module 
signing back.

Note that:
- the part of the patch to generate and enroll the key should be carefully 
checked
  (I already have keys so I do not test this part of the patch)
  Perhaps, "mokutil --import KEY" should be run after checking that the key is 
not already enrolled
- on upgrade, if a user previously make module signing with its own 
sign_tool/sign_helper.sh,
  the key is not necessarly at the default expected place (/var/lib/dkms)
- perhaps, it would be better in Debian to put the key by default in
  /etc/dkms/keys/ instead of /var/lib/dkms/ (the current default set in the 
dkms script)

  Regards
Vincent


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dkms depends on:
ii  build-essential12.9
ii  clang-11 [c-compiler]  1:11.1.0-6+b2
ii  clang-13 [c-compiler]  1:13.0.1-7
ii  clang-14 [c-compiler]  1:14.0.6-2
ii  clang-9 [c-compiler]   1:9.0.1-20+b1
ii  dctrl-tools2.24-3+b1
ii  dh-dkms3.0.6-2
ii  dpkg-dev   1.21.9
ii  gcc [c-compiler]   4:12.2.0-1
ii  gcc-10 [c-compiler]10.4.0-5
ii  gcc-11 [c-compiler]11.3.0-6
ii  gcc-12 [c-compiler]12.2.0-2
ii  gcc-9 [c-compiler] 9.5.0-2
ii  kmod   30+20220630-3
ii  lsb-release11.2
ii  make   4.3-4.1
ii  patch  2.7.6-7

Versions of packages dkms recommends:
ii  fakeroot 1.29-1
ii  linux-headers-amd64 [linux-headers-generic]  5.19.6-1
ii  sudo 1.9.11p3-1

Versions of packages dkms suggests:
ii  e2fsprogs  1.46.5-2
ii  menu   2.1.49

-- no debconf information
--- usr/sbin/dkms   2022-09-07 12:27:13.0 +0200
+++ /usr/sbin/dkms  2022-09-12 21:43:27.006384862 +0200
@@ -897,14 +897,14 @@
 echo "Public certificate (MOK): $mok_certificate"
 
 case "$running_distribution" in
-debian* | ubuntu* )
+ubuntu* )
 
-if [[ -x "$(command -v kmodsign)" ]]; then
-echo "Binary kmod-sign not found, modules won't be signed"
+if [[ ! -x "$(command -v kmodsign)" ]]; then
+echo "Binary kmodsign not found, modules won't be signed"
 return
 fi
 
-if [[ -x "$(command -v update-secureboot-policy)" ]]; then
+if [[ ! -x "$(command -v update-secureboot-policy)" ]]; then
 echo "Binary update-secureboot-policy not found, modules won't 
be signed"
 return
 fi
@@ -917,6 +917,33 @@
 fi
 
 ;;
+debian* )
+
+if [[ ! -f "${sign_file}" || ! -x "${sign_file}" ]]; then
+echo "Binary sign-file not found, module won't be signed"
+return
+fi
+
+if [[ ! -x "$(command -v update-secureboot-policy)" ]]; then
+echo "Binary update-secureboot-policy not found, modules won't 
be signed"
+return
+fi
+
+do_signing=1
+
+if [[ "$sb_state" == "SecureBoot is enabled" ]]; then
+if [[ ( ! -f $mok_signing_key && ! "$mok_signing_key" == *":"* 
) || ! -f $mok_certificate ]]; then
+echo "Certificate or key are missing, generating self 
signed certificate for MOK..."
+openssl req -new -x509 -nodes -days 36500 -subj "/CN=DKMS 
module signing key" \
+-newkey rsa:2048 -keyout $mok_signing_key \
+-outform DER -out $mok_certificate > /dev/null 2>&1
+   openssl x509 -in $mok_certificate -out 
/var/lib/dkms/mok.der -outform DER
+   mokutil --import /var/lib/dkms/mok.der
+   rm /var/lib/dkms/mok.der
+fi
+fi
+
+;;
 *)
 
 if [[ ! -f "${sign_file}" || ! -x 

Bug#1004769: Video not handled anymore for now

[Vincent Danjean]

Le 16/07/2022 à 18:50, Steven Robbins a écrit :

I would say that there may well be others in your situation so if you do find a
method please report back to this bug.


  For my personnal use, until upstream provides a correct fix, I recompile
digikam 7.7.0-1 (-2 was not pushed in the git ;-) ) with devel packages
of ffmpeg4 (from stable) installed (other build dependencies come from
unstable) [I only revert the commit that disable video and add a
changelog entry].
  The result is packages with video support, but using ffmpeg from
stable (version 4). So, it is ok for my personnal use (but unsuitable
for official Debian). If others are interested, you can look here:

http://people.debian.org/~vdanjean/debian/pool/main/d/digikam/

Note: no support is provided. So particular tests have been done, ...

  Regards,
Vincent

Bug#1004769: Video not handled anymore for now

[Vincent Danjean]

Le 16/07/2022 à 18:50, Steven Robbins a écrit :

Thank you for the suggestion.  I was completely unaware of "apt-listbugs".

I have just re-titled and changed the severity of this bug.


Great, it can help other users to avoid the upgrade if they want to.


Due to the large dependencies, it is probably very difficult to
downgrade digikam to a version with video support once 4:7.7.0-1
is installed. I did not try for now.


I haven't tried either, so I don't know.  Maybe one can just pull the packages
from the last stable release?  Build the 7.6 source package ?

I would say that there may well be others in your situation so if you do find a
method please report back to this bug.


Reading bug reports (in particular [1] and [2]), the root cause comes from
the ffmpeg transition in Debian. Trying to reverse this would be very
difficult leading to lots of downgrade of other packages (going back to
stable versions).

I'm also afraid that the older digikam would run with a upgraded
database. I'm not sure this won't corrupt some internal tables...

If I've time, I would probably try to build local ffmpeg4 packages
(or to install previous one if they are coinstallable) and rebuild
digikam with ffmpeg4. Of cause, this would be a local workaround,
not something sutable for Debian.

  Thanks for your work on digikam packaging

  Vincent

[1] https://bugs.kde.org/show_bug.cgi?id=453840
[2] https://bugs.kde.org/show_bug.cgi?id=448681

Bug#1004769: Video not handled anymore for now

[Vincent Danjean]

  Hi,

  This bug is rather anoying as I'm using digikam to manage my video.
The low severity (and the title of the bug) does not allow one to stop
the upgrade with apt-listbugs. In my opinion, this bug is at lease
important (to be seen by apt-listbugs) and its title should reflect
that video is not handle by digikam for now (or a new bug can be
created and blocked by this one)
  Due to the large dependencies, it is probably very difficult to
downgrade digikam to a version with video support once 4:7.7.0-1
is installed. I did not try for now. I hope video will be soon back.

  Regards,
Vincent

Bug#1013090: digikam: Regression : when batch renaming file (F2), only the first modifier is taken into account

[Vincent Danjean]

Package: digikam
Version: 4:7.6.0-1
Severity: normal
Tags: patch

  Hi,

  When using several modifiers in the rename file dialog, only the first one is 
taken into account.

  I submitted the bug upstream:
https://bugs.kde.org/show_bug.cgi?id=455417

  According to the answer, this bug is already fixed in 7.7.0.
But if packaging the 7.7.0 is difficult/long, the fix is a one-caracter patch:
https://invent.kde.org/graphics/digikam/-/commit/6330e608f9e477253a3982a4e88abf1c901fe0c2

  Regards,
Vincent

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages digikam depends on:
ii  digikam-data  4:7.6.0-1
ii  digikam-private-libs  4:7.6.0-1
ii  libc6 2.33-7
ii  libgcc-s1 12-20220428-1
ii  libkf5configcore5 5.90.0-1
ii  libkf5coreaddons5 5.90.0-1
ii  libkf5i18n5   5.90.0-1
ii  libmagick++-6.q16-8   8:6.9.11.60+dfsg-1.3+b2
ii  libqt5core5a  5.15.2+dfsg-16+b1
ii  libqt5gui55.15.2+dfsg-16+b1
ii  libqt5sql55.15.2+dfsg-16+b1
ii  libqt5sql5-mysql  5.15.2+dfsg-16+b1
ii  libqt5sql5-sqlite 5.15.2+dfsg-16+b1
ii  libqt5widgets55.15.2+dfsg-16+b1
ii  libstdc++612-20220428-1
ii  perl  5.34.0-4

Versions of packages digikam recommends:
ii  chromium [www-browser] 101.0.4951.54-1
ii  ffmpegthumbs   4:21.12.3-1.1
ii  firefox [www-browser]  100.0-1
ii  firefox-esr [www-browser]  91.9.0esr-1
ii  konqueror [www-browser]4:21.12.3-1
ii  lynx [www-browser] 2.9.0dev.10-1
ii  w3m [www-browser]  0.5.3+git20220429-1

Versions of packages digikam suggests:
ii  breeze-icon-theme  4:5.90.0-1
pn  digikam-doc
ii  systemsettings 4:5.24.4-1

-- no debconf information

Bug#1009742: adcli: wrong umask leading to no keytab update

[Vincent Danjean]

Package: adcli
Version: 0.9.0-1
Severity: normal

  Hi,

  On bullseye systems in AD environment (managed with sssd),
I observed problems with krb5.conf snippet generation in sssd.log:
   *  (2022-04-14 22:36:18): [be[domain.fr]] 
[ad_machine_account_password_renewal_done] (0x1000): --- adcli output start---
adcli: couldn't write new krb5.conf file: /tmp/adcli-krb5-f3rplr/krb5.conf: 
Permission denied
---adcli output end---

And, indeed, looking into /tmp, I find lots of
/tmp/adcli-krb5-... directories (one per day), all empty, and
all with 600 perms (not 700!).

So, I patched adcli to first print, and then change the umak.
The umask was 0x7f. Now, I force-clear the USER bits (see
the patch at the end).

The main bug probably comes from sssd (setting a wrong umask).
I'm using sssd 2.6.3-1~bpo11+1 (a local rebuild for bullseye)
I fixed the bug in adcli (easier for me to do so, and there
is no reason for adcli to be invoked with such a bogus umask)

Now, with my patch, sssd logs tell me:
(2022-04-16  0:15:39): [be[domain.fr]] 
[ad_machine_account_password_renewal_done] (0x1000): --- adcli output start---
adcli: strange umask 7f, setting it to 3f
 * Wrote out krb5.conf snippet to 
/tmp/adcli-krb5-SQMtbL/krb5.d/adcli-krb5-conf-kcm9gK
---adcli output end---

And /tmp/adcli-krb5-SQMtbL directory is correctly removed.

  Regards,
Vincent

my patch:

--- a/tools/tools.c
+++ b/tools/tools.c
@@ -314,6 +314,15 @@
int errn = 0;
FILE *fo;
 
+   {
+   mode_t u = umask(0);
+   umask(u);
+   mode_t u2 = u & ~(S_IRUSR|S_IWUSR|S_IXUSR);
+   if (u2 != u) {
+   warnx ("strange umask %x, setting it to %x", u, u2);
+   umask(u2);
+   }
+   }
krb5_conf = getenv ("KRB5_CONFIG");
if (!krb5_conf || !krb5_conf[0])
krb5_conf = KRB5_CONFIG;



-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages adcli depends on:
ii  libc62.33-7
ii  libcom-err2 [libcomerr2] 1.46.5-2
ii  libgssapi-krb5-2 1.19.2-2+b1
ii  libk5crypto3 1.19.2-2+b1
ii  libkrb5-31.19.2-2+b1
ii  libldap-2.4-22.4.59+dfsg-1+b1
ii  libldap-2.5-02.5.11+dfsg-1
pn  libsasl2-modules-gssapi-mit  

adcli recommends no packages.

adcli suggests no packages.

Bug#1009081: g++-11: friend statement not used for template specialization

[Vincent Danjean]

  Hi,

  More strange: by adding an unused static method, the behavior
of the previous templates change.

$ cat toto6.cpp
#include 

struct X {
  template  struct check_is_map {
  static constexpr bool value = false;
  };

  template 
  struct check_is_map {
  static constexpr bool value = true;
  };

  template  struct check_is_map2 {
static constexpr bool value = check_is_map::value;
  };

  static void func();
};

template  struct check_is_map {
static constexpr bool value = false;
};

template 
struct check_is_map {
static constexpr bool value = true;
};

struct Config {
using is_map=void;
};

struct ConfigBis {
  private:
template 
friend struct check_is_map;
friend struct X;
using is_map=void;
};

#ifdef FOO
void X::func() {
std::cerr << "* Through method" << std::endl;
std::cerr << "X::VALUE (public): "
<< X::check_is_map::value
  << std::endl;
std::cerr << "X::VALUE (private+friend): "
<< X::check_is_map::value
  << std::endl;
std::cerr << "** By proxy template" << std::endl;
std::cerr << "X::Proxy::VALUE (public): "
<< X::check_is_map2::value
  << std::endl;
std::cerr << "X::Proxy::VALUE (private+friend): "
<< X::check_is_map2::value
  << std::endl;
}
#endif

int main()
{
std::cerr << "* From main" << std::endl;
std::cerr << "VALUE (public): "
<< check_is_map::value
  << std::endl;
std::cerr << "VALUE (private+friend): "
<< check_is_map::value
  << std::endl;
std::cerr << "X::VALUE (public): "
<< X::check_is_map::value
  << std::endl;
std::cerr << "X::VALUE (private+friend): "
<< X::check_is_map::value
  << std::endl;
std::cerr << "** By proxy template" << std::endl;
std::cerr << "X::Proxy::VALUE (public): "
<< X::check_is_map2::value
  << std::endl;
std::cerr << "X::Proxy::VALUE (private+friend): "
<< X::check_is_map2::value
  << std::endl;
}
$ g++ -std=gnu++17 -Wall -Wextra toto6.cpp
$ ./a.out
* From main
VALUE (public): 1
VALUE (private+friend): 0
X::VALUE (public): 1
X::VALUE (private+friend): 0
** By proxy template
X::Proxy::VALUE (public): 1
X::Proxy::VALUE (private+friend): 0
$ g++ -std=gnu++17 -Wall -Wextra toto6.cpp -DFOO
$ ./a.out
* From main
VALUE (public): 1
VALUE (private+friend): 0
X::VALUE (public): 1
X::VALUE (private+friend): 1
** By proxy template
X::Proxy::VALUE (public): 1
X::Proxy::VALUE (private+friend): 1

  Regards,
Vincent

Bug#1009081: g++-11: friend statement not used for template specialization

[Vincent Danjean]

Package: g++-11
Version: 11.2.0-19
Severity: normal

Contrary to clang++, g++ does not honor "friend" statement when evaluating
template specialization

Here is a short example:
$ cat toto6.cpp 
#include 

struct X {
  template  struct check_is_map {
  static constexpr bool value = false;
  };
  
  template 
  struct check_is_map {
  static constexpr bool value = true;
  };
};

template  struct check_is_map {
static constexpr bool value = false;
};

template 
struct check_is_map {
static constexpr bool value = true;
};

struct Config {
using is_map=void;
};

struct ConfigBis {
  private:
template 
friend struct check_is_map; // friend of the template
friend struct X; // friend of the surrounding class
using is_map=void;
};

int main()
{
std::cerr << "VALUE (public): "
<< check_is_map::value
  << std::endl;
std::cerr << "VALUE (private+friend): "
<< check_is_map::value
  << std::endl;
std::cerr << "X::VALUE (public): "
<< X::check_is_map::value
  << std::endl;
std::cerr << "X::VALUE (private+friend): "
<< X::check_is_map::value
  << std::endl;
}

$ clang++ -std=gnu++17 -Wall -Wextra toto6.cpp 
$ ./a.out 
VALUE (public): 1
VALUE (private+friend): 1
X::VALUE (public): 1
X::VALUE (private+friend): 1
$ g++ -std=gnu++17 -Wall -Wextra toto6.cpp 
$ ./a.out 
VALUE (public): 1
VALUE (private+friend): 0
X::VALUE (public): 1
X::VALUE (private+friend): 0

  Regards,
Vincent


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages g++-11 depends on:
ii  gcc-1111.2.0-19
ii  gcc-11-base   11.2.0-19
ii  libc6 2.33-7
ii  libgmp10  2:6.2.1+dfsg-3
ii  libisl23  0.24-2
ii  libmpc3   1.2.1-2
ii  libmpfr6  4.1.0-3
ii  libstdc++-11-dev  11.2.0-19
ii  libzstd1  1.4.10+dfsg-1
ii  zlib1g1:1.2.11.dfsg-4

g++-11 recommends no packages.

Versions of packages g++-11 suggests:
pn  g++-11-multilib  
ii  gcc-11-doc   11.2.0-1

-- no debconf information

Bug#1007220: digikam: Failed to update the database schema from version 10 to version 11 with mysql database

[Vincent Danjean]

Package: digikam
Version: 4:7.5.0-5
Severity: important

When using digikam with an external (mysql/mariadb) database, the upgrade
can fail leading to digikam refusing to start.
This is due to a permission problems.

It can be workarounded/fixed by issuing the following mysql command:
set global log_bin_trust_function_creators=1;
I'm not sure of all the security implication (it does not matter for
me: I'm alone on the machine).

At minimal, a notice in /usr/share/doc/digikam/NEWS.Debian.gz would
be appreciated (and/or a better/more precise error message from digikam).

Details of this can be found in
https://bugs.kde.org/show_bug.cgi?id=451460
and
https://bugs.kde.org/show_bug.cgi?id=435065

  Regards,
Vincent


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.16.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages digikam depends on:
ii  digikam-data  4:7.5.0-5
ii  digikam-private-libs  4:7.5.0-5
ii  libc6 2.33-7
ii  libgcc-s1 12-20220222-1
ii  libkf5configcore5 5.90.0-1
ii  libkf5coreaddons5 5.90.0-1
ii  libkf5i18n5   5.90.0-1
ii  libmagick++-6.q16-8   8:6.9.11.60+dfsg-1.3+b2
ii  libqt5core5a  5.15.2+dfsg-15
ii  libqt5gui55.15.2+dfsg-15
ii  libqt5sql55.15.2+dfsg-15
ii  libqt5sql5-mysql  5.15.2+dfsg-15
ii  libqt5sql5-sqlite 5.15.2+dfsg-15
ii  libqt5widgets55.15.2+dfsg-15
ii  libstdc++612-20220222-1
ii  perl  5.34.0-3

Versions of packages digikam recommends:
ii  chromium [www-browser] 98.0.4758.102-1+b1
ii  ffmpegthumbs   4:21.08.0-1
ii  firefox [www-browser]  96.0.3-1
ii  firefox-esr [www-browser]  91.6.0esr-1
ii  konqueror [www-browser]4:21.08.2-1
ii  lynx [www-browser] 2.9.0dev.10-1
ii  w3m [www-browser]  0.5.3+git20210102-6

Versions of packages digikam suggests:
ii  breeze-icon-theme  4:5.90.0-1
pn  digikam-doc
ii  systemsettings 4:5.24.2-1

-- no debconf information

Bug#1006724: network-manager: DNS information not cleaned correctly when switching of networks

[Vincent Danjean]

Package: network-manager
Version: 1.36.0-2
Severity: normal

  Hi,

  When I change of location with my laptop (putting it in suspend-to-ram
during the transfert), I found several times that the network become slow.
  Looking more in details, I discovered that network-manager does not cleanup
correctly the DNS information of the previous (wired) connection. As I have
specific settings, the network-manager connection is not the same at work and
at home (specific Mac fixed at home, forced fixed IPv6 at work, ...)
  The DNS information still present in /etc/resolv.conf comes from DHCP
information (at work or at home) that are kept when the connexion is switched
by network-manager.
  Even when I disable the connexion, the DNS information are kept.

  Here is the current situation (with anonymisation of IP and dnsdomain) where
I manually disable the wired connexion (so I do not have network access for
now):
vdanjean@eyak:/run/resolvconf/interface$ nmcli 
docker0: connecté à docker0
"docker0"
bridge, XX:XX:XX:XX:XX:5D, sw, mtu 1500
inet4 172.17.0.1/16
route4 169.254.0.0/16 metric 1000
route4 172.17.0.0/16 metric 0
inet6 fe80::42:45ff:fe7a:55d/64

3C:DC:BC:D0:26:00: déconnecté
"Silk"
1 connexion disponible
bt (bluez), 3C:DC:BC:D0:26:00, hw

enx98fc84e13b03: déconnecté
"Realtek RTL8153"
2 connexions disponibles
ethernet (r8152), XX:XX:XX:XX:XX:03, connexion automatique, hw, mtu 1500

en-wifi: déconnecté
"Intel 8265 / 8275"
3 connexions disponibles
wifi (iwlwifi), XX:XX:XX:XX:XX:29, connexion automatique, hw, mtu 1500

p2p-dev-en-wifi: déconnecté
"p2p-dev-en-wifi"
wifi-p2p, hw

veth315cdd3: non-géré
"veth315cdd3"
ethernet (veth), XX:XX:XX:XX:XX:A7, sw, mtu 1500

lo: non-géré
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
servers: AAA.AAA.24.30 BBB.BBB.1.22
domains: mywork1.fr mywork2.fr

servers: ::::4 :::::7

servers: AAA.AAA.24.30 BBB.BBB.1.22
domains: mywork1.fr mywork2.fr

servers: ::::4 :::::7

servers: AAA.AAA.24.30 BBB.BBB.1.22
domains: mywork1.fr mywork2.fr

servers: ::::4 :::::7

Utilisez « nmcli device show » pour obtenir des informations complètes sur les >

Consultez les pages de manuel nmcli(1) et nmcli-examples(7) pour les détails co>
vdanjean@eyak:/run/resolvconf/interface$ cat NetworkManager 
search mywork1.fr mywork2.fr
nameserver AAA.AAA.24.30
nameserver BBB.BBB.1.22
nameserver ::::4
nameserver :::::7
vdanjean@eyak:/run/resolvconf/interface$ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

nameserver AAA.AAA.24.30
nameserver BBB.BBB.1.22
nameserver ::::4
search mywork1.fr mywork2.fr


Only if I restart NetworkManager, then these outdated informations go out:
vdanjean@eyak:/run/resolvconf/interface$ sudo systemctl restart NetworkManager
vdanjean@eyak:/run/resolvconf/interface$ cat NetworkManager 
search home.fr sub1.home.fr sub2.home.fr
nameserver 10.77.0.2
nameserver fd77:53::1
nameserver 192.168.77.1
vdanjean@eyak:/run/resolvconf/interface$

If I disable my home connextion (that NetworkManager connects automatically on 
restart),
I come back to the previous nmcli state (ie no active connexion) as before, 
but, this time,
/run/resolvconf/interface/NetworkManager do not exists and the "DNS
configuration:" section in nmcli is not printed.



  So, it seems that sometimes NetworkManager forgets to clean DNS information
(as shown by nmcli) when switching between networks connexion. As manual
restart of the NetworkManager deamon allows one to fix that.


  Regards,
Vincent




-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.16.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages network-manager depends on:
ii  adduser  3.118
ii  dbus 1.14.0-1
ii  libaudit11:3.0.7-1
ii  libbluetooth35.62-2
ii  libc62.33-7
ii  libcurl3-gnutls  7.81.0-1
ii  libglib2.0-0 2.70.4-1
ii  libgnutls30  3.7.3-4+b1
ii  

Bug#1006366: hostapd: No WEP support by default anymore should be documented

[Vincent Danjean]

Package: hostapd
Version: 2:2.10-2
Severity: normal

Hi,

Since 2.10, upstream does not enable CONFIG_WEP for default build
and Debian build does not change that.

This modification should be at least documented (in README.Debian
for example) or CONFIG_WEP should be re-enabled for Debian packages.

I had to dig into the source in order to understand why I got this
error messages:
# hostapd /etc/hostapd/hostapd.conf
Line 162: unknown configuration item 'wep_default_key'
Line 163: unknown configuration item 'wep_key0'
2 errors found in configuration file '/etc/hostapd/hostapd.conf'
Failed to set up interface with /etc/hostapd/hostapd.conf
Failed to initialize interface

wep_default_key and wep_key0 are still in the documentation.

A better fix (for upstream) would be to check again for
these configuration item at the end of the long test
for each conf item, and add a specific message such as
"hostapd not configurated with WEP support, configuration item 
'wep_default_key' unavailable"

  Regards,
Vincent

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hostapd depends on:
ii  init-system-helpers  1.61
ii  libc62.33-5
ii  libnl-3-200  3.5.0-0.1
ii  libnl-genl-3-200 3.5.0-0.1
ii  libnl-route-3-2003.5.0-0.1
ii  libssl1.11.1.1m-1
ii  lsb-base 11.1.0

hostapd recommends no packages.

hostapd suggests no packages.

Bug#1006313: ucf: Syntax error in ucf: /usr/bin/ucf: 444: [: missing ]

[Vincent Danjean]

Package: ucf
Version: 3.0043
Severity: normal
Tags: patch

  As I'm using a few diversion, I notice a syntax error in ucf while
running APT:
[...]
Setting up samba-common (2:4.13.13+dfsg-1~deb11u3) ...
/usr/bin/ucf: 444: [: missing ]
grep: ]: No such file or directory
[...]

Indeed, the code is:
divert_line=$(dpkg-divert --list "$dest_file")
if [ -n "$divert_line" ]; then
   if [ echo "$divert_line" | grep "^local" ]; then
   # local diversion; pick something not in the package namespace
   divert_package="LOCAL"
[...]

   if [ echo "$divert_line" | grep "^local" ]; then
should be changed into
   if echo "$divert_line" | grep -sq "^local"; then
or
   if [ "$(echo "$divert_line" | grep "^local")" ]; then

  Regards,
Vincent



-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ucf depends on:
ii  coreutils   8.32-4.1
ii  debconf 1.5.79
ii  sensible-utils  0.0.17

ucf recommends no packages.

ucf suggests no packages.

-- debconf information:
* ucf/changeprompt: install_new
* ucf/changeprompt_threeway: merge_threeway
* ucf/show_diff:
* ucf/conflicts_found:
  ucf/title:

Bug#1003479: swig: Missing support for php8.1

[Vincent Danjean]

Package: swig
Version: 4.0.2-1
Followup-For: Bug #1003479

  Looking at upstream, support for php8 will be present in swig 4.1.0 that is
not yet released.

  Vincent

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages swig depends on:
ii  swig4.0  4.0.2-1

swig recommends no packages.

Versions of packages swig suggests:
pn  swig-doc   
pn  swig-examples  

-- no debconf information

Bug#1003479: swig: Missing support for php8.1

[Vincent Danjean]

Package: swig
Version: 4.0.2-1
Severity: important

  php8.1 is entering sid but swig generates incompatible source files
(with the -php7 flag as there are no -php8 flag for now)
The result is that some packages FTBFS due to this (see owfs, #1003472 for
example).

  According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976811#200
swig 4.2.0 should fix the problem (I did not check myself).

  Regards,
   Vincent

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages swig depends on:
ii  swig4.0  4.0.2-1

swig recommends no packages.

Versions of packages swig suggests:
pn  swig-doc   
pn  swig-examples  

-- no debconf information

Bug#1002711: linux-image-5.14.0-4-amd64: poll syscall does not work on some /proc files

[Vincent Danjean]

On 30/12/2021 14:52, Bastian Blank wrote:

On Mon, Dec 27, 2021 at 11:31:21PM +0100, Vincent Danjean wrote:

On a plain (with more than two bytes) file, the second poll succeed.
On /proc/bus/input/devices, the second poll hangs.
Note: this is an old behavior. I initially observe it on an embeded system with
a 4.1 kernel.


/proc is no real filesystem.  It simply does not support poll, because
the output is generated while you are reading it, so it does not know
when anything changes.  See also
https://unix.stackexchange.com/questions/74713/how-frequently-is-the-proc-file-system-updated-on-linux?rq=1

If you want to know about hardware changes, use udev or listen to kernel
netlink messages.


I understand that /proc is different. But I'm not monitoring it.
My goal was only to read it totally from a busybox shell with a
"while read" loop to find the eventX associated with the
touchscreen of the e-reader.
And the first read from busybox shell never complete (instead of
returning the first line of the file) due to the fact that
busybox use poll, then read a byte, then use poll again.


  Do you think I should reassign this bug to busybox?

  Or do you think I'm wrong trying to read the /proc file
from a shell script without to copy it elsewhere before?

Stalling:
busybox sh -c 'while read l ; do echo $l ; done  < /proc/bus/input/devices'
Working (but bash is not present on the initial target system):
bash -c 'while read l ; do echo $l ; done  < /proc/bus/input/devices'

  As workaround, I'm currently using a copy of the file
("busybox cp" works). It should probably also be possible
to get the same kind of info from /sys files but this seems
less easy.

  I just saw that other files seems to work:
Ok:
busybox sh -c 'read l < /proc/bus/input/handlers ; echo $l'
Stale:
busybox sh -c 'read l < /proc/bus/input/devices ; echo $l'

  Regards,
Vincent



Bastian

Bug#1002711: linux-image-5.14.0-4-amd64: poll syscall does not work on some /proc files

[Vincent Danjean]

Package: src:linux
Version: 5.14.16-1
Severity: normal

Hi,

While writing a script with busybox parsing /proc/bus/input/devices,
I discovered that poll syscall seems to not give correct information
on this file. Before reporting, I checked with a small C program
(in attachment).

The main part of the program is:
ret = poll(fds, 1, -1);
ret = read(fd, , 1);
ret = poll(fds, 1, -1);

On a plain (with more than two bytes) file, the second poll succeed.
On /proc/bus/input/devices, the second poll hangs.

$ ./poll-test ./poll-test.c 
ret=1, revent=1 (POLLIN=1)
ret=1, revent=1 (POLLIN=1)
$ ./poll-test /proc/bus/input/devices 
ret=1, revent=1 (POLLIN=1)
[hangs until C-c]

I discovered the problem writing a script similar to:
while read l; do
  ... [ modifying global shell variables, so using a pipe is not an option ]
done < /proc/bus/input/devices

I hangs when executed with busybox (not bash that probably uses another way to
get its input)
Using strace give me the idea to look at poll behavior.

Note: this is an old behavior. I initially observe it on an embeded system with
a 4.1 kernel.

  Regards,
Vincent


-- Package-specific info:
** Version:
Linux version 5.14.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.3.0-12) 10.3.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Debian 
5.14.16-1 (2021-11-03)

** Command line:
BOOT_IMAGE=/vmlinuz-5.14.0-4-amd64 root=/dev/mapper/eyak-root ro apparmor=0 
security= swapaccount=1 cgroup_enable=memory atkbd.softraw=0 vsyscall=emulate 
syscall.x32=y quiet

** Tainted: O (4096)
 * externally-built ("out-of-tree") module was loaded

** Kernel log:
[1831798.548063] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831801.552011] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831804.556033] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831807.564376] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831810.559917] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831813.560164] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831816.568135] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831819.572297] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831822.572134] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831825.568408] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831828.572187] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831831.580257] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831834.576209] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831837.576477] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831840.584549] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831843.580438] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831846.580507] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831849.584526] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831852.584449] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831855.588255] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831858.592325] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831861.596533] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831864.596270] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831867.596294] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831870.596267] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831873.600754] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831876.600514] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831879.604364] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831882.608328] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831885.608359] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831888.612459] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831891.612468] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831894.616589] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831897.624509] Lockdown: rpc-worker: debugfs access is restricted; see man 
kernel_lockdown.7
[1831900.624468] Lockdown: rpc-worker: debugfs access is restricted; see man 

Bug#1000180: ifupdown: dhclient -6 not stopped with inet6, auto and dhcp=1

[Vincent Danjean]

Package: ifupdown
Version: 0.8.36+nmu1
Severity: normal

When setting up an interface with:
iface IFACE inet6 auto
dhcp 1
[...]
then, the dhclient -6 is correctly started (on ifup) but
not stopped (on ifdown).

Looking at the sources, inet6.defn, we can see:
method auto
  [...]
  up
[...]
/sbin/dhclient -6 -v -P -pf /run/dhclient6.%iface%.pid -lf 
/var/lib/dhcp/dhclient6.%iface%.leases -I -df 
/var/lib/dhcp/dhclient.%iface%.leases %iface% \
if (var_true("dhcp", ifd) && execable("/sbin/dhclient") && 
var_true("request_prefix", ifd))
/sbin/dhclient -6 -1 -v -S -pf /run/dhclient6.%iface%.pid -lf 
/var/lib/dhcp/dhclient6.%iface%.leases -I -df 
/var/lib/dhcp/dhclient.%iface%.leases %iface% \
elsif (var_true("dhcp", ifd) && execable("/sbin/dhclient"))
echo 'No DHCPv6 client software found!' >&2; false \
elsif (var_true("dhcp", ifd))

  down
[nothing to stop dhclient...]

Should not we have something like (taken from the dhcp method):
  down
/sbin/dhclient -6 -v -r -pf /run/dhclient6.%iface%.pid -lf 
/var/lib/dhcp/dhclient6.%iface%.leases -I -df 
/var/lib/dhcp/dhclient.%iface%.leases %iface% \
if (var_true("dhcp", ifd) && execable("/sbin/dhclient"))
echo 'No DHCPv6 client software found!' >&2; false \
elsif (var_true("dhcp", ifd))

(not sure if we should test for "var_true("dhcp", ifd)" in the down
part. Perhaps it is better to always stop dhclient if any?

  Regards,
   Vincent



-- Package-specific info:
--- /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

noauto eth0
#iface eth0 inet dhcp

iface tap0 inet manual
pre-up openvpn --mktun --dev $IFACE
post-down openvpn --rmtun --dev $IFACE
#iface br0 inet dhcp
#bridge_ports tap0 eth0

noauto en-wired
#iface en-wired inet dhcp

#iface en-wired inet manual

# The primary network interface
#noauto eth5
#iface eth5 inet dhcp

iface imag-static inet static
address 129.88.69.129
netmask 255.255.255.0
network 129.88.69.0
broadcast 129.88.69.255
gateway 129.88.69.254
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 129.88.69.8
dns-search vpn.danjean.fr

iface imag-static-atsina inet static
address 129.88.69.127
netmask 255.255.255.0
network 129.88.69.0
broadcast 129.88.69.255
gateway 129.88.69.254
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 129.88.69.8
dns-search vpn.danjean.fr

iface mnhn-static inet static
address 192.134.154.62
netmask 255.255.255.0
network 192.134.154.0
broadcast 192.134.154.255
gateway 192.134.154.14
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 192.134.151.15 192.134.155.19
dns-search vpn.danjean.fr

iface mnhn-static2 inet static
address 192.134.154.75
netmask 255.255.255.0
network 192.134.154.0
broadcast 192.134.154.255
gateway 192.134.154.14
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 192.134.151.15 192.134.155.19
dns-search vpn.danjean.fr

iface dhcpserver inet static
address 192.168.77.1
netmask 255.255.255.0

iface galadriel-labri inet static
address 147.210.20.7
netmask 255.255.255.0
gateway 147.210.20.254
dns-nameservers 147.210.8.187 147.210.9.143 147.210.18.138

iface eth5_3 inet static
  address 10.77.0.2
  netmask 255.255.0.0
  network 10.77.0.0

#auto eth6
#iface eth6 inet dhcp

iface static inet static
address 192.168.77.1
netmask 255.255.255.0

iface wifi-campus inet dhcp
wireless-essid wifi-campus
#wireless-key 14BBB1E060C7C6BE8064CDF32C
#wpa : rcmJMQqUR5F8piQXcxofBiMjE3joMIsW

iface dino2 inet dhcp
wireless-essid dino2
wireless-key 14BBB1E060C7C6BE8064CDF32C
#wpa : rcmJMQqUR5F8piQXcxofBiMjE3joMIsW

iface dino inet dhcp
wireless-essid dino
wireless-key 14BBB1E060C7C6BE8064CDF32C
#   pre-up ifconfig $IFACE hw ether 00:13:ce:c5:f6:6f
#   wireless-mode ad-hoc
#   wireless-key off
#   wireless-key ABC1234567

iface dino-static inet static
wireless-essid dino
wireless-key 14BBB1E060C7C6BE8064CDF32C
address 192.168.77.15
netmask 255.255.255.0

iface dinotv inet static
wireless-essid dino
wireless-key 14BBB1E060C7C6BE8064CDF32C
address 192.168.14.6
netmask 255.255.255.0
gateway 192.168.14.254
dns-nameservers 192.168.77.1
post-up ifconfig eth6:1 192.168.77.100 netmask 255.255.255.0
#
iface villejuif inet dhcp
   

Bug#872891: gcc-multilib conflicts with GCC cross toolchains

[Vincent Danjean]

Package: gcc-multilib
Version: 4:11.2.0-2
Followup-For: Bug #872891

  Hi,

  I also have been hit by this bug.
I'm using several cross-tool chains (arm-linux-gnueabi, mipsel-linux-gnu,
i686-linux-gnu) and I was wondering why using plain gcc with -m32 does
not work.
  Perhaps due to the fact that gcc-i686-linux-gnu was installed, I successfully 
compile a basic C program (the one given in this bug report) but the link
fails ("gcc -m32" was looking only in x86_64 directory to find gcc libs and
objects)
  I first workaround this by looking at the LIBRARY_PATH of i686-linux-gnu-gcc
(adding "-v" when compiling to see the info), and I successfully link with
LIBRARY_PATH=...value_I_read... gcc -m32 file.o -o file

  Digging a bit more, I saw that gcc-multilib is an empty package with
a few dependencies and lots of conflicts. Only one dependencies was missing
on my system: gcc-11-multilib
  I tried to install it directly, the install succeeded (no conflicts for
gcc-11-multilib).
  And then, I discovered that "gcc -m32" works for both compiling and linking.

  So I'm really wondering why there are all these conflicts in gcc-multilib
(perhaps,  I works on my system because I also have several *:i386 packages
installed, or perhaps it works 'by chance' mixing files from different packages
that should not...)
  In anycase, for people that wish to have both cross chains and "gcc -m32"
working, manually installing the gcc-XX-multilib package for the current
compiler might be a solution.

  Regards
Vincent

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-multilib depends on:
ii  cpp  4:11.2.0-2
ii  gcc  4:11.2.0-2
ii  gcc-10-multilib  10.3.0-12
ii  gcc-11-multilib  11.2.0-10
ii  gcc-8-multilib   8.4.0-6
ii  linux-libc-dev   5.14.16-1

gcc-multilib recommends no packages.

gcc-multilib suggests no packages.

Bug#999582: ucf: Wrong code in ucf

[Vincent Danjean]

Package: ucf
Version: 3.0043
Severity: important

  Hi,

  While installing a package, I see:
==
Setting up samba-common (2:4.13.13+dfsg-1~deb11u2) ...
/usr/bin/ucf: 444: [: missing ]
grep: ]: No such file or directory
==
  Looking at ucf script, there is at line 444:
==
   if [ echo "$divert_line" | grep "^local" ]; then
==
  This is clearly wrong.

  I do not know what is tested here, but the line should
be rewriten with something like
   if echo "$divert_line" | grep sq "^local"; then
or
   if [ "$(echo "$divert_line" | grep "^local")" ]; then
or ...

  I put the important severity as I do not know the real
implication of this bug (LOCAL diversion ignored?).
Feel free to downgrade if there are no consequence for
local systems

  Regards,
Vincent


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ucf depends on:
ii  coreutils   8.32-4.1
ii  debconf 1.5.79
ii  sensible-utils  0.0.17

ucf recommends no packages.

ucf suggests no packages.

-- debconf information:
  ucf/title:
* ucf/show_diff:
* ucf/changeprompt: install_new
* ucf/conflicts_found:
* ucf/changeprompt_threeway: merge_threeway

Bug#993876: Crash after recent glibc update

[Vincent Danjean]

Package: aide
Version: 0.17.3-4+b3
Followup-For: Bug #993876

  Installing the 0.17.3-4+b3 version does not help.
Here is the backtrace (with the corresponding -dbgsym
package) that is slightly different.

  I do not know if this is relevant, but I'm using
sssd (with an ldap provider) to manage the users
on this machine.

  Regards
Vincent

# gdb --args /usr/bin/aide -c /etc/aide/aide.conf --init
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/aide...
Reading symbols from 
/usr/lib/debug/.build-id/28/7549582b1c7ee837b4b8a5e633797a5f0f1af3.debug...
(gdb) r
Starting program: /usr/bin/aide -c /etc/aide/aide.conf --init
[Detaching after fork from child process 6625]
[Detaching after fork from child process 6658]
[Detaching after fork from child process 6685]
[Detaching after fork from child process 6687]
[Detaching after fork from child process 6689]
[Detaching after fork from child process 6692]
[Detaching after fork from child process 6693]
[Detaching after fork from child process 6694]
[Detaching after fork from child process 6695]
[Detaching after fork from child process 6696]
[Detaching after fork from child process 6697]
[Detaching after fork from child process 10754]
[Detaching after fork from child process 10755]
[Detaching after fork from child process 10756]
[Detaching after fork from child process 10757]
aide: dl-call-libc-early-init.c:37: _dl_call_libc_early_init: Assertion `sym != 
NULL' failed.

Program received signal SIGABRT, Aborted.
0x0049e5a1 in raise ()
(gdb) bt
#0  0x0049e5a1 in raise ()
#1  0x004012a5 in abort ()
#2  0x0040118e in __assert_fail_base.cold ()
#3  0x00499772 in __assert_fail ()
#4  0x00550b5b in _dl_call_libc_early_init ()
#5  0x0054e1bf in dl_open_worker ()
#6  0x00509360 in _dl_catch_exception ()
#7  0x0054d8b3 in _dl_open ()
#8  0x00507ff2 in do_dlopen ()
#9  0x00509360 in _dl_catch_exception ()
#10 0x0050941f in _dl_catch_error ()
#11 0x00508037 in dlerror_run ()
#12 0x005084d6 in __libc_dlopen_mode ()
#13 0x00501ed6 in __nss_lookup_function ()
#14 0x00501fac in __nss_lookup ()
#15 0x004f2e4b in getpwuid_r ()
#16 0x004f2633 in getpwuid ()
#17 0x00479c8c in __acl_to_any_text ()
#18 0x00415501 in acl2line (line=line@entry=0x1c45fb0) at 
../src/do_md.c:465
#19 0x00417166 in get_file_attrs (filename=filename@entry=0x1c462b0 
"/media/bernard", attr=273806774206, fs=fs@entry=0x7fffe310, 
dry_run=dry_run@entry=false) at ../src/gen_list.c:608
#20 0x0041158d in db_readline_disk (dry_run=dry_run@entry=false) at 
../src/db_disk.c:239
#21 0x00417425 in populate_tree (tree=0x601a20, 
dry_run=dry_run@entry=false) at ../src/gen_list.c:694
#22 0x0040281f in main (argc=4, argv=0x7fffe5f8) at 
../src/aide.c:663
(gdb) 



-- System Information:
Debian Release: 11.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing-debug'), (500, 'stable-updates'), 
(500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-updates'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

aide depends on no packages.

Versions of packages aide recommends:
ii  aide-common  0.17.3-4

Versions of packages aide suggests:
pn  figlet  

-- no debconf information

Bug#993876: Crash after recent glibc update

[Vincent Danjean]

  Hi,

On 30/10/2021 13:30, Marc Haber wrote:

On Fri, Oct 29, 2021 at 11:48:23PM +0200, Vincent Danjean wrote:

Package: aide
Version: 0.17.3-4+b2
Followup-For: Bug #993876

   I also observe the problem on a stable (bullseye) machine.


This should have been fixed by a binNMU at the beginning of october.


  I upgraded the machine one week ago (buster to bullseye). As you can
see in my report, I'm using the 0.17.3-4+b2 version (last version
currently in stable).
  Should I test with the 0.17.3-4+b3 from testing/unstable ?

  Regards,
Vincent


Greetings
Marc

Bug#993876: Crash after recent glibc update

[Vincent Danjean]

Package: aide
Version: 0.17.3-4+b2
Followup-For: Bug #993876

  I also observe the problem on a stable (bullseye) machine.
Aide cannot be used at all (is the 'important' severity enough?)

Here is the backtrace I got (after installing aide-dbgsym):
# gdb --args /usr/bin/aide -c /etc/aide/aide.conf --init
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/aide...
Reading symbols from 
/usr/lib/debug/.build-id/ea/8fe32c919bb19a555ef52a2da196698550752c.debug...
(gdb) r
Starting program: /usr/bin/aide -c /etc/aide/aide.conf --init
[Detaching after fork from child process 25736]
[Detaching after fork from child process 25769]
[Detaching after fork from child process 25796]
[Detaching after fork from child process 25798]
[Detaching after fork from child process 25800]
[Detaching after fork from child process 25803]
[Detaching after fork from child process 25804]
[Detaching after fork from child process 25805]
[Detaching after fork from child process 25806]
[Detaching after fork from child process 25807]
[Detaching after fork from child process 25808]
[Detaching after fork from child process 29842]
[Detaching after fork from child process 29843]
[Detaching after fork from child process 29844]
[Detaching after fork from child process 29845]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x77a77350 in _nss_systemd_is_blocked () from 
/usr/lib/x86_64-linux-gnu/libnss_systemd.so.2
(gdb) bt
#0  0x77a77350 in _nss_systemd_is_blocked () from 
/usr/lib/x86_64-linux-gnu/libnss_systemd.so.2
#1  0x77a78507 in _nss_systemd_getpwuid_r () from 
/usr/lib/x86_64-linux-gnu/libnss_systemd.so.2
#2  0x004f28a3 in getpwuid_r ()
#3  0x004f2253 in getpwuid ()
#4  0x00479aed in __acl_to_any_text ()
#5  0x00415361 in acl2line (line=line@entry=0x1c52b20) at 
../src/do_md.c:465
#6  0x00416ff6 in get_file_attrs (filename=filename@entry=0x1c52e20 
"/media/bernard", attr=273806774206, fs=fs@entry=0x7fffe320, 
dry_run=dry_run@entry=false)
at ../src/gen_list.c:608
#7  0x004113ed in db_readline_disk (dry_run=dry_run@entry=false) at 
../src/db_disk.c:239
#8  0x004172b5 in populate_tree (tree=0x6018e0, 
dry_run=dry_run@entry=false) at ../src/gen_list.c:694
#9  0x0040282f in main (argc=4, argv=0x7fffe5f8) at 
../src/aide.c:663


  Regards
Vincent



-- System Information:
Debian Release: 11.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

aide depends on no packages.

Versions of packages aide recommends:
ii  aide-common  0.17.3-4

Versions of packages aide suggests:
pn  figlet  

-- no debconf information

Bug#998005: Regression: bad handling of permission in directory with sticky bit

[Vincent Danjean]

Package: src:linux
Version: 5.14.12-1
Severity: normal

Hi,

One of my users reports me a strange file access problem:
In a directory with sticky bit such as /tmp, the write
permission he can set on one of his (plain) file is ignored.
He cannot allow another user to write in its file (no ACL
are involved).

I dig into this issue and, indeed, I observe this stange
behavior. The sticky bit in directory change file rename
and deletion, ok. But it should not change write access.

I wrote the attached script. I run it on ubuntu live 14,
ubuntu live 20 and on my laptop (sid). The script has been
run in /tmp (sticky bit) and /home/$USER (no sticky bit).
[users and groups have been changed for the runs on the sid
machine]
  Access problems occur in /tmp on ubuntu live 20 and sid,
but not on /home (all systems) nor on ubuntu live 14 in
/tmp (old kernel)

The results are in the attachments.

Here is an extract with one problematic result:
vdanjean@eyak:/tmp$ id -un
vdanjean
vdanjean@eyak:/tmp$ ls -ld .
drwxrwxrwt 368 root root 196608 28 oct.  14:39 .
vdanjean@eyak:/tmp$ ls -l essai 
-rw-rw-rw- 1 cbardel cbardel 4 28 oct.  13:33 essai
vdanjean@eyak:/tmp$ echo ok >> essai
bash: essai: Permission non accordée

With 0666 permission, anybody should be able to write
in the file (even if the containing directory has a
sticky bit)

Do you confirm this is a bug? Do you want I look
for the first kernel in Debian with this regression?

  Regards
Vincent
#!/bin/bash

LC_ALL=C

FILE=essai
OTHER_USER=toto
SHARED_GROUP=ubuntu
PRIVATE_GROUP=toto

display() {
echo "+ $*"
"$@"
}

check() {
display ls -l $FILE
cat $FILE > /dev/null || echo "READ FORBIDEN $1"
echo ok >> $FILE || echo "WRITE FORBIDEN $2"
}

display uname -a
display id
display id $OTHER_USER
display ls -ld $(pwd)
echo "foo" > $FILE

sudo chown $OTHER_USER $FILE
sudo chgrp $SHARED_GROUP $FILE

sudo chmod 660 $FILE
check "" "WHY?"

sudo chmod 666 $FILE
check "" "WHY?"

sudo chmod 606 $FILE
check "OK" "OK"


sudo chgrp $PRIVATE_GROUP $FILE

sudo chmod 660 $FILE
check "OK" "OK"

sudo chmod 666 $FILE
check "" "WHY?"

sudo chmod 606 $FILE
check "" "WHY?"
+ uname -a
Linux ubuntu 4.4.0-142-generic #168~14.04.1-Ubuntu SMP Sat Jan 19 11:26:28 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux
+ id
uid=999(ubuntu) gid=999(ubuntu) 
groups=999(ubuntu),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),124(sambashare)
+ id toto
uid=1000(toto) gid=1000(toto) groups=1000(toto),999(ubuntu)
+ ls -ld /home/ubuntu
drwxr-xr-x 15 ubuntu ubuntu 480 oct.  28 12:01 /home/ubuntu
+ ls -l essai
-rw-rw 1 toto ubuntu 4 oct.  28 12:01 essai
+ ls -l essai
-rw-rw-rw- 1 toto ubuntu 7 oct.  28 12:01 essai
+ ls -l essai
-rwrw- 1 toto ubuntu 10 oct.  28 12:01 essai
cat: essai: Permission denied
READ FORBIDEN OK
/home/ubuntu/test-perms: line 18: essai: Permission denied
WRITE FORBIDEN OK
+ ls -l essai
-rw-rw 1 toto toto 10 oct.  28 12:01 essai
cat: essai: Permission denied
READ FORBIDEN OK
/home/ubuntu/test-perms: line 18: essai: Permission denied
WRITE FORBIDEN OK
+ ls -l essai
-rw-rw-rw- 1 toto toto 10 oct.  28 12:01 essai
+ ls -l essai
-rwrw- 1 toto toto 13 oct.  28 12:01 essai
+ uname -a
Linux ubuntu 4.4.0-142-generic #168~14.04.1-Ubuntu SMP Sat Jan 19 11:26:28 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux
+ id
uid=999(ubuntu) gid=999(ubuntu) 
groups=999(ubuntu),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),124(sambashare)
+ id toto
uid=1000(toto) gid=1000(toto) groups=1000(toto),999(ubuntu)
+ ls -ld /tmp
drwxrwxrwt 4 root root 200 oct.  28 12:01 /tmp
+ ls -l essai
-rw-rw 1 toto ubuntu 4 oct.  28 12:01 essai
+ ls -l essai
-rw-rw-rw- 1 toto ubuntu 7 oct.  28 12:01 essai
+ ls -l essai
-rwrw- 1 toto ubuntu 10 oct.  28 12:01 essai
cat: essai: Permission denied
READ FORBIDEN OK
/home/ubuntu/test-perms: line 18: essai: Permission denied
WRITE FORBIDEN OK
+ ls -l essai
-rw-rw 1 toto toto 10 oct.  28 12:01 essai
cat: essai: Permission denied
READ FORBIDEN OK
/home/ubuntu/test-perms: line 18: essai: Permission denied
WRITE FORBIDEN OK
+ ls -l essai
-rw-rw-rw- 1 toto toto 10 oct.  28 12:01 essai
+ ls -l essai
-rwrw- 1 toto toto 13 oct.  28 12:01 essai
+ uname -a
Linux ubuntu 5.11.0-27-generic #29~20.04.1-Ubuntu SMP Wed Aug 11 15:58:17 UTC 
2021 x86_64 x86_64 x86_64 GNU/Linux
+ id
uid=999(ubuntu) gid=999(ubuntu) 
groupes=999(ubuntu),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),120(lpadmin),132(lxd),133(sambashare)
+ id toto
uid=1000(toto) gid=1000(toto) groupes=1000(toto),999(ubuntu)
+ ls -ld /home/ubuntu
drwxr-xr-x 15 ubuntu ubuntu 440 oct.  28 12:17 /home/ubuntu
+ ls -l essai
-rw-rw 1 toto ubuntu 4 oct.  28 12:18 essai
+ ls -l essai
-rw-rw-rw- 1 toto ubuntu 7 oct.  28 12:18 essai
+ ls -l essai
-rwrw- 1 toto ubuntu 10 oct.  28 12:18 essai
cat: essai: Permission non accordée
READ FORBIDEN OK
/home/ubuntu/test-perms: line 18: essai: Permission denied
WRITE FORBIDEN OK
+ ls -l essai
-rw-rw 1 toto toto 10 oct.  28 12:18 essai
cat: essai: 

Bug#994474: altree bug fixed but autopkgtest causes Segmentation fault (Was: Bug#994474: please update recommends on openblas)

[Vincent Danjean]

On 17/09/2021 19:45, Nilesh Patra wrote:

On Fri, 17 Sept 2021 at 22:48, Vincent Danjean mailto:vdanj...@debian.org>> wrote:
    I cannot push to salsa (yet) because I'm not in the Debian-Med groups
nor in the members of the altree project. I just requested the Debian-Med
group membership on salsa. I'm waiting for approval.


Granted access, welcome.


Thanks.



PS: I made two MR (for master and pristine-tar) if someone wants to 
see/merge
before I gain write access.


I think it is much more cleaner if you push directly.


Done.

  Regards,
Vincent

Bug#994474: altree bug fixed but autopkgtest causes Segmentation fault (Was: Bug#994474: please update recommends on openblas)

[Vincent Danjean]

On 17/09/2021 15:40, Vincent Danjean wrote:

   I built the package locally, installed it and executed the
debian/tests/run-unit-test manually.
   No errors occurred (with gcc from up-to-date unstable, ie
gcc=4:10.2.1-1 and gcc-10=10.3.0-10).

   Did you try with gcc from experimental ?


  I applied debian patches to upstream where I also fixed a missing
include. Then, I generated a new (upstream) version, updated the Debian
package (fixing the watch file) and upload it.
  I cannot push to salsa (yet) because I'm not in the Debian-Med groups
nor in the members of the altree project. I just requested the Debian-Med
group membership on salsa. I'm waiting for approval.

  Andreas: can you check if the missing header fix makes autopkg tests
to succeed?

  Regards,
Vincent

PS: I made two MR (for master and pristine-tar) if someone wants to see/merge
before I gain write access.



   Regards,
     Vincent




autopkgtest [12:08:54]: test run-unit-test: [---
Analyzing file number 1
read done
Starting tree analysis
Starting permutations
/tmp/autopkgtest.BGTBdL/tree/debian/tests/run-unit-test: line 26:   150 
Segmentation fault  altree -i test.res.log -j nb_cas_control.txt -a -t SNP 
-p paup -r 1 --tree-to-analyse 1 -o 1_caco.asso -q qualitative
autopkgtest [12:08:55]: test run-unit-test: ---]
autopkgtest [12:08:55]: test run-unit-test:  - - - - - - - - - - results - - - 
- - - - - - -
run-unit-test    FAIL non-zero exit status 139


I'd love if someone could have a look

  Andreas.

Bug#994474: altree bug fixed but autopkgtest causes Segmentation fault (Was: Bug#994474: please update recommends on openblas)

[Vincent Danjean]

On 17/09/2021 14:15, Andreas Tille wrote:

Control: tags -1 pending

Hi,

On Thu, Sep 16, 2021 at 12:03:44PM +0200, Sébastien Villemot wrote:


altree recommends libopenblas-base, which is a transitional dummy package.
Please replace it by libopenblas0.


this is fixed in Git but when rebuilding (with more recent gcc) I get


  I built the package locally, installed it and executed the
debian/tests/run-unit-test manually.
  No errors occurred (with gcc from up-to-date unstable, ie
gcc=4:10.2.1-1 and gcc-10=10.3.0-10).

  Did you try with gcc from experimental ?

  Regards,
Vincent




autopkgtest [12:08:54]: test run-unit-test: [---
Analyzing file number 1
read done
Starting tree analysis
Starting permutations
/tmp/autopkgtest.BGTBdL/tree/debian/tests/run-unit-test: line 26:   150 
Segmentation fault  altree -i test.res.log -j nb_cas_control.txt -a -t SNP 
-p paup -r 1 --tree-to-analyse 1 -o 1_caco.asso -q qualitative
autopkgtest [12:08:55]: test run-unit-test: ---]
autopkgtest [12:08:55]: test run-unit-test:  - - - - - - - - - - results - - - 
- - - - - - -
run-unit-testFAIL non-zero exit status 139


I'd love if someone could have a look

  Andreas.

Bug#994474: altree bug fixed but autopkgtest causes Segmentation fault (Was: Bug#994474: please update recommends on openblas)

[Vincent Danjean]

  Hi,

On 17/09/2021 14:15, Andreas Tille wrote:

Control: tags -1 pending

Hi,

On Thu, Sep 16, 2021 at 12:03:44PM +0200, Sébastien Villemot wrote:


altree recommends libopenblas-base, which is a transitional dummy package.
Please replace it by libopenblas0.


this is fixed in Git but when rebuilding (with more recent gcc) I get


autopkgtest [12:08:54]: test run-unit-test: [---
Analyzing file number 1
read done
Starting tree analysis
Starting permutations
/tmp/autopkgtest.BGTBdL/tree/debian/tests/run-unit-test: line 26:   150 
Segmentation fault  altree -i test.res.log -j nb_cas_control.txt -a -t SNP 
-p paup -r 1 --tree-to-analyse 1 -o 1_caco.asso -q qualitative
autopkgtest [12:08:55]: test run-unit-test: ---]
autopkgtest [12:08:55]: test run-unit-test:  - - - - - - - - - - results - - - 
- - - - - - -
run-unit-testFAIL non-zero exit status 139


I'd love if someone could have a look


  I will handle it.

  Regards,
Vincent


  Andreas.

Bug#993594: thunderbird: No (official) extension can be installed anymore

[Vincent Danjean]

Package: thunderbird
Version: 1:91.0.2-1
Severity: important

  Hi,

  I just tried thunderbird 91.0.2 from experimental. Once upgraded,
no extension can be installed / upgraded anymore.

  To check that this does not come from my profile/setup, I
installed thunderbird/experimental in a fresh virtual machine.
Then, I tried to install some of the recommended add-ons (from
the thunderbird add-on manager). I got popup with the following
error messages:
"Thunderbird has prevented this site from installing an
unverified add-on"
I tried the following extension (the first proposed):
- Addon Compatibility Check for TB 91
- Thunderbird Conversations
- Quecktext
- Dictionary for recipient
- CardBook

  Regards,
Vincent


-- System Information:
Debian Release: 11.0
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages thunderbird depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libbotan-2-172.17.3+dfsg-3
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libicu69 69.1-2
ii  libjson-c5   0.15-2
ii  libnspr4 2:4.32-1
ii  libnss3  2:3.68-1
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.10.0+really1.8.1-dmo1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.3-1.1
ii  libxrender1  1:0.9.10-1
ii  psmisc   23.4-2
ii  x11-utils7.7+5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
ii  hunspell-fr-classical [hunspell-dictionary]  1:7.0-1
ii  myspell-en-us [myspell-dictionary]   1:3.3.0-4+deb8u1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.6-10
ii  fonts-lyx 2.3.6-1
ii  libgssapi-krb5-2  1.18.3-6

-- no debconf information

Bug#913431: Debian Installer Bullseye RC 2 release

[Vincent Danjean]

  Hi,

On 14/06/2021 23:26, Cyril Brulebois wrote:
> The Debian Installer team[1] is pleased to announce the second
> release candidate of the installer for Debian 11 "Bullseye".
> 
[...]
> Feedback for this release
> =
> 
> We need your help to find bugs and further improve the installer, so
> please try it. Installation images, and everything else you will need
> are available at our web site[3].

  Would someone give a feedback to the (old) patch proposed
in #913431 in order to be able to also use power-of-two units
in the Debian Installer? Is the bug badly assigned?
  I just tested RC2, power-of-two units are still refused
when partitionning a disk with the installer.

  Regards,
Vincent

PS: I'm not subscribed to debian-boot, please CC me if needed.

Bug#989961: picard-tools: Wrong classpath in PicardCommandLine

[Vincent Danjean]

On 17/06/2021 12:23, Andreas Tille wrote:
> On Wed, Jun 16, 2021 at 10:00:25PM +0200, Vincent Danjean wrote:
>>   The package correctly depends on libcommons-math3-java,
>> but /usr/share/java/commons-math3.jar is not added in the classpath
>> in /usr/bin/PicardCommandLine, leading to errors (in some situations)
>> such as:
>> [Tue Jun 15 15:59:20 CEST 2021] picard.analysis.CollectWgsMetrics done. 
>> Elapsed time: 135.31 minutes.
>> Runtime.totalMemory()=6954156032
>> To get help, see 
>> http://broadinstitute.github.io/picard/index.html#GettingHelp
>> ...
> 
> I wonder whether this is a grave issue and should be fixed in testing?

Not all workload are affected, but on the one where the class is needed,
the fix is required.
  PicardCommandLine uses the -cp option, so the CLASSPATH envvar is
ignored. The script must be modified to fix the bug.

  It seems to me that the fix is small and simple, so a freeze exception
for testing might be asked.

  Latter, for unstable, a fix that also add CLASSPATH (if defined) to
the -cp option might be considered.

  Regards,
Vincent


> 
> Kind regards
> 
> Andreas.
> 

Bug#989961: picard-tools: Wrong classpath in PicardCommandLine

[Vincent Danjean]

Package: picard-tools
Version: 2.24.1+dfsg-1
Severity: normal
Tags: patch

  Hi,

  The package correctly depends on libcommons-math3-java,
but /usr/share/java/commons-math3.jar is not added in the classpath
in /usr/bin/PicardCommandLine, leading to errors (in some situations)
such as:
[Tue Jun 15 15:59:20 CEST 2021] picard.analysis.CollectWgsMetrics done. Elapsed 
time: 135.31 minutes.
Runtime.totalMemory()=6954156032
To get help, see http://broadinstitute.github.io/picard/index.html#GettingHelp
Exception in thread "main" java.lang.NoClassDefFoundError: 
org/apache/commons/math3/random/RandomGenerator
at 
picard.analysis.CollectWgsMetrics$WgsMetrics.calculateDerivedFields(CollectWgsMetrics.java:433)
at 
picard.analysis.CollectWgsMetrics$WgsMetrics.(CollectWgsMetrics.java:248)
at 
picard.analysis.CollectWgsMetrics.generateWgsMetrics(CollectWgsMetrics.java:551)
at 
picard.analysis.CollectWgsMetrics.generateWgsMetrics(CollectWgsMetrics.java:591)
at 
picard.analysis.AbstractWgsMetricsCollector.getMetrics(AbstractWgsMetricsCollector.java:175)
at 
picard.analysis.AbstractWgsMetricsCollector.addToMetricsFile(AbstractWgsMetricsCollector.java:132)
at 
picard.analysis.WgsMetricsProcessorImpl.addToMetricsFile(WgsMetricsProcessorImpl.java:127)
at picard.analysis.CollectWgsMetrics.doWork(CollectWgsMetrics.java:494)
at 
picard.cmdline.CommandLineProgram.instanceMain(CommandLineProgram.java:295)
at 
picard.cmdline.PicardCommandLine.instanceMain(PicardCommandLine.java:103)
at picard.cmdline.PicardCommandLine.main(PicardCommandLine.java:113)
Caused by: java.lang.ClassNotFoundException: 
org.apache.commons.math3.random.RandomGenerator
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 11 more

  Adding the jar to the classpath in the script fixes the problem.

  Regards
Vincent

-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages picard-tools depends on:
ii  default-jre [java6-runtime] 2:1.11-72
ii  libpicard-java  2.24.1+dfsg-1
ii  openjdk-11-jre [java6-runtime]  11.0.12+4-1
ii  openjdk-17-jre [java6-runtime]  17~24-1

picard-tools recommends no packages.

picard-tools suggests no packages.

-- no debconf information

Bug#551937: Closing

[Vincent Danjean]

Le 24/04/2021 à 14:47, Salvatore Bonaccorso a écrit :
> Hi Vincent,
> 
> On Tue, Jun 04, 2013 at 10:22:09PM +0200, Vincent Danjean wrote:
>> reopen 551937
>> reassign 551937 src:linux
>> found 551937 3.2.41-2
>> thanks
>>
>> Le 04/06/2013 19:44, Moritz Mühlenhoff a écrit :
>>> We don't have the ressources to reproduce the complete backlog of all older 
>>> kernel
>>> bugs, so we're closing this bug for now. If you can reproduce the bug with 
>>> Debian Wheezy
>>> or a more recent kernel from testing or unstable, please reopen the bug by 
>>> sending
>>> a mail to cont...@bugs.debian.org with the following three commands 
>>> included in the
>>> mail:
>>
>> Soing so as the bug does not seem to be fixed: I can easily reproduce
>> the series of command listed in the bug report.
>> "ip replace" still fails (as "ip add") if the route already exists.
> 
> Is this still a problem with recent kernels?

It seems fixed on buster with backport kernel:

# ip -6 route ls table 1
# ip -6 route replace ::c058:6301 src 2a01:::::1 dev dummy0 table 1
# ip -6 route replace ::c058:6301 src 2a01:::::1 dev dummy0 table 1
# ip -6 route ls table 1
::192.88.99.1 dev dummy0 src 2a01:::::1 metric 1024 pref medium
# uname -a
Linux kooot 5.10.0-0.bpo.3-amd64 #1 SMP Debian 5.10.13-1~bpo10+1 (2021-02-11) 
x86_64 GNU/Linux
# ip -V
ip utility, iproute2-ss190107
#

  Regards,
Vincent

> 
> Regards,
> Salvatore
> 

Bug#983740: gssproxy: Missing default config for nfs clients

[Vincent Danjean]

Package: gssproxy
Version: 0.8.2-1
Severity: normal

  Hi,

  On a server I recently installed, I saw its behavior
was different from older ones wrt to gssproxy and NFS
mounts.
  On this new server, I saw that /etc/gssproxy/99-nfs-client.conf
is missing.

  Looking into git log of the packaging, I see two
commit with the same message:
ef6d35f7: Stop providing NFS server config snippet (Closes: #856965)
83da02b8: Fix #856965 by dropping NFS server config snippet

  The problem is that the second one (83da02b8, the older)
is, in fact, removing the NFS *client* config. Is it really
wanted?

  Regards,
Vincent

PS: about the NFS server config snippet, the config file
is removed from new packages, but it is not removed on
machine on upgrades, even if the file has not been modified.


-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gssproxy depends on:
ii  libc6 2.31-9
ii  libgssapi-krb5-2  1.18.3-4
ii  libgssrpc41.18.3-4
pn  libini-config5
ii  libk5crypto3  1.18.3-4
ii  libkrb5-3 1.18.3-4
ii  libpopt0  1.18-2
pn  libref-array1 
ii  libselinux1   3.1-2+b2
ii  libverto1 0.3.1-1

gssproxy recommends no packages.

gssproxy suggests no packages.

Bug#950518: gssproxy: segfault when debug is enabled

[Vincent Danjean]

  Hi,

  I backported gssproxy/0.8.2-1 (gssproxy/0.8.2-2 is not fully commited in
the git repo) and saw that this bug is still present:

Feb  4 11:01:37 ge132116vm-1 systemd[1]: Starting GSSAPI Proxy Daemon...
Feb  4 11:01:37 ge132116vm-1 gssproxy[1455]: [2021/02/04 10:01:37]: Debug 
Enabled (level: 1)
Feb  4 11:01:37 ge132116vm-1 systemd[1]: Started GSSAPI Proxy Daemon.
Feb  4 11:01:37 ge132116vm-1 gssproxy[1455]: [2021/02/04 10:01:37]: Client 
[2021/02/04 10:01:37]: (/usr/sbin/gssproxy) [2021/02/04 10:01:37]:  connected 
(fd = 10)[2021/02/04 10:01:37]:  (pid = 1456) (uid = 0) (gid = 0)
Feb  4 11:01:37 ge132116vm-1 systemd[1]: gssproxy.service: Main process exited, 
code=killed, status=11/SEGV
Feb  4 11:01:37 ge132116vm-1 kernel: [471673.673095] gssproxy[1456]: segfault 
at 0 ip 7fc521abfe5a sp 7ffe0a035a50 error 4 in 
libselinux.so.1[7fc521ab3000+25000]
Feb  4 11:01:37 ge132116vm-1 kernel: [471673.673103] Code: c7 45 00 16 00 00 00 
e9 df fe ff ff 0f 1f 40 00 bf 01 00 00 00 45 31 f6 e9 4c ff ff ff 0f 1f 00 41 
55 41 54 55 53 48 83 ec 08 <4c> 8b 27 49 8b 3c 24 48 85 ff 74 05 e8 95 91 ff ff 
49 8d 5c 24 08
Feb  4 11:01:37 ge132116vm-1 systemd[1]: gssproxy.service: Failed with result 
'signal'.

# apt-cache policy gssproxy
gssproxy:
  Installé : 0.8.2-1~bpo10+1


Removing the debug line in the config allows gssproxy to start.

  Regards,
Vincent

Bug#979447: ganglia-monitor: init script badly interacting with systemd

[Vincent Danjean]

Package: ganglia-monitor
Version: 3.6.0-7+b2
Severity: important
Tags: patch

  Hi,

  After a long debug session, I realized that an administrator
cannot invoke directly the /etc/init.d/ganglia-monitor if he wants
systemd to be aware of the action.
  For example, gmond was started at boot, but it hungs due to the
reboot of the target machine (probably another bug).
  An admin types:
/etc/init.d/ganglia-monitor restart
  And then gmond have been restarted but systemd thinks the service is down.

Here is a trace illustrating what I say:

root@ge91097-vm1:/etc/ganglia# systemctl status ganglia-monitor
● ganglia-monitor.service
   Loaded: loaded (/etc/init.d/ganglia-monitor; generated)
  Drop-In: /etc/systemd/system/ganglia-monitor.service.d
   └─restart.conf
   Active: active (running) since Wed 2021-01-06 21:29:29 CET; 13s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 7134 ExecStart=/etc/init.d/ganglia-monitor start (code=exited, 
status=0/SUCCESS)
 Main PID: 7138 (gmond)
Tasks: 2 (limit: 4915)
   Memory: 1.8M
   CGroup: /system.slice/ganglia-monitor.service
   └─7138 /usr/sbin/gmond --pid-file /var/run/gmond.pid

janv. 06 21:29:29 ge91097-vm1 systemd[1]: ganglia-monitor.service: Scheduled 
restart job, restart counter is at 1.
janv. 06 21:29:29 ge91097-vm1 systemd[1]: Stopped ganglia-monitor.service.
janv. 06 21:29:29 ge91097-vm1 systemd[1]: Starting ganglia-monitor.service...
janv. 06 21:29:29 ge91097-vm1 ganglia-monitor[7134]: Starting Ganglia Monitor 
Daemon: gmond.
janv. 06 21:29:29 ge91097-vm1 systemd[1]: Started ganglia-monitor.service.
root@ge91097-vm1:/etc/ganglia# systemd-cgls -u  ganglia-monitor.service
Unit ganglia-monitor.service (/system.slice/ganglia-monitor.service):
└─7138 /usr/sbin/gmond --pid-file /var/run/gmond.pid
root@ge91097-vm1:/etc/ganglia# ps axf | grep gmon
 7171 pts/0S+ 0:00  |   \_ grep gmon
 7138 ?Ssl0:00 /usr/sbin/gmond --pid-file /var/run/gmond.pid
root@ge91097-vm1:/etc/ganglia# /etc/init.d/ganglia-monitor restart
Stopping Ganglia Monitor Daemon: gmond.
Starting Ganglia Monitor Daemon: gmond.
root@ge91097-vm1:/etc/ganglia# systemctl status ganglia-monitor
● ganglia-monitor.service
   Loaded: loaded (/etc/init.d/ganglia-monitor; generated)
  Drop-In: /etc/systemd/system/ganglia-monitor.service.d
   └─restart.conf
   Active: activating (auto-restart) since Wed 2021-01-06 21:30:20 CET; 5s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 7134 ExecStart=/etc/init.d/ganglia-monitor start (code=exited, 
status=0/SUCCESS)
  Process: 7176 ExecStop=/etc/init.d/ganglia-monitor stop (code=exited, 
status=0/SUCCESS)
 Main PID: 7138 (code=killed, signal=TERM)
root@ge91097-vm1:/etc/ganglia# systemd-cgls -u  ganglia-monitor.service
Unit ganglia-monitor.service not found.
Failed to list cgroup tree: No such file or directory
root@ge91097-vm1:/etc/ganglia# ps axf | grep gmon
 7189 pts/0S+ 0:00  |   \_ grep gmon
 7179 ?Ssl0:00 /usr/sbin/gmond --pid-file /var/run/gmond.pid

gmond restarted, but systemd is unaware of it.



  The fix is pretty simple: as (nearly all) other init script,
just add the following line at the begining (just after LSB header):
. /lib/lsb/init-functions
It will handle the synchronization with systemd (or other
init systems) for direct script invocation.

  Regards
Vincent

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ganglia-monitor depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libapr1  1.7.0-4
ii  libc62.31-6
pn  libconfuse1  
pn  libconfuse2  
ii  libexpat12.2.10-1
pn  libganglia1  
ii  libpcre3 2:8.39-13
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

ganglia-monitor recommends no packages.

ganglia-monitor suggests no packages.

Bug#961454: dahdi-dkms: Cannot compile using DKMS on kernel 5.4 backport and latter

[Vincent Danjean]

Package: dahdi-dkms
Version: 1:2.11.1.0.20170917~dfsg-7
Followup-For: Bug #961454

  Hi,

  I needed to compile these drivers on the 5.9 kernel in buster-backports.
I used ubuntu patches and I added one more to handle the last compile
problem.
  Results can be seen here:
https://salsa.debian.org/pkg-voip-team/dahdi-linux/-/merge_requests/2

  With a changelog entry (and the disabling of no_firmware_download
patch for my private build), I successfully built the kernel module
in buster.

  Regards
Vincent

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dahdi-dkms depends on:
ii  dkms   2.8.4-1
ii  dpkg-dev   1.20.5
ii  gawk   1:5.0.1+dfsg-1
ii  gcc4:10.2.0-1
ii  libc6-dev  2.31-6
ii  make   4.3-4
ii  wget   1.20.3-1+b3

Versions of packages dahdi-dkms recommends:
pn  dahdi-linux  

dahdi-dkms suggests no packages.

Bug#971278: owfs: new upstream version 3.2p4

[Vincent Danjean]

Le 28/09/2020 à 20:11, Bastian Germann a écrit :
> Source: owfs
> Severity: normal
> 
> Please package the new version 3.2p4 that has python 3 support according
> to https://github.com/owfs/owfs/pull/24.

  I uploaded owfs 3.2p4 to unstable (it is currently in NEW waiting
for approval due to bump in SONAME).
  But CI on salsa shows that the python support is not yet ready
leading to an uninstallable package:
https://salsa.debian.org/debian/owfs/-/jobs/1059798
===
Setting up python3-ow (3.2p4+dfsg1-1+salsaci) ...
  File "/usr/lib/python3/dist-packages/ow/__init__.py", line 346
raise AttributeError, name
^
SyntaxError: invalid syntax
dpkg: error processing package python3-ow (--configure):
 installed python3-ow package post-installation script subprocess returned 
error exit status 1

===


  So, unless there are other patches to apply, I will disable it
again for now.

  Regards,
Vincent

Bug#956251: xscreensaver-demo do not handle correctly domain part of usernames

[Vincent Danjean]

Le 30/09/2020 à 22:06, Jamie Zawinski a écrit :
> The reason remote.c includes @hostname on the XA_SCREENSAVER_ID is to detect 
> the case when "xscreensaver" and "xscreensaver-demo" are running on different 
> hosts, because if they are different hosts, they are likely different file 
> systems for the home directory. Your first patch disables this check. 
> 
> I still don't understand why a user name would have an @ in it in the first 
> place, so I can't comment on the rest.

  When using sssd[1] with different auth providers (ldap, ad, ...),
users (and groups) are suffixed by '@'providerid
  Usernames without qualifiers get the default one when used.

  For example:
cat /etc/sssd/sssd.conf
[sssd]
[...]
domains = nts,example.fr
default_domain_suffix = example.fr
[...]
[domain/example.fr]
id_provider = ad
[... ad config ...]
[domain/nts]
id_provider = ldap
[...ldap config ...]


And then:
$ id user1
uid=157153(us...@example.fr) gid=5153(maingr...@example.fr) 
groupes=5153(maingr...@example.fr),13182(othergr...@example.fr),136315(applicationgr...@example.fr)
$ id user2
id: 'user2': no such user
$ id user2@nts
uid=5000(user2@nts) gid=5000(user2@nts) 
groups=5000(user2@nts),4010(application-access-grp@nts)

So, the '@' in the username comes from the sssd software that is
more and more used in large systems (AD/ldap/...)

This is transparent to most software, even with ssh that already uses
'@' itself. Using my previous example, to log into the system, I can use:
ssh user1@host
ssh us...@example.fr@host
ssh -l user1 host
ssh -l us...@example.fr host
ssh user2@nts@host
ssh -l user2@nts host
but not (user2 is not a user in the default auth provider)
ssh user2@host

  Regards,
Vincent

[1] https://en.wikipedia.org/wiki/System_Security_Services_Daemon

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#970704: tiger: "Don't have required command DIFF" on Linux kernel 5.x

[Vincent Danjean]

Package: tiger
Version: 1:3.2.4~rc1-1
Severity: important
Tags: patch

  Hi,

  Using backported kernels in buster, I've been hit by this bug,
very similar to #785589.
  The workaround is the same (but the numbers to bump) :

  cd /usr/lib/tiger/systems/Linux/
  sudo ln -s 4 5

  And the patch is similar (create the symlink in the package)

  As the config is the same for linux 2, 3, 4 and 5, perhaps
the fix can involve to use the highest available number
less or equal the current kernel major version...
  This would avoid these missing symlink bugs.

  Regards
Vincent

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.9.0-rc4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tiger depends on:
ii  binutils   2.35-3
ii  bsdmainutils   12.1.7
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.31-3
ii  lsb-release11.1.0
ii  net-tools  1.60+git20180626.aebd88e-1
ii  ucf3.0043

Versions of packages tiger recommends:
pn  chkrootkit  
pn  john
ii  postfix [mail-transport-agent]  3.5.6-1
pn  tripwire | aide 

Versions of packages tiger suggests:
ii  lsof   4.93.2+dfsg-1
pn  lynis  

Bug#955488: nat-rtsp-dkms: Does not build with kernel >= 5.3

[Vincent Danjean]

Source: nat-rtsp
Version: 0.7+4.18-0.1
Followup-For: Bug #955488

I've been hit by this bug (trying to use it with the
kernel 5.7.0-0.bpo.2-amd64).
My workaround has been to manually apply the patch from
https://github.com/openwrt/packages/pull/11468

  Regards,
Vincent

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#860200: poti: please make the build reproducible

[Vincent Danjean]

Le 03/09/2020 à 00:58, Chris Lamb a écrit :
> Chris Lamb wrote:
> 
>> Would you consider applying this patch and uploading?
> 
> Friendly ping on this? Seems like there hasn't been any update on this bug in
> 1233 days now (!).

  Thanks for the reminder. I just uploaded a new upstream version that
removed the problematic lines. So, it should be fine.

  Regards,
Vincent

> 
> Regards,
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#963558: firmware-qlogic: Missing qed/qed_init_values_zipped-8.42.2.0.bin

[Vincent Danjean]

Package: firmware-qlogic
Version: 20190717-2
Severity: important

  Hi,

Recent linux kernels (at lease 5.6) requires a new version of the
qlogic firmware. 
qed/qed_init_values_zipped-8.42.2.0.bin can be found in the linux
kernel sources; for example here:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/qed

  Our current workaround is to manually copy this file, but
we would be pleased if you add it into firmware-qlogic

  Regards
Vincent

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

firmware-qlogic depends on no packages.

firmware-qlogic recommends no packages.

Versions of packages firmware-qlogic suggests:
ii  initramfs-tools  0.137

Bug#963185: xsane-common: xsane-startimage.pnm provided in the wrong directory

[Vincent Danjean]

Package: xsane-common
Version: 0.999-8
Severity: normal

#941344 was about the missing xsane-startimage.pnm file.
0.999-8 added back this file in the package, but it put it
in the doc directory whereas xsane looks for it in the
/usr/share/sane/xsane directory (where is was installed before).

I'm not sure where the other images added back in 0.999-8
should also be moved or not (but, at first look, it does not seem
to be related to documentation)

  Regards,
Vincent

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

xsane-common depends on no packages.

Versions of packages xsane-common recommends:
ii  xsane  0.999-8

xsane-common suggests no packages.

-- no debconf information

Bug#959731: debhelper: Please export $HOME as absolute path, not relative

[Vincent Danjean]

Package: debhelper
Version: 13
Followup-For: Bug #959731

  I also have been hit by this bug. My package build a pdf
with LaTeX. pdflatex invoke /usr/bin/mktexpk which invoke
/usr/share/texlive/texmf-dist/web2c/mktexdir

I added some echo at the start of /usr/share/texlive/texmf-dist/web2c/mktexdir
and add "set -x" in /usr/bin/mktexpk. I got:
[...]
++ /usr/share/texlive/texmf-dist/web2c/mktexnam tcrm1000 600 ljfour
EXEC /usr/share/texlive/texmf-dist/web2c/mktexdir 
debian/.debhelper/generated/_source/home/.texlive2020/texmf-var
HOME debian/.debhelper/generated/_source/home
PWD: /tmp/mt8688.tmp /tmp/mt8688.tmp
+ set x 
debian/.debhelper/generated/_source/home/.texlive2020/texmf-var/fonts/pk/ljfour/jknappen/ec/tcrm1000.600pk
 
debian/.debhelper/generated/_source/home/.texlive2020/texmf-var/fonts/tfm/jknappen/ec/tcrm1000.tfm
 
debian/.debhelper/generated/_source/home/.texlive2020/texmf-var/fonts/source/jknappen/ec/tcrm1000.mf
+ shift
[...]
+ test -r 
debian/.debhelper/generated/_source/home/.texlive2020/texmf-var/fonts/pk/ljfour/jknappen/ec/tcrm1000.600pk
+ /usr/share/texlive/texmf-dist/web2c/mktexdir 
debian/.debhelper/generated/_source/home/.texlive2020/texmf-var/fonts/pk/ljfour/jknappen/ec
EXEC /usr/share/texlive/texmf-dist/web2c/mktexdir 
debian/.debhelper/generated/_source/home/.texlive2020/texmf-var/fonts/pk/ljfour/jknappen/ec
HOME debian/.debhelper/generated/_source/home
PWD: /tmp/mt8659.tmp /tmp/mt8659.tmp
+ test '!' -d 
debian/.debhelper/generated/_source/home/.texlive2020/texmf-var/fonts/pk/ljfour/jknappen/ec
+ echo 'mktexpk: /usr/share/texlive/texmf-dist/web2c/mktexdir 
debian/.debhelper/generated/_source/home/.texlive2020/texmf-var/fonts/pk/ljfour/jknappen/ec
 failed.'
mktexpk: /usr/share/texlive/texmf-dist/web2c/mktexdir 
debian/.debhelper/generated/_source/home/.texlive2020/texmf-var/fonts/pk/ljfour/jknappen/ec
 failed.
+ exit 1


Note how /usr/share/texlive/texmf-dist/web2c/mktexdir is
invoked from different current directories
(/tmp/mt8688.tmp, then /tmp/mt8659.tmp)

=> all of this messup pdflatex and the compilation fails.

This bug should really be quickly fixed as it breaks
lots of tools.

For now, I will downgrade my package to debhelper compat 12
as a workaround.

  Regards


-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.8.0-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  dwz  0.13-5
ii  file 1:5.38-4
ii  libdebhelper-perl13
ii  libdpkg-perl 1.19.7
ii  man-db   2.9.1-1
ii  perl 5.30.0-10
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.202001

-- no debconf information

Bug#959635: latex-make: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Vincent Danjean]

Le 11/05/2020 à 14:26, Andreas Tille a écrit :
> On Mon, May 11, 2020 at 01:53:10PM +0200, Vincent Danjean wrote:
>> Le 11/05/2020 à 13:48, Vincent Danjean a écrit :
>>> Le 11/05/2020 à 13:38, Andreas Tille a écrit :
>>>> BTW, I used routine-update on the packaging in salsa[1] and realised
>>>> that the package is using Python2 for no good reason.
>>
>> It should have been fixed in 2.3.0-3
>> "python" is used in upstream script, but a debian patch changes this in 
>> "python3".
>> Did I miss an occurrence ?
> 
> If you mean this patch
> 
> 
> https://salsa.debian.org/debian/latex-make/-/blob/master/debian/patches/python3.patch
>  
> 
> it is what I just pushed some hours ago.

I mean this one :
https://sources.debian.org/patches/latex-make/2.3.0-3/deb_specific__force-python3.patch/

That is probably nearly the same. I uploaded to Debian in January, but I forgot 
to push to salsa :-(
I'm really sorry.

  Regards,
Vincent

> Hope this helps
> 
> Andreas.
> 
> 

Bug#959635: latex-make: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Vincent Danjean]

Le 11/05/2020 à 13:48, Vincent Danjean a écrit :
> Le 11/05/2020 à 13:38, Andreas Tille a écrit :
>> BTW, I used routine-update on the packaging in salsa[1] and realised
>> that the package is using Python2 for no good reason.

It should have been fixed in 2.3.0-3
"python" is used in upstream script, but a debian patch changes this in 
"python3".
Did I miss an occurrence ?

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main




signature.asc
Description: OpenPGP digital signature

Bug#959635: latex-make: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Vincent Danjean]

  Hi,

Le 11/05/2020 à 13:38, Andreas Tille a écrit :
> Hi,
> 
> I tried to track down the issue and called `make -n` in my pbuilder
> chroot.  It seems the issue can be found somewhere here:
> 
> 
> /build/latex-make-2.3.0/examples# texmf/scripts/latex-make/svg2dev.py 
> -L pdftex fig/logo.svg fig/logo.pdftex
> Unable to init server: Could not connect: Connection refused
> Unknown option -z
> Traceback (most recent call last):
>   File "/usr/lib/python3.8/shutil.py", line 788, in move
> os.rename(src, real_dst)
> FileNotFoundError: [Errno 2] No such file or directory: 'fig/logo.pdftex_tex' 
> -> 'fig/logo.pdftex_t'
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "texmf/scripts/latex-make/svg2dev.py", line 41, in 
> main()
>   File "texmf/scripts/latex-make/svg2dev.py", line 36, in main
> create_image(input_filename, output_filename, svg2pdf)
>   File "texmf/scripts/latex-make/svg2dev.py", line 16, in create_image
> shutil.move(n1, n2)
>   File "/usr/lib/python3.8/shutil.py", line 802, in move
> copy_function(src, real_dst)
>   File "/usr/lib/python3.8/shutil.py", line 432, in copy2
> copyfile(src, dst, follow_symlinks=follow_symlinks)
>   File "/usr/lib/python3.8/shutil.py", line 261, in copyfile
> with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
> FileNotFoundError: [Errno 2] No such file or directory: 'fig/logo.pdftex_tex'
> 
> 
> I have no idea what server is tried to connect and whyt this all means
> but may be that's a place to start with further investigation.

  If I recall correctly, inskape is invoked non-interractively to do the
conversion. So it is probably inkscape that changes its options.

> BTW, I used routine-update on the packaging in salsa[1] and realised
> that the package is using Python2 for no good reason.  Astonishing there
> is no according bug but I tried to switch it to Python3 just in case.
> The result above is not different whether using Python2 or Python3.

  The compatibility is here for a long time (for ubuntu compatibility)
but I forget to change it in the Debian package. I will fix all of this.

  Thanks
Vincent

> Hope this helps a bit
> 
>  Andreas.
> 
> 
> [1] https://salsa.debian.org/debian/latex-make
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#959190: gssproxy: Log flooded by gssproxy

[Vincent Danjean]

  Hi,

Le 30/04/2020 à 20:21, Robbie Harwood a écrit :
> Hi Vincent,
> 
> Please see `man gssproxy.conf` for logging options.  You probably want to set 
> debug_level to 0 to disable logging.

  I did not do it because one can read in the manpage:
   debug (boolean)
   Enable debugging to syslog.

   Default: debug = false

   debug_level (integer)
   Detail level at which to log debugging messages. 0 corresponds to no 
logging, while 1 turns on basic debug logging. Level 2 increases verbosity, 
including more detailed credential verification.

   At level 3 and above, KRB5_TRACE output is logged. If KRB5_TRACE was 
already set in the execution environment, trace output is sent to its value 
instead.

   Default: 1 if debug is true, otherwise 0

As neither debug nor debug_level is set in my config, I was
expecting that no debug log was generated, so messages were
error reportings that cannot be prevented.

And indeed, I tried to put "debug_level = 0" in both
gssproxy.conf and 99-nfs-client.conf (while reverting my
ccache:FILE:.. change)

=> no effect (i.e. logs are flooded again)

  Regards,
Vincent

> Thanks,
> --Robbie

Bug#959190: Bug#959186: gssproxy: kerberos credentials not looked into the classical file

[Vincent Danjean]

  Hi,

Le 30/04/2020 à 20:23, Robbie Harwood a écrit :
> Hi Vincent,
> 
> I disagree about "usually", but I have a larger question, which is: why are 
> you using gssproxy if you want the credentials in an easily accessible 
> location?  The entire point of the daemon is privilege separation.

  I'm using gssproxy because I've some (cron jobs) system users
that must access to the NFS. For them, I add a keytab using
client_keytab:/var/lib/gssproxy/clients/%U.keytab
  If I understand correctly, classical (normal, loggued) users
already have their credential and, in this case, gssproxy
should not be used?

  In fact, this is linked to my other bug report
(#959190 that I put in CC) where you just point me to the
fact that I can totally disable the logs.

  My use case is a machine with a kerberized NFS.
Logged users (with kerberos credentials) generates lots of
logs (as told in #959190) unless gssproxy is pointed to
their file credential.
  When gssproxy is complaining, these users still can access
to the NFS (so I suspect that after gssproxy failure, classical
credential retrieval is used).

  With your explanation, I understand now that gssproxy
config should not be changed and was correct (so #959186
can be closed). But it means that, under normal and default
config, gssproxy can generate lots of logs.
  The admin can totally disable the logs as you told me,
but it means that he will not have any information in case
of problems. I will do this for now as I cannot handle
several GB of logs per days when some application are
running, but I would suggest that a way for gssproxy to
limits its logs (rate limit and/or log only the first messages
of similar messages or ...) would be way better.

  Many thanks for your information
  Regards
Vincent

> Thanks,
> --Robbie
> 
> On April 30, 2020 10:48:29 AM EDT, Vincent Danjean  
> wrote:
>> Package: gssproxy
>> Version: 0.8.0-1.1
>> Severity: normal
>>
>>  Hi,
>>
>>  The default configuration file looks for kerberos credentials
>> in ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U but they usually
>> are in ccache:FILE:/tmp/krb5cc_%U
>>  Is this configuration intended? Why? I had to change it, I found
>> the solution on several internet forum where it said that this is
>> an error in the default configuration. I'm not sure if this is the
>> case (an error) or if the default configuration file targets another
>> usage.
>>
>>  Regards
>>Vincent
>>
>> -- System Information:
>> Debian Release: 10.3
>>  APT prefers stable
>> APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
>> 'oldstable-updates'), (500, 'testing'), (500, 'oldstable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/30 CPU cores)
>> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
>> TAINT_UNSIGNED_MODULE
>> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8),
>> LANGUAGE=C.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages gssproxy depends on:
>> ii  libc6 2.28-10
>> ii  libgssapi-krb5-2  1.17-3
>> ii  libgssrpc41.17-3
>> ii  libini-config50.6.1-2
>> ii  libk5crypto3  1.17-3
>> ii  libkrb5-3 1.17-3
>> ii  libpopt0  1.16-12
>> ii  libref-array1 0.6.1-2
>> ii  libselinux1   2.8-1+b1
>> ii  libverto1 0.3.0-2
>>
>> gssproxy recommends no packages.
>>
>> gssproxy suggests no packages.
>>
>> -- Configuration Files:
>> /etc/gssproxy/99-nfs-client.conf changed:
>> [service/nfs-client]
>>  mechs = krb5
>>  cred_store = keytab:/etc/krb5.keytab
>>  cred_store = ccache:FILE:/tmp/krb5cc_%U
>>  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
>>  cred_usage = initiate
>>  allow_any_uid = yes
>>  trusted = yes
>>  euid = 0
>>
>>
>> -- no debconf information


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#959190: gssproxy: Log flooded by gssproxy

[Vincent Danjean]

Package: gssproxy
Version: 0.8.0-1.1
Severity: important

  Hi,

  On a system with kerberos (AD with sssd) and NFS mount,
some applications (long bioinfo applications with data on
the NFS partition) generate lots of logs that fill the
root (or /var/log/) partition.
  To have an idea, in less than 24h, more that 5GB of
logs have been generated. There are all similar to:

Apr 30 14:31:24 ge95142-vm1 gssproxy[6880]: gssproxy[6888]: (OID: { 1 2 840 
113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more 
information, No credentials cache found
[and 300 similar lines for the same *second*]

And I find them tree times: they are logged into
/var/log/syslog, /var/log/daemon.log and /var/log/auth.log.


  You should really provide a way to either limit the
rate of the logs and/or provide an way to avoid logs
(I do not find any).

  Regards,
Vincent


-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/30 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gssproxy depends on:
ii  libc6 2.28-10
ii  libgssapi-krb5-2  1.17-3
ii  libgssrpc41.17-3
ii  libini-config50.6.1-2
ii  libk5crypto3  1.17-3
ii  libkrb5-3 1.17-3
ii  libpopt0  1.16-12
ii  libref-array1 0.6.1-2
ii  libselinux1   2.8-1+b1
ii  libverto1 0.3.0-2

gssproxy recommends no packages.

gssproxy suggests no packages.

-- Configuration Files:
/etc/gssproxy/99-nfs-client.conf changed:
[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/tmp/krb5cc_%U
  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0


-- no debconf information

Bug#959186: gssproxy: kerberos credentials not looked into the classical file

[Vincent Danjean]

Package: gssproxy
Version: 0.8.0-1.1
Severity: normal

  Hi,

  The default configuration file looks for kerberos credentials
in ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U but they usually
are in ccache:FILE:/tmp/krb5cc_%U
  Is this configuration intended? Why? I had to change it, I found
the solution on several internet forum where it said that this is
an error in the default configuration. I'm not sure if this is the
case (an error) or if the default configuration file targets another
usage.

  Regards
Vincent

-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/30 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gssproxy depends on:
ii  libc6 2.28-10
ii  libgssapi-krb5-2  1.17-3
ii  libgssrpc41.17-3
ii  libini-config50.6.1-2
ii  libk5crypto3  1.17-3
ii  libkrb5-3 1.17-3
ii  libpopt0  1.16-12
ii  libref-array1 0.6.1-2
ii  libselinux1   2.8-1+b1
ii  libverto1 0.3.0-2

gssproxy recommends no packages.

gssproxy suggests no packages.

-- Configuration Files:
/etc/gssproxy/99-nfs-client.conf changed:
[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/tmp/krb5cc_%U
  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0


-- no debconf information

Bug#948321: postfix: tls_ca_cert_file not copied to chroot

[Vincent Danjean]

Le 17/04/2020 à 16:58, Scott Kitterman a écrit :
> On Tue, 7 Jan 2020 12:19:48 +0100 Vincent Danjean  wrote:
>>>   I'm not sure what should be done:
>>> - nothing (let the administrator handle the situation as currently)
>>> - add support for tls_ca_cert_file/tls_ca_cert_dir in
>>>   /usr/lib/postfix/configure-instance.sh (as for
>>>   smtp_tls_CApath/smtp_tls_CAfile)
>>>   ok, but you have to handle every situation. And I'm pretty sure that 
> lots
>>>   of other use of ldaps do not need to copy theses files in chroot (because
>>>   ldaps wont be used in chroot process) else this bug would have been fixed
>>>   long before
>>
>>   => this is more difficult: it requires to find all ldap:XXX maps and
>> parse them...
> 
> I don't personally use the LDAP support, so my ability to come up with a 
> solution to the problem and test it is limited.  If you can send me (direct 
> is 
> fine if you don't want it in the bug) a copy of the maps file, I'll see if I 
> can 
> come up with something.

No problem to copy the information in the bug report.

In main.cf, I've:
=
[...]
canonical_maps =
  hash:/etc/postfix/canonical
  ldap:/etc/postfix/canonical-ldap.cf
=

In /etc/postfix/canonical-ldap.cf, I've (with anonymization):
=
debug_level = 1

version = 3
server_host =
ldaps://serv-ad.domain.fr:636
ldaps://serv-ad-rep.domain.fr:636
search_base = cn=Users,dc=domain,dc=fr
query_filter = 
(&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*)(sAMAccountName=%u))
result_attribute = mail

timeout = 10

bind = yes
bind_dn = cn=ldap-connect-user,cn=Users,dc=domain,dc=fr
bind_pw = password

#start_tls = yes
tls_ca_cert_file = /etc/ssl/certs/local-certificate.pem
tls_require_cert = yes

# only do ldap request for local name
domain = machine.domain.fr
=

In my case, I need /etc/ssl/certs/local-certificate.pem to be installed
in the chroot (and recopied when it changes)

But, according to ldap_table(5), you would have to handle
tls_ca_cert_dir, tls_ca_cert_file, tls_cert, and tls_key if used
(and the first is a directory, not a file)

  Regards,
Vincent


> We already manage dynamicmaps.cf via shell in postinst/prerm.  Doing 
> something 
> similar in configure-instance.sh should be possible.

If it is too complex to handle all possible configurations,
a hook in configure-instance.sh to be used by the local admin
would be very convenient.

  Regards,
Vincent

> Scott K
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#956251: xscreensaver-demo do not handle correctly domain part of usernames

[Vincent Danjean]

Package: xscreensaver
Version: 5.42+dfsg1-1
Severity: normal

  Hi,

  I run xscreensaver (with xfce4) on machines that use SSSD
to managed its users. There are several source of authentification
(as allowed by SSSD) but the main one (and default one) is to
authenticate against an AD (windows kind of ldap/kerberos).
  The important thing is that user names (ie logins) are of the
form name@domain

  When launching xscreensaver-demo, I always got the following
message (sorry, its in French):
===
xscreensaver-demo est lancé par l'utilisateur «name@domain» sur la machine 
«myhostname».
Cependant le xscreensaver gérant l'écran «:0.0»
est lancé par l'utilisateur «name»  sur la machine «domain@myhostname».

Comme ce sont des utilisateurs différents, ils ne vont pas lire/écrire
le même fichier «~/.xscreensaver», donc xscreensaver-demo ne fonctionnera
pas correctement.

Vous devez soit relancer xscreensaver-demo en tant que «name», soit relancer
xscreensaver en tant que «name@domain».

Relancer le démon xscreensaver maintenant ?

Annuler / Valider
==
[approximate translation:]
xscreensaver-demo is launched by the «name@domain» user on the «myhostname» 
machine.
However, the xscreensaver managing the screen «:0.0»
is launched by the «name» user on the «domain@myhostname» machine.

As these are two different users, they won't read/write
the same «~/.xscreensaver» file, so xscreensaver-demo won't work
correctly.

You must either restart xscreensaver-demo as «name», or restart
xscreensaver as «name@domain».

Restart xscreensaver daemon now?

Cancel / Validate
==

Using "Annuler" (ie cancel) or "Valider" (validate) leads to the
same effect: I can manipulate the demo options through xscreensaver-demo
in any cases.

  I suspect the message is due to the fact that xscreensaver(-demo?)
stores the login and the machine name under the form login@machine
but fails to correctly parse such string when login contains a '@'
character, as this is the case here.

  Regards,
Vincent

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xscreensaver depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglade2-0  1:2.6.4-2+b1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk2.0-0  2.24.32-3
ii  libice6  2:1.0.9-2
ii  libpam0g 1.3.1-5
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-01.42.4-7~deb10u1
ii  libsm6   2:1.2.3-1
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  libxi6   2:1.7.9-1
ii  libxinerama1 2:1.1.4-2
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxmu6  2:1.1.2-2+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxt6   1:1.1.5-1+b3
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data5.42+dfsg1-1

Versions of packages xscreensaver recommends:
ii  libjpeg-turbo-progs   1:1.5.2-2+b1
ii  perl  5.28.1-6
ii  wamerican [wordlist]  2018.04.16-1
ii  wfrench [wordlist]1.2.4-1

Versions of packages xscreensaver suggests:
ii  firefox-esr [www-browser]  68.4.1esr-1~deb10u1
pn  fortune
ii  gdm3   3.30.2-3
ii  konqueror [www-browser]4:18.12.0-1
ii  lynx [www-browser] 2.8.9rel.1-3
pn  qcam | streamer
ii  w3m [www-browser]  0.5.3-37
pn  xdaliclock 
pn  xfishtank  
pn  xscreensaver-data-extra
pn  xscreensaver-gl
pn  xscreensaver-gl-extra  

-- no debconf information

Bug#942520: buster-pu: package oar/2.5.8-1

[Vincent Danjean]

Le 30/03/2020 à 23:07, Adam D. Barratt a écrit :
> On Fri, 2019-11-08 at 21:55 +, Adam D. Barratt wrote:
>> Control: tags -1 + confirmed
>>
>> On Thu, 2019-10-17 at 15:48 +0200, Vincent Danjean wrote:
>>>   The default behavior of perl Storable::dclone function changed
>>> in buster, setting a default maximum recursion in the structures
>>> [1], [2].
>>>   This change has not been spotted before the release, but now
>>> that buster is released and that big clusters are switching to
>>> buster, this bug has been found (before the release, oar was
>>> tested only on smaller cluster).
>>>   So, we sould like to revert to the old behavior of
>>> Storable::dclone
>>> in the oar package (it is just two variables to set), so that
>>> oar in buster still works on big cluster (> 1000 cores).
>>>
>>
>> Please go ahead.
> 
> Any news on that?

Sorry, I forgot it. The package is ready (and in use in a local repo)
we will upload it today.

  Regards,
Vincent

> Regards,
> 
> Adam
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#842610: digikam lost track of photos when renaming an album

[Vincent Danjean]

  Hi,

Le 06/02/2020 à 13:35, Agustin Martin a écrit :
> Triaging old bug reports. Is this still a problem with current digikam
> (6.4.0 in sid)? I tried some simple renamings with 6.4.0 and seems to work.

  I think that this particular bug can be closed. However, from times to
times, the digikam database become corrupted. But I do not know what
triggers this (renames or other things). I see the corruption when I
remark some images on disk but not displayed in Digikam.
  I keep on my disk these notes to help me to fix the database:

use digikamdb;

Cleanup Comments :
SELECT * FROM ImageComments i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
DELETE i FROM ImageComments i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
Cleanup Copyright :
SELECT * FROM ImageCopyright i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
DELETE i FROM ImageCopyright i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
Cleanup Information :
SELECT * FROM ImageInformation i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
DELETE i FROM ImageInformation i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
Cleanup Metadata :
SELECT * FROM ImageMetadata i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
DELETE i FROM ImageMetadata i LEFT OUTER JOIN Images ON Images.id=i.imageid 
WHERE Images.name IS NULL;
Cleanup Tags :
SELECT * FROM ImageTags i LEFT OUTER JOIN Images ON Images.id=i.imageid WHERE 
Images.name IS NULL;
DELETE i FROM ImageTags i LEFT OUTER JOIN Images ON Images.id=i.imageid WHERE 
Images.name IS NULL;


Images without information :
select CONCAT(relativePath, '/', name) from Images LEFT OUTER JOIN 
ImageInformation on Images.id=ImageInformation.imageid LEFT OUTER JOIN Albums 
on Images.album=Albums.id where ImageInformation.imageid is NULL INTO OUTFILE 
'/var/lib/mysql-files/digikam.log' ;

RESTART:
sudo cat /var/lib/mysql-files/digikam.log | while read file ; do 
f="$HOME/photos/albums/$file"; if [ -f "$f"  ] ; then touch "$f" ; else echo 
"Missing $f" ; fi ; done
sudo cat /var/lib/mysql-files/digikam.log  | sed -e 's,/[^/]*$,,' | sort -u
 In digikam, reload metadata from files in these albums

Check that all info is loaded with
select CONCAT(relativePath, '/', name) from Images LEFT OUTER JOIN 
ImageInformation on Images.id=ImageInformation.imageid LEFT OUTER JOIN Albums 
on Images.album=Albums.id where ImageInformation.creationDate is NULL AND 
status != 3 ;

GOTO RESTART


And, to force film thumbnails regeneration in an album:
delete from UniqueHashes where thumbId in (select thumbId from FilePaths where 
path like "%17_Irlande/%.avi" );
describe Thumbnails ;
delete from Thumbnails where id in (select thumbId as id from FilePaths where 
path like "%17_Irlande/%.avi" );
delete from FilePaths where path like "%17_Irlande/%.avi" ;



That said, I just checked now. No rows have been reported at all
(and I do not run these commands since a long time), so the bugs
can have been fixed.

  Regards,
Vincent


> Regards,
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#950518: gssproxy: segfault when debug is enabled

[Vincent Danjean]

Package: gssproxy
Version: 0.8.0-1.1
Severity: normal

  In one of my machines, debug was enabled in /etc/gssproxy/gssproxy.conf
(so it tells me that, contrary to the message from the daemon, this file
is indeed read, see #950514). It was probably done before the strech->buster
update.
  I saw that, when debug is enabled, gssproxy segfault at start.
Removing the debug option makes gssproxy working.

# cat /etc/gssproxy/gssproxy.conf
[gssproxy]
debug=true
debug_level=2
# tail /var/log/syslog
[...]
Feb  2 23:06:06 ge91098 systemd[1]: Starting LSB: Controls operation of the 
gssproxy daemon...
Feb  2 23:06:06 ge91098 gssproxy[21077]: [2020/02/02 22:06:06]: Debug Enabled 
(level: 2)
Feb  2 23:06:06 ge91098 gssproxy[21077]: [2020/02/02 22:06:06]: Client 
[2020/02/02 22:06:06]: (/usr/sbin/gssproxy) [2020/02/02 22:06:06]:  connected 
(fd = 10)[2020/02/02 22:06:06]:  (pid = 21085) (uid = 0) (gid = 0)
Feb  2 23:06:06 ge91098 kernel: [258173.020117] gssproxy[21085]: segfault at 0 
ip 7fa622cf8e5a sp 7fffe3e72e30 error 4 in 
libselinux.so.1[7fa622cec000+25000]
Feb  2 23:06:06 ge91098 kernel: [258173.020127] Code: c7 45 00 16 00 00 00 e9 
df fe ff ff 0f 1f 40 00 bf 01 00 00 00 45 31 f6 e9 4c ff ff ff 0f 1f 00 41 55 
41 54 55 53 48 83 ec 08 <4c> 8b 27 49 8b 3c 24 48 85 ff 74 05 e8 95 91 ff ff 49 
8d 5c 24 08
Feb  2 23:06:06 ge91098 systemd[1]: gssproxy.service: Succeeded.
# systemctl status gssproxy
● gssproxy.service - LSB: Controls operation of the gssproxy daemon
   Loaded: loaded (/etc/init.d/gssproxy; generated)
  Drop-In: /etc/systemd/system/gssproxy.service.d
   └─restart.conf
   Active: activating (auto-restart) since Sun 2020-02-02 23:53:14 CET; 991ms 
ago
 Docs: man:systemd-sysv-generator(8)
  Process: 21645 ExecStart=/etc/init.d/gssproxy start (code=exited, 
status=0/SUCCESS)
  Process: 21659 ExecStop=/etc/init.d/gssproxy stop (code=exited, 
status=0/SUCCESS)

Note: the drop-In restart.conf file is here to make the service automatically
restart in case of failure: the service is required on my machines.

  Regards,
   Vincent


-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/32 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gssproxy depends on:
ii  libc6 2.28-10
ii  libgssapi-krb5-2  1.17-3
ii  libgssrpc41.17-3
ii  libini-config50.6.1-2
ii  libk5crypto3  1.17-3
ii  libkrb5-3 1.17-3
ii  libpopt0  1.16-12
ii  libref-array1 0.6.1-2
ii  libselinux1   2.8-1+b1
ii  libverto1 0.3.0-2

gssproxy recommends no packages.

gssproxy suggests no packages.

-- no debconf information

Bug#950514: gssproxy: Provided conf file ignored due to bad naming

[Vincent Danjean]

Le 02/02/2020 à 22:38, Vincent Danjean a écrit :
> Package: gssproxy
> Version: 0.8.0-1.1
> Severity: normal
> 
>   The gssproxy package provides a confile as /etc/gssproxy/gssproxy.conf
> However, as printed by the deamon on startup and as said in the manpage,
> this file is ignored:

In fact, this file is not ignored (see my next bug in a few minutes ;-) )
because it is loaded due to the default -c option:
   -c,--config
   Specify a config file to use as the main config file (read before
   the rest of the config directory). The default is to use the file
   /etc/gssproxy/gssproxy.conf. For reference on the config file
   syntax and options, consult the gssproxy.conf(5) manual page.

That said, the message from gssproxy telling this file is ignored
(because it is ignored when reading the configdir) is misleading.
  I do not know how to easily fix this.

> # systemctl status gssproxy
> [...]
> févr. 02 22:27:24 ge95142 gssproxy[31460]: Error when reading config 
> directory: File /etc/gssproxy/gssproxy.conf did not match provided patterns. 
> Skipping.
> [...]
> And, in the manpage:
>-C,--configdir
>Specify a non-default config dir. Files named of the form
>"##-foo.conf" (that is, beginning with two digits and a dash, and
>ending in ".conf") will be read in numeric order from this
>directory, in addition to the config file itself. The default is
>/etc/gssproxy. For reference on the config file syntax and options,
>    consult the gssproxy.conf(5) manual page.

  Regards
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#950514: gssproxy: Provided conf file ignored due to bad naming

[Vincent Danjean]

Package: gssproxy
Version: 0.8.0-1.1
Severity: normal

  The gssproxy package provides a confile as /etc/gssproxy/gssproxy.conf
However, as printed by the deamon on startup and as said in the manpage,
this file is ignored:
# systemctl status gssproxy
[...]
févr. 02 22:27:24 ge95142 gssproxy[31460]: Error when reading config directory: 
File /etc/gssproxy/gssproxy.conf did not match provided patterns. Skipping.
[...]
And, in the manpage:
   -C,--configdir
   Specify a non-default config dir. Files named of the form
   "##-foo.conf" (that is, beginning with two digits and a dash, and
   ending in ".conf") will be read in numeric order from this
   directory, in addition to the config file itself. The default is
   /etc/gssproxy. For reference on the config file syntax and options,
   consult the gssproxy.conf(5) manual page.

So, the conffile should be renamed as something like
/etc/gssproxy/50-gssproxy.conf

The provided conffile is nearly empty (just a section name
but with no directives) but the admin can have modified it.

dpkg-maintscript-helper can help:
https://raphaelhertzog.com/2010/10/14/correctly-renaming-a-conffile-in-debian-package-maintainer-scripts/

  Regards,
Vincent

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.4.0-trunk-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gssproxy depends on:
ii  libc6 2.29-3
ii  libgssapi-krb5-2  1.17-6
ii  libgssrpc41.17-6
pn  libini-config5
ii  libk5crypto3  1.17-6
ii  libkrb5-3 1.17-6
ii  libpopt0  1.16-14
pn  libref-array1 
ii  libselinux1   3.0-1
ii  libverto1 0.3.0-2+b1

gssproxy recommends no packages.

gssproxy suggests no packages.

Bug#950457: linux-image-5.4.0-0.bpo.2-amd64: Regression: mount option not correctly handled

[Vincent Danjean]

Package: src:linux
Version: 5.4.8-1~bpo10+1
Severity: important

  Hi,

  I'm using singularity on kvm Debian machines. After the last upgrade
that installed the linux-image-5.4.0-0.bpo.2-amd64 kernel, I cannot
start any singularity image. The error is:
$ singularity -v -v shell /srv/scratch/atac-20180906-012322.simg
[...]
VERBOSE: Mounting squashfs image: /dev/loop0 -> 
/var/lib/singularity/mnt/container
ERROR  : Failed to mount squashfs image in (read only): Invalid argument
ABORT  : Retval = 255

  Using strace, I investiguate the problem, and find this:
# mount -o ro,loop,offset=31,errors=remount-ro -t squashfs 
/srv/scratch/atac-20180906-012322.simg  /mnt/ 
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing 
codepage or helper program, or other error.
# mount -o ro,loop,offset=31 -t squashfs /srv/scratch/atac-20180906-012322.simg 
 /mnt/
# ls /mnt
[ all file of my singularity image ]

  With the previous installed kernel (5.3.0-0.bpo.2-amd64), the first mount
(with the "errors=remount-ro" option) succeed. And, of course, strace told
me that singularity is using the "errors=remount-ro" option...

  For now, I'm downgrading my kernel and using 5.3.0-0.bpo.2-amd64 as
a workaround.

  Regards,
Vincent

PS: see https://github.com/sylabs/singularity/issues/4801 for
the issue in singularity where it will be fixed (errors=remount-ro
removed). But as I'm still using singularity from strech-backports,
(singularity-container is not in buster and, in any case, I need
to stick to 2.X version for singularity due to the use of datacenters
where 3.X images are not yet supported)

-- Package-specific info: 
** Version: 
Linux version 5.4.0-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.4.8-1~bpo10+1 (2020-01-07) 
 
** Command line: 
BOOT_IMAGE=/boot/vmlinuz-5.4.0-0.bpo.2-amd64 root=/dev/mapper/ge83982--vm1-root 
ro apparmor=0 quiet 
 
** Not tainted 
 
** Kernel log: 
[2.993838] sd 0:0:0:2: Power-on or device reset occurred 
[2.993863] usb 1-1: new high-speed USB device number 2 using ehci-pci 
[2.993864] sd 0:0:0:1: Power-on or device reset occurred 
[2.995633] sd 0:0:0:2: [sdb] 2147483648 512-byte logical blocks: (1.10 
TB/1.00 TiB) 
[2.995634] sd 0:0:0:1: [sda] 209715200 512-byte logical blocks: (107 GB/100 
GiB) 
[2.995746] sd 0:0:0:1: [sda] Write Protect is off 
[2.995749] sd 0:0:0:1: [sda] Mode Sense: 63 00 00 08 
[2.995752] sd 0:0:0:2: [sdb] Write Protect is off 
[2.995755] sd 0:0:0:2: [sdb] Mode Sense: 63 00 00 08 
[2.995879] sd 0:0:0:1: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA 
[2.995884] sd 0:0:0:2: [sdb] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA 
[2.999071] sr 0:0:0:0: Power-on or device reset occurred 
[2.999282] sr 0:0:0:0: [sr0] scsi3-mmc drive: 16x/50x cd/rw xa/form2 cdda 
tray 
[2.999284] cdrom: Uniform CD-ROM driver Revision: 3.20 
[3.031252] sr 0:0:0:0: Attached scsi CD-ROM sr0 
[3.067516]  sda: sda1 sda2 sda3 
[3.070413] sd 0:0:0:1: [sda] Attached SCSI disk 
[3.083294]  sdb: sdb1 sdb2 
[3.086273] sd 0:0:0:2: [sdb] Attached SCSI disk 
[3.156216] usb 1-1: New USB device found, idVendor=0627, idProduct=0001, 
bcdDevice= 0.00 
[3.156219] usb 1-1: New USB device strings: Mfr=1, Product=3, 
SerialNumber=5 
[3.156221] usb 1-1: Product: QEMU USB Tablet 
[3.156223] usb 1-1: Manufacturer: QEMU 
[3.156225] usb 1-1: SerialNumber: 42 
[3.170058] hidraw: raw HID events driver (C) Jiri Kosina 
[3.181006] usbcore: registered new interface driver usbhid 
[3.181006] usbhid: USB HID core driver 
[3.183898] input: QEMU QEMU USB Tablet as 
/devices/pci:00/:00:1d.7/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input4
 
[3.184398] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 
Mouse [QEMU QEMU USB Tablet] on usb-:00:1d.7-1/input0 
[3.335960] 9pnet: Installing 9P2000 support 
[3.364289] random: lvm: uninitialized urandom read (4 bytes read) 
[3.412111] device-mapper: uevent: version 1.0.3 
[3.412335] device-mapper: ioctl: 4.41.0-ioctl (2019-09-16) initialised: 
dm-de...@redhat.com 
[3.414744] random: lvm: uninitialized urandom read (2 bytes read) 
[3.490968] input: ImExPS/2 Generic Explorer Mouse as 
/devices/platform/i8042/serio1/input/input3 
[3.803171] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: 
(null) 
[4.031278] Not activating Mandatory Access Control as /sbin/tomoyo-init 
does not exist. 
[4.789972] pcieport :00:02.6: pciehp: Failed to check link status 
[4.801959] pcieport :00:02.3: pciehp: Failed to check link status 
[5.048843] systemd[1]: Inserted module 'autofs4' 
[5.154338] random: crng init done 
[5.229945] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT 

Bug#948321: postfix: tls_ca_cert_file not copied to chroot

[Vincent Danjean]

  Hi,

Le 07/01/2020 à 11:23, Vincent Danjean a écrit :
> Package: postfix
> Version: 3.4.7-0+deb10u1
> Severity: normal
> 
>   Hi,
> 
>   I'm using a ldaps server for canonization. The cleanup deamon works in 
> chroot
> (default setup) but tls_ca_cert_file (from ldap_table(5) manpage) is not
> copied into the chroot. Manually copying the file allows the cleanup daemon
> to contact and use the ldaps server.
>   Note: tls_ca_cert_dir does not seem to be also handled.

  In fact, I was partially wrong in the following analyze. The situation is 
indeed
not correctly handled, but the situation is different from 
smtp_tls_CApath/smtp_tls_CAfile:
tls_ca_cert_file/tls_ca_cert_dir are setup in config files referenced
by ldap:filename maps (whereas smtp_tls_CApath/smtp_tls_CAfile are
directly in main.cf). So a global handling as smtp_tls_CApath/smtp_tls_CAfile
seems more difficult.

>   I'm not sure what should be done:
> - nothing (let the administrator handle the situation as currently)
> - add support for tls_ca_cert_file/tls_ca_cert_dir in
>   /usr/lib/postfix/configure-instance.sh (as for
>   smtp_tls_CApath/smtp_tls_CAfile)
>   ok, but you have to handle every situation. And I'm pretty sure that lots
>   of other use of ldaps do not need to copy theses files in chroot (because
>   ldaps wont be used in chroot process) else this bug would have been fixed
>   long before

  => this is more difficult: it requires to find all ldap:XXX maps and
parse them...

> - add support for declarative hook(s) to be handled by
>   /usr/lib/postfix/configure-instance.sh:
>   /etc/postfix/to-chroot.lst can be a file of a list of files/dirs to be 
> copied
>   to chroot (or /etc/postfix/to-chroot.d/ for a directory of such files)
>   But what about allowing or not wildcards?
>   What to do about dynamic files (I think of the "openssl rehash" call for
>   CApath) 
> - add support for script hook(s) to be handled by
>   /usr/lib/postfix/configure-instance.sh:
>   /etc/postfix/build-chroot.d/ can be a directory run through run-parts when
>   a chroot is rebuilt
> - ...
> 
>   Regards,
> Vincent

  Regards,
Vincent

> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
> 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, armel, mipsel
> 
> Kernel: Linux 5.4.0-trunk-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
> LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages postfix depends on:
> ii  adduser3.118
> ii  cpio   2.13+dfsg-1
> ii  debconf [debconf-2.0]  1.5.73
> ii  dpkg   1.19.7
> ii  e2fsprogs  1.45.4-1
> ii  libc6  2.29-3
> ii  libdb5.3   5.3.28+dfsg1-0.6
> ii  libicu63   63.2-2
> ii  libsasl2-2 2.1.27+dfsg-1+deb10u1
> ii  libssl1.1  1.1.1d-2
> ii  lsb-base   11.1.0
> ii  netbase5.8
> ii  ssl-cert   1.0.39
> 
> Versions of packages postfix recommends:
> ii  ca-certificates  20190110
> ii  python3  3.7.5-3
> 
> Versions of packages postfix suggests:
> ii  bsd-mailx [mail-reader]8.1.2-0.20180807cvs-1+b1
> ii  dovecot-core [dovecot-common]  1:2.3.7.2-1
> ii  emacs-gtk [mail-reader]1:26.3+1-1
> ii  evolution [mail-reader]3.34.1-2+b1
> ii  kmail [mail-reader]4:19.08.3-1
> ii  libsasl2-modules   2.1.27+dfsg-1+deb10u1
> ii  mailutils [mail-reader]1:3.7-2
> ii  mutt [mail-reader] 1.13.2-1
> pn  postfix-cdb
> ii  postfix-doc3.4.7-2
> ii  postfix-ldap   3.4.7-2
> pn  postfix-lmdb   
> pn  postfix-mysql  
> pn  postfix-pcre   
> pn  postfix-pgsql      
> ii  postfix-sqlite 3.4.7-2
> ii  procmail   3.22-26
> ii  resolvconf 1.81
> ii  thunderbird [mail-reader]  1:60.9.0-1
> pn  ufw
> 
> -- debconf information excluded
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#948321: postfix: tls_ca_cert_file not copied to chroot

[Vincent Danjean]

Package: postfix
Version: 3.4.7-0+deb10u1
Severity: normal

  Hi,

  I'm using a ldaps server for canonization. The cleanup deamon works in chroot
(default setup) but tls_ca_cert_file (from ldap_table(5) manpage) is not
copied into the chroot. Manually copying the file allows the cleanup daemon
to contact and use the ldaps server.
  Note: tls_ca_cert_dir does not seem to be also handled.

  I'm not sure what should be done:
- nothing (let the administrator handle the situation as currently)
- add support for tls_ca_cert_file/tls_ca_cert_dir in
  /usr/lib/postfix/configure-instance.sh (as for
  smtp_tls_CApath/smtp_tls_CAfile)
  ok, but you have to handle every situation. And I'm pretty sure that lots
  of other use of ldaps do not need to copy theses files in chroot (because
  ldaps wont be used in chroot process) else this bug would have been fixed
  long before
- add support for declarative hook(s) to be handled by
  /usr/lib/postfix/configure-instance.sh:
  /etc/postfix/to-chroot.lst can be a file of a list of files/dirs to be copied
  to chroot (or /etc/postfix/to-chroot.d/ for a directory of such files)
  But what about allowing or not wildcards?
  What to do about dynamic files (I think of the "openssl rehash" call for
  CApath) 
- add support for script hook(s) to be handled by
  /usr/lib/postfix/configure-instance.sh:
  /etc/postfix/build-chroot.d/ can be a directory run through run-parts when
  a chroot is rebuilt
- ...

  Regards,
Vincent

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.4.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.13+dfsg-1
ii  debconf [debconf-2.0]  1.5.73
ii  dpkg   1.19.7
ii  e2fsprogs  1.45.4-1
ii  libc6  2.29-3
ii  libdb5.3   5.3.28+dfsg1-0.6
ii  libicu63   63.2-2
ii  libsasl2-2 2.1.27+dfsg-1+deb10u1
ii  libssl1.1  1.1.1d-2
ii  lsb-base   11.1.0
ii  netbase5.8
ii  ssl-cert   1.0.39

Versions of packages postfix recommends:
ii  ca-certificates  20190110
ii  python3  3.7.5-3

Versions of packages postfix suggests:
ii  bsd-mailx [mail-reader]8.1.2-0.20180807cvs-1+b1
ii  dovecot-core [dovecot-common]  1:2.3.7.2-1
ii  emacs-gtk [mail-reader]1:26.3+1-1
ii  evolution [mail-reader]3.34.1-2+b1
ii  kmail [mail-reader]4:19.08.3-1
ii  libsasl2-modules   2.1.27+dfsg-1+deb10u1
ii  mailutils [mail-reader]1:3.7-2
ii  mutt [mail-reader] 1.13.2-1
pn  postfix-cdb
ii  postfix-doc3.4.7-2
ii  postfix-ldap   3.4.7-2
pn  postfix-lmdb   
pn  postfix-mysql  
pn  postfix-pcre   
pn  postfix-pgsql  
ii  postfix-sqlite 3.4.7-2
ii  procmail   3.22-26
ii  resolvconf 1.81
ii  thunderbird [mail-reader]  1:60.9.0-1
pn  ufw

-- debconf information excluded

Bug#946594: Fwd: libguestfs incorrectly detects host CPU architecture

[Vincent Danjean]

[resend to the good (cloned) bug, sorry for the message in the original bug,
it was a mistake]

  Hi,

On Thu, 5 Dec 2019 11:12:56 + "Richard W.M. Jones"  
wrote:
> I believe this is a new bug and nothing much to do with:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775761

  So I just cloned the bug into #946594 in order to manage the bug reported
by Pierre Neyron.

> However about this new bug, what is supposed to happen is that
> common/mlstdutils/guestfs_config.ml is generated by ./configure with
> the correct @host_cpu@ substituted.  If that's not happening then it's
> a build issue on Debian of some kind.

  I closely look at the build system with him. It occurs that :
- the Debian package use an 'out-of-source' build (ie the build is
  *not* done into the source directories)
- Debian applies some patches to archive this
- but the current rules about guestfs_config.ml especially target
  the source directory (whereas ./configure generates it in the
  build directory, as for all other configure generated files)

Easy test :
- remove common/mlstdutils/guestfs_config.ml in the source directory
- build the Debian package (dpkg-buildpackage -us -uc)
  => the build fails with:
ocamlfind ocamlopt -g -annot -safe-string -warn-error CDEFLMPSUVYZX+52-3 -ccopt 
'-g -O2 -fdebug-prefix-map=/home/polaris/danjean/libguestfs/libguestfs=. 
-fstack-protector-strong -Wformat -Werror=format-security -fno-strict-overflow 
-Wno-strict-overflow' -package str,unix -I . -c 
../../../../common/mlstdutils/std_utils.ml -o std_utils.cmx
File "_none_", line 1:
Warning 58: no cmx file was found in path for module Guestfs_config, and its 
interface was not compiled with -opaque

=> the guestfs_config.ml generated in the build directory is not
taken into account.
=> the Debian package is currently using the provided (x86-64)
guestfs_config.ml in the source directory and ignore the generated
one (in the build directory) on all architectures
=> the Debian package is correctly built only on x86-64...

  The root of the problem is in subdir-rules.mk at the root of the
package. I found a fix the seems to work:
=
--- subdir-rules.mk 2019-12-11 15:45:01.274572831 +0100
+++ subdir-rules.mk.fixed   2019-12-11 15:44:23.738419530 +0100
@@ -79,12 +79,12 @@
 guestfs_am_v_jar_ = $(guestfs_am_v_jar_@AM_DEFAULT_V@)
 guestfs_am_v_jar_0 = @echo "  JAR " $@;

-%.cmi: $(srcdir)/%.mli
+%.cmi: %.mli
$(guestfs_am_v_ocamlcmi)$(OCAMLFIND) ocamlc $(OCAMLFLAGS) 
$(OCAMLPACKAGES) -c $< -o $@
-%.cmo: $(srcdir)/%.ml
+%.cmo: %.ml
$(guestfs_am_v_ocamlc)$(OCAMLFIND) ocamlc $(OCAMLFLAGS) 
$(OCAMLPACKAGES) -c $< -o $@
 if HAVE_OCAMLOPT
-%.cmx: $(srcdir)/%.ml
+%.cmx: %.ml
$(guestfs_am_v_ocamlopt)$(OCAMLFIND) ocamlopt $(OCAMLFLAGS) 
$(OCAMLPACKAGES) -c $< -o $@
 endif
=

  The idea is to let "make" to check itself in the build directory and then
in the source directory by not forcing a path and using the VPATH feature
(as for all internal automake rules)

  Looking at the ChangeLog, I saw that the build rules about cmi/cmo/cmx/...
seems tricky, so I would prefer that someone that know ocaml builds checks
my patch.
  In any case, the Debian build is broken.
  As upstream does not seem to support out-of-source build, this problem should
not appear for it. So the fix can go into a debian patch (even if I think that
my patch is a no-op for a 'in-source' build)

  Regards,
Vincent


> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> 
> 
> 

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.h

Bug#775761: libguestfs incorrectly detects host CPU architecture

[Vincent Danjean]

  Hi,

On Thu, 5 Dec 2019 11:12:56 + "Richard W.M. Jones"  
wrote:
> I believe this is a new bug and nothing much to do with:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775761

  So I just cloned the bug into #946594 in order to manage the bug reported
by Pierre Neyron.

> However about this new bug, what is supposed to happen is that
> common/mlstdutils/guestfs_config.ml is generated by ./configure with
> the correct @host_cpu@ substituted.  If that's not happening then it's
> a build issue on Debian of some kind.

  I closely look at the build system with him. It occurs that :
- the Debian package use an 'out-of-source' build (ie the build is
  *not* done into the source directories)
- Debian applies some patches to archive this
- but the current rules about guestfs_config.ml especially target
  the source directory (whereas ./configure generates it in the
  build directory, as for all other configure generated files)

Easy test :
- remove common/mlstdutils/guestfs_config.ml in the source directory
- build the Debian package (dpkg-buildpackage -us -uc)
  => the build fails with:
ocamlfind ocamlopt -g -annot -safe-string -warn-error CDEFLMPSUVYZX+52-3 -ccopt 
'-g -O2 -fdebug-prefix-map=/home/polaris/danjean/libguestfs/libguestfs=. 
-fstack-protector-strong -Wformat -Werror=format-security -fno-strict-overflow 
-Wno-strict-overflow' -package str,unix -I . -c 
../../../../common/mlstdutils/std_utils.ml -o std_utils.cmx
File "_none_", line 1:
Warning 58: no cmx file was found in path for module Guestfs_config, and its 
interface was not compiled with -opaque

=> the guestfs_config.ml generated in the build directory is not
taken into account.
=> the Debian package is currently using the provided (x86-64)
guestfs_config.ml in the source directory and ignore the generated
one (in the build directory) on all architectures
=> the Debian package is correctly built only on x86-64...

  The root of the problem is in subdir-rules.mk at the root of the
package. I found a fix the seems to work:
=
--- subdir-rules.mk 2019-12-11 15:45:01.274572831 +0100
+++ subdir-rules.mk.fixed   2019-12-11 15:44:23.738419530 +0100
@@ -79,12 +79,12 @@
 guestfs_am_v_jar_ = $(guestfs_am_v_jar_@AM_DEFAULT_V@)
 guestfs_am_v_jar_0 = @echo "  JAR " $@;

-%.cmi: $(srcdir)/%.mli
+%.cmi: %.mli
$(guestfs_am_v_ocamlcmi)$(OCAMLFIND) ocamlc $(OCAMLFLAGS) 
$(OCAMLPACKAGES) -c $< -o $@
-%.cmo: $(srcdir)/%.ml
+%.cmo: %.ml
$(guestfs_am_v_ocamlc)$(OCAMLFIND) ocamlc $(OCAMLFLAGS) 
$(OCAMLPACKAGES) -c $< -o $@
 if HAVE_OCAMLOPT
-%.cmx: $(srcdir)/%.ml
+%.cmx: %.ml
$(guestfs_am_v_ocamlopt)$(OCAMLFIND) ocamlopt $(OCAMLFLAGS) 
$(OCAMLPACKAGES) -c $< -o $@
 endif
=

  The idea is to let "make" to check itself in the build directory and then
in the source directory by not forcing a path and using the VPATH feature
(as for all internal automake rules)

  Looking at the ChangeLog, I saw that the build rules about cmi/cmo/cmx/...
seems tricky, so I would prefer that someone that know ocaml builds checks
my patch.
  In any case, the Debian build is broken.
  As upstream does not seem to support out-of-source build, this problem should
not appear for it. So the fix can go into a debian patch (even if I think that
my patch is a no-op for a 'in-source' build)

  Regards,
Vincent


> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> 
> 
> 

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#943683: RM: hgsvn/0.1.8-1.1

[Vincent Danjean]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

  Hi,

  Can you remove this package from unstable ? It is
completly buggy in oldstable (see #907494), not
present in stable and testing, not maintained
upstream anymore and not usable with current
versions of mercurial and subversion (see last
message in #907494).

  Regards,
Vincent

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#942520: buster-pu: package oar/2.5.8-1

[Vincent Danjean]

Control: tags -1 - moreinfo

The package with the fix has been accepted in unstable.
[and the fix itself has been used on some impacted cluster]

  Regards,
Vincent

Le 17/10/2019 à 16:15, Adam D. Barratt a écrit :
> Control: tags -1 + moreinfo
> 
> On 2019-10-17 14:48, Vincent Danjean wrote:
>>   The default behavior of perl Storable::dclone function changed
>> in buster, setting a default maximum recursion in the structures
>> [1], [2].
>>   This change has not been spotted before the release, but now
>> that buster is released and that big clusters are switching to
>> buster, this bug has been found (before the release, oar was
>> tested only on smaller cluster).
>>   So, we sould like to revert to the old behavior of Storable::dclone
>> in the oar package (it is just two variables to set), so that
>> oar in buster still works on big cluster (> 1000 cores).
>>
>>   You can find in attachment the debdiff of our proposal.
>> This would close #942467
> 
> This needs to be resolved in unstable before it can be considered for a 
> stable update. (oar currently has the same version in unstable ansd stable.)
> 
> Regards,
> 
> Adam


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#942520: buster-pu: package oar/2.5.8-1

[Vincent Danjean]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

  Hi,

  The default behavior of perl Storable::dclone function changed
in buster, setting a default maximum recursion in the structures
[1], [2].
  This change has not been spotted before the release, but now
that buster is released and that big clusters are switching to
buster, this bug has been found (before the release, oar was
tested only on smaller cluster).
  So, we sould like to revert to the old behavior of Storable::dclone
in the oar package (it is just two variables to set), so that
oar in buster still works on big cluster (> 1000 cores).

  You can find in attachment the debdiff of our proposal.
This would close #942467

  Regards,
Vincent

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no=912695
[2] https://rt.perl.org/Public/Bug/Display.html?id=133326

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru oar-2.5.8/debian/changelog oar-2.5.8/debian/changelog
--- oar-2.5.8/debian/changelog  2019-01-04 21:06:58.0 +0100
+++ oar-2.5.8/debian/changelog  2019-10-17 15:31:19.0 +0200
@@ -1,3 +1,10 @@
+oar (2.5.8-1+deb10u1) buster; urgency=medium
+
+  * Revert to stretch behavior for Storable::dclone perl function (Closes:
+#942467) 
+
+ -- Vincent Danjean   Thu, 17 Oct 2019 15:31:19 +0200
+
 oar (2.5.8-1) unstable; urgency=medium
 
   [ Pierre Neyron ]
diff -Nru 
oar-2.5.8/debian/patches/00-fix-max-recursion-depth-in-perl-storable.patch 
oar-2.5.8/debian/patches/00-fix-max-recursion-depth-in-perl-storable.patch
--- oar-2.5.8/debian/patches/00-fix-max-recursion-depth-in-perl-storable.patch  
1970-01-01 01:00:00.0 +0100
+++ oar-2.5.8/debian/patches/00-fix-max-recursion-depth-in-perl-storable.patch  
2019-10-17 15:31:19.0 +0200
@@ -0,0 +1,18 @@
+Fix Max. recursion depth with nested structures
+
+Due to a restriction implemented in Perl's Storable module
+distributed in Buster, Storable::dclone prevent recursions that
+were used before by oar.
+Removing here this limitation, going back to the previous behavior.
+--- a/sources/core/common-libs/lib/OAR/Schedulers/ResourceTree.pm
 b/sources/core/common-libs/lib/OAR/Schedulers/ResourceTree.pm
+@@ -7,6 +7,9 @@
+ use Storable qw(dclone);
+ #use Time::HiRes qw(gettimeofday);
+ 
++$Storable::recursion_limit=-1;
++$Storable::recursion_limit_hash=-1;
++
+ 
###
+ #   RESOURCE TREE MANAGEMENT  
#
+ 
###
diff -Nru oar-2.5.8/debian/patches/series oar-2.5.8/debian/patches/series
--- oar-2.5.8/debian/patches/series 2019-01-04 21:06:58.0 +0100
+++ oar-2.5.8/debian/patches/series 2019-10-17 15:31:19.0 +0200
@@ -0,0 +1 @@
+00-fix-max-recursion-depth-in-perl-storable.patch

Bug#942476: r-cran-dt: missing css files and bad path for javascript files

[Vincent Danjean]

Package: r-cran-dt
Version: 0.9+dfsg-1
Severity: normal

  Hi,

  I'm trying to use r-cran-dt to generate a report. The Debian
package has problems (see the script at the end to reproduce
the issue):
- one css file is missing:
  $ Rscript -e "rmarkdown::render('small_test.rmd')"
  [...]
  /usr/bin/pandoc +RTS -K512m -RTS small_test.utf8.md --to html4 --from 
markdown+autolink_bare_uris+tex_math_single_backslash+smart --output 
small_test.html --email-obfuscation none --self-contained --standalone 
--section-divs --template /usr/lib/R/site-library/rmarkdown/rmd/h/default.html 
--highlight-style tango --css style.css --variable 'theme:cerulean' 
--include-in-header /tmp/RtmpDhs6QV/rmarkdown-str692d16ebe87a.html --mathjax 
--variable 
'mathjax-url:https://mathjax.rstudio.com/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML'
 --lua-filter /usr/lib/R/site-library/rmarkdown/rmd/lua/pagebreak.lua 
--lua-filter /usr/lib/R/site-library/rmarkdown/rmd/lua/latex-div.lua 
  pandoc: 
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables/css/jquery.dataTables.extra.css:
 openBinaryFile: does not exist (No such file or directory)
  Erreur : pandoc document conversion failed with error 1
  Exécution arrêtée

  Indeed, jquery.dataTables.extra.css is removed from the Debian r-cran-dt 
package,
  however, according to apt-file and https://pacakages.debian.org,
  no Debian package is providing this file.

  Continuing with
  $ sudo touch 
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables/css/jquery.dataTables.extra.css
  to workaround this problem

- one javascript file is not in the expected path:
  $ Rscript -e "rmarkdown::render('small_test.rmd')"
  [...]
  /usr/bin/pandoc +RTS -K512m -RTS small_test.utf8.md --to html4 --from 
markdown+autolink_bare_uris+tex_math_single_backslash+smart --output 
small_test.html --email-obfuscation none --self-contained --standalone 
--section-divs --template /usr/lib/R/site-library/rmarkdown/rmd/h/default.html 
--highlight-style tango --css style.css --variable 'theme:cerulean' 
--include-in-header /tmp/RtmpI2EroN/rmarkdown-str6bbf3216f5ad.html --mathjax 
--variable 
'mathjax-url:https://mathjax.rstudio.com/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML'
 --lua-filter /usr/lib/R/site-library/rmarkdown/rmd/lua/pagebreak.lua 
--lua-filter /usr/lib/R/site-library/rmarkdown/rmd/lua/latex-div.lua 
  pandoc: 
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables/js/jquery.dataTables.min.js:
 openBinaryFile: does not exist (No such file or directory)
  Erreur : pandoc document conversion failed with error 1
  Exécution arrêtée

  Indeed, the javascript file is in
  
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables/js/jquery.dataTables.min.js
  and not
  /usr/lib/R/site-library/DT/htmlwidgets/lib/datatables/jquery.dataTables.min.js

  Continuing with
  $ sudo ln -s . /usr/lib/R/site-library/DT/htmlwidgets/lib/datatables/js
  to workarround the problem

- another javascript file is still not in the expected place:
  Rscript -e "rmarkdown::render('small_test.rmd')"
  [...]
  /usr/bin/pandoc +RTS -K512m -RTS small_test.utf8.md --to html4 --from 
markdown+autolink_bare_uris+tex_math_single_backslash+smart --output 
small_test.html --email-obfuscation none --self-contained --standalone 
--section-divs --template /usr/lib/R/site-library/rmarkdown/rmd/h/default.html 
--highlight-style tango --css style.css --variable 'theme:cerulean' 
--include-in-header /tmp/RtmpS0d9gK/rmarkdown-str6e161233a5ca.html --mathjax 
--variable 
'mathjax-url:https://mathjax.rstudio.com/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML'
 --lua-filter /usr/lib/R/site-library/rmarkdown/rmd/lua/pagebreak.lua 
--lua-filter /usr/lib/R/site-library/rmarkdown/rmd/lua/latex-div.lua 
  pandoc: 
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions/Buttons/js/jszip.min.js:
 openBinaryFile: does not exist (No such file or directory)
  Erreur : pandoc document conversion failed with error 1
  Exécution arrêtée

  dpkg -S tells me that this file is (on Debian system) in
  libjs-jquery-datatables-extensions: 
/usr/share/javascript/jquery-datatables-extensions/JSZip/jszip.min.js
  (with a copy in 3 others packages on my machine)

  Continuing with
  $ sudo ln -s 
/usr/share/javascript/jquery-datatables-extensions/JSZip/jszip.min.js 
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions/Buttons/js/jszip.min.js
  to workarround the problem

- another javascript file is still not in the expected place:
  Rscript -e "rmarkdown::render('small_test.rmd')"
  [...]
  /usr/bin/pandoc +RTS -K512m -RTS small_test.utf8.md --to html4 --from 
markdown+autolink_bare_uris+tex_math_single_backslash+smart --output 
small_test.html --email-obfuscation none --self-contained --standalone 
--section-divs --template /usr/lib/R/site-library/rmarkdown/rmd/h/default.html 
--highlight-style tango --css style.css --variable 'theme:cerulean' 
--include-in-header /tmp/RtmpMKo2nV/rmarkdown-str6e7f218627e7.html --mathjax 
--variable