Bug#877297: [Debian-lego-team] Bug#877297: libnxt: usb:v03EBp* too inclusive, leads to false positive matches

[Nicolas Schodet]

* Petter Reinholdtsen  [2021-09-30 10:49]:
> [Nicolas Schodet]
> > I think so, could you check you have the same product id on your NXT?
> I guess, but am not quite sure how to check.  Do you have a recipe?

I think there is no need to check, the product ID is included verbatim
in the libnxt code source:

  { 0x03EB, 0x6124 }, /* SAM-BA */

> >> Alternative, perhaps that USB ID should not be listed in the appstream
> >> metainfo file?  I suspect I got the ID from one of the udev entries in
> >> one of the other lego related packages:
> > What are the consequences when several packages use the same
> > identifier?
> The appstream information is used to present package information to
> those that are looking for what to install, typically in graphical
> software helpers.  The only user of the hardware information that I am
> aware of, is the isenkram system I wrote, which will trigger every time
> it see some new hardware inserted into the machine, look up packages
> claiming support for this hardware and pop up a prompt suggesting to
> install these packages.  It can also look up already present hardware
> and identify firmware packages requested by the kernel.
> So if several packages use the same identifier, several packages will be
> proposed to the user.
> > I do not think there will be many SAM-BA in the wild, unless you are
> > working with a SAM91 dev board. What would be the consequence for
> > someone working with such a board?
> The consequence is that isenkram will propose to install lego related
> packages for this bord, which will confuse the user and not really help
> them in any way.

I think your patch is OK, a developer working on a (old) microcontroller
will not be too confused by a prompt to install libnxt in my opinion.

Nicolas.

Bug#994829: buster-pu: package node-prismjs/1.11.0+dfsg-3+deb10u1

[Yadd]

Control: tags -1 - moreinfo

Le 30/09/2021 à 21:33, Adam D. Barratt a écrit :
> Control: tags -1 + moreinfo
> 
> On Tue, 2021-09-21 at 14:56 +0200, Yadd wrote:
>> node-prismjs is vulnerable to a Regex Denial of Service (ReDoS)
>> (CVE-2021-40438)
>>
> 
> As with the bullseye request, that appears to be the wrong CVE number.
> 
> Regards,
> 
> Adam

Fixed and pushed, thanks!

Bug#995267: devhelp doesn't load the selected content

[crvi c]

Clearing ~/.local/share/mime seems to fix the issue.

Thanks!

On Wed, 29 Sept 2021 at 20:34, crvi c  wrote:

> Created a new user and devhelp works. So, I'm not sure what is stopping it
> from working for my current user.
>
> Results are the same across Xorg/Wayland.
>

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

[Ryan Thoryk]

After installing a debug version of glibmm, I've attached the related 
backtrace showing the glibmm code lines.  The "binding.cc" is the 
glib/glibmm/binding.cc file.  The old (working) version doesn't appear 
to use the related g_quark_from_static_string() function that crashes.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

#0  __strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
#1  0x7f0771e943b9 in g_str_equal () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f0771e92e03 in g_hash_table_lookup () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f0771eb5c8a in g_quark_from_static_string () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f0771e0ead0 in __static_initialization_and_destruction_0 
(__priority=65535, __initialize_p=1)
at binding.cc:32
#5  _GLOBAL__sub_I_binding.cc(void) () at binding.cc:370
#6  0x7f0773b0610e in call_init (l=, argc=argc@entry=3, 
argv=argv@entry=0x7ffdbb8e0208, 
env=env@entry=0x7ffdbb8e0228) at dl-init.c:74

Bug#994971: closed by Debian FTP Masters (reply to Andreas Beckmann ) (Bug#994971: fixed in nvidia-graphics-drivers 470.63.01-1)

[Pascal Obry]

Hello !

Just installed 470.63.01-1 this morning and I can confirm that the
issue is fixed. I have OpenCL activated without any other action.

Thanks a lot for the quick resolution.

Have a nice day,


-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B


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

Bug#995216: simple-scan: B&W Text scans saved as gibberish

[Felix Lechner]

Hi,

On Tue, Sep 28, 2021 at 2:49 AM Jörg Frings-Fürst  wrote:
>
> First of all, I set the severity to normal, because there is no data
> loss in the sense of grave, but only an erroneous output.

Well, I am trying to read over a month's worth of scanned personal and
business documents. I may have lost access to the data—except for LO
Draw, apparently—due to this bug. Maybe it's not a bug in simple-scan,
but something mangled the image data. The hard copies are shredded.

Other users may also have issues and not realize it, either.

>  - What was the occupancy of the mouted partitions?

Here is an overview of my mounted partitions:

Filesystem Size  Used Avail Use% Mounted on
udev13G 0   13G   0% /dev
tmpfs  2.6G  1.8M  2.6G   1% /run
/dev/mapper/optivg-stable   41G   27G   12G  70% /
tmpfs   13G   92M   13G   1% /dev/shm
tmpfs  5.0M  4.0K  5.0M   1% /run/lock
/dev/mapper/optivg-nodeb   4.8G  4.2G  405M  92% /nodeb
/dev/mapper/optivg-fscache 4.9G  4.2G  480M  90%
/var/cache/fscache
/dev/mapper/optivg-home.local   25G   14G  9.8G  59% /lcl
/dev/sda127500M  5.2M  494M   2% /boot/efi
/dev/mapper/optivg-tmp 197G   62M  188G   1% /tmp
/dev/mapper/optivg-schroot.unstable.amd64  4.9G  1.3G  3.4G  27%
/var/lib/schroot/union/underlay/unstable-amd64-e469dd9d-9737-4e57-96e7-fe321d53cc2f
unstable-amd64  41G   27G   12G  70%
/run/schroot/mount/unstable-amd64-e469dd9d-9737-4e57-96e7-fe321d53cc2f
tmpfs   13G 0   13G   0%
/run/schroot/mount/unstable-amd64-e469dd9d-9737-4e57-96e7-fe321d53cc2f/dev/shm
wallace-server:/mirror 1.5T  618G  828G  43% /mirror
wallace-server:/acct   1.5T  1.3T  266G  83% /acct
tmpfs  2.6G   68K  2.6G   1% /run/user/0
tmpfs  2.6G   28M  2.6G   2% /run/user/1000

>  - How big was the logfile (~/.cache/simple-scan/simple-scan.log)?

