Bug#1004349: img2pdf: Some GIF tests need to be disabled for Pillow >= 9.0.0

[Johannes Schauer Marin Rodrigues]

Package: img2pdf
Version: 0.4.2-1
Severity: normal
X-Debbugs-Cc: jo...@debian.org
Control: tag -1 + help

Currently, img2pdf has some of its testsuite disabled because Pillow
9.0.0 will emit all GIF frames after the first as RGB images instead of
palette images.

An easy fix would be to change the behaviour of Pillow such that frames
after the first are again shown as palette images if (and only if) the
palette didn't change.

I started working on a solution but am stuck (the Pillow testsuite
doesn't pass) and need help:

https://github.com/python-pillow/Pillow/pull/5974

Bug#1004348: hurd: FTBFS on hurd-i386 locally

[Svante Signell]

Source: hurd
Version: 0.9.git20211230-5
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

Currently hurd FTBFS on GNU/Hurd due to a problem with the
Makeconf/mkinstalldirs scripts.

>From the build log:
make -C libshouldbeinlibc install
make[3]: Entering directory '/home/.../hurd-0.9.git20211230/build-deb/
libshouldbeinlibc'
mkdir /home
mkdir: cannot create directory ‘/home’: File exists
mkdir /home/.../hurd-0.9.git20211230/debian/tmp/lib
mkdir /home/.../hurd-0.9.git20211230/debian/tmp/lib/i386-gnu
../../Makeconf:307: recipe for target '/home/.../hurd-
0.9.git20211230/debian/tmp/lib/i386-gnu' failed
make[3]: *** [/home/.../hurd-0.9.git20211230/debian/tmp/lib/i386-gnu]
Error 1
make[3]: Leaving directory '/home/.../hurd-0.9.git20211230/build-
deb/libshouldbeinlibc'
../Makefile:280: recipe for target 'libshouldbeinlibc-install' failed
make[2]: *** [libshouldbeinlibc-install] Error 2

On the buildd the build succeeds:
make[3]: Entering directory '/<>/build-
deb/libshouldbeinlibc'
mkdir /<>/debian/tmp/lib
mkdir /<>/debian/tmp/lib/i386-gnu
mkdir /<>/debian/tmp/usr
mkdir /<>/debian/tmp/usr/include
where 
I: NOTICE: Log filtering will replace 'build/hurd-52h0Hx/hurd-
0.9.git20211230' with '<>'

Maybe building hurd in a chroot would also succeed. This has not been
attempted yet.

The attached patch, Makeconf.patch, has been used to successfully build
hurd on GNU/Hurd locally. Alternately one could modify mkinstalldirs
accordingly since MKINSTALLDIRS = $(top_srcdir)/mkinstalldirs, and
replacing mkdir with mkdir -p, as given in mkinstalldirs.patch.

With this patch hurd builds fine too. It might be the preferred
solution.

>From the build log:
make -C libshouldbeinlibc install
make[3]: Entering directory '/home/hurd-0.9.git20211230/build-
deb/libshouldbeinlibc'
mkdir -p /home/.../hurd-0.9.git20211230/debian/tmp/lib
mkdir -p /home/.../hurd-0.9.git20211230/debian/tmp/lib/i386-gnu
mkdir -p /home/.../hurd-0.9.git20211230/debian/tmp/usr
mkdir -p /home/.../hurd-0.9.git20211230/debian/tmp/usr/include

Thanks!






--- a/Makeconf	2022-01-25 10:57:58.0 +0100
+++ b/Makeconf	2022-01-25 10:57:41.0 +0100
@@ -240,7 +240,7 @@
 all: $(install-targets)
 install: $(DESTDIR)$(installationdir) $(addprefix $(DESTDIR)$(installationdir)/,$(install-targets))
 $(DESTDIR)$(installationdir):
-	@$(MKINSTALLDIRS) $@
+	-@$(MKINSTALLDIRS) $@
 $(addprefix $(DESTDIR)$(installationdir)/,$(installable)): $(DESTDIR)$(installationdir)/%: %
 	$(INSTALL_PROGRAM) $(INSTALL-$<-ops) $< $@
 else
@@ -255,7 +255,7 @@
 install-headers: $(DESTDIR)$(includedir)/$(installhdrsubdir) $(addprefix $(DESTDIR)$(includedir)/$(installhdrsubdir)/,$(installhdrs))
 
 $(DESTDIR)$(includedir)/$(installhdrsubdir): $(DESTDIR)$(includedir)
-	@$(MKINSTALLDIRS) $@
+	-@$(MKINSTALLDIRS) $@
 
 # Arrange to have the headers installed locally anytime we build the library.
 # Not quite perfect, but at least it does end up getting done; and once done
@@ -304,7 +304,7 @@
 
 # Making installation directories
 $(addprefix $(DESTDIR),$(installationdirlist)): %:
-	@$(MKINSTALLDIRS) $@
+	-@$(MKINSTALLDIRS) $@
 
 # Building the target
 ifneq ($(makemode),misc)
--- a/mkinstalldirs	2021-12-30 15:16:15.0 +0100
+++ b/mkinstalldirs	2022-01-25 15:41:19.0 +0100
@@ -22,9 +22,9 @@
  esac
 
  if test ! -d "$pathcomp"; then
-echo "mkdir $pathcomp" 1>&2
+echo "mkdir -p $pathcomp" 1>&2
 
-mkdir "$pathcomp" || lasterr=$?
+mkdir -p "$pathcomp" || lasterr=$?
 
 if test ! -d "$pathcomp"; then
   	  errstatus=$lasterr

Bug#990311:

[Jarl Gullberg]

I can also confirm this bug with shim 1.38.

Bug#990913: ausweisapp2: creates config in '~/.config/Unknown Organization'

[Christoph Anton Mitterer]

Hey John.

On Tue, 2022-01-25 at 15:14 +0100, John Paul Adrian Glaubitz wrote:
> Could you check whether this issue still persists with version
> 1.22.3-1 which is
> now in testing and unstable?

I just did and it seems to persist.


Thanks,
Chris.

Bug#1003961: ITP: cwl-upgrader -- Common Workflow Language standalone document upgrader

[Michael R. Crusoe]

On Tue, 18 Jan 2022 18:03:28 +0100 Jonas Smedegaard  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jonas Smedegaard 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>

* Package name : cwl-upgrader
Version : 1.2.2
Upstream Author : Common Workflow Language contributors 


* URL : https://github.com/common-workflow-language/cwl-upgrader
* License : Apache-2.0
Programming Lang: Python
Description : Common Workflow Language standalone document upgrader

cwl-upgrader is a standalone upgrader
for Common Workflow Language documents
from draft-3, v1.0, and v1.1 to v1.2.



This package will be maintained in the collaborative Debian section of
Salsa.



Dear Jonas,

Thank you for your ITP! I'm the upstream maintainer; also of cwltool, 
toil, python-schema-salad. Feel free to add me as a co-maintainer.


If you are open to team maintenance, may I suggest Debian Science?

--
Michael R. Crusoe



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004347: Suggests no longer existing crda

[Michael Biebl]

Package: wireless-regdb
Version: 2021.08.28-1
Severity: normal

The wireless-regdb suggests crda, yet this package has been removed from
the archive:

https://tracker.debian.org/news/1295874/removed-414git201911129856751-1-from-unstable/

wireless-regdb should drop the Suggests accordingly.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

wireless-regdb depends on no packages.

wireless-regdb recommends no packages.

Versions of packages wireless-regdb suggests:
ii  crda  4.14+git20191112.9856751-1

-- no debconf information

Bug#995171: 3.9.2 has new dependencies

[Benda Xu]

I looked upon singularity-3.9.2.  It has several dependencies that will
need coordinated updates of the go packages.

Benda

Bug#990913: ausweisapp2: creates config in '~/.config/Unknown Organization'

[John Paul Adrian Glaubitz]

Hi Christoph!

On 7/11/21 03:01, Christoph Anton Mitterer wrote:
> Since one of the last updates, the program writes it's config into
> '~/.config/Unknown Organization'
> instead of what it used previously (…/AusweisApp2_CE).
> 
> Perhaps that could be reverted or so, because the new one is a bit
> ambigous.

Could you check whether this issue still persists with version 1.22.3-1 which is
now in testing and unstable?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1004345: RFS: ricochet-refresh/3.0.11-1 [ITP] -- Anonymous metadata-resistant instant messaging over tor

[Marco Simonelli]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ricochet-refresh":

* Package name : ricochet-refresh
Version : 3.0.11-1
Upstream Author : Blueprint for Free Speech 


* URL : https://ricochetrefresh.net
* License : Ricochet, tor, public-domain
* Vcs : https://github.com/blueprint-freespeech/ricochet-refresh
Section : contrib/comm

It builds these binary packages:

ricochet-refresh - Anonymous metadata-resistant instant messaging over tor

To access further information about this package, please visit the 
following URL:


https://mentors.debian.net/package/ricochet-refresh/

Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/contrib/r/ricochet-refresh/ricochet-refresh_3.0.11-1.dsc


Changes for the initial release:

ricochet-refresh (3.0.11-1) unstable; urgency=medium
.
* Initial Debian release. (Closes: #1003510)

Regards,

Bug#1004344: buildbot: Fails to load the web interface

[Samuel Thibault]

Package: buildbot
Version: 2.10.1-1
Severity: important

Hello,

Our buildbot instances has the web interface enabled:

c['www'] = dict(port=8080)

But buildbot doesn't want to start:

2022-01-24 20:36:49+0100 [-] adding 834 new builders, removing 0
2022-01-24 20:37:17+0100 [-] adding 441 new schedulers, removing 0
2022-01-24 20:37:34+0100 [-] while starting BuildMaster
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 
1418, in _inlineCallbacks
result = g.send(result)
  File "/usr/lib/python3/dist-packages/buildbot/util/service.py", line 
49, in reconfigServiceWithBuildbotConfig
yield svc.reconfigServiceWithBuildbotConfig(new_config)
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 
1613, in unwindGenerator
return _cancellableInlineCallbacks(gen)
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 
1529, in _cancellableInlineCallbacks
_inlineCallbacks(None, g, status)
---  ---
  File "/usr/lib/python3/dist-packages/buildbot/master.py", line 304, 
in startService
yield self.reconfigServiceWithBuildbotConfig(self.config)
  File "/usr/lib/python3/dist-packages/buildbot/util/service.py", line 
49, in reconfigServiceWithBuildbotConfig
yield svc.reconfigServiceWithBuildbotConfig(new_config)
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 
1418, in _inlineCallbacks
result = g.send(result)
  File "/usr/lib/python3/dist-packages/buildbot/www/service.py", line 
215, in reconfigServiceWithBuildbotConfig
self.setupSite(new_config)
  File "/usr/lib/python3/dist-packages/buildbot/www/service.py", line 
285, in setupSite
raise RuntimeError("could not find buildbot-www; is it installed? 
%s" % (str(info(

The str(info()) part is an addition on our side to know what plugins
were actually detected, and we have: [...] 'www': {}}

so nothing is detected for www. Indeed, looking at the source code in
/usr/lib/python3/dist-packages/buildbot/plugins/db.py that detects
plugins:

def _tree(self):
if self._real_tree is None:
self._real_tree = _NSNode()
for entry in iter_entry_points(self._group):

This is using pkg_resources.iter_entry_points to get the list of python
classes etc. but that reports nothing, for instance in a plain chroot:

# apt install buildbot
# python3 -c "import pkg_resources ; 
print(list(pkg_resources.iter_entry_points('buildbot.www')))"
[]

while /usr/lib/python3/dist-packages/buildbot/www/ is really there. One
thing I noticed is that
/usr/lib/python3/dist-packages/buildbot-2.0.1.post2.egg-info/entry_points.txt
doesn't list anything for buildbot-www.

We had to revert to the manual installation of buildbot, the Debian
package was unusable for us.

Samuel

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

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

Versions of packages buildbot depends on:
ii  adduser   3.118
ii  cdebconf [debconf-2.0]0.261
ii  debconf [debconf-2.0] 1.5.79
ii  dpkg  1.21.1
ii  libc6 2.33-2
ii  libjs-sphinxdoc   4.3.2-1
ii  lsb-base  11.1.0
ii  passwd1:4.8.1-2
pn  python
pn  python-dateutil   
pn  python-jinja2 
pn  python-migrate
pn  python-sqlalchemy 
pn  python-twisted
pn  python-twisted-core   
pn  python-twisted-web
pn  python-twisted-words  
ii  python3   3.9.7-1
pn  python3-alembic   
pn  python3-autobahn  
ii  python3-dateutil  2.8.1-6
pn  python3-future
ii  python3-idna  3.2-2
ii  python3-jinja23.0.1-2
ii  python3-jwt   2.1.0-1
pn  python3-migrate   
ii  python3-openssl   21.0.0-1
ii  python3-pkg-resources 59.6.0-1.2
ii  python3-service-identity  18.1.0-6
pn  python3-sqlalchemy
ii  python3-twisted   20.3.0-7
pn  python3-txaio 
ii  

Bug#1004343: gem2deb: please split off the dh addon to its own binary

[Mattia Rizzolo]

Source: gem2deb
Version: 1.8
Severity: wishlist

Dear maintainer,

I'm proposing you split off the dh_ruby and the other pieces of the
debhelper addon to their own binary package (i.e. dh-ruby ?).

The goal is to make that package having less inflated dependencies (in
particular, not depend on devscripts).

Moving the dh-sequnce-ruby might require test-rebuilding the packages
that are currently using it to make sure they are not depending on
pieces provided by debhelper or so.


Thank you for considering.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1004341: mercurial-common: please add contrib/zsh_completion to d/copyright

[Daniel Shahaf]

Package: mercurial-common
Version: 6.0.1-3
Severity: wishlist
Tags: newcomer

Dear Maintainer,

Please add contrib/zsh_completion's license (lines 19:34) to
debian/copyright.

Thanks,

Daniel

P.S.  I wasn't sure whether this is a wishlist bug (since the license
seems to be compatible with license in the «Files: *» section of
d/copyright) or an RC bug (a violation of the license or of Policy §2.3
point (1), as well as §4.5 and §12.5), so I'm filing this as wishlist and
Cc'ing -legal@ in case the severity should be bumped.

Bug#1004340: pitivi: FTBFS in unstable and testing

[Graham Inggs]

Source: pitivi
Version: 2020.09.2-3
Severity: serious
Tags: ftbfs bookworm sid

Hi Maintainer

Since sometime around January 15, pitivi started to FTBFS in unstable [1].
I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/pitivi.html


Found pkg-config: /usr/bin/pkg-config (0.29.2)
Run-time dependency python-3.9-embed found: YES 3.9
Run-time dependency gstreamer-1.0 found: YES 1.18.5
Run-time dependency cairo found: YES 1.16.0
Run-time dependency py3cairo found: YES 1.20.1
Program getenvvar.py found: YES (/build/pitivi-2020.09.2/getenvvar.py)
WARNING: You should add the boolean check kwarg to the run_command call.
 It currently defaults to false,
 but it will default to true in future releases of meson.
 See also: https://github.com/mesonbuild/meson/issues/9300
Configuring configure.py using configuration
Configuring pitivi using configuration

data/meson.build:9:0: ERROR: Function does not take positional arguments.

A full log can be found at
/build/pitivi-2020.09.2/deb-build/meson-logs/meson-log.txt
make[1]: *** [debian/rules:19: override_dh_auto_configure] Error 1
make[1]: Leaving directory '/build/pitivi-2020.09.2'
make: *** [debian/rules:12: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Bug#1004292: debian-installer:s390x: installer fails to format dasd disc on s390x systems

[Dipak Zope1]

Hi Cyril, 
This is the only fix I have for s390-dasd and we can release the package 
to unstable. This is good for back-porting to bullseye as well. However, I 
am still testing the installer and more bugs/fixes are on their way for 
s390 installer packages. 

I am new to this but I am committed to supporting s390x moving forward. So 
I would like to know how I should ideally move forward with this fix. May 
be through the package update and sponsorship path? 

Thanks,
-Dipak Zope



From:   "Cyril Brulebois" 
To: "Dipak Zope" , 1004...@bugs.debian.org
Date:   24/01/2022 10:32 PM
Subject:[EXTERNAL] Re: Bug#1004292: debian-installer:s390x: 
installer fails to format dasd disc on s390x systems



Hi Dipak,

Dipak Zope  (2022-01-24):
> On s390x machines with dasd disc, the installer fails to format the dasd 

> disc. 
> 
> Logs: 
> Jan 24 12:25:13 main-menu[341]: INFO: Menu item 's390-dasd' selected
> Jan 24 12:25:19 s390-dasd[3224]: dasdfmt:
> Jan 24 12:25:19 main-menu[341]: WARNING **: Configuring 's390-dasd' 
failed with error code 1
> Jan 24 12:25:19 main-menu[341]: WARNING **: Menu item 's390-dasd' 
failed.
> 
> 
> Root cause: 
> The s390-dasd package calls dasdfmt with '-f' option which is obselete
>  long ago. 
> 
> Proposed Fix: 
> s390-dasd / dasd-config.c: line 393:
> Existing line: snprintf (buf, sizeof (buf), "dasdfmt -l LX%04x -b 4096 
-m 1 -f %s -y", channel_device (channel_current->name), dev);
> Proposed line: snprintf (buf, sizeof (buf), "dasdfmt -l LX%04x -b 4096 
-m 1 %s -y", channel_device (channel_current->name), dev);
> 
> 
> This fix is verified. Logs for reference after changes (with additional
> debug statement): 

Thanks for the proposed fix and the verification. Do you have anything
else s390x/dasd related? Or can we commit this fix, release the package
to unstable and consider backporting it to bullseye?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
[attachment "signature.asc" deleted by Dipak Zope1/India/Contr/IBM] 

Bug#1004339: /usr/bin/systemctl: `systemctl start --user --wait` fails with "Failed to connect to bus: No such file or directory"

[Adam Dinwoodie]

Package: systemd
Version: 250.3-1
Severity: normal
File: /usr/bin/systemctl

Dear Maintainer,

According to the systemctl.1 man page, it should be possible to specify
`--wait` to systemctl commands that will start units, to have the
systemctl command block until the units terminate again.  This seems to
work as expected for system units, but not for user units.

The attached short script provides a simple test case: given appropriate
ssh configuration, when run with `sudo bash test.sh` it will create a
new user called "test" with a simple example service template unit, then
log in through using ssh to start that unit twice, once without
`--wait`, and once with.  Expected behaviour is for this script to
start both unit instances, with the second one sleeping before the
script finishes.  Actual behaviour is that the first unit starts as
expected, but the second unit is never started, and the attempt gives a
return code of 1 and the following error printed to the terminal:

Failed to connect to bus: No such file or directory

As I say, the `--wait` function works as expected for system units; it's
only with user units that it seems to fail.

Kind regards,

Adam

-- Package-specific info:

-- System Information:
Debian Release: 11.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-10-cloud-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-10
ii  libapparmor1 2.13.6-10
ii  libaudit11:3.0-2
ii  libblkid12.36.1-8
ii  libc62.33-3
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.18-4
ii  libcryptsetup12  2:2.4.3-1
ii  libfdisk12.36.1-8
ii  libgcrypt20  1.9.4-5
ii  libgnutls30  3.7.2-5
ii  libgpg-error01.38-2
ii  libip4tc21.8.7-1
ii  libkmod2 28-1
ii  liblz4-1 1.9.3-2
ii  liblzma5 5.2.5-2
ii  libmount12.36.1-8
ii  libpam0g 1.4.0-9+deb11u1
ii  libseccomp2  2.5.1-1+deb11u1
ii  libselinux1  3.1-3
ii  libsystemd0  250.3-1
ii  libzstd1 1.4.8+dfsg-2.1
ii  mount2.36.1-8
ii  util-linux   2.36.1-8

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.12.20-2
ii  systemd-timesyncd [time-daemon]  250.3-1

Versions of packages systemd suggests:
ii  libfido2-11.6.0-2
pn  libtss2-esys-3.0.2-0  
pn  libtss2-mu0   
pn  libtss2-rc0   
pn  policykit-1   
pn  systemd-container 

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
pn  libnss-systemd   
ii  libpam-systemd   250.3-1
ii  udev 247.3-6

-- no debconf information
set -eu
useradd test
mkdir -p ~test/.config/systemd/user
cat <<'EOF' >~test/.config/systemd/user/sleep@.service
[Service]
ExecStart=sleep %I
EOF
mkdir -p ~test/.ssh
cp ~/.ssh/id_rsa.pub ~test/.ssh/authorized_keys
chown -R test:test ~test
ssh test@localhost 'systemctl --user start sleep@5.service'
ssh test@localhost 'systemctl --user status sleep@5.service'
ssh test@localhost 'systemctl --user start --wait sleep@6.service' || echo 
"Error: rc=$?"
ssh test@localhost 'systemctl --user status sleep@6.service'

Bug#1004338: node-cached-path-relative: CVE-2021-23518 - prototype pollution

[Neil Williams]

Source: node-cached-path-relative
Version: 1.0.2-3
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for node-cached-path-relative.

CVE-2021-23518[0]:
| The package cached-path-relative before 1.1.0 are vulnerable to
| Prototype Pollution via the cache variable that is set as {} instead
| of Object.create(null) in the cachedPathRelative function, which
| allows access to the parent prototype properties when the object is
| used to create the cached relative path. When using the origin path as
| __proto__, the attribute of the object is accessed instead of a path.
| **Note:** This vulnerability derives from an incomplete fix in
| https://security.snyk.io/vuln/SNYK-JS-CACHEDPATHRELATIVE-72573


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-23518
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23518

Please adjust the affected versions in the BTS as needed.

Note: results from incomplete fix for 
https://security.snyk.io/vuln/SNYK-JS-CACHEDPATHRELATIVE-72573

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-3-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1004337: glade: FTBFS in unstable and testing

[Graham Inggs]

Source: glade
Version: 3.38.2-6
Severity: serious
Tags: ftbfs bookworm sid

Hi Maintainer

Since sometime around January 13, glade started to FTBFS in unstable [1].
I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/glade.html


env[PKG_CONFIG_PATH]:
Called `/usr/bin/pkg-config --variable=targets gdk-3.0` -> 0
x11 broadway wayland
Got pkgconfig variable targets : x11 broadway wayland
Configuring org.gnome.Glade.desktop.in using configuration

../data/meson.build:4:5: ERROR: Function does not take positional arguments.
dh_auto_configure: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8
meson .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr
--sysconfdir=/etc --localstatedir=/var --libdir=lib/x86_64-linux-gnu
-Dauto_features=enabled -Dgtk_doc=true returned exit code 1
make[1]: *** [debian/rules:27: override_dh_auto_configure] Error 25
make[1]: Leaving directory '/build/1st/glade-3.38.2'
make: *** [debian/rules:24: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Bug#1004259: newboat - upcoming rust-rand update.

[Nikos Tsipinakis]

Hi,

On Sun, 23 Jan 2022, at 18:40, Peter Michael Green wrote:
> A debdiff is attatched, do you want to handle the upload after
> rand is updated in unstable or would you like me to NMU it?

I have no preference, since you have the debdiff feel free to NMU it if you're 
doing a mass-upload already.

> rand 0.8 and sufficient related packages to build newsboat
> have been uploaded to experimental if you want to test things
> in advance of the update in unstable.

Thanks! I'll take a look.

-- 
Best Regards,
  Nikos Tsipinakis

Bug#995289: foolscap: status

[Andrius Merkys]

Control: block 995352 by -1

Hello,

I have fixed the autopkgtest for foolscap. Now the package builds and
passes its autopkgtest on sbuild successfully.

There seem to be stochastic build failures, however. Out of ~8 builds I
performed one failed with non-apparent reason.

One remaining blocker is some files being installed into
/usr/lib/python3.10/dist-packages/ while they should instead appear in
/usr/lib/python3/dist-packages/. And test outputs get installed as well.
I assume it should be OK to remove everything except
/usr/lib/python3/dist-packages/foolscap/ from the current package. I
will try that.

Andrius

Bug#1004336: mate-panel: workspace-switcher unusable on side panels because height is too small

[Francesco Potortì]

Package: mate-panel
Version: 1.26.1-2
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 
File: /etc/mateconf/schemas/workspace-switcher.schemas

The workspace switcher unusable on panel with the Right orientation, because 
the rectangles representing the workspaces are far too low (fe pixels high, in 
my case.  

This problem does not exist for panel in the Bottom orientation.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (101, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages mate-panel depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-2
ii  libatk1.0-0  2.36.0-3
ii  libc62.33-2
ii  libcairo21.16.0-5
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.2-1
ii  libgtk-3-0   3.24.31-1
ii  libgtk-layer-shell0  0.6.0-1
ii  libice6  2:1.0.10-1
ii  libmate-desktop-2-17 1.26.0-1
ii  libmate-menu21.26.0-1
ii  libmate-panel-applet-4-1 1.26.1-2
ii  libmateweather1  1.26.0-1
ii  libpango-1.0-0   1.50.3+ds1-4
ii  librda0  0.0.5-1.1
ii  libsm6   2:1.2.3-1
ii  libwayland-client0   1.19.0-2+b1
ii  libwnck-3-0  40.0-2
ii  libx11-6 2:1.7.2-2+b1
ii  libxrandr2   2:1.5.2-1
ii  mate-desktop 1.26.0-1
ii  mate-menus   1.26.0-1
ii  mate-panel-common1.26.1-2
ii  mate-polkit  1.26.0-1

mate-panel recommends no packages.

mate-panel suggests no packages.

-- no debconf information

Bug#1004060: systemd: breaks lightdm / lightdm-gtk-greeter

[Vincent Lefevre]

On 2022-01-25 11:28:14 +0100, Yves-Alexis Perez wrote:
> I guess it is, yes. Could you try without that Xorg configuration, to be sure?
> I'm not really familiar with the NVIDIA driver configuration file (in my case
> I'm using the XRandr configuration using Xfce display profiles) so maybe
> there's indeed something fishy here.

If I comment out the

  Option "metamodes" "DP-3: nvidia-auto-select +0+0, DP-4: nvidia-auto-select 
+0+0"

line, then, based on 2 tests, both the laptop screen and the right
4K monitor are enabled, with the laptop screen on the left and the
right 4K monitor on the right (so, not a mirror mode). The greeter
correctly appears, and when I move the mouse pointer from one
screen to the other one, the greeter switches to where the mouse
pointer goes. So it is working correctly in this case. However,
when I log in then log out, I get the following error in Xorg.0.log
(I had already noticed this issue in the past, and that's probably
why I added an explicit Xorg monitor configuration):

[83.150] (WW) NVIDIA(0): No valid modes for
[83.150] (WW) NVIDIA(0): 
"DFP-3:nvidia-auto-select,DFP-4:nvidia-auto-select,DFP-5:nvidia-auto-select";
[83.150] (WW) NVIDIA(0): removing.
[83.150] (WW) NVIDIA(0): 
[83.150] (WW) NVIDIA(0): Unable to validate any modes; falling back to the 
default mode
[83.150] (WW) NVIDIA(0): "nvidia-auto-select".
[83.150] (WW) NVIDIA(0): 
[83.151] (WW) NVIDIA(0): No valid modes for
[83.151] (WW) NVIDIA(0): 
"DFP-3:nvidia-auto-select,DFP-4:nvidia-auto-select,DFP-5:nvidia-auto-select";
[83.151] (WW) NVIDIA(0): removing.
[83.151] (EE) NVIDIA(0): Unable to use default mode "nvidia-auto-select".
[83.151] (EE) NVIDIA(0): Failing initialization of X screen 0
[83.719] (II) UnloadModule: "nvidia"
[83.719] (II) UnloadSubModule: "wfb"
[83.719] (II) UnloadSubModule: "fb"
[83.719] (EE) Screen(s) found, but none have a usable configuration.
[83.719] (EE) 
Fatal server error:
[83.719] (EE) no screens found(EE) 
[83.719] (EE) 
Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
[83.719] (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
additional information.
[83.719] (EE) 
[83.758] (EE) Server terminated with error (1). Closing log file.

Indeed, the driver cannot handle 3 monitors.

With the mirror mode, if lightdm thinks that it is in a left/right
configuration, perhaps the greeter is displayed on the right side,
while only the left side is visible.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#995242: isc-dhcp-server: omshell returns inconsistent results or segfaults

[Andrea Turbiglio]

I temporarily switched our servers to the source package version of 
isc-dhcp-server (4.4.2) and the same issue doesn't happens, so I assume 
this is a problem with the Debian version of the package.
The servers are now running on Debian 11 without issues (the only 
problematic package in the transition  from debian 10 to debian 11 was 
isc-dhcp-server).


--
__
Andrea Turbiglio
Università degli Studi dell’Insubria
Centro Sistemi Informativi e Comunicazione
Servizio Telecomunicazioni - Gestione Rete Dati di Ateneo

Via Valleggio, 11
22100 - COMO
tel. +39 031 238 9784
fax +39 031 238 9709
web   www.uninsubria.it
mail  andrea.turbig...@uninsubria.it
mail  netw...@uninsubria.it

Bug#1004060: systemd: breaks lightdm / lightdm-gtk-greeter

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2022-01-25 at 11:25 +0100, Vincent Lefevre wrote:
> Something that may be important: in my /etc/X11/xorg.conf file,

I guess it is, yes. Could you try without that Xorg configuration, to be sure?
I'm not really familiar with the NVIDIA driver configuration file (in my case
I'm using the XRandr configuration using Xfce display profiles) so maybe
there's indeed something fishy here.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmHv0L4ACgkQ3rYcyPpX
RFuElggA7o4EnCd71lQfS8F4f25SK/cRz2QlSJ2VvuKUHLHRxAmdlZsCaN6zZg18
N9nXt/3XeNjrFbVh0Ovax0wD1uCazMPDxpVUF6ZZ+azipg3QO+4nPdJFCKohuJ+u
mbHT+qWRLt9paRQV73CV8DKa4Xhhh2pnd7Lj/8RIo1iGdGpMydMXSLL/5NUG6zCA
rImub1t+XGIvMRgQBPvqNg8/kHnl8oiPndVBTwrACbZPppHoxEoLDDFCGrn+vmEC
qg3PIo72i/sN6CsJ3m/76EUCrDtQu9oKSK4JUC9IYgaNTelSs/MMS1zb6NSZKWYU
CLO8YaTu3IxoekTJ+qIcVlxeav2eFQ==
=r9si
-END PGP SIGNATURE-

Bug#946231:

[Nicholas Brown]

https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/97 was just
merged. It brings in support for duktape instead of mozjs.

Bug#1004060: systemd: breaks lightdm / lightdm-gtk-greeter

[Vincent Lefevre]

Something that may be important: in my /etc/X11/xorg.conf file,
I have:

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor"Monitor0"
DefaultDepth24
Option "Stereo" "0"
Option "metamodes" "DP-3: nvidia-auto-select +0+0, DP-4: 
nvidia-auto-select +0+0"
Option "SLI" "Off"
Option "MultiGPU" "Off"
Option "BaseMosaic" "off"
SubSection "Display"
Depth   24
EndSubSection
EndSection

and in the /var/log/Xorg.0.log file:

[23.807] (II) NVIDIA(0): Validated MetaModes:
[23.807] (II) NVIDIA(0): 
"DP-3:nvidia-auto-select+0+0,DP-4:nvidia-auto-select+0+0"
[23.807] (II) NVIDIA(0): Virtual screen size determined to be 3840 x 2160
[23.811] (--) NVIDIA(0): DPI set to (232, 240); computed from "UseEdidDpi" 
X config
[23.811] (--) NVIDIA(0): option
[23.811] (II) NVIDIA: Using 6144.00 MB of virtual memory for indirect memory
[23.811] (II) NVIDIA: access.
[23.843] (II) NVIDIA(0): Setting mode 
"DP-3:nvidia-auto-select+0+0,DP-4:nvidia-auto-select+0+0"

This is what selects the mirror mode for the two monitors.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1004060: systemd: breaks lightdm / lightdm-gtk-greeter

[Vincent Lefevre]

On 2022-01-24 18:52:28 +0100, Vincent Lefevre wrote:
> On 2022-01-24 18:32:43 +0100, Yves-Alexis Perez wrote:
> > out of curiosity, did you try to move the mouse (and bring it “back” to the
> > main screen) and see if the login dialog appears? My main setup also uses a
> > dual screen (docked laptop with an external screen), and I didn't (yet)
> > experienced the issue you describe, but both my screens have pretty similar
> > resolutions (laptop is 1920×1080, external screen is 1920×1200).
> 
> I had tried to move the mouse, but this didn't have any effect. So
> this is rather different than bug 993752 (where moving the mouse
> switches the width of the screen) I had reported in September.

Note that the virtual screen is the 4K one, thus only a part of the
desktop is visible on the laptop screen (there is no scrolling). The
mouse pointer cannot go beyond of the 4 edges (and corners) of this
4K virtual screen.

> > Also are both screens on and visible?

In my latest test, I noticed the following: initially, only the laptop
screen was visible, and it had the login dialog, but a fraction of
second later, it became black also for a fraction of second, then the
screen appeared on both monitors (laptop + left 4K monitor), mirrored,
but without the login dialog and menu.

So I suspect that lightdm detected that a second monitor was connected
*after* the greeter appeared. It handled it, but the greeter was then
no longer visible.

Note also that if I type Alt-F4 to do a shutdown, a confirmation dialog
should appear, but it doesn't. I can still confirm by hitting Enter,
though.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Dirk Kostrewa]

On 25/01/2022 09:16, Chris Hofstaedtler wrote:

Hi,

* Sean Whitton  [220125 00:06]:

On Mon 24 Jan 2022 at 11:33AM +01, Chris Hofstaedtler wrote:


For context, the idea is that /usr/bin/rename should become
src:util-linux' rename implementation.

That seems likely to break a great many scripts, though?

Perhaps we should ship them both under a name other than
/usr/bin/rename, such that people are prompted to update their scripts
to choose one, or create their own symlink?

Then all of this is a completely pointless exercise. Either we break
them, or it is favorable to keeping the way things are:

A very valid way of closing this discussion is saying "our
(Perl) /usr/bin/rename is great, people should use that".

Chris

Both rename programs are around for a long time and have their use 
cases, and apparently, there are users who rely on one or the other.


Say, the bsdutils package provides "rename.ul", and the perl rename 
package provides "rename.pl". Debian's alternatives system could then 
make each of them available as "/usr/bin/rename". If both get installed, 
the user could be prompted to choose a default "rename".


Would this apparently simple solution really create any problems?

Dirk.

Bug#1004091: Starts user services

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2022-01-24 at 18:37 +0100, Yuri D'Elia wrote:
> On Mon, Jan 24 2022, Yves-Alexis Perez wrote:
> > I assume you're talking about systemd user services or something? I don't
> > think there's any specific code in lightdm about starting manually
> > pulseaudio,
> > pipewire or anything, so I don't think there's a way to special cases some
> > thing.
> 
> Yes, the issue is that lightdm starts automatically all systemd's user
> services (anything which is installed in the default.target in
> /usr/lib/systemd/user/) probably because it is creating a full user
> session?

Is there anything else than “a full user session”. I don't think lightdm has
any specific support for user session so it's likely started through other
means.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmHvxY4ACgkQ3rYcyPpX
RFve3wgAvP1lGHhiZH3XRrOe6ZUjFI2K1UiMCSb491XApCTPOTGIEWq9RGlceiW7
HuCMfyElf1SP+/dx10IS+Jf5vlDOMNc/BWKaYDJf11mGNf9lGopCH53XyomA/cmj
huE55P5ECbgNl/BQGOFBet+pL9ielO6K8LR0Tq8bPyeWsTgcATWy9FnVRKXLocF9
gxVA/k3VfZMPtuMM/M5Oy/tOcPYGUhbnhpJAnFHJyU175PdnSJPzAbbfAdfD5YUL
Kac13baOIrIocfP+9Sfk4/H/eAJdvnDPVNtCG6Z57DGLzMDC+L0YgzQh/bU+WLof
LRxhhXCaSezMH55XQQx88DbLlM+LVg==
=MHVh
-END PGP SIGNATURE-

Bug#1004335: ITP: python-tcolorpy -- apply true color for terminal text

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-tcolorpy
  Version : 0.1.1
  Upstream Author : Tsuyoshi Hombashi 
* URL : https://github.com/thombashi/tcolorpy/
* License : Expat
  Programming Lang: Python
  Description : apply true color for terminal text

 tcolopy is a Python library to apply true color for terminal text. It supports
 foreground and background color in addition to styles like "bold", "italic",
 etc.

I intend to maintain it as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmHvwIwRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wqr0wf/UaUCVQG+9UhaEE9qZoI1YoruqjHO3ehg
W9rtiLxuSaOVQQnKe8mBlMSQu/Ivpo9gu/Zg5hAYwo8vKn6foSwX84t/6rXSlYXn
A42Pfc7yrfw9q981T/ko5F8AUeq05Q9fT6P2ZyxZRB9c70zg33AWD4oa5ct8uFOO
kGe7RQE2oSJPUPZGf47T5kpvtxyR2kituM20QAiCrr2ncmMhuWR6Ka4jIW3lJWio
o/Opne3cJFO5AL5ORTDRON+ltvdHCA4mmLzvRWqtotCahlm6XeU9F0osJBnVCtQZ
Y8cNhgn4RtKWyMdiMOzXtQlUoY158UUkOp7tzL84Cze5qxXGudW/mg==
=f2X9
-END PGP SIGNATURE-

Bug#1000435: Matplotlib crashes on mips64el in lines.py

[Yunqiang Su]

On Sat, 22 Jan 2022 18:23:13 +0800 YunQiang Su  wrote:
> On Sat, 22 Jan 2022 17:06:00 +0800 YunQiang Su  wrote:
>> On Tue, 23 Nov 2021 08:08:23 +0100 Ole Streicher  wrote:
>>> Source: matplotlib
>>> Severity: serious
>>> Version: 3.5.0-1
>>> Control: affects -1 yt
>>> Control: affects -1 astropy
>>> 
>>> With the new matplotlib version, I now have crashes with a segmentation 
>>> fault
>>> in at least two of my packages on mips64el, which cause a FTBFS: yt and
>>> astropy. On both packages, the crash happens here:
>>> 
>>> --8<
>>>   File "/usr/lib/python3/dist-packages/matplotlib/lines.py", line 840 in 
>>> draw
>>>   File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
>>> draw_wrapper
>>>   File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 299 in draw
>>>   File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
>>> draw_wrapper
>>>   File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1163 in 
>>> draw
>>>   File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
>>> draw_wrapper
>>>   File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132 in 
>>> _draw_list_compositing_images
>>>   File "/usr/lib/python3/dist-packages/matplotlib/axes/_base.py", line 3082 
>>> in draw
>>>   File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
>>> draw_wrapper
>>>   File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132 in 
>>> _draw_list_compositing_images
>>>   File "/usr/lib/python3/dist-packages/matplotlib/figure.py", line 2803 in 
>>> draw
>>>   File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
>>> draw_wrapper
>>>   File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 73 in 
>>> draw_wrapper
>>>   File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py", 
>>> line 436 in draw
>>> --8<
>>> 
>>> Build log on Astropy: 
>>> https://buildd.debian.org/status/fetch.php?pkg=astropy=mips64el=5.0-1=1637626067=0
>>> 
>>> Build log on yt: 
>>> https://buildd.debian.org/status/fetch.php?pkg=yt=mips64el=4.0.1-3=1637588650=0
>>> 
>>> This happens on both Python 3.9 and 3.10. The I will try to create a 
>>> stacktrace for it.
>>> 
>> 
>> It is due to gcc-11 of mips64el.
>> 
>> -O1, -O2 may generate bad code, while -O0 and -O3 works well.
>> As a workaround: we can:
>> 
>> The attachment is a workaround patch.
>> 
> 
> 
> 
> A better formatted patch with DEB__MAINT_APPEND

Should I NMU this package?

> 
>>> 

Bug#1004333: deb-systemd-helper does not recognize purged package

[Marc Haber]

retitle -1 please consider more debugging in state file handling
severity -1 minor
thanks

Turns out that it was an issue in the test system.

Please, however, consider adding a bit more debugging and error
processing. Here is the patch that I used to debug this. This is clearly
not suitable for the release code, but I think you get the idea

--- /usr/bin/deb-systemd-helper 2021-11-01 15:05:55.0 +0100
+++ /home/mh/deb-systemd-helper 2022-01-25 00:14:53.235498204 +0100
@@ -464,12 +464,17 @@
 
 my $statefile = $mask_link;
 $statefile =~ s,^/etc/systemd/$instance/,$masked_state_dir/,;
+debug "statefile $statefile.";
 
 # Store the fact that we masked this service, so that we can unmask it on
 # installation time. We cannot unconditionally unmask because that would
 # interfere with the user’s decision to mask a service.
-make_path(dirname($statefile));
-open(my $fh, '>>', $statefile);
+debug "dirname statefile ". dirname($statefile);
+system("ls -l ". dirname($statefile));
+if (! -e dirname($statefile)) {
+make_path(dirname($statefile)) or die "cannot make_path: $!";
+}
+open(my $fh, '>>', $statefile) or die "cannot open: $!";
 close($fh);
 }

Retitling and resetting severity.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#995171: need newer release

[Andreas Tille]

Hi Yaroslav,

Am Mon, Jan 24, 2022 at 10:11:21AM -0500 schrieb Yaroslav Halchenko:
> 
> >  " https://github.com/sylabs/singularity/releases \
> > -  (?:.*/)?singularity-(\d[\d\.]*)\.tar\.gz
> > +  (?:.*/)?singularity-ce-(\d[\d\.]*)\.tar\.gz
> 
> cool -- applied

I can't see this in master branch.
 
> I have started to update packaging for 3.9.4+ds1 but got stuck on
> updating the 2nd patch which seems "too involved" for a go-ignorant me.
> Any help would be welcomed.  I have pushed update of source tree etc

To what branch? 

Kind regards

  Andreas.


-- 
http://fam-tille.de

Bug#1004166: strongswan-nm: Creates VPN configs that disable using system CA certificate directories

[Tobias Brunner]

Hi Daniel,

Applying any change to any field in the 
NetworkManager strongswan VPN plugin config will write a text config 
file with the 'certificate=' line.


As I said, I can't reproduce this.  I can change whatever in the GUI, no 
"certificate=" line is added to the config file.


Notice the missing 'certificate=' line.  However, any change made in the 
GUI would restore the certificate= line as show below:


I don't see how.  The GUI checks gtk_file_chooser_get_filename() and 
only if that returns a value != NULL will "certificate" be written to 
the config.  That's why I was asking what the GUI actually displays in 
that file chooser in your case.


According to the reference [1], NULL is returned "if no file is 
selected, or the selected file can't be represented with a local 
filename", I don't think an empty string should be returned.


Alternatively, strongswan should 
assume 'certificate=' indicates the system certificates should be used.


Yes, we could add a check for an empty string, but the setting shouldn't 
be there with an empty string in the first place.


Regards,
Tobias

[1] https://docs.gtk.org/gtk3/method.FileChooser.get_filename.html

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Chris Hofstaedtler]

Hi,

* Sean Whitton  [220125 00:06]:
> On Mon 24 Jan 2022 at 11:33AM +01, Chris Hofstaedtler wrote:
> 
> > For context, the idea is that /usr/bin/rename should become
> > src:util-linux' rename implementation.
> 
> That seems likely to break a great many scripts, though?
> 
> Perhaps we should ship them both under a name other than
> /usr/bin/rename, such that people are prompted to update their scripts
> to choose one, or create their own symlink?

Then all of this is a completely pointless exercise. Either we break
them, or it is favorable to keeping the way things are:

A very valid way of closing this discussion is saying "our
(Perl) /usr/bin/rename is great, people should use that".

Chris