Bug#934284: journal sometimes with x-bit, sometimes without

[Marc Haber]

On Sat, Feb 01, 2020 at 12:50:55PM +0100, Michael Biebl wrote:
> On Sat, 10 Aug 2019 12:37:04 +0200 Marc Haber
>  wrote:
> > Hi Michael,
> > 
> > thanks for your answer.
> > 
> > On Fri, Aug 09, 2019 at 04:16:06PM +0200, Michael Biebl wrote:
> > > I have never seen this behaviour myself on the multitude of systems I
> > > run (laptop, servers, VM, containers) so I don't really have any idea.
> > 
> > How closely are you watching the ACLs on the journal files?
> > 
> 
> Forgot to answer here: I simply checked all systems I have acces to.
> This was a one-time check and includes a couple of PIs, a few VMs,
> containers, a laptop and a server. For some of them, /tmp is on the
> root, ext4 file system. Most of them have tmpfs for /tmp (like in your
> case).

I usually have tmpfs for /tmp, and /run is a tmpfs as well.

> I guess once the x-bit has been set, it sticks? Or did it vanish (and
> reappear again) after some time, which would mean I'd need to
> continuously monitor the file system?

The system is booted, no x bit, then at some time, the x bit appears and
sticks until the machine is rebooted again.

> Btw, does this only affect system.journal or also the files that are
> rotated away? E.g. on one of my PIs this look like this
> 
> > root@raspberrypi:~# ls -l 
> > /run/log/journal/d3670ff77a0bb988a953e7f053a3f4e7/system*
> > -rw-r-+ 1 root systemd-journal 2834432 Jan 24 03:17 
> > /run/log/journal/d3670ff77a0bb988a953e7f053a3f4e7/system@ee9cfeba24044e90a191a267c13840a2-0001-00059cbeac13de5a.journal
> > -rw-r-+ 1 root systemd-journal 2834432 Jan 27 06:17 
> > /run/log/journal/d3670ff77a0bb988a953e7f053a3f4e7/system@ee9cfeba24044e90a191a267c13840a2-063b-00059cd95a64682e.journal
> > -rw-r-+ 1 root systemd-journal 2834432 Jan 30 07:22 
> > /run/log/journal/d3670ff77a0bb988a953e7f053a3f4e7/system@ee9cfeba24044e90a191a267c13840a2-0e28-00059d1837ab38f0.journal
> > -rw-r-+ 1 root systemd-journal 2834432 Feb  1 05:39 
> > /run/log/journal/d3670ff77a0bb988a953e7f053a3f4e7/system@ee9cfeba24044e90a191a267c13840a2-1675-00059d557cd266fa.journal
> > -rw-r-+ 1 root systemd-journal 2834432 Feb  1 12:43 
> > /run/log/journal/d3670ff77a0bb988a953e7f053a3f4e7/system.journal

Rotation is a very good point.

I have one machine that got rebooted on February 2 around 15:00, and my
check script reported the x bit on
run/log/journal/8f018d505adf4ecaad2720811a888b04/system.journal to be
reset after that.

Then, at 22:20, the report came in that the x bit on
run/log/journal/8f018d505adf4ecaad2720811a888b04/system.journal was set.

1 [1/2158]mh@oversway:~ $ ls -al 
/run/log/journal/8f018d505adf4ecaad2720811a888b04/
total 5,0M
drwxr-s---+ 2 root systemd-journal   80 Feb  2 22:17 ./
drwxr-sr-x  3 root systemd-journal   60 Feb  2 15:17 ../
-rw-r-+ 1 root systemd-journal 2,5M Feb  2 22:17 
system\@caad1846ab564a1c8d59d656f050776e-0001-00059d98777909b1.journal
-rw-r-+ 1 root systemd-journal 2,5M Feb  3 08:41 system.journal
[2/2159]mh@oversway:~ $ 

This is consistent with the behavior I have seen on a different box. I
will take a closer look at those times now that we have some evidence.

So I now suspect that the x bit gets set during the log rotation. What
umask is the process doing the log rotation running with?

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#950300: Fixed in upstream version 0.9.1

[Fiona Klute]

This has been fixed upstream since version 0.9.1.

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2020-02-02 at 21:08 +0100, Yves-Alexis Perez wrote:
> > An empty
> > override_dh_installsystemd:
> > 
> > is probably better suited in this case.
> > 
> > Not sure if this fixes the issue you are seeing, just something I
> > noticed while quickly glancing at it.
> 
> I can surely try, at least.

So, if I do that, lightdm.service is not installed at all (it comes from
debian/, not the upstream sources).

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl43ySwACgkQ3rYcyPpX
RFtS/ggAiKk4n0acU9JFeB9tJb2IfOVG6wsxFlWfEHDkeyFw2B6Vb8cg3SE4cuUc
aeDyraoJuS5rq2MRU592arHaOaISuWiNRf+cKR6YB+6qZmqvBR4dGxwAuGeMinu0
ZwGrPiElCYb40HknsDQr5f27l812QOqLIpi2VKZxPOvols2MzwC92JHlqNxnCKOU
WPT71s6y+kEKvqiEFV08aQJp9n6RbYT6qM6Xxrqft1ZPiKBgdzdOClDtXsPHgC95
mw+ioLdDBMiLkOosNpHMSCML8xlSESfkTM3yp5NalWdihUR3dKKSyKNP/Vn6MW68
t1Ny9sU5WtTaO69X6rc0eM5lt0odJg==
=YrkR
-END PGP SIGNATURE-

Bug#950516: file: please backport 5.38 to stable for removal of python2

[Christoph Biedl]

Control:  tag 950516 moreinfo

Felix Lechner wrote...

> Lintian has to stop using python2, which is being removed from Debian,
> to generate test binaries and must instead rely on python3 even on
> stable.

Actually, I don't (yet) follow why this is a problem "even on stable".
But assuming you have good reason for your request, I could also use a
detail of what you're asking for:

(1) The buster version of file should be available in stretch-backports.

(2) The buster version of file should be available in stretch, i.e.
the rather seldom case of bringing a completely new version to
stable.

About (1), I am be happy to provide and extensively test such a
backport, but will not upload for non-technical reasons. If somebody is
willing to do this, and on a regular base, please drop me a line and
we'll arrange things.

About (2): This is a big change. Breakage is not likely but *if* it
happens the impact will be huge, so the anger created. Let me propose an
alternative approach, almost risk-free: Cherry-pick the applicable
commits from upstream and upload to stable-proposed-updates. With
backing from the lintian team, the release team will certainly not
object.

Christoph


signature.asc
Description: PGP signature

Bug#950525: broken symlink: /usr/lib/gcc//9/libgcc_s.so{,.1}

[Matthias Klose]

On 2/3/20 6:39 AM, YunQiang Su wrote:
> Package: src:gcc-9
> Version: 9.2.1-25
> Severity: serious
> X-Debug-Cc: debian-s...@lists.debian.org
> 
> On i386
> # file /usr/lib/gcc/i686-linux-gnu/9/libgcc_s.so.1
> /usr/lib/gcc/i686-linux-gnu/9/libgcc_s.so.1: broken symbolic link to
> /lib/i386-linux-gnu/libgcc_s.so.1
> 
> On s390x:
> $ file /usr/lib/gcc/s390x-linux-gnu/9/libgcc_s.so*
> /usr/lib/gcc/s390x-linux-gnu/9/libgcc_s.so: broken symbolic link to
> /lib/s390x-linux-gnu/libgcc_s.so.1
> 
> Which make some packages ftbfs on s390x:
> https://buildd.debian.org/status/fetch.php?pkg=zlib=s390x=1%3A1.2.11.dfsg-1.2=1580704985=0

yes, fix in progress, although I need some disk space on zelenka ...

Bug#950526: endlessh FTCBS: does not pass cross tools to make

[Helmut Grohne]

Source: endlessh
Version: 1.1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

endlessh fails to cross build from source, because it does not pass
cross tools to make. The easiest way of doing so - using dh_auto_build -
makes endlessh cross buildable. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru endlessh-1.1/debian/changelog endlessh-1.1/debian/changelog
--- endlessh-1.1/debian/changelog   2020-02-01 05:29:51.0 +0100
+++ endlessh-1.1/debian/changelog   2020-02-03 05:53:17.0 +0100
@@ -1,3 +1,10 @@
+endlessh (1.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_make pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 03 Feb 2020 05:53:17 +0100
+
 endlessh (1.1-1) unstable; urgency=medium
 
   * New upstream version 1.1
diff --minimal -Nru endlessh-1.1/debian/rules endlessh-1.1/debian/rules
--- endlessh-1.1/debian/rules   2020-02-01 05:29:51.0 +0100
+++ endlessh-1.1/debian/rules   2020-02-03 05:53:16.0 +0100
@@ -8,7 +8,7 @@
dh $@
 
 override_dh_auto_build:
-   make endlessh CFLAGS="$(CFLAGS) -std=c99" LDFLAGS="$(LDFLAGS)"
+   dh_auto_build -- endlessh CFLAGS="$(CFLAGS) -std=c99" 
LDFLAGS="$(LDFLAGS)"
 
 override_dh_auto_install:
make install DESTDIR=debian/endlessh PREFIX=/usr

Bug#950525: broken symlink: /usr/lib/gcc//9/libgcc_s.so{,.1}

[YunQiang Su]

Package: src:gcc-9
Version: 9.2.1-25
Severity: serious
X-Debug-Cc: debian-s...@lists.debian.org

On i386
# file /usr/lib/gcc/i686-linux-gnu/9/libgcc_s.so.1
/usr/lib/gcc/i686-linux-gnu/9/libgcc_s.so.1: broken symbolic link to
/lib/i386-linux-gnu/libgcc_s.so.1

On s390x:
$ file /usr/lib/gcc/s390x-linux-gnu/9/libgcc_s.so*
/usr/lib/gcc/s390x-linux-gnu/9/libgcc_s.so: broken symbolic link to
/lib/s390x-linux-gnu/libgcc_s.so.1

Which make some packages ftbfs on s390x:
https://buildd.debian.org/status/fetch.php?pkg=zlib=s390x=1%3A1.2.11.dfsg-1.2=1580704985=0

Bug#947995: ncbi-entrez-direct: ncbi-entrez-direct FTBFS in testing/unstable

[Andreas Tille]

On Sun, Feb 02, 2020 at 10:30:31PM -0500, Aaron M. Ucko wrote:
> > If any of the commits was not helpful just rebase.
> 
> Thanks!  I've uploaded with your generic commits cherry-picked (and a
> bunch of changes of my own), but Salsa rejected my force pushes to
> protected branches.  Could you please adjust the project's permissions?

Done (hopefully), Andreas. 

-- 
http://fam-tille.de

Bug#937791: Blocked on reverse dependencies

[Sandro Tosi]

> > $ apt-cache rdepends python-gmpy
> > python-gmpy
> > Reverse Depends:
> >obfsproxy
> >python-tlslite-ng
> >python-sympy
> >python-gmpy-doc
> >
> >
>
> Dependencies on obfsproxy and python-sympy documented with affects and
> blocks. python-tlslite-ng has been removed already,

there are no more reverse dependencies on python-gmpy, what should we
do next? i see the source package doesnt produce any python3 package,
and the last changelog entry contains:

  * Override python-foo-but-no-python3-foo Lintian warning, since this package
is end-of-life after Python 2 support ends.

should we remove this package then? or do you want to generate a python3-gmpy?

> and we can rename
> python-gmpy-doc to python3-gmpy-doc once the blocking bugs are resolved.

please dont, -doc package must preserve the python- prefix.

Cheers,
Sandro

Bug#938656: texlive-extra: Python2 removal in sid/bullseye

[Norbert Preining]

Hi

> can this be very soon instead?

It is ready when it is ready! (Quote release managers).

> written 20 years ago will have to be upgraded or removed (that's just
> how IT works), and that's the reason why we are a distribution and not

Uhh, ohhh, you see the irony here, sending this to a TeX related circle?
DEK will be happy to know that he is not "IT", or outdated.

Enjoy

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#947995: ncbi-entrez-direct: ncbi-entrez-direct FTBFS in testing/unstable

[Aaron M. Ucko]

> If any of the commits was not helpful just rebase.

Thanks!  I've uploaded with your generic commits cherry-picked (and a
bunch of changes of my own), but Salsa rejected my force pushes to
protected branches.  Could you please adjust the project's permissions?

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#950524: apt: Please let users specify how deeply to update the dependency tree

[Kingsley G. Morse Jr.]

Package: apt
Version: 1.8.4
Severity: wishlist

Dear Maintainer,

Thank you very much for helping keep Debian's
admin tools so cool!

It seems to me that managing software complexity
is becoming more important as Debian acquires more
packages.

The main reason I'm writing is to humbly suggest a
new feature to apt, apt-get and/or aptitude.

It would let users specify how deeply into a
packages dependency tree to upgrade dependencies
to their current versions.

My understanding is the current policy is to
upgrade the named package to its current version,
and only its dependencies if their installed
versions do not happen to satisfy the named
package's dependency.

For example

"$ aptitude upgrade sagemath 

failed to upgrade its dependency on the cython3
package to the latest version available in
unstable, 0.29.14-0.1+b1. 

sagemath's dependency says ">= 0.29.1" is good
enough, and 0.29.2-2 was installed.

I humbly suggest added a cool new option: "-dl "
where  is a number specifying how deeply
into the named package's dependency tree to
upgrade dependencies to the currently available
version.

I suppose it may also accept a key word like "max"
or "all" to freshen the whole dependency tree.

I can imagine it helping 

find bugs and/or

our understanding of software complexity.

Either way, Debian may get better.

So,
Kingsley

Bug#950467: Maybe upgrading the cython3 package fixed it

[Kingsley G. Morse Jr.]

I'm happy to report I'm now looking at a cool 

sage:

prompt.

Since the last error message also alluded to 
cython

> ImportError: 
> /usr/lib/python3/dist-packages/sage/libs/gap/element.cpython-37m-i386-linux-gnu.so:
>  undefined symbol: GAP_EnterStack_

I tried manually upgrading the cython3 package
from 0.29.2-2 to 0.29.14-0.1+b1.

I wish I were more confident I knew what actually
fixed it, but as a practical metter, it's OK with
me if you close this bug report.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#859066: linux-image-*: recommend free firmware-ath9k-htc

[John Scott]

The live images include firmware-ath9k-htc now, see #934522.

By the way, being unaware of this bug at the time I filed #900171, that 
firmware-free should recommend firmware-ath9k-htc. This reflects the logical 
relationship better, but it's a trivial difference and I wonder which would be 
preferred.

Bug#950523: ITP: golang-gopkg-hlandau-acmeapi.v2 -- ACME v2 (RFC 8555) client library for Go

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-gopkg-hlandau-acmeapi.v2
  Version : 2.0.1-1
  Upstream Author : Hugo Landau
* URL : https://github.com/hlandau/acmeapi
* License : Expat
  Programming Lang: Go
  Description : ACME v2 (RFC 8555) client library for Go

This library implements the final version of the ACME specification.

https://tools.ietf.org/html/rfc8555

Bug#950522: adequate reports obsolete conffile while upgrading pulseaudio

[shirish शिरीष]

Package: libpulse0
Version: 13.0-4
Severity: normal
Usertags: obsolete-conffile adequate

Dear Maintainer,

Got the following obsolete conffile while upgrading pulseaudio

$ libpulse0:amd64: obsolete-conffile
/etc/pulse/client.conf.d/00-disable-autospawn.conf

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages libpulse0 depends on:
ii  libasyncns0  0.8-6+b1
ii  libc62.29-9
ii  libdbus-1-3  1.12.16-2
ii  libsndfile1  1.0.28-6
ii  libsystemd0  244.1-1
ii  libwrap0 7.6.q-30
ii  libxcb1  1.13.1-2

libpulse0 recommends no packages.

Versions of packages libpulse0 suggests:
ii  pulseaudio  13.0-4

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#950521: In pulseaudio 13.0-4 adequate shares about a broken symlink

[shirish शिरीष]

Package: pulseaudio
Version: 13.0-4
Severity: normal
Usertags : broken-symlink adequate

Dear Maintainer,
There seems to be something wrong with pulseaudio. I got the following
while upgrading which also was confirmed by adequate.

$adequate pulseaudio
pulseaudio: broken-symlink
enable/etc/pulse/client.conf.d/01--autospawn.conf ->
/run/pulseaudio-enable-autospawn

As can be seen /etc/default/pulseaudio also does not exist. I have no
clue what happened.

-- Package-specific info:
File '/etc/default/pulseaudio' does not exist

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.57
ii  libasound2   1.2.1.2-2
ii  libasound2-plugins   1.2.1-1
ii  libc62.29-9
ii  libcap2  1:2.27-1
ii  libdbus-1-3  1.12.16-2
ii  libgcc1  1:9.2.1-25
ii  libice6  2:1.0.9-2
ii  libltdl7 2.4.6-11
ii  liborc-0.4-0 1:0.4.31-1
ii  libpulse013.0-4
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.28-6
ii  libsoxr0 0.1.3-1
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   9.2.1-25
ii  libsystemd0  244.1-1
ii  libtdb1  1.4.2-3
ii  libudev1 244.1-1
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.6.8-1
ii  libx11-xcb1  2:1.6.8-1
ii  libxcb1  1.13.1-2
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 13.0-4

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.12.16-2
ii  libpam-systemd [logind]  244.1-1
ii  rtkit0.12-4

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  4.0-1
pn  pavumeter
ii  udev 244.1-1

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#950467: Nice catch, Tobias! Up for another? (Was: Install, run & crash w/ ...)

[Kingsley G. Morse Jr.]

I'm happy to report your guess was correct.

Through no fault of yours

$ apt-get install sagemath

on my computer failed to upgrade the
libgsl23 package to the latest version in
unstable.

Evidently not upgrading compliant dependencies to
their latest available versions is intentional.

But, I'm also happy to report, manually upgrading
it with

$ apt-get install libgsl23

seems to have fixed

>  ImportError: /usr/lib/i386-linux-gnu/libgsl.so.23: undefined symbol: 
> cblas_ctrmv

That's the good news.

The bad?

$ sage 

crashed with a new error.

