Bug#942593: b2backend: still broken - backblaze folders broken

[Alexander Zangerl]

reopen 942593
thanks

On Thu, 24 Oct 2019 15:15:59 +0100, Graham Cobb writes:
>Unfortunately b2backend is still broken upstream. I have sent a patch and I
>think that should fix it.

thanks for sending the links to the two launchpad bugs.

>Will you reopen this bug to track this or do you want me to submit another one?

reopening now. with a bit of luck i'll find some time tomorrow
to apply the magic sauce from upstream's trunk and push out a new release.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
LISP: To call a spade a thpade.


signature.asc
Description: Digital Signature

Bug#940809: WORLD LEADERS : CONGO RAINFOREST

[jandavidmoerike]

Hallo,

ich habe gerade die Petition „WORLD LEADERS : CONGO RAINFOREST"
unterschrieben und wollte dich fragen, ob du auch mitmachst.

Unser Ziel ist es, 500 Unterschriften zu sammeln und dafür brauchen wir
Unterstützung. Hier kannst du mehr über die Petition erfahren:

http://chng.it/PFQNMVvFTK

Vielen Dank!
Jan David

Bug#943542: google-cloud-print-connector: hardcoded dependency on libsnmp30

[Peter Green]

Package: google-cloud-print-connector
Version: 1.12.1
Severity: serious
Tags: bullseye, sid

After uploading my fix for 942331 to Raspbian bullseye I discovered another 
problem. The dependency on libsnmp30 is hardcoded.

In raspbian I have just gone ahead and changed the dependency. a debdiff should 
appear soon at 
https://debdiffs.raspbian.org/main/g/google-cloud-print-connector/

Bug#943541: duplicity: Please build-depend on pylint, not pylint3

[Steve Langasek]

Package: duplicity
Version: 0.8.05-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Alexander,

The duplicity package build-depends on pylint3, but in unstable, the
'pylint' package is now the python3 pylint and the pylint3 package is no
longer built from source (and will eventually be dropped).

Please switch the package to build-depend on pylint, as in the attached
patch.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru duplicity-0.8.05/debian/control duplicity-0.8.05/debian/control
--- duplicity-0.8.05/debian/control 2019-09-22 17:54:52.0 -0700
+++ duplicity-0.8.05/debian/control 2019-10-25 21:26:34.0 -0700
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Alexander Zangerl 
-Build-Depends: debhelper (>= 10.0.0), librsync-dev (>=0.9.6), python3-dev, 
dh-python, python3-setuptools, rdiff, gnupg | gnupg1, par2, python3-lockfile, 
python3-mock, python3-pexpect, python3-fasteners, python3-requests, 
python3-urllib3, python3-coverage, python3-pycodestyle, pylint3, 
python3-pytest, python3-pytest-runner, python3-pytest-cov, tox, python3-future, 
rename, rsync
+Build-Depends: debhelper (>= 10.0.0), librsync-dev (>=0.9.6), python3-dev, 
dh-python, python3-setuptools, rdiff, gnupg | gnupg1, par2, python3-lockfile, 
python3-mock, python3-pexpect, python3-fasteners, python3-requests, 
python3-urllib3, python3-coverage, python3-pycodestyle, pylint, python3-pytest, 
python3-pytest-runner, python3-pytest-cov, tox, python3-future, rename, rsync
 Standards-Version: 4.1.3.0
 Homepage: http://duplicity.nongnu.org/
 X-Python3-Version: >= 3.7

Bug#943499: telegram-desktop: Disable building in big endian archs

[Lisandro Damián Nicanor Pérez Meyer]

Hi Коля!

On 19/10/25 09:51, Коля Гурьев wrote:
> tags 943499 patch
> stop
> 
> 25.10.2019 17:12, Lisandro Damián Nicanor Pérez Meyer пишет:
> > A removal for those archs has been asked in 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943467 but
> > ideally the package should list the architectures it builds instead of 
> > being Arch: any. This will not
> > waste buildds' time and also provide a clearer insight to people looking 
> > for this app in their archs.
> 
> I agree with you, but dpkg does not seem to provide an easy way to
> express such assertion that the package works only on little-endian
> architectures.
> 
> I tried to just list[1] all possible CPUs in the Architecture field, but
> I do not understand its syntax. It looks like line breaks or comments
> are not allowed.
> 
>  [1]: 
> https://salsa.debian.org/debian/telegram-desktop/commit/c22fa4f7cfb3105f3c9889d5342ff7aeeef68157

See https://www.debian.org/doc/debian-policy/ch-controlfields.html#architecture

I normally take a look at buildd.debian.org and create the list from there:

https://buildd.debian.org/status/package.php?p=telegram%2ddesktop

Today you tought me about this table, so using both things:

Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el hppa 
hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k riscv64 sh4 x32

Cheers, Lisandro.

Bug#937914: python-memcache: diff for NMU version 1.59-1.1

[Sandro Tosi]

On Fri, Oct 25, 2019 at 6:47 PM Thomas Goirand  wrote:
> Thanks for this, but there's no need for such NMU or debdiff, I can do
> the work myself. Next time, just poke me, and I'll do the work. If it's
> left undone, it's just that I didn't notice I could do it as there's no
> reverse (build-)dependency remaining.

to do that, you can just go to
http://sandrotosi.me/debian/py2removal/index.html,  filter for your
name, filter for `=0` in the rdeps column and ta-da a list of package
you can just upload :)

> Also, I don't want the package to be switched to Pybuild (or any other
> in the OpenStack team). I'm fine with nothing more than dh, no need for
> the extra complexity of Pybuild.

it actually reduces a lot of complexity. and if you're stick with
python_distutils build system.. that's gonna fail when you remove
python as b-d

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

Bug#943540: include ninja_syntax.py as an example

[Mo Zhou]

Package: ninja-build
Version: 1.9.0-3
Severity: normal

Dear maintainer,

Please include ninja_syntax.py as an example.
It's very useful for people who would like write
their own ninja generators in python.

Bug#943539: gnome-shell: super + number seems to be hardwired to favorite applications

[Roberto De Oliveira]

Package: gnome-shell Version: 3.34.0-2 Severity: normal

Dear Maintainer,

[super] + [number] seems to be hardwired to favorite applications in the dock 
and it can't be
overwrited, this may cause confusion to users.

Indeed, I've tried to change this behavior through control panel and it has no 
effect.

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

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

Versions of packages gnome-shell depends on: ii dconf-gsettings-backend 
[gsettings-backend] 0.34.0-1 ii evolution-data-server 3.34.1-1+b1 ii 
gir1.2-accountsservice-1.0 0.6.55-1 ii gir1.2-atspi-2.0 2.34.0-3 ii 
gir1.2-freedesktop 
1.62.0-2 ii gir1.2-gcr-3 3.33.4-2 ii gir1.2-gdesktopenums-3.0 3.34.0-2 ii 
gir1.2-gdm-1.0 3.34.1-1 ii gir1.2-geoclue-2.0 2.5.5-1 ii gir1.2-glib-2.0 
1.62.0-2 ii 
gir1.2-gnomebluetooth-1.0 3.34.0-1 ii gir1.2-gnomedesktop-3.0 3.34.1-1 ii 
gir1.2-gtk-3.0 3.24.12-1 ii gir1.2-gweather-3.0 3.34.0-1 ii gir1.2-ibus-1.0 
1.5.19-4+deb10u1 ii gir1.2-mutter-5 3.34.0-4 ii gir1.2-nm-1.0 1.20.4-2 ii 
gir1.2-nma-1.0 1.8.24-1 ii gir1.2-pango-1.0 1.42.4-7 ii gir1.2-polkit-1.0 
0.105-26 ii 
gir1.2-rsvg-2.0 2.44.14-1 ii gir1.2-soup-2.4 2.68.2-1 ii gir1.2-upowerglib-1.0 
0.99.11-1 ii gjs 1.58.1-1 ii gnome-backgrounds 3.34.0-1 ii 
gnome-settings-daemon 
3.34.1-1+b1 ii gnome-shell-common 3.34.0-2 ii gsettings-desktop-schemas 
3.34.0-2 ii 
libatk-bridge2.0-0 2.34.1-1 ii libatk1.0-0 2.34.1-1 ii libc6 2.29-2 ii 
libcairo2 
1.16.0-4 ii libcroco3 0.6.13-1 ii libecal-2.0-1 3.34.1-1+b1 ii 
libedataserver-1.2-24 
3.34.1-1+b1 ii libgcr-base-3-1 3.33.4-2 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-1 ii 
libgirepository-1.0-1 1.62.0-2 ii libgjs0g 1.58.1-1 ii libgles2 1.1.0-1+b1 ii 
libglib2.0-0 2.62.1-1 ii libglib2.0-bin 2.62.1-1 ii libgnome-autoar-0-0 0.2.3-2 
ii 
libgstreamer1.0-0 1.16.1-1 ii libgtk-3-0 3.24.12-1 ii libical3 3.0.5-2 ii 
libjson-glib-1.0-0 1.4.4-2 ii libmutter-5-0 3.34.0-4 ii libnm0 1.20.4-2 ii 
libpango-1.0-0 1.42.4-7 ii libpangocairo-1.0-0 1.42.4-7 ii libpolkit-agent-1-0 
0.105-26 
ii libpolkit-gobject-1-0 0.105-26 ii libpulse-mainloop-glib0 13.0-2 ii 
libpulse0 13.0-2 
ii libsecret-1-0 0.19.1-1 ii libsystemd0 242-7 ii libwayland-server0 1.17.0-1 
ii 
libx11-6 2:1.6.8-1 ii libxfixes3 1:5.0.3-1 ii mutter 3.34.0-4 ii python3 3.7.5-1

Versions of packages gnome-shell recommends: ii bolt 0.8-4 ii 
chrome-gnome-shell 10.1-5 
ii gdm3 3.34.1-1 ii gkbd-capplet 3.26.1-1 ii gnome-control-center 1:3.34.1-1 ii 
gnome-user-docs 3.34.0-2 ii ibus 1.5.19-4+deb10u1 ii iio-sensor-proxy 2.4-2+b1 
pn 
switcheroo-control  ii unzip 6.0-25

Versions of packages gnome-shell suggests: ii gir1.2-telepathyglib-0.12 
0.24.1-2+b1 ii 
gir1.2-telepathylogger-0.2 0.8.2-3+b1

Versions of packages gnome-session depends on: ii gnome-session-bin 3.34.1-1 ii 
gnome-session-common 3.34.1-1 ii gnome-settings-daemon 3.34.1-1+b1

Versions of packages gnome-session suggests: ii desktop-base 10.0.3 ii 
gnome-keyring 
3.34.0-1

Versions of packages gnome-settings-daemon depends on: ii 
gnome-settings-daemon-common 
3.34.1-1 ii gsettings-desktop-schemas 3.34.0-2 ii libasound2 1.1.8-2 ii libc6 
2.29-2 ii 
libcairo2 1.16.0-4 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii 
libcolord2 
1.4.3-4 ii libcups2 2.3.0-5 ii libfontconfig1 2.13.1-2+b1 ii libgcr-base-3-1 
3.33.4-2 
ii libgdk-pixbuf2.0-0 2.40.0+dfsg-1 ii libgeoclue-2-0 2.5.5-1 ii 
libgeocode-glib0 
3.26.1-1 ii libglib2.0-0 2.62.1-1 ii libgnome-desktop-3-18 3.34.1-1 ii 
libgtk-3-0 
3.24.12-1 ii libgudev-1.0-0 233-1 ii libgweather-3-16 3.34.0-1 ii liblcms2-2 
2.9-3+b1 
ii libmm-glib0 1.10.4-0.1 ii libnm0 1.20.4-2 ii libnotify4 0.7.8-1 ii libnspr4 
2:4.21-2 
ii libnss3 2:3.45-1 ii libpam-systemd 242-7 ii libpango-1.0-0 1.42.4-7 ii 
libpangocairo-1.0-0 1.42.4-7 ii libpolkit-gobject-1-0 0.105-26 ii 
libpulse-mainloop-glib0 13.0-2 ii libpulse0 13.0-2 ii libupower-glib3 0.99.11-1 
ii 
libwacom2 1.1-1 ii libwayland-client0 1.17.0-1 ii libx11-6 2:1.6.8-1 ii 
libxext6 
2:1.3.3-1+b2 ii libxi6 2:1.7.9-1

Versions of packages gnome-settings-daemon recommends: ii iio-sensor-proxy 
2.4-2+b1 ii 
pulseaudio 13.0-2

Versions of packages libgjs0g depends on: ii gir1.2-glib-2.0 1.62.0-2 ii libc6 
2.29-2 
ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libffi6 3.2.1-9 ii 
libgcc1 
1:9.2.1-8 ii libgirepository-1.0-1 1.62.0-2 ii libglib2.0-0 2.62.1-1 ii 
libmozjs-60-0 
60.8.0-2 ii libreadline8 8.0-3 ii libstdc++6 9.2.1-8 ii libx11-6 2:1.6.8-1

Versions of packages gnome-shell is related to: ii libegl-mesa0 [libegl-vendor] 
19.2.1-1 ii libgl1-mesa-dri 19.2.1-1 ii libglx-mesa0 [libglx-vendor] 19.2.1-1

-- no debconf information

Bug#942331: google-cloud-print-connector FTBFS with current cups (was: google-cloud-print-connector: FTBFS during rebuild with libsnmp35)

[peter green]

tags 942331 +patch
thanks


Your package is part of the libsnmp transition. During a rebuild your package
FTBFS on all architectures.

Reading the log more thoroughly it seems the actual failure is cups related.


cgo-gcc-prolog:95:2: warning: ‘cupsGetPPD3’ is deprecated: Use cupsCopyDestInfo 
and friends instead. [-Wdeprecated-declarations]
In file included from 
src/github.com/google/cloud-print-connector/cups/cups.h:15,
  from 
