Bug#1005906: CIFS options

[David Eccles (gringer)]

Possibly important information: the docker container is running on a 
networked file system.


//fileShares.X.X.X/Bioinformatics on /var/autofs/Bioinformatics type 
cifs (rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,

  username=XXX,domain=XXX,uid=0,noforceuid,gid=0,
  noforcegid,addr=10.0.0.XXX,file_mode=0777,
  dir_mode=0777,nounix,serverino,mapposix,
  rsize=1048576,wsize=1048576,echo_interval=60,
  actimeo=1)

Bug#1005820: Seems better after kernel upgrade and reboot

[Erwan David]

Since I upgraded to kernel 5.16.0-1-amd64, I no longer have those 
segfault messages in the logs.  I do not known wether the kernel or the 
reboot is responsible for this

Bug#1005808: chromium: ERR_SSL_VERSION_OR_CIPHER_MISMATCH after upgrade to 98.0.4758.80

[Benoît Panizzon]

Hi Andres

> I'm a bit confused by this bug report. Why do you need chromium 
> (presumably over https) talking to network hardware drivers? Or do
> you mean you have older network hardware where the firmware exposes
> an https port, and chromium no longer supports the older SSL
> protocols that the network hardware web server is trying to
> negotiate? What specific SSL versions are we talking about?

Sorry for the confustion. I wrote the report from a user point of view,
noticing that stuff was broken after the update and that it still
worked on a machine I had not yet updated.

I work for a telco. We have some equipment that is being used long past
it's intended time. But also manufacturers often stick to old
technologies like java web applets.

So this is the ciphers supported by the affected webgui of one of our
core telephony switches:

PORTSTATE SERVICE
443/tcp open  https
| ssl-enum-ciphers: 
|   SSLv3: 
| ciphers: 
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| compressors: 
|   NULL
| cipher preference: client
| warnings: 
|   Broken cipher RC4 is deprecated by RFC 7465
|   CBC-mode cipher in SSLv3 (CVE-2014-3566)
|   Forward Secrecy not supported by any cipher
|   TLSv1.0: 
| ciphers: 
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| compressors: 
|   NULL
| cipher preference: client
| warnings: 
|   Broken cipher RC4 is deprecated by RFC 7465
|   Forward Secrecy not supported by any cipher
|_  least strength: C

I suppose TLSv1.0 and SSLv3 was completely ditched with the most recent
Chromium update.

I am aware that the SSL implementation is very unsafe, but that
equipment is in a corporate lan, not reachable from the internet
protected by additional ACL. IMHO chromium should somehow provide an
option to specify 'yes I know the risk, create an exception' to still
access such sites.

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__

Bug#1005808: chromium: ERR_SSL_VERSION_OR_CIPHER_MISMATCH after upgrade to 98.0.4758.80

[Andres Salomon]

On 2/17/22 02:21, Benoît Panizzon wrote:

Hi Andres


I'm a bit confused by this bug report. Why do you need chromium
(presumably over https) talking to network hardware drivers? Or do
you mean you have older network hardware where the firmware exposes
an https port, and chromium no longer supports the older SSL
protocols that the network hardware web server is trying to
negotiate? What specific SSL versions are we talking about?

Sorry for the confustion. I wrote the report from a user point of view,
noticing that stuff was broken after the update and that it still
worked on a machine I had not yet updated.

I work for a telco. We have some equipment that is being used long past
it's intended time. But also manufacturers often stick to old
technologies like java web applets.

So this is the ciphers supported by the affected webgui of one of our
core telephony switches:

PORTSTATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   SSLv3:
| ciphers:
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| compressors:
|   NULL
| cipher preference: client
| warnings:
|   Broken cipher RC4 is deprecated by RFC 7465
|   CBC-mode cipher in SSLv3 (CVE-2014-3566)
|   Forward Secrecy not supported by any cipher
|   TLSv1.0:
| ciphers:
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| compressors:
|   NULL
| cipher preference: client
| warnings:
|   Broken cipher RC4 is deprecated by RFC 7465
|   Forward Secrecy not supported by any cipher
|_  least strength: C

I suppose TLSv1.0 and SSLv3 was completely ditched with the most recent
Chromium update.

I am aware that the SSL implementation is very unsafe, but that
equipment is in a corporate lan, not reachable from the internet
protected by additional ACL. IMHO chromium should somehow provide an
option to specify 'yes I know the risk, create an exception' to still
access such sites.



Thanks for the explanation. What happens if you run chromium with --tls1 
? That sets the min SSL version to TLSv1.0, although I'm not sure what 
changed within chromium to actually drop TLSv1 support; if it's a third 
party library, then the code to support it might just be gone.

Bug#1004037: Segmentation fault in plink2 (Was: src:plink2: fails to migrate to testing for too long: autopkgtest regression)

[Andreas Tille]

PS to last mail:  Here

   https://salsa.debian.org/med-team/plink2/-/jobs/2479769

is a full test log in our Gitlab CI for the latest version which I just
injected into the packaging Git repository but did not upload yet.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#1004037: Segmentation fault in plink2 (Was: src:plink2: fails to migrate to testing for too long: autopkgtest regression)

[Andreas Tille]

Control: reopen -1
Control: tags -1 confirmed
Control: tags -1 upstream
Control: forwarded -1 Christopher Chang 

Hi Christopher (and Dylan),

I verified the latest version (29 Jan 2022) of plink2 with the same
result for the CI test we are doing in Debian (which was written by
Dylan):

$ plink2 --dummy 33 65537 0.1 dosage-freq=0.1 --out tmp_data
PLINK v2.00a3 SSE4.2 (29 Jan 2022) www.cog-genomics.org/plink/2.0/
(C) 2005-2022 Shaun Purcell, Christopher Chang   GNU General Public License v3
Logging to tmp_data.log.
Options in effect:
  --dummy 33 65537 0.1 dosage-freq=0.1
  --out tmp_data

Start time: Thu Feb 17 06:34:30 2022
31998 MiB RAM detected; reserving 15999 MiB for main workspace.
Using up to 4 compute threads.
Dummy data (33 samples, 65537 SNPs) written to tmp_data.pgen + tmp_data.pvar +
tmp_data.psam .
End time: Thu Feb 17 06:34:30 2022
/usr/bin/plink2: line 8:   156 Segmentation fault  "${cmd}" "$@"


Please note that for the build the Debian packaged zstd and libdeflate
are used.  This is the same result as for the version released at 11 Oct
2021 which is currently uploaded to Debian unstable.  There is a full
log of the CI test available[1].

Kind regards

  Andreas.


[1] 
https://ci.debian.net/data/autopkgtest/testing/amd64/p/plink2/1921/log.gz


-- 
http://fam-tille.de

Bug#998656: sane-avision: adds a blank a4 page at the bottom of the scan

[David Ward]

On 11/5/2021 1:59 PM, Bertrand Marc wrote:
After upgrading to bullseye, scanning with my HP Scanjet 5300C (ID 
03f0:0701 HP, Inc ScanJet 5300c/5370c) became difficult.
Please note that it was working fine with buster, except that it 
required the attached /etc/sane.d/avision.conf and works with 300 and 
600 ppp (but not 150).


With the same /etc/sane.d/avision.conf as in buster, it now adds a 
second blank a4 page at the bottom of any scan (see attached picture).
Force-a4 option in /etc/sane.d/avision.conf doesn't change anything. 
Forcing a4 with simple-scan sometimes produces a4 with half bottom 
blank (randomly).


 * What happens if you don't choose any options in
   /etc/sane.d/avision.conf?
   I would make note of the last paragraph of the "Configuration"
   section in the sane-avision(5) man page.

 * This might be the "double height" problem with the HP ScanJet 5300C
   mentioned upstream:
   https://gitlab.com/sane-project/backends/-/issues/393

   There is a fix for it in version 1.0.32 (and version 1.1.1 in sid).
   Could you please try that to see if it makes a difference?

 * If these do not help, can you try running "scanimage" with increased
   verbosity?

Bug#1003153: [pkg-apparmor] Bug#1003153: Bug#1003153: /etc/apparmor.d/usr.sbin.apache2: Apache profile complains when ss -tnlp is run

[intrigeri]

Hi,

Craig Small (2022-02-17):
> On Sat, 12 Feb 2022 at 20:35, intrigeri  wrote:
>
>> So it seems to me a good solution may be to allow being ptraced
>> in the "apache2-common" abstraction.
>>
> That makes sense.

:)

>> Would one of you be interested in proposing this upstream?
>>
>> I'm not using Apache2 myself so I'm not a good person to work on this.
>>
> Sure, any idea how I do this?

Best is to submit a MR against
https://gitlab.com/apparmor/apparmor/-/blob/master/profiles/apparmor.d/abstractions/apache2-common

(and suggest it gets cherry-picked into the 3.0 branch to ensure we
have it in Bookworm)

Cheers!

Bug#1005906: libc6: 'test -x' ignores executable bit on files and directories

[David Eccles (gringer)]

Package: libc6
Version: 2.33-6
Severity: important
X-Debbugs-Cc: b...@gringene.org

Dear Maintainer,

I'm not sure which package this bug is linked to; I'm fairly confident it's one 
of the following:

fontconfig-config libbrotli-dev libbrotli1 libc-bin libc-dev-bin libc-l10n
  libc6 libc6-dev libexpat1 libexpat1-dev libfontconfig-dev libfontconfig1
  libfreetype-dev libfreetype6 libfreetype6-dev libuuid1 locales uuid-dev

I was trying to get R working on a Docker container with the following 
Dockerfile:

--- BEGIN ---

FROM rocker/r-base:4.1.2

## This works
RUN R -e 'install.packages(c("rjson"))'

RUN apt-get update && apt-get install -y \
  libfontconfig1-dev

## This doesn't work
RUN R -e 'install.packages(c("rjson"))'

--- END ---

Unfortunately, the R command stops working after the packages are updated. At 
the time I ran this,
the following packages were pulled in:

fontconfig-config libbrotli-dev libbrotli1 libc-bin libc-dev-bin libc-l10n
  libc6 libc6-dev libexpat1 libexpat1-dev libfontconfig-dev libfontconfig1
  libfreetype-dev libfreetype6 libfreetype6-dev libuuid1 locales uuid-dev

I get similar results [i.e. R not working] when I try to install 'nano' instead 
of libfontconfig1-dev.

I opened up the docker container to try to work out what was happening, and 
noticed the R command
has the following logic:

if test -x "${R_HOME}"; then
  :
else
  error "R_HOME ('${R_HOME}') not found"
fi

When I changed this to a 'test -d', R started working again:

if test -d "${R_HOME}"; then
  :
else
  error "R_HOME ('${R_HOME}') not found"
fi

Unfortunately, this didn't fix all my problems, because there was another R 
INSTALL script that
was required for installing R packages, and this script also didn't work. The 
script had a simiar
'-x' command, but it was used to test to make sure a file was executable, 
instead of a directory.

I created a short test shell commands to demonstrate the issue:

# export R_HOME=/usr/lib/R
# ls -lh ${R_HOME}/bin/INSTALL
-rwxr-xr-x 1 root root 825 Nov  1 11:00 /usr/lib/R/bin/INSTALL
# if test -x "${R_HOME}/bin/INSTALL"; then echo "file is executable"; else echo 
"dead beef"; fi
dead beef

[note that this reports "dead beef", rather than stating that the file is 
executable, even though
'ls' reports the file as executable]

As I believed this to have an effect beyond R, I am reporting this under one of 
the packages
that was installed by apt. This package is likely incorrect; please reassign as 
necessary.

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

Kernel: Linux 4.4.0-194-generic (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libc6 depends on:
ii  libgcc-s1  11.2.0-16

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.0-5

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.77
pn  glibc-doc  
ii  libc-l10n  2.33-5
pn  libnss-nis 
pn  libnss-nisplus 
ii  locales2.33-5

-- debconf information:
  libraries/restart-without-asking: false
  glibc/kernel-not-supported:
  glibc/upgrade: true
  glibc/kernel-too-old:
  glibc/restart-failed:
  glibc/disable-screensaver:
  glibc/restart-services:

Bug#1003548: transition: libwebp

[Jeff Breidenbach]

libwebp 1.2.1-7 has been successfully uploaded to unstable.

Anthony and Iustin, help is very strongly appreciated for the NMUs.

Bug#983332: sane-utils: incorrectly identifies Wifi USB dongles as scanners

[Martin-Éric Racine]

On Thu, Feb 17, 2022 at 6:07 AM David Ward  wrote:
>
> On 2/23/2021 8:13 AM, Martin-Éric Racine wrote:
> > $ sudo sane-find-scanner
> > found USB scanner (vendor=0x04a9 [Canon], product=0x2220 [CanoScan],
> > chip=LM9830) at libusb:002:003
> > found USB scanner (vendor=0x0411 [Ralink], product=0x00e8 [802.11 n
> > WLAN]) at libusb:001:004
> > found USB scanner (vendor=0x0b05 [Ralink], product=0x179d [802.11 n
> > WLAN]) at libusb:001:003
>
> What is the output of:
> $ sudo sane-find-scanner -v -v

Attached.

> The relevant source code is here:
> https://gitlab.com/sane-project/backends/-/blob/1.1.1/tools/sane-find-scanner.c#L1039-1060
>
> Apparently, this assumes that if your USB device exposes even /one/
> interface where the device class or interface class is
> "vendor-specific", then it is a scanner. That is almost certainly the
> problem.

That's probably it.

Martin-Éric
This is sane-find-scanner from sane-backends 1.0.31-debian

  # sane-find-scanner will now attempt to detect your scanner. If the
  # result is different from what you expected, first make sure your
  # scanner is powered up and properly connected to your computer.

searching for SCSI scanners:
checking /dev/scanner... failed to open (Invalid argument)
checking /dev/sg0... failed to open (Invalid argument)
checking /dev/sg1... failed to open (Invalid argument)
checking /dev/sg2... failed to open (Invalid argument)
checking /dev/sg3... failed to open (Invalid argument)
checking /dev/sg4... failed to open (Invalid argument)
checking /dev/sg5... failed to open (Invalid argument)
checking /dev/sg6... failed to open (Invalid argument)
checking /dev/sg7... failed to open (Invalid argument)
checking /dev/sg8... failed to open (Invalid argument)
checking /dev/sg9... failed to open (Invalid argument)
checking /dev/sga... failed to open (Invalid argument)
checking /dev/sgb... failed to open (Invalid argument)
checking /dev/sgc... failed to open (Invalid argument)
checking /dev/sgd... failed to open (Invalid argument)
checking /dev/sge... failed to open (Invalid argument)
checking /dev/sgf... failed to open (Invalid argument)
checking /dev/sgg... failed to open (Invalid argument)
checking /dev/sgh... failed to open (Invalid argument)
checking /dev/sgi... failed to open (Invalid argument)
checking /dev/sgj... failed to open (Invalid argument)
checking /dev/sgk... failed to open (Invalid argument)
checking /dev/sgl... failed to open (Invalid argument)
checking /dev/sgm... failed to open (Invalid argument)
checking /dev/sgn... failed to open (Invalid argument)
checking /dev/sgo... failed to open (Invalid argument)
checking /dev/sgp... failed to open (Invalid argument)
checking /dev/sgq... failed to open (Invalid argument)
checking /dev/sgr... failed to open (Invalid argument)
checking /dev/sgs... failed to open (Invalid argument)
checking /dev/sgt... failed to open (Invalid argument)
checking /dev/sgu... failed to open (Invalid argument)
checking /dev/sgv... failed to open (Invalid argument)
checking /dev/sgw... failed to open (Invalid argument)
checking /dev/sgx... failed to open (Invalid argument)
checking /dev/sgy... failed to open (Invalid argument)
checking /dev/sgz... failed to open (Invalid argument)
  # No SCSI scanners found. If you expected something different, make sure that
  # you have loaded a kernel SCSI driver for your SCSI adapter.

searching for USB scanners:
checking /dev/usb/scanner... failed to open (Invalid argument)
checking /dev/usb/scanner0... failed to open (Invalid argument)
checking /dev/usb/scanner1... failed to open (Invalid argument)
checking /dev/usb/scanner2... failed to open (Invalid argument)
checking /dev/usb/scanner3... failed to open (Invalid argument)
checking /dev/usb/scanner4... failed to open (Invalid argument)
checking /dev/usb/scanner5... failed to open (Invalid argument)
checking /dev/usb/scanner5... failed to open (Invalid argument)
checking /dev/usb/scanner7... failed to open (Invalid argument)
checking /dev/usb/scanner8... failed to open (Invalid argument)
checking /dev/usb/scanner9... failed to open (Invalid argument)
checking /dev/usb/scanner10... failed to open (Invalid argument)
checking /dev/usb/scanner11... failed to open (Invalid argument)
checking /dev/usb/scanner12... failed to open (Invalid argument)
checking /dev/usb/scanner13... failed to open (Invalid argument)
checking /dev/usb/scanner14... failed to open (Invalid argument)
checking /dev/usb/scanner15... failed to open (Invalid argument)
checking /dev/usbscanner... failed to open (Invalid argument)
checking /dev/usbscanner0... failed to open (Invalid argument)
checking /dev/usbscanner1... failed to open (Invalid argument)
checking /dev/usbscanner2... failed to open (Invalid argument)
checking /dev/usbscanner3... failed to open (Invalid argument)
checking /dev/usbscanner4... failed to open (Invalid argument)
checking /dev/usbscanner5... failed to open (Invalid argument)
checking /dev/usbscanner6... failed to open (Invalid argument)

Bug#983332: sane-utils: incorrectly identifies Wifi USB dongles as scanners

[David Ward]

On 2/23/2021 8:13 AM, Martin-Éric Racine wrote:

$ sudo sane-find-scanner
found USB scanner (vendor=0x04a9 [Canon], product=0x2220 [CanoScan],
chip=LM9830) at libusb:002:003
found USB scanner (vendor=0x0411 [Ralink], product=0x00e8 [802.11 n
WLAN]) at libusb:001:004
found USB scanner (vendor=0x0b05 [Ralink], product=0x179d [802.11 n
WLAN]) at libusb:001:003


What is the output of:
$ sudo sane-find-scanner -v -v


The relevant source code is here:
https://gitlab.com/sane-project/backends/-/blob/1.1.1/tools/sane-find-scanner.c#L1039-1060

Apparently, this assumes that if your USB device exposes even /one/ 
interface where the device class or interface class is 
"vendor-specific", then it is a scanner. That is almost certainly the 
problem.

Bug#1004285: [DAViCal-devel] Bug#1004285: davical: problems after upgrade to php 8, calendar clients reports "500"

[Florian Schlichting]

Hi Benno,

> I have looked at the apache2 log files and checked the /etc/php and
> /etc/davical directories if there were any references to php7 instead
> of php/php8.  The apache2 log file reported
> 
> [Mon Jan 24 11:29:29.678647 2022] [php:notice] [pid 684] [client /IPv6 
> address/] davical: LOG: response:-->DAViCal Fatal Error

Andrew fixed many issues with PHP 8 over the last few days. Are you able
to test with git versions of AWL and DAViCal? Otherwise it would be
helpful if you can find a few more lines from your logs containing the
PHP backtrace identifying the exact place in the code where the fatal
error occurred, as well as the PHP error message.

Florian

Bug#1005449: [DAViCal-devel] Bug#1005449: awl: FTBFS: sh: 1: error: Problems running dot: exit code=127, command='dot', arguments='"/<>/docs/api/inherit_graph_10.dot" -Tpng -o "/<

[Florian Schlichting]

On Sun, Feb 13, 2022 at 08:00:15AM +0100, Lucas Nussbaum wrote:
> Source: awl
> Version: 0.62-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220212 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.


> >dh_auto_test
> > make -j4 test
> > make[1]: Entering directory '/<>'
> > # simple php syntax check
> > OK (Syntax checked)
> > # run phpunit tests
> > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:./vendor/bin/
> >  phpunit tests/
> > PHPUnit 9.5.13 by Sebastian Bergmann and contributors.
> > 
> > 
> > Warning:   Test case class not matching filename is deprecated
> >in /<>/tests/myComponentTest.php
> >Class name was 'vComponentTest', expected 'myComponentTest'
> > Warning:   Test case class not matching filename is deprecated
> >in /<>/tests/myPropertyTest.php
> >Class name was 'vPropertyTest', expected 'myPropertyTest'
> > 
> > RE...R... 41 / 41 
> > (100%)
> > 
> > Time: 00:00.007, Memory: 6.00 MB
> > 
> > There was 1 error:
> > 
> > 1) myCalendarTest::test2
> > TypeError: implode(): Argument #2 ($array) must be of type ?array, string 
> > given
> > 
> > /<>/tests/myCalendarTest.php:61
> > 
> > --
> > 
> > There were 2 risky tests:
> > 
> > 1) myCalendarTest::test1
> > This test did not perform any assertions
> > 
> > /<>/tests/myCalendarTest.php:27
> > 
> > 2) vComponentTest::testRenderNoChanges2
> > This test did not perform any assertions
> > 
> > /<>/tests/myComponentTest.php:420
> > 
> > ERRORS!
> > Tests: 41, Assertions: 104, Errors: 1, Risky: 2.
> > make[1]: *** [Makefile:52: test] Error 2

tests/myCalendarTest.php:61 was fixed by
https://gitlab.com/davical-project/awl/-/commit/45f2ee44f2458a8c4e514fdf5a7b3bc329c44b9a

Bug#942176: libsane: Canon LiDE 220 works up to 1200 dpi only

[David Ward]

It seems very likely that the original problem is an upstream bug in 
SANE. There are a few issues reported there specifically against the 
Canon LiDE 220 that sound very similar:


https://gitlab.com/sane-project/backends/-/issues/439
https://gitlab.com/sane-project/backends/-/issues/518

On 12/9/2020 8:22 AM, Philipp Klaus Krause wrote:

Summary: The situation improved somewhat, but is still far from perfect:

There is still an odd waiting time when starting to scan at 2400 or 4800
(at 1200 and below the scan starts nearly instantly, after less than
second). At 4800 colors ar wrong.

Once one of these problems appears, it affects all resolutions until
restarting xsane:
Having done a scan at 2400 or 4800, subsequent scans at lower
resolutions also have the waiting time at the start. Having done a scan
at 2400 or 4800, where black appeared as bordeaux, subsequent scans at
lower resolutions also have wrong colors.


You mentioned that you are using GIMP to launch xsane. The problem with 
the colors could be occurring there. Can we rule that out? What happens 
if you run "scanimage" from the command-line — does it produce an image 
with the correct colors?

Bug#1004947: xscreensaver: still happening in version 6.02+dfsg1-2

[Jamie Zawinski]

https://www.jwz.org/xscreensaver/faq.html#typeahead

• I used to be able to start typing my password before the unlock 
dialog had appeared, but now I have to wait for the prompt.

This is an inevitable consequence of the new security model introduced in 
XScreenSaver 6.00. The old behavior will not be returning, so get used to 
clicking the mouse or tapping "Shift" before you start typing your password.

Just typing blindly had always been bad opsec anyway: if the screen was only 
blanked but not locked, you probably would have accidentally typed part of your 
password into another window.

Bug#1005804: xserver-xorg-video-nvidia-legacy-390xx: does not depend on xorg-video-abi-25

[Vincent Lefevre]

On 2022-02-17 00:35:40 +0100, Andreas Beckmann wrote:
> On 16/02/2022 15.10, Vincent Lefevre wrote:
> > On 2022-02-15 13:06:57 +0100, Andreas Beckmann wrote:
> > > If you force the installation of the driver with the new X server, can you
> > > confirm that the driver works without complaining about an ABI mismatch?
> > 
> > This seems to work on my desktop machine at my lab.
> 
> Thanks for confirming. Enabled xorg-video-abi-25 on the package

FYI, this also works without any issue on my laptop, with 2 external
monitors.

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

Bug#1005903: nmu: rime-related packages (for non source-only upload)

[Boyuan Yang]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: by...@debian.org
Severity: normal

While uploading packages related to RIME input method, some of my uploads were 
not done source-only. Please
binNMU the following packages to have them rebuilt on buildd:

nmu rime-array_0.0~git20210824.d10f2f8-3 . amd64 . unstable . -m "Rebuild on 
buildd"
nmu rime-bopomofo_0.0~git20210131.c7618f4-3 . amd64 . unstable . -m "Rebuild on 
buildd"
nmu rime-cangjie_0.0~git20210223.8dfad9e-3 . amd64 . unstable . -m "Rebuild on 
buildd"
nmu rime-cantonese_0.0~git20220105.42aed00-3 . amd64 . unstable . -m "Rebuild 
on buildd"
nmu rime-combo-pinyin_0.0~git20220213.02709b7-1 . amd64 . unstable . -m 
"Rebuild on buildd"
nmu rime-double-pinyin_0.0~git20190120.69bf85d-4 . amd64 . unstable . -m 
"Rebuild on buildd"
nmu rime-ipa_0.0~git20200413.22b7171-3 . amd64 . unstable . -m "Rebuild on 
buildd"
nmu rime-luna-pinyin_0.0~git20210805.6e67742-3 . amd64 . unstable . -m "Rebuild 
on buildd"

Thanks!
Boyuan Yang


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

Bug#1005902: xmms2: do not release with bookworm

[Sebastian Ramacher]

Source: xmms2
Version: 0.8+dfsg-22
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
Tags: sid bookworm

Upstream development of xmms2 has seized. There is no activity at
https://github.com/xmms2 and xmms2.org no longer exists. The last
upstream release was in 2011, so it's time to let it go.

Cheers



signature.asc
Description: PGP signature

Bug#1005901: tree-puzzle: please make the build reproducible on i386

[Chris Lamb]

Source: tree-puzzle
Version: 5.3~rc16+dfsg-8
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
tree-puzzle could not be built reproducibly on the on i386
architecture.

This seems to be some kind of rounding issue, but as it only affects a
test or example output file, a patch is attached that results in
Debian simply not shipping this file.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

--- a/debian/rules  2022-02-16 15:54:07.153676650 -0800
--- b/debian/rules  2022-02-16 16:05:32.982516872 -0800
@@ -31,6 +31,10 @@
 
 override_dh_installexamples:
rm -f tests/*.log tests/*.trs
+ifneq (,$(filter $(DEB_BUILD_ARCH),i386))
+   # Does not generate deterministic output on i386.
+   rm -f tests/qp-tn-nucl.nucl*
+endif
dh_installexamples
 
 override_dh_fixperms:

Bug#1005804: xserver-xorg-video-nvidia-legacy-390xx: does not depend on xorg-video-abi-25

[Andreas Beckmann]

On 16/02/2022 15.10, Vincent Lefevre wrote:

On 2022-02-15 13:06:57 +0100, Andreas Beckmann wrote:

If you force the installation of the driver with the new X server, can you
confirm that the driver works without complaining about an ABI mismatch?


This seems to work on my desktop machine at my lab.


Thanks for confirming. Enabled xorg-video-abi-25 on the package

Now we just need someone confirming that for the Tesla 418/450/460 
drivers, too. 450 probably works, the other two probably don't.



Andreas

Bug#1005900: linux.uml: uml_mconsole client becomes blocked on read after issuing commands stop and go

[Mihai Hanor]

Package: user-mode-linux
Version: 5.16um1
Severity: normal
File: /usr/bin/linux.uml
X-Debbugs-Cc: quake2i...@gmail.com

Dear Maintainer,

* What is the problem:
Issuing the commands stop followed by go, at the input of the uml_mconsole
client, results in the client becoming blocked on read socket. This is
because
of logic in arch/um/drivers/mconsole_kern.c, where mconsole_stop() doesn't
reactivate the MCONSOLE_IRQ before the function has exited.

I've managed to find a fix which seems to be working, but I don't know if
it's
a proper fix. Please see the attached file.


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

Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 user-mode-linux depends on:
ii  libc6  2.33-5

Versions of packages user-mode-linux recommends:
ii  uml-utilities  20070815.4-1

Versions of packages user-mode-linux suggests:
ii  mate-terminal [x-terminal-emulator]  1.26.0-1
ii  pterm [x-terminal-emulator]  0.76-2
pn  rootstrap
pn  slirp
pn  user-mode-linux-doc  
pn  vde2 

-- no debconf information
--- linux-source-5.16/arch/um/drivers/mconsole_kern.c	2022-02-05 20:22:06.0 +0200
+++ linux-source-5.16.fix/arch/um/drivers/mconsole_kern.c	2022-02-16 23:35:39.562668086 +0200
@@ -224,6 +224,7 @@
 
 void mconsole_stop(struct mc_request *req)
 {
+	int err;
 	deactivate_fd(req->originating_fd, MCONSOLE_IRQ);
 	os_set_fd_block(req->originating_fd, 1);
 	mconsole_reply(req, "stopped", 0, 0);
@@ -247,6 +248,11 @@
 	}
 	os_set_fd_block(req->originating_fd, 0);
 	mconsole_reply(req, "", 0, 0);
+	err=activate_fd(MCONSOLE_IRQ, req->originating_fd, IRQ_READ,
+		(void*)(req->originating_fd), NULL);
+	if (err)
+	  mconsole_reply(req, "Failed to reactivate MCONSOLE_IRQ, \
+			this will block the read for uml_mconsole", 1, 0);
 }
 
 static DEFINE_SPINLOCK(mc_devices_lock);
--- linux-source-5.16/arch/um/kernel/irq.c	2022-02-05 20:22:06.0 +0200
+++ linux-source-5.16.fix/arch/um/kernel/irq.c	2022-02-16 23:39:15.650279367 +0200
@@ -249,7 +249,7 @@
 		free_irq_entry(entry, false);
 }
 
-static int activate_fd(int irq, int fd, enum um_irq_type type, void *dev_id,
+int activate_fd(int irq, int fd, enum um_irq_type type, void *dev_id,
 		   void (*timetravel_handler)(int, int, void *,
 		  struct time_travel_event *))
 {
@@ -304,6 +304,7 @@
 out:
 	return err;
 }
+EXPORT_SYMBOL(activate_fd);
 
 /*
  * Remove the entry or entries for a specific FD, if you
--- linux-source-5.16/arch/um/include/shared/irq_user.h	2022-02-05 20:22:06.0 +0200
+++ linux-source-5.16.fix/arch/um/include/shared/irq_user.h	2022-02-16 23:39:09.642292312 +0200
@@ -19,6 +19,7 @@
 void sigio_run_timetravel_handlers(void);
 extern void free_irq_by_fd(int fd);
 extern void deactivate_fd(int fd, int irqnum);
+extern int activate_fd(int irq, int fd, enum um_irq_type type, void *dev_id, void (*timetravel_handler)(int, int, void *, struct time_travel_event *));
 extern int deactivate_all_fds(void);
 extern int activate_ipi(int fd, int pid);
 

Bug#973336: apt: test suite dependency valgrind is not available on armel (Was: apt autopkgtest-virt-lxc failure on armel)

[Adam Borowski]

On Thu, Oct 29, 2020 at 12:14:58PM +0100, Adam Borowski wrote:
> On Thu, Oct 29, 2020 at 10:42:21AM +0100, Julian Andres Klode wrote:
> > On Thu, Oct 29, 2020 at 02:54:46PM +0900, Ryutaroh Matsumoto wrote:
> > > Source: apt
> 
> > Well valgrind is not available on armel, so the test suite
> > can't run as it needs valgrind for a test.

Also riscv64, plus a lot of archs I don't care about as much.

> > I don't think we have a sane way to express test recommends,
> > so while the test could be skipped if valgrind is not available,
> > I don't see how to make valgrind optional.

> > But patches welcome, as long as they don't hardcode a list of
> > architectures for valgrind in the test control file.
> 
> valgrind-if-available (#928184) is not yet a thing, but that's a problem
> only for build-time testsuite, not autopkgtests.

It's now in the archive, you can make the autopkgtest b-dep:
valgrind-if-available.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Acided and whitepilled.
⠈⠳⣄

Bug#1005899: mplayer: should not release with bookworm

[Sebastian Ramacher]

Source: mplayer
Version: 2:1.4+ds1-3
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
Tags: sid bookworm

Let's stop pretending that mplayer is maintained. The upstream mailing
list infrastructure is gone and development has been minimal over the
last couple of months and years. So I think we should not include
mplayer in bookworm. mpv is a worthy replacement for mplayer.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1005898: java: The package "java" should exist, and it should install default-jre.

[Daniel Crookston]

Package: java
Severity: wishlist
Tags: newcomer

Dear Maintainer,

   * What led up to the situation?
 I was trying to install the Java runtime environment, so I ran
 "apt-get install java", which seems like a sensible course of
 action.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I, uhh... ran "apt-get install java"
   * What was the outcome of this action?
 I got an error message saying that the package doesn't exist.
   * What outcome did you expect instead?
 I expected that some sensible default version of the JRE would be
 installed.  You know, like you get with default-jre, only without
 having to experience annoyance, or interact with the internet.

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

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

Bug#1005072: mate-tweak: Unpleasant transition from marco-compton to marco-picom

[Mihai Hanor]

Control: title -1 mate-tweak: Unpleasant transition from marco-compton to
marco-picom

Bug#1004578: silan: FTBFS with ffmpeg 5.0

[Sebastian Ramacher]

Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 RM: silan -- RoQA; unmaintained upstream
Control: tags -2 =
Control: severity -2 normal

On 2022-01-31 09:47:21 +0200, Kyle Robbertze wrote:
> Silan is no longer maintained upstream, so probably should be removed as I
> doubt support for ffmpeg 5.0 will be added.

Alright.

Dear FTP masters, please remove silan from unstable.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1005169: regression: Chromium is not using plasma file dialog anymore since overlast update

[Andres Salomon]

clone 1005169 -1
reassign -1 src:plasma-desktop
retitle -1 plasma-desktop: plasma-desktop should probably depend upon 
xdg-desktop-portal-kde
affects chromium -1
thanks


Rather than just reassigning this, I'm going to leave it open for a
while with chromium. Even if it gets fixed in plasma-desktop, it'll
still be an issue for bullseye for quite a while.

To the KDE folks: I'm not sure if kde-desktop is the right package for
this, but something in the KDE stack should depend upon
xdg-desktop-portal-kde. This ensures that things like chromium (both
the debian version and upstream version) use the KDE file selector
instead of the GTK one. The chromium package now has a hard dependency
on xdg-desktop-portal-gtk|xdg-desktop-portal-backend, so KDE should be
pulling in the KDE portal package to ensure that satisfying that
dependency doesn't just pull in GTK stuff.

Bug#907174: New version available

[Florian Ernst]

On Tue, Jan 18, 2022 at 05:15:39PM +0100, Florian Ernst wrote:
> On Fri, Aug 24, 2018 at 03:14:18PM +0200, Sebastien Bacher wrote:
> > There is a new upstream version available, it would be nice to get the
> > update in Debian
> > https://github.com/jpirko/libndp/commits/v1.7
> 
> FWIW, by now there already is v1.8 available, with commits dealing with
> some leaks and a buffer overflow and adding options to ndptool.

I have prepared a rather minimal update for this at
 (i.e. in a fork of the latest
). Of course further changes are
possible, as e.g. suggested by lintian.

Upstream v1.8 seems to build sanely from this, and I also tested
building the reverse dependencies of libndp-dev, i.e. network-manager,
which succeeded as well showing no differences.

Please find attached the changes to debian/ to ease review.

Cheers,
Flo
diff --git a/debian/changelog b/debian/changelog
index 173649e..cab4437 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,38 @@
+libndp (1.8-0.1) UNRELEASED; urgency=medium
+
+  [ Michael Biebl ]
+  * Drop --disable-silent-rules from debian/rules. This is now handled by dh
+directly depending on whether the DH_QUIET environment variable is set.
+
+  [ Ondřej Nový ]
+  * d/copyright: Use https protocol in Format field
+  * d/control: Deprecating priority extra as per policy 4.0.1
+  * d/control: Set Vcs-* to salsa.debian.org
+
+  [ Debian Janitor ]
+  * [07f0e48] Transition to automatic debug package (from: libndp-dbg).
+Changes-By: lintian-brush
+Fixes: lintian: debian-control-has-obsolete-dbg-package
+See-also: https://lintian.debian.org/tags/debian-control-has-obsolete-dbg-package.html
+  * [0e8a255] Bump debhelper from deprecated 9 to 10.
+Changes-By: lintian-brush
+Fixes: lintian: package-uses-deprecated-debhelper-compat-version
+See-also: https://lintian.debian.org/tags/package-uses-deprecated-debhelper-compat-version.html
+  * [3ef06fb] Set upstream metadata fields: Bug-Database, Bug-Submit, Repository, Repository-Browse.
+Changes-By: lintian-brush
+Fixes: lintian: upstream-metadata-file-is-missing
+See-also: https://lintian.debian.org/tags/upstream-metadata-file-is-missing.html
+Fixes: lintian: upstream-metadata-missing-bug-tracking
+See-also: https://lintian.debian.org/tags/upstream-metadata-missing-bug-tracking.html
+Fixes: lintian: upstream-metadata-missing-repository
+See-also: https://lintian.debian.org/tags/upstream-metadata-missing-repository.html
+
+  [ Florian Ernst ]
+  * [2f15507] New upstream version 1.8 (Closes: #907174)
+  * [79a30ff] update symbols for upstream 1.8
+
+ -- Florian Ernst   Wed, 16 Feb 2022 22:24:38 +0100
+
 libndp (1.6-1) unstable; urgency=high
 
   * New upstream release. Fixes CVE-2016-3698. (Closes: #824545, #781755)
@@ -65,4 +100,3 @@ libndp (1.2-1) unstable; urgency=low
   * Initial release (Closes: #742973)
 
  -- Andrew Ayer   Sat, 29 Mar 2014 10:40:30 -0700
-
diff --git a/debian/compat b/debian/compat
index ec63514..f599e28 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-9
+10
diff --git a/debian/control b/debian/control
index 3df0519..d68b3e9 100644
--- a/debian/control
+++ b/debian/control
@@ -1,26 +1,12 @@
 Source: libndp
 Priority: optional
 Maintainer: Andrew Ayer 
-Build-Depends: debhelper (>= 9)
+Build-Depends: debhelper (>= 10~)
 Standards-Version: 3.9.8
 Section: net
 Homepage: http://libndp.org
-Vcs-Git: https://anonscm.debian.org/git/collab-maint/libndp.git
-Vcs-Browser: https://anonscm.debian.org/gitweb/?p=collab-maint/libndp.git
-
-Package: libndp-dbg
-Section: debug
-Priority: extra
-Architecture: linux-any kfreebsd-any
-Multi-Arch: same
-Depends: libndp0 (= ${binary:Version}), ${misc:Depends}
-Description: Library for Neighbor Discovery Protocol (debug symbols)
- libndp is a library for the IPv6 Neighbor Discovery Protocol (NDP).  It
- contains functions for building and parsing NDP messages, and provides
- a high-level interface for sending and receiving NDP messages on a
- network interface.
- .
- This package provides debug symbols.
+Vcs-Git: https://salsa.debian.org/debian/libndp.git
+Vcs-Browser: https://salsa.debian.org/debian/libndp
 
 Package: libndp-dev
 Section: libdevel
diff --git a/debian/copyright b/debian/copyright
index abae717..2036d75 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: libndp
 Source: https://github.com/jpirko/libndp
 
diff --git a/debian/libndp0.symbols b/debian/libndp0.symbols
index 72f91b4..556f385 100644
--- a/debian/libndp0.symbols
+++ b/debian/libndp0.symbols
@@ -5,6 +5,7 @@ libndp.so.0 libndp0 #MINVER#
  ndp_get_eventfd@Base 1.2
  ndp_get_log_priority@Base 1.2
  ndp_msg_addrto@Base 1.2
+ ndp_msg_dest_set@Base 1.8
  ndp_msg_destroy@Base 1.2
  

Bug#1005894: expat: CVE-2022-25235

[Salvatore Bonaccorso]

Source: expat
Version: 2.4.4-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/libexpat/libexpat/pull/562
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for expat.

CVE-2022-25235[0]:
| xmltok_impl.c in Expat (aka libexpat) before 2.4.5 lacks certain
| validation of encoding, such as checks for whether a UTF-8 character
| is valid in a certain context.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-25235
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25235
[1] https://github.com/libexpat/libexpat/pull/562

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1005895: expat: CVE-2022-25236

[Salvatore Bonaccorso]

Source: expat
Version: 2.4.4-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/libexpat/libexpat/pull/561
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for expat.

CVE-2022-25236[0]:
| xmlparse.c in Expat (aka libexpat) before 2.4.5 allows attackers to
| insert namespace-separator characters into namespace URIs.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-25236
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25236
[1] https://github.com/libexpat/libexpat/pull/561

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1005005: same behavior on my MSI Bravo 17 A4DDR : second resume fails and exception in kernel traces

[Eric Valette]

On 16/02/2022 21:01, Eric Valette wrote:

On 16/02/2022 20:58, Alex Deucher wrote:
On Wed, Feb 16, 2022 at 2:56 PM Eric Valette  
wrote:




Here is the dmesg. For bisecting, I'm not home and the Intrenet 
connection is just too slow.


In order to help a bit, I started to build kernel with the kernel 
patches set I had on my laptop so here it is:


5.11 suspend/resume is ok
5.12 suspend/resume is ok
5.13 suspend OK, resume KO, PC is dead I have to reboot.
5.14 suspend/resume is ok multiple times but I do have the exceptions at 
various places

sudo dmesg | grep RIP
[   19.918769] RIP: 0010:ieee80211_reconfig+0x9a/0x1300
[   19.918976] RIP: 0010:drv_remove_interface+0xd8/0xe0
[   19.919086] RIP: 0010:drv_stop+0xb8/0xc0
[   20.320553] RIP: 0010:iwl_mvm_mac_ctxt_init+0x1e2/0x220 [iwlmvm]
[   20.320801] RIP: 0033:0x7f0d4632536d

5.15 you have the result with latest one 5.15.24. RIP is at a given place.


Sorry to be unable to do more.

--eric

Bug#1003153: [pkg-apparmor] Bug#1003153: /etc/apparmor.d/usr.sbin.apache2: Apache profile complains when ss -tnlp is run

[Craig Small]

On Sat, 12 Feb 2022 at 20:35, intrigeri  wrote:

> So it seems to me a good solution may be to allow being ptraced
> in the "apache2-common" abstraction.
>
That makes sense.


> Would one of you be interested in proposing this upstream?
>
> I'm not using Apache2 myself so I'm not a good person to work on this.
>
Sure, any idea how I do this?

 - Craig

Bug#1005874: dnsmasq: TFTP server disregards bind-interfaces & co.

[Martin-Éric Racine]

On Wed, Feb 16, 2022 at 11:05 PM Simon Kelley  wrote:
> On 16/02/2022 20:19, Martin-Éric Racine wrote:
> > The startup message DOES suggest that DHCP is bound to an exclusive
> > interface, not to wildcard.  This is misleading.
>
> No it's not. it calls setsockopt(SO_BINDTODEVICE) which binds the socket
> to the physical interface, instead of to a IP address.

Ah.

> > Meanwhile TFTP is not meant to appear on loopback.
>
> Why? I guess we could argue the 15-year old design decision to do that,
> but it would be pointless since I'm not going to change it now and risk
> breaking installations which rely on it.

Fair enough.

Mind you, if I add the interface specification as follow, it does what I need:

enable-tftp=br0

Then TFTP indeed only is available on the IP for br0. Nontheless, I
still think that since interfaces=br0 is already specified, it should
have sufficed to ensure that all services are only available on that
interface (plus DNS also being available on loopback, since this is an
explicit exception stated in the documentation).

Anyhow, feel free to close this bug if you don't think that any code
or documentation change is required.

Martin-Éric

Bug#997120: [Debian-med-packaging] Bug#997120:

[Andreas Tille]

Am Wed, Feb 16, 2022 at 09:00:28PM +0100 schrieb Jose Luis Rivero:
> 
> No worries Emmanuel, thanks for your offer to help. I have not pinged the
> ftp-master team yet,
> so you are on time to help the poor Gazebo to go to testing :)

camitk was accepted and I have done a source-only upload.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#1005873: [git-buildpackage/master] pq: Check if repo is clean before importing patches

[Sean Whitton]

Hello,

On Wed 16 Feb 2022 at 02:39PM +01, Andrej Shadura wrote:

> Hi,
>
> On Fri, 11 Feb 2022 14:30:50 +0100 (CET) Guido Günther 
> wrote:
>> tag 1005321 pending
>> thanks
>>
>> Date:   Fri Feb 11 11:35:01 2022 +0100
>> Author: Guido Günther 
>> Commit ID: 8db5af7326c581014ca07dcd98beac30f2c90d4f
>> Commit URL: 
>> https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=8db5af7326c581014ca07dcd98beac30f2c90d4f
>> Patch URL: 
>> https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=8db5af7326c581014ca07dcd98beac30f2c90d4f
>>
>> pq: Check if repo is clean before importing patches
>
> Defaulting to --no-ignore-new breaks dgit --gbp push-source when there
> are patches. As a workaround, I had to stick pq.ignore-new = False into
> my gbp.conf:
>
> $ dgit push-source
> Format `3.0 (quilt)', need to check/update patch stack
> canonical suite name is bullseye-backports
> dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
> examining quilt state (multiple patches, gbp mode)
> dgit: base trees orig=a2b0298f5ffa80788851 o+d/p=17982c3db326770dc1b2
> dgit: quilt differences: src:  == orig ## gitignores:  == orig ==
> dgit: quilt differences:  HEAD ## o+d/p   HEAD == o+d/p
> dgit view: creating patches-applied version using gbp pq
> gbp:error: You have uncommitted changes in your source tree:
> gbp:error: On branch dgit-view
> Untracked files:
>(use "git add ..." to include in what will be committed)
>   .pc/
>
> nothing added to commit but untracked files present (use "git add" to track)
>
> gbp:error: Use --ignore-new to ignore.
> dgit: failed command: sh -ec 'exec >/dev/null; exec "$@"' x gbp pq import

Sounds like dgit should start passing --ignore-new in this case?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1005893: dh-haskell: please add Provides: dh-sequence-haskell

[Jonas Smedegaard]

Package: dh-haskell
Version: 0.5
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Felix,

Wonderful initiative!

Please have the binary package "Provides: dh-sequence-haskell"
to make it even easier for consuming packages:

Instead of build-depending on dh-haskell and "--with" in rules,
packages can simply build-depend on dh-sequence-haskell.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmINaAMACgkQLHwxRsGg
ASHMEg/9GWi614l2419kjsVX6dDlNATbrrMcmdVj1UZ07Mla3LJSlzqUS8++XWLM
mvcO5p4sl9wGXIpYbSB6YvGwmrM1kkNkUGPx11WwBJo7YpYr4YsSkjSDxyffdznP
aw0Ceqrr3o+fgkiH6j8YONCFgKelv7smk58ex7WOYYQW+OpKztHi7kICED4W7JQV
roSjvAtHk5qVCYK5LOeAn5AKY4oo/fLcrPkaFn1fRD1BhxbGfJ9ZUTUudsT1S/a1
pa7z3aFxpZZXRqOeYb1lcAmAxCnckrsWijtCh7+C+26zl365jfHA1tlWvWpuVAuZ
4AHbQHfAmJFC/KdFyHm8noSOVET3Y04r9JG/qPpOb6KGlRxpA+RB9DfhO5UjQ7z8
86gAOS1ENs4tD09w8vep0GXYyb7IvpDmjVQBRdLFlLR5ZyoAz44HmexMDS0w4Jmt
DoBk60oC4mokJLg5uvQd9MY4EwzkKg9QfzTjzI4WbpMMWiHL6nTLsOxs51zIi3Ic
iMn23EFshUz3b83hyq1jX7vdGmNHZ70ZLzfbSZB1EYnTkDSEmqS/FybmpXSsFI3r
lmsmJ5awXGdj+0To4DrrnCCy2EpjsRamhW3vVJfgNWPEN7Qyxe1pui0vD/yOmtxL
k11CdjUt9Lhap90+wyqS4N8C9sW7XaI2YaebTBx7MXeriLqCG3M=
=nrZp
-END PGP SIGNATURE-

Bug#1005766: alert to upstream bug report on pikepdf test failures

[Sean Whitton]

Hello,

On Mon 14 Feb 2022 at 11:02AM -05, Jay Berkenbilt wrote:

> I'm hoping a new pikepdf version will come out with this fix soon so
> just uploading a new pikepdf will unblock the qpdf transition. Since
> debian maintenance of pikepdf has generally been very responsive, I
> won't plan on creating another issue about it unless you would like to
> say something when pikepdf is updated. Thanks!

Please write to me or the bug when you are waiting on an actionable
upload by me.  Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1005874: dnsmasq: TFTP server disregards bind-interfaces & co.

[Simon Kelley]

On 16/02/2022 20:19, Martin-Éric Racine wrote:

The startup message DOES suggest that DHCP is bound to an exclusive
interface, not to wildcard.  This is misleading.


No it's not. it calls setsockopt(SO_BINDTODEVICE) which binds the socket 
to the physical interface, instead of to a IP address.



Meanwhile TFTP is not meant to appear on loopback.


Why? I guess we could argue the 15-year old design decision to do that, 
but it would be pointless since I'm not going to change it now and risk 
breaking installations which rely on it.


As I said, that option is available using --listen-address.

Simon.



Martin-Éric

On Wed, Feb 16, 2022 at 10:11 PM Simon Kelley  wrote:


67 is DHCP and always binds the wildcard: that's necessary to make DHCP
work. It checks the arrival address of packets and discards those which
are not valid.

interface= is documented to listen on the addresses of the given
interface AND LOOPBACK. If you want to exclude loopback, you can do


listen-address=17n172.16.1.22.16.1.2
(
instead.

Simon.

On 16/02/2022 19:58, Martin-Éric Racine wrote:

bind-enterfaces is supposed to restrict the services to exactly those
defined in interfaces. It currently doesn't.

My reduced config:

bogus-priv
conntrack
dns-loop-detect
dnssec
domain-needed
domain=lan
local=/lan/
expand-hosts
dhcp-hostsfile=/etc/dhcp-hostsfile
dhcp-fqdn
dhcp-option=option:dns-server,0.0.0.0,9.9.9.9,1.1.1.1
dhcp-option=option6:dns-server,[::]
dhcp-range=tag:br0,172.16.0.0,static,infinite
dhcp-range=tag:br0,::,constructor:br0,ra-names,ra-stateless,infinite
quiet-ra
interface=br0
bind-interfaces
enable-tftp
tftp-root=/srv/tftp
dhcp-boot=net:eth,/debian-installer/i386/undionly.kpxe
dhcp-boot=net:pxe,/debian-installer/i386/pxelinux.0
dhcp-vendorclass=eth,Etherboot
dhcp-vendorclass=pxe,PXEClient
dhcp-option=vendor:pxe,6,2b
#EOF

What the startup log shows:

Feb 16 21:51:07 voima systemd[1]: Starting dnsmasq - A lightweight
DHCP and caching DNS server...
Feb 16 21:51:07 voima dnsmasq[8813]: started, version 2.85 cachesize 150
Feb 16 21:51:07 voima dnsmasq[8813]: compile time options: IPv6
GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack
ipset auth cryptohash DNSSEC loop-detect inotify dumpfile
Feb 16 21:51:07 voima dnsmasq[8813]: DNSSEC validation enabled
Feb 16 21:51:07 voima dnsmasq[8813]: configured with trust anchor for
 keytag 20326
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCP, static leases only on
172.16.0.0, lease time infinite
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv6 stateless on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv4-derived IPv6 names on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: router advertisement on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv6 stateless on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv4-derived IPv6 names on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: router advertisement on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCP, sockets bound
exclusively to interface br0
Feb 16 21:51:07 voima dnsmasq-tftp[8813]: TFTP root is /srv/tftp
Feb 16 21:51:07 voima dnsmasq[8813]: using only locally-known
addresses for domain lan
Feb 16 21:51:07 voima dnsmasq[8813]: reading /etc/resolv.conf
Feb 16 21:51:07 voima dnsmasq[8813]: using only locally-known
addresses for domain lan
Feb 16 21:51:07 voima dnsmasq[8813]: using nameserver (redacted)#53
Feb 16 21:51:07 voima dnsmasq[8813]: using nameserver (redacted)#53
Feb 16 21:51:07 voima dnsmasq[8813]: read /etc/hosts - 20 addresses
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: read /etc/dhcp-hostsfile
Feb 16 21:51:07 voima systemd[1]: Started dnsmasq - A lightweight DHCP
and caching DNS server.

Yet netstat shows me:

$ netstat  | grep dnsmasq | grep -v p6
tcp0  0 127.0.0.1:530.0.0.0:*
LISTEN  7036/dnsmasq
tcp0  0 172.16.1.2:53   0.0.0.0:*
LISTEN  7036/dnsmasq
udp0  0 0.0.0.0:67  0.0.0.0:*
   7036/dnsmasq
udp0  0 127.0.0.1:530.0.0.0:*
   7036/dnsmasq
udp0  0 127.0.0.1:690.0.0.0:*
   7036/dnsmasq
udp0  0 172.16.1.2:53   0.0.0.0:*
   7036/dnsmasq
udp0  0 172.16.1.2:69   0.0.0.0:*
   7036/dnsmasq

67 is on wild card and 69 appears on loopback. Neither of these should
happen. They should only be on 172.16.1.2 yet they aren't. Basically,
unless I misunderstood something, nothing except 53 should appear on
loopback as per the above config.

Cheers!
Martin-Éric


On Wed, Feb 16, 2022 at 9:36 PM Simon Kelley  wrote:


I'm not clear what you think is happening, and what you want to happen.

bind-interfaces works for tftp; there will be a socket for each address
on each valid interface bound to that address and port 69

no-dhcp-interface does indeed suppress tftp on that interface too, and
is documented so to do.


Cheers,

Simon.


On 

Bug#1005892: libwlroots10: running sway triggers assertion bug in wlroots, preventing start

[Lukasz Miller]

Package: libwlroots10
Version: 0.15.0-2
Severity: important
X-Debbugs-Cc: lukan...@gmail.com

Dear Maintainer,

when running with propertiary Nvidia drivers, an attempt to start sway
compositor results in following error:

sway: render/wlr_renderer.c:240: wlr_renderer_init_wl_shm: Assertion `argb
&& xrgb' failed.

Upstream has been apparently fixed in version 0.15.1 of the package. Please
consider bumping the version.



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

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

Versions of packages libwlroots10 depends on:
ii  libc62.33-6
ii  libdrm2  2.4.109-2
ii  libegl1  1.4.0-1
ii  libgbm1  21.3.5-1
ii  libgles2 1.4.0-1
ii  libinput10   1.19.3-2
ii  libpixman-1-00.40.0-1
ii  libseat1 0.6.3-2
ii  libudev1 250.3-2
ii  libwayland-client0   1.20.0-1
ii  libwayland-server0   1.20.0-1
ii  libxcb-composite01.14-3
ii  libxcb-dri3-01.14-3
ii  libxcb-icccm40.4.1-1.1
ii  libxcb-present0  1.14-3
ii  libxcb-render-util0  0.3.9-1+b1
ii  libxcb-render0   1.14-3
ii  libxcb-res0  1.14-3
ii  libxcb-shm0  1.14-3
ii  libxcb-xfixes0   1.14-3
ii  libxcb-xinput0   1.14-3
ii  libxcb1  1.14-3
ii  libxkbcommon01.4.0-1

libwlroots10 recommends no packages.

libwlroots10 suggests no packages.

-- no debconf information

Bug#986458: python-pangolearn_2021-10-18+dfsg-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Wed, Feb 16, 2022 at 07:00:08PM + schrieb Thorsten Alteholz:
> our hardworking trainees added to note to your package:

Kudos to the trainees!
 
>   pangoLEARN\data\decisionTreeHeaders_v1.joblib seems to be binary.
>   Same for pangoLEARN\data\decisionTree_v1.joblib.
> 
> So, please explain what is needed to create these files (and the other data 
> files as well).

Hmmm, astonishingly I have removed these files in Git - may be these
were uploaded by mistake?  I just fetched the new upstream and did not
only removed *.joblib but also *.joblib.zip files in my new upload.
 
Kind regards and thanks to all who worked on checking this package

 Andreas.

-- 
http://fam-tille.de

Bug#1004894: sudo: [i386] invalid opcode

[Martin-Éric Racine]

On Wed, Feb 16, 2022 at 10:31 PM Marc Haber
 wrote:
>
> On Wed, Feb 16, 2022 at 07:15:37PM +0200, Martin-Éric Racine wrote:
> > I cannot help but wonder why the build doesn't simply parse
> > $(HARDENING_CFLAGS) and $(HARDENING_LDFLAGS). Hard-coded hardening
> > options tend to be a bad idea. GCC supports them all, but the target
> > host's CPU won't always support them.
>
> That would be an upstream issue, I think. Upstream uses bugzilla, so you
> need an account to submit a bug. Would you want to do that, or can you
> help me with the wording of a bug report?
>
> > during GIMPLE pass: cunroll
> > ../../../lib/util/event.c: In function ‘sudo_ev_add_v2’:
> > ../../../lib/util/event.c:465:1: internal compiler error: in
> > graphds_scc, at graphds.c:316
> >   465 | sudo_ev_add_v2(struct sudo_event_base *base, struct sudo_event *ev,
> >   | ^~
> > 0xb754d904 __libc_start_main
> > ../csu/libc-start.c:332
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > Please include the complete backtrace with any bug report.
> > See  for instructions.
> > The bug is not reproducible, so it is likely a hardware or OS problem.
>
> So it still doesn't build on Geode LX.
>
> How about your i386 build chroot?

Builds fine on my i386 chroot (amd64 host) and the resulting binary
doesn't dump core when installed on the Geode. Assuming there's no
uncovered corner case due to other optimizations, I think we've got a
winner.

Martin-Éric

Bug#1005891: runc: failing autopkgtest on one of ci.d.n amd64 workers

[Paul Gevers]

Source: runc
Version: 1.1.0+ds1-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of you package on amd64
because with a recent upload of glibc the autopkgtest of runc
fails in testing. Recently (mid January) your packages started to fail 
regularly and it seems to me that the failures are related to the

worker that the test runs on. ci-worker13 fails, while the other workers
are OK. Obviously I'm not sure it's related, but this particular host is 
extremely powerful, 256 GB RAM and 48 cores.


Don't hesitate to contact us at debian...@lists.debian.org if you need
help debugging this issue.

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/r/runc/18799590/log.gz

ok  github.com/opencontainers/runc/libcontainer/utils   0.005s
?   github.com/opencontainers/runc/types[no test files]
FAIL
dh_auto_test: error: cd _build && go test -vet=off -v -p 48 -tags 
seccomp github.com/opencontainers/runc 
github.com/opencontainers/runc/libcontainer 
github.com/opencontainers/runc/libcontainer/apparmor 
github.com/opencontainers/runc/libcontainer/capabilities 
github.com/opencontainers/runc/libcontainer/cgroups 
github.com/opencontainers/runc/libcontainer/cgroups/devices 
github.com/opencontainers/runc/libcontainer/cgroups/ebpf 
github.com/opencontainers/runc/libcontainer/cgroups/ebpf/devicefilter 
github.com/opencontainers/runc/libcontainer/cgroups/fs 
github.com/opencontainers/runc/libcontainer/cgroups/fs2 
github.com/opencontainers/runc/libcontainer/cgroups/fscommon 
github.com/opencontainers/runc/libcontainer/cgroups/systemd 
github.com/opencontainers/runc/libcontainer/configs 
github.com/opencontainers/runc/libcontainer/configs/validate 
github.com/opencontainers/runc/libcontainer/devices 
github.com/opencontainers/runc/libcontainer/intelrdt 
github.com/opencontainers/runc/libcontainer/keys 
github.com/opencontainers/runc/libcontainer/logs 
github.com/opencontainers/runc/libcontainer/nsenter 
github.com/opencontainers/runc/libcontainer/nsenter/test 
github.com/opencontainers/runc/libcontainer/seccomp 
github.com/opencontainers/runc/libcontainer/seccomp/patchbpf 
github.com/opencontainers/runc/libcontainer/specconv 
github.com/opencontainers/runc/libcontainer/stacktrace 
github.com/opencontainers/runc/libcontainer/system 
github.com/opencontainers/runc/libcontainer/user 
github.com/opencontainers/runc/libcontainer/userns 
github.com/opencontainers/runc/libcontainer/utils 
github.com/opencontainers/runc/types returned exit code 1
make[1]: Leaving directory 
'/tmp/autopkgtest-lxc.v97d589s/downtmp/autopkgtest_tmp'

make[1]: *** [debian/rules:24: override_dh_auto_test] Error 25
make: *** [debian/rules:11: build] Error 2
autopkgtest [13:11:41]: test dh-golang-autopkgtest: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004894: sudo: [i386] invalid opcode

[Marc Haber]

On Wed, Feb 16, 2022 at 07:15:37PM +0200, Martin-Éric Racine wrote:
> I cannot help but wonder why the build doesn't simply parse
> $(HARDENING_CFLAGS) and $(HARDENING_LDFLAGS). Hard-coded hardening
> options tend to be a bad idea. GCC supports them all, but the target
> host's CPU won't always support them.

That would be an upstream issue, I think. Upstream uses bugzilla, so you
need an account to submit a bug. Would you want to do that, or can you
help me with the wording of a bug report?

> during GIMPLE pass: cunroll
> ../../../lib/util/event.c: In function ‘sudo_ev_add_v2’:
> ../../../lib/util/event.c:465:1: internal compiler error: in
> graphds_scc, at graphds.c:316
>   465 | sudo_ev_add_v2(struct sudo_event_base *base, struct sudo_event *ev,
>   | ^~
> 0xb754d904 __libc_start_main
> ../csu/libc-start.c:332
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> The bug is not reproducible, so it is likely a hardware or OS problem.

So it still doesn't build on Geode LX.

How about your i386 build chroot?

Greetings
Marc

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

Bug#1005890: gsocket: flaky autopkgtest

[Paul Gevers]

Source: gsocket
Version: 1.4.33-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of you package on armhf 
because it was showing up as a regression for the upload of glibc. I 
noticed that the test regularly fails on all architectures.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

https://ci.debian.net/data/autopkgtest/testing/armhf/g/gsocket/19250005/log.gz

autopkgtest [07:10:23]: test upstream-tests: [---
Running: netcat #6.1 (stdin, 
1MB).[FAILED]-1

autopkgtest [07:10:25]: test upstream-tests: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005874: dnsmasq: TFTP server disregards bind-interfaces & co.

[Martin-Éric Racine]

The startup message DOES suggest that DHCP is bound to an exclusive
interface, not to wildcard.  This is misleading.
Meanwhile TFTP is not meant to appear on loopback.

Martin-Éric

On Wed, Feb 16, 2022 at 10:11 PM Simon Kelley  wrote:
>
> 67 is DHCP and always binds the wildcard: that's necessary to make DHCP
> work. It checks the arrival address of packets and discards those which
> are not valid.
>
> interface= is documented to listen on the addresses of the given
> interface AND LOOPBACK. If you want to exclude loopback, you can do
>
>
> listen-address=17n172.16.1.22.16.1.2
>
> instead.
>
> Simon.
>
> On 16/02/2022 19:58, Martin-Éric Racine wrote:
> > bind-enterfaces is supposed to restrict the services to exactly those
> > defined in interfaces. It currently doesn't.
> >
> > My reduced config:
> >
> > bogus-priv
> > conntrack
> > dns-loop-detect
> > dnssec
> > domain-needed
> > domain=lan
> > local=/lan/
> > expand-hosts
> > dhcp-hostsfile=/etc/dhcp-hostsfile
> > dhcp-fqdn
> > dhcp-option=option:dns-server,0.0.0.0,9.9.9.9,1.1.1.1
> > dhcp-option=option6:dns-server,[::]
> > dhcp-range=tag:br0,172.16.0.0,static,infinite
> > dhcp-range=tag:br0,::,constructor:br0,ra-names,ra-stateless,infinite
> > quiet-ra
> > interface=br0
> > bind-interfaces
> > enable-tftp
> > tftp-root=/srv/tftp
> > dhcp-boot=net:eth,/debian-installer/i386/undionly.kpxe
> > dhcp-boot=net:pxe,/debian-installer/i386/pxelinux.0
> > dhcp-vendorclass=eth,Etherboot
> > dhcp-vendorclass=pxe,PXEClient
> > dhcp-option=vendor:pxe,6,2b
> > #EOF
> >
> > What the startup log shows:
> >
> > Feb 16 21:51:07 voima systemd[1]: Starting dnsmasq - A lightweight
> > DHCP and caching DNS server...
> > Feb 16 21:51:07 voima dnsmasq[8813]: started, version 2.85 cachesize 150
> > Feb 16 21:51:07 voima dnsmasq[8813]: compile time options: IPv6
> > GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack
> > ipset auth cryptohash DNSSEC loop-detect inotify dumpfile
> > Feb 16 21:51:07 voima dnsmasq[8813]: DNSSEC validation enabled
> > Feb 16 21:51:07 voima dnsmasq[8813]: configured with trust anchor for
> >  keytag 20326
> > Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCP, static leases only on
> > 172.16.0.0, lease time infinite
> > Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv6 stateless on br0
> > Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv4-derived IPv6 names on br0
> > Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: router advertisement on br0
> > Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv6 stateless on
> > (redacted), constructed for br0
> > Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv4-derived IPv6 names on
> > (redacted), constructed for br0
> > Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: router advertisement on
> > (redacted), constructed for br0
> > Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCP, sockets bound
> > exclusively to interface br0
> > Feb 16 21:51:07 voima dnsmasq-tftp[8813]: TFTP root is /srv/tftp
> > Feb 16 21:51:07 voima dnsmasq[8813]: using only locally-known
> > addresses for domain lan
> > Feb 16 21:51:07 voima dnsmasq[8813]: reading /etc/resolv.conf
> > Feb 16 21:51:07 voima dnsmasq[8813]: using only locally-known
> > addresses for domain lan
> > Feb 16 21:51:07 voima dnsmasq[8813]: using nameserver (redacted)#53
> > Feb 16 21:51:07 voima dnsmasq[8813]: using nameserver (redacted)#53
> > Feb 16 21:51:07 voima dnsmasq[8813]: read /etc/hosts - 20 addresses
> > Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: read /etc/dhcp-hostsfile
> > Feb 16 21:51:07 voima systemd[1]: Started dnsmasq - A lightweight DHCP
> > and caching DNS server.
> >
> > Yet netstat shows me:
> >
> > $ netstat  | grep dnsmasq | grep -v p6
> > tcp0  0 127.0.0.1:530.0.0.0:*
> > LISTEN  7036/dnsmasq
> > tcp0  0 172.16.1.2:53   0.0.0.0:*
> > LISTEN  7036/dnsmasq
> > udp0  0 0.0.0.0:67  0.0.0.0:*
> >   7036/dnsmasq
> > udp0  0 127.0.0.1:530.0.0.0:*
> >   7036/dnsmasq
> > udp0  0 127.0.0.1:690.0.0.0:*
> >   7036/dnsmasq
> > udp0  0 172.16.1.2:53   0.0.0.0:*
> >   7036/dnsmasq
> > udp0  0 172.16.1.2:69   0.0.0.0:*
> >   7036/dnsmasq
> >
> > 67 is on wild card and 69 appears on loopback. Neither of these should
> > happen. They should only be on 172.16.1.2 yet they aren't. Basically,
> > unless I misunderstood something, nothing except 53 should appear on
> > loopback as per the above config.
> >
> > Cheers!
> > Martin-Éric
> >
> >
> > On Wed, Feb 16, 2022 at 9:36 PM Simon Kelley  
> > wrote:
> >>
> >> I'm not clear what you think is happening, and what you want to happen.
> >>
> >> bind-interfaces works for tftp; there will be a socket for each address
> >> on each valid interface bound to that address and port 69
> >>
> >> no-dhcp-interface does indeed suppress tftp on that interface too, and
> >> is documented so to do.
> >>
> >>
> >> Cheers,
> >>
> >> 

Bug#995567: Can't handle cross-signed Let's Encrypt CA

[Gabriel Filion]

Upstream hasn't yet made a release that includes the fix.

Since this is currently affecting the software on certain hosts and 
making it impossible to connect to hosts using Let's Encrypt 
certificates (we're seeing this problem with a production host), I'm 
wondering if the patch could be included in the debian package in the 
curent package releases.

Bug#1005889: dbus: flaky autopkgtest on ppc64el: dbus/integration/transient-services.sh.test

[Paul Gevers]

Source: dbus
Version: 1.12.20-3
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of you package on ppc64el 
because it was showing up as a regression for the upload of glibc. I 
noticed that the test regularly fails since the beginning of February 
this year. The failure is always the same (so far), and it happens on 
multiple of our hosts.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

https://ci.debian.net/packages/d/dbus/testing/ppc64el/

https://ci.debian.net/data/autopkgtest/testing/ppc64el/d/dbus/18861487/log.gz

Running test: 
dbus-debug-build/integration/transient-services.sh_with_config.test

1..2
Bail out! /run/user/1000/dbus-1/services is not a directory
FAIL: 
dbus-debug-build/integration/transient-services.sh_with_config.test 
(Child process exited with code 1)


[...]

SUMMARY: total=88; passed=87; skipped=0; failed=1; user=81.8s; 
system=55.2s; maxrss=23680
FAIL: 
dbus-debug-build/integration/transient-services.sh_with_config.test 
(Child process exited with code 1)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005874: dnsmasq: TFTP server disregards bind-interfaces & co.

[Simon Kelley]

67 is DHCP and always binds the wildcard: that's necessary to make DHCP 
work. It checks the arrival address of packets and discards those which 
are not valid.


interface= is documented to listen on the addresses of the given 
interface AND LOOPBACK. If you want to exclude loopback, you can do



listen-address=17n172.16.1.22.16.1.2

instead.

Simon.

On 16/02/2022 19:58, Martin-Éric Racine wrote:

bind-enterfaces is supposed to restrict the services to exactly those
defined in interfaces. It currently doesn't.

My reduced config:

bogus-priv
conntrack
dns-loop-detect
dnssec
domain-needed
domain=lan
local=/lan/
expand-hosts
dhcp-hostsfile=/etc/dhcp-hostsfile
dhcp-fqdn
dhcp-option=option:dns-server,0.0.0.0,9.9.9.9,1.1.1.1
dhcp-option=option6:dns-server,[::]
dhcp-range=tag:br0,172.16.0.0,static,infinite
dhcp-range=tag:br0,::,constructor:br0,ra-names,ra-stateless,infinite
quiet-ra
interface=br0
bind-interfaces
enable-tftp
tftp-root=/srv/tftp
dhcp-boot=net:eth,/debian-installer/i386/undionly.kpxe
dhcp-boot=net:pxe,/debian-installer/i386/pxelinux.0
dhcp-vendorclass=eth,Etherboot
dhcp-vendorclass=pxe,PXEClient
dhcp-option=vendor:pxe,6,2b
#EOF

What the startup log shows:

Feb 16 21:51:07 voima systemd[1]: Starting dnsmasq - A lightweight
DHCP and caching DNS server...
Feb 16 21:51:07 voima dnsmasq[8813]: started, version 2.85 cachesize 150
Feb 16 21:51:07 voima dnsmasq[8813]: compile time options: IPv6
GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack
ipset auth cryptohash DNSSEC loop-detect inotify dumpfile
Feb 16 21:51:07 voima dnsmasq[8813]: DNSSEC validation enabled
Feb 16 21:51:07 voima dnsmasq[8813]: configured with trust anchor for
 keytag 20326
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCP, static leases only on
172.16.0.0, lease time infinite
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv6 stateless on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv4-derived IPv6 names on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: router advertisement on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv6 stateless on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv4-derived IPv6 names on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: router advertisement on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCP, sockets bound
exclusively to interface br0
Feb 16 21:51:07 voima dnsmasq-tftp[8813]: TFTP root is /srv/tftp
Feb 16 21:51:07 voima dnsmasq[8813]: using only locally-known
addresses for domain lan
Feb 16 21:51:07 voima dnsmasq[8813]: reading /etc/resolv.conf
Feb 16 21:51:07 voima dnsmasq[8813]: using only locally-known
addresses for domain lan
Feb 16 21:51:07 voima dnsmasq[8813]: using nameserver (redacted)#53
Feb 16 21:51:07 voima dnsmasq[8813]: using nameserver (redacted)#53
Feb 16 21:51:07 voima dnsmasq[8813]: read /etc/hosts - 20 addresses
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: read /etc/dhcp-hostsfile
Feb 16 21:51:07 voima systemd[1]: Started dnsmasq - A lightweight DHCP
and caching DNS server.

Yet netstat shows me:

$ netstat  | grep dnsmasq | grep -v p6
tcp0  0 127.0.0.1:530.0.0.0:*
LISTEN  7036/dnsmasq
tcp0  0 172.16.1.2:53   0.0.0.0:*
LISTEN  7036/dnsmasq
udp0  0 0.0.0.0:67  0.0.0.0:*
  7036/dnsmasq
udp0  0 127.0.0.1:530.0.0.0:*
  7036/dnsmasq
udp0  0 127.0.0.1:690.0.0.0:*
  7036/dnsmasq
udp0  0 172.16.1.2:53   0.0.0.0:*
  7036/dnsmasq
udp0  0 172.16.1.2:69   0.0.0.0:*
  7036/dnsmasq

67 is on wild card and 69 appears on loopback. Neither of these should
happen. They should only be on 172.16.1.2 yet they aren't. Basically,
unless I misunderstood something, nothing except 53 should appear on
loopback as per the above config.

Cheers!
Martin-Éric


On Wed, Feb 16, 2022 at 9:36 PM Simon Kelley  wrote:


I'm not clear what you think is happening, and what you want to happen.

bind-interfaces works for tftp; there will be a socket for each address
on each valid interface bound to that address and port 69

no-dhcp-interface does indeed suppress tftp on that interface too, and
is documented so to do.


Cheers,

Simon.


On 16/02/2022 13:42, Martin-Éric Racine wrote:
  > Package: dnsmasq
  > Version: 2.85-1
  > Severity: important
  >

If 'enable-tftp' is set, the TFTP server appears on all interfaces. It 
completely disregards bind-interfaces and friends. One would think that TFTP 
would only be offered on interfaces where dnsmasq happens to offer DHCP 
services (since DHCP essentially is a superset of BOOTP, to which TFTP is 
related), but apparently not.

The relevant part of my config:

bind-interfaces
interface=br0
except-interface=enp4s0
no-dhcp-interface=enp4s0

IMHO, the only service that dnsmasq should offer on both loopback and 
'interface' is DNS. It ought to be possible to bind every 

Bug#1005888: man-db: "man open" gives the manpage of "xdg-open"

[Nikolaus Klepp]

Package: man-db
Version: 2.9.4-4
Severity: normal
X-Debbugs-Cc: off...@klepp.biz

Dear Maintainer,

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

   * What led up to the situation?
$ man open

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

   * What was the outcome of this action?
The manpage of xdg-open, /usr/share/man/man1/xdg-open.1.gz, from package "xdg-op

   * What outcome did you expect instead?
The manpage of "open", /usr/share/man/man2/open.2.gz, from package "manpages-dev


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 5 (daedalus/ceres)
Release:5
Codename:   daedalus ceres
Architecture: x86_64

Kernel: Linux 5.15.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_M
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE=de_AT:d
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages man-db depends on:
ii  bsdextrautils  2.37.3-1+devuan1
ii  debconf [debconf-2.0]  1.5.79
ii  groff-base 1.22.4-8
ii  libc6  2.33-5
ii  libgdbm6   1.22-1
ii  libpipeline1   1.5.5-1
ii  libseccomp22.5.3-2
ii  zlib1g 1:1.2.11.dfsg-2

man-db recommends no packages.

Versions of packages man-db suggests:
pn  apparmor
ii  firefox-esr [www-browser]   91.5.0esr-1
ii  google-chrome-stable [www-browser]  98.0.4758.80-1
ii  groff   1.22.4-8
ii  konqueror-trinity [www-browser] 4:14.1.0~s911-0debian12.0.0+17~a
ii  less590-1
ii  lynx [www-browser]  2.9.0dev.10-1

-- debconf information:
  man-db/install-setuid: false
  man-db/auto-update: true



-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...

Bug#1005874: dnsmasq: TFTP server disregards bind-interfaces & co.

[Martin-Éric Racine]

bind-enterfaces is supposed to restrict the services to exactly those
defined in interfaces. It currently doesn't.

My reduced config:

bogus-priv
conntrack
dns-loop-detect
dnssec
domain-needed
domain=lan
local=/lan/
expand-hosts
dhcp-hostsfile=/etc/dhcp-hostsfile
dhcp-fqdn
dhcp-option=option:dns-server,0.0.0.0,9.9.9.9,1.1.1.1
dhcp-option=option6:dns-server,[::]
dhcp-range=tag:br0,172.16.0.0,static,infinite
dhcp-range=tag:br0,::,constructor:br0,ra-names,ra-stateless,infinite
quiet-ra
interface=br0
bind-interfaces
enable-tftp
tftp-root=/srv/tftp
dhcp-boot=net:eth,/debian-installer/i386/undionly.kpxe
dhcp-boot=net:pxe,/debian-installer/i386/pxelinux.0
dhcp-vendorclass=eth,Etherboot
dhcp-vendorclass=pxe,PXEClient
dhcp-option=vendor:pxe,6,2b
#EOF

What the startup log shows:

Feb 16 21:51:07 voima systemd[1]: Starting dnsmasq - A lightweight
DHCP and caching DNS server...
Feb 16 21:51:07 voima dnsmasq[8813]: started, version 2.85 cachesize 150
Feb 16 21:51:07 voima dnsmasq[8813]: compile time options: IPv6
GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack
ipset auth cryptohash DNSSEC loop-detect inotify dumpfile
Feb 16 21:51:07 voima dnsmasq[8813]: DNSSEC validation enabled
Feb 16 21:51:07 voima dnsmasq[8813]: configured with trust anchor for
 keytag 20326
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCP, static leases only on
172.16.0.0, lease time infinite
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv6 stateless on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv4-derived IPv6 names on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: router advertisement on br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv6 stateless on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCPv4-derived IPv6 names on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: router advertisement on
(redacted), constructed for br0
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: DHCP, sockets bound
exclusively to interface br0
Feb 16 21:51:07 voima dnsmasq-tftp[8813]: TFTP root is /srv/tftp
Feb 16 21:51:07 voima dnsmasq[8813]: using only locally-known
addresses for domain lan
Feb 16 21:51:07 voima dnsmasq[8813]: reading /etc/resolv.conf
Feb 16 21:51:07 voima dnsmasq[8813]: using only locally-known
addresses for domain lan
Feb 16 21:51:07 voima dnsmasq[8813]: using nameserver (redacted)#53
Feb 16 21:51:07 voima dnsmasq[8813]: using nameserver (redacted)#53
Feb 16 21:51:07 voima dnsmasq[8813]: read /etc/hosts - 20 addresses
Feb 16 21:51:07 voima dnsmasq-dhcp[8813]: read /etc/dhcp-hostsfile
Feb 16 21:51:07 voima systemd[1]: Started dnsmasq - A lightweight DHCP
and caching DNS server.

Yet netstat shows me:

$ netstat  | grep dnsmasq | grep -v p6
tcp0  0 127.0.0.1:530.0.0.0:*
LISTEN  7036/dnsmasq
tcp0  0 172.16.1.2:53   0.0.0.0:*
LISTEN  7036/dnsmasq
udp0  0 0.0.0.0:67  0.0.0.0:*
 7036/dnsmasq
udp0  0 127.0.0.1:530.0.0.0:*
 7036/dnsmasq
udp0  0 127.0.0.1:690.0.0.0:*
 7036/dnsmasq
udp0  0 172.16.1.2:53   0.0.0.0:*
 7036/dnsmasq
udp0  0 172.16.1.2:69   0.0.0.0:*
 7036/dnsmasq

67 is on wild card and 69 appears on loopback. Neither of these should
happen. They should only be on 172.16.1.2 yet they aren't. Basically,
unless I misunderstood something, nothing except 53 should appear on
loopback as per the above config.

Cheers!
Martin-Éric


On Wed, Feb 16, 2022 at 9:36 PM Simon Kelley  wrote:
>
> I'm not clear what you think is happening, and what you want to happen.
>
> bind-interfaces works for tftp; there will be a socket for each address
> on each valid interface bound to that address and port 69
>
> no-dhcp-interface does indeed suppress tftp on that interface too, and
> is documented so to do.
>
>
> Cheers,
>
> Simon.
>
>
> On 16/02/2022 13:42, Martin-Éric Racine wrote:
>  > Package: dnsmasq
>  > Version: 2.85-1
>  > Severity: important
>  >
> > If 'enable-tftp' is set, the TFTP server appears on all interfaces. It 
> > completely disregards bind-interfaces and friends. One would think that 
> > TFTP would only be offered on interfaces where dnsmasq happens to offer 
> > DHCP services (since DHCP essentially is a superset of BOOTP, to which TFTP 
> > is related), but apparently not.
> >
> > The relevant part of my config:
> >
> > bind-interfaces
> > interface=br0
> > except-interface=enp4s0
> > no-dhcp-interface=enp4s0
> >
> > IMHO, the only service that dnsmasq should offer on both loopback and 
> > 'interface' is DNS. It ought to be possible to bind every other service 
> > that dnsmasq can offer to specific interfaces.
> >
> > If the above already is possible, but my particular combination of 
> > bind-interfaces/interface/except-interface/no-dhcp-interface prevents that, 
> > I welcome tips on how to fix it.
> >
> > Martin-Éric
> >
> > -- System Information:
> > Debian 

Bug#1005874: dnsmasq: TFTP server disregards bind-interfaces & co.

[Simon Kelley]

I'm not clear what you think is happening, and what you want to happen.

bind-interfaces works for tftp; there will be a socket for each address 
on each valid interface bound to that address and port 69


no-dhcp-interface does indeed suppress tftp on that interface too, and 
is documented so to do.



Cheers,

Simon.


On 16/02/2022 13:42, Martin-Éric Racine wrote:
> Package: dnsmasq
> Version: 2.85-1
> Severity: important
>

If 'enable-tftp' is set, the TFTP server appears on all interfaces. It 
completely disregards bind-interfaces and friends. One would think that TFTP 
would only be offered on interfaces where dnsmasq happens to offer DHCP 
services (since DHCP essentially is a superset of BOOTP, to which TFTP is 
related), but apparently not.

The relevant part of my config:

bind-interfaces
interface=br0
except-interface=enp4s0
no-dhcp-interface=enp4s0

IMHO, the only service that dnsmasq should offer on both loopback and 
'interface' is DNS. It ought to be possible to bind every other service that 
dnsmasq can offer to specific interfaces.

If the above already is possible, but my particular combination of 
bind-interfaces/interface/except-interface/no-dhcp-interface prevents that, I 
welcome tips on how to fix it.

Martin-Éric

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

Kernel: Linux 5.10.0-11-amd64 (SMP w/8 CPU threads)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dnsmasq depends on:
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  netbase  6.3
ii  runit-helper 2.10.3

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
pn  resolvconf  

-- no debconf information

Bug#997120: [Debian-med-packaging] Bug#997120:

[Jose Luis Rivero]

On Wed, Feb 16, 2022 at 8:32 AM Emmanuel Promayon <
emmanuel.proma...@univ-grenoble-alpes.fr> wrote:

> Dear Jose and Andreas,
>
> On 14/02/2022 17:02, Andreas Tille wrote:
>
> Am Mon, Feb 14, 2022 at 12:18:47AM +0100 schrieb Jose Luis Rivero:
>
> You are welcome. This bug is preventing one of my packages (Gazebo) from
> being
> migrated to testing. Could we please upload a revision bump of the current
> version to solve this issue while we work on 5.0.2?
>
> Hmmm, that's a bit tricky now.  I've uploaded 5.0.2 to new[1].  May be
> pinging #debian-ftp could help?  (I'm hesitating a bit to do so myself
> since I used that option recently a bit frequently.)
>
> Sorry about that: I did not notice that bug 997120 was blocking gazebo
> (should there did not be a flag or message somewhere to alert about that?
> Being quite inexperienced I might well as missed it...)
> Let me know if (and how!) I can help with asking the ftpmaster team.
>

No worries Emmanuel, thanks for your offer to help. I have not pinged the
ftp-master team yet,
so you are on time to help the poor Gazebo to go to testing :)

Thanks!

>

Bug#1005766: alert to upstream bug report on pikepdf test failures

[Jay Berkenbilt]

I have released qpdf 10.6.2, and a new pikepdf should be coming out imminently 
as well. This gets us back in sync -- the new pikepdf tests pass against 10.6.2.

Bug#1005005: same behavior on my MSI Bravo 17 A4DDR : second resume fails and exception in kernel traces

[Alex Deucher]

On Wed, Feb 16, 2022 at 2:56 PM Eric Valette  wrote:
>
> On Tue, 15 Feb 2022 15:42:27 -0500 Alex Deucher 
> wrote:
> > What chip is this?  Can you provide the full dmesg output?
>
> Its a a renoir chip with a second gpu : [Radeon RX 5500/5500M / Pro 5500M].

Thanks.  Can you attach the dmesg output?  Can you bisect?

Alex


>
>
> Processor Information
>  Socket Designation: FP6
>  Type: Central Processor
>  Family: Zen
>  Manufacturer: Advanced Micro Devices, Inc.
>  ID: 01 0F 86 00 FF FB 8B 17
>  Signature: Family 23, Model 96, Stepping 1
>  Flags:
>  FPU (Floating-point unit on-chip)
>  VME (Virtual mode extension)
>  DE (Debugging extension)
>  PSE (Page size extension)
>  TSC (Time stamp counter)
>  MSR (Model specific registers)
>  PAE (Physical address extension)
>  MCE (Machine check exception)
>  CX8 (CMPXCHG8 instruction supported)
>  APIC (On-chip APIC hardware supported)
>  SEP (Fast system call)
>  MTRR (Memory type range registers)
>  PGE (Page global enable)
>  MCA (Machine check architecture)
>  CMOV (Conditional move instruction supported)
>  PAT (Page attribute table)
>  PSE-36 (36-bit page size extension)
>  CLFSH (CLFLUSH instruction supported)
>  MMX (MMX technology supported)
>  FXSR (FXSAVE and FXSTOR instructions supported)
>  SSE (Streaming SIMD extensions)
>  SSE2 (Streaming SIMD extensions 2)
>  HTT (Multi-threading)
>  Version: AMD Ryzen 7 4800H with Radeon Graphics
>  Voltage: 1.2 V
>  External Clock: 100 MHz
>  Max Speed: 4300 MHz
>  Current Speed: 2900 MHz
>  Status: Populated, Enabled
>  Upgrade: None
>  L1 Cache Handle: 0x000D
>  L2 Cache Handle: 0x000E
>  L3 Cache Handle: 0x000F
>  Serial Number: Unknown
>  Asset Tag: Unknown
>  Part Number: Unknown
>  Core Count: 8
>  Core Enabled: 8
>  Thread Count: 16
>  Characteristics:
>  64-bit capable
>  Multi-Core
>  Hardware Thread
>  Execute Protection
>  Enhanced Virtualization
>  Power/Performance Control

Bug#1005005: same behavior on my MSI Bravo 17 A4DDR : second resume fails and exception in kernel traces

[Eric Valette]

On Tue, 15 Feb 2022 15:42:27 -0500 Alex Deucher  
wrote:

What chip is this?  Can you provide the full dmesg output?


Its a a renoir chip with a second gpu : [Radeon RX 5500/5500M / Pro 5500M].


Processor Information
Socket Designation: FP6
Type: Central Processor
Family: Zen
Manufacturer: Advanced Micro Devices, Inc.
ID: 01 0F 86 00 FF FB 8B 17
Signature: Family 23, Model 96, Stepping 1
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
HTT (Multi-threading)
Version: AMD Ryzen 7 4800H with Radeon Graphics
Voltage: 1.2 V
External Clock: 100 MHz
Max Speed: 4300 MHz
Current Speed: 2900 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: 0x000D
L2 Cache Handle: 0x000E
L3 Cache Handle: 0x000F
Serial Number: Unknown
Asset Tag: Unknown
Part Number: Unknown
Core Count: 8
Core Enabled: 8
Thread Count: 16
Characteristics:
64-bit capable
Multi-Core
Hardware Thread
Execute Protection
Enhanced Virtualization
Power/Performance Control

Bug#971241: debconf-kde-helper: Boolean inputs are always set to true/yes position, no matter what the actual state is

[Matthias Klumpp]

Hi Jaakko!

Thank you *very* much for the script to reproduce this, thanks to the 
script I was able to fix this in a few minutes after years of not 
touching debconf-kde (in preparation of a bugfix release).


This issue will be resolved with the next upload.

Cheers,
Matthias

Bug#986458: python-pangolearn_2021-10-18+dfsg-1_amd64.changes REJECTED

[Thorsten Alteholz]

Hi Andreas,

our hardworking trainees added to note to your package:

  pangoLEARN\data\decisionTreeHeaders_v1.joblib seems to be binary.
  Same for pangoLEARN\data\decisionTree_v1.joblib.

So, please explain what is needed to create these files (and the other data 
files as well).

Thanks!
  Thorsten



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

Bug#1002291: bpfcc: Fails to build with libbpf/0.6.1-1

[Sudip Mukherjee]

Hi Vasudev,

On Thu, Dec 23, 2021 at 6:07 PM Sudip Mukherjee
 wrote:
>
> On Wed, Dec 22, 2021 at 10:52 AM Vasudev Kamath  
> wrote:
> >
> > Hi Sudip,
> >
> > Sudip Mukherjee  writes:
> >
> >
> > >
> > > Reported error:
>
> 
>
> > >
> >
> > I tried building bpfcc 0.23.0 with experimental libbpf and it too
> > failed. These versions are released with 0.5.0 libbpf. I see that next
> > release 0.24.0 (not sure when it happens) should work with newer libbpf.
> > Can we hold uploading newer libbpf to unstable till then?.
>
> Sure, just let me know when its ready and I can upload then.

Seems like the FTBFS is not there with libbpf/0.7.0
I will upload to experimental by Friday so that you can test.

-- 
Regards
Sudip

Bug#1005851: systemd: networkd does not reliably configure hot-plugged interfaces

[Noah Meyerhans]

Control: forarded -1 https://github.com/systemd/systemd/issues/22538

On Wed, Feb 16, 2022 at 08:11:15AM +0100, Michael Biebl wrote:
> Am 16.02.22 um 02:14 schrieb Noah Meyerhans:
> > However, starting with the systemd 250 upstream releases, configuration of
> > these interfaces fails intermittently, with networkd not properly 
> > associating
> > the interface with the .network file:
> 
> Is that a regression compared to v249?
> Would be great if you can file this upstream
> https://github.com/systemd/systemd/

Done, thanks.  It definitely seems to be a regression.  I can run the
attach/test/detach operation in a loop 100x (and counting) with no
failures using 249, but it fails ~30% of the time in 250.

noah

Bug#992080: udiskie bug

[Gianfranco Costamagna]

On Tue, 10 Aug 2021 16:31:36 -0700 Nolan  wrote:
It may be obvious, but I forgot to mention that this is on Bullseye, up 
to date as of today (Aug 10th).


This bug is likely related to #991552.




Hello, I probably fixed this bug in debian/2.4.1-2, please check if now it 
works correctly.

Thanks!

Gianfranco

Bug#1005188: Please package newer upstream

[Dmitry Shachnev]

Control: reassign -1 wnpp
Control: retitle -1 RFP: mathjax3 -- math rendering engine for browsers, 
implemented in TypeScript
Control: merge 997945 -1
Control: affects -1 libjs-mathjax

Hi Julien!

On Tue, Feb 08, 2022 at 07:26:03PM +0100, Julien Puydt wrote:
> Package: libjs-mathjax
> Version: 2.7.9+dfsg-1
> Severity: wishlist
>
> I see upstream released 3.20 and I have a package with privacy breaches
> because it looks outside for mathjax files which are not in the current
> version: can you update the package to a newer version?

Unfortunately, nothing changed since you reported #997945. My response
there still applies.

I'm merging these bugs and adding affects: for mathjax2 to make it more
visible.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1005886: additional info

[Tony Power]

I've tried all amd64 ISO-CD installers available here:
https://cdimage.debian.org/cdimage/daily-builds/daily/

The computer is:
Lenovo X1 Carbon Gen 6
Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
Intel Dual Band Wireless-AC 8265 (iwlwifi loads fine, during installation)
Intel Ethernet Connection (4) I219-LM
Samsung Electronics NVMe SSD Controller SM981/PM981/PM983

Everything is currently working fine with Debian bullseye, therefore,
it shouldn't be an hardware problem.

Bug#1005885: missing entries in debian/copyright

[Andreas Tille]

Control: tags -1 pending

Am Wed, Feb 16, 2022 at 05:30:01PM + schrieb Thorsten Alteholz:
> please also mention at least:
>   CamiTK-5.0.2/python_sdk/pyside_global.h
>   Insight Consortium
> in your debian/coypright.

Thanks for spotting this and filing this bug report which is
fixed in Git now.  It will be closed with the source-only upload
after clearing new queue.

Kind regards

Andreas. 

-- 
http://fam-tille.de

Bug#1005887: unixodbc-dev does not contain unixodbc_conf.h

[Lev Lamberov]

Package: unixodbc-dev
Version: 2.3.9-4
Severity: important
X-Debbugs-Cc: dogs...@debian.org

Dear Maintainer,

unixodbc-dev does not ship unixodbc_conf.h (at least, on amd64 and
i386). The version in stable does ship it, but the version in testing
and unstable does not.

It breaks builds of some packages, e. g. build of swi-prolog fails for
32-bit architectures. 32-bit platforms support 64-bit integers and
actually all should as SWI-Prolog cannot work without them. There is a
suggestion that somehow SQLBIGINT is not configured correctly. More
specifically, the missing unixodbc_conf.h should contain either both
or one of

#define HAVE_LONG_LONG 1
#define SIZEOF_LONG_INT 8

With regards,
Lev Lamberov

(Sorry, I'm writing it from Ubuntu, so the following system
information is not relevant.)

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

Kernel: Linux 5.13.0-28-generic (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unixodbc-dev depends on:
ii  libltdl-dev   2.4.6-15
ii  libodbc1  2.3.6-0.1build2
ii  odbcinst1debian2  2.3.6-0.1build2

unixodbc-dev recommends no packages.

unixodbc-dev suggests no packages.

Bug#1005886: cdimage.debian.org: bookworm net-install CD hangs on "Detecting Network Hardware"

[Tony Power]

Package: cdimage.debian.org
Severity: grave
Tags: d-i
Justification: renders package unusable
X-Debbugs-Cc: powe...@gmail.com

Dear Maintainer,

For a few days I've been trying to install Debian bookworm using the 
net-install ISO (e.g., all of today's). All of them hang when it reaches the 
"Detecting Network Hardware". I'm able to switch to the log console, and 
everything seems to be fine, however, that step doesn't work. If I go to the 
disk partitioning step, I have the same problem.

It feels that the options are not displayed.

Cheers,
Tony

Bug#1005885: missing entries in debian/copyright

[Thorsten Alteholz]

Package: camitk
Severity: serious
Usertags: ftp
User: alteh...@debian.org
thanks

Hi,

please also mention at least:
  CamiTK-5.0.2/python_sdk/pyside_global.h
  Insight Consortium
in your debian/coypright.

Thanks!
  Thorsten

Bug#1004894: sudo: [i386] invalid opcode

[Martin-Éric Racine]

On Wed, Feb 16, 2022 at 6:45 PM Marc Haber
 wrote:
> On Tue, Feb 15, 2022 at 09:58:49PM +0200, Martin-Éric Racine wrote:
> > On Tue, Feb 15, 2022 at 9:10 PM Marc Haber
> >  wrote:
> > >
> > > On Tue, Feb 15, 2022 at 09:03:01PM +0200, Martin-Éric Racine wrote:
> > > > 1.9.8p2-1 FTBFS on Geode testing host (log attached earlier)
> > > > 1.9.9-1 FTBFS on Geode testing host (log attached earlier)
> > >
> > > I apologize, I didnt see earlier that your builds were already failing
> > > at build time. The error is
> > >
> > > config.status:1474: error: cannot find input file: 
> > > `plugins/sudoers/sudoers'
> > >
> > > Was that file actually missing in your build chroot? If not, I don't
> > > know what went wrong there.
> >
> > No idea. I unpacked the source and types debuild. That's all.

Btw, the build log has tons of the following:

./configure: cannot duplicate fd -19201 to fd 0: Bad file descriptor

> Can you retry building with the lines 4863-4866:
>
> AX_CHECK_LINK_FLAG([-fcf-protection], [
> AX_APPEND_FLAG([-fcf-protection], [SSP_CFLAGS])
> AX_APPEND_FLAG([-Wc,-fcf-protection], [SSP_LDFLAGS])
> ])
>
> of configure.ac removed? There is suspicion that the hardening options don't
> play too well with Geode LX.

I cannot help but wonder why the build doesn't simply parse
$(HARDENING_CFLAGS) and $(HARDENING_LDFLAGS). Hard-coded hardening
options tend to be a bad idea. GCC supports them all, but the target
host's CPU won't always support them.

during GIMPLE pass: cunroll
../../../lib/util/event.c: In function ‘sudo_ev_add_v2’:
../../../lib/util/event.c:465:1: internal compiler error: in
graphds_scc, at graphds.c:316
  465 | sudo_ev_add_v2(struct sudo_event_base *base, struct sudo_event *ev,
  | ^~
0xb754d904 __libc_start_main
../csu/libc-start.c:332
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.

***

diff -Nru sudo-1.9.9/debian/changelog sudo-1.9.9/debian/changelog
--- sudo-1.9.9/debian/changelog2022-01-31 21:19:55.0 +0200
+++ sudo-1.9.9/debian/changelog2022-02-16 18:56:31.0 +0200
@@ -1,3 +1,9 @@
+sudo (1.9.9-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+
+ -- Martin-Éric Racine   Wed, 16 Feb 2022
18:56:31 +0200
+
 sudo (1.9.9-1) unstable; urgency=medium

   * new upstream version
diff -Nru sudo-1.9.9/debian/patches/remove-fcf-protection.patch
sudo-1.9.9/debian/patches/remove-fcf-protection.patch
--- sudo-1.9.9/debian/patches/remove-fcf-protection.patch
1970-01-01 02:00:00.0 +0200
+++ sudo-1.9.9/debian/patches/remove-fcf-protection.patch
2022-02-16 18:56:31.0 +0200
@@ -0,0 +1,42 @@
+Description: 
+ TODO: Put a short summary on the line above and replace this paragraph
+ with a longer explanation of this change. Complete the meta-information
+ with other relevant fields (see below for details). To make it easier, the
+ information below has been extracted from the changelog. Adjust it or drop
+ it.
+ .
+ sudo (1.9.9-1.1) UNRELEASED; urgency=medium
+ .
+   * Non-maintainer upload.
+Author: Martin-Éric Racine 
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: , 
+Bug: 
+Bug-Debian: https://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded: 
+Reviewed-By: 
+Last-Update: 2022-02-16
+
+--- sudo-1.9.9.orig/configure.ac
 sudo-1.9.9/configure.ac
+@@ -4860,10 +4860,10 @@ if test "$enable_hardening" != "no"; the
+ AX_APPEND_FLAG([-fstack-clash-protection], [SSP_CFLAGS])
+ AX_APPEND_FLAG([-Wc,-fstack-clash-protection], [SSP_LDFLAGS])
+ ])
+-AX_CHECK_LINK_FLAG([-fcf-protection], [
+-AX_APPEND_FLAG([-fcf-protection], [SSP_CFLAGS])
+-AX_APPEND_FLAG([-Wc,-fcf-protection], [SSP_LDFLAGS])
+-])
++dnl AX_CHECK_LINK_FLAG([-fcf-protection], [
++dnlAX_APPEND_FLAG([-fcf-protection], [SSP_CFLAGS])
++dnlAX_APPEND_FLAG([-Wc,-fcf-protection], [SSP_LDFLAGS])
++dnl])
+ AX_CHECK_LINK_FLAG([-Wl,-z,relro],
[AX_APPEND_FLAG([-Wl,-z,relro], [LDFLAGS])])
+ AX_CHECK_LINK_FLAG([-Wl,-z,now], [AX_APPEND_FLAG([-Wl,-z,now],
[LDFLAGS])])
+ AX_CHECK_LINK_FLAG([-Wl,-z,noexecstack],
[AX_APPEND_FLAG([-Wl,-z,noexecstack], [LDFLAGS])])
diff -Nru sudo-1.9.9/debian/patches/series sudo-1.9.9/debian/patches/series
--- sudo-1.9.9/debian/patches/series2022-01-31 21:19:55.0 +0200
+++ sudo-1.9.9/debian/patches/series2022-02-16 18:56:31.0 +0200
@@ -1,3 +1,4 @@
 paths-in-samples.diff
 Whitelist-DPKG_COLORS-environment-variable.diff
 sudo-ldap-docs
+remove-fcf-protection.patch

Martin-Éric

Bug#1005622: [Pkg-utopia-maintainers] Bug#1005622: libblockdev: FTBFS: dpkg-gensymbols: error: some new symbols appeared in the symbols file: see diff output below

[GCS]

Hi,

Sorry for the symlink breakage.

On Mon, Feb 14, 2022 at 6:54 PM Michael Biebl  wrote:
> While speaking of getting rid off unnecessary complexity: Is the
> separate udeb build still needed?
 This is what I sometimes decide to evaluate, but then time goes on
something else. :(
Now I'm going to upload Helmut's fix, thanks for that!

Regards,
Laszlo/GCS

Bug#1005669: binutils-or1k-elf: FTBFS: autoreconf2.69: 'configure.ac' or 'configure.in' is required

[Nicolas Boulenguez]

Source: binutils-or1k-elf
Followup-For: Bug #1005669

> > Apparently, a configure.ac has been forgotten alongside the generated
> > configure.
> > Commit dd96117a5e1da80ad1f977ea8abe39acc9f7e7cb works around the
> > issue.

> Hmm - I don't see the commit you mention above - did you perhaps forget
> to push?  Otherwise please provide me a URI so I know exactly what you
> are talking about.

I don’t know what is wrong. I can see it at:
https://salsa.debian.org/debian/binutils-or1k-elf/-/commit/dd96117a5e1da80ad1f977ea8abe39acc9f7e7cb

I am attaching the patch just in case.

> Also, I can suggest that you post the information to
> 1005...@bugs.debian.org instead of discretely here.

You are right, of course. Done.

Thanks.
>From dd96117a5e1da80ad1f977ea8abe39acc9f7e7cb Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Sun, 13 Feb 2022 19:07:19 +0100
Subject: debian/autoreconf: skip etc/ in 2.38-1, configure.ac is missing


diff --git a/debian/autoreconf b/debian/autoreconf
index f2daa59..88e8205 100755
--- a/debian/autoreconf
+++ b/debian/autoreconf
@@ -12,6 +12,9 @@ set -C -e -u
 # Exclude zlib, which fails (binutils/2.35.2 autoconf/2.71).
 # It is ignored in favor of the Debian package anyway.
 
+# Exclude etc, which contains etc/configure but not its source
+# (since 2.38-1).
+
 echo src
 
-dirname src/*/configure | grep -v -e zlib -e libiberty
+dirname src/*/configure | grep -v -e zlib -e libiberty -e etc

Bug#1004894: sudo: [i386] invalid opcode

[Marc Haber]

Hi,

On Tue, Feb 15, 2022 at 09:58:49PM +0200, Martin-Éric Racine wrote:
> On Tue, Feb 15, 2022 at 9:10 PM Marc Haber
>  wrote:
> >
> > On Tue, Feb 15, 2022 at 09:03:01PM +0200, Martin-Éric Racine wrote:
> > > 1.9.8p2-1 FTBFS on Geode testing host (log attached earlier)
> > > 1.9.9-1 FTBFS on Geode testing host (log attached earlier)
> >
> > I apologize, I didnt see earlier that your builds were already failing
> > at build time. The error is
> >
> > config.status:1474: error: cannot find input file: `plugins/sudoers/sudoers'
> >
> > Was that file actually missing in your build chroot? If not, I don't
> > know what went wrong there.
> 
> No idea. I unpacked the source and types debuild. That's all.

Can you retry building with the lines 4863-4866:

AX_CHECK_LINK_FLAG([-fcf-protection], [
AX_APPEND_FLAG([-fcf-protection], [SSP_CFLAGS])
AX_APPEND_FLAG([-Wc,-fcf-protection], [SSP_LDFLAGS])
])

of configure.ac removed? There is suspicion that the hardening options don't
play too well with Geode LX.

Greetings
Marc

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

Bug#1005883: dxvk: Please make autopkgtests cross-test-friendly

[Graham Inggs]

Source: dxvk
Version: 1.9.4+ds1-1

Hi Maintainer

dxvk has an autopkgtest dependency on wine-development, which is an
arch:all package that Depends: wine64-development |
wine32-development.

When dxvk's autopkgtests are run in a pure i386 environment,
wine64-development is not installable, and wine32-development will be
installed.  However, if one tries to run dxvk's i386 autopkgtest on an
amd64 host, then wine64-development satisfies the dependency, and the
autopkgtest fails.

Please consider applying the patch below, which ensures the correct
packages are installed for testing the i386 binaries on an amd64 host,
and should have no negative effect when testing in pure i386 or amd64
environments.

Regards
Graham


--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,3 +1,10 @@
 Tests: check-dxvk-setup
-Depends: @, wine-development, xvfb, xauth
+Depends: dxvk,
+ dxvk-wine64-development [amd64],
+ dxvk-wine32-development [i386],
+ wine-development,
+ wine64-development [amd64],
+ wine32-development [i386],
+ xvfb,
+ xauth
 Restrictions: allow-stderr

Bug#1005882: modsecurity-apache: Typo in homepage URL, leading to 404

[Fiona Klute]

Source: modsecurity-apache
Version: 2.9.5-1
Severity: minor

The homepage URL listed in debian/control is
https://github.com/SpiderLapbs/ModSecurity, which doesn't exist.
debian/watch correctly uses https://github.com/SpiderLabs/ModSecurity,
so I guess it's just a typo. Please fix the homepage URL.


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

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

Bug#990464: Kdump is unable to use NVME

[Guilherme G. Piccoli]

On Mon, 27 Dec 2021 09:44:24 -0600 Kody Barks 
wrote:
> Kernel 5.10, and an upgrade to Bullseye. This issue is still not fixed.

Hi Kody, can you please share the outputs of the following 3 commands?

lspci -nns :09:00.0
lspci -nns :41:00.0
lspci -nns :42:00.0

Also, do you remember of a specific kernel version that ever worked with
these drivers on kdump?
Thanks,


Guilherme


P.S. Please don't forget to CC me when responding, I'm not sure if I'd
receive responses to the bug only, I'm not subscribed it seems.

Bug#1005881: runit-init: Not installable in bookworm.

[David Essam]

Package: runit-init
Severity: grave
Justification: renders package unusable

Dear maintainer,

I just tried to switch to runit-init on bookworm, as I have done many times on 
installs of stable (bullseye).

On a new install with only standard system utilities I executed "apt-get 
install runit init"
What I expected to happen was for apt to complain & to have to repeat the 
command with 
--allow-remove-essential specified, watch it install, then reboot to a system 
using runit-init as pid 1.

What happened:
Apt still refused to install it, citing init pre-depends on systemd-sysv or 
sysvinit-core and that neither are installable.
Which is funny given currently apt-cache policy systemd-sysv shows version 
250.3-2 installed, the very thing I wish to switch
away from.

What I expected to happen, is for it to install, then to reboot into a system 
using runit-init & configure from there
just as I can when running stable. Even if I had to specify 
--allow-remove-essential. However, neither that nor even
--force-yes would cause runit-init to be installed.

I also tried with runit & runit-run installed, just to see if having those 
present already helped, it didn't.

The attempt did leave my system broken though I had to apt-get install 
--reinstall systemd-sysv then 
apt-get remove runit* before it would behave again.

I iaso tried switching to sysvinit-core first, that switch went well, but the 
attempt to switch to runit-init
had a very similar outcome, namely I couldn't find any way to install the 
package.

Currently I can see no method available to get this package installed.

It's possible of course that this is a bug in apt & needs reassigning, that 
however, is beyond my pay-grade to decide.


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

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

Versions of packages runit-init depends on:
pn  getty-run
pn  initscripts  
pn  insserv  
ii  runit2.1.2-44

runit-init recommends no packages.

runit-init suggests no packages.

Bug#1005862: apt: Feature request - apt-get Source IP

[Joe Botha]

Hi

I figured out a temporary workaround using ‘ip netns exec’

It works, but things like apticron will still fail.




-- 
Swimmingly,
 Joe

swimgeek.com/blog  +27 82 562 6167  instagram.com/joe.swimgeek
  "...all progress depends on the unreasonable man.”




> On 16 Feb 2022, at 11:24, Joe Botha  wrote:
> 
> Hi
> 
> Yes, sorry, should maybe have had title with Source _IP_address_
> 
> I think you should be able to specify a source IP when opening the tcp socket.
> 
> Would probably need to add some code for IPv4 and IPv6 cases.
> 
> -- 
> Swimmingly,
> Joe
> 
> swimgeek.com/blog  +27 82 562 6167  instagram.com/joe.swimgeek
>  "...all progress depends on the unreasonable man.”
> 
> 
> 
> 
>> On 16 Feb 2022, at 11:11, Julian Andres Klode  wrote:
>> 
>> On Wed, Feb 16, 2022 at 10:42:57AM +0200, Joe Botha wrote:
>>> Package: apt
>>> Version: 2.2.4
>>> Severity: wishlist
>>> Tags: ipv6
>>> 
>>> Dear Maintainer,
>>> 
>>> *** Reporter, please consider answering these questions, where appropriate 
>>> ***
>>> 
>>> I use Debian on a server with multiple upstream internet links. Some of 
>>> these links have peering point IPs.
>>> 
>>> It happens fairly often that apt-get traffic uses the source IP in a 
>>> peering point range and then downloads fail.
>>> 
>>> Please consider adding a feature so I can configure apt-get to specify a 
>>> source IP or interface on the server.
>>> 
>>> For example: traceroute has a -s option: "Chooses  an alternative source 
>>> address."
>> 
>> I was about to say that specifying ip addresses for sources needs to be
>> solved at an RFC level (need to standardize URLs like http://foo[ip]/), 
>> but um now I understand that you don't want to configure the IP of the
>> source, but the interface we send packets from.
>> 
>> Probably should be retitled with a less ambiguous title :D
>> 
>> Anyway, no idea how complex that feature is, I guess proof of
>> concept patches welcome.
>> 
>> -- 
>> debian developer - deb.li/jak | jak-linux.org - free software dev
>> ubuntu core developer  i speak de, en
> 

Bug#1005880: build depend on toml11

[Thomas Koch]

Source: nix
Version: 2.6.0+dfsg-3
Severity: minor
Tags: newcomer

The nix upstream package bundles a convenience copy of toml11. Since toml11
has been packaged now, it should also be used.

Bug#977223: guile-3.0: FTBFS on hppa - segmentation faults

[John Paul Adrian Glaubitz]

Hello!

On 10/3/21 12:43, John Paul Adrian Glaubitz wrote:
> The attached patch fixes the problem for me. It was suggested by Efraim 
> Flashner
> in the corresponding upstream bug report [1].
> 
> It simply adds "-Oresolve-primitives -Ocps" to GUILE_OPTIMIZATIONS in 
> bootstrap/
> Makefile.am. I have tried coming up a with a solution to add these flags on 
> hppa,
> m68k and powerpc only but I couldn't find any suitable solution.
> 
> However, I would assume that passing these flags to the bootstrap build won't 
> hurt
> as the second stage is built with -O2 anyway and the above flags are not 
> being used
> in this case.

Any chance this patch could be included for the next upload?

This bug is currently blocking package builds on powerpc.

Adrian

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

Bug#1005879: build depend on toml11

[Thomas Koch]

Source: nix
Version: 2.6.0+dfsg-3
Severity: minor
Tags: newcomer

The nix upstream package bundles a convenience copy of toml11. Since toml11
has been packaged now, it should also be used.

Bug#1005878: s3curl: include --endpoint (and --servicePath) not-upstream patch

[Luca Capello]

Package: s3curl
Version: 20171008-1.1
Severity: wishlist
Tags: patch
User: l...@pca.it
Usertags: unige.ch-s3
User: stor...@unige.ch
Usertags: unige.ch-s3

Hi there,

while testing the UNIGE S3 internal instance (not provided by Amazon),
I discovered a patch adding support for the --endpoint (and
--servicePath) parameter :

  

Without this, the custom `endpoint` must be manually added in the Perl
code, so it could be a useful addition IMHO, especially considering that
at least another similar patch exists (albeit based on a fork of the
code above):

  
   


Thx, bye,
Gismo / Luca

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

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

Versions of packages s3curl depends on:
ii  curl 7.74.0-1.3+deb11u1
ii  libdigest-hmac-perl  1.03+dfsg-2.1
ii  libdigest-md5-file-perl  0.08-1.1
ii  libfindbin-libs-perl 2.190.02-1
ii  libgetopt-long-descriptive-perl  0.105-1

s3curl recommends no packages.

s3curl suggests no packages.

-- no debconf information

-- 
Dr. Luca Capello
Ingénieur stockage
Division du Système et des Technologies de l'Information et de la Communication
Université de Genève | 24 rue Général-Dufour | 1204 Genève
Tél +41 22 379 77 69 | Bureau 155
mailto:luca.cape...@unige.ch


signature.asc
Description: PGP signature

Bug#1005876: [Pkg-zsh-devel] Bug#1005876: zsh: Version mismatch with zsh-common

[Axel Beckert]

Hi,

inasprecali wrote:
> package zsh-common was recently updated from version 5.8-6 to version
> 5.8-6+deb11u1 to address CVE-2021-45444.  However, package zsh is still
> stuck at version 5.8-6,

Yeah, something went wrong on the build daemons. We are aware of it
and it should soon be fixed and builds for the arch:any binary
packages of zsh should be available then, too.

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


signature.asc
Description: PGP signature

Bug#1005873: gbp 0.9.26 will break dgit --gbp

[Andrej Shadura]

Hello,

On 16/02/2022 14:39, Andrej Shadura wrote:

dgit: error: subprocess failed with error exit status 1
! Push failed, before we got started.
! You can retry the push, after fixing the problem, if you like.


Here’s a log of a session in which I reproduced the issue from the 
scratch. Sorry for the line wrapping.


andrewsh@nuevo /t/test-gbp> dgit clone hello
canonical suite name for unstable is sid
starting new git history
last upload to archive: NO git hash
  % Total% Received % Xferd  Average Speed   TimeTime Time 
Current
 Dload  Upload   Total   SpentLeft 
Speed
100  708k  100  708k0 0  1868k  0 --:--:-- --:--:-- --:--:-- 
1865k
  % Total% Received % Xferd  Average Speed   TimeTime Time 
Current
 Dload  Upload   Total   SpentLeft 
Speed
100  6132  100  61320 0   1174  0  0:00:05  0:00:05 --:--:-- 
 1436

dpkg-source: info: extracting hello in hello-2.10
dpkg-source: info: unpacking hello_2.10.orig.tar.gz
dpkg-source: info: unpacking hello_2.10-2.debian.tar.xz
synthesised git commit from .dsc 2.10-2
HEAD is now at a72f60c8c312 hello (2.10-2) unstable; urgency=medium
dgit ok: ready for work in hello
andrewsh@nuevo /t/test-gbp> cd hello
andrewsh@nuevo /t/t/hello (dgit/sid)> gbp pq import
gbp:info: Trying to apply patches at 
'a72f60c8c31288e3e3715d0409c74faee35b3b18'
gbp:info: 0 patches listed in 'debian/patches/series' imported on 
'patch-queue/dgit/sid'
andrewsh@nuevo /t/t/hello (patch-queue/dgit/sid)> echo super important 
change >> README

andrewsh@nuevo /t/t/hello (patch-queue/dgit/sid)> git diff
diff --git a/README b/README
index cf22cf9d3e7f..4353e9e0eef3 100644
--- a/README
+++ b/README
@@ -74,3 +74,4 @@ order to be a canonical example of a GNU package. 
Many people have

 contributed; please see the AUTHORS and ChangeLog files.

 GNU Hello is free software.  See the file COPYING for copying conditions.
+super important change
andrewsh@nuevo /t/t/hello (patch-queue/dgit/sid)> git commit -a -m "A 
super important change"

[patch-queue/dgit/sid 61571bd130b0] A super important change
 1 file changed, 1 insertion(+)
andrewsh@nuevo /t/t/hello (patch-queue/dgit/sid)> gbp pq export
gbp:info: On 'patch-queue/dgit/sid', switching to 'dgit/sid'
gbp:info: Generating patches from git (dgit/sid..patch-queue/dgit/sid)
andrewsh@nuevo /t/t/hello (dgit/sid)> git status
On branch dgit/sid
Untracked files:
  (use "git add ..." to include in what will be committed)
debian/patches/

nothing added to commit but untracked files present (use "git add" to track)
andrewsh@nuevo /t/t/hello (dgit/sid)> git add debian/patches/
andrewsh@nuevo /t/t/hello (dgit/sid)> git commit -a -m "Add a patch for 
a super important change"

[dgit/sid 67da756416d3] Add a patch for a super important change
 2 files changed, 18 insertions(+)
 create mode 100644 debian/patches/0001-A-super-important-change.patch
 create mode 100644 debian/patches/series
andrewsh@nuevo /t/t/hello (dgit/sid)> dgit build-source
Format `3.0 (quilt)', need to check/update patch stack
dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
examining quilt state (multiple patches, gbp mode)
dgit: base trees orig=d05377ef3e3d210f0b5c o+d/p=1c1466eaf095c2031ea6
dgit: quilt differences: src:  == orig ## gitignores:  == orig ==
dgit: quilt differences:  HEAD ## o+d/p   HEAD == o+d/p
dgit view: creating patches-applied version using gbp pq
gbp:error: You have uncommitted changes in your source tree:
gbp:error: On branch dgit-view
Untracked files:
  (use "git add ..." to include in what will be committed)
.pc/

nothing added to commit but untracked files present (use "git add" to track)

gbp:error: Use --ignore-new to ignore.
dgit: failed command: sh -ec 'exec >/dev/null; exec "$@"' x gbp pq import

dgit: error: subprocess failed with error exit status 1
andrewsh@nuevo /t/t/hello (dgit/sid)>


--
Cheers,
  Andrej

Bug#983349: hplip

[David Ward]

On 8/29/2021 4:12 AM, alain wrote:

$ dpkg -l sane-backends
dpkg-query: aucun paquet ne correspond à sane-backends


sane-backends is the source package name. You cannot install that.

Please run "sudo apt upgrade libsane-common".


$ cat /etc/debian_version
bookworm/sid
$ dpkg-query -l 'hplip*' 'libsane*' 'sane*' | cat
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name    Version Architecture Description
+++-===-===--===
ii  hplip   3.21.12+dfsg0-1 amd64    HP Linux Printing 
and Imaging System (HPLIP)
ii  hplip-data  3.21.12+dfsg0-1 all  HP Linux Printing 
and Imaging - data files

un  hplip-doc      (no description available)
ii  hplip-gui   3.21.12+dfsg0-1 all  HP Linux Printing 
and Imaging - GUI utilities (Qt-based)

un  libsane    (no description available)
ii  libsane-common  1.1.1-2 all  API library for 
scanners -- documentation and support files
ii  libsane-hpaio:amd64 3.21.12+dfsg0-1 amd64    HP SANE backend for 
multi-function peripherals
ii  libsane1:amd64  1.1.1-2 amd64    API library for 
scanners
ii  sane-utils  1.1.1-2 amd64    API library for 
scanners -- utilities

Bug#1005877: ITP: jangouts -- videoconferencing web service using Janus Gateway

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian VoIP Team 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: jangouts
  Version : 0.5.0
  Upstream Author : SUSE Linux
* URL : https://github.com/jangouts/jangouts
* License : Expat
  Programming Lang: JavaScript
  Description : videoconferencing web service using Janus Gateway

 Jangouts (for "Janus Hangouts") is a solution
 for videoconferencing based on WebRTC
 and the excellent Janus Gateway,
 with a user interface loosely inspired by Google Hangouts.
 It aims to provide a completely self-hosted open source alternative
 to Google Hangouts and similar solutions.
 Currently Jangouts supports conferences with video, audio,
 screen sharing and textual chat
 organized into an unlimited amount of conference rooms
 with a configurable limit of participants per room.
 .
 Janus is a general purpose WebRTC server/gateway
 with a minimal footprint.

Package will be maintained by the VoIP team using Salsa
at .

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmINDjYACgkQLHwxRsGg
ASEWTQ/9GQIJjsSlilz6ORTy0e8TMLSqz1b0D8ZWBpmWlGdMnF8MSIbld6ugcn8Y
AjMUlSwqzKpVIqc+Iz3xTe7vPUaqp4+/UBz+SHtuh7Wau2TL6fAv51hhjEcjrbWi
8DgNPlURTdzSKp+s60u8e8xDwimW/oekSImCEWf5efKQFkrQx/FAAY4NNfNvKGsR
vdL89K97Ry2L4Y93g/crXdCzjuIbHrQBRi2dRmKgpbR5PlQCXiOPLcOvcQSZbuvA
2dBPlOrOnmTxJAArYKOYXjeYpHG9moylCOUDETWBVfd+u8X8gB51DrYYkJp++5QE
uvLf3+GrFgBV/rX4aCs/9iZdT6c/zF7attvQ7WHke+5SURt5izSpMaqoaGCfTysJ
JMDwas1xBhC4Hx9JuEJ1HccSm/fO2xdrgPpqSnPdtGn35vhXuS3fiDuE820qSYZe
KBYRvOJnd0zJd/mnYIwxvWdbSSFwVw0EQqAemKjrw/iz7MIo5iQQYBhhA9H0R+Im
tXIyy9GoaHYKYLQtVkLBgQAlprdLVrOw5pDXlWuDoSHNT8H7M2fs8qm1wk03BtmZ
1qPeXGcqgSvpxYe9fAc6SsNJ9WgszWuRcD6kOvub5vGBHh8MrUvHWfPnF4+e/gUE
HSUWLK9GiVEt02EuGuLIHOatXkL7pOisScbs+twDhfw7oO3PHYU=
=RtCK
-END PGP SIGNATURE-

Bug#1005011: Please fix capnproto in unstable as well (Was: Re: Bug#1005011: fixed in capnproto 0.9.1-2)

[tony mancill]

On Wed, Feb 16, 2022 at 05:01:49PM +0530, Nilesh Patra wrote:
> 
> Tony/Tom, Can you do corresponding fixes for unstable too,
> or otherwise move experimental release to unstable?
> 
> Otherwise this bug is causing a un-warranted-for autorm, for example in 
> parsnp[1]
 
Hi Nilesh,

Thanks for the reminder; this work is already underway.  It's not as
simple as merely copying the changes made in 0.9.1 to the version in
unstable because they are different sources.

For what it's worth (nothing, I suppose), this is why I questioned the
severity of the filed bug in the first place.  I maintain that there are
many packages in Debian that don't have the copyright for every single
file in the source distribution correctly attributed in
debian/copyright, and yet don't have RC bugs file against them.

Thanks,
tony


signature.asc
Description: PGP signature

Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database

[Enrico Zini]

On Sat, Feb 12, 2022 at 08:51:01PM +0100, Enrico Zini wrote:

> That's even better, then: it becomes a matter of documenting the
> procedure to bootstrap an rpm-based distro from Debian: I can test it
> and produce a draft HOWTO.

I tested, and I confirm that this works:

   dnf -c "$CONFFILE" -y --disablerepo=* --enablerepo=chroot-base 
--disableplugin=* \
   --installroot="$DESTDIR" --releasever="$VERSION" install
   if [ -d "$DESTDIR/root/.rpmdb" ]; then
   rm -rf "$DESTDIR/var/lib/rpm"
   mv "$DESTDIR/root/.rpmdb" "$DESTDIR/var/lib/rpm"
   systemd-nspawn -D "$DESTDIR" -- /usr/bin/rpmdb --rebuilddb
   fi

I wonder where would be the right place to document this. README.Debian
maybe?


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#1005804: xserver-xorg-video-nvidia-legacy-390xx: does not depend on xorg-video-abi-25

[Vincent Lefevre]

On 2022-02-15 13:06:57 +0100, Andreas Beckmann wrote:
> If you force the installation of the driver with the new X server, can you
> confirm that the driver works without complaining about an ABI mismatch?

This seems to work on my desktop machine at my lab.

cventin:~> dpkg -l | grep -E '390xx|xserver'
ii  libegl-nvidia-legacy-390xx0:amd64390.147-1+b1   
 amd64NVIDIA binary EGL library (390xx legacy version)
ii  libgl1-nvidia-legacy-390xx-glvnd-glx:amd64   390.147-1+b1   
 amd64NVIDIA binary OpenGL/GLX library (GLVND variant) (390xx 
legacy version)
ii  libglx-nvidia-legacy-390xx0:amd64390.147-1+b1   
 amd64NVIDIA binary GLX library (390xx legacy version)
ii  libglx-nvidia-legacy-390xx0:i386 390.147-1+b1   
 i386 NVIDIA binary GLX library (390xx legacy version)
ii  libnvidia-legacy-390xx-cfg1:amd64390.147-1+b1   
 amd64NVIDIA binary OpenGL/GLX configuration library (390xx legacy 
version)
ii  libnvidia-legacy-390xx-cfg1:i386 390.147-1+b1   
 i386 NVIDIA binary OpenGL/GLX configuration library (390xx legacy 
version)
ii  libnvidia-legacy-390xx-cuda1:amd64   390.147-1+b1   
 amd64NVIDIA CUDA Driver Library (390xx legacy version)
ii  libnvidia-legacy-390xx-cuda1:i386390.147-1+b1   
 i386 NVIDIA CUDA Driver Library (390xx legacy version)
ii  libnvidia-legacy-390xx-cuda1-i386:i386   390.147-1+b1   
 i386 NVIDIA CUDA 32-bit runtime library (390xx legacy version)
ii  libnvidia-legacy-390xx-eglcore:amd64 390.147-1+b1   
 amd64NVIDIA binary EGL core libraries (390xx legacy version)
ii  libnvidia-legacy-390xx-fatbinaryloader:amd64 390.147-1+b1   
 amd64NVIDIA FAT binary loader (390xx legacy version)
ii  libnvidia-legacy-390xx-fatbinaryloader:i386  390.147-1+b1   
 i386 NVIDIA FAT binary loader (390xx legacy version)
ii  libnvidia-legacy-390xx-glcore:amd64  390.147-1+b1   
 amd64NVIDIA binary OpenGL/GLX core libraries (390xx legacy version)
ii  libnvidia-legacy-390xx-glcore:i386   390.147-1+b1   
 i386 NVIDIA binary OpenGL/GLX core libraries (390xx legacy version)
ii  libnvidia-legacy-390xx-ml1:amd64 390.147-1+b1   
 amd64NVIDIA Management Library (NVML) runtime library (390xx 
legacy version)
ii  libnvidia-legacy-390xx-ml1:i386  390.147-1+b1   
 i386 NVIDIA Management Library (NVML) runtime library (390xx 
legacy version)
ii  libnvidia-legacy-390xx-ptxjitcompiler1:amd64 390.147-1+b1   
 amd64NVIDIA PTX JIT Compiler library (390xx legacy version)
ii  libnvidia-legacy-390xx-ptxjitcompiler1:i386  390.147-1+b1   
 i386 NVIDIA PTX JIT Compiler library (390xx legacy version)
ii  nvidia-legacy-390xx-alternative  390.147-1+b1   
 amd64allows the selection of NVIDIA as GLX provider (390xx legacy 
version)
ii  nvidia-legacy-390xx-driver   390.147-1+b1   
 amd64NVIDIA metapackage (390xx legacy version)
ii  nvidia-legacy-390xx-driver-bin   390.147-1+b1   
 amd64NVIDIA driver support binaries (390xx legacy version)
ii  nvidia-legacy-390xx-driver-libs:amd64390.147-1+b1   
 amd64NVIDIA metapackage (OpenGL/GLX/EGL/GLES libraries) (390xx 
legacy version)
ii  nvidia-legacy-390xx-egl-icd:amd64390.147-1+b1   
 amd64NVIDIA EGL installable client driver (ICD)
ii  nvidia-legacy-390xx-kernel-dkms  390.147-1+b1   
 amd64NVIDIA binary kernel module DKMS source (390xx legacy version)
ii  nvidia-legacy-390xx-kernel-support   390.147-1+b1   
 amd64NVIDIA binary kernel module support files (390xx legacy 
version)
ii  nvidia-legacy-390xx-smi:i386 390.147-1+b1   
 i386 NVIDIA System Management Interface (390xx legacy version)
ii  nvidia-legacy-390xx-vdpau-driver:amd64   390.147-1+b1   
 amd64Video Decode and Presentation API for Unix - NVIDIA driver 
(390xx legacy)
ii  nvidia-legacy-390xx-vulkan-icd:amd64 390.147-1+b1   
 amd64NVIDIA Vulkan installable client driver (ICD) (390xx legacy 
version)
ii  nvidia-legacy-390xx-vulkan-icd:i386  390.147-1+b1   
 i386 NVIDIA Vulkan installable client driver (ICD) (390xx legacy 
version)
ii  nvidia-settings-legacy-390xx 390.147-1  
 

Bug#1000868: High power drain while in s2idle suspend mode

[mapsonon]

Hi,

 

yesterday, I have received new FW from Seagate (SU6SM003) which solves my 
problem. Power consumption during s2idle sleep is about 230mW/h.

 

Sorry for disturbing,


Milos.

Bug#1005872: [Pkg-javascript-devel] Bug#1005872: node-istanbul: Remove libjs-prettify dependency

[Jonas Smedegaard]

Quoting Vignesh Raman (2022-02-16 14:34:17)
> prettify.js is unmaintanined https://github.com/googlearchive/code-prettify.
> node-istanbul has vendored copy of prettify.js and it can that instead of
> prettify.js,
> 
> Attached is a patch to remove dependency on libjs-prettify and to use
> the vendor provided prettify.js. Please let me know
> you opinion on this. Thanks.

Please do *not* hide problems like that.

If package src:prettify.js is broken and upstream is dead, then it is 
wrong to move to embedded snapshots, because that does not solve the 
issue of code being unmaintained, only hides it!

Instead, please patch package src:prettify.js as needed.

Or if package src:prettify.js is unmaintainable even with patches, then 
it is an indication that code should be *avoided* in Debian, which means 
that instead reverse dependencies of package src:prettify.js should be 
patches to *not* use prettify.js at all.

Obviously, if package src:prettify.js works fine without patches, then 
it is not a problem that upstream is dead and there is no reason to 
embed nor to patch anything.


 - 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#1005875: ITP: python-headerparser -- Python module to parse key-value pairs in the style of RFC 822 headers

[Stephan Lachnit]

Package: wnpp
Severity: wishlist
Owner: Stephan Lachnit 
X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@debian.org

* Package name: python-headerparser
  Version : 0.4.0
  Upstream Author : John T. Wodder II
* URL : https://github.com/jwodder/headerparser
* License : MIT
  Programming Lang: Python
  Description : Python module to parse key-value pairs in the style of RFC
822 headers


I intend this maintain this in the Debian Python Team. I will use this library
for my ongoing work to convert SPDX documents to DEP5 documents [1]. The reason
I won't use python-debian is that it is apparently a bit buggy on non-Debian
systems.

Regards,
Stephan

[1] https://lists.debian.org/debian-devel/2022/02/msg00207.html


The long description from the readme:

headerparser parses key-value pairs in the style of RFC 822 (e-mail) headers
and converts them into case-insensitive dictionaries with the trailing message
body (if any) attached. Fields can be converted to other types, marked
required, or given default values using an API based on the standard library’s
argparse module. (Everyone loves argparse, right?) Low-level functions for just
scanning header fields (breaking them into sequences of key-value pairs without
any further processing) are also included.

RFC 822-style headers are header fields that follow the general format of
e-mail headers as specified by RFC 822 and friends: each field is a line of the
form “Name: Value”, with long values continued onto multiple lines (“folded”)
by indenting the extra lines. A blank line marks the end of the header section
and the beginning of the message body.

This basic grammar has been used by numerous textual formats besides e-mail,
including but not limited to:

HTTP request & response headers
Usenet messages
most Python packaging metadata files
Debian packaging control files
META-INF/MANIFEST.MF files in Java JARs
a subset of the YAML serialization format

- all of which this package can parse.

Bug#1005874: dnsmasq: TFTP server disregards bind-interfaces & co.

[Martin-Éric Racine]

Package: dnsmasq
Version: 2.85-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

If 'enable-tftp' is set, the TFTP server appears on all interfaces. It 
completely disregards bind-interfaces and friends. One would think that TFTP 
would only be offered on interfaces where dnsmasq happens to offer DHCP 
services (since DHCP essentially is a superset of BOOTP, to which TFTP is 
related), but apparently not.

The relevant part of my config:

bind-interfaces
interface=br0
except-interface=enp4s0
no-dhcp-interface=enp4s0

IMHO, the only service that dnsmasq should offer on both loopback and 
'interface' is DNS. It ought to be possible to bind every other service that 
dnsmasq can offer to specific interfaces.

If the above already is possible, but my particular combination of 
bind-interfaces/interface/except-interface/no-dhcp-interface prevents that, I 
welcome tips on how to fix it.

Martin-Éric

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

Kernel: Linux 5.10.0-11-amd64 (SMP w/8 CPU threads)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dnsmasq depends on:
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  netbase  6.3
ii  runit-helper 2.10.3

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
pn  resolvconf  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmIM/0IACgkQrh+Cd8S0
17YxjQ//fWx8Gq8SlkyP9MGBtnvvYoWX3Vov2i2QPNXgAoBIhbsyA6ELxYQVT/9B
oYViMGJxXxkU7+JmjZ5FJTKd6rv1hroOfL7N1esdEjh69GUUXxVTjkZ4I95AnE9i
6L3qQmIiq2jbzOK7D8S5bSACfxBUSKFd20eG5CHPJxK7hGaH+JqltiuqbsFCxhxC
OAnZzFeR/tmcLB6npRB0H0fnJmiA+J0S6i6+iI4fGwcnQV7rssK0GKMtqGpxKVVU
8knR/ZD5JkSEQJgKnLRWYkw4Vttjf0UDa5Fiw0WWgcYZHVneciYDAsDAK3G6cPJ6
Vy+A6A2XTgZD0TKzmJWxcWMCcetOMYxHfftdw8Ky+6BcKJ5tqd1jH9C6CLFgsQSU
vnk6LCwxBXz3toN6m7cuhxP8jws7YkVouMfUzwX0jW6MQS1Fw3rr73pKb4ssibDJ
nqqaG4DKdxZ+jOLwYKd0NllaDHauKezf85hMx4wnyVSp+gmPhFFLLjKujIXCiw3u
EvFSRuRas/86HirsCp8WHU7I5YraNv1ksU4IjEn4zwRPPhLiu0fxz4NIKgzhET6R
J+SpXty5rNw68w+m/Nro6OFnMUL1AMoY/JZNPJGvwYMRXl7/gRehgTH+H6KSXT3R
WYMQ0Xy05Slie3GeONeSE5uSw4I3bIJGTaNKUnEPbwCMywjNBKQ=
=7Yhl
-END PGP SIGNATURE-

Bug#1005873: [git-buildpackage/master] pq: Check if repo is clean before importing patches

[Andrej Shadura]

Hi,

On Fri, 11 Feb 2022 14:30:50 +0100 (CET) Guido Günther  
wrote:

tag 1005321 pending
thanks

Date:   Fri Feb 11 11:35:01 2022 +0100
Author: Guido Günther 
Commit ID: 8db5af7326c581014ca07dcd98beac30f2c90d4f
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=8db5af7326c581014ca07dcd98beac30f2c90d4f
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=8db5af7326c581014ca07dcd98beac30f2c90d4f

pq: Check if repo is clean before importing patches


Defaulting to --no-ignore-new breaks dgit --gbp push-source when there 
are patches. As a workaround, I had to stick pq.ignore-new = False into 
my gbp.conf:


$ dgit push-source
Format `3.0 (quilt)', need to check/update patch stack
canonical suite name is bullseye-backports
dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
examining quilt state (multiple patches, gbp mode)
dgit: base trees orig=a2b0298f5ffa80788851 o+d/p=17982c3db326770dc1b2
dgit: quilt differences: src:  == orig ## gitignores:  == orig ==
dgit: quilt differences:  HEAD ## o+d/p   HEAD == o+d/p
dgit view: creating patches-applied version using gbp pq
gbp:error: You have uncommitted changes in your source tree:
gbp:error: On branch dgit-view
Untracked files:
  (use "git add ..." to include in what will be committed)
.pc/

nothing added to commit but untracked files present (use "git add" to track)

gbp:error: Use --ignore-new to ignore.
dgit: failed command: sh -ec 'exec >/dev/null; exec "$@"' x gbp pq import

dgit: error: subprocess failed with error exit status 1
! Push failed, before we got started.
! You can retry the push, after fixing the problem, if you like.


--
Cheers,
  Andrej

Bug#1005872: node-istanbul: Remove libjs-prettify dependency

[Vignesh Raman]

Package: node-istanbul
Version: 0.4.5+ds+~cs56.14.45-1
Severity: normal
Tags: patch
X-Debbugs-Cc: vignesh.ra...@collabora.com

Dear Maintainer,

prettify.js is unmaintanined https://github.com/googlearchive/code-prettify.
node-istanbul has vendored copy of prettify.js and it can that instead of
prettify.js,

Attached is a patch to remove dependency on libjs-prettify and to use
the vendor provided prettify.js. Please let me know
you opinion on this. Thanks.

Regards,
Vignesh

-- System Information:
Debian Release: 11.1
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500, 
'stable-updates'), (500, 'stable-security')
Architecture: amd64 (x86_64)

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

Versions of packages node-istanbul depends on:
pn  handlebars
pn  libjs-prettify
pn  node-abbrev   
pn  node-archy
pn  node-async
pn  node-escodegen
pn  node-esprima  
pn  node-glob 
pn  node-is-stream
pn  node-js-yaml  
pn  node-make-dir 
pn  node-mkdirp   
pn  node-nopt 
pn  node-once 
pn  node-p-map
pn  node-path-key 
pn  node-resolve  
pn  node-rimraf   
pn  node-shebang-command  
pn  node-strip-bom
pn  node-supports-color   
pn  node-type-fest
pn  node-uuid 
pn  node-which
pn  node-wordwrap 
pn  nodejs

Versions of packages node-istanbul recommends:
pn  node-babel7
pn  node-resolve-from  

node-istanbul suggests no packages.
>From a6107a79874aea0ad7d985ee11b795670eb03886 Mon Sep 17 00:00:00 2001
From: Vignesh Raman 
Date: Mon, 14 Feb 2022 19:42:18 +0530
Subject: [PATCH] Remove libjs-prettify dependency

Instead of using the unmaintained prettify.js from
https://github.com/googlearchive/code-prettify, use
the vendored prettify.js and remove the libjs-prettify
dependency.

Signed-off-by: Vignesh Raman 
---
 debian/control  | 2 --
 debian/nodejs/links | 6 ++
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/debian/control b/debian/control
index 8cf1c0a..87e6eab 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,6 @@ Build-Depends:
  , dh-buildinfo
  , dh-sequence-nodejs
  , handlebars 
- , libjs-prettify
  , node-abbrev 
  , node-async 
  , node-babel7 
@@ -38,7 +37,6 @@ Architecture: all
 Depends:
  ${misc:Depends}
  , handlebars
- , libjs-prettify
  , node-abbrev
  , node-async
  , node-escodegen
diff --git a/debian/nodejs/links b/debian/nodejs/links
index b7773cb..ba51f32 100644
--- a/debian/nodejs/links
+++ b/debian/nodejs/links
@@ -1,5 +1,3 @@
-/usr/share/javascript/prettify/prettify.css 
istanbul/lib/assets/vendor/prettify.css
-/usr/share/javascript/prettify/prettify.js  
istanbul/lib/assets/vendor/prettify.js
-/usr/share/javascript/prettify/prettify.css 
istanbul-reports/lib/html/assets/vendor/prettify.css
-/usr/share/javascript/prettify/prettify.js  
istanbul-reports/lib/html/assets/vendor/prettify.js
+/usr/share/nodejs/istanbul-reports/lib/html/assets/vendor/prettify.css 
istanbul/lib/assets/vendor/prettify.css
+/usr/share/nodejs/istanbul-reports/lib/html/assets/vendor/prettify.js 
istanbul/lib/assets/vendor/prettify.js
 istanbul/lib/cli.js /usr/bin/istanbul
-- 
2.30.2

Bug#1001053: can't connect

[Thibault Roulet]

Hi all,

I'm not sure if I have the same issue but from impossible for my users 
to connect the shared folders with samba>4.13.5 from windows desktop.

Password popup is coming back. Everything works fine with samba 4.13.5

I though the last update would fix the issue but nop.


This server is a member of the domain.

Server conf:

[global]

  workgroup = MYDOMAIN
  server string = myserver.corp.com
  realm = MYDOMAIN.corp.com
  security = ADS
  min protocol = SMB2
  client signing = mandatory
  server signing = mandatory
  netbios name = SBFS5

  password server = AD1.MYDOMAIN.corp.com
  wins server = 000.000.15.44

  dedicated keytab file = /etc/krb5.keytab
  kerberos method = secrets and keytab

  hosts allow = 000.000. 000.000. 127. 10.95.

  dns proxy = no
  local master = no
  domain master = no
  log level = 3
  log file = /var/log/samba/log.%I
  max log size = 3000
  template shell = /bin/bash
  winbind use default domain = no

  deadtime = 30

  # winbind settings
  idmap config * : range = 3000 - 8500
  idmap config *: backend = tdb

  idmap config MYDOMAIN: range = 9000 - 900
  idmap config MYDOMAIN: backend = ad
  idmap config MYDOMAIN: schema_mode = rfc2307

  panic action = /usr/share/samba/panic-action %d
  passdb backend = tdbsam

  username map = /etc/samba/smbusers
  username map script = /bin/echo
  unix password sync = yes

  domain logons = yes

  load printers = no
  disable spoolss = yes

  usershare allow guests = yes

And by the way, I enabled this dummy "username map script", else, the 
password popup keeps showing too!


In the logs

  check_account: Failed to find local account with UID 3000 for SID 
S-1-5-21-77949841-363743269-439555115-142182 (dom_user[MYDOMAIN\myusername])
[2022/02/16 10:58:52.246885,  2] 
../../source3/auth/auth.c:344(auth_check_ntlm_password)
  check_ntlm_password:  Authentication for user [myusername] -> 
[myusername] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1
  Auth: [SMB2,(null)] user [MYDOMAIN]\[myusername] at [Wed, 16 Feb 2022 
10:58:52.246922 CET] with [NTLMv2] status [NT_STATUS_NO_SUCH_USER] 
workstation [DESKTOP-KQKF394] remote host [ipv4:xxx.xxx.159.189:50840] 
mapped to [MYDOMAIN]\[myusername]. local host [ipv4:xxx.xxx.241.3:445]
  gensec_spnego_server_negTokenTarg_step: SPNEGO(ntlmssp) login failed: 
NT_STATUS_NO_SUCH_USER


Thanks in advance for your help.

Bug#1005870: Unable to activate singularity container from within boot service script

[Fox, Ron]

Package: singularity-container
Version: 3.5.2+ds2-1
Severity: important

On Debian 11 note this comes from debian-unstable.
I am attempting to activate a singularity squashfs image from a script that runs
at boot time.   Singularity segfaults with the attached debug/traceback in
the attached file portmanager

Here is the tail of that file in case the bug reporting system does not support 
attachments:

sandbox format initializer returned: not a directory image
[0mDEBUG   [0m[U=0,P=1210]   Init()Check for sif 
image format
[0mDEBUG   [0m[U=0,P=1210]   Init()sif format 
initializer returned: SIF magic not found
[0mDEBUG   [0m[U=0,P=1210]   Init()Check for 
squashfs image format
[0mDEBUG   [0m[U=0,P=1210]   Init()squashfs image 
format detected
[0mDEBUG   [0m[U=0,P=1210]   setSessionLayer() Overlay seems 
supported and allowed by kernel
[0mDEBUG   [0m[U=0,P=1210]   setSessionLayer() Attempting to 
use overlayfs (enable overlay = try)
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x606f8a]

goroutine 7 [running]:
github.com/sylabs/singularity/internal/pkg/runtime/engine/config/starter.(*Config).SetCapabilities(0xc109c8,
 {0x8e7c7e, 0x0}, {0xc00046eb00, 0x29, 0x0})
   
/build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/internal/pkg/runtime/engine/config/starter/starter_linux.go:403
 +0x26a
github.com/sylabs/singularity/internal/pkg/runtime/engine/singularity.(*EngineOperations).PrepareConfig(0xc0003b7d60,
 0xc109c8)
   
/build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/internal/pkg/runtime/engine/singularity/prepare_linux.go:140
 +0x5ab
github.com/sylabs/singularity/internal/app/starter.StageOne(0x988d40, 
0xc0ed08)
   
/build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/internal/app/starter/stage_linux.go:27
 +0x6a
main.startup()
   
/build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/cmd/starter/main_linux.go:56
 +0x1ed
created by main.main
   
/build/singularity-container-aOOjKg/singularity-container-3.5.2+ds2/_build/src/github.com/sylabs/singularity/cmd/starter/main_linux.go:102
 +0x25
VERBOSE [U=0,P=835]wait_child()  stage 1 exited with 
status 2
[0m

Once the system is booted, I can activate the image in the same way
with no problem (same command).  I can even do this as an unprivileged user.

Here are excerpts from the script which show what I'm doing when that happens:


#!/bin/sh
### BEGIN INIT INFO
# Provides:  nscldaq
# Required-Start:$network $time $named $remote_fs $syslog
# Required-Stop: $network $time $named $remote_fs $syslog
# Should-Start:  nscldaq
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: NSCL data acquisition daemons
# Description:   NSCL data acquisition daemons
### END INIT INFO
export _SYSTEMCTL_SKIP_REDIRECT=true

...


##
#  Some definitions:
#

#  We run the port manager and the ring master under the following singularity 
container
#  with BUSTEROPT bound to /usr/opt

SINGULARITY_CONTAINER="/usr/opt/nscl-buster.img"
USROPT="/usr/opt/opt-buster"

...
PIDDIR="/scratch/nscldaq/run"
LOGDIR="/scratch/nscldaq/log"

DAQHOME="/usr/opt/daq/current"
DAQBIN="${DAQHOME}/bin"

DAQPORTMANAGER="${DAQBIN}/DaqPortManager"
DAQPORTMANAGERPIDFILE="${PIDDIR}/portmgr.pid"
DAQPORTMANAGERLOGFILE="${LOGDIR}/portmgr.log"


...

start_portmanager() {
nohup singularity -d  exec --bind ${USROPT}:/usr/opt,/scratch --no-home 
${SINGULARITY_CONTAINER}
  \
  ${DAQPORTMANAGER} \
  -log ${DAQPORTMANAGERLOGFILE} \
  -pidfile ${DAQPORTMANAGERPIDFILE}  \
  /scratch/portmanager 2>&1 &
   log_daemon_msg portmanager
sleep 3 # Let the port manager start.

}


Note that I have attempted to do the same thing after converting the container 
image to a .sif file and that too failed with essentially the same result.

Thank you for any help you might be able to provide. I'd be happy to provide any
additional information.

Ron.


portmanager
Description: portmanager

Bug#1005869: xdg-desktop-portal-wlr: Please provide xdg-desktop-portal-backend

[Guillem Jover]

Package: xdg-desktop-portal-wlr
Version: 0.5.0-2
Severity: normal

Hi!

At least chromium has started now to depend on xdg-desktop-portal-backend
which this package does not provide, so it requires installing one of
the other desktop-portal implementations. It would be nice if this
could provide it, so that no other backends need to be installed.

At least the gtk and gnome desktop-portals provide a specific version
(= 1.7.1), which I'm not sure is relevant here, but you might want to
check that out.

Thanks,
Guillem

Bug#1005856: bible-kjv: Search is broken, possible follow-up to #991133

[Matthew Vernon]

On 16/02/2022 10:18, Jon Daley wrote:

On Wed, 16 Feb 2022, Matthew Vernon wrote:
[Debian policy is usually that bugs need to be "Important" priority or 
higher for fixes to be considered for a stable point release. I'm 
assuming you don't think that applies here]


Ok, thanks.  Just wanted to make sure it wasn't missed.  And yeah, I've 
wondered sometimes about how priorities work for different package 
types. "important" for a bible program is different than for "mount" or 
something more critical.


Though, checking the description in "reportbug", it says:
Important: a bug which has a major effect on the usability of a package, 
without rendering it completely unusable to everyone.


Which I suppose is an appropriate description of a search feature.


I'm inclined to agree, so I've opened #1005868 to see if the release 
managers will allow a fixed package into a future Stable update.


Regards,

Matthew

Bug#998705: Many 502 errors, when using apt-cacher-ng for Debian installation

[Eriberto Mota]

Hi guys,

I am running Debian Stable (Bullseye) in my desktop and in my local server.

Yesterday I made a backport version of the apt-cacher-ng for me and I put it
in the server. The problem seems is solved.

Regards,

Eriberto

Bug#1003165: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x

[Christian Kastner]

Hi,

On 2022-02-16 11:57, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> On 2/16/22 11:36, Graham Inggs wrote:
>> Is anyone able to help with the bus error on armhf please?
> 
> Bus errors are normally easy to spot. Just run the code in question through
> GDB and see where it crashes. Then look at the backtrace with the debug
> symbols installed.
> 
> Usually it's a result of bad pointer arithmetics which should definitely be
> fixed as such operations usually violate the C/C++ standards.
> 
> I can have quick look.

one of these errors has been reported in the past, and I already did
some analysis way back then:

https://github.com/scikit-learn/scikit-learn/issues/16443

Check the last comment. The relevant Cython code doesn't look wrong, so
I guess the problem is with the binary result produced during build, as
you point out.

Best,
Christian

Bug#996953: perl: make -j72 failing with a text file busy error

[gyptazy]

Hey Cedric,

I can confirm this issue when rebuilding Perl on powerful systems. Multiple 
builds of ‚generate_uudmap.o‘ are
created during the compile time and at some point it fails with:

make -j88 […]
./generate_uudmap uudmap.h bitcount.h mg_data.h
6584make[3]: ./generate_uudmap: Text file busy
6585make[3]: *** [Makefile:329: bitcount.h] Error 127

As a result, I patched the ‚rules‘ file to run ‚dh_auto_build‘ with 
‚--no-parallel‘ option.
You can find attached my patch file:

Subject: Avoid build failures on powerful machines

+++ perl-5.34.0/debian/rules
@@ -115,11 +115,11 @@
if [ "$*" = "shared" ]; then \
  ln -s libperl.so.$(fullversion) build-$*/libperl.so.$(version); \
  ln -s libperl.so.$(version) build-$*/libperl.so; \
- dh_auto_build --builddirectory=build-$* -- SHRPLDFLAGS='$$(LDDLFLAGS) 
-Wl,-soname,libperl.so.$(version)'; \
+ dh_auto_build --no-parallel --builddirectory=build-$* -- 
SHRPLDFLAGS='$$(LDDLFLAGS) -Wl,-soname,libperl.so.$(version)'; \
elif [ "$*" = "debug" ]; then \
- dh_auto_build --builddirectory=build-$* -- perl; \
+ dh_auto_build --no-parallel --builddirectory=build-$* -- perl; \
else \
- dh_auto_build --builddirectory=build-$*; \
+ dh_auto_build --no-parallel --builddirectory=build-$*; \
fi
touch $@


Regards,
gyptazy



perl_debian_rules.patch
Description: Binary data