Bug#1004334: ITP: python-allpairspy -- Pairwise test combinations generator

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-allpairspy
  Version : 2.5.0
  Upstream Author : Tsuyoshi Hombashi 
* URL : https://github.com/thombashi/allpairspy/
* License : Expat
  Programming Lang: Python
  Description : Pairwise test combinations generator

 A Python library for test combinations generator. The generator allows one to
 create a set of tests using "pairwise combinations" method, reducing a number
 of combinations of variables into a lesser set that covers most situations.
 .
 Features:
  * Produces good enough dataset.
  * Pythonic, iterator-style enumeration interface.
  * Allows one to filter out "invalid" combinations during search for the next
combination.
  * If/when required can generate n-wise combinations.

I intend to maintain it as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmHvrBYRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WrUOwf+JMvtZ46m8K99r65Kcg3V8ZjIyfgmermG
eRsNGKQ2y+Va3bpKckVUp/jS3pNY+qxGPw3mYDOhIZGokgaljK8Ew40sVccDxD7h
a5PWhNrfP0iF+Nflp+/SJAbkkUNu0iVf2ZQ7LJym/9xV2Ybm/JKZvmqwvnWjIXWw
87LOV9Qkmc8Eeu1vuK2/Lq9RcHOhTy8mC94VD9vgKLoH3wGRUUuRJBM4KmTWLQgz
u+6kyfeVGAUqtWxxcFZ3XqS8Eu6o8c1MFyF0kYeWopM6avCKeFG/nE3cZFxU3nja
2i3EnJtp5OLFhJM4oXkEIHWOimNC82pJSCR60fZ22cdN/6PkyvJLtw==
=lRpd
-END PGP SIGNATURE-

Bug#1004214: Info received (Bug#1004214: Acknowledgement (kodi: Segfaults on menu selection))

[Vasyl Gello]

Hi!

> OK did this - was Kodi supposed to launch with this command, bc it didn't.

How do you start it? If from remote SSH, dont forget exporting DISPLAY=:0 first.

And py-bt-full is GDB command, not shell one, i.e you type it in GDB after Kodi 
starts and crashes and
GDB gets control back with "SIGSEGV…" smth message.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1004333: deb-systemd-helper does not recognize purged package

[Marc Haber]

Package: init-system-helpers
Version: 1.61
Severity: normal
File: /usr/bin/deb-systemd-helper

Hi,

given the following code in a maintainer script:

postinst
if [ -x "/usr/bin/deb-systemd-helper" ]; then
deb-systemd-helper mask 'sudo.service' || true
fi

postrm
case "$1" in
  purge)
if [ -x "/usr/bin/deb-systemd-helper" ]; then
deb-systemd-helper unmask 'sudo.service' || true
fi

the masking symlink stays around after purge. When the package is
installed, ther is no sudo.service marker file in 
/var/lib/systemd/deb-systemd-helper-masked/

dpkg/deb-systemd-helper output from package installation:

root@salida:~# dpkg --list sudo
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
+++-==---=
un  sudo (no description available)
root@salida:~# dpkg --install 
/home/mh/packages/sudo/build-area/sudo_1.9.8p2-2~1_amd64.deb
Selecting previously unselected package sudo.
(Reading database ... 42180 files and directories currently installed.)
Preparing to unpack .../sudo_1.9.8p2-2~1_amd64.deb ...
Unpacking sudo (1.9.8p2-2~1) ...
Setting up sudo (1.9.8p2-2~1) ...
(deb-systemd-helper DEBUG) is purge = no
(deb-systemd-helper DEBUG) action = mask, scriptname = sudo.service, 
service_path = sudo.service
Processing triggers for libc-bin (2.33-3) ...
Processing triggers for man-db (2.9.4-4) ...
root@salida:~# ls -la /var/lib/systemd/deb-systemd-helper-masked/
total 8
drwxr-xr-x  2 root root 4096 Jan  5 21:55 .
drwxr-xr-x 11 root root 4096 Jan  5 21:55 ..
-rw-r--r--  1 root root0 Jan  5 21:55 systemd-timesyncd.service
root@salida:~#

dpkg/deb-systemd-helper output from package purge:

root@salida:~# dpkg --purge sudo
(Reading database ... 42313 files and directories currently installed.)
Removing sudo (1.9.8p2-2~1) ...
Purging configuration files for sudo (1.9.8p2-2~1) ...
(deb-systemd-helper DEBUG) is purge = no
(deb-systemd-helper DEBUG) action = unmask, scriptname = sudo.service, 
service_path = sudo.service
(deb-systemd-helper DEBUG) Not unmasking /etc/systemd/system/sudo.service 
because the state file /var/lib/systemd/deb-systemd-helper-masked/sudo.service 
does not exist
(deb-systemd-helper DEBUG) rmdir_if_empty 
/var/lib/systemd/deb-systemd-helper-masked
(deb-systemd-helper DEBUG) rmdir(/var/lib/systemd/deb-systemd-helper-masked) 
failed (Directory not empty)
(deb-systemd-helper DEBUG) rmdir_if_empty 
/var/lib/systemd/deb-systemd-user-helper-masked
(deb-systemd-helper DEBUG) 
rmdir(/var/lib/systemd/deb-systemd-user-helper-masked) failed (No such file or 
directory)
dpkg: warning: while removing sudo, directory '/etc/sudoers.d' not empty so not 
removed
Processing triggers for libc-bin (2.33-3) ...
Processing triggers for man-db (2.9.4-4) ...
root@salida:~# ls -al /etc/systemd/system/sudo.service
lrwxrwxrwx 1 root root 9 Jan 23 23:25 /etc/systemd/system/sudo.service -> 
/dev/null
root@salida:~#

What is going wrong here?

Greetings
Marc

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

Kernel: Linux 5.16.1-zgsrv20080 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages init-system-helpers depends on:
ii  perl-base  5.32.1-6

init-system-helpers recommends no packages.

init-system-helpers suggests no packages.

Versions of packages init-system-helpers is related to:
pn  insserv  

-- no debconf information

Bug#1004332: cntlm: rotate cntlm logs

[Sergey Matsievskiy]

Package: cntlm
Version: 0.92.3-1+b1
Severity: normal
Tags: patch
X-Debbugs-Cc: seregaxvm.m...@gmail.com

Dear Maintainer,

Cntlm is vary chatty and produces large amount of logs. In my case it filled
250Gb SSD in a week. It would be nice to provide rsyslog and logrotate
configurations with this package so that could be managed with ease.

For this I used the following configurations:

In /etc/rsyslog.d/cntlm.conf

```
if $programname == 'cntlm' then {
   /var/log/cntlm.log
   ~
}
```

and in /etc/logrotate.d/cntlm

```
/var/log/cntlm.log
{
rotate 2
daily
maxsize 100M
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
```


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable'), (50, 'unstable'), (10, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads)
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 cntlm depends on:
ii  adduser  3.118
ii  libc62.33-2

cntlm recommends no packages.

cntlm suggests no packages.

-- Configuration Files:
/etc/cntlm.conf [Errno 13] Permission denied: '/etc/cntlm.conf'

-- no debconf information
if $programname == 'cntlm' then {
   /var/log/cntlm.log
   ~
}
/var/log/cntlm.log
{
rotate 2
daily
maxsize 100M
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}

Bug#1003966: ntpsec: split out ntpdig?

[Richard Laager]

I'm relatively set on the idea of breaking out ntpdig, since it's the 
renamed replacement for sntp which is broken out in src:ntp, which we 
are talking (on debian-devel) about ntpsec replacing.


--
Richard


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003956: ntpsec: security settings

[Richard Laager]

Control: reopen -1

On 1/24/22 13:25, Christoph Anton Mitterer wrote:

On Tue, 2022-01-18 at 21:52 -0600, Richard Laager wrote:

Shouldn't -g be removed?


First off, note that the stock ntpsec.service has Restart=no, not
Restart=yes. So in the malicious/broken server scenario described,
ntpd will die, but not restart.



Isn't it still, that if one e.g. reboots
and ntpd starts the first time


Yes, -g is only applicable at boot (or first install).


then an attacker could basically set any time?


There are two potential issues:
A) the server serves bogus/malicious time
B) a MITM messes with the time.

The primary protection for A is consensus (see specifically minsane). A 
single bogus/malicious clock can't do anything.


Of course, in scenario B, the MITM can mess with all of the clocks 
you're talking to. NTS is the best protection. The older style fixed 
secret hash-based (e.g. MD5/SHA) authentication is better than nothing.


But yes, without NTS and with -g (both being the defaults in Debian), 
ultimately a MITM could adjust all of the times you're seeing and set 
any time, but only once upon boot. Eliminating -g would improve security 
in this situation. But there are trade-offs.



One could argue here, that most "normal" systems (desktops, servers)
have usually rather well working clocks... an so they wouldn't be
likely affected by what you describe.


That's true until it isn't: one day your motherboard's battery dies and 
now your clock is wrong, despite running ntpd.



OTOH, embedded systems are "special" and if someone uses a system with
no clock at all, than IMO it's rather his duty to take necessary steps
so that it works (e.g. by installing ntpdate).


I'm not sure how installing ntpdate is different from installing ntpsec 
in that regard.



Let's say I remove -g by default. (Then I can safely set 
Restart=on-failure by default.) I could address some/all of the trade-offs:


I'd imagine I could script up something to add -g on the first run of 
ntpd on initial install, to address that case. For example, I could 
detect the first run scenario as there being no drift file.


I could use hwclock(1) to determine if there is an RTC. If not, add -g. 
That would make the Raspberry Pi case work out-of-the-box without 
decreasing security for regular systems.


That still leaves the case of "my RTC battery died". I could probably 
detect that too, by checking to see if the current time is older than 
the drift file, and again add -g.


The only problem I see with this is that if I'm adding -g under various 
circumstances, there's then no way for the administrator to prohibit -g.


Another option would be to remove -g from $NTPD_OPTS if none of those 
conditions apply. If I'm only removing -g, the admin can still ensure -g 
is not used by removing it. This creates the opposite problem: there's 
no way for an admin to add -g if they want it always. (Unless my -g 
removal only removes one and they set NTPD_OPTS="-g -g" but that seems 
like a hack.) But, removing options is itself tricky (e.g. 
NTPD_OPTS="-gN" or NTPD_OPTS="-Ng") and that feels like asking for trouble.



2) Also in /etc/default/ntpsec, per default IGNORE_DHCP is "".
Shouldn't that be set to yes, so that per default a malicious DHCP
server
couldn't add it's own possible rogue servers?


Maybe. But ntpsec-ntpdate isn't installed by default and even
installing
ntpsec doesn't pull it in. If you choose to install that package, you
(arguably) are expressing a desire to use its features, and the DHCP
integration is a big part of that.


I didn't realise that /etc/default/ntpsec's IGNORE_DHCP actually
affects only ntpsec-ntpdate (or at least that's how I understand
you)... which however has it's own /etc/default file with it's own
IGNORE_DHCP??


Yeah, in looking at this more, this is different / more complicated than 
I remember, and arguably messy.


So both ntpsec and ntpsec-ntpdate have DHCP support, which is enabled by 
default (IGNORE_DHCP="").


/etc/default/ntpsec's IGNORE_DHCP affects ntpd from ntpsec.

/etc/default/ntpsec-ntpdate affects ntpdate-debian (note the -debian 
there) from ntpsec-ntpdate.


It's technically possible to have both installed, but generally one is 
either using ntpd or ntpdate-debian, not both.


The only documentation for this is README.Debian, which only references 
/etc/default/ntpsec. In fairness, lots of that file is talking only 
about ntpd from the ntpsec package, which ntpsec-ntpdate being a bit of 
a separate thing / an afterthought.


Really, ntpsec-ntpdate should just die and this gets simpler.

As far as DHCP goes, though... the DHCP server controls my address and 
my gateway. It can trivially MITM me. It could serve me DNS that 
redirects the pool servers somewhere. Or even without DNS being 
involved, it could simply serve me a gateway IP that forwards all NTP 
traffic somewhere.


That said, if I'm using NTS in my ntp.conf, that's being defeated by the 
DHCP integration. That's probably a 

Bug#1004331: pytorch: b-d on python3-all-dev, but not built for all supported Python3 versions

[Graham Inggs]

Source: pytorch
Version: 1.8.1-3
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10 python3-all-dev

Hi Maintainer

This package build-depends on python3-all-dev, but does not build
extensions/libraries for all supported python3 versions.  This is seen
on the transition tracker for adding python3.10 support [1] and
creates false positives.

Please either replace the b-d python3-all-dev with python3-dev, or
build for all supported Python3 versions.  With the former solution
yet get later exposure to a new python3 version, with
the latter solution you get early exposure.

Regards
Graham


[1] https://release.debian.org/transitions/html/python3.10-add.html

Bug#1002681: transition: ocaml

[Stéphane Glondu]

Le 24/01/2022 à 23:31, Sebastian Ramacher a écrit :
>> - ppx-tools-versioned (#1002941), ppxfind (#1002942): they seem
>> deprecated, should be removed from testing
> 
> That would also require removal of:
> 
> coq-elpi
> coq-hierarchy-builder
> elpi
> haxe
> liquidsoap
> mercurial-buildpackage
> morbig
> morsmall
> node-carto
> node-hsluv
> ocaml-sedlex
> ocaml-visitors
> pgocaml
> ppx-deriving
> ppx-deriving-yojson

Packages that used to depend on ppx-tools-versioned and/or ppxfind (in
testing) do no longer in their 4.13.1-compatible version (in
unstable)... That's why I said they seem deprecated.

In current unstable, the only reverse-dependencies that remain are eliom
and nurpawiki:

> glondu@coccia:~$ dak rm -Rn -s unstable ppx-tools-versioned ppxfind eliom 
> nurpawiki
> Will remove the following packages from unstable:
> [...]
> Checking reverse dependencies...
> No dependency problem found.


Cheers,

-- 
Stéphane

Bug#1004330: dokuwiki: No more works with PHP 8.1: Array and string offset access syntax with curly braces is no longer supported in /usr/share/dokuwiki/inc/init.php on line 557

[Axel Beckert]

Package: dokuwiki
Severity: serious
Version: 0.0.20180422.a-2.1
Tags: fixed-upstream

Dokuwiki broke when PHP was upgraded to 8.1 (now in testing):

[Tue Jan 25 03:54:31.666206 2022] [php:error] [pid 1959] [client 
127.0.0.1:39658] PHP Fatal error:  Array and string offset access syntax with 
curly braces is no longer supported in /usr/share/dokuwiki/inc/init.php on line 
557

This is very likely fixed upstream, either in the not yet packaged
upstream release 2020-07-29 “Hogfather” ("some preparations for the
upcoming PHP8") or in the upcoming upstream release "Igor" ("Fix various
errors in PHP8 support").

-- System Information:
Debian Release: bookworm/sid  APT prefers testing
(Bug report not written on the server where the issue occurs.)

Bug#1004329: ibus-mozc: The "Japanese (Mozc)" keyboard layout doesn't change to a japanese keyboard layout

[SpiceMan]

Package: ibus-mozc
Version: 2.23.2815.102+dfsg-8ubuntu1
Severity: normal

Hello, I reported this in ubuntu and was directed upstream (here).
I ran reportbug -B debian -q ibus-mozc in my ubuntu system, hence the
packages being ubuntu ones.

This is not a bug, but a default configuration issue in
/usr/share/ibus/components/mozc.xml

The initial ubuntu bug report is available at
https://bugs.launchpad.net/ubuntu/+source/mozc/+bug/1958492

The summary is:

/usr/share/ibus/components/mozc.xml has  configured as "default"
instead of "jp".
This leads to the following behaviour:

1) Switching to "Japanese (Mozc)" just enables Mozc and doesn't switch to
the Japanese keyboard layout
but keeps the currently used one (whatever that may be).
Switching to Japanese (no mozc) DOES switch to a japanese keyboard layout
(ie: runs setxkbmap jp)
Why does a keyboard layout named "Japanese" NOT change to a japanese layout?
What's the rationale behind this?

2) The /usr/share/ibus/component/mozc.xml layout set to "default" leads to
very inconsistent behaviour.
Should I have 4 different layouts besides "Japanese (Mozc)", switching to
"Japanese (Mozc)" has four
possible different behaviors depending on the previously used keyboard
layout.
Very inconsistent.

This debian bug report is the very example of that:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953046

3) Japanese users don't notice because switching from Japanese (without
mozc) to Japanese (Mozc)
just "works". (By chance, should they have another keyboard layout too,
they would experience the
inconsistencies pointed out in 2)

