date:20200918

On 2020-09-18 21:51 +0200, Sven Joachim wrote:

> It seems that cowdancer should not link with ncurses in the first place,
> as it only uses the tinfo library.  In fact, rebuilding cowbuilder with
> a current toolchain that defaults to the "--as-needed" linker flag
> causes cowbuilder and cowdancer to depend on libtinfo6 only.

Since cowdancer does not actually use any curses functions and makes do
with the terminfo library, it seems logical to link with it.  I have
created a merge request on Salsa:

https://salsa.debian.org/pbuilder-team/cowdancer/-/merge_requests/4

Cheers,
   Sven

Bug#914813: Some additional informations

2020-09-18 Thread Bernhard

Hello Vagrant
Hello Geert

I had a further look, what possibly happened.

If you have a look at the older bug report #879987 from Stefan Berzl:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879987

>>snip<<
> [1.631520] can: netlink gateway (rev 20170425) max_hops=1
> [1.631794] Key type dns_resolver registered
> [1.631923] Registering SWP/SWPB emulation handler
> [1.640174] sunxi-rsb 1f03400.rsb: RSB running at 300 Hz
> [1.640897] axp20x-rsb sunxi-rsb-3a3: AXP20x variant AXP813 found
> [1.644526] input: axp20x-pek as 
> /devices/platform/soc/1f03400.rsb/sunxi-rsb-3a3/axp221-pek/input/input0
> [1.644911] axp20x-rsb sunxi-rsb-3a3: AXP20X driver loaded
> [1.647179] ac100-rtc ac100-rtc: rtc core: registered rtc-ac100 as rtc0
> [1.647756] ac100-rtc ac100-rtc: RTC enabled
> [1.648353] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb1_vbus... 
> Deferring probe
>>snip<<

At timestamp 1.640174, there is the sunxi-rsb detected.
Immediately after that, there is the AXP813 initialized.

Now, i had a look about the RSB.
This is the Allwinner sunxi reduced serial bus driver:
> https://cateee.net/lkddb/web-lkddb/SUNXI_RSB.html

Here, you see, this bus is for communicating with the PMIC AXP8XX.

If you have a look at my last log from the Banana Pi M3:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=914813;filename=uboot-2020.07%2Bdfsg-1.log;msg=110

>>snip<<
> [3.921308] Key type fscrypt-provisioning registered
> [3.921751] AppArmor: AppArmor sha1 policy hashing enabled
> [3.941274] sun8i-a83t-r-pinctrl 1f02c00.pinctrl: supply vcc-pl not found, 
> using dummy regulator
> [3.942050] sunxi-rsb 1f03400.rsb: RSB running at 300 Hz
> [3.944712] ac100-rtc ac100-rtc: DMA mask not set
> [3.948747] ac100-rtc ac100-rtc: registered as rtc0
> [3.949185] ac100-rtc ac100-rtc: setting system clock to 
> 1970-01-01T01:00:15 UTC (3615)
>>snip<<

Here, the RSB is detected.
But there is no AXP initialization.

Now, my question:
Is it possible, that the RSB kernel module is missing (drivers/bus/)?
Or, is it possible, that the AXP kernel module is missing?

Hopefully, these informations help for further analysis.

Best regards and thank you for the great support.

Bernhard



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

Bug#925561: xfce4-weather-plugin patch

2020-09-18 Thread Pavel R.


Hello

I have made a patch to fix weather updates in current version in 
xfce4-weather-plugin


--- xfce4-weather-plugin-0.8.10.orig/panel-plugin/weather.c
+++ xfce4-weather-plugin-0.8.10/panel-plugin/weather.c
@@ -619,17 +619,14 @@ update_handler(plugin_data *data)
 end_tm = *localtime(_t);
 
 /* build url */
-url = g_strdup_printf("https://api.met.no/weatherapi/sunrise/1.1/?;
+url = g_strdup_printf("https://api.met.no/weatherapi/sunrise/2.0/?;
   "lat=%s;lon=%s;"
-  "from=%04d-%02d-%02d;"
-  "to=%04d-%02d-%02d",
+  "date=%04d-%02d-%02d;"
+  "offset=00:00",
   data->lat, data->lon,
   now_tm.tm_year + 1900,
-  now_tm.tm_mon + 1,
-  now_tm.tm_mday,
-  end_tm.tm_year + 1900,
-  end_tm.tm_mon + 1,
-  end_tm.tm_mday);
+  now_tm.tm_mon + 1, 
+  now_tm.tm_mday);
 
 /* start receive thread */
 g_message(_("getting %s"), url);
@@ -647,8 +644,8 @@ update_handler(plugin_data *data)
 /* build url */
 url =
 g_strdup_printf("https://api.met.no/weatherapi;
-"/locationforecastlts/1.3/?lat=%s;lon=%s;msl=%d",
-data->lat, data->lon, data->msl);
+"/locationforecast/2.0/classic?lat=%s;lon=%s",
+data->lat, data->lon);
 
 /* start receive thread */
 g_message(_("getting %s"), url);

Bug#969291: RFS: sane-backends/1.0.31-1~experimental1 [RC] -- API library for scanners [transitional package]

2020-09-18 Thread Raphael Hertzog

Hi,

On Sat, 05 Sep 2020, Jörg Frings-Fürst wrote:
> > First of all, why is this packaging git repository not hosted on
> > salsa.debian.org? I can create you a repository in the "debian"
> > namespace and grant you commit rights on this repository. It
> > would make it easier for random DD to help you out.
> 
> Why is simply explained. For the packages in the salsa section debian DDs have
> the right to make changes even against the intention of the maintainers and 
> then
> upload them without following the NMU rules. This is not my idea of teamwork.

This is seldom a problem. And you should trust your peers, not fear their
help.

Having it hosted outside of salsa.debian.org creates needless barriers, in
particular when you are not a DD. When I sponsor, I prefer to sponsor out
of salsa so that I can fix the issues that I find and so that I can tag,
etc.

> The change from libsane to libsane1 requires IMHO a transition. Therefore only
> in experimental. 

It no longer requires a transition since we have a transitional package.
That said you should still ask for a binnmu of the reverse dependencies to
get updated dependencies. But they don't have to migrate together with
sane-backends.

> Normally I forward almost all patches. After lintian complained about the
> missing entry forwarded as a warning, I added not-needed for old patches. 
> After
> moving sane to GitLab I don't have direct access to the old bug reports
> anymore. 

I don't understand what you are trying to explain. Surely you can open
merge request against sane-backends if you have something to submit?

> > Looking at your history on this package, have you considered asking
> > for the Debian Maintainer status so that you can upload that package
> > on your own?
> 
> I am missing the second signing of my key by a DD. I live here near the oldest
> city in Germany, but for Debian far away from everything. 

If you have seen the recent messages, you will see that those signatures
are no longer mandatory. If you have worked with a regular sponsor over a
long period of time, then you can likely go through the process easily.

https://lists.debian.org/debian-devel-announce/2020/09/msg0.html

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#970570: llvm-toolchain-11: autopkgtest failure: Should find 3 warnings

2020-09-18 Thread Paul Gevers

Source: llvm-toolchain-11
Version: 1:11.0.0~+rc2-5
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added a new package with an autopkgtest, great. However,
the autopkgest fails. Currently this failure is blocking the migration
to testing [1]. Can you please investigate the situation and fix it?

I copied some of the output at the bottom of this report.

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

Paul

[1] https://qa.debian.org/excuses.php?package=llvm-toolchain-11

https://ci.debian.net/data/autopkgtest/testing/amd64/l/llvm-toolchain-11/6878994/log.gz

clang-$VERSION -cc1  -analyze -analyzer-constraints=range
-analyzer-checker=core,debug.ExprInspection foo.c &> foo.log
if ! grep -q "3 warnings generated." foo.log; then
echo "Should find 3 warnings"
exit 1
fi
Should find 3 warnings



signature.asc
Description: OpenPGP digital signature

Bug#970555: ncurses: Upgrade fails: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/x86_64-linux-gnu/libncurses.so.6)

2020-09-18 Thread Jessica Clarke

On 18 Sep 2020, at 20:51, Sven Joachim  wrote:
> 
> Control: reassign -1 cowdancer 0.88
> Control: retitle -1 cowdancer: needlessly links with ncurses
> Control: severity -1 important
> 
> On 2020-09-18 18:22 +0200, Sebastiaan Couwenberg wrote:
> 
>> Control: tags -1 - moreinfo
>> 
>> On 9/18/20 6:13 PM, Sven Joachim wrote:
>>> On 2020-09-18 16:55 +0200, Bas Couwenberg wrote:
 Upgrading sid & experimental pbuilder chroots fails due to the new ncurses:
 
 Preparing to unpack .../libncursesw6_6.2+20200912-1_amd64.deb ...
 Unpacking libncursesw6:amd64 (6.2+20200912-1) over (6.2-1) ...
 Preparing to unpack .../libncurses6_6.2+20200912-1_amd64.deb ...
 Unpacking libncurses6:amd64 (6.2+20200912-1) over (6.2-1) ...
 rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
 `NCURSES6_TINFO_6.2.current' not found (required by 
 /lib/x86_64-linux-gnu/libncurses.so.6)
 dpkg: error while cleaning up:
  rm command for cleanup subprocess returned error exit status 1
 dpkg-split: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
 `NCURSES6_TINFO_6.2.current' not found (required by 
 /lib/x86_64-linux-gnu/libncurses.so.6)
 rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
 `NCURSES6_TINFO_6.2.current' not found (required by 
 /lib/x86_64-linux-gnu/libncurses.so.6)
 dpkg: error processing archive 
 /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb (--unpack):
  rm command for cleanup subprocess returned error exit status 1
 Errors were encountered while processing:
  /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)
>>> 
>>> I cannot reproduce this, but my pbuilder chroots do not have libncurses6
>>> installed at all.
>> 
>> What about cowbuilder chroots?
> 
> Thanks for the hint, I do not use cowbuilder but had a look at the
> manpage where I found this option:
> 
> ,
> |  --no-cowdancer-update
> | Do  not use cowdancer on cowbuilder update. Please use this
> | option when cowdancer is interfering with upgrade  process,
> | or cowdancer itself is being upgraded within chroot.
> `
> 
> Apparently this is what you need to use, for cowdancer seems to bring
> libncurses.so.6 into the address space of every binary on the system,
> which is "interfering with upgrade process".
> 
>>> What is this rm binary in your chroot, apparently it
>>> is linked to libncurses.so.6?
>> 
>> # which rm
>> /bin/rm
>> # dpkg -S /bin/rm
>> coreutils: /bin/rm
>> # ldd /bin/rm
>> linux-vdso.so.1 (0x7ffea75fb000)
>> /usr/lib/cowdancer/libcowdancer.so (0x7f2e6a6db000)
>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f2e6a512000)
>> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2e6a50c000)
>> libncurses.so.6 => /lib/x86_64-linux-gnu/libncurses.so.6
>> (0x7f2e6a4e3000)
>> libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6
>> (0x7f2e6a4b4000)
>> /lib64/ld-linux-x86-64.so.2 (0x7f2e6a6f9000)
>> # aptitude why libncurses6
>> i   cowdancer Depends libncurses6 (>= 6)
> 
> It seems that cowdancer should not link with ncurses in the first place,
> as it only uses the tinfo library.  In fact, rebuilding cowbuilder with
> a current toolchain that defaults to the "--as-needed" linker flag
> causes cowbuilder and cowdancer to depend on libtinfo6 only.

Hm, that only defers the problem until libtinfo6 is similarly broken
mid-upgrade, no? It seems to me like dpkg has done a very dodgy
sequence of events that have resulted in the system being broken for a
short period and, whilst most don't notice, cowdancer does. Why is this
not a dpkg (or apt) bug? It should be possible to do that sequence in a
way that preserves the system as working, no?

But yes, there is the separate _minor_ issue that cowdancer is linking
against more than it needs to. I don't know why I made it pull in all
of ncurses, maybe an earlier version of the patch needed it and it no
longer does, but it's been too long to have any hope of remembering
what past me was thinking.

Jess

Bug#970569: buster-pu: package pyzmq/17.1.2-2+deb10u1

2020-09-18 Thread Salvatore Bonaccorso

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: car...@debian.org,bl...@debian.org,g...@debian.org

Hi SRM,

[ Reason ]
After the zeromq3 update to address CVE-2020-15166 Laszlo noticed that
the TestAsyncioAuthentication::test_blacklist was hanging. Luca
investigated the issue further an noticed that pyzmq was actually
relying in the test on the broken behaviour of zeromq3 which got
fixed.

[ Impact ]
When there would be need of an update of pyzmq in buster the test
suite would fail with the updated zeromq3 package.

[ Tests ]
Did run the full package build and so in particular the test suite
with the fixed zeromq3 and the patched pyzmq.

[ Risks ]
The updates involves only fixing the broken test, so I would consider
the risk minimal.

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

[ Changes ]
Test is fixed and not relying anymore on the broken behaviour of
zeromq3.