For another scan job that was likewise garbled (my son's homework) the
size was about 2 MB.

>  - What was recorded in the logfile at the time of the error?

I believe reportbug forwarded a copy but a compressed version, which
is much smaller, is also attached to this message.

>  - Does the error still occur after a reboot?

Yes, after each of at least two reboots.

Meanwhile I also installed simple-scan and Evince from unstable on my
otherwise bullseye machine (with backports) but the symptoms are the
same. Perhaps it is worthwhile to point out that I am using Sway, and
not Gnome.

> And so that I have all system information can you please start once:
>
>   bugreport -N 995216

You probably meant reportbug. I do not use it much but it worked very
well, especially with the custom data collection.

I use your tool almost every day. Thanks for looking into this issue!

Kind regards
Felix Lechner


simple-scan.log.xz
Description: application/xz

Bug#995370: pidgin: segmentation fault on malloc/free

[Richard Laager]

On 9/30/21 7:16 AM, Vaclav Ovsik wrote:

after ugprade of pidgin:amd64 to 2.14.7-1 from 2.14.1-1+b1


Are you in any position to bisect this by building the intermediate 
2.14.x versions of Pidgin?


--
Richard

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

[Ryan Thoryk]

I tried force-downgrading the libglibmm package to the Debian Bullseye 
version (2.66 back to 2.64), the crash goes away, and my audio hardware 
works again with Jack.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#995428: openuniverse FTCBFS: secondary ./configure invocation does not pass --host

[Helmut Grohne]

Source: openuniverse
Version: 1.0beta3.1+dfsg-7
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Thank you for applying my previous cross build patch. Unfortunately, it
fails again. This time, ./configure is invoked twice. Once via
dh_auto_configure and another time explicitly via
override_dh_auto_build. This secondary invocation lacks the relevant
--host flag. The easiest way of adding it is using dh_auto_configure.
Please consider applying the attached patch.

Helmut
diff -u openuniverse-1.0beta3.1+dfsg/debian/changelog 
openuniverse-1.0beta3.1+dfsg/debian/changelog
--- openuniverse-1.0beta3.1+dfsg/debian/changelog
+++ openuniverse-1.0beta3.1+dfsg/debian/changelog
@@ -1,3 +1,10 @@
+openuniverse (1.0beta3.1+dfsg-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to configure. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 01 Oct 2021 06:22:35 +0200
+
 openuniverse (1.0beta3.1+dfsg-7) unstable; urgency=medium
 
   * Apply patch provided by Helmut Grohne which fixes FTCBFS: Export
diff -u openuniverse-1.0beta3.1+dfsg/debian/rules 
openuniverse-1.0beta3.1+dfsg/debian/rules
--- openuniverse-1.0beta3.1+dfsg/debian/rules
+++ openuniverse-1.0beta3.1+dfsg/debian/rules
@@ -34,9 +34,8 @@
 build-stamp:
dh_testdir
 
-override_dh_auto_build:
-   CXXFLAGS="$(CXXFLAGS) -I/usr/include/plib/" LIBS="-lplibfnt -lplibul 
-lglut" ./configure --prefix= --exec_prefix=/usr 
--mandir=\$${exec_prefix}/share/man --infodir=\$${exec_prefix}/share/info 
--sysconfdir=\$${prefix}/etc/ --includedir=\$${exec_prefix}/include 
--datadir=\$${exec_prefix}/share
-   $(MAKE)
+override_dh_auto_configure:
+   CXXFLAGS="$(CXXFLAGS) -I/usr/include/plib/" LIBS="-lplibfnt -lplibul 
-lglut" dh_auto_configure -- --prefix= --exec_prefix=/usr 
--mandir=\$${exec_prefix}/share/man --infodir=\$${exec_prefix}/share/info 
--sysconfdir=\$${prefix}/etc/ --includedir=\$${exec_prefix}/include 
--datadir=\$${exec_prefix}/share
 
 override_dh_fixperms-arch:
dh_fixperms

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

[Ryan Thoryk]

I wanted to chime in on this bug, since I'm getting basically the same 
issue.  I'm running Debian Testing.


My situation is a little different, because I'm using an M-Audio 
firewire device with Jack2 on a VIA VT6315 card, and so I need the 
firewire module.  I recently swapped out the firewire card but couldn't 
get the audio device to work, since Jack kept segfaulting on startup. 
Tonight I booted a Debian 11 live cd, and the device and Jack work 
flawlessly on it.  The device has trouble working with ALSA, so I use 
the FFADO system instead.


This is what it looks like when running:

ryan@andromeda:~$ jackd -d firewire
jackdmp 1.9.19
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2021 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
Segmentation fault (core dumped)


I downloaded the Jack source code and did some GDB debugging, and found 
that it's segfaulting when doing a dlopen() on the jack_firewire.so 
module.  Jack appears to run fine with the ALSA module instead, but not 
firewire.


I attached the backtrace from GDB.  I had been going over my system's 
linker configuration to see if there was something wrong, and then I 
found this bug report.  Since glib is crashing during a string 
comparison, the culprit appears to be the glibmm frontend's constructor. 
 I didn't set up an environment to debug glibmm yet, but let me know if 
there's something you'd like me to try out.  I was wanting to find out 
details on that string comparison.  You might be able to reproduce it if 
you try to use the firewire device module like I did.


This is the output when running Valgrind on Jack:

==8689==
==8689== Process terminating with default action of signal 11 (SIGSEGV): 
dumping core

==8689==  Bad permissions for mapped region at address 0x6594034
==8689==at 0x4D09370: __strcmp_sse2_unaligned 
(strcmp-sse2-unaligned.S:24)
==8689==by 0x6800F58: g_str_equal (in 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0)
==8689==by 0x67FF9E1: g_hash_table_lookup (in 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0)
==8689==by 0x6822C99: g_quark_from_static_string (in 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0)
==8689==by 0x6938BAF: ??? (in 
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1.3.0)

==8689==by 0x401010D: call_init.part.0 (dl-init.c:74)
==8689==by 0x40101EF: call_init (dl-init.c:37)
==8689==by 0x40101EF: _dl_init (dl-init.c:121)
==8689==by 0x4DAAB6C: _dl_catch_exception (dl-error-skeleton.c:182)
==8689==by 0x4014483: dl_open_worker (dl-open.c:783)
==8689==by 0x4DAAB0F: _dl_catch_exception (dl-error-skeleton.c:208)
==8689==by 0x4013D09: _dl_open (dl-open.c:864)
==8689==by 0x5025257: dlopen_doit (dlopen.c:66)

--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net
#0  __strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
#1  0x7f7abc466f59 in g_str_equal () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f7abc4659e2 in g_hash_table_lookup () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f7abc488c9a in g_quark_from_static_string () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f7abc3dbbb0 in  () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#5  0x7f7abe0df10e in call_init
(l=, argc=argc@entry=3, argv=argv@entry=0x7ffca09e2288, 
env=env@entry=0x7ffca09e22a8) at dl-init.c:74
#6  0x7f7abe0df1f0 in call_init (env=0x7ffca09e22a8, argv=0x7ffca09e2288, 
argc=3, l=) at dl-init.c:37
#7  _dl_init (main_map=0x55dd66345d90, argc=3, argv=0x7ffca09e2288, 
env=0x7ffca09e22a8) at dl-init.c:121
#8  0x7f7abdc19b6d in __GI__dl_catch_exception
(exception=exception@entry=0x0, operate=operate@entry=0x7f7abe0e2a00 
, args=args@entry=0x7ffca09e1800)
at dl-error-skeleton.c:182
#9  0x7f7abe0e3484 in dl_open_worker (a=a@entry=0x7ffca09e19a0) at 
dl-open.c:783
#10 0x7f7abdc19b10 in __GI__dl_catch_exception
(exception=exception@entry=0x7ffca09e1980, 
operate=operate@entry=0x7f7abe0e30e0 , 
args=args@entry=0x7ffca09e19a0) at dl-error-skeleton.c:208
#11 0x7f7abe0e2d0a in _dl_open
(file=0x7ffca09e1980 "", mode=-2147483390, caller_dlopen=0x7f7abe038bee 
, nsid=-2, argc=3, 
argv=0x7ffca09e2288, env=0x7ffca09e22a8)
at dl-open.c:864
#12 0x7f7abd8ef258 in dlopen_doit (a=a@entry=0x7ffca09e1bd0) at dlopen.c:66
#13 0x7f7abdc19b10 in __GI__dl_catch_exception
(exception=exception@entry=0x7ffca09e1b70, 
operate=operate@entry=0x7f7abd8ef200 , 
args=args@entry=0x7ffca09e1bd0) at dl-error-skeleton.c:208
#14 0x7f7abdc19bcf in __GI__dl_catch_error
(objname=objname@entry=0x55dd662d70b0, 
e

Bug#994828: bullseye-pu: package node-prismjs/1.23.0+dfsg-1+deb11u1

[Yadd]

Control: tags -1 - moreinfo

Le 30/09/2021 à 20:58, Adam D. Barratt a écrit :
> Control: tags -1 + moreinfo
> 
> On Tue, 2021-09-21 at 14:49 +0200, Yadd wrote:
>> node-prismjs is vulnerable to a Regex Denial of Service (ReDoS)
>> (CVE-2021-40438)
>>
> 
> According to the Security Tracker, that's an Apache mod-proxy issue.
> 
> Regards,
> 
> Adam

Fixed and pushed, thanks!

Bug#995341: release.debian.org: Xen dom0 does not power off on bullseye (stable)

[Chuck Zmudzinski]

On 9/29/2021 7:26 PM, Chuck Zmudzinski wrote:


Ordinarily, as I understand the process, a bug in the
stable version is first fixed in the unstable release
and then the fix is migrated (backported) to the
stable release. But it appears to me a fix in the
unstable release will not be forthcoming soon, or
it might be a different bug (see #991967, affecting the
unstable release, sid, for more details).


Another way to look at this unusual situation:

At the present time the Xen packages targeting
the unstable version are identical to the
Xen packages targeting the stable version. In other
words, either the stable version is not really stable
or the unstable version is actually stable. I argue it
is the former and somewhere along the line the
process for migrating a stable version of Xen into
bullseye broke. I have identified when the process
broke. It was when patches from unstable upstream
Xen 4.16 were migrated to bullseye even though
the upstream version of Xen for both stable and
unstable was stable upstream Xen 4.14. In other words,
the current Debian version of Xen targeting the
stable distribution is actually an unstable version
of Debian Xen that is a mixture of mostly stable Xen 4.14
and nine unstable patches from upstream
Xen 4.16. This is causing instabilities and bugs such as
#994899 and #991967 on amd64 and also likely i386.
This upload to stable fixes this by removing the instabilities
on amd64 and i386 without removing the good work
done by the Debian Xen Team improving support
for arm devices. So it is a win-win to accept this upload
to stable.

Going forward, work on Debian's unstable version
of Xen can continue with investigating and fixing
#991967 and eventually updating to a newer upstream
version, which will probably be at least Xen 4.16 which
in my tests already show that #994899 is fixed upstream
in Xen 4.16, as discussed here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899#5

To quote (with corrections and clarifications) from the
aforementioned message:

I also tested the current unstable (master) branch
from Xen upstream, which is xen-c76cfad, which
(upstream) calls Xen-4.16-unstable. I tested
the current bullseye kernel (5.10.46-4) as a
dom0 on that upstream Xen-4.16 hypervisor
and did not see the bug, so this most definitely
is NOT an upstream bug.

So far all practical purposes, #994899 *is* fixed upstream
in upstream's unstable version Xen 4.16. So we should be
free to patch it in stable now.

Chuck

Bug#265211:

[DILIP CHAUDHARI]

Bug#995349: ncbi-entrez-direct: FTBFS: no required module provides package github.com/fiam/gounidecode/unidecode

[Aaron M. Ucko]

Steve Langasek  writes:

> rchive.go:40:2: no required module provides package 
> github.com/fiam/gounidecode/unidecode: go.mod file not found in current 
> directory or any parent directory; see 'go help modules'
[etc.]

Thanks for the report!  AFAICT, my approach to go.mod and go.sum (moving
both aside) ran afoul of https://go.dev/blog/go116-module-changes, and
the "GO111MODULE=off" workaround noted there won't work for Impish
(which rmadison tells me already has 1.17) or likely long for Debian.

I have some thoughts about how to craft a proper fix, and will look into
doing so when I get a chance.

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

Bug#995427: RFA: mrtg -- multi router traffic grapher

[Sandro Tosi]

Package: wnpp
Severity: normal
X-Debbugs-Cc: mo...@debian.org
Control: affects -1 src:mrtg

I request an adopter for the mrtg package.

I no longer use mrtg and there are better solutions out there (grafana +
prometheus)

Repo is already in the shared Salsa namespace at:
https://salsa.debian.org/debian/mrtg

The package description is:
 The Multi Router Traffic Grapher is a tool primarily used to monitor the
 traffic load on network links (typically by using SNMP). MRTG generates HTML
 pages containing PNG images which provide a LIVE visual representation of this
 traffic. MRTG typically produces daily, weekly, monthly, and yearly graphs.
 .
 In addition to monitoring via SNMP, MRTG can also generate graphs based on
 the output of any application, allowing one to generate graphs of anything
 that needs monitoring (for example, CPU and memory usage, email volumes, web
 hits, etc). For faster data collection, MRTG can also interface to RRDtool.
 .
 The mrtg-contrib package contains the contributed scripts and configuration
 files that used to form part of the mrtg package.

Bug#995426: ITP: textual -- TUI (Text User Interface) framework for Python inspired by modern web development

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 
X-Debbugs-Cc: debian-de...@lists.debian.org, mo...@debian.org

* Package name: textual
  Version : 0.1.11
  Upstream Author : Will McGugan
* URL : https://github.com/willmcgugan/textual
* License : MIT
  Programming Lang: Python
  Description : TUI (Text User Interface) framework for Python inspired by 
modern web development

 Textual uses Rich to render rich text, so anything that Rich can render may be
 used in Textual.
 .
 Event handling in Textual is asynchronous (using async and await keywords).
 Widgets (UI components) can independently update and communicate with each
 other via message passing.
 .
 Textual has more in common with modern web development than it does with
 curses; layout is done with CSS grid and (soon) the theme may be customized
 with CSS. Other techniques are borrowed from JS frameworks such as Vue and
 React.

Bug#975985: ITA: geda-gaf -- Electronics design software

[Bastian Germann]

On Wed, 29 Sep 2021 12:51:18 +0200 (CEST) Roland Lutz  wrote:

On Mon, 27 Sep 2021, Bastian Germann wrote:
> Roland, do you still want the package revived which means having it in 
> bookworm?

> I would then review and upload your version.

Sure.  Thank you!

Kai-Martin did some further work on packaging, in particular silencing 
lintian messages, so it may be worth checking out his repository, as well:


https://salsa.debian.org/kmk/geda-gaf/

Roland


I pushed an edited version of your changes to
https://salsa.debian.org/electronics-team/geda-gaf/-/tree/ita975985

Basically, I changed the following:

man page is not a patch but a file in debian/. A .manpages file has still to be 
added for the package that holds xorn to include it (should be in geda-utils, 
not in libgeda-common).


The GFDL situation: Do not just patch the license texts of upstream. While in 
this case Roland holds the copyright probably, this is generally not allowed.
The only case where GFDL can be included is in its GFDL-NIV variant excluding 
immutable sections (should be the case here). There are 1.2 and 1.3 files. The 
license text for 1.3 is missing and so are the files that are 1.2 licensed.


I got rid of some package renames.

As long as the package still (build-)depends on Python 2 I will not upload it. 
So please get rid of the Python files in the packages and patch the files that 
are executed during the build.

Bug#829754: bibclean: please make the build reproducible

[Vagrant Cascadian]

On 2021-09-30, Vagrant Cascadian wrote:
> On 2016-07-05, Reiner Herrmann wrote:
>> Source: bibclean
>> Version: 2.11.4.1-4
>> Severity: wishlist
>> Tags: patch upstream
>> User: reproducible-bui...@lists.alioth.debian.org
>> Usertags: timestamps username hostname
>> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>>
>> Hi!
>>
>> While working on the "reproducible builds" effort [1], we have noticed
>> that bibclean could not be built reproducibly.
>> It embeds the username and hostname into the binary, and a timestamp
>> into a dvi file.
>>
>> The attached patch this by stripping non-deterministic data and setting
>> FORCE_SOURCE_DATE, which tells texlive to override the timestamps in the
>> dvi file with SOURCE_DATE_EPOCH.
>>
>> Regards,
>>  Reiner
>>
>> [1]: https://wiki.debian.org/ReproducibleBuilds
>
> I can confirm this patch still works, although there are build-path
> issues it does not resolve (though tests.reproducible-builds.org doesn't
> current test build path variations in testing or stable, so applying
> this patch would be sufficient to get the package to at least build
> reproducibly there.

Adding this to debian/rules fixes build paths too:

+# Pass option to strip out build paths for reproducible builds
+CFLAGS += -ffile-prefix-map=$(CURDIR)=.

Updated patch attached also including this.

Alternately, switching to using the default buildflags provided by
/usr/share/dpkg/buildflags.mk or calling dpkg-buildflags to set CFLAGS
appropriately would also work.


live well,
  vagrant
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..6d32ce8
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,30 @@
+Author: Reiner Herrmann 
+Description: Strip non-deterministic data to make build reproducible
+
+--- a/option.c
 b/option.c
+@@ -567,24 +567,6 @@
+ #if defined(HOST) || defined(USER) || defined(__DATE__) || defined(__TIME__)
+ 	"Compiled",
+ 
+-#if defined(USER)
+-	" by <", USER,
+-
+-#if defined(HOST)
+-	"@", HOST,
+-#endif /* defined(HOST) */
+-
+-	">",
+-#endif /* defined(USER) */
+-
+-#if defined(__DATE__)
+-	" on ", __DATE__,
+-#endif /* defined(__DATE__) */
+-
+-#if defined(__TIME__)
+-	" ", __TIME__,
+-#endif /* defined(__TIME__) */
+-
+ #if defined(HAVE_PATTERNS)
+ 	"\nwith native pattern matching",
+ #endif /* defined(HAVE_PATTERNS) */
diff --git a/debian/patches/series b/debian/patches/series
index b4e2b79..4305c2c 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@ make.patch
 source.patch
 man.patch
 bibclean.ini.patch
+reproducible-build.patch
diff --git a/debian/rules b/debian/rules
index 23a3ba1..3396a42 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,12 +9,16 @@
 DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 
+export FORCE_SOURCE_DATE=1
+
 CFLAGS = -Wall -g
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
 	CFLAGS += -O0
 else
 	CFLAGS += -O2
 endif
+# Pass option to strip out build paths for reproducible builds
+CFLAGS += -ffile-prefix-map=$(CURDIR)=.
 
 # This target makes sure that timestamps of files are in the
 # right order after dpkg-deb has unpacked the package. It prevents


signature.asc
Description: PGP signature

Bug#995425: linux-image-amd64: kernel BUG at fs/ext4/ext4_extents.h:199! (fast_commit feature)

[Nelson G]

Package: linux-image-amd64
Version: 5.10.46-5
Severity: normal

Hello,

There's a bug for the ext4 filesystem, when the fast_commit flag is enabled and
you use fallocate or any other task that allocates space.


You can easily reproduce this bug on a VM or raw hardware by doing the
following:

1° You'll need a drive formatted with ext4 of course.
2° Enable fast_commit in that drive:  tune2fs -O fast_commit /dev/yourdrive
3° mount 'yourdrive', and inside 'yourdrive' try the following: fallocate -l
2000MB file




You'll see a similar output in dmesg/jourald:


[  263.841804] kernel BUG at fs/ext4/ext4_extents.h:199!
[  263.841821] invalid opcode:  [#1] SMP NOPTI
[  263.841827] CPU: 0 PID: 1283 Comm: fallocate Not tainted 5.10.0-8-amd64 #1
Debian 5.10.46-4
[  263.841830] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
1.14.0-2 04/01/2014
[  263.841864] RIP: 0010:ext4_fc_write_inode_data+0x19e/0x1b0 [ext4]
[  263.841868] Code: 7f 00 00 74 25 66 81 ca 00 80 66 89 54 24 30 e9 62 ff ff
ff 4c 89 ff e8 00 8a d6 c6 31 c0 eb 84 b8 83 ff ff ff e9 7a ff ff ff <0f> 0b e8
4b e1 d5 c6 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
[  263.841871] RSP: 0018:c3eb8125fd88 EFLAGS: 00010246
[  263.841875] RAX:  RBX: 0001f800 RCX:
00028000
[  263.841878] RDX: 00028000 RSI: 001216f9 RDI:
000359f0
[  263.841881] RBP: 002540bf R08: c3eb8125fe6c R09:
0f7c
[  263.841883] R10: 9fe2c1418c74 R11: c3eb8125fc20 R12:
002540be
[  263.841885] R13: c3eb8125fe6c R14: 9fe2c37c8a80 R15:
9fe2c37c8a08
[  263.841892] FS:  7fe263bcb5c0() GS:9fe33dc0()
knlGS:
[  263.841895] CS:  0010 DS:  ES:  CR0: 80050033
[  263.841897] CR2: 7fe263ae9e60 CR3: 050b6000 CR4:
003506f0
[  263.841903] Call Trace:
[  263.841936]  ext4_fc_commit+0x652/0x930 [ext4]
[  263.841961]  ext4_sync_file+0xd4/0x350 [ext4]
[  263.841981]  __x64_sys_fsync+0x34/0x60
[  263.842017]  do_syscall_64+0x33/0x80
[  263.842041]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  263.842055] RIP: 0033:0x7fe263afaa93
[  263.842059] Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f
1f 44 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 4a 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8
[  263.842062] RSP: 002b:7fff4b3c4af8 EFLAGS: 0246 ORIG_RAX:
004a
[  263.842065] RAX: ffda RBX: 558fd86a0660 RCX:
7fe263afaa93
[  263.842068] RDX:  RSI:  RDI:
0003
[  263.842069] RBP: 0003 R08:  R09:

[  263.842076] R10: 0002540be400 R11: 0246 R12:
7fff4b3c4d28
[  263.842078] R13:  R14:  R15:
0002540be400
[  263.842083] Modules linked in: uinput nft_fib_inet nft_fib_ipv4 nft_fib_ipv6
nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct
nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set
nf_tables nfnetlink snd_hda_codec_generic ledtrig_audio snd_hda_intel
snd_intel_dspcfg soundwire_intel soundwire_generic_allocation snd_soc_core
snd_compress soundwire_cadence snd_hda_codec amd_energy qxl snd_hda_core
drm_ttm_helper snd_hwdep lz4 zram serio_raw zsmalloc iTCO_wdt evdev
intel_pmc_bxt iTCO_vendor_support pcspkr soundwire_bus joydev ttm snd_pcm_oss
watchdog snd_mixer_oss virtio_balloon virtio_console drm_kms_helper snd_pcm cec
button snd_timer qemu_fw_cfg snd soundcore fuse drm configfs virtio_rng
rng_core ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs
blake2b_generic xor hid_generic usbhid raid6_pq libcrc32c crc32c_generic hid
crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel
ahci libahci libata aesni_intel libaes
[  263.842159]  scsi_mod crypto_simd psmouse cryptd glue_helper virtio_blk
virtio_net net_failover failover i2c_i801 xhci_pci i2c_smbus xhci_hcd lpc_ich
usbcore usb_common virtio_pci virtio_ring virtio
[  263.842186] ---[ end trace d31468378c3555b1 ]---
[  263.842214] RIP: 0010:ext4_fc_write_inode_data+0x19e/0x1b0 [ext4]
[  263.842218] Code: 7f 00 00 74 25 66 81 ca 00 80 66 89 54 24 30 e9 62 ff ff
ff 4c 89 ff e8 00 8a d6 c6 31 c0 eb 84 b8 83 ff ff ff e9 7a ff ff ff <0f> 0b e8
4b e1 d5 c6 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
[  263.842221] RSP: 0018:c3eb8125fd88 EFLAGS: 00010246
[  263.842224] RAX:  RBX: 0001f800 RCX:
00028000
[  263.842226] RDX: 00028000 RSI: 001216f9 RDI:
000359f0
[  263.842228] RBP: 002540bf R08: c3eb8125fe6c R09:
0f7c
[  263.842230] R10: 9fe2c1418c74 R11: c3eb8125fc20 R12:
002540be
[  263.842232] R13: c3eb8125fe6c R14: 9fe2c37c8a80 R15:
9fe2c37c8a08
[  263.842239] FS:  7fe263bcb5c0() GS:9fe33dc0()
knlGS:
[  263.842241] CS:  0010 DS:  ES: 0

Bug#995392: ghostscript: ps2pdf trashes some characters

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=704478

On 2021-09-30 18:49:02 +0200, Jonas Smedegaard wrote:
> Quoting Vincent Lefevre (2021-09-30 18:28:51)
> > On 2021-09-30 17:18:46 +0200, Jonas Smedegaard wrote:
> > > This seems an upstream bug, and it would be helpful if you report it 
> > > upstream as well.  Their bugtracker is at https://bugs.ghostscript.com/
> > 
> > OK. I'll do it tonight (I could also try to find the cause).

I've identified the commit that introduced the issue (though I'm not
sure whether the bug could be already present on other kinds of text)
and reported the bug upstream with the details (see above URL).

> Also, you could test against the newer pre-release in experimental.

Not tried, but the issue is still present in master.

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

Bug#829754: bibclean: please make the build reproducible

[Vagrant Cascadian]

On 2016-07-05, Reiner Herrmann wrote:
> Source: bibclean
> Version: 2.11.4.1-4
> Severity: wishlist
> Tags: patch upstream
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps username hostname
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> Hi!
>
> While working on the "reproducible builds" effort [1], we have noticed
> that bibclean could not be built reproducibly.
> It embeds the username and hostname into the binary, and a timestamp
> into a dvi file.
>
> The attached patch this by stripping non-deterministic data and setting
> FORCE_SOURCE_DATE, which tells texlive to override the timestamps in the
> dvi file with SOURCE_DATE_EPOCH.
>
> Regards,
>  Reiner
>
> [1]: https://wiki.debian.org/ReproducibleBuilds

I can confirm this patch still works, although there are build-path
issues it does not resolve (though tests.reproducible-builds.org doesn't
current test build path variations in testing or stable, so applying
this patch would be sufficient to get the package to at least build
reproducibly there.


live well,
  vagrant

> diff --git a/debian/patches/reproducible-build.patch 
> b/debian/patches/reproducible-build.patch
> new file mode 100644
> index 000..6d32ce8
> --- /dev/null
> +++ b/debian/patches/reproducible-build.patch
> @@ -0,0 +1,30 @@
> +Author: Reiner Herrmann 
> +Description: Strip non-deterministic data to make build reproducible
> +
> +--- a/option.c
>  b/option.c
> +@@ -567,24 +567,6 @@
> + #if defined(HOST) || defined(USER) || defined(__DATE__) || defined(__TIME__)
> + "Compiled",
> + 
> +-#if defined(USER)
> +-" by <", USER,
> +-
> +-#if defined(HOST)
> +-"@", HOST,
> +-#endif /* defined(HOST) */
> +-
> +-">",
> +-#endif /* defined(USER) */
> +-
> +-#if defined(__DATE__)
> +-" on ", __DATE__,
> +-#endif /* defined(__DATE__) */
> +-
> +-#if defined(__TIME__)
> +-" ", __TIME__,
> +-#endif /* defined(__TIME__) */
> +-
> + #if defined(HAVE_PATTERNS)
> + "\nwith native pattern matching",
> + #endif /* defined(HAVE_PATTERNS) */
> diff --git a/debian/patches/series b/debian/patches/series
> index b4e2b79..4305c2c 100644
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -3,3 +3,4 @@ make.patch
>  source.patch
>  man.patch
>  bibclean.ini.patch
> +reproducible-build.patch
> diff --git a/debian/rules b/debian/rules
> index 23a3ba1..6da74d6 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -9,6 +9,8 @@
>  DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
>  DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
>  
> +export FORCE_SOURCE_DATE=1
> +
>  CFLAGS = -Wall -g
>  ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
>   CFLAGS += -O0
> ___
> Reproducible-builds mailing list
> reproducible-bui...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds


signature.asc
Description: PGP signature

Bug#995406: [Debian-med-packaging] Bug#995406: bbmap: package does not ship resource files

[Étienne Mollier]

Control: found -1 38.90+dfsg-1
Control: tag -1 confirmed

Hi all,

Andreas Tille, on 2021-09-30:
> Am Thu, Sep 30, 2021 at 01:22:23PM -0400 schrieb Robert:
> > The bbmap package does not ship the needed resource files which causes some 
> > of
> > the included tools not to work, e.g. bbduk when trying to process some fastq
> > data, crashes with output like [1].
> 
> Thanks a lot for the report.  Its extremely helpful since several of our
> maintainers are not using this software and we really need to rely on
> user input.

Thank you Robert!  Your report is very useful indeed!

[…]
> > $ bbduk.sh in1=fwd.fastq in2=rev.fastq ktrim=r k=21 mink=8 hdist=2 ftm=5 
> > tpe tbo threads=48 out=out.fastq
> > java -ea -Xmx76702m -Xms76702m -cp /usr/share/java/bbmap.jar jgi.BBDuk 
> > in1=fwd.fastq in2=rev.fastq ktrim=r k=21 mink=8 hdist=2 ftm=5 tpe tbo 
> > threads=48 out=out.fastq
> > Executing jgi.BBDuk [in1=fwd.fastq, in2=rev.fastq, ktrim=r, k=21, mink=8, 
> > hdist=2, ftm=5, tpe, tbo, threads=48, out=out.fastq]
> > Version 38.90
> > 
> > Set threads to 48
> > maskMiddle was disabled because useShortKmers=true
> > Warning!  Cannot find primes.txt.gz 
> > /tmp/bbduk_test/file:/usr/share/java/bbmap.jar!/primes.txt.gz
> > at jgi.BBDuk.main(BBDuk.java:78)
> 
> If we could turn this into a test I could upload including test.

Andreas, I pulled some data files from python-biopython-doc,
and I think I managed to reproduce the problem on my end:

$ bbduk.sh \

in1=/usr/share/doc/python-biopython-doc/Tests/Quality/example.fastq \

in2=/usr/share/doc/python-biopython-doc/Tests/Quality/solexa_example.fastq \
ktrim=r k=21 mink=8 hdist=2 ftm=5 tpe tbo threads=48 \
out=out.fastq
java -ea -Xmx7195m -Xms7195m -cp /usr/share/java/bbmap.jar jgi.BBDuk 
in1=/usr/share/doc/python-biopython-doc/Tests/Quality/example.fastq 
in2=/usr/share/doc/python-biopython-doc/Tests/Quality/solexa_example.fastq 
ktrim=r k=21 mink=8 hdist=2 ftm=5 tpe tbo threads=48 out=out.fastq
Executing jgi.BBDuk 
[in1=/usr/share/doc/python-biopython-doc/Tests/Quality/example.fastq, 
in2=/usr/share/doc/python-biopython-doc/Tests/Quality/solexa_example.fastq, 
ktrim=r, k=21, mink=8, hdist=2, ftm=5, tpe, tbo, threads=48, out=out.fastq]
Version 38.93

Set threads to 48
maskMiddle was disabled because useShortKmers=true
Warning!  Cannot find primes.txt.gz 
/home/emollier/tmp/bbduk_test/file:/usr/share/java/bbmap.jar!/primes.txt.gz
java.lang.Exception
at dna.Data.findPath(Data.java:1247)
at dna.Data.findPath(Data.java:1194)
at shared.Primes.fetchPrimes(Primes.java:167)
at shared.Primes.(Primes.java:177)
at kmer.ScheduleMaker.(ScheduleMaker.java:155)
at jgi.BBDuk.(BBDuk.java:964)
at jgi.BBDuk.main(BBDuk.java:78)
Exception in thread "main" java.lang.ExceptionInInitializerError
at kmer.ScheduleMaker.(ScheduleMaker.java:155)
at jgi.BBDuk.(BBDuk.java:964)
at jgi.BBDuk.main(BBDuk.java:78)
Caused by: java.lang.NullPointerException
at fileIO.ByteFile.(ByteFile.java:43)
at fileIO.ByteFile1.(ByteFile1.java:98)
at fileIO.ByteFile1.(ByteFile1.java:94)
at shared.Primes.fetchPrimes(Primes.java:169)
at shared.Primes.(Primes.java:177)
... 3 more

I tested the patch from Robert and applied by Andreas, and it
seems I could get much further in the processing.  For the
autopkgtest, note that I had to pick an appropriate dataset with
same dimensions in both files, otherwise the processing fails,
because of intrinsic data inconsistencies I presume:

$ bbduk.sh \

in1=/usr/share/doc/python-biopython-doc/Tests/Quality/wrapping_as_sanger.fastq \

in2=/usr/share/doc/python-biopython-doc/Tests/Quality/wrapping_as_solexa.fastq \
ktrim=r k=21 mink=8 hdist=2 ftm=5 tpe tbo threads=48 \
out=out.fastq
java -ea -Xmx7140m -Xms7140m -cp /usr/share/java/bbmap.jar jgi.BBDuk 
in1=/usr/share/doc/python-biopython-doc/Tests/Quality/wrapping_as_sanger.fastq 
in2=/usr/share/doc/python-biopython-doc/Tests/Quality/wrapping_as_solexa.fastq 
ktrim=r k=21 mink=8 hdist=2 ftm=5 tpe tbo threads=48 out=out.fastq
Executing jgi.BBDuk 
[in1=/usr/share/doc/python-biopython-doc/Tests/Quality/wrapping_as_sanger.fastq,
 
in2=/usr/share/doc/python-biopython-doc/Tests/Quality/wrapping_as_solexa.fastq, 
ktrim=r, k=21, mink=8, hdist=2, ftm=5, tpe, tbo, threads=48, out=out.fastq]
Version 38.93

Set threads to 48
maskMiddle was disabled because useShortKmers=true
0.018 seconds.
Initial:
Memory: max=7486m, total=7486m, free=7467m, used=19m

**  WARNING! A KMER OPERATION W

Bug#995341: release.debian.org: Xen dom0 does not power off on bullseye (stable)

[Chuck Zmudzinski]

On 9/30/2021 2:57 PM, Paul Gevers wrote:

Hi Chuck,

On 30-09-2021 18:15, Chuck Zmudzinski wrote:


... the debdiff I uploaded to BTS has UNRELEASED
rather than bullseye for the distribution field of the changelog,
and the new target version is ...deb11u1.1 instead of deb11u2.
That is how dch formatted the changelog when I generated
the debdiff. Let me know if I need to fix the debdiff filename and
changelog with a new debdiff that corrects those, and I will
upload it to 995...@bugs.debian.org.

You could indeed send a follow-up with a debdiff that fixes these issues
as that saves the stable release managers a round trip to you and less
brain power. You'd need to fix it locally anyways to actually do the upload.


Update debdiff with these fixes to changelog is attached to this message.
Changelog also Closes #994899.

Chuck
diff -Nru xen-4.14.3/debian/changelog xen-4.14.3/debian/changelog
--- xen-4.14.3/debian/changelog 2021-09-13 10:28:21.0 -0400
+++ xen-4.14.3/debian/changelog 2021-09-30 16:06:50.0 -0400
@@ -1,3 +1,12 @@
+xen (4.14.3-1~deb11u2) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches - move RPI4 patches into a separate directory
+  * debian/rules - disable RPI4 patches on amd64|i386 (Closes: #994899)
+  * debian/control - add Build Dependency quilt
+
+ -- Chuck Zmudzinski   Thu, 30 Sep 2021 16:06:50 -0400
+
 xen (4.14.3-1~deb11u1) bullseye-security; urgency=medium
 
   * Rebuild for bullseye-security
diff -Nru xen-4.14.3/debian/control xen-4.14.3/debian/control
--- xen-4.14.3/debian/control   2021-07-10 08:01:39.0 -0400
+++ xen-4.14.3/debian/control   2021-09-26 22:21:51.0 -0400
@@ -34,6 +34,7 @@
markdown,
ocaml-native-compilers | ocaml-nox,
ocaml-findlib,
+   quilt,
 Homepage: https://xenproject.org/
 Vcs-Browser: https://salsa.debian.org/xen-team/debian-xen
 Vcs-Git: https://salsa.debian.org/xen-team/debian-xen.git
diff -Nru 
xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch 
xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch
--- 
xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch
2021-09-13 10:25:25.0 -0400
+++ 
xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch
1969-12-31 19:00:00.0 -0500
@@ -1,105 +0,0 @@
-From: Stefano Stabellini 
-Date: Fri, 2 Oct 2020 13:47:17 -0700
-Subject: xen/rpi4: implement watchdog-based reset
-
-The preferred method to reboot RPi4 is PSCI. If it is not available,
-touching the watchdog is required to be able to reboot the board.
-
-The implementation is based on
-drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux v5.9-rc7.
-
-Signed-off-by: Stefano Stabellini 
-Acked-by: Julien Grall 
-Reviewed-by: Bertrand Marquis 
-Tested-by: Roman Shaposhnik 
-CC: ro...@zededa.com
-(cherry picked from commit 25849c8b16f2a5b7fcd0a823e80a5f1b590291f9)

- xen/arch/arm/platforms/brcm-raspberry-pi.c | 61 ++
- 1 file changed, 61 insertions(+)
-
-diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c 
b/xen/arch/arm/platforms/brcm-raspberry-pi.c
-index f5ae58a..811b40b 100644
 a/xen/arch/arm/platforms/brcm-raspberry-pi.c
-+++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c
-@@ -17,6 +17,10 @@
-  * GNU General Public License for more details.
-  */
- 
-+#include 
-+#include 
-+#include 
-+#include 
- #include 
- 
- static const char *const rpi4_dt_compat[] __initconst =
-@@ -37,12 +41,69 @@ static const struct dt_device_match rpi4_blacklist_dev[] 
__initconst =
-  * The aux peripheral also shares a page with the aux UART.
-  */
- DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"),
-+/* Special device used for rebooting */
-+DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"),
- { /* sentinel */ },
- };
- 
-+
-+#define PM_PASSWORD 0x5a00
-+#define PM_RSTC 0x1c
-+#define PM_WDOG 0x24
-+#define PM_RSTC_WRCFG_FULL_RESET0x0020
-+#define PM_RSTC_WRCFG_CLR   0xffcf
-+
-+static void __iomem *rpi4_map_watchdog(void)
-+{
-+void __iomem *base;
-+struct dt_device_node *node;
-+paddr_t start, len;
-+int ret;
-+
-+node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm");
-+if ( !node )
-+return NULL;
-+
-+ret = dt_device_get_address(node, 0, &start, &len);
-+if ( ret )
-+{
-+printk("Cannot read watchdog register address\n");
-+return NULL;
-+}
-+
-+base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE);
-+if ( !base )
-+{
-+printk("Unable to map watchdog register!\n");
-+return NULL;
-+}
-+
-+return base;
-+}
-+
-+static void rpi4_reset(void)
-+{
-+uint32_t val;
-+void __iomem *base = rpi4_map_watchdog();
-+
-+if ( !base )
-+return;
-+
-+/* use a timeout of 10 ticks (~150us) */
-+writel(10 | PM_PASSWORD, base + PM_WDOG);
-+val = readl(base + PM

Bug#995341: release.debian.org: Xen dom0 does not power off on bullseye (stable)

[Chuck Zmudzinski]

On 9/30/2021 2:57 PM, Paul Gevers wrote:

Hi Chuck,

On 30-09-2021 18:15, Chuck Zmudzinski wrote:


... the debdiff I uploaded to BTS has UNRELEASED
rather than bullseye for the distribution field of the changelog,
and the new target version is ...deb11u1.1 instead of deb11u2.
That is how dch formatted the changelog when I generated
the debdiff. Let me know if I need to fix the debdiff filename and
changelog with a new debdiff that corrects those, and I will
upload it to 995...@bugs.debian.org.

You could indeed send a follow-up with a debdiff that fixes these issues
as that saves the stable release managers a round trip to you and less
brain power. You'd need to fix it locally anyways to actually do the upload.

Two notes:
1) https://lists.debian.org/debian-devel-announce/2019/08/msg0.html
(under "Workflow").
2) https://lists.debian.org/debian-live/2021/09/msg00027.html

Paul



I will prepare the updated debdiff.

I understand I am asking for an exception to the Release
Team's first "usual" criteria for acceptance:

   * The bug you want to fix in stable must be fixed in unstable
 already (and not waiting in NEW or the delayed queue)

I don't know if they will be willing to make an exception. Probably
not before 11.1 comes out as I am sure they are busy dealing with
the upcoming point release. I do hope they will read my whole
report before deciding. What happened here is very unusual
for Debian, and IMHO Debian would not be renowned for
stability if it happened more often.

Chuck

Bug#900244: NVM error information log entry count increase not an error

[Benjamin Poirier]

I also see this issue with the following drive, nvme1 on my system:

Model Number:   Samsung SSD 970 EVO Plus 1TB
Firmware Version:   2B2QEXM7
PCI Vendor/Subsystem ID:0x144d

This has been going on for months and until recently the output of
`smartctl -l error /dev/nvme1` showed

=== START OF SMART DATA SECTION ===
Error Information (NVMe Log 0x01, 16 of 64 entries)
No Errors Logged

However now it shows

=== START OF SMART DATA SECTION ===
Error Information (NVMe Log 0x01, 16 of 64 entries)
Num   ErrCount  SQId   CmdId  Status  PELoc  LBA  NSIDVS
  0   3401 0  0x0006  0x4004  -0 0 -

`nvme smart-log /dev/nvme1` shows
.
 Entry[ 0]
.
error_count : 3401
sqid: 0
cmdid   : 0x6
status_field: 0x4004(INVALID_FIELD: A reserved coded value or an 
unsupported value in a defined field)
parm_err_loc: 0x
lba : 0
nsid: 0
vs  : 0
trtype  : The transport type is not indicated or the error is not 
transport related.
cs  : 0
trtype_spec_info: 0
.

The other entries are not populated, they all have
status_field: 0(SUCCESS: The command completed successfully)

The same system also has another drive, /dev/nvme0:
Model Number:   Samsung SSD 980 PRO 1TB
Firmware Version:   2B2QGXA7
PCI Vendor/Subsystem ID:0x144d

That drive does not show this problem, `smartctl -A /dev/nvme0` remains
at
Error Information Log Entries:  0

In my case this is a dual boot system; nvme1 is used for Windows 10 and
rarely mounted in Linux. However in the past I was also using nvme1 for
my linux root partition and the error count was also increasing. Like
others have said, the error count on nvme1 seems to increase after
reboots though not systematically.

I have edited /etc/smartmontools/run.d/10mail to filter out the messages
about nvme1 error log entries.

Bug#995415: unblock: theano/1.0.5+dfsg-3 - not really a regression

[Rebecca N. Palmer]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

theano 1.0.5+dfsg-3 is currently held in unstable for an autopkgtest 
"regression" on armhf.


The test in question (smoketestgpu) is currently skipped in plain 
testing because it depends on clblas (not in testing) and is marked 
skip-not-installable.  When it is run with the testing version of 
theano, it fails with the same message.
theano 1.0.5+dfsg-2 + clblas: 
https://ci.debian.net/data/autopkgtest/testing/armhf/t/theano/15627483/log.gz
theano 1.0.5+dfsg-3 + clblast: 
https://ci.debian.net/data/autopkgtest/testing/armhf/t/theano/15629750/log.gz


theano 1.0.5+dfsg-3 removes the skip-not-installable (#993107) and 
replaces clblas by clblast.


(I suspect the underlying issue is actually a pocl bug triggered by 
gcc-11, but I can't prove that: this request is based on "not new", not 
"not mine".)

Bug#995362: zint breaks zbar autopkgtest: unable to open file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory @ error/constitute.c/ReadImage/614

[John Scott]

On Thu, 2021-09-30 at 09:18 -0400, John Scott wrote:
> Outside a minimal chroot, on my desktop system, zbarimg seems to
> process SVGs just fine. So this may be a case of a Recommends
> (somewhere) not being installed wreaking havok, but in my opinion
> zbarimg should still not behave this way when a Recommends is
> missing.

I've found the culprit: if libmagickcore-6.q16-6-extra is not
installed, then this cryptic error occurs. I've reported this issue
(the lack of a helpful error message) at
https://github.com/mchehab/zbar/issues/202 .

I'll leave it to the maintainer to decide what they'd like to do:
either hardcode a dependency on libmagickcore-6.q16-6-extra, or switch
zint's output format to PNG (I personally would prefer the latter).


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

Bug#974789: beignet FTBFS with llvm-toolchain-11

[Rebecca N. Palmer]

I'm not aware of a fix for this, and beignet is abandoned upstream and 
mostly useful for old hardware (on newer hardware it is replaced by 
intel-opencl-icd).  However, I may look at it more later (and at least 
try llvm-toolchain-12, though I'd expect that to be worse if anything).


Hence, I'm fine with you removing llvm-toolchain-9 and intentionally 
making beignet unbuildable, but please do *not* remove beignet from 
unstable for the time being.  (It can be removed from testing.)

Bug#986709: rsnapshot is stable, not dead

[John Brooks]

On 2021-09-30 6:13 p.m., Michael Lustfield wrote:

On Sun, 26 Sep 2021 13:49:36 -0400
John Brooks  wrote:


[...]


So... My first response was a wordier version of the message you replied to,
emphasizing the bit where my opinion is moot. What's written below is as much
as I'm willing to dip back into #debiandrama. While reading, please remember
this point (and don't expect further response).


My original request was for a removal, which is a stance I whole-heartedly
still stand by, and which draws from experiences after adopting the package. A
removal like this is basically orphan++ ("I'm afk4eva" vs. "bad package"). That
changed slightly with zeha's bug modifications, but the effect is still largely
the same, with a touch of stability added. (Thanks zeha!)

(sensible action, but likely helps with that "limbo" perception?)
   ^ https://tracker.debian.org/pkg/rsnapshot

side note --

   > Additionally, in response to this very bug, a new upstream release has
   > now been issued. In light of this, do you plan to upload the new version

   You very correctly point out that a number of fixes and a new release came
   directly in response to certain actions. Unfortunately, we draw very 
different
   conclusions. (a hint, perhaps?)


I appreciate that you responded to that particular (#30) message of mine, where
I say that I don't intend to stand in anyone's way, and offered to help anyone
interested in package maintenance, while also maintaining my position. This is
important to me because some people have indeed taken a stab at rsnapshot
maintenance; however, they very quickly disappeared when they learned that it
would require more effort than just slapping an updated tarball onto the
packaging.


and continue to fill the role of maintainer for the rsnapshot Debian
package, or is another maintainer still needed going forward?


^ "continue" stopped at the RM-RoQA (note: this tag was not an accident)

The root of why I claim how I feel does not matter is because the end result is
the same. The only thing that's required to override my (strong) opinion is for
someone to pick it up, understand it well enough to confidently claim it's
ready for release (start w/ debian bugs), and that'll be the end of this thread.



Thank you for your reply. I admit I'm rather a dilettante in this area. 
I'm only a user and have had little or no exposure to the Debian 
development process. I didn't even see "RoQA" until you pointed it out, 
and then had to look up what it means — "Requested by the QA team".


And that's about where my ability to contribute usefully ends. My belief 
that the Debian organization and its contributors are generally 
intelligent and sensible leads me to believe that you and the QA team 
have good reasons for removing the package, even if I don't understand them.


I don't know precisely what criteria of stability and quality are used 
to judge whether a package is suitable for inclusion; my outside view is 
that this package is no more broken or unmaintained than the average 
Debian package. The only bug of "serious" severity classification is 
this one. But when my uninformed assessment is at odds with an actual 
Debian maintainer, I have no choice but to assume that there is an 
important factor which I am blind to. I understand that it's not your 
responsibility to teach me just to satisfy my idle curiosity, so we can 
leave it at that.


Thank you for your service.

John Brooks

Bug#995408: transition: libquvi

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-libquvi.html

On 2021-09-30 14:43:14 -0400, Boyuan Yang wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: by...@debian.org ans...@debian.org alejan...@debian.org
> Severity: normal
> 
> Dear Debian release team,
> 
> I request to start the transition as listed on
> https://release.debian.org/transitions/html/auto-libquvi.html .
> 
> The new version of libquvi comes with new SONAME and altered library package
> name (libquvi-0.9-0.9.3 -> libquvi-0.9-0.9.4). Updating libquvi means that a
> library transition is needed.
> 
> I have tested all reverse dependencies (cclive, quvi) and they all build well
> with new libquvi. BinNMUs should be enough after the transition is initiated.

Please go ahead

Cheers

> 
> (Also CC-ing maintainers of package cclive and quvi).
> 
> Ben file (the one current on the transition tracker is good enough):
> 
> title = "libquvi";
> is_affected = .depends ~ "libquvi-0.9-0.9.3" | .depends ~ "libquvi-0.9-0.9.4";
> is_good = .depends ~ "libquvi-0.9-0.9.4";
> is_bad = .depends ~ "libquvi-0.9-0.9.3";
> 
> 
> Thanks,
> Boyuan Yang



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#995424: libgmsh4: SONAME bump without package rename

[Sebastian Ramacher]

Package: libgmsh4
Version: 4.8.4+ds1-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org, elb...@debian.org

The package name of shared libraries is supposed to follow the SONAME of
the library. In the case of libgmsh, the SONAME in testing is
libgmsh.so.4.7 and the package should have been named libgmsh4.7. But
now, the SONAME changed to libgmsh.so.4.8 and the package name should
have been changed accorindgly.

This broke every user outside of the gmsh source package of libgmsh4.
See for example
https://ci.debian.net/data/autopkgtest/testing/amd64/d/deal.ii/15628998/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#986709: rsnapshot is stable, not dead

[Michael Lustfield]

On Sun, 26 Sep 2021 13:49:36 -0400
John Brooks  wrote:

> [...]
> Michael,
> 
> I think it is important that you clarify or modify your stance given 
> that upon further inspection by others here, there are no serious 
> outstanding functional or security issues with the program. Even 
> self-asserted justification (i.e. "I just don't want to maintain it 
> anymore, so find someone else") is acceptable; that is your right as a 
> volunteer. But it would have been prudent to either defend your initial 
> assessment of the program as no longer suitable for inclusion, or 
> acknowledge that you may have been incorrect. Otherwise the issue is 
> just stuck in limbo.
> 
> Additionally, in response to this very bug, a new upstream release has 
> now been issued. In light of this, do you plan to upload the new version 
> and continue to fill the role of maintainer for the rsnapshot Debian 
> package, or is another maintainer still needed going forward?
> 
> I don't seek to impose anything upon you, I just want to see that this 
> doesn't fall through the cracks.
> 
> Thanks
> John Brooks

So... My first response was a wordier version of the message you replied to,
emphasizing the bit where my opinion is moot. What's written below is as much
as I'm willing to dip back into #debiandrama. While reading, please remember
this point (and don't expect further response).


My original request was for a removal, which is a stance I whole-heartedly
still stand by, and which draws from experiences after adopting the package. A
removal like this is basically orphan++ ("I'm afk4eva" vs. "bad package"). That
changed slightly with zeha's bug modifications, but the effect is still largely
the same, with a touch of stability added. (Thanks zeha!)

(sensible action, but likely helps with that "limbo" perception?)
  ^ https://tracker.debian.org/pkg/rsnapshot

side note --

  > Additionally, in response to this very bug, a new upstream release has 
  > now been issued. In light of this, do you plan to upload the new version 

  You very correctly point out that a number of fixes and a new release came
  directly in response to certain actions. Unfortunately, we draw very different
  conclusions. (a hint, perhaps?)


I appreciate that you responded to that particular (#30) message of mine, where
I say that I don't intend to stand in anyone's way, and offered to help anyone
interested in package maintenance, while also maintaining my position. This is
important to me because some people have indeed taken a stab at rsnapshot
maintenance; however, they very quickly disappeared when they learned that it
would require more effort than just slapping an updated tarball onto the
packaging.

> and continue to fill the role of maintainer for the rsnapshot Debian 
> package, or is another maintainer still needed going forward?

^ "continue" stopped at the RM-RoQA (note: this tag was not an accident)

The root of why I claim how I feel does not matter is because the end result is
the same. The only thing that's required to override my (strong) opinion is for
someone to pick it up, understand it well enough to confidently claim it's
ready for release (start w/ debian bugs), and that'll be the end of this thread.

Bug#995423: libyaml-cpp-dev: Incorrect include PATH in CMake configuration script.

[Tomasz Wolak]

Package: libyaml-cpp-dev
Version: 0.6.3-9
Severity: normal
X-Debbugs-Cc: tomas.wo...@gmail.com

One of the package config files for CMake:

/usr/lib/x86_64-linux-gnu/cmake/yaml-cpp/yaml-cpp-config.cmake

contains an incorrect path to the library's header files:
'include' instead of '/usr/include/yaml-cpp'.

I have managed to hot-fix this by correcting debian patches:

1. install-cmake-dev-files.patch - the line (for CMakeLists.txt):
 set(INCLUDE_INSTALL_ROOT_DIR include)
was changed to:
-set(INCLUDE_INSTALL_ROOT_DIR include)
+set(INCLUDE_INSTALL_ROOT_DIR /usr/include)

2. fix-pkg-config.patch, where I changed the line:
+set(YAML_CPP_INCLUDE_DIR "@INCLUDE_INSTALL_ROOT_DIR@")
to the following:
+set(YAML_CPP_INCLUDE_DIR "@INCLUDE_INSTALL_DIR@")

After changing this, the rebuilt package contains the correct
path to the header files (/usr/include/yaml-cpp) in its cmake
configuration.

(I am not sure if this is the best way for fixing this but it seems
reasonable. It should be reviewed and tested, of course.
I am not sure how to provide you a patch to a Debian patch...
that's why such descriptive form).

(Btw. version 0.6.3-10 seems to have the same problem).


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

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

Versions of packages libyaml-cpp-dev depends on:
ii  libyaml-cpp0.6  0.6.3-9

libyaml-cpp-dev recommends no packages.

libyaml-cpp-dev suggests no packages.

-- no debconf information

Bug#995419: rust-utf-8: autopkgtest regression: crate directory not found: /usr/share/cargo/registry/utf-8-0.7.6

[peter green]

It passes when run with only packages from testing.


This is not entirely correct, the version of rust-utf-8 in testing
has no autopkgtests at all. So this is a case of a newly added
(by a newer version of debcargo) test failing, not a case of an
existing test regressing.

Investigating, it seems the reason for the failure is that
the crate is installed in the wrong place. It is installed
in /usr/share/cargo/registry/utf-0.7.6/ when it should be
installed in /usr/share/cargo/registry/utf-8-0.7.6/

The reason it's installed in the wrong place is that
dh-cargo by default determines the crate name from the
source package name, but source package names are ambiguous
"rust-utf-8" could mean a crate called "utf" with a major
version of 8 or it could (and actually does in this case)
mean a crate called utf-8.

dh-cargo allows a package to specify an explicit crate name
through X-Cargo-Crate in the source section of the control
file but debcargo seems to offer no way to set this other
than overriding the complete control file. There is no mention
of X-Cargo-Crate in the debcargo source and the mechanism
for adding arbitrary lines to the generated control file only
applies to binary package sections.

This also affects rust-md-5 and rust-sha-1, though neither
of those packages are currently in testing and rust-sha-1
has not had an upload since debcargo started doing
autopkgtests

I see a number of possible ways of solving the issue.

1. Just override the whole control file
   (debcargo rightly discourages this due to the maintenance
   burden it creates, but OTOH this issue only affects
   three crates)
2. Add support for adding arbitrary lines to the source
   section of debian/control in debcargo and use it to
   manually add X-Cargo-Crate
3. Modify dh-cargo to obtain the crate name from Cargo.toml
   instead of the package name.
   (would presumablly mean dragging in a perl toml parser
   which may not be desirable)
4. Modify debcargo to generate X-Cargo-Crate lines in
   cases where dh-cargo would otherwise get the wrong
   crate name.
5. Modify debcargo to generate X-Cargo-Crate lines
   unconditionally

Bug#995392: ghostscript: ps2pdf trashes some characters

[JustAnotherArchivist]

Control: notfound -1 9.53.3~dfsg-8

Apologies, I somehow missed the part about pdftotext and the glyph's 
normal appearance in your original message. I can reproduce that with 
both files produced by 9.54.0~dfsg-5 but *not* the one produced by 
9.53.3~dfsg-8 (attached for reference), using the same pdftotext version 
(poppler-utils 20.09.0-3.1) for all files.




chartest-gs-jaa-9.53.3.pdf
Description: Adobe PDF document

Bug#995422: ITP: long-read-assembler -- assembly from long reads against reference genome

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: long-read-assembler -- assembly from long reads against reference 
genome
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: long-read-assembler
  Version : 1.3.2
  Upstream Author : Copyright: Bonnie Phan Wolfe 
* URL : https://github.com/ChaissonLab/LRA
* License : USC-RL-1.0
  Programming Lang: C
  Description : assembly from long reads against reference genome
 Machines that determine the DNA sequence do not provide answers 
 en block, but as many comparatively short reads that by chance
 also overlap. From these, the complete genome is puzzled together
 assembled. This is less easy than one may think because of
 redundancies of the genome, so you do not know where a read comes
 from if that read is too short. A reference genome helps, but
 people differ, e.g. with local duplications, and you may be
 interested in diseases that have chromosomal rearrangements.
 .
 lra is a sequence alignment program that aligns long reads from
 single-molecule sequencing (SMS) instruments, or megabase-scale contigs
 from SMS assemblies. These technologies provide reads that are 1000 or
 10k times longer than what can be achieved with the Sanger Sequencing
 technology and help the assembly.
 .
 lra implements seed chaining sparse dynamic programming with a concave
 gap function to read and assembly alignment, which is also extended to
 allow for inversion cases. lra alignment approach increases sensitivity
 and specificity for SV discovery, particularly for variants above 1kb
 and when discovering variation from ONT reads, while having runtime
 that arecomparable (1.05-3.76×) to current methods. When applied to
 calling variation from *de novo* assembly contigs, there is a 3.2%
 increase in Truvari F1 score compared to minimap2+htsbox.

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

Bug#994218: RFS: r-cran-partitions (NEW)

[Nilesh Patra]

On 30 September 2021 10:11:47 pm IST, "Torrance, Douglas" 
 wrote:
>On Thu 30 Sep 2021 10:47:16 AM EDT, Nilesh Patra  
>wrote:
>   I didn't realize this and just made the change based Lintian's [...]

Perfectly understandable.
I wonder if it makes sense to open a bug report against lintian to not emit 
this for R packages.

>> We are supposed to take versions as-is with hyphenations, and let debhelper 
>> do its job.
>> If you agree, please ask for a reject, fix the version and I'll re-upload.
>
>Sounds good to me!  I've fixed the version for r-cran-partitions in git:
>https://salsa.debian.org/r-pkg-team/r-cran-partitions

Thanks, I will upload once the one in NEW is scraped.

>How do I ask for a reject?  Just send an email to the FTP masters, or is there
>some official way through the BTS or something?  I haven't been able to find 
>any
>documentation on how to do this for packages still in the NEW queue...

You'd have got an email with the subject 
"r-cran-partitions_1.10.2+ds-1_amd64.changes is NEW"
You just need to reply all to that email and ask for reject.

Also, asking on #debian-ftp IRC could be quicker, if you'd like doing so.

>> I also noticed that similar thing has been done in r-cran-sets and 
>> r-cran-orthopolynom. But I guess
>> its a bit too late unfortunately to change them :/
>> So probably you need to add an epoch at some point in time for these.
>
>When would an epoch be necessary?  It seems like the dot/hyphen issues I'm
>seeing searching through the list archives (e.g., [2]) are in the opposite
>direction, i.e., upstream uses a dot in a versioned dependency when our
>package uses a hyphen.

I agree, but it is better to follow standards than not. It otherwise makes 
tracking the whole thing harder.
It has brought more harm than good in the past, when this was done, but 
admittedly I wasn't in the project back in the day, so hard for me to quote 
examples.

>I guess my question is, would it be ok to just wait for, e.g., sets 1.1-1 to
>be released to switch r-cran-sets to use a hyphen?

sets last release was in 2017, after which I don't see any commits on its 
GitHub mirror, so I'm not sure if a new one with this version would come out 
anytime soon.

That said,
It looks like r-cran-sets and orthopolynom would mostly be leaf packages, so 
probably it is just fine for them to be the way as they are now.
But please do keep an eye for these in future R packages!

>Thanks for noticing this!

Thanks to you for your work!

>[1] https://lists.debian.org/debian-devel/2003/12/msg02332.html
>[2] https://lists.debian.org/debian-r/2018/06/msg00069.html

Nilesh

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#994918: linux-image-5.14.0-1-amd64: Cannot load amdgpu firmware on 5.14 kernel

[Sebastian Reichel]

Hi,

The amdgpu driver from Linux 5.14 seems to require
IOMMU support, which was disabled by default in my
system's BIOS. My system (which has a Radeon RX 5700XT
GPU) successfully booted 5.14 after enabling it in
the BIOS. Previous 5.10 kernel also worked with IOMMU
disabled. I did not do any further investigations.

In any case the missing firmware files from the original
report are a red herring since the warnings either already
existed for 5.10 kernel (e.g. the one about navi10_mes.bin)
or are for quite recent GPUs, which were not yet supported
by 5.10.

Regards,

-- Sebastian


signature.asc
Description: PGP signature

Bug#994415: tang: Missing xinetd support in tang package

[Christoph Biedl]

Control: tags 994415 pending

Tom Boven wrote...

> And the files are part of the git repo under the units folder.
> Could these also be implemented in the debian package (or a seperate
> package like tang-xinetd) ?

Work is almost done now - but do you have an idea how to automatically
enable another service (like tangdx) in xinetd via postinst? I did not
find any example, would not want to just restart xinetd (which is what
the fex package does), and just leaving that to the user isn't something
I'd call good packaging quality. The latter however is going to happen
unless there is a better solution.

Regards,
Christoph



signature.asc
Description: PGP signature

Bug#990718: RFS: duma/2.5.21-1 [ITA] -- Detect Unintended Memory Access - A Red-Zone memory allocator

[Bastian Germann]

Hi Peter,

There was one QA (2.5.15-3) upload since you started your packaging effort. 
Please include the changelog entry in your version. The changes themselves are 
irrelevant with your upstream change.


On Thu, 8 Jul 2021 13:04:29 +0100 Peter  wrote:


  duma (2.5.21-1) unstable; urgency=medium


Please keep the -1 as revision even if you provide new uploads on mentors.


  .
    * Adopt package. (Closes: #565925)
    * New Upstream Release. (Closes: #550660, #623495, #655892)
    * Fixes FTBFS with GCC-11  (#984041)


Add a "Closes: " for this entry.


    * Use hardening flags, fixes bindnow, (Closes: #532483)
    * Use changelog file date instead of system date for build date
    * DEP-5 copyright


The license name has to be GPL-2+ because it has the "or later" clause.
Fix trailing whitespace.

Some files are licensed under LGPL 2.1+. Please identify them and add the 
license.


    * Add autopkgtests
    * Preserve Debian's CFLAGS etc (use += , not just = , in makefile)


Your 002-makefile.patch also has:
* Enable bindnow by using LDFLAGS
* C++14 standard needed tor testoperators.cpp

These two changes do not need a patch. Instead you can control the make 
variables via the debian/rules file.



I have dropped the patch from bug #532483 as Ubuntu dropped it in Focal Fossa.


Regards,
Peter Blackman


Please do not add lintian overrides because the warnings are all valid. You do 
not have to address them for your first version because they are already in the 
package. But in the future it may be good to split out the library to separate 
binary packages.


For bonus points you can use uscan's git mode (debian/watch) and add the 
upstream maintainer's GPG key that he uses to sign the release tags.


Thanks,
Bastian

Bug#990718: RFS: duma/2.5.21-1 [ITA] -- Detect Unintended Memory Access - A Red-Zone memory allocator

[Bastian Germann]

    * DEP-5 copyright


The license name has to be GPL-2+ because it has the "or later" clause.
Fix trailing whitespace.

Some files are licensed under LGPL 2.1+. Please identify them and add the 
license.


There are also some old-style MIT licensed files.

Bug#994828: bullseye-pu: package node-prismjs/1.23.0+dfsg-1+deb11u1

[Salvatore Bonaccorso]

Hi,

On Thu, Sep 30, 2021 at 07:58:31PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Tue, 2021-09-21 at 14:49 +0200, Yadd wrote:
> > node-prismjs is vulnerable to a Regex Denial of Service (ReDoS)
> > (CVE-2021-40438)
> > 
> 
> According to the Security Tracker, that's an Apache mod-proxy issue.

Looks this was typoed, and the right CVE mentioned whould be
CVE-2021-3801 (whereas the commit used is as per CVE-2021-3801,
https://github.com/prismjs/prism/commit/0ff371bb4775a131634f47d0fe85794c547232f9).

Regards,
Salvatore

Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1

[Adam D. Barratt]

On Mon, 2021-09-27 at 12:38 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
> 

To confirm some IRC conversations - given the closeness of the freeze
for 11.1, please feel free to upload and kibi can review the package
from stable-new.

Regards,

Adam


> Control: fixed 994042 2.32-3
> 
> Hi,
> 
> On Sun, 2021-09-26 at 22:16 +0200, Aurelien Jarno wrote:
> > Hi,
> > 
> > On 2021-09-26 20:46, Adam D. Barratt wrote:
> > > On Tue, 2021-09-21 at 23:47 +0200, Aurelien Jarno wrote:
> > > [...]
> > > > In the meantime another issue that would need to be fixed in
> > > > sid
> > > > > > came
> > > > as
> > > > bug#994042. 
> > > > 
> > > > This time the issue is in the preinst. To summarize, in the
> > > > case
> > > > debconf is not usable to prompt the user about the upgrade, the
> > > > preinst switches to text prompt. However as the debconf module
> > > > has
> > > > been loaded got control of the tty, which prevent any input
> > > > from
> > > > the
> > > > user. For skilled users it still possible to kill the upgrade
> > > > from
> > > > another, but other users will probably try other actions that
> > > > might
> > > > have damaging effects (like rebooting the system).
> > > > 
> > > > The fix is to get the debconf configuration without using the
> > > > debconf
> > > > module, as suggested by Colin Watson.
> > > > 
> > > 
> > > Thanks. That looks OK to me, particularly with Colin's review.
> > 
> > Thanks for the review. I guess that now it just needs a kibi-ack.
> 
> Yep; re-tagging accordingly.
> 
> > > Is there an ETA for getting the fix into unstable?
> > 
> > Upgrades from buster to bookworm are not supported, so it means
> > upgrade
> > to bookworm starts from bullseye, which has a fixed debconf (the
> > issue
> > has been fixed in version 1.5.76). Therefore the fix in unstable
> > has
> > been done in glibc 2.32-3 by just dropping all the workaround:
> > 
> > https://salsa.debian.org/glibc-team/glibc/-/commit/66359576b1aa793ae6c79618b188738287cf8789
> 
> Aha, thanks for connecting the dots. I was misled / confused slightly
> by the lack of fixed versions on #994042, where the version tracking
> implies that unstable is still affected, and 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994042;msg=33 not
> indicating which branch the fix was on (I realise I {c,sh}ould have
> checked). I've added a fixed version based on your explanation above;
> hopefully that makes the status clearer.
> 
> Regards,
> 
> Adam
> 
> 

Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1

[Aurelien Jarno]

Hi,

On 2021-09-27 12:38, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
> Control: fixed 994042 2.32-3
> 
> Hi,
> 
> On Sun, 2021-09-26 at 22:16 +0200, Aurelien Jarno wrote:
> > Hi,
> > 
> > On 2021-09-26 20:46, Adam D. Barratt wrote:
> > > On Tue, 2021-09-21 at 23:47 +0200, Aurelien Jarno wrote:
> > > [...]
> > > > In the meantime another issue that would need to be fixed in sid
> > > > > > came
> > > > as
> > > > bug#994042. 
> > > > 
> > > > This time the issue is in the preinst. To summarize, in the case
> > > > debconf is not usable to prompt the user about the upgrade, the
> > > > preinst switches to text prompt. However as the debconf module
> > > > has
> > > > been loaded got control of the tty, which prevent any input from
> > > > the
> > > > user. For skilled users it still possible to kill the upgrade
> > > > from
> > > > another, but other users will probably try other actions that
> > > > might
> > > > have damaging effects (like rebooting the system).
> > > > 
> > > > The fix is to get the debconf configuration without using the
> > > > debconf
> > > > module, as suggested by Colin Watson.
> > > > 
> > > 
> > > Thanks. That looks OK to me, particularly with Colin's review.
> > 
> > Thanks for the review. I guess that now it just needs a kibi-ack.
> 
> Yep; re-tagging accordingly.

I have just uploaded this package to bullseye.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#995397: Dropped support for 32-bit Xen PV guests should be mentioned in i386 release notes

[Andy Smith]

Hi Paul,

On Thu, Sep 30, 2021 at 10:21:42PM +0200, Paul Gevers wrote:
> This indeed sounds like something that could be mentioned under the
> "issues to be aware of" section. A proposal text would help the process
> forward.

Thanks. I am not sure whether it fits in "Items not limited to the
upgrade process" or under "Obsolescence and deprecation", but how
about:

The Linux kernel no longer provides support for 32-bit Xen
guests in PV mode.

Users of 32-bit Xen guests should check that they are running in
either PVH or HVM mode before upgrading to bullseye, since as of
v5.9 the Linux kernel will not boot as a 32-bit Xen PV mode
guest.

You can check which type of Xen guest you are running as
follows:


$ cat /sys/hypervisor/guest_type
PV


If you see PVH or HVM here then you should be safe
to upgrade to bullseye.

If it is a requirement to continue using PV mode, the least
disruptive option may be to https://wiki.debian.org/CrossGrading";>switch to an amd64
(64-bit) kernel. It is not necessary to cross-grade the
entire system to amd64.

Not sure if the last paragraph is appropriate as I'm not sure if
cross-grading like that is considered supported, even though I
suppose multiarch is considered supported, so why not?

Anyway, all of this is only for the i386 release notes as amd64
support has not been dropped.

Thanks!
Andy

Bug#995392: ghostscript: ps2pdf trashes some characters

[JustAnotherArchivist]

Hi Vincent,

For what it's worth, I do not see the corruption you're describing with 
`gv chartest-gs.pdf` nor when converting it myself from your input file 
using versions 9.53.3~dfsg-8 or 9.54.0~dfsg-5.


I noticed that your file used a different internal conversion command 
compared to when I try it with ps2pdf 9.54.0~dfsg-5:


Yours: %%Invocation: path/gs -dPrinted=false -P- -dSAFER 
-dCompatibilityLevel=1.5 -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite 
-sstdout=? -sOutputFile=? -P- -dSAFER -dCompatibilityLevel=1.5 ?
Mine: %%Invocation: path/gs -P- -dSAFER -dCompatibilityLevel=1.4 -q -P- 
-dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=? -sOutputFile=? -P- 
-dSAFER -dCompatibilityLevel=1.4 ?


Invoking it like your command manually did not make a difference for me 
though, with the output file being identical except for the expected 
differences in the version string, timestamps, and UUIDs.


I have attached my `ps2pdf chartest.pdf chartest-gs-jaa.pdf` output file 
(created with 9.54.0~dfsg-5).


Cheers,
JustAnotherArchivist



chartest-gs-jaa.pdf
Description: Adobe PDF document

Bug#994697: libgit-annex-perl: Test failure - autopkgtest and build

[Sean Whitton]

control: tag -1 + confirmed

Hello,

On Sun 19 Sep 2021 at 05:30PM +02, gregor herrmann wrote:

> Package: libgit-annex-perl
> Version: 0.007-1
> Severity: serious
> Tags: ftbfs sid bookworm
> Justification: fails to build from source (but built successfully in the past)
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> As first seen at ci.debian.net [0], libgit-annex-perl recently
> started to fail its testsuite. I note that this started to happen
> after the last git-annex upload (8.20210903-1).
>
> The same test failure also happens at buildtime:
>
> #   Failed test 'other is reinjected'
> #   at t/23_annex-to-annex-reinject.t line 33.
> # Looks like you failed 1 test of 2.
> t/23_annex-to-annex-reinject.t 
> ok 1 - other is initially present
> not ok 2 - other is reinjected
> 1..2
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/2 subtests

Bisection has determined that git-annex commit
4bf7940d6b912fbf692b268f621ebd41ed871125 is responsible for this bug.
Haven't come up with a minimal test case yet.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#995376: wsjtx: Segfault when use refspec

[Yvan Brodier]

$ gdb wsjtx
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
    .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from wsjtx...
(No debugging symbols found in wsjtx)
(gdb) set pagination 0
(gdb) run
Starting program: /usr/bin/wsjtx
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x711d0640 (LWP 2167370)]
[New Thread 0x7fffea9fb640 (LWP 2167371)]
[New Thread 0x7fffea1fa640 (LWP 2167372)]
[New Thread 0x7fffe1056640 (LWP 2167379)]
[New Thread 0x7fffd7fff640 (LWP 2167404)]
[New Thread 0x7fffd77fe640 (LWP 2167405)]
[Thread 0x7fffd77fe640 (LWP 2167405) exited]
[New Thread 0x7fffd77fe640 (LWP 2167412)]
[Thread 0x7fffd77fe640 (LWP 2167412) exited]
[New Thread 0x7fffd77fe640 (LWP 2167413)]
[New Thread 0x7fffd6ffd640 (LWP 2167414)]
[New Thread 0x7fffd67fc640 (LWP 2167415)]
[New Thread 0x7fffbe76d640 (LWP 2167416)]
[New Thread 0x7fffbde2b640 (LWP 2167417)]
[New Thread 0x7fffbd62a640 (LWP 2167418)]
[Detaching after fork from child process 2167419]
[New Thread 0x7fffbce29640 (LWP 2167420)]
[Thread 0x7fffbce29640 (LWP 2167420) exited]
[New Thread 0x7fffbce29640 (LWP 2167421)]
[Thread 0x7fffbce29640 (LWP 2167421) exited]
[New Thread 0x7fffbce29640 (LWP 2167444)]
[New Thread 0x7fffa669a640 (LWP 2167445)]
[Thread 0x7fffd77fe640 (LWP 2167413) exited]

Thread 1 "wsjtx" received signal SIGSEGV, Segmentation fault.
__memmove_sse2_unaligned_erms () at 
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:391
391 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Aucun 
fichier ou dossier de ce type.

(gdb) bt
#0  __memmove_sse2_unaligned_erms () at 
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:391

#1  0x55724da0 in ?? ()
#2  0x5572ec0d in ?? ()
#3  0x55695103 in ?? ()
#4  0x75cb478c in QObject::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#5  0x556d6925 in ?? ()
#6  0x76a5d74f in QApplicationPrivate::notify_helper(QObject*, 
QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5

#7  0x55713169 in ?? ()
#8  0x75c87e9a in QCoreApplication::notifyInternal2(QObject*, 
QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x75c8ae11 in 
QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x75ce0413 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x74745d0b in g_main_context_dispatch () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x74745fb8 in ?? () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7474606f in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x75cdfa90 in 
QEventDispatcherGlib::processEvents(QFlags) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x75c868db in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x75c8eb10 in QCoreApplication::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#17 0x555e89ba in ?? ()
#18 0x75325e4a in __libc_start_main (main=0x555e70a0, 
argc=1, argv=0x7fffe058, init=, fini=out>, rtld_fini=, stack_end=0x7fffe048) at 
../csu/libc-start.c:314

#19 0x555eb65a in ?? ()
(gdb) Quit
(gdb)


Le 30/09/2021 à 21:18, Christoph Berg a écrit :

Re: Yvan Brodier

Yes :


recvmsg(6, {msg_namelen=0}, 0)  = -1 EAGAIN (Ressource temporairement 
non disponible)

I meant a backtrace from gdb:

https://wiki.debian.org/HowToGetABacktrace

Christoph

Bug#995421: rust-bumpalo: autopkgtest armhf regression: oom_instead_of_bump_pointer_overflow

[Paul Gevers]

Source: rust-bumpalo
Version: 3.7.0-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of rust-bumpalo the autopkgtest of rust-bumpalo
fails in testing when that autopkgtest is run with the binary packages
of rust-bumpalo from unstable. It passes when run with only packages
from testing. In tabular form:

   passfail
rust-bumpalo   from testing3.7.0-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. Looking at the
name of the test *and* the resources of our armhf worker (250GB RAM) I
wonder if the test is assuming stuff that's not true.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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=rust-bumpalo

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-bumpalo/15635904/log.gz

running 10 tests
test alloc_slice_clone ... ok
test alloc_slice_copy ... ok
test alloc_with_strong_alignment ... ok
test force_new_chunk_fits_well ... ok
test oom_instead_of_bump_pointer_overflow ... FAILED
test small_size_and_large_align ... ok
test test_alignment ... ok
test test_reset ... ok
test can_iterate_over_allocated_things ... ok
test with_capacity_test ... ok

failures:

failures:
oom_instead_of_bump_pointer_overflow

test result: FAILED. 9 passed; 1 failed; 0 ignored; 0 measured; 0
filtered out; finished in 0.09s

error: test failed, to rerun pass '--test tests'
autopkgtest [16:03:45]: test librust-bumpalo-dev:: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#995420: D-Bus crash atk-bridge

[Kai Lüke]

Package: epiphany-browser
Version: 41.0-2


A few seconds after startup the app crashes with the following error 
printed on the console:


(WebKitWebProcess:2): dbind-WARNING **: 22:39:12.184: AT-SPI: Error 
retrieving accessibility bus address: 
org.freedesktop.DBus.Error.ServiceUnknown: 
org.freedesktop.DBus.Error.ServiceUnknown
dbus[10454]: arguments to dbus_message_new_method_call() were incorrect, 
assertion "destination == NULL || _dbus_check_is_valid_bus_name 
(destination)" failed in file ../../../dbus/dbus-message.c line 1364.

This is normally a bug in some application using the D-Bus library.

  D-Bus not built with -rdynamic so unable to print a backtrace

(WebKitWebProcess:2): WPE-FDO-ERROR **: 22:39:16.262: Failed to bind 
wpe_bridge

Abgebrochen (Speicherabzug geschrieben)

The systemd-coredump entry is:

   Message: Process 9820 (epiphany) of user 1000 dumped core.

    Stack trace of thread 9820:
    #0  0x7faa00e23e71 __GI_raise (libc.so.6 + 0x3ce71)
    #1  0x7faa00e0d536 __GI_abort (libc.so.6 + 0x26536)
    #2  0x7fa9f92e0d62 n/a (libdbus-1.so.3 + 0xed62)
    #3  0x7fa9f9303b60 _dbus_warn_check_failed 
(libdbus-1.so.3 + 0x31b60)
    #4  0x7fa9f92f32d2 dbus_message_new_method_call 
(libdbus-1.so.3 + 0x212d2)
    #5  0x7fa9fb10eebd n/a (libatk-bridge-2.0.so.0 + 
0xfebd)
    #6  0x7fa9fdbc779c n/a (libwebkit2gtk-4.0.so.37 + 
0xb8379c)
    #7  0x7fa9fd764067 n/a (libwebkit2gtk-4.0.so.37 + 
0x720067)
    #8  0x7fa9fd759370 n/a (libwebkit2gtk-4.0.so.37 + 
0x715370)
    #9  0x7fa9fd9879eb n/a (libwebkit2gtk-4.0.so.37 + 
0x9439eb)
    #10 0x7fa9fda83f13 n/a (libwebkit2gtk-4.0.so.37 + 
0xa3ff13)
    #11 0x7fa9fd980e25 n/a (libwebkit2gtk-4.0.so.37 + 
0x93ce25)
    #12 0x7fa9fd982d5e n/a (libwebkit2gtk-4.0.so.37 + 
0x93ed5e)
    #13 0x7fa9fcc26cdd _ZN3WTF7RunLoop11performWorkEv 
(libjavascriptcoregtk-4.0.so.18 + 0x159dcdd)
    #14 0x7fa9fcc75879 n/a 
(libjavascriptcoregtk-4.0.so.18 + 0x15ec879)
    #15 0x7fa9fcc7619f n/a 
(libjavascriptcoregtk-4.0.so.18 + 0x15ed19f)
    #16 0x7faa011b0c0f g_main_context_dispatch 
(libglib-2.0.so.0 + 0x53c0f)

    #17 0x7faa011b0fb8 n/a (libglib-2.0.so.0 + 0x53fb8)
    #18 0x7faa011b106f g_main_context_iteration 
(libglib-2.0.so.0 + 0x5406f)
    #19 0x7faa013cd7d5 g_application_run 
(libgio-2.0.so.0 + 0xe27d5)

    #20 0x55b0b4109c24 n/a (epiphany + 0x4c24)
    #21 0x7faa00e0ee4a __libc_start_main (libc.so.6 + 
0x27e4a)

    #22 0x55b0b4109efa n/a (epiphany + 0x4efa)

Bug#902167: distro-info: ubuntu-distro-info incorrectly lists the development release in --supported

[Stefano Rivera]

Hi Daniel (2018.06.22_18:56:11_-0700)
> I've prepared the attached patch against the Ubuntu packaging to fix the
> apparently incorrect output for --supported.  I will be seeking
> sponsorship for it in the coming days.

Sorry for never replying to this.

I agree that the current behaviour for --supported doesn't match the
documentation, and would be better named --active or --created.

I'm sure this would have a knock-on effect for consumers that we'd have
to investigate and resolve first.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#995419: rust-utf-8: autopkgtest regression: crate directory not found: /usr/share/cargo/registry/utf-8-0.7.6

[Paul Gevers]

Source: rust-utf-8
Version: 0.7.6-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of rust-utf-8 the autopkgtest of rust-utf-8 fails
in testing when that autopkgtest is run with the binary packages of
rust-utf-8 from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
rust-utf-8 from testing0.7.6-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Indeed the
cargo/registry only has /usr/share/cargo/registry/utf-0.7.6/

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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=rust-utf-8

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-utf-8/14941578/log.gz

autopkgtest [09:19:25]: test rust-utf-8:@:
/usr/share/cargo/bin/cargo-auto-test utf-8 0.7.6 --all-targets
--all-features
autopkgtest [09:19:25]: test rust-utf-8:@: [---
crate directory not found: /usr/share/cargo/registry/utf-8-0.7.6
autopkgtest [09:19:25]: test rust-utf-8:@: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#995308: libcrypt1: symlink points to libpthread

[shichimohedron]

On Thursday, September 30th, 2021 at 12:08 PM, Aurelien Jarno 
 wrote:

> It could be that this libpthread.so.1 file is actually a copy of an old
>
> libcrypt.so.1. It's something you can check with:
>
> readelf --dynamic /lib/x86_64-linux-gnu/libpthread.so.1 | grep SONAME

And it actually is:

~# readelf --dynamic /lib/x86_64-linux-gnu/libpthread.so.1 | grep SONAME
 0x000e (SONAME) Library soname: [libcrypt.so.1]

Bug#978773: bmake: ftbfs with autoconf 2.70

[Andrej Shadura]

Hi,

On Thu, 30 Sep 2021, at 22:18, Boyuan Yang wrote:
> On Thu, 31 Dec 2020 14:26:45 + Matthias Klose  wrote:
>> Package: src:bmake
>> Version: 20200710-5
>> Severity: normal
>> Tags: sid bookworm
>> User: d...@debian.org
>> Usertags: ftbfs-ac270
>> 
>> [This bug report is not targeted to the upcoming bullseye release]
>> 
>> The package fails to build in a test rebuild on at least amd64 with
>> autoconf 2.70, but succeeds to build with autoconf 2.69.
>
> The build error is caused by upstream using autotools macros without proper
> escaping. I am attaching a patch that corrects the syntax and makes the build
> pass. (Simply place it into debian/patches dir.)

Thanks a lot, applied :)

-- 
Cheers,
  Andrej

Bug#995397: Dropped support for 32-bit Xen PV guests should be mentioned in i386 release notes

[Paul Gevers]

Hi Andy,

On 30-09-2021 17:13, Andy Smith wrote:
> I think this issue should be mentioned in the i386 release notes in
> the upgrading from buster part. I am happy to propose some text for
> that if it is agreed.

This indeed sounds like something that could be mentioned under the
"issues to be aware of" section. A proposal text would help the process
forward.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#978773: bmake: ftbfs with autoconf 2.70

[Boyuan Yang]

Control: tags -1 +patch
X-Debbugs-CC: andre...@debian.org

Hi,

On Thu, 31 Dec 2020 14:26:45 + Matthias Klose  wrote:
> Package: src:bmake
> Version: 20200710-5
> Severity: normal
> Tags: sid bookworm
> User: d...@debian.org
> Usertags: ftbfs-ac270
> 
> [This bug report is not targeted to the upcoming bullseye release]
> 
> The package fails to build in a test rebuild on at least amd64 with
> autoconf 2.70, but succeeds to build with autoconf 2.69.

The build error is caused by upstream using autotools macros without proper
escaping. I am attaching a patch that corrects the syntax and makes the build
pass. (Simply place it into debian/patches dir.)

-- 
Regards,
Boyuan Yang
From: Boyuan Yang 
Date: Thu, 30 Sep 2021 16:07:03 -0400
Subject: autoconf2.70 fix

---
 configure.in | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/configure.in b/configure.in
index 5b45329..c945a96 100644
--- a/configure.in
+++ b/configure.in
@@ -122,17 +122,16 @@ if test $bmake_path_max -gt 1024; then
bmake_path_max=1024
 fi
 echo "Using: BMAKE_PATH_MAX=$bmake_path_max" >&6
-AC_SUBST(bmake_path_max)dnl
+AC_SUBST([bmake_path_max])dnl
 dnl
 dnl AC_C_CROSS
 dnl
 
 dnl Checks for header files.
-AC_INCLUDES_DEFAULT
 AC_HEADER_SYS_WAIT
 AC_HEADER_DIRENT
 dnl Keep this list sorted
-AC_CHECK_HEADERS(sys/param.h)
+AC_CHECK_HEADERS([sys/param.h])
 dnl On BSDi at least we really need sys/param.h for sys/sysctl.h
 AC_CHECK_HEADERS([sys/sysctl.h], [], [],
 [#ifdef HAVE_SYS_PARAM_H
@@ -161,17 +160,17 @@ dnl Both *BSD and Linux have sys/cdefs.h, most do not.
 dnl If it is missing, we add -I${srcdir}/missing to CFLAGS
 dnl also if sys/cdefs.h does not have __RCSID we need to use ours
 dnl but we need to include the host's one too *sigh*
-AC_CHECK_HEADER(sys/cdefs.h,
-echo $ECHO_N "checking whether sys/cdefs.h is compatible... $ECHO_C" >&6
+AC_CHECK_HEADER([sys/cdefs.h],
+[echo $ECHO_N "checking whether sys/cdefs.h is compatible... $ECHO_C" >&6
 AC_EGREP_CPP(yes,
 [#include 
 #ifdef __RCSID
 yes
 #endif
 ],
-echo yes  >&6,
-echo no  >&6; CPPFLAGS="${CPPFLAGS} -I`cd ${srcdir}/missing && pwd` -DNEED_HOST_CDEFS_H"),
-CPPFLAGS="${CPPFLAGS} -I`cd ${srcdir}/missing && pwd`")
+[echo yes  >&6,
+echo no  >&6; CPPFLAGS="${CPPFLAGS} -I`cd ${srcdir}/missing && pwd` -DNEED_HOST_CDEFS_H"])],
+[CPPFLAGS="${CPPFLAGS} -I`cd ${srcdir}/missing && pwd`"])
 
 dnl Checks for typedefs, structures, and compiler characteristics.
 AC_C___ATTRIBUTE__


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

Bug#995418: python-colorlog breaks macsyfinder autopkgtest: module 'colorlog' has no attribute 'logging'

[Paul Gevers]

Source: python-colorlog, macsyfinder
Control: found -1 python-colorlog/6.4.1-1
Control: found -1 macsyfinder/2.0~rc1-3
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of python-colorlog the autopkgtest of macsyfinder
fails in testing when that autopkgtest is run with the binary packages
of python-colorlog from unstable. It passes when run with only packages
from testing. In tabular form:

   passfail
python-colorlogfrom testing6.4.1-1
macsyfinderfrom testing2.0~rc1-3
all others from testingfrom testing

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

Currently this regression is blocking the migration of python-colorlog
to testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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=python-colorlog

https://ci.debian.net/data/autopkgtest/testing/amd64/m/macsyfinder/15629571/log.gz

==
ERROR: test_gembase (test_functional_test.Test)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/tests/test_functional_test.py",
line 77, in test_gembase
self._macsyfinder_run(args)
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/tests/test_functional_test.py",
line 417, in _macsyfinder_run
macsyfinder.main(args=args.split(),
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/scripts/macsyfinder.py",
line 799, in main
macsypy.init_logger(log_file=os.path.join(config.working_dir(),
config.log_file()),
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/__init__.py",
line 48, in init_logger
logging = colorlog.logging.logging
AttributeError: module 'colorlog' has no attribute 'logging'

==
ERROR: test_model_unknown (test_functional_test.Test)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/tests/test_functional_test.py",
line 403, in test_model_unknown
macsyfinder.main(args=args.split(), loglevel='ERROR')
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/scripts/macsyfinder.py",
line 799, in main
macsypy.init_logger(log_file=os.path.join(config.working_dir(),
config.log_file()),
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/__init__.py",
line 48, in init_logger
logging = colorlog.logging.logging
AttributeError: module 'colorlog' has no attribute 'logging'

==
ERROR: test_no_db_type (test_functional_test.Test)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/tests/test_functional_test.py",
line 387, in test_no_db_type
macsyfinder.main(args=args.split(), loglevel='ERROR')
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/scripts/macsyfinder.py",
line 799, in main
macsypy.init_logger(log_file=os.path.join(config.working_dir(),
config.log_file()),
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/__init__.py",
line 48, in init_logger
logging = colorlog.logging.logging
AttributeError: module 'colorlog' has no attribute 'logging'

==
ERROR: test_no_models (test_functional_test.Test)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/tests/test_functional_test.py",
line 358, in test_no_models
macsyfinder.main(args=args.split(), loglevel='ERROR')
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/scripts/macsyfinder.py",
line 799, in main
macsypy.init_logger(log_file=os.path.join(config.working_dir(),
config.log_file()),
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build.Lv8/src/macsypy/__init__.py",
line 48, in init_logger
logging = colorlog.logging.logging
AttributeError: module 'colorlog' has no attribute 'logging'

==
ERROR: test_no_seq_db (test_functional_test.Test)
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.01odxjz7/downtmp/build

Bug#995162: cannot install together with i386

[Mattia Rizzolo]

On Thu, Sep 30, 2021 at 09:27:50PM +0200, Giovanni Mascellani wrote:
> Thanks for the info. Unless I am mistaken, this means that any package which
> installs a shared PNG breaks at every binNMU, unless the binNMU is for all
> architectures. Wouldn't it be better if dh_strip_nondeterminism used the
> last sourceful upload as reference timestamp? Was this option considered?

It has been considered, but I can tell you that it's _much_ more complex
than just that.  For starters, there would be a huge layer violation in
doing so: the timestamp to use in the normalization comes from dpkg.
Also, normalizing to the previous sourceful upload date is quite likely
to resurface other bugs such what https://bugs.debian.org/843773 tried to fix.

I can add that there are quite many other packages affected by this
(currently 58 binaries), and regularly they cycle as they are binNMUed
and then re-uploaded.  Fortunately this pretty much only affects -dev
and some perl-* packages, and not many people try to cross-coinstall
those packages (as opposed to pure libraries), so the bug doesn't
resurface too often.

I'll leave with the relevant "toolchain" bug: https://bugs.debian.org/969501
(which is what I consider a very valid technical non-full solution of
the problem), and what realistically is the one final solution:
https://bugs.debian.org/894441

Realistically, package-wise, I think they would good by not placing PNGs
in arch:any packages, that would side-step this issue.  And it's the
proper thing to do anyway so why not.  More than that, I don't think
they should bother excessively unless somebody reports them.

-- 
regards,
Mattia Rizzolo

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

Bug#994892: evdi-dkms: fails to build for kernel 5.14.0-1

[Justin Searle]

I can confirm I am having the same issue for the last few weeks, with
the same make.log error messages, resulting in no graphics upon boot.
Only solution I've found so far is to remove the 5.14 kernel.  All
other packages are fully updated to Sid.

Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709

[Hans van Kranenburg]

Hi spi, Salvatore,

On 8/5/21 1:58 PM, s...@gmxpro.de wrote:
> 
> In preparation for the bug report for upstream I did some more
> investigation.
> 
> The kernel panic also occurs without bonding interfaces but needs much
> more time to happen. With a bonding interface it happens within some
> seconds. Without bonding interfaces it needs like a minute with the
> network discovery being re-launched for 2 or 3 times. The kernel panic
> is still the same about the bnx2 driver.
> 
> In the constellation without a bonding interface the kernel panic only
> occurs if
> - opnsense as a domU is running (this domU bounds all bridged interfaces
> as default gateway for all networks)

Just FWIW, I'm seeing this bug-mail-thread now, and it rings a bell.

I spent some time in the past to debug crashing BCM5719 (4x1G) nics in
HP DL360 G8/9 series servers. In this case, the firmware inside the nic
crashed, so the symptoms were different. This happened only when having
a Xen domU active as router, which was routing incoming traffic packets
(from outside the box) back to the outside again.

02:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)
02:00.1 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)
02:00.2 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)
02:00.3 Ethernet controller: Broadcom Limited NetXtreme BCM5719 Gigabit
Ethernet PCIe (rev 01)

Also, 2x 1G were bonded, I use openvswitch with LACP for that.

The symptoms are obviously different, mine looked like this:

tg3 :02:00.2 eth1: transmit timed out, resetting
tg3 :02:00.2 eth1: 0x: 0x165714e4, 0x00100546, 0x0201,
0x00800010
tg3 :02:00.2 eth1: 0x0010: 0x92b3000c, 0x, 0x92b4000c,
0x
tg3 :02:00.2 eth1: 0x0020: 0x92b5000c, 0x, 0x,
0x22be103c

tg3 :02:00.2 eth1: 0x7000: 0x0808, 0x, 0x,
0x4cd8
tg3 :02:00.2 eth1: 0x7010: 0xdbbd2b97, 0x010080f3, 0x00d70081,
0x03008200
tg3 :02:00.2 eth1: 0x7020: 0x, 0x, 0x0406,
0x10004000
tg3 :02:00.2 eth1: 0x7030: 0x0002, 0x4cdc, 0x001f,
0x
tg3 :02:00.2 eth1: 0: Host status block
[0001:0070:(:0563:):(:0094)]
tg3 :02:00.2 eth1: 0: NAPI info
[0070:0070:(016a:0094:01ff)::(068c:::)]
tg3 :02:00.2 eth1: 1: Host status block
[0001:0083:(::):(015b:)]
tg3 :02:00.2 eth1: 1: NAPI info
[0051:0051:(::01ff):0124:(0124:0124::)]
tg3 :02:00.2 eth1: 2: Host status block
[0001:00d8:(0e96::):(:)]
tg3 :02:00.2 eth1: 2: NAPI info
[00a4:00a4:(::01ff):0e5b:(065b:065b::)]
tg3 :02:00.2 eth1: 3: Host status block
[0001:0013:(::):(:)]
tg3 :02:00.2 eth1: 3: NAPI info
[00f8:00f8:(::01ff):072f:(072f:072f::)]
tg3 :02:00.2 eth1: 4: Host status block
[0001:009c:(::0736):(:)]
tg3 :02:00.2 eth1: 4: NAPI info
[007c:007c:(::01ff):0716:(0716:0716::)]
tg3 :02:00.2: tg3_stop_block timed out, ofs=1400 enable_bit=2
tg3 :02:00.2: tg3_stop_block timed out, ofs=c00 enable_bit=2
tg3 :02:00.2 eth1: Link is down
tg3 :02:00.2 eth1: Link is up at 1000 Mbps, full duplex
tg3 :02:00.2 eth1: Flow control is off for TX and off for RX
tg3 :02:00.2 eth1: EEE is disabled

> - sysctl parameter net.bridge.bridge-nf-call-ip6tables is set to 0.
> 
> If both conditions are not met no kernel panic oaccurs.

What I found out in the end is that using `ethtool -K $iface tso off` is
a workaround to not make it trigger some obscure bug inside the nic that
makes it crash.

So, I think my actual suggestion would be, even while it does not look
like the same thing, but it's still Broadcom stuff which can have
*cough* weird issues... if you can reliably reproduce the problem, then
can you try setting tso off on the physical interfaces in dom0 and try
again? In Dutch we say "nooit geschoten altijd mis".

> Other IPv6 related sysctl parameters are set on dom0 like
> net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.lo.disable_ipv6 = 1
> 
> 
> The layer2-iptables settings are
> net.bridge.bridge-nf-call-ip6tables = 0 ***
> 
> 
> net.bridge.bridge-nf-call-iptables = 1
> 
> 
> net.bridge.bridge-nf-call-arptables = 0
> 
> 
> 
> 
> As said, if I don't set the one marked with *** to 0 there is no kernel
> panic.
> 
> I wonder if this still is a kernel issue but still wouldn't expect a
> kernel panic to happen.
> 
> Cheers,
> spi
> 

Have fun,
Hans

Bug#995417: python-requests-oauthlib: please update to current upstream version 1.3.0

[Dominik George]

Source: python-requests-oauthlib
Version: 1.0.0-1.1
Severity: wishlist

Please update this package to the current upstream version.

I would also like to suggest moving this to team maintenance under the Python 
Packaging team.

Thanks,
Nik

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:da:sv
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#995412: libstring-copyright-perl breaks licensecheck autopkgtest: lots of different outputs

[Jonas Smedegaard]

Quoting Paul Gevers (2021-09-30 21:34:54)
> With a recent upload of libstring-copyright-perl the autopkgtest of 
> licensecheck fails in testing when that autopkgtest is run with the 
> binary packages of libstring-copyright-perl from unstable. It passes 
> when run with only packages from testing. In tabular form:
> 
>  passfail
> libstring-copyright-perl from testing0.003011-1
> licensecheck from testing3.2.11-1
> all others from testingfrom testing

Thanks for filing this, Paul.

It is caused by changes to String::Copyright affecting how wrongly coded 
data is handled.  String::Copyright is documented to take strings as 
input, not raw data, yet its testsuite tests cases of feeding it 
misencoded data - and App::Licensecheck tests even more.

I'll get around to fixing this.  Thanks again,

 - Jonas

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

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

signature.asc
Description: signature

Bug#995416: netgen: autopkgtest regression on armhf: Fatal Python error: Bus error

[Paul Gevers]

Source: netgen
Version: 6.2.2006+really6.2.1905+dfsg-4
X-Debbugs-CC: debian...@lists.debian.org
Severity: important
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Thanks for fixing bug #993533. However, with the introduction of the
improved autopkgtest, the test fails on armhf. I note that the failure
already happens during the build of your package, while it builds fine
on the buildd. Can you help understanding what could be going wrong and
what's essential in the difference of our host and the buildd?

Currently this regression is blocking the migration to testing [1]. I've
filed this bug not at the regular severity of serious as it's the build
that already fails, but we need to come to an agreement of how to proceed.

Paul

By the way, the intention of autopkgtest usage in Debian is to test the
as-installed binaries. I *think* you're only testing the build artifacts
of the current run. Is it feasible to have the tests as you run them use
the installed binaries?

[1] https://qa.debian.org/excuses.php?package=netgen

https://ci.debian.net/data/autopkgtest/testing/armhf/n/netgen/15627976/log.gz

cd tests/pytest && \

PYTHONPATH=/tmp/autopkgtest-lxc.aj0csnj9/downtmp/build.ieK/src/debian/tmp/usr/lib/python3/dist-packages
\

LD_LIBRARY_PATH=/tmp/autopkgtest-lxc.aj0csnj9/downtmp/build.ieK/src/debian/tmp/usr/lib/arm-linux-gnueabihf
\
  python3 -m pytest
= test session starts
==
platform linux -- Python 3.9.7, pytest-6.0.2, py-1.10.0, pluggy-0.13.0
rootdir: /tmp/autopkgtest-lxc.aj0csnj9/downtmp/build.ieK/src/tests/pytest
collected 7 items

test_gui.py s
 [ 14%]
test_pickling.py Fatal Python error: Bus error

Current thread 0xf7af5730 (most recent call first):
  File
"/tmp/autopkgtest-lxc.aj0csnj9/downtmp/build.ieK/src/tests/pytest/test_pickling.py",
line 31 in test_pickle_csg
  File "/usr/lib/python3/dist-packages/_pytest/python.py", line 180 in
pytest_pyfunc_call
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in

  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in
_hookexec
  File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in
__call__
  File "/usr/lib/python3/dist-packages/_pytest/python.py", line 1570 in
runtest
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 153 in
pytest_runtest_call
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in

  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in
_hookexec
  File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in
__call__
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 247 in

  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 294 in
from_call
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 246 in
call_runtest_hook
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 207 in
call_and_report
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 117 in
runtestprotocol
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 100 in
pytest_runtest_protocol
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in

  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in
_hookexec
  File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in
__call__
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 321 in
pytest_runtestloop
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in

  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in
_hookexec
  File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in
__call__
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 296 in _main
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 240 in
wrap_session
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 289 in
pytest_cmdline_main
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187 in
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83 in

  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92 in
_hookexec
  File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286 in
__call__
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line
157 in main
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line
180 in console_main
  File "/usr/lib/python3/dist-packages/pytest/__main__.py", line 7 in

  File "/usr/lib/python3.9/runpy.py", line 87 in _run_code
  File "/usr/lib/python3.9/runpy.py", line 197 in _run_module_as_main
Bus error



OpenPGP_signature
Description: OpenPGP digital signat

Bug#995308: libcrypt1: symlink points to libpthread

[shichimohedron]

>Can you please try to call /usr/sbin/ldconfig.old to check if the wrong
link is recreated? That's needed to confirm if ldconfig is the culprit
here.
>Can you confirm it's libpthread.so.1 and not libpthread.so.0? If so can
you please tell how did you install that file?

Here is a shell log, literally

~# ls -l /lib/x86_64-linux-gnu/ | grep libcrypt
-rw-r--r--  1 root root266262 Apr 18 20:46 libcrypt.a
lrwxrwxrwx  1 root root35 Apr 18 20:46 libcrypt.so -> 
/lib/x86_64-linux-gnu/libcrypt.so.1
lrwxrwxrwx  1 root root17 Apr 18 20:46 libcrypt.so.1 -> 
libcrypt.so.1.1.0
-rw-r--r--  1 root root202680 Apr 18 20:46 libcrypt.so.1.1.0
~# /usr/sbin/ldconfig.old
~# ls -l /lib/x86_64-linux-gnu/ | grep libcrypt
-rw-r--r--  1 root root266262 Apr 18 20:46 libcrypt.a
lrwxrwxrwx  1 root root35 Apr 18 20:46 libcrypt.so -> 
/lib/x86_64-linux-gnu/libcrypt.so.1
lrwxrwxrwx  1 root root15 Sep 30 07:53 libcrypt.so.1 -> libpthread.so.1
-rw-r--r--  1 root root202680 Apr 18 20:46 libcrypt.so.1.1.0

I struggle to reveal the origins of libpthread.so.1. It can easily be a result 
of unqualified experimentation, but not necessarily. Of course, if this is the 
case its presence in the system is completely my fault and not in any sense 
yours. Anyway, dpkg -S doesn't match it with any of packages currently 
installed, and another attempts to guess where the library comes from didn't 
lead to any answer.

Bug#991632: buster-pu: package node-jszip/3.1.4+dfsg-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Thu, 2021-07-29 at 13:07 +0200, Yadd wrote:
> node-jszip is vulnerable to a prototype pollution (CVE-2021-23413)
> 

+  * Fix a null prototype object for this.files (Closes: CVE-2021-
23413)

As far as I can tell, you're fixing an issue by *using* a null
prototype object, whereas the changelog entry above implies that you're
removing such a use.

Regards,

Adam

Bug#995414: neomutt: pager sometimes displays the wrong mail content

[Jonathan Dowland]

Package: neomutt
Version: 20201127+dfsg.1-1.2
Severity: important

I think this is going to be a pretty difficult one to figure out!

Sometimes, when viewing my INBOX (at least; perhaps other folders
too) and selecting a mail to view in the pager, the wrong mail is
displayed in the pager. It's a mail from the same thread (I think
this only happens with messages in threads), possibly (but I have
not confirmed this) always an 'adjacent' mail.

A consequence of this, when it happens, is I'm really hesitant to 
delete mails, since I can't be sure I will be deleting the right
messages.

My config: invoke neomutt via an alias m=neomutt. I'll attach all
my config files to this email or a follow-up.  (Sorry, they are a
mess).  I use neomutt with IMAP.

-- Package-specific info:
NeoMutt 20201127
Copyright (C) 1996-2020 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 5.10.0-6-amd64 (x86_64)
ncurses: ncurses 6.2.20201114 (compiled with 6.2.20201114)
libidn: 1.33 (compiled with 1.33)
GPGME: 1.14.0-unknown
GnuTLS: 3.7.1
libnotmuch: 5.3.0
storage: tokyocabinet

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
{--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet --sqlite --autocrypt

Compilation CFLAGS: -g -O2 
-ffile-prefix-map=/build/neomutt-aFsTyZ/neomutt-20201127+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.4 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  +autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens 
  +getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify 
  -locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +regex +sasl 
  +smime +sqlite +start_color +sun_attachment +typeahead 
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (999, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-6-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages neomutt depends on:
ii  libc6 2.32-4
ii  libgnutls30   3.7.1-5
ii  libgpg-error0 1.38-2
ii  libgpgme111.14.0-1+b2
ii  libgssapi-krb5-2  1.18.3-6
ii  libidn11  1.33-3
ii  liblua5.4-0   5.4.2-2
ii  libncursesw6  6.2+20201114-2
ii  libnotmuch5   0.31.4-2
ii  libsasl2-22.1.27+dfsg-2.1
ii  libsqlite3-0  3.34.1-3
ii  libtinfo6 6.2+20201114-2
ii  libtokyocabinet9  1.4.48-13
ii  sensible-utils0.0.14

Versions of packages neomutt recommends:
ii  libsasl2-modules  2.1.27+dfsg-2.1
ii  locales   2.32-4
ii  mime-support  3.66

Versions of packages neomutt suggests:
ii  aspell 0.60.8-3
ii  ca-certificates20210119
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
ii  gnupg  2.2.27-2
ii  ispell 3.4.02-2
pn  mixmaster  
ii  openssl1.1.1k-1+deb11u1
ii  urlview0.9-21+b1

Versions of packages neomutt is related to:
ii  neomutt  20201127+dfsg.1-1.2

-- no debconf information

-- 
👱🏻  Jona

Bug#995413: fcitx5-chinese-addons: qtwebengine is now also available on mips64el

[Adrian Bunk]

Source: fcitx5-chinese-addons
Version: 5.0.7-1
Severity: normal

qtwebengine5-dev is now available on mips64el,
please change debian/control and debian/rules to use it.

Bug#992117: buster-pu: package node-tar/4.4.6+ds1-3+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-08-12 at 00:11 +0200, Yadd wrote:
> node-tar is vulnerable to 2 CVE:
>  * #992110, CVE-2021-32803: arbitrary File Creation/Overwrite
>vulnerability via insufficient symlink protection
>  * #992111, CVE-2021-32804: arbitrary File Creation/Overwrite
>vulnerability due to insufficient absolute path sanitization
> 

Please go ahead.

Regards,

Adam

Bug#991811: unblock: libapache2-mod-auth-openidc/2.4.9-1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Mon, 2021-08-23 at 14:46 +0200, Salvatore Bonaccorso wrote:
> Hi Christoph,
> 
> On Mon, Aug 23, 2021 at 01:17:18PM +0200, Christoph Martin wrote:
> > Hi Salvatore,
> > 
> > Am 19.08.21 um 21:32 schrieb Salvatore Bonaccorso:
> > > Hi Christoph,
> > > 
> > > On Tue, Aug 10, 2021 at 01:42:32PM +0200, Christoph Martin wrote:
> > > > Dear Security Team,
> > > > 
> > > > the fixed version is now in bullseye. Thanks for that.
> > > > 
> > > > What is the plan for buster and stretch? Do you prepare fixes?
> > > 
> > > thanks for following up on that. For buster, can you fix those
> > > issues,
> > > and ideally as well CVE-2019-14857 (#942165) and CVE-2019-20479
> > > via an
> > > upcoming buster point release?
> > 
> > Ok. I prepare that update. That would be a version 2.4.9-1~deb11u1
> > ?
> 
> Depends (but then ~deb10u1). Why i say depends: buster has currently
> 2.3.10.2-1, and I'm not sure if we can be confident to bump the
> version from 2.3.10.2 upstream to 2.4.9? This has to be acked by the
> release team if suitable.
> 
> If SRM agree on importing the 2.4.9 version: if it is merely a
> rebuild
> of the bullseye package back for buster, then 2.4.9-1~deb10u1 would
> be
> good, if it's an import of new upstream on top of the current
> packaging instead I would choose 2.4.9-0+deb10u1.
> 
> But the most important question here is if SRM agree on bumping the
> version to 2.4.9.

We'd really need to see what that looks like first.

Regards,

Adam

Bug#994513: buster-pu: package debconf/1.5.71+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2021-09-17 at 00:16 +0100, Colin Watson wrote:
> https://bugs.debian.org/984533 and its clone
> https://bugs.debian.org/985572 showed a buster-to-bullseye upgrade
> bug in which debconf was unable to execute whiptail between unpacking
> the new libslang2 and unpacking the new libc6.  Part of the fix for
> that involved adjusting debconf in bullseye to detect this situation
> and gracefully fall back to text mode.  The other part of the fix was
> to adjust libc6.preinst to do something similar, in case debconf has
> not yet been upgraded or the running debconf frontend is still from
> an old version.
> 
> Unfortunately, the code in libc6.preinst was somewhat broken,
> resulting in buster-to-bullseye upgrades that hang in some
> situations.  We only noticed this after bullseye released because the
> breakage is only apparent with certain package sets that provoke apt
> into choosing particular upgrade orderings; even with this, I only
> know of it happening for people who run "apt upgrade" as a separate
> step before "apt full-upgrade" (IMO unnecessarily, but it seems to be
> some people's habit).  https://bugs.debian.org/994042 has an analysis
> of the situation situation and a reproduction recipe.
> 
> While fixing this particular upgrade bug requires fixing
> libc6.preinst (because its broken logic happens before debconf has an
> opportunity to decide what to do), it's possible for apt to attempt
> to unpack some *other* package between unpacking the new libslang2
> and the new libc6 which also tries to use debconf in its preinst, and
> that would run into a similar bug.  (I admit to not having a concrete
> example of such an upgrade ordering.)  The only way to fix that
> situation is to cherry- pick the fix for #985572 into debconf in
> buster.  As Aurelien points out in
> #994042, we can't rely on people having applied all buster updates
> before starting the upgrade to bullseye.  Nevertheless, I think this
> change would make upgrades more robust, since debconf must take great
> care not to crash like this.
> 

Please go ahead; thanks.

Regards,

Adam

Bug#995162: cannot install together with i386

[Giovanni Mascellani]

Hi Mattia,

Il 29/09/21 19:28, Mattia Rizzolo ha scritto:

This is triggered by the binNMU, which varies the date of the changelog,
so that dh_strip_nondeterminism will normalize the metadata of the .png
to the binNMU build time instead of the time of the source upload as it
was before.


Thanks for the info. Unless I am mistaken, this means that any package 
which installs a shared PNG breaks at every binNMU, unless the binNMU is 
for all architectures. Wouldn't it be better if dh_strip_nondeterminism 
used the last sourceful upload as reference timestamp? Was this option 
considered?


Thanks, Giovanni.
--
Giovanni Mascellani 

Bug#995412: libstring-copyright-perl breaks licensecheck autopkgtest: lots of different outputs

[Paul Gevers]

yright {
ok 1 - Can run '/usr/bin/licensecheck -m --copyright t/devscripts/gpl-2'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck -m --copyright
t/devscripts/gpl-2' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
ok 9 - Fortran comments {
ok 1 - Can run '/usr/bin/licensecheck t/devscripts/bsd.f'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck t/devscripts/bsd.f' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
ok 10 - comments; C++ inline style {
ok 1 - Can run '/usr/bin/licensecheck t/devscripts/comments-detection.h'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck
t/devscripts/comments-detection.h' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
ok 11 - comments; hash style {
ok 1 - Can run '/usr/bin/licensecheck
t/devscripts/comments-detection.txt'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck
t/devscripts/comments-detection.txt' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
ok 12 - false positives {
ok 1 - Can run '/usr/bin/licensecheck -m --copyright
t/devscripts/false-positives'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck -m --copyright
t/devscripts/false-positives' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
ok 13 - regexp killer {
ok 1 - Can run '/usr/bin/licensecheck t/devscripts/regexp-killer.c'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck
t/devscripts/regexp-killer.c' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
ok 14 - info at end {
ok 1 - Can run '/usr/bin/licensecheck -m --shortname-scheme=debian
--copyright --lines 0 t/devscripts/info-at-eof.h'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck -m
--shortname-scheme=debian --copyright --lines 0
t/devscripts/info-at-eof.h' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
ok
t/encoding.t .
# Seeded srand with seed '20210930' from local date.
1..13
# locale encoding: UTF-8
ok 1 - Latin-1 in UTF-8 parsed as UTF-8 returns chars {
ok 1 - Can run '/usr/bin/licensecheck -m --copyright --encoding utf8
t/encoding/copr-utf8.h'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck -m --copyright
--encoding utf8 t/encoding/copr-utf8.h' is 0
ok 4 - Testing stdout
ok 5 - No stderr
1..5
}
not ok 2 - Latin-1 in UTF-8 parsed by default returns mojibake {
ok 1 - Can run '/usr/bin/licensecheck -m --copyright
t/encoding/copr-utf8.h'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck -m --copyright
t/encoding/copr-utf8.h' is 0
not ok 4 - Testing stdout
# Failed test 'Testing stdout'
# at t/encoding.t line 55.
# +---++---+
# | GOT   | OP | CHECK |
# +---++---+
# | t/encoding/copr-utf8.h\tGNU G | eq | t/encoding/copr-utf8.h\tGNU G |
# | eneral Public License v2.0 or || eneral Public License v2.0 or |
# |  later\t2004-2015 Oliva 'f00' ||  later\t2004-2015 Oliva 'f00' |
# |  Oberto / 2001-2010 Paul 'bar ||  Oberto / 2001-2010 Paul 'bar |
# | ' Stevénsön\n   || ' Stev�\N{U+83}©ns�\N{U+83}� |
# |   || �n\n  |
# +---++---+
ok 5 - No stderr
1..5
}

# Failed test 'Latin-1 in UTF-8 parsed by default returns mojibake'
# at t/encoding.t line 57.
not ok 3 - Latin-1 in UTF-8 parsed by guessing returns chars {
ok 1 - Can run '/usr/bin/licensecheck -m --copyright --encoding
Guess t/encoding/copr-utf8.h'
ok 2 - Process terminated without a signal
ok 3 - Check return from '/usr/bin/licensecheck -m --copyright
--encoding Guess t/encoding/copr-utf8.h' is 0
not ok 4 - Testing stdout
# Failed test 'Testing stdout'
# at t/encoding.t line 60.
# +---++---+
# | GOT   | OP | CHECK |
# +---++---+
# | t/encoding/copr-utf8.h\tGNU G | eq | t/

Bug#994583: buster-pu: package node-axios/0.17.1+dfsg-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2021-09-18 at 07:36 +0200, Yadd wrote:
> Another regex denial of service
> 

Please go ahead.

Regards,

Adam

Bug#994829: buster-pu: package node-prismjs/1.11.0+dfsg-3+deb10u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Tue, 2021-09-21 at 14:56 +0200, Yadd wrote:
> node-prismjs is vulnerable to a Regex Denial of Service (ReDoS)
> (CVE-2021-40438)
> 

As with the bullseye request, that appears to be the wrong CVE number.

Regards,

Adam

Bug#995144: bullseye-pu: package jailkit/2.21-4+deb11u1

[Eriberto]

Em qui., 30 de set. de 2021 às 16:24, Adam D. Barratt
 escreveu:
>
> Control: tags -1 + confirmed
>
> On Sun, 2021-09-26 at 23:01 -0300, Joao Eriberto Mota Filho wrote:
> > This update is not for a regression. There are two bugs discovered
> > recently.
> > With these bugs, jailkit will work partially. The bugs are #992420
> > and #992422.
> >
>
> +  * debian/patches/:
> +  - 050_fix-incorrect-device.patch: created to fix the incorrect calc of
> +device major number. Without this patch, jailkit won't be able to
> +create jails that needs a device from /dev. Thanks to Jesse Norell
> +. (Closes: #992422)
>
> s/needs/need/
>
> +  - 060_fix-typo-jk_init.patch: created to fix a typo in 
> /usr/sbin/jk_init.
> +Without this patch, jailkit won't be able to check the presence of
> +some libraries. Thanks to Peter Viskup .
> +(Closes: #992420)
>
> s/check the/check for the/
>
> Please go ahead.

Thank you Adam. Fixed the errors and sent the package.

Have a nice day!

Regards,

Eriberto

Bug#994943: buster-pu: package atftp/0.7.git20120829-3.2~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-09-23 at 17:47 +0200, Andreas B. Mundt wrote:
> I would like to ask for permission to upload a new atftpd 
> package 0.7.git20120829-3.2+deb10u2 to fix #994895, buffer
> overflow, CVE-2021-41054.
> 

The diff here has the same s/save/safe/g issue as the bullseye diff,
fwiw.

[...]
> 
> I chose the package version to increases from -3.2~deb10u1 to
> -3.2+deb10u2

It's not a huge issue, but why? The conventional successor to ~deb10u1
is ~deb10u2.

I'd prefer the "~" versioning, but in any case please go ahead.

Regards,

Adam

Bug#994862: buster-pu: package node-ansi-regex/3.0.0-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2021-09-22 at 09:15 +0200, Yadd wrote:
> node-ansi-regex is vulnerable to a ReDoS (CVE-2021-3807)
> 

Please go ahead.

Regards,

Adam

Bug#995406: bbmap: package does not ship resource files

[Andreas Tille]

Control: tags -1 pending

Hi Robert,

thanks a lot for the

Am Thu, Sep 30, 2021 at 01:22:23PM -0400 schrieb Robert:
> The bbmap package does not ship the needed resource files which causes some of
> the included tools not to work, e.g. bbduk when trying to process some fastq
> data, crashes with output like [1].

Thanks a lot for the report.  Its extremely helpful since several of our
maintainers are not using this software and we really need to rely on
user input.
 
> I don't have a census which other bbtools require resource files to be usable,
> but bbduk is not usable at all in the current state.
> 
> My suggested fix (see patch [2]) puts the resource files to the root of
> the built jar file.  This is were dna.Data.findPath() will indeed find
> these files, which can be seen when looking at the verbose output [3]
> for findPath() (by setting vb=true in current/dna.Data.java near line
> 1204).  By contrast, the current packaging tries (but also fails) to put
> the files under resources/.  I don't see a way to trick jh_build with
> the JH_JAR_EXTRA mechanism to do what is needed (without changes to
> jh_build).  The patch applies agaiinst the bbmap source package's
> current git master branch and the package builds and run for me on
> bullseye.

I've pushed your patch to Git and can upload soon, but I wonder wether
we could your use case use as autopkgtest.
 
> $ pwd
> /tmp/bbduk_test
> $ ls
> fwd.fastq  rev.fastq

Could you provide these data as examples - or do you have some similar
ones we could use.

> $ bbduk.sh in1=fwd.fastq in2=rev.fastq ktrim=r k=21 mink=8 hdist=2 ftm=5 tpe 
> tbo threads=48 out=out.fastq
> java -ea -Xmx76702m -Xms76702m -cp /usr/share/java/bbmap.jar jgi.BBDuk 
> in1=fwd.fastq in2=rev.fastq ktrim=r k=21 mink=8 hdist=2 ftm=5 tpe tbo 
> threads=48 out=out.fastq
> Executing jgi.BBDuk [in1=fwd.fastq, in2=rev.fastq, ktrim=r, k=21, mink=8, 
> hdist=2, ftm=5, tpe, tbo, threads=48, out=out.fastq]
> Version 38.90
> 
> Set threads to 48
> maskMiddle was disabled because useShortKmers=true
> Warning!  Cannot find primes.txt.gz 
> /tmp/bbduk_test/file:/usr/share/java/bbmap.jar!/primes.txt.gz
>   at jgi.BBDuk.main(BBDuk.java:78)

If we could turn this into a test I could upload including test.

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Bug#995304: bullseye-pu: package pmdk/1.10-2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2021-09-29 at 15:47 +0200, Adam Borowski wrote:
> There's a bug in pmdk versions 1.9..1.11, that can cause data loss
> when
> power to the CPU is lost (ie, an unclean shutdown of the machine).
> 
> It's caused by a clash between a macro named "barrier" vs function
> pointers
> also named "barrier".
> 

Please go ahead.

Regards,

Adam

Bug#995144: bullseye-pu: package jailkit/2.21-4+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2021-09-26 at 23:01 -0300, Joao Eriberto Mota Filho wrote:
> This update is not for a regression. There are two bugs discovered
> recently.
> With these bugs, jailkit will work partially. The bugs are #992420
> and #992422.
> 

+  * debian/patches/:
+  - 050_fix-incorrect-device.patch: created to fix the incorrect calc of
+device major number. Without this patch, jailkit won't be able to
+create jails that needs a device from /dev. Thanks to Jesse Norell
+. (Closes: #992422)

s/needs/need/

+  - 060_fix-typo-jk_init.patch: created to fix a typo in /usr/sbin/jk_init.
+Without this patch, jailkit won't be able to check the presence of
+some libraries. Thanks to Peter Viskup .
+(Closes: #992420)

s/check the/check for the/

Please go ahead.

Regards,

Adam

Bug#995411: ruby-omniauth-ultraauth: autopkgtest needs update for new version of ruby-omniauth-openid-connect: Could not find 'omniauth_openid_connect' (~> 0.3.0)

[Paul Gevers]

Source: ruby-omniauth-ultraauth
Version: 0.0.2-1.1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, 
ruby-omniauth-openid-conn...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:ruby-omniauth-openid-connect

Dear maintainer(s),

With a recent upload of ruby-omniauth-openid-connect the autopkgtest of
ruby-omniauth-ultraauth fails in testing when that autopkgtest is run
with the binary packages of ruby-omniauth-openid-connect from unstable.
It passes when run with only packages from testing. In tabular form:

 passfail
ruby-omniauth-openid-connect from testing0.4.0-2
ruby-omniauth-ultraauth  from testing0.0.2-1.1
all others   from testingfrom testing

I copied some of the output at the bottom of this report. It looks to me
that you have to make your package compatible with the next version of
ruby-omniauth-openid-connect.

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

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

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

Paul

[1] https://qa.debian.org/excuses.php?package=ruby-omniauth-openid-connect

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-omniauth-ultraauth/15624243/log.gz


┌──┐
│ Checking Rubygems dependency resolution on ruby2.7
   │
└──┘

GEM_PATH= ruby2.7 -e gem\ \"omniauth-ultraauth\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in
block in activate_dependencies': Could not find
'omniauth_openid_connect' (~> 0.3.0) among 90 total gem(s)
(Gem::MissingSpecError)
Checked in
'GEM_PATH=/home/debci/.local/share/gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
at:
/usr/share/rubygems-integration/all/specifications/omniauth-ultraauth-0.0.2.gemspec,
execute `gem env` for more information
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block
in activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in
`activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
`activate'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`block in gem'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`gem'
from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:311:in `to_specs':
Could not find 'omniauth_openid_connect' (~> 0.3.0) among 90 total
gem(s) (Gem::MissingSpecError)
Checked in
'GEM_PATH=/home/debci/.local/share/gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
, execute `gem env` for more information
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block
in activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in
`activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
`activate'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`block in gem'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in
`synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`gem'
from -e:1:in `'





OpenPGP_signature
Description: OpenPGP digital signature

Bug#995410: breezy: FTBFS:

[Steve Langasek]

Source: breezy
Version: 3.2.1-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish

Hi Jelmer,

While tracking a build failure of breezy 3.2.1 in Ubuntu, I found that it is
currently also reproducible in Debian unstable:

[...]
==
ERROR: 
breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path(WorkingTreeFormat4)
--
Traceback (most recent call last):
testtools.testresult.real._StringException: log: {{{
763.552  creating repository in 
file:///tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path%28WorkingTreeFormat4%29/work/tree/.bzr/.
763.553  creating branch  in 
file:///tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path%28WorkingTreeFormat4%29/work/tree/
763.558  trying to create missing lock 
'/tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path(WorkingTreeFormat4)/work/tree/.bzr/checkout/dirstate'
763.558  opening working tree 
'/tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path(WorkingTreeFormat4)/work/tree'
}}}

Traceback (most recent call last):
  File "/tmp/breezy-3.2.1/breezy/tests/per_workingtree/test_workingtree.py", 
line 1253, in test_bad_fs_path
with open(b'tree/subdir/m\xb5', 'wb') as f:
OSError: [Errno 84] Invalid or incomplete multibyte or wide character: 
b'tree/subdir/m\xb5'

[...]
==
ERROR: 
breezy.tests.test_plugins.TestPlugins.test_1_2_3__version__with_version_info
--
Traceback (most recent call last):
testtools.testresult.real._StringException: log: {{{
853.935  loading plugins!
853.935  using _Path('breezy.testingplugins', [], [], ['.'])
853.935  Traceback (most recent call last):
  File "/tmp/breezy-3.2.1/breezy/plugin.py", line 429, in _load_plugin_module
__import__(_MODULE_PREFIX + name)
ModuleNotFoundError: No module named 'breezy.testingplugins.plugin'

853.935  Unable to load plugin 'plugin' from '.': No module named 
'breezy.testingplugins.plugin'
 WARNING  Unable to load plugin 'plugin' from '.': No module named 
'breezy.testingplugins.plugin'
853.936  removed breezy.testingplugins from sys.modules
}}}

Traceback (most recent call last):
  File "/tmp/breezy-3.2.1/breezy/tests/test_plugins.py", line 468, in 
test_1_2_3__version__with_version_info
plugin = breezy.plugin.plugins()['plugin']
KeyError: 'plugin'

[...]

(There are multiple errors of these two classes in the log, but this seems to
be the gist of it.)

I don't have capacity to dig into these failures and figure them out, but I
look forward to a resolution so the set of breezy-related packages can be
unstuck in Ubuntu again.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#995376: wsjtx: Segfault when use refspec

[Christoph Berg]

Re: Yvan Brodier
> Yes :
> 
> > recvmsg(6, {msg_namelen=0}, 0)  = -1 EAGAIN (Ressource 
> > temporairement non disponible)

I meant a backtrace from gdb:

https://wiki.debian.org/HowToGetABacktrace

Christoph

Bug#994285: libseccomp: FTBFS on arm64, armhf, mips64el and mipsel

[Felix Geyer]

Hi,

On 30.09.21 08:40, Johannes Schauer Marin Rodrigues wrote:

Hi Felix,

On Fri, 17 Sep 2021 07:15:16 +0200 Johannes Schauer Marin Rodrigues 
 wrote:

you set the upstream bug to https://github.com/seccomp/libseccomp/issues/336
but I don't think that is correct. The failures is not the same for the
different architectures. mipsel fails different than arm64. I bisected
upstream git on both architectures and found out that the arm64 failure was
introduced in aa0f858 and the mipsel failure comes from e976080.

I contacted upstream about that here:
https://github.com/seccomp/libseccomp/issues/338


the problem has no been present in unstable for three weeks. This is blocking
my work. Could we revert the offending commits or at least set a deadline up to
how long we want to wait for upstream to fix this issue?

I'm willing to put work into an NMU in case you don't have the time right now.


I've prepared a revert of the problematic commits in the git repo.

So far I've tested amd64 build+autopkgtest and mipsel build, no issues yet.

Cheers,
Felix

Bug#994086: transition: netcdf

[Sebastiaan Couwenberg]

On 9/29/21 4:19 PM, Sebastiaan Couwenberg wrote:
> On 9/29/21 10:02 AM, Sebastian Ramacher wrote:
>> Please go ahead
> 
> Thanks. netcdf (1:4.8.1-1) has been uploaded to unstable and is built &
> installed on all release architectures.

eccodes and gdal have been fixed, dependency level 3 can be binNMUed now.

Kind Regards,

Bas

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

Bug#978830: https://gitlab.com/kalilinux/packages/gtkhash

[Arnaud Rebillout]

Dear maintainer,

I had to update this package for Kali Linux. I updated it to latest 
upstream version 1.4, and cherry-picked an upstream patch to fix this FTBFS.


You can find this package at 
https://gitlab.com/kalilinux/packages/gtkhash. Please feel free to 
cherry-pick all the commits you need from there.


Alternatively, if you're not willing to maintain this package anymore, 
I'm OK to maintain it.


Cheers,

--
Arnaud Rebillout

Bug#994946: bullseye-pu: package atftp/0.7.git20120829-3.3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-09-23 at 18:07 +0200, Andreas B. Mundt wrote:
> I would like to ask for permission to upload a new atftpd 
> package 0.7.git20120829-3.3+deb11u1 to fix #994895, buffer
> overflow, CVE-2021-41054.
> 

I'm assuming this is from upstream, but as a small note:

+   *  the options here for simplicity, which puts us on the save side.

s/save/safe/ (in two lines)

Please go ahead.

Regards,

Adam

Bug#994828: bullseye-pu: package node-prismjs/1.23.0+dfsg-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Tue, 2021-09-21 at 14:49 +0200, Yadd wrote:
> node-prismjs is vulnerable to a Regex Denial of Service (ReDoS)
> (CVE-2021-40438)
> 

According to the Security Tracker, that's an Apache mod-proxy issue.

Regards,

Adam

Bug#994861: bullseye-pu: package node-ansi-regex/5.0.1-1~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2021-09-22 at 09:05 +0200, Yadd wrote:
> node-ansi-regex is vulnerable to a ReDoS (CVE-2021-3807)
> 

Please go ahead.

Regards,

Adam

Bug#994710: bullseye-pu: package nautilus/3.38.2-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2021-09-20 at 11:19 +0100, Simon McVittie wrote:
> On Mon, 20 Sep 2021 at 11:08:49 +0100, Simon McVittie wrote:
> > It seems #994710 didn't make it to the list because the diff was
> > too big.
> > Here's another try, removing the translation updates from the diff.
> 
> ... now with diff. Sorry, not enough coffee yet this morning...

Please go ahead.

Regards,

Adam

Bug#994490: bullseye-pu: package node-set-value/3.0.1-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-09-16 at 18:21 +0200, Yadd wrote:
> node-set-value is vulnerable to prototype pollution (#994448, CVE-
> 2021-23440)
> 

Please go ahead.

Regards,

Adam

Bug#994555: bullseye-pu: package node-object-path/0.11.5-3+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2021-09-17 at 18:49 +0200, Yadd wrote:
> node-object-path is vulnerable to prototye pollution (CVE-2021-23434
> and
> CVE-2021-3805
> 

The noise in the patches - spacing changes and removal of terminating
semi-colons at least - makes review quite annoying. :-(

Please go ahead.

Regards,

Adam

Bug#995409: ball: Please build depend on qtwebengine5-dev also on mips64el

[Adrian Bunk]

Source: ball
Version: 1.5.0+git20180813.37fc53c-7
Severity: normal

qtwebengine5-dev is now available on mips64el.

Bug#995331: perl 5.32.1-4+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 995331 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: perl
Version: 5.32.1-4+deb11u2

Explanation: fix a regular expression memory leak

Bug#995306: dpdk 20.11.3-1~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 995306 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: dpdk
Version: 20.11.3-1~deb11u1

Explanation: new upstream stable release

Bug#995025: pam 1.4.0-9+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 995025 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: pam
Version: 1.4.0-9+deb11u1

Explanation: fix syntax error in libpam0g.postinst when a systemd unit fails

Bug#995062: speech-dispatcher 0.10.2-2+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 995062 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: speech-dispatcher
Version: 0.10.2-2+deb11u1

Explanation: fix setting voice name for the generic module

Bug#994885: glewlwyd 2.5.2-2+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994885 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: glewlwyd
Version: 2.5.2-2+deb11u1

Explanation: fix possible buffer overflow during FIDO2 signature validation in 
webauthn registration [CVE-2021-40818]

Bug#994881: rhonabwy 0.9.13-3+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994881 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: rhonabwy
Version: 0.9.13-3+deb11u1

Explanation: fix jwe cbc tag computation and jws alg:none signature verification

Bug#994880: ulfius 2.7.1-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994880 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: ulfius
Version: 2.7.1-1+deb11u1

Explanation: ensure memory is initialised before use [CVE-2021-40540]