Bug#1003484: bullseye-pu: package openssl/1.1.1m-0+deb11u1

[Sebastian Andrzej Siewior]

On 2022-02-19 17:57:25 [+], Adam D. Barratt wrote:
> Feel free to upload; we'll wait for the d-i ack before accepting the
> package into p-u.

There will be the release of 1.1.1n on Tuesday 15th March 2022 including
a security fix. Therefore I will:
- prepare a security release against 1.1.1k-1+deb11u1 which will be
  released via d-security.
- respond to this bug with a debdiff against 1.1.1m-0+deb11u1
- upload 1.1.1n-0+deb11u1.

Please say if I should delay my upload until a request from the release
team happens, prepare a debdiff against another release or if there is
something else.

> Regards,
> 
> Adam

Sebastian

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Petra R.-P.]

Hello Damien,

Thanks for looking into the problem:

On Wed 09 Mar 2022 at 16:11:37 +0900  Damien Le Moal 
 wrote:

 [...]
> Could you try this patch:
> 
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
 [...]

I am very sorry, but I am a simple user, not a developer.
It would need a lot of tuition to make me accomplish that,
and I'm not sure I'd have enough time at the moment.

> Not sure if it will help, especially if you have a clean boot with 5.15
> ? If you do, could you also send me the full dmesg of a boot with 5.15
> kernel ? No video, dmesg output :)
> 
> I suspect that my patch that increases the timeout for read log may be
> the cause for the "hang", but the root cause is that the laptop drive
> does not like read log commands (there are some drives like that).
> Before the patch, the failure was faster and somehow ignored. I would
> like to see if dmesg shows the failures with 5.15.

Okay, that's easier:  See attached  dmesg-T41-k5.15.txt .

HTH a little.

 Best regards,
 Petra

[0.00] Linux version 5.15.0-3-686 (debian-ker...@lists.debian.org) 
(gcc-11 (Debian 11.2.0-14) 11.2.0, GNU ld (GNU Binutils for Debian) 
2.37.90.20220123) #1 SMP Debian 5.15.15-2 (2022-01-30)
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] signal: max sigframe size: 1440
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff] reserved
[0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1ff5] usable
[0.00] BIOS-e820: [mem 0x1ff6-0x1ff76fff] ACPI data
[0.00] BIOS-e820: [mem 0x1ff77000-0x1ff78fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x1ff8-0x1fff] reserved
[0.00] BIOS-e820: [mem 0xff80-0x] reserved
[0.00] Notice: NX (Execute Disable) protection missing in CPU!
[0.00] SMBIOS 2.3 present.
[0.00] DMI: IBM 2374H12/2374H12, BIOS 1RETC6WW (3.05a) 05/14/2004
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 1398.789 MHz processor
[0.005574] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.005584] e820: remove [mem 0x000a-0x000f] usable
[0.005599] last_pfn = 0x1ff60 max_arch_pfn = 0x10
[0.006397] x86/PAT: PAT not supported by the CPU.
[0.007306] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC- UC  
[0.017285] initial memory mapped: [mem 0x-0x0eff]
[0.017349] RAMDISK: [mem 0x1d5c9000-0x1ed2]
[0.017361] ACPI: Early table checksum verification disabled
[0.017371] ACPI: RSDP 0x000F6E00 24 (v02 IBM   )
[0.017384] ACPI: XSDT 0x1FF6AF83 4C (v01 IBMTP-1R
3051  LTP )
[0.017400] ACPI: FACP 0x1FF6B000 F4 (v03 IBMTP-1R
3051 IBM  0001)
[0.017415] ACPI BIOS Warning (bug): 32/64X length mismatch in 
FADT/Gpe0Block: 64/32 (20210730/tbfadt-564)
[0.017425] ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has valid 
Address but zero Length: 0x102C/0x0 (20210730/tbfadt-615)
[0.017439] ACPI: DSDT 0x1FF6B1E7 00BC1F (v01 IBMTP-1R
3051 MSFT 010E)
[0.017452] ACPI: FACS 0x1FF78000 40
[0.017461] ACPI: FACS 0x1FF78000 40
[0.017471] ACPI: SSDT 0x1FF6B1B4 33 (v01 IBMTP-1R
3051 MSFT 010E)
[0.017484] ACPI: ECDT 0x1FF76E06 52 (v01 IBMTP-1R
3051 IBM  0001)
[0.017496] ACPI: TCPA 0x1FF76E58 32 (v01 IBMTP-1R
3051 PTL  0001)
[0.017507] ACPI: BOOT 0x1FF76FD8 28 (v01 IBMTP-1R
3051  LTP 0001)
[0.017518] ACPI: Reserving FACP table memory at [mem 0x1ff6b000-0x1ff6b0f3]
[0.017524] ACPI: Reserving DSDT table memory at [mem 0x1ff6b1e7-0x1ff76e05]
[0.017529] ACPI: Reserving FACS table memory at [mem 0x1ff78000-0x1ff7803f]
[0.017535] ACPI: Reserving FACS table memory at [mem 0x1ff78000-0x1ff7803f]
[0.017540] ACPI: Reserving SSDT table memory at [mem 0x1ff6b1b4-0x1ff6b1e6]
[0.017545] ACPI: Reserving ECDT table memory at [mem 0x1ff76e06-0x1ff76e57]
[0.017551] ACPI: Reserving TCPA table memory at [mem 0x1ff76e58-0x1ff76e89]
[0.017556] ACPI: Reserving BOOT table memory at [mem 0x1ff76fd8-0x1ff76fff]
[0.017580] 0MB HIGHMEM available.
[0.017584] 511MB LOWMEM available.
[0.017587]   mapped low ram: 0 - 1ff6
[0.017592]   low ram: 0 - 1ff6
[0.017611] Zone ranges:
[0.017614]   DMA  [mem 0x1000-0x00ff]
[0.017622]   Normal   [mem 0x0100-0x1ff5]
[0.017629]   HighMem  empty
[0.017634]

Bug#1006581: xmltooling: FTBFS with OpenSSL 3.0

[Sebastian Andrzej Siewior]

On 2022-03-06 11:38:15 [+0100], Ferenc Wágner wrote:
> Sebastian Andrzej Siewior  writes:
> 
> > Your package is failing to build using OpenSSL 3.0 with the
> > following error:
> >
> > | make[5]: Entering directory '/<>/xmltoolingtest'
> > | ../build-aux/test-driver: line 112: 1662259 Segmentation fault  "$@" 
> > >> "$log_file" 2>&1
> > | FAIL: xmltoolingtest
> 
> Hi,
Hi,

> I suspect that this stems from an OpenSSL version mismatch among the
> dependencies (xml-security-c or cURL, which both use OpenSSL themselves)
> and XMLTooling itself.  Or did you rebuild those with OpenSSL 3 before
> testing XMLTooling? 

I only built xmltooling against openssl3. I will try to build the two
packages you mentioned and then try again.

> Speaking of this, do you plan to finish the OpenSSL
> transition before bookworm is frozen?

I sure hope so. The release team did not ack it yet but then it is a
year or two until the freeze.

Sebastian

Bug#989604: [Pkg-openssl-devel] Bug#989604: libssl1.1: segfault on arm64 (M1) with some ciphers e.g. curl https://dl.yarnpkg.com

[Sebastian Andrzej Siewior]

On 2022-03-05 16:34:29 [-0800], Anders Kaseorg wrote:
> Any progress on this fix, via either my targeted debdiff or a full update to
> ≥ 1.1.1i?

There will be an openssl security release on Tuesday 15th March 2022. I
intend to a fix to this as part of the security update.

> Anders

Sebastian

Bug#1006956: tt-rss spits a lot of php warnings

[VA]

Package: tt-rss
Version: 21~git20210204.b4cbc79+dfsg-1

tt-rss spits a lot of logs. In 8 hours it did that:

% journalctl -S today | grep -c tt-rss
36715

Logs are all php warnings like this:

mars 09 07:56:17 xxx php[478978]: [tt-rss] E_WARNING (2) 
(classes/urlhelper.php:99) Undefined array key "port"
mars 09 07:56:17 xxx php[478978]: [tt-rss] E_WARNING (2) 
(classes/db/prefs.php:63) Undefined global variable $_SESSION
mars 09 07:56:17 xxx php[478978]: [tt-rss] E_WARNING (2) 
(classes/db/prefs.php:63) Trying to access array offset on value of type 
null
mars 09 07:56:17 xxx php[478978]: [tt-rss] E_WARNING (2) 
(classes/db/prefs.php:86) Undefined global variable $_SESSION
mars 09 07:56:17 xxx php[478978]: [tt-rss] E_WARNING (2) 
(classes/db/prefs.php:86) Trying to access array offset on value of type 
null
mars 09 07:56:17 xxx php[478978]: [tt-rss] E_WARNING (2) 
(classes/db/prefs.php:63) Undefined global variable $_SESSION
mars 09 07:56:17 xxx php[478978]: [tt-rss] E_WARNING (2) 
(classes/db/prefs.php:63) Trying to access array offset on value of type 
null
mars 09 07:56:17 xxx php[478978]: [tt-rss] E_WARNING (2) 
(classes/db/prefs.php:86) Undefined global variable $_SESSION
mars 09 07:56:17 xxx php[478978]: [tt-rss] E_WARNING (2) 
(classes/db/prefs.php:86) Trying to access array offset on value of type 
null
mars 09 07:56:17 xxx php[478978]: [tt-rss] E_DEPRECATED (8192) 
(classes/rssutils.php:703) strip_tags(): Passing null to parameter #1 
($string) of type string is deprecated
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx php[478973]: [tt-rss] E_WARNING (2) 
(classes/userhelper.php:78) Undefined global variable $_SESSION
mars 09 07:56:17 xxx php[478973]: [tt-rss] E_WARNING (2) 
(classes/userhelper.php:78) Trying to access array offset on value of 
type null
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx php[478973]: [tt-rss] E_WARNING (2) 
(classes/db/prefs.php:11) Undefined global variable $_SESSION
mars 09 07:56:17 xxx php[478973]: [tt-rss] E_WARNING (2) 
(classes/db/prefs.php:11) Trying to access array offset on value of type 
null
mars 09 07:56:17 xxx php[478973]: [tt-rss] E_WARNING (2) 
(classes/db/prefs.php:63) Undefined global variable $_SESSION
mars 09 07:56:17 xxx php[478973]: [tt-rss] E_WARNING (2) 
(classes/db/prefs.php:63) Trying to access array offset on value of type 
null
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx php[478973]: [tt-rss] E_WARNING (2) 
(classes/db/prefs.php:86) Undefined global variable $_SESSION
mars 09 07:56:17 xxx php[478973]: [tt-rss] E_WARNING (2) 
(classes/db/prefs.php:86) Trying to access array offset on value of type 
null
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx php[478973]: [tt-rss] E_WARNING (2) 
(classes/pluginhost.php:143) Undefined array key 2
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx update.php[478973]: PHP Warning:  Array to string 
conversion in /usr/share/tt-rss/www/include/errorhandler.php on line 24
mars 09 07:56:17 xxx update.php[478973]: PHP W

Bug#1006271: Info received (Bug#1006271: Acknowledgement (network-manager: crashes if DHCPv6 server sends multiple IPv6 addresses))

[Mad Horse]

Upstream issue 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/907 
is related to this bug, and it is fixed with 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/5402a7217964205aa6041324fa0fd393bfbb4838

Bug#863751: Info received (Bug#863751: Add --btrfs-subvolume-home option to adduser)

[Osamu Aoki]

Hi,

I should have checked my typos more. 

Important corrections are:

WRONG: make sharpshoots of their data easily.
CORRECT: make snapshots of their data easily.

WRONG: It they become separate btrfs subvolume,
CORRECT: If they become separate btrfs subvolume,

(There are many other errors such as 3rd person singular "s" for verbs ...)

Osamu

Bug#982159: dxvk: Dependency on development version of WINE might not be justified

[duck]

Quack,

Btw, Adrian could you clarify with you bumped the severity?
wine-development was already blocked from entering Bullseye and that 
blocked dxvk as well, so no need to add a RC bug just for that.


Regards.
\_o<

--
Marc Dequènes

Bug#982159: dxvk: Dependency on development version of WINE might not be justified

[duck]

Quack,

Could you please test the changes in branch 'br982159' on Salsa and tell 
me if it works for you?


Regards.
\_o<

--
Marc Dequènes

Bug#1006863: [Pkg-samba-maint] Bug#1006863: tevent: reproducible-builds: build path embedded in various libraries

[Vagrant Cascadian]

On 2022-03-07, Andrew Bartlett wrote:
> I would rather this be discussed and implemented upstream.
>
> For one, the tevent build system is shared with the rest of Samba, and
> if possible this should be implemented by default for all 'make
> install' runs, just as we do to strip out the bin/default from -rpath.

Thanks for the quick response, I'll try and come up with something
upstreamable...

live well,
  vagrant

> On Sun, 2022-03-06 at 16:43 -0800, Vagrant Cascadian wrote:
>> Source: tevent
>> Severity: normal
>> Tags: patch
>> User: reproducible-bui...@lists.alioth.debian.org
>> Usertags: buildpath
>> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>> 
>> The build path and resulting Build ID for various libraries is
>> embedded:
>> 
>>   
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/tevent.html
>> 
>>   /usr/lib/x86_64-linux-gnu/libtevent.so.0.11.0
>> 
>>   /build/1st/tevent-0.11.0/bin/default/../../tevent.c:303
>>   vs.
>>   /build/2/tevent-0.11.0/2nd/bin/default/../../tevent.c:303
>> 
>> The attached patch to debian/rules fixes this by passing
>> -ffile-prefix-map via CFLAGS in the dh_auto_configure override.
>> 
>> Alternately, updating to use the CFLAGS passed via dh/debhelper would
>> also likely fix this.
>> 
>> With this patch applied tevent should build reproducibly on
>> tests.reproducible-builds.org!
>> 
>> live well,
>>   vagrant
>> ___
>> Pkg-samba-maint mailing list
>> pkg-samba-ma...@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-samba-maint
> -- 
> Andrew Bartlett (he/him)   https://samba.org/~abartlet/
> Samba Team Member (since 2001) https://samba.org
> Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba
>
> Samba Development and Support, Catalyst IT - Expert Open Source
> Solutions


signature.asc
Description: PGP signature

Bug#948691: MOZ_APP_LAUNCHER

[Simon McVittie]

Control: merge 948691 980461
Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1494436

On Sat, 27 Nov 2021 at 07:13:20 +, Jonathan Krebs wrote:
> Could you please explain, why Thunderbird should not set
> [MOZ_APP_LAUNCHER]?

Let me turn this round: why *should* Thunderbird set this environment
variable? What benefit does it give Thunderbird to make any child process
that happens to be Mozilla-based (even Firefox!) think it is part of
Thunderbird?

Firefox doesn't seem to need to do similarly; what's different in
Thunderbird that makes this necessary?

On Sat, 27 Nov 2021 at 08:46:16 +0100, Carsten Schoenert wrote:
> But yeah, I have the same question, so Mike please, it would be nice to hear
> some thoughts from you why setting MOZ_APP_LAUNCHER isn't something we
> should do and what other options we have.

I'm not Mike, but the obvious reason to not set MOZ_APP_LAUNCHER is:
because it breaks Firefox when used as a URL handler by Thunderbird,
by making Firefox think it's part of Thunderbird.

https://bugs.debian.org/980461 seems to be basically the same bug,
and points to upstream bug report
https://bugzilla.mozilla.org/show_bug.cgi?id=1494436 where the
other suggestion was to remove MOZ_APP_LAUNCHER from the environment
before launching any external URL or MIME-type handler. I'll try to
put together a patch for that.

smcv

Bug#863751: Add --btrfs-subvolume-home option to adduser

[Osamu Aoki]

Hi,

> -Original Message-
> From: Marc Haber 
> To: Osamu Aoki 
> Cc: 863...@bugs.debian.org, 863751-submit...@bugs.debian.org, Nicholas D 
> Steeves
> 
> Subject: Re: Bug#863751: Add --btrfs-subvolume-home option to adduser
> Date: Tue, 8 Mar 2022 14:21:09 +0100
> 
> Hi,
> 
> On Tue, Mar 08, 2022 at 07:16:57PM +0900, Osamu Aoki wrote:
> > I was thinking opt-in only.
> > 
> > I mean to add an opt-in --btrfs-subvolume-home option to adduser so
> > the user can use this feature if he requests.  I didn't think beyond.
> > (I didn't test it on non-btrfs system so I don't know the answer to
> > your question.  Whoever specifies it in command line, he should know
> > it.)
> 
> I had a sane default in mind. As times have changed and maintainer /
> developer resources are scarce, adduser primarily sees itself as a
> policy wrapper to help package maintainers to create their package
> accounts in their maintainer scripts without violating policy. Offering
> account creation capabilities to the local admin has been pushed into
> the background in the last decades.

I now understand your POV and where it came from.

> I'd say then if the local admin wants to use a feature that adduser
> doesnt offer, they are free to use other tools such as useradd directly
> to get what they want.

Yes.  That's basically what I do here trivially.  (I still use adduser.  After 
whole
standard d-i installation, I rename the primary user's home directory from root
account on console and create subvolume in place and copy data into it.)

> > As I come to think of this, since it is trivial to check FS of /home
> > in adduser in advance by calling a basic shell command as:
> > 
> > ``` $ stat -f -c %T /home btrfs ``` , adding this feature as an
> > automatic option for pertinent system is an interesting thought for
> > adduser too.
> 
> I am reluctant to add filesystem specific code to adduser, as writing
> automated tests is probably hard.

I think it causes some dependency increase and resource drain for you. (I don't 
think
it is so exotic to do this.)

TBH, I am not pushing this patch after hearing back from you.  I now think the 
best
action is to label this as "wontfix" on condition until followings become about 
to be
reached.

* Linux kernel supports btrfs as its primary filesystem over ext4.
* useradd manpage (not -h output) explicitly includes this option.
* Debian installer considers to support btrfs as root filesystem as out-of-box
feature and this becomes a required feature of installation process.

When these things are on horizon, this feature may be desirable one to have for 
user
to make sharpshoots of their data easily.

> I would think more about adding this if having account-specific btrfs
> subvolumes per _system_ account would be a valid feature to have AND if
> useradd is smart enough to not error out or spew warnings if one tries
> to create a btrfs subvolume on non-btrfs volumes. At th moment, I am not
> convinced that this is worth spending developer / maintainer time on.

As I see many so-called _system_ accounts in /etc/passwd, their home directory 
are
everywhere under /var, /bin, /usr/bin, ...  It they become separate btrfs 
subvolume,
making snapshot script will be nightmare to address all.  So it's bad idea to 
do so
unless some rare maintainer script specifically request so (sbuild, 
apt-cacher-ng may
be good candidate if their maintainer wishes but most _system_ account using
/nonexistent, /bin . /var/... as home directory shall not use this to maintain 
easy
snapshot recoverable system).  Anyway, practically that kind of question 
happens only
when debian-installer start supporting installation of system root on btrfs 
subvolume
as default and some packages start taking advantage.

Your concern for your time is valid one to reject this patch.

> Would it help to have an "useradd-extra-options" command line option and
> configuration file setting that causes their respective contents to
> be added to useradd's command line verbatim? Which other commands would
> need a respective foo-extra-options option?
> 

As I said above, I don't see such benefit under current situation for most of
_system_ accounts.  This is useful mostly for user accounts.

Currently, Debian can be installed and booted from btrfs subvolume using d-i 
but that
requires a lot of manual tweakings.  Compared to them, user's home directory as 
btrfs
subvolume is a minor non-essential tweak.

Regards,

Osamu

Bug#994924: python-virtualenv: "pip list --outdated" fails

[Stefano Rivera]

Control: forcemerge 1006150 994924

Hi Florian (2021.09.23_15:34:11_-0400)
> Interesting bug. It occurs on new venvs, but goes away as soon as I
> start poking at it. And I can't figure out why...

I think I got to the bottom of it in #1006150.

SR

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

Bug#1006912: is it time to have account deletion in policy?

[Sean Whitton]

Hello Marc,

On Tue 08 Mar 2022 at 07:40am +01, Marc Haber wrote:

> How about putting advice like this in policy:
>
> Suggestion 1:
> Create a dedicated chapter (which would ideally be placed between the
> current chapters 9.2.1. Introduction and 9.2.2. UID and GID classes)
> named "dynamically allocated system users or groups for packages" with
> the following contents:
> - packages can create users and groups on installation
> - usernames should be chosen wisely, allowing to deduce the related
>   package from the name, and prefixed with an underscore

This sounds good, though we would need an extremely strong argument for
inserting rather than appending the new section -- we do not want to
renumber sections not just because it breaks hyperlinks, but because it
breaks purely textual references to Policy sections in bugs that remain
open, mailing list posts to which people still refer, etc.

> - adduser --system is the preferred method to create package account, it
>   takes responsibility of being policy compliant. Other packages doing
>   this job might exist (dh-sysuser, for example).

It would be good to get some input from people who use other methods.  I
would always look to adduser myself, but there might be others who feel
strongly that it's not right for certain classes of case -- perhaps we
want to limit the scope of this advice a bit.

> Suggestion 2a:
> Document that a package should not delete its user on uninstallation
> and/or purge. This reflects current practice of most packages but might
> need changes in some packages that currently delete their user. Those
> packages are the reason that this policy item should not be introduced
> as a MUST.

Sounds good.

> Suggestion 2b:
> Document that a package may lock its user on uninstall, but leave it on
> the system on purge. That way, a leftover account could not be used as
> an attack vector and just blocks the uid/gid and the name. On
> reinstallation of a package, the existing, locked account would just be
> unlocked.
>
> This would be a new behavior that could be worth documenting in Policy.
> Should the policy editors indicate that this might be an option, adduser
> would be willing to implement a deluser --lock --system option that
> would lock a named account if its uid is in the appropriate range for
> system accounts, and adduser --system would not error out if the account
> already exists and would just remove the lock. Thus implementing this
> option in a package would just mean to add the appropriat deluser call
> to postrm uninstall while postinst can remain unchanged.

Sounds like a nice improvement on the current situation.

> I am willing to suggest wording, but I am not a policy expert and
> wording would probably be better if an experienced policy editor would
> write the appropriate language. How would a new chapter be inserted in
> Policy without destroying existing references to chapter numbers?

Please go ahead and write a patch.  The Policy Editors are happy to
review and edit proposed wording but we can't be responsible for
producing all of the text that gets added to Policy.

-- 
Sean Whitton

Bug#1006955: ITP: python-txrequests -- Asynchronous Python HTTP Requests for Humans using twisted

[Robin Jarry]

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

* Package name: python-txrequests
  Version : 0.9.6
  Upstream Author : Pierre Tardy 
* URL : https://github.com/tardyp/txrequests
* License : Apache-2.0
  Programming Lang: Python
  Description : Asynchronous Python HTTP Requests for Humans using twisted

Small add-on for the python requests http library. Makes use twisted's
ThreadPool, so that the requests'API returns deferred objects.

This is a dependency of buildbot. Required to update to 3.4.1 and later.

I intend on maintaining this package in the context of the Debian Python
Team. I will need a sponsor for uploads after pushing on Salsa.

Thanks!

Bug#1006954: qt6-base has an explicit dependency on libssl1.1 Edit

[Daniel Bungert]

Package: qt6-base
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com

Dear Maintainer,

qt6-base has an explicit dependency on libssl1.1 for the network
library.  You may find the following merge request helpful, which ports
commit 531c31ae58aefc7c from salsa qt-kde-team/qt/qtbase to address
this overly-specific dependency on the openssl version.

https://salsa.debian.org/qt-kde-team/qt6/qt6-base/-/merge_requests/6

-Dan

Bug#1006905: bullseye-pu: package ostree/2020.8-2+deb11u1

[Dan Nicholson]