Regards,
Salvatore
diff -Nru pyzmq-17.1.2/debian/changelog pyzmq-17.1.2/debian/changelog
--- pyzmq-17.1.2/debian/changelog   2019-01-19 22:26:02.0 +0100
+++ pyzmq-17.1.2/debian/changelog   2020-09-18 21:43:25.0 +0200
@@ -1,3 +1,10 @@
+pyzmq (17.1.2-2+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * asyncio: wait for POLLOUT on sender in can_connect (Closes: #970567)
+
+ -- Salvatore Bonaccorso   Fri, 18 Sep 2020 21:43:25 +0200
+
 pyzmq (17.1.2-2) unstable; urgency=medium
 
   [ Luca Boccassi ]
diff -Nru 
pyzmq-17.1.2/debian/patches/asyncio-wait-for-POLLOUT-on-sender-in-can_connect.patch
 
pyzmq-17.1.2/debian/patches/asyncio-wait-for-POLLOUT-on-sender-in-can_connect.patch
--- 
pyzmq-17.1.2/debian/patches/asyncio-wait-for-POLLOUT-on-sender-in-can_connect.patch
 1970-01-01 01:00:00.0 +0100
+++ 
pyzmq-17.1.2/debian/patches/asyncio-wait-for-POLLOUT-on-sender-in-can_connect.patch
 2020-09-18 21:43:25.0 +0200
@@ -0,0 +1,24 @@
+From: Min RK 
+Date: Wed, 9 Sep 2020 10:16:36 +0200
+Subject: asyncio: wait for POLLOUT on sender in can_connect
+Origin: 
https://github.com/zeromq/pyzmq/commit/afd72820946f544790c6f70d90ba50eb29f1c6e1
+Bug: https://github.com/zeromq/pyzmq/issues/1418
+Bug-Debian: https://bugs.debian.org/970567
+
+matches login in thread, because POLLOUT will only be set if connection is 
allowed
+---
+ zmq/tests/asyncio/_test_asyncio.py | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/zmq/tests/asyncio/_test_asyncio.py
 b/zmq/tests/asyncio/_test_asyncio.py
+@@ -384,7 +384,8 @@ class TestAsyncioAuthentication(TestThre
+ port = server.bind_to_random_port(iface)
+ client.connect("%s:%i" % (iface, port))
+ msg = [b"Hello World"]
+-yield from server.send_multipart(msg)
++if (yield from server.poll(1000, zmq.POLLOUT)):
++yield from server.send_multipart(msg)
+ if (yield from client.poll(1000)):
+ rcvd_msg = yield from client.recv_multipart()
+ self.assertEqual(rcvd_msg, msg)
diff -Nru pyzmq-17.1.2/debian/patches/series pyzmq-17.1.2/debian/patches/series
--- pyzmq-17.1.2/debian/patches/series  2019-01-19 21:47:22.0 +0100
+++ pyzmq-17.1.2/debian/patches/series  2020-09-18 21:43:25.0 +0200
@@ -2,3 +2,4 @@
 cffi-fix.patch
 skip_large_send
 fix_monitor_test.patch
+asyncio-wait-for-POLLOUT-on-sender-in-can_connect.patch

Bug#970568: mdadm: [INTL:it] Italian debconf templates translation

2020-09-18 Thread Luca Monducci

Package: mdadm
Severity: wishlist
Tags: patch l10n

Please add the italian debconf templates translation (attached).

Thanks,
Luca

# Italian (it) translation of debconf templates for mdadm
# Copyright (C) 2008 Software in the Public Interest
# This file is distributed under the same license as the mdadm package.
# Luca Monducci , 2008-2020.
#
msgid ""
msgstr ""
"Project-Id-Version: mdadm italian debconf\n"
"Report-Msgid-Bugs-To: md...@packages.debian.org\n"
"POT-Creation-Date: 2019-02-09 08:48+0100\n"
"PO-Revision-Date: 2020-09-16 20:02+0200\n"
"Last-Translator: Luca Monducci \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../mdadm.templates:2001
msgid "Should mdadm run monthly redundancy checks of the MD arrays?"
msgstr "Far eseguire a mdadm i controlli mensili di ridondanza sugli array MD?"

#. Type: boolean
#. Description
#: ../mdadm.templates:2001
msgid ""
"If the kernel supports it (versions greater than 2.6.14), mdadm can "
"periodically check the redundancy of MD arrays (RAIDs). This may be a "
"resource-intensive process, depending on the local setup, but it could help "
"prevent rare cases of data loss. Note that this is a read-only check unless "
"errors are found; if errors are found, mdadm will try to correct them, which "
"may result in write access to the media."
msgstr ""
"Se il kernel lo supporta (tutte le versioni successive la 2.6.14), mdadm può "
"effettuare delle verifiche periodiche sulla ridondanza degli array MD "
"(RAID). Questo è un processo che potrebbe richiedere molte risorse, in base "
"alle impostazioni locali, ma può prevenire i rari casi di perdita di dati. "
"Notare che questa verifica è di sola-lettura tranne quando riscontra degli "
"errori; quando ci sono errori, mdadm prova a correggerli e potrebbe accedere "
"in scrittura al supporto."

#. Type: boolean
#. Description
#: ../mdadm.templates:2001
msgid ""
"The default, if turned on, is to check on the first Sunday of every month at "
"01:06."
msgstr ""
"Se attivo, la configurazione predefinita prevede che il controllo sia "
"eseguito la prima domenica di ogni mese alle 01.06."

#. Type: boolean
#. Description
#: ../mdadm.templates:3001
msgid "Should mdadm check once a day for degraded arrays?"
msgstr "Far eseguire a mdadm il controllo quotidiano di degrado degli array?"

#. Type: boolean
#. Description
#: ../mdadm.templates:3001
msgid ""
"mdadm can check once a day for degraded arrays and missing spares to ensure "
"that such events don't go unnoticed."
msgstr ""
"mdadm può controllare una volta al giorno il degrado degli array e "
"l'assenza dei dischi di scorta in modo che questi eventi non passino "
"inosservati."

#. Type: boolean
#. Description
#: ../mdadm.templates:4001
msgid "Do you want to start the MD monitoring daemon?"
msgstr "Avviare il demone di monitoraggio MD?"

#. Type: boolean
#. Description
#: ../mdadm.templates:4001
msgid ""
"The MD (RAID) monitor daemon sends email notifications in response to "
"important MD events (such as a disk failure)."
msgstr ""
"Il demone di monitoraggio MD (RAID) invia delle notifiche via email quando "
"si verificano eventi importanti (come la rottura di un disco)."

#. Type: boolean
#. Description
#: ../mdadm.templates:4001
msgid "Enabling this option is recommended."
msgstr "Si raccomanda l'attivazione di questa funzione."

#. Type: string
#. Description
#: ../mdadm.templates:5001
msgid "Recipient for email notifications:"
msgstr "Destinatario delle email di notifica:"

#. Type: string
#. Description
#: ../mdadm.templates:5001
msgid ""
"Please enter the email address of the user who should get the email "
"notifications for important MD events."
msgstr ""
"Inserire l'indirizzo email dell'utente che deve ricevere le notifiche di "
"eventi importanti legati al MD."

#~ msgid "MD arrays needed for the root file system:"
#~ msgstr "Array MD necessari per il file system di root:"

#~ msgid ""
#~ "Please enter 'all', 'none', or a space-separated list of devices such as "
#~ "'md0 md1' or 'md/1 md/d0' (the leading '/dev/' can be omitted)."
#~ msgstr ""
#~ "Inserire \"all\", \"none\" oppure un elenco dei device separati da uno "
#~ "spazio, per esempio \"md0 md1\" o \"md/1 md/d0\" (il \"/dev/\" iniziale "
#~ "può essere omesso)."

#~ msgid "for internal use - only the long description is needed."
#~ msgstr "uso interno - è necessaria solo la descrizione lunga."

#~ msgid ""
#~ "If the system's root file system is located on an MD array (RAID), it "
#~ "needs to be started early during the boot sequence. If it is located on a "
#~ "logical volume (LVM), which is on MD, all constituent arrays need to be "
#~ "started."
#~ msgstr ""
#~ "Se il file system di root è su un array MD (RAID), è necessario attivare "
#~ "tale array all'inizio della sequenza d'avvio. Se è su un volume logico "
#~ "(LVM), il quale è su un MD, è necessario attivare tutti

Bug#970555: ncurses: Upgrade fails: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/x86_64-linux-gnu/libncurses.so.6)

Control: reassign -1 cowdancer 0.88
Control: retitle -1 cowdancer: needlessly links with ncurses
Control: severity -1 important

On 2020-09-18 18:22 +0200, Sebastiaan Couwenberg wrote:

> Control: tags -1 - moreinfo
>
> On 9/18/20 6:13 PM, Sven Joachim wrote:
>> On 2020-09-18 16:55 +0200, Bas Couwenberg wrote:
>>> Upgrading sid & experimental pbuilder chroots fails due to the new ncurses:
>>>
>>>  Preparing to unpack .../libncursesw6_6.2+20200912-1_amd64.deb ...
>>>  Unpacking libncursesw6:amd64 (6.2+20200912-1) over (6.2-1) ...
>>>  Preparing to unpack .../libncurses6_6.2+20200912-1_amd64.deb ...
>>>  Unpacking libncurses6:amd64 (6.2+20200912-1) over (6.2-1) ...
>>>  rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
>>> `NCURSES6_TINFO_6.2.current' not found (required by 
>>> /lib/x86_64-linux-gnu/libncurses.so.6)
>>>  dpkg: error while cleaning up:
>>>   rm command for cleanup subprocess returned error exit status 1
>>>  dpkg-split: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
>>> `NCURSES6_TINFO_6.2.current' not found (required by 
>>> /lib/x86_64-linux-gnu/libncurses.so.6)
>>>  rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
>>> `NCURSES6_TINFO_6.2.current' not found (required by 
>>> /lib/x86_64-linux-gnu/libncurses.so.6)
>>>  dpkg: error processing archive 
>>> /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb (--unpack):
>>>   rm command for cleanup subprocess returned error exit status 1
>>>  Errors were encountered while processing:
>>>   /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb
>>>  E: Sub-process /usr/bin/dpkg returned an error code (1)
>>
>> I cannot reproduce this, but my pbuilder chroots do not have libncurses6
>> installed at all.
>
> What about cowbuilder chroots?

Thanks for the hint, I do not use cowbuilder but had a look at the
manpage where I found this option:

,
|  --no-cowdancer-update
| Do  not use cowdancer on cowbuilder update. Please use this
| option when cowdancer is interfering with upgrade  process,
| or cowdancer itself is being upgraded within chroot.
`

Apparently this is what you need to use, for cowdancer seems to bring
libncurses.so.6 into the address space of every binary on the system,
which is "interfering with upgrade process".

>> What is this rm binary in your chroot, apparently it
>> is linked to libncurses.so.6?
>
>  # which rm
>  /bin/rm
>  # dpkg -S /bin/rm
>  coreutils: /bin/rm
>  # ldd /bin/rm
>  linux-vdso.so.1 (0x7ffea75fb000)
>  /usr/lib/cowdancer/libcowdancer.so (0x7f2e6a6db000)
>  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f2e6a512000)
>  libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2e6a50c000)
>  libncurses.so.6 => /lib/x86_64-linux-gnu/libncurses.so.6
> (0x7f2e6a4e3000)
>  libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6
> (0x7f2e6a4b4000)
>  /lib64/ld-linux-x86-64.so.2 (0x7f2e6a6f9000)
>  # aptitude why libncurses6
>  i   cowdancer Depends libncurses6 (>= 6)

It seems that cowdancer should not link with ncurses in the first place,
as it only uses the tinfo library.  In fact, rebuilding cowbuilder with
a current toolchain that defaults to the "--as-needed" linker flag
causes cowbuilder and cowdancer to depend on libtinfo6 only.

Cheers,
   Sven

Bug#957265: [PATCH] Re: Bug#957265: geekcode: ftbfs with GCC-10

2020-09-18 Thread Axel Beckert

Control: tag -1 + pending patch

Hi Eric,

Matthias Klose wrote:
> The package fails to build in a test rebuild on at least amd64 with
> gcc-10/g++-10, but succeeds to build with gcc-9/g++-9.

I've submitted a merge request for this bug report at
https://salsa.debian.org/eric/geekcode/-/merge_requests/2/diffs based
on the current state of your git repository (and not the current state
of the package in Debian Unstable).

I'm also thinking about NMU'ing this issue given how long this has
been open. But since you merged another MR about two months ago or so,
I assume and hope that providing a bite-sized patch will speed up
things. :-)

Didn't fix more lintian issues. though, as this MR is intended to work
as NMU, too.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#970563: buster-pu: package libx11/2:1.6.7-1+deb10u1

2020-09-18 Thread Adam D. Barratt

Control: tags -1 + confirmed d-i

On Fri, 2020-09-18 at 20:04 +0200, Moritz Muehlenhoff wrote:
> This updates fixes a few security issues in libx11, which don't
> warrant a DSA. Debdiff attached.

That looks OK to me, but will need a KiBi-ack as a it builds a udeb.

Regards

Adam

Bug#970567: pyzmq: TestAsyncioAuthentication::test_blacklist hanging after CVE-2020-15166 bugfix for zeromq3

2020-09-18 Thread Salvatore Bonaccorso

Source: pyzmq
Version: 17.1.2-2
Severity: serious
Tags: upstream,patch,fixed-upstream
Justification: FTBFS
Forwarded: https://github.com/zeromq/pyzmq/issues/1418
X-Debbugs-Cc: 
car...@debian.org,t...@security.debian.org,bl...@debian.org,g...@debian.org
Control: fixed -1 19.0.2-2
Control: affects -1 + release.debian.org,security.debian.org

Hi

After the CVE-2020-15166 fix in zeromq3 the upstream test
TestAsyncioAuthentication::test_blacklist will hang, cf [1].

This was already fixed in unstable. For stable this would cause an
issue when pyzmq would need to be rebuild. It though does not warrant
a regression update via security because. The test was actually
relying on the broken behaviour afaiu.

 [1] https://github.com/zeromq/pyzmq/issues/1418
 [2] 
https://github.com/zeromq/pyzmq/commit/afd72820946f544790c6f70d90ba50eb29f1c6e1

Regards,
Salvatore

Bug#970566: src:sleef: autopkgtest on non-amd64: please exit 77 and use restriction skippable

2020-09-18 Thread Paul Gevers

Source: sleef
Version: 3.5.0-1
Severity: important

Dear maintainers,

Your package has an autopkgtest, great. However, it doesn't test the
installed binaries in any way on non-amd64 architectures. While bug
#970513 against the autopkgtest package is still unfixed, please mark
the test as skippable and exit with code 77 instead of 0 in the current
test, so that the test is treated properly by the migration software.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#970565: python-duckpy: autopkgtest failure: No module named 'bs4'

2020-09-18 Thread Paul Gevers

Source: python-duckpy
Version: 2.1.1-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package python-duckpy, great.
However, it fails. Currently this failure is blocking the migration to
testing [1]. Can you please investigate the situation and fix it?

Paul

[1] https://qa.debian.org/excuses.php?package=python-duckpy

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-duckpy/6300451/log.gz



signature.asc
Description: OpenPGP digital signature

Bug#968324: Provide /usr/bin/python

2020-09-18 Thread Matthias Klose

On 9/17/20 3:43 PM, Norbert Preining wrote:
> Package: python3-minimal
> Version: 3.8.2-3
> Followup-For: Bug #968324
> X-Debbugs-Cc: norb...@preining.info
> 
> Hi,
> 
> I am interested in bringing this up again. I have read through the
> relevant threads on debian-python, and I consider this a gross
> mis-decision to not ship /usr/bin/python. The reasons are the wide
> variety of third party scripts that rely on an interpreter.
> Most of third party scripts are already using Python3, so pointing
> /usr/bin/python -> python3 is the correct way forward. Not providing
> /usr/bin/python superficially breaks lots of scripts.
> 
> The counter-argument is that some scripts might be written for Python 2
> - well, let only **those** break instead of all. 

sorry to say, but apparently you missed the
  https://lists.debian.org/debian-python/2020/07/msg00042.html
thread.

"""
the what-is-python package is now in NEW.  Yes, the policy needs an update.
I'll put that on my TODO list.  If there is too much disagreement about the
python-is-python3 package, then I plan to run it via the CTTE, and ask for an
advice how to move on.
"""

Matthias

Bug#970564: buster-pu: package milkytracker/1.02.00+dfsg-1+deb10u1

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jcowg...@debian.org

Attached debdiff fixes a few security issues in milkytracker
which don't warrant a DSA. I've verified all reproducers
and the (identical) patches have been in unstable for quite a
bit.