Toward the end of Sage_crash_report.txt I now see

ImportError: 
/usr/lib/python3/dist-packages/sage/libs/gap/element.cpython-37m-i386-linux-gnu.so:
 undefined symbol: GAP_EnterStack_

If I understand correctly, it suggests sage
didn't find the symbol

GAP_EnterStack_

which seems to be associated with the GAP computer
algebra system.

Upgrading the following gap packages to their
latest versions in unstable elicited the same
error:

gap-core
gap-smallgrp-extra
gap-design
gap-float
gap-grape
gap-guava
gap-laguna
gap-openmath
gap-radiroot
gap-scscp
gap-sonata
gap-toric

I also checked if the versions of packages owning
files listed in its stack trace were currently in
unstable.

Unless I overlooked something, they are.

If you happen to have the time, and are so
inclined, feel free to share more insight!

The latest Sage_crash_report.txt isi attached to
this email, and hopefully, bug report.

Thanks,
Kingsley

On 02/02/2020 09:56, Tobias Hansen wrote:
> Hi,
> 
> looks like an instance of #907119 which was fixed in gsl 2.5+dfsg-5, however 
> you have gsl 2.5+dfsg-4 installed. Please update your packages to the 
> versions in unstable.
> 
> Best,
> Tobias
> 
> On 2/2/20 9:13 AM, Kingsley G. Morse Jr. wrote:
> > ImportError: /usr/lib/i386-linux-gnu/libgsl.so.23: undefined 
> > symbol: cblas_ctrmv
> 
> > ii  libgsl23  2.5+dfsg-4
> 

-- 
Time is the fire in which we all burn.

***

IPython post-mortem report

{'commit_hash': '',
 'commit_source': '(none found)',
 'default_encoding': 'UTF-8',
 'ipython_path': '/usr/lib/python3/dist-packages/IPython',
 'ipython_version': '7.11.1',
 'os_name': 'posix',
 'platform': 'Linux-4.4.0-1-686-pae-i686-with-debian-bullseye-sid',
 'sys_executable': '/usr/bin/python3',
 'sys_platform': 'linux',
 'sys_version': '3.7.5rc1 (default, Oct  2 2019, 04:19:31) \n'
'[GCC 9.2.1 20190909]'}

***



***

Crash traceback:

---
---
ImportError   Python 3.7.5rc1: /usr/bin/python3
   Sun Feb  2 15:13:05 2020
A problem occurred executing Python code.  Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.
/usr/share/sagemath/bin/sage-ipython in 
  1 #!/usr/bin/env sage-python
  2 # -*- coding: utf-8 -*-
  3 """
  4 Sage IPython startup script.
  5 """
  6 
  7 # Display startup banner. Do this before anything else to give the user
  8 # early feedback that Sage is starting.
  9 from sage.misc.banner import banner
 10 banner()
 11 
 12 from sage.repl.interpreter import SageTerminalApp
 13 
 14 app = SageTerminalApp.instance()
---> 15 app.initialize()
global app.initialize = >
 16 app.start()

 in initialize(self=, argv=None)

/usr/lib/python3/dist-packages/traitlets/config/application.py in 
catch_config_error(method=, 
app=, *args=(None,), **kwargs={})
 72 TRAITLETS_APPLICATION_RAISE_CONFIG_FILE_ERROR = False
 73 else:
 74 raise ValueError("Unsupported value for environment variable: 
'TRAITLETS_APPLICATION_RAISE_CONFIG_FILE_ERROR' is set to '%s' which is none of 
 {'0', '1', 'false', 'true', ''}."% _envvar )
 75 
 76 
 77 @decorator
 78 def catch_config_error(method, app, *args, **kwargs):
 79 """Method decorator for catching invalid config 
(Trait/ArgumentErrors) during init.
 80 
 81 On a TraitError (generally caused by bad config), this will print 
the trait's
 82 message, and exit the app.
 83 
 84 For use on init methods, to prevent invoking excepthook on invalid 
input.
 85 """
 86 try:
---> 87 return method(app, *args, **kwargs)
method = 
app = 
args = (None,)
kwargs = {}
 88 except (TraitError, ArgumentError) as e:
 89 app.print_help()
 90 app.log.fatal("Bad config encountered during initialization:")
   

Bug#950520: blueman: Ship blueman-mechanism.service under /lib/systemd/system

[Nicolas Braud-Santoni]

Package: blueman
Version: 2.1.1-1+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

On my system, blueman shipped blueman-mechanism.service to
/usr/lib/systemd/system/ (and is the only package to use that directory)

While systemd does find it, it is a fairly surprising location to find it
in, as unit files are usually shipped to /lib/systemd/system.

Similarly, you ship /usr/lib/systemd/user/blueman-applet.service which
ought to be /lib/systemd/user/blueman-applet.service


Best,

  nicoo

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages blueman depends on:
ii  adwaita-icon-theme3.34.0-2
ii  bluez 5.50-1+b1
ii  bluez-obexd   5.50-1+b1
ii  cinnamon [notification-daemon]4.2.4-2
ii  dbus  1.12.16-2
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dconf-gsettings-backend [gsettings-backend]   0.34.0-2
ii  gir1.2-appindicator3-0.1  0.4.92-7
ii  gir1.2-gdkpixbuf-2.0  2.40.0+dfsg-2
ii  gir1.2-glib-2.0   1.62.0-2
ii  gir1.2-gtk-3.03.24.13-1
ii  gir1.2-nm-1.0 1.22.4-1
ii  gir1.2-pango-1.0  1.42.4-7
ii  gnome-icon-theme  3.12.0-3
ii  libbluetooth3 5.50-1+b1
ii  libc6 2.29-9
ii  libglib2.0-0  2.62.4-1+b1
ii  libpulse-mainloop-glib0   13.0-3
ii  libpython3.7  3.7.6-1+b1
ii  librsvg2-common   2.46.4-1
ii  python3   3.7.5-3
ii  python3-cairo 1.16.2-2
ii  python3-gi3.34.0-3
ii  python3-gi-cairo  3.34.0-3

Versions of packages blueman recommends:
ii  policykit-1  0.105-26
ii  pulseaudio-module-bluetooth  13.0-3

blueman suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl43Y1IRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MuPEA//V6cLb06QN3ilz19ls1Yqjt6tbx/SZQyS
pInrmgjC4D0pXLvOYSGBghNE2SJ+ksYPmJZPhTs/ZyMcSEPCS9hPsjNMhQQmNOER
KmfO05Kg6XdcYUTXWnaLDCqpk7m2z/TFMQyQJnVP/3dmqj0OUbs6TH2KUu0xxudQ
UOp6oibkstrR+Gp7grjix2xjNzb2/d2Dl2f8wyp0fiCIQp+roD1JsozAbNB58YYt
1dHUX6Fe1S/+tVcOzGzDdUC+rbhenKZ7qieYL2cEZxJ9pBX1+1lsWiEFrVejJJeC
0fx4DyN560w6mi1p6MQWsbmm1sEfuJLeoXPJOE7A9El3dS6uAJwE0oj0DN2YOSG0
LklHoUIUVK0+1oEI6eyqh/82195cvRUWDpyWo3o0aUcfao/sfEcWjRGq/H3zGLCQ
YaiaBJGRVaPBNSwqmmxETskBNZsp7oFuZOSVPynDp0a5twMk4iwbGED4DbdRS1g+
ZSuZcE+Vnfh6883wem3aW0KPTM0qofWzlbHZIs7vBZmZt38lDbn6SODa5wCLCX8k
WZFNYYX1hmi85TBYIx7y2z8j4SDu5fESEnFf+uUEWiSh/0LCdRESYUQOL+5V/SMB
K8zpx62duhXspDxUABXcBTGO+/5HVj/hTyOjSbiY9pHJHcGGUWXwQcSLl8O1spml
IU4yI7u5pCg=
=JjPz
-END PGP SIGNATURE-

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#950519: gzip: please default to -n

[Adam Borowski]

Package: gzip
Version: 1.9-3
Severity: wishlist

Hi!
I've run ran into an Y2038 problem when compressing a file with a timestamp
after that date.  It's a yet another reason to drop including the timestamp
into .gz files -- something that no other popular compressor does.

It makes the output unreproducible for the same input.  This results in
having to manually add -n in thousands of places.

Then, it breaks logrotate:
error: Compressing program wrote following message to stderr when compressing 
log /var/log/exim4/mainlog.1:
gzip: stdin: warning: file timestamp out of range for gzip format
error: failed to compress log /var/log/exim4/mainlog.1
error: Compressing program wrote following message to stderr when compressing 
log /var/log/syslog.1:
gzip: stdin: warning: file timestamp out of range for gzip format
error: failed to compress log /var/log/syslog.1

We're working on Y2038 bugs all around the kernel, glibc, etc.  The time
such a fix would be strictly required for gzip is 18 years from now... but
why not flip the switch already?


Meow!
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.5.1-00053-g39149fc6f728 (SMP w/4 CPU cores; PREEMPT)
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: sysvinit (via /sbin/init)

Versions of packages gzip depends on:
ii  dpkg   1.19.7
ii  libc6  2.29-9

gzip recommends no packages.

Versions of packages gzip suggests:
ii  less  551-1

-- 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#937738: python-et-xmlfile: diff for NMU version 1.0.1-2.1

[Sandro Tosi]

> I'd have been happy to, but at the time, DPMT was using git-dpm and it
> didn't seem worth learning to use an unmaintained tool just to package a
> couple of python modules.

yeah, i feel you, and since then we migrated to salsa and a plain gbp
+ pristine-tar workflow

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#937738: python-et-xmlfile: diff for NMU version 1.0.1-2.1

[Afif Elghraoui]

On ٨‏/٦‏/١٤٤١ هـ ١٢:١٥ م, Sandro Tosi wrote:
> Control: tags 937738 + patch
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for python-et-xmlfile (versioned as 1.0.1-2.1). The diff
> is attached to this message.
> 
> Consider maintaining this package with the DPMT
> 

I'd have been happy to, but at the time, DPMT was using git-dpm and it
didn't seem worth learning to use an unmaintained tool just to package a
couple of python modules.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
https://afif.ghraoui.name

Bug#950517: golang-1.14: please add support for riscv64

[Aurelien Jarno]

Source: golang-1.14
Version: 1.14~beta1-2
Severity: wishlist
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

golang 1.14 will add support for the 64-bit RISC-V architecture, aka
riscv64. It has been committed upstream over the last days.

On the Debian packaging side, it requires very few changes. See the
attached patch. With it and with a git snapshot from today, I have been
able to bootstrap golang. Unfortunately bootstrapping it from gcc-go
didn't work, one of the go1 process never ends. It's probably a GCC bug.
Instead I have followed the process from Carlos Eduardo [1] to bootstrap
it from amd64, and then build it natively. All seems to work fine.

Would it be possible to include that patch in the next golang-1.14
upload?

Thanks,
Aurelien

[1] https://github.com/carlosedp/riscv-bringup/blob/master/build-golang.md
--- a/debian/control
+++ b/debian/control
@@ -21,7 +21,7 @@
 Rules-Requires-Root: no
 
 Package: golang-1.14-go
-Architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64 ppc64el 
s390x
+Architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64 ppc64el 
riscv64 s390x
 Depends: golang-1.14-src (>= ${source:Version}),
  ${misc:Depends},
  ${perl:Depends},
@@ -45,7 +45,7 @@
  pre-compile the standard library inside GOROOT for cross-compilation to work.
 
 Package: golang-1.14-src
-Architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64 ppc64el 
s390x
+Architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64 ppc64el 
riscv64 s390x
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: Go programming language - source files
  The Go programming language is an open source project to make programmers more
--- a/debian/control.in
+++ b/debian/control.in
@@ -17,7 +17,7 @@
 Rules-Requires-Root: no
 
 Package: golang-X.Y-go
-Architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64 ppc64el 
s390x
+Architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64 ppc64el 
riscv64 s390x
 Depends: golang-X.Y-src (>= ${source:Version}),
  ${misc:Depends},
  ${perl:Depends},
@@ -41,7 +41,7 @@
  pre-compile the standard library inside GOROOT for cross-compilation to work.
 
 Package: golang-X.Y-src
-Architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64 ppc64el 
s390x
+Architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64 ppc64el 
riscv64 s390x
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: Go programming language - source files
  The Go programming language is an open source project to make programmers more
--- a/debian/helpers/goenv.sh
+++ b/debian/helpers/goenv.sh
@@ -11,7 +11,7 @@
 
 __goarch__deb_arch_cpu() {
case "$1" in
-   amd64|arm|arm64|mips|ppc64|s390x) echo "$1" ;;
+   amd64|arm|arm64|mips|ppc64|riscv64|s390x) echo "$1" ;;
i386) echo 386 ;;
mips64el) echo mips64le ;;
mipsel) echo mipsle ;;

Bug#950516: file: please backport 5.38 to stable for removal of python2

[Felix Lechner]

Package: file
Severity: normal
Control: block 936952 by -1
X-Debbugs-CC: debian-pyt...@lists.debian.org

Hi,

In stable, the file utility (5.34) does not recognize byte-compiled
python3 binaries, even though they were generated by the default
python3 for that release (3.7.3). The version currently in unstable
(5.38) should work. Will you please provide a backport or a security
upload?

If the first point is not enough, Lintian depends on the
identification via 'file' to provide the tag
'source-contains-prebuilt-python-object'. Without it, Lintian cannot
test the tag on stable and would likely drop it.

Lintian has to stop using python2, which is being removed from Debian,
to generate test binaries and must instead rely on python3 even on
stable. Lintian cannot resort to python2 on stable alone, because
python3 stores byte-compiled binaries in a different location
(__pycache__).

Kind regards
Felix Lechner

Bug#950515: RM: sciscipy -- ROM; Dead upstream

[Sylvestre Ledru]

Package: ftp.debian.org
Severity: normal

Hello,

Please delete sciscipy. It is dead upstream. Probably broken currently
Small popcon (<50) and won't be upgraded to Python 3.

thanks
Sylvestre

Bug#937485: pymvpa2: Python2 removal in sid/bullseye

[Stuart Prescott]

Dear maintainers,

In the last update on pymvpa2, it sounded like upstream would soon have sorted 
Python 3 compatibility and the FTBFS bugs for the package would soon be fixed. 
However, there has been no upstream activity in the referenced PR 
https://github.com/PyMVPA/PyMVPA/pull/525 for many months.

What are the prospects for a fixed package in the buster release cycle? Given 
that it will have to go through NEW to gain the Python 3 module package in any 
case, are we at the stage where it should just be removed from Debian, perhaps 
to be reintroduced later when upstream work is completed?

(There's a cost to keeping buggy packages in Debian in that they occupy 
people's time when dealing with transitions or bug squashing. Even finding the 
packaging Vcs to see if there has been yet-to-be uploaded progress on these 
bugs is excessively difficult right now)

Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#920497: [Pkg-opencl-devel] Bug#920497: Bug#920497: clblas: *ger out of bounds memory access under pocl

[Rebecca N. Palmer]

On 01/02/2020 13:32, Andreas Beckmann wrote:

Is this issue still reproducible with recent versions of pocl?


Yes, and if anything it's worse in that it can now be silently wrong 
answers not just crashes.


(Each example output below is from a separate run of the test suite, 
after reverting the size to 4,5 - 
libgpuarray/debian/patches/920497_ger_workaround.patch normally sets it 
to 64,64 to avoid this bug.)


$ DEVICE=opencl0:0 python3 -m nose -v 
/usr/lib/python3/dist-packages/pygpu/tests/test_blas.py:test_ger


pocl 1.4-4 (sid):

pygpu.tests.test_blas.test_ger(4, 5, 'float32', 'f', 1, 1, False, False) 
... FAIL

free(): invalid next size (normal)
Aborted
[2 non-failing runs]
pygpu.tests.test_blas.test_ger(4, 5, 'float32', 'f', 1, 1, True, False) 
... malloc(): invalid size (unsorted)

Aborted
pygpu.tests.test_blas.test_ger(4, 5, 'float32', 'f', 1, 1, True, True) 
... FAIL