On Mon, Mar 7, 2022 at 6:09 PM Simon McVittie  wrote:
>
> If d/p/Fall-back-if-copy_file_range-fails-with-EINVAL.patch is not applied,
> users with an eCryptFS encrypted home directory cannot use `flatpak --user`.
> If they had already configured all necessary remotes before encrypting the
> home directory, the symptom is that `flatpak build-bundle` crashes; if not,
> from my tests on unstable, it appears that the symptom is that
> `flatpak remote-add` fails. (#1004467)
> There are indications from upstream bug reports that this patch might
> also fix similar issues for ZFS users, although this is not yet confirmed.

This is a safe patch as it just extends the cases where a fallback
will be run. Since it affects all users of ecryptfs, it seems like a
good idea to include.

> If d/p/Fix-marking-static-delta-commits-as-partial.patch is not applied,
> interrupted downloads can result in a corrupted local repository, requiring
> manual cleanup via `flatpak repair` or `ostree fsck`.

This is a really unfortunate bug in ostree that should be fixed ASAP.
For Endless I'm going to backport this to all of our supported stable
branches but haven't gotten around to it yet.

> If d/p/libotutil-Avoid-infinite-recursion-during-error-unwinding.patch is
> not applied, some failure modes (in particular the symptom of #1004467)
> lead to a crash instead of a graceful failure.

The change here is clearly correct and should have no unintended side
effects. Since this also affects all users of ecryptfs, it's a good
idea to have it in stable.

> If d/p/Fix-translation-of-file-URIs-into-paths.patch is not applied,
> users will be unable to install Flatpak apps from paths on the local
> filesystem that contain a backslash or non-ASCII, most commonly during
> "sideloading" from a USB stick created by `flatpak create-usb`.

We've been shipping this in Endless stable for about a year with no
reported issues.

> If d/p/lib-Fix-a-bad-call-to-g_file_get_child.patch is not applied,
> checking out only a subset of a commit (most frequently seen in Flatpak
> when installing locale data) can fail with an assertion failure if a
> backport or local build of GLib 2.71 is in use. I'm a little unsure about
> this one for bullseye, since I would generally not recommend backporting
> something as foundational as GLib, but it's a one-line fix. With my
> GNOME team hat on, we need to get GLib >= 2.72 into bookworm within the
> next few weeks, so if someone does a backport of bookworm's GLib into
> bullseye-backports, then the priority of this change will suddenly go up.

Even though this would only manifest with a newer GLib release, I
think this is a good idea to include in bullseye. It's a bit
unfortunate that GLib changed the semantics of g_file_get_child, but
the change makes OSTree checkouts more robust all around in the face
of user supplied subpaths.

> [ Risks ]
> I would say this is low-risk. They're narrowly-targeted patches, and
> all are straightforward backports, either from upstream release 2022.2
> (in unstable, not in testing yet) or from older releases that are already
> in testing.

I would agree that this is low risk. These patches fix real bugs, were
vetted by upstream, and are narrowly scoped. I think the risk of
regressions is very low. These are all things I plan to put in our
stable branch for Endless (I actually have the task to do that this
week).

--
Dan

Bug#1006953: fonts-creep2: Font does not install correctly, so does not show up in GUI font lists

[David Calman]

Package: fonts-creep2
Version: 0.0~git20210325.69dc0de+ds-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: alt.people.davidcal...@gmail.com

Dear Maintainer,

I installed creep2 because I wanted to use it. It does not install
correctly, so it does not show up in e.g. the font list in AbiWord,
or the font list in Konsole, etc., despite being a TrueType font supposedly.


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

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

-- no debconf information

Bug#1006952: ITP: python3-flask-dance -- doing the OAuth dance with style using Flask, requests, and oauthlib

[Sergio de Almeida Cipriano Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio de Almeida Cipriano Junior 
X-Debbugs-Cc: debian-de...@lists.debian.org, sergios...@riseup.net

* Package name: python3-flask-dance
  Version : v5.1.0
  Upstream Author : David Baumgold 
* URL : https://github.com/singingwolfboy/flask-dance
* License : MIT
  Programming Lang: Python3
  Description : Doing the OAuth dance with style using Flask, requests, and 
oauthlib

 Doing the OAuth dance with style using Flask, requests, and oauthlib.
 Currently, only OAuth consumers are supported. 

 I intent to package debian-image-finder [1] and flask-dance is one of
 its dependencies. I also plan to package under the umbrella of the
 Debian Python Team.

 [1]: https://image-finder.debian.net/

Bug#1006616: firefox: new upstream version

[Christoph Anton Mitterer]

Seems that rustc 1.57 is now even in sid and FF 98, with further
"high" rated fixes, is out.

Mike, any estimates on whether this could be upgraded? :)

Thanks,
Chris.

Bug#1006009: libwebp: diff for NMU version 1.2.1-7.2

[Sebastian Ramacher]

Dear maintainer,

I've made a mistake in my previous NMU and named the patch incorrectly.
Hence it wasn't applied. This issue is fixed with this upload.

Cheers
-- 
Sebastian Ramacher
diff -Nru libwebp-1.2.1/debian/changelog libwebp-1.2.1/debian/changelog
--- libwebp-1.2.1/debian/changelog	2022-03-06 11:12:08.0 +0100
+++ libwebp-1.2.1/debian/changelog	2022-03-08 22:50:07.0 +0100
@@ -1,3 +1,10 @@
+libwebp (1.2.1-7.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix path of the patch (Closes: #1006009, 1006110)
+
+ -- Sebastian Ramacher   Tue, 08 Mar 2022 22:50:07 +0100
+
 libwebp (1.2.1-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libwebp-1.2.1/debian/pachtes/0001-Fix-lossless-encoding-for-MIPS.patch libwebp-1.2.1/debian/pachtes/0001-Fix-lossless-encoding-for-MIPS.patch
--- libwebp-1.2.1/debian/pachtes/0001-Fix-lossless-encoding-for-MIPS.patch	2022-03-06 11:10:27.0 +0100
+++ libwebp-1.2.1/debian/pachtes/0001-Fix-lossless-encoding-for-MIPS.patch	1970-01-01 01:00:00.0 +0100
@@ -1,47 +0,0 @@
-From e4cbcdd2b5ff33a64f97fe49d67fb56f915657e8 Mon Sep 17 00:00:00 2001
-From: Vincent Rabaud 
-Date: Tue, 1 Mar 2022 13:38:29 +0100
-Subject: [PATCH 1/2] Fix lossless encoding for MIPS.
-
-Bug: webp:558
-Change-Id: I3d3ddb64ed26a8d8ff5664664c5f20f6eadfeb4f

- src/dsp/lossless_enc_mips32.c | 8 
- 1 file changed, 4 insertions(+), 4 deletions(-)
-
-diff --git a/src/dsp/lossless_enc_mips32.c b/src/dsp/lossless_enc_mips32.c
-index 0412a093..99630517 100644
 a/src/dsp/lossless_enc_mips32.c
-+++ b/src/dsp/lossless_enc_mips32.c
-@@ -347,24 +347,24 @@ static void GetCombinedEntropyUnrefined_MIPS32(const uint32_t X[],
- static void AddVector_MIPS32(const uint32_t* pa, const uint32_t* pb,
-  uint32_t* pout, int size) {
-   uint32_t temp0, temp1, temp2, temp3, temp4, temp5, temp6, temp7;
--  const uint32_t end = ((size) / 4) * 4;
-+  const int end = ((size) / 4) * 4;
-   const uint32_t* const LoopEnd = pa + end;
-   int i;
-   ASM_START
-   ADD_TO_OUT(0, 4, 8, 12, 1, pa, pb, pout)
-   ASM_END_0
--  for (i = end; i < size; ++i) pout[i] = pa[i] + pb[i];
-+  for (i = 0; i < size - end; ++i) pout[i] = pa[i] + pb[i];
- }
- 
- static void AddVectorEq_MIPS32(const uint32_t* pa, uint32_t* pout, int size) {
-   uint32_t temp0, temp1, temp2, temp3, temp4, temp5, temp6, temp7;
--  const uint32_t end = ((size) / 4) * 4;
-+  const int end = ((size) / 4) * 4;
-   const uint32_t* const LoopEnd = pa + end;
-   int i;
-   ASM_START
-   ADD_TO_OUT(0, 4, 8, 12, 0, pa, pout, pout)
-   ASM_END_1
--  for (i = end; i < size; ++i) pout[i] += pa[i];
-+  for (i = 0; i < size - end; ++i) pout[i] += pa[i];
- }
- 
- #undef ASM_END_1
--- 
-2.35.1
-
diff -Nru libwebp-1.2.1/debian/pachtes/series libwebp-1.2.1/debian/pachtes/series
--- libwebp-1.2.1/debian/pachtes/series	2022-03-06 11:11:12.0 +0100
+++ libwebp-1.2.1/debian/pachtes/series	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-0001-Fix-lossless-encoding-for-MIPS.patch
diff -Nru libwebp-1.2.1/debian/patches/0001-Fix-lossless-encoding-for-MIPS.patch libwebp-1.2.1/debian/patches/0001-Fix-lossless-encoding-for-MIPS.patch
--- libwebp-1.2.1/debian/patches/0001-Fix-lossless-encoding-for-MIPS.patch	1970-01-01 01:00:00.0 +0100
+++ libwebp-1.2.1/debian/patches/0001-Fix-lossless-encoding-for-MIPS.patch	2022-03-06 11:10:27.0 +0100
@@ -0,0 +1,47 @@
+From e4cbcdd2b5ff33a64f97fe49d67fb56f915657e8 Mon Sep 17 00:00:00 2001
+From: Vincent Rabaud 
+Date: Tue, 1 Mar 2022 13:38:29 +0100
+Subject: [PATCH 1/2] Fix lossless encoding for MIPS.
+
+Bug: webp:558
+Change-Id: I3d3ddb64ed26a8d8ff5664664c5f20f6eadfeb4f
+---
+ src/dsp/lossless_enc_mips32.c | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/src/dsp/lossless_enc_mips32.c b/src/dsp/lossless_enc_mips32.c
+index 0412a093..99630517 100644
+--- a/src/dsp/lossless_enc_mips32.c
 b/src/dsp/lossless_enc_mips32.c
+@@ -347,24 +347,24 @@ static void GetCombinedEntropyUnrefined_MIPS32(const uint32_t X[],
+ static void AddVector_MIPS32(const uint32_t* pa, const uint32_t* pb,
+  uint32_t* pout, int size) {
+   uint32_t temp0, temp1, temp2, temp3, temp4, temp5, temp6, temp7;
+-  const uint32_t end = ((size) / 4) * 4;
++  const int end = ((size) / 4) * 4;
+   const uint32_t* const LoopEnd = pa + end;
+   int i;
+   ASM_START
+   ADD_TO_OUT(0, 4, 8, 12, 1, pa, pb, pout)
+   ASM_END_0
+-  for (i = end; i < size; ++i) pout[i] = pa[i] + pb[i];
++  for (i = 0; i < size - end; ++i) pout[i] = pa[i] + pb[i];
+ }
+ 
+ static void AddVectorEq_MIPS32(const uint32_t* pa, uint32_t* pout, int size) {
+   uint32_t temp0, temp1, temp2, temp3, temp4, temp5, temp6, temp7;
+-  const uint32_t end = ((size) / 4) * 4;
++  const int end = ((size) / 4) * 4;
+   const uint32_t* const LoopEnd = pa + end;
+   int i;
+   ASM_START
+   ADD_TO_OUT(0, 4, 8, 12, 0, pa, pout, pout)
+   ASM_END_1
+-  for (i = end; i < size; +

Bug#990026: Aaargh!

[Christian Kastner]

Hi,

FYI, cron is looking for a new maintainer, see #984736, so I guess that
is why there hasn't been any activity yet.

On 2021-06-22 16:52, Wouter Verhelst wrote:
> Whoever wrote that patch should be slapped around the head with a copy
> of RFC3696.

As evident from the header, that patch was taken from cronie, RedHat's
fork of cron-4.1. cronie is much more actively maintained than our own
cron, which is a fork of Vixie cron... from 1993.

> Go read it. Now, please. Understand it. Internalize it. Then update your
> data verification code so that all valid email addresses will be
> accepted.
> 
> But first remove the "save_p" function from the cron implementation. It
> is broken, and the fix may otherwise take too long, I suppose.

The safe_p function and its use of were introduced in upstream, that is
ISC cron 4.1 (from 2004), the basis for most cron daemons (cronie,
OpenBSD's version, and others).

On 2021-07-13 11:15, Georges Khaznadar wrote:
> Hello, as bug #990026 got no update for three weeks, I uploaded a fix to
> our salsa repository, which allows characters like "=" and "/" in e-mail
> addresses.
> 
> I add the patch as an attachment.

I'll upload an NMU.

Best,
Christian

Bug#990026: Aaargh!

[Christian Kastner]

On 2022-03-08 21:58, Christian Kastner wrote:
> I'll upload an NMU.

Ah, pulling the newest source from Salsa, I saw Georges' @debian.org
address. Apologies!

In that case, please NMU it yourself (as you've already prepared the
changelog).

Best,
Christian

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Petra R.-P.]

Hello,

I am the "OP" with the T41 Thinkpads.

On Tue 08 Mar 2022 at 05:58:53 +0900  Damien Le Moal 
 wrote:

> Could you try taking a video of the boot messages ?

You can find my first attempt (only ≈12MB) here: 
https://prp.in-berlin.de/MAQ01257.MP4
I will leave it there for 2 weeks.

Not sure if I got the loglevel right and whether the image is
clear enough.

BTW:  This is really a T41 Thinkpad; I'm using it with an
external monitor because its display is broken.

   Best regards,
   Petra

Bug#868568: [Pkg-shadow-devel] Bug#868568: Bug#868568: Possible cause of deluser problem: subordinate user IDs

[Jason Franklin]

On Tue, 2022-03-08 at 18:39 +, Ben Harris wrote:
> On Tue, 8 Mar 2022, Serge E. Hallyn wrote
> 
> > So deluser was doing the right thing, right?
> > 
> > The bug is how you got into this state?  Either the adduser for
> > the high uid should have checked for it being a delegated subuid,
> > or the adduser which added the subuids to the lower subuid should
> > have refused when the higher subuid existed as a uid.
> 
> As far as I can see, there is no checking for collisions in either 
> direction: useradd depends on the ranges [UID_MIN,UID_MAX] and 
> [SUB_UID_MIN,SUB_UID_MAX] not overlapping, and issues a warning if you 
> assign a static UID outside the specified range.

Serge:

This is something that has recently gotten my attention in my adduser
maintenance efforts. I am trying to help where I can to work around it
and to collaborate with shadow on the issue to get at an optimal
solution.

adduser has its own UID ranges set in /etc/adduser.conf. These variables
are the ones that matter...

> FIRST_SYSTEM_UID=100
> LAST_SYSTEM_UID=999
> FIRST_SYSTEM_GID=100
> LAST_SYSTEM_GID=999
> FIRST_UID=1000
> LAST_UID=5
> FIRST_GID=1000
> LAST_GID=5

As far as I can tell, adduser has no concept of a "subordinate UID"
(neither do I for that matter). I was not familiar with this feature
until recently. This is something I'll have to read about.

The latest upload of adduser (v3.120) uses a naive technique of passing
through its own system user UID range settings to the useradd call. See
below...

  &systemcall('/usr/sbin/useradd', '-r',
  '-K', sprintf('SYS_UID_MIN=%d', $config{'first_system_uid'}),
  '-K', sprintf('SYS_UID_MAX=%d', $config{'last_system_uid'}),
  '-d', $home_dir,
  '-g', $ingroup_name,
  '-s', $shell,
  '-u', $new_uid,

This technique has the benefit that when you use "adduser" you make use
of adduser settings with no warnings from useradd. Likewise, using
useradd obviously still reads from /etc/login.defs.

However, it does not solve the problem that we have two places for the
settings to be specified. Maybe this is not as confusing as I think. The
adduser tool uses /etc/adduser.conf and useradd uses its own file. I
suppose it's on the user to know which file configures which tool.

Other than having adduser pass through its own settings to avoid
"useradd" warnings, I'm not sure what else can be done to reconcile this
divergence.  It has existed for a while.

Let me know if you have any thoughts! Thanks!

-- 
Jason Franklin

Bug#1006951: bts -i: "Cc: 0"

[Jakub Wilk]

Package: devscripts
Version: 2.22.1

After I edit mail content generated by bts(1), a mysterious "Cc: 0" 
header appears:


  $ EDITOR=true bts -i retitle 1 moo

  From: Jakub Wilk 
  To: cont...@bugs.debian.org
  Subject: retitle 1 to moo
  Date: Tue, 08 Mar 2022 21:22:45 +0100
  User-Agent: devscripts bts/2.22.1
  Message-ID: <1646770965-898-bts-jw...@jwilk.net>


  retitle 1 moo
  thanks

  ---
  OK to send? [Y/n/e] e

  From: Jakub Wilk 
  To: cont...@bugs.debian.org
  Cc: 0
  Subject: retitle 1 to moo
  Date: Tue, 08 Mar 2022 21:22:45 +0100
  User-Agent: devscripts bts/2.22.1
  Message-ID: <1646770965-898-bts-jw...@jwilk.net>


  retitle 1 moo
  thanks

  ---
  OK to send? [Y/n/e] n

--
Jakub Wilk

Bug#1006950: libreoffice: toggle options in menus are too subtle to see

[Daniel Kahn Gillmor]

Package: libreoffice
Version: 1:7.3.1~rc1-1
Control: tags -1 + a11y

The dropdown menus in Libreoffice contain some entries that are toggle
buttons (items with a boolean state, which can be enabled or disabled by
clicking on them).

the toggle indicators in the standard configuration (i've never adjusted
my libreoffice configuration) are extremely difficult to see.

In the attached screenshot, you can see the "Edit" menu is open, with
the "Track Changes" submenu open.

The top two menuitems of the "Track Changes" submenu are toggle buttons.

The "Record" menuitem is a toggle button in the "off" state.

The "Show" menuitem is a toggle button in the "on" state.

Both menuitems have a light grey background.

"Show" has a 1px slightly-darker grey border around its icon to indicate
that it is in the "on" state.

My eyes aren't perfect, but they're not terrible either, and I have to
squint or get up close to the screen to be able to identify when a
toggle menuitem is on or off.  It doesn't help that when i click on the
menuitem to change its state, it also disappears immediately, so i can't
see whether something visually changes during the click.

I can only assume that this is much worse for someone with significant
vision impairment.

  --dkg



signature.asc
Description: PGP signature

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

[Sean Whitton]

Dear Chris, Dirk,

On Tue 08 Feb 2022 at 09:23pm +01, Helmut Grohne wrote:

> We've discussed a number of possible ways to put it back (various
> packages, various paths, with or without update-alternatives, with or
> without Conflicts). From what you said, I understand that: [...]
>
> Given these, we think that much of the issue can be resolved
> cooperatively. To get there we (as ctte) ask you to explain how you
> prefer adding the util-linux rename executable as precisely as you see
> it at this stage. [...]

The ctte discussed this bug at our meeting today and determined that
there are two resolutions to this bug supported by at least one member:

(A) src:util-linux should build a binary package that ships util-linux's
rename as "rename.ul" somewhere on PATH.

(B) src:util-linux should build a binary package that ships util-linux's
rename, but does not install it as "rename" anywhere on PATH.
It is not settled, at present, whether util-linux's rename should be
provided somewhere on PATH with a name other than "rename".

Option (A) is meant to be (B) plus the additional requirement that it be
rename.ul somewhere on PATH.  Neither option says anything about whether
util-linux's rename.ul should be installed in an Essential package.

Chris, we haven't heard back from you in response to our request for
input quoted above.  We would still very much like to hear what you
think of (A) and (B) and whether you prefer some (C).  If we don't hear
back from you by the time of our next committee meeting in a month, we
will consider voting on (A) and (B).

Dirk, we would be grateful if you would comment on these two
resolutions, but we aren't going to block resolving this bug on hearing
from you.

Thanks both.

-- 
Sean Whitton

Bug#1006949: src:ldc: fails to migrate to testing for too long: FTBFS on armhf and i386

[Paul Gevers]

Source: ldc
Version: 1:1.28.0-1
Severity: serious
Control: close -1 1:1.28.1-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:ldc has been trying to migrate for 76 days 
[2]. Hence, I am filing this bug. Your package fails to build from 
source on armhf and i386 while it successfully built there before.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=ldc



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006948: gcc-12: FTBFS on mips64el

[Paul Gevers]

Source: gcc-12
Version: 12-20220222-1
Severity: serious
Tags: ftbfs

Dear Matthias, GCC maintainers,

gcc-12 fails to build from source on mips64el in unstable. Normally this isn't 
an issue, but it builds a Build-Depends of gcc-11 which now can't migrate 
because it can't be build on mips64el.

Paul

Bug#1006947: matrix-synapse: synapse_port_db ignores options from /etc/matrix-synapse/conf.d/

[Nikolay Shaplov]

Package: matrix-synapse
Version: 1.53.0-1~bpo11+1
Severity: normal
X-Debbugs-Cc: dh...@nataraj.su


On debian bullseye I install matrix-synapse as usual:

sudo apt-get install python3-frozendict/bullseye-backports
sudo apt-get install matrix-synapse/bullseye-backports

and then trying to upgrade it from SQLite to postgresql as said here:

https://matrix-org.github.io/synapse/latest/postgres.html#porting-from-sqlite

But when I run

synapse_port_db --sqlite-database /var/lib/matrix-synapse/homeserver.db \
--postgres-config /etc/matrix-synapse/homeserver.yaml

I get error:

Traceback (most recent call last):
  File "/usr/bin/synapse_port_db", line 1217, in 
config.parse_config_dict(hs_config, "", "")
  File "/usr/lib/python3/dist-packages/synapse/config/_base.py", line 731, in 
parse_config_dict
self.invoke_all(
  File "/usr/lib/python3/dist-packages/synapse/config/_base.py", line 357, in 
invoke_all
res[config_class.section] = getattr(config, func_name)(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/synapse/config/server.py", line 252, in 
read_config
self.server_name = config["server_name"]
KeyError: 'server_name'

But if I add "server_name" to the homeserver.yaml

cat /etc/matrix-synapse/conf.d/server_name.yaml >> \
/etc/matrix-synapse/homeserver.yaml

synapse_port_db  starts working as it should.

My guess, synapse_port_db  is not aware of /etc/matrix-synapse/conf.d/
confings, thus we are having problems





-- System Information:
Debian Release: 11.0
  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-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 matrix-synapse depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  libjs-jquery   3.5.1+dfsg+~3.5.5-7
ii  libpython3-stdlib  3.9.2-3
ii  lsb-base   11.1.0
ii  perl   5.32.1-4+deb11u2
ii  python33.9.2-3
ii  python3-attr   20.3.0-1
ii  python3-bcrypt 3.1.7-4
ii  python3-bleach 3.2.1-2.1
ii  python3-canonicaljson  1.4.0-1
ii  python3-cryptography   3.3.2-1
ii  python3-distutils  3.9.2-1
ii  python3-frozendict 1.2-3~bpo11+1
ii  python3-idna   2.10-1
ii  python3-ijson  3.1.4-1
ii  python3-jinja2 2.11.3-1
ii  python3-jsonschema 3.2.0-3
ii  python3-lxml   4.6.3+dfsg-0.1+deb11u1
ii  python3-matrix-common  1.1.0-1~bpo11+1
ii  python3-msgpack1.0.0-6+b1
ii  python3-nacl   1.4.0-1+b1
ii  python3-netaddr0.7.19-5
ii  python3-openssl20.0.1-1
ii  python3-phonenumbers   8.12.1-1
ii  python3-pil8.1.2+dfsg-0.3
ii  python3-prometheus-client  0.9.0-1
ii  python3-psycopg2   2.8.6-2
ii  python3-pyasn1 0.4.8-1
ii  python3-pyasn1-modules 0.2.1-1
ii  python3-pymacaroons0.13.0-4
ii  python3-service-identity   18.1.0-6
ii  python3-signedjson 1.1.1-2
ii  python3-sortedcontainers   2.1.0-2
ii  python3-systemd234-3+b4
ii  python3-treq   18.6.0-0.2
ii  python3-twisted20.3.0-7
ii  python3-typing-extensions  3.7.4.3-1
ii  python3-unpaddedbase64 1.1.0-5
ii  python3-yaml   5.3.1-5

Versions of packages matrix-synapse recommends:
ii  matrix-synapse-ldap3  0.1.4+git20201015+a3c7a9f-1
ii  python3-pympler   0.9+dfsg1-2

Versions of packages matrix-synapse suggests:
pn  python3-authlib  
pn  python3-jwt  

-- Configuration Files:
/etc/matrix-synapse/homeserver.yaml changed [not included]

-- debconf information excluded

Bug#868568: [Pkg-shadow-devel] Bug#868568: Possible cause of deluser problem: subordinate user IDs

[Ben Harris]

On Tue, 8 Mar 2022, Serge E. Hallyn wrote


So deluser was doing the right thing, right?

The bug is how you got into this state?  Either the adduser for
the high uid should have checked for it being a delegated subuid,
or the adduser which added the subuids to the lower subuid should
have refused when the higher subuid existed as a uid.


As far as I can see, there is no checking for collisions in either 
direction: useradd depends on the ranges [UID_MIN,UID_MAX] and 
[SUB_UID_MIN,SUB_UID_MAX] not overlapping, and issues a warning if you 
assign a static UID outside the specified range.


--
Ben Harris, University of Cambridge Information Services.

Bug#1006946: Usb connected printer not working

[eHenry Berg]

Package: cups
Version: 2.4.1op1-1

Computer:   Raspberry Pi 3b+
Printer:Samsung CLX-3305W
Environment: Debian Unstable arm64
uname -a:   Linux atlas 5.16.0-3-arm64 #1 SMP Debian 5.16.11-1
(2022-02-25) aarch64 GNU/Linux

Usb connected printer worked 2022-02-16, but not the following time 2022-03-05.
The scanner works.

The printer worked 2022-02-16, journalctl:
Feb 16 13:42:55 atlas kernel: usb 1-1.3: new high-speed USB device
number 8 using dwc2
Feb 16 13:42:56 atlas kernel: usb 1-1.3: language id specifier not
provided by device, defaulting to English
Feb 16 13:42:56 atlas kernel: usb 1-1.3: New USB device found,
idVendor=04e8, idProduct=3456, bcdDevice= 1.00
Feb 16 13:42:56 atlas kernel: usb 1-1.3: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
Feb 16 13:42:56 atlas kernel: usb 1-1.3: Product: CLX-3300 Series
Feb 16 13:42:56 atlas kernel: usb 1-1.3: Manufacturer: Samsung
Electronics Co., Ltd.
Feb 16 13:42:56 atlas kernel: usb 1-1.3: SerialNumber: Z76JBJAC60004XE
Feb 16 13:42:58 atlas kernel: usblp 1-1.3:1.1: usblp0: USB
Bidirectional printer dev 8 if 1 alt 0 proto 2 vid 0x04E8 pid 0x3456
Feb 16 13:42:59 atlas kernel: usbcore: registered new interface driver usblp
Feb 16 13:42:59 atlas systemd[762]: Reached target Printer.
Feb 16 13:43:05 atlas systemd[1]: Created slice Slice /system/configure-printer.
Feb 16 13:43:05 atlas systemd[1]: Reached target Printer Support.
Feb 16 13:43:06 atlas systemd[1]: Started Configure Plugged-In Printer.
Feb 16 13:43:06 atlas udev-configure-printer[5299]: add usb-001-008
Feb 16 13:43:07 atlas udev-configure-printer[5299]: device devpath is
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.3
Feb 16 13:43:07 atlas udev-configure-printer[5299]: MFG:Samsung
MDL:CLX-3300 Series SERN:- serial:Z76JBJAC60004XE
Feb 16 13:43:18 atlas kernel: usblp0: removed
Feb 16 13:43:19 atlas kernel: usblp 1-1.3:1.1: usblp0: USB
Bidirectional printer dev 8 if 1 alt 0 proto 2 vid 0x04E8 pid 0x3456
Feb 16 13:43:20 atlas udev-configure-printer[5299]: URI matches
without serial number: usb://Samsung/CLX-3300%20Series?interface=1
Feb 16 13:43:20 atlas udev-configure-printer[5299]: No serial number
URI matches so using those without
Feb 16 13:43:20 atlas udev-configure-printer[5299]: URI of detected
printer: usb://Samsung/CLX-3300%20Series?interface=1, normalized:
samsung clx 3300 series interface 1
Feb 16 13:43:20 atlas udev-configure-printer[5299]: URI of print
queue: usb://Samsung/CLX-3300%20Series?interface=1, normalized:
samsung clx 3300 series interface 1
Feb 16 13:43:20 atlas udev-configure-printer[5299]: Queue
ipp://localhost/printers/Samsung_CLX-3300_Series has matching device
URI
Feb 16 13:43:20 atlas udev-configure-printer[5299]: Re-enabled printer
ipp://localhost/printers/Samsung_CLX-3300_Series
Feb 16 13:43:20 atlas udev-configure-printer[5299]: URI of print
queue: usb://Samsung/CLX-3300%20Series?interface=1, normalized:
samsung clx 3300 series interface 1
Feb 16 13:43:20 atlas udev-configure-printer[5299]: Queue
ipp://localhost/printers/Samsung_CLX-3300_Series_BlackWhite has
matching device URI
Feb 16 13:43:20 atlas udev-configure-printer[5299]: Re-enabled printer
ipp://localhost/printers/Samsung_CLX-3300_Series_BlackWhite
Feb 16 13:43:20 atlas systemd[1]:
configure-printer@usb-001-008.service: Deactivated successfully.
Feb 16 13:43:20 atlas systemd[1]:
configure-printer@usb-001-008.service: Consumed 1.012s CPU time.
Feb 16 13:43:31 atlas kernel: usblp0: removed
Feb 16 13:43:39 atlas kernel: usblp 1-1.3:1.1: usblp0: USB
Bidirectional printer dev 8 if 1 alt 0 proto 2 vid 0x04E8 pid 0x3456
Feb 16 13:43:39 atlas kernel: usblp0: removed
Feb 16 13:43:39 atlas kernel: usb 1-1.3: reset high-speed USB device
number 8 using dwc2
Feb 16 13:43:40 atlas kernel: usblp 1-1.3:1.1: usblp0: USB
Bidirectional printer dev 8 if 1 alt 0 proto 2 vid 0x04E8 pid 0x3456
Feb 16 13:45:01 atlas CRON[5347]: pam_unix(cron:session): session
opened for user root(uid=0) by (uid=0)
Feb 16 13:45:01 atlas CRON[5348]: (root) CMD (command -v debian-sa1 >
/dev/null && debian-sa1 1 1)
Feb 16 13:45:02 atlas CRON[5347]: pam_unix(cron:session): session
closed for user root
Feb 16 13:45:16 atlas kernel: usb 1-1.3: USB disconnect, device number 8
Feb 16 13:45:16 atlas kernel: usblp0: removed
Feb 16 13:45:17 atlas udev-configure-printer[5356]: remove
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.3/1-1.3:1.1
Feb 16 13:45:17 atlas udev-configure-printer[5356]: URI of detected
printer: usb://Samsung/CLX-3300%20Series?interface=1, normalized:
samsung clx 3300 series interface 1
Feb 16 13:45:17 atlas udev-configure-printer[5356]: URI of print
queue: usb://Samsung/CLX-3300%20Series?interface=1, normalized:
samsung clx 3300 series interface 1
Feb 16 13:45:17 atlas udev-configure-printer[5356]: Queue
ipp://localhost/printers/Samsung_CLX-3300_Series has matching device
URI
Feb 16 13:45:17 atlas udev-configure-printer[5356]: Disabled printer
ipp://localhost/printers/Samsung_CLX-3300_Series as the corresponding
device was unplugg

Bug#868568: [Pkg-shadow-devel] Bug#868568: Possible cause of deluser problem: subordinate user IDs

[Serge E. Hallyn]

So deluser was doing the right thing, right?

The bug is how you got into this state?  Either the adduser for
the high uid should have checked for it being a delegated subuid,
or the adduser which added the subuids to the lower subuid should
have refused when the higher subuid existed as a uid.

On Tue, Mar 08, 2022 at 05:31:41PM +, Ben Harris wrote:
> I ran into a problem very similar to the one described in Debian bug 868568:
> deleting a user with a UID < 10 failed because of a process that was
> running as a user with a UID >= 10.  It turned out to be because the
> larger user ID was recorded in /etc/subuid as a subordinate user-ID for the
> lower-numbered user.  Blanking out /etc/subuid and /etc/subgid caused
> deluser to behave as normal.
> 
> According to login.defs(5), the default range of subuids starts at 10.
> If you're using UIDs over 10 for normal users then you probably want to
> change that (or find a way to disable subordinate user-IDs entirely).
> 
> -- 
> Ben Harris, University of Cambridge Information Services.
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

Bug#868568: Possible cause of deluser problem: subordinate user IDs

[Ben Harris]

I ran into a problem very similar to the one described in Debian bug 
868568: deleting a user with a UID < 10 failed because of a process 
that was running as a user with a UID >= 10.  It turned out to be 
because the larger user ID was recorded in /etc/subuid as a subordinate 
user-ID for the lower-numbered user.  Blanking out /etc/subuid and 
/etc/subgid caused deluser to behave as normal.


According to login.defs(5), the default range of subuids starts at 10. 
If you're using UIDs over 10 for normal users then you probably want 
to change that (or find a way to disable subordinate user-IDs entirely).


--
Ben Harris, University of Cambridge Information Services.

Bug#1006945: please consider supporting wildcards

[Marc Haber]

Package: debhelper
Version: 13.6
Severity: wishlist
File: /usr/bin/dh_link

Hi,

this is my adduser.links:
usr/share/man/da/man8/adduser.8.gz usr/share/man/da/man8/addgroup.8.gz
usr/share/man/da/man8/deluser.8.gz usr/share/man/da/man8/delgroup.8.gz
usr/share/man/de/man8/adduser.8.gz usr/share/man/de/man8/addgroup.8.gz
usr/share/man/de/man8/deluser.8.gz usr/share/man/de/man8/delgroup.8.gz
usr/share/man/es/man8/adduser.8.gz usr/share/man/es/man8/addgroup.8.gz
usr/share/man/es/man8/deluser.8.gz usr/share/man/es/man8/delgroup.8.gz
usr/share/man/fr/man8/adduser.8.gz usr/share/man/fr/man8/addgroup.8.gz
usr/share/man/fr/man8/deluser.8.gz usr/share/man/fr/man8/delgroup.8.gz
usr/share/man/it/man8/adduser.8.gz usr/share/man/it/man8/addgroup.8.gz
usr/share/man/it/man8/deluser.8.gz usr/share/man/it/man8/delgroup.8.gz

I think you get the idea.

Would it not be nice to be able to write instead:
usr/share/man/*/man8/adduser.8.gz usr/share/man/*/man8/addgroup.8.gz
usr/share/man/*/man8/deluser.8.gz usr/share/man/*/man8/delgroup.8.gz

or even
usr/share/man/*/man8/adduser.8.gz usr/share/man/*/man8/
usr/share/man/*/man8/deluser.8.gz usr/share/man/*/man8/

Instead?

Greetings
Marc

Bug#1006944: transition: proj

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
Control: block -1 by 998833
Control: forwarded -1 https://release.debian.org/transitions/html/auto-proj.html

For the Debian GIS team I'd like to transition to PROJ 9.

Unlike previous transitions, no major breaking changes were introduced.

Everything except mysql-workbench built successfully as summarized below.


Transition: proj

 libproj22 (8.2.1-1) -> libproj25 (9.0.0-1~exp2)

The status of the most recent rebuilds is as follows.

 atlas-ecmwf (0.27.0-1) OK
 gammaray(2.11.2-2) OK
 libgeotiff  (1.7.0-2)  OK
 mshr(2019.2.0~git20200924.c27eb18+dfsg1-7) OK
 octave-octproj  (2.0.1-5)  OK
 osm2pgsql   (1.6.0+ds-1)   OK
 pdl (1:2.076-1)OK
 proj-rdnap  (2008+2018-5)  OK
 python-pyproj   (3.3.0-2)  OK
 spatialite  (5.0.1-2)  OK
 survex  (1.4.2-1)  OK
 xygrib  (1.2.6.1-1)OK

 gdal(3.4.1+dfsg-1) OK
 gnudatalanguage (1.0.1-3)  OK
 librasterlite2  (1.1.0~beta1-2)OK
 magics++(4.10.1-1) OK
 python-cartopy  (0.20.2+dfsg-1)OK
 spatialite-tools(5.0.1-1)  OK
 xastir  (2.1.6-4)  OK

 cdo (2.0.4-1)  OK
 grass   (7.8.7-1)  OK
 mapnik  (3.1.0+ds-1)   OK
 mapserver   (7.6.4-2)  OK
 merkaartor  (0.19.0+ds-2)  OK
 metview (5.14.1-1) OK
 mysql-workbench (8.0.26+dfsg-1)FTFBS (#998833)
 ncl (6.6.2-10) OK
 openorienteering-mapper (0.9.5-3)  OK
 pdal(2.3.0+ds-2)   OK
 postgis (3.2.1+dfsg-1) OK
 qmapshack   (1.16.1-1) OK
 r-cran-rgdal(1.5-28+dfsg-1)OK
 r-cran-sf   (1.0-6+dfsg-1) OK
 r-cran-terra(1.5-21-2) OK
 saga(7.3.0+dfsg-7) OK
 spatialite-gui  (2.1.0~beta1-1)OK
 sumo(1.12.0+dfsg1-1)   OK
 vtk7(7.1.1+dfsg2-10.1) OK
 vtk9(9.1.0+really9.1.0+dfsg2-3)OK

 freecad (0.19.4+dfsg1-1)   OK
 qgis(3.22.4+dfsg-3)OK
 r-cran-lwgeom   (0.2-8-1)  OK
 therion (6.0.5-2)  OK


Kind Regards,

Bas

Bug#1006943: eigen3: freecad FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:eigen3
Version: 3.4.0-2
Control: tags -1 + patch

--

Dear maintainer,
freecad fails to build on ppc64el :
https://buildd.debian.org/status/fetch.php?pkg=freecad&arch=ppc64el&ver=0.19.4%2Bdfsg1-1&stamp=1646410969&raw=0

This bug is due to gcc failing in eigen3. Some related links :
https://bugzilla.redhat.com/show_bug.cgi?id=1996330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059

Ubuntu used a workaround mentionned in the first link for eigen3 :
https://launchpadlibrarian.net/578678112/eigen3_3.4.0-2ubuntu1_3.4.0-2ubuntu2.diff.gz

I used it and freecad builds fine then.
Could you consider using the patch which seems the easiest workaround
for now ?

Regards,


F.


signature.asc
Description: PGP signature

Bug#1006942: safeeyes: Safeeyes no longer seems to appears in the KDE/Plasma system tray

[Jonas Andradas]

Package: safeeyes
Version: 2.1.3-1
Severity: minor
X-Debbugs-Cc: j.andra...@gmail.com

Dear Maintainer,

I noticed that fairly recently (unfortunately, cannot exactly be sure when or
after which package update), safeeyes does not seem appear anymore in
KDE/Plasma system tray. It is not shown on the system tray, neither in the
"visible" elements nor in the "box" that has the hidden icons.

Accessing the "Configure System Tray" setting, different entries appear for
"Application Status" (Bluetooth active device, flameshot, KGpg, etc.),
"Hardware Control" (audio volume, battery, disks&devices, display
configuration, etc.), "System Services" (backup status, clipboard, disk
quota...) and "Miscellaneous" (which in my case shows kate sessions and weather
report). However, safeeyes does not seem to appear there, which makes me think
somehow it is not recognized by KDE/Plasma as something to be shown on the
system tray.

Before observing this behavior, I had saafeeyes on the system tray, to be able
to postpone or skip the next break, quit safeeyes, etc.

I am raising the bug in safeeyes as I speculate it is not announcing itself to
KDE/Plasma in the way these expect it to be there. However, if the bug should
be in KDE/Plasma, please feel free to move it there (if possible) or ask me to
report it under the appropriate component.

The versions of Plasma workspace/desktop I currently have installed are the
following ones:

plasma-workspace: 4:5.24.2-2
plasma-desktop: 4:5.24.2-1

Best Regards,
Jonas.


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

Kernel: Linux 5.16.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
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 safeeyes depends on:
ii  gir1.2-gtk-3.03.24.31-1
ii  python3   3.9.8-1
ii  python3-babel 2.8.0+dfsg.1-7
ii  python3-croniter  1.0.15-3
ii  python3-dbus  1.2.18-3+b1
ii  python3-gi3.42.0-3
ii  python3-psutil5.9.0-1
ii  python3-xlib  0.29-1

Versions of packages safeeyes recommends:
pn  gir1.2-appindicator3-0.1  
ii  xprintidle0.2.4-2

safeeyes suggests no packages.

-- no debconf information

Bug#1002994: expat: CVE-2021-45960: A large number of prefixed XML attributes on a single tag can crash libexpat (troublesome left shifts by >=29 bits in function storeAtts)

[Carlos Rodriguez]

Hi Laszlo,

Thank you so much!


Regards,

Carlos Rodriguez-Fernandez
Principal Software Engineer

www.healthtrio.com


> On Mar 8, 2022, at 9:37 AM, László Böszörményi (GCS)  wrote:
> 
> Hi Carlos,
> 
> On Tue, Mar 8, 2022 at 4:51 PM Carlos Rodriguez
>  wrote:
>> I see that the commit 
>> https://github.com/libexpat/libexpat/commit/0adcb34c49bee5b19bd29b16a578c510c23597ea
>>  is present in the branches corresponding to the expat version >=2.4.3. At 
>> the same time, I see that Debian reported the issue fixed in 
>> https://security-tracker.debian.org/tracker/CVE-2021-45960, in the versions 
>> 2.2.0-2+deb9u5, 2.2.6-2+deb10u3 and 2.2.10-2+deb11u2.
>> 
>> I’m having a hard time seeing how the fix was ported to earlier versions of 
>> expat. Could you please point me to where those fixes were ported?
> You can also check who did the actual update. For 2.2.10-2+deb11u2.
> [1] it's Salvatore Bonaccorso and for 2.2.6-2+deb10u3 [2] it's him
> again. But I can answer your question as well. You can get the
> corresponding debian files, expat_2.2.10-2+deb11u2.debian.tar.xz [3]
> and expat_2.2.6-2+deb10u3.debian.tar.xz [4].
> For example, if you download the former, under debian/patches/ you
> will find the backported patches. File naming follows the commit
> messages. That is, for this commit it's the
> lib-Detect-and-prevent-troublesome-left-shifts-in-fu.patch file.
> 
> Regards,
> Laszlo/GCS
> [1] 
> https://tracker.debian.org/news/1306825/accepted-expat-2210-2deb11u2-source-into-proposed-updates-stable-new-proposed-updates/
> [2] 
> https://tracker.debian.org/news/1306839/accepted-expat-226-2deb10u3-source-into-oldstable-proposed-updates-oldstable-new-oldstable-proposed-updates/
> [3] http://snapshot.debian.org/package/expat/2.2.10-2%2Bdeb11u2/
> [4] http://snapshot.debian.org/package/expat/2.2.6-2%2Bdeb10u3/

Bug#926262: adduser: deluser uses mount without depending on it

[Marc Haber]

Control: tags -1 confirmed
thanks

On Tue, Apr 02, 2019 at 08:21:38PM +0200, gregor herrmann wrote:
> Maybe adding a dependency has been discussed and dismissed earlier
> already, but on first look it seems to me that it would be warranted.

I would prefer to detect whether mount is present and to emit a warning.
The --remove-home options are rarely used and I'd indeed like to avoid
the dependency.

Greetings
Marc

Bug#1006938: docker.io lacks buildx

[Shengjing Zhu]

Control: reassign -1 wnpp
Control: merge 989917 -1

On Tue, Mar 8, 2022 at 11:27 PM Heinrich Schuchardt  wrote:
>
> Package: docker.io
> Version: 20.10.11+dfsg1-2
> Severity: wishlist
>
> buildx is a CLI plugin for docker, see
> https://docs.docker.com/buildx/working-with-buildx/,
> https://github.com/docker/buildx/. It is used by many build scripts for
> Docker tools. It would be great to have it available in Debian.

Please read https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989917

-- 
Shengjing Zhu

Bug#1006941: checkname logic twisted

[Marc Haber]

Package: adduser
Version: 3.118
Severity: important

Hi,

the logic of the sub checkname in adduser should be revisited and
checked, it looks wrong to first check for a hardcoded regex and THEN
check for the configurable regex.

Greetings
Marc

Bug#1002994: expat: CVE-2021-45960: A large number of prefixed XML attributes on a single tag can crash libexpat (troublesome left shifts by >=29 bits in function storeAtts)

[GCS]

Hi Carlos,

On Tue, Mar 8, 2022 at 4:51 PM Carlos Rodriguez
 wrote:
> I see that the commit 
> https://github.com/libexpat/libexpat/commit/0adcb34c49bee5b19bd29b16a578c510c23597ea
>  is present in the branches corresponding to the expat version >=2.4.3. At 
> the same time, I see that Debian reported the issue fixed in 
> https://security-tracker.debian.org/tracker/CVE-2021-45960, in the versions 
> 2.2.0-2+deb9u5, 2.2.6-2+deb10u3 and 2.2.10-2+deb11u2.
>
> I’m having a hard time seeing how the fix was ported to earlier versions of 
> expat. Could you please point me to where those fixes were ported?
 You can also check who did the actual update. For 2.2.10-2+deb11u2.
[1] it's Salvatore Bonaccorso and for 2.2.6-2+deb10u3 [2] it's him
again. But I can answer your question as well. You can get the
corresponding debian files, expat_2.2.10-2+deb11u2.debian.tar.xz [3]
and expat_2.2.6-2+deb10u3.debian.tar.xz [4].
For example, if you download the former, under debian/patches/ you
will find the backported patches. File naming follows the commit
messages. That is, for this commit it's the
lib-Detect-and-prevent-troublesome-left-shifts-in-fu.patch file.

Regards,
Laszlo/GCS
[1] 
https://tracker.debian.org/news/1306825/accepted-expat-2210-2deb11u2-source-into-proposed-updates-stable-new-proposed-updates/
[2] 
https://tracker.debian.org/news/1306839/accepted-expat-226-2deb10u3-source-into-oldstable-proposed-updates-oldstable-new-oldstable-proposed-updates/
[3] http://snapshot.debian.org/package/expat/2.2.10-2%2Bdeb11u2/
[4] http://snapshot.debian.org/package/expat/2.2.6-2%2Bdeb10u3/

Bug#730107: adduser --system and addgroup --system should ignore remote directory services

[Marc Haber]

Control: tags -1 wontfix
thanks

On Mon, Dec 16, 2013 at 04:13:26PM +0100, Harald Dunkel wrote:
> - I agree that nsswitch.conf is of no help here. The suggestion of
>   this bug report is to ignore remote directory services. Obviously
>   this implies to bypass nsswitch.conf and to read&write /etc/passwd
>   and the others directly, if --system is set.

Adduser uses useradd to do its work. I don't think it would be wise to
special case around the low level tools. Please discuss this with the
shadow maintainers, and after they have come up with a fix adduser might
follow or not.

Please consider refering to the technical committee if you feel strongly
about this.

Greetings
Marc

Bug#723572: adduser: Invoking adduser twice with the same parameters yields exit status 1 for non system users.

[Marc Haber]

Control: severity -1 minor
thanks

On Tue, Sep 17, 2013 at 04:23:48PM +0200, mi...@openend.se wrote:
> The adduser man page says this about exit status:
> EXIT VALUES
>0  The user exists as specified. This can have  2  causes:  The
>   user  was created by adduser or the user was already present
>   on the system before adduser was  invoked.  If  adduser  was
>   returning  0  , invoking adduser a second time with the same
>   parameters as before also returns 0.
> 
> However, running the command twice with the same parameters for a non system
> user will yield exit code 1:

That's a documentation error, only adduser --system is designed to be
idempotent.

Greetings
Marc

Bug#1006039: pytest-xdist: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

[Scott Talbert]

Control: forwarded -1 https://github.com/pytest-dev/pytest-xdist/issues/735

On Tue, 22 Feb 2022, Lucas Nussbaum wrote:


I'm not able to reproduce this, at least locally in sbuild.  Possibly some
transient error in unstable?  Can you re-try?


Hi Scott,

I can reproduce it, but this looks like a random failure. Building in a
loop, I get:
log.1:Status: attempted
log.2:Status: successful
log.3:Status: successful
log.4:Status: successful
log.5:Status: attempted


Ah, random failures.  The best kind.  ;)

Since the build succeeds more than 50% of the time, can we lower the 
severity?


Scott

Bug#440801: adduser: Option --firstuid no longer applied to GID's of new users' user

[Marc Haber]

On Wed, Nov 05, 2008 at 10:22:59AM +0200, George Karaolides wrote:
> I think that where usergroups are used, the --firstuid option should
> also apply to the GID of the new user as it did in the adduser command
> shipped in previous versions of Debian.

I do not particularly like the idea of overloading the first_U_id
option. Would it help you to have firstgid and lastgid options?

Greetings
Marc

Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file

[Rhonda D'Vine]

Yes indeed, i had to fix it through the module. Sorry that I wasn't clear on 
that part. Likely this should be changed to be a bug in the module interface 
since the frontend shouldn't have to know too much about what's allowed or not 
in the fields, the module should give the frontend error messages accordingly, 
but I hadn't had the time to look up if that's possible to differentiate.

Thanks for asking for clarification,
Rhonda

Am 8. März 2022 16:47:41 MEZ schrieb Lester Hightower 
:
>Hi Rhonda,
>
>I am happy that you found and fixed your problem. I suspect, however, that
>the code that you changed was not actually kpcli code but, instead,
>File::KeePass code -- the module that kpcli uses to read and write keepass
>files. https://metacpan.org/pod/File::KeePass
>
>Can you confirm that I am correct about that?
>
>Thanks,
>
>--
>Lester
>
>
>On Tue, Mar 8, 2022 at 10:33 AM Rhonda D'Vine  wrote:
>
>>   Hi,
>>
>> $buffer =~ s/\e//g;
>>
>>  .. this was all that was needed to fix my mess.  Though, kpcli for
>> obvious reasons shouldn't be able to write broken data it can't read
>> again, so I keep seeing this as a severe bug in the code which can lead
>> to data loss for people who aren't familiar enough with perl or who
>> don't have friends who support them to dig down the issue.
>>
>>  The above line was a quick fix for my case, I'm uncertain if it might
>> appear to others in other ways, but this clearly goes against the
>> principle of robustness.
>>
>>  Upstream is at 3.6 in the meantime, I'm willing to update it now that I
>> digged a bit further into it.  If I don't hear back in the next few days
>> I propose an NMU for it, as thanks for having it around in the first
>> place. :)
>>
>>  Enjoy,
>> Rhonda [happy again]
>>
>>
>> * Rhonda D'Vine  [2022-03-08 16:19:46 CET]:
>> >Hi,
>> >
>> >  I managed to find the culprit With A Little Help From My Friends[tm]. I
>> > used Data::Dumper before the content got passed to XML::Parser, and it
>> > turned out that there is an Escape character (0x1b, ^[) in a comment
>> > field.
>> >
>> >  kpcli seems to have accepted this when the comment was pasted and
>> > stored it happily, but was unable to re-read the file written with that
>> > in it.
>> >
>> >  I'm currently fiddling around to delete that escape character on load
>> > time and have kpcli start, allowing me to save it without the escape
>> > character, hopefully allowing to re-read it afterwards.
>> >
>> >  I'll keep you posted,
>> > Rhonda
>>
>> --
>> Fühlst du dich mutlos, fass endlich Mut, los  |
>> Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
>> Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
>> Fühlst du dich haltlos, such Halt und lass los|
>>
>>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#1006940: Why still Alioth at main page

[Geert Stappers]

Package: sso.debian.org


Hello SSO maintainers,


Currently, 2022-03-08, has https://sso.debian.org/ two large icons.

One is for Alioth, Alioth account certificates, and links
to https://sso.debian.org/alioth/certs/

For which reason is there such large icon for Alioth?


Or: Why not remove it?   After all is Alioth been shutdown.

 
Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1002994: expat: CVE-2021-45960: A large number of prefixed XML attributes on a single tag can crash libexpat (troublesome left shifts by >=29 bits in function storeAtts)

[Carlos Rodriguez]

Hello Laszlo,
 
I see that the commit 
https://github.com/libexpat/libexpat/commit/0adcb34c49bee5b19bd29b16a578c510c23597ea
 is present in the branches corresponding to the expat version >=2.4.3. At the 
same time, I see that Debian reported the issue fixed in 
https://security-tracker.debian.org/tracker/CVE-2021-45960, in the versions 
2.2.0-2+deb9u5, 2.2.6-2+deb10u3 and 2.2.10-2+deb11u2.
 
I’m having a hard time seeing how the fix was ported to earlier versions of 
expat. Could you please point me to where those fixes were ported?
 
Thank you,

Carlos Rodriguez-Fernandez
Principal Software Engineer

www.healthtrio.com

Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file

[Lester Hightower]

Hi Rhonda,

I am happy that you found and fixed your problem. I suspect, however, that
the code that you changed was not actually kpcli code but, instead,
File::KeePass code -- the module that kpcli uses to read and write keepass
files. https://metacpan.org/pod/File::KeePass

Can you confirm that I am correct about that?

Thanks,

--
Lester


On Tue, Mar 8, 2022 at 10:33 AM Rhonda D'Vine  wrote:

>   Hi,
>
> $buffer =~ s/\e//g;
>
>  .. this was all that was needed to fix my mess.  Though, kpcli for
> obvious reasons shouldn't be able to write broken data it can't read
> again, so I keep seeing this as a severe bug in the code which can lead
> to data loss for people who aren't familiar enough with perl or who
> don't have friends who support them to dig down the issue.
>
>  The above line was a quick fix for my case, I'm uncertain if it might
> appear to others in other ways, but this clearly goes against the
> principle of robustness.
>
>  Upstream is at 3.6 in the meantime, I'm willing to update it now that I
> digged a bit further into it.  If I don't hear back in the next few days
> I propose an NMU for it, as thanks for having it around in the first
> place. :)
>
>  Enjoy,
> Rhonda [happy again]
>
>
> * Rhonda D'Vine  [2022-03-08 16:19:46 CET]:
> >Hi,
> >
> >  I managed to find the culprit With A Little Help From My Friends[tm]. I
> > used Data::Dumper before the content got passed to XML::Parser, and it
> > turned out that there is an Escape character (0x1b, ^[) in a comment
> > field.
> >
> >  kpcli seems to have accepted this when the comment was pasted and
> > stored it happily, but was unable to re-read the file written with that
> > in it.
> >
> >  I'm currently fiddling around to delete that escape character on load
> > time and have kpcli start, allowing me to save it without the escape
> > character, hopefully allowing to re-read it afterwards.
> >
> >  I'll keep you posted,
> > Rhonda
>
> --
> Fühlst du dich mutlos, fass endlich Mut, los  |
> Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
> Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
> Fühlst du dich haltlos, such Halt und lass los|
>
>

Bug#1006939: .so links not converted for directly installed manpage

[Marc Haber]

Package: debhelper
Version: 13.6
Severity: normal
File: /usr/bin/dh_installman

Hi,

I have a package, adduser, that is Debian native and therefore the
manpages are installed directly from the doc directory:

[212/5303]mh@fan:~/packages/adduser/adduser (master *% u+5) $ cat 
debian/manpages
doc/adduser.8
doc/addgroup.8
doc/adduser.*.8
[213/5304]mh@fan:~/packages/adduser/adduser (master *% u+5) $

addgroup.8 contains a .so link:
.so man8/adduser.8

This ends up in the package verbatim as an so link instead of being
converted to a symlink as the docs suggest.

In addition, I would love to have the respective symlinks to be also
established for the respective translated manual pages, preferably
without having to list every language in a debhelper config file (prone
to be forgotten for new translation) and also without having to have a
dedicated .so link file for every translation (will also be forgotten
for new translations).

Could that be possible in a future version, so cut down on length of my
debian/links file and to reduce the possibility of forgotten symlinks?

Greetings
Marc

Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file

[Rhonda D'Vine]

  Hi,

$buffer =~ s/\e//g;

 .. this was all that was needed to fix my mess.  Though, kpcli for
obvious reasons shouldn't be able to write broken data it can't read
again, so I keep seeing this as a severe bug in the code which can lead
to data loss for people who aren't familiar enough with perl or who
don't have friends who support them to dig down the issue.

 The above line was a quick fix for my case, I'm uncertain if it might
appear to others in other ways, but this clearly goes against the
principle of robustness.

 Upstream is at 3.6 in the meantime, I'm willing to update it now that I
digged a bit further into it.  If I don't hear back in the next few days
I propose an NMU for it, as thanks for having it around in the first
place. :)

 Enjoy,
Rhonda [happy again]


* Rhonda D'Vine  [2022-03-08 16:19:46 CET]:
>Hi,
> 
>  I managed to find the culprit With A Little Help From My Friends[tm]. I
> used Data::Dumper before the content got passed to XML::Parser, and it
> turned out that there is an Escape character (0x1b, ^[) in a comment
> field.
> 
>  kpcli seems to have accepted this when the comment was pasted and
> stored it happily, but was unable to re-read the file written with that
> in it.
> 
>  I'm currently fiddling around to delete that escape character on load
> time and have kpcli start, allowing me to save it without the escape
> character, hopefully allowing to re-read it afterwards.
> 
>  I'll keep you posted,
> Rhonda

-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file

[Rhonda D'Vine]

   Hi,

 I managed to find the culprit With A Little Help From My Friends[tm]. I
used Data::Dumper before the content got passed to XML::Parser, and it
turned out that there is an Escape character (0x1b, ^[) in a comment
field.

 kpcli seems to have accepted this when the comment was pasted and
stored it happily, but was unable to re-read the file written with that
in it.

 I'm currently fiddling around to delete that escape character on load
time and have kpcli start, allowing me to save it without the escape
character, hopefully allowing to re-read it afterwards.

 I'll keep you posted,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#817130: README.Debian refers to non-existent /etc/default/pulseaudio

[Jean-Michel Vourgère]

An update would be welcome, indeed.

I have a clock that plays a sound every hour. It is run from the crontab, and
I need pulse audio when no user is logged in.

This is just an example where the use of a system-wide pulseaudio instance
comes handy.

For the reference, here's the leny file pointed at.# Start the PulseAudio sound server in system mode.
# (enables the pulseaudio init script - requires that users be in the
# pulse-access group)
# System mode is not the recommended way to run PulseAudio as it has some
# limitations (such as no shared memory access) and could potentially allow
# users to disconnect or redirect each others' audio streams. The
# recommended way to run PulseAudio is as a per-session daemon. For GNOME/KDE/
# Xfce sessions in Ubuntu Lucid/10.04, /etc/xdg/autostart/pulseaudio.desktop
# handles this function of automatically starting PulseAudio on login, and for
# it to work correctly your user must *not* have "autospawn = no" set in
# ~/.pulse/client.conf (or in /etc/pulse/client.conf). By default, autospawn
# is enabled. For other sessions, you can simply start PulseAudio with
# "pulseaudio --daemonize".
# 0 = don't start in system mode, 1 = start in system mode
PULSEAUDIO_SYSTEM_START=0

# Prevent users from dynamically loading modules into the PulseAudio sound
# server. Dynamic module loading enhances the flexibility of the PulseAudio
# system, but may pose a security risk.
# 0 = no, 1 = yes
DISALLOW_MODULE_LOADING=1

Bug#1006938: docker.io lacks buildx

[Heinrich Schuchardt]

Package: docker.io
Version: 20.10.11+dfsg1-2
Severity: wishlist

buildx is a CLI plugin for docker, see
https://docs.docker.com/buildx/working-with-buildx/,
https://github.com/docker/buildx/. It is used by many build scripts for
Docker tools. It would be great to have it available in Debian.

Best regards

Heinrich

Bug#1006937: stable header for templates.pot

[Marc Haber]

Package: po-debconf
Version: 1.0.21+nmu1
Severity: normal

Hi,

since the advent of machine readable copyright files, my inner monk has
felt forced to pay more close attention to licensing of translations.
Oh, what a mess.

To make things easier for my translators, I put a nice header into
debian/po/templates.pot, giving a meaningful copyright entry, stating
explicitly that a translator might add herself there, and that it would
be nice if the translation would be put under the same license like the
package.

Imagine my surprise when debconf-updatepo replaced my nice header with
the usual blurb of SOME DESCRIPTIVE TITLE and Copyright (C) YEAR THE
PACKAGE'S COPYRIGHT HOLDER again.

Can po-debconf in some way be convinced to leave the leading comments of
a file alone when updating the contents?

This might be a property of a different program since I had a program
translation de-beautified the same way, but I don't enough about all
this po-pot-translation business to correctly judge. Feel free to point
me in the correct direction please.

Greetings
Marc

Bug#1006936: Update symfony-finder to newer version

[Katharina Drexel]

Package: php-symfony-finder
Version: 5.4.6+dfsg-1
Severity: normal

Hello,

for a project I need some actual php-symfony* packages which partly depend on 
php-symfony-finder. The actual debian package uses upstream version 5.4.6. For 
going ahead I built a package from version 6.0.3 (
https://github.com/sunflowerbofh/finder/tree/debian).  It would be nice if this 
or a newer version could get into the debian package.

Thanks+Regards
Katharina

Bug#969531: avahi-daemon: retrieving printer info blocks printing until shutdown

[Brian Potkin]

On Fri 04 Sep 2020 at 15:23:32 +0200, Michael Hatzold wrote:

> OKI printer B432, conected via USB, no network cable attached.

The B432 is an IPP device; it very likely understands the IPP-over-USB
protocol.

When connected to USB the ipp-usb service is started and ipp-usb takes
control of the only available USB interface.
> 
>* What led up to the situation?
> Want to print
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> select document, start print dialog, select my printer (config was done via
> CUPS);

Your manually configured iprinter is not being allowed to access the
USB interface. This is not a bug. Please see sections 14, 15 and 16 at

  https://wiki.debian.org/CUPSDriverlessPrinting
  
> Now the printer appears a second time in the list with a different entry. If I
> select this new entry, I am asked for CUPS PW twice, then it (a deamon,
> whatever) starts retriving printer info which *never* completes.

That was a GTK bug at the time. 

>* What was the outcome of this action?
> Either way, selecting my own entry or the new one made by the daemon, the
> printer does nothing (I waited up to 45 minutes... until I shutdown my system.
> Them during shutdown, there is a pause during which the document gets printed.

Pass.
 
>* What outcome did you expect instead?
> I want the printer to print after I sent the job.
> 
> 
> *** End of the template - remove these template lines ***
> 
> There is a workaround:
> 
> In the original /etc/avahi/avahi-daemon.conf file, there is an entry "#allow-
> interfaces=eth0".
> Changing and uncommenting it to "allow-interfaces=eth9" solves the problem
> (printer not conected via ethXYZ, though). 

"allow-interfaces=eth9" effectively prevents avahi-daemon from working
on all interfaces, including the loopback interface. ipp-usb is exposed
on the loopback interface by default.

avahi-daemon is now completely crippled; it may as well be purged from
the system.

>Therefor I assume this hides a bug
> or an improper default configuration.

There isn't any bug in avahi-daemon.

Regards,

Brian.

Bug#1006935: samba on bullseye:i386 fails for logging and sockets

[dbn-bugs]

Package: samba
Version: 2:4.13.13+dfsg-1~deb11u3
Architecture: i386

we're successfully running samba 2:4.9.5+dfsg-5+deb10u3 in a container
with devuan beowulf (debian buster) since several months, but decides to
migrate all containers to chimaera (bullseye), but this fails for
several reasons.

because the devuan-people doesn't change anything in the
samba-debian-package, they told me to forward the bug towards debian...


1.
having "bind interfaces only = yes" in config, smbd errors out with
"INTERNAL ERROR: open_sockets_smbd()" and "open_sockets_smbd: No sockets
available to bind to"

deactivating this config-entry makes smbd start normally.

2.
having "log file = /var/log/samba/%m.log" in config is completly
ignored. No such files are written, even when setting /varlog/samba to
mode 1777 and having parent dirs all at least at mode 751
(no workaround found)

further tests are stopped for now, because we need the system working,
but it seems, that the performance on network was worse than before
during initial connects.


using the same config with beowulf(buster)-container and samba
2:4.9.5+dfsg-5+deb10u3 works fine. (fortunately we could switch back to
the old container easily). Anything else but the inner system of the
container are equal!

because devuan-people already asked: the "interfaces"-config contains
multiple ip-addresses including 127.0.0.1

the network-config of the container is completed before the container
starts any program (then connecting to it via nsenter)

and as already said: it's really the same as before and now, running the
beowulf(buster)-container...


if there're any additional infos are needed we'll try to give them, any
certain tests with the buggy samba may take a bit time, because we can't
switch the container at every time, but have to wait for evening or
weekend, to really have equal conditions.

regards

d.

Bug#486585: adduser/homedir-permission isn't set the first time running debconf

[Marc Haber]

Control: outlook -1 close end 2022
Control: tags -1 moreinfo
thanks

On Wed, Nov 23, 2011 at 11:36:55AM +0100, Marc Haber wrote:
> No idea. Is it still reproducible in current versions of Debian?

I intend to close this by the end of 2022 unless somebody shows that
this is still reproducible on current systems.

Greetings
Marc

Bug#1006744: open-vm-tools core dump on debian 10

[Bernd Zeimetz]

Hi Girish,

could you give 11.3.5 from buster-backports-sloppy a try please?
If that doesn't fix it, 12.0 was released recently, but that will take a 
bit until packages are ready. You could download it from gthub and 
build/test it, though.


Also - please note that bullseye is the current stable release.


Bernd


On 2022-03-08 11:18, Chilukuri, Girish - Dell Team wrote:

Hi Bernd,
   Debian buster we are using.

Thanks,
 Girish


Internal Use - Confidential

-Original Message-
From: Bernd Zeimetz 
Sent: Tuesday, March 8, 2022 2:13 PM
To: Chilukuri, Girish - Dell Team; 1006...@bugs.debian.org
Cc: Singh, Harmeet - Dell Team; Paturu, Santhosh - Dell Team
Subject: Re: Bug#1006744: open-vm-tools core dump on debian 10


[EXTERNAL EMAIL]

Hi,

did you actually install the debug packages? The backtrace doesn't
look like that.
Please do so.

https://urldefense.com/v3/__https://wiki.debian.org/HowToGetABacktrace__;!!LpKI!0puEtOoAByFgLNggB_VMDeU15wGT9ZJdww_v-PEituwvNiosvGG9pv-_z76wY7MGw9htYJ8$
[wiki[.]debian[.]org]

Which release are you using? Bullseye? Or something else? What is
"your product"?


Thanks,

Bernd

On 2022-03-08 07:37, Chilukuri, Girish - Dell Team wrote:

Hi Bernd,
Below is the full backtrace from all threads from the core
file.

gdb /usr/bin/vmtoolsd rp_core.417

GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later


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

Find the GDB manual and other documentation resources online at:

.


For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/vmtoolsd...(no debugging symbols
found)...done.
[New LWP 417]
[New LWP 1105]
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/usr/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/vmtoolsd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
120 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or
directory.
[Current thread is 1 (Thread 0x7f321f095780 (LWP 417))]
(gdb) where
#0  0x7f321f589206 in __strlen_sse2 () at
../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x7f321f56b475 in __GI___fputs_unlocked
(str=0x7f321e2f7ac8 , fp=fp@entry=0x55d222325690)
at iofputs_u.c:34
#2  0x7f321f5e4868 in __GI___vsyslog_chk (pri=,
flag=1, fmt=0x7f321edc083c "%s.", ap=0x7ffd36e1eda0)
at ../misc/syslog.c:205
#3  0x7f321f5e4dff in __syslog_chk (pri=,
flag=, fmt=)
at ../misc/syslog.c:129
#4  0x7f321edbb1db in Audit_EventV () at /lib/libvgauth.so.0
#5  0x7f321edbb2a4 in Audit_Event () at /lib/libvgauth.so.0
#6  0x7f321edb7f95 in VGAuth_AuditEvent () at /lib/libvgauth.so.0
#7  0x7f321edb6d05 in VGAuth_ValidateUsernamePassword () at
/lib/libvgauth.so.0
#8  0x7f321edd1cf1 in  () at
/usr/lib/open-vm-tools/plugins/common/libvix.so
#9  0x7f321edd22e3 in  () at
/usr/lib/open-vm-tools/plugins/common/libvix.so
#10 0x7f321edd25d9 in  () at
/usr/lib/open-vm-tools/plugins/common/libvix.so
#11 0x7f321edd81f6 in  () at
/usr/lib/open-vm-tools/plugins/common/libvix.so
#12 0x7f321edcf2cb in  () at
/usr/lib/open-vm-tools/plugins/common/libvix.so
#13 0x7f3221a5f664 in RpcChannel_Dispatch () at
/lib/libvmtools.so.0
#14 0x7f3221a611de in  () at /lib/libvmtools.so.0
#15 0x7f3221a61aa4 in  () at /lib/libvmtools.so.0
#16 0x7f32218dfe98 in g_main_context_dispatch () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x7f32218e0288 in  () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0

#18 0x7f32218e0582 in g_main_loop_run () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x55d221850bb6 in  ()
#20 0x55d22184fcc7 in main ()
(gdb) thread apply all bt

Thread 2 (Thread 0x7f321ed23700 (LWP 1105)):
#0  0x7f321f5df819 in __GI___poll (fds=0x55d22231b050, nfds=1,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f32218e01f6 in  () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0

#2  0x7f32218e031c in g_main_context_iteration () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f32218e0361 in  () at 
/lib/x86_64-l

Bug#1006934: php-solr: Please rebuild php-solr to fix dependencies

[Athos Ribeiro]

Package: php-solr
Version: 2.5.1+2.4.0-14
Severity: normal

Dear Maintainer,

As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006428,
dh-php was adjusted to stop injecting a bogus dependency in the dummy
-all-dev packages for php-curl-all-dev. Such dependency blocks php-solr
migration (and hence, it was removed from testing).

A simple rebuild of this package should be enough to pick-up the dh-php
changes and fix the bogus dependency issue.

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

Kernel: Linux 5.15.0-18-generic (SMP w/16 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.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 php-solr depends on:
ii  libc62.35-0ubuntu1
ii  libcurl4 7.81.0-1
iu  libxml2  2.9.12+dfsg-6
pn  php-common   
pn  php-xml  
pn  phpapi-20210902  

php-solr recommends no packages.

php-solr suggests no packages.

-- 
Athos Ribeiro

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Axel Beckert]

Hi Damien,

Damien Le Moal wrote:
> > Damien Le Moal wrote:
> >> In the bug report, I did not see a dmesg output for a failed boot. But I
> >> guess it is because the user cannot capture it.
> > 
> > Correct.
> 
> Could you try taking a video of the boot messages ?

Did that now.

https://noone.org/debian/Bug-Reports/1006149/DSCN5255.MOV

(82 MB, no debugging yet)

Note that this is from an IBM ThinkPad A31
(https://www.thinkwiki.org/wiki/Category:A31), not from a ThinkPad
T41 as with the original bug reporter, i.e. it's even a bit older.

> However, since things are working with 5.15, I would like to
> understand what is going on and which part of the device scan is
> failing. For that, booting with logging_level=7 (debug) and having
> the kernel messages would help.

Ok, did another one, this time with "debug loglevel=7" added on the
kernel commandline by editing it in GRUB:

https://noone.org/debian/Bug-Reports/1006149/DSCN5259.MOV

(94 MB, with debugging)

HTH. (Sorry for all that zooming out at the beginning of the videos.
For some reason my digital camera doesn't seem to use the same zoom
setting or maybe resolution for videos as the one it uses for pictures
(and hence also for the preview before starting the recording).

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

Bug#1006933: catdoc xls2csv converting dates and adding 4 years and 1 day

[Dr. Radu Wirth]

Package: catdoc
Version: 1:0.95-5

Debian distribution: bookworm
Linux 5.16.0-3-amd64 #1 SMP PREEMPT Debian 5.16.11-1 (2022-02-25) x86_64 
GNU/Linux
libc6 2.33-7

xls file with a column of dates (german format) with the content:

01.01.2000
01.01.2010
01.01.2020

xls2csv converting to tab separated file and date in iso format:

$ xls2csv -c $'\t' -q 0 -f '%Y-%m-%d' dates.xls > dates.tsv

the resulting file contains:

$ cat dates.tsv
2004-01-02
2014-01-02
2024-01-02

All converted dates got added 4 years and 1 day

Thank you
Best wishes

Bug#863751: Add --btrfs-subvolume-home option to adduser

[Marc Haber]

Hi,

On Tue, Mar 08, 2022 at 07:16:57PM +0900, Osamu Aoki wrote:
> I was thinking opt-in only.
> 
> I mean to add an opt-in --btrfs-subvolume-home option to adduser so
> the user can use this feature if he requests.  I didn't think beyond.
> (I didn't test it on non-btrfs system so I don't know the answer to
> your question.  Whoever specifies it in command line, he should know
> it.)

I had a sane default in mind. As times have changed and maintainer /
developer resources are scarce, adduser primarily sees itself as a
policy wrapper to help package maintainers to create their package
accounts in their maintainer scripts without violating policy. Offering
account creation capabilities to the local admin has been pushed into
the background in the last decades.

I'd say then if the local admin wants to use a feature that adduser
doesnt offer, they are free to use other tools such as useradd directly
to get what they want.

> As I come to think of this, since it is trivial to check FS of /home
> in adduser in advance by calling a basic shell command as:
> 
> ``` $ stat -f -c %T /home btrfs ``` , adding this feature as an
> automatic option for pertinent system is an interesting thought for
> adduser too.

I am reluctant to add filesystem specific code to adduser, as writing
automated tests is probably hard.

I would think more about adding this if having account-specific btrfs
subvolumes per _system_ account would be a valid feature to have AND if
useradd is smart enough to not error out or spew warnings if one tries
to create a btrfs subvolume on non-btrfs volumes. At th moment, I am not
convinced that this is worth spending developer / maintainer time on.

Would it help to have an "useradd-extra-options" command line option and
configuration file setting that causes their respective contents to
be added to useradd's command line verbatim? Which other commands would
need a respective foo-extra-options option?

Greetings
Marc

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

Bug#1006932: fontconfig: new upstream version 2.13.96 available

[Vincent Lefevre]

Source: fontconfig
Version: 2.13.1-4.2
Severity: wishlist

A new upstream version 2.13.96 is available.

Upstream says that "2.13.96 has some improvements around mutex lock",
so that it might fix bug 1006720 (though I could not find the cause
and could not reproduce the issue yet). Note that unless I have new
information, bug 1006720 could be closed at the same time as a new
release, even though the code hasn't changed much.

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

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

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

Bug#1006931: lintian: does not correctly show references to social contract items

[Timon Engelke]

Package: lintian
Version: 2.114.0
Severity: normal
Tags: upstream
X-Debbugs-Cc: deb...@timonengelke.de

Dear Maintainer,

In the "Please refer to..." section of detailed tag info, socially contract
items are not correctly displayed.
For example, for patch-not-forwarded-upstream, the output is

> Please refer to , Debian Developer's Reference section 3.1.4, Debian Policy
Manual section 4.3, and Bug#755153 for details.

In tags/p/patch-not-forwarded-upstream, the See-Also list contains "social
contract item 2" which is replaced by an empty string in the displayed list.


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

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

Versions of packages lintian depends on:
ii  binutils2.38-2
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+b1
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b8
ii  libclone-perl   0.45-1+b2
ii  libconfig-tiny-perl 2.28-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.27-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-1+b3
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.1
ii  libemail-address-xs-perl1.04-1+b4
ii  libencode-perl  3.16-1+b1
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+b8
ii  libperlio-utf8-strict-perl  0.009-1+b1
ii  libproc-processtable-perl   0.634-1+b1
ii  libsereal-decoder-perl  4.023+ds-1
ii  libsereal-encoder-perl  4.023+ds-1
ii  libsort-versions-perl   1.62-1
ii  libsyntax-keyword-try-perl  0.27-1
ii  libterm-readkey-perl2.38-1+b3
ii  libtext-glob-perl   0.11-2
ii  libtext-levenshteinxs-perl  0.03-4+b9
ii  libtext-markdown-discount-perl  0.13-1+b1
ii  libtext-xslate-perl 3.5.9-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b4
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b3
ii  liburi-perl 5.10-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1
ii  libyaml-libyaml-perl0.83+ds-1+b1
ii  lzip1.23-1
ii  lzop1.04-2
ii  man-db  2.10.1-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.34.0-3
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#1006928: librust-phf-shared+uncased-dev depends on package that is not in Debian.

[James McCoy]

Control: tag -1 pending

On Tue, Mar 08, 2022 at 11:40:21AM +, peter green wrote:
> The most recent upload of rust-phf-shared added a new feature package,
> librust-phf-shared+uncased-dev which depends on librust-uncased-0.9-dev
> 
> rust-uncased is not in Debian and I cannot find any evidence of an attempt
> to package it.

Thanks for the notice.  I've uploaded the uncased crate to NEW.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#584919: Some of the adduser.conf configuration options not present (in commented-out form) in installed /etc/adduser.conf

[Marc Haber]

On Mon, Jun 07, 2010 at 10:53:36AM -0400, Christian Hudon wrote:
> The installed /etc/adduser.conf file features most of the variables that
> can control adduser, at least in commented out form, together with an
> explanatory comment. This is really nice for the sysadmin, as it saves
> back and forth between the documentation and the configuration file.

I have changed the configuration files to have the option settings
commented out if they're the same as the default in the code.

> However, some adduser variables are not in that configuration file. It'd
> be nice if they could be added too, in commented-out form and with a
> short explanatory comment. At least, the ADD_EXTRA_GROUPS and
> EXTRA_GROUPS seem very useful and were unknown to this sysadmin before
> today, because they were not included in the /etc/adduser.conf file.
> >From a quick look, every configuration item after QUOTA_USER in the
> (5)adduser.conf manpage is not in the /etc/adduser.conf file.

According to git blame, the respective documentation was added to
adduser.conf in April of 2006, while adduser 3.102, which you have
reported this against, was released in January 2007. Any chance that you
just didn't accept the conffile prompt when you did the upgrade?

Anyway, I took the opportunity to revisit the adduser.conf and
deluser.conf files in git, there will be some changes in the next
upload.

Greetings
Marc

Bug#1006930: ovmf: X64 Exception Type - 06(#UD - Invalid Opcode)

[Timo Lindfors]

Package: ovmf
Version: 2020.11-2+deb11u1
Severity: important

Steps to reproduce:
1) virt-install --connect qemu:///session --name  
baremetal_template_debian_buster_uefi --ram 2048 --disk 
size=4,path=baremetal_template_debian_buster_uefi.img,format=raw,bus=scsi,discard=unmap,cache=unsafe
 --controller type=scsi,model=virtio-scsi --location 
http://deb.debian.org/debian/dists/buster/main/installer-amd64/ --os-variant 
debian10 --virt-type kvm --network user,model=virtio --controller 
usb,model=none --graphics none --transient --boot uefi --extra-args auto=true 
hostname=debian domain= console=ttyS0,115200n8 serial net.ifnames=0 
variant=buster

Expected results:
1) Debian installer starts

Actual results:
1) the following is printed:

Running text console command: virsh --connect qemu:///session console 
baremetal_template_debian_buster_uefi
Connected to domain 'baremetal_template_debian_buster_uefi'
Escape character is ^] (Ctrl + ])
 X64 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID -  


RIP  - 0003, CS  - 0038, RFLAGS - 00010246
RAX  - , RCX - , RDX - 
RBX  - , RSP - 7EFB7E28, RBP - 7EFB7E98
RSI  - 7E8EC798, RDI - 7EFCCF38
R8   - , R9  - 03041001, R10 - 003A
R11  - 7E8E9678, R12 - 7E8E9018, R13 - 0001
R14  - 8000F880, R15 - 8000F844
DS   - 0030, ES  - 0030, FS  - 0030
GS   - 0030, SS  - 0030
CR0  - 80010033, CR2 - , CR3 - 7EC01000
CR4  - 0668, CR8 - 
DR0  - , DR1 - , DR2 - 
DR3  - , DR6 - 0FF0, DR7 - 0400
GDTR - 7E9EDA98 0047, LDTR - 
IDTR - 7E522018 0FFF,   TR - 
FXSAVE_STATE - 7EFB7A80
 Can't find image information. 

I am guessing this is related to ovmf as the problem does not occur if
I downgrade ovmf to 2020.05-3~bpo+1.


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

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-11-amd64 (SMP w/8 CPU threads)
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

-- no debconf information

Bug#1006929: ITP: openjph -- High-throughput JPEG2000 image compression/decompression library

[Mathieu Malaterre]

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

* Package name: openjph
  Version : 0.8.2
  Upstream Author : aous72 (github)
* URL : https://github.com/aous72/OpenJPH
* License : BSD-2
  Programming Lang: C++
  Description : High-throughput JPEG2000 image compression/decompression 
library

Open source implementation of High-throughput JPEG2000 (HTJ2K), also
known as JPH, JPEG2000 Part 15, ISO/IEC 15444-15, and ITU-T T.814. Here,
we are interested in implementing the HTJ2K only, supporting features
that are defined in JPEG2000 Part 1 (for example, for wavelet transform,
only reversible 5/3 and irreversible 9/7 are supported).

 - HTJ2K is a very promising image compression algorithm meant to
   replace the original JEPG 2000 with a faster decompression speed.
 - Will be team maintained in Phototools

Bug#1006928: librust-phf-shared+uncased-dev depends on package that is not in Debian.

[peter green]

Package: librust-phf-shared+uncased-dev
Version: 0.10.0-2
Severity: serious
x-debbugs-cc: james...@debian.org

The most recent upload of rust-phf-shared added a new feature package,
librust-phf-shared+uncased-dev which depends on librust-uncased-0.9-dev

rust-uncased is not in Debian and I cannot find any evidence of an attempt
to package it. I have looked in the new queue, have looked through the mailing
lists for recent reject messages and have looked in the debcargo-conf git
repository.

Is there any intent to package rust-uncased or should the feature be dropped?

Bug#1006870: sdl12-compat: please make the build reproducible

[Simon McVittie]

On Tue, 08 Mar 2022 at 07:27:36 +, Chris Lamb wrote:
> Ah, whoops, looks like I screwed up in two ways here. I meant to write
> "then removes the *group* executable bits" and the patch should match:
> 
>   -override_dh_fixperms:
>   -dh_fixperms -Xusr/libexec/installed-tests
>   +execute_after_dh_fixperms:
>   +find debian -path "*/usr/libexec/installed-tests/*" -type f print0 
> | xargs -0r chmod g-x

I don't think that's right either, for two reasons:

1. We usually want to normalize permissions of installed files to 0755
   for executables and 0644 for non-executables, except in special cases
   (which is `chmod a+rX,u+w,go-w` in symbolic notation);
2. If we let dh_fixperms make everything executable, then the 1 bit per
   regular file that we want to preserve for use by chmod a+X
   (executable vs. not) has already been lost and cannot be recovered

> you will probably find a cleaner solution anyway

This has prompted me to open https://bugs.debian.org/1006927, because I
think the cleaner solution might be to change debhelper so it doesn't
have the behaviour that we're working around here.

Failing that, I think the next best thing is `chmod a+rX,u+w,og-w`
which has the desired result, ((mode & 0111) ? 0755 : 0644)
(assuming that the upstream build system can at least manage to make
files correctly executable or non-executable, which this one does).

smcv

Bug#1006927: /usr/bin/dh_fixperms: please don't make all files executable in subdirectories of /usr/libexec

[Simon McVittie]

Package: debhelper
Version: 13.4
Severity: normal
File: /usr/bin/dh_fixperms

In debhelper 13.4, usr/libexec was added to the array @executable_files_dirs
of directories in which all files are to be made executable.

I'm not sure that this is necessarily appropriate: several packages install
files into subdirectories of /usr/libexec that are not directly executable.
In particular:

* There is a convention in GLib and GLib-adjacent packages to install
  "as-installed" integration test suites (for use by e.g. autopkgtest),
  including both executables and non-executable data, into
  /usr/libexec/installed-tests
* Valgrind uses /usr/libexec/valgrind for private data that is
  a mixture of executables, non-executable XML files, and shared libraries
* sudo uses /usr/libexec/sudo for plugins

I recognise that this is not 100% FHS-compliant. However, there isn't
really a great FHS location for the installed-tests use-case:

* A subdirectory of ${datadir} can't have architecture-dependent files
  like compiled binaries
* A subdirectory of ${libdir} varies between architectures (and between
  operating systems, e.g. Debian vs. Red Hat), which makes automated and
  manual testing instructions harder to write, and can cause multiarch
  collisions in scripts/metadata that refer to the tests
* A subdirectory of ${prefix}/lib (like systemd uses for units, tmpfiles,
  etc.) requires repeatedly explaining to well-intentioned contributors
  and packagers that, yes, it's intentionally the same between
  architectures, and, no, they shouldn't move it to ${libdir} even though
  their favourite OS uses /usr/lib64
* Dividing test executables and test data between ${libexecdir}, ${libdir}
  and ${datadir} requires teaching the test-cases to look in the
  correct one of those paths for each resource or helper executable,
  making the tests more complicated and error-prone, particularly if
  upstream developers will usually run them as build-time tests in a
  single directory; it also means separating the tests out of a complete
  OS image (for example into an optional Flatpak extension) involves
  removing multiple directories, not just /usr/libexec/installed-tests

Presumably other use-cases like valgrind and sudo have similar concerns.
I think installing this sort of mixed content into a subdirectory of
/usr/libexec is in the spirit of the FHS, even if not obeying the letter
of the FHS.

At the moment, I'm working around this in affected packages by using
`dh_fixperms -Xusr/libexec/installed-tests`, but that means I don't get
the other behaviours of dh_fixperms such as normalizing executable
permissions to 0755 and non-executable permissions to 0644, which can
cause non-reproducibility when varying the umask.

As a result, I think it would be better if dh_fixperms didn't force all
files in subdirectories of /usr/libexec to be executable. I think there
are three reasonable routes to do that:

1. usr/libexec could be removed from the @executable_files_dirs, returning
   to bullseye behaviour
2. dh_fixperms could continue to chmod regular files in each of the
   @executable_files_dirs to be executable, but stop recursing into their
   subdirectories when doing so
3. dh_fixperms could special-case usr/libexec so that the other
   @executable_files_dirs are processed recursively, but usr/libexec is
   processed non-recursively

I would personally take option 2 and process the @executable_files_dirs
non-recursively, if it was up to me, because all the use-cases that
I'm aware of for mixing executable and non-executable files in the
${libexecdir} also want to group them into a subdirectory. The other
@executable_files_dirs don't generally have subdirectories (the only
counterexamples I know of are /usr/bin/mh/, which has a special exception
in Policy, and some mh-like mail suites) so processing the other
directories non-recursively shouldn't have any practical effect on many
packages.

In any case, I would hope that we can assume that upstream build systems
usually chmod executables +x without dh_fixperms' help, because if they
didn't do that, they would not work as expected in a manual installation
from source code or in a non-Debian packaging system.

Thanks,
smcv

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20220

Bug#1006616: firefox: new upstream version

[jim_p]

Package: firefox
Version: 96.0.3-1
Followup-For: Bug #1006616
X-Debbugs-Cc: pitsior...@outlook.com

Dear Maintainer,

First of all, I know that firefox 97 requires rustc, cargo and nss to build.
How about updating those 3 and building firefox 97+ for the experimental repo?
It is not just to get "the latest and greatest" but to close critical security
issues like the ones discovered here
https://www.mozilla.org/en-US/security/advisories/mfsa2022-09/

Like the user that opened this report, I am on debian testing and I use
unstable for firefox and a few other packages.


-- Package-specific info:

-- Extensions information
Name: Add-ons Search Detection
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Amazon.co.uk
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Amazon.com
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Bing
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: DoH Roll-Out
Location: /usr/lib/firefox/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: eBay
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Firefox Alpenglow theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Firefox Screenshots
Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Google
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Light theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Picture-In-Picture
Location: /usr/lib/firefox/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Privacy Redirect
Location: ${PROFILE_EXTENSIONS}/{b7f9d2cd-d772-4302-8c3f-eb941af36f76}.xpi
Status: enabled

Name: Proxy Failover
Location: /usr/lib/firefox/browser/features/proxy-failo...@mozilla.com.xpi
Package: firefox
Status: enabled

Name: System theme — auto theme
Location: /usr/lib/firefox/omni.ja
Package: firefox
Status: enabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: Video DownloadHelper
Location: ${PROFILE_EXTENSIONS}/{b9db16a4-6edc-47ec-a1f4-b86292ed211d}.xpi
Status: enabled

Name: Web Compatibility Interventions
Location: /usr/lib/firefox/browser/features/webcom...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: WebCompat Reporter
Location: /usr/lib/firefox/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled


-- Addons package information
ii  firefox96.0.3-1 amd64Mozilla Firefox web browser

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

Kernel: Linux 5.16.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firefox depends on:
ii  debianutils  5.7-0.1
ii  fontconfig   2.13.1-4.4
ii  libatk1.0-0  2.36.0-3
ii  libc62.33-7
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.14.0-1
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi8  3.4.2-4
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.11.1+dfsg-1
ii  libgcc-s112-20220302-1
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.4-1
ii  libgtk-3-0   3.24.31-1
ii  libnspr4 2:4.32-3
ii  libnss3  2:3.75-1
ii  libpango-1.0-0   1.50.4+ds-1
ii  libstdc++6   12-20220302-1
ii  libvpx7  1.11.0-2
ii  libx11-6 2:1.7.2-2+b1
ii  libx11-xcb1  2:1.7.2-2+b1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:6.0.0-1
ii  libxrandr2   2:1.5.2-1
ii  libxtst6 2:1.2.3-1
ii  procps   2:3.3.17-6
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox recommends:
ii  libavcodec58  10:4.4.1-dmo4

Versions of packages firefox suggests:
pn  fonts-lmodern  

Bug#988333: [Pkg-xen-devel] Bug#988333: Bug#988333: libxenmisc4.16: libxl fails to grant necessary I/O memory access for gfx_passthru of Intel IGD

[Hans van Kranenburg]

On 3/7/22 18:30, Chuck Zmudzinski wrote:

[...]


Thanks for adding all the info and researching this, Chuck!

Hans

Bug#1004503: Pushed

[Yadd]

Hi,

I just pushed tap 15 to experimental WITHOUT treport. A patch disables 
its output formats, classic output formats looks OK (tap, spec,...). 
Let's wait for [1] reports...


Cheers,
Yadd

[1]: 
https://release.debian.org/britney/pseudo-excuses-experimental.html#node-tap

Bug#958427: libsrtp2: FTBFS on x32: bogus printf with time_t, then segfaults [regression]

[Thorsten Glaser]

Hi Laurent,

> Thorsten do you think you could have a look?

sorry, I have absolutely no spoons left for that, what with
sid now requiring systemd’s idea of a filesystem layout,
which led to me leaving Debian-Ports entirely, and other
current discussions.

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#1006926: flash-kernel: add support for SiFive Unmatched board

[Heinrich Schuchardt]

Package: flash-kernel
Version: 3.104
Severity: wishlist
Tags: patch

As boards using the riscv64 architecture can be booted from U-Boot via 
the booti command like arm64 boards we should start adding these to the 
package.


The three appended patches

* add a bootscr.uboot-generic script for riscv64
* provide the database entry for the SiFive Unmatched board
* enable building on riscv64

The main benefit of the package I see is that when booting via GRUB it 
can be used to supply the newest device-tree before launching GRUB via 
the preboot hook.


Best regards

HeinrichFrom 94d1eba3ffdfdca6917a7975b35197f1aae70e26 Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt 
Date: Tue, 8 Mar 2022 11:03:16 +0100
Subject: [PATCH 3/3] debian/control: enable building for riscv64

riscv64 boards use device-trees. So we should provide the flash-kernel
package for them.

Signed-off-by: Heinrich Schuchardt 
---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index d37b6d5..89e6751 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Vcs-Git: https://salsa.debian.org/installer-team/flash-kernel.git
 Rules-Requires-Root: no
 
 Package: flash-kernel
-Architecture: arm64 armel armhf
+Architecture: arm64 armel armhf riscv64
 Depends: ${misc:Depends},
  devio,
  initramfs-tools (>= 0.92f),
@@ -31,7 +31,7 @@ Section: debian-installer
 Priority: standard
 Package-Type: udeb
 Build-Profiles: 
-Architecture: arm64 armel armhf
+Architecture: arm64 armel armhf riscv64
 XB-Subarchitecture: kirkwood orion5x s3c24xx mx5 generic
 Provides: bootable-system
 Depends: cdebconf-udeb, installed-base
-- 
2.34.1

From d43ffd2af4fd5387fa20909ccf0b51fbbba76626 Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt 
Date: Tue, 8 Mar 2022 10:18:49 +0100
Subject: [PATCH 2/3] db/all.db: add SiFive HiFive Unmatched A00

Add the SiFive HiFive Unmatched board to the database.

Ubuntu uses the 'generic' flavor while Debian uses 'riscv64'.
Add both to the database.

Signed-off-by: Heinrich Schuchardt 
---
 db/all.db | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/db/all.db b/db/all.db
index 951effe..585e45c 100644
--- a/db/all.db
+++ b/db/all.db
@@ -1719,6 +1719,13 @@ Boot-DTB-Path: /boot/dtb
 Required-Packages: u-boot-tools
 Bootloader-Sets-Incorrect-Root: no
 
+Machine: SiFive HiFive Unmatched A00
+Kernel-Flavors: generic riscv64
+DTB-Id: sifive/hifive-unmatched-a00.dtb
+Boot-Script-Path: /boot/boot.scr
+U-Boot-Script-Name: bootscr.uboot-generic
+Required-Packages: u-boot-tools
+
 Machine: Sinlinx SinA31s Development Board
 Kernel-Flavors: armmp armmp-lpae
 Boot-Script-Path: /boot/boot.scr
-- 
2.34.1

From 44be15212b83a2c72de6a0c8a79c49cef7442494 Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt 
Date: Tue, 8 Mar 2022 11:24:30 +0100
Subject: [PATCH 1/3] riscv64: add bootscr.uboot-generic

riscv64 uses booti not bootz. So we have to add a separate
bootscr.uboot-generic.

Signed-off-by: Heinrich Schuchardt 
---
 bootscript/riscv64/bootscr.uboot-generic | 56 
 1 file changed, 56 insertions(+)
 create mode 100644 bootscript/riscv64/bootscr.uboot-generic

diff --git a/bootscript/riscv64/bootscr.uboot-generic b/bootscript/riscv64/bootscr.uboot-generic
new file mode 100644
index 000..33f90d2
--- /dev/null
+++ b/bootscript/riscv64/bootscr.uboot-generic
@@ -0,0 +1,56 @@
+# Bootscript using the new unified bootcmd handling
+#
+# Expects to be called with the following environment variables set:
+#
+#  devtype  e.g. mmc/scsi etc
+#  devnum   The device number of the given type
+#  bootpart The partition containing the boot files
+#  distro_bootpart  The partition containing the boot files
+#   (introduced in u-boot mainline 2016.01)
+#  prefix   Prefix within the boot partiion to the boot files
+#  kernel_addr_rAddress to load the kernel to
+#  fdt_addr_r   Address to load the FDT to
+#  ramdisk_addr_r   Address to load the initrd to.
+#
+# The uboot must support the booti and generic filesystem load commands.
+
+if test -n "${console}"; then
+  setenv bootargs "${bootargs} console=${console}"
+fi
+
+setenv bootargs @@LINUX_KERNEL_CMDLINE_DEFAULTS@@ ${bootargs} @@LINUX_KERNEL_CMDLINE@@
+@@UBOOT_ENV_EXTRA@@
+
+if test -z "${fk_kvers}"; then
+   setenv fk_kvers '@@KERNEL_VERSION@@'
+fi
+
+# These two blocks should be the same apart from the use of
+# ${fk_kvers} in the first, the syntax supported by u-boot does not
+# lend itself to removing this duplication.
+
+if test -n "${fdtfile}"; then
+   setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
+else
+   setenv fdtpath dtb-${fk_kvers}
+fi
+
+if test -z "${distro_bootpart}"; then
+  setenv partition ${bootpart}
+else
+  setenv partition ${distro_bootpart}
+fi
+
+@@UBOOT_PREBOOT_EXTRA@@
+
+load ${devtype} ${devnum}:${partition} ${kernel_addr_r} ${prefix}vmlinuz-${fk_kvers} \
+&& load ${devtype} ${d

Bug#1006744: open-vm-tools core dump on debian 10

[Chilukuri, Girish - Dell Team]

Hi Bernd,
   Debian buster we are using. 

Thanks,
 Girish


Internal Use - Confidential

-Original Message-
From: Bernd Zeimetz  
Sent: Tuesday, March 8, 2022 2:13 PM
To: Chilukuri, Girish - Dell Team; 1006...@bugs.debian.org
Cc: Singh, Harmeet - Dell Team; Paturu, Santhosh - Dell Team
Subject: Re: Bug#1006744: open-vm-tools core dump on debian 10


[EXTERNAL EMAIL] 

Hi,

did you actually install the debug packages? The backtrace doesn't look like 
that.
Please do so.

https://urldefense.com/v3/__https://wiki.debian.org/HowToGetABacktrace__;!!LpKI!0puEtOoAByFgLNggB_VMDeU15wGT9ZJdww_v-PEituwvNiosvGG9pv-_z76wY7MGw9htYJ8$
 [wiki[.]debian[.]org]

Which release are you using? Bullseye? Or something else? What is "your 
product"?


Thanks,

Bernd

On 2022-03-08 07:37, Chilukuri, Girish - Dell Team wrote:
> Hi Bernd,
> Below is the full backtrace from all threads from the core 
> file.
> 
> gdb /usr/bin/vmtoolsd rp_core.417
> 
> GNU gdb (Debian 8.2.1-2+b3) 8.2.1
> Copyright (C) 2018 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
>   [gnu[.]org]>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
>   [gnu[.]org]>.
> Find the GDB manual and other documentation resources online at:
> 
>   [gnu[.]org]>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/bin/vmtoolsd...(no debugging symbols 
> found)...done.
> [New LWP 417]
> [New LWP 1105]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library 
> "/usr/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/bin/vmtoolsd'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
> 120 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or 
> directory.
> [Current thread is 1 (Thread 0x7f321f095780 (LWP 417))]
> (gdb) where
> #0  0x7f321f589206 in __strlen_sse2 () at
> ../sysdeps/x86_64/multiarch/../strlen.S:120
> #1  0x7f321f56b475 in __GI___fputs_unlocked
> (str=0x7f321e2f7ac8  0x7f321e2f7ac8>, fp=fp@entry=0x55d222325690)
> at iofputs_u.c:34
> #2  0x7f321f5e4868 in __GI___vsyslog_chk (pri=,
> flag=1, fmt=0x7f321edc083c "%s.", ap=0x7ffd36e1eda0)
> at ../misc/syslog.c:205
> #3  0x7f321f5e4dff in __syslog_chk (pri=,
> flag=, fmt=)
> at ../misc/syslog.c:129
> #4  0x7f321edbb1db in Audit_EventV () at /lib/libvgauth.so.0
> #5  0x7f321edbb2a4 in Audit_Event () at /lib/libvgauth.so.0
> #6  0x7f321edb7f95 in VGAuth_AuditEvent () at /lib/libvgauth.so.0
> #7  0x7f321edb6d05 in VGAuth_ValidateUsernamePassword () at
> /lib/libvgauth.so.0
> #8  0x7f321edd1cf1 in  () at 
> /usr/lib/open-vm-tools/plugins/common/libvix.so
> #9  0x7f321edd22e3 in  () at 
> /usr/lib/open-vm-tools/plugins/common/libvix.so
> #10 0x7f321edd25d9 in  () at 
> /usr/lib/open-vm-tools/plugins/common/libvix.so
> #11 0x7f321edd81f6 in  () at 
> /usr/lib/open-vm-tools/plugins/common/libvix.so
> #12 0x7f321edcf2cb in  () at 
> /usr/lib/open-vm-tools/plugins/common/libvix.so
> #13 0x7f3221a5f664 in RpcChannel_Dispatch () at 
> /lib/libvmtools.so.0
> #14 0x7f3221a611de in  () at /lib/libvmtools.so.0
> #15 0x7f3221a61aa4 in  () at /lib/libvmtools.so.0
> #16 0x7f32218dfe98 in g_main_context_dispatch () at
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #17 0x7f32218e0288 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #18 0x7f32218e0582 in g_main_loop_run () at
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #19 0x55d221850bb6 in  ()
> #20 0x55d22184fcc7 in main ()
> (gdb) thread apply all bt
> 
> Thread 2 (Thread 0x7f321ed23700 (LWP 1105)):
> #0  0x7f321f5df819 in __GI___poll (fds=0x55d22231b050, nfds=1,
> timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x7f32218e01f6 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #2  0x7f32218e031c in g_main_context_iteration () at
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #3  0x7f32218e0361 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #4  0x7f32219084d5 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #5  0x7f321f6bbfa3 in start_thread (arg=) at
> pthread_create.c:486
> #6  0x

Bug#951113: ITP: webp-pixbuf-loader -- WebP Image format GdkPixbuf loader.

[Tarik Graba]

Hi,

There is a new upstream version but the package is not yet an official 
Debian package.


What is exactly the issue here?

Regards,
Tarik

On Fri, 3 Dec 2021 18:07:33 +0100 Vieno Hakkerinen  
wrote:

Any news about this issue?

I stumbled over this while searching why eyeOfGnome does not show WebP 
images. I would be happy to view WebP images with eog.


kind regards
txt.file

On Thu, 29 Oct 2020 16:05:45 +0100 David Heidelberg  wrote:
> Current debian packaging can be found here:
> https://salsa.debian.org/okias-guest/webp-pixbuf-loader
> Best regards
> David Heidelberg
> 
> 
> 
> 

Bug#863751: Add --btrfs-subvolume-home option to adduser

[Osamu Aoki]

Hi,

Interesting POV.  (opt-in vs. automatic)

> -Original Message-
> From: Marc Haber 
> To: Osamu Aoki , 863...@bugs.debian.org,
> 863751-submit...@bugs.debian.org
> Cc: Nicholas D Steeves 
> Subject: Re: Bug#863751: Add --btrfs-subvolume-home option to adduser
> Date: Tue, 8 Mar 2022 07:46:58 +0100
> 
> Control: retitle -1 use useradd's --btrfs-subvolume-home option
> thanks
> 
> On Sun, Feb 21, 2021 at 08:52:39PM +0900, Osamu Aoki wrote:
> > The current useradd since 2019 has --btrfs-subvolume-home option.
> 
> How does this option behave if the parent of the new home directory is
> not on btrfs? adduser could add this option to all useradd calls but
> this would only be possible if useradd will _silently_ ignore the option
> if the parent directory is not btrfs and of course create a normal
> directory in that case. If the operation is not silent, package
> maintainers are going to redirect adduser's output to /dev/null which is
> not desired from adduser's pov.
> 
> Greetings
> Marc

I was thinking opt-in only.

I mean to add an opt-in --btrfs-subvolume-home option to adduser so the user 
can use
this feature if he requests.  I didn't think beyond.  (I didn't test it on 
non-btrfs
system so I don't know the answer to your question.  Whoever specifies it in 
command
line, he should know it.)

As I come to think of this, since it is trivial to check FS of /home in adduser 
in
advance by calling a basic shell command as:

```
 $ stat -f -c %T /home
btrfs
```
, adding this feature as an automatic option for pertinent system is an 
interesting
thought for adduser too.

Osamu

Bug#1006744: open-vm-tools core dump on debian 10

[Chilukuri, Girish - Dell Team]

Hi Bernd,
 I followed the steps in mentioned in below mail thread and collected 
the backtrace, 

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 8236]


Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
120 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.
#0  0x75aa1206 in __strlen_sse2 () at 
../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x75a83475 in __GI___fputs_unlocked (str=0x751ddac8 , fp=fp@entry=0x555de1e0) at 
iofputs_u.c:34
#2  0x75afc868 in __GI___vsyslog_chk (pri=, flag=1, 
fmt=0x7548683c "%s.", ap=0x7fffd9c0) at ../misc/syslog.c:205
#3  0x75afcdff in __syslog_chk (pri=, flag=flag@entry=1, 
fmt=fmt@entry=0x7548683c "%s.") at ../misc/syslog.c:129
#4  0x754811db in syslog (__fmt=0x7548683c "%s.", __pri=) at /usr/include/x86_64-linux-gnu/bits/syslog.h:31
#5  0x754811db in Audit_EventV (isSuccess=, 
fmt=, args=) at ../common/audit.c:205
#6  0x754812a4 in Audit_Event (isSuccess=isSuccess@entry=1, 
fmt=fmt@entry=0x75484b34 "%s: %s") at ../common/audit.c:139
#7  0x7547df95 in VGAuth_AuditEvent (ctx=ctx@entry=0x555e48b0, 
isSuccess=isSuccess@entry=1, fmt=) at common.c:655
#8  0x7547cd05 in VGAuth_ValidateUsernamePassword (ctx=0x555e48b0, 
userName=0x555dafe0 "admin", password=0x555dde20 "admin!", 
numExtraParams=numExtraParams@entry=0, extraParams=extraParams@entry=0x0, 
handle=handle@entry=0x7fffdce0) at auth.c:587
#9  0x75497cf1 in GuestAuthPasswordAuthenticateImpersonate 
(obfuscatedNamePassword=obfuscatedNamePassword@entry=0x555e1cb1 
"YWRtaW4AYWRtaW4hAA==", userToken=userToken@entry=0x7fffdf00) at 
vixTools.c:11579
#10 0x754982e3 in VixToolsImpersonateUserImplEx 
(credentialTypeStr=credentialTypeStr@entry=0x0, credentialType=, 
obfuscatedNamePassword=obfuscatedNamePassword@entry=0x555e1cb1 
"YWRtaW4AYWRtaW4hAA==", userToken=userToken@entry=0x7fffdf00) at 
vixTools.c:7992
#11 0x754985d9 in VixToolsImpersonateUser 
(requestMsg=requestMsg@entry=0x555e1c38, 
userToken=userToken@entry=0x7fffdf00) at vixTools.c:7752
#12 0x7549e1f6 in VixToolsInitiateFileTransferFromGuest 
(result=0x7fffdee0, requestMsg=0x555e1c38) at vixTools.c:4805
#13 0x7549e1f6 in VixTools_ProcessVixCommand 
(requestMsg=requestMsg@entry=0x555e1c38, 
requestName=requestName@entry=0x555db050 "4d3cb141d224fba", 
maxResultBufferSize=maxResultBufferSize@entry=65444, 
confDictRef=confDictRef@entry=0x55581c50, 
eventQueue=eventQueue@entry=0x5558a100, 
resultBuffer=resultBuffer@entry=0x7fffe008, resultLen=0x7fffe010, 
deleteResultBufferResult=0x7fffe007 "") at vixTools.c:10962
#14 0x754952cb in ToolsDaemonTcloReceiveVixCommand 
(data=0x7fffe150) at foundryToolsDaemon.c:1248
#15 0x77f77664 in RpcChannel_Dispatch () at /usr/lib/libvmtools.so.0
#16 0x77f791de in  () at /usr/lib/libvmtools.so.0
#17 0x77f79aa4 in  () at /usr/lib/libvmtools.so.0
#18 0x77df7e98 in g_main_context_dispatch () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x77df8288 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x77df8582 in g_main_loop_run () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x9bb6 in ToolsCoreRunLoop (state=0x55562540 ) at 
mainLoop.c:369
#22 0x9bb6 in ToolsCoreRunLoop (state=0x55562540 ) at 
mainLoop.c:301
#23 0x8cc7 in main (argc=1, argv=, 
envp=0x7fffe4f8) at mainPosix.c:283
#0  0x75aa1206 in __strlen_sse2 () at 
../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x75a83475 in __GI___fputs_unlocked (str=0x751ddac8 , fp=fp@entry=0x555de1e0) at 
iofputs_u.c:34
len = 
#2  0x75afc868 in __GI___vsyslog_chk (pri=, flag=1, 
fmt=0x7548683c "%s.", ap=0x7fffd9c0) at ../misc/syslog.c:205
now_tm = {tm_sec = 1, tm_min = 8, tm_hour = 10, tm_mday = 8, tm_mon = 
2, tm_year = 122, tm_wday = 2, tm_yday = 66, tm_isdst = 0, tm_gmtoff = 0, 
tm_zone = 0x555e1c00 "UTC"}
now = 1646734081
fd = 
f = 0x555de1e0
buf = 0x0
bufsize = 0
msgoff = 20
saved_errno = -3
failbuf = "\240n^UUU\000\000\342n^UUU\000\000\004o^UUU\000\000\240n^UU"
#3  0x75afcdff in __syslog_chk (pri=, flag=flag@entry=1, 
fmt=fmt@entry=0x7548683c "%s.") at ../misc/syslog.c:129
ap = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 
0x7fffdaa0, reg_save_area = 0x7fffd9e0}}
#4  0x754811db in syslog (__fmt=0x7548683c "%s.", __pri=) at /usr/include/x86_64-linux-gnu/bits/syslog.h:31
buf = 0x555e6ea0 "vmtoolsd: Username and password successfully 
validated for 'admin'"
#5  0x7f