Cheers,
Moritz
diff -Nru milkytracker-1.02.00+dfsg/debian/changelog 
milkytracker-1.02.00+dfsg/debian/changelog
--- milkytracker-1.02.00+dfsg/debian/changelog  2018-02-25 11:15:54.0 
+0100
+++ milkytracker-1.02.00+dfsg/debian/changelog  2020-09-18 15:32:18.0 
+0200
@@ -1,3 +1,10 @@
+milkytracker (1.02.00+dfsg-1+deb10u1) buster; urgency=medium
+
+  * CVE-2020-15569 (Closes: #964797)
+  * CVE-2019-14464, CVE-2019-14496, CVE-2019-14497 (Closes: #933964)
+
+ -- Moritz Mühlenhoff   Fri, 18 Sep 2020 20:30:05 +0200
+
 milkytracker (1.02.00+dfsg-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru 
milkytracker-1.02.00+dfsg/debian/patches/0001-Fix-use-after-free-in-PlayerGeneric-destructor.patch
 
milkytracker-1.02.00+dfsg/debian/patches/0001-Fix-use-after-free-in-PlayerGeneric-destructor.patch
--- 
milkytracker-1.02.00+dfsg/debian/patches/0001-Fix-use-after-free-in-PlayerGeneric-destructor.patch
  1970-01-01 01:00:00.0 +0100
+++ 
milkytracker-1.02.00+dfsg/debian/patches/0001-Fix-use-after-free-in-PlayerGeneric-destructor.patch
  2020-09-18 15:30:01.0 +0200
@@ -0,0 +1,36 @@
+From d6f07ee05fe114ed843aad5f1a2492a73c2b9183 Mon Sep 17 00:00:00 2001
+From: Jeremy Clarke 
+Date: Mon, 13 Apr 2020 23:53:51 +0100
+Subject: Fix use-after-free in PlayerGeneric destructor
+
+---
+ src/milkyplay/PlayerGeneric.cpp | 7 ---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/src/milkyplay/PlayerGeneric.cpp b/src/milkyplay/PlayerGeneric.cpp
+index 8df2c13..59f7cba 100644
+--- a/src/milkyplay/PlayerGeneric.cpp
 b/src/milkyplay/PlayerGeneric.cpp
+@@ -202,15 +202,16 @@ PlayerGeneric::PlayerGeneric(mp_sint32 frequency, 
AudioDriverInterface* audioDri
+   
+ PlayerGeneric::~PlayerGeneric()
+ {
+-  if (mixer)
+-  delete mixer;
+ 
+   if (player)
+   {
+-  if (mixer->isActive() && !mixer->isDeviceRemoved(player))
++  if (mixer && mixer->isActive() && 
!mixer->isDeviceRemoved(player))
+   mixer->removeDevice(player);
+   delete player;
+   }
++  
++  if (mixer)
++  delete mixer;
+ 
+   delete[] audioDriverName;
+   
+-- 
+2.20.1
+
diff -Nru milkytracker-1.02.00+dfsg/debian/patches/CVE-2019-144{64,96,97}.patch 
milkytracker-1.02.00+dfsg/debian/patches/CVE-2019-144{64,96,97}.patch
--- milkytracker-1.02.00+dfsg/debian/patches/CVE-2019-144{64,96,97}.patch   
1970-01-01 01:00:00.0 +0100
+++ milkytracker-1.02.00+dfsg/debian/patches/CVE-2019-144{64,96,97}.patch   
2020-09-18 15:30:01.0 +0200
@@ -0,0 +1,118 @@
+Description: This patch fixes the stack-based buffer overflow
+ and a heap-based buffer overflow.
+Author: Christopher O'Neill 
+Author: Utkarsh Gupta 
+Bug-Debian: https://bugs.debian.org/933964
+Origin: 
https://github.com/milkytracker/MilkyTracker/commit/ea7772a3fae0a9dd0a322e8fec441d15843703b7
+Origin: 
https://github.com/milkytracker/MilkyTracker/commit/fd607a3439fcdd0992e5efded3c16fc79c804e34
+Bug: https://github.com/milkytracker/MilkyTracker/issues/182
+Bug: https://github.com/milkytracker/MilkyTracker/issues/183
+Bug: https://github.com/milkytracker/MilkyTracker/issues/184
+Last-Update: 2019-10-28
+
+--- a/src/milkyplay/LoaderS3M.cpp
 b/src/milkyplay/LoaderS3M.cpp
+@@ -340,7 +340,11 @@
+   return MP_OUT_OF_MEMORY;
+   
+   header->insnum = f.readWord(); // number of instruments
+-  header->patnum = f.readWord(); // number of patterns
++if (header->insnum > MP_MAXINS)
++return MP_LOADER_FAILED;
++header->patnum = f.readWord(); // number of patterns
++if (header->patnum > 256)
++return MP_LOADER_FAILED;
+   
+   mp_sint32 flags = f.readWord(); // st3 flags
+ 
+--- a/src/milkyplay/LoaderXM.cpp
 b/src/milkyplay/LoaderXM.cpp
+@@ -63,8 +63,8 @@
+ mp_sint32 LoaderXM::load(XMFileBase& f, XModule* module)
+ {
+   mp_ubyte insData[230];  
+-  mp_sint32 smpReloc[96];
+-  mp_ubyte nbu[96];
++  mp_sint32 smpReloc[MP_MAXINSSAMPS];
++  mp_ubyte nbu[MP_MAXINSSAMPS];
+   mp_uint32 fileSize = 0;
+   
+   module->cleanUp();
+@@ -117,6 +117,8 @@
+   memcpy(header->ord, hdrBuff+16, 256);
+   if(header->ordnum > MP_MAXORDERS)
+   header->ordnum = MP_MAXORDERS;
++if(header->insnum > MP_MAXINS)
++return MP_LOADER_FAILED;
+ 
+   delete[] hdrBuff;
+   
+@@ -143,7 +145,7 @@
+   f.read([y].type,1,1);
+   mp_uword numSamples = 0;
+   f.readWords(,1);
+-  if(numSamples >

Bug#954289: openvpn: Incomplete handling of interrupted credentials prompt with auth-user-pass

2020-09-18 Thread Tomáš Szaniszlo

Dear Bernhard,

thanks for the info. Just to let you know, I tried this with a recent
upgrade of openvpn to 2.5~beta3-1 (if that's the update you mentioned), but
the issue still seems to persist.

TomaS

On Tue, Sep 1, 2020 at 5:45 PM Bernhard Schmidt  wrote:

> Control: fixed -1 2.5~beta1-1
>
> On Thu, Mar 19, 2020 at 07:34:45PM +0100, Tomáš Szaniszlo wrote:
>
> Dear Tomas,
>
> > It seems that openvpn does not handle SIGINT correctly when in client
> mode
> > with option auth-user-pass enabled. If I press ^C when presented with
> prompt
> > "Enter Auth Username: ", the terminal settings are not reset to a usable
> state.
>
> Thanks for your report.
>
> According to my tests this is fixed in the 2.5 series, if we can
> identify the fixing commit we will issue a stable update.
>
> Bernhard
>

Bug#970563: buster-pu: package libx11/2:1.6.7-1+deb10u1

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jcris...@debian.org, tjaal...@debian.org

This updates fixes a few security issues in libx11, which don't
warrant a DSA. Debdiff attached.

Cheers,
Moritz
diff -u libx11-1.6.7/debian/changelog libx11-1.6.7/debian/changelog
--- libx11-1.6.7/debian/changelog
+++ libx11-1.6.7/debian/changelog
@@ -1,3 +1,10 @@
+libx11 (2:1.6.7-1+deb10u1) buster; urgency=medium
+
+  * CVE-2020-14344
+  * CVE-2020-14363 (Closes: #969008)
+
+ -- Moritz Mühlenhoff   Fri, 11 Sep 2020 19:38:11 +0200
+
 libx11 (2:1.6.7-1) unstable; urgency=medium
 
   * New upstream release.
diff -u libx11-1.6.7/debian/patches/series libx11-1.6.7/debian/patches/series
--- libx11-1.6.7/debian/patches/series
+++ libx11-1.6.7/debian/patches/series
@@ -5,0 +6,2 @@
+CVE-2020-14344.diff
+CVE-2020-14363.diff
only in patch2:
unchanged:
--- libx11-1.6.7.orig/debian/patches/CVE-2020-14344.diff
+++ libx11-1.6.7/debian/patches/CVE-2020-14344.diff
@@ -0,0 +1,296 @@
+Backport of the following upstream commits to address CVE-2020-14344:
+
+0e6561efcfaa0ae7b5c74eac7e064b76d687544e
+1703b9f3435079d3c6021e1ee2ec34fd4978103d
+1a566c9e00e5f35c1f9e7f3d741a02e5170852b2
+2fcfcc49f3b1be854bb9085993a01d17c62acf60
+388b303c62aa35a245f1704211a023440ad2c488
+93fce3f4e79cbc737d6468a4f68ba3de1b83953b
+
+diff -Naur libx11-1.6.7.orig/modules/im/ximcp/imDefIc.c 
libx11-1.6.7/modules/im/ximcp/imDefIc.c
+--- libx11-1.6.7.orig/modules/im/ximcp/imDefIc.c   2018-10-09 
16:27:08.0 +0200
 libx11-1.6.7/modules/im/ximcp/imDefIc.c2020-09-11 17:30:58.689814672 
+0200
+@@ -350,7 +350,7 @@
++ sizeof(INT16)
++ XIM_PAD(2 + buf_size);
+ 
+-if (!(buf = Xmalloc(buf_size)))
++if (!(buf = Xcalloc(buf_size, 1)))
+   return arg->name;
+ buf_s = (CARD16 *)[XIM_HEADER_SIZE];
+ 
+@@ -708,6 +708,7 @@
+ #endif /* XIM_CONNECTABLE */
+ 
+ _XimGetCurrentICValues(ic, _values);
++memset(tmp_buf, 0, sizeof(tmp_buf32));
+ buf = tmp_buf;
+ buf_size = XIM_HEADER_SIZE
+   + sizeof(CARD16) + sizeof(CARD16) + sizeof(INT16) + sizeof(CARD16);
+@@ -730,7 +731,7 @@
+ 
+   buf_size += ret_len;
+   if (buf == tmp_buf) {
+-  if (!(tmp = Xmalloc(buf_size + data_len))) {
++  if (!(tmp = Xcalloc(buf_size + data_len, 1))) {
+   return tmp_name;
+   }
+   memcpy(tmp, buf, buf_size);
+@@ -740,6 +741,7 @@
+   Xfree(buf);
+   return tmp_name;
+   }
++memset([buf_size], 0, data_len);
+   buf = tmp;
+   }
+ }
+diff -Naur libx11-1.6.7.orig/modules/im/ximcp/imDefIm.c 
libx11-1.6.7/modules/im/ximcp/imDefIm.c
+--- libx11-1.6.7.orig/modules/im/ximcp/imDefIm.c   2018-10-09 
16:27:08.0 +0200
 libx11-1.6.7/modules/im/ximcp/imDefIm.c2020-09-11 17:30:58.689814672 
+0200
+@@ -62,6 +62,7 @@
+ #include "XimTrInt.h"
+ #include "Ximint.h"
+ 
++#include 
+ 
+ int
+ _XimCheckDataSize(
+@@ -809,12 +810,16 @@
+ intbuf_size;
+ intret_code;
+ char  *locale_name;
++size_t locale_len;
+ 
+ locale_name = im->private.proto.locale_name;
+-len = strlen(locale_name);
+-buf_b[0] = (BYTE)len;/* length of locale name */
+-(void)strcpy((char *)_b[1], locale_name);  /* locale name */
+-len += sizeof(BYTE); /* sizeof length */
++locale_len = strlen(locale_name);
++if (locale_len > UCHAR_MAX)
++  return False;
++memset(buf32, 0, sizeof(buf32));
++buf_b[0] = (BYTE)locale_len;  /* length of locale name */
++memcpy(_b[1], locale_name, locale_len);  /* locale name */
++len = (INT16)(locale_len + sizeof(BYTE));/* sizeof length */
+ XIM_SET_PAD(buf_b, len); /* pad */
+ 
+ _XimSetHeader((XPointer)buf, XIM_OPEN, 0, );
+@@ -1289,6 +1294,7 @@
+ #endif /* XIM_CONNECTABLE */
+ 
+ _XimGetCurrentIMValues(im, _values);
++memset(tmp_buf, 0, sizeof(tmp_buf32));
+ buf = tmp_buf;
+ buf_size = XIM_HEADER_SIZE + sizeof(CARD16) + sizeof(INT16);
+ data_len = BUFSIZE - buf_size;
+@@ -1311,7 +1317,7 @@
+ 
+   buf_size += ret_len;
+   if (buf == tmp_buf) {
+-  if (!(tmp = Xmalloc(buf_size + data_len))) {
++  if (!(tmp = Xcalloc(buf_size + data_len, 1))) {
+   return arg->name;
+   }
+   memcpy(tmp, buf, buf_size);
+@@ -1321,6 +1327,7 @@
+   Xfree(buf);
+   return arg->name;
+   }
++memset([buf_size], 0, data_len);
+   buf = tmp;
+   }
+ }
+@@ -1462,7 +1469,7 @@
++ sizeof(INT16)
++ XIM_PAD(buf_size);
+ 
+-if (!(buf = Xmalloc(buf_size)))
++if (!(buf = Xcalloc(buf_size, 1)))
+   return arg->name;
+ buf_s = (CARD16 *)[XIM_HEADER_SIZE];
+ 
+@@ -1724,7

Bug#970562: Moderation script for debian-security-announce doesn't cope with non-ASCII characters

Package: lists.debian.org
Severity: important

For DSA 4765 I used the correct name of the person who discovered the issue
(Ervin Hegedüs), but the clearsigned message got rejected by the mod script
(message ID was 20200918171830.ga12...@seger.debian.org). Only when I
rewrote the surname has "Hegedues" it worked.

AFAICT this is a longstanding issue; it would be really great to see it
addressed, so that we don't need to restrict to ASCII.

Cheers,
Moritz

Bug#970545: dpkg FTBFS: KEY_EVENT undeclared

2020-09-18 Thread Guillem Jover

On Fri, 2020-09-18 at 18:26:34 +0200, Sven Joachim wrote:
> Am 18.09.2020 um 13:43 schrieb Helmut Grohne:
> > Source: dpkg
> > Version: 1.20.5
> > Severity: serious
> > Tags: ftbfs
> >
> > dpkg FTBFS as of today:
> >
> > | In file included from ../../dselect/curkeys.cc:30:
> > | ./curkeys.h:168:5: error: ‘KEY_EVENT’ was not declared in this scope; did 
> > you mean ‘KEY_OPEN’?
> > |   168 |   { KEY_EVENT,  "Event"   },
> > |   | ^
> > |   | KEY_OPEN

> > I suppose this is connected to a ncurses upload.

> Quoting the ncurses NEWS file:
> 
> ,
> | 20200817
> | + prevent KEY_EVENT from appearing in curses.h unless the configure
> |   option --enable-wgetch-events is used (report by Werner Fink).
> `

Right, thanks for the confirmation, that's along the lines of what I
had gathered from checking the header. Even though the problem here
is that the macro is there, but just behind a conditional, I suppose
that's still expected?

> See the thread at
> https://lists.gnu.org/archive/html/bug-ncurses/2020-08/threads.html#00017
> for a discussion that motivated this change.

I'll check this later, but no matter what, I think it is still worth
fixing the dpkg build system to handle this kind of case more robustly.
I've prepared the attached patch which seems to work with gcc and clang,
and I'll try to upload either later today or tomorrow.

Thanks,
Guillem
diff --git i/dselect/Makefile.am w/dselect/Makefile.am
index 9206603a2..8195fe414 100644
--- i/dselect/Makefile.am
+++ w/dselect/Makefile.am
@@ -57,18 +57,14 @@ dselect_LDADD = \
 
 
 EXTRA_DIST = keyoverride mkcurkeys.pl
-CLEANFILES = curkeys.h
+CLEANFILES = curkeys.hpp curkeys.h
 
 curkeys.$(OBJEXT): curkeys.h
-curkeys.h: $(srcdir)/keyoverride $(srcdir)/mkcurkeys.pl
-	$(AM_V_GEN) cursesfile=`echo '#include "dselect-curses.h"' | \
-	  $(CPP) $(CPPFLAGS) -I$(top_builddir) -I $(srcdir) - | \
-	  grep '[^-]curses\.h' | head -n 1 | \
-	  sed -e 's/^[^"]*"//; s/".*$$//'`; \
-	if [ "$$cursesfile" = "" ]; then \
-	  echo "can't find curses file"; exit 1; \
-	fi; \
-	$(PERL) $(srcdir)/mkcurkeys.pl $< $$cursesfile >$@
+curkeys.hpp: dselect-curses.h
+	$(AM_V_GEN) echo '#include "dselect-curses.h"' | \
+	  $(CPP) -dD $(CPPFLAGS) -I$(top_builddir) -I $(srcdir) - > $@
+curkeys.h: $(srcdir)/keyoverride $(srcdir)/mkcurkeys.pl curkeys.hpp
+	$(PERL) $(srcdir)/mkcurkeys.pl $< curkeys.hpp >$@
 
 install-data-local:
 	$(MKDIR_P) $(DESTDIR)$(pkgconfdir)/dselect.cfg.d

Bug#970561: [usbguard] service start issues - start request repeated too quickly??

2020-09-18 Thread Lyndon Brown

Package: usbguard
Version: 0.7.8+ds-2

I'm experiencing some failures getting the service started cleanly.

I'll briefly explain how I got to this, if I can recall correctly. I
just had a need to use my printer (unused for quite some time), which I
connected via USB. Nothing was happening when I tried to print, so I
suspected usbguard, and indeed the printer was being blocked as
unauthorised per dmesg output. Not wanting to have to try to craft my
own rule for the printer, I deleted the rules.conf, had aptitude
reinstall usbguard to auto-generate a new one with the printer included
(double checking the details, confirming that it just added an entry).
I believe at this point I re-added the following custom rules to the
end and got the service restarted, before successfully printing, or
maybe I printed first:

```
allow with-interface equals { 08:*:* }
reject with-interface all-of { 08:*:* 03:00:* }
reject with-interface all-of { 08:*:* 03:01:* }
reject with-interface all-of { 08:*:* e0:*:* }
reject with-interface all-of { 08:*:* 02:*:* }
```

I then plugged in a USB pendrive (which usbguard has never blocked
before), but could not access it, and dmesg was indicating usbguard
blocking it, strangely. Restarting the service did not help, so I had
to reboot, at which point it then worked. (Does the service have an
issue re-reading the rules on restarting?).

(Edit: To be clear with the above, I'm pretty certain that I stopped
the service first, then started it again, and repeatedly asked it to
start until it did so successfully, per status output, and it would not
let me use the pendrive until after rebooting).

Getting to the point, when trying to restart the service, I also
checked the status afterwards to double check, only to find the
following:
```
$ sudo systemctl start usbguard
$ sudo systemctl status usbguard
● usbguard.service - USBGuard daemon
 Loaded: loaded (/lib/systemd/system/usbguard.service; enabled;
vendor preset: enabled)
 Active: failed (Result: exit-code) since Fri 2020-09-18 17:12:58
BST; 15s ago
   Docs: man:usbguard-daemon(8)
Process: 2673 ExecStart=/usr/sbin/usbguard-daemon -k -c
/etc/usbguard/usbguard-daemon.conf (code=exited, status=1/FAILURE)
   Main PID: 2673 (code=exited, status=1/FAILURE)

Sep 18 17:12:58 debian1 systemd[1]: usbguard.service: Scheduled restart
job, restart counter is at 5.
Sep 18 17:12:58 debian1 systemd[1]: Stopped USBGuard daemon.
Sep 18 17:12:58 debian1 systemd[1]: usbguard.service: Start request
repeated too quickly.
Sep 18 17:12:58 debian1 systemd[1]: usbguard.service: Failed with
result 'exit-code'.
Sep 18 17:12:58 debian1 systemd[1]: Failed to start USBGuard daemon.
Sep 18 17:13:00 debian1 systemd[1]: usbguard.service: Start request
repeated too quickly.
Sep 18 17:13:00 debian1 systemd[1]: usbguard.service: Failed with
result 'exit-code'.
Sep 18 17:13:00 debian1 systemd[1]: Failed to start USBGuard daemon.
```

It would take multiple attempts at asking it to start for it to report
started successfully.

Now, upon that reboot, I noticed red error indicators in the console
output (they may well have been there before without my noticing),
against services usbguard and usbguard-dbus.

So the first thing I did upon logging in was to double-check the
status, and finding them failed, tried to restart them. I asked first
usbguard to start, then usbguard-dbus, with the latter reporting
failure due to "a dependency job" failing. I checked the usbguard
status, finding it still down due to some failure. I asked it to start
again, checked the status, and it was then up. I then again asked
usbguard-dbus to start, which did not result in a dependency error this
time. But then I immediately checked the usbguard (not usbguard-dbus)
status, and found it down again for some reason, yet then checking
usbguard-dbus status, that was up. I double checked usbguard, and
indeed it was still down, while usbguard-dbus was up. So I asked
usbguard to start once more, and again it then reported being up.

I've just double checked the status after writing this, and usbguard is
down again with error for some reason, while usbguard-dbus remains up.

Bug#617856: apt-show-versions: does not see gzipped Packages files when uncompressed are not available

2020-09-18 Thread MichaIng


Package: apt-show-versions
Version: 0.22.11

I just recognised the same with xz-compressed list files.

I agree that best is probably to rely on APT's internal cache 
commands/functions instead of accessing the list files directly, so no 
additional extraction needs to be implemented and maintained.


This bug/lack btw makes the package install fail as well as "apt(-get) 
update" from then on due to its invocation via apt.conf.d.


Best regards,

Micha

Bug#970560: ITP: glab -- An open-source GitLab command line tool

2020-09-18 Thread TODO

Package: wnpp
Severity: wishlist
Owner: TODO

* Package name: glab
Version : 1.10.0-1
Upstream Author : Clement Sam
* URL : https://github.com/profclems/glab
* License : Expat
Programming Lang: Go
Description : An open-source GitLab command line tool

GLab
.
All Contributors (#contributors-)
.
.
Go Report Card (https://goreportcard.com/report/github.com/profclems/glab)
GitHub Workflow Status .github/workflows/build_docs.yml Gitter

(https://gitter.im/glabcli/community?utm_source=badge_medium=badge_campaign=pr-badge)
License (LICENSE) Twitter

(https://twitter.com/intent/tweet?text=Take%20Gitlab%20to%20the%20command%20line%20with%20%23glab,%20an%20open-source%20GitLab%20CLI%20tool:=https%3A%2F%2Fgithub.com%2Fprofclems%2Fglab)
.
GLab is an open source Gitlab Cli tool written in Go (golang) to help
work seamlessly with Gitlab from the command line. Work with issues,
merge requests, watch running pipelines directly from your CLI among
other features.
.
image Usage bash
glab [flags]
.
Core Commands• glab mr [list, create, close, reopen, delete]• glab
issue [list, create, close, reopen, delete]• glab pipeline [list,
delete, ci status, ci view]• glab config• glab helpExamples bash
$ glab issue create --title="This is an issue title" --description="This
is a really long description" $ glab issue list --closed $ glab pipeline
ci view -b master# to watch the latest pipeline on master $ glab
pipeline status# classic ci view
.
Learn More Read the documentation (https://clementsam.tech/glab) for
more information on this tool. Support glab  By donating $5 or
more you can support the ongoing development of this project. We'll
appreciate some support. Thank you to all our supporters! 
[Contribute (https://opencollective.com/glab/contribute)] Individuals
This project exists thanks to all the people who contribute. [Contribute
(https://github.com/profclems/glab/blob/trunk/.github/CONTRIBUTING.md)].
.
Backers Thank you to all our backers!  [Become a backer
(https://opencollective.com/glab/contribute)]
.
Installation Download a binary suitable for your OS at the releases page
(https://github.com/profclems/glab/releases/latest). Quick Install (Bash)
You can install or update glab with: bash curl -sL https://j.mp/glab-i |
sudo bash
.
or bash curl -s
https://raw.githubusercontent.com/profclems/glab/trunk/scripts/quick_install.sh
| sudo bash
.
Installs into usr/local/bin
.
NOTE: Please take care when running scripts in this fashion. Consider
peaking at the install script itself and verify that it works as intended.
Windows Available for download on scoop or manually as an installable
executable file or a Portable archived file in tar and zip formats at the
releases page (https://github.com/profclems/glab/releases/latest).
Download and install now at the releases page
(https://github.com/profclems/glab/releases/latest).
.
The installable executable file sets the PATH
automatically. Scoop sh scoop bucket add profclems-bucket
https://github.com/profclems/scoop-bucket.git scoop install glab
.
Linux Downloads available via linuxbrew (homebrew) and tar balls Linuxbrew
(Homebrew) sh brew install profclems/tap/glab
.
Updating: sh brew upgrade glab
.
Arch Linux glab is available through the gitlab-glab-bin
(https://aur.archlinux.org/packages/gitlab-glab-bin/) package on
the AUR. Manual Installation Download the tar ball, untar and
install: • Download the .tar.gz file from the releases page
(https://github.com/profclems/glab/releases/latest)• unzip
glab-*-linux-amd64.tar.gz to unzip the downloaded file• sudo mv
glab-*-linux-amd64/glab /usr/binMacOS glab is available via Homebrew or
you can manually install Homebrew sh brew install profclems/tap/glab
.
Updating: sh brew upgrade glab
.
Installing manually• Download the .tar.gz or .zip file from the releases
page (https://github.com/profclems/glab/releases/latest) and unzip or
untar• ls /usr/local/bin/ || sudo mkdir /usr/local/bin/; to make sure
the bin folder exists• sudo mv glab-*-darwin-amd64/glab /usr/binBuilding
From Source If a supported binary for your OS is not found at the releases
page (https://github.com/profclems/glab/releases/latest), you can build
from source: • Verify that you have Go 1.13.8+ installed sh
$ go version go version go1.14
.
.
If go is not installed, follow instructions on the Go website
(https://golang.org/doc/install). • Clone this repository sh
$ git clone https://github.com/profclems/glab.git glab-cli $
cd glab-cli
.
.
or
.
sh
$ git clone https://gitlab.com/profclems/glab.git $ cd glab-cli
.
• Build the project
.
$ make build
.
• Move the resulting bin/glab executable to somewhere in your PATH sh
$ sudo mv ./bin/glab /usr/local/bin/
.
or sh $ sudo mv ./bin/glab /usr/bin/
.
• Run glab version to check if it worked and glab
config -g to set upConfiguration Get a

Bug#970559: ITP: glab -- An open-source GitLab command line tool

2020-09-18 Thread TODO

Package: wnpp
Severity: wishlist
Owner: TODO

GLab
.
All Contributors (#contributors-)
.
.
Go Report Card (https://goreportcard.com/report/github.com/profclems/glab)
GitHub Workflow Status .github/workflows/build_docs.yml Gitter

(https://gitter.im/glabcli/community?utm_source=badge_medium=badge_campaign=pr-badge)
License (LICENSE) Twitter

Bug#970555: ncurses: Upgrade fails: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/x86_64-linux-gnu/libncurses.so.6)

2020-09-18 Thread Sebastiaan Couwenberg

Control: tags -1 - moreinfo

On 9/18/20 6:13 PM, Sven Joachim wrote:
> On 2020-09-18 16:55 +0200, Bas Couwenberg wrote:
>> Upgrading sid & experimental pbuilder chroots fails due to the new ncurses:
>>
>>  Preparing to unpack .../libncursesw6_6.2+20200912-1_amd64.deb ...
>>  Unpacking libncursesw6:amd64 (6.2+20200912-1) over (6.2-1) ...
>>  Preparing to unpack .../libncurses6_6.2+20200912-1_amd64.deb ...
>>  Unpacking libncurses6:amd64 (6.2+20200912-1) over (6.2-1) ...
>>  rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
>> `NCURSES6_TINFO_6.2.current' not found (required by 
>> /lib/x86_64-linux-gnu/libncurses.so.6)
>>  dpkg: error while cleaning up:
>>   rm command for cleanup subprocess returned error exit status 1
>>  dpkg-split: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
>> `NCURSES6_TINFO_6.2.current' not found (required by 
>> /lib/x86_64-linux-gnu/libncurses.so.6)
>>  rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
>> `NCURSES6_TINFO_6.2.current' not found (required by 
>> /lib/x86_64-linux-gnu/libncurses.so.6)
>>  dpkg: error processing archive 
>> /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb (--unpack):
>>   rm command for cleanup subprocess returned error exit status 1
>>  Errors were encountered while processing:
>>   /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb
>>  E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> I cannot reproduce this, but my pbuilder chroots do not have libncurses6
> installed at all.

What about cowbuilder chroots?

> What is this rm binary in your chroot, apparently it
> is linked to libncurses.so.6?

 # which rm
 /bin/rm
 # dpkg -S /bin/rm
 coreutils: /bin/rm
 # ldd /bin/rm
 linux-vdso.so.1 (0x7ffea75fb000)
 /usr/lib/cowdancer/libcowdancer.so (0x7f2e6a6db000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f2e6a512000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2e6a50c000)
 libncurses.so.6 => /lib/x86_64-linux-gnu/libncurses.so.6
(0x7f2e6a4e3000)
 libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6
(0x7f2e6a4b4000)
 /lib64/ld-linux-x86-64.so.2 (0x7f2e6a6f9000)
 # aptitude why libncurses6
 i   cowdancer Depends libncurses6 (>= 6)

Kind Regards,

Bas

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

Bug#970545: dpkg FTBFS: KEY_EVENT undeclared

Am 18.09.2020 um 13:43 schrieb Helmut Grohne:

> Source: dpkg
> Version: 1.20.5
> Severity: serious
> Tags: ftbfs
>
> dpkg FTBFS as of today:
>
> | g++ -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\"
> | -DADMINDIR=\"/var/lib/dpkg\" -DLIBDIR=\"/usr/lib/dpkg\"
> | -DLOCALLIBDIR=\"/usr/local/lib/dpkg\" -idirafter ../../lib/compat
> | -iquote . -I.. -I../../lib -Wdate-time -D_FORTIFY_SOURCE=2 -fno-rtti
> | -fno-exceptions -Wall -Wextra -Wcast-align -Wduplicated-branches
> | -Wduplicated-cond -Wformat -Wformat-security -Wformat=2 -Winit-self
> | -Wlogical-not-parentheses -Wlogical-op -Wmissing-declarations
> | -Wmissing-format-attribute -Wno-missing-field-initializers
> | -Wno-nonnull-compare -Wno-unused-parameter -Wnull-dereference
> | -Wpointer-arith -Wredundant-decls -Wregister -Wrestrict -Wshadow
> | -Wshift-negative-value -Wsizeof-array-argument -Wswitch-bool -Wvla
> | -Wwrite-strings -Wc++11-compat -Wcast-qual -Wold-style-cast
> | -Wzero-as-null-pointer-constant -g -O2
> | -fdebug-prefix-map=/<>=. -fstack-protector-strong
> | -Wformat -Werror=format-security -Wall -Wextra
> | -Wno-missing-field-initializers -Wno-nonnull-compare
> | -Wno-unused-parameter -MT curkeys.o -MD -MP -MF .deps/curkeys.Tpo -c
> | -o curkeys.o ../../dselect/curkeys.cc
> | mv -f .deps/pkgdisplay.Tpo .deps/pkgdisplay.Po
> | mv -f .deps/pkginfo.Tpo .deps/pkginfo.Po
> | mv -f .deps/pkgcmds.Tpo .deps/pkgcmds.Po
> | In file included from ../../dselect/curkeys.cc:30:
> | ./curkeys.h:168:5: error: ‘KEY_EVENT’ was not declared in this scope; did 
> you mean ‘KEY_OPEN’?
> |   168 |   { KEY_EVENT,  "Event"   },
> |   | ^
> |   | KEY_OPEN
> | make[4]: *** [Makefile:617: curkeys.o] Error 1
> | make[4]: *** Waiting for unfinished jobs
> | mv -f .deps/pkgdepcon.Tpo .deps/pkgdepcon.Po
> | mv -f .deps/pkgsublist.Tpo .deps/pkgsublist.Po
> | mv -f .deps/pkgtop.Tpo .deps/pkgtop.Po
> | mv -f .deps/pkglist.Tpo .deps/pkglist.Po
> | make[4]: Leaving directory '/<>/build-tree/dselect'
> | make[3]: *** [Makefile:650: all-recursive] Error 1
> | make[3]: Leaving directory '/<>/build-tree/dselect'
> | make[2]: *** [Makefile:743: all-recursive] Error 1
> | make[2]: Leaving directory '/<>/build-tree'
> | make[1]: *** [Makefile:609: all] Error 2
> | make[1]: Leaving directory '/<>/build-tree'
> | make: *** [debian/rules:74: build] Error 2
> | dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
> status 2
>
> I suppose this is connected to a ncurses upload.

Quoting the ncurses NEWS file:

,
| 20200817
|   + prevent KEY_EVENT from appearing in curses.h unless the configure
| option --enable-wgetch-events is used (report by Werner Fink).
`

See the thread at
https://lists.gnu.org/archive/html/bug-ncurses/2020-08/threads.html#00017
for a discussion that motivated this change.

Cheers,
   Sven

Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

Dear Tony and Tiago,

Pleasure!  Needs forced me to do so ;-)

Best wishes,

   Julian

On Fri, Sep 18, 2020 at 01:13:55PM -0300, Tiago Daitx wrote:
> Hi Tony,
> 
> Matthias is the actual Debian Maintainer, but in my opinion the patch
> is great and should be ok to go do an upload including it.
> 
> Thanks Julian for the investigation and figuring out how to fix this
> problem, I really appreciate it. =)
> 
> Best regards,
> Tiago
> 
> On Fri, Sep 18, 2020 at 11:12 AM tony mancill  wrote:
> >
> > On Fri, Sep 18, 2020 at 11:15:13AM +0100, Julian Gilbey wrote:
> > > tags 944738 patch
> > > thanks
> > >
> > > On Thu, Sep 17, 2020 at 06:45:39PM +0100, Julian Gilbey wrote:
> > > > affects 944738 openjdk-14-jdk
> > > > thanks
> > > >
> > > > The same problem is still present in openjdk-14 - see
> > > > https://bugs.debian.org/968991
> > >
> > > I have located the source of the bug and have a patch to fix it.
> > >
> > > The cause is the use of dh_strip_nondeterminism late in the build
> > > process.  This reorganises the jmod files, which in turn changes their
> > > SHA256 checksums.  This would not be a problem, except that the
> > > checksums are saved in java.base.jmod *before* the use of
> > > dh_strip_nondeterminism.  Performing this stripping immediately after
> > > each jmod file is created results in the checksums being consistent
> > > throughout.
> >
> > Thank you for digging into this bug Julian!
> >
> > Matthias or Tiago, any concerns with me preparing an upload that
> > includes this patch?
> >
> > Thank you,
> > tony

Bug#970558: openblas: segfault in zgemm_oncopy_EMAG8180 during sagemath test on arm64

2020-09-18 Thread Tobias Hansen

Package: libopenblas0
Version: 0.3.10+ds-3
Severity: normal

Hi,

a sagemath test segfaulted in libopenblas.so.0 / zgemm_oncopy_EMAG8180 when 
building on arm-ubc-01.debian.org,
see 
https://buildd.debian.org/status/fetch.php?pkg=sagemath=arm64=9.2%7Ebeta12-1=159992=0

openblas was called by numpy and the issue looks similar to #966175 where the 
segfault occurred in dgemm_oncopy_HASWELL.

Extract from the stack backtrace:

#5  0xab2fe3b0 in zgemm_oncopy_EMAG8180 () from 
/usr/lib/aarch64-linux-gnu/libopenblas.so.0
#6  0xaaac8430 in zgetrf_single () from 
/usr/lib/aarch64-linux-gnu/libopenblas.so.0
#7  0xaa064f3c in zgesv_ () from 
/usr/lib/aarch64-linux-gnu/liblapack.so.3
#8  0xaa00f330 in ?? () from 
/usr/lib/python3/dist-packages/numpy/linalg/_umath_linalg.cpython-38-aarch64-linux-gnu.so

Best,
Tobias

Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

2020-09-18 Thread Tiago Daitx

Hi Tony,

Matthias is the actual Debian Maintainer, but in my opinion the patch
is great and should be ok to go do an upload including it.

Thanks Julian for the investigation and figuring out how to fix this
problem, I really appreciate it. =)

Best regards,
Tiago

On Fri, Sep 18, 2020 at 11:12 AM tony mancill  wrote:
>
> On Fri, Sep 18, 2020 at 11:15:13AM +0100, Julian Gilbey wrote:
> > tags 944738 patch
> > thanks
> >
> > On Thu, Sep 17, 2020 at 06:45:39PM +0100, Julian Gilbey wrote:
> > > affects 944738 openjdk-14-jdk
> > > thanks
> > >
> > > The same problem is still present in openjdk-14 - see
> > > https://bugs.debian.org/968991
> >
> > I have located the source of the bug and have a patch to fix it.
> >
> > The cause is the use of dh_strip_nondeterminism late in the build
> > process.  This reorganises the jmod files, which in turn changes their
> > SHA256 checksums.  This would not be a problem, except that the
> > checksums are saved in java.base.jmod *before* the use of
> > dh_strip_nondeterminism.  Performing this stripping immediately after
> > each jmod file is created results in the checksums being consistent
> > throughout.
>
> Thank you for digging into this bug Julian!
>
> Matthias or Tiago, any concerns with me preparing an upload that
> includes this patch?
>
> Thank you,
> tony
> ___
> Mailing list: https://launchpad.net/~openjdk
> Post to : open...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openjdk
> More help   : https://help.launchpad.net/ListHelp



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#970555: ncurses: Upgrade fails: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/x86_64-linux-gnu/libncurses.so.6)

Control: tags -1 moreinfo

On 2020-09-18 16:55 +0200, Bas Couwenberg wrote:

> Source: ncurses
> Version: 6.2+20200912-1
> Severity: serious
> Justification: makes the package in question unusable or mostly so
>
> Dear Maintainer,
>
> Upgrading sid & experimental pbuilder chroots fails due to the new ncurses:
>
>  Preparing to unpack .../libncursesw6_6.2+20200912-1_amd64.deb ...
>  Unpacking libncursesw6:amd64 (6.2+20200912-1) over (6.2-1) ...
>  Preparing to unpack .../libncurses6_6.2+20200912-1_amd64.deb ...
>  Unpacking libncurses6:amd64 (6.2+20200912-1) over (6.2-1) ...
>  rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
> `NCURSES6_TINFO_6.2.current' not found (required by 
> /lib/x86_64-linux-gnu/libncurses.so.6)
>  dpkg: error while cleaning up:
>   rm command for cleanup subprocess returned error exit status 1
>  dpkg-split: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
> `NCURSES6_TINFO_6.2.current' not found (required by 
> /lib/x86_64-linux-gnu/libncurses.so.6)
>  rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
> `NCURSES6_TINFO_6.2.current' not found (required by 
> /lib/x86_64-linux-gnu/libncurses.so.6)
>  dpkg: error processing archive 
> /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb (--unpack):
>   rm command for cleanup subprocess returned error exit status 1
>  Errors were encountered while processing:
>   /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb
>  E: Sub-process /usr/bin/dpkg returned an error code (1)

I cannot reproduce this, but my pbuilder chroots do not have libncurses6
installed at all.  What is this rm binary in your chroot, apparently it
is linked to libncurses.so.6?

Cheers,
   Sven

Bug#970557: linux-image-5.8.0-1-amd64: kernel crash in nouveau

2020-09-18 Thread Vincent Lefevre

Package: src:linux
Version: 5.8.7-1
Severity: important

A short time after updating the kernel and rebooted, the kernel
crashed in nouveau while I wasn't using the machine (I only had
an ssh session).

Sep 18 17:56:26 ypig kernel: [ 1445.181686] [ cut here ]
Sep 18 17:56:26 ypig kernel: [ 1445.181755] WARNING: CPU: 1 PID: 0 at 
drivers/gpu/drm/nouveau/nvkm/subdev/mc/base.c:72 nvkm_mc_intr+0x14d/0x170 
[nouveau]
Sep 18 17:56:26 ypig kernel: [ 1445.181756] Modules linked in: bnep bluetooth 
jitterentropy_rng drbg aes_generic crypto_simd cryptd glue_helper ansi_cprng 
ecdh_generic ecc libaes cpufreq_powersave cpufreq_conservative 
cpufreq_userspace binfmt_misc nfsd auth_rpcgss nfs_acl nfs lockd grace fscache 
sunrpc smsc47b397 loop firewire_sbp2 nft_counter ip6_tables nft_compat 
nf_tables x_tables nfnetlink snd_hda_codec_realtek snd_hda_codec_generic 
ledtrig_audio snd_hda_intel nouveau intel_powerclamp coretemp mxm_wmi 
snd_intel_dspcfg video snd_hda_codec kvm_intel ttm kvm snd_hda_core 
drm_kms_helper irqbypass cec hp_wmi snd_hwdep sparse_keymap snd_pcm rfkill drm 
intel_cstate evdev snd_timer intel_uncore i2c_algo_bit snd serio_raw button 
iTCO_wdt intel_pmc_bxt wmi_bmof soundcore sg iTCO_vendor_support watchdog 
i7core_edac acpi_cpufreq ext4 crc16 mbcache jbd2 crc32c_generic hid_generic 
usbhid hid sd_mod t10_pi crc_t10dif crct10dif_generic sr_mod cdrom 
crct10dif_common ahci mptsas libahci mptscsih mptbase libata scsi_transport_sas
Sep 18 17:56:26 ypig kernel: [ 1445.181790]  firewire_ohci scsi_mod 
firewire_core psmouse ehci_pci uhci_hcd crc_itu_t crc32c_intel ehci_hcd tg3 
usbcore lpc_ich libphy ptp pps_core usb_common wmi floppy
Sep 18 17:56:26 ypig kernel: [ 1445.181800] CPU: 1 PID: 0 Comm: swapper/1 
Tainted: G  I   5.8.0-1-amd64 #1 Debian 5.8.7-1
Sep 18 17:56:26 ypig kernel: [ 1445.181801] Hardware name: Hewlett-Packard HP 
Z800 Workstation/0AECh, BIOS 786G5 v01.17 08/19/2009
Sep 18 17:56:26 ypig kernel: [ 1445.181842] RIP: 0010:nvkm_mc_intr+0x14d/0x170 
[nouveau]
Sep 18 17:56:26 ypig kernel: [ 1445.181844] Code: 44 24 18 65 48 2b 04 25 28 00 
00 00 75 2b 48 83 c4 20 5b 5d 41 5c 41 5d 41 5e 41 5f c3 41 8b 47 40 85 c0 74 
ba e9 34 97 0a 00 <0f> 0b 45 31 e4 c6 44 24 0f 00 e9 00 ff ff ff e8 bf bf 77 f2 
66 66
Sep 18 17:56:26 ypig kernel: [ 1445.181845] RSP: 0018:be65c3250ee8 EFLAGS: 
00010046
Sep 18 17:56:26 ypig kernel: [ 1445.181846] RAX:  RBX: 
95ed5fcefd00 RCX: 0018
Sep 18 17:56:26 ypig kernel: [ 1445.181847] RDX: 00ff RSI: 
be65c3250f47 RDI: be65d1000100
Sep 18 17:56:26 ypig kernel: [ 1445.181848] RBP: 95eb45d89c00 R08: 
be65c3250ff8 R09: 
Sep 18 17:56:26 ypig kernel: [ 1445.181849] R10:  R11: 
 R12: 
Sep 18 17:56:26 ypig kernel: [ 1445.181850] R13:  R14: 
be65c3250fac R15: 95f00f84b4e0
Sep 18 17:56:26 ypig kernel: [ 1445.181851] FS:  () 
GS:95ed63c4() knlGS:
Sep 18 17:56:26 ypig kernel: [ 1445.181852] CS:  0010 DS:  ES:  CR0: 
80050033
Sep 18 17:56:26 ypig kernel: [ 1445.181853] CR2: 7fa6714218b0 CR3: 
96a0a000 CR4: 06e0
Sep 18 17:56:26 ypig kernel: [ 1445.181854] Call Trace:
Sep 18 17:56:26 ypig kernel: [ 1445.181858]  
Sep 18 17:56:26 ypig kernel: [ 1445.181902]  nvkm_pci_intr+0x4d/0x90 [nouveau]
Sep 18 17:56:26 ypig kernel: [ 1445.181908]  
__handle_irq_event_percpu+0x48/0x190
Sep 18 17:56:26 ypig kernel: [ 1445.181910]  handle_irq_event+0x5d/0xbb
Sep 18 17:56:26 ypig kernel: [ 1445.181912]  handle_edge_irq+0x9c/0x280
Sep 18 17:56:26 ypig kernel: [ 1445.181916]  asm_call_on_stack+0x12/0x20
Sep 18 17:56:26 ypig kernel: [ 1445.181917]  
Sep 18 17:56:26 ypig kernel: [ 1445.181919]  common_interrupt+0xb5/0x150
Sep 18 17:56:26 ypig kernel: [ 1445.181921]  asm_common_interrupt+0x1e/0x40
Sep 18 17:56:26 ypig kernel: [ 1445.181925] RIP: 
0010:cpuidle_enter_state+0xb3/0x3f0
Sep 18 17:56:26 ypig kernel: [ 1445.181927] Code: 65 8b 3d 90 87 fb 4c e8 8b 32 
a6 ff 49 89 c7 66 66 66 66 90 31 ff e8 3c 3d a6 ff 80 7c 24 0f 00 0f 85 d4 01 
00 00 fb 66 66 90 <66> 66 90 45 85 e4 0f 88 e0 01 00 00 49 63 d4 4c 2b 7c 24 10 
48 8d
Sep 18 17:56:26 ypig kernel: [ 1445.181927] RSP: 0018:be65c31abe78 EFLAGS: 
0246
Sep 18 17:56:26 ypig kernel: [ 1445.181929] RAX: 95ed63c6bf40 RBX: 
de62bfc7f800 RCX: 001f
Sep 18 17:56:26 ypig kernel: [ 1445.181929] RDX:  RSI: 
3877f6f2 RDI: 
Sep 18 17:56:26 ypig kernel: [ 1445.181930] RBP: b3cc79c0 R08: 
01507655682b R09: 0151d95e40fc
Sep 18 17:56:26 ypig kernel: [ 1445.181931] R10: 0046 R11: 
003c R12: 0004
Sep 18 17:56:26 ypig kernel: [ 1445.181932] R13: de62bfc7f800 R14: 
0004 R15: 01507655682b
Sep 18 17:56:26 ypig kernel: [ 1445.181935]  ? cpuidle_enter_state+0xa4/0x3f0
Sep

Bug#970525: docker.io: Unable to start minikube/kubernetes containers: unable to find user 0: invalid argument

2020-09-18 Thread anomie

Here's a simpler test case:

  $ sudo dpkg -i docker.io_19.03.12+dfsg1-4_amd64.deb 
  (Reading database ... 257350 files and directories currently installed.)
  Preparing to unpack docker.io_19.03.12+dfsg1-4_amd64.deb ...
  Unpacking docker.io (19.03.12+dfsg1-4) over (19.03.12+dfsg1-3) ...
  Setting up docker.io (19.03.12+dfsg1-4) ...
  insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
  Processing triggers for systemd (246.5-1) ...
  Processing triggers for man-db (2.9.3-2) ...
  $ sudo systemctl restart docker
  $ sudo docker run tianon/true && echo "ok"
  docker: Error response from daemon: unable to find user 0: invalid argument.
  ERRO[] error waiting for container: context canceled 

versus

  $ sudo dpkg -i docker.io_19.03.12+dfsg1-3_amd64.deb 
  dpkg: warning: downgrading docker.io from 19.03.12+dfsg1-4 to 19.03.12+dfsg1-3
  (Reading database ... 257350 files and directories currently installed.)
  Preparing to unpack docker.io_19.03.12+dfsg1-3_amd64.deb ...
  Unpacking docker.io (19.03.12+dfsg1-3) over (19.03.12+dfsg1-4) ...
  Setting up docker.io (19.03.12+dfsg1-3) ...
  insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
  Processing triggers for systemd (246.5-1) ...
  Processing triggers for man-db (2.9.3-2) ...
  $ sudo systemctl restart docker
  $ sudo docker run tianon/true && echo "ok"
  ok

Bug#970556: vulkan-validationlayers-dev: ships /usr/include/xxhash.h already provided by libxxhash-dev

2020-09-18 Thread Andreas Beckmann

Package: vulkan-validationlayers-dev
Version: 1.2.148.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

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

  Preparing to unpack .../vulkan-validationlayers-dev_1.2.148.0-1_amd64.deb ...
  Unpacking vulkan-validationlayers-dev:amd64 (1.2.148.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/vulkan-validationlayers-dev_1.2.148.0-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/include/xxhash.h', which is also in package 
libxxhash-dev:amd64 0.8.0-1
  Errors were encountered while processing:
   /var/cache/apt/archives/vulkan-validationlayers-dev_1.2.148.0-1_amd64.deb


cheers,

Andreas


libxxhash-dev=0.8.0-1_vulkan-validationlayers-dev=1.2.148.0-1.log.gz
Description: application/gzip

Bug#927062: RFE: ddupdate: Please provide non-systemd scripts.

2020-09-18 Thread Tobias Frost

Package: ddupdate
Followup-For: Bug #927062
Control: tags -1 upstream

Lowering severity to wishlist then. (done seperatly with bts(1))
However, I've forgot the "upstream" tagging and also wanted to add a line:

I suggest to close the bug and reopen once someone provides a patch.
(of course this can be discussed also upstream, again best with a patch)

-- 
tobi

Bug#970555: ncurses: Upgrade fails: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/x86_64-linux-gnu/libncurses.so.6)

2020-09-18 Thread Bas Couwenberg

Source: ncurses
Version: 6.2+20200912-1
Severity: serious
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

Upgrading sid & experimental pbuilder chroots fails due to the new ncurses:

 Preparing to unpack .../libncursesw6_6.2+20200912-1_amd64.deb ...
 Unpacking libncursesw6:amd64 (6.2+20200912-1) over (6.2-1) ...
 Preparing to unpack .../libncurses6_6.2+20200912-1_amd64.deb ...
 Unpacking libncurses6:amd64 (6.2+20200912-1) over (6.2-1) ...
 rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' 
not found (required by /lib/x86_64-linux-gnu/libncurses.so.6)
 dpkg: error while cleaning up:
  rm command for cleanup subprocess returned error exit status 1
 dpkg-split: /lib/x86_64-linux-gnu/libtinfo.so.6: version 
`NCURSES6_TINFO_6.2.current' not found (required by 
/lib/x86_64-linux-gnu/libncurses.so.6)
 rm: /lib/x86_64-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' 
not found (required by /lib/x86_64-linux-gnu/libncurses.so.6)
 dpkg: error processing archive 
/var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb (--unpack):
  rm command for cleanup subprocess returned error exit status 1
 Errors were encountered while processing:
  /var/cache/apt/archives/libtinfo6_6.2+20200912-1_amd64.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)

Kind Regards,

Bas

Bug#946845: closing no longer relevant bug

2020-09-18 Thread Pirate Praveen


This is fixed in rails and autopkgtests are passing now

Bug#970550: this is a bug in ruby-autoprefixer-rails

2020-09-18 Thread Pirate Praveen


Control: reassign -1 ruby-autoprefixer-rails
Control: found -1 8.6.5+dfsg-3

After replacing sass-rails, execjs and autoprefixer-rails (taking clues 
from the error log) with versions from rubygems.org, I found 
autoprefixer-rails version installed from rubygems.org fixes this 
issue, so the bug is in ruby-autoprefixer-rails.

Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

2020-09-18 Thread tony mancill

On Fri, Sep 18, 2020 at 11:15:13AM +0100, Julian Gilbey wrote:
> tags 944738 patch
> thanks
> 
> On Thu, Sep 17, 2020 at 06:45:39PM +0100, Julian Gilbey wrote:
> > affects 944738 openjdk-14-jdk
> > thanks
> > 
> > The same problem is still present in openjdk-14 - see
> > https://bugs.debian.org/968991
> 
> I have located the source of the bug and have a patch to fix it.
> 
> The cause is the use of dh_strip_nondeterminism late in the build
> process.  This reorganises the jmod files, which in turn changes their
> SHA256 checksums.  This would not be a problem, except that the
> checksums are saved in java.base.jmod *before* the use of
> dh_strip_nondeterminism.  Performing this stripping immediately after
> each jmod file is created results in the checksums being consistent
> throughout.

Thank you for digging into this bug Julian!

Matthias or Tiago, any concerns with me preparing an upload that
includes this patch?

Thank you,
tony


signature.asc
Description: PGP signature

Bug#970554: RFP: librespeed-speedtest -- A self-hosted Speedtest backend implementation

2020-09-18 Thread Vipul

Package: wnpp
Severity: wishlist

* Package name: librespeed-speedtest
  Version : 5.2.1
  Upstream Author : Federico Dossena 
* URL : https://github.com/librespeed/speedtest
* License : LGPL-3.0
  Programming Lang: Javascript, PHP
  Description : A self-hosted Speedtest backend implementation

librespeed-speedtest is a free and open source backend implemention to
test Internet bandwith. Unlike speedtest.net, librespeed backends are
free and open source, which is available in PHP[1] and Go[2] (currently
in beta) implementation; also it doesn't have miles-long privacy
policy[3].

Related bug report: 968032[4]

[1]: https://github.com/librespeed/speedtest
[2]: https://github.com/librespeed/speedtest-go
[3]: https://www.speedtest.net/about/privacy
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968032

Bug#970553: RFS: lebiniou/3.43.1-2 -- displays images that evolve with sound

2020-09-18 Thread Olivier Girondel


Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lebiniou":

 * Package name: lebiniou
   Version : 3.43.1-2
   Upstream Author : Olivier Girondel 
 * URL : https://biniou.net
 * License : GPL-2+
   Section : graphics

It builds this binary package:

  lebiniou - displays images that evolve with sound

The package appears to be lintian-clean.

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.43.1-2.dsc

Changes since the last upload:

  * debian/tests/control: Add Restrictions: superficial (Closes: #969837).

Regards,

Olivier Girondel






signature.asc
Description: OpenPGP digital signature

Bug#892105: i40e

2020-09-18 Thread Mikhail Krylatykh


> We have the same problem here with the newest Stretch 4.9 kernel. When using 
> a secondary IP address the i40e driver starts to randomly ignore ARP requests 
> and makes the system unreachable for the rest of the network.
> Upgrading to a backport kernel (4.19) with newer 4.19 driver fixes the 
> problem.


Hi,
We've faced the same issue with Debian Stretch. i40e driver with version 1.6.16 
silently dropped ARP packets while not `promisc on` enabled on target 
interface. Update to linux-image-4.19 from backports (i40e driver comes with 
version 2.3.2) repository fixed this issue.

Thanks for comments and suggested workaround.

---
WBR, 
Mikhail

Bug#970552: python-wicd: up-to-date testing python2 package breaks reinstallation

2020-09-18 Thread Harald

Package: python-wicd
Version: 1.7.4+tb2-6
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

After upgrading, I lost my wicd packages and wanted to reinstall those. Python 
2.7.18 breaks it. 

See terminal session snippet:
+++
jupp:|quellen/wicd > python2 --version
Python 2.7.18
jupp:|quellen/wicd > sudo apt-get install python-wicd
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python-wicd : Depends: python:any (< 2.8)
   Depends: python:any (>= 2.7.5-5~)
E: Unable to correct problems, you have held broken packages.
+++

After downgrading to 2.7.16-1 I could reinstall wicd and its dependencies.

Upgrading to python2 2.7.18 breaks wicd packages.


   * What led up to the situation?
apt dist-upgrade installed new python2 version and removed wicd packages
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
downgrading of all relevant python-based dependencies to 2.7.16-1
   * What was the outcome of this action?
wicd could be installed again, ll is running

*** End of the template - remove these template lines ***

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

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

Versions of packages python-wicd depends on:
ii  net-tools  1.60+git20180626.aebd88e-1
ii  python 2.7.16-1

python-wicd recommends no packages.

Versions of packages python-wicd suggests:
ii  ethtool   1:5.8-1
ii  iproute2  5.8.0-1

Versions of packages wicd-gtk depends on:
ii  python 2.7.16-1
ii  python-glade2  2.24.0-5.1+b1
ii  python-gtk22.24.0-5.1+b1
ii  wicd-daemon1.7.4+tb2-6

Versions of packages wicd-gtk recommends:
ii  menu   2.1.47+b1
ii  policykit-10.105-29
ii  python-notify  0.1.1-4

Versions of packages wicd-daemon depends on:
ii  adduser   3.118
ii  dbus  1.12.20-1
ii  debconf   1.5.74
ii  inetutils-ping2:1.9.4-12
ii  isc-dhcp-client   4.4.1-2.1+b2
ii  lsb-base  11.1.0
ii  psmisc23.3-1
ii  python2.7.16-1
ii  python-dbus   1.2.8-3
ii  python-gobject-2  2.28.6-13+b1
ii  wireless-tools30~pre9-13.1
ii  wpasupplicant 2:2.9.0-15

Versions of packages wicd-daemon recommends:
ii  rfkill  2.36-3
ii  wicd-gtk [wicd-client]  1.7.4+tb2-6

Versions of packages wicd-daemon suggests:
ii  pm-utils  1.4.1-19

-- debconf information:
* wicd/users:

Bug#970134: libweston-9-dev: missing (unversioned) Breaks+Replaces: libweston-8-dev

2020-09-18 Thread Hector Oron

Hello,

On Sat, 12 Sep 2020 at 11:21, Andreas Beckmann  wrote:
>
> Package: libweston-9-dev
> Version: 9.0.0-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
>
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
>
> >From the attached log (scroll to the bottom...):
>
>   Preparing to unpack .../libweston-9-dev_9.0.0-1_amd64.deb ...
>   Unpacking libweston-9-dev (9.0.0-1) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/libweston-9-dev_9.0.0-1_amd64.deb (--unpack):
>trying to overwrite '/usr/lib/x86_64-linux-gnu/weston/libexec_weston.so', 
> which is also in package libweston-8-dev 8.0.0-1
>   Errors were encountered while processing:
>/var/cache/apt/archives/libweston-9-dev_9.0.0-1_amd64.deb
>
> Since libweston-8-dev is gone, the Breaks+Replaces can be unversioned.

Thanks for the report, I have been investigating a bit this issue,
libexec_weston was introduced in weston_8, it was created for the
purpose of the reset of the test suite so it doesn't need to exec()
but just load libexec_weston.so. libexec_weston is not something
anyone else should develop against, it is only needed by weston
binary.

I'll look into dropping
/usr/lib/x86_64-linux-gnu/weston/libexec_weston.so since weston is
linked to /usr/lib/x86_64-linux-gnu/weston/libexec_weston.so.0 which
should be shipped in the weston package.

Regards
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#970551: icingaweb2-module-reporting -- reporting functionality in the web frontend

2020-09-18 Thread David Kunz

Package: wnpp
Owner: david.k...@dknet.ch (only by sent from a diffrent mail-address)

* Package name: icingaweb2-module-reporting
  Upstream Author : Icinga Development Team
* License : GPL-2
  Description : Reporting functionality in the web frontend

  Icinga Web 2 is a modular, fast and simple web interface for
  your Icinga monitoring environment.
  .
  This package contains the central component for the reporting
  related functionality in the web frontend. It allows you to
  create reports over a specified time period for ad-hoc and
  scheduled generation of reports.


Greetings,
David

Bug#969781: RFP: libtoml-tiny-perl -- minimal, pure perl TOML parser and serializer

2020-09-18 Thread gregor herrmann

On Fri, 18 Sep 2020 04:21:06 +0200, Guillem Jover wrote:

> > libtoml-tiny-perl is in the NEW queue now.
> Perfect, thanks! BTW upstream fixed the dependency problem for which
> I included a patch, I think in a better way, and released a new
> version. :)

Thanks for the pointer, I'm updating the package as we speak :)
 
> Also, I guess you might not have removed me as maintainer out of
> courtesy? :) 

Exactly.

> If so, I think for now I'd prefer to not be listed, as
> I'm afraid I've got too much on my plate, although I would not mind
> lending a hand for specific issues or similar if needed!

Perfect, thanks for the offer, and I'm removing you from Uploaders
now.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Aimee Mann: Nothing is Good Enough


signature.asc
Description: Digital Signature

Bug#925561: xfce4-weather-plugin: API Outdated

2020-09-18 Thread Paul Stodghill

Agreed. My work around was to follow the instructions for creating 
"simple backports" (https://wiki.debian.org/SimpleBackportCreation) to 
make a backport of xfce4-weather-plugin/testing for my Buster machines.

The "proper" solution would be to get 0.10.1 into stable-updates.

On Fri, 04 Sep 2020 12:25:31 +0200 =?utf-8?q?Manolo_D=C3=ADaz?= 
 wrote:

> Package: xfce4-weather-plugin
> Version: 0.8.10-1
> Followup-For: Bug #925561
>
> Dear Maintainer,
>
> This bug now render the Buster version of this package completely 
unusable.

>
> Best regards,
> --
> Manolo Díaz

Bug#970550: diaspora installation fails with ExecJS::ProgramError: TypeError: Cannot read property 'list' of undefined

2020-09-18 Thread Pirate Praveen


Package: diaspora
Version: 0.7.14.0-2
Severity: grave

Using packages from 
https://wiki.debian.org/Diaspora#Buster_Fasttrack.2Fpersonal_repo


(as rails 5 in not available in unstable/experimental) installation 
fails with


Bundle complete! 101 Gemfile dependencies, 223 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
Setting up secret_token...
Checking if the database is empty...
diaspora_production database is not empty, skipping database setup
Running migrations...
Precompiling assets...
rake aborted!
ExecJS::ProgramError: TypeError: Cannot read property 'list' of 
undefined

/usr/share/diaspora/app/assets/config/manifest.js:9
(execjs):150:23
(execjs):76:3
(execjs):77:2
(execjs):8643:14
(execjs):1:40
Object. ((execjs):1:58)
Module._compile (internal/modules/cjs/loader.js:778:30)
Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
Module.load (internal/modules/cjs/loader.js:653:32)
tryModuleLoad (internal/modules/cjs/loader.js:593:12)
/usr/share/rubygems-integration/all/gems/autoprefixer-rails-8.6.5/lib/autoprefixer-rails/processor.rb:153:in 
`runtime'
/usr/share/rubygems-integration/all/gems/autoprefixer-rails-8.6.5/lib/autoprefixer-rails/processor.rb:37:in 
`process'
/usr/share/rubygems-integration/all/gems/autoprefixer-rails-8.6.5/lib/autoprefixer-rails/sprockets.rb:20:in 
`run'
/usr/share/rubygems-integration/all/gems/autoprefixer-rails-8.6.5/lib/autoprefixer-rails/sprockets.rb:14:in 
`call'
/usr/share/rubygems-integration/all/gems/rake-13.0.1/exe/rake:27:in 
`'

Tasks: TOP => assets:precompile
(See full trace by running task with --trace)
dpkg: error processing package diaspora (--configure):
installed diaspora package post-installation script subprocess 
returned error exit status 1

Errors were encountered while processing:
diaspora
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#970547: Acknowledgement (caja: changes file modification time on ssh remote copy)

Apparently something has just changed, or I was just plain wrong: I
cannot reproduce the problem any more.  Please close this bug

-- 
Francesco Potortì (ricercatore)Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR  Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa Skype:  wnlabisti
(gate 20, 1st floor, room C71) Web:http://fly.isti.cnr.it

Bug#970548: Acknowledgement (nautilus: changes file modification time on ssh remote copy)

Apparently something has just changed, or I was just plain wrong: I
cannot reproduce the problem any more.  Please close this bug

-- 
Francesco Potortì (ricercatore)Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR  Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa Skype:  wnlabisti
(gate 20, 1st floor, room C71) Web:http://fly.isti.cnr.it

Bug#970549: buster-pu: package libcommons-compress-java/1.18-2

2020-09-18 Thread Sudip Mukherjee

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: tmanc...@debian.org

Hi,

This is an update for CVE-2019-12402. The change is same as done for
libcommons-compress-java_1.18-3 at:
https://salsa.debian.org/java-team/libcommons-compress-java/-/commit/b0f86e2643f1edde31f42a8245224b618030c6aa

Its a no-dsa so needs to be fixed via stable update.


--
Regards
Sudip
diff -Nru libcommons-compress-java-1.18/debian/changelog 
libcommons-compress-java-1.18/debian/changelog
--- libcommons-compress-java-1.18/debian/changelog  2019-03-01 
22:27:13.0 +
+++ libcommons-compress-java-1.18/debian/changelog  2020-09-18 
12:47:06.0 +0100
@@ -1,3 +1,10 @@
+libcommons-compress-java (1.18-2+deb10u1) buster; urgency=medium
+
+  * Team upload.
+  * Add patch for CVE-2019-12402 (Closes: #939610)
+
+ -- Sudip Mukherjee   Fri, 18 Sep 2020 12:47:06 
+0100
+
 libcommons-compress-java (1.18-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
libcommons-compress-java-1.18/debian/patches/CVE-2019-12402-939610.patch 
libcommons-compress-java-1.18/debian/patches/CVE-2019-12402-939610.patch
--- libcommons-compress-java-1.18/debian/patches/CVE-2019-12402-939610.patch
1970-01-01 01:00:00.0 +0100
+++ libcommons-compress-java-1.18/debian/patches/CVE-2019-12402-939610.patch
2020-09-14 16:52:45.0 +0100
@@ -0,0 +1,127 @@
+Description: addresses CVE-2019-12402 (Debian: #939610)
+From: Stefan Bodewig 
+Date: Fri, 23 Aug 2019 14:12:05 + (+0200)
+Subject: unit tests for encoding logic
+X-Git-Tag: 1.19-RC1~6
+X-Git-Url: 
https://gitbox.apache.org/repos/asf?p=commons-compress.git;a=commitdiff_plain;h=4ad5d80a6272e007f64a6ac66829ca189a8093b9;hp=16a0c84e84b93cc8c107b7ff3080bd11317ab581
+
+unit tests for encoding logic
+---
+
+diff --git 
a/src/main/java/org/apache/commons/compress/archivers/zip/NioZipEncoding.java 
b/src/main/java/org/apache/commons/compress/archivers/zip/NioZipEncoding.java
+index 0a7581a..4ce9c20 100644
+--- 
a/src/main/java/org/apache/commons/compress/archivers/zip/NioZipEncoding.java
 
b/src/main/java/org/apache/commons/compress/archivers/zip/NioZipEncoding.java
+@@ -112,6 +112,9 @@ class NioZipEncoding implements ZipEncoding, 
CharsetAccessor {
+ } else if (res.isOverflow()) {
+ int increment = estimateIncrementalEncodingSize(enc, 
cb.remaining());
+ out = ZipEncodingHelper.growBufferBy(out, increment);
++
++} else if (res.isUnderflow() || res.isError()) {
++break;
+ }
+ }
+ // tell the encoder we are done
+diff --git 
a/src/test/java/org/apache/commons/compress/archivers/zip/NioZipEncodingTest.java
 
b/src/test/java/org/apache/commons/compress/archivers/zip/NioZipEncodingTest.java
+new file mode 100644
+index 000..a04730c
+--- /dev/null
 
b/src/test/java/org/apache/commons/compress/archivers/zip/NioZipEncodingTest.java
+@@ -0,0 +1,97 @@
++/*
++ * Licensed to the Apache Software Foundation (ASF) under one
++ * or more contributor license agreements.  See the NOTICE file
++ * distributed with this work for additional information
++ * regarding copyright ownership.  The ASF licenses this file
++ * to you under the Apache License, Version 2.0 (the
++ * "License"); you may not use this file except in compliance
++ * with the License.  You may obtain a copy of the License at
++ *
++ * http://www.apache.org/licenses/LICENSE-2.0
++ *
++ * Unless required by applicable law or agreed to in writing,
++ * software distributed under the License is distributed on an
++ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
++ * KIND, either express or implied.  See the License for the
++ * specific language governing permissions and limitations
++ * under the License.
++ */
++
++package org.apache.commons.compress.archivers.zip;
++
++import java.nio.ByteBuffer;
++import java.nio.charset.StandardCharsets;
++import java.util.Arrays;
++
++import org.junit.Assert;
++import org.junit.Test;
++
++public class NioZipEncodingTest {
++
++private static final String UMLAUTS = "\u00e4\u00f6\u00fc";
++
++@Test
++public void umlautToUTF16BE() {
++NioZipEncoding e = new NioZipEncoding(StandardCharsets.UTF_16BE, 
false);
++ByteBuffer bb = e.encode(UMLAUTS);
++final int off = bb.arrayOffset();
++byte[] result = Arrays.copyOfRange(bb.array(), off, off + bb.limit() 
- bb.position());
++Assert.assertArrayEquals(UMLAUTS.getBytes(StandardCharsets.UTF_16BE), 
result);
++}
++
++@Test
++public void umlautToUTF8() {
++NioZipEncoding e = new NioZipEncoding(StandardCharsets.UTF_8, true);
++ByteBuffer bb = e.encode("\u00e4\u00f6\u00fc");
++final int off = bb.arrayOffset();
++byte[] result = Arrays.copyOfRange(bb.array(), off, off + bb.limit() 
- bb.position());
++

Bug#970548: nautilus: changes file modification time on ssh remote copy

Package: nautilus
Version: 3.36.3-1
Severity: important
X-Debbugs-Cc: none, Francesco Potortì 

Whn copying a local file to a remote destination using ssh, file
modification times are not retained and set to the current time.

I marked this as "important" because it makes it almost unusable for
remote operation as far as I am concerned.

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

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

Versions of packages nautilus depends on:
ii  bubblewrap  0.4.1-1
ii  desktop-file-utils  0.26-1
ii  gsettings-desktop-schemas   3.36.1-1
ii  gvfs1.44.1-1+b1
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.31-3
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-5
ii  libgexiv2-2 0.12.1-1
ii  libglib2.0-02.66.0-2
ii  libglib2.0-data 2.66.0-2
ii  libgnome-autoar-0-0 0.2.4-2
ii  libgnome-desktop-3-19   3.36.4-1
ii  libgstreamer-plugins-base1.0-0  1.16.2-dmo3
ii  libgstreamer1.0-0   1.16.2-2
ii  libgtk-3-0  3.24.23-1
ii  libnautilus-extension1a 3.36.3-1
ii  libpango-1.0-0  1.46.1-1
ii  libpangocairo-1.0-0 1.46.1-1
ii  libselinux1 3.1-2
ii  libtracker-sparql-2.0-0 2.3.4-1+b1
ii  nautilus-data   3.36.3-1
ii  shared-mime-info1.15-1
ii  tracker 2.3.4-1+b1
ii  tracker-extract 2.3.3-2+b1
ii  tracker-miner-fs2.3.3-2+b1

Versions of packages nautilus recommends:
pn  gnome-sushi  
ii  gvfs-backends1.44.1-1+b1
ii  librsvg2-common  2.48.8+dfsg-1

Versions of packages nautilus suggests:
ii  atril [pdf-viewer] 1.24.0-1
pn  eog
ii  evince [pdf-viewer]3.36.7-1
ii  gv [pdf-viewer]1:3.7.4-2+b1
pn  nautilus-extension-brasero 
pn  nautilus-sendto
ii  okular [pdf-viewer]4:20.08.1-1
ii  opencubicplayer [mp3-decoder]  1:0.2.2+ds-1+b1
ii  qpdfview [pdf-viewer]  0.4.18-1+b1
ii  totem  3.34.1-2+b1
ii  xdg-user-dirs  0.17-2
ii  xpdf [pdf-viewer]  3.04-13

-- no debconf information

Bug#970547: caja: changes file modification time on ssh remote copy

Package: caja
Version: 1.24.0-1
Severity: important
X-Debbugs-Cc: none, Francesco Potortì 

Whn copying a local file to a remote destination using ssh, file
modification times are not retained and set to the current time.

I marked this as "important" because it makes it almost unusable for
remote operation as far as I am concerned.

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

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

Versions of packages caja depends on:
ii  caja-common   1.24.0-1
ii  desktop-file-utils0.26-1
ii  gvfs  1.44.1-1+b1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.31-3
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libcaja-extension11.24.0-1
ii  libexempi82.5.2-1
ii  libexif12 0.6.22-2
ii  libgail-3-0   3.24.23-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-5
ii  libglib2.0-0  2.66.0-2
ii  libglib2.0-bin2.66.0-2
ii  libglib2.0-data   2.66.0-2
ii  libgtk-3-03.24.23-1
ii  libice6   2:1.0.9-2
ii  libmate-desktop-2-17  1.24.1-1
ii  libnotify40.7.9-1
ii  libpango-1.0-01.46.1-1
ii  libpangocairo-1.0-0   1.46.1-1
ii  libselinux1   3.1-2
ii  libsm62:1.2.3-1
ii  libx11-6  2:1.6.10-3
ii  libxml2   2.9.10+dfsg-6
ii  mate-desktop  1.24.1-1
ii  shared-mime-info  1.15-1

Versions of packages caja recommends:
ii  gvfs-backends  1.44.1-1+b1

Versions of packages caja suggests:
ii  engrampa1.24.1-1
ii  gstreamer1.0-tools  1.16.2-2
ii  meld3.20.2-2

-- no debconf information

Bug#970503: linux-image-5.8.0-1-amd64: using swap makes the machine hang

2020-09-18 Thread Vincent Lefevre

On 2020-09-18 10:23:01 +0200, Vincent Lefevre wrote:
> https://github.com/openzfs/zfs/issues/8552 suggests a drive firmware
> bug (which could explain the absence of errors with smartctl and
> badblocks), but in this case the kernel might have a way to avoid it.
> 
> Also I'm wondering why this issue occurs *only* with swap. This could
> mean that the problem is on the kernel side (at least partly).

As suggested by the above URL and also by
http://www.howtoeverything.net/linux/hardware/ubuntu-freeze-issue-after-ssd-upgrade
(which also mentions freeze issues with swap) I've set
libata.force=noncq, which made the error disappear. The error
no longer occurs after reboot without this kernel parameter.

Still wondering whether this is a general issue with SSD and
something can be done in the kernel.

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

Bug#970546: RFP: golang-github-cli-cli -- GitHub’s official command line tool

2020-09-18 Thread Vipul

Package: wnpp
Severity: wishlist

* Package name: golang-github-cli-cli
  Version : 1.0.0
  Upstream Author : Github 
* URL : https://cli.github.com/
* License : MIT License
  Programming Lang: Go
  Description : GitHub’s official command line tool

Github CLI brings Github to terminal. It reduces context switching,
helps focus and create own workflows. With lastest stable version of
Github CLI 1.0, we can:
- Run entire Github workflow from terminal from issues to releases
- Call the Github APIs to script any action
- Set custom aliases, etc...

See Github's blog post on Github CLI 1.0 release[1] for more
information.

[1]: https://github.blog/2020-09-17-github-cli-1-0-is-now-available/

Bug#970545: dpkg FTBFS: KEY_EVENT undeclared

2020-09-18 Thread Helmut Grohne

Source: dpkg
Version: 1.20.5
Severity: serious
Tags: ftbfs

dpkg FTBFS as of today:

| g++ -DHAVE_CONFIG_H   -DLOCALEDIR=\"/usr/share/locale\" 
-DADMINDIR=\"/var/lib/dpkg\" -DLIBDIR=\"/usr/lib/dpkg\" 
-DLOCALLIBDIR=\"/usr/local/lib/dpkg\" -idirafter ../../lib/compat -iquote . 
-I.. -I../../lib -Wdate-time -D_FORTIFY_SOURCE=2 -fno-rtti -fno-exceptions  
-Wall -Wextra -Wcast-align -Wduplicated-branches -Wduplicated-cond -Wformat 
-Wformat-security -Wformat=2 -Winit-self -Wlogical-not-parentheses -Wlogical-op 
-Wmissing-declarations -Wmissing-format-attribute 
-Wno-missing-field-initializers -Wno-nonnull-compare -Wno-unused-parameter 
-Wnull-dereference -Wpointer-arith -Wredundant-decls -Wregister -Wrestrict 
-Wshadow -Wshift-negative-value -Wsizeof-array-argument -Wswitch-bool -Wvla 
-Wwrite-strings -Wc++11-compat -Wcast-qual -Wold-style-cast 
-Wzero-as-null-pointer-constant -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wextra 
-Wno-missing-field-initializers -Wno-nonnull-compare -Wno-unused-parameter  -MT 
curkeys.o -MD -MP -MF .deps/curkeys.Tpo -c -o curkeys.o ../../dselect/curkeys.cc
| mv -f .deps/pkgdisplay.Tpo .deps/pkgdisplay.Po
| mv -f .deps/pkginfo.Tpo .deps/pkginfo.Po
| mv -f .deps/pkgcmds.Tpo .deps/pkgcmds.Po
| In file included from ../../dselect/curkeys.cc:30:
| ./curkeys.h:168:5: error: ‘KEY_EVENT’ was not declared in this scope; did you 
mean ‘KEY_OPEN’?
|   168 |   { KEY_EVENT,  "Event"   },
|   | ^
|   | KEY_OPEN
| make[4]: *** [Makefile:617: curkeys.o] Error 1
| make[4]: *** Waiting for unfinished jobs
| mv -f .deps/pkgdepcon.Tpo .deps/pkgdepcon.Po
| mv -f .deps/pkgsublist.Tpo .deps/pkgsublist.Po
| mv -f .deps/pkgtop.Tpo .deps/pkgtop.Po
| mv -f .deps/pkglist.Tpo .deps/pkglist.Po
| make[4]: Leaving directory '/<>/build-tree/dselect'
| make[3]: *** [Makefile:650: all-recursive] Error 1
| make[3]: Leaving directory '/<>/build-tree/dselect'
| make[2]: *** [Makefile:743: all-recursive] Error 1
| make[2]: Leaving directory '/<>/build-tree'
| make[1]: *** [Makefile:609: all] Error 2
| make[1]: Leaving directory '/<>/build-tree'
| make: *** [debian/rules:74: build] Error 2
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

I suppose this is connected to a ncurses upload.

Helmut

Bug#970544: civitweb FTBFS almost everywhere: hard coded install path

2020-09-18 Thread Helmut Grohne

Source: civetweb
Version: 1.12+dfsg-2
Severity: important
Tags: ftbfs patch

Hi Andreas,

civetweb FTBFS everywhere but amd64, because one of its arch-dependent
paths is hard coded in an .install file. I suppose that the attached
patch fixes that. Didn't lintian complain loudly about this? I think
this is a mistake that really shouldn't happen given our tooling.

Helmut
diff --minimal -Nru civetweb-1.12+dfsg/debian/changelog 
civetweb-1.12+dfsg/debian/changelog
--- civetweb-1.12+dfsg/debian/changelog 2020-09-17 09:27:48.0 +0200
+++ civetweb-1.12+dfsg/debian/changelog 2020-09-18 12:53:05.0 +0200
@@ -1,3 +1,10 @@
+civetweb (1.12+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't use arch-dependent paths in *.install files. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 18 Sep 2020 12:53:05 +0200
+
 civetweb (1.12+dfsg-2) unstable; urgency=medium
 
   * Source-only upload
diff --minimal -Nru civetweb-1.12+dfsg/debian/libcivetweb-dev.install 
civetweb-1.12+dfsg/debian/libcivetweb-dev.install
--- civetweb-1.12+dfsg/debian/libcivetweb-dev.install   2020-09-17 
09:27:48.0 +0200
+++ civetweb-1.12+dfsg/debian/libcivetweb-dev.install   2020-09-18 
12:52:55.0 +0200
@@ -1,3 +1,3 @@
 usr/lib/*/libcivetweb.so
 usr/include
-usr/lib/x86_64-linux-gnu/cmake
+usr/lib/*/cmake

Bug#966951: libpeas: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test returned exit code 1

2020-09-18 Thread Simon McVittie

Control: clone -1 -2
Control: retitle -1 libpeas: FTBFS with Meson >= 0.55.0: Typelib file for 
namespace 'Introspection', version '1.0' not found
Control: reassign -1 libpeas 1.26.0-2
Control: tags -1 = ftbfs pending
Control: severity -2 normal
Control: retitle -2 meson: gnome module stopped generating uninstalled typelib 
depended on by an executable
Control: reassign -2 meson 0.55.0-2
Control: forwarded -2 https://github.com/mesonbuild/meson/issues/7756
Control: tags -2 = upstream

On Mon, 03 Aug 2020 at 13:09:55 +0100, Simon McVittie wrote:
> I've confirmed that this succeeds in a pure bullseye chroot and fails if
> I upgrade meson (only) to the version from unstable. I'm not completely
> sure whether this is a straightforward regression in meson, or whether
> libpeas is holding it wrong.

I'm still not sure whose bug this is, but I've found a workaround that
libpeas can use (or a fix that can be applied, depending whether this
is considered to be a bug in Meson or in libpeas).

I'll close the original FTBFS report by fixing or working around this in
libpeas; I'm cloning it as a non-RC Meson bug report for investigation
of whether Meson is doing the wrong thing.

Please see the upstream Meson bug for more details and a somewhat
minimal reproducer.

Thanks,
smcv

Bug#968991: jlink error: Hash of jdk.management.jfr differs to expected hash

tags 968991 patch
thanks

On Thu, Sep 17, 2020 at 08:34:55PM +0100, Julian Gilbey wrote:
> On Tue, Aug 25, 2020 at 02:40:43PM +0100, Julian Gilbey wrote:
> > [...]
> > output (where I have replace the path with QUPATHDIR); the failure
> > appears to have happened in the jlink command, which gives the error
> > message:
> > 
> > Error: Hash of jdk.management.jfr 
> > (fe13cbaad9132f3aafe8db1febd951ded02ac6f6371c0b1b14fc4fc561ce3b70) differs 
> > to expected hash 
> > (8f4b914f856e98e19ec589e7c679b7ce7774a3985aa3c0ec79e5f831e0c3eec1) recorded 
> > in java.base
> 
> It turns out that this bug is identical to the problem reported
> against openjdk-11-jdk in https://bugs.debian.org/944738
> 
> Any help with this old bug would be much appreciated!
> 
>Julian

And I have located and found a patch for this bug.  See the patch
submitted to https://bugs.debian.org/944738

Best wishes,

   Julian

Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

On Fri, Sep 18, 2020 at 11:15:14AM +0100, Julian Gilbey wrote:
> I have located the source of the bug and have a patch to fix it.
> 
> The cause is the use of dh_strip_nondeterminism late in the build
> process.  This reorganises the jmod files, which in turn changes their
> SHA256 checksums.  This would not be a problem, except that the
> checksums are saved in java.base.jmod *before* the use of
> dh_strip_nondeterminism.  Performing this stripping immediately after
> each jmod file is created results in the checksums being consistent
> throughout.
> 
> To do this:
> 
> * add the attached patch to debian/patches (and to the quilt patch
>   series); this calls strip-nondeterminism whenever a jmod file is
>   created

Duh, I forgot to attach the patch.  Attached this time!

Best wishes,

   Julian
--- a/make/CreateJmods.gmk
+++ b/make/CreateJmods.gmk
@@ -228,7 +228,7 @@
 --target-platform '$(OPENJDK_MODULE_TARGET_PLATFORM)' \
 --module-path $(JMODS_DIR) $(JMOD_FLAGS) \
 $(JMODS_SUPPORT_DIR)/$(JMOD_FILE), \
-POST_COMMAND := $(MV) $(JMODS_SUPPORT_DIR)/$(JMOD_FILE) $(JMODS_DIR)/$(JMOD_FILE), \
+POST_COMMAND := strip-nondeterminism $(JMODS_SUPPORT_DIR)/$(JMOD_FILE) && $(MV) $(JMODS_SUPPORT_DIR)/$(JMOD_FILE) $(JMODS_DIR)/$(JMOD_FILE), \
 ))
 
 TARGETS += $(create_$(JMOD_FILE))

Bug#970500: [Pkg-utopia-maintainers] Bug#970500: network-manager does not start at boot

2020-09-18 Thread Ansgar

On Thu, 2020-09-17 at 14:32 +0200, Hans wrote:
> OK, I have rechecked my configurations. It appears, that network-manager is 
> started, when I do a "systemctl enable NetworkManager". However, still /etc/
> init.d/network-manager is missing. Dunno, if this is still needed.

systemd uses /lib/systemd/system/NetworkManager.service to start
NetworkManager; the init script isn't used by systemd.

> When I am running plasma, then nm-applet gets access to the network-manager 
> service, but when I start LXDE, I get the message, that the network-manger-
> service is not running. So it looks for me, like a rights problem.
> 
> When I do start nm-applet as root in LXDE, then I get access to the network-
> manager-service, but when I do the same as a normal user, access is forbidden 
> (something dbus and so).

Hmm, I don't maintain network-manager and am not quite sure, but for
permission issues I would guess that PolicyKit is configured to allow
access only to logged in users, but the system thinks you are not
logged in.  Maybe check with `loginctl` for an active session?

Do you use the same way to start Plasma and LXDE, i.e. the same display
manager (sddm, lightdm, gdm), or is there a difference?

> I would not have changed to nemtwork-manager, because I was happy with wicd, 
> but as wicd was removed from the repo, I chose the alternative.

wicd was removed from testing/unstable as part of the Python2 removal,
but there is a version in experimental that uses Python 3.  You could
try to install that or wait until it gets uploaded to unstable.

Ansgar

Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

tags 944738 patch
thanks

On Thu, Sep 17, 2020 at 06:45:39PM +0100, Julian Gilbey wrote:
> affects 944738 openjdk-14-jdk
> thanks
> 
> The same problem is still present in openjdk-14 - see
> https://bugs.debian.org/968991

I have located the source of the bug and have a patch to fix it.

The cause is the use of dh_strip_nondeterminism late in the build
process.  This reorganises the jmod files, which in turn changes their
SHA256 checksums.  This would not be a problem, except that the
checksums are saved in java.base.jmod *before* the use of
dh_strip_nondeterminism.  Performing this stripping immediately after
each jmod file is created results in the checksums being consistent
throughout.

To do this:

* add the attached patch to debian/patches (and to the quilt patch
  series); this calls strip-nondeterminism whenever a jmod file is
  created

* add the strip-nondeterminism package as a Build-Depends

* optionally add "-Xjmods" to the dh_strip_nondeterminism call on line
  1781 (or thereabouts) of debian/rules (within the binary-arch
  target) - this is optional, because applying strip-nondeterminism a
  second time should not change anything.

Of course, to make the patch more generally applicable, one could add
a check for strip-nondeterminism into the configure script, etc., but
for a debian-specific build, that does not seem to be necessary.

Incidentally, the check for the existence of dh_strip_nondeterminism
in debian/rules is unnecessary, as debhelper Depends on
dh-strip-nondeterminism, and has done since version 9.20151004.

Best wishes,

   Julian

Bug#970539: CVE-2020-25084

Package: qemu
Severity: important

Please see https://www.openwall.com/lists/oss-security/2020/09/16/5

https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg08050.html
https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg08043.html

Cheers,
Moritz

Bug#970540: CVE-2020-25085

Package: qemu
Severity: important

Please see https://www.openwall.com/lists/oss-security/2020/09/16/6:

https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg00733.html
https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg01439.html

Cheers,
Moritz

Bug#970542: CVE-2020-25625

Package: qemu
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

Please see https://www.openwall.com/lists/oss-security/2020/09/17/1

https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg05905.html

Cheers,
Moritz

Bug#970541: CVE-2020-25624