src/github.com/google/cloud-print-connector/cups/core.go:14:
/usr/include/cups/ppd.h:360:22: note: declared here
   360 | extern http_status_t cupsGetPPD3(http_t *http, const char *name, time_t 
*modtime, char *buffer, size_t bufsize) _CUPS_DEPRECATED_1_6_MSG("Use 
cupsCopyDestInfo and friends instead.");
   |  ^~~
# github.com/google/cloud-print-connector/cups
cups.c: In function ‘getIPPRequestStatusCode’:
cups.c:42:12: error: dereferencing pointer to incomplete type ‘ipp_t’ {aka 
‘struct _ipp_s’}
42 |  return ipp->request.status.status_code;
   |^~
cups.c: In function ‘getAttributeDateValue’:
cups.c:47:13: error: dereferencing pointer to incomplete type ‘ipp_attribute_t’ 
{aka ‘struct _ipp_attribute_s’}
47 |  return attr->values[i].date;
   | ^~
crypto

Specifically it seems cups no longer allows direct access to some structures ( 
https://github.com/apple/cups/commit/0fb02fb9cef39fd0b0c838f11af21d99fe5eab9b#diff-a299fb5293cedc8102f5963e50fbe22c
 ).

I have whipped up a patch and it seems to build, but I have not tested it beyond 
that as I do not use google cloud printing. In particular I note that it seems the 
only way to iterate through the attributes changes ipp->next. I don't know why 
the the API is designed this way or if this will cause any problems. I also notice 
that ippGetValueTag applies a mask before returning the tag, again I don't know if 
that will cause any problems. Also I don't know go, so my changes to the go code 
should probablly be checked by someone who actually knows the langauge.

I have uploaded my fix to raspbian, a debdiff should appear soon at 
https://debdiffs.raspbian.org/main/g/google-cloud-print-connector/

Bug#937855: python-jsonext: Python2 removal in sid/bullseye (now this is an RC bug...)

[Ben Finney]

Control: tags -1 + pending - patch

On 18-Oct-2019, Thomas Goirand wrote:

> Attached is a debdiff fixing this RC bug. There's other clean-up
> necessary for this package (like removing the X-Python{3,}-Version:)
> which I think should be done before the upload.

Thanks for the proposed changes.

(Something in your toolchain – or possibly you, manually? – are
removing valid U+000C white space characters from source files. I
would reject a diff with that error, not sure if it was deliberate
though.)

> Let me know if you're ok for me to NMU this package.

I've packaged a newer upstream release and am dealing with this bug in
with that. Thanks again.

-- 
 \  “One bad programmer can easily create two new jobs a year. |
  `\  Hiring more bad programmers will just increase our perceived |
_o__) need for them.” —David Lorge Parnas, 1999-03 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#943538: glibc: please backport patch gnu hash support for MIPS

[YunQiang Su]

Package: src:glibc
Version: 2.29-2

https://sourceware.org/git/?p=glibc.git;a=commit;h=23c1c256ae7b0f010d0fcaff60682b620887b164

The binutils has support gnu hash now, and the only thing left is about glibc.
Please backport this patch.

We have another question is about buster->bulleyes upgrade.
So, should we enable gnu hash by default for bulleyes or bulleyes+1?

-- 
YunQiang Su

Bug#939983: error: Unable to read from '/sys/fs/cgroup/unified/machine/cgroup.controllers'

[Anthony DeRobertis]

Package: libvirt-daemon
Version: 5.6.0-2
Followup-For: Bug #939983

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Searching the web led to a suggestion this is from libvirt not realizing
its on a systemd machine and trying to use non-systemd cgroups. (It
should be machine.slice under systemd).

Installing systemd-container, making sure it was started
(machines.target and machine.slice, though maybe that'll happen
automatically --- certainly should on reboot), and restarting libvirt
fixed it here.

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

Kernel: Linux 4.19.0-5-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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvirt-daemon depends on:
ii  libblkid1   2.34-0.1
ii  libc6   2.29-2
ii  libcap-ng0  0.7.9-2+b1
ii  libdbus-1-3 1.12.16-2
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libfuse22.9.9-2
ii  libgcc1 1:9.2.1-8
ii  libgnutls30 3.6.9-5
ii  libnetcf1   1:0.2.8-1+b3
ii  libparted2  3.3-1
ii  libpcap0.8  1.9.1-2
ii  libpciaccess0   0.14-1
ii  libselinux1 2.9-2+b2
ii  libudev1242-7
ii  libvirt05.6.0-2
ii  libxenmisc4.11  4.11.1+92-g6c33308a8d-2+b1
ii  libxenstore3.0  4.11.1+92-g6c33308a8d-2+b1
ii  libxentoollog1  4.11.1+92-g6c33308a8d-2+b1
ii  libxml2 2.9.4+dfsg1-7+b3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-7+b3
ii  netcat-openbsd  1.203-2
ii  qemu-kvm1:4.1-1+b2

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster  
pn  libvirt-daemon-driver-storage-rbd  
pn  libvirt-daemon-driver-storage-zfs  
ii  libvirt-daemon-system  5.6.0-2
pn  numad  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCXbOIAhUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf4P/gCfXPpKvk+nDfuSbVxcVZxMnpk9rbkA
n2rOrdrR+7rJJm7VNqqCjGxVXGIu
=IOZI
-END PGP SIGNATURE-

Bug#942808: ITP: dropbear-rescue -- A set of initramfs scripts to add and run dropbear when the system boots in rescue mode

[Guilhem Moulin]

Control: retitle -1 ITP: dropbear-rescue -- A set of initramfs scripts to add 
and run dropbear when the system boots in rescue mode
Control: tag -1 - pending

On Sat, 26 Oct 2019 at 01:50:02 +0200, Guilhem Moulin wrote:
> Control: retitle -1 race condition: init-bottom script doesn't abort/cleanup 
> configure_networking()
> Control: tag -1 pending

Oops sorry, meant to reply to the clone (#943459) not the original :-/

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#942808: Bug#943459: dropbear-initramfs: race condition: init-bottom script doesn't abort/cleanup configure_networking()

[Guilhem Moulin]

Control: retitle -1 race condition: init-bottom script doesn't abort/cleanup 
configure_networking()
Control: tag -1 pending

On Fri, 25 Oct 2019 at 02:26:39 +0200, Guilhem Moulin wrote:
> Ah right, I understand the problem now.  Whether configure_networking()
> is run (at premount stage) in the background or not depends on the boot
> method.  On local (non-NFS) mounts it's done in the background, and
> should be interrupted at bottom stage.  However if no other script is
> waiting for interactive user input the bottom script might run before
> dropbear had a chance to run yielding a race condition at bottom stage.
> This is a bug.

Implemented a fix at https://salsa.debian.org/debian/dropbear/commit/1ab168b9 ,
could you please confirm that it solves the race for you?

It appears that ipconfig doesn't react to SIGTERM, so I've not been able
to properly abort configure_networking().  Instead, the init-bottom
script now waits (for up to 1min) until dropbear is started before
bringing the network down.  Of course it's a bit of a waste as it
needlessly delays the boot process (it's no longer possible to log in at
that stage anyway), but at least when execution is handed over to init(1)
it's with a clean network stack and not with a running ipconfig process.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#943537: apt-show-versions: "apt-show-versions -i" takes too much memory, killed by oom-killer

[Vincent Lefevre]

Control: retitle -1 apt-show-versions takes too much memory, killed by 
oom-killer

On 2019-10-26 01:18:11 +0200, Vincent Lefevre wrote:
> "apt-show-versions -i" takes too much memory and is killed by oom-killer
> on my machine. From journalctl output:
[...]
> Note that it is invoked after "apt-get update"
> (/etc/apt/apt.conf.d/20apt-show-versions).

This occurs even without the -i option.

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

Bug#943537: apt-show-versions: "apt-show-versions -i" takes too much memory, killed by oom-killer

[Vincent Lefevre]

Package: apt-show-versions
Version: 0.22.11
Severity: important

"apt-show-versions -i" takes too much memory and is killed by oom-killer
on my machine. From journalctl output:

Oct 26 01:03:10 joooj kernel: apt-show-versio invoked oom-killer: 
gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, 
oom_score_adj=0
Oct 26 01:03:10 joooj kernel: apt-show-versio cpuset=/ mems_allowed=0
Oct 26 01:03:10 joooj kernel: CPU: 0 PID: 15598 Comm: apt-show-versio Not 
tainted 4.19.0-6-amd64 #1 Debian 4.19.67-2+deb10u1
Oct 26 01:03:10 joooj kernel: Call Trace:
Oct 26 01:03:10 joooj kernel:  dump_stack+0x5c/0x80
Oct 26 01:03:10 joooj kernel:  dump_header+0x6b/0x283
Oct 26 01:03:10 joooj kernel:  oom_kill_process.cold.30+0xb/0x1cf
Oct 26 01:03:10 joooj kernel:  ? oom_badness+0xe9/0x140
Oct 26 01:03:10 joooj kernel:  out_of_memory+0x1a5/0x430
Oct 26 01:03:10 joooj kernel:  __alloc_pages_slowpath+0xbd8/0xcb0
Oct 26 01:03:10 joooj kernel:  ? __switch_to_asm+0x41/0x70
Oct 26 01:03:10 joooj kernel:  __alloc_pages_nodemask+0x28b/0x2b0
Oct 26 01:03:10 joooj kernel:  alloc_pages_vma+0x74/0x1c0
Oct 26 01:03:10 joooj kernel:  __read_swap_cache_async+0x14c/0x200
Oct 26 01:03:10 joooj kernel:  read_swap_cache_async+0x28/0x60
Oct 26 01:03:10 joooj kernel:  swapin_readahead+0x325/0x4c0
Oct 26 01:03:10 joooj kernel:  ? radix_tree_lookup_slot+0x1e/0x50
Oct 26 01:03:10 joooj kernel:  ? find_get_entry+0x19/0xf0
Oct 26 01:03:10 joooj kernel:  ? pagecache_get_page+0x30/0x2c0
Oct 26 01:03:10 joooj kernel:  do_swap_page+0x44b/0x960
Oct 26 01:03:10 joooj kernel:  ? __raw_callee_save_xen_pmd_val+0x11/0x1e
Oct 26 01:03:10 joooj kernel:  __handle_mm_fault+0x876/0x1270
Oct 26 01:03:10 joooj kernel:  handle_mm_fault+0xd6/0x200
Oct 26 01:03:10 joooj kernel:  __do_page_fault+0x249/0x4f0
Oct 26 01:03:10 joooj kernel:  ? page_fault+0x8/0x30
Oct 26 01:03:10 joooj kernel:  page_fault+0x1e/0x30
Oct 26 01:03:10 joooj kernel: RIP: e033:0x55843f28d9ab
Oct 26 01:03:10 joooj kernel: Code: 4b 8d 0c ce 48 8b b1 60 08 00 00 48 89 32 
48 89 91 60 08 00 00 48 39 eb 74 0b 8b 53 08 85 d2 0f 84 0c 02 00 00 48 85 c0 
74 17 <8b> 50 08 85 d2 0f 84 1a 06 00 00 83 ea 01 89 50 08 0f 84 16 ff ff
Oct 26 01:03:10 joooj kernel: RSP: e02b:7ee355c0 EFLAGS: 00010202
Oct 26 01:03:10 joooj kernel: RAX: 558445106458 RBX: 558444ffb330 RCX: 
55843f344cc8
Oct 26 01:03:10 joooj kernel: RDX: 55844546e2b0 RSI: 0800 RDI: 
55843f344cc0
Oct 26 01:03:10 joooj kernel: RBP: 558447c95678 R08:  R09: 
000c
Oct 26 01:03:10 joooj kernel: R10: 0007 R11: 5584408f03b0 R12: 
55843f343ae0
Oct 26 01:03:10 joooj kernel: R13: 0001 R14: 5584408e7260 R15: 
55844546e280
Oct 26 01:03:10 joooj kernel: Mem-Info:
Oct 26 01:03:10 joooj kernel: active_anon:10619 inactive_anon:10681 
isolated_anon:0
   active_file:180 inactive_file:301 isolated_file:0
   unevictable:2634 dirty:0 writeback:0 unstable:0
   slab_reclaimable:59427 slab_unreclaimable:17738
   mapped:1358 shmem:1 pagetables:1207 bounce:0
   free:1052 free_pcp:144 free_cma:0
Oct 26 01:03:10 joooj kernel: Node 0 active_anon:42476kB inactive_anon:42724kB 
active_file:720kB inactive_file:1204kB unevictable:10536kB isolated(anon):0kB 
isolated(file):0kB mapped:5432kB dirty:0kB writeback:0kB shmem:4kB shmem_thp: 
0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB 
all_unreclaimable? no
Oct 26 01:03:10 joooj kernel: Node 0 DMA free:1812kB min:92kB low:112kB 
high:132kB active_anon:1132kB inactive_anon:1420kB active_file:4kB 
inactive_file:24kB unevictable:0kB writepending:0kB present:15996kB 
managed:15912kB mlocked:0kB kernel_stack:0kB pagetables:32kB bounce:0kB 
free_pcp:0kB local_pcp:0kB free_cma:0kB
Oct 26 01:03:10 joooj kernel: lowmem_reserve[]: 0 434 434 434 434
Oct 26 01:03:10 joooj kernel: Node 0 DMA32 free:2396kB min:2616kB low:3268kB 
high:3920kB active_anon:41088kB inactive_anon:41552kB active_file:604kB 
inactive_file:1100kB unevictable:10536kB writepending:0kB present:507904kB 
managed:473348kB mlocked:10536kB kernel_stack:4384kB pagetables:4796kB 
bounce:0kB free_pcp:576kB local_pcp:576kB free_cma:0kB
Oct 26 01:03:10 joooj kernel: lowmem_reserve[]: 0 0 0 0 0
Oct 26 01:03:10 joooj kernel: Node 0 DMA: 16*4kB (UEH) 19*8kB (UH) 16*16kB (UE) 
22*32kB (UEH) 8*64kB (H) 1*128kB (H) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 
= 1816kB
Oct 26 01:03:10 joooj kernel: Node 0 DMA32: 110*4kB (UME) 110*8kB (UE) 70*16kB 
(UE) 8*32kB (U) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 
2696kB
Oct 26 01:03:10 joooj kernel: 1677 total pagecache pages
Oct 26 01:03:10 joooj kernel: 110 pages in swap cache
Oct 26 01:03:10 joooj kernel: Swap cache stats: add 16616845, delete 16616735, 
find 9813553/15811820
Oct 26 01:03:10 joooj kernel: Free swap  = 0kB
Oct 26 01:03:10 joooj kernel: 

Bug#933832: enigmail: Please package new version 2.1 into experimental

[Carsten Schoenert]

Control: retitle -1 Please package new version 2.1.2 into experimental

Hello Daniel,

On Sun, Aug 04, 2019 at 10:14:44AM +0200, Carsten Schoenert wrote:
> The current enigmail version 2.0.x in unstable is not compatible with TB
> >= 68.0. Please package version 2.1 and upload these version into
> experimental for now. Testing my TB packaging with always dealing the
> local installed enigmail version is a bit tedious.

we are getting closer to Thunderbird version 68.2.0 for unstable.
I will upload 68.1.2 within the next two days to experimental as
announced in some other email. And I will start work on 68.2.0 once this
version will go into the stable tree on the CDN of Mozilla.

As Thunderbird 68.x will come with a Breask enigmail (<< 2:2.1.2~) users
will get lost of an installed Enigmail AddOn in unstable if no newer
version will be around.

So it would be nice if you can provide a updated version of Enigmail at
least in experimental for now.

Regards
Carsten

Bug#937914: python-memcache: diff for NMU version 1.59-1.1

[Thomas Goirand]

Hi Sandro,

Thanks for this, but there's no need for such NMU or debdiff, I can do
the work myself. Next time, just poke me, and I'll do the work. If it's
left undone, it's just that I didn't notice I could do it as there's no
reverse (build-)dependency remaining.

Also, I don't want the package to be switched to Pybuild (or any other
in the OpenStack team). I'm fine with nothing more than dh, no need for
the extra complexity of Pybuild.

Cheers,

Thomas Goirand (zigo)

Bug#943529: python-debianbts: missing information on who closed a bug

[Sandro Tosi]

On Fri, Oct 25, 2019 at 4:24 PM Sandro Tosi  wrote:
> if you look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937796 the
> 'Done' header mentions who closed this bug, but that information is not 
> exposed
> in debianbts:

it could be as simple as this:

diff --git a/debianbts/debianbts.py b/debianbts/debianbts.py
index 3393c69..2eb764f 100644
--- a/debianbts/debianbts.py
+++ b/debianbts/debianbts.py
@@ -417,6 +417,7 @@ def _parse_status(bug_el):
bug.log_modified = datetime.utcfromtimestamp(float(bug_el('log_modified')))
bug.tags = [_uc(tag) for tag in str(bug_el('tags')).split()]
bug.done = _parse_bool(bug_el('done'))
+bug.done_by = _parse_string_el(bug_el('done')) if bug.done else None
bug.archived = _parse_bool(bug_el('archived'))
bug.unarchived = _parse_bool(bug_el('unarchived'))
bug.bug_num = int(bug_el('bug_num'))


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

Bug#862300: continuos segfaults debian due systemd paths

[PICCORO McKAY Lenz]

since debian 10 path are not in root accoutn and then citadel does not
work...

citadel server also other must run several other commands and does not
found those

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#943404: O: sopel -- simple, lightweight, open source, easy-to-use IRC utility bot

[Emmanuel Arias]

Hello,

I am interest in adopt it

Cheers,
Emmanuel

Bug#943465: fwupd is wrongly marked Multi-Arch: foreign

[Helmut Grohne]

On Fri, Oct 25, 2019 at 04:01:10PM +, mario.limoncie...@dell.com wrote:
> I made some modifications and think I captured your suggestion here
> https://github.com/fwupd/fwupd/commit/3508aecefdbd81924314834ac9e14bcd71aa253f
> 
> Can you make sure that looks good now?

Unfortunately, no. Ansgar Burchardt kindly pointed out that Built-Using
must refer to a source package, not a binary package. This was wrong in
the previous iteration and I didn't spot it. Refer to the debian policy
section 7.8.

Now there are two other subtle things left.

Previously, fwupd included the *.efi images. Now it recommends them. Is
that enough or should that be a hard dependency to retain the old
behaviour? I don't know. Does fwupd actually work without the *.efi
binaries?

I'm also wondering why the signing-template includes the SIGNARCH in the
package name. This is not a regression, but it should follow the same
reasoning as for why fwupd-unsigned doesn't have to include an
architecture. Do note that the same binary package may be built from
different source packages for different architectures as long as now two
source packages build it for the same architecture. For instance
libsystemd-dev used to be built from different source packages for
linux-any and kfreebsd-any. Can we simplify that part as well?

Helmut

Bug#941016: ITP: gnome-firmware-updater -- GTK tool to upgrade, downgrade, and reinstall firmware on devices supported by fwupd

[Mike Gabriel]

Hi Jesper,

On  Fr 25 Okt 2019 20:16:06 CEST, Jesper Mejervik Derander wrote:


Hello Mike,

On Mon, 23 Sep 2019 14:44:50 +0200 Mike Gabriel wrote:


Package: wnpp
Severity: wishlist
Owner: Mike Gabriel

* Package name : gnome-firmware-updater
Version : 3.34.0
Upstream Author : Richard Hughes (https://gitlab.gnome.org/hughsie)
* URL : https://gitlab.gnome.org/hughsie/gnome-firmware-updater/
* License : GPL-2+
Programming Lang: C
Description : GTK tool to upgrade, downgrade, and reinstall  
firmware on devices supported by fwupd


With this application you can:
.
- upgrade, downgrade, and reinstall firmware on devices supported by fwupd
- Unlock locked fwupd devices
- Verify firmware on supported devices
- Display all releases for a fwupd device
.
This application will be maintained by the MATE packaging team. If
people from the GNOME team want to chime in, please give us notice.




I have some packaging in the works which build and installs fine,  
but there are a few things still left to do like getting manpages to  
work and fix some lintian errors. You can see my progress here:  
https://salsa.debian.org/jespermd-guest/gnome-firmware


I would like to become a Debian package maintainer and thought this  
might be a good

starting point. I have a sponsor ready.

Best regards,
Jesper Derander


Thanks for working on this. As ITP holder, I'd prefer being the  
uploading sponsor myself. This piece of work will be funded by Ubuntu  
MATE and if not packaging the software myself, it may make sense to  
invest the time on sponsoring and reviewing your work.


Let me know, if it is ok with your current sponsor to hand over  
sponsoring and reviewing to me. (Who is it by the way?)


Is that ok with you? I'll be happy to support your process of becoming  
a Debian package maintainer.


light+love
Mike

--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp5ueAcJUh2f.pgp
Description: Digitale PGP-Signatur

Bug#931640: webext-ublock-origin: no longer functional in firefox-esr

[Manolo Díaz]

> 
> 
> Am 25.10.19 um 21:43 schrieb Manolo Díaz:
> > Package: webext-ublock-origin
> > Version: 1.22.2+dfsg-1
> > Followup-For: Bug #931640
> > 
> > Dear Maintainer,
> > The same here. Upgrading to 1.22.2+dfsg-1 changes nothing.
> 
> 1.22.2+dfsg-1 works. You have to restart Firefox and potentially disable
> and then re-enable the addon.
> 
> Markus Koschany
> 

Yes, you're right. Thanks for the hint.

Best Regards.
-- 
Manolo Díaz

Bug#943536: lintian: Stop shipping profile 'debian/ftp-master-auto-reject'

[Bastian Blank]

On Fri, Oct 25, 2019 at 02:37:33PM -0700, Felix Lechner wrote:
> Based on information from #debian-ftp, which is recorded in part below, the
> profile is no longer being used. It will be removed in the near future.

How will this command line option work afterwards?

| -F, --ftp-master-rejects
| Run only the checks that issue tags that result in automatic rejects
| from the Debian upload queue.  The list of such tags is refreshed with
| each Lintian release, so may be slightly out of date if it has changed
| recently.
| This is implemented via a profile and thus this option cannot be used
| together with --profile.

Bastian

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3

Bug#943374: dgit push-source fails and loses a package version number without retries

[Russ Allbery]

Ian Jackson  writes:

> The DNS resolver library used by ssh *does* retry.  See resolv.conf(5)
> `attempts:'.  But it defaults to 2 which seems far too little!

Oh, thank you.  This may be a better solution to my problem than changes
to dgit.  I think I mostly filed this bug because I was surprised there
was a possibility to fail past a point of no return in allocating the
version number, although in retrospect it makes sense there would be such
a point.

In retrospect, I probably should just run a caching DNS server on my
laptop so that I have more control over things like this.

> This is not so easy; not all of the commands are idempotent (because of
> the underlying protocols).  Also dgit does some things itself with (eg)
> a built-in http client.  I will consider your suggestion but if I do
> this it will probably be a long-term thing.

Good point, that makes sense.  Prompting is also kind of a pain.  Maybe
just the ssh commands, since they may be the most prone to failure?
Although that's just an assumption; maybe the internal HTTP client could
have just as easily had the same failure.

> It might also be possible to try to do the generation of signed
> artefacts in a single batch, and provide a way to retry the delivery of
> the objects to remote places.  That would also make it more convenient
> to work around a dput failure.

That sounds like an even better fix if it's possible.

-- 
Russ Allbery (r...@debian.org)  

Bug#941055: Bug #941055: dtkwm FTBFS: Project ERROR: set DTK_MODULE_NAME first

[Boyuan Yang]

notfound 941055 2.0.9-3
found 941055 2.0.9-4
thanks

This bug actually does not affect dtkwm in Buster. I am hacking into the
version string to avoid mentioning stable in the bug.

Regards,
Boyuan Yang


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

Bug#937914: python-memcache: diff for NMU version 1.59-1.1

[Sandro Tosi]

Control: tags 937914 + patch
Control: tags 937914 + pending


Dear maintainer,

I've prepared an NMU for python-memcache (versioned as 1.59-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-memcache-1.59/debian/changelog python-memcache-1.59/debian/changelog
--- python-memcache-1.59/debian/changelog	2018-09-05 19:18:05.0 -0400
+++ python-memcache-1.59/debian/changelog	2019-10-25 15:52:36.0 -0400
@@ -1,3 +1,10 @@
+python-memcache (1.59-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937914
+
+ -- Sandro Tosi   Fri, 25 Oct 2019 15:52:36 -0400
+
 python-memcache (1.59-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru python-memcache-1.59/debian/control python-memcache-1.59/debian/control
--- python-memcache-1.59/debian/control	2018-09-05 19:18:05.0 -0400
+++ python-memcache-1.59/debian/control	2019-10-25 15:51:44.0 -0400
@@ -8,15 +8,10 @@
 Build-Depends:
  debhelper (>= 9),
  dh-python,
- python-all,
- python-setuptools,
  python3-all,
  python3-setuptools,
 Build-Depends-Indep:
  memcached,
- python-mock,
- python-nose,
- python-six,
  python3-mock,
  python3-nose,
  python3-six,
@@ -25,21 +20,6 @@
 Vcs-Browser: https://salsa.debian.org/openstack-team/python/python-memcache
 Homepage: https://github.com/linsomniac/python-memcached
 
-Package: python-memcache
-Architecture: all
-Depends:
- python-six,
- ${misc:Depends},
- ${python:Depends},
-Suggests:
- memcached,
-Description: pure Python memcached client
- This software is a 100% Python interface to the memcached memory cache
- daemon. It is the client side software which allows storing values in
- one or more, possibly remote, memcached servers.
- .
- This package contains the Python 2.x module.
-
 Package: python3-memcache
 Architecture: all
 Depends:
diff -Nru python-memcache-1.59/debian/rules python-memcache-1.59/debian/rules
--- python-memcache-1.59/debian/rules	2018-09-05 19:18:05.0 -0400
+++ python-memcache-1.59/debian/rules	2019-10-25 15:52:36.0 -0400
@@ -1,19 +1,14 @@
 #!/usr/bin/make -f
 
-PYTHONS:=$(shell pyversions -vr)
 PYTHON3S:=$(shell py3versions -vr)
 
 UPSTREAM_GIT := https://github.com/linsomniac/python-memcached.git
 -include /usr/share/openstack-pkg-tools/pkgos.make
 
 %:
-	dh $@ --buildsystem=python_distutils --with python2,python3
+	dh $@ --buildsystem=pybuild --with python3
 
 override_dh_install:
-	set -e && for pyvers in $(PYTHONS); do \
-		python$$pyvers setup.py install --install-layout=deb \
-			--root $(CURDIR)/debian/python-memcache; \
-	done
 	set -e && for pyvers in $(PYTHON3S); do \
 		python$$pyvers setup.py install --install-layout=deb \
 			--root $(CURDIR)/debian/python3-memcache; \
@@ -23,7 +18,7 @@
 override_dh_auto_test:
 ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
 	chmod +x debian/setup-test-env-memcached.sh
-	set -e ; set -x ; for i in 2.7 $(PYTHON3S) ; do \
+	set -e ; set -x ; for i in $(PYTHON3S) ; do \
 		PYMAJOR=`echo $$i | cut -d'.' -f1` ; \
 		echo "===> Testing with python$$i (python$$PYMAJOR)" ; \
 		debian/setup-test-env-memcached.sh python$$i -m nose -v ; \
diff -Nru python-memcache-1.59/debian/tests/control python-memcache-1.59/debian/tests/control
--- python-memcache-1.59/debian/tests/control	2018-09-05 19:18:05.0 -0400
+++ python-memcache-1.59/debian/tests/control	2019-10-25 15:52:28.0 -0400
@@ -1,3 +1 @@
-Test-Command: python -c "import memcache; print memcache.__version__"
-
 Test-Command: python3 -c "import memcache; print(memcache.__version__)"

Bug#943532: kwartz-client: fails to install: /etc/nslcd.conf:23: bindpw: wrong number of arguments

[Andreas Beckmann]

Package: kwartz-client
Version: 1.0-6
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up kwartz-client (1.0-6) ...
  invoke-rc.d: could not determine current runlevel
  invoke-rc.d: policy-rc.d denied execution of start.
  Restarting LDAP connection daemon: nslcdnslcd: /etc/nslcd.conf:23: bindpw: 
wrong number of arguments
   [ESC][31mfailed![ESC][39;49m
  dpkg: error processing package kwartz-client (--configure):
   installed kwartz-client package post-installation script subprocess returned 
error exit status 1
  Processing triggers for libc-bin (2.29-2) ...
  Processing triggers for ca-certificates (20190110) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   kwartz-client


cheers,

Andreas


kwartz-client_1.0-6.log.gz
Description: application/gzip

Bug#907727: Empty directory is already present in orig tarball

[Felix Lechner]

Hi Russ,

On Wed, Oct 23, 2019 at 1:08 PM Russ Allbery  wrote:
>
> the original request was to
> suppress the tag source-contains-empty-directory if the Debian patch set
> explicitly adds a file to that directory

An override is more explicit, and also more self-explanatory, when
compared to a '.placeholder'. Could dpkg perhaps add such a
placeholder automatically if the directory mentioned in the override
is still empty after all the patches have been applied?

> The result is that the patches-applied Debian
> packaging tree is then representable in Git

I re-read our prior messages, but still do not see why the ability to
round-trip through Git is so important. Either way, the issue should
IMHO be fixed in the tool chain that processes such round trips. Then
we can remove the tag from Lintian.

> which did seem mildly
> superior to recreating the directory in debian/rules

How would a placeholder created in debian/rules (or dh) help with the
round-tripping issue? Does anyone create source packages from built
source trees?

Upon further reflection, how about we record a manifest of the
upstream sources in the debian repo? Such a manifest could also
contain checksums for individual files, which would relieve us from
all problems synchronizing signed git tags and tarball signatures. (I
once wrote such a tool but it has seen no adoption.) Empty directories
could be easily re-created from the manifest when needed.

Kind regards
Felix

Bug#943533: ldh-gui-suite: fails to install: mv: cannot move '/tmp/debconf_SxQLyd2wY8' to '/var/lib/one.liberty/deckhost.conf': No such file or directory

[Andreas Beckmann]

Package: ldh-gui-suite
Version: 0.1~20190927-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up ldh-gui-suite (0.1~20190927-3) ...
  mv: cannot move '/tmp/debconf_SxQLyd2wY8' to 
'/var/lib/one.liberty/deckhost.conf': No such file or directory
  dpkg: error processing package ldh-gui-suite (--configure):
   installed ldh-gui-suite package post-installation script subprocess returned 
error exit status 1
  Processing triggers for systemd (242-7) ...
  Processing triggers for libc-bin (2.29-2) ...
  Processing triggers for dictionaries-common (1.28.1) ...
  Processing triggers for libgdk-pixbuf2.0-0:amd64 (2.40.0+dfsg-1) ...
  Errors were encountered while processing:
   ldh-gui-suite


You probably need to ship /var/lib/one.liberty as an empty directory
in the package.


cheers,

Andreas


ldh-gui-suite_0.1~20190927-3.log.gz
Description: application/gzip

Bug#943528: gpaste: 'gpaste-client upload' depends on missing command 'wgetpaste'

[Jérémy Lal]

Le ven. 25 oct. 2019 à 22:18, Mike Miller  a écrit :

> Package: gpaste
> Version: 3.34.1-1
> Severity: normal
>
> Dear Maintainer,
>
> The `gpaste-client upload` command has a hard dependency on a command
> called `wgetpaste`, which is expected to be an executable in the user's
> PATH. This command is not packaged in Debian as far as I can tell.
>
> The error message looks like this
>
>   Oct 25 11:40:36 localhost gpaste-daemon[17913]:
> g_subprocess_communicate_utf8_async: assertion 'G_IS_SUBPROCESS
> (subprocess)' failed
>
> The package `pastebinit` _is_ packaged in Debian and seems to work as a
> drop in replacement. The only requirement seems to be a program that
> takes text on stdin and writes out a URL on stdout. This could be solved
> with a one line patch and a Suggests: pastebinit.
>
> However, maybe it would make sense for the user to be able to configure
> whatever script they want to use to upload text to a pastebin service?
>
> And moreover, maybe this should be disabled by default until the user
> explicitly opts in and chooses a paste upload handler and service?
>
> I am open to proposing patches or working with upstream if you think
> this should be worked out there instead of Debian patches.
>

Yes, you should get in touch with upstream - who is quite friendly.
Don't forget to check existing issues like
https://github.com/Keruspe/GPaste/issues/146

Jérémy

Bug#943465: fwupd is wrongly marked Multi-Arch: foreign

[Mario.Limonciello]

On Oct 25, 2019 14:46, Helmut Grohne  wrote:

[EXTERNAL EMAIL]

On Fri, Oct 25, 2019 at 04:01:10PM +, mario.limoncie...@dell.com wrote:
> I made some modifications and think I captured your suggestion here
> https://github.com/fwupd/fwupd/commit/3508aecefdbd81924314834ac9e14bcd71aa253f
>
> Can you make sure that looks good now?

Unfortunately, no. Ansgar Burchardt kindly pointed out that Built-Using
must refer to a source package, not a binary package. This was wrong in
the previous iteration and I didn't spot it. Refer to the debian policy
section 7.8.

Now there are two other subtle things left.

Previously, fwupd included the *.efi images. Now it recommends them. Is
that enough or should that be a hard dependency to retain the old
behaviour? I don't know. Does fwupd actually work without the *.efi
binaries?

It used to be a hard dependency, but these days the runtime will detect this 
situation and show the user an error that the efi binary is missing so they 
can't do UEFI updates until installed.

It was introduced about the same time we introduced signed binaries to Debian.



I'm also wondering why the signing-template includes the SIGNARCH in the
package name. This is not a regression, but it should follow the same
reasoning as for why fwupd-unsigned doesn't have to include an
architecture. Do note that the same binary package may be built from
different source packages for different architectures as long as now two
source packages build it for the same architecture. For instance
libsystemd-dev used to be built from different source packages for
linux-any and kfreebsd-any. Can we simplify that part as well?

Helmut

This was mostly copied off of what grub2 did, which split it up this way. I 
don't see a strong reason that it can't be adjusted (of course need to do 
package transitions and stuff).

Steve, any thoughts?

Bug#942507: pdfsam: Not working due to multiple errors

[Markus Koschany]

Control: severity -1 important

I'm downgrading this issue to important because pdfsam in testing is not
affected. As long as hibernate-validator 5.x does not migrate to
testing, before this bug is fixed in unstable, it should not be a problem




signature.asc
Description: OpenPGP digital signature

Bug#943529: python-debianbts: missing information on who closed a bug

[Sandro Tosi]

> if you look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937796 the
> 'Done' header mentions who closed this bug, but that information is not 
> exposed
> in debianbts:

it could be as simple as this:

diff --git a/debianbts/debianbts.py b/debianbts/debianbts.py
index 3393c69..4a05bac 100644
--- a/debianbts/debianbts.py
+++ b/debianbts/debianbts.py
@@ -417,6 +417,7 @@ def _parse_status(bug_el):
bug.log_modified = datetime.utcfromtimestamp(float(bug_el('log_modified')))
bug.tags = [_uc(tag) for tag in str(bug_el('tags')).split()]
bug.done = _parse_bool(bug_el('done'))
+bug.done_by = bug_el('done') if bug.done else None
bug.archived = _parse_bool(bug_el('archived'))
bug.unarchived = _parse_bool(bug_el('unarchived'))
bug.bug_num = int(bug_el('bug_num'))


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#943535: manpages-fr: man ip(7): struct sock_extended_err defined in linux/errqueue.h

[clohr]

Package: manpages-fr
Version: 3.65d1p1-1
Severity: minor
Tags: upstream

Dear Maintainer,
  The manpage of ip(7) may indicates that 'struct sock_extended_err' and
associated macros are defined in


Best regards
Christophe



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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

manpages-fr depends on no packages.

manpages-fr recommends no packages.

Versions of packages manpages-fr suggests:
ii  man-db [man-browser]  2.8.7-3
ii  manpages-fr-dev   3.65d1p1-1
ii  manpages-fr-extra 20151231

-- no debconf information

Bug#943536: lintian: Stop shipping profile 'debian/ftp-master-auto-reject'

[Felix Lechner]

Hi Bastian,

On Fri, Oct 25, 2019 at 2:51 PM Bastian Blank  wrote:
>
> How will this command line option work afterwards?
>
> | -F, --ftp-master-rejects

Thanks for pointing that out. Maybe we should not remove the profile.
Is anyone using that option?

Kind regards,
Felix Lechner

Bug#740580: O: fbset -- framebuffer device maintenance program

[Sudip Mukherjee]

Hi All,

On Mon, Mar 03, 2014 at 12:25:05PM +0100, Cyril Brulebois wrote:
> Guillem Jover  (2014-03-03):
> > This package has a lethargic upstream, and needs to be synced from time
> > to time with the latest Linux framebuffer header, accelerators, docs and
> > modes, from «linux/include/linux/fb.h» and «linux/Documentation/fb/»
> > respectively, which I've not done since linux-3.0.0-rc1, as I can't be
> > bothered any longer. It also produces a udeb, so people interested in
> > the installer might want to take a look.
> 
> I only quickly looked, but I didn't find anything obvious making use of
> the binaries the udeb contains, or a reference to the udeb itself; so I
> might be OK for it to go away entirely. Cc-ing -boot@ so that someone
> can yell if I missed something.

I have a framebuffer driver in the upstream kernel and have used fbset
to test the driver. Though I have not used the debian version and built
it from source for my use, I will hate to see it go away. I have looked
at the source and the docs needs to update and one change in the header
file.
I will like to maintain it if noone else has already shown interest and
if it is still orphan. I can see Guillem has updated it after making it
orphan, so not sure what the currect status is.


--
Regards
Sudip

Bug#943465: fwupd is wrongly marked Multi-Arch: foreign

[Steve McIntyre]

On Fri, Oct 25, 2019 at 06:32:48AM +0200, Helmut Grohne wrote:
>Package: fwupd
>Version: 1.3.2-5
>Severity: important
>User: debian-cr...@lists.debian.org
>Usertags: ftcbfs
>Control: affects -1 + src:fwupd-armhf-signed
>
>TL;DR: The *.efi images must not live in a M-A:foreign binary package.
>
>fwupd is presently marked Multi-Arch: foreign. Likely for good reasons.
>Unfortunately, this is subtly wrong. fwupd contains (unsigned) efi
>binaries in /usr/lib/fwupd/efi. These binaries have
>architecture-dependent names. When you cross build fwupd-armhf-signed
>from amd64, it tries to sign fwupdx64.efi and the build fails.
>
>Now we have two possible routes. Either fwupdx64.efi is part of the
>interface of fwupd. Then clearly the interface is architecture-dependent
>and the Multi-Arch: foreign marking is wrong. In the other case,
>fwupd-armhf-signed is accessing an internal aspect of fwupd and must not
>do that. The latter would essentially mean that cannot have
>fwupd-armhf-signed, so the former seems more plausible.
>
>Simply removing the foreign marking isn't going to make us much happier
>either (though it might fix cross building fwupd-armhf-signed). I think
>what we need here is recognizing that fwupd has both
>architecture-independent and architecture-dependent interfaces. The
>logical consequence is splitting the package into two (usually one being
>M-A:foreign and the other M-A:same).
>
>So I see two possible routes here:
> 1. Remove M-A:foreign. (Nobody likes that)
> 2. a. Move the efi packages to a separate non-M-A:foreign package.
>b. Have fwupd depend on that new package.
>c. Rename the fwupd dependency of fwupd-armhf-signed to that new
>   package.

Ummm, I don't think I follow your logic here at all. The normal system
pieces of the fwupd package (i.e. the bits that are executed by the
running Linux system need to match the arch you're running (to be
useful). But to be able to work on a normal system, the underlying EFI
binaries *must* match the hardware that's running (otherwise the EFI
firmware won't be able to use them at all). *However*, in some
circumstances (like building a live image) we want to allow
installation of all versions of the fwupd EFI binaries.

I think this particular situation is not well-described at all by M-A!
Maybe we could do something like:

 * fwupd (non-M-A) - bits in /usr/{s,}bin, must have the right arch
   installed
 * (we could possibly split out some of the common data into a
   M-A:foreign fwupd-data package)
 * fwupd-efi (M-A:same) for each architecture

but I don't see how to ensure that the *right* fwupd-efi package is
installed for a system that wants to run it...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross

Bug#943536: lintian: Stop shipping profile 'debian/ftp-master-auto-reject'

[Felix Lechner]

Package: lintian
Severity: wishlist
X-Debbugs-CC: nthyk...@debian.org, ftpmas...@debian.org

Hi,

Based on information from #debian-ftp, which is recorded in part below, the
profile is no longer being used. It will be removed in the near future.

Please respond with objections.

Kind regards,
Felix Lechner

13:44 < 1> lechner: ftp master uses it's copy from the dak git repo.
lintian is something else
13:54 < 1> dak calls lintian with it's own tags file, so the package
included profile is not used
13:55 < lechner> i am not aware that lintian unstands the format of your
file in
https://salsa.debian.org/ftp-team/dak/blob/master/config/debian/lintian.tags
14:08 < 2> ... I think it's pretty obvious that file from dak's config is
what's being used
14:09 < 2> config/debian/dak.conf: LintianTags "/srv/
ftp-master.debian.org/dak/config/debian/lintian.tags";
14:10 < 2> which is then parsed by LintianCheck in daklib/checks.py to
generate a file for lintian --tags-from-file
14:11 < 2> and daklib/lintian.py's generate_reject_messages looks at
whether they were fatal or nonfatal in the YAML input to decide whether to
allow overrides
14:12 < lechner> thanks for clarifying. i actually like that approach much
better.
14:13 < lechner>  i will remove the auto-reject profile shipped with
lintian in the near future.

Bug#943534: python3-lesscpy: fails to install: update-alternatives: error: alternative path /usr/bin/python3-lesscpy doesn't exist

[Andreas Beckmann]

Package: python3-lesscpy
Version: 0.13.0+ds-1.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up python3-lesscpy (0.13.0+ds-1.1) ...
  update-alternatives: error: alternative path /usr/bin/python3-lesscpy doesn't 
exist
  dpkg: error processing package python3-lesscpy (--configure):
   installed python3-lesscpy package post-installation script subprocess 
returned error exit status 2
  Processing triggers for libc-bin (2.29-2) ...
  Errors were encountered while processing:
   python3-lesscpy

With the python2 variant gone, the alternatives can probably be dropped
- but don't forget to properly remove them on upgrades.


cheers,

Andreas


python3-lesscpy_0.13.0+ds-1.1.log.gz
Description: application/gzip

Bug#907727: Empty directory is already present in orig tarball

[Russ Allbery]

Felix Lechner  writes:

> An override is more explicit, and also more self-explanatory, when
> compared to a '.placeholder'.

To me, an override implies that Lintian is wrong, and I don't think it
is.  (Whether the tag should exist is a different question; not all
problems are worth fixing.)  It's bad practice to ship empty directories
in tarballs precisely because they're not representable in Git (and
generally have a tendency to get lost in various ways).

> I re-read our prior messages, but still do not see why the ability to
> round-trip through Git is so important. Either way, the issue should
> IMHO be fixed in the tool chain that processes such round trips. Then we
> can remove the tag from Lintian.

I don't know that it's so important.  It feels like minor to pedantic.
It's just an avoidable minor issue.

> How would a placeholder created in debian/rules (or dh) help with the
> round-tripping issue? Does anyone create source packages from built
> source trees?

It means that if anything relied on the directory existing, the directory
would be recreated by unpacking the source package and whatever relied on
that would succeed.

You're correct that it doesn't help with keeping the directory in the
source package; it just makes sure it's created by the build step before
anything might use it.

-- 
Russ Allbery (r...@debian.org)  

Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker

[Luca Boccassi]

On Sat, 03 Mar 2018 17:49:02 -0700 Daniele Nicolodi <
daniele+deb...@grinta.net
> wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Daniele Nicolodi <
daniele+deb...@grinta.net
>
> 
> * Package name: dbus-broker
>   Version : 11
>   Upstream Author : David Herrmann <
dh.herrm...@gmail.com
>, Tom Gundersen <
t...@jklm.no
>, et al.
> * URL : 
https://github.com/bus1/dbus-broker/

> * License : Apache-2.0
>   Programming Lang: C
>   Description : Linux D-Bus Message Broker
> 
> The dbus-broker project is an implementation of a message bus as
> defined by the D-Bus specification. Its aim is to provide high
> performance and reliability, while keeping compatibility to the D-Bus
> reference implementation. It is exclusively written for Linux
> systems, and makes use of many modern features provided by recent
> Linux kernel releases.
> 
> I'll contact the dbus maintainers for advice, to offer to co-maintain
> the package, and for sponsoring the upload.  Others interested in the
> package are welcome to participate.

Hi,

Any update on dbus-broker? If you are looking for a sponsor, I am
willing to help.

Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#942518: Renewed Dutch translation for win32-loader

[Maarten]

Dear Holger


I have read your e-mail of 17 October 2019, in which you asked me two
questions about my Dutch translation for win32-loader.

Your questions are only about the following part of my translation.

SOURCE TEXT
Base URL for netboot images (linux and initrd.gz):

TRANSLATION
[Laat een basale URL het gedeelte van een URL zijn dat
gemeenschappelijk is voor alle bestanden van een server. Laat een
netwerk-opstart-image een archiefbestand zijn dat een bestandssysteem
bevat waarmee een computer kan worden opgestart via een netwerk.
--vertaler]\n
\n
Geef de basale URL voor de netwerk-opstart-images (linux en
initrd.gz):

YOUR QUESTIONS
You wrote that I had added a somewhat longer text to a string that
is short in English. You asked me whether I had checked that the
resulting long text will be correctly displayed by the program. You
also thought of the text as being displayed in a small box and asked
me whether that assumption is correct.

ANSWER TO YOUR FIRST QUESTION
I did not check that the translation will be correctly displayed by
the program.

However, checking the correct display of a translation is not my
responsibility. My responsibility is to provide the best possible
translation that complies with the translation instructions. In the
case of the above-mentioned translation, a translation instruction
was not given by the programmers. This means that I had complete
freedom in devising the best translation.

The characteristics of a perfect translation are many. One of them
is full usability for the purpose specified in the translation
instructions. When translation instructions are not provided, a
translator simply aims for maximum usefulness of the translation
itself for the target audience.

The correct display of a translation is the responsibility of the
programmers. The programmers can choose to use a text area with a
vertical scrollbar so that a translation will always fit, or they
can provide a translation instruction to make sure that a translation
will fit in the available space. The matter is not of my concern.

ANSWER TO YOUR SECOND QUESTION
I do not know whether the above translation is displayed in a small
box.

'Base URL for netboot images (linux and initrd.gz):' was found in
'work/l10n/win32-loader.c'. This file uses a function 'langstring'
that seems to be used in connection with nsis.

The website of nsis has a page about a message box. See
https://nsis.sourceforge.io/Reference/MessageBox . It is not clear
whether this message box has a vertical scrollbar that appears
automatically when needed. A procedure 'MessageBox' is called in 7
files in 'work' and their names end with '.nsi'.

The function 'langstring' seems to relate 'Base URL for netboot
images (linux and initrd.gz):' to 'custom5'. 'custom5' can also be
found in the file 'work/custom.nsi'. It contains '${NSD_CreateLabel}
0u 48u -3u 8u $(custom5)'. I cannot understand that code, however.

SUMMARY
You asked me whether I had checked that a long translation will be
correctly displayed by win32-loader. I did not check that. However,
checking the correct display of a translation is not my
responsibility.

You also asked me whether the translation is displayed in a small
box. I do not know that and I am not able to find that out.

CONCLUSION
Your questions have been answered.


With kind regards

Maarten
member of the Dutch translation team of Debian

Bug#943531: citadel does not creates socket unix and segfault at startup

[PICCORO McKAY Lenz]

Package: citadel-server
Version: 917-2+b1
Severity: important

Dear Maintainer,

   * What led up to the situation?

installed citadel-suite and does not work since buster, systemd (again)
startud does nto really start the service..

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

only install citadel

   * What was the outcome of this action?

does not stat, it said segfault and does not create socket. but daemon
are running

in fisrt place.. the isntallation scripts does not work
due the new behaviour of systemd su command and forces me to use sudo..

but agains now start but does not creates socket..

also package creates a user and does not use to start the daemon..

   * What outcome did you expect instead?

it that question necesary?


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages citadel-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libcitadel4917-2
ii  libcurl4   7.64.0-4
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libexpat1  2.2.6-2
ii  libical3   3.0.4-3
ii  libldap-2.4-2  2.4.47+dfsg-3
ii  libpam0g   1.3.1-5
ii  libsieve2-12.2.6-2
ii  libssl1.1  1.1.1c-1
ii  lsb-base   10.2019051400
ii  openssl1.1.1c-1
ii  patch  2.7.6-3+deb10u1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages citadel-server recommends:
pn  db4.6-util
ii  shared-mime-info  1.10-1

citadel-server suggests no packages.

-- Configuration Files:
/etc/citadel/public_clients changed [not included]
/etc/init.d/citadel changed [not included]

-- debconf information:
* citadel/Password: (password omitted)
* citadel/Password_again: (password omitted)
  citadel/BadUser:
  citadel/LDAPBaseDN: dc=example,dc=com
  citadel/LDAPBindDN:
* citadel/ServerIPAddress: 0.0.0.0
  citadel/LDAPServer: 0.0.0.0
* citadel/LoginType: Internal
  citadel/LDAPBindDNPassword: OpenSesame
* citadel/Administrator: citaroot
  citadel/LDAPServerPort: 389

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#943530: dahdi-source: The initialisation-script dahdi_span_types fails to access the correct spantypes-file

[Matthias]

Package: dahdi-source
Version: 1:2.11.1.0.20170917~dfsg-7
Severity: important
Tags: patch

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dahdi-source depends on:
ii  bzip2 1.0.6-9.2~deb10u1
ii  debhelper 12.1.1
ii  module-assistant  0.11.10

Versions of packages dahdi-source recommends:
ii  dahdi-linux  1:2.11.1.0.20170917~dfsg-7

dahdi-source suggests no packages.

-- no debconf information

Diff auf /usr/sbin/dahdi_span_types:

179c179
<   cat "$device/spantype" | while read st; do
---
>   cat "$device/dahdi_spantype" | while read st; do
192c192
<   find $DEVICES -follow -maxdepth 1 -name spantype | \
---
>   find $DEVICES -follow -maxdepth 1 -name dahdi_spantype | \
255c255
<   cat "$device/spantype" | while read st; do
---
>   cat "$device/dahdi_spantype" | while read st; do
281c281
<   attr_file="$device/spantype"
---
>   attr_file="$device/dahdi_spantype"
338c338
<   cat "$device/spantype" | while read spantype; do
---
>   cat "$device/dahdi_spantype" | while read spantype; do


/var/log/messages before applying the path: error messages

Oct 25 20:23:19 produktiv 'dahdi_handle_device'[619]: D: Running 
'/usr/share/dahdi/handle_device.d/10-span-types'
Oct 25 20:23:19 produktiv 'dahdi_handle_device'[631]: D: Running 
'/usr/share/dahdi/handle_device.d/10-span-types'
Oct 25 20:23:19 produktiv 'dahdi_handle_device'[631]: cat: 
'/sys/devices/pci:00/:00:1e.0/:07:01.0/pci::07:01.0/spantype': 
No such file or directory
Oct 25 20:23:19 produktiv 'dahdi_handle_device'[619]: cat: 
'/sys/devices/pci:00/:00:1e.0/:07:01.0/pci::07:01.0/spantype': 
No such file or directory
Oct 25 20:23:19 produktiv 'dahdi_handle_device'[631]: D: Running 
'/usr/share/dahdi/handle_device.d/20-span-assignments'
Oct 25 20:23:19 produktiv 'dahdi_handle_device'[619]: D: Running 
'/usr/share/dahdi/handle_device.d/20-span-assignments'
Oct 25 20:23:19 produktiv 'dahdi_handle_device'[631]: using 
'/etc/dahdi/assigned-spans.conf'
Oct 25 20:23:19 produktiv 'dahdi_handle_device'[619]: using 
'/etc/dahdi/assigned-spans.conf'


/var/log/messages after the patch

Oct 25 21:00:36 produktiv 'dahdi_handle_device'[611]: D: Running 
'/usr/share/dahdi/handle_device.d/10-span-types'
Oct 25 21:00:36 produktiv 'dahdi_handle_device'[623]: D: Running 
'/usr/share/dahdi/handle_device.d/10-span-types'
Oct 25 21:00:36 produktiv 'dahdi_handle_device'[623]: D: Running 
'/usr/share/dahdi/handle_device.d/20-span-assignments'
Oct 25 21:00:36 produktiv 'dahdi_handle_device'[611]: D: Running 
'/usr/share/dahdi/handle_device.d/20-span-assignments'
Oct 25 21:00:36 produktiv 'dahdi_handle_device'[611]: using 
'/etc/dahdi/assigned-spans.conf'
Oct 25 21:00:36 produktiv 'dahdi_handle_device'[623]: using 
'/etc/dahdi/assigned-spans.conf'


I don't know the consequences of the error and the patch,
because I could not yet finish my installation.
Regards
Matthias

Bug#943529: python-debianbts: missing information on who closed a bug

[Sandro Tosi]

Package: python-debianbts
Version: 2.8.2
Severity: normal

Hello,
if you look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937796 the
'Done' header mentions who closed this bug, but that information is not exposed
in debianbts:

In [293]: b = debianbts.get_status(937796)[0]

In [294]: for f in dir(b):
 ...: if not f.startswith('_'):
 ...: print(f, getattr(b, f))
 ...:
affects []
archived False
blockedby []
blocks [937695, 937960, 937961, 938168]
bug_num 937796
date 2019-08-30 09:00:20
done True
fixed_versions ['python-gnuplotlib/0.31-2']
forwarded
found_versions ['python-gnuplotlib/0.31-1']
location db-h
log_modified 2019-10-25 03:09:04
mergedwith []
msgid 
originator Matthias Klose 
owner
package src:python-gnuplotlib
pending done
severity normal
source python-gnuplotlib
subject python-gnuplotlib: Python2 removal in sid/bullseye
summary
tags ['sid', 'bullseye']
unarchived False


it would be very useful to be able to access that information

thanks for maintaining python-debianbts! :)


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python-debianbts depends on:
ii  python   2.7.16-1
ii  python-pysimplesoap  1.16.2-1

python-debianbts recommends no packages.

python-debianbts suggests no packages.

-- no debconf information

Bug#925563: dxvk installation script doesn't install 32 bit libraries to 64 bit prefix

[Alexandre Viau]

I hacked on this for a bit and I could not find a reliable way to have
it work automatically on all configurations.

I was pretty sure that my script worked on all setups and this shows
that I was wrong.

I am starting to think that the best way to handle this is to have the
user manually specify everything:
 - wine executable to use
 - architecture to install

If somebody has an idea, now would be a good time!

-- 
Aleaxandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#943016: Bug#938690: dia: Python2 removal in sid/bullseye

[Andreas Henriksson]

Control: unblock 943016 by 938690

On Fri, Oct 25, 2019 at 04:08:14PM +0200, Martin wrote:
> Quoting Andreas Henriksson :
> > This however would (I assume) make the trac-diavisview and ldaptor
> > reverse dependencies non-functional.
> 
> trac-diavisview depends on the dia executable, not on the Python 2
> plugin, AFAIK. Therefore from this point no objection against just
> disabling Python 2 support in Dia.

Many thanks for the feedback.

Not sure why trac-diavisview was set as a blocker for dia
given your info. Removing again.

This means we should also make sure make a patch v3 that again drops
the Breaks: trac-diavisview that was added in patch v2.

Regards,
Andreas Henriksson

Bug#943528: gpaste: 'gpaste-client upload' depends on missing command 'wgetpaste'

[Mike Miller]

Package: gpaste
Version: 3.34.1-1
Severity: normal

Dear Maintainer,

The `gpaste-client upload` command has a hard dependency on a command
called `wgetpaste`, which is expected to be an executable in the user's
PATH. This command is not packaged in Debian as far as I can tell.

The error message looks like this

  Oct 25 11:40:36 localhost gpaste-daemon[17913]: 
g_subprocess_communicate_utf8_async: assertion 'G_IS_SUBPROCESS (subprocess)' 
failed

The package `pastebinit` _is_ packaged in Debian and seems to work as a
drop in replacement. The only requirement seems to be a program that
takes text on stdin and writes out a URL on stdout. This could be solved
with a one line patch and a Suggests: pastebinit.

However, maybe it would make sense for the user to be able to configure
whatever script they want to use to upload text to a pastebin service?

And moreover, maybe this should be disabled by default until the user
explicitly opts in and chooses a paste upload handler and service?

I am open to proposing patches or working with upstream if you think
this should be worked out there instead of Debian patches.

Thanks for maintaining this package!

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: 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 gpaste depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  libc62.29-2
ii  libglib2.0-0 2.62.1-1
ii  libgpaste11  3.34.1-1
ii  libgtk-3-0   3.24.12-1

gpaste recommends no packages.

gpaste suggests no packages.

-- no debconf information

Bug#943527: webext-umatrix: umatrix is unusable with current firefox-esr

[Daniel Reichelt]

Package: webext-umatrix
Version: 1.3.16+dfsg-2
Severity: grave
Justification: renders package unusable

Hi,

since the latest update of firefox-esr from 60.9 to 68.2, umatrix is no longer
usable. I tried v1.4 from addons.mozilla.org which seems to do fine.

Please update to the latest version. Thanks!

Daniel



-- System Information:
Debian Release: 10.1
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 
'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 
'oldstable-debug'), (500, 'oldstable'), (99, 'testing'), (98, 'unstable'), (96, 
'oldoldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-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), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages webext-umatrix depends on:
ii  fonts-font-awesome 5.0.10+really4.7.0~dfsg-1
ii  fonts-roboto-unhinted  2:0~20170802-3
ii  libjs-codemirror   5.43.0-1
ii  libjs-punycode 1.3.2-2
ii  publicsuffix   20190415.1030-1

Versions of packages webext-umatrix recommends:
ii  firefox-esr  68.2.0esr-1~deb10u1

webext-umatrix suggests no packages.

-- no debconf information

Bug#931640: webext-ublock-origin: no longer functional in firefox-esr

[Markus Koschany]

Am 25.10.19 um 21:43 schrieb Manolo Díaz:
> Package: webext-ublock-origin
> Version: 1.22.2+dfsg-1
> Followup-For: Bug #931640
> 
> Dear Maintainer,
> The same here. Upgrading to 1.22.2+dfsg-1 changes nothing.

1.22.2+dfsg-1 works. You have to restart Firefox and potentially disable
and then re-enable the addon.

Markus Koschany



signature.asc
Description: OpenPGP digital signature

Bug#931640: webext-ublock-origin: no longer functional in firefox-esr

[Manolo Díaz]

Package: webext-ublock-origin
Version: 1.22.2+dfsg-1
Followup-For: Bug #931640

Dear Maintainer,
The same here. Upgrading to 1.22.2+dfsg-1 changes nothing.

Best Regards,
Manolo Díaz


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

Kernel: Linux 5.3.7+ (SMP w/8 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

webext-ublock-origin depends on no packages.

Versions of packages webext-ublock-origin recommends:
ii  firefox-esr  68.2.0esr-1~deb10u1

Versions of packages webext-ublock-origin suggests:
pn  ublock-origin-doc  

-- no debconf information

Bug#943526: node-tslib: directory vs. symlink conflict: /usr/share/nodejs/tslib

[Andreas Beckmann]

Package: node-tslib
Version: 1.10.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + node-rollup-plugin-typescript

Hi,

during a test with piuparts I noticed your package installs files over
an existing symlink shipped or created by another package.

Your package ships:

drwxr-xr-x root/root 0 2019-08-03 13:44 ./usr/share/nodejs/tslib/
-rw-r--r-- root/root   701 2019-06-10 22:24 
./usr/share/nodejs/tslib/package.json
-rw-r--r-- root/root  2290 2019-06-10 22:24 
./usr/share/nodejs/tslib/tslib.d.ts
-rw-r--r-- root/root36 2019-06-10 22:24 
./usr/share/nodejs/tslib/tslib.es6.html
-rw-r--r-- root/root  9436 2019-06-10 22:24 
./usr/share/nodejs/tslib/tslib.es6.js
-rw-r--r-- root/root32 2019-06-10 22:24 
./usr/share/nodejs/tslib/tslib.html
-rw-r--r-- root/root 12037 2019-06-10 22:24 
./usr/share/nodejs/tslib/tslib.js

but package node-typescript ships:

lrwxrwxrwx root/root 0 2019-10-15 06:12 ./usr/share/nodejs/tslib -> 
typescript/lib


Installing something over existing symlinks is considered bad practice.
See e.g. https://lists.debian.org/87ehlevcrf@windlord.stanford.edu

It may break in subtle ways and dpkg cannot detect this as a problem.
* Your package might silently overwrite files installed at the symlink
  destination by other packages.
* If the package shipping the symlink decides to make the link point
  somewhere else (or turn it into a real directory), the files owned
  by your package "will be lost" somewhere in the filesystem.
* Depending on installation order the problematic path will be created
  either as a symlink or a directory: the package installed first will
  "win" and all others have "lost".
  Note that dpkg intentionally does not replace directories with
  symlinks and vice versa, see in particular the end of point 4 in
  
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade
  (Note: Adding Pre-Depends is *not* a solution.)

Please move the files shipped in your package to the "real" location.

>From the attached log (scroll to the bottom...):

0m24.0s ERROR: installs objects over existing directory symlinks:
  /usr/share/nodejs/tslib/package.json (node-tslib) != 
/usr/share/nodejs/typescript/lib/package.json (?)
/usr/share/nodejs/tslib -> typescript/lib
  /usr/share/nodejs/tslib/tslib.d.ts (node-tslib) != 
/usr/share/nodejs/typescript/lib/tslib.d.ts (?)
/usr/share/nodejs/tslib -> typescript/lib
  /usr/share/nodejs/tslib/tslib.es6.html (node-tslib) != 
/usr/share/nodejs/typescript/lib/tslib.es6.html (?)
/usr/share/nodejs/tslib -> typescript/lib
  /usr/share/nodejs/tslib/tslib.es6.js (node-tslib) != 
/usr/share/nodejs/typescript/lib/tslib.es6.js (?)
/usr/share/nodejs/tslib -> typescript/lib
  /usr/share/nodejs/tslib/tslib.html (node-tslib) != 
/usr/share/nodejs/typescript/lib/tslib.html (?)
/usr/share/nodejs/tslib -> typescript/lib
  /usr/share/nodejs/tslib/tslib.js (node-tslib) != 
/usr/share/nodejs/typescript/lib/tslib.js (?)
/usr/share/nodejs/tslib -> typescript/lib


cheers,

Andreas


node-rollup-plugin-typescript_1.0.0-1.log.gz
Description: application/gzip

Bug#937926: python-pbr package

[Daniel Schepler]

In a message to #937926 you said that you've re-introduced python-pbr.
Could I ask where that was re-introduced?  I've checked the new upload
of src:python-pbr version 5.4.3-1, and I've also checked unstable and
NEW for anything like a python2-pbr source package without seeing
anything relevant.
-- 
Daniel

Bug#940136: aqbanking-tools: Transaction fails with 9075::Starke Kundenauthentifizierung notwendig.

[Micha Lenk]

Hi Joachim,

On 25.10.19 17:41, Joachim Breitner wrote:

But I guess more needs to happen for gnucash to be able to use it,
right? Gnucash depends on libaqbanking35-plugins.


In theory only a rebuild of the gnucash package with the new 
libaqbanking and libgwenhywfar from experimental installed is required 
to make it use the new AqBanking. In practice you also need a patch to 
fix a bug in Gnucash.


In case you're using Debian buster and you can't wait for official 
backports to be made available on backports.debian.org, you can make use 
of some preliminary buster backports from this APT repository:


# Command to let APT trust the repository key
curl -sf https://people.debian.org/~micha/PSD2/PSD2-APT-repo.asc \
| sudo apt-key add -

# Entry for your sources.list
deb https://people.debian.org/~micha/PSD2/ buster-experimental-backports/

The needed patch is applied to the Gncuash source package that is 
distributed in that APT repository.


Please note that you will still need to manually migrate your old 
AqBanking configuration to the new format. Some documentation about that 
is available in the AqBanking wiki (sorry, German only):


> AqBanking6 kann halbautomatisch die bisherige Konfiguration von
> AqBanking5 übernehmen. Dazu muß man allerdings die Daten speziell
> zur Verfügung stellen:
>
> cd ~/.aqbanking
> mkdir -p settings6
> cp -r settings/* settings6
>
> Dieses Verzeichnis - "settings6" - verwendet AqBanking6 dann
> zukünftig, so daß grundsätzlich auch die parallele Verwendung von
> Anwendungen, die AqBanking5 verwenden (benutzt weiterhin das
> Verzeichnis "settings"), und solchen, die AqBanking6 verwenden,
> möglich sein sollte.
Source: https://www.aquamaniac.de/rdm/projects/aqbanking/wiki/AqBanking6

I hope this gets you started.

Best regards,
Micha

Bug#943525: lintian: Create private name spaces for tags

[Felix Lechner]

Package: lintian
Severity: wishlist

Hi,

Tags currently reside in a global name space, which has many
drawbacks. Based on my difficulties of separating reused tags in the
'files' family of checks, the time is right to implement private name
spaces. Then two checks can share the same tag name without a
conflict.

Some things may break, like overrides. We can probably fix those by
adding the name changes to data/override/renamed-tags.

I am happy to present advantages if someone wants to hang on to the
current setup.

For now, let's focus on:

(1) What's the best tag format?
(2) How can we mitigate potential breakage for custom profiles
such as FTP Master and pkg-perl-tools, as well as for downstream users
in Debian derivatives?

Here are some suggestions for the format:

debian/changelog/malformed-version
debian/changelog:malformed-version
debian/changelog->malformed-version
debian/changelog@malformed-version
debian/changelog#malformed-version
malformed-version
debian/changelog^malformed-version

Putting the check up front means the tags sort naturally. Also, some
formats interfere less with shell scripts than others. All suggestions
are welcome. Which is your favorite?

Kind regards,
Felix Lechner

Bug#942686: fix the installation of 3.8 extensions

[Joel Rosdahl]

reopen 942686
thanks

I applied the patch too quickly (see #943506) – it doesn't work with
the Python 3.7 filenames in current Debian unstable.

Python 3.8 apparently produces

apsw.cpython-38-x86_64-linux-gnu.so
apsw.cpython-38d-x86_64-linux-gnu.so

but Python 3.7 produces

apsw.cpython-37m-x86_64-linux-gnu.so
apsw.cpython-37dm-x86_64-linux-gnu.so

so the proposed pattern

usr/lib/python3*/*-packages/*.cpython-3?*-*.so

in python-apsw.install matches both the regular and the debug filename
for Python 3.7.

Matthias Klose: What's the preferred way of dealing with this situation?

-- Joel

Bug#943524: python3-stdlib-extensions: FTBFS with ModuleNotFoundError: No module named '_sysconfigdata_d_linux_x86_64-linux-gnu'

[Andreas Beckmann]

Source: python3-stdlib-extensions
Version: 3.8.0~a3-1
Severity: serious

Hi,

python3-stdlib-extensions/experimental FTBFS in an up-to-date
sid/experimental pbuilder environment:

[...]
cd 3.8 && PYTHONPATH=/build/python3-stdlib-extensions-3.8.0~a3/3.8/Lib 
python3.8-dbg setup.py build
running build
running build_ext
setup.py:623: DeprecationWarning: invalid escape sequence \s
  archs = re.findall('-arch\s+(\w+)', cflags)
setup.py:4: DeprecationWarning: the imp module is deprecated in favour of 
importlib; see the module's documentation for alternative uses
  import sys, os, imp, re, optparse
setup.py:787: DeprecationWarning: SO is deprecated, use EXT_SUFFIX
  so_ext = sysconfig.get_config_var("SO")
Traceback (most recent call last):
  File "setup.py", line 877, in 
main()
  File "setup.py", line 849, in main
setup(# PyPI Metadata (PEP 301)
  File "/build/python3-stdlib-extensions-3.8.0~a3/3.8/Lib/distutils/core.py", 
line 148, in setup
dist.run_commands()
  File "/build/python3-stdlib-extensions-3.8.0~a3/3.8/Lib/distutils/dist.py", 
line 966, in run_commands
self.run_command(cmd)
  File "/build/python3-stdlib-extensions-3.8.0~a3/3.8/Lib/distutils/dist.py", 
line 985, in run_command
cmd_obj.run()
  File 
"/build/python3-stdlib-extensions-3.8.0~a3/3.8/Lib/distutils/command/build.py", 
line 135, in run
self.run_command(cmd_name)
  File "/build/python3-stdlib-extensions-3.8.0~a3/3.8/Lib/distutils/cmd.py", 
line 313, in run_command
self.distribution.run_command(command)
  File "/build/python3-stdlib-extensions-3.8.0~a3/3.8/Lib/distutils/dist.py", 
line 985, in run_command
cmd_obj.run()
  File 
"/build/python3-stdlib-extensions-3.8.0~a3/3.8/Lib/distutils/command/build_ext.py",
 line 310, in run
customize_compiler(self.compiler)
  File 
"/build/python3-stdlib-extensions-3.8.0~a3/3.8/Lib/distutils/sysconfig.py", 
line 197, in customize_compiler
get_config_vars('CC', 'CXX', 'CFLAGS',
  File 
"/build/python3-stdlib-extensions-3.8.0~a3/3.8/Lib/distutils/sysconfig.py", 
line 501, in get_config_vars
func()
  File 
"/build/python3-stdlib-extensions-3.8.0~a3/3.8/Lib/distutils/sysconfig.py", 
line 461, in _init_posix
_temp = __import__(name, globals(), locals(), ['build_time_vars'], 0)
ModuleNotFoundError: No module named '_sysconfigdata_d_linux_x86_64-linux-gnu'
make: *** [debian/rules:60: dbg-stamp-py3.8] Error 1
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2


Andreas


python3-stdlib-extensions_3.8.0~a3-1.log.gz
Description: application/gzip

Bug#943425: klibc: [s390x] SIGSEGV in mksh testcase funsub-2

[Thorsten Glaser]

Control: block 943425 by 925358

I can’t debug this currently ☹ hitting qemu-user-static bugs.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#925358: qemu-user-static: mis-emulates something to do with process/signal handling

[Thorsten Glaser]

Control: retitle 925358 qemu-user-static: mis-emulates something to do with 
process/signal handling

Dixi quod…

> Using qemu-user-static in an m68k chroot:
> 
> # ./mksh -c '/bin/echo foo; echo bar'
> foo
> ^C^\
> 
> (it just hangs here, with qemu-user-static:i386; on the

This now happens with qemu-s390x-static for me as well, which has
worked on the buildd (see #943425). I tested both the i386 and the
amd64 static binary and both freeze like that, killable only by
kill -9 on the qemu-s390x-static process from outside the chroot.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#943523: xpdf: FTBFS: build/PDFCore.cc:311:37: error: no matching function for call to 'PDFDoc::findPage(Ref&)'

[Andreas Beckmann]

Source: xpdf
Version: 3.04-13exp2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

xpdf/experimental FTBFS on all architectures:
https://buildd.debian.org/status/package.php?p=xpdf=experimental

 debian/rules build-arch
dh build-arch
   dh_update_autotools_config -a
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
cp goo/gfile.h xpdf/xfile.h
sed -e s/GFILE/XFILE/g -i xpdf/xfile.h
cp goo/gfile.cc xpdf/xfile.cc
sed -e s/GFILE/XFILE/g -i xpdf/xfile.cc
cp xpdf/GlobalParams.h xpdf/XPDFParams.h
sed -e s/globalParams/xpdfParams/g -e s/GlobalParams/XPDFParams/g \
-e s/GLOBALPARAMS/XPDFPARAMS/g -e s/popplerParams/globalParams/g \
-e s/PopplerParams/GlobalParams/g \
-i xpdf/XPDFParams.h
cp xpdf/GlobalParams.cc xpdf/XPDFParams.cc
sed -e s/globalParams/xpdfParams/g -e s/GlobalParams/XPDFParams/g \
-e s/GLOBALPARAMS/XPDFPARAMS/g -e s/popplerParams/globalParams/g \
-e s/PopplerParams/GlobalParams/g \
-i xpdf/XPDFParams.cc
mkdir -p build
cp goo/parseargs.c goo/parseargs.h xpdf/CoreOutputDev.cc xpdf/CoreOutputDev.h 
xpdf/PDFCore.cc xpdf/PDFCore.h xpdf/XPDFApp.cc xpdf/XPDFApp.h xpdf/XPDFCore.cc 
xpdf/XPDFCore.h xpdf/XPDFParams.cc xpdf/XPDFParams.h xpdf/XPDFTree.cc 
xpdf/XPDFTree.h xpdf/XPDFViewer.cc xpdf/XPDFViewer.h xpdf/xfile.cc xpdf/xfile.h 
xpdf/xpdf.cc xpdf/config.h xpdf/XPDFTreeP.h xpdf/about-text.h xpdf/*.xbm 
xpdf/xpdfIcon.xpm build
sed -E -e s/GString/GooString/g -e s/GMutex/GooMutex/g -e s/GHash/GooHash/g \
-e s/GList/GooList/g -e s/\/\/g \
-e s/GBool/bool/g -e s/gTrue/true/g -e s/gFalse/false/g \
-e 's/deleteGooList\(([^,]+), ([^)]+)\);/deleteGooList<\2> \(\1\);/' \
-i build/*
mv build/parseargs.c build/parseargs.cc
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
x86_64-linux-gnu-g++ -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/include/poppler -I/usr/include/poppler/goo 
-I/usr/include/poppler/splash -Wno-write-strings -Wno-format-extra-args 
-Wfatal-errors -DHAVE_DIRENT_H -DHAVE_PAPER_H 
-DSYSTEM_XPDFRC=\"/etc/xpdf/xpdfrc\"  -c -o build/CoreOutputDev.o 
build/CoreOutputDev.cc
x86_64-linux-gnu-g++ -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/include/poppler -I/usr/include/poppler/goo 
-I/usr/include/poppler/splash -Wno-write-strings -Wno-format-extra-args 
-Wfatal-errors -DHAVE_DIRENT_H -DHAVE_PAPER_H 
-DSYSTEM_XPDFRC=\"/etc/xpdf/xpdfrc\"  -c -o build/PDFCore.o build/PDFCore.cc
build/PDFCore.cc: In member function 'virtual void 
PDFCore::displayDest(LinkDest*, double, int, bool)':
build/PDFCore.cc:311:37: error: no matching function for call to 
'PDFDoc::findPage(Ref&)'
 topPageA = doc->findPage(pageRef);
 ^
compilation terminated due to -Wfatal-errors.
make[1]: *** [: build/PDFCore.o] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:50: build-arch] Error 2


Andreas

Bug#943499: telegram-desktop: Disable building in big endian archs

[Коля Гурьев]

tags 943499 patch
stop

25.10.2019 17:12, Lisandro Damián Nicanor Pérez Meyer пишет:
> A removal for those archs has been asked in 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943467 but
> ideally the package should list the architectures it builds instead of being 
> Arch: any. This will not
> waste buildds' time and also provide a clearer insight to people looking for 
> this app in their archs.

I agree with you, but dpkg does not seem to provide an easy way to
express such assertion that the package works only on little-endian
architectures.

I tried to just list[1] all possible CPUs in the Architecture field, but
I do not understand its syntax. It looks like line breaks or comments
are not allowed.

 [1]: 
https://salsa.debian.org/debian/telegram-desktop/commit/c22fa4f7cfb3105f3c9889d5342ff7aeeef68157

Below is a copy of the commit.

commit c22fa4f7cfb3105f3c9889d5342ff7aeeef68157
Author: Nicholas Guriev 
Date:   Tue Oct 22 09:10:07 2019 +0300

Restrict supported architectures

diff --git a/debian/control b/debian/control
index 4fd34d9..ba7a6ec 100644
--- a/debian/control
+++ b/debian/control
@@ -35,7 +35,9 @@ Vcs-Git: https://salsa.debian.org/debian/telegram-desktop.git
 Vcs-Browser: https://salsa.debian.org/debian/telegram-desktop
 
 Package: telegram-desktop
-Architecture: any
+# Only little endian is supported. Cmd:
+# awk '/^\s*[^#]/ && $5 == "little" {print $1}' ../dpkg-1.19.7/data/cputable
+Architecture: i386 ia64 alpha amd64 arm arm64 mipsel mipsr6el mips64el 
mips64r6el nios2 powerpcel ppc64el riscv64 sh3 sh4 tilegx
 Depends: qt5-image-formats-plugins (>=5.5), ${misc:Depends}, ${shlibs:Depends}
 Recommends: fonts-open-sans
 Built-Using: ${cpplibs:Built-Using}

Bug#943522: node-file-entry-cache: fails to clean after build

[Andreas Beckmann]

Source: node-file-entry-cache
Version: 5.0.1+~2.0.1+~2.0.0+~1.0.0+~2.0.1-3
Severity: serious

Hi,

node-file-entry-cache/experimental fails to clean after a successful
build:

 debian/rules clean
dh clean
   dh_clean
rm: cannot remove './debian/node_modules': Is a directory
dh_clean: rm -f -- debian/node-file-entry-cache.substvars 
debian/node-flat-cache.substvars debian/node-write.substvars 
./debian/node_modules debian/files returned exit code 1
make: *** [debian/rules:66: clean] Error 255

This sounds like you have a 'debian/node_modules' entry without
trailing slash in debian/clean.


Andreas


node-file-entry-cache_5.0.1+~2.0.1+~2.0.0+~1.0.0+~2.0.1-3_twice.log.gz
Description: application/gzip

Bug#943465: fwupd is wrongly marked Multi-Arch: foreign

[Mario.Limonciello]

> -Original Message-
> From: Helmut Grohne 
> Sent: Friday, October 25, 2019 9:30 AM
> To: Limonciello, Mario
> Cc: 943...@bugs.debian.org
> Subject: Re: Bug#943465: fwupd is wrongly marked Multi-Arch: foreign
> 
> 
> [EXTERNAL EMAIL]
> 
> On Fri, Oct 25, 2019 at 02:08:34PM +, mario.limoncie...@dell.com wrote:
> > I took a stab at how this should work here (not yet merged):
> >
> https://github.com/fwupd/fwupd/commit/809eb181f57dc5158b5d37d2855a0a48
> eafc3565
> >
> > Can you please review that and make sure you agree it's done correctly?
> 
> I think this should technically work, but it seems unnecessarily
> complex.

Thanks for reviewing it.

> 
> You split the various firmware packages into
> fwupd-$(DEB_HOST_ARCH)-unsigned. Why did you do that? Why not have one
> real fwupd-unsigned package? Clearly you intend them to be
> coinstallable, which is why you marked them M-A:same. Note that M-A:same
> doesn't make sense, when you only list one specific architecture in the
> Architecture field. Can you maybe do the following?
> 
> d/control:
> Package: fwupd-unsigned
> Architecture: amd64 i386 ...
> Multi-Arch: same
> no Provides:
> 
> I also think that Built-Using must refer to real packages, which is not
> presently the case. My suggestion would ensure that.
> 

I made some modifications and think I captured your suggestion here
https://github.com/fwupd/fwupd/commit/3508aecefdbd81924314834ac9e14bcd71aa253f

Can you make sure that looks good now?

Bug#943472: launchy: Rename icons cache folder to .weby-icon-cache or similar

[Boyuan Yang]

Hi Pavel,

Just FYI, The package launchy has been removed from Debian Testing/Sid due to
the lack of maintenance and the inactivity of upstream. As a result, this bug
is unlikely to be solved unless someone steps in and reintroduce launchy into
Debian. The current old version in Debian stable will be left untouched.

Best,
Boyuan Yang

在 2019-10-25五的 11:01 +0200，Pavel Reznicek写道：
> Package: launchy
> Version: 2.5-4
> Severity: wishlist
> 
> Dear Maintainer,
> 
>   would it be possible to patch the package so that the application is
> storing its icons cache into a hidden directory, instead of ~/weby-icon-
> cache ? It is a bit distracting when such an obviously temp direcotry is
> always being recreated in my home dir. The patch should be trivial: just
> change launchy-2.5/plugins/weby/weby.cpp at line 95, e.g. to ~/.weby-icon-
> cache.
> 
> Thank you,
> Pavel
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (840, 'testing'), (740, 'unstable'), (738, 'experimental'),
> (540, 'proposed-updates'), (540, 'stable'), (500, 'oldstable-proposed-
> updates'), (500, 'oldoldstable'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored:
> LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (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 launchy depends on:
> ii  libc6   2.29-2
> ii  libgcc1 1:9.2.1-8
> ii  libqt4-network  4:4.8.7+dfsg-19
> ii  libqtcore4  4:4.8.7+dfsg-19
> ii  libqtgui4   4:4.8.7+dfsg-19
> ii  libstdc++6  9.2.1-8
> ii  libx11-62:1.6.8-1
> 
> launchy recommends no packages.
> 
> Versions of packages launchy suggests:
> ii  launchy-plugins  2.5-4
> ii  launchy-skins2.5-4
> 
> -- no debconf information
> 


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

Bug#943521: node-proxyquire: fails to clean after build: rm: cannot remove './debian/node_modules': Is a directory

[Andreas Beckmann]

Source: node-proxyquire
Version: 2.1.3+~1.0.1+~1.0.2-3
Severity: serious

Hi,

node-proxyquire fails to clean after a successful build:

 debian/rules clean
dh clean
   dh_clean
rm: cannot remove './debian/node_modules': Is a directory
dh_clean: rm -f -- debian/node-proxyquire.substvars ./debian/node_modules 
debian/files returned exit code 1
make: *** [debian/rules:47: clean] Error 255


This sounds like you have a 'debian/node_modules' entry without
trailing slash in debian/clean.


Andreas


node-proxyquire_2.1.3+~1.0.1+~1.0.2-3_twice.log.gz
Description: application/gzip

Bug#943520: mdadm: Introduce broken state parsing to mdadm

[Dan Streetman]

Package: mdadm
Version: 4.1-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear Maintainer,

* Currently, mounted raid0/md-linear arrays have no indication/warning when one 
or more members are removed or suffer from some non-recoverable error 
condition. The mdadm tool shows "clean" state regardless if a member was 
removed.

* The patch proposed in this SRU addresses this issue by introducing a new 
state "broken", which is analog to "clean" but indicates that array is not in a 
good/correct state. The commit, available upstream as 43ebc910 ("mdadm: 
Introduce new array state 'broken' for raid0/linear") [0], was extensively 
discussed and received a good amount of reviews/analysis by both the current 
mdadm maintainer as well as an old maintainer.

* One important note here is that this patch requires a counter-part in the 
kernel to be fully functional, which was SRUed in LP: #1847773.
It works fine/transparently without this kernel counter-part though.


In Ubuntu, the attached patch was applied to achieve the following:

  * Introduce "broken" state for RAID0/Linear in mdadm (LP: #1847924)


Thanks for considering the patch.
diff -Nru mdadm-4.1/debian/control mdadm-4.1/debian/control
--- mdadm-4.1/debian/control2019-05-04 23:58:27.0 -0400
+++ mdadm-4.1/debian/control2019-10-13 17:04:34.0 -0400
@@ -1,8 +1,7 @@
 Source: mdadm
 Section: admin
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian QA Group 
+Maintainer: Debian QA Group 
 Build-Depends: debhelper (>= 11), po-debconf, groff-base
 Standards-Version: 4.3.0
 Vcs-Git: https://git.dgit.debian.org/mdadm
diff -Nru 
mdadm-4.1/debian/patches/lp-1847924-introduce-new-array-state-broken.patch 
mdadm-4.1/debian/patches/lp-1847924-introduce-new-array-state-broken.patch
--- mdadm-4.1/debian/patches/lp-1847924-introduce-new-array-state-broken.patch  
1969-12-31 19:00:00.0 -0500
+++ mdadm-4.1/debian/patches/lp-1847924-introduce-new-array-state-broken.patch  
2019-10-13 17:04:34.0 -0400
@@ -0,0 +1,159 @@
+Subject: Introduce new array state 'broken' for raid0/linear
+
+Currently if a md raid0/linear array gets one or more members removed while
+being mounted, kernel keeps showing state 'clean' in the 'array_state'
+sysfs attribute. Despite udev signaling the member device is gone, 'mdadm'
+cannot issue the STOP_ARRAY ioctl successfully, given the array is mounted.
+
+Nothing else hints that something is wrong (except that the removed devices
+don't show properly in the output of mdadm 'detail' command). There is no
+other property to be checked, and if user is not performing reads/writes
+to the array, even kernel log is quiet and doesn't give a clue about the
+missing member.
+
+This patch is the mdadm counterpart of kernel new array state 'broken'.
+The 'broken' state mimics the state 'clean' in every aspect, being useful
+only to distinguish if an array has some member missing. All necessary
+paths in mdadm were changed to deal with 'broken' state, and in case the
+tool runs in a kernel that is not updated, it'll work normally, i.e., it
+doesn't require the 'broken' state in order to work.
+Also, this patch changes the way the array state is showed in the 'detail'
+command (for raid0/linear only) - now it takes the 'array_state' sysfs
+attribute into account instead of only rely in the MD_SB_CLEAN flag.
+
+Author: Guilherme G. Piccoli 
+Origin: upstream,
+git.kernel.org/pub/scm/utils/mdadm/mdadm.git/commit/?id=cb77f8c598ede2b7efec23f899b1cda44c315195
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1847924
+Last-Update: 2019-10-13
+---
+ Detail.c  | 14 --
+ Monitor.c |  8 ++--
+ maps.c|  1 +
+ mdadm.h   |  1 +
+ mdmon.h   |  2 +-
+ monitor.c |  4 ++--
+ 6 files changed, 23 insertions(+), 7 deletions(-)
+
+diff --git a/Detail.c b/Detail.c
+index b3e857a..d24f334 100644
+--- a/Detail.c
 b/Detail.c
+@@ -81,6 +81,7 @@ int Detail(char *dev, struct context *c)
+   int external;
+   int inactive;
+   int is_container = 0;
++  char *arrayst;
+ 
+   if (fd < 0) {
+   pr_err("cannot open %s: %s\n",
+@@ -485,9 +486,18 @@ int Detail(char *dev, struct context *c)
+   else
+   st = ", degraded";
+ 
++  if (array.state & (1 << MD_SB_CLEAN)) {
++  if ((array.level == 0) ||
++  (array.level == LEVEL_LINEAR))
++  arrayst = map_num(sysfs_array_states,
++sra->array_state);
++  else
++  arrayst = "clean";
++  } else
++  arrayst = "active";
++
+   printf(" State : %s%s%s%s%s%s \n",
+- (array.state & (1 << 

Bug#943519: RM: golang-1.12 -- ROM; obsolete, superseded by golang-1.13

[Dr. Tobias Quathamer]

Package: ftp.debian.org
Severity: normal

Dear FTP Masters,

please remove golang-1.12, it's obsolete now that golang-1.13 has been
accepted into the archive. There are no reverse dependencies.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#942106: (some kind of) transition: add python3.8 as a supported python3 version

[Matthias Klose]

On 11.10.19 18:46, Paul Gevers wrote:

Hi Matthias,

On 10-10-2019 15:06, Matthias Klose wrote:

Please setup a tracker to add python3.8 as a supported python3 version.
This is non-blocking, as packages can migrate on their own once built.
I'm not yet starting this, just want to have an overview of affected
packages.

Please could you re-use the final version of the python3.7 tracker,
which had several iterations in #902582?


Done. Will appear slightly after 17:30 UTC if I didn't make any mistake.


I'm now ready to upload python3-defaults to unstable and would like to proceed 
on Saturday. Ideally that should be followed by binNMUs, so that we don't end up 
with too much infrastructure like broken python test frameworks.


Matthias

Bug#939364: stretch-pu: package python-acme/0.28.0-1~deb9u2

[Adam D. Barratt]

On Fri, 2019-10-25 at 10:58 -0700, Brad Warren wrote:
> I’m an upstream maintainer of python-acme.
> 
> Both Let’s Encrypt [1] and the Certbot client which uses this library
> encourage people to use Let’s Encrypt’s staging endpoint to test that
> they have things working correctly before using Let’s Encrypt’s
> production endpoint which has strict rate limits. Certbot uses the
> staging endpoint when —dry-run is provided which we tell all Debian
> Stretch users to use [2] and we have been doing so for years.

Thanks for the extra context.

Regards,

Adam

Bug#942399: rxvt-unicode: server lockup making all clients unresponsive

[rharwood]

Package: rxvt-unicode
Version: 9.22-6+b2
Followup-For: Bug #942399

Dear Maintainer,

I've gotten a few more of these lockups (two today).  They all look about the
same.  Here's one of the tracebacks:

(gdb) thread apply all bt

Thread 1 (Thread 0x7f7a8ee7f880 (LWP 11279)):
#0  0x7f7a8fd6328e in __libc_read (fd=4, buf=buf@entry=0x7ffc5bc2ff20, 
nbytes=nbytes@entry=536) at ../sysdeps/unix/sysv/linux/read.c:26
#1  0x55a8bdabcd63 in read (__nbytes=536, __buf=0x7ffc5bc2ff20, 
__fd=) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44
#2  0x55a8bdabcd63 in serve() () at ./../libptytty/src/proxy.C:158
#3  0x55a8bdabd0a7 in ptytty::use_helper() () at 
./../libptytty/src/proxy.C:268
#4  0x55a8bdabd111 in ptytty::use_helper() () at 
./../libptytty/src/proxy.C:318
#5  0x55a8bdabd111 in ptytty::init() () at ./../libptytty/src/proxy.C:318
#6  0x55a8bda99349 in main(int, char**) (argc=3, argv=0x7ffc5bc30328) at 
rxvtd.C:230
(gdb)

Causing the read call to immediately return launches us back into an
epoll_wait (still on fd=4).  Unsurprisingly, close(4) then caused the daemon
to crash, terminating all clients.

Thanks,
--Robbie

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

Kernel: Linux 5.2.0-3-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_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 rxvt-unicode depends on:
ii  base-passwd   3.5.46
ii  libc6 2.29-2
ii  libfontconfig12.13.1-2+b1
ii  libgcc1   1:9.2.1-8
ii  libgdk-pixbuf2.0-02.40.0+dfsg-1
ii  libglib2.0-0  2.62.1-1
ii  libperl5.30   5.30.0-8
ii  libstartup-notification0  0.12-6
ii  libx11-6  2:1.6.8-1
ii  libxft2   2.3.2-2
ii  libxrender1   1:0.9.10-1
ii  ncurses-base  6.1+20190803-1
ii  ncurses-term  6.1+20190803-1

Versions of packages rxvt-unicode recommends:
ii  fonts-dejavu2.37-1
ii  fonts-ipaexfont-gothic [fonts-japanese-gothic]  00401-1
ii  fonts-ipafont-gothic [fonts-japanese-gothic]00303-19
ii  fonts-vlgothic [fonts-japanese-gothic]  20141206-5

Versions of packages rxvt-unicode suggests:
ii  sensible-utils  0.0.12

-- no debconf information

Bug#943517: boxbackup: FTBFS with test failures

[Andreas Beckmann]

Package: boxbackup
Version: 0.13~~git20190527.g039c4a1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

boxbackup/experimental FTBFS in my sid/experimental pbuilder environment
on amd64 and i386. This seems to be a recent regression, since earlier
builds of that version have succeeded.

Unfortunately I can't tell from the buildlog which error is the actual
failure and which errors are expected for some tests.


Andreas


boxbackup_0.13~~git20190527.g039c4a1-2.log.gz
Description: application/gzip

Bug#943518: RFS: systune/0.5.8 [ITA] -- kernel tuning through the /proc file system

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "systune"

 * Package name: systune
   Version : 0.5.8
   Upstream Author : NA
 * URL : NA
 * License : GNU GPLv2
 * Vcs : None
   Section : admin

It builds those binary packages:

  systune - kernel tuning through the /proc file system

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

  https://mentors.debian.net/package/systune

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/systune/systune_0.5.8.dsc

Changes since the last upload:

   * use DESTDIR in Makefile accordig to GNU coding standard
   * New maintainer (Closes: #636734)
   * Update compat level to 9


-- 
Regards
Sudip

Bug#929453: lftp: hangs on getting directory contents at the end of mirror

[Nico Golde]

Any idea what is causing this?

Bug#943516: valinor: FTBFS and autopkgtest failure due to new version of python-colorama

[Paul Gevers]

Source: valinor
Version: 1.1.4-1
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python-colorama

[X-Debbugs-CC: debian...@lists.debian.org,
python-color...@packages.debian.org]

Dear maintainers,

With a recent upload of python-colorama the autopkgtest of valinor fails
in testing when that autopkgtest is run with the binary packages of
python-colorama from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
python-coloramafrom testing0.4.1-1
valinorfrom testing1.1.4-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. I also tried
to rebuild on reproducible-builds.org infrastructure and your package
FTBFS with the same error.

Currently this regression is blocking the migration of python-colorama
to testing [1]. Of course, python-colorama shouldn't just break your
autopkgtest (or even worse, your package), but the change in
python-colorama was intended and your package needs to update to the new
situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from python-colorama should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
python-colorama/0.4.1-1. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=python-colorama

https://ci.debian.net/data/autopkgtest/testing/amd64/v/valinor/3248223/log.gz

autopkgtest [18:12:07]: test valinor: [---
=== python3.7 ===
.F
==
FAIL: testARMNoneEABIGDB (test.test_outputdir.TestCLIOutputDirectory)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.ejtpkkiz/downtmp/autopkgtest_tmp/test/test_outputdir.py",
line 48, in testARMNoneEABIGDB
runWithDir()
  File
"/tmp/autopkgtest-lxc.ejtpkkiz/downtmp/autopkgtest_tmp/test/test_outputdir.py",
line 46, in runWithDir
out = self.runCheck(args)
  File
"/tmp/autopkgtest-lxc.ejtpkkiz/downtmp/autopkgtest_tmp/test/test_outputdir.py",
line 33, in runCheck
self.assertEqual(status, 0)
AssertionError: 1 != 0
 >> begin captured stdout << -

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/share/valinor/valinor/main.py", line 36, in main
version=pkg_resources.require("valinor")[0].version,
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
900, in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
791, in resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (colorama 0.4.1
(/usr/lib/python3/dist-packages),
Requirement.parse('colorama<0.4,>=0.3'), {'valinor'})


- >> end captured stdout << --

--
Ran 2 tests in 0.245s

FAILED (failures=1)
autopkgtest [18:12:08]: test valinor: ---]



signature.asc
Description: OpenPGP digital signature

Bug#943513: fiona ftbfs when building for multiple python3 versions

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 10/25/19 6:59 PM, Matthias Klose wrote:
> fiona ftbfs when building for multiple python3 versions, patch at
> http://launchpadlibrarian.net/448415280/fiona_1.8.9-1_1.8.9-1ubuntu1.diff.gz

Thanks for the patch, it's applied in git and a new upload to unstable
will follow shortly.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#939364: stretch-pu: package python-acme/0.28.0-1~deb9u2

[Brad Warren]

I’m an upstream maintainer of python-acme.

Both Let’s Encrypt [1] and the Certbot client which uses this library encourage 
people to use Let’s Encrypt’s staging endpoint to test that they have things 
working correctly before using Let’s Encrypt’s production endpoint which has 
strict rate limits. Certbot uses the staging endpoint when —dry-run is provided 
which we tell all Debian Stretch users to use [2] and we have been doing so for 
years.

If this update is released after November 1st, I would expect a significant 
amount of bug reports and confusion as well as some people resorting to using 
the production environment to debug domain validation problems with their setup 
which can easily cause them to become rate limited.

Delaying this update won’t break existing setups where Certbot is automatically 
renewing the user’s certificates, but I personally think there will be enough 
headaches about —dry-run breaking from those initially creating or modifying 
their setup that it’s worth releasing early.

Best,
Brad

[1] https://letsencrypt.org/docs/staging-environment/
[2] https://certbot.eff.org/lets-encrypt/debianstretch-other

> On Oct 25, 2019, at 10:18 AM, Adam D. Barratt  
> wrote:
> 
> On Tue, 2019-09-03 at 22:16 -0400, Harlan Lieberman-Berg wrote:
>> We have a proposed update for acme in stretch (oldstable).  This is
>> necessary to prevent the package, and all its dependencies, stopping
>> to work due to changes to the web service that the acme module is
>> primarily used for.  (Let's Encrypt)
> 
> Apparently this is now only an issue for the staging endpoint in the
> immediate future, according to 
> https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unauthenticated-resource-gets/74380/3
> 
> On that basis, could releasing this update now wait until the next
> stretch point release, or is the change to the staging endpoint still
> likely to have a significant enough impact to want to make an earlier
> release?
> 
> Regards,
> 
> Adam
> 
> -- 
> To unsubscribe, send mail to 939364-unsubscr...@bugs.debian.org.
> 

Bug#943507: [Pkg-javascript-devel] Bug#943507: eslint: FTBFS in experimental

[Jonas Smedegaard]

Hi Andreas,

Quoting Andreas Beckmann (2019-10-25 18:04:33)
> eslint FTBFS in my pbuilder sid/experimental environment on both amd64 
> and i386. There is a test failing, but I couldn't easily see which 
> one:
> 
> # tests 16628
> # pass 16627
> # fail 1
> make[1]: *** [debian/rules:79: override_dh_auto_test] Error 1

Thanks for reporting this.

This is a known error - and one of the reasons eslint is still kept in 
experimental: Oddly, 1-2 tests succeeds in my cowbuilder environment but 
hangs in Debian sbuild - and surpringly also in your pbuilder (I had 
thought it was somehow tied to differences between cowbuilder and 
sbuild).

The tests use TAP output: errors are found with regex '^not ok':

> not ok 15448 configInitializer "before each" hook for "should create default 
> config"
>  Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure 
> "done()" is called; if returning a Promise, ensure it resolves.
>  at done (/usr/lib/nodejs/mocha/lib/runnable.js:298:13)
>  at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:372:7)
>  at Hook.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:346:7)
>  at next (/usr/lib/nodejs/mocha/lib/runner.js:304:10)
>  at Immediate._onImmediate (/usr/lib/nodejs/mocha/lib/runner.js:334:5)

The eslint currently in experimental is several years old, and I am 
slowly grinding my way through dependencies and build-dependencies to 
bump to newer releases, hoping that magically solves to problem, but any 
help identifying the cause more directly is certainly appreciated, and 
that would make it possible to release even an older release of eslint 
to unstable - even older releases are very useful for some purposes.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#943515: linux-image-5.2.0-3-amd64: Cannot resume from suspend

[Anton Bobov]

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

After linux 5 I can't resume after suspend, my laptop remains is suspend mode
(the power button is slowly blinking because it's in suspend mode) and only way
to continue is to reboot. The old linux-image-4.19.0-5-amd64 works without
problems.

I found a couple similar issues with other Lenovo laptops, perhaps related to
some Thinkpad modules.



-- Package-specific info:
** Version:
Linux version 5.2.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-22)) #1 SMP Debian 5.2.17-1 (2019-09-26)

** Command line:
BOOT_IMAGE=/vmlinuz-5.2.0-3-amd64 root=/dev/mapper/debian-root ro quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[   13.445826] audit: type=1400 audit(1572023319.447:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session" pid=687 
comm="apparmor_parser"
[   13.445829] audit: type=1400 audit(1572023319.447:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium" 
pid=687 comm="apparmor_parser"
[   13.449112] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1f.3/sound/card0/input19
[   13.449170] input: HDA Intel PCH Dock Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input20
[   13.449230] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input21
[   13.449277] input: HDA Intel PCH Dock Headphone as 
/devices/pci:00/:00:1f.3/sound/card0/input22
[   13.449321] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1f.3/sound/card0/input23
[   13.449367] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input24
[   13.449422] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sound/card0/input25
[   13.449468] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1f.3/sound/card0/input26
[   13.449512] input: HDA Intel PCH HDMI/DP,pcm=9 as 
/devices/pci:00/:00:1f.3/sound/card0/input27
[   13.449559] input: HDA Intel PCH HDMI/DP,pcm=10 as 
/devices/pci:00/:00:1f.3/sound/card0/input28
[   13.460206] audit: type=1400 audit(1572023319.459:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-soffice" 
pid=688 comm="apparmor_parser"
[   13.460210] audit: type=1400 audit(1572023319.459:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-soffice//gpg" 
pid=688 comm="apparmor_parser"
[   13.474882] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[   13.475153] thermal thermal_zone3: failed to read out thermal zone (-61)
[   13.515781] input: ACPI Virtual Keyboard Device as 
/devices/virtual/input/input29
[   13.879108] iwlwifi :04:00.0 wlp4s0: renamed from wlan0
[   14.338471] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   14.390407] Bluetooth: Core ver 2.22
[   14.390425] NET: Registered protocol family 31
[   14.390426] Bluetooth: HCI device and connection manager initialized
[   14.390429] Bluetooth: HCI socket layer initialized
[   14.390437] Bluetooth: L2CAP socket layer initialized
[   14.390441] Bluetooth: SCO socket layer initialized
[   14.516578] usbcore: registered new interface driver btusb
[   14.516989] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
[   14.524008] Bluetooth: hci0: Device revision is 5
[   14.524009] Bluetooth: hci0: Secure boot is enabled
[   14.524010] Bluetooth: hci0: OTP lock is enabled
[   14.524010] Bluetooth: hci0: API lock is enabled
[   14.524011] Bluetooth: hci0: Debug lock is disabled
[   14.524012] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[   14.527584] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-11-5.sfi
[   14.527588] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi
[   14.539281] media: Linux media interface: v0.10
[   14.562876] videodev: Linux video capture interface: v2.00
[   14.565670] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   14.565671] Bluetooth: BNEP filters: protocol multicast
[   14.565673] Bluetooth: BNEP socket layer initialized
[   14.722519] uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b52c)
[   14.731103] uvcvideo: Failed to initialize entity for entity 6
[   14.731104] uvcvideo: Failed to register entities (-22).
[   14.731373] input: Integrated Camera: Integrated C as 
/devices/pci:00/:00:14.0/usb1/1-10/1-10:1.0/input/input30
[   14.731522] usbcore: registered new interface driver uvcvideo
[   14.731523] USB Video Class driver (1.1.1)
[   15.973580] Bluetooth: hci0: Waiting for firmware download to complete
[   15.973953] Bluetooth: hci0: Firmware loaded in 1423262 usecs
[   15.973981] Bluetooth: hci0: Waiting for device to boot
[   15.984996] Bluetooth: hci0: Device booted in 10770 usecs
[   15.986243] bluetooth hci0: firmware: 

Bug#939364: stretch-pu: package python-acme/0.28.0-1~deb9u2

[Adam D. Barratt]

On Tue, 2019-09-03 at 22:16 -0400, Harlan Lieberman-Berg wrote:
> We have a proposed update for acme in stretch (oldstable).  This is
> necessary to prevent the package, and all its dependencies, stopping
> to work due to changes to the web service that the acme module is
> primarily used for.  (Let's Encrypt)

Apparently this is now only an issue for the staging endpoint in the
immediate future, according to 
https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unauthenticated-resource-gets/74380/3

On that basis, could releasing this update now wait until the next
stretch point release, or is the change to the staging endpoint still
likely to have a significant enough impact to want to make an earlier
release?

Regards,

Adam

Bug#943513: fiona ftbfs when building for multiple python3 versions

[Matthias Klose]

Package: src:fiona
Version: 1.8.9-1
Severity: important
Tags: sid bullseye patch
User: debian-pyt...@lists.debian.org
Usertags: python3.8

fiona ftbfs when building for multiple python3 versions, patch at
http://launchpadlibrarian.net/448415280/fiona_1.8.9-1_1.8.9-1ubuntu1.diff.gz

Bug#943512: notion: FTBFS on i386 with test failure

[Andreas Beckmann]

Source: notion
Version: 3+2019092501-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

notion/experimental FTBFS on i386 (which is a regression from sid):
https://buildd.debian.org/status/fetch.php?pkg=notion=i386=3%2B2019092501-1=1569833560=0

   dh_auto_test -a
make -j4 test
make[1]: Entering directory '/<>'
>> pkg-config found Lua 5.3 (available: lua5.3 lua-5.3).
>> Lua 5.3 binary is /usr/bin/lua5.3 and luac is /usr/bin/luac5.3
make -C mod_xrandr test
make[2]: Entering directory '/<>/mod_xrandr'
for i in test_xrandr*.lua ; do echo 'Testing' $i ; /usr/bin/lua5.3 $i ; done
Testing test_xrandr.lua
Testing test_xrandr_remove_screen.lua
make[2]: Leaving directory '/<>/mod_xrandr'
make -C mod_xinerama test
make[2]: Entering directory '/<>/mod_xinerama'
/usr/bin/lua5.3 test_xinerama.lua

Testing:merge_contained_screens
Input:
   1: { x=0, y=0, h=600, w=800 }
Output:
   1: { x=0, y=0, h=600, w=800, ids={ 1 } }

Testing:merge_contained_screens
Input:
   1: { x=0, y=0, h=600, w=800 }
   2: { x=0, y=0, h=600, w=800 }
Output:
   1: { x=0, y=0, h=600, w=800, ids={ 1, 2 } }

Testing:merge_contained_screens
Input:
   1: { x=0, y=0, h=600, w=800 }
   2: { x=100, y=100, h=400, w=600 }
Output:
   1: { x=0, y=0, h=600, w=800, ids={ 1, 2 } }

Testing:merge_contained_screens
Input:
   1: { x=0, y=0, h=600, w=800 }
   2: { x=100, y=100, h=600, w=800 }
Output:
   1: { x=0, y=0, h=600, w=800, ids={ 1 } }
   2: { x=100, y=100, h=600, w=800, ids={ 2 } }

Testing:merge_overlapping_screens
Input:
   1: { x=0, y=0, h=600, w=800 }
Output:
   1: { x=0, y=0, h=600, w=800, ids={ 1 } }

Testing:merge_overlapping_screens
Input:
   1: { x=0, y=0, h=600, w=800 }
   2: { x=0, y=0, h=600, w=800 }
Output:
   1: { x=0, y=0, h=600, w=800, ids={ 1, 2 } }

Testing:merge_overlapping_screens
Input:
   1: { x=0, y=0, h=600, w=800 }
   2: { x=100, y=100, h=400, w=600 }
Output:
   1: { x=0, y=0, h=600, w=800, ids={ 1, 2 } }

Testing:merge_overlapping_screens
Input:
   1: { x=0, y=0, h=600, w=800 }
   2: { x=100, y=100, h=600, w=800 }
Output:
   1: { x=0, y=0, h=700, w=900, ids={ 1, 2 } }

Testing:merge_overlapping_screens
Input:
   1: { x=0, y=0, h=600, w=800 }
   2: { x=400, y=400, h=600, w=800 }
   3: { x=500, y=0, h=300, w=500 }
Output:
   1: { x=0, y=0, h=1000, w=1200, ids={ 1, 2, 3 } }

Testing:merge_overlapping_screens
Input:
   1: { x=0, y=0, h=600, w=800 }
   2: { x=900, y=100, h=300, w=300 }
   3: { x=400, y=400, h=600, w=800 }
Output:
   1: { x=0, y=0, h=1000, w=1200, ids={ 1, 2, 3 } }

Testing:merge_overlapping_screens_alternative
Input:
   1: { x=0, y=0, h=600, w=800 }
   2: { x=400, y=400, h=600, w=800 }
   3: { x=900, y=100, h=300, w=300 }
Output:
   1: { x=0, y=0, h=1000, w=1200, ids={ 1, 2 } }
   2: { x=900, y=100, h=300, w=300, ids={ 3 } }
make[2]: Leaving directory '/<>/mod_xinerama'
make -C libtu test
make[2]: Entering directory '/<>/libtu'
make -C test test
make[3]: Entering directory '/<>/libtu/test'
cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Os -W -Wall -pedantic 
-DCF_XFREE86_TEXTPROP_BUG_WORKAROUND -DHAVE_X11_BMF   -DHAS_SYSTEM_ASPRINTF=1 
-DNOTION_RELEASE='"3+2019092501"' -MMD -Os -W -Wall -pedantic 
-DCF_XFREE86_TEXTPROP_BUG_WORKAROUND -DHAVE_X11_BMF   -DHAS_SYSTEM_ASPRINTF=1 
-DNOTION_RELEASE='"3+2019092501"'  -D_POSIX_C_SOURCE=200112L -W -Wall -pedantic 
-MMD -Os -W -Wall -pedantic -DCF_XFREE86_TEXTPROP_BUG_WORKAROUND -DHAVE_X11_BMF 
-I../..  -DHAS_SYSTEM_ASPRINTF=1 -DNOTION_RELEASE='"3+2019092501"' 
-D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED -std=c99 -DCF_HAS_VA_COPY -MMD -o 
tutest ../misc.c ../tokenizer.c ../util.c ../output.c tutest.c -llua5.3 -ldl -lm
In file included from ../tokenizer.c:424:
../np/np-conv.h:15:13: warning: ‘num_to_char’ defined but not used 
[-Wunused-function]
   15 |  static int num_to_##T(T *ret, const NPNum *num, bool allow_uns_big) \
  | ^~~
../np/np-conv.h:118:1: note: in expansion of macro ‘FN_NUM_TO_SIGNED’
  118 | FN_NUM_TO_SIGNED(char, UCHAR_MAX, CHAR_MAX, CHAR_MIN)
  | ^~~~
tutest.c: In function ‘main’:
tutest.c:92:14: warning: unused parameter ‘argc’ [-Wunused-parameter]
   92 | int main(int argc, char *argv[])
  |  ^~~~
./tutest
[TESTING] libtu 
[TEST] test_get_token: [ERROR]: 33
make[3]: *** [Makefile:21: test] Error 1
make[3]: Leaving directory '/<>/libtu/test'
make[2]: *** [Makefile:50: test] Error 2
make[2]: Leaving directory '/<>/libtu'
make[1]: *** [Makefile:59: test] Error 2
make[1]: Leaving directory '/<>'
dh_auto_test: make -j4 test returned exit code 2


Andreas

Bug#943401: libreoffice: Autopkgtests are failing since 2019-10-21

[Rene Engelhard]

Hi,

On Fri, Oct 25, 2019 at 06:48:45PM +0200, Rene Engelhard wrote:
> > or adding information what is going wrong?
> 
> See above. apt-get build-dep libreoffice, install the test
> depenencies of smoketest, debian/tests/smoketest in the chroot.

Or just build libreoffice as is in sid. Same error when it tries to run
the first C++ unit test.

Regards,

Rene
> 

Bug#943401: libreoffice: Autopkgtests are failing since 2019-10-21

[Rene Engelhard]

On Fri, Oct 25, 2019 at 06:45:27PM +0200, Matthias Klose wrote:
> Control: tags -1 + moreinfo
> 
> On 25.10.19 18:33, Rene Engelhard wrote:
> > And since then I also can just reproduce it in a chroot, too.
> 
> You didn't say that before.

I did in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943401#17

--- snip ---
So, the last exception one (which I badly edited out of my last mail,
after I
actually mentioned it..  - my bad.) is reproducible here in a quick
"debian/tests/smoketest" run in a uptodate sid chroot.

Given LO didn't change (what gets installed) and the exceptionprotector
stuff gets
built with the new(er) g++ and this ends up in

Failure instantiating protector
"/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.3.1/workdir/LinkTarget/Library/unoexceptionprotector.so",
"unoexceptionprotector"
make: ***
[/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.3.1/solenv/gbuild/CppunitTest.mk:114:
/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.3.1/workdir/CppunitTest/smoketest.test]
Error 1
make: Target 'CppunitTest_smoketest' not remade because of errors.
--- snip ---
. My paste said exactly that:

> Please could you provide a test case,

No

> or adding information what is going wrong?

See above. apt-get build-dep libreoffice, install the test
depenencies of smoketest, debian/tests/smoketest in the chroot.

Regards,

Rene

Bug#943401: libreoffice: Autopkgtests are failing since 2019-10-21

[Matthias Klose]

Control: tags -1 + moreinfo

On 25.10.19 18:33, Rene Engelhard wrote:

And since then I also can just reproduce it in a chroot, too.


You didn't say that before. Please could you provide a test case, or adding 
information what is going wrong?

Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector) (was: Re: Bug#943401: libreoffice: Autopkgtests are failing since 2019-10-21)

[Rene Engelhard]

Hi,

On Fri, Oct 25, 2019 at 06:33:13PM +0200, Rene Engelhard wrote:
> On Fri, Oct 25, 2019 at 06:25:43PM +0200, Matthias Klose wrote:
> > [...] -12 was uploaded on Oct 23, but you say
> > that the tests started failing on Oct 21.
> 
> No, the submitter did which clearly was wrong. Please read the bug,
> I said that at my very first message.

Which is why I reitled the bug already ...

> > So why do you think this is related to gcc-9?
> 
> Because the exception-related message started on Oct 24. See
> https://ci.debian.net/packages/libr/libreoffice/unstable/amd64/:
> 
> https://ci.debian.net/data/packages/unstable/amd64/libr/libreoffice/3241554.log
> oh, gcc-9 9.2.1-12.
> Log:
> https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreoffice/3241554/log.gz

... to what we have here. (yes, this thread has the old subject, but
that doesn't matter for the bug contents.)

Changing subject now...

Regards,

Rene

Bug#943476: django-reversion: Python2 removal in sid/bullseye + Django 2.2 support

[Sandro Tosi]

control: retitle -1 django-reversion: Django 2.2 support
control: user debian-pyt...@lists.debian.org
control: usertag - py2removal

On Fri, 25 Oct 2019 11:54:34 +0200 Thomas Goirand  wrote:
> Source: django-reversion
> Version: 3.0.3-1
> Severity: serious
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

python2 support was dropped as part of 3.0.4-1
(https://tracker.debian.org/news/1045684/accepted-django-reversion-304-1-source-all-into-unstable/),
so i removed the tags for py2removal as it doesnt apply here.

> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests (the specific reason can be found searching this
> source package in
> https://people.debian.org/~morph/mass-bug-py2removal_take2.txt ).

please be careful with cut & paste :) django-reversion is not in that
list as it was not flagged as part of the second set of MBF bugs

> Moreover, this package needs to add support for Django 2.2 which is is SID
> since 3 days after Buster is released. Your package will be AUTORM if you
> don't do anything to fix the situation.

this is still valid, and there might be 2.2 support upstream already
(had a very quick glance at the repo)

Bug#942893: ftp.debian.org: please drop MD5sum lines from Packages

[Steve McIntyre]

On Thu, Oct 24, 2019 at 01:27:44PM +0200, Thomas Schmitt wrote:
>Hi,
>
>i wrote:
>> How about mirror checking by SHA256 in grab_md5, before computing the
>> MD5 for jigdo ?
>
>Or you could let libjte internally compute both, SHA256 and MD5,
>let it work with SHA256, but store in .jigdo and .template the MD5.

Much cleaner to switch to sha256 here, I think.

>(I just checked the API definition. If you can tolerate the function
> names libjte_set_md5_path() and libjte_add_md5_demand(), then the
> API part used by xorriso will need no change, whatever you decide.
>
> Not so good looks the API part which re-narrates the way how genisoimage
> produced jigdo. Functions libjte_decide_file_jigdo() and
> libjte_write_match_record() have MD5 char arrays as parameters.
> They'd need to be deprecated and/or replaced by new functions.
> I am not aware of any other user of libjte except xorriso. So maybe
> just throw out the "Traditional Data File API".

I'll take a look at thst shortly. Working on the core jigdo tool first.

> What happens to "powerpc" ISOs ?
> Will you backport the new JTE to genisoimage ?

We haven't made official "powerpc" ISOs in a while, so I'm not sure we
need to bother.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.

Bug#943511: RM: opentoken -- ROM; dead upstream, replaced with wisitoken

[Nicolas Boulenguez]

Package: ftp.debian.org
Severity: normal

The upstream author is not maintaining opentoken anymore.
He is rewritting a new library from scratch.
http://www.stephe-leake.org/ada/wisitoken.html

Bug#943401: libreoffice: Autopkgtests are failing since 2019-10-21

[Rene Engelhard]

Hi,

On Fri, Oct 25, 2019 at 06:25:43PM +0200, Matthias Klose wrote:
> [...] -12 was uploaded on Oct 23, but you say
> that the tests started failing on Oct 21.

No, the submitter did which clearly was wrong. Please read the bug,
I said that at my very first message.

> So why do you think this is related to gcc-9?

Because the exception-related message started on Oct 24. See
https://ci.debian.net/packages/libr/libreoffice/unstable/amd64/:

https://ci.debian.net/data/packages/unstable/amd64/libr/libreoffice/3241554.log
oh, gcc-9 9.2.1-12.
Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreoffice/3241554/log.gz

And since then I also can just reproduce it in a chroot, too.

Regards,

Rene

Bug#933334: ugene: FTBFS in buster (dpkg-shlibdeps error)

[Santiago Vila]

On Fri, Oct 25, 2019 at 05:49:25PM +0200, Andreas Beckmann wrote:
> On Mon, 29 Jul 2019 11:02:45 + Santiago Vila  wrote:
> > Package: src:ugene
> > Version: 1.31.1+dfsg-1
> 
> > I tried to build this package in buster but it failed:
> 
> I cannot reproduce this in buster, ugene just builds fine in my pbuilder
> buster environment (normal, -A, -B; amd64 and i386). Did you mean bullseye?

I meant buster. I only tried amd64, where -A works and -B fails.

I've put all my failed build logs here:

https://people.debian.org/~sanvila/build-logs/ugene/

I'm using sbuild. You will also see that I'm using eatmydata, but at
least in one build log I didn't use eatmydata and it also failed, so
eatmydata is not to blame for the failure.

> In sid it now fails with
> 
> make[3]: *** No rule to make target 'QtWebKit/QWebView', needed by
> '_tmp/ui/ui_Reporter.h'.  Stop.

That's very strange because sid has version 1.31.1+dfsg-1 as well.
It would seem that this is a Makefile bug and it worked for you by
pure chance in buster.

I can offer ssh access to one of my machines, where the problem
happened 100% of the time so far. Please contact me privately for
details.

Thanks.

Bug#943510: python-urllib3: FTBFS with test failures

[Andreas Beckmann]

Source: python-urllib3
Version: 1.25.6-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

python-urllib3/experimental FTBFS with some failing tests:
https://buildd.debian.org/status/fetch.php?pkg=python-urllib3=all=1.25.6-1=1570856398=0

   dh_auto_test -i -O--buildsystem=pybuild
I: pybuild base:217: cd /<>/.pybuild/cpython2_2.7_urllib3/build; 
python2.7 -m pytest --ignore=test/appengine --ignore=test/with_dummyserver 
--ignore=test/test_connectionpool.py --ignore=test/test_ssl.py 
--ignore=test/contrib/test_pyopenssl.py 
--ignore=test/contrib/test_securetransport.py 
--ignore=test/contrib/test_socks.py -k-test_recent_date
= test session starts ==
platform linux2 -- Python 2.7.17rc1, pytest-4.6.5, py-1.8.0, pluggy-0.12.0
rootdir: /<>, inifile: setup.cfg
collected 476 items / 1 deselected / 475 selected

test/test_collections.py .   [  7%]
test/test_compatibility.py ...   [  8%]
test/test_connection.py  [  9%]
test/test_exceptions.py .[ 12%]
test/test_fields.py ...  [ 15%]
test/test_filepost.py ...[ 17%]
test/test_no_ssl.py ..   [ 17%]
test/test_poolmanager.py .   [ 23%]
test/test_proxymanager.py ...[ 23%]
test/test_queue_monkeypatch.py . [ 24%]
test/test_response.py ..sss. [ 34%]
..   [ 37%]
test/test_retry.py . [ 45%]
test/test_util.py ..s... [ 56%]
 [ 71%]
F..F..s...s. [ 86%]
...  [ 96%]
test/test_wait.py .  [ 99%]
test/contrib/test_pyopenssl_dependencies.py ss   [100%]

=== FAILURES ===
_ 
TestUtil.test_parse_url[http://K\xf6nigsg\xe4\xdfchen.de/stra\xdfe-expected_url27]
 _

self = 
url = 'http://Königsgäßchen.de/straße'
expected_url = Url(scheme='http', auth=None, host='xn--knigsgchen-b4a3dun.de', 
port=None, path='/stra%C3%9Fe', query=None, fragment=None)

@pytest.mark.parametrize(
"url, expected_url",
chain(parse_url_host_map, non_round_tripping_parse_url_host_map),
)
def test_parse_url(self, url, expected_url):
>   returned_url = parse_url(url)

test/test_util.py:310: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
urllib3/util/url.py:401: in parse_url
return six.raise_from(LocationParseError(source_url), None)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

value = LocationParseError(u'Failed to parse: 
http://K\xf6nigsg\xe4\xdfchen.de/stra\xdfe',)
from_value = None

def raise_from(value, from_value):
>   raise value
E   LocationParseError: Failed to parse: 
http://K\xf6nigsg\xe4\xdfchen.de/stra\xdfe

/usr/lib/python2.7/dist-packages/six.py:737: LocationParseError
_ 
TestUtil.test_url_vulnerabilities[http://\u30d2:\u30ad@\u30d2.abc.\u30cb/\u30d2?\u30ad#\u30ef-expected_url5]
 _

self = 
url = 'http://ヒ:キ@ヒ.abc.ニ/ヒ?キ#ワ'
expected_url = Url(scheme=u'http', auth=u'%E3%83%92:%E3%82%AD', 
host=u'xn--pdk.abc.xn--idk', port=None, path=u'/%E3%83%92', query=u'%E3%82%AD', 
fragment=u'%E3%83%AF')

@pytest.mark.parametrize("url, expected_url", url_vulnerabilities)
def test_url_vulnerabilities(self, url, expected_url):
if expected_url is False:
with pytest.raises(LocationParseError):
parse_url(url)
else:
>   assert parse_url(url) == expected_url

test/test_util.py:436: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
urllib3/util/url.py:401: in parse_url
return six.raise_from(LocationParseError(source_url), None)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

value = LocationParseError(u'Failed to parse: 
http://\u30d2:\u30ad@\u30d2.abc.\u30cb/\u30d2?\u30ad#\u30ef',)
from_value = None

def raise_from(value, from_value):
>   raise value
E   LocationParseError: Failed to parse: 
http://\u30d2:\u30ad@\u30d2.abc.\u30cb/\u30d2?\u30ad#\u30ef

/usr/lib/python2.7/dist-packages/six.py:737: LocationParseError
 2 failed, 465 passed, 8 skipped, 1 deselected in 10.96 seconds 
E: pybuild 

Bug#943401: libreoffice: Autopkgtests are failing since 2019-10-21

[Matthias Klose]

On 25.10.19 18:09, Rene Engelhard wrote:

Hi,

On Fri, Oct 25, 2019 at 05:59:53PM +0200, Rene Engelhard wrote:

OK, thanks, reassigning to src:gcc-9 (libstdc++6 for now) then.


no. based on what rationale?


And to prevent said gcc-9 version from migrating, to not break something
else (no idea whether it does, but..).

The Release Team asked me exactly this: to reassign the bug to gcc-9.


base on what rationale?

> As can be seen on [1], the autopkgtests started failing this Monday and
> succeeded only once since then.

At this time, there was no new gcc-9 in the archive, -9 was on the archive on 
Oct 8, -10 and -11 are ftbfs, and -12 was uploaded on Oct 23, but you say that 
the tests started failing on Oct 21.  So why do you think this is related to gcc-9?

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[Andreas Beckmann]

Source: python-django
Version: 2:3.0~beta1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

python-django/experimental FTBFS:
https://buildd.debian.org/status/fetch.php?pkg=python-django=all=2%3A3.0%7Ebeta1-1=1571079369=0


==
FAIL: test_explicit_ForeignKey 
(nested_foreign_keys.tests.DeeplyNestedForeignKeysTests)
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 628, in run
testMethod()
  File "/<>/tests/nested_foreign_keys/tests.py", line 176, in 
test_explicit_ForeignKey

self.assertEqual(Package.objects.exclude(screening__movie__director=self.director).count(),
 1)
  File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
assertion_func(first, second, msg=msg)
  File "/usr/lib/python3.7/unittest/case.py", line 845, in _baseAssertEqual
raise self.failureException(msg)
AssertionError: 0 != 1

==
FAIL: test_inheritance (nested_foreign_keys.tests.DeeplyNestedForeignKeysTests)
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 628, in run
testMethod()
  File "/<>/tests/nested_foreign_keys/tests.py", line 153, in 
test_inheritance

self.assertEqual(Event.objects.exclude(screening__movie__director=self.director).count(),
 1)
  File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
assertion_func(first, second, msg=msg)
  File "/usr/lib/python3.7/unittest/case.py", line 845, in _baseAssertEqual
raise self.failureException(msg)
AssertionError: 0 != 1

==
FAIL: test_explicit_ForeignKey 
(nested_foreign_keys.tests.NestedForeignKeysTests)
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 628, in run
testMethod()
  File "/<>/tests/nested_foreign_keys/tests.py", line 100, in 
test_explicit_ForeignKey

self.assertEqual(Package.objects.exclude(screening__movie=self.movie).count(), 
1)
  File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
assertion_func(first, second, msg=msg)
  File "/usr/lib/python3.7/unittest/case.py", line 845, in _baseAssertEqual
raise self.failureException(msg)
AssertionError: 0 != 1

==
FAIL: test_explicit_ForeignKey_NullFK 
(nested_foreign_keys.tests.NestedForeignKeysTests)
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 628, in run
testMethod()
  File "/<>/tests/nested_foreign_keys/tests.py", line 121, in 
test_explicit_ForeignKey_NullFK

self.assertEqual(PackageNullFK.objects.exclude(screening__movie=self.movie).count(),
 2)
  File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
assertion_func(first, second, msg=msg)
  File "/usr/lib/python3.7/unittest/case.py", line 845, in _baseAssertEqual
raise self.failureException(msg)
AssertionError: 1 != 2

==
FAIL: test_inheritance (nested_foreign_keys.tests.NestedForeignKeysTests)
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 628, in run
testMethod()
  File "/<>/tests/nested_foreign_keys/tests.py", line 53, in 
test_inheritance

self.assertEqual(Event.objects.exclude(screening__movie=self.movie).count(), 1)
  File "/usr/lib/python3.7/unittest/case.py", line 852, in assertEqual
assertion_func(first, second, msg=msg)
  File "/usr/lib/python3.7/unittest/case.py", line 845, in _baseAssertEqual
raise self.failureException(msg)
AssertionError: 0 != 1

==
FAIL: test_inheritance_null_FK 
(nested_foreign_keys.tests.NestedForeignKeysTests)
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.7/unittest/case.py", line 628, in run
testMethod()
  File 

Bug#943508: RM: libgnatcoll-db -- ROM; dead upstream

[Nicolas Boulenguez]

Package: ftp.debian.org
Severity: normal

Hello.

The upstream GNATColl maintainers have stopped maintaining a database
component.  The current libgnatcoll-db depends on libgnatcoll17-dev
and would block the migration of Ada packages from experimental.

Please remove libgnatcoll from unstable.

Bug#943401: libreoffice: Autopkgtests are failing since 2019-10-21

[Rene Engelhard]

Hi,

On Fri, Oct 25, 2019 at 05:59:53PM +0200, Rene Engelhard wrote:
> > > OK, thanks, reassigning to src:gcc-9 (libstdc++6 for now) then.
> > 
> > no. based on what rationale?

And to prevent said gcc-9 version from migrating, to not break something
else (no idea whether it does, but..). 

The Release Team asked me exactly this: to reassign the bug to gcc-9.

Regards,

Rene

Bug#916594: Bug#919557: [Pkg-mozext-maintainers] Bug#919557: webext-umatrix: garbled display of toolbar menu in Firefox 64.0-1

[Antoine Beaupré]

On 2019-10-25 11:58:37, Antoine Beaupré wrote:
> On 2019-09-04 23:05:19, Paul Wise wrote:
>> On Fri, 22 Feb 2019 07:47:00 + Ximin Luo wrote:
>>
>>> For the time being you can work around the issue either by using
>>> firefox-esr instead of firefox (65) which is why I myself had not yet
>>> noticed this issue, it was working perfectly fine for me.
>>
>> Unfortunately Firefox ESR 68 has now reached Debian unstable.
>>
>>> If you cannot run firefox-esr and must run firefox 65, you can also
>>> work around the issue by running:
>>> 
>>> $ sudo rm /usr/share/webext/umatrix/lib/punycode.js
>>> $ sudo cp /usr/share/javascript/punycode/punycode.js 
>>> /usr/share/webext/umatrix/lib/punycode.js
>>
>> This workaround is no longer sufficient to fix the issue. I also tried
>> removing other symlinks and replacing them with the equivalent files
>> but this didn't help either.
>
> I also see this problem, on Debian 10 buster, after upgrading to FF 68.
>
> But what I found strange is that I did the upgrade on two different
> machines, and one survived: my laptop doesn't have problems with
> uMatrix, as far as I can tell.
>
> Note that this bug also triggers #916594 which means it's impossible to
> restore from backups.
>
> That said, the above "rm + cp" workaround *did* work here,
> strangely. Not sure what I have different from pabs...

... ah. but the bug described in #916594 *does* still happen now: the
display is correct, but the "My rules" dialog is blank:

https://paste.anarc.at/publish/2019-10-25-otplYB53oFI/screenshot.png

The nice thing is that while the "My rules" dialog looks blank, the
rules *are* actually still there, and it's possible to export the
configuration in the "About" dialog. Then I can get a working umatrix
extension again with the following procedure:

 1. go into the uMatrix preferences
 2. in the About dialog, backup to a file
 3. quit firefox
 4. apt purge webext-umatrix
 5. start firefox
 6. install umatrix from the addons.mozilla.org site
 7. go in the preferences, about dialog, restore

Now uMatrix works again, although without the Debian package. I couldn't
figure out how to have the "My rules" dialog work properly in the Debian
package.

A.

-- 
Thousands of candles can be lit from a single candle
And the life of the candle will not be shortened.
Happiness never decreases by being shared.
 - Buddha

Bug#943401: libreoffice: Autopkgtests are failing since 2019-10-21

[Rene Engelhard]

reassign 943401 libstdc++6
thanks

On Fri, Oct 25, 2019 at 05:53:54PM +0200, Matthias Klose wrote:
> Control: reassign -1 src:libreoffice
> 
> On 25.10.19 17:31, Rene Engelhard wrote:
> > reassign 943401 libstdc++6
> > found 943401 9.2.1-12
> > thanks
> > 
> > Hi,
> > 
> > On Fri, Oct 25, 2019 at 12:21:11PM +0200, Matthias Klose wrote:
> > > > I guess I need to disable make check to get round this.. (Unless someone
> > > > at GCC tells me what change libstdc++6(?) might have to cause this or
> > > > some other debugging help...)
> > > 
> > > gcc-9 9.2.1-9 (r276687) was uploaded on Oct 10, the next version built in
> > > the archive was 9.2.1-12 (r277294), built on Oct 23. Fyi, I see these 
> > > issues
> > > in Ubuntu focal as well.
> > 
> > OK, thanks, reassigning to src:gcc-9 (libstdc++6 for now) then.
> 
> no. based on what rationale?

Because libreoffice didn't change. gcc-9 did. And you yourself say
that it also affects Ubuntu which has an older libreoffice version.

If you say it's a libreoffice bug you should say why - until then i
assume it's some gcc-9 change.

Regards,

Rene

Bug#919557: [Pkg-mozext-maintainers] Bug#919557: webext-umatrix: garbled display of toolbar menu in Firefox 64.0-1

[Antoine Beaupré]

On 2019-09-04 23:05:19, Paul Wise wrote:
> On Fri, 22 Feb 2019 07:47:00 + Ximin Luo wrote:
>
>> For the time being you can work around the issue either by using
>> firefox-esr instead of firefox (65) which is why I myself had not yet
>> noticed this issue, it was working perfectly fine for me.
>
> Unfortunately Firefox ESR 68 has now reached Debian unstable.
>
>> If you cannot run firefox-esr and must run firefox 65, you can also
>> work around the issue by running:
>> 
>> $ sudo rm /usr/share/webext/umatrix/lib/punycode.js
>> $ sudo cp /usr/share/javascript/punycode/punycode.js 
>> /usr/share/webext/umatrix/lib/punycode.js
>
> This workaround is no longer sufficient to fix the issue. I also tried
> removing other symlinks and replacing them with the equivalent files
> but this didn't help either.

I also see this problem, on Debian 10 buster, after upgrading to FF 68.

But what I found strange is that I did the upgrade on two different
machines, and one survived: my laptop doesn't have problems with
uMatrix, as far as I can tell.

Note that this bug also triggers #916594 which means it's impossible to
restore from backups.

That said, the above "rm + cp" workaround *did* work here,
strangely. Not sure what I have different from pabs...

a.

-- 
Religion is like a blind man looking in a black room for a black cat
that isn't there, and finding it.
 - Oscar Wilde