[...]
Mismatch: 45%
Max absolute difference: 15.6799345
Max relative difference: 0.86604244
 x: array([[36.466873, 18.703169, 16.077265, 28.332705, 12.42333 ],
   [55.76504 , 21.695398, 15.684309, 43.812134, 16.141874],
   [ 5.726563, 11.466312,  2.295661,  7.407461,  2.720506],...
 y: array([[36.466873, 18.703169, 16.077265, 28.332705, 12.42333 ],
   [66.77751 , 21.695398, 26.107975, 43.812134, 26.334879],
   [21.406498, 11.466312, 17.137228,  7.407461, 17.233652],...
pygpu.tests.test_blas.test_ger(4, 5, 'float32', 'f', 1, 1, True, False) 
... malloc_consolidate(): invalid chunk size

Aborted
pygpu.tests.test_blas.test_ger(4, 5, 'float32', 'f', 1, 1, True, True) 
... FAIL

[...]
Mismatch: 60%
Max absolute difference: 2.3951557e+23
Max relative difference: 1.
 x: array([[62.353832, 20.148596, 76.49873 , 39.474213, 32.401543],
   [13.127782, 10.97283 ,  5.661376,  9.378635,  6.7582  ],
   [11.341855,  6.147425, 17.3454  ,  6.12348 , 11.391024],...
 y: array([[ 6.235383e+01,  2.014860e+01,  7.649873e+01,  3.947421e+01,
 3.240154e+01],
   [ 3.232117e+01, -2.395156e+23,  1.929382e+01,  9.378635e+00,...

pocl 1.4-5 (experimental):
pygpu.tests.test_blas.test_ger(4, 5, 'float32', 'f', 1, 1, False, True) 
... malloc(): unsorted double linked list corrupted

Aborted
pygpu.tests.test_blas.test_ger(4, 5, 'float32', 'f', 1, 1, False, True) 
... corrupted size vs. prev_size

Aborted
pygpu.tests.test_blas.test_ger(4, 5, 'float32', 'f', 1, 1, True, True) 
... FAIL

double free or corruption (!prev)
Aborted
pygpu.tests.test_blas.test_ger(4, 5, 'float32', 'f', 1, 1, True, True) 
... FAIL

[...]
Mismatch: 60%
Max absolute difference: 6.506278e+37
Max relative difference: 1.
 x: array([[41.57771 , 65.34176 , 20.970417, 52.550655, 46.916115],
   [25.290237, 27.915987, 11.624907, 23.786522, 30.36904 ],
   [37.770523, 45.49727 , 14.813134, 42.574074, 41.936626],...
 y: array([[ 4.157771e+01,  6.534176e+01,  2.097042e+01,  5.255066e+01,
 4.691611e+01],
   [ 3.974606e+01,  2.791599e+01,  2.405841e+01, -6.506278e+37,...

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#950513: RM: python-sciscipy -- ROM; no development upstream, not Python 3 compatible

[Stuart Prescott]

Package: ftp.debian.org
Severity: normal

python-sciscipy does not appear to be under active upstream development
and is not likely to be ported to Python 3 within the bullseye development
cycle. It can be removed from Debian, as discussed in #938445.

Thanks!

Bug#950512: quotecolors: not usable anymore with TB>= 68.x

[Carsten Schoenert]

Source: quotecolors
Severity: serious

Hello Christoph,

xul-ext-quotecolors isn't usable with Thunderbird 68.x due API
incompatibilities.

There is no new version provided by upstream which is usable again with
recent Thunderbird versions so this package is useless now.
The whole package should be removed from the archives.

Regards
Carsten

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

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

Bug#950326: dgit: can't import binutils 2.33.90.20200122-2

[Ian Jackson]

I have a fix for this which is currently undergoing local intensive
regressio testing.  It fixes the bug for me:

  
https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=shortlog;h=refs/heads/wip.950326

  git://git.chiark.greenend.org.uk/~ianmdlvl/dgit.git -b wip.950326

  635b2a6e7d55503a75ace034d96326d5b2197798

You can just dpkg-buildpackage -uc -b and dpkg -i the .deb.

Upload will probably be tomorrow.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#950258: fixed in spamassassin 3.4.2-1~deb9u3

[Damian]

Will there be a fix for jessie?

On Sun, 02 Feb 2020 13:47:53 + Debian FTP Masters
 wrote:

> Source: spamassassin
> Source-Version: 3.4.2-1~deb9u3
>
> We believe that the bug you reported is fixed in the latest version of
> spamassassin, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed. If you
> have further comments please address them to 950...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.

Bug#950511: ITP: tinyalign -- numerical representation of differences between strings

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: tinyalign -- numerical representation of differences between 
strings
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: tinyalign
  Version : 0.2
  Upstream Author : Marcel Martin 
* URL : https://github.com/marcelm/tinyalign
* License : MIT
  Programming Lang: Python
  Description : numerical representation of differences between strings
 A small Python module providing edit distance (aka Levenshtein distance,
 that is, counting insertions, deletions and substitutions) and Hamming
 distance computation.
 .
 Its main purpose is to speed up computation of edit distance by allowing
 to specify a maximum number of differences maxdiff (banding). If that
 parameter is provided, the returned edit distance is anly accurate up
 to maxdiff. That is, if the actual edit distance is higher than maxdiff,
 a value larger than maxdiff is returned, but not necessarily the actual
 edit distance.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/med-team/tinyalign

Bug#950510: Messages still present in Debian Stable (buster)

[Michael Biebl]

Control: reassign -1 lvm2

Am 02.02.20 um 21:06 schrieb Narcis Garcia:
> Package: systemd
> Version: 241-7
> Severity: normal
> Justification: Logs repeated error messages
> 
> udev version: 241-7
> 
> Dear Maintainer:
> 
> * Not using LVM for any disk/volume
> * Some installations show messages only on first boot after OS install.
> * Single disk with GPT label. Partitions:
> 1. bios_grub
> 2. Ext4 partition (/boot)
> 3. LUKS partition and direct Ext4 inside (/)
> 
> $ sudo journalctl -b -p err
> (...)
> lvm2-activation-generator: lvmconfig failed
> lvm2-activation-generator: Activation generator failed.
> systemd[3103]:
> /usr/lib/systemd/system-generators/lvm2-activation-generator failed with
> exit status 1.
> (...)
> 

That generator comes from the lvm2 package, so reassigning accordingly.

Please attach the output of
reportbug --template lvm2
to this bug report, so the lvm2 maintainers have some context.





signature.asc
Description: OpenPGP digital signature

Bug#937738: python-et-xmlfile: diff for NMU version 1.0.1-2.1

[Sandro Tosi]

Control: tags 937738 + patch


Dear maintainer,

I've prepared an NMU for python-et-xmlfile (versioned as 1.0.1-2.1). The diff
is attached to this message.

Consider maintaining this package with the DPMT

Regards.

diff -Nru python-et-xmlfile-1.0.1/debian/changelog python-et-xmlfile-1.0.1/debian/changelog
--- python-et-xmlfile-1.0.1/debian/changelog	2016-04-26 21:36:21.0 -0400
+++ python-et-xmlfile-1.0.1/debian/changelog	2020-02-02 15:13:55.0 -0500
@@ -1,3 +1,10 @@
+python-et-xmlfile (1.0.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937738
+
+ -- Sandro Tosi   Sun, 02 Feb 2020 15:13:55 -0500
+
 python-et-xmlfile (1.0.1-2) unstable; urgency=medium
 
   * Use compliant binary package names (Closes: #822742)
diff -Nru python-et-xmlfile-1.0.1/debian/control python-et-xmlfile-1.0.1/debian/control
--- python-et-xmlfile-1.0.1/debian/control	2016-04-26 21:48:03.0 -0400
+++ python-et-xmlfile-1.0.1/debian/control	2020-02-02 15:13:44.0 -0500
@@ -5,34 +5,17 @@
 Build-Depends:
 	debhelper (>=9),
 	dh-python,
-# Python2
-	python-all,
-	python-setuptools,
-	python-lxml (>= 3.4),
 # Python3
 	python3-all,
 	python3-setuptools,
 	python3-lxml (>= 3.4),
 # Test-Depends:
-	python-pytest,
 	python3-pytest,
 Standards-Version: 3.9.8
 Homepage: https://bitbucket.org/openpyxl/et_xmlfile
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/python-et-xmlfile.git
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/python-et-xmlfile.git
 
-Package: python-et-xmlfile
-Architecture: all
-Depends:
-	${python:Depends},
-	${misc:Depends},
-Description: low memory library for creating large XML files (Python 2)
- et_xmlfile is based upon the xmlfile module from lxml with the aim of
- allowing code to be developed that will work with both libraries. It was
- developed initially for the openpyxl project but is now a standalone module.
- .
- This package installs the library for Python 2.
-
 Package: python3-et-xmlfile
 Architecture: all
 Depends:
diff -Nru python-et-xmlfile-1.0.1/debian/rules python-et-xmlfile-1.0.1/debian/rules
--- python-et-xmlfile-1.0.1/debian/rules	2016-04-26 21:30:50.0 -0400
+++ python-et-xmlfile-1.0.1/debian/rules	2020-02-02 15:13:51.0 -0500
@@ -5,4 +5,4 @@
 export PYBUILD_NAME=et-xmlfile
 
 %:
-	dh $@  --with python2,python3 --buildsystem=pybuild
+	dh $@  --with python3 --buildsystem=pybuild

Bug#950510: Messages still present in Debian Stable (buster)

[Narcis Garcia]

Package: systemd
Version: 241-7
Severity: normal
Justification: Logs repeated error messages

udev version: 241-7

Dear Maintainer:

* Not using LVM for any disk/volume
* Some installations show messages only on first boot after OS install.
* Single disk with GPT label. Partitions:
1. bios_grub
2. Ext4 partition (/boot)
3. LUKS partition and direct Ext4 inside (/)

$ sudo journalctl -b -p err
(...)
lvm2-activation-generator: lvmconfig failed
lvm2-activation-generator: Activation generator failed.
systemd[3103]:
/usr/lib/systemd/system-generators/lvm2-activation-generator failed with
exit status 1.
(...)

This may be related to bug #917124
https://bugs.debian.org/917124

-- 
Regards,
Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this tracker archive. Public archive administrator
should fix this against automated addresses collectors.

Bug#936762: jdcal: diff for NMU version 1.0-1.3

[Sandro Tosi]

Control: tags 936762 + patch


Dear maintainer,

I've prepared an NMU for jdcal (versioned as 1.0-1.3). The diff
is attached to this message.

Consider maintaining this package with the DPMT

Regards.

diff -Nru jdcal-1.0/debian/changelog jdcal-1.0/debian/changelog
--- jdcal-1.0/debian/changelog	2017-09-24 21:15:10.0 -0400
+++ jdcal-1.0/debian/changelog	2020-02-02 15:10:30.0 -0500
@@ -1,3 +1,10 @@
+jdcal (1.0-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #936762
+
+ -- Sandro Tosi   Sun, 02 Feb 2020 15:10:30 -0500
+
 jdcal (1.0-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru jdcal-1.0/debian/control jdcal-1.0/debian/control
--- jdcal-1.0/debian/control	2017-09-24 21:15:10.0 -0400
+++ jdcal-1.0/debian/control	2020-02-02 15:09:56.0 -0500
@@ -2,24 +2,12 @@
 Section: python
 Priority: optional
 Maintainer: Yaroslav Halchenko 
-Build-Depends: debhelper (>= 9), python, python3, dh-python
+Build-Depends: debhelper (>= 9), python3, dh-python
 Standards-Version: 3.9.6
 Homepage: https://github.com/phn/jdcal
 Vcs-Git: http://github.com/neurodebian/jdcal -b debian
 Vcs-Browser: http://github.com/neurodebian/jdcal
 
-Package: python-jdcal
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Description: Julian dates from proleptic Gregorian and Julian calendars
- This module contains functions for converting between Julian dates
- and calendar dates.
- .
- Different regions of the world switched to Gregorian calendar from
- Julian calendar on different dates. Having separate functions for
- Julian and Gregorian calendars allow maximum flexibility in choosing
- the relevant calendar.
-
 Package: python3-jdcal
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru jdcal-1.0/debian/rules jdcal-1.0/debian/rules
--- jdcal-1.0/debian/rules	2014-12-10 00:49:59.0 -0500
+++ jdcal-1.0/debian/rules	2020-02-02 15:10:26.0 -0500
@@ -3,15 +3,6 @@
 # output every command that modifies files on the build system.
 #DH_VERBOSE = 1
 
-PYVERS = $(shell pyversions -vr)
-PY3VERS = $(shell py3versions -vr)
-
 # main packaging script based on dh7 syntax
 %:
-	dh $@ --with=python2,python3
-
-
-override_dh_auto_install: ${PYVERS:%=python-install%} ${PY3VERS:%=python-install%}
-python-install%:
-	echo "$*" | grep -q '^3' && PY=3 || PY= ; \
-python$$PY setup.py install --install-layout=deb --root=$(CURDIR)/debian/python$$PY-jdcal
+	dh $@ --with=python3 --buildsystem=pybuild

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

[Michael Biebl]

Am 02.02.20 um 21:08 schrieb Yves-Alexis Perez:
> On Sun, 2020-02-02 at 21:03 +0100, Michael Biebl wrote:
>> I had a very superficial look at debian/rules
> 
>> override_dh_installsystemd:
>>dh_installsystemd -plightdm --no-start -r lightdm.service
> 
>> I suppose you don't want that.
> 
> To be honest, I think I always followed what other where telling me to do
> here, in order to coordinate with other DM for the shared display-
> manager.service stuff.

Nod. It would probably not be the worst idea if we created a wiki page
with some best practices for how to handle the display-manager.service
symlink in Debian.





signature.asc
Description: OpenPGP digital signature

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2020-02-02 at 21:03 +0100, Michael Biebl wrote:
> I had a very superficial look at debian/rules
> 
> override_dh_installsystemd:
>dh_installsystemd -plightdm --no-start -r lightdm.service
> 
> I suppose you don't want that.

To be honest, I think I always followed what other where telling me to do
here, in order to coordinate with other DM for the shared display-
manager.service stuff.

> For one, it would unconditionally enable the service, not respecting the
> debconf choice.
> It would also unconditionally remove the display-manager.service symlink
> on purge.
> 
> An empty
> override_dh_installsystemd:
> 
> is probably better suited in this case.
> 
> Not sure if this fixes the issue you are seeing, just something I
> noticed while quickly glancing at it.

I can surely try, at least.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl43LCcACgkQ3rYcyPpX
RFsnEAf9FVMdypIHlJTeizHUypwi0Uh7oR08o7At7RpChSVCoDARL13F6b0nad4s
sA8VeElf+WsFDs4jYTs+8ycIwIKGYxpwRVduQEH4zNFRWdNlfN3t3kS67UncX5cc
uQFu3kuMc2ftYFvF4JsSc2qMSyt1fdv2d6joFUd0ybO/BsMoiv5AEI9aJihUvkP0
Pb5UCNnGjuTYMgie1HQEDer8V3yvRR3msUWxDKTm/DkXZEI8ACLum7+bUIPePOMB
L1Zt+cXkhdn+QU+LZYD80ENpWFolL+2a7gEqFkZmuPijCO7TF/jCjtfufu6A3z+5
LcsToz1N5/FhJ5SpgsmmRHC5pDp8HQ==
=RmX2
-END PGP SIGNATURE-

Bug#946456: systemd: Provide systemd-sysusers as an independent package

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 30, 2020 at 11:51:48PM -0300, Felipe Sateler wrote:
> On Thu, Jan 30, 2020 at 6:40 PM Michael Biebl  wrote:
> 
> > Hi Felipe
> >
> > Am 30.01.20 um 22:30 schrieb Felipe Sateler:
> > >
> > >
> > > On Thu, Jan 30, 2020 at 1:39 PM Michael Biebl  > > > wrote:
> > >
> > > Am 28.01.20 um 17:27 schrieb Ansgar:
> > > > On Tue, 2020-01-28 at 16:51 +0100, Michael Biebl wrote:
> > > >> Am 28.01.20 um 14:59 schrieb Ansgar:
> > > >>> I tried linking systemd-{sysusers,tmpfiles} statically against
> > > >>> systemd's private library earlier this month.  It increases the
> > > >>> binaries size by ~100 kB (compared to Installed-Size: 14.2 MB of
> > > >>> systemd that is just one percent).
> > > >>
> > > >> Is that 100K per binary?
> > > >
> > > > I checked my notes at it was 100 kB per binary: they are 212 kB
> > larger
> > > > (sysusers 51 kB → 137 kB, tmpfiles 84 kB → 212 kB); I tested with
> > > > systemd 243-8.
> > > >
> > > > It might be possible to make it a bit smaller if one was to somehow
> > > > link libsystemd0 for functions available there (libsystemd-shared
> > > > currently duplicates those).
> > >
> > >
> > > That is not possible. There is global state that is not to be shared.
> > > See https://github.com/systemd/systemd/pull/3516#issuecomment-227482524
> >
> > What's your thought on how to solve this libsystemd-shared issue should
> > we consider splitting out systemd-{sysusers,tmpfiles}
> >
> > - link statically (and carry a downstream patch for eternity)
> > - move libsystemd-shared to systemd-utils and risk the breakage that can
> > result from a partial/aborted upgrade
> > - copy, instead of move, the binaries + libsystemd-shared and make the
> > resulting systemd-utils package Conflict with systemd (instead of having
> > systemd depend on systemd-utils)
> > - something else?
> >
> 
> I tried linking statically the "can run without systemd-pid1 tools" with
> the attached patch.
> 
> Disk usage appears to increase by about 400 kb:
> % dpkg --info systemd_244.1-1_amd64.deb|grep Installed
> 
>  Installed-Size: 13908
> % dpkg --info ../systemd_244-3_amd64.deb|grep Installed
>  Installed-Size: 14319
> 
> Maybe upstream can be persuaded to merge something like this?
> 
> -- 
> 
> Saludos,
> Felipe Sateler

> diff --git a/meson.build b/meson.build
> index b8dff8cd94..39cef6b301 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1493,6 +1493,29 @@ make_autosuspend_rules_py = 
> find_program('tools/make-autosuspend-rules.py')
>  
>  
>  
> +
> +libutil = static_library(
> +'util',
> +[
> +'src/shared/acl-util.c',
> +'src/shared/enable-mempool.c',
> +'src/shared/id128-print.c',
> +'src/shared/pager.c',
> +'src/shared/path-lookup.c',
> +'src/shared/pretty-print.c',
> +'src/shared/spawn-ask-password-agent.c',
> +'src/shared/spawn-polkit-agent.c',
> +'src/shared/specifier.c',
> +'src/shared/sysctl-util.c',
> +'src/shared/sysctl-util.h',
> +'src/shared/tmpfile-util-label.c',
> +'src/shared/uid-range.c',
> +'src/shared/verbs.c',
> +] + id128_sources,
> +link_with: [libbasic, libsystemd_static],
> +include_directories: includes
> +)

Is creating a separate static library actually necessary?  What would
the results be if those binaries were linked to the static version of
libshared that we already provide support for? I hope the compiler
would be able to drop any unused objects and achieve the same size,
without having to maintain yet another list of files.

>  # binaries that have --help and are intended for use by humans,
>  # usually, but not always, installed in /bin.
>  public_programs = []
> @@ -1537,6 +1560,7 @@ test_dlopen = executable(
>  include_directories : includes,
>  link_with : [libbasic],
>  dependencies : [libdl],
> +b_lto: false,
>  build_by_default : want_tests != 'false')
>  
>  foreach tuple : [['myhostname', 'ENABLE_NSS_MYHOSTNAME'],
> @@ -2407,7 +2431,7 @@ install_data('src/sleep/sleep.conf',
>  exe = executable('systemd-sysctl',
>   'src/sysctl/sysctl.c',
>   include_directories : includes,
> - link_with : [libshared],
> + link_with : [libutil],

To upstream this, the change in behaviour must be configuration-time
selectable.

Zbyszek

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

[Michael Biebl]

Am 02.02.20 um 20:45 schrieb Michael Biebl:
> Am 02.02.20 um 16:13 schrieb Yves-Alexis Perez:
>> On Sat, 2020-02-01 at 03:21 +0100, Michael Biebl wrote:
>>> They should also add a
>>
>>> [Install]
>>> Alias=display-manager.service
>>
>>> section
>>
>>> to their service file. Which will make sure that if you run
>>> "systemctl enable foo.service", display-manager.service will point at
>>> the desired display manager.
>>
>> Hi Michael, I tried that, but it seems that it has the side effect of making
>> lightdm restart when upgrading, which is not really a good idea when you're
>> actually in a X session.
>>
>> Any idea how to prevent that?
> 
> Can you show me the (complete) postinst code?
> 

I had a very superficial look at debian/rules

override_dh_installsystemd:
   dh_installsystemd -plightdm --no-start -r lightdm.service

I suppose you don't want that.
For one, it would unconditionally enable the service, not respecting the
debconf choice.
It would also unconditionally remove the display-manager.service symlink
on purge.

An empty
override_dh_installsystemd:

is probably better suited in this case.

Not sure if this fixes the issue you are seeing, just something I
noticed while quickly glancing at it.



signature.asc
Description: OpenPGP digital signature

Bug#950500: aqbanking-tools: aqpaypal-tool unable to call any control function

[Micha Lenk]

Control: tags -1 pending

Hi,

On 02.02.20 17:59, Charlemagne Lasse wrote:

The libaqbanking44 or the aqbanking-tools are currently incompatible
with each other when calling the aqpaypal backend


Thank you for providing helpful feedback about the aqbanking-tools 
package. I've just committed and pushed a [1]change that will enable the 
aqpaypal backend in the next upload.


Best regards,
Micha Lenk

1. 
https://salsa.debian.org/aqbanking-team/pkg-libaqbanking/commit/c92dd29222bd6dc4722e5c9661afadf09df4d6d9

Bug#950509: pristine-tar: pristine-xz failed to reproduce build of ../digikam_7.0.0~b1.orig.tar.xz

[Norbert Preining]

Package: pristine-tar
Version: 1.47
Severity: important

Hi

see $subject
orig tarball is here:
https://download.kde.org/unstable/digikam/digikam-7.0.0-beta1.tar.xz

Best

Norbert


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

Kernel: Linux 5.5.0 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pristine-tar depends on:
ii  bzip21.0.8-2
ii  libbz2-1.0   1.0.8-2
ii  libc62.29-9
ii  libsys-cpuaffinity-perl  1.12-1+b4
ii  pbzip2   1.1.13-1
ii  perl 5.30.0-9
ii  pixz 1.0.6-2+b1
ii  tar  1.30+dfsg-6+b1
ii  xdelta   1.1.3-9.3
ii  xdelta3  3.0.11-dfsg-1+b1
ii  xz-utils 5.2.4-1+b1
ii  zlib1g   1:1.2.11.dfsg-1+b1

pristine-tar recommends no packages.

pristine-tar suggests no packages.

-- no debconf information

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

[Michael Biebl]

Am 02.02.20 um 20:45 schrieb Michael Biebl:
> Am 02.02.20 um 16:13 schrieb Yves-Alexis Perez:
>> On Sat, 2020-02-01 at 03:21 +0100, Michael Biebl wrote:
>>> They should also add a
>>
>>> [Install]
>>> Alias=display-manager.service
>>
>>> section
>>
>>> to their service file. Which will make sure that if you run
>>> "systemctl enable foo.service", display-manager.service will point at
>>> the desired display manager.
>>
>> Hi Michael, I tried that, but it seems that it has the side effect of making
>> lightdm restart when upgrading, which is not really a good idea when you're
>> actually in a X session.
>>
>> Any idea how to prevent that?
> 
> Can you show me the (complete) postinst code?
> 

before and after



signature.asc
Description: OpenPGP digital signature

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

[Michael Biebl]

Am 02.02.20 um 16:13 schrieb Yves-Alexis Perez:
> On Sat, 2020-02-01 at 03:21 +0100, Michael Biebl wrote:
>> They should also add a
> 
>> [Install]
>> Alias=display-manager.service
> 
>> section
> 
>> to their service file. Which will make sure that if you run
>> "systemctl enable foo.service", display-manager.service will point at
>> the desired display manager.
> 
> Hi Michael, I tried that, but it seems that it has the side effect of making
> lightdm restart when upgrading, which is not really a good idea when you're
> actually in a X session.
> 
> Any idea how to prevent that?

Can you show me the (complete) postinst code?



signature.asc
Description: OpenPGP digital signature

Bug#948288: A workaround ...

[Md Ayquassar]

... that circumvents both problems but does not solve them turns out to be
disabling Wayland and sticking with Xorg by means of changing
#WaylandEnable=false
to
WaylandEnable=false

in /etc/gdm3/daemon.conf and rebooting. The original problems didn't go away, of
course; the bugs still persist in whichever state they might be.

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Johannes Schauer]

Quoting Johannes Schauer (2020-02-02 20:22:49)
> Hi,
> 
> Quoting Francesco Poli (2020-02-02 16:58:05)
> > > >   • ./usr/lib/python3.7/__pycache__/hashlib.cpython-37.pyc files have
> > > >   some different hex values (I am not sure why, but it's compiled Python
> > > >   code, maybe it includes a compilation timestamp or something?!?)
> > > This is a known bug that I have yet to report to the Python maintainers.
> > Ah, interesting.  I encourage you to report this bug, as it might help the
> > Reproducible Builds effort...
> 
> I reported a very similar bug over a year ago:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917407
> 
> The bug then magically fixed itself when python 3.7.3 upgraded to 3.7.4 but
> nobody really ever investigated what happened.
> 
> > > > I am under the impression that the two .tar files are to be considered
> > > > equivalent.  Do you agree?
> > > Yes. :)
> > OK, in the meanwhile I got around to check whether the .qcow2 image is
> > actually working as autopkgtest testbed.
> > 
> > Unfortunately, no, it's not working!  :-(
> > 
> > 
> >   $ autopkgtest --output-dir ./${PKG}_${VERS}_autopkgtest.out \
> >--summary ./${PKG}_${VERS}_autopkgtest.summary \
> >   -B ./${PKG}_${VERS}_amd64.changes \
> > -- qemu ~/Downloads/TEST/debian-unstable.qcow2
> >   autopkgtest [16:23:45]: version 5.11
> >   autopkgtest [16:23:45]: host ${HOST}; command line: ${CMDLINE}
> >   qemu-system-x86_64: terminating on signal 15 from pid 8488 
> > (/usr/bin/python3)
> >   : failure: timed out waiting for "login prompt on ttyS0"
> >   autopkgtest [16:24:45]: ERROR: testbed failure: cannot send to testbed: 
> > [Errno 32] Broken pipe
> > 
> > Could you help me to investigate the issue?
> > Is the command line correct?  Where did I go wrong?
> 
> I can imagine two ways forward.
> 
> 1. you can try the qcow2 image you built without autopkgtest by just running 
> it
>inside qemu like so:
> 
> $ qemu-system-x86_64 -enable-kvm -m 512 -serial 
> unix:/tmp/ttyS0,server,nowait -drive 
> "file=$HOME/Downloads/TEST/debian-unstable.qcow2,cache=unsafe,if=virtio,index=0"

One non-obvious thing is missing here. After running the above command you have
a new unix socket under /tmp/ttyS0 that you should be able to connect to using
a serial terminal emulator. This is how autopkgtest connects to qemu. So after
running above command, check that everything works by running something like:

$ minicom -D 'unix#/tmp/ttyS0'

> 2. you could upload your qcow2 image somewhere together with the right
>SOURCE_DATE_EPOCH value that you used. Then I could try to reproduce that
>image myself and diff it against what I have because what I have here is
>working just fine. :)



signature.asc
Description: signature

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Johannes Schauer]

Hi,

Quoting Francesco Poli (2020-02-02 16:58:05)
> > >   • ./usr/lib/python3.7/__pycache__/hashlib.cpython-37.pyc files have
> > >   some different hex values (I am not sure why, but it's compiled Python
> > >   code, maybe it includes a compilation timestamp or something?!?)
> > This is a known bug that I have yet to report to the Python maintainers.
> Ah, interesting.  I encourage you to report this bug, as it might help the
> Reproducible Builds effort...

I reported a very similar bug over a year ago:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917407

The bug then magically fixed itself when python 3.7.3 upgraded to 3.7.4 but
nobody really ever investigated what happened.

> > > I am under the impression that the two .tar files are to be considered
> > > equivalent.  Do you agree?
> > Yes. :)
> OK, in the meanwhile I got around to check whether the .qcow2 image is
> actually working as autopkgtest testbed.
> 
> Unfortunately, no, it's not working!  :-(
> 
> 
>   $ autopkgtest --output-dir ./${PKG}_${VERS}_autopkgtest.out \
>--summary ./${PKG}_${VERS}_autopkgtest.summary \
>   -B ./${PKG}_${VERS}_amd64.changes \
> -- qemu ~/Downloads/TEST/debian-unstable.qcow2
>   autopkgtest [16:23:45]: version 5.11
>   autopkgtest [16:23:45]: host ${HOST}; command line: ${CMDLINE}
>   qemu-system-x86_64: terminating on signal 15 from pid 8488 
> (/usr/bin/python3)
>   : failure: timed out waiting for "login prompt on ttyS0"
>   autopkgtest [16:24:45]: ERROR: testbed failure: cannot send to testbed: 
> [Errno 32] Broken pipe
> 
> Could you help me to investigate the issue?
> Is the command line correct?  Where did I go wrong?

I can imagine two ways forward.

1. you can try the qcow2 image you built without autopkgtest by just running it
   inside qemu like so:

$ qemu-system-x86_64 -enable-kvm -m 512 -serial 
unix:/tmp/ttyS0,server,nowait -drive 
"file=$HOME/Downloads/TEST/debian-unstable.qcow2,cache=unsafe,if=virtio,index=0"

2. you could upload your qcow2 image somewhere together with the right
   SOURCE_DATE_EPOCH value that you used. Then I could try to reproduce that
   image myself and diff it against what I have because what I have here is
   working just fine. :)

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#950508: debos: broken in Buster: libresolv.so.2: cannot open shared object file

[Sascha Silbe]

Package: debos
Version: 1.0.0+git20190123.d6e16be-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after the upgrade to Buster debos stopped working. This happens even
with the minimal example from the man page. The output when run with
--show-boot suggests a shared library issue inside the VM:

sascha@brick:~$ debos --show-boot example.yaml 
[0.00] Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 
(2019-11-11)
[0.00] Command line: console=ttyS0 panic=-1 
systemd.unit=fakemachine.service
[...]
[0.713821] Run /init as init process
/bin/busybox: error while loading shared libraries: libresolv.so.2: cannot open 
shared object file: No such file or directory
[0.715660] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x7f00
[...]
[0.728779] Kernel Offset: 0x3800 from 0x8100 (relocation 
range: 0x8000-0xbfff)
open /tmp/fakemachine-785139448/result: no such file or directory
sascha@brick:~$

The same happens in a VM where I did a fresh install of debos so it's
very likely to affect all debos users on Buster (hence severity
grave).

Kind regards,
Sascha

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en:en_US:C:de_DE:de (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debos depends on:
ii  busybox1:1.30.1-4
ii  debootstrap1.0.114
ii  libc6  2.28-10
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libostree-1-1  2019.1-1
ii  qemu-system-x861:3.1+dfsg-8+deb10u3
ii  qemu-user-static   1:3.1+dfsg-8+deb10u3
ii  systemd-container  241-7~deb10u2

Versions of packages debos recommends:
ii  bmap-tools 3.5-2
ii  bzip2  1.0.6-9.2~deb10u1
ii  e2fsprogs  1.44.5-1+deb10u2
ii  linux-image-amd64  4.19+105+deb10u1
ii  mount  2.33.1-0.1
ii  ovmf   0~20181115.85588389-3
ii  parted 3.2-25
ii  udev   241-7~deb10u2
ii  xz-utils   5.2.4-1
ii  zip3.0-11+b1

debos suggests no packages.

-- no debconf information

Bug#950507: qmake cross wrapper should pass QMAKE_STRIP

[Helmut Grohne]

Package: qt5-qmake
Version: 5.12.5+dfsg-8
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:synthv1

The synthv1 package is one of the few that strips in the upstream build
system using qmake. It currently hard codes strip and should be using
$$QMAKE_STRIP instead. When it does so, it'll continue using the build
architecture strip, because the cross wrapper doesn't pass a host tool
here. Therefore the cross wrapper should also pass QMAKE_STRIP. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru qtbase-opensource-src-5.12.5+dfsg/debian/changelog 
qtbase-opensource-src-5.12.5+dfsg/debian/changelog
--- qtbase-opensource-src-5.12.5+dfsg/debian/changelog  2020-01-30 
22:03:38.0 +0100
+++ qtbase-opensource-src-5.12.5+dfsg/debian/changelog  2020-02-02 
19:34:30.0 +0100
@@ -1,3 +1,10 @@
+qtbase-opensource-src (5.12.5+dfsg-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * qmake cross wrapper should pass QMAKE_STRIP. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 02 Feb 2020 19:34:30 +0100
+
 qtbase-opensource-src (5.12.5+dfsg-8) unstable; urgency=medium
 
   * Revert adding alternative qtbase5-gles-dev dependencies:
diff --minimal -Nru 
qtbase-opensource-src-5.12.5+dfsg/debian/qmake-cross-wrapper.in 
qtbase-opensource-src-5.12.5+dfsg/debian/qmake-cross-wrapper.in
--- qtbase-opensource-src-5.12.5+dfsg/debian/qmake-cross-wrapper.in 
2020-01-30 22:03:38.0 +0100
+++ qtbase-opensource-src-5.12.5+dfsg/debian/qmake-cross-wrapper.in 
2020-02-02 19:34:26.0 +0100
@@ -16,6 +16,7 @@
QMAKE_CC=${CC:-@DEB_HOST_GNU_TYPE@-gcc} \
QMAKE_CXX=${CXX:-@DEB_HOST_GNU_TYPE@-g++} \
QMAKE_LINK=${CXX:-@DEB_HOST_GNU_TYPE@-g++} \
+   QMAKE_STRIP=${STRIP:-@DEB_HOST_GNU_TYPE@-strip} \
QMAKE_QMAKE=/usr/bin/@DEB_HOST_GNU_TYPE@-qmake \
PKG_CONFIG=@DEB_HOST_GNU_TYPE@-pkg-config \
-before \

Bug#948550: e2fsprogs 1.44.5-1+deb10u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 948550 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: e2fsprogs
Version: 1.44.5-1+deb10u3

Explanation: fix potential stack underflow in e2fsck [CVE-2019-5188]; fix use 
after free in e2fsck

Bug#944233: glib2.0 2.50.3-2+deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 944233 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: glib2.0
Version: 2.50.3-2+deb9u2

Explanation: ensure libdbus clients can authenticate with a GDBusServer like 
the one in ibus

Bug#950272: mariadb-10.3 10.3.22-0+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 950272 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: mariadb-10.3
Version: 10.3.22-0+deb10u1

Explanation: new upstream stable release [CVE-2019-2938 CVE-2019-2974 
CVE-2020-2574]

Bug#948695: openssh 7.9p1-10+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 948695 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: openssh
Version: 7.9p1-10+deb10u2

Explanation: deny (non-fatally) ipc in the seccomp sandbox, fixing failures 
with OpenSSL 1.1.1d and Linux < 3.19 on some architectures

Bug#948695: buster-pu: package openssh/1:7.9p1-10+deb10u2

[Cyril Brulebois]

Hi,

Adam D. Barratt  (2020-01-31):
> Given how close we are to the freeze for 10.3, feel free to upload and
> we'll hold the package in stable-new until KiBi has chance to check it.

Given the changelog entry (and given I'm not usually testing openssh
support inside d-i anyway, so I don't have any immediate ways to check
the runtime), feel free to accept.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#950166: buster-pu: package systemd/241-7~deb10u3

[Cyril Brulebois]

Cyril Brulebois  (2020-01-29):
> Based on the (as always appreciated) detailed analysis, feel free to go
> ahead, thanks.

FTAOD, testing looked good.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#944233: stretch-pu: package glib2.0/2.50.3-2+deb9u1

[Cyril Brulebois]

Hi,

Adam D. Barratt  (2019-12-07):
> Sorry for the delay. This looks OK to me, but will need a d-i ack as
> ever.

No obvious issues while testing, please go ahead.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#950505: RFS: moka-icon-theme/5.4.0.1-1 -- Tango-esque desktop icon set called Moka

[David Mohammed]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "moka-icon-theme"

 * Package name: moka-icon-theme
   Version : 5.4.0.1-1
   Upstream Author : Sam Hewitt 
 * URL : https://snwh.org/moka
 * License : CC-BY-SA-4.0 or GPL-3+
 * Vcs : https://github.com/UbuntuBudgie/moka-icon-theme/tree/debian
   Section : misc

It builds those binary packages:

  moka-icon-theme - Tango-esque desktop icon set called Moka

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

  https://mentors.debian.net/package/moka-icon-theme

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/moka-icon-theme/moka-icon-theme_5.4.0.1-1.dsc

Changes since the last upload:

   * New release
 - Soft-fork of upstream to expedite releases incorporating
   upstream pull-requests.
 - Add missing symlinks for gnome-notes, baobab, gnome-screenshot,
   gnome-fontviewer (LP: #1821004)
   Add missing symlinks for d-feet and system-monitor
   https://github.com/snwh/moka-icon-theme/pull/397
 - Add missing icon for livepatch
   https://github.com/snwh/moka-icon-theme/pull/401
 - Add missing icon for system-users
   https://github.com/snwh/moka-icon-theme/pull/397
 - Add symlinks for mainly GNOME based apps
   https://github.com/snwh/moka-icon-theme/pull/400
 - Add symlink for GNOME MPV
   https://github.com/snwh/moka-icon-theme/pull/398
 - Add symlnk for Rhythmbox
   https://github.com/snwh/moka-icon-theme/pull/415
 - Add symlink for Celluloid
   https://github.com/snwh/moka-icon-theme/pull/414
 - Add GNOME 3.32 icons
   https://github.com/snwh/moka-icon-theme/pull/410
 - fix mismatched sized unity-3d binaries resolving lintian issues
   * from upstream 5.4.0 release
 - Atom beta, xreader symlinks, tor browser, Unity 3D
   Slack, GIMP, Spotify, GNOME Games, retroarch,
   fprint_demo, smartgit
   * Packaging Changes:
 - copyright - year changes, full CC and debian changed to GPL-2+
 - control - bump Standards-Version - rules updated to be more verbose
 - control - debhelper changed to v12
 - control - add B-D meson for new source build system
 - remove compat
 - copyright - update year
 - upstream/metaupdate format change and new repo details
 - rules - remove executable bit from index.theme and tox
   to resolve lintian warnings
 - Update watch for new repo release
 - Add packager signing signature

Notes:

I am the debian maintainer of faba-icon-theme which this icon-theme is
dependent upon.  I also uploaded the current version of
moka-icon-theme into Debian.

Please accept this revised version of the theme.  It substantially
updated with the current available release version together with
several upstream pull requests to ensure GNOME 3.34 compatibility.

I have sbuild via unstable ensuring linitian
errors/warnings/information are resolved.  I have also run
check-all-the-things to double check all is well.

In addition to sponsoring this project - if appropriate I would like
to continue maintainership of this package
(assuming that it is acceptable to Debian) in a similar manner as my
current maintainership packages (dak fossfree...@ubuntu.com)


Regards,

--
  David Mohammed

Bug#948288: bugs 948288 and 950504 are related but not the same

[Md Ayquassar]

affects 948288 gdm3

affects 950504 gnome-shell

--


In http://bugs.debian.org/948288 , we deal with a segfault of gnome-shell and
Mesa issues using the default kernel command line without nomodeset. In
http://bugs.debian.org/950504, we deal with the boot process getting stuck when
nomodeset option in the kernel command line.

Bug#950506: shadowsocks-libev: Please backport patch on autopkgtest python3 migration

[Boyuan Yang]

Source: shadowsocks-libev
Version: 3.3.4+ds-1
Severity: normal
Tags: sid  bullseye  fixed-upstream
Forwarded: https://github.com/shadowsocks/shadowsocks-libev/pull/2611

Hi,

Downstream ubuntu just made an upload of 3.3.4+ds-1ubuntu1, in which the
autopkgtest dependency was explicitly set to be using python2 instead of
python. To solve the python2 migration issue more elegently, I worked with
upstream to have the test script migrated to python3 at 
https://github.com/shadowsocks/shadowsocks-libev/pull/2611 . I believe we
should include it either with a backported patch or through an upstream new
release.

-- 
Thanks,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part

Bug#913479: Sends genre 255 to eyeD3 taht is refused

[Marcel Dischinger]

Package: abcde
Version: 2.9.3-1
Followup-For: Bug #913479

You can avoid this error by setting
EYED3OPTS="--non-std-genres"
in your /etc/abcde.conf or ~/.abcde.conf

Regards,
Marcel

Bug#948288: gnome-shell reproducibly crashes on boot, and the boot process gets stuck

[Md Ayquassar]

Dear Bernhard,

As to what happens with nomodeset, I posted another bug report against gdm3:
http://bugs.debian.org/950504. There, we probably won't have to deal with a
gnome-shell segfault and Mesa issues that we have to deal with here.

Best regards,
Md Ayquassar

Bug#950504: gdm3 reproducibly gets stuck upon boot with nomodeset kernel setting: boot photos 1

[Md Ayquassar]

Here are some initial boot photos.

Bug#950111: libvigraimpex-doc: unhandled symlink to directory conversion: /usr/share/doc/libvigraimpex-dev/html

[Andreas Metzler]

On 2020-01-28 Andreas Beckmann  wrote:
> Package: libvigraimpex-doc
> Version: 1.11.1+dfsg-6
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts

> Hi,

> an upgrade test with piuparts revealed that your package installs files
> over existing symlinks and possibly overwrites files owned by other
> packages. This usually means an old version of the package shipped a
> symlink but that was later replaced by a real (and non-empty)
> directory. This kind of overwriting another package's files cannot be
> detected by dpkg.

> This was observed on the following upgrade paths:

>   buster -> bullseye
[...]
> It is recommended to use the dpkg-maintscript-helper commands
> 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
> to perform the conversion, ideally using d/$PACKAGE.maintscript.
> See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.

Hello Andreas,

thanks for report and pointers.

Afaiu (and that is what my tests showed) dpkg-maintscript-helper will
help me for upgrades from before-the-move to after-the-move but will not
fix the broken installations that have already upgraded from
before-the-move to 1.11.1+dfsg-6 and I will need to handle this
separately in the maintainerscripts. - Or am I missing something?

I have already got some draft packages, but they will probably not be
uploaded before next weekend.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#950502: linux-image-5.4.0-3-amd64: Issue with nvidia GP108M (X server startup + lscpi)

[mando]

Installing xserver-xorg-video-nvidia "solves" this problem: the X server 
starts and stops without freezing 10s.


(even if the module is not automatically loaded at boot + seems not 
support this card).


Best regards

Bug#949187: transition: python3.8

[Rene Engelhard]

On Sun, Feb 02, 2020 at 06:12:08PM +0100, Rene Engelhard wrote:
> Hi,
> 
> On Sun, Feb 02, 2020 at 06:07:29PM +0100, Matthias Klose wrote:
> > > e.g. fontforge is still red in
> > > https://release.debian.org/transitions/html/python3.8.html.
> > > 
> > > That means that a rebuild of stuff using fontforge in the build will
> > > just FTBFS since it will be called with python3.8 and that has no module
> > > for 3.8 (yet).
> > > 
> > > (Seen in a python-3.8-as-default testbuild for libreoffice some time
> > > ago.)
> > 
> > you are wrong. fontforge just builds for the default python version.
> 
> OK, maybe. But that also means that when python3.8 is default and
> fontforge isn't yet rebuilt for python3.8-as-default but some package
> from my list is rebuilt the same problem happens.

OK; inded it seems to just work. Maybe I even misremembered an it was
graphite2 and python3-fonttools. (Reused the chroot for multiple tests.)

But I *had* a module import failure when I tried some months ago.
Regards,
 
Rene

Bug#950493: steam:i386: Fails to install when using debconf priority critical

[Stephen Kitt]

On Sun, 02 Feb 2020 15:11:02 +, Witold Baryluk 
wrote:
> It DID NOT ask me anything about license at all.
> 
> Why do I need to accept steam license anyway explicitly anyway. I am
> requesting installation, so it is quite obvious.

It’s not obvious: there are license terms which don’t match what you’d expect
when installing a package in Debian. *You* might know that installing Steam
involves accepting a specific license, but the package maintainers can’t
expect that of all users.

> My debconf priority is 'critical'. But this totally looks like a question
> that needs to be asked, so it should be critical.

The priorities are defined as follows in debconf-devel(7):

high
Items that don't have a reasonable default.
critical
Items that will probably break the system without user intervention.

This isn’t something that would break the system, it’s a question for which
there is no reasonable default, so it’s priority “high”, not “critical”.

> If I change my debconf priority to high, and then retry, it asks me to
> agree and finishes successfully.

And I think that’s the more sensible approach. If you set your default
debconf priority to “critical”, you need to expect breakage of this sort,
given the priority definitions...

Regards,

Stephen


pgpGGnyBz4noo.pgp
Description: OpenPGP digital signature

Bug#950503: remove /banners subpage

[Thomas Lange]

Package: www.debian.org
Severity: normal
User: debian-...@lists.debian.org
Usertags: content

The page www.d.o/banners contain only very old content. Adding banners
to web pages is nowadays not used any more. The last banner was added
in 2007.

I see no reason to keep anything of this.

--
regards Thomas

Bug#947558: d1x-rebirth: diff for NMU version 0.58.1-1.1

[Stephen Kitt]

On Sun, 02 Feb 2020 02:44:51 +1100, Dmitry Smirnov  wrote:
> On Sunday, 2 February 2020 2:28:04 AM AEDT Stephen Kitt wrote:
> > I've prepared an NMU for d1x-rebirth (versioned as 0.58.1-1.1) and
> > uploaded it to DELAYED/5.  
> 
> Thank you very much for doing this, Stephen. Much appreciated.

You’re very welcome! I’ve just done the same for d2x-rebirth (with a very
similar patch). The srcdir handling at the end of SConstruct is dealt with in
a rather ham-fisted manner in my patches, but I couldn’t figure out the
proper fix in a reasonable amount of time...

Regards,

Stephen


pgpdtmMtYCBRJ.pgp
Description: OpenPGP digital signature

Bug#947559: d2x-rebirth: diff for NMU version 0.58.1-1.2

[Stephen Kitt]

Control: tags 947559 + patch
Control: tags 947559 + pending

Dear maintainer,

I've prepared an NMU for d2x-rebirth (versioned as 0.58.1-1.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,

Stephen
diff -Nru d2x-rebirth-0.58.1/debian/changelog d2x-rebirth-0.58.1/debian/changelog
--- d2x-rebirth-0.58.1/debian/changelog	2017-12-09 15:16:38.0 +0100
+++ d2x-rebirth-0.58.1/debian/changelog	2020-02-02 18:18:43.0 +0100
@@ -1,3 +1,10 @@
+d2x-rebirth (0.58.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Allow building with Python 3. Closes: #947559.
+
+ -- Stephen Kitt   Sun, 02 Feb 2020 18:18:43 +0100
+
 d2x-rebirth (0.58.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru d2x-rebirth-0.58.1/debian/patches/python3.patch d2x-rebirth-0.58.1/debian/patches/python3.patch
--- d2x-rebirth-0.58.1/debian/patches/python3.patch	1970-01-01 01:00:00.0 +0100
+++ d2x-rebirth-0.58.1/debian/patches/python3.patch	2020-02-02 18:18:43.0 +0100
@@ -0,0 +1,179 @@
+--- a/SConstruct
 b/SConstruct
+@@ -12,19 +12,8 @@
+ 	def get(self,name,value=None):
+ 		return self.ARGUMENTS.get('%s_%s' % (self.prefix, name), self.ARGUMENTS.get(name,value))
+ 
+-# endianess-checker
+-def checkEndian():
+-import struct
+-array = struct.pack('', '\x01', '\x02', '\x03', '\x04')
+-i = struct.unpack('i', array)
+-if i == struct.unpack('i', array):
+-return "big"
+-return "unknown"
+-
+ class DXXCommon:
+-	__endian = checkEndian()
++	__endian = sys.byteorder
+ 	class UserSettings:
+ 		def __init__(self,ARGUMENTS):
+ 			# Paths for the Videocore libs/includes on the Raspberry Pi
+@@ -57,7 +46,7 @@
+ 			builddir_suffix = ARGUMENTS.get('builddir_suffix', None)
+ 			default_builddir = builddir_prefix or ''
+ 			if builddir_prefix is not None or builddir_suffix is not None:
+-if os.environ.has_key('CC'):
++if 'CC' in os.environ:
+ 	default_builddir += '%s-' % os.path.basename(os.environ['CC'])
+ for a in (
+ 	('debug', 'dbg'),
+@@ -131,7 +120,7 @@
+ flags = self.__pkg_config_sdl[cmd]
+ 			except KeyError as e:
+ if (program.user_settings.verbosebuild != 0):
+-	print "%s: reading SDL settings from `%s`" % (program.PROGRAM_NAME, cmd)
++	print("%s: reading SDL settings from `%s`" % (program.PROGRAM_NAME, cmd))
+ self.__pkg_config_sdl[cmd] = env.backtick(cmd)
+ flags = self.__pkg_config_sdl[cmd]
+ 			env.MergeFlags(flags)
+@@ -156,31 +145,31 @@
+ 		self.env.Append(CPPDEFINES = ['NETWORK'])
+ 		# Get traditional compiler environment variables
+ 		for cc in ['CC', 'CXX']:
+-			if os.environ.has_key(cc):
++			if cc in os.environ:
+ self.env[cc] = os.environ[cc]
+ 		for flags in ['CFLAGS', 'CXXFLAGS']:
+-			if os.environ.has_key(flags):
++			if flags in os.environ:
+ self.env[flags] += SCons.Util.CLVar(os.environ[flags])
+ 
+ 	def check_endian(self):
+ 		# set endianess
+ 		if (self.__endian == "big"):
+-			print "%s: BigEndian machine detected" % self.PROGRAM_NAME
++			print("%s: BigEndian machine detected" % self.PROGRAM_NAME)
+ 			self.asm = 0
+ 			self.env.Append(CPPDEFINES = ['WORDS_BIGENDIAN'])
+ 		elif (self.__endian == "little"):
+-			print "%s: LittleEndian machine detected" % self.PROGRAM_NAME
++			print("%s: LittleEndian machine detected" % self.PROGRAM_NAME)
+ 
+ 	def check_platform(self):
+ 		# windows or *nix?
+ 		if sys.platform == 'win32':
+-			print "%s: compiling on Windows" % self.PROGRAM_NAME
++			print("%s: compiling on Windows" % self.PROGRAM_NAME)
+ 			platform = self.Win32PlatformSettings
+ 		elif sys.platform == 'darwin':
+-			print "%s: compiling on Mac OS X" % self.PROGRAM_NAME
++			print("%s: compiling on Mac OS X" % self.PROGRAM_NAME)
+ 			platform = self.DarwinPlatformSettings
+ 		else:
+-			print "%s: compiling on *NIX" % self.PROGRAM_NAME
++			print("%s: compiling on *NIX" % self.PROGRAM_NAME)
+ 			platform = self.LinuxPlatformSettings
+ 		self.platform_settings = platform(self.user_settings)
+ 		# Acquire environment object...
+@@ -194,15 +183,15 @@
+ 		# opengl or software renderer?
+ 		if (self.user_settings.opengl == 1) or (self.user_settings.opengles == 1):
+ 			if (self.user_settings.opengles == 1):
+-print "%s: building with OpenGL ES" % self.PROGRAM_NAME
++print("%s: building with OpenGL ES" % self.PROGRAM_NAME)
+ env.Append(CPPDEFINES = ['OGLES'])
+ 			else:
+-print "%s: building with OpenGL" % self.PROGRAM_NAME
++print("%s: building with OpenGL" % self.PROGRAM_NAME)
+ 			env.Append(CPPDEFINES = ['OGL'])
+ 
+ 		# assembler code?
+ 		if (self.user_settings.asm == 1) and (self.user_settings.opengl == 0):
+-			print "%s: including: ASSEMBLER" % self.PROGRAM_NAME
++			print("%s: including: ASSEMBLER" % self.PROGRAM_NAME)
+ 			env.Replace(AS = 'nasm')
+ 			env.Append(ASCOM = ' -f ' + str(self.platform_settings.osasmdef) + ' -d' + str(self.platform_settings.osdef) + ' -Itexmap/ ')
+ 			self.common_sources += 

Bug#950489: systemd: systemctl cat fails (assertion error) on inexistent templates

[Michael Biebl]

Am 02.02.20 um 15:02 schrieb Nicolas Braud-Santoni:

> systemctl cat currently fails with the following assertion error, on 
> inexistent
> unit templates:
> 
>   $ systemctl cat ssh@.service
>   Assertion 'name' failed at src/shared/dropin.c:143, function 
> unit_file_find_dirs(). Aborting.
>   [1]670974 abort  systemctl cat ssh@.service
> 

Thanks for the bug report. I can reproduce the issue.
Would you mind filing this upstream at
https://github.com/systemd/systemd/issues and reporting back with the
issue number?

Regards,
Michael






signature.asc
Description: OpenPGP digital signature

Bug#949187: transition: python3.8

[Rene Engelhard]

Hi,

On Sun, Feb 02, 2020 at 06:07:29PM +0100, Matthias Klose wrote:
> > e.g. fontforge is still red in
> > https://release.debian.org/transitions/html/python3.8.html.
> > 
> > That means that a rebuild of stuff using fontforge in the build will
> > just FTBFS since it will be called with python3.8 and that has no module
> > for 3.8 (yet).
> > 
> > (Seen in a python-3.8-as-default testbuild for libreoffice some time
> > ago.)
> 
> you are wrong. fontforge just builds for the default python version.

OK, maybe. But that also means that when python3.8 is default and
fontforge isn't yet rebuilt for python3.8-as-default but some package
from my list is rebuilt the same problem happens.

Then fontforge (which is not in the list below!) needs to be rebuilt before
https://release.debian.org/transitions/html/python3.8-default.html
is worked on.

Didn't see it there so wanted to go sure.

Regards,

Rene

Bug#950502: linux-image-5.4.0-3-amd64: Issue with nvidia GP108M (X server startup + lscpi)

[mando]

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

Dear Maintainer,

   * What led up to the situation?

I updated debian (bullseye) and restart the computer.

When running with the kernel provided by linux-image-5.3.0-3-amd64, X server 
and KDE runs and stops normally.

When running with the kernels provided by linux-image-5.4.0-2-amd64 and 
linux-image-5.4.0-3-amd64, X server remains black ~10s and then KDE appears.

More precisely with linux-image-5.4.0-3-amd64, if I run lspci, results are 
displayed after ~10s.
In the meantime /var/log/kern.log collects error:

Feb  2 18:00:35 aldur kernel: [  776.639741] [ cut here 
]
Feb  2 18:00:35 aldur kernel: [  776.639849] WARNING: CPU: 5 PID: 110 at 
drivers/gpu/drm/nouveau/nouveau_bo.c:1322 nouveau_bo_move_ntfy+0x87/0xe0 
[nouveau]
Feb  2 18:00:35 aldur kernel: [  776.639850] Modules linked in: ctr ccm rfcomm 
cmac bnep snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp coretemp 
kvm_intel intel_rapl_msr kvm iwlmvm snd_sof_pci snd_sof_intel_hda_common 
snd_sof_intel_hda irqbypass snd_sof_intel_byt snd_sof_intel_ipc mac80211 
snd_sof crct10dif_pclmul snd_sof_xtensa_dsp joydev snd_soc_skl libarc4 
snd_hda_codec_realtek btusb snd_soc_hdac_hda snd_hda_ext_core btrtl 
snd_soc_sst_ipc btbcm snd_soc_sst_dsp btintel snd_hda_codec_generic 
snd_soc_acpi_intel_match snd_soc_acpi ghash_clmulni_intel ledtrig_audio iwlwifi 
bluetooth nls_ascii snd_soc_core nls_cp437 aesni_intel snd_compress 
snd_hda_intel snd_intel_nhlt uvcvideo snd_hda_codec crypto_simd cryptd vfat 
glue_helper videobuf2_vmalloc videobuf2_memops fat snd_hda_core intel_cstate 
asus_nb_wmi efi_pstore drbg videobuf2_v4l2 cfg80211 intel_uncore 
videobuf2_common asus_wmi snd_hwdep videodev intel_rapl_perf snd_pcm ansi_cprng 
snd_timer iTCO_wdt sparse_keymap pcspkr iTCO_vendor_support snd
Feb  2 18:00:35 aldur kernel: [  776.639889]  processor_thermal_device mei_me 
serio_raw ecdh_generic ecc intel_rapl_common efivars wmi_bmof watchdog mc 
soundcore hid_multitouch mei intel_soc_dts_iosf rfkill intel_pch_thermal 
tpm_crb ac tpm_tis int3403_thermal tpm_tis_core int340x_thermal_zone 
int3400_thermal tpm acpi_thermal_rel evdev rng_core acpi_tad acpi_pad 
parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 ext4 crc16 
mbcache jbd2 crc32c_generic hid_generic usbhid spi_pxa2xx_platform dw_dmac 
i2c_designware_platform dw_dmac_core i2c_designware_core nouveau i915 ttm 
i2c_algo_bit drm_kms_helper xhci_pci xhci_hcd crc32_pclmul nvme drm mxm_wmi 
usbcore crc32c_intel nvme_core i2c_i801 i2c_hid intel_lpss_pci hid intel_lpss 
idma64 mfd_core usb_common battery wmi video button
Feb  2 18:00:35 aldur kernel: [  776.639929] CPU: 5 PID: 110 Comm: kworker/5:1 
Tainted: GW 5.4.0-3-amd64 #1 Debian 5.4.13-1
Feb  2 18:00:35 aldur kernel: [  776.639931] Hardware name: ASUSTeK COMPUTER 
INC. ZenBook UX433FN_UX433FN/UX433FN, BIOS UX433FN.308 07/15/2019
Feb  2 18:00:35 aldur kernel: [  776.639938] Workqueue: pm pm_runtime_work
Feb  2 18:00:35 aldur kernel: [  776.640028] RIP: 
0010:nouveau_bo_move_ntfy+0x87/0xe0 [nouveau]
Feb  2 18:00:35 aldur kernel: [  776.640032] Code: ff 85 c0 75 25 48 89 df e8 
06 6b 00 00 48 8b 43 10 48 8d 58 f0 49 39 c4 74 ab 31 d2 31 f6 48 89 ef e8 fd 
10 d0 ff 85 c0 74 db <0f> 0b eb d7 48 3d f0 98 98 c0 75 8f 48 8b 87 28 03 00 00 
4c 8d a7
Feb  2 18:00:35 aldur kernel: [  776.640034] RSP: 0018:acc480f47b18 EFLAGS: 
00010286
Feb  2 18:00:35 aldur kernel: [  776.640036] RAX: fff0 RBX: 
935059ca91c0 RCX: 
Feb  2 18:00:35 aldur kernel: [  776.640038] RDX: 0002 RSI: 
935032d09758 RDI: 0001
Feb  2 18:00:35 aldur kernel: [  776.640039] RBP: 935056365400 R08: 
935032d09730 R09: 93505db6b110
Feb  2 18:00:35 aldur kernel: [  776.640041] R10: 0009 R11: 
93505db69580 R12: 935056365728
Feb  2 18:00:35 aldur kernel: [  776.640042] R13: 935010cf3200 R14: 
0001 R15: acc480f47cd0
Feb  2 18:00:35 aldur kernel: [  776.640044] FS:  () 
GS:93505db4() knlGS:
Feb  2 18:00:35 aldur kernel: [  776.640046] CS:  0010 DS:  ES:  CR0: 
80050033
Feb  2 18:00:35 aldur kernel: [  776.640048] CR2: 7f1f89625008 CR3: 
00021420a002 CR4: 003606e0
Feb  2 18:00:35 aldur kernel: [  776.640049] Call Trace:
Feb  2 18:00:35 aldur kernel: [  776.640066]  ttm_bo_handle_move_mem+0xd2/0x5a0 
[ttm]
Feb  2 18:00:35 aldur kernel: [  776.640074]  ttm_bo_evict+0x166/0x1e0 [ttm]
Feb  2 18:00:35 aldur kernel: [  776.640106]  ? drm_i2c_encoder_init+0x86/0xe0 
[drm]
Feb  2 18:00:35 aldur kernel: [  776.640114]  ttm_mem_evict_first+0x26c/0x360 
[ttm]
Feb  2 18:00:35 aldur kernel: [  776.640120]  
ttm_bo_force_list_clean+0xa4/0x180 [ttm]
Feb  2 18:00:35 aldur kernel: [  776.640211]  nouveau_do_suspend+0x80/0x170 
[nouveau]
Feb  2 18:00:35 aldur kernel: [  776.640295]  
nouveau_pmops_runtime_suspend+0x40/0xa0 

Bug#949187: transition: python3.8

[Rene Engelhard]

On Sun, Feb 02, 2020 at 05:53:37PM +0100, Rene Engelhard wrote:
> On Sun, Feb 02, 2020 at 09:35:04AM +0100, Matthias Klose wrote:
> > > On 17-01-2020 23:28, Matthias Klose wrote:
> > >> Please add a transition tracker to switch the python3 default to 3.8.  
> > >> It's not
> > >> yet ready, however it would be good to see affected packages. Please 
> > >> copy it
> > >> from the 3.7 defaults change if possible.
> > > 
> > > Tracker is in place. Please remove the moreinfo tag when you're ready.
> > 
> > I think this is now in shape to be started. bug reports have been filed for
> 
> I don't think so.
> 
> e.g. fontforge is still red in
> https://release.debian.org/transitions/html/python3.8.html.
> 
> That means that a rebuild of stuff using fontforge in the build will
> just FTBFS since it will be called with python3.8 and that has no module
> for 3.8 (yet).

$ grep-dctrl fontforge -FBuild-Depends 
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources | 
grep-dctrl python3 -FBuild-Depends -sPackage
Package: diffoscope
Package: fonts-allerta
Package: fonts-courier-prime
Package: fonts-gotico-antiqua
Package: fonts-junicode
Package: fonts-karmilla
Package: fonts-le-murmure
Package: fonts-rit-sundar
Package: fonts-smc-anjalioldlipi
Package: fonts-smc-dyuthi
Package: fonts-smc-karumbi
Package: fonts-smc-keraleeyam
Package: fonts-smc-meera
Package: fonts-smc-rachana
Package: fonts-smc-raghumalayalamsans
Package: fonts-smc-uroob
Package: fonts-solide-mirage
Package: libreoffice
Package: mftrace
Package: searx

Regards,
 
Rene

Bug#949187: transition: python3.8

[Matthias Klose]

On 2/2/20 5:53 PM, Rene Engelhard wrote:
> On Sun, Feb 02, 2020 at 09:35:04AM +0100, Matthias Klose wrote:
>>> On 17-01-2020 23:28, Matthias Klose wrote:
 Please add a transition tracker to switch the python3 default to 3.8.  
 It's not
 yet ready, however it would be good to see affected packages. Please copy 
 it
 from the 3.7 defaults change if possible.
>>>
>>> Tracker is in place. Please remove the moreinfo tag when you're ready.
>>
>> I think this is now in shape to be started. bug reports have been filed for
> 
> I don't think so.
> 
> e.g. fontforge is still red in
> https://release.debian.org/transitions/html/python3.8.html.
> 
> That means that a rebuild of stuff using fontforge in the build will
> just FTBFS since it will be called with python3.8 and that has no module
> for 3.8 (yet).
> 
> (Seen in a python-3.8-as-default testbuild for libreoffice some time
> ago.)

you are wrong. fontforge just builds for the default python version.

Bug#950501: Create a separate package libqtcreator-plugin-dev for the files needed for building plugins

[KOLANICH]

Package: qtcreator
Version: any

When I wanna build a plugin for qtcreator I have to download its whole source 
and do some manual actions like writing paths to the dir where it is 
downloaded. This is not very suitable for CI-automated builds.

Could a package be create with the files needed to build plugins only residing 
in some immutable location not containing version number in its path? 

Bug#950500: aqbanking-tools: aqpaypal-tool unable to call any control function

[Charlemagne Lasse]

Package: aqbanking-tools
Version: 6.0.1-2
Tags: patch

The libaqbanking44 or the aqbanking-tools are currently incompatible
with each other when calling the aqpaypal backend

aqpaypal-tool  fff
3:2020/02/02 17-39-18:aqpaypal-tool(16869):aqpaypal-tool.c:  246:
Error calling control function (-51)

It can be solved by changing --with-backends="aqnone aqhbci
aqofxconnect aqebics" in debian/rules to --with-backends="aqnone
aqhbci aqofxconnect aqebics aqpaypal"

Bug#949187: transition: python3.8

[Rene Engelhard]

On Sun, Feb 02, 2020 at 09:35:04AM +0100, Matthias Klose wrote:
> > On 17-01-2020 23:28, Matthias Klose wrote:
> >> Please add a transition tracker to switch the python3 default to 3.8.  
> >> It's not
> >> yet ready, however it would be good to see affected packages. Please copy 
> >> it
> >> from the 3.7 defaults change if possible.
> > 
> > Tracker is in place. Please remove the moreinfo tag when you're ready.
> 
> I think this is now in shape to be started. bug reports have been filed for

I don't think so.

e.g. fontforge is still red in
https://release.debian.org/transitions/html/python3.8.html.

That means that a rebuild of stuff using fontforge in the build will
just FTBFS since it will be called with python3.8 and that has no module
for 3.8 (yet).

(Seen in a python-3.8-as-default testbuild for libreoffice some time
ago.)

Regards,

Rene

Bug#950496: msgpack-c: FTBFS on 32-bit: error: narrowing conversion of ‘4294967295’ from ‘long unsigned int’ to ‘__time_t’ {aka ‘long int’}

[James McCoy]

Control: tag -1 fixed-upstream

On Sun, Feb 02, 2020 at 04:47:26PM +0100, Andreas Beckmann wrote:
> msgpack-c/experimental on all 32-bit architectures:
> https://buildd.debian.org/status/package.php?p=msgpack-c=experimental

Yes, that and #950460 are the main reasons I haven't uploaded this to
unstable yet.

Upstream already has a fix, which I was already working on backporting.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#950499: Samba - CVE-2019-19344

[Maurizio Cimaschi]

Package: samba
Version: 2:4.9.5+dfsg-5+deb10u1
Severity: wishlist

Dear Maintainer,
in the shipped version of samba the DNS scavenging function is broken:

https://www.samba.org/samba/security/CVE-2019-19344.html
https://security-tracker.debian.org/tracker/CVE-2019-19344

A patch already exists:

https://github.com/samba-team/samba/commit/55fb0c2f67ef1906c942729c00f9f918dd92a658

Please, could the patch be applied to the package ?

Thank you for you work and interest in this report.

Regards.


-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf present, but not attached

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages samba depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libbsd0   0.9.1-2
ii  libc6 2.28-10
ii  libldb1   2:1.5.1+really1.4.6-3
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpopt0  1.16-12
ii  libpython2.7  2.7.16-2+deb10u1
ii  libtalloc22.1.14-2
ii  libtdb1   1.3.16-2+b1
ii  libtevent00.9.37-1
ii  lsb-base  10.2019051400
ii  procps2:3.3.15-2
ii  python2.7.16-1
ii  python-dnspython  1.16.0-1
ii  python-samba  2:4.9.5+dfsg-5+deb10u1
ii  python2.7 2.7.16-2+deb10u1
ii  samba-common  2:4.9.5+dfsg-5+deb10u1
ii  samba-common-bin  2:4.9.5+dfsg-5+deb10u1
ii  samba-libs2:4.9.5+dfsg-5+deb10u1
ii  tdb-tools 1.3.16-2+b1

Versions of packages samba recommends:
pn  attr
ii  logrotate   3.14.0-4
ii  samba-dsdb-modules  2:4.9.5+dfsg-5+deb10u1
ii  samba-vfs-modules   2:4.9.5+dfsg-5+deb10u1

Versions of packages samba suggests:
ii  bind9  1:9.11.5.P4+dfsg-5.1
ii  bind9utils 1:9.11.5.P4+dfsg-5.1
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.8p12+dfsg-4
pn  smbldap-tools  
pn  ufw
ii  winbind2:4.9.5+dfsg-5+deb10u1

-- no debconf information

Bug#949367: stretch-pu: package wpa/2:2.4-1+deb9u5

[Cyril Brulebois]

Hi,

And apologies for the delay.

Adam D. Barratt  (2020-01-20):
> On Mon, 2020-01-20 at 10:02 +0100, Andrej Shadura wrote:
> >  wpa (2:2.4-1+deb9u5) stretch; urgency=medium
> >  .
> >* SECURITY UPDATE:
> >  - AP mode PMF disconnection protection bypass.
> >More details:
> > + https://w1.fi/security/2019-7/
> >Closes: #940080 (CVE-2019-16275)
> > 
> 
> As wpa builds a udeb, this will need a d-i ack. Tagging and CCing to
> that end.

Trying to build the binaries to get that tested in a d-i environment, I
ended up with a build failure:
| x86_64-linux-gnu-gcc -Wl,-z,relro -Wl,-z,now -Wl,--as-needed-o 
wpa_supplicant config.o notify.o bss.o eap_register.o ../src/utils/common.o 
../src/utils/wpa_debug.o ../src/utils/wpabuf.o wmm_ac.o ../src/utils/os_unix.o 
../src/utils/eloop.o config_file.o ../src/rsn_supp/wpa_ft.o wnm_sta.o 
../src/rsn_supp/tdls.o ../src/rsn_supp/wpa.o ../src/rsn_supp/preauth.o 
../src/rsn_supp/pmksa_cache.o ../src/rsn_supp/peerkey.o 
../src/rsn_supp/wpa_ie.o ../src/common/wpa_common.o ibss_rsn.o p2p_supplicant.o 
../src/p2p/p2p.o ../src/p2p/p2p_utils.o ../src/p2p/p2p_parse.o 
../src/p2p/p2p_build.o ../src/p2p/p2p_go_neg.o ../src/p2p/p2p_sd.o 
../src/p2p/p2p_pd.o ../src/p2p/p2p_invitation.o ../src/p2p/p2p_dev_disc.o 
../src/p2p/p2p_group.o ../src/ap/p2p_hostapd.o ../src/utils/bitfield.o 
wifi_display.o ../src/eap_peer/eap_tls.o ../src/eap_peer/eap_peap.o 
../src/eap_common/eap_peap_common.o ../src/eap_peer/eap_ttls.o 
../src/eap_peer/eap_md5.o ../src/eap_peer/eap_mschapv2.o 
../src/eap_peer/mschapv2.o ../src/eap_peer/eap_gtc.o ../src/eap_peer/eap_otp.o 
../src/eap_peer/eap_sim.o ../src/eap_peer/eap_leap.o ../src/eap_peer/eap_psk.o 
../src/eap_common/eap_psk_common.o ../src/eap_peer/eap_aka.o 
../src/eap_common/eap_sim_common.o ../src/eap_peer/eap_fast.o 
../src/eap_peer/eap_fast_pac.o ../src/eap_common/eap_fast_common.o 
../src/eap_peer/eap_pax.o ../src/eap_common/eap_pax_common.o 
../src/eap_peer/eap_sake.o ../src/eap_common/eap_sake_common.o 
../src/eap_peer/eap_gpsk.o ../src/eap_common/eap_gpsk_common.o 
../src/eap_peer/eap_pwd.o ../src/eap_common/eap_pwd_common.o 
../src/eap_peer/eap_eke.o ../src/eap_common/eap_eke_common.o wps_supplicant.o 
../src/utils/uuid.o ../src/eap_peer/eap_wsc.o 
../src/eap_common/eap_wsc_common.o ../src/wps/wps.o ../src/wps/wps_common.o 
../src/wps/wps_attr_parse.o ../src/wps/wps_attr_build.o 
../src/wps/wps_attr_process.o ../src/wps/wps_dev_attr.o 
../src/wps/wps_enrollee.o ../src/wps/wps_registrar.o ../src/wps/ndef.o 
../src/wps/wps_er.o ../src/wps/wps_er_ssdp.o ../src/wps/wps_upnp.o 
../src/wps/wps_upnp_ssdp.o ../src/wps/wps_upnp_web.o 
../src/wps/wps_upnp_event.o ../src/wps/wps_upnp_ap.o ../src/wps/upnp_xml.o 
../src/wps/httpread.o ../src/wps/http_client.o ../src/wps/http_server.o 
../src/eap_peer/eap_ikev2.o ../src/eap_peer/ikev2.o 
../src/eap_common/eap_ikev2_common.o ../src/eap_common/ikev2_common.o 
../src/eap_peer/eap_tnc.o ../src/eap_peer/tncc.o 
../src/eapol_supp/eapol_supp_sm.o ../src/eap_peer/eap.o 
../src/eap_peer/eap_methods.o ap.o ../src/ap/hostapd.o 
../src/ap/wpa_auth_glue.o ../src/ap/utils.o ../src/ap/authsrv.o 
../src/ap/ap_config.o ../src/utils/ip_addr.o ../src/ap/sta_info.o 
../src/ap/tkip_countermeasures.o ../src/ap/ap_mlme.o ../src/ap/ieee802_1x.o 
../src/eapol_auth/eapol_auth_sm.o ../src/ap/ieee802_11_auth.o 
../src/ap/ieee802_11_shared.o ../src/ap/drv_callbacks.o ../src/ap/ap_drv_ops.o 
../src/ap/beacon.o ../src/ap/bss_load.o ../src/ap/eap_user_db.o 
../src/ap/ieee802_11_ht.o ../src/ap/ieee802_11_vht.o ../src/ap/wnm_ap.o 
../src/ap/ctrl_iface_ap.o ../src/eap_server/eap_server.o 
../src/eap_server/eap_server_identity.o ../src/eap_server/eap_server_methods.o 
../src/ap/wmm.o ../src/ap/ap_list.o ../src/ap/ieee802_11.o 
../src/ap/hw_features.o ../src/ap/dfs.o ../src/ap/wps_hostapd.o 
../src/eap_server/eap_server_wsc.o ../src/ap/wpa_auth.o ../src/ap/wpa_auth_ie.o 
../src/ap/pmksa_cache_auth.o ../src/ap/wpa_auth_ft.o ../src/ap/peerkey_auth.o 
../src/utils/pcsc_funcs.o ../src/crypto/ms_funcs.o ../src/eap_common/chap.o 
../src/eap_peer/eap_tls_common.o ../src/crypto/tls_openssl.o 
../src/crypto/crypto_openssl.o ../src/crypto/fips_prf_openssl.o  
../src/crypto/aes-eax.o ../src/crypto/aes-ctr.o ../src/crypto/aes-encblock.o 
../src/crypto/aes-omac1.o ../src/crypto/aes-cbc.o   ../src/crypto/sha256-prf.o 
../src/crypto/dh_groups.o ../src/crypto/random.o ctrl_iface.o ctrl_iface_unix.o 
dbus/dbus_old.o dbus/dbus_old_handlers.o dbus/dbus_old_handlers_wps.o 
dbus/dbus_dict_helpers.o dbus/dbus_new_helpers.o dbus/dbus_new.o 
dbus/dbus_new_handlers.o dbus/dbus_new_handlers_wps.o 
dbus/dbus_new_handlers_p2p.o dbus/dbus_new_introspect.o dbus/dbus_common.o 
../src/utils/base64.o sme.o ../src/common/ieee802_11_common.o 
../src/common/hw_features_common.o ../src/eap_common/eap_common.o 
../src/crypto/sha1-prf.o ../src/crypto/sha1-tprf.o ../src/crypto/sha1-tlsprf.o  
bgscan_simple.o bgscan.o autoscan_exponential.o 

Bug#948550: buster-pu: package e2fsprogs/1.44.5-1+deb10u2

[Cyril Brulebois]

Hi,

Adam D. Barratt  (2020-01-21):
> Control: tags -1 + confirmed d-i
> 
> On Thu, 2020-01-09 at 22:34 -0500, Theodore Y. Ts'o wrote:
> > +e2fsprogs (1.44.5-1+deb10u3) buster; urgency=medium
> > +
> > +  * Fix CVE-2019-5188: potential stack underflow in e2fsck (Closes:
> > #948508)
> > +  * Fix use after free in e2fsck (Closes: #948517)
> > 
> 
> This looks OK to me, but will also need a d-i ACK as e2fsprogs produces
> a udeb; CCing and tagging to reflect that.

Thanks for your patience.

Testing looks good, feel free to accept.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#931173: (no subject)

[Jonathan Michalon]

FTR an easy workaround is to link a valid/recognised name to the one
created by cloud-init:
ln-s /etc/network/interfaces.d/50-cloud-init.cfg 
/etc/network/interfaces.d/50-cloud-init

This is also sufficient to avoid having the duplicate in /run so the
fix in 19.3 should be sufficient for both problems.

Thanks for tracking this :)

Bug#950498: RM: zeitgeist/experimental -- RoQA; NVIU; python3-zeitgeist was fixed and not removed in sid

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Please get rid of the broken zeitgeist in experimental.
That weird version number was intended to keep the buggy
python3-zeitgeist package in experimental while it gets removed from
sid, but the removal didn't happen because it got fixed in sid instead.

Andreas

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Francesco Poli]

On Sun, 02 Feb 2020 00:23:59 +0100 Johannes Schauer wrote:

> Quoting Francesco Poli (2020-02-01 16:52:47)
> > The only differences shown in the resulting report_diffoscope.html file seem
> > to be:
> > 
> >   • the generated files in the content
> > of ./boot/initrd.img-5.4.0-3-amd64 have differing creation
> > timestamps (but this is obvious, since the two initrd were not
> > created exactly at the same time!)
> > 
> >   • ./var/lib/initramfs-tools/5.4.0-3-amd64 files differ (but they seem
> > to include some checksum of the initrd, hence the difference should
> > be consequence of the first point)
> 
> this should go away when you set SOURCE_DATE_EPOCH to something like $(date
> +%s) -- why didn't you set it in your tests?

It's plain simple: because I am an idiot!  ;-)
I just failed to think about it...

After setting the same SOURCE_DATE_EPOCH, the only remaining
differences were the machine-id and the hashlib.cpython-37.pyc file!

> 
> >   • ./etc/machine-id and ./var/lib/dbus/machine-id files differ (but I
> > think this should not be surprising...)
> 
> In the next mmdebstrap release /etc/machine-id will be set to an empty file.

OK.

> 
> >   • ./usr/lib/python3.7/__pycache__/hashlib.cpython-37.pyc files have
> > some different hex values (I am not sure why, but it's compiled
> > Python code, maybe it includes a compilation timestamp or
> > something?!?)
> 
> This is a known bug that I have yet to report to the Python maintainers.

Ah, interesting.
I encourage you to report this bug, as it might help the Reproducible
Builds effort...

> 
> > I am under the impression that the two .tar files are to be considered
> > equivalent.
> > Do you agree?
> 
> Yes. :)

OK, in the meanwhile I got around to check whether the .qcow2 image is
actually working as autopkgtest testbed.

Unfortunately, no, it's not working!  :-(


  $ autopkgtest --output-dir ./${PKG}_${VERS}_autopkgtest.out \
   --summary ./${PKG}_${VERS}_autopkgtest.summary \
  -B ./${PKG}_${VERS}_amd64.changes \
-- qemu ~/Downloads/TEST/debian-unstable.qcow2
  autopkgtest [16:23:45]: version 5.11
  autopkgtest [16:23:45]: host ${HOST}; command line: ${CMDLINE}
  qemu-system-x86_64: terminating on signal 15 from pid 8488 (/usr/bin/python3)
  : failure: timed out waiting for "login prompt on ttyS0"
  autopkgtest [16:24:45]: ERROR: testbed failure: cannot send to testbed: 
[Errno 32] Broken pipe

Could you help me to investigate the issue?
Is the command line correct?
Where did I go wrong?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp86n5EiaIx2.pgp
Description: PGP signature

Bug#950497: ITP: puppet-module-puppetlabs-host-core -- Puppet module for managing /etc/hosts file

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-puppetlabs-host-core
  Version : 1.0.3
  Upstream Author : Puppet labs Inc.
* URL : https://github.com/puppetlabs/puppetlabs-host_core
* License : Apache-2.0
  Programming Lang: Puppet, Ruby
  Description : Puppet module for managing /etc/hosts file

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 The host_core module is used to manage host entries in a hosts file. For most
 systems, the hosts file is located in /etc/hosts.

Note: this package will be needed for puppet 6, which is not embedding this
code anymore.

Bug#950496: msgpack-c: FTBFS on 32-bit: error: narrowing conversion of ‘4294967295’ from ‘long unsigned int’ to ‘__time_t’ {aka ‘long int’}

[Andreas Beckmann]

Package: msgpack-c
Version: 3.2.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

msgpack-c/experimental on all 32-bit architectures:
https://buildd.debian.org/status/package.php?p=msgpack-c=experimental

[17/122] /usr/bin/c++   -I../build-gtest/install/include -I../include -Iinclude 
-DMSGPACK_DEFAULT_API_VERSION=3 -std=c++11 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2-Wall -Wextra 
-Wconversion -MD -MT test/CMakeFiles/msgpack_cpp11.dir/msgpack_cpp11.cpp.o -MF 
test/CMakeFiles/msgpack_cpp11.dir/msgpack_cpp11.cpp.o.d -o 
test/CMakeFiles/msgpack_cpp11.dir/msgpack_cpp11.cpp.o -c 
../test/msgpack_cpp11.cpp
FAILED: test/CMakeFiles/msgpack_cpp11.dir/msgpack_cpp11.cpp.o 
/usr/bin/c++   -I../build-gtest/install/include -I../include -Iinclude 
-DMSGPACK_DEFAULT_API_VERSION=3 -std=c++11 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2-Wall -Wextra 
-Wconversion -MD -MT test/CMakeFiles/msgpack_cpp11.dir/msgpack_cpp11.cpp.o -MF 
test/CMakeFiles/msgpack_cpp11.dir/msgpack_cpp11.cpp.o.d -o 
test/CMakeFiles/msgpack_cpp11.dir/msgpack_cpp11.cpp.o -c 
../test/msgpack_cpp11.cpp
../test/msgpack_cpp11.cpp: In member function ‘virtual void 
MSGPACK_TIMESPEC_timespec_pack_convert_32bit_sec_Test::TestBody()’:
../test/msgpack_cpp11.cpp:1081:36: error: narrowing conversion of ‘4294967295’ 
from ‘long unsigned int’ to ‘__time_t’ {aka ‘long int’} [-Wnarrowing]
 1081 | timespec val1{ 0xUL, 0 };
  |^
../test/msgpack_cpp11.cpp: In member function ‘virtual void 
MSGPACK_TIMESPEC_timespec_object_with_zone_32bit_sec_Test::TestBody()’:
../test/msgpack_cpp11.cpp:1097:36: error: narrowing conversion of ‘4294967295’ 
from ‘long unsigned int’ to ‘__time_t’ {aka ‘long int’} [-Wnarrowing]
 1097 | timespec val1{ 0xUL, 0 };
  |^


Andreas

Bug#950494: /usr/bin/unattended-upgrade: unattended-upgrade sets speed to 70kbps even for manual apt runs

[Bálint Réczey]

Control: severity -1 wishlist
Control: tags -1 confirmed newcomer

Oliver  ezt írta (időpont: 2020. febr. 2., V, 16:27):
>
> Package: unattended-upgrades
> Version: 1.16
> Severity: normal
> File: /usr/bin/unattended-upgrade
>
> Dear Maintainer,
>
> For the last few weeks, apt has been extremely slow on my machine,
> downloading packages at about 70 kbps give or take, and making the
> installation of larger software packages very painful.
>
> This is caused by a line in /etc/apt/apt.conf.d/50unattended-upgrades:
>
> =
> // Use apt bandwidth limit feature, this example limits the download
> // speed to 70kb/sec
> Acquire::http::Dl-Limit "70";
> =
>
> Commenting out this line restores apt's speeds.
>
> I understand the utility of limiting download speeds for unattended-upgrades,
> but I would not have expected this configuration to be applied to all usage
> of apt (including outside of unattended-upgrades) by default.

Yes, it should be at leas clarified in the configuration file.
For the record in the default configuration the limit is not set.

Cheers,
Balint

>
> Thank you for your consideration.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages unattended-upgrades depends on:
> ii  debconf [debconf-2.0]  1.5.73
> ii  lsb-base   11.1.0
> ii  lsb-release11.1.0
> ii  python33.7.5-3
> ii  python3-apt1.8.4+b1
> ii  python3-dbus   1.2.14-1
> ii  python3-distro-info0.22
> ii  ucf3.0038+nmu1
> ii  xz-utils   5.2.4-1+b1
>
> Versions of packages unattended-upgrades recommends:
> ii  anacron 2.3-29
> ii  cron [cron-daemon]  3.0pl1-135
> ii  systemd-sysv244-3
>
> Versions of packages unattended-upgrades suggests:
> pn  bsd-mailx  
> ii  exim4-daemon-light [mail-transport-agent]  4.93-3
> ii  needrestart3.4-5
> ii  powermgmt-base 1.36
> ii  python3-gi 3.34.0-3
>
> -- debconf information:
>   unattended-upgrades/enable_auto_updates: true
>

Bug#950495: /usr/bin/xdg-settings: 735: Bad substitution

[luca]

Package: xdg-utils
Version: 1.1.3-1
Severity: normal

Dear Maintainer,

$ sh -x /usr/bin/xdg-settings check default-web-browser firefox.desktop
+ check_common_commands check default-web-browser firefox.desktop
+ [ 3 -gt 0 ]
+ parm=check
+ shift
+ [ 2 -gt 0 ]
+ parm=default-web-browser
+ shift
+ [ 1 -gt 0 ]
+ parm=firefox.desktop
+ shift
+ [ 0 -gt 0 ]
+ [ -z  ]
+ unset XDG_UTILS_DEBUG_LEVEL
+ [ 0 -lt 1 ]
+ xdg_redirect_output= > /dev/null 2> /dev/null
+ [ xcheck = x--list ]
+ [ xcheck != x ]
+ [ xdefault-web-browser != x ]
+ [ xcheck = xget -o xfirefox.desktop != x ]
+ op=check
+ parm=default-web-browser
+ shift 2
+ [ xcheck != xget -a xcheck != xcheck -a xcheck != xset ]
+ detectDE
+ unset GREP_OPTIONS
+ [ -n KDE ]
+ DE=kde
+ [ xkde = x ]
+ [ xkde = x ]
+ [ xkde = x ]
+ [ xkde = xgnome ]
+ [ -f /run/user/500/flatpak-info ]
+ [ -z kde ]
+ dispatch_specific kde firefox.desktop
+ local handler=kde
+ shift
+ [ xcheck = xget ]
+ [ xcheck = xcheck ]
+ check_desktop_filename firefox.desktop
+ return
+ check_browser_kde firefox.desktop
+ desktop_file_to_binary firefox.desktop
+ search=/home/ilprof/.local/share:/usr/share:/usr/share:/usr/local/share
+ basename firefox.desktop
+ desktop=firefox.desktop
+ IFS=:
+ unset IFS
+ [ /home/ilprof/.local/share ]
+ [ -d /home/ilprof/.local/share/applications ]
+ [ firefox.desktop != firefox.desktop ]
+ test -z
+ file=/home/ilprof/.local/share/applications//firefox.desktop
+ [ -r /home/ilprof/.local/share/applications//firefox.desktop ]
+ file=/home/ilprof/.local/share/applications/javaws//firefox.desktop
+ [ -r /home/ilprof/.local/share/applications/javaws//firefox.desktop ]
+ file=/home/ilprof/.local/share/applications/wine//firefox.desktop
+ [ -r /home/ilprof/.local/share/applications/wine//firefox.desktop ]
+ file=/home/ilprof/.local/share/applnk//firefox.desktop
+ [ -r /home/ilprof/.local/share/applnk//firefox.desktop ]
+ file=/home/ilprof/.local/share/applnk/*//firefox.desktop
+ [ -r /home/ilprof/.local/share/applnk/*//firefox.desktop ]
+ [ -r  ]
+ unset IFS
+ [ /usr/share ]
+ [ -d /usr/share/applications ]
+ [ firefox.desktop != firefox.desktop ]
+ test -z
+ file=/usr/share/applications//firefox.desktop
+ [ -r /usr/share/applications//firefox.desktop ]
+ file_path=/usr/share/applications//firefox.desktop
+ break
+ [ -r /usr/share/applications//firefox.desktop ]
+ grep -E ^Exec(\[[^]=]*])?= /usr/share/applications//firefox.desktop
+ cut -d= -f 2-
+ first_word
+ read first rest
+ echo /usr/lib/firefox/firefox
+ command=/usr/lib/firefox/firefox
+ which /usr/lib/firefox/firefox
+ command=/usr/lib/firefox/firefox
+ readlink -f /usr/lib/firefox/firefox
+ return
+ check=/usr/lib/firefox/firefox
+ [ -z /usr/lib/firefox/firefox ]
+ read_kde_browser
+ read_kde_config kdeglobals General BrowserApplication
+ configfile=kdeglobals
+ configsection=General
+ configkey=BrowserApplication
+ [ x5 = x5 ]
+ kreadconfig5 --file kdeglobals --group General --key BrowserApplication
+ application=!/usr/bin/firefox
+ [ x!/usr/bin/firefox != x ]
+ echo !/usr/bin/firefox
+ browser=!/usr/bin/firefox
+ resolve_kde_browser
+ [ -z !/usr/bin/firefox ]
+ echo /usr/bin/firefox
+ binary=/usr/bin/firefox
/usr/bin/xdg-settings: 735: Bad substitution

--

debian links /bin/dash to /bin/sh so the script seems fail, while it's working
with bash

$ bash /usr/bin/xdg-settings check default-web-browser firefox.desktop
yes



-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=KDE

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.29-1
ii  libnet-dbus-perl   1.2.0-1
ii  libx11-protocol-perl   0.56-7
ii  x11-utils  7.7+4
ii  x11-xserver-utils  7.7+8

xdg-utils suggests no packages.

-- no debconf information

Bug#950494: /usr/bin/unattended-upgrade: unattended-upgrade sets speed to 70kbps even for manual apt runs

[Oliver]

Package: unattended-upgrades
Version: 1.16
Severity: normal
File: /usr/bin/unattended-upgrade

Dear Maintainer,

For the last few weeks, apt has been extremely slow on my machine,
downloading packages at about 70 kbps give or take, and making the
installation of larger software packages very painful.

This is caused by a line in /etc/apt/apt.conf.d/50unattended-upgrades:

=
// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
Acquire::http::Dl-Limit "70";
=

Commenting out this line restores apt's speeds.

I understand the utility of limiting download speeds for unattended-upgrades,
but I would not have expected this configuration to be applied to all usage
of apt (including outside of unattended-upgrades) by default.

Thank you for your consideration.

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

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

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  lsb-base   11.1.0
ii  lsb-release11.1.0
ii  python33.7.5-3
ii  python3-apt1.8.4+b1
ii  python3-dbus   1.2.14-1
ii  python3-distro-info0.22
ii  ucf3.0038+nmu1
ii  xz-utils   5.2.4-1+b1

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-29
ii  cron [cron-daemon]  3.0pl1-135
ii  systemd-sysv244-3

Versions of packages unattended-upgrades suggests:
pn  bsd-mailx  
ii  exim4-daemon-light [mail-transport-agent]  4.93-3
ii  needrestart3.4-5
ii  powermgmt-base 1.36
ii  python3-gi 3.34.0-3

-- debconf information:
  unattended-upgrades/enable_auto_updates: true

Bug#950491: unattended-upgrades: MOTD mention about packages that could not be upgraded

[Bálint Réczey]

Hi Martin-Éric,

Martin-Éric Racine  ezt írta (időpont:
2020. febr. 2., V, 16:06):
>
> su 2. helmik. 2020 klo 17.03 Bálint Réczey (bal...@balintreczey.hu) kirjoitti:
> >
> > Hi Martin-Éric Racine,
> >
> > Martin-Éric Racine  ezt írta (időpont:
> > 2020. febr. 2., V, 15:54):
> > >
> > > su 2. helmik. 2020 klo 16.50 Bálint Réczey (bal...@balintreczey.hu) 
> > > kirjoitti:
> > > > Martin-Éric Racine  ezt írta (időpont:
> > > > 2020. febr. 2., V, 15:33):
> > > > >
> > > > > Package: unattended-upgrades
> > > > > Version: 1.17
> > > > > Severity: important
> > > > >
> > > > > -BEGIN PGP SIGNED MESSAGE-
> > > > > Hash: SHA256
> > > > >
> > > > > Since a few days, MOTD includes the following stanza:
> > > > >
> > > > > 1 updates could not be installed automatically. For more details,
> > > > > see /var/log/unattended-upgrades/unattended-upgrades.log
> > > > >
> > > > > The log doesn't show any failure. It only shows a succesful upgrade 
> > > > > for a handful of packages.
> > > > >
> > > > > Additionally, there doesn't seem to be any way to make this mention 
> > > > > disappear from MOTD.
> > > >
> > > > The list of packages can be found in 
> > > > /var/lib/unattended-upgrades/kept-back
> > >
> > > There is one package mentioned there. It however seems to be
> > > up-to-date. Shouldn't kept-back have been cleared once the situation
> > > resolved itself?
> > >
> > > > There are bugs open about explaining why packages are kept back in the 
> > > > log:
> > > > #903874 , LP: #1850964
> > >
> > > I'm not looking for the explanation for why they were kept back.
> > >
> > > > Is yours a case where a package is kept back or a different one?
> > >
> > > My case is a persistent MOTD notice about a kept back package that
> > > evidently is no longer kept back and not being able to make the
> > > incorrect notice disappear.
> >
> > The next successful run of unattended-upgrades is expected to clear the
> > kept-back file and as a result make the MOTD notice disappear.
> >
> > Could you please run u-u with --verbose --debug to see if it removes
> > the file or tell why it does not do so?
>
> Checking: python3-breezy ([ origin:'Debian' label:'Debian' site:'httpredir.debian.org'
> isTrusted:True>])
> sanity check failed for: {'python3-breezy=3.0.2-3', 'brz=3.0.2-2'} :
> pkg brz is marked to be deleted
> pkgs that look like they should be upgraded:
> Fetched 0 B in 0s (0 B/s)
> fetch.run() result: 0
> blacklist: []
> whitelist: []
> Packages that will be upgraded:
> InstCount=0 DelCount=0 BrokenCount=0
> Extracting content from
> /var/log/unattended-upgrades/unattended-upgrades-dpkg.log since
> 2020-02-02 17:04:50

Based on that is seems to be true that there is 1 package,
python3-breezy, that can't be upgraded from an allowed origin.

You can verify that by running: apt policy python3-breezy

U-u should explain in the log why python3-breezy can't be upgraded and
this is covered in the mentioned bugs.

Cheers,
Balint

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, 2020-02-01 at 03:21 +0100, Michael Biebl wrote:
> They should also add a
> 
> [Install]
> Alias=display-manager.service
> 
> section
> 
> to their service file. Which will make sure that if you run
> "systemctl enable foo.service", display-manager.service will point at
> the desired display manager.

Hi Michael, I tried that, but it seems that it has the side effect of making
lightdm restart when upgrading, which is not really a good idea when you're
actually in a X session.

Any idea how to prevent that?

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl425xsACgkQ3rYcyPpX
RFvAMwf/Tk4n/O+Do2BtvKCyGlURo4xlofmHtZNlBISDVV+dxAN5jNxwcnjf2D3t
T+65JIJ6sDHWg1DjWSu0Ug6Y0KF3ei3ka7M4di50iMwtn2ULglHg0Z3Prjuyq4bH
CH4JfLXfCIsa62XPSn1tSbUW4KAj+SO1j7CGBhVUf7eixF0anMLP1QC/z+W52z78
CAa4Tf2ODrUip9n4iad10W+pHMD9x8uEIrTAF8Grgro916xcAcyyI9c6BDYRKIAS
Hxj9ZrDen3n5EjN1gXEzFt3hX8o+X6NRoMNRWNCZNGJSo+4s/Y41vwD0a2x1KmUj
mJaXI6l+30ipwGPsWfN0nVBNePA/2Q==
=3gP4
-END PGP SIGNATURE-

Bug#950493: steam:i386: Fails to install when using debconf priority critical

[Witold Baryluk]

Package: steam
Version: 1.0.0.61-2
Severity: important

Dear Maintainer,

# apt install steam
...

The following NEW packages will be installed:
  steam:i386
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
1 not fully installed or removed.
Need to get 0 B/1,457 kB of archives.
After this operation, 4,505 kB of additional disk space will be used.
Preconfiguring packages ...
(Reading database ... 636645 files and directories currently installed.)
Preparing to unpack .../steam_1.0.0.61-2_i386.deb ...
dpkg: error processing archive 
/var/cache/apt/archives/steam_1.0.0.61-2_i386.deb (--unpack):
 new steam:i386 package pre-installation script subprocess returned error exit 
status 1
Installation terminated: Steam License Agreement was DECLINED.
Errors were encountered while processing:
 /var/cache/apt/archives/steam_1.0.0.61-2_i386.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
#


It DID NOT ask me anything about license at all.

Why do I need to accept steam license anyway explicitly anyway. I am
requesting installation, so it is quite obvious.

My debconf priority is 'critical'. But this totally looks like a question
that needs to be asked, so it should be critical.

If I change my debconf priority to high, and then retry, it asks me to
agree and finishes successfully.




-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages steam:i386 depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  libc6  2.29-9
ii  libgl1-mesa-dri19.3.3-1
ii  libgl1-mesa-glx19.3.3-1
ii  libgpg-error0  1.36-7
ii  libstdc++6 9.2.1-25
ii  libudev1   244.1-2
ii  libx11-6   2:1.6.8-1
ii  libxcb-dri3-0  1.13.1-3
ii  libxinerama1   2:1.1.4-2
ii  xz-utils   5.2.4-1+b1

Versions of packages steam:i386 recommends:
ii  ca-certificates   20190110
ii  fontconfig2.13.1-2+b1
ii  fonts-liberation  1:1.07.4-10
ii  gnome-terminal [x-terminal-emulator]  3.34.2-1
ii  libxss1   1:1.2.3-1
ii  mate-terminal [x-terminal-emulator]   1.22.1-1
ii  mesa-vulkan-drivers   19.3.3-1
ii  mlterm [x-terminal-emulator]  3.8.9-1
ii  rxvt-unicode [x-terminal-emulator]9.22-6+b2
ii  steam-devices 1.0.0.61-2
ii  terminator [x-terminal-emulator]  1.91-4
ii  xiterm+thai [x-terminal-emulator] 1.10-2+b2
ii  xterm [x-terminal-emulator]   352-1

Versions of packages steam:i386 suggests:
pn  nvidia-driver-libs-i386  
pn  nvidia-vulkan-icd

-- no debconf information

Bug#950491: unattended-upgrades: MOTD mention about packages that could not be upgraded

[Martin-Éric Racine]

su 2. helmik. 2020 klo 17.03 Bálint Réczey (bal...@balintreczey.hu) kirjoitti:
>
> Hi Martin-Éric Racine,
>
> Martin-Éric Racine  ezt írta (időpont:
> 2020. febr. 2., V, 15:54):
> >
> > su 2. helmik. 2020 klo 16.50 Bálint Réczey (bal...@balintreczey.hu) 
> > kirjoitti:
> > > Martin-Éric Racine  ezt írta (időpont:
> > > 2020. febr. 2., V, 15:33):
> > > >
> > > > Package: unattended-upgrades
> > > > Version: 1.17
> > > > Severity: important
> > > >
> > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA256
> > > >
> > > > Since a few days, MOTD includes the following stanza:
> > > >
> > > > 1 updates could not be installed automatically. For more details,
> > > > see /var/log/unattended-upgrades/unattended-upgrades.log
> > > >
> > > > The log doesn't show any failure. It only shows a succesful upgrade for 
> > > > a handful of packages.
> > > >
> > > > Additionally, there doesn't seem to be any way to make this mention 
> > > > disappear from MOTD.
> > >
> > > The list of packages can be found in 
> > > /var/lib/unattended-upgrades/kept-back
> >
> > There is one package mentioned there. It however seems to be
> > up-to-date. Shouldn't kept-back have been cleared once the situation
> > resolved itself?
> >
> > > There are bugs open about explaining why packages are kept back in the 
> > > log:
> > > #903874 , LP: #1850964
> >
> > I'm not looking for the explanation for why they were kept back.
> >
> > > Is yours a case where a package is kept back or a different one?
> >
> > My case is a persistent MOTD notice about a kept back package that
> > evidently is no longer kept back and not being able to make the
> > incorrect notice disappear.
>
> The next successful run of unattended-upgrades is expected to clear the
> kept-back file and as a result make the MOTD notice disappear.
>
> Could you please run u-u with --verbose --debug to see if it removes
> the file or tell why it does not do so?

Checking: python3-breezy ([])
sanity check failed for: {'python3-breezy=3.0.2-3', 'brz=3.0.2-2'} :
pkg brz is marked to be deleted
pkgs that look like they should be upgraded:
Fetched 0 B in 0s (0 B/s)
fetch.run() result: 0
blacklist: []
whitelist: []
Packages that will be upgraded:
InstCount=0 DelCount=0 BrokenCount=0
Extracting content from
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log since
2020-02-02 17:04:50

Martin-Éric

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

[Ben Hutchings]

[Resending with squashfs-devel in cc]

On Sun, 2020-02-02 at 00:22 +0100, Vincent Danjean wrote:
> 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/

It seems that squashfs used to ignore unknown mount options, but
rejects them since:

commit 5a2be1288b514d74acdb3f0131d4d8fa3d689f06
Author: David Howells 
Date:   Mon Mar 25 16:38:32 2019 +

vfs: Convert squashfs to use the new mount API

Although ignoring mount options was a bug, this change is a user-space
regression and at least this option should still be ignored.

Ben.

> # 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)
[...]

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.

Bug#950491: unattended-upgrades: MOTD mention about packages that could not be upgraded

[Bálint Réczey]

Hi Martin-Éric Racine,

Martin-Éric Racine  ezt írta (időpont:
2020. febr. 2., V, 15:54):
>
> su 2. helmik. 2020 klo 16.50 Bálint Réczey (bal...@balintreczey.hu) kirjoitti:
> > Martin-Éric Racine  ezt írta (időpont:
> > 2020. febr. 2., V, 15:33):
> > >
> > > Package: unattended-upgrades
> > > Version: 1.17
> > > Severity: important
> > >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > Since a few days, MOTD includes the following stanza:
> > >
> > > 1 updates could not be installed automatically. For more details,
> > > see /var/log/unattended-upgrades/unattended-upgrades.log
> > >
> > > The log doesn't show any failure. It only shows a succesful upgrade for a 
> > > handful of packages.
> > >
> > > Additionally, there doesn't seem to be any way to make this mention 
> > > disappear from MOTD.
> >
> > The list of packages can be found in /var/lib/unattended-upgrades/kept-back
>
> There is one package mentioned there. It however seems to be
> up-to-date. Shouldn't kept-back have been cleared once the situation
> resolved itself?
>
> > There are bugs open about explaining why packages are kept back in the log:
> > #903874 , LP: #1850964
>
> I'm not looking for the explanation for why they were kept back.
>
> > Is yours a case where a package is kept back or a different one?
>
> My case is a persistent MOTD notice about a kept back package that
> evidently is no longer kept back and not being able to make the
> incorrect notice disappear.

The next successful run of unattended-upgrades is expected to clear the
kept-back file and as a result make the MOTD notice disappear.

Could you please run u-u with --verbose --debug to see if it removes
the file or tell why it does not do so?

Thanks,
Balint

Bug#947578: FTBFS with scons 3.1.2-1

[Reiner Herrmann]

Control: tags -1 + patch

Dear maintainer,

the attached patch fixes the build failure with the Python3-enabled
scons.

Regards,
  Reiner
diff -Nru rafkill-1.2.2/debian/patches/scons.patch rafkill-1.2.2/debian/patches/scons.patch
--- rafkill-1.2.2/debian/patches/scons.patch	1970-01-01 01:00:00.0 +0100
+++ rafkill-1.2.2/debian/patches/scons.patch	2020-02-02 15:43:25.0 +0100
@@ -0,0 +1,89 @@
+Author: Reiner Herrmann 
+Description: Fix build with Python3-enabled scons
+Bug-Debian: https://bugs.debian.org/947578
+
+--- a/SConstruct
 b/SConstruct
+@@ -6,7 +6,7 @@
+ 
+ # env.Append( CCFLAGS = flags, CPPPATH = [ "../src" ] );
+ 
+-print "Use 'scons -h' for help"
++print("Use 'scons -h' for help")
+ 
+ prefix = '/usr/local/games'
+ bin = '/usr/local/bin'
+@@ -19,9 +19,9 @@
+ 	prefix = 'gen'
+ 	bin = 'gen'
+ 
+-opts = Options( 'rafkill.conf' )
+-opts.Add( PathOption('prefix', 'Directory to install under', prefix ) )
+-opts.Add( PathOption('bin', 'Directory where symlinked executable should go', bin ) )
++opts = Variables( 'rafkill.conf' )
++opts.Add( PathVariable('prefix', 'Directory to install under', prefix ) )
++opts.Add( PathVariable('bin', 'Directory where symlinked executable should go', bin ) )
+ opts.Update( env )
+ opts.Save( 'rafkill.conf', env )
+ 
+@@ -34,7 +34,7 @@
+ 	env.Append( CCFLAGS = [ '-pg' ] )
+ 	env.Append( LINKFLAGS = [ '-pg' ] )
+ 
+-env.BuildDir( 'build/', 'src/' )
++env.VariantDir( 'build/', 'src/' )
+ env.Append( LIBS = [ 'aldmb', 'dumb' ] );
+ if sys.platform == 'win32':
+ 	env.Append( CCFLAGS = [ '-DWINDOWS' ] )
+@@ -51,11 +51,11 @@
+ 
+ # SConscript( 'src/SConscript', build_dir='build', exports = 'env' );
+ sources = SConscript( 'src/SConscript', exports = 'env' );
+-rafkill = env.Program( 'rafkill', map( lambda x: 'build/' + x, sources ) )
++rafkill = env.Program( 'rafkill', list(map( lambda x: 'build/' + x, sources )) )
+ 
+ def installReminder( target, source, env ):
+ 	print
+-	print "Run 'scons install' to install rafkill"
++	print("Run 'scons install' to install rafkill")
+ 	return 0
+ 
+ def ShutUp( target, source, env ):
+@@ -71,7 +71,7 @@
+ env.Alias( 'package', 'src/source.tar' )
+ 
+ def install( target, source, env ):
+-	print "Installing!"
++	print("Installing!")
+ 	return 0
+ 
+ installDir = '$prefix/'
+@@ -81,7 +81,7 @@
+ def addData( file ):
+ 	env.Install( installDir + 'rafkill/data', "data/%s" % file )
+ 
+-map( lambda x: addData( x ), Split( """
++list(map( lambda x: addData( x ), Split( """
+ 1.pck
+ 2.pck
+ 3.pck
+@@ -103,7 +103,7 @@
+ sound.dat
+ table.col
+ vulture.fnt
+-"""));
++""")));
+ 
+ def addMusic( file ):
+ 	env.Install( installDir + 'rafkill/music', "music/%s" % file )
+--- a/src/SConscript
 b/src/SConscript
+@@ -150,7 +150,7 @@
+ """)));
+ 
+ import re
+-headers = map( lambda x: re.compile( 'cpp' ).sub( 'h', x ), sources )
++headers = list(map( lambda x: re.compile( 'cpp' ).sub( 'h', x ), sources ))
+ headers.extend( [ 'fonts.h', 'sound.h', 'wormhole.h' ] )
+ 
+ import os
diff -Nru rafkill-1.2.2/debian/patches/series rafkill-1.2.2/debian/patches/series
--- rafkill-1.2.2/debian/patches/series	2018-01-19 14:24:15.0 +0100
+++ rafkill-1.2.2/debian/patches/series	2020-02-02 15:43:25.0 +0100
@@ -5,3 +5,4 @@
 103_gcc_4.3_fixes
 104_gcc-4.7.patch
 105_glibc-2.26.patch
+scons.patch


signature.asc
Description: PGP signature

Bug#950491: unattended-upgrades: MOTD mention about packages that could not be upgraded

[Martin-Éric Racine]

su 2. helmik. 2020 klo 16.50 Bálint Réczey (bal...@balintreczey.hu) kirjoitti:
> Martin-Éric Racine  ezt írta (időpont:
> 2020. febr. 2., V, 15:33):
> >
> > Package: unattended-upgrades
> > Version: 1.17
> > Severity: important
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Since a few days, MOTD includes the following stanza:
> >
> > 1 updates could not be installed automatically. For more details,
> > see /var/log/unattended-upgrades/unattended-upgrades.log
> >
> > The log doesn't show any failure. It only shows a succesful upgrade for a 
> > handful of packages.
> >
> > Additionally, there doesn't seem to be any way to make this mention 
> > disappear from MOTD.
>
> The list of packages can be found in /var/lib/unattended-upgrades/kept-back

There is one package mentioned there. It however seems to be
up-to-date. Shouldn't kept-back have been cleared once the situation
resolved itself?

> There are bugs open about explaining why packages are kept back in the log:
> #903874 , LP: #1850964

I'm not looking for the explanation for why they were kept back.

> Is yours a case where a package is kept back or a different one?

My case is a persistent MOTD notice about a kept back package that
evidently is no longer kept back and not being able to make the
incorrect notice disappear.

Martin-Éric