Bug#1006924: ITS: connman

[Vignesh Raman]

Package: connman
Version: 1.36-2.2
Severity: important
X-Debbugs-Cc: vignesh.ra...@collabora.com, a...@debian.org, 
aga...@siduction.org, m...@qa.debian.org

Dear connman package maintainer in Debian,

After looking into the package you maintain (connman, 
https://tracker.debian.org/pkg/connman), I found that this package
received no maintainer updates in last two years. 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 (1.41),
clean up packaging and review/fix all Debian bug reports.

I will push my changes to salsa [2] and my sponsor will upload it in
debian in 21 days if you have no objection.

[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://salsa.debian.org/debian/connman/-/merge_requests/8

Regards,
Vignesh

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
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 connman depends on:
ii  dbus  1.12.20-2
ii  iptables  1.8.7-1
ii  libc6 2.31-13+deb11u2
ii  libdbus-1-3   1.12.20-2
ii  libglib2.0-0  2.66.8-1
ii  libgnutls30   3.7.1-5
ii  libreadline8  8.1-1
ii  libxtables12  1.8.7-1
ii  lsb-base  11.1.0

Versions of packages connman recommends:
ii  bluez  5.55-3.1
ii  ofono  1.31-3
ii  wpasupplicant  2:2.9.0-21

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information

Bug#1006923: Add a method to append something to reprotest's build-command

[Santiago R.R.]

Package: reprotest
Version: 0.7.19
Severity: wishlist
X-Debbugs-Cc: debian-salsa...@alioth-lists.debian.net

Hi there!

Let's suppose that someone wants to pass some arguments to
dpkg-buildpackage called by reprotest, as reported here:
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/245

AFAICS, we could hack --build-command, but I would like to avoid
hard-coding how reprotest calls dpkg-buildpackage. We could also use
--auto-preset-expr, but is not something straightforward (e.g. you have
to make sure the shell correctly interprets characters spaces in the
PYTHON_EXPRESSION).

Could reprotest have an --append-build-command option please?

 -- Santiago

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.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 reprotest depends on:
ii  apt-utils  2.4.0
ii  libdpkg-perl   1.21.1
ii  procps 2:3.3.17-6
ii  python33.9.8-1
ii  python3-debian 0.1.43
ii  python3-distro 1.7.0-1
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-rstr   2.2.6-3

Versions of packages reprotest recommends:
ii  diffoscope-minimal  206
ii  disorderfs  0.5.11-2
ii  faketime0.9.8-9
ii  locales-all 2.33-7
ii  sudo1.9.9-1

Versions of packages reprotest suggests:
ii  autodep8 0.25
pn  qemu-system  
ii  qemu-utils   1:6.2+dfsg-3
ii  schroot  1.6.10-12

-- no debconf information


signature.asc
Description: PGP signature

Bug#1006914: Acknowledgement (fonts-noto-color-emoji: Most emojis not displayed at all in Plasma)

[Max Görner]

I forgot to provide the link to bug ticket #1006685. It is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006685.

Bug#1006922: sdcc: Please package current upstream release

[Philipp Klaus Krause]

Source: sdcc
Version: 4.0.0+dfsg-2
Severity: wishlist
X-Debbugs-Cc: p...@spth.de

Dear Maintainer,

the current upstream release is 4.2.0, released today. There have been a
substantial number of bugfixes and other improvements since the 4.0.0 release
currently in Debian.
Please consider updating the Debian package.


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

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

Bug#1006616: firefox: new upstream version

[Vincent Lefevre]

On 2022-03-07 19:28:19 +0100, Christoph Anton Mitterer wrote:
> On Wed, 2022-03-02 at 03:13 -0300, Leandro Cunha wrote:
> > It's having a problem and logs can be accessed through the link
> > below.
> > https://buildd.debian.org/status/package.php?p=firefox&suite=sid
> 
> Isn't it "just" the current rust version that's missing?

It seems that's the only missing build dependency for the common
architectures.

rust 1.57 is now available in experimental (I wonder why it hasn't
been uploaded directly to unstable, so that dependencies could be
fulfilled). So, how about a new firefox version in experimental?

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

Bug#1006921: apache2: security.conf can be improved

[Daniel Lewart]

Package: apache2
Version: 2.4.52
Severity: normal
Tags: patch

Debian Apache Maintainers,

The attached patch improves security.conf (last updated Jun 24, 2015)
in the following ways:
  * Change Subversion example to git and improve it
  * Change obsolete X-Frame-Options to Content-Security-Policy
  * Add reference URLs to comments
  * Change indentation from spaces to tabs

Thank you!
Daniel Lewart
Urbana, Illinois
diff -ru a/debian/config-dir/conf-available/security.conf 
b/debian/config-dir/conf-available/security.conf
--- a/debian/config-dir/conf-available/security.conf2021-12-29 
00:35:53.0 -0600
+++ b/debian/config-dir/conf-available/security.conf2022-03-08 
00:00:00.0 -0600
@@ -6,8 +6,8 @@
 # Debian packages.
 #
 #
-#   AllowOverride None
-#   Require all denied
+#  AllowOverride None
+#  Require all denied
 #
 
 
@@ -21,6 +21,7 @@
 # and compiled in modules.
 # Set to one of:  Full | OS | Minimal | Minor | Major | Prod
 # where Full conveys the most information, and Prod the least.
+# https://httpd.apache.org/docs/2.4/mod/core.html#servertokens
 #ServerTokens Minimal
 ServerTokens OS
 #ServerTokens Full
@@ -32,6 +33,7 @@
 # documents or custom error documents).
 # Set to "EMail" to also include a mailto: link to the ServerAdmin.
 # Set to one of:  On | Off | EMail
+# https://httpd.apache.org/docs/2.4/mod/core.html#serversignature
 #ServerSignature Off
 ServerSignature On
 
@@ -42,6 +44,7 @@
 # diagnostic purposes).
 #
 # Set to one of:  On | Off | extended
+# https://httpd.apache.org/docs/2.4/mod/core.html#traceenable
 TraceEnable Off
 #TraceEnable On
 
@@ -49,16 +52,15 @@
 # Forbid access to version control directories
 #
 # If you use version control systems in your document root, you should
-# probably deny access to their directories. For example, for subversion:
+# probably deny access to their directories. For example, for git:
 #
-#
-#   Require all denied
-#
+#RedirectMatch 404 /\.git
 
 #
 # Setting this header will prevent MSIE from interpreting files as something
 # else than declared by the content type in the HTTP headers.
 # Requires mod_headers to be enabled.
+# 
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
 #
 #Header set X-Content-Type-Options: "nosniff"
 
@@ -66,8 +68,9 @@
 # Setting this header will prevent other sites from embedding pages from this
 # site as frames. This defends against clickjacking attacks.
 # Requires mod_headers to be enabled.
+# 
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors
 #
-#Header set X-Frame-Options: "sameorigin"
+#Header set Content-Security-Policy "frame-ancestors 'self';"
 
 
 # vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Bug#1006920: please split out a libtbbmalloc2 package, both in tbb and onetbb

[Matthias Klose]

Source: tbb,onetbb
Severity: important
Tags: patch

currently libtbb2 and libtbb12 break each other, making a tbb transition hard. 
please split out a libtbbmalloc2 package, both in tbb and onetbb, such that the 
transition can happen smoothly, and the both the old and the new tbb/onetbb can 
co-exist for a while.


patch for the tbb and onetbb splitouts are attached (please check the final 
versions for the breaks/replaces).


the onetbb patch also includes the patch from upstream issue #776 to build on 
other architectures.


For Ubuntu, I'm going to rename the old libtbb-dev and libtbb-doc packages to 
libtbb2-dev and libtbb2-doc, not sure if that's something you also want to do in 
Debian, but for the next Ubuntu release we need to ship both versions, or we 
need to remove packages like numba.
diff -Nru tbb-2020.3/debian/changelog tbb-2020.3/debian/changelog
--- tbb-2020.3/debian/changelog	2020-08-13 02:33:57.0 +0200
+++ tbb-2020.3/debian/changelog	2022-03-08 09:38:45.0 +0100
@@ -1,3 +1,10 @@
+tbb (2020.3-1ubuntu2) jammy; urgency=medium
+
+  * Split out a libtbbmalloc2 package.
+  * Mark some libtbbmalloc symbols as optional.
+
+ -- Matthias Klose   Tue, 08 Mar 2022 09:38:45 +0100
+
 tbb (2020.3-1) unstable; urgency=medium
 
   * New upstream version 2020.3
diff -Nru tbb-2020.3/debian/control tbb-2020.3/debian/control
--- tbb-2020.3/debian/control	2020-04-05 12:03:19.0 +0200
+++ tbb-2020.3/debian/control	2022-03-08 09:38:45.0 +0100
@@ -38,13 +38,32 @@
 Package: libtbb2
 Architecture: linux-any
 Multi-Arch: same
-Depends: ${shlibs:Depends},
+Depends: libtbbmalloc2, ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
 Description: parallelism library for C++ - runtime files
  TBB is a library that helps you leverage multi-core processor
  performance without having to be a threading expert. It represents a
  higher-level, task-based parallelism that abstracts platform details
+ and threading mechanism for performance and scalability.
+ .
+ (Note: if you are a user of the i386 architecture, i.e., 32-bit Intel
+ or compatible hardware, this package only supports Pentium4-compatible
+ and higher processors.)
+ .
+ This package includes the TBB runtime files.
+
+Package: libtbbmalloc2
+Architecture: linux-any
+Multi-Arch: same
+Depends: ${shlibs:Depends},
+ ${misc:Depends}
+Breaks: libtbb2 (<< 2020.3-1ubuntu2)
+Replaces: libtbb2 (<< 2020.3-1ubuntu2)
+Description: parallelism helper library for C++ - runtime files
+ TBB is a library that helps you leverage multi-core processor
+ performance without having to be a threading expert. It represents a
+ higher-level, task-based parallelism that abstracts platform details
  and threading mechanism for performance and scalability.
  .
  (Note: if you are a user of the i386 architecture, i.e., 32-bit Intel
diff -Nru tbb-2020.3/debian/libtbb2.install tbb-2020.3/debian/libtbb2.install
--- tbb-2020.3/debian/libtbb2.install	2020-04-03 04:45:37.0 +0200
+++ tbb-2020.3/debian/libtbb2.install	2022-03-08 09:38:45.0 +0100
@@ -1,2 +1,2 @@
 #! /usr/bin/dh-exec
-build/linux_*_release/lib*.so.*	usr/lib/${DEB_HOST_MULTIARCH}
+build/linux_*_release/libtbb.so.*	usr/lib/${DEB_HOST_MULTIARCH}
diff -Nru tbb-2020.3/debian/libtbb2.symbols.amd64 tbb-2020.3/debian/libtbb2.symbols.amd64
--- tbb-2020.3/debian/libtbb2.symbols.amd64	2020-08-11 05:52:00.0 +0200
+++ tbb-2020.3/debian/libtbb2.symbols.amd64	2022-03-08 09:38:45.0 +0100
@@ -298,65 +298,3 @@
  _ZTVN3tbb8internal21concurrent_queue_baseE@Base 2017~U7
  _ZTVN3tbb8internal24concurrent_queue_base_v3E@Base 2017~U7
  _ZTVN3tbb8pipelineE@Base 2017~U7
-libtbbmalloc.so.2 libtbb2 #MINVER#
- MallocInitializeITT@Base 2017~U7
- _Z9parseFileILi100ELi1EEvPKcRAT0__K13parseFileItem@Base 2018~U6
- _Z9parseFileILi100ELi2EEvPKcRAT0__K13parseFileItem@Base 2018~U6
- _ZN11MallocMutex11scoped_lockD1Ev@Base 2020.3
- _ZN11MallocMutex11scoped_lockD2Ev@Base 2020.3
- _ZN3rml10pool_msizeEPNS_10MemoryPoolEPv@Base 2019~U4
- _ZN3rml10pool_resetEPNS_10MemoryPoolE@Base 2017~U7
- _ZN3rml11pool_createElPKNS_13MemPoolPolicyE@Base 2017~U7
- _ZN3rml11pool_mallocEPNS_10MemoryPoolEm@Base 2017~U7
- _ZN3rml12pool_destroyEPNS_10MemoryPoolE@Base 2017~U7
- _ZN3rml12pool_reallocEPNS_10MemoryPoolEPvm@Base 2017~U7
- _ZN3rml13pool_identifyEPv@Base 2017~U7
- _ZN3rml14pool_create_v1ElPKNS_13MemPoolPolicyEPPNS_10MemoryPoolE@Base 2017~U7
- _ZN3rml19pool_aligned_mallocEPNS_10MemoryPoolEmm@Base 2017~U7
- _ZN3rml20pool_aligned_reallocEPNS_10MemoryPoolEPvmm@Base 2017~U7
- _ZN3rml9pool_freeEPNS_10MemoryPoolEPv@Base 2017~U7
- __TBB_malloc_safer_aligned_msize@Base 2017~U7
- __TBB_malloc_safer_aligned_realloc@Base 2017~U7
- __TBB_malloc_safer_free@Base 2017~U7
- __TBB_malloc_safer_msize@Base 2017~U7
- __TBB_malloc_safer_realloc@Base 2017~U7
- scalable_aligned_free@Base 2017~U7
- scalable_aligned_malloc@Base 2017~U7
- scalable_aligned_realloc@Base 2017~U7
- scalable_allocation_command@Base 2017~U7
- 

Bug#1006919: src:cbmc FTBFS

[Thomas Goirand]

Source: cbmc
Version: 5.12-5
Severity: serious

Hi,

Trying to solve #1006850, I couldn't build cbmc:

make[3]: Leaving directory '/<>/src/util'
## Entering langapi
/usr/bin/make  -C langapi
make[3]: Entering directory '/<>/src/langapi'
g++ -c -DSATCHECK_MINISAT2 -MMD -MP -std=c++11 -DHAVE_MINISAT2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Werror -Wno-parentheses -Wno-deprecated 
-pedantic -Wall -pedantic -Werror -Wno-deprecated-declarations -Wswitch-enum  
-I .. -o language_util.o language_util.cpp
g++ -c -DSATCHECK_MINISAT2 -MMD -MP -std=c++11 -DHAVE_MINISAT2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Werror -Wno-parentheses -Wno-deprecated 
-pedantic -Wall -pedantic -Werror -Wno-deprecated-declarations -Wswitch-enum  
-I .. -o language_file.o language_file.cpp
In file included from language_file.cpp:9:
language_file.h: In member function ‘void language_filest::remove_file(const 
string&)’:
language_file.h:87:54: error: loop variable ‘method’ of type ‘const 
std::pair&’ binds to a temporary constructed from 
type ‘std::pair’ [-Werror=range-loop-construct]
   87 | for(const std::pair &method : 
lazy_method_map)
  |  ^~
language_file.h:87:54: note: use non-reference type ‘const std::pair’ to make the copy explicit or ‘const std::pair&’ to prevent copying
cc1plus: all warnings being treated as errors
make[3]: *** [../common:222: language_file.o] Error 1


Please solve it, together with #1006850.

Cheers,

Thomas Goirand (zigo)

Bug#868171: qbittorrent: Many a time qbittorrent crashes esp. when using magnet links

[bruno zanetti]

There's an upstream issue filed (and closed) for this bug:
https://github.com/qbittorrent/qBittorrent/issues/6064.

It seems related to the libtorrent-rasterbar branch 1.1.x not officially
supported by qbittorrent 3.3.7.

The current versions of both pkgs should work fine together, so I believe
this report can be closed now.

Regards

BZ

Bug#1006906: plocate: cifs file system not being indexed by plocate or mlocate

[Steinar H. Gunderson]

On Mon, Mar 07, 2022 at 05:12:47PM -0800, Ed Biow wrote:
> I always change the /etc/updatedb.conf file to remove cifs from PRUNEFS. The
> command works as expected on my Ubuntu systems, mostly 20.04 using the
> 0.26-3ubuntu3 of mlocate. In the past mlocate worked on Debian.
> The locate command is pretty useless to me without indexing my cifs directory.

There is a flag --debug-pruning to updatedb; could you add it and see whether
it gives any useful information?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1006744: open-vm-tools core dump on debian 10

[Bernd Zeimetz]

Hi,

did you actually install the debug packages? The backtrace doesn't look 
like that.

Please do so.

https://wiki.debian.org/HowToGetABacktrace

Which release are you using? Bullseye? Or something else? What is "your 
product"?



Thanks,

Bernd

On 2022-03-08 07:37, Chilukuri, Girish - Dell Team wrote:

Hi Bernd,
Below is the full backtrace from all threads from the core 
file.


gdb /usr/bin/vmtoolsd rp_core.417

GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


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

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/vmtoolsd...(no debugging symbols 
found)...done.

[New LWP 417]
[New LWP 1105]
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/usr/lib/x86_64-linux-gnu/libthread_db.so.1".

Core was generated by `/usr/bin/vmtoolsd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
120 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or 
directory.

[Current thread is 1 (Thread 0x7f321f095780 (LWP 417))]
(gdb) where
#0  0x7f321f589206 in __strlen_sse2 () at
../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x7f321f56b475 in __GI___fputs_unlocked
(str=0x7f321e2f7ac8 , fp=fp@entry=0x55d222325690)
at iofputs_u.c:34
#2  0x7f321f5e4868 in __GI___vsyslog_chk (pri=,
flag=1, fmt=0x7f321edc083c "%s.", ap=0x7ffd36e1eda0)
at ../misc/syslog.c:205
#3  0x7f321f5e4dff in __syslog_chk (pri=,
flag=, fmt=)
at ../misc/syslog.c:129
#4  0x7f321edbb1db in Audit_EventV () at /lib/libvgauth.so.0
#5  0x7f321edbb2a4 in Audit_Event () at /lib/libvgauth.so.0
#6  0x7f321edb7f95 in VGAuth_AuditEvent () at /lib/libvgauth.so.0
#7  0x7f321edb6d05 in VGAuth_ValidateUsernamePassword () at
/lib/libvgauth.so.0
#8  0x7f321edd1cf1 in  () at 
/usr/lib/open-vm-tools/plugins/common/libvix.so
#9  0x7f321edd22e3 in  () at 
/usr/lib/open-vm-tools/plugins/common/libvix.so
#10 0x7f321edd25d9 in  () at 
/usr/lib/open-vm-tools/plugins/common/libvix.so
#11 0x7f321edd81f6 in  () at 
/usr/lib/open-vm-tools/plugins/common/libvix.so
#12 0x7f321edcf2cb in  () at 
/usr/lib/open-vm-tools/plugins/common/libvix.so
#13 0x7f3221a5f664 in RpcChannel_Dispatch () at 
/lib/libvmtools.so.0

#14 0x7f3221a611de in  () at /lib/libvmtools.so.0
#15 0x7f3221a61aa4 in  () at /lib/libvmtools.so.0
#16 0x7f32218dfe98 in g_main_context_dispatch () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x7f32218e0288 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x7f32218e0582 in g_main_loop_run () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x55d221850bb6 in  ()
#20 0x55d22184fcc7 in main ()
(gdb) thread apply all bt

Thread 2 (Thread 0x7f321ed23700 (LWP 1105)):
#0  0x7f321f5df819 in __GI___poll (fds=0x55d22231b050, nfds=1,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f32218e01f6 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f32218e031c in g_main_context_iteration () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f32218e0361 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f32219084d5 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f321f6bbfa3 in start_thread (arg=) at
pthread_create.c:486
#6  0x7f321f5ea4cf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7f321f095780 (LWP 417)):
#0  0x7f321f589206 in __strlen_sse2 () at
../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x7f321f56b475 in __GI___fputs_unlocked
(str=0x7f321e2f7ac8 , fp=fp@entry=0x55d222325690)
at iofputs_u.c:34
#2  0x7f321f5e4868 in __GI___vsyslog_chk (pri=,
flag=1, fmt=0x7f321edc083c "%s.", ap=0x7ffd36e1eda0)
at ../misc/syslog.c:205
#3  0x7f321f5e4dff in __syslog_chk (pri=,
flag=, fmt=)
at ../misc/syslog.c:129
#4  0x7f321edbb1db in Audit_EventV () at /lib/libvgauth.so.0
#5  0x7f321edbb2a4 in Audit_Event () at /lib/libvgauth.so.0
#6  0x7f321edb7f95 in VGAuth_AuditEvent () at /lib/libvgauth.so.0
#7  0x7f321edb6d05 in VGAuth_ValidateUsernamePassword () at
/lib/libvgauth.so.0
#8  0x7f321edd1cf1 in  () at 
/usr/lib/open-vm-tools/plugins/common/libvix.so
#9  0x7f321edd22e3 in  () at 
/usr/lib/open-vm-tools/plugins/common/libvix.so
#10 0x7f321edd25d9 in  () at 
/usr/lib/open-vm-tools/plugins/commo

Bug#584919: Some of the adduser.conf configuration options not present (in commented-out form) in installed /etc/adduser.conf

[Marc Haber]

Control: tags -1 confirmed
Control: severity -1 important 
Control: retitle -1 re-work of (add|del)user.conf needed
thanks

On Mon, Jun 07, 2010 at 10:53:36AM -0400, Christian Hudon wrote:
> The installed /etc/adduser.conf file features most of the variables that
> can control adduser, at least in commented out form, together with an
> explanatory comment. This is really nice for the sysadmin, as it saves
> back and forth between the documentation and the configuration file.
> However, some adduser variables are not in that configuration file. It'd
> be nice if they could be added too, in commented-out form and with a
> short explanatory comment. At least, the ADD_EXTRA_GROUPS and
> EXTRA_GROUPS seem very useful and were unknown to this sysadmin before
> today, because they were not included in the /etc/adduser.conf file.
> >From a quick look, every configuration item after QUOTA_USER in the
> (5)adduser.conf manpage is not in the /etc/adduser.conf file.

Thanks for spotting this. As maintainers, we should:
- check whether program code, config file and man page are in sync
  regarding implemented and documented options
- comment out settings in the configuration files that match the
  default set in the code
- probably give more sense to the order of options in the configuration
  file
- add a reference to the manual page to deluser.conf as well

Greetings
Marc

Bug#1006918: docker.io: RISC-V support missing for docker.io

[Heinrich Schuchardt]

Package: docker.io
Version: 20.10.11+dfsg1-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear Maintainer,

docker.io can be easily enabled to support the riscv64 architecture by
adding it in debian control.

*** /tmp/tmp8s296zdv/bug_body

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

  * Enable riscv64 architecture (LP: #1963920)

Thanks for considering the patch.

Best regards

Heinrich

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy
  APT policy: (500, 'jammy')
Architecture: riscv64

Kernel: Linux 5.15.0-1004-generic (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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
diff -Nru docker.io-20.10.12/debian/control docker.io-20.10.12/debian/control
--- docker.io-20.10.12/debian/control   2022-01-14 20:23:16.0 +0100
+++ docker.io-20.10.12/debian/control   2022-03-07 16:57:50.0 +0100
@@ -1,8 +1,7 @@
 Source: docker.io
 Section: admin
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Paul Tagliamonte 
+Maintainer: Paul Tagliamonte 
 Uploaders: Docker Packaging Team ,
Tianon Gravi 
 Build-Conflicts: golang-github-docker-docker-dev
@@ -32,7 +31,7 @@
 XS-Go-Import-Path: github.com/docker/docker
 
 Package: docker.io
-Architecture: amd64 arm64 armhf i386 ppc64el s390x
+Architecture: amd64 arm64 armhf i386 ppc64el riscv64 s390x
 Depends: adduser,
  containerd (>= 1.2.6-0ubuntu1~),
  iptables,

Bug#1006917: kpcli: "not well-formed (invalid token)" when opening a file

[Rhonda D'Vine]

Package: kpcli
Version: 3.1-3.1
Severity: grave
Tags: upstream
Justification: causes serious data loss

Dear Maintainer,

I store my passwords in a keepass file that I exclusively use through kpcli.
After the last kernel upgrade reboot I was unable to open the file anymore, and
thus can't access my passwords.  I have an aged backup, and most sites offer
password resets, but this is actually a serious data loss.

When I try to open the database now I get the following error message:

➤ kpcli --kdb rhonda.kdbx
Please provide the master password: *
Couldn't load the file rhonda.kdbx:
not well-formed (invalid token) at line 3103, column 15, byte 100409 at 
/usr/lib/x86_64-linux-gnu/perl5/5.34/XML/Parser.pm line 187.

So I have somehow the hope that the data isn't lost completely, only that the
XML parser is stumbling upon something.  I haven't had the nerve yet to dig
further into it and try to unpack the whole situation, make kpcli dump what it
gives to XML::Parser, that part gives me a bit of a hope because it clearly can
decrypt the file in the first place, but it makes it unusable to the
"innocent".

If you are able to give me any helping hand on those grounds, they would be
very much appreciated! Because as it stands I assume this might happen to
others, and I'm uncertain if it would have anything to do with specific data
stored in some comment or password field or whatever.

Thanks in advance,
Rhonda


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

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

Versions of packages kpcli depends on:
ii  libclone-perl  0.45-1+b2
ii  libcrypt-rijndael-perl 1.16-1+b1
ii  libfile-keepass-perl   2.03-1.1
ii  libsort-naturally-perl 1.03-2
ii  libterm-readkey-perl   2.38-1+b3
ii  libterm-readline-gnu-perl  1.42-2+b1
ii  libterm-shellui-perl   0.92-4
ii  perl   5.34.0-3

Versions of packages kpcli recommends:
ii  libcapture-tiny-perl   0.48-1
ii  libclipboard-perl  0.27-1
pn  libdata-password-perl  
pn  libmath-random-isaac-perl  

kpcli suggests no packages.

-- no debconf information

Bug#640651: please set default FIRST_SYSTEM_UID=1 and FIRST_SYSTEM_GID=1

[Marc Haber]

Control: tags -1 help
Control: outlook -1 merge request (code, docs, autopkgtest) appreciated
Control: retitle -1 allow FIRST_SYSTEM_(UID|GID) to be preseeded
thanks

On Fri, Jun 27, 2014 at 01:18:13PM +0900, Charles Plessy wrote:
> I just ran in the same issue and I agree with Marc that the best
> solution would be to change adduser so that these values can be
> preseeded.

There have been only two people requesting this functionality in over a
decade. Making these settings preseedable would mean that adduser.conf
could no longer be a conffile, which means that a lot of error-prione
code is needed to handle local changes to the file.

I do not think that this is worth doing at the moment with such a big
number of bugs that might be more useful to people. I am therefore
de-prioritizing this even more, but would consider a merge request
containing a tested patch, documentation and test cases for
autopkgtests.

Greetings
Marc