4) Non-japanese users (that usually don't have the Japanese (no mozc))
layout end up being unable
to switch input modes from the keyboard with the zenkaku/hankaku key (the
key to the left of the 1,
~ tilde in the us keyboard layout) because that doesn't exist in other
layouts.

A lot of information on the internet suggests changing the input mode to
hiragana from the menus,
but this is a workaround.
Changing to a japanese keyboard layout SHOULD let me change input modes
with the japanese keyboard
layout key explicitly designed to do so.

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

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

Versions of packages ibus-mozc depends on:
ii  ibus1.5.22-2ubuntu2.1
ii  libc6   2.31-0ubuntu9.2
ii  libglib2.0-02.64.6-1~ubuntu20.04.4
ii  libibus-1.0-5   1.5.22-2ubuntu2.1
ii  libprotobuf17   3.6.1.3-2ubuntu5
ii  libstdc++6  10.3.0-1ubuntu1~20.04
ii  libxcb-xfixes0  1.14-2
ii  libxcb1 1.14-2
ii  mozc-data   2.23.2815.102+dfsg-8ubuntu1
ii  mozc-server 2.23.2815.102+dfsg-8ubuntu1
ii  tegaki-zinnia-japanese  0.3-1

ibus-mozc recommends no packages.

Versions of packages ibus-mozc suggests:
ii  mozc-utils-gui  2.23.2815.102+dfsg-8ubuntu1

-- no debconf information

Bug#1004328: stayrtr: STAYRTR_ARGS -verify argument not available

[John Kristoff]

Package: stayrtr
Version: 0.3.0-1
Severity: normal
X-Debbugs-Cc: j...@depaul.edu

Dear Maintainer,

/etc/default/stayrtr by default specifies -verify=false to STAYRTR_ARGS,
but this argument is no longer a valid argument (it was once for gortr).
This prevents stayrtr from starting, but is easily fixed.

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

Kernel: Linux 5.10.0-11-cloud-amd64 (SMP w/2 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 stayrtr depends on:
ii  adduser  3.118
ii  libc62.33-3

stayrtr recommends no packages.

stayrtr suggests no packages.

-- Configuration Files:
/etc/default/stayrtr changed [not included]

-- no debconf information

Bug#1004198: diffoscope: shows no diff between device and crafted text file

[Chris Lamb]

tags 1004198 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/6ae98df8a74662dc6e2284573015e2aa6e9643b9


Regards,

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

Bug#1004327: Broken URL for src pkgs with plus sign in pkgname (e.g., gtk+3.0)

[Boyuan Yang]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: debsources

Steps to reproduce:

1. Visit https://sources.debian.org/src/gtk+3.0/ .
2. Click the link named "3.2.24-4" (version for bullseye).
3. The system returns 404.

Reason: the plus sign ("+") is escaped as "%252B".

-- 
Thanks,
Boyuan Yang


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

Bug#1004323: My suggested fix is wrong

[Ian Kelling]

After reading it again. To support both macros with conditional skips,
the syntax check would need to be duplicated like this:

.ifdef CHECK_DATA_VERIFY_HEADER_SYNTAX
header syntax check here
.elifndef NO_CHECK_DATA_VERIFY_HEADER_SYNTAX
header syntax check here
.endif


-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org

Bug#1004312: diffoscope: can't diff non-existent file with .pyc: struct.error: unpack requires a buffer of 4 bytes

[Chris Lamb]

tags 1004312 + pending
thanks

Fixed in Git, pending upload... likely Friday. :)

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/9ebba4b2e333d8bffe0932cefb353ed54c0bfd36


Regards,

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

Bug#1004325: php7.4: upgrade from 7.3 installs unwanted libapache2-mod-php7.4

[hamish]

Package: php7.4
Version: 7.4.25-1+deb11u1
Severity: normal

I had php, php7.3 and php7.3-fpm installed on buster but not 
libapache2-mod-php7.3.

The bullseye upgrade installed and enabled libapache2-mod-php7.4, which also 
changed
the Apache mpm. This is undesirable.

This is because php7.4 depends on libapache2-mod-php7.4 | php7.4-fpm | 
php7.4-cgi,
so apt installed the first. Shouldn't php7.4 depend on the unversioned 
components instead?



Hamish


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

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

Versions of packages php7.4 depends on:
ii  php7.4-common  7.4.25-1+deb11u1
ii  php7.4-fpm 7.4.25-1+deb11u1

php7.4 recommends no packages.

php7.4 suggests no packages.

Bug#1004326: libnss-systemd: postinst modification of /etc/nsswitch.conf forgets (g)shadow

[Robert Siemer]

Package: libnss-systemd
Version: 250.3-1
Severity: normal
X-Debbugs-Cc: robert.siemer-report...@backsla.sh

/var/lib/dpkg/info/libnss-systemd\:i386.postinst does not add
`systemd` on the shadow and gshadow lines of /etc/nsswitch.conf,
only passwd and group.

All four dbs should have `systemd` added according to
man page nss-systemd(8).

I guess the manual page got corrected without it going into the
postinst script, isn’t it?

Regards,
Robert



-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-8-686-pae (SMP w/2 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 libnss-systemd depends on:
ii  libc62.33-3
ii  systemd  250.3-1

libnss-systemd recommends no packages.

libnss-systemd suggests no packages.

-- no debconf information

Bug#1004324: yt-dlp gives wrong version info.

[Unit 193]

On Mon, 24 Jan 2022, shirish शिरीष wrote:


Package: yt-dlp
Version: 2022.01.21-1
Severity: normal

Dear Maintainer,

I updated today and got the new version -

$ apt-cache policy yt-dlp
yt-dlp:
 Installed: 2022.01.21-1
 Candidate: 2022.01.21-1
 Version table:
*** 2022.01.21-1 900
   900 http://deb.debian.org/debian testing/main amd64 Packages
   100 http://deb.debian.org/debian unstable/main amd64 Packages
   100 /var/lib/dpkg/status

But when I asked it it's version number, that is what it replied -

$ yt-dlp --version
2021.12.27

There seems to be confusion in yt-dlp as to what version it is. Please fix.


Do you also have this installed by some other method, such as pip, that would be 
giving you an old version?  If you remove the Debian package, can you still call 
yt-dlp?


unit193@Loki:~$ yt-dlp --version
2022.01.21
unit193@Loki:~$ which yt-dlp
/usr/bin/yt-dlp
unit193@Loki:~$ cat /usr/lib/python3/dist-packages/yt_dlp/version.py
# Autogenerated by devscripts/update-version.py

__version__ = '2022.01.21'

RELEASE_GIT_HEAD = 'f20d607b0'
unit193@Loki:~$ apt-cache policy yt-dlp
yt-dlp:
  Installed: 2022.01.21-1
  Candidate: 2022.01.21-1
  Version table:
 *** 2022.01.21-1 500
500 http://deb.debian.org/debian testing/main amd64 Packages
100 http://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status


~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#942412: Does not build on platform other than i386/amd64

[Laurent Bigonville]

On Tue, 15 Oct 2019 23:30:53 +0200 Bernhard Schmidt  
wrote:


Hello,

>
> src:mariadb-connector-odbc fails to build on platforms other than 
i386/amd64 with

>
> -- Looking for floor
> -- Looking for floor - not found
> -- Looking for floor in m
> -- Looking for floor in m - found
> -- odbc_config is not found
> -- Found ODBC Driver Manager includes: /usr/include
> CMake Error at CMakeLists.txt:237 (MESSAGE):
> Driver Manager was not found
>
> There is a lot of hardcoding library paths based on pointer size in 
cmake/FindDM.cmake,

> which is probably the culprit here.
>
> It has been reported upstream at 
https://jira.mariadb.org/browse/ODBC-268 .

>
> I'll limit architectures to i386 / amd64 with the next upload for now.
>
>

What's the status of this bug?

There is a proposed patch attached to it, could you please apply it and 
upload?

Bug#999824: ima-evm-utils: missing evm portable signature verification in tooling

[Steffen Kothe]

A7m 24.01.22 um 13:36 schrieb Bastian Germann:
Control: retitle -1 ima-evm-utils: FTBFS because of the signature 
verification unit tests

Control: severity -1 serious

On Wed, 17 Nov 2021 10:35:05 +0100 Steffen Kothe wrote:
EVM signatures can be created with the option '--portable | -o ' to 
get rid of a hashing of i_version and fsuuid.


When files should be verified after a signing with '--portable' on the 
host, the tooling returns with "Verification failed" unless

the signing itself is correct.

The cause for this issue is a missing implementation for the probing
and verification of portable signatures.

A patch for this issue is already available in the official git source
of the ima-evm-utils tooling:

https://git.code.sf.net/p/linux-ima/ima-evm-utils
f4b901d081ec ("Add support for verifying portable EVM signatures")

The wrong checking of the signature format results in a false-positive 
error.


Note, that this bug also affects version 1.3.2-2.1 provided
by Debian/SID https://packages.debian.org/sid/ima-evm-utils.

The official release 1.4 of the ima-evm-utils contains this fixes.


Version 1.4 was imported but still fails to build from scratch on buildd 
because the unit tests for
that new feature do not run without gnutls-bin and softhsm2 installed as 
build dependencies.
I did not catch that building my NMU in a clean sid chroot. I do not 
know why, it still
builds in that chroot and claims two of the three test to succeed with 
those packages uninstalled.


I cross built the package via dpkg-buildpackage --host-arch=armhf
on an x86 Buster host:

1 test skipped, 1 passed, 1 failed.

After some research, I figured out, that the evmctl -engine pkcs11 
flagging caused an error since the "libengine-pkcs11-openssl" seems not 
not be referenced properly in Build-depends:


After apt install libengine-pkcs11-openssl:arm64 on my host, test 
succeeded. Have to confirm this behavior on a clean native ARM64 target.


I guess somebody forgot the pkcs11 backend engine.

Same story for x86.


Mit freundlichen Grüßen / Kind Regards
--
Steffen Kothe
Linutronix GmbH | Bahnhofstrasse 3 | D-88690 Uhldingen-Mühlhofen
Phone: +49 7556 25 999 38; Fax.: +49 7556 25 999 99

Hinweise zum Datenschutz finden Sie hier (Informations on data privacy
can be found here): https://linutronix.de/kontakt/Datenschutz.php

Linutronix GmbH | Firmensitz (Registered Office): Uhldingen-Mühlhofen |
Registergericht (Registration Court): Amtsgericht Freiburg i.Br., HRB700
806 | Geschäftsführer (Managing Directors): Heinz Egger, Thomas Gleixner

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Sean Whitton]

Hello Chris,

On Mon 24 Jan 2022 at 11:33AM +01, Chris Hofstaedtler wrote:

> For context, the idea is that /usr/bin/rename should become
> src:util-linux' rename implementation.

That seems likely to break a great many scripts, though?

Perhaps we should ship them both under a name other than
/usr/bin/rename, such that people are prompted to update their scripts
to choose one, or create their own symlink?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1004324: yt-dlp gives wrong version info.

[shirish शिरीष]

Package: yt-dlp
Version: 2022.01.21-1
Severity: normal

Dear Maintainer,

I updated today and got the new version -

$ apt-cache policy yt-dlp
yt-dlp:
  Installed: 2022.01.21-1
  Candidate: 2022.01.21-1
  Version table:
 *** 2022.01.21-1 900
900 http://deb.debian.org/debian testing/main amd64 Packages
100 http://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

But when I asked it it's version number, that is what it replied -

$ yt-dlp --version
2021.12.27

There seems to be confusion in yt-dlp as to what version it is. Please fix.


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

Kernel: Linux 5.15.0-3-amd64 (SMP w/4 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 yt-dlp depends on:
ii  python33.9.7-1
ii  python3-mutagen1.45.1-2
ii  python3-pkg-resources  58.2.0-1
ii  python3-pycryptodome   3.11.0+dfsg1-3
ii  python3-websockets 9.1-1

Versions of packages yt-dlp recommends:
ii  ca-certificates  20210119
ii  curl 7.81.0-1
ii  ffmpeg   7:4.4.1-3
ii  mpv  0.34.1-1+b1
ii  python3-pyxattr  0.7.2-2
ii  rtmpdump 2.4+20151223.gitfa8646d.1-2+b2
ii  wget 1.21.2-2+b1

Versions of packages yt-dlp suggests:
pn  libfribidi-bin | bidiv  
ii  phantomjs   2.1.1+dfsg-2+b2

-- no debconf information

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

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

Bug#1004323: exim4-config: CHECK_DATA_VERIFY_HEADER_SYNTAX prevents header syntax verification

[Ian Kelling]

Package: exim4-config
Version: 4.93-13ubuntu1.5
Severity: normal
Tags: patch

Dear Maintainer,

   * What led up to the situation?

I noticed that exim accepted an email with invalid header syntax, yet I
had previously configured an exim macro to work with debian's exim
config to reject those emails.

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

I was confused, because the header syntax check had become the default
in a package upgrade, yet it still wasn't working. I eventually figured
out the cause.


The issue is in the following commit, from 
https://salsa.debian.org/exim-team/exim4:

commit b561c99ba7edd94891bfc66257823f79178ece62 (tag: experimental/4.91--RC1-1)
Author: Andreas Metzler 
Date:   Sat Mar 17 17:40:50 2018 +0100

verify = header_syntax by default

Upstream now enables verify = header_syntax check in default config,
mirror this change in Debian, introduce
NO_CHECK_DATA_VERIFY_HEADER_SYNTAX macro to override this.

diff --git a/debian/changelog b/debian/changelog
index 7a8ebc40..0f7126ca 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,13 +3,15 @@ exim4 (4.91~RC1-1) experimental; urgency=medium
   * Point watchfile to test subdirectory.
   * New upstream version:
 + Drop debian/patches/75_*.
-+ Update example.conf.md5. Upstream now enables verify = header_syntax
-  check in default config.
++ Update example.conf.md5.
+  Upstream now enables verify = header_syntax check in default config,
+  mirror this change in Debian, introduce
+  NO_CHECK_DATA_VERIFY_HEADER_SYNTAX macro to override this.
   * Build with newly available (well, for GnuTLS) DANE support.
   * Pull 75_01-Fix-heavy-pipeline-SMTP-command-input-corruption.-Bu.patch from
 upstream master, fixing https://bugs.exim.org/show_bug.cgi?id=2250.

- -- Andreas Metzler   Sat, 17 Mar 2018 16:09:34 +0100
+ -- Andreas Metzler   Sat, 17 Mar 2018 17:41:51 +0100

 exim4 (4.90.1-3) unstable; urgency=medium

diff --git a/debian/debconf/conf.d/acl/40_exim4-config_check_data 
b/debian/debconf/conf.d/acl/40_exim4-con
fig_check_data
index abfa1643..07a949db 100644
--- a/debian/debconf/conf.d/acl/40_exim4-config_check_data
+++ b/debian/debconf/conf.d/acl/40_exim4-config_check_data
@@ -17,14 +17,14 @@ acl_check_data:
   condition  = ${if > {$max_received_linelength}{998}}
   .endif

-  # Deny unless the address list headers are syntactically correct.
+  # Deny if the headers contain badly-formed addresses.
   #
-  # If you enable this, you might reject legitimate mail.
-  .ifdef CHECK_DATA_VERIFY_HEADER_SYNTAX
+  .ifndef NO_CHECK_DATA_VERIFY_HEADER_SYNTAX
   deny
-message = Message headers fail syntax check
 !acl = acl_local_deny_exceptions
 !verify = header_syntax
+message = header syntax
+log_message = header syntax ($acl_verify_message)
   .endif

END COMMIT

The problem is that if you had a line in your exim config like:

CHECK_DATA_VERIFY_HEADER_SYNTAX = true

then after this change,

.ifndef NO_CHECK_DATA_VERIFY_HEADER_SYNTAX

gets expanded to

.ifndef NO_true

which exim sees as "yes, defined" and the .ifndef becomes false, and so
header syntax checking is removed from the config. Thus, people like me
who opted in to header syntax checking, suddenly got it turned off after
an exim package upgrade. That was clearly not what was intended. The new
macro name should have not included the old as a substring. Exim spec
6.5 warns about macro substrings.

The ideal solution is to support both the old and new macro names. I
think that can be done like so:

.ifndef CHECK_DATA_VERIFY_HEADER_SYNTAX
.ifdef NO_CHECK_DATA_VERIFY_HEADER_SYNTAX
.else
header syntax check here
.endif
.endif

-- Package-specific info:
Exim version 4.93 #3 built 28-Apr-2021 13:19:17
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event I18N OCSP PRDR 
PROXY SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated

-- System Information:
Debian Release: bullseye/sid
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-63-generic (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 

Bug#1002681: transition: ocaml

[Sebastian Ramacher]

On 2022-01-24 07:30:44 +0100, Stéphane Glondu wrote:
> Le 19/01/2022 à 09:34, Sebastian Ramacher a écrit :
> > The libguestfs build for the php8.1 transition migrated, so this
> > transition can proceed. Please go ahead.
> 
> 5 days later, most of packages have been rebuilt with the new OCaml. The
> remaining outliers are:
> 
> - hol-light (#1002983): the fix is not trivial and upstream doesn't seem
> interested in supporting a modern toolchain, should be removed from
> testing for the time being
> - otags (#1002940): seems dead upstream, should be removed from testing
> for the time being

Removal hint added.

> - ppx-tools-versioned (#1002941), ppxfind (#1002942): they seem
> deprecated, should be removed from testing

That would also require removal of:

coq-elpi
coq-hierarchy-builder
elpi
haxe
liquidsoap
mercurial-buildpackage
morbig
morsmall
node-carto
node-hsluv
ocaml-sedlex
ocaml-visitors
pgocaml
ppx-deriving
ppx-deriving-yojson

> - sks (#1002657): a patch is available
> - llvm-toolchain-11 (#1002607), llvm-toolchain-12 (#1002608): the fix is
> trivial

Those have been fixed.

> - eliom: a new upstream release is available, but it needs ocsipersist
> which is sitting in NEW... can be removed temporarily from testing if needed
> - nurpawiki: depends on eliom, can be removed temporarily from testing
> if needed

Removal hints added.

Cheers

> - llvm-toolchain-9: not in testing... as far as I understand, should be
> removed from Debian altogether
> - why3, frama-c: not in testing... FTBFS at the moment, but should be
> fixed in the future
> 
> 
> Cheers,
> 
> -- 
> Stéphane
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1004322: RM: gr-soapy -- ROM; Included in GNU Radio 3.10

[Christoph Berg]

Package: ftp.debian.org
Severity: normal

Hi,

please remove src:gr-soapy from unstable, the new gnuradio version
includes it in core.

Christoph

Bug#729816: ITP: elementary-icon-theme -- Official elementary icon theme.

[Boyuan Yang]

X-Debbugs-CC: camerontnor...@gmail.com mat...@linuxmint.pl

You may now find debian git packaging repo for elementary-icon-theme at
https://salsa.debian.org/debian/elementary-icon-theme .

I have uploaded the package onto Debian NEW queue (
https://ftp-master.debian.org/new.html ). After the review is complete, it
should appear at https://tracker.debian.org/pkg/elementary-icon-theme .

Thanks,
Boyuan Yang

On Sat, 11 Jan 2014 17:29:34 -0008 Cameron Norman 
wrote:
> On Sat, Jan 11, 2014 at 2:47 AM, Mateusz Łukasik  
> wrote:
> > Hello,
> > 
> > Is anyone working on this package? If not, I want to start doing it.
> > 
> > Mateusz
> > 
> I was working on this, but I am a little busy right now. Feel free to 
> work on it. Also, you can look at faenza-icon-theme packaging for 
> inspiration.
> 
> Cheers,
> Cameron



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

Bug#1004166: strongswan-nm: Creates VPN configs that disable using system CA certificate directories

[Daniel Fussell]

On 1/24/22 02:00, Tobias Brunner wrote:

Hi Daniel,


Removing the blank "certificate=" line from the VPN connection config in
/etc/NetworkManager/system-connections/ restores the original behavior.
However, modifying the connection config in NetworkManager will again 
add
the blank "certficiate=" line, once again breaking the connection 
config.


I can't reproduce this.  What does the "Certificate" file chooser 
display when you open the editor?  "(None)"?


Regards,
Tobias



Perhaps I wasn't clear.  Applying any change to any field in the 
NetworkManager strongswan VPN plugin config will write a text config 
file with the 'certificate=' line.  For example, the following resulting 
connection config snippet would be broken because no certificate was 
specified in the GUI:


...

[vpn]
address=vpn.example.com
certificate=
encap=yes
...


Changing that snippet to the following makes the connection work using 
system certificates:


...

[vpn]
address=vpn.example.com
encap=yes
...


Notice the missing 'certificate=' line.  However, any change made in the 
GUI would restore the certificate= line as show below:

...

[vpn]
address=different-vpn.example.com
certificate=
encap=yes
...

Thus, manually modifying the GUI-created VPN config is a temporary 
workaround, but it will break eventually when the the user applies 
something in the GUI, and a new config is written out.


The GUI config should not include a 'certificate=' line when the GUI's 
"Certificate:" field is left blank.  Alternatively, strongswan should 
assume 'certificate=' indicates the system certificates should be used.


Does that answer your question?

--
Daniel Fussell
CAEDM Linux Administrator
BYU College of Engineering
240 EB, Provo UT 84602
801-422-5351
dfuss...@byu.edu

Bug#1004321: fwupd-amd64-signed-template: missing package name in files.json

[Ansgar]

Package: fwupd-amd64-signed-template
Version: 1:1.1-5
Severity: serious

The package name is missing in the third line of the generated files.json:

+---
| {
|   "packages": {
| "": {
|   "trusted_certs": [],
|   "files": [
| {"sig_type": "efi", "file": "usr/libexec/fwupd/efi/fwupdx64.efi"}
|   ]
| }
|   }
| }
+---[ usr/share/code-signing/fwupd-amd64-signed-template/files.json ]

Ansgar

Bug#1004320: ITP: r-cran-rcpptoml -- 'Rcpp' Bindings to Parser for Tom's Obvious Markup Language

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-rcpptoml -- 'Rcpp' Bindings to Parser for Tom's Obvious 
Markup Language
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-rcpptoml
  Version : 0.1.7
  Upstream Author : Dirk Eddelbuettel
* URL : https://cran.r-project.org/package=RcppTOML
* License : GPL-2+
  Programming Lang: GNU R
  Description : 'Rcpp' Bindings to Parser for Tom's Obvious Markup Language
 The configuration format defined by 'TOML' (which expands to
 "Tom's Obvious Markup Language") specifies an excellent format
 (described at ) suitable for both human editing
 as well as the common uses of a machine-readable format. This package
 uses 'Rcpp' to connect the 'cpptoml' parser written by Chase Geigle
 (in C++11) to R.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-rcpptoml

Bug#1002210: adapt: diff for NMU version 1.0.0-1.1

[Adrian Bunk]

On Mon, Jan 24, 2022 at 06:38:21PM +0200, Wouter Verhelst wrote:
> Thanks!
> 
> The delay is absolutely not necessary; feel free to redirect to a direct 
> upload.

Thanks, rescheduled for immediate upload.

cu
Adrian

Bug#996747: src:debianutils: fails to migrate to testing for too long: blocked by sramacher

[Johannes Schauer Marin Rodrigues]

Hi Sebastian,

On Fri, 21 Jan 2022 13:52:15 +0100 Johannes Schauer Marin Rodrigues 
 wrote:
> Sebastian, do you think that this is a solution that would allow debianutils 
> to
> be unblocked from migration to testing?

the recent debianutils NMU by waldi implements the tech ctte decisions.

Could you consider unblocking debianutils so that it can transition to testing?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1004318: mrtg: [INTL:nl] Dutch translation of debconf messages

[Eriberto]

Em seg., 24 de jan. de 2022 às 17:39, Frans Spiesschaert
 escreveu:
>
> Dear Maintainer,
>
>
> Please find attached the updated Dutch translation of mrtg debconf
> messages.
> It has been submitted for review to the debian-l10n-dutch mailing list.
> Please add it to your next package revision.
> It should be put as debian/po/nl.po in your package build tree.


Thanks Frans! I will upload it today.

Cheers,

Eriberto

Bug#1004319: atftp: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: atftp 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of atftp debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1004318: mrtg: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: mrtg 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of mrtg debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1004317: gnunet: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: gnunet 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of gnunet debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1004316: postfix: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: postfix 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of postfix debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1004315: ITS: ffmpegthumbnailer

[Boyuan Yang]

Source: ffmpegthumbnailer
Version: 2.1.1-0.2
Severity: important
X-Debbugs-CC: mrpo...@gmail.com

Dear package ffmpegthumbnailer maintainer in Debian,

After looking into the package you maintain (ffmpegthumbnailer, 
https://tracker.debian.org/pkg/ffmpegthumbnailer), I found that this package
received no maintainer updates in the past 9 years and was not in good
shape. As a result, I am filing an ITS (Intent to Salvage) request
against your package according to section 5.12 in Debian's Developers'
Reference [1].

My current plan is to package the latest upstream release (2.2.2),
clean up packaging and co-maintain this package in Debian Multimedia Team to
allow possible external contribution.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(Feb. 14, 2022) to continue with the package salvaging. If you find it
necessary to pause the ITS process, please let me know immediately by
replying this bug report.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


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

Bug#1004314: ITP: r-cran-admisc -- Adrian Dusa's Miscellaneous GNU R functions

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-admisc -- Adrian Dusa's Miscellaneous GNU R functions
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-admisc
  Version : 0.23
  Upstream Author : Adrian Dusa
* URL : https://cran.r-project.org/package=admisc
* License : GPL-3+
  Programming Lang: GNU R
  Description : Adrian Dusa's Miscellaneous GNU R functions
 Contains functions used across packages 'declared', 'DDIwR', 'mixed',
 'QCA' and 'venn'. Interprets and translates, factorizes and negates SOP - Sum
 of Products expressions, for both binary and multi-value crisp sets, and
 extracts information (set names, set values) from those expressions. Other
 functions perform various other checks if possibly numeric (even if all
 numbers reside in a character vector) and coerce to numeric, or check if the
 numbers are whole. It also offers, among many others, a highly flexible
 recoding routine and a more flexible alternative to the base function
 'with()'.
 .
 Some of the functions in this package use related functions from package
 'QCA'. Users are encouraged to install that package despite not being listed
 in the Imports field, due to circular dependency issues.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-admisc

Bug#1004313: overrides for dbgsym package not parsed

[Marc Haber]

Package: lintian
Version: 2.114.0
Severity: minor

Hi,

I wanted to silence those pesky "elf-error In proram headers" warnings
that have been resulting from #1000977 and #1000449 since weeks.

For example, I get:

W: sudo-dbgsym: elf-error In program headers: Unable to find program 
interpreter name 
[usr/lib/debug/.build-id/21/0aef602898438de8e2b8ff7d9d78aef04ae2be.debug]

and put

$ cat debian/sudo-dbgsym.lintian-overrides
# lintian bug, #1000977, #1000449
sudo-dbgsym: elf-error In program headers: Unable to find program interpreter 
name *
$

In strace, I see debian/sudo-dbgsym.lintian-overrides being opened and
ead. In debug output, I see nothing, because the debug output just says
Base directory for processable: 
/tmp/lintian-pool-GRZESmDB6r/sudo/sudo_1.9.8p2-2~1_source-amd64_changes
Loading overrides file (if any) ...
wthout saying whether there are any. Wishlist item: Please give debug
output saying which override files are being read.

I therefore applied the following patch to
/usr/share/lintian/lib/Lintian/Group.pm:
--- /home/mh/Group.pm   2022-01-24 19:58:53.720765500 +0100
+++ /usr/share/lintian/lib/Lintian/Group.pm 2022-01-24 20:06:23.349479431 
+0100
@@ -210,6 +210,10 @@
   if !ref $err || $err->errno != ENOENT;
 }

+use Data::Dumper;
+say {*STDERR} encode_utf8('declared overrides '. 
Dumper($declared_overrides))
+  if $option->{debug};
+
 my %alias = %{$self->profile->known_aliases};
 my @renamed_overrides
   = grep { length $alias{$_} } keys %{$declared_overrides};

I see that $declared_overrides is empty for sudo-dbgsym, but not for
sudo and sudo-ldap. So there must be something different for the dbgsym
package that the file is read but not parsed.

Wishlist item: Please print the actual overrides read from the file in
debug output, maybe a little more pretty like my makeshift patch does.

After adding a dummy stanza for sudo-dbgsym to debian/control this
changes, and $declared_overrides is now filled. Lintian's output is
weird after that, but at least it looks like the processing of an
override file depends on whether the package is mentioned in
debian/control.

I think that implicitly generated packages such as -dbgsym packages
should have their lintian-overrides files honored.

Greetings
Marc

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

Kernel: Linux 5.16.1-zgsrv20080 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils2.37.50.20220121-1
ii  bzip2   1.0.8-5
ii  diffstat1.64-1
ii  dpkg1.21.1
ii  dpkg-dev1.21.1
ii  file1:5.41-2
ii  gettext 0.21-4
ii  gpg 2.2.27-3
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.28-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.27-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-1
ii  libdevel-size-perl  0.83-1+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.1
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.122-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.009-1
ii  libproc-processtable-perl   0.634-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libsyntax-keyword-try-perl  0.26-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-2
ii  libtext-levenshteinxs-perl  0.03-4+b8

Bug#1003956: ntpsec: security settings

[Christoph Anton Mitterer]

On Tue, 2022-01-18 at 21:52 -0600, Richard Laager wrote:
> > Shouldn't -g be removed?
> 
> First off, note that the stock ntpsec.service has Restart=no, not 
> Restart=yes. So in the malicious/broken server scenario described,
> ntpd 
> will die, but not restart.

How does that add protection? Isn't it still, that if one e.g. reboots
and ntpd starts the first time, then an attacker could basically set
any time?



> As far as -g goes, there's really no one right answer. If you keep -
> g, 
> then ntpsec can fix arbitrarily broken clocks. If you remove it, then
> it 
> can't. Imagine how confusing would be if you clock is wrong, you
> install 
> ntpsec, and your clock is still wrong. Additionally, consider systems
> like the Raspberry Pi where there is no real-time clock; they need
> ntpd 
> to be able to make large adjustments, so removing -g would break
> them.

One could argue here, that most "normal" systems (desktops, servers)
have usually rather well working clocks... an so they wouldn't be
likely affected by what you describe.

OTOH, embedded systems are "special" and if someone uses a system with
no clock at all, than IMO it's rather his duty to take necessary steps
so that it works (e.g. by installing ntpdate).

Someone who installs ntpsec probably goes for the "sec" part... and it
feels as if security would be weakened quite a bit by having -g or
allowing DCHP advertised clocks per default, just in order to make
things more runs-out-of-the-box.


> Users can override the -g default in /etc/default/ntpsec and/or the 
> Restart=no default with a systemd drop-in file. FWIW, at my day job,
> I 
> override both on non-Pi always-on server systems: I set NTPD_OPTS="-
> N" 
> (no -g) and Restart=on-failure. On Raspberry Pis, I keep -g and still
> set Restart=on-failure, but I'm not doing anything security sensitive
> on 
> Pis. Those settings mean that ntpd will get restarted if it crashes
> (not 
> that I've ever seen it crash).

Again,... seems like if security would be weakened for use cases where
security isn't that important anyway (and ntpsec itself isn't that
crucial).


> > 2) Also in /etc/default/ntpsec, per default IGNORE_DHCP is "".
> > Shouldn't that be set to yes, so that per default a malicious DHCP
> > server
> > couldn't add it's own possible rogue servers?
> 
> Maybe. But ntpsec-ntpdate isn't installed by default and even
> installing 
> ntpsec doesn't pull it in. If you choose to install that package, you
> (arguably) are expressing a desire to use its features, and the DHCP 
> integration is a big part of that.

I didn't realise that /etc/default/ntpsec's IGNORE_DHCP actually
affects only ntpsec-ntpdate (or at least that's how I understand
you)... which however has it's own /etc/default file with it's own
IGNORE_DHCP??


> > 3) The legacy ntp.conf used:
> > restrict -4 default kod notrap nomodify nopeer noquery limited
> > restrict -6 default kod notrap nomodify nopeer noquery limited
> > 
> > okay, notrap is gone
> 
> This was removed from the Debian ntp.conf (commit from ntpsec-pkg,
> not 
> upstream):

That's what I've meant with my "is gone" :-)

> docs/access.adoc (in the source), which compiles to 
> /usr/share/doc/ntpsec-doc/html/access.html in ntpsec-doc, says:
> +restrict default+, with no mask option, modifies both IPv4 and IPv6
> default entries.
Ah I see.


> So it should apply to both. If you have any reason to believe it's
> not 
> working for both, please let me know.

No, not apart from those links I've sent before.



Thanks for your help :-)
Chris.

Bug#983985: bctoolbox: ftbfs with GCC-11

[Bastian Germann]

Control: tags -1 patch fixed-upstream

Upstream has that fixed with
https://gitlab.linphone.org/BC/public/bctoolbox/-/commit/9ac0e412c45bf28d02829e9d912342359714f638

Bug#1003966: ntpsec: split out ntpdig?

[Christoph Anton Mitterer]

Hey Richard.

On Tue, 2022-01-18 at 20:33 -0600, Richard Laager wrote:
> 1. What is your use case for ntpdig and/or ntpdate (please be
> specific 
> which) if not for the hooks?
Well it's mostly what I've semi-indicated already:

- I wouldn't want all the hooks, as for normal operations I have ntpsec
 running.

- But *if* for some reason the system time deviated to far from the
real time (e.g. when it was changed manually for some debugging or so,
or when the system was longer powered of and the clock is bad),...
where the daemon would take to long to correct,... it would be nice to
have a manual(!) one-shot command which simply sets the time to what
every is determined via NTP (well ideally NTS, but ntpdig doesn't seem
to support that).

An alternative would of course be to use -g and/or -G ... but that I
wouldn't want to set in general.



> 2. My recollection is that there was some talk about removing ntpdate
> from Debian's src:ntp. I don't know if that's already happened.
> 
> I ended up implementing all that in Debian's src:ntpsec for 
> compatibility with ntp, but I intended on removing it once ntp did.
I thought the plan was to replace ntpdate with sntp?


> The network hooks do a couple of different things. First, if you're 
> using ifupdown, then when an interface comes up, ntpsec is stopped, 
> ntpdate is run, and ntpsec is started. This is arguably* desirable if
> the system is not always connected to the Internet.
If it then fetches the current time every time... and if ntpdig doesn't
use NTS... doesn't that give an attacker the chance to mess with the
time rather easily?



> * But why not either: A) run systemd-timesyncd (the default anyway)
I think that has (not yet) support for NTS? 


> 3. The DHCP bit can be turned off in /etc/default/ntpsec-ntpdate. 
> Disabling running ntpdate on ifup would require deleting the hook
> script.

Well that's why I kinda wanted not to have the hooks at all, but just
the tool,... so that I don't need to worry how far or not they
integrated into NM/ifupdown/etc..


Cheers,
Chris.

Bug#1004300: linux-image-5.15.0-3-amd64: firmware-iwlwifi and reported kernel doesn't work

[Daniel Urdiales]

Yeah, was after some reboots (cannot tell 1, 2 or more). Maybe I copied 
bad the package name (I should have checked it before sending). The 
problem maybe is that the package is called 
"linux-image-5.15.0-3-amd64", which is in the version 5.15.15-1


El 24/1/22 a las 19:57, Diederik de Haas escribió:


On maandag 24 januari 2022 18:38:20 CET Daniel Urdiales wrote:

Sorry. For some weird reason now the wifi works. Now i don't know if I
did well reporting the bug or no... I had a weird behavior where the
wifi never were able to connect, to any wifi

Did you reboot perhaps?

In your initial report I noticed something odd after I send my initial reply:

Linux version 5.15.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-11
(Debian 11.2.0-13) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP
Debian 5.15.5-3 (2021-12-18)

Kernel 5.15.0-3-amd64 belongs to kernel 5.15.15, whereas you reported it
against 5.15.5-3. That version itself doesn't exist in Debian, but there is/
was a 5.15.5-2, released on 2021-12-18, but that belongs to 5.15.5.

Bug#1004312: diffoscope: can't diff non-existent file with .pyc: struct.error: unpack requires a buffer of 4 bytes

[Jakub Wilk]

Package: diffoscope
Version: 201

I wanted to use diffoscope to see what's inside a .pyc file, but that 
didn't work:


   $ echo '6 * 7' > test.py

   $ python3 -m compileall -b test.py
   Compiling 'test.py'...

   $ diffoscope --new-file /nonexistent test.pyc
   Traceback (most recent call last):
 File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 752, in main
   sys.exit(run_diffoscope(parsed_args))
 File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 707, in 
run_diffoscope
   difference = compare_root_paths(path1, path2)
 File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
69, in compare_root_paths
   difference = compare_files(file1, file2)
 File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
128, in compare_files
   return file1.compare(file2, source)
 File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/missing_file.py", line 
89, in compare
   backward_diff = other.compare(self, source)
 File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 
502, in compare
   difference = self._compare_using_details(other, source)
 File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", line 
409, in _compare_using_details
   details.extend(self.compare_details(other, source))
 File "/usr/lib/python3/dist-packages/diffoscope/comparators/python.py", 
line 45, in compare_details
   describe_pyc(other.path),
 File "/usr/lib/python3/dist-packages/diffoscope/comparators/python.py", 
line 58, in describe_pyc
   return "\n".join(parse_pyc(f))
 File "/usr/lib/python3/dist-packages/diffoscope/comparators/python.py", 
line 67, in parse_pyc
   modtime = time.asctime(time.gmtime(struct.unpack("

Bug#1004300: linux-image-5.15.0-3-amd64: firmware-iwlwifi and reported kernel doesn't work

[Diederik de Haas]

On maandag 24 januari 2022 18:38:20 CET Daniel Urdiales wrote:
> Sorry. For some weird reason now the wifi works. Now i don't know if I
> did well reporting the bug or no... I had a weird behavior where the
> wifi never were able to connect, to any wifi

Did you reboot perhaps?

In your initial report I noticed something odd after I send my initial reply:
> Linux version 5.15.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-11
> (Debian 11.2.0-13) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP
> Debian 5.15.5-3 (2021-12-18)

Kernel 5.15.0-3-amd64 belongs to kernel 5.15.15, whereas you reported it 
against 5.15.5-3. That version itself doesn't exist in Debian, but there is/
was a 5.15.5-2, released on 2021-12-18, but that belongs to 5.15.5.

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

Bug#1004182: diffoscope: can't compare non-existent files: No such file or directory

[Jakub Wilk]

* Chris Lamb , 2022-01-24, 11:21:

https://salsa.debian.org/reproducible-builds/diffoscope/commit/b51a31e9c5d62d40327a870cb8dfdbeed9a4b021


Hmm, that's not the outcome I was hoping for…

But when reading the changelog entry for 32, I (re-)discovered the 
option --new-file, which makes this work:


   $ diffoscope --new-file /nonexistent archive.zip
   --- /nonexistent
   +++ archive.zip
   ├── zipinfo {}
   │ @@ -0,0 +1,3 @@
   │ +Zip file size: 199 bytes, number of entries: 1
   │ +-rw-r--r--  3.0 unx   13 tx stor 21-Aug-22 17:00 etc/debian_version
   │ +1 file, 13 bytes uncompressed, 13 bytes compressed:  0.0%
   ...

--
Jakub Wilk

Bug#1004311: pahole segfaults during kernel build

[Andres Freund]

Package: pahole
Version: 1.22-2
Severity: normal

Dear Maintainer,

Building an upstream kernel reliably segfaults in pahole, starting with
1.22-2. I just downgraded to 1.22-1 (from snapshot.do) and that does *not*
have this problem. I don't immediately see a changelog entry that could
explain this problem.

Greetings,

Andres

Backtrace from core file:

#0  type__compare_members (b=0x55a9260432b0, a=0x55a925f8ce70) at ./pahole.c:216
216 ./pahole.c: No such file or directory.
(gdb) bt
#0  type__compare_members (b=0x55a9260432b0, a=0x55a925f8ce70) at ./pahole.c:216
#1  type__compare (cu_a=, cu_b=0x55a925f4b880, b=0x55a9260432b0, 
a=0x55a925f8ce70) at ./pahole.c:310
#2  __structures__add (class=class@entry=0x55a9260432b0, 
cu=cu@entry=0x55a925f4b880, id=id@entry=26, 
existing_entry=existing_entry@entry=0x7ffce1053090)
at ./pahole.c:326
#3  0x55a9258f4491 in structures__add (existing_entry=0x7ffce1053090, 
id=26, cu=0x55a925f4b880, class=0x55a9260432b0) at ./pahole.c:357
#4  print_classes (cu=) at ./pahole.c:524
#5  pahole_stealer (cu=0x55a925f4b880, conf_load=) at 
./pahole.c:2859
#6  0x55a925901613 in cu__finalize (conf=0x55a925914100 , 
cu=0x55a925f4b880) at ./dwarf_loader.c:2477
#7  cus__finalize (cus=0x55a925f47610, cu=cu@entry=0x55a925f4b880, 
conf=0x55a925914100 ) at ./dwarf_loader.c:2484
#8  0x55a925903ba7 in dwarf_cus__create_and_process_cu 
(dcus=dcus@entry=0x7ffce10532a0, cu_die=0x7ffce1053250, pointer_size=)
at ./dwarf_loader.c:2675
#9  0x55a92590462c in __dwarf_cus__process_cus (dcus=) at 
./dwarf_loader.c:2764
#10 dwarf_cus__process_cus (dcus=0x7ffce10532a0) at ./dwarf_loader.c:2778
#11 cus__load_module (cus=cus@entry=0x55a925f47610, conf=, 
mod=mod@entry=0x55a925f49f00, dw=, elf=elf@entry=0x55a925f476f0,
filename=0x7ffce1054a6e ".tmp_vmlinux.btf") at ./dwarf_loader.c:2913
#12 0x55a9259048b1 in cus__process_dwflmod (dwflmod=0x55a925f49f00, 
userdata=, name=, base=,
arg=0x7ffce1053400) at ./dwarf_loader.c:2957
#13 0x7fdc64fe3471 in dwfl_getmodules () from 
/lib/x86_64-linux-gnu/libdw.so.1
#14 0x55a925900880 in cus__process_file (filename=0x7ffce1054a6e 
".tmp_vmlinux.btf", fd=5, conf=0x55a925914100 , cus=0x55a925f47610)
at ./dwarf_loader.c:3023
#15 dwarf__load_file (cus=0x55a925f47610, conf=0x55a925914100 , 
filename=0x7ffce1054a6e ".tmp_vmlinux.btf") at ./dwarf_loader.c:3058
#16 0x55a9258f905f in cus__load_file (cus=cus@entry=0x55a925f47610, 
conf=conf@entry=0x55a925914100 ,
filename=0x7ffce1054a6e ".tmp_vmlinux.btf") at ./dwarves.c:2043
#17 0x55a9258f92d8 in cus__load_files (cus=cus@entry=0x55a925f47610, 
conf=conf@entry=0x55a925914100 , 
filenames=filenames@entry=0x7ffce10537c0)
at ./dwarves.c:2396
#18 0x55a9258f0ba9 in main (argc=4, argv=0x7ffce10537a8) at ./pahole.c:3224
(gdb)

Using a pahole built from source I do not see this.


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

Kernel: Linux 5.16.0-rc5-andres-00225-g5e9874628080 (SMP w/40 CPU threads; 
PREEMPT)
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)

Versions of packages pahole depends on:
ii  libbpf0  1:0.5.0-1
ii  libc62.33-3
ii  libdw1   0.186-1
ii  libelf1  0.186-1
ii  zlib1g   1:1.2.11.dfsg-2

pahole recommends no packages.

pahole suggests no packages.

-- no debconf information

Bug#1004310: knxd: ftbfs with glibc 2.34: don't use common unix function name as variable name

[Steve Langasek]

Package: knxd
Version: 0.14.46-1
Severity: serious
Tags: patch experimental
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Hi Matthias,

In Ubuntu, we have found that the knxd package fails to build from source
because glibc header dependencies mean that the link() declaration from
unistd.h is now exposed in a context it wasn't previously, leading to a
namespace conflict:

[...]
g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src/libserver -I../../src/backend -I../
../src/common -I../../src/usb -I/usr/include/libusb-1.0  -Wno-missing-field-init
ializers -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protecto
r-strong -std=c++0x -Wno-subobject-linkage -MT knxd_args.o -MD -MP -MF .deps/knx
d_args.Tpo -c -o knxd_args.o knxd_args.cpp
knxd_args.cpp:71:13: error: ‘char link [99]’ redeclared as different kind of 
entity
   71 | char link[99] = "@.";
  | ^
In file included from /usr/include/x86_64-linux-gnu/bits/sigstksz.h:24,
 from /usr/include/signal.h:328,
 from /usr/include/ev.h:162,
 from /usr/include/ev++.h:46,
 from ../../src/libserver/common.h:31,
 from ../../src/libserver/trace.h:40,
 from knxd_args.cpp:29:
/usr/include/unistd.h:818:12: note: previous declaration ‘int link(const char*, 
const char*)’
  818 | extern int link (const char *__from, const char *__to)
  |^~~~
[...]

  (https://launchpad.net/ubuntu/+source/knxd/0.14.46-1build1/+build/22982832)

glibc 2.34 is currently in Debian experimental, so this problem will also
affect Debian soon.

I've uploaded the attached patch to Ubuntu to fix the build failure there;
please consider including it in Debian.  You can of course choose any more
meaningful variable name of your choice if you don't like the one I've
chosen :), but I don't think it's worth the effort to try to mask the
standard symbol from the namespace in order to keep the current variable
name.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru knxd-0.14.46/debian/patches/glibc-2.34.patch 
knxd-0.14.46/debian/patches/glibc-2.34.patch
--- knxd-0.14.46/debian/patches/glibc-2.34.patch1969-12-31 
16:00:00.0 -0800
+++ knxd-0.14.46/debian/patches/glibc-2.34.patch2022-01-24 
09:17:19.0 -0800
@@ -0,0 +1,151 @@
+Description: Fix build failure with glibc 2.34
+ The code uses a generic variable name of 'link' which collides with a 
+ standard (unistd.h) function that as of glibc 2.34 happens to be 
+ indirectly exposed in the namespace for this file.  Address this by
+ renaming the variable.
+Author: Steve Langasek 
+Last-Update: 2022-01-24
+Forwarded: no
+
+Index: knxd-0.14.46/src/server/knxd_args.cpp
+===
+--- knxd-0.14.46.orig/src/server/knxd_args.cpp
 knxd-0.14.46/src/server/knxd_args.cpp
+@@ -68,13 +68,13 @@
+ } while(0)
+ 
+ IniData ini;
+-char link[99] = "@.";
++char link_target[99] = "@.";
+ void link_to(const char *arg)
+ {
+   char *p;
+-  ++*link;
+-  strcpy(link+2,arg);
+-  p = strchr(link+2,':');
++  ++*link_target;
++  strcpy(link_target+2,arg);
++  p = strchr(link_target+2,':');
+   if (p)
+ *p = 0;
+ }
+@@ -163,10 +163,10 @@
+   {
+ link_to(name);
+ ITER(i, more_args)
+-(*ini[link])[i->first] = i->second;
+-(*ini[link])["filter"] = name;
++(*ini[link_target])[i->first] = i->second;
++(*ini[link_target])["filter"] = name;
+ more_args.clear();
+-filters.push_back(link);
++filters.push_back(link_target);
+   }
+ else
+   filters.push_back(name);
+@@ -232,7 +232,7 @@
+ {
+   va_list apl;
+   va_start(apl, ap);
+-  (*ini[link])["driver"] = arg;
++  (*ini[link_target])["driver"] = arg;
+   char *pa = NULL;
+ 
+   while(ap)
+@@ -250,7 +250,7 @@
+   if (*pa == '!') // required-argument flag
+ pa++;
+   if (*ap) // skip empty arguments
+-(*ini[link])[pa] = ap;
++(*ini[link_target])[pa] = ap;
+   ap = p2;
+ }
+   if (pa != NULL)
+@@ -280,7 +280,7 @@
+   else if(!strcmp(arg,"iptn"))
+ {
+   driver_argsv("ipt",ap, 
"!ip-address","dest-port","src-port","nat-ip","data-port", NULL);
+-  (*ini[link])["nat"] = "true";
++  (*ini[link_target])["nat"] = "true";
+ }
+   else if(!strcmp(arg,"ft12") || !strcmp(arg,"ncn5120") || 
!strcmp(arg,"tpuarts") || !strcmp(arg,"ft12cemi") || !strcmp(arg,"tpuart"))
+ {
+@@ -556,18 +556,18 @@
+   if (arguments->want_server)
+ die("You need -S after -D/-T/-R");
+   

Bug#999155: ping

[Thorsten Alteholz]

On 24.01.22 18:02, Mark Brown wrote:

On Mon, Jan 24, 2022 at 05:51:43PM +0100, Thorsten Alteholz wrote:


In order have some activity on this bug and to avoid autoremoval of
dependencies, this is a reminder of outstanding things to do ...

Please don't send content free pings, they just add noise and make it
likely that it's going to take longer (since I remember that I did
something but forget that it was just handling the ping).



Please have a look at [1].  Those ping I send to the corresponding bugs 
reset the time of the autorm again. As I don't want my packages to be 
removed from testing, I am afraid you need to bear those pings.


  Thorsten

[1] https://lists.debian.org/debian-devel-announce/2013/09/msg6.html

Bug#953929: NMU

[Bastian Germann]

Control: tags -1 patch

A debdiff that fixes this is enclosed. I am uploading a NMU again because my 
last one did not build on buildd.diff -Nru ima-evm-utils-1.4/debian/changelog ima-evm-utils-1.4/debian/changelog
--- ima-evm-utils-1.4/debian/changelog  2022-01-24 10:49:06.0 +0100
+++ ima-evm-utils-1.4/debian/changelog  2022-01-24 18:33:09.0 +0100
@@ -1,3 +1,11 @@
+ima-evm-utils (1.4-1.2) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * d/control: Drop unnecessary build dependency libattr1-dev (Closes: #953929)
+  * d/rules: Skip tests (many depend on extended attrs, Closes: #999824)
+
+ -- Bastian Germann   Mon, 24 Jan 2022 18:33:09 +0100
+
 ima-evm-utils (1.4-1.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru ima-evm-utils-1.4/debian/control ima-evm-utils-1.4/debian/control
--- ima-evm-utils-1.4/debian/control2022-01-24 10:49:06.0 +0100
+++ ima-evm-utils-1.4/debian/control2022-01-24 18:32:41.0 +0100
@@ -8,7 +8,6 @@
  docbook-xml,
  docbook-xsl,
  attr,
- libattr1-dev,
  libkeyutils-dev,
  libssl-dev,
  openssl,
diff -Nru ima-evm-utils-1.4/debian/rules ima-evm-utils-1.4/debian/rules
--- ima-evm-utils-1.4/debian/rules  2021-09-24 11:39:11.0 +0200
+++ ima-evm-utils-1.4/debian/rules  2022-01-24 18:33:09.0 +0100
@@ -4,3 +4,6 @@
 
 %:
dh $@
+
+override_dh_auto_test:
+# Many tests set extended attributes, which are not guaranteed to work on a 
system

Bug#1004060: systemd: breaks lightdm / lightdm-gtk-greeter

[Vincent Lefevre]

On 2022-01-24 18:32:43 +0100, Yves-Alexis Perez wrote:
> out of curiosity, did you try to move the mouse (and bring it “back” to the
> main screen) and see if the login dialog appears? My main setup also uses a
> dual screen (docked laptop with an external screen), and I didn't (yet)
> experienced the issue you describe, but both my screens have pretty similar
> resolutions (laptop is 1920×1080, external screen is 1920×1200).

I had tried to move the mouse, but this didn't have any effect. So
this is rather different than bug 993752 (where moving the mouse
switches the width of the screen) I had reported in September.

> Also are both screens on and visible?

When the bug occurs, both screens are always on and are mirrored.

I'm wondering: in the lightdm-gtk-greeter logs, I got lots of warnings

  Drawing a gadget with negative dimensions. Did you forget to allocate a size? 
(node menubar owner GreeterMenuBar)

I also get some of such warnings when the bug doesn't occur.
But perhaps this shows that something is wrong.

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

Bug#1004293: warn users that src:webkit2gtk and src:khtml are insecure?

[Holger Levsen]

control: retitle -1 warn users that src:khtml is insecure?

On Mon, Jan 24, 2022 at 04:39:22PM +0100, Moritz Muehlenhoff wrote:
> webkit2gtk is fully supported since Buster and there have been plenty of 
> security updates since
> then: https://security-tracker.debian.org/tracker/source-package/webkit2gtk
> 
> khtml should in fact be added, since it's AFAICT used by Konqueror.

thanks, Moritz!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

half the worlds poor life in resource rich countries.
HOME: https://youtu.be/Eu6ieWI3yjI


signature.asc
Description: PGP signature

Bug#1004091: Starts user services

[Yuri D'Elia]

On Mon, Jan 24 2022, Yves-Alexis Perez wrote:
> I assume you're talking about systemd user services or something? I don't
> think there's any specific code in lightdm about starting manually pulseaudio,
> pipewire or anything, so I don't think there's a way to special cases some
> thing.

Yes, the issue is that lightdm starts automatically all systemd's user
services (anything which is installed in the default.target in
/usr/lib/systemd/user/) probably because it is creating a full user
session?

Bug#997478: pyls-black: diff for NMU version 0.4.6-3.1

[Julian Gilbey]

On Wed, Jan 19, 2022 at 07:22:50PM +0200, Adrian Bunk wrote:
> Control: tags 997478 + patch
> Control: tags 997478 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for pyls-black (versioned as 0.4.6-3.1) and 
> uploaded it to DELAYED/15. Please feel free to tell me if I should 
> cancel it.
> 
> cu
> Adrian

Dear Adrian,

Many thanks for doing this!  It will help keep things ticking over for
the time being.

I've been in discussion with the upstream Spyder developers, and they
would like us to wait a few months before upgrading Spyder until they
have released 5.3.0, as 5.2.x crashes on quitting when using the
current PyQt5 (which is a little unfortunate).  So this will help for
now.  (Though as python-language-server is also due for removal due to
#1002351 and #999524, this fix may not be sufficient to keep Spyder in
testing.)

Once Spyder 5.3.0 is uploaded, we will be requesting the removal of
pyls-black from the archive, as it has been superseded by
pylsp-black.

Best wishes,

   Julian

Bug#1004300: linux-image-5.15.0-3-amd64: firmware-iwlwifi and reported kernel doesn't work

[Daniel Urdiales]

Sorry. For some weird reason now the wifi works. Now i don't know if I 
did well reporting the bug or no... I had a weird behavior where the 
wifi never were able to connect, to any wifi


El 24/1/22 a las 16:20, Diederik de Haas escribió:

On maandag 24 januari 2022 15:38:01 CET Daniel wrote:

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

* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
  ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?

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

Could you fill in the above template so we'll have more information to help you?
"Doesn't work" isn't much to go on and the kernel log included in the bug
report seems to indicate a successful wireless connection:


[   24.900350] wlo1: authenticate with 02:09:c1:90:4a:10
[   24.903768] wlo1: send auth to 02:09:c1:90:4a:10 (try 1/3)
[   24.948852] wlo1: authenticated
[   24.949316] wlo1: associate with 02:09:c1:90:4a:10 (try 1/3)
[   24.953015] wlo1: RX AssocResp from 02:09:c1:90:4a:10 (capab=0x1131 status=0 
aid=1)
[   24.972100] wlo1: associated
[   25.041391] wlo1: Limiting TX power to 14 (14 - 0) dBm as advertised by 
02:09:c1:90:4a:10
[   25.041487] IPv6: ADDRCONF(NETDEV_CHANGE): wlo1: link becomes ready

Bug#1004060: systemd: breaks lightdm / lightdm-gtk-greeter

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2022-01-20 at 13:59 +0100, Vincent Lefevre wrote:
> Additional details:
> 
> The resolution of the laptop screen is 3200×1800.
> The resolution of the external monitor is 3840×2160.
> A 3840×2160 virtual screen is used.
> 
> I suspect that the greeter thinks that there is a second separate
> screen (instead of a mirrored screen), and it puts the menu bar
> and login dialog there, so that I cannot see them. The following
> workaround would confirm that: set active-monitor=1 in the greeter
> config file (/etc/lightdm/lightdm-gtk-greeter.conf). With this
> setting, the issue on startup seems to have completely disappeared
> (still no issues either with a one-monitor setup). Note: some users
> say active-monitor=0, e.g.

Hi Vincent,

out of curiosity, did you try to move the mouse (and bring it “back” to the
main screen) and see if the login dialog appears? My main setup also uses a
dual screen (docked laptop with an external screen), and I didn't (yet)
experienced the issue you describe, but both my screens have pretty similar
resolutions (laptop is 1920×1080, external screen is 1920×1200).

Also are both screens on and visible?

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmHu4rsACgkQ3rYcyPpX
RFtF5AgAuC28bTr9VLnxTdrMqSDvC+w0SgdA3IzTSpvqYms13dCpWs+dcVGzUckU
01sEAllZZIsF0SJzRCkZtDqR7j1+LDyiWO//CaQBAibjF/pp/mlfYOovc7ZxA9kV
G49y903snFbx8eWECYWbshYFSETEKxyuDtqs4eRfXiaQW10ore/xC5om+CHSqREg
TM6GTU57smTo2J0xJ9UVIuZy2V2pYHrDm/c9o5r/z42n7PfRlfqgUZJtMhHO2Oju
U6i0ylOPErbQygmoC55Oozz3zGf2ce/gxY5bBhiguSK1C1OFbmNhPpMvbXg5blmf
7J3SMBuEkLJR6kLywuB6UFhvf9aj8w==
=a6/p
-END PGP SIGNATURE-

Bug#1004091: Starts user services

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2022-01-20 at 19:03 +0100, Yuri D'Elia wrote:
> The user which is running lightdm starts all "user" services which are
> enabled by default, which might include pipewire (and I guess
> pulseaudio), gnupg.. synchthing.
> 
> I find this behavior undersiderable. pipewire/pulseaudio could probably
> by used by the theme to provide audio in the session, but most other
> services only make sense for a real user.
> 
> It seems like lightdm might befinit from a strictly defined list of
> services instead of starting a full-fledged user session that results in
> this behavior.

Hi,

I assume you're talking about systemd user services or something? I don't
think there's any specific code in lightdm about starting manually pulseaudio,
pipewire or anything, so I don't think there's a way to special cases some
thing.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmHu4MIACgkQ3rYcyPpX
RFv+jwgA5kojYzryPAqDiNygOhWMIcP78tYHRSJQS+mYLWpAhRR5AvFc6+BZRde+
pR8PS+xqyEorp9OuPgm6QOoGDfVZygVQUEEYL+swilnZddaVv3OMDmbGYX+qO2i+
Qtlc8zg2nBdj251ndgJcWb7S2HIWf5Fr4JJjvJGM+kGmgAWfJn8ivBrwScBLcwyy
5IbXpiTuzrv88dpxfRTDRUFkY44Mcu9mV8B/n2y17JOaGhg8g1vnBTL/5yX8Kkz6
SQv4urcX1Y+D4xdZyLZmAldVMQ3+WmFr8VSJ/Qu2QKPo1hJGd9rX/wAsFeMdbWV6
PFfobXCrCl83dpNztf7cUwhTtqB9JQ==
=PShR
-END PGP SIGNATURE-

Bug#1002210: adapt: diff for NMU version 1.0.0-1.1

[Wouter Verhelst]

Thanks!

The delay is absolutely not necessary; feel free to redirect to a direct upload.
-- 
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.

Bug#1004297: libpcsclite1: SCardConnect is blocking but not cancellable

[Ludovic Rousseau]

Hello Ievgenii,

Le 24/01/2022 à 15:12, Ievgenii Meshcheriakov a écrit :

Package: libpcsclite1
Version: 1.9.5-1
Severity: normal
X-Debbugs-Cc: eu...@debian.org

ScardConnect() call is blocking when another process has started a transaction
on the same card, but it is impossible to cancel it using SCardCancel().
This makes it harder to use the library reliably in an asynchronous manner.

I'm attaching source code that demonstrates the problem. After building it
run 'cardlock' executable followed by 'cardlock_cancel' in a different
terminal. A card should be in the used card reader. Both executables accept
reader ID as arguments. My expectation is that 'cardlock_cancel' could exit
after 5 second sleep, but it does not.


This problem is not Debian specific.

Please follow the discussion on the MUSCLE list
https://lists.infradead.org/pipermail/pcsclite-muscle/2022-January/001233.html

If you really want to open a ticket please open it upstream at salsa or github
https://salsa.debian.org/rousseau/PCSC/-/issues
https://github.com/LudovicRousseau/PCSC/issues

Bye

--
Dr. Ludovic Rousseau

Bug#995171: need newer release

[Afif Elghraoui]

Hi, Andreas!

On 1/24/22 07:24, Andreas Tille wrote:

I might have a look once I get permissions to push directly.


Access granted. I don't get email notifications when someone makes an 
access request, so I rely on someone emailing the list saying "hey, I 
want to join"


thanks and regards
Afif

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

Bug#1004292: debian-installer:s390x: installer fails to format dasd disc on s390x systems

[Cyril Brulebois]

Hi Dipak,

Dipak Zope  (2022-01-24):
> On s390x machines with dasd disc, the installer fails to format the dasd 
> disc. 
> 
> Logs: 
> Jan 24 12:25:13 main-menu[341]: INFO: Menu item 's390-dasd' selected
> Jan 24 12:25:19 s390-dasd[3224]: dasdfmt:
> Jan 24 12:25:19 main-menu[341]: WARNING **: Configuring 's390-dasd' failed 
> with error code 1
> Jan 24 12:25:19 main-menu[341]: WARNING **: Menu item 's390-dasd' failed.
> 
> 
> Root cause: 
> The s390-dasd package calls dasdfmt with '-f' option which is obselete
>  long ago. 
> 
> Proposed Fix: 
> s390-dasd / dasd-config.c: line 393:
> Existing line: snprintf (buf, sizeof (buf), "dasdfmt -l LX%04x -b 4096 -m 1 
> -f %s -y", channel_device (channel_current->name), dev);
> Proposed line: snprintf (buf, sizeof (buf), "dasdfmt -l LX%04x -b 4096 -m 1 
> %s -y", channel_device (channel_current->name), dev);
> 
> 
> This fix is verified. Logs for reference after changes (with additional
> debug statement): 

Thanks for the proposed fix and the verification. Do you have anything
else s390x/dasd related? Or can we commit this fix, release the package
to unstable and consider backporting it to bullseye?


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


signature.asc
Description: PGP signature

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Russ Allbery]

Christoph Berg  writes:

> We were discussing the bug in last week's tech-ctte meeting, and the
> gist of the discussion was that, in a ideal world, Debian would be
> shipping the util-linux version as /usr/bin/rename to match what other
> distributions are shipping, but that since we have been shipping the
> Perl rename for the past 20 years, a proper transition would be very
> hard.

I understand the appeal of this for cross-distribution compatibility, but
we haven't been compatible with other distributions for a very long time
and there haven't seem to have been that many complaints.  Even the
request that set off this discussion was, if I recall correctly, only
about getting access to the util-linux version, not about changing the
default /usr/bin/rename.

Balancing against this is the fact that the Perl rename, while a bit more
complicated to use, is significantly more useful.  The util-linux rename
can only do simple substring replacements, not even regexes (and at least
in my experience a simple s/// expression is the most common use case for
rename).

Neither version is a strict subset of the other (the util-linux
--interactive and --symlink arguments don't appear to have equivalents in
the Perl version), but the Perl version also supports -0 so that it can be
used safely with find/xargs.

It's unfortunate that the command-line syntax for the two programs is
different in such a way as to make it impossible to merge them and write
one program that supports the syntax of both.

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

Bug#999155: ping

[Mark Brown]

On Mon, Jan 24, 2022 at 05:51:43PM +0100, Thorsten Alteholz wrote:

> In order have some activity on this bug and to avoid autoremoval of
> dependencies, this is a reminder of outstanding things to do ...

Please don't send content free pings, they just add noise and make it
likely that it's going to take longer (since I remember that I did
something but forget that it was just handling the ping).


signature.asc
Description: PGP signature

Bug#999155: ping

[Thorsten Alteholz]

In order have some activity on this bug and to avoid autoremoval of 
dependencies, this is a reminder of outstanding things to do ...


  Thorsten

Bug#998553: ping

[Thorsten Alteholz]

In order have some activity on this bug and to avoid autoremoval of 
dependencies, this is a reminder of outstanding things to do ...


  Thorsten

Bug#1002532: pygments breaks ruby-pygments.rb autopkgtest: UTF-8 != ASCII-8BIT

[Alexandre Ghiti]

On Sun, 23 Jan 2022 22:17:08 +0100 Mattia Rizzolo  wrote:
> On Fri, Jan 21, 2022 at 03:51:02PM +0100, Alexandre Ghiti wrote:
> > I can't find how to create a MR in salsa, can you pull directly from here:
> >
> > https://salsa.debian.org/alexghiti/ruby-pygments.rb/-/tree/int/alex/2.3.0
> >
> > It successfully built in my PPA, if you need any more modification, do
> > not hesitate.
>
> Ah, another thing. Please be careful with the version you pick.
>
> You used 2.3.0+ds-1ubuntu1, which is *higher* than what I'll be
> uploading, namely 2.3.0+ds-1.
> Furthermore, in your PPA you used 2.3.0+ds-1ubuntu2, which would also
> conflict with an eventual -1ubuntu done in the offical ubuntu archive.
>
> I'd recommend you used something like -0ppa1 or -0ubuntu1~ppa1 or
> somesuch.
>
> (in this case this is of no consequence, but just something to note).

Thanks for the advice.

>
>
>
> Lastly, I noticed that you haven't even touched the changelog. In this
> case there was even a new copyright holder, so it really should have
> been updated.

Sorry and thanks for taking care of that.

> I didn't add you to the paragraph of d/copyright, as I assume you are
> doing this under your paid time, and I don't know what's Canonical's
> rules regarding copyright here. If needed/wanted, just send me a note
> and I'll update the copy in git.

No problem.

Regarding the autopkgtest failure (again an oversight on my part,
sorry), I fixed it here, it works in my PPA and on an ubuntu jammy VM
(I failed to make autopkgtest work with testing):

https://salsa.debian.org/alexghiti/ruby-pygments.rb/-/commit/19442f7b89c5a6ca5ef1d8e1e6ebc42a261e441e

Thanks again,

Alex

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

Bug#1004182: diffoscope: can't compare non-existent files: No such file or directory

[Chris Lamb]

tags 1004182 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/b51a31e9c5d62d40327a870cb8dfdbeed9a4b021


Regards,

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

Bug#1004302: mmdebstrap: Unable to specify APT pinning (via Dir::Etc::preferencesparts)

[Johannes Schauer Marin Rodrigues]

Quoting Benjamin Drung (2022-01-24 17:14:18)
> > to make sure I understand your problem correctly: The mmdebstrap version in
> > unstable is doing exactly what you want/expect but only the version in
> > stable is not doing what you want?
> 
> Yes,

The difference you see between running the stable version with and without
--simulate is that when you use --simulate, there is no apt inside the chroot
and thus apt from the outside is used and that apt has access to different
paths than the apt inside the chroot.

This is not the case anymore with mmdebstrap in unstable because there we never
use apt inside the chroot since apt included this fix:

https://salsa.debian.org/apt-team/apt/-/commit/544d81a26f8c97a2a45262aecbaef4a5b43fb325

That's also one of the reasons why mmdebstrap cannot be backported.

> but the mmdebstrap version in unstable requires one to specify the full path
> to the preference file.
> 
> It would be nice if I could set `Dir::Etc::preferencesparts` to
> something like "$CURDIR/preferences.d/" without needed to parse this
> expression with Bash (since that would not work when specifying it in a YAML
> file for bdebstrap).

I do not yet understand why your "copy-in" essential hook where you copy
bookworm.pref into /etc/apt/preferences.d inside the chroot doesn't solve this
problem for you. Even though mmdebstrap doesn't run apt from inside the chroot
anymore, it uses the configuration from /etc/apt inside the chroot.

Is that not working in your case somehow?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1004302: mmdebstrap: Unable to specify APT pinning (via Dir::Etc::preferencesparts)

[Benjamin Drung]

Am Montag, dem 24.01.2022 um 16:54 +0100 schrieb Johannes Schauer Marin
Rodrigues:
> Quoting Benjamin Drung (2022-01-24 16:22:43)
> > I tested this in a minimal Debian schroot:
> > 
> > ```
> > apt -y install mmdebstrap
> > mkdir -p preferences.d
> > printf 'Package: *\nPin: release l=Debian,n=bookworm\nPin-Priority:
> > 400\n' > preferences.d/bookworm.pref
> > mmdebstrap -v --variant=minbase \
> >   --aptopt="Dir::Etc::preferencesparts \"$(pwd)/preferences.d/\"" \
> >   --include=python3-minimal/bullseye,python3 \
> >   --essential-hook="copy-in preferences.d/bookworm.pref
> > /etc/apt/preferences.d" \
> >   bullseye root.tar \
> >   "deb http://deb.debian.org/debian bullseye main" \
> >   "deb http://deb.debian.org/debian bookworm main"
> > ```
> > 
> > It fails on a Debian bullseye schroot, but succeeds on an unstable
> > schroot. Since the mmdebstrap version from unstable needs a newer
> > APT
> > version, there is no easy way for backporting.
> > 
> > Is setting `Dir::Etc::preferencesparts` to an absolute path the way
> > to
> > go forward? In this case it would be nice if I could set
> > `Dir::Etc::preferencesparts` to something like
> > "$CURDIR/preferences.d/"
> > and let mmdebstrap resolve it to the absolute path.
> 
> to make sure I understand your problem correctly: The mmdebstrap
> version in
> unstable is doing exactly what you want/expect but only the version
> in stable
> is not doing what you want?

Yes, but the mmdebstrap version in unstable requires one to specify the
full path to the preference file.

It would be nice if I could set `Dir::Etc::preferencesparts` to
something like "$CURDIR/preferences.d/" without needed to parse this
expression with Bash (since that would not work when specifying it in a
YAML file for bdebstrap).

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations Cloud

IONOS SE | Revaler Str. 30 | 10245 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Britta Schmidt, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet


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

Bug#1004080: asterisk: Configuration files owned by asterisk user

[Jonas Smedegaard]

Quoting Johannes Drexl (2022-01-24 16:44:19)
> Am Donnerstag, dem 20.01.2022 um 16:17 +0100 schrieb Jonas Smedegaard:
> > An obvious next step might be to try make the suggested change and 
> > see if it still seems to work the same. Did you try that already, 
> > Drexl? If not, can I ask you to try it?
> 
> Hi Jonas,
> 
> will do internally when I'm finding the time for it, but in a first 
> glance it seems only two files need being private (app_mysql.conf and 
> I think the extensions.conf), and probably none being written.
> Like said, will do. Thanks a lot in the meantime.

Sounds excellent - there is no hurry from my side :-)


 - 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#1004308: smokeping: New upstream version 2.8.2 needs to be packaged

[Gabriel Filion]

Package: smokeping
Severity: normal

Upstream has released a new version of smokeping, 2.8.2 and it would be helpful
to upgrade the debian package to this version since it contains a number of
fixes, some of which would remove patches in the package.

I've received two emails directly requesting the new version so I'm creating
this bug report to reflect their wish to have this version.


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 smokeping depends on:
ii  adduser 3.118
ii  debianutils 5.5-1
pn  fping   
pn  libcgi-fast-perl
pn  libconfig-grammar-perl  
ii  libdigest-hmac-perl 1.04+dfsg-1
pn  libjs-cropper   
pn  libjs-prototype 
pn  libjs-scriptaculous 
ii  librrds-perl1.7.2-4
pn  libsnmp-session-perl
ii  liburi-perl 5.10-1
ii  libwww-perl 6.60-1
ii  lsb-base11.1.0
ii  perl5.32.1-6
ii  postfix [mail-transport-agent]  3.6.3-5
ii  ucf 3.0043

Versions of packages smokeping recommends:
pn  apache2 | apache2 | httpd  
pn  apache2 | httpd-cgi
ii  bind9-dnsutils [dnsutils]  1:9.17.22-1
ii  dnsutils   1:9.17.21-1
pn  echoping   
ii  libsocket6-perl0.29-1+b3

Versions of packages smokeping suggests:
ii  curl   7.81.0-1
pn  libauthen-radius-perl  
ii  libio-socket-ssl-perl  2.074-2
ii  libnet-dns-perl1.33-1
pn  libnet-ldap-perl   
pn  libnet-telnet-perl 
ii  openssh-client 1:8.7p1-4

Bug#1004302: mmdebstrap: Unable to specify APT pinning (via Dir::Etc::preferencesparts)

[Johannes Schauer Marin Rodrigues]

Quoting Benjamin Drung (2022-01-24 16:22:43)
> I tested this in a minimal Debian schroot:
> 
> ```
> apt -y install mmdebstrap
> mkdir -p preferences.d
> printf 'Package: *\nPin: release l=Debian,n=bookworm\nPin-Priority: 400\n' > 
> preferences.d/bookworm.pref
> mmdebstrap -v --variant=minbase \
>   --aptopt="Dir::Etc::preferencesparts \"$(pwd)/preferences.d/\"" \
>   --include=python3-minimal/bullseye,python3 \
>   --essential-hook="copy-in preferences.d/bookworm.pref 
> /etc/apt/preferences.d" \
>   bullseye root.tar \
>   "deb http://deb.debian.org/debian bullseye main" \
>   "deb http://deb.debian.org/debian bookworm main"
> ```
> 
> It fails on a Debian bullseye schroot, but succeeds on an unstable
> schroot. Since the mmdebstrap version from unstable needs a newer APT
> version, there is no easy way for backporting.
> 
> Is setting `Dir::Etc::preferencesparts` to an absolute path the way to
> go forward? In this case it would be nice if I could set
> `Dir::Etc::preferencesparts` to something like "$CURDIR/preferences.d/"
> and let mmdebstrap resolve it to the absolute path.

to make sure I understand your problem correctly: The mmdebstrap version in
unstable is doing exactly what you want/expect but only the version in stable
is not doing what you want?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1004305: RM: dhis-dns-engine -- RoQA; dead upstream; FTBFS

[Ondřej Surý]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

the dhis-dns-engine has been orphaned, the upstream discontinued support for
modular architecture and the modules and engines are no longer part of dhisd
since dhisd 5.4.

Also the package Build-Depends on src:bind9-libs <= 9.11, which is going to be
removed from Debian because BIND 9.11 will be EOL with the next release.

Please remove dhis-dns-engine.

As a matter of fact, the dhis-server should be probably also removed from
Debian, because it's unmaintained.  The upstream version 5.4 has been released
in 2008 and the package hasn't been updated since!

Ondrej

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmHuy7BfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcJx1A/+MkwRdeICIHwC687qoXOYZVaWq1DXPwPw4GG0t7Qj7q6kLU55gztc/cni
qzJJuroXyIWRY+cB/7dq7+dM3HU1xUBkJoprEN0Ns3/SvxVBTck9tHkfzpTy7Dqd
haID3kP35mxOyJoQwBI5AjH55UAsJbSUuA55YqCMXHTiaJWdPYppufSxiX0NS2jT
XXc2U9NY7MwBNLd78g7rwq914+8GY4++pD0G4G/qbJ+q6nowkKE/vOf52nlBEzEJ
5xIduQAvhrgl/UJdpIigKxImEW10mfD1+EVwKOK4vbRdKpxI912YsylYqKB3YA/X
WD4FsPEDS/k0P45tqBBKgTKnDEfn6c2v/Qk57qN/52Ttmjjpcs6Q0MDeSdx9K6Nb
QsykZpTj8E+v7jOofjmQKO++gGvlnA6ERDEoFCg2B2VBS1rTfzU9lWE6dCP7YAO0
JrQtQ+heMmxXXmGMdDdePhyrhc8pV5eO6mc6JL8ughIBArKKpML4LVhVu2jrqv4G
Gku1MIjpMPaSr/WaQJtRS+g6slX/3T5qYK+i77vPePi1v2A/uHFxZ/qw2PQDY3z+
tqavzGZZPeU2z4J1qS1mWq3Rur9floiDTlXHGmEDQYTov82sLRAvbi7kqQV9Fh2X
GfYg5EgdLBiVo9AeJ/Z8V1pPBIUeyHJombfwTOyYgwdbVCtSVkc=
=Kkzd
-END PGP SIGNATURE-

Bug#1004080: asterisk: Configuration files owned by asterisk user

[Johannes Drexl]

Am Donnerstag, dem 20.01.2022 um 16:17 +0100 schrieb Jonas Smedegaard:
> An obvious next step might be to try make the suggested change and
> see 
> if it still seems to work the same. Did you try that already, Drexl? 
> If not, can I ask you to try it?

Hi Jonas,

will do internally when I'm finding the time for it, but in a first
glance it seems only two files need being private (app_mysql.conf and I
think the extensions.conf), and probably none being written. 
Like said, will do. Thanks a lot in the meantime.

Kind regards,
Jo


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

Bug#1004304: argon2: FTBFS on kfreebsd

[Laurent Bigonville]

Source: argon2
Version: 0~20171227-0.2
Severity: important
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Hello,

argon2 currently FTBFS on kfreebsd

The attached patch fixes this, could you please apply it?

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
diff -Nru argon2-0~20171227/debian/patches/kfreebsd 
argon2-0~20171227/debian/patches/kfreebsd
--- argon2-0~20171227/debian/patches/kfreebsd   1970-01-01 01:00:00.0 
+0100
+++ argon2-0~20171227/debian/patches/kfreebsd   2022-01-24 16:44:42.0 
+0100
@@ -0,0 +1,11 @@
+--- a/Makefile
 b/Makefile
+@@ -58,7 +58,7 @@ BUILD_PATH := $(shell pwd)
+ KERNEL_NAME := $(shell uname -s)
+ 
+ LIB_NAME=argon2
+-ifeq ($(KERNEL_NAME), $(filter $(KERNEL_NAME),Linux GNU))
++ifeq ($(KERNEL_NAME), $(filter $(KERNEL_NAME),Linux GNU GNU/kFreeBSD))
+   LIB_EXT := so.$(ABI_VERSION)
+   LIB_CFLAGS := -shared -fPIC -fvisibility=hidden -DA2_VISCTL=1
+   SO_LDFLAGS := -Wl,-soname,lib$(LIB_NAME).$(LIB_EXT)
diff -Nru argon2-0~20171227/debian/patches/series 
argon2-0~20171227/debian/patches/series
--- argon2-0~20171227/debian/patches/series 2019-01-13 14:20:59.0 
+0100
+++ argon2-0~20171227/debian/patches/series 2022-01-24 16:42:44.0 
+0100
@@ -1 +1,2 @@
 hurd
+kfreebsd

Bug#1004303: raft-boltdb FTBFS with riscv

[Shengjing Zhu]

On Mon, Jan 24, 2022 at 11:39 PM Ileana Dumitrescu
 wrote:
>
> Package: golang-github-hashicorp-raft-boltdb
> Version: 0.0~git20171010.6e5ba93-3
> Tags: FTBFS
>
> raft-boltdb fails to build on riscv architecture. This package is dependent 
> on boltdb, which is incompatible with riscv. Example build log is shown 
> below. bbolt is an updated fork of boltdb that does support riscv, but 
> raft-boltdb has a build dependency on boltdb. I created an issue on the 
> raft-boltdb upstream github page 
> (https://github.com/hashicorp/raft-boltdb/issues/27). This FTBFS still occurs 
> with the latest upstream release 2.2.0. See #982931 for another package 
> impacted by this incompatibility with riscv.

Instead of asking upstream to fix building on riscv64 with boltdb,
just ask them to switch to github.com/etcd-io/bbolt(packaged as
golang-github-coreos-bbolt-dev).
boltdb is just dead, see
https://github.com/boltdb/bolt#a-message-from-the-author

-- 
Shengjing Zhu

Bug#1004293: warn users that src:webkit2gtk and src:khtml are insecure?

[Moritz Muehlenhoff]

On Tue, Jan 25, 2022 at 12:20:46AM +1100, Trent W. Buck wrote:
> Package: debian-security-support
> Version: 1:11+2021.03.19
> Severity: normal
> File: /usr/share/debian-security-support/security-support-limited
> 
> As at Debian 11,
> 
>   * webkitgtk is in src:webkit2gtk, not src:webkit.
>   * khtml is in src:khtml, not src:kde4libs.
> 
> GNOME3 and KDE5 have been around for a while now.
> I think security-support-limited should be updated to reflect this.

webkit2gtk is fully supported since Buster and there have been plenty of 
security updates since
then: https://security-tracker.debian.org/tracker/source-package/webkit2gtk

khtml should in fact be added, since it's AFAICT used by Konqueror.

Cheers,
Moritz

Bug#999824: ima-evm-utils: FTBFS because of the signature verification unit tests

[Bastian Germann]

Control: retitle -1 ima-evm-utils: FTBFS without extended attributes support

On Mon, 24 Jan 2022 13:36:00 +0100 Bastian Germann wrote:

Version 1.4 was imported but still fails to build from scratch on buildd 
because the unit tests for
that new feature do not run without gnutls-bin and softhsm2 installed as build 
dependencies.


The mentioned packages only enable tests that are currently skipped.
The failure reason is that extended attributes are unsupported on the build 
file system.
An easy solution would be disabling the test suite generally.

Bug#995171: need newer release

[Yaroslav Halchenko]

On Mon, 24 Jan 2022, Andreas Tille wrote:
> $ apt showsrc singularity-container | grep Uploaders
> Uploaders: Dave Love , Mehdi Dogguy , 
> Yaroslav Halchenko , Afif Elghraoui , 
> Dmitry Smirnov , Benda Xu 

> shows you as Uploader of singularity-container.  Is there any reason you
> file this bug report instead of simply uploading a new version of this
> package?

because it is maintained by the Debian HPC Team 
and I either did not have time or "foo" to update the packaging.  

And that is what I typically do even when working "by myself" - to
record relevant issues against corresponding project/package in that
project/package issue tracker.

> When doing so I'd recommend the following patch:


> diff --git a/debian/watch b/debian/watch
> index 140951c..e4f994d 100644
> --- a/debian/watch
> +++ b/debian/watch
> @@ -6,4 +6,4 @@ repacksuffix=+ds1,\
>  repack,compression=xz,\
>  dversionmangle=s{[+~](dfsg|ds)\d*}{},\
>  " https://github.com/sylabs/singularity/releases \
> -  (?:.*/)?singularity-(\d[\d\.]*)\.tar\.gz
> +  (?:.*/)?singularity-ce-(\d[\d\.]*)\.tar\.gz

cool -- applied


> I admit I've never used singularity before but this might change in the
> near future.  

I hope so -- singularity is current bread for containerized
computing in scientific context.

> Thus I'm wondering why we have 4 open bugs with CVE
> numbers and are lagging several versions behind upstream.  May be there
> is a good reason to stick to the outdated security problematic version
> which I simply do not understand?

shortage of time/ppl?

I have started to update packaging for 3.9.4+ds1 but got stuck on
updating the 2nd patch which seems "too involved" for a go-ignorant me.
Any help would be welcomed.  I have pushed update of source tree etc

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Bug#987156: Acknowledgement (mod_ssl depends on mod_setenvif while it does not)

[MichaIng]

Huh, what spam bot made it in here?

However,

@Stefan as I see MS Internet Explorer support being dropped by more and 
more projects, do you agree to have the MSIE [2-6] comment blocks simply 
removed, together with the mod_setenvif dependency? If so, let me know 
and I can send a merge request, in case the repo link in my last post is 
okay.


Best regards,

Micha

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Zack Weinberg]

As an end user I wish to register an objection to any solution to this bug that 
makes it impossible for me to install a Debian system where, out of the box, 
"rename" in the default PATH is the Perl rename.  This is what my fingers 
expect, and what dozens of non-packaged scripts rely on.

(I say "the default PATH" and "out of the box" because I _can_ always put a 
symlink in $HOME/.local/bin or /usr/local/bin, regardless of what packages do, 
but that's an extra step that may not be tracked by configuration management 
and may not apply to all processes.)

I recognize that there are people coming to Debian from environments where 
there is precisely the opposite expectation, but I think backward compatibility 
with the environment Debian has provided for many years is, in this case, more 
important.

zw

Bug#995171: need newer release

[Andreas Tille]

Hi Yaroslav,

Am Mon, Jan 24, 2022 at 10:11:21AM -0500 schrieb Yaroslav Halchenko:
> 
> >  " https://github.com/sylabs/singularity/releases \
> > -  (?:.*/)?singularity-(\d[\d\.]*)\.tar\.gz
> > +  (?:.*/)?singularity-ce-(\d[\d\.]*)\.tar\.gz
> 
> cool -- applied

:-)
 
> > Thus I'm wondering why we have 4 open bugs with CVE
> > numbers and are lagging several versions behind upstream.  May be there
> > is a good reason to stick to the outdated security problematic version
> > which I simply do not understand?
> 
> shortage of time/ppl?

OK, just wanted to make sure there is no technical reason.
 
> I have started to update packaging for 3.9.4+ds1 but got stuck on
> updating the 2nd patch which seems "too involved" for a go-ignorant me.
> Any help would be welcomed.  I have pushed update of source tree etc

I might have a look once I get permissions to push directly.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#1004302: mmdebstrap: Unable to specify APT pinning (via Dir::Etc::preferencesparts)

[Benjamin Drung]

Package: mmdebstrap
Version: 0.7.5-2.2
Severity: normal

Hi,

I want to use mmdebstrap combined with APT pinning in a consistent way
(i.e. that mmdebstrap behaves the same in normal and dry-run mode), but
I failed to do so. To demonstrate the issue, I constructed a simple test
case: This test case defines bullseye and bookworm as mirrors and has an
APT pinning config to set the priority of bookworm packages below the
priority of bullseye packages. Without the pinning, the bookworm
packages will be newer and installed. With pinning, the bullseye
packages will be installed instead. Then install the package
`python3-minimal` from bullseye and let APT select the package version
for `python3`. Both packages need to be installed from the same release.
Otherwise APT will complain. That way the used pinning can be tested.

APT pinning is configured in `/etc/apt/preferences` and
`/etc/apt/preferences.d`. The location can be configured with the
settings `Dir::Etc::preferences` and `Dir::Etc::preferencesparts`. In
the test case, I am setting `Dir::Etc::preferencesparts`.

APT pinning `preferences.d/bookworm.pref`:

```
Package: *
Pin: release l=Debian,n=bookworm
Pin-Priority: 400
```

Here is the `pinning.yaml` configuration as YAML file for bdebstrap:

```
---
mmdebstrap:
  aptopts:
- Dir::Etc::preferencesparts "$CURDIR/preferences.d/"
  essential-hooks:
- copy-in preferences.d/bookworm.pref /etc/apt/preferences.d
  keyrings:
- /usr/share/keyrings/debian-archive-keyring.gpg
  mirrors:
- deb http://deb.debian.org/debian bullseye main
- deb http://deb.debian.org/debian bookworm main
  packages:
- python3-minimal/bullseye
- python3
  suite: bullseye
  target: root.tar
  variant: minbase
name: pinning-example
```

You have to set `$CURDIR` in the example above to the absolute path of your
current working directory.

1) If I specify a relative directory in `Dir::Etc::preferencesparts`, the
configuration is ignored.

2) If I set `Dir::Etc::preferencesparts` to an absolute path, it works in
`--dry-run`, but fails in the normal mode:

```
I: installing remaining packages inside the chroot...
Reading package lists...
Building dependency tree...
mawk is already the newest version (1.3.4.20200120-2).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python3 : PreDepends: python3-minimal (= 3.9.7-1) but 3.9.2-3 is to be 
installed
   Depends: python3.9 (>= 3.9.7-0~) but it is not going to be installed
   Depends: libpython3-stdlib (= 3.9.7-1) but it is not going to be 
installed
W: Unable to read /home/user/path/to/preferences.d/ - DirectoryExists (2: No 
such file or directory)
```

I tested this in a minimal Debian schroot:

```
apt -y install mmdebstrap
mkdir -p preferences.d
printf 'Package: *\nPin: release l=Debian,n=bookworm\nPin-Priority: 400\n' > 
preferences.d/bookworm.pref
mmdebstrap -v --variant=minbase \
  --aptopt="Dir::Etc::preferencesparts \"$(pwd)/preferences.d/\"" \
  --include=python3-minimal/bullseye,python3 \
  --essential-hook="copy-in preferences.d/bookworm.pref /etc/apt/preferences.d" 
\
  bullseye root.tar \
  "deb http://deb.debian.org/debian bullseye main" \
  "deb http://deb.debian.org/debian bookworm main"
```

It fails on a Debian bullseye schroot, but succeeds on an unstable
schroot. Since the mmdebstrap version from unstable needs a newer APT
version, there is no easy way for backporting.

Is setting `Dir::Etc::preferencesparts` to an absolute path the way to
go forward? In this case it would be nice if I could set
`Dir::Etc::preferencesparts` to something like "$CURDIR/preferences.d/"
and let mmdebstrap resolve it to the absolute path.

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations Cloud

IONOS SE | Revaler Str. 30 | 10245 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Britta Schmidt, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet

Bug#1004300: linux-image-5.15.0-3-amd64: firmware-iwlwifi and reported kernel doesn't work

[Diederik de Haas]

On maandag 24 januari 2022 15:38:01 CET Daniel wrote:
> *** Reporter, please consider answering these questions, where appropriate
> ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***

Could you fill in the above template so we'll have more information to help 
you? 
"Doesn't work" isn't much to go on and the kernel log included in the bug
report seems to indicate a successful wireless connection:

> [   24.900350] wlo1: authenticate with 02:09:c1:90:4a:10
> [   24.903768] wlo1: send auth to 02:09:c1:90:4a:10 (try 1/3)
> [   24.948852] wlo1: authenticated
> [   24.949316] wlo1: associate with 02:09:c1:90:4a:10 (try 1/3)
> [   24.953015] wlo1: RX AssocResp from 02:09:c1:90:4a:10 (capab=0x1131 
> status=0 aid=1)
> [   24.972100] wlo1: associated
> [   25.041391] wlo1: Limiting TX power to 14 (14 - 0) dBm as advertised by 
> 02:09:c1:90:4a:10
> [   25.041487] IPv6: ADDRCONF(NETDEV_CHANGE): wlo1: link becomes ready


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

Bug#1003972: Acknowledgement (libphonenumber: New upstream release - please update)

[Neil Mayhew]

It may be helpful to have a brief summary of the main problem that's 
being fixed.


Previously, the C/C++ version of libphonenumber was accepting and 
parsing phone numbers that have malformed UTF-8 sequences in them, by 
converting the offending bytes to spaces. It now rejects the input 
instead of returning a phone number, which the Java version has always 
done. Accepting malformed UTF-8 is a potential security issue.


libphonenumber was also accepting well-formed input containing invalid 
code points like U+0096 (a C1 control character) which can be the result 
of a bad conversion from Windows 1252 legacy encoding where N DASH 
(U+2013) is represented by \x96. If the legacy text is treated as 
iso-8859-1 instead of windows-1252, \x96 will be converted to U+0096 
instead of U+2013. This type of input is now rejected as well.

Bug#1004301: App force-closes with backtrace when selecting camera

[Lee Garrett]

Package: qtqr
Version: 2.0~bzr33-2
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

the issue I'm seeing seems superficially related to #961503. When I start the
application, pick "Decode from webcam", there are two webcams (with identical
name and ID) listed. Picking the bottom one will crash the application and
create a backtrace:

$ qtqr 
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
QT_QPA_PLATFORM=wayland to run on Wayland anyway.
Traceback (most recent call last):
  File "/usr/bin/qtqr", line 834, in decodeWebcam
qr.decode_webcam(device=device)
  File "/usr/lib/python3/dist-packages/qrtools.py", line 240, in decode_webcam
proc.init(device)
zbar.UnsupportedError: 
Aborted


I've already tried the version in backports, but the issue is the same there.

Regards,
Lee


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

Kernel: Linux 5.16.1 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages qtqr depends on:
ii  python3  3.9.2-3
ii  python3-pyqt55.15.2+dfsg-3
ii  python3-qrtools  2.0~bzr33-2

qtqr recommends no packages.

qtqr suggests no packages.

-- no debconf information

Bug#1002210: adapt: diff for NMU version 1.0.0-1.1

[Adrian Bunk]

Control: tags 1002210 + patch
Control: tags 1002210 + pending

Dear maintainer,

I've prepared an NMU for adapt (versioned as 1.0.0-1.1) and uploaded
it to DELAYED/15. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru adapt-1.0.0/debian/changelog adapt-1.0.0/debian/changelog
--- adapt-1.0.0/debian/changelog	2021-11-21 20:15:54.0 +0200
+++ adapt-1.0.0/debian/changelog	2022-01-24 16:42:31.0 +0200
@@ -1,3 +1,10 @@
+adapt (1.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add the missing build dependency on python3-six. (Closes: #1002210)
+
+ -- Adrian Bunk   Mon, 24 Jan 2022 16:42:31 +0200
+
 adapt (1.0.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru adapt-1.0.0/debian/control adapt-1.0.0/debian/control
--- adapt-1.0.0/debian/control	2021-07-08 18:39:16.0 +0300
+++ adapt-1.0.0/debian/control	2022-01-24 16:42:31.0 +0200
@@ -2,7 +2,7 @@
 Section: python
 Priority: optional
 Maintainer: Wouter Verhelst 
-Build-Depends: debhelper-compat (= 13), dh-python, python3-setuptools, python3-all
+Build-Depends: debhelper-compat (= 13), dh-python, python3-setuptools, python3-all, python3-six
 Standards-Version: 4.5.1
 Homepage: https://github.com/MycroftAI/adapt
 Vcs-Browser: https://salsa.debian.org/mycroftai-team/adapt

Bug#1004300: linux-image-5.15.0-3-amd64: firmware-iwlwifi and reported kernel doesn't work

[Daniel]

Package: src:linux
Version: 5.15.5-3
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
** Version:
Linux version 5.15.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.2.0-13) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Debian 
5.15.5-3 (2021-12-18)

** Command line:
BOOT_IMAGE=/vmlinuz-5.15.0-3-amd64 
root=UUID=012e01a2-d5f1-45f7-b19f-840a969372bd ro quiet

** Not tainted

** Kernel log:
[5.216255] caller snb_uncore_imc_init_box+0x78/0xc0 [intel_uncore] mapping 
multiple BARs
[5.246261] iTCO_wdt iTCO_wdt.1.auto: Found a Panther Point TCO device 
(Version=2, TCOBASE=0x0460)
[5.246479] iTCO_wdt iTCO_wdt.1.auto: initialized. heartbeat=30 sec 
(nowayout=0)
[5.389822] usb 1-1.3: Found UVC 1.00 device HP HD Webcam [Fixed] (0461:4dfd)
[5.403911] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 163840 ms 
ovfl timer
[5.403917] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules
[5.403918] RAPL PMU: hw unit of domain package 2^-16 Joules
[5.403920] RAPL PMU: hw unit of domain pp1-gpu 2^-16 Joules
[5.469699] cryptd: max_cpu_qlen set to 1000
[5.472684] iwlwifi :24:00.0: CONFIG_IWLWIFI_DEBUG disabled
[5.472689] iwlwifi :24:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[5.472691] iwlwifi :24:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[5.472693] iwlwifi :24:00.0: Detected Intel(R) Centrino(R) Advanced-N 
6205 AGN, REV=0xB0
[5.516498] snd_hda_intel :00:1b.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[5.520606] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
discard. Quota mode: none.
[5.543210] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[5.569335] AVX version of gcm_enc/dec engaged.
[5.569367] AES CTR mode by8 optimization enabled
[5.613327] snd_hda_codec_idt hdaudioC0D0: autoconfig for 92HD81B1X5: 
line_outs=1 (0xa/0x0/0x0/0x0/0x0) type:line
[5.613335] snd_hda_codec_idt hdaudioC0D0:speaker_outs=1 
(0xd/0x0/0x0/0x0/0x0)
[5.613338] snd_hda_codec_idt hdaudioC0D0:hp_outs=1 (0xb/0x0/0x0/0x0/0x0)
[5.613341] snd_hda_codec_idt hdaudioC0D0:mono: mono_out=0x0
[5.613342] snd_hda_codec_idt hdaudioC0D0:inputs:
[5.613344] snd_hda_codec_idt hdaudioC0D0:  Mic=0xc
[5.613346] snd_hda_codec_idt hdaudioC0D0:  Internal Mic=0x11
[5.613348] snd_hda_codec_idt hdaudioC0D0:  Line=0xf
[5.637481] iwlwifi :24:00.0 wlo1: renamed from wlan0
[5.700631] input: HP HD Webcam [Fixed]: HP HD Web as 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input17
[5.700904] usbcore: registered new interface driver uvcvideo
[5.741961] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/sound/card0/input16
[5.742037] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input18
[5.742104] input: HDA Intel PCH Line as 
/devices/pci:00/:00:1b.0/sound/card0/input19
[5.742184] input: HDA Intel PCH Dock Line Out as 
/devices/pci:00/:00:1b.0/sound/card0/input20
[5.742289] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card0/input21
[5.742354] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1b.0/sound/card0/input22
[5.742668] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1b.0/sound/card0/input23
[5.743599] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1b.0/sound/card0/input24
[6.246502] Bluetooth: Core ver 2.22
[6.246546] NET: Registered PF_BLUETOOTH protocol family
[6.246548] Bluetooth: HCI device and connection manager initialized
[6.246554] Bluetooth: HCI socket layer initialized
[6.246558] Bluetooth: L2CAP socket layer initialized
[6.246562] Bluetooth: SCO socket layer initialized
[6.273556] usbcore: registered new interface driver btusb
[6.301945] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b 
lmp_ver=0a lmp_subver=8761
[6.303936] Bluetooth: hci0: RTL: rom_version status=0 version=1
[6.303942] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin
[6.305489] bluetooth hci0: firmware: direct-loading firmware 
rtl_bt/rtl8761bu_fw.bin
[6.305512] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin
[6.305675] bluetooth hci0: firmware: direct-loading firmware 
rtl_bt/rtl8761bu_config.bin
[6.305692] Bluetooth: hci0: RTL: cfg_sz 6, total sz 20522
[6.415927] Bluetooth: hci0: RTL: fw version 0x0999646b
[6.649256] F2FS-fs (mmcblk0p1): Mounted with checkpoint version = 1aafbc34
[6.669457] intel_rapl_common: Found RAPL domain 

Bug#1004299: ruby-net-ssh: FTBFS in sid

[Cédric Boutillier]

Package: ruby-net-ssh
Version: 1:6.1.0-2

Hi,

When trying to rebuild ruby-net-ssh in sid, I get test failures related
to DSA cryptography. They all have the message: 
OpenSSL:PKey::DSAError: bad sig size


Hopefully, this is the relevant part. Full log attached

Finished in 4.013999s, 372.1974 runs/s, 1244.6442 assertions/s.

  1) Error:
Authentication::TestAgent#test_add_dsa_cert_identity:
OpenSSL::PKey::DSAError: bad sig size
/<>/lib/net/ssh/transport/openssl.rb:115:in `ssh_do_sign'
/<>/lib/net/ssh/authentication/certificate.rb:91:in `sign!'
/<>/test/authentication/test_agent.rb:414:in `make_cert'
/<>/test/authentication/test_agent.rb:273:in 
`test_add_dsa_cert_identity'

  2) Error:
Authentication::TestKeyManager#test_each_identity_should_load_from_implicit_cert_file:
OpenSSL::PKey::DSAError: bad sig size
/<>/lib/net/ssh/transport/openssl.rb:115:in `ssh_do_sign'
/<>/lib/net/ssh/authentication/certificate.rb:91:in `sign!'
/<>/test/authentication/test_key_manager.rb:320:in `rsa_cert'
/<>/test/authentication/test_key_manager.rb:76:in 
`test_each_identity_should_load_from_implicit_cert_file'

  3) Error:
Authentication::TestKeyManager#test_each_identity_should_ignore_explicit_cert_file_unless_matching_key_is_avaiable:
OpenSSL::PKey::DSAError: bad sig size
/<>/lib/net/ssh/transport/openssl.rb:115:in `ssh_do_sign'
/<>/lib/net/ssh/authentication/certificate.rb:91:in `sign!'
/<>/test/authentication/test_key_manager.rb:320:in `rsa_cert'
/<>/test/authentication/test_key_manager.rb:104:in 
`test_each_identity_should_ignore_explicit_cert_file_unless_matching_key_is_avaiable'

  4) Error:
Authentication::TestKeyManager#test_each_identity_should_load_from_explicit_cert_file_given_matching_key_is_loaded:
OpenSSL::PKey::DSAError: bad sig size
/<>/lib/net/ssh/transport/openssl.rb:115:in `ssh_do_sign'
/<>/lib/net/ssh/authentication/certificate.rb:91:in `sign!'
/<>/test/authentication/test_key_manager.rb:320:in `rsa_cert'
/<>/test/authentication/test_key_manager.rb:88:in 
`test_each_identity_should_load_from_explicit_cert_file_given_matching_key_is_loaded'

  5) Error:
Authentication::TestKeyManager#test_each_identity_should_match_explicit_keycert_with_agent_provided_identity:
OpenSSL::PKey::DSAError: bad sig size
/<>/lib/net/ssh/transport/openssl.rb:115:in `ssh_do_sign'
/<>/lib/net/ssh/authentication/certificate.rb:91:in `sign!'
/<>/test/authentication/test_key_manager.rb:320:in `rsa_cert'
/<>/test/authentication/test_key_manager.rb:141:in 
`test_each_identity_should_match_explicit_keycert_with_agent_provided_identity'

  6) Error:
Authentication::TestKeyManager#test_sign_with_agent_originated_key_should_be_signable_through_explicitly_loaded_cert:
OpenSSL::PKey::DSAError: bad sig size
/<>/lib/net/ssh/transport/openssl.rb:115:in `ssh_do_sign'
/<>/lib/net/ssh/authentication/certificate.rb:91:in `sign!'
/<>/test/authentication/test_key_manager.rb:320:in `rsa_cert'
/<>/test/authentication/test_key_manager.rb:218:in 
`test_sign_with_agent_originated_key_should_be_signable_through_explicitly_loaded_cert'

1494 runs, 4996 assertions, 0 failures, 6 errors, 0 skips
rake aborted!
Command failed with status (1): [ruby -w 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb
 "test/test_all.rb" "test/test_buffer.rb" "test/test_buffered_io.rb" 
"test/test_config.rb" "test/test_key_factory.rb" "test/test_known_hosts.rb" 
"test/test_proxy_jump.rb" -v]
/usr/share/rubygems-integration/all/gems/rake-13.0.6/exe/rake:27:in `'
Tasks: TOP => default
(See full trace by running task with --trace)
ERROR: Test "ruby3.0" failed. Exiting.
dh_auto_install: error: dh_ruby --install /<>/debian/ruby-net-ssh 
returned exit code 1
make: *** [debian/rules:7: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Source: ruby-net-ssh
Version: 1:6.1.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

ruby-net-ssh_6.1.0-2_amd64-2022-01-24T13:24:15Z.build.gz
Description: application/gzip


signature.asc
Description: signature

Bug#1004298: iotjs: 8 new CVEs 2022-22892 to 2022-2292

[Neil Williams]

Source: iotjs
Version: 1.0+715-1
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerabilities were published for iotjs.

CVE-2022-22895[0]:
| Jerryscript 3.0.0 was discovered to contain a heap-buffer-overflow via
| ecma_utf8_string_to_number_by_radix in /jerry-core/ecma/base/ecma-
| helpers-conversion.c.


CVE-2022-22894[1]:
| Jerryscript 3.0.0 was discovered to contain a stack overflow via
| ecma_lcache_lookup in /jerry-core/ecma/base/ecma-lcache.c.


CVE-2022-22893[2]:
| Jerryscript 3.0.0 was discovered to contain a stack overflow via
| vm_loop.lto_priv.304 in /jerry-core/vm/vm.c.


CVE-2022-22892[3]:
| There is an Assertion 'ecma_is_value_undefined (value) ||
| ecma_is_value_null (value) || ecma_is_value_boolean (value) ||
| ecma_is_value_number (value) || ecma_is_value_string (value) ||
| ecma_is_value_bigint (value) || ecma_is_value_symbol (value) ||
| ecma_is_value_object (value)' failed at jerry-core/ecma/base/ecma-
| helpers-value.c in Jerryscripts 3.0.0.


CVE-2022-22891[4]:
| Jerryscript 3.0.0 was discovered to contain a SEGV vulnerability via
| ecma_ref_object_inline in /jerry-core/ecma/base/ecma-gc.c.


CVE-2022-22890[5]:
| There is an Assertion 'arguments_type != SCANNER_ARGUMENTS_PRESENT
|  arguments_type != SCANNER_ARGUMENTS_PRESENT_NO_REG' failed
| at /jerry-core/parser/js/js-scanner-util.c in Jerryscript 3.0.0.


CVE-2022-22888[6]:
| Jerryscript 3.0.0 was discovered to contain a stack overflow via
| ecma_op_object_find_own in /ecma/operations/ecma-objects.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-22895
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22895
[1] https://security-tracker.debian.org/tracker/CVE-2022-22894
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22894
[2] https://security-tracker.debian.org/tracker/CVE-2022-22893
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22893
[3] https://security-tracker.debian.org/tracker/CVE-2022-22892
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22892
[4] https://security-tracker.debian.org/tracker/CVE-2022-22891
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22891
[5] https://security-tracker.debian.org/tracker/CVE-2022-22890
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22890
[6] https://security-tracker.debian.org/tracker/CVE-2022-22888
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22888

Please adjust the affected versions in the BTS as needed.



-- 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.0-2-amd64 (SMP w/16 CPU threads)
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

Bug#1004297: libpcsclite1: SCardConnect is blocking but not cancellable

[Ievgenii Meshcheriakov]

Package: libpcsclite1
Version: 1.9.5-1
Severity: normal
X-Debbugs-Cc: eu...@debian.org

ScardConnect() call is blocking when another process has started a transaction
on the same card, but it is impossible to cancel it using SCardCancel().
This makes it harder to use the library reliably in an asynchronous manner.

I'm attaching source code that demonstrates the problem. After building it
run 'cardlock' executable followed by 'cardlock_cancel' in a different
terminal. A card should be in the used card reader. Both executables accept
reader ID as arguments. My expectation is that 'cardlock_cancel' could exit
after 5 second sleep, but it does not.

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

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

Versions of packages libpcsclite1 depends on:
ii  libc6  2.33-3

libpcsclite1 recommends no packages.

Versions of packages libpcsclite1 suggests:
ii  pcscd  1.9.5-1

-- no debconf information


cardlock.tar.gz
Description: application/gzip

Bug#1004296: smart-notifier: Provide a filter mechanism

[Stefano Rivera]

Package: smart-notifier
Version: 0.28-8
Severity: normal
Tags: upstream

Due to #900244, smart-notifier makes a lot of noise for NVMe devices,
which are the norm these days.

It would be nice to be able to filter these out. If smartd doesn't have
a filter, then smart-notifier should.

SR

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 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 smart-notifier depends on:
ii  dbus1.12.20-3
ii  gir1.2-gtk-3.0  3.24.31-1
ii  python3 3.9.8-1
ii  python3-dbus1.2.18-3+b1
ii  python3-gi  3.42.0-3
ii  smartmontools   7.2-1

smart-notifier recommends no packages.

smart-notifier suggests no packages.

-- no debconf information

Bug#1004295: pagekite: Please consider new upstream version

[Timo Lindfors]

Package: pagekite
Version: 1.5.2.200603-2
Severity: wishlist

I tried using pagekite 1.5.2.200603-2 that comes with Debian 11. My 
configuration was a simple server with only one configuration file 
/etc/pagekite.d/10_account.rc:


kitename   = *.pagekite.myexamplecorp.com
kitesecret = CENSORED
isfrontend
ports = 1080
protos = raw
rawports = virtual
domain = raw:*.myexamplecorp.com:CENSORED
END

This configuration worked fine in Debian 9 but does not seem to work with 
Debian 11. After a long debugging session I noticed that I can get the 
service to work with the following patch


diff -ur ./fixed/pagekite/proto/conns.py 
./pagekite-1.5.2.200603/pagekite/proto/conns.py
--- ./fixed/pagekite/proto/conns.py 2022-01-24 15:22:36.959163732 +0200
+++ ./pagekite-1.5.2.200603/pagekite/proto/conns.py 2020-06-04 
02:37:39.0 +0300
@@ -1975,8 +1975,8 @@
 data = None
   try:
 if data:
-  if b'\nHost: ping.pagekite' in data:
-client.send(self.rejection.encode("utf-8"))
+  if '\nHost: ping.pagekite' in data:
+client.send(self.rejection)
 client.close()
 self.fast_pinged.append(obfuIp(addr[0]))
   else:
diff -ur ./fixed/pagekite/proto/selectables.py 
./pagekite-1.5.2.200603/pagekite/proto/selectables.py
--- ./fixed/pagekite/proto/selectables.py   2022-01-24 15:20:40.061914811 
+0200
+++ ./pagekite-1.5.2.200603/pagekite/proto/selectables.py   2020-06-04 
02:37:39.0 +0300
@@ -344,7 +344,7 @@
   def EatPeeked(self, eat_bytes=None, keep_peeking=False):
 if not self.peeking: return
 if eat_bytes is None: eat_bytes = self.peeked
-discard = b''
+discard = ''
 while len(discard) < eat_bytes:
   try:
 bytecount = eat_bytes - len(discard)

I then noticed that these fixes have been in the upstream git already in 
2020 (for example in commit 716b7f57102e2a21b8a76154a7885af3b3ed602e) but 
they just have not released a new version.


Would it be possible to package a new upstream version? Current version 
does not seem to only work as a client with the SaaS server, you cannot 
run your own server :(


best regards,
Timo Lindfors

Bug#1004229: [debian-mysql] Bug#1004229: default-mysql-server-core and mariadb-server don't agree on default

[Paul Gevers]

Hi Otto,

On 23-01-2022 23:41, Otto Kekäläinen wrote:

With mariadb-10.6 migrated to testing, I was expecting to see it
installed on my bookworm system today. However, it turns out that the
version of mariadb on my system is determined by
default-mysql-server-core. I think both packages should agree on what
the default mariadb version is.


Thanks for reminding us about this.

I've committed the fix in
https://salsa.debian.org/mariadb-team/mysql/-/commits/mysql-defaults/debian/master
and will wait for a few days for review or additional improvements to
mysql-defaults before uploading a new version.


Shouldn't it just point to the unversioned packages? No reason to define 
the default in two places.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004293: Acknowledgement (warn users that src:webkit2gtk and src:khtml are insecure?)

[Trent W. Buck]

As discussed in IRC, here's a rough draft patch.
I haven't actually, like, built a .deb and installed it and run the script 
(sorry).
>From 501e9a6653c86fb59eceffdc6bdcc320691b8604 Mon Sep 17 00:00:00 2001
From: "Trent W. Buck" 
Date: Tue, 25 Jan 2022 00:38:23 +1100
Subject: [PATCH] Warn people about khtml and webkit2gtk (Closes: #773387,
 #1004293)

---
 debian/changelog | 7 +++
 security-support-limited | 9 +
 2 files changed, 16 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 2a828a1..dc19574 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+debian-security-support (1:12+2021.12.09) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Warn people about khtml and webkit2gtk (Closes: #773387, #1004293)
+
+ -- Trent W. Buck   Tue, 25 Jan 2022 00:37:16 +1100
+
 debian-security-support (1:12+2021.12.08) unstable; urgency=medium
 
   [ Sylvain Beucler ]
diff --git a/security-support-limited b/security-support-limited
index bebda1c..7e9c7ad 100644
--- a/security-support-limited
+++ b/security-support-limited
@@ -6,13 +6,19 @@
 # 2. Descriptive text or URL with more details (optional)
 #In the program's output, this is prefixed with "Details:"
 
+# See also:
+# https://www.debian.org/releases/bullseye/arm64/release-notes/ch-information.en.html#limited-security-support
+
 adnsStub resolver that should only be used with trusted recursors
 binutilsOnly suitable for trusted content; see https://lists.debian.org/msgid-search/87lfqsomtg@mid.deneb.enyo.de
 cython  Only included for building packages, not running them, #975058
 ganglia See README.Debian.security, only supported behind an authenticated HTTP zone, #702775
 ganglia-web See README.Debian.security, only supported behind an authenticated HTTP zone, #702776
 golang.*See https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#golang-static-linking
+# Debian 10 and earlier?
 kde4libskhtml has no security support upstream, only for use on trusted content
+# Debian 9 and later?
+khtml   khtml has no security support upstream, only for use on trusted content
 libv8-3.14  Not covered by security support, only suitable for trusted content
 mozjs   Not covered by security support, only suitable for trusted content
 mozjs24 Not covered by security support, only suitable for trusted content
@@ -28,5 +34,8 @@ qtwebkitNo security support upstream and backports not feasible, only fo
 qtwebkit-opensource-src No security support upstream and backports not feasible, only for use on trusted content
 sql-ledger  Only supported behind an authenticated HTTP zone
 swftoolsNot covered by security support, only suitable for trusted content
+# Debian 9 and earlier
 webkitgtk   No security support upstream and backports not feasible, only for use on trusted content
+# Debian 8 and later
+webkit2gtk  No security support upstream and backports not feasible, only for use on trusted content
 zoneminder  See README.Debian.security, only supported behind an authenticated HTTP zone, #922724
-- 
2.30.2

Bug#1004180: [debian-mysql] Bug#1004180: mysql-8.0: should mysql-8.0 be removed from unstable?

[Robie Basak]

On Sat, Jan 22, 2022 at 10:53:48AM +0100, Salvatore Bonaccorso wrote:
> While mysql-8.0 itself won't enter testing, the version in unstable is
> as well only from february 2021, lacking behind several updates for
> fixes in the Oracle CPUs.
> 
> Should mysql-8.0 be removed as well from unstable?

FWIW, we started a renewed effort to catch up and stay caught up - for
example I cherry-picked a fix to the master branch in Salsa recently,
and further picks from Ubuntu to catch up security-wise should be coming
soon.

So hopefully we'll be doing much better soon.


signature.asc
Description: PGP signature

Bug#1004294: libinsighttoolkit5.2: ITKReview module is not built

[Flavien BRIDAULT-LOUCHEZ]

Package: libinsighttoolkit5.2
Version: 5.2
Severity: wishlist

Dear Maintainer,

When upgrading sight package to use libinsightoolkit5.2 instead of
libinsighttoolkit4, it became impossible to build one of our filter
that uses the header itkLabelGeometryImageFilter.h. 

This file was moved in ITK5 in the module ITKReview, which is not built
by default. Could you consider enabling this module ? Other People might 
want to test the filters available in this module.

You can find details about this module here:
- https://itk.org/Doxygen/html/group__ITKReview.html

Thank you.

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

Kernel: Linux 5.13.0-25-generic (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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#946683: nokogumbo has been merged into nokogiri

[Cédric Boutillier]

Hi,

It seems that since nokogiri 1.12, the functionalities of nokogumbo have
been merged into nokogiri. html-proofer does not depend on nokogumbo
anymore, and uses nokogiri >=1.12.

It seems reasonable to upgrade nokogiri (I am trying to do it), make all
packages depending on ruby-nokogumbo to switch to nokogiri if it is not
already the case, and then remove nokogumbo.

Best wishes,

Cédric

signature.asc
Description: signature

Bug#1004293: warn users that src:webkit2gtk and src:khtml are insecure?

[Trent W. Buck]

Package: debian-security-support
Version: 1:11+2021.03.19
Severity: normal
File: /usr/share/debian-security-support/security-support-limited

As at Debian 11,

  * webkitgtk is in src:webkit2gtk, not src:webkit.
  * khtml is in src:khtml, not src:kde4libs.

GNOME3 and KDE5 have been around for a while now.
I think security-support-limited should be updated to reflect this.

These libraries are used by, for example, yelp and khelpcenter.
This means this fix will make check-security-support whinge at most GUI users,
the way it already does for needrestart users (#986507).

(I think this is a good thing.
There's really no reason yelp and khelpcenter need to JIT compile 
docbook/mallard to HTML and then embed a custom browser engine.
Get rid of them, render the HTML when the .deb is built, and just run the 
user's normal, security-supported browser.)

Note that someone already reported the khtml issue way back in Debian 7 
(#773387), but it was marked as blocked because
(paraphrasing) "KDE4 libraries are a mess and we'd end up with false positives 
for EVERY library in KDE" (#765452).
This is substantially improved in KDE5, and (AFAICT) should no longer block 
"correctly report src:khtml is insecure crap".



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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 debian-security-support depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  gettext-base   0.21-4

debian-security-support recommends no packages.

debian-security-support suggests no packages.

-- debconf information:
  debian-security-support/earlyend:
  debian-security-support/ended:
  debian-security-support/limited:

Bug#598434: bind9: Improve detection and handling of recursive 'include' statements in configuration files

[Ondřej Surý]

Package: bind9
Version: 1:9.17.21-1+0~20211215.67+debian11~1.gbp8acaec
Followup-For: Bug #598434
Control: close -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

this has been filled against a version of BIND 9 no longer in Debian.

In any case, hardcoding "100" files is not a very good idea anyway, so I am just
going to close the issue as we are not going to apply the patch anyway.

A better patch (f.e. that would keep the track of already included files) would
be fine to submit for inclusion in upstream.  But with my upstream hat, I am
saying that no solution that would hardcode number of files that could be open
would be accepted upstream.  Especially, in a situation that OOM killer would
solve the situation for you and this is not a mistake you do every other day.

Ondrej

- -- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-10-amd64 (SMP w/24 CPU threads)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bind9 depends on:
ii  adduser3.118
ii  bind9-libs 1:9.17.21-1+0~20211215.67+debian11~1.gbp8acaec
ii  bind9-utils1:9.17.21-1+0~20211215.67+debian11~1.gbp8acaec
ii  debconf [debconf-2.0]  1.5.77
ii  dns-root-data  2021011101
ii  iproute2   5.10.0-4
ii  libc6  2.31-13+deb11u2
ii  libcap21:2.44-1
ii  libfstrm0  0.6.0-1+b1
ii  libjson-c5 0.15-2
ii  liblmdb0   0.9.24-1+0~20200325.6+debian10~1.gbpfd112d
ii  libmaxminddb0  1.5.2-1
ii  libnghttp2-14  1.43.0-1
ii  libprotobuf-c1 1.3.3-1+b2
ii  libssl1.1  1.1.1k-1+deb11u1
ii  libuv1 1.40.0-2
ii  libxml22.9.12+dfsg-0+0~20210621.9+debian11~1.gbp43e861
ii  lsb-base   11.1.0
ii  netbase6.3
ii  zlib1g 1:1.2.11.dfsg-2

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind-doc   
ii  bind9-dnsutils [dnsutils]  1:9.17.21-1+0~20211215.67+debian11~1.gbp8acaec
pn  resolvconf 
pn  ufw

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmHups5fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcLKIA//efbTHlMbU5h+TDrDKfyqvvpQNkkaHdW2bKTubQN975CmpLQqU+GaPKVS
ifKU3Q5uB8E4CwKTyZuGkRJr8gqX2BCQdxXyE/ZfvN22uKznyvuZBVC8H7n6fXDR
Y4cO4lgYhTkqyILe66VtIc9EZnXeZsyD/UktqDHd+YoTXIwpomM6g3XsfSoLV9hb
eZOoQb9rRF/b272PFAqJyrNG0L2uuYg1pfS76pOy2T8W3nhYsbGhGsGcWxldMNO6
wEiGFzj0gTuCjf+v0w4V84LW/LElFaDSrXDqcdyUlv5LZJ9RuDALUCf15Zwy+dio
Mg6fCQXPW4Bc5h9OV0nO/FLlVLk+PLD3L2+0yXywwxayX/0KYK/dENB1Bl6R1pWa
fe1AsWhe3OD+D81van+J+mwjIfhqH0JSsJbm2KXBZAead8GlyoMvhtFuiSGwbCrn
7RMbm6k/sH0MaiULo9x1BhSikxkgkI39tILoFxLluCCoaxCyV4OnT874rwCgiY5h
0tQD+IxVexqvREAhQUGCIKariAZYUxWikw1+N06xvAELkdBXYHew9XhO/6DA1EkN
NwIXeZXn1Ej7uvcH49ZvX4L0RVmKXSJVS6HYdo0vcn9/LkMrM4WduyjEYNSea6bw
ZMN3xF5bXNFPVmapsT26nkQ0xYWskyPbFM6nVTELgDy6Qq5asno=
=u1ik
-END PGP SIGNATURE-