Bug#1009999: pulseaudio: log flooded with "ICE I/O error handler called"

[Igor Kovalenko]

On Fri, 22 Apr 2022 07:23:05 +0200 Tino Mettler
 wrote:
> Package: pulseaudio
> Version: 15.0+dfsg1-4
> Severity: important
>
> Dear Maintainer,
>
> pulseaudio sometimes start to flood the log with these messages:
>
> pulseaudio[110205]: ICE I/O error handler called
>
> Currtently, there are millions of it in my systemd journal since yesterday 
> afternoon:

Hi Tino,

This is fixed in pulseaudio-15.99.1, you need this change
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/650

Bug#1009572: Workaround to fix Jest resolver

[Yadd]

Control: severity -1 important

To facilitate ES transition, we built some hybrid modules (node-find-up 
for example):

 * package.json#exports#require exposes old & new API
 * package.json#exports#import exposes new API

The reported error shows Jest resolver behavior:

> FAIL test/cjs.test.js
>   ● Test suite failed to run
>
> TypeError: findUp.sync is not a function
>
>   11 |
>   12 | module.exports.sync = cwd => {
> > 13 |  const filePath = findUp.sync('package.json', {cwd});
>  | ^
>   14 | return filePath && path.dirname(filePath);
>   15 | };
>   16 |

Jest does not use Node.js resolver but jest-resolver instead. Here, 
jest-resolver uses find-up/index.js instead of find-up/index.cjs and 
then does not find old API functions.


Here is a workaround:
 * patch package.json to add: "jest": {"resolver":"debian/resolver.js"},
 * write the resolver:

$ cat > debian/resolver.js << EOF
module.exports = (request, options) => {
  // use defaultResolver
  return options.defaultResolver(request, {
...options,
// use packageFilter to modify `package.json` before resolution
// (see https://www.npmjs.com/package/resolve#resolveid-opts-cb)
packageFilter: (pkg) => {
  let main = pkg.exports && pkg.exports.require ? 
pkg.exports.require : pkg.main;

  return {
...pkg,
// change `main` value
main: main
  };
},
  });
};
EOF

Bug#1001209: dnsmasq: Regression: Fails to direct queries to 127.0.1.1#10053

[Paul Wise]

Control: forwarded -1 
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=089a11f3400485f215f5e29c77e41d7730f2c806
Control: tags -1 + fixed-upstream

On Fri, 10 Dec 2021 20:48:18 +0100 Sven Mueller wrote:

> judging from the Dnsmasq list, the problem is that --local is
> supposed to
> be an alias for --server, but the recent rewrite of the address logic
> apparently made it an alias of --adress instead.
...
> Basically, AFAICT, this boils down to:
> Make --local a proper alias for --server again.

Looking at the upstream git repository, this is fixed upstream in
commit 089a11f34 from 2021-10-05 and tag v2.87test4 according to:

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=shortlog#:~:text=--local

I note there is also a CVE fix in the recent commits.

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=03345ecefeb0d82e3c3a4c28f27c3554f0611b39

Simon, could you release 2.87 and upload it to Debian please?

Otherwise dnsmasq will be removed from Debian bookworm.

https://tracker.debian.org/pkg/dnsmasq
https://udd.debian.org/cgi-bin/autoremovals.cgi

If you don't have time then I can upload a test release.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1010089: xarchiver: Crash at start, fixed in upstream

[thefoo]

Package: xarchiver
Version: 1:0.5.4.17-3
Severity: important
X-Debbugs-Cc: the...@gmx.de


Dear maintainer,

depending on which compressors/decompressors are installed, Xarchiver might
segfault on launch. See the GDB excerpt below.

The upstream repo already has a fix at the problematic line 89, and building
from the newest source gives me a working program.

Thread 1 "xarchiver" received signal SIGSEGV, Segmentation fault.
__strstr_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strstr-
sse2-unaligned.S:40
(gdb) bt
#0  __strstr_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strstr-
sse2-unaligned.S:40
#1  0x55e6411838e2 in xa_gzip_et_al_check_zstd
(compressor=compressor@entry=0x55e6411a9a5d "zstd",
decompressor=decompressor@entry=0x55e6411a9a9e "unzstd",
is_compressor=is_compressor@entry=0x55e6411b64b0 ) at
gzip_et_al.c:89
#2  0x55e64118be03 in xa_check_available_archivers () at main.c:131
#3  0x55e641177326 in main (argc=, argv=) at
main.c:1097


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

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

Versions of packages xarchiver depends on:
ii  libc62.33-7
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.72.1-1
ii  libgtk-3-0   3.24.33-1

Versions of packages xarchiver recommends:
ii  bzip2   1.0.8-5
ii  p7zip-full  16.02+dfsg-8
ii  unzip   6.0-26
ii  xdg-utils   1.1.3-4.1
ii  xz-utils5.2.5-2.1

Versions of packages xarchiver suggests:
pn  arj  
ii  binutils 2.38-3
ii  cpio 2.13+dfsg-7
pn  lbzip2   
pn  lhasa
pn  liblz4-tool  
pn  lrzip
pn  lzip 
pn  lzop 
pn  ncompress
pn  pbzip2   
ii  pigz 2.6-1
pn  plzip
ii  rar  2:6.11-0.1
pn  unar 
ii  zip  3.0-12
ii  zstd 1.5.2+dfsg-1

-- no debconf information

Bug#1009927: krb5: deprecated encryption type for master_key_type

[Benjamin Kaduk]

I'm pretty sure that changing the master key encryption type used for new
databases has basically no upgrade considerations and could be "just done".
Updating the encryption type for that key on existing databases will have
nontrivial upgrade considerations (and in fact will not be possible to do
automatically in a maintainer script in all cases).

It is even possible that we might drop that configuration stanza entirely
rather than just changing the encryption type, though we would want to more
thoroughly research the consequences of doing so before actually making
that change.

Thanks for the report, this is definitely something we should be taking
action on.

-Ben

On Wed, Apr 20, 2022 at 05:51:45PM -0300, Andreas Hasenack wrote:
> Package: krb5
> Version: 1.19.2-2
> Severity: normal
> 
> Dear Maintainer,
> 
> when creating a new realm using `krb5_newrealm`, the following warning
> is logged in /var/log/syslog:
> 
> Apr 20 20:43:16 kdc krb5kdc[3136]: Stash file /etc/krb5kdc/stash uses
> DEPRECATED enctype des3-cbc-sha1!
> 
> This comes from the kdc.conf template in
> /usr/share/krb5-kdc/kdc.conf.template which has "master_key_type =
> des3-hmac-sha1".
> 
> Maybe it's time to update that encryption type? The kdc.conf manpage
> says that the current default is "aes256-cts-hmac-sha1-96". The sample
> kdc.conf in the documentation at
> https://web.mit.edu/kerberos/krb5-latest/doc/admin/install_kdc.html#kdc-conf
> suggests just "master_key_type = aes256-cts".
> 
> I understand there may be important upgrade path considerations. Given
> all the care and precautions that are shown for migrating away from
> single DES in 
> https://web.mit.edu/kerberos/krb5-latest/doc/admin/advanced/retiring-des.html,
> changing the default master key type for fresh installs might also
> require careful planning and thought, but at some point this process
> must start. And upstream is now flagging DES3 as deprecated already.
> 

Bug#1010088: gdm3 - Login fails and returns to login or blank screen

[Philip Wyett]

Package: gdm3
Version: 42.0-1
Severity: serious
Tags: bookworm sid

Login fails and returns to login or a blank screen.

Platform is VM with virtio graphics.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1010087: waylandpp: please split out a -doc package

[Aaron M. Ucko]

Source: waylandpp
Version: 0.2.10-1
Severity: minor

waylandpp-dev's size increased from 843 kB to 14.4 MB between versions
0.2.8-2 and 0.2.10-1 on amd64, with other architectures presumably
also encountering similar increases.  AFAICT, this massive increase
comes primarily from Doxygen's generated HTML, which is
architecture-independent and not usually needed locally; could you
please split it out into a separate -doc package?

Thanks!

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/8 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)
LSM: AppArmor: enabled

Bug#1010086: wiki.debian.org: Access to wiki.debian.org is blocked with 403 Forbidden

[Hernán K .]

Package: wiki.debian.org
Severity: normal

I've received a 403 Forbidden when trying to reach wiki.debian.org.


Could you please unblock 200.85.189.97 ?


Thanks in advance.

Bug#1001253: wl-beta: After network change, cannot fetch email

[Tatsuya Kinoshita]

On 2021-12-07 at 11:09 +1100, peter (at chubb.wattle.id.au) wrote:
> If I suspend my laptop, and resume it somewhere where /etc/resolv.conf
> is different (home vs work for instance), any attempt to fetch email
> gives:
>   mailserver.name/993 Temporary failure in name resolution
>
> Other emacs functions work properly:  I can do
>(dns-query "mailserver.name")

Because dns.el directly uses /etc/resolv.conf.

Wanderlust doesn't directly use /etc/resolv.conf.  Wanderlust uses
Emacs' open-network-stream.  It may fail, because Emacs process
caches /etc/resolv.conf by getaddrinfo/gethostbyname.

A workaround is to install a DNS server locally for caching.

Thanks,
--
Tatsuya Kinoshita


pgpxZJ2Z8OvCq.pgp
Description: PGP signature

Bug#1010083: librust-addr2line-dev: please upgrade to newer release

[Peter Michael Green]

Please upgrade addr2line to a newer release - preferably v0.17.0 but
possibly v0.13.0 (in experimental since more than 5 months) is adequate.


Unfortunately it seems addr2line, gimli, object and some other packages 
are fairly closely tied together. I don't think updating them 
individually is feasible and updating the whole lot including object 
would break dwarf2sources.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998306

Now maybe the time has come that dwarf2sources should be broken, the 
maintainer has had nearly 6 months warning to fix their package but i'm 
a little reluctant to break a package that is in Debian now for the sake 
of a package that may be in Debian at some time in the future.



error[E0277]: the trait bound `Rc<[u8]>: CloneStableDeref` is not satisfied
--> 
/usr/share/cargo/registry/safe-network-0.58.13/debian/cargo_registry/addr2line-0.10.0/src/lib.rs:92:20
 |
92  | pub struct Context>
 |^ the trait `CloneStableDeref` is not implemented for 
`Rc<[u8]>`
 |
note: required by a bound in `EndianReader`

error[E0277]: the trait bound `Rc<[u8]>: CloneStableDeref` is not satisfied
--> 
/usr/share/cargo/registry/safe-network-0.58.13/debian/cargo_registry/addr2line-0.10.0/src/lib.rs:101:14
 |
101 | impl Context> {
 |  ^^ the trait 
`CloneStableDeref` is not implemented for `Rc<[u8]>`
 |
note: required by a bound in `EndianReader`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `addr2line` due to 2 previous errors
With the version of addr2line currently in Debian you need to enable the 
"std" feature, it won't build with no features at all enabled. You can 
instead enable the alloc feature but that only works if the compiler is 
running in nightly mode.

Bug#1009448: libpdf-builder-perl: FTBFS: dh_auto_test: error: make -j8 test TEST_VERBOSE=1 returned exit code 2

[gregor herrmann]

On Sat, 23 Apr 2022 07:37:40 +, Jeff wrote:

> As ghostscript is only used by the tests for comparison purposes, and this
> does not affect the output of libpdf-builder-perl, I propose that we forward
> this to ghostscript and skip these two tests until we have a fix.

Sounds reasonable to me, and thanks for all your debugging efforts!


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1010075: librust-intervaltree+std-dev: please upgrade to v0.2.7

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2022-04-23 21:23:52)
> Please upgrade intervaltree to v0.2.7.

...or upgrade addr2line (see bug#1010083): I have no direct need for 
intervaltree, only transitively via the old addr2line - newer releases 
drop the dependency on intervaltree, and nothing else in Debian depends 
on intervaltree so it seems it can simply e dropped when addr2line is 
upgraded.


 - Jonas

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

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

signature.asc
Description: signature

Bug#1010084: x11-xkb-utils: xkbcomp outputs many warnings without "-w 0"

[Vincent Lefevre]

On 2022-04-23 23:57:24 +0200, Vincent Lefevre wrote:
[...]
> where .xkb/keymap/test contains
> 
> xkb_keymap {
> xkb_keycodes  { include "evdev+aliases(qwerty)" };
> xkb_types { include "complete"  };
> xkb_compat{ include "complete"  };
> xkb_symbols   { include "pc+gb+inet(evdev)" };
> xkb_geometry  { include "pc(pc105)" };
> };
> 
> Either these are real bugs or these are just spurious warnings that
> should be licenced by default.
 I meant "silenced"

It could also be that xkb-data has obsolete or invalid keys.

> Some of them are common with bug 756268.

(which was in 2014).

> Most of them can be silenced with "-w 0", but the user shouldn't need
> to provide "-w 0" since it is not his fault.

FYI, except for the XF86EmojiPicker one (bug 1009995), a first warning
starts with -w 2:

zira:~> xkbcomp -w 2 -I$HOME/.xkb -R$HOME/.xkb keymap/test xkb.dump
Keycodes above 256 (e.g. ) are not supported by X and are ignored
Warning:  Could not resolve keysym XF86EmojiPicker

> For warnings not silenced by "-w 0", this is bug 1009994.

Currently, this concerns the XF86EmojiPicker one only.

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

Bug#1010085: linux: Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)

[Diederik de Haas]

Control: found -1 5.10.46-4

On Sunday, 24 April 2022 00:10:01 CEST Diederik de Haas wrote:
> IIRC I also got the warning under a 5.10 kernel, but I'll verify it
> first before adding its version to the 'Found' category.

I booted into linux-image-5.10.0-8-amd64 kernel and there I had the same issue 
too, so adding that now to the 'found' versions.

I also have linux-image-4.19.0-12-amd64 but booting into that failed entirely, 
so couldn't verify it there. But that would be a different issue.

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

Bug#1010085: linux: Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)

[Diederik de Haas]

Source: linux
Version: 5.17.3-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have 2 WDC WD30EFRX-68E HDDs, one is connected 'normally' via SATA
cables, the other one is build into a USB enclosure and uses UAS.
The drives have the exact same same characteristics:

# fdisk -l /dev/sdb
Disk /dev/sdb: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors
Disk model: WDC WD30EFRX-68E
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt

Device StartEndSectors  Size Type
/dev/sdb1   8192 5860533134 5860524943  2.7T Linux filesystem

This is the output from the drive with SATA connection and afaik the
'End' and 'Sectors' value are suboptimal.
This is what I had initially on the USB connected drive:

Device StartEndSectors Size Type
/dev/sda1   8192 2147491839 2147483648   1T Linux filesystem

Whereby the number of sectors is divisible by 8192 and thus also by 4096
(with 0 remainder ofc).

However the SATA connected drive does not show any errors or warnings in
dmesg when connected (on bootup), but the USB connected drive does:

[19776.494284] usb 2-3: new SuperSpeed USB device number 5 using xhci_hcd
[19776.524210] usb 2-3: New USB device found, idVendor=174c, idProduct=55aa, 
bcdDevice= 1.00
[19776.524216] usb 2-3: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[19776.524218] usb 2-3: Product: USB 3.0 Device
[19776.524220] usb 2-3: Manufacturer: Space keys
[19776.524221] usb 2-3: SerialNumber: 0409
[19776.566299] scsi host9: uas
[19776.567355] scsi 9:0:0:0: Direct-Access Space ke USB 3.0 Device   0
PQ: 0 ANSI: 6
[19776.567923] sd 9:0:0:0: Attached scsi generic sg1 type 0
[19776.568397] sd 9:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 
TB/2.73 TiB)
[19776.568400] sd 9:0:0:0: [sdb] 4096-byte physical blocks
[19776.568475] sd 9:0:0:0: [sdb] Write Protect is off
[19776.568477] sd 9:0:0:0: [sdb] Mode Sense: 43 00 00 00
[19776.568637] sd 9:0:0:0: [sdb] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[19776.569217] sd 9:0:0:0: [sdb] Optimal transfer size 33553920 bytes not a 
multiple of physical block size (4096 bytes)
[19776.659088]  sdb: sdb1
[19776.678425] sd 9:0:0:0: [sdb] Attached SCSI disk

But via USB I get this warning in dmesg:
Optimal transfer size 33553920 bytes not a multiple of physical block size 
(4096 bytes)

Looking into this issue I came across the following:
http://gparted-forum.surf4.info/viewtopic.php?id=17839 which talks about
misaligned partitions. Having had issue with that before (unrelated to
this), I now make sure that the first partition starts at 8192 and that
the total sectors is divisible by 8192 (although 4096 is likely enough).
The `fdisk` program appears to nicely align partitions by default now.
So AFAICT, this is NOT applicable to my situation.

https://askubuntu.com/a/1237638 indicates that the warning is a sanity
check by the kernel and that the kernel 'works around' the incorrectly
reported optimal transfer size.

But it seems to be a bug when it does so on one drive but not the other.

Some data from USB drive:
# lsusb -tvvv
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 1M
ID 1d6b:0003 Linux Foundation 3.0 root hub
/sys/bus/usb/devices/usb2  /dev/bus/usb/002/001
|__ Port 3: Dev 5, If 0, Class=Mass Storage, Driver=uas, 5000M
ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, 
ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s 
bridge
/sys/bus/usb/devices/2-3  /dev/bus/usb/002/005

# lsblk -t /dev/sdb
NAME   ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED   RQ-SIZE  RA 
WSAME
sdb0   4096  04096 5121 mq-deadline  60 128   
32M
└─sdb1 0   4096  04096 5121 mq-deadline  60 128   
32M

# sg_readcap -l /dev/sdb
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=0, lbprz=0
   Last LBA=5860533167 (0x15d50a3af), Number of logical blocks=5860533168
   Logical block length=512 bytes
   Logical blocks per physical block exponent=3 [so physical block length=4096 
bytes]
   Lowest aligned LBA=0
Hence:
   Device size: 3000592982016 bytes, 2861588.5 MiB, 3000.59 GB, 3.00 TB

# sg_vpd -p bl /dev/sdb
Block limits VPD page (SBC):
  Write same non-zero (WSNZ): 0
  Maximum compare and write length: 0 blocks [Command not implemented]
  Optimal transfer length granularity: 8 blocks
  Maximum transfer length: 65535 blocks
  Optimal transfer length: 65535 blocks
  Maximum prefetch transfer length: 65535 blocks
  Maximum unmap LBA count: 0 [Unmap command not implemented]
  Maximum unmap block descriptor count: 0 [Unmap command not implemented]
  Optimal unmap granularity: 0 blocks [not reported]
  Unmap granularity alignment valid: false
  Unmap granularity 

Bug#1010084: x11-xkb-utils: xkbcomp outputs many warnings without "-w 0"

[Vincent Lefevre]

Package: x11-xkb-utils
Version: 7.7+6
Severity: normal

Without "-w 0", I get many warnings with xkbcomp:

zira:~> xkbcomp -I$HOME/.xkb -R$HOME/.xkb keymap/test xkb.dump
Keycodes above 256 (e.g. ) are not supported by X and are ignored
Warning:  Could not resolve keysym XF86EmojiPicker
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) keycodes
  Symbols ignored
Warning:  Key  not found in evdev+aliases(qwerty) 

Bug#970104: rust-gstreamer has unsatisfiable dependency on non-existent rust-futures-core-preview

[Peter Michael Green]

I took a look at updating rust-gstreamer to 0.17.4 (this is not the 
latest version, but it is the version corresponding to the current rust 
gtk stack in Debian) and hence solving the dependency issues with the 
current package. There were two unsatisfied dependencies: muldiv 1.x and 
pretty-hex 0.2. The former simply needed an update to the latest 
upstream (there are no other reverse dependencies in Debian), but the 
latter looks like it will need packaging from scratch.

Bug#1009433: tried but got stuck with dgit and git-debrebase

[Sean Whitton]

Hello,

On Sat 23 Apr 2022 at 09:10PM +03, Thomas Koch wrote:

> I think I believe how to fix the FTBFS:
>
> --- a/debian/patches/0005-configure-mkdocs-for-Debian.patch
> +++ b/debian/patches/0005-configure-mkdocs-for-Debian.patch
> @@ -23,7 +23,8 @@ index 1302441..05ada85 100644
>  +site_dir: html
>   copyright: "Copyright (C) 2011-2020 Bozhidar Batsov and Projectile 
> contributors"
>   docs_dir: doc
> - pages:
> +-pages:
> ++nav:
>   - Home: index.md
>  -- Installation: installation.md
>   - Usage: usage.md
>
> But I'm stuck since I need to finally learn dgit and apparently 
> git-debrebase. I'll start with the manpages.

dgit-maint-debrebase(7) should be in a "How do I ..." format; let me
know if there are parts that are unclear.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1010000: podman run panics with "assignment to entry in nil map"

[Xavier G.]

Package: podman
Version: 3.4.7+ds1-2
Followup-For: Bug #101

Dear Maintainer,

Unfortunately, it seems upgrading from 3.4.7+ds1-1 to 3.4.7+ds1-2 does not
solve the issue reported by Norbert.

I tested as root user to avoid potential rootless-induced issues:

# dpkg -l podman
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---==
ii  podman 3.4.7+ds1-2  amd64engine to run OCI-based containers 
in Pods

# podman run alpine date
panic: assignment to entry in nil map

goroutine 1 [running]:
github.com/opencontainers/runtime-tools/generate.(*Generator).addEnv(...)
github.com/opencontainers/runtime-tools/generate/generate.go:532
github.com/opencontainers/runtime-tools/generate.(*Generator).AddProcessEnv(0xc00053da20,
 {0x17edeb7, 0x8}, {0xc0004022c0, 0xc})
github.com/opencontainers/runtime-tools/generate/generate.go:508 +0x2ea
github.com/containers/podman/libpod.(*Container).generateSpec(0xc00031e790, 
{0x1ad3150, 0xc000228d20})
github.com/containers/podman/libpod/container_internal_linux.go:648 
+0x2965
github.com/containers/podman/libpod.(*Container).init(0xc00031e790, {0x1ad3150, 
0xc000228d20}, 0x0)
github.com/containers/podman/libpod/container_internal.go:1098 +0x8e
github.com/containers/podman/libpod.(*Container).prepareToStart(0xc00031e790, 
{0x1ad3150, 0xc000228d20}, 0xa8?)
github.com/containers/podman/libpod/container_internal.go:875 +0x345
github.com/containers/podman/libpod.(*Container).StartAndAttach(0xc00031e790, 
{0x1ad3150?, 0xc000228d20?}, 0xc0006300c0, {0x17f5ed4, 0xd}, 0xc949c0, 
0xb0?)
github.com/containers/podman/libpod/container_api.go:115 +0x145
github.com/containers/podman/pkg/domain/infra/abi/terminal.StartAttachCtr({0x1ad3150,
 0xc000228d20}, 0xc00031e790, 0xc10018, 0xc10020, 0x0, {0x17f5ed4, 
0xd}, 0x1, 0x1)

github.com/containers/podman/pkg/domain/infra/abi/terminal/terminal_linux.go:91 
+0x546
github.com/containers/podman/pkg/domain/infra/abi.(*ContainerEngine).ContainerRun(0xc0001249f8,
 {0x1ad3150, 0xc000228d20}, {{0x0, 0x0}, 0x0, {0x17f5ed4, 0xd}, 0xc10020, 
0x0, ...})
github.com/containers/podman/pkg/domain/infra/abi/containers.go:957 
+0x31e
github.com/containers/podman/cmd/podman/containers.run(0x25046a0?, 
{0xc4ae60?, 0x2, 0x2})
github.com/containers/podman/cmd/podman/containers/run.go:194 +0x7e6
github.com/spf13/cobra.(*Command).execute(0x25046a0, {0xc3c0a0, 0x2, 0x2})
github.com/spf13/cobra/command.go:856 +0x67c
github.com/spf13/cobra.(*Command).ExecuteC(0x251b3a0)
github.com/spf13/cobra/command.go:974 +0x3b4
github.com/spf13/cobra.(*Command).Execute(...)
github.com/spf13/cobra/command.go:902
github.com/spf13/cobra.(*Command).ExecuteContext(...)
github.com/spf13/cobra/command.go:895
main.Execute()
github.com/containers/podman/cmd/podman/root.go:91 +0xc5
main.main()
github.com/containers/podman/cmd/podman/main.go:39 +0x74

Let me know if there is anything I can do to help on this matter.
Thanks for your work.

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

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

Versions of packages podman depends on:
ii  conmon   2.0.25+ds1-1.1
ii  containernetworking-plugins  1.1.0+ds1-1
ii  crun 0.17+dfsg-1.1
ii  golang-github-containers-common  0.44.5+ds1-1
ii  libc62.33-7
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libgpgme11   1.16.0-1.2
ii  libseccomp2  2.5.4-1
ii  runc 1.1.1+ds1-1

Versions of packages podman recommends:
ii  buildah   1.23.1+ds1-2
pn  catatonit | tini | dumb-init  
ii  fuse-overlayfs1.8.2-1
pn  golang-github-containernetworking-plugin-dnsname  
ii  slirp4netns   1.0.1-2
ii  uidmap1:4.11.1+dfsg1-2

Versions of packages podman suggests:
ii  containers-storage  1.37.2+ds1-1
ii  docker-compose  1.29.2-1
ii  iptables1.8.7-1

-- no debconf information

Bug#1010083: librust-addr2line-dev: please upgrade to newer release

[Jonas Smedegaard]

Package: librust-addr2line-dev
Version: 0.10.0-3
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

addr2line v0.10.0 was released almost 3 years ago, with many releases,
most recent being v0.17.0.

When trying to build Rust crate safe_network, it depends on addr2line
and when mangled to use addr2line v0.10, the build fails to compile
addr2line:

   Compiling addr2line v0.10.0
 Running `rustc --crate-name addr2line 
/build/safe-network-0.58.13/debian/cargo_registry/addr2line-0.10.0/src/lib.rs 
--error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib 
--emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C 
metadata=d3681081280e189f -C extra-filename=-d3681081280e189f --out-dir 
/build/safe-network-0.58.13/target/release/deps -L 
dependency=/build/safe-network-0.58.13/target/release/deps --extern 
fallible_iterator=/build/safe-network-0.58.13/target/release/deps/libfallible_iterator-f3571a2c74a91535.rmeta
 --extern 
gimli=/build/safe-network-0.58.13/target/release/deps/libgimli-3a53fbdb8cf73933.rmeta
 --extern 
intervaltree=/build/safe-network-0.58.13/target/release/deps/libintervaltree-8717046d402b258c.rmeta
 --extern 
lazycell=/build/safe-network-0.58.13/target/release/deps/liblazycell-1d2e2cbafc57f2df.rmeta
 --extern 
smallvec=/build/safe-network-0.58.13/target/release/deps/libsmallvec-c329857f37f1e605.rmeta
 --cap-lints allow -C debuginfo=2 --cap-lints warn -C 
linker=x86_64-linux-gnu-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix 
/build/safe-network-0.58.13=/usr/share/cargo/registry/safe-network-0.58.13`
error[E0277]: the trait bound `Rc<[u8]>: CloneStableDeref` is not satisfied
   --> 
/usr/share/cargo/registry/safe-network-0.58.13/debian/cargo_registry/addr2line-0.10.0/src/lib.rs:92:20
|
92  | pub struct Context>
|^ the trait `CloneStableDeref` is not implemented for 
`Rc<[u8]>`
|
note: required by a bound in `EndianReader`

error[E0277]: the trait bound `Rc<[u8]>: CloneStableDeref` is not satisfied
   --> 
/usr/share/cargo/registry/safe-network-0.58.13/debian/cargo_registry/addr2line-0.10.0/src/lib.rs:101:14
|
101 | impl Context> {
|  ^^ the trait 
`CloneStableDeref` is not implemented for `Rc<[u8]>`
|
note: required by a bound in `EndianReader`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `addr2line` due to 2 previous errors


It seems at least the first of those two errors is addressed before the
next upstream release, v0.11.0 (see upstream git commit bd20153).

Please upgrade addr2line to a newer release - preferably v0.17.0 but
possibly v0.13.0 (in experimental since more than 5 months) is adequate.

Raising severity due to the (seemingly general) failure to build.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJkZ7YACgkQLHwxRsGg
ASF6AQ/+MM0F+PwDXX2KVgjLE+XJ/ioSheoi0jDrJUAF5K7XKeWDFZOrMHlSTicS
jBGw3sJMHNLqhXXEfI25wlWt5GppOToPaXh/yYZzQ6zxGmWZ651+RXgqFgs+lwRC
5ojZrYbcyJ0hDJ9UKRL4T9cvV5mKzv2n/58Nnbc5rcNTHwYn8tzuVG96/Qfkr+OZ
4H9QKHOWl8NRS5KCmdMBqGlCwonIZZ6BeogkvPhw2uSQpGKAFe9MZ39RD7FY/GjY
okH+GCEg6StJ3DY/KWDltrrO8x+Kt059dwrg5Nz1/c2bogHs6neZyJC5uZiF9koW
hC4vbpLYz6gJst/qPEIVel4nXF6CL5KVOcUEDce62aot3y5qAHXRpnfNghdyhtZY
xV9/+AEnRp8ALCOZPQAMAcf9Z8k5MblE03TTXT1Oi6+7AN824oY7aSREiQQk25Lk
iN1hlzH66YSY/tHUzBJxUsrULKQ0bznPvaHwl/zjFGIay3nkoWa1awNmUUsF89rO
Wq2ZqNp+ECIH38EkEjA7ZrVsLJHfO1NebqTxoj1KK/5yJH02FyX/Vh/rvFe27DDa
dha7tglyfbOHfAE2Xxsk58x1Oi+AORA03L3vM3qkgsP3L3J+rW2IjzpK+HkF0dYx
Z4OSExf/YriZi+QB/mkiLIMx5sP2AlAsPF5Z/F/1/r/NAWIJEIU=
=roN1
-END PGP SIGNATURE-

Bug#1010082: please drop qemu from recommends

[Michael Tokarev]

Package: due
Version: 3.0.0-1
Severity: normal
X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org

Please drop "qemu" package from Recommends. It makes no sense, qemu is
a dummy no-op package for a few debian releases already and is going away.

/mjt

Bug#1010081: please drop qemu from recommends

[Michael Tokarev]

Package: packer
Version: 1.6.6+ds1-4
Severity: normal
X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org

recommending qemu makes no sense. It is a dummy package
for a few debian releases already and is going away.

/mjt

Bug#1010080: wiki.debian.org: silently fails to create account

[Forest]

Package: wiki.debian.org
Severity: important
X-Debbugs-Cc: fores...@sonic.net

Dear Maintainer,

After filling in and submitting the wiki's Create Account form, the wiki
returns me to the last page I was visiting, apparently ignoring my submission
completely.

It doesn't acknowledge that an account was created.
It doesn't show an error message.
It doesn't send me an email confirmation message.
It doesn't show me as logged it.
It doesn't log me in when I use the login form.

It behaves as if I never submitted the New Account form at all.

I am therefore unable to contribute to the wiki.

Bug#1009865: transition: octave

[Rafael Laboissière]

* Sébastien Villemot  [2022-04-23 13:02]:


Le samedi 23 avril 2022 à 12:40 +0200, Rafael Laboissière a écrit :

Version 0.3.1~git.2019.04.13-4 of the octave-level-set package, just 
uploaded to unstable, seems to build correctly against Octave 7.1.


Great, thanks. Then you should probably close #1009180.


Done! Thanks for the reminder.

Rafael Laboissière

Bug#1010077: ITP: r-cran-xlsx -- Read, Write, Format Excel 2007 and Excel 97/2000/XP/2003 Files

[Eric Brown]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: e...@ericebrown.com

Subject: ITP: r-cran-xlsx -- Read, Write, Format Excel 2007 and Excel 
97/2000/XP/2003 Files
Package: wnpp
Owner: Eric Brown 
Severity: wishlist

* Package name: r-cran-xlsx
  Version : 0.6.5
  Upstream Author : Adrian Dragulescu,
* URL : https://cran.r-project.org/package=xlsx
* License : GPL-3
  Programming Lang: GNU R
  Description : Read, Write, Format Excel 2007 and Excel 97/2000/XP/2003 
Files
 Provide R functions to read/write/format Excel 2007 and Excel
 97/2000/XP/2003 file formats.

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

Bug#1009996: IBus broken on GNOME on x11

[Gunnar Hjalmarsson]

Control: affects -1 gnome-settings-daemon

Hi Osamu,

On 2022-04-22 18:28, Osamu Aoki wrote:

Since no-no, I agree to go with what you proposed.


Thanks for the green light.

I submitted an upstream gnome-settings-daemon issue:

https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/682

I'm thinking that I should wait and see if I get any useful response 
within a couple of days. If not, I'm going to apply and upload the 
im-config patch for now. And yes, we should review the situation in a 
few months.



In order to avoid future confusion, can you add some of the key facts
you stated.


Isn't a reference to this bug, and maybe also the g-s-d issue with a 
more concise and complete problem description, sufficient?



As I read the discussion, if this bug affects Debian/testing, and
GTK_IM_MODULE=ibus solves major concern which may come with on-screen
keyboard, that's OK.


Note that the OSK issue, which we discussed a lot a while ago, only 
happens in wayland. It was never an x11 issue.


--
Gunnar

Bug#1010076: ITP: r-cran-xlsxjars -- Package required POI jars for the xlsx package

[Eric Brown]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: e...@ericebrown.com

Subject: ITP: r-cran-xlsxjars -- Package required POI jars for the xlsx package
Package: wnpp
Owner: Eric Brown 
Severity: wishlist

* Package name: r-cran-xlsxjars
  Version : 0.6.1
  Upstream Author : Adrian A. Dragulescu,
* URL : https://cran.r-project.org/package=xlsxjars
* License : GPL-3
  Programming Lang: GNU R
  Description : Package required POI jars for the xlsx package
 The xlsxjars package collects all the external jars
 required for the xlxs package. This release corresponds to POI
 3.10.1.

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

Bug#1009971: Our current validation script does not work with html5 files

[Shlomi Fish]

Hi Laura!

On Thu, 21 Apr 2022 15:53:03 +0200
Laura Arjona Reina  wrote:

> Package: www.debian.org
> User: www.debian@packages.debian.org
> Usertag: scripts
> Severity: important
> 
> Hi all
> I'm starting to work in the bug #980921 (Pages in HTML5) and, as it is
> mentioned there, we need to adapt our "validate" script so it correctly
> processes the pages declared as HTML5 (currently, only the homepage in the
> different languages).
> 
> The current status is following:
> 
> Related scripts:
> 
> https://salsa.debian.org/webmaster-team/cron/-/blob/master/lessoften executed
> once a day, calling (via run-parts) the following script:
> https://salsa.debian.org/webmaster-team/cron/-/blob/master/scripts/999Xvalidate
> which gets the list of languages and folders to process and then calls:
> 
> https://salsa.debian.org/webmaster-team/cron/-/blob/master/scripts/validate
> 
> Which is the actual script doing the HTML validation, using the onsgmls
> command (part of opensp package). 
> 
> This command validates a SGML file based on a DTD. The issue (as far as I
> know) is that there is no "official" SGML DTD template to use when parsing
> HTML5 files.
> 
> I have tried adapting the "validate" script to be able to recognize the
> DOCTYPE header used for html5 files, and then tried to pass a DTD (I tried
> downloading the ones here http://sgmljs.net/docs/w3c-html5-dtd.html and here
> http://sgmljs.net/docs/w3c-html52-dtd.html and also here
> https://jkorpela.fi/html5-dtd.html ) but couldn't make it work, and also was
> not convinced it is the better approach.
> 
> I've tried to look at what w3c validator uses and they use Nu.checker:
> 
> https://validator.w3.org/nu/about.html
> https://github.com/validator/validator/releases/latest
> 
> But I'm not sure if this is packaged in Debian in any of its flavours.
> 
> I have searched https://packages.debian.org/search?keywords=html5 but none of
> the results looks like a commandline tool that we could call instead of
> onsgmls
> 
> So I don't know what to do at this point.
> 
> In my local machine, I have downloaded the vnu.jar file from the latest Nu
> checker release " and tried to validate files and it works. But I don't know
> if asking DSA to install openjdk in www-master and include a copy of vnu.jar
> in our cron scripts is good and/or elegant.
> 
> Opinions, advice and patches are very welcome.
> 
> Meanwhile, I guess we can modify 99Xvalidate to add file exclusions, and
> exclude, for now, /index.*.html and later the few other files we have with
> html5 tags for now. I don't know how to exclude the index.*.html files on top
> folder only and not in subfolders but I guess playing with find -wholename
> and prune will do the treak (if you know, please go ahead).
> 
> Kind regards,

Perhaps my vnu wrapper will prove of use:

* https://github.com/shlomif/python-vnu_validator

* https://pypi.org/project/vnu-validator/

*
https://github.com/shlomif/shlomi-fish-homepage/blob/master/Tests/validate-html-using-vnu.py
 

-- 

Shlomi Fish   https://www.shlomifish.org/
What Makes Software Apps High Quality -  https://shlom.in/sw-quality

 Underscores are the most nutritious punctuation. But you also need
to eat letters, digits and whitespace for a balanced diet.
— https://is.gd/pHLcFq

Please reply to list if it's a mailing list post - https://shlom.in/reply .

Bug#894316: intentional behaviour

[Johannes Berg]

Hi,

This is not a bug, it's intentional behaviour. The help text states:

dev  scan trigger ... [ssid *|passive]
Trigger a scan on the given frequencies **with probing for the 
given
SSIDs** (or wildcard if not given) unless passive scanning is 
requested.
Duration(in TUs), if specified, will be used to set dwell times.

("**" highlight mine, some stuff elided with "...")

This is correct, and should be implemented this way in hopefully all
drivers, certainly all the ones I know of.

However, this does *not* mean that it will also *show* only networks
with the given SSID(s), it merely means that the underlying driver only
*sends probes* for those SSID(s). All other networks discovered at the
same time, by passively picking up other beacons or probe responses, or
perhaps even by a previous scan, will still be shown.

johannes

Bug#930271: upstream reporting

[Johannes Berg]

Hi,

If you do end up reporting this upstream, please make sure you indicate
the driver that's being used - this is highly unusual behaviour and for
most drivers that correctly use cfg80211 it shouldn't even be possible
to end up with this behaviour.

johannes

Bug#1010073:

[Андрій Василишин]

On other server with same configuration


Apr 23 22:30:43 nl03 kernel: [613296.099396] Modules linked in: binfmt_misc
msr mst_pciconf(OE) amd64_edac_mod edac_mce_amd kvm_amd kvm irqbypass
crct10dif_pclmul efi_pstore crc32_pclmul ghash_clmulni_intel efivars pcspkr
ipmi_ssif nls_ascii nls_cp437 vfat fat ast ttm joydev drm_kms_helper drm
ccp i2c_algo_bit rng_core evdev sp5100_tco ipmi_si ipmi_devintf
ipmi_msghandler pcc_cpufreq acpi_cpufreq button tcp_bbr sch_fq aufs(OE)
efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic
fscrypto ecb hid_generic usbhid hid mlx5_core(OE) mlxfw(OE) xhci_pci
psample crc32c_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper
mlxdevm(OE) xhci_hcd ahci auxiliary(OE) libahci libata mlx_compat(OE) nvme
usbcore devlink scsi_mod nvme_core i2c_piix4 usb_common [last unloaded:
mst_pci]
Apr 23 22:30:43 nl03 kernel: [613296.099438] CPU: 20 PID: 135069 Comm:
nginx Tainted: GW  OEL4.19.0-20-amd64 #1 Debian 4.19.235-1
Apr 23 22:30:43 nl03 kernel: [613296.099439] Hardware name: Supermicro AS
-1124US-TNRP/H12DSU-iN, BIOS 2.3a 03/03/2022
Apr 23 22:30:43 nl03 kernel: [613296.099444] RIP:
0010:_raw_spin_unlock_irqrestore+0x11/0x20
Apr 23 22:30:43 nl03 kernel: [613296.099445] Code: d8 48 3d 90 d0 03 00 76
cc 80 4d 00 08 eb 98 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 c6 07 00
0f 1f 40 00 48 89 f7 57 9d <0f> 1f 44 00 00 c3 66 0f 1f 84 00 00 00 00 00
0f 1f 44 00 00 8b 07
Apr 23 22:30:43 nl03 kernel: [613296.099446] RSP: 0018:9c930d103e88
EFLAGS: 0282 ORIG_RAX: ff13
Apr 23 22:30:43 nl03 kernel: [613296.099447] RAX: 0009 RBX:
d9380721d658 RCX: 0082
Apr 23 22:30:43 nl03 kernel: [613296.099448] RDX: 9c92dfcdc000 RSI:
0282 RDI: 0282
Apr 23 22:30:43 nl03 kernel: [613296.099448] RBP:  R08:
 R09: b40f6001
Apr 23 22:30:43 nl03 kernel: [613296.099449] R10: 9c164669d700 R11:
0001 R12: 9d928c6d0858
Apr 23 22:30:43 nl03 kernel: [613296.099449] R13: 0282 R14:
9d928c6d0140 R15: d9380721f660
Apr 23 22:30:43 nl03 kernel: [613296.099450] FS:  7fa7d9ef0b80()
GS:9c930d10() knlGS:
Apr 23 22:30:43 nl03 kernel: [613296.099451] CS:  0010 DS:  ES: 
CR0: 80050033
Apr 23 22:30:43 nl03 kernel: [613296.099451] CR2: 55cfa4118000 CR3:
01004a9f8000 CR4: 00340ee0
Apr 23 22:30:43 nl03 kernel: [613296.099452] Call Trace:
Apr 23 22:30:43 nl03 kernel: [613296.099453]  
Apr 23 22:30:43 nl03 kernel: [613296.099456]  fq_flush_timeout+0x6a/0x90
Apr 23 22:30:43 nl03 kernel: [613296.099459]  ? fq_ring_free+0xd0/0xd0
Apr 23 22:30:43 nl03 kernel: [613296.099462]  call_timer_fn+0x2b/0x130
Apr 23 22:30:43 nl03 kernel: [613296.099464]  run_timer_softirq+0x1c7/0x3e0
Apr 23 22:30:43 nl03 kernel: [613296.099465]  __do_softirq+0xde/0x2d8
Apr 23 22:30:43 nl03 kernel: [613296.099468]  irq_exit+0xba/0xc0
Apr 23 22:30:43 nl03 kernel: [613296.099469]
 smp_apic_timer_interrupt+0x74/0x140
Apr 23 22:30:43 nl03 kernel: [613296.099471]  apic_timer_interrupt+0xf/0x20
Apr 23 22:30:43 nl03 kernel: [613296.099472]  
Apr 23 22:30:43 nl03 kernel: [613296.099473] RIP:
0010:_raw_spin_unlock_irqrestore+0x11/0x20
Apr 23 22:30:43 nl03 kernel: [613296.099474] Code: d8 48 3d 90 d0 03 00 76
cc 80 4d 00 08 eb 98 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 c6 07 00
0f 1f 40 00 48 89 f7 57 9d <0f> 1f 44 00 00 c3 66 0f 1f 84 00 00 00 00 00
0f 1f 44 00 00 8b 07
Apr 23 22:30:43 nl03 kernel: [613296.099474] RSP: 0018:ba37da943638
EFLAGS: 0297 ORIG_RAX: ff13
Apr 23 22:30:43 nl03 kernel: [613296.099475] RAX: 9c9276209c00 RBX:
9c92e05bc140 RCX: 9c926d1046c1
Apr 23 22:30:43 nl03 kernel: [613296.099476] RDX: 9d72ec4e0640 RSI:
0297 RDI: 0297
Apr 23 22:30:43 nl03 kernel: [613296.099476] RBP: 00fc R08:
008c R09: 9c15dcdc9e40
Apr 23 22:30:43 nl03 kernel: [613296.099476] R10:  R11:
9c90f4ed2000 R12: 9c15dcdc9e40
Apr 23 22:30:43 nl03 kernel: [613296.099477] R13: 0100 R14:
ff00 R15: ff00
Apr 23 22:30:43 nl03 kernel: [613296.099478]  alloc_iova+0x11f/0x140
Apr 23 22:30:43 nl03 kernel: [613296.099480]  alloc_iova_fast+0x56/0x250
Apr 23 22:30:43 nl03 kernel: [613296.099483]  ? __kmalloc+0x180/0x220
Apr 23 22:30:43 nl03 kernel: [613296.099485]  ? mempool_alloc+0x67/0x190
Apr 23 22:30:43 nl03 kernel: [613296.099486]
 dma_ops_alloc_iova.isra.28+0x4b/0x70
Apr 23 22:30:43 nl03 kernel: [613296.099488]  map_sg+0x73/0x1f0
Apr 23 22:30:43 nl03 kernel: [613296.099492]  nvme_queue_rq+0x1e7/0x9e0
[nvme]
Apr 23 22:30:43 nl03 kernel: [613296.099495]  ?
__sbitmap_queue_get+0x24/0x90
Apr 23 22:30:43 nl03 kernel: [613296.099497]  ? blk_mq_get_tag+0x236/0x260
Apr 23 22:30:43 nl03 kernel: [613296.099499]  ? finish_wait+0x80/0x80
Apr 23 22:30:43 nl03 kernel: [613296.099500]
 

Bug#895422: Bug#1010065: ITP: swagger-ui -- Swagger UI is a collection of HTML, JavaScript, and CSS assets that dynamically generate beautiful documentation from a Swagger-compliant API.

[Yadd]

On 23/04/2022 16:26, Salvatore Bonaccorso wrote:

Hi Jelmer,

On Sat, Apr 23, 2022 at 02:05:45PM +, Jelmer Vernooij wrote:

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

* Package name: swagger-ui
   Version : 4.10.3
   Upstream Author : Name 
* URL : https://github.com/swagger-api/swagger-ui
* License : Apache-2.0
   Programming Lang: Javsscript
   Description : generate beautiful documentation from a Swagger-compliant 
API

Swagger UI allows anyone — be it your development team or your end consumers —
to visualize and interact with the API’s resources without having any of the
implementation logic in place. It’s automatically generated from your OpenAPI
(formerly known as Swagger) Specification, with the visual documentation making
it easy for back end implementation and client side consumption.


There seems to be already a ITP for swagger-ui at #895422. I would
suggest to coordinate with Yadd, who in an earlier attempt marked it
as pending, Cc'ing.

Regards,
Salvatore


Hi,

I didn't finished the job. The repo is js-team/swagger-ui

Cheers,
Yadd

Bug#1010075: librust-intervaltree+std-dev: please upgrade to v0.2.7

[Jonas Smedegaard]

Package: librust-intervaltree+std-dev
Version: 0.2.4-2
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

intervaltree v0.2.4 was released upstream almost 3 years ago, and
several releases has been issued since.

Trying to build safe_network (see bug#1008016) coerced to use
Debian-packaged addr2line fails to build Debian-packaged intervaltree:

   Compiling intervaltree v0.2.4
 Running `rustc --crate-name intervaltree 
/build/safe-network-0.58.13/debian/cargo_registry/intervaltree-0.2.4/src/lib.rs 
--error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib 
--emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C 
metadata=375a2031b4daf0bd -C extra-filename=-375a2031b4daf0bd --out-dir 
/build/safe-network-0.58.13/target/release/deps -L 
dependency=/build/safe-network-0.58.13/target/release/deps --extern 
smallvec=/build/safe-network-0.58.13/target/release/deps/libsmallvec-c329857f37f1e605.rmeta
 --cap-lints allow -C debuginfo=2 --cap-lints warn -C 
linker=x86_64-linux-gnu-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix 
/build/safe-network-0.58.13=/usr/share/cargo/registry/safe-network-0.58.13`
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> 
/usr/share/cargo/registry/safe-network-0.58.13/debian/cargo_registry/intervaltree-0.2.4/src/lib.rs:2:43
  |
2 | #![cfg_attr(not(feature = "std"), feature(alloc))]
  |   ^

For more information about this error, try `rustc --explain E0554`.
error: could not compile `intervaltree` due to previous error

It seems that the above error was fixed for intervaltree v0.2.7, which
was released upstream more than 5 months ago.

Please upgrade intervaltree to v0.2.7.

Raising severity due to the (suspected general) failure to build modern
code linked against currently packaged crate.


Kind regards,

 - Jonas

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

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

Versions of packages librust-intervaltree+std-dev depends on:
pn  librust-intervaltree-dev  
pn  librust-smallvec-1+write-dev  

librust-intervaltree+std-dev recommends no packages.

librust-intervaltree+std-dev suggests no packages.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJkUkYACgkQLHwxRsGg
ASFK+w/6AqKiC+QZ74kkLtsEKMZjfbw6+RhtRot9TqMOs9qiibTK/Jahv8VVJd1O
748loBLgKrEBNA1ae6pyCX61r2HaI2QbL5HjlfgqPAHoprowaFjhSPXYIzafa6QU
kMCtW2CBmt1DxDvaAISvwpb9ZujKaG8yooMte/rkciVtZpVa4o9TdnTx4GI4qYWv
mUiDIEFh9FSnqqRUUzyzRIqhl08iZ+2gBonZgoEESqFv+3VppH7u4rDmaEGr6J7O
X4s9wIAbUfeOXLNb8oMuEHJ/ZW5jCD77TyMBEfxnH/Ot2jx5pUBzYe9FGpYExpLB
D+pR6vleB2TQgMBxlHj+QibYYbwt4ENyvQ8H33MyCqnBcJa+q/qEo8B2fzwUfG00
NiwYymTL9zRPZjLVzOYhBUrNRtBoa3NCtq92aRMo/7KYFkHb0Qa2tls06dqA6t10
e9UlanVJOqq1q2C/Fir0nb1nD8K+ggmfENGCFwvFxah0Kk5fUtsVqkjvB1rZdlwc
5VmAZ56YN4vRVn39ZfwVW7jrS66Gz4rEYQJpQHZJxA4j6eRgbHsJ6YVxQQ1S9KBM
rUxf+6cAIO/2zhzj9EYBEC6rSkyV5K0VEXMICL0aaP95Q0+vEIyD2HUqOdbS2/x/
EVhp/QJHMMTn0I6Zp0yaNVc2Mh/c5nGu775Z5X8exYgrLIEO1bs=
=A8Fw
-END PGP SIGNATURE-

Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it

[Tino Mettler]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "show-in-file-manager":

 * Package name: show-in-file-manager
   Version : 1.1.4-1
   Upstream Author : Damon Lynch 
 * URL : https://github.com/damonlynch/showinfilemanager
 * License : Expat
 * Vcs : 
https://salsa.debian.org/python-team/packages/python-show-in-file-manager
   Section : python

This python libary is required by recent upstream version for
rapid-photo-downloader, a mighty tool to transfer pictures from cameras
and other devices.  Recently, rapid-photo-downloader got broken in
unstable due to Python changes. 

This package is needed to update the rapid-photo-downloader package to
the current upstream version and make it work again. It is mostly a
copy of the current Ubuntu package with minor adjustments.

Antoine Beaupré suggested to put it into the Python team on Salsa.

The source builds the following binary packages:

  python3-showinfilemanager - Open the system file manager and optionally 
select files in it

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

  https://mentors.debian.net/package/show-in-file-manager/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/show-in-file-manager/show-in-file-manager_1.1.4-1.dsc

Changes for the initial release:

 show-in-file-manager (1.1.4-1) unstable; urgency=medium
 .
   * First upload in Debian (Closes: #1009782)

Regards,
-- 
  Tino Mettler

Bug#1009188: kernel 5.17

[alain]

tested ipp-usb with 5.17 kernel .


do not work anymore . i made an error ? i forgot something ?


any ideas for testing and debugging ?


thanks ,

friendly ,

respectfully .

alain .

Bug#1009433: tried but got stuck with dgit and git-debrebase

[Thomas Koch]

I think I believe how to fix the FTBFS:

--- a/debian/patches/0005-configure-mkdocs-for-Debian.patch
+++ b/debian/patches/0005-configure-mkdocs-for-Debian.patch
@@ -23,7 +23,8 @@ index 1302441..05ada85 100644
 +site_dir: html
  copyright: "Copyright (C) 2011-2020 Bozhidar Batsov and Projectile 
contributors"
  docs_dir: doc
- pages:
+-pages:
++nav:
  - Home: index.md
 -- Installation: installation.md
  - Usage: usage.md

But I'm stuck since I need to finally learn dgit and apparently git-debrebase. 
I'll start with the manpages.

Bug#1008929: python3-django-hyperkitty: Error gone with python3-django update

[Colin Turner]

Package: python3-django-hyperkitty
Followup-For: Bug #1008929

Dear Maintainer,

This seems to have gone as of a python3-django update or some similar update. I 
don't really know why?

I did have to run a "migrate" but that seemed to be related to a different SQL 
cron complaint.

Kind regards,

CT.

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

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

Versions of packages python3-django-hyperkitty depends on:
ii  fonts-glyphicons-halflings   1.009~3.4.1+dfsg-2
ii  libjs-bootstrap4 4.6.1+dfsg1-1
ii  libjs-sphinxdoc  4.5.0-3
ii  python3  3.10.4-1
ii  python3-dateutil 2.8.1-6
ii  python3-django   2:3.2.13-1
ii  python3-django-compressor2.4.1-2
ii  python3-django-extensions3.1.5-2
ii  python3-django-gravatar2 1.4.4-2
ii  python3-django-haystack  3.1.1-1
ii  python3-django-mailman3  1.3.7-1
ii  python3-django-q 1.3.9-3
ii  python3-djangorestframework  3.12.4-2.1
ii  python3-elasticsearch7.16.2-1
ii  python3-flufl.lock   5.0.1-1
ii  python3-mailmanclient3.3.3-1
ii  python3-mistune  2.0.2-1
ii  python3-networkx 2.5+ds-2
ii  python3-robot-detection  0.4.0-2
ii  python3-tz   2022.1-1

Versions of packages python3-django-hyperkitty recommends:
ii  mailman3-web  0+20200530-2

python3-django-hyperkitty suggests no packages.

-- no debconf information

Bug#1010057: digikam: Failed when generated data-base

[Steven Robbins]

On Saturday, April 23, 2022 7:23:48 A.M. CDT Hoareau Jean Pierre wrote:
> Package: digikam
> Version: 4:7.6.0-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> I installed Debian "Bookworm" in order to test this version. When launching
> "Digikam" I get a database loading/generation error.

Are you using an external DB like mysql/mariadb?  
Does the workaround in this report help?  
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007220

If not, can you provide reproduction steps?  Digikam 7.6.0 works for me so the 
reproduction will need explicit configuration steps.  Maybe you can configure 
from scratch for a new folder and share those steps?

Regards,
-Steve


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

Bug#1009913: dpkg: when the user reverts to the package maintainer's version of a conffile, the execute bit is not propagated

[Guillem Jover]

Hi!

On Wed, 2022-04-20 at 17:17:16 +0200, Vincent Lefevre wrote:
> Package: dpkg
> Version: 1.21.7
> Severity: normal

> In an upgrade, the user may get a prompt like that and answer yes
> to install the package maintainer's version of a conffile, thus
> reverting all changes done he had done:
> 
> Configuration file '/etc/resolvconf/update.d/unbound'
>  ==> Modified (by you or by a script) since installation.
>  ==> Package distributor has shipped an updated version.
>What would you like to do about it ?  Your options are:
> Y or I  : install the package maintainer's version
> N or O  : keep your currently-installed version
>   D : show the differences between the versions
>   Z : start a shell to examine the situation
>  The default action is to keep your current version.
> *** unbound (Y/I/N/O/D/Z) [default=N] ? Y
> Installing new version of config file /etc/resolvconf/update.d/unbound ...
> [...]
> 
> However, if the user had changed the execute permission, e.g. to
> enable the script after modifying it, the execute permission is
> not restored to the default one.
> 
> The execute permission is part of the file, thus should be propagated
> like the contents.

Right, ideally yes.

> The current behavior is an issue since a script may be disabled
> by default because it could be incorrect until the user has
> adapted it for his own usage. And the message like
> 
>   Installing new version of config file /etc/resolvconf/update.d/unbound ...
> 
> (letting the user think that the conffile is reverted to the default,
> without informing him that the execute bit is not copied) is
> misleading.
> 
> An alternative solution would be a 5th option, splitting the
> 
> Y or I  : install the package maintainer's version
> 
> choice, when there is a difference for the execute permission.

There are currently three main problems that make substantial immediate
improvements to this rather impractical. :/

  - There is no tracking (yet) of fsys metadata, so dpkg does not know
what were the original old conffile perms, and thus cannot take
them into account as part of a "modified" check, otherwise we would
end up prompting unnecessarily when the perms are different between
the installed old and stock new conffiles.
  - The statoverrides are applied on unpack, so right now we even lose
the minimal tracking we could have over the new conffile shipped in
the .deb.
  - The perms are unconditionally copied from the current to the new
conffile, and given the current constraints, stopping doing that
could have either small (perms) data loss consequences, or could
have security implications (even for the install-new-conffile case,
as a common way people resolve new changes might be to spawn a shell
during the prompt and incorporate the old modifications into the new
file).

Changing the current behavior, without fsys metadata tracking assistance,
seems challenging, to say the least. This behavior has been like this
since the beginning of git history, which also means that the perhaps
more appropriate way to override these perms via statoverrides has never
worked on conffiles. So this is messy. :/


I think right now what I could do, that I think is safe and meaningful
would be to:

 - document that currently (but that would change) statoverrides for
   conffiles does not have a practical effect.
 - show the permission differences during the prompt (current, new,
   whether there is any ineffective override in place).

 - perhaps as a temporary workaround, delay the application of
   statoverrides for a conffile until the conffile handling step, so that
   we can better track the new conffile perms, but mostly for
   reporting purposes only.

Ideally in the future once we have fsys metadata tracking:

 - stop unconditionally copying the old perms into the new conffiles.
 - take permissions into account as part of the "modified" check,
   and show and apply any meaningful permission change there, taking
   statoverrides into account.

This will mean we will be able to do a 3-way check (like we do with
contents using their digests) over the permissions, to decide when to
propagate the perms or not, in prompt or automatic mode, etc.

Thanks,
Guillem

Bug#1010072: yash FTCBFS: configure script uses wrong compiler

[Timo Röhling]

Source: yash
Version: 2.52-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Dear maintainer,

yash fails to cross build from source, because the (hand-written)
configure script does not use the correct compiler to test-compile.
Attached is a small patch that fixes the build.

Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
diff --git a/debian/rules b/debian/rules
index 72a8aa8..6de1ca6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,11 +11,12 @@
 
 export LANG=C
 DPKG_EXPORT_BUILDFLAGS=1
+include /usr/share/dpkg/architecture.mk
 include /usr/share/dpkg/buildflags.mk
 
 %:
 	dh $@
 
 override_dh_auto_configure:
-	./configure --prefix=/usr
+	CC=$(DEB_HOST_GNU_TYPE)-gcc ./configure --prefix=/usr
 	


signature.asc
Description: PGP signature

Bug#1010071: wireguard-tools: the wg tool outputs color on monochrome terminals

[Axel]

Package: wireguard-tools
Version: 1.0.20210223-1
Severity: normal

Dear Maintainer,

The wg tool outputs color on monochrome terminals, it should either default
to no color output or use a proper terminal library like ncurses to output
color instead of just querying if the terminal is a tty.

I really don't like having to set a different environment variable to 
disable color output for each program which behaves like this.

Kind regards,
Axel

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

Kernel: Linux 5.10.0-13-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

Versions of packages wireguard-tools depends on:
ii  libc6  2.31-13+deb11u3

Versions of packages wireguard-tools recommends:
ii  iptables   1.8.7-1
ii  linux-image-amd64 [wireguard-modules]  5.10.106-1
ii  nftables   0.9.8-3.1

Versions of packages wireguard-tools suggests:
pn  openresolv | resolvconf  

-- no debconf information

Bug#993670: linux-image-5.10.0-8-686: Screen corruption using radeon kernel driver

[Mikhail Krylov]

On Sat, Apr 23, 2022 at 04:53:24PM +0200, Diederik de Haas wrote:
> Can you report this upstream? The appropriate place is 
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> When you have, please also mention the URL of that, so that we can track any 
> progress here too.
> 

Done. I'll post the link tomorrow, because it seems like their archives
get updated once in a day or so, and the link is not available at the
moment.
 
> *) I consider the Mageia revert a workaround (which also seems wrt aarch64/
> arm64, not x86?), not a fix. If upstream considers that a proper and does 
> revert 
> that commit themselves too, then it's more likely Debian will incorporate it 
> (until it trickles down from updated upstream version(s)).

The correct link to the 32-bit x86 is 
http://sophie.zarb.org/distrib/Mageia/7/i586/by-pkgid/b9193a4f85192bc57f4d770fb9bb399c/files/32
by the way.


signature.asc
Description: PGP signature

Bug#1008965: lazygal: Crashes with illegal chars in IPTC keywords

[coronalist]

Hello,



lazygal assumes utf-8 everywhere. I'll see what I can do to ignore this.

This is related to https://gitlab.gnome.org/GNOME/pygobject/-/issues/327 .
I may be wrong by I do not see any obvious way to fix this in lazygal.

Thank you very much for investigation. I guess, I will have to rework 
the tags in old pictures.



Björn

Bug#974833: iw: output of 'mpath dump' is wrongly formatted

[Diederik de Haas]

Control: tag -1 patch upstream
Control: forwarded -1 
https://lore.kernel.org/linux-wireless/20220423160922.14952-1-didi.deb...@cknow.org/T/#u

I've made an attempt, hope that's alright. And hopefully I did it correctly.

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

Bug#1010070: python3-fuse: several bindings broken on Python 3.10

[Colin Watson]

Package: python3-fuse
Version: 2:1.0.2-1+b1
Severity: grave

Anything that uses the "write", "setxattr", or "ioctl" method is broken
with Python 3.10 due to the change described at the top of
https://docs.python.org/3/whatsnew/3.10.html#id2.  Among other things,
this breaks the binfmt-support test suite.

https://github.com/libfuse/python-fuse/issues/41 already existed for
this, and I've proposed https://github.com/libfuse/python-fuse/pull/43
which fixes binfmt-support's tests.  An upload of that would be great so
that my CI works again.

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

Kernel: Linux 5.15.0-23-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
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 /bin/dash
Init: unable to detect

Versions of packages python3-fuse depends on:
ii  fuse3 [fuse]  3.10.5-1
ii  libc6 2.33-7
ii  libfuse2  2.9.9-5
ii  python3   3.10.4-1

python3-fuse recommends no packages.

python3-fuse suggests no packages.

-- no debconf information

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#1010069: nodejs: FTBFS test failure on mipsel-osuosl-05.debian.org

[Jérémy Lal]

Package: nodejs
Version: 16.13.2+really14.19.1~dfsg-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

https://buildd.debian.org/status/fetch.php?pkg=nodejs=mipsel=16.13.2%2Breally14.19.1~dfsg-6%2Bb1=1650719824=log

  ...
not ok 185 parallel/test-buffer-writefloat
  ---
  duration_ms: 0.409
  severity: fail
  exitcode: 1
  stack: |-
assert.js:394
throw err;
^

AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:

  assert.ok(
buffer.equals(new Uint8Array(
  [ 0x7F, 0xC0, 0x00, 0x00, 0x00, 0x00, 0xC0, 0x7F ])))

at Object. 
(/<>/test/parallel/test-buffer-writefloat.js:61:10)
at Module._compile (internal/modules/cjs/loader.js:1085:14)
at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:1114:10)
at Module.load (internal/modules/cjs/loader.js:950:32)
at Function.Module._load (internal/modules/cjs/loader.js:790:12)
at Function.executeUserEntryPoint [as runMain] 
(internal/modules/run_main.js:75:12)
at internal/main/run_main_module.js:17:47 {
  generatedMessage: true,
  code: 'ERR_ASSERTION',
  actual: false,
  expected: true,
  operator: '=='
}


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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 nodejs depends on:
ii  libc6  2.33-7
ii  libnode83  16.13.2+really14.19.1~dfsg-6

Versions of packages nodejs recommends:
ii  ca-certificates  20211016
ii  nodejs-doc   16.13.2+really14.19.1~dfsg-6

Versions of packages nodejs suggests:
ii  npm  8.6.0~ds2-2

-- no debconf information

Bug#1010068: RFS: base16384/2.2.0 [ITP] -- Encode binary files to printable utf16be.

[fumiama]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: base16384
   Version : 2.2.0
   Upstream Author : fumiama 
 * URL : https://github.com/fumiama/base16384
 * License : GPL-3.0+
 * Vcs : https://salsa.debian.org/debian/base16384
   Section : utils

The source builds the following binary packages:

  base16384 - Encode binary files to printable utf16be.

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

  - https://github.com/fumiama/base16384
  - https://mentors.debian.net/package/base16384/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/base16384/base16384_2.2.0.dsc

I have also published the package to launchpad. If you are using Ubuntu,
you can install the package by the commands below:

  sudo add-apt-repository ppa:fumiama/ppa
  sudo apt-get update
  sudo apt-get install base16384

Changes for the initial release:

 base16384 (2.2.0) stable; urgency=medium
 .
   * Initial Release.
   * Closes: #1010055 (ITP).

Regards,
--
  fumiama

Bug#993670: linux-image-5.10.0-8-686: Screen corruption using radeon kernel driver

[Diederik de Haas]

Control: tag -1 upstream
Control: found -1 linux/5.17.3-1

On Saturday, 23 April 2022 15:12:33 CEST Mikhail Krylov wrote:
> On Mon, Apr 18, 2022 at 05:21:28PM +0200, Diederik de Haas wrote:
> > Can you still reproduce this issue with a more recent kernel?
> 
> Yup, tried with linux-image-5.17.0-1-686_5.17.3-1_i386.deb a few moments
> ago, unfortunately, the problem still persists.
> 
> > There was another suggestion: "setting radeon.agpmode=-1 on the kernel
> > command line (in grub)"
> > If a recent kernel hasn't fixed it, does the other suggestion fix the
> > issue?
> For me, the only thing it does is that it disables acceleration.
> Basically everything that uses it, like openarena stops working, even
> some 2d apps because they use glamor I guess.

Yeah, that's indeed not much of a solution.

This is an upstream kernel issue which should be fixed there.
AFAICT you have all the information you'd need, including the offending commit 
and the skills to test an upstream suggested (proper*) fix.
(I/We can try to help if you still run into issues on that)

Can you report this upstream? The appropriate place is 
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
When you have, please also mention the URL of that, so that we can track any 
progress here too.

TIA,
  Diederik

*) I consider the Mageia revert a workaround (which also seems wrt aarch64/
arm64, not x86?), not a fix. If upstream considers that a proper and does 
revert 
that commit themselves too, then it's more likely Debian will incorporate it 
(until it trickles down from updated upstream version(s)).

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

Bug#1010065: ITP: swagger-ui -- Swagger UI is a collection of HTML, JavaScript, and CSS assets that dynamically generate beautiful documentation from a Swagger-compliant API.

[Salvatore Bonaccorso]

Hi Jelmer,

On Sat, Apr 23, 2022 at 02:05:45PM +, Jelmer Vernooij wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jelmer Vernooij 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: swagger-ui
>   Version : 4.10.3
>   Upstream Author : Name 
> * URL : https://github.com/swagger-api/swagger-ui
> * License : Apache-2.0
>   Programming Lang: Javsscript
>   Description : generate beautiful documentation from a Swagger-compliant 
> API
> 
> Swagger UI allows anyone — be it your development team or your end consumers —
> to visualize and interact with the API’s resources without having any of the
> implementation logic in place. It’s automatically generated from your OpenAPI
> (formerly known as Swagger) Specification, with the visual documentation 
> making
> it easy for back end implementation and client side consumption.

There seems to be already a ITP for swagger-ui at #895422. I would
suggest to coordinate with Yadd, who in an earlier attempt marked it
as pending, Cc'ing.

Regards,
Salvatore

Bug#1010066: prayer: Depends on private functions that are hidden with tidy 5.8

[Boyuan Yang]

Source: prayer
Version: 1.3.5-dfsg1-8
Severity: grave
X-Debbugs-CC: holmg...@debian.org
User: tidy-ht...@packages.debian.org
Usertags: tidy5.8

Dear Debian prayer package maintainer,

When preparing the upload of package tidy-html5 v5.8 onto Debian Unstable, I
noticed that your package FTBFS with the new tidy library:


/usr/bin/ld: ../session/session.a(html_secure_tidy.o): in function
`tidy_tree':
./session/html_secure_tidy.c:311: undefined reference to
`prvTidyDiscardElement'
/usr/bin/ld: ./session/html_secure_tidy.c:322: undefined reference to
`prvTidyRemoveAttribute'
/usr/bin/ld: ./session/html_secure_tidy.c:329: undefined reference to
`prvTidyAddAttribute'
collect2: error: ld returned 1 exit status


This is because that your package uses some of Tidy's unexported internal
functions that are explicitly hidden in Tidy 5.8:


/* Foul layering volation: Tidy doesn't export these functions */

extern void prvTidyDiscardElement( TidyDoc doc, TidyNode node);
extern void prvTidyRemoveAttribute( TidyDoc doc, TidyNode node, TidyAttr
attr);
extern void prvTidyAddAttribute( TidyDoc doc, TidyNode node,
 const char *attr, const char *value);



I believe this change is intentional by upstream, and will not be changed in
the forseeable future. Please consider fixing the build by removing the use of
internal Tidy functions. Thanks!

Best,
Boyuan Yang


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

Bug#980107: python-rioxarray

[Antonio Valentino]

Dear Magnus and Alastair,
I have recently pushed to the salsa repository a new upstream version of 
the rioxarray package (v0.11.1).

I would really like to have this package in debian.
If you are still interested in this package please go ahead with the 
upload into the new queue.


I you are no longer interested or do not have time to dedicate, please 
let me know and I will try to find another sponsor for the first upload.

Of course I will take in charge also the maintenance.


kind regards
antonio

On Fri, 5 Nov 2021 07:44:10 +0100 Antonio Valentino 
 wrote:

Dear Alastair and Magnus,
yesterday I have pushed on the salsa repository an updated version of 
the rioxarray package including the latest upstream version 0.8.0.


Please consider it for your review and upload.

kind regards
antonio

Il 02/10/21 17:08, Antonio Valentino ha scritto:
> Thank Magnus,
> all branches and tags have been pushed now.
> Now the package is ready for a review.
> 
> kind regards

> antonio
> 
> Il 02/10/21 16:34, Magnus HAGDORN ha scritto:

>> Hi Antionio,
>> Excellent. I am very happy for you to push directly to the repo.
>> magnus
>>
>> On Sat, 2021-10-02 at 09:48 +0200, Antonio Valentino wrote:
>>> This email was sent to you by someone outside the University.
>>> You should only click on links or attachments if you are certain that
>>> the email is genuine and the content is safe.
>>>
>>> Dear Alastair and Magnus,
>>> I have update the package on my fork [1].
>>> I have temporary removed the -doc package because it not buildable at
>>> the moment due to #995299 [2].
>>> We can re-add the -doc package in a future version if necessary.
>>> I have also updated the package to the latest upstream version 0.7.1.
>>>
>>> @Magnus please let me know if you prefer me to push directly on the
>>> debian-science repository or to submit a merge request.
>>>
>>> [1] https://salsa.debian.org/antonio.valentino/python-rioxarray
>>> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995299
>>>
>>> kind regards
>>> Antonio
>>>
>>>
>>> Il 27/09/21 11:59, Alastair McKinstry ha scritto:
 Hi Magnus

 I downloaded and reviewed the package.

 As it currently stands it needs some work to deal with privacy
 issues
 (The lintian tests). Basically sphinxdocs is adding links to
 cloudflare
 etc that leak user information.

 You can look at "python-xarray" to see some solutions - some can be
 fixed with a patch to the sphinxdocs configuration, some needs
 editing
 of the html files in debian/rules to use javascript helpers that
 you


--
Antonio Valentino

Bug#1010065: ITP: swagger-ui -- Swagger UI is a collection of HTML, JavaScript, and CSS assets that dynamically generate beautiful documentation from a Swagger-compliant API.

[Jelmer Vernooij]

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

* Package name: swagger-ui
  Version : 4.10.3
  Upstream Author : Name 
* URL : https://github.com/swagger-api/swagger-ui
* License : Apache-2.0
  Programming Lang: Javsscript
  Description : generate beautiful documentation from a Swagger-compliant 
API

Swagger UI allows anyone — be it your development team or your end consumers —
to visualize and interact with the API’s resources without having any of the
implementation logic in place. It’s automatically generated from your OpenAPI
(formerly known as Swagger) Specification, with the visual documentation making
it easy for back end implementation and client side consumption.

Bug#1010056: ncl: patch for fix ncl ftbfs on riscv64

[Bo YU]

Source: ncl
Version: 6.6.2-10
Followup-For: Bug #1010056
Control: tags -1 patch

Dear Maintainer,

Sorry, send patch again.

--- ncl-6.6.2.orig/config/ymake
+++ ncl-6.6.2/config/ymake
@@ -390,6 +390,7 @@ caseLinux:
 caseppc*:
 caseaarch64*:
 casealpha:
+caseriscv64:
 set model   = $mach
 set arch= $mach
 set sysincs = LINUX

Bug#1010061: git-buildpackage: FTBFS on bookworm and sid: multiple issues

[Guido Günther]

Hi,
On Sat, Apr 23, 2022 at 10:10:44AM -0300, Antonio Terceiro wrote:
> Source: git-buildpackage
> Version: 0.9.25
> Severity: serious
> Tags: patch ftbfs
> Justification: fails to build from source
> 
> Dear Maintainer,
> 
> git-buildpackage currently fails to build due to a few issues. I tried
> both the source currently in testing/unstable, and the master branch
> from the git repository. There are a few different issues:

These all make sense. Pushed, thanks!
 -- Guido

Bug#1010061: [git-buildpackage/master] tests: fix input data to create-remote-repo tests

[Antonio Terceiro]

tag 1010061 pending
thanks

Date:   Sat Apr 23 10:08:16 2022 -0300
Author: Antonio Terceiro 
Commit ID: 6733ab9603773281016812c34604aa3358fbdc34
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=6733ab9603773281016812c34604aa3358fbdc34
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=6733ab9603773281016812c34604aa3358fbdc34

tests: fix input data to create-remote-repo tests

Closes: #1010061

  

Bug#1001163: [git-buildpackage/master] push: skip pristine-tar push if already present remotely

[Antonio Terceiro]

tag 1001163 pending
thanks

Date:   Sat Apr 23 09:02:10 2022 -0300
Author: Antonio Terceiro 
Commit ID: 2405e15805c68b53628cb4fb55e1e6313c8e114c
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=2405e15805c68b53628cb4fb55e1e6313c8e114c
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=2405e15805c68b53628cb4fb55e1e6313c8e114c

push: skip pristine-tar push if already present remotely

When one is working on an older branch (stable update or backport), the
pristine-tar branch may already contain new commits after the one
corresponding to the upstream version in question.

Closes: #1001163

  

Bug#1010064: salsa: please push the pristine-tar branch

[Dmitry Baryshkov]

Source: device-tree-compiler
Version: 1.6.1-1
Severity: normal

Recent push to dtc sources to the repo at salsa includes the
debian/gbp.conf file. This file contains the "pristine-tar = True"
config option, however the repo does not contain the pristine-tar
branch. Thus rebuilding the package from the repo without passing
additional options to gbp is impossible.

Please push the prisine-tar branch to the salsa repo.

-- 
With best wishes
Dmitry


-- 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-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1010063: ITP: golang-github-mndrix-tap-go -- Test Anything Protocol for Go

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-mndrix-tap-go
  Version : 0.0~git20171203.629fa40-1
  Upstream Author : Michael Hendricks
* URL : https://github.com/mndrix/tap-go
* License : Public Domain
  Programming Lang: Go
  Description : Test Anything Protocol for Go

 Test Anything Protocol for Go
 .
 The Test Anything Protocol (http://testanything.org/) ("TAP") is a text-
 based interface between tests and a test harness.  This package helps Go
 to generate TAP output.
 .
 Read the full package documentation
 (https://godoc.org/github.com/mndrix/tap-go)

I'm going be maintain this under the pkg-golang team umbrella

Build dependency for golang-github-opencontainers-runtime-tools

Bug#1009965: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder not working anymore

[Diederik de Haas]

On Saturday, 23 April 2022 13:30:36 CEST Holger Schröder wrote:
> For some reason, part of the firmware with Debian 5.17 is not loaded
> during boot. Manually loading the firmware fixes the problem and
> everything works again. I have absolutely no idea why.

Good that you found a workaround :) A solution is still better though.

IIUC if you *only* change to the siduction kernel (i.e. everything else is 
exactly the same, especially the firmware files), then the firmware loads 
normally?

If I did understand correctly, can you then ask the siduction (kernel) people 
what's the most likely change they did to their kernel compared to Debian's?

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

Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

[Helge Kreutzmann]

Hello Guillem,
On Sat, Apr 23, 2022 at 12:34:20PM +0200, Guillem Jover wrote:
> On Fri, 2022-04-22 at 20:16:02 +0200, Thorsten Glaser wrote:
> > On Fri, 22 Apr 2022, Mark Hindley wrote:
> > > > Or Replaces: but that has downsides on deinstallation.
> > > 
> > > Yes. And I am unclear how dpkg would behave if sysvinit-core was installed
> > > Replacing the manpages-l10n versions but then manpages-l10n was upgraded.
> > 
> > Hm. Given that manpages-l10n would *not* Replaces sysvinit-core,
> > I’d… say/hope ☺ that those of sysvinit-core take precedence. But
> > I have to admit… I actually am not sure. Asking the experts ☻
> 
> Replaces works as it would be expected, yes. So as long as a package
> contains the field, even if a replaced package gets installed/upgraded
> later then it will be kept being replaced. But as has been mentioned,
> and on their own, they have the problem of leaving the system w/o those
> replaced files if the replacing package gets removed or swapped.
> 
> I just checked the context for this report, and I think the better
> option would be for systemd to ship their own translated man pages
> (with appropriate Replaces/Breaks). (Helge have you considered or
> tried that approach with upstream?) So that when someone switches
> between sysvinit and systemd (or another init system providing the
> same binaries), the translated man pages always correspond with the
> actual original man pages and tools. I also think diversions or
> alternatives do not seem appropriate as long as the commands themselves
> are not handled in the same way.

In theory this is the best way, yes. In practice it works seldom.
Sysvinit is the very rare example where the transfer and integration
went quick and smoothly.  

Unfortunatley, alsmost alwyys, this is a multi-year process, first getting
upstreams (we have > 100 upstreams!) to accept the idea of translated
man pages (some are even hostile at this very first step), then to
help them integrate them, then to have them actually ship the files
and finally to convince the downstreams like Debian to enable this
process.

As we can fail in any step, Mario (manpages-l10n upstream) just 
decided to stop working on those transfers, even though he believes
this is the right step.

For systemd I've not tried this, however, they are well aware of the
translated man pages and never ever requested transfer or even asked
about it.

Greetings

   Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1010056: ncl: FTBFS on riscv64

[Bo YU]

Source: ncl
Followup-For: Bug #1010056

Dear Maintainer,

This is a simple patch to fix ncl ftbfs issue on riscv64. I have built
it successfully on riscv64 hardware.

Bug#1010049: qt6-base-dev: should provide a QT_HOST_PATH directory for cross building

[Helmut Grohne]

Hi,

On Sat, Apr 23, 2022 at 09:38:54AM +0200, Helmut Grohne wrote:
> I expect that QT_HOST_PATH also needs to point to architecture-dependent
> files (e.g. libraries). Qt5 has faced as similar problem and thus added

Dmitry noted that none of Qt6's executables (possibly except for qmake)
are architecture-dependent and encouraged me to try
-DQT_HOST_PATH=/usr/lib/qt6. When you do that, you get the following
error:

| CMake Error at /usr/lib/aarch64-linux-gnu/cmake/Qt6/Qt6Config.cmake:61 
(find_package):
|   Could not find a package configuration file provided by "Qt6HostInfo" with
|   any of the following names:
| 
| Qt6HostInfoConfig.cmake
| qt6hostinfo-config.cmake
| 
|   Add the installation prefix of "Qt6HostInfo" to CMAKE_PREFIX_PATH or set
|   "Qt6HostInfo_DIR" to a directory containing one of the above files.  If
|   "Qt6HostInfo" provides a separate development package or SDK, be sure it
|   has been installed.
| Call Stack (most recent call first):
|   CMakeLists.txt:16 (find_package)
| 
| 
| -- Configuring incomplete, errors occurred!

So no, that's not the solution unfortunately. As far as I can see, this
file is architecture-dependent and since QT_HOST_PATH defines its
location, QT_HOST_PATH must be architecture-dependent as I expected.

Helmut

Bug#1010062: RFA: autogen -- automated text file generator

[Andreas Metzler]

Package: wnpp
Severity: normal
X-Debbugs-Cc: auto...@packages.debian.org
Control: affects -1 src:autogen

I request an adopter for the autogen package.

The package description is:
 AutoGen is a tool designed for generating program files that contain
 repetitive text with varied substitutions. This is especially valuable if
 there are several blocks of such text that must be kept synchronized.
 .
 Included with AutoGen is a tool that virtually eliminates the hassle of
 processing options, keeping usage text up to date and so on. This tool
 allows you to specify several program attributes, innumerable options and
 option attributes, then it produces all the code necessary to parse and
 handle the command line and initialization file options.
 .
 This package contains the development tools. libopts25-dev contains the
 static libraries and header files. libopts25 contains the shared libraries.
 autogen-doc contains the PostScript and HTML documentation.

I adopted this about 10 years ago because it was a gnutls
build-dependency. GnuTLS has switched away in January, so I am not using
it anymore.

cu Andreas


signature.asc
Description: PGP signature

Bug#1010061: git-buildpackage: FTBFS on bookworm and sid: multiple issues

[Antonio Terceiro]

Source: git-buildpackage
Version: 0.9.25
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source

Dear Maintainer,

git-buildpackage currently fails to build due to a few issues. I tried
both the source currently in testing/unstable, and the master branch
from the git repository. There are a few different issues:

- pydoctor changed its configuration file format, and there is needed
  porting.

- The tests make assumptions about the global git configuration (and
  fail for me on my system).

- A few parts of the Debian packaging assume the current python3 version
  ends with single digit (python3.?), what breaks now that python 3.10
  is the default.

- the tests for create-remote-repo seem to be using slightly broken
  input data. I'm not sure how this worked before.

I'm including patches for all of the above issues, in that order.


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

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
From d77682bf92b2c486ef1a35e5af13411129583fb1 Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Sat, 23 Apr 2022 09:23:43 -0300
Subject: [PATCH 1/3] docs: port build system to newer pydoctor

According to https://pydoctor.readthedocs.io/en/latest/help.html, the
command line and configuration parsing has changed in an incompatible
way. These changes fix the documentation build for me, but are probably
backwards-incompatible with older versions of pydoctor.
---
 .pydoctor.cfg | 4 
 Makefile  | 2 +-
 pydoctor.ini  | 4 
 3 files changed, 5 insertions(+), 5 deletions(-)
 delete mode 100644 .pydoctor.cfg
 create mode 100644 pydoctor.ini

diff --git a/.pydoctor.cfg b/.pydoctor.cfg
deleted file mode 100644
index ede8e513..
--- a/.pydoctor.cfg
+++ /dev/null
@@ -1,4 +0,0 @@
-projectname: git-buildpackage
-projecturl: https://honk.sigxcpu.org/piki/projects/git-buildpackage/
-htmloutput: build/apidocs
-packages: gbp,tests/doctests/
diff --git a/Makefile b/Makefile
index c94fa6c2..618f1a18 100644
--- a/Makefile
+++ b/Makefile
@@ -27,6 +27,6 @@ docs:
 
 apidocs:
 	mkdir -p build
-	pydoctor -v --config=.pydoctor.cfg
+	pydoctor -v gbp tests/doctests/
 
 .PHONY: docs
diff --git a/pydoctor.ini b/pydoctor.ini
new file mode 100644
index ..a9bd0215
--- /dev/null
+++ b/pydoctor.ini
@@ -0,0 +1,4 @@
+[pydoctor]
+project-name = git-buildpackage
+project-url = https://honk.sigxcpu.org/piki/projects/git-buildpackage/
+html-output = build/apidocs
-- 
2.35.1

From a627139e5ac73a65f99a970981063bc0e709f4df Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Sat, 23 Apr 2022 09:37:41 -0300
Subject: [PATCH 2/3] tests: set HOME to an unexisting directory

The test suite contains several assumptions about the global git
configuration, including but not limited to the default branch name
being `master`. By running the tests against a unexisting HOME, git will
not load the user configuration and instead use all the git defaults.
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 618f1a18..db5ad88e 100644
--- a/Makefile
+++ b/Makefile
@@ -9,6 +9,7 @@ all+net:
 	$(MAKE) GBP_NETWORK_TESTS=1 all
 
 test:
+	export HOME=/nonexisting;   \
 	export GIT_AUTHOR_NAME="Gbp Tests";		\
 	export GIT_AUTHOR_EMAIL=te...@example.com;	\
 	export GIT_COMMITTER_NAME=$$GIT_AUTHOR_NAME;	\
-- 
2.35.1

From 2fae160d990992a1273b713778ee6928646a Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Sat, 23 Apr 2022 09:42:14 -0300
Subject: [PATCH 3/3] debian/rules: fix build with python3.10 as default

---
 debian/git-buildpackage-rpm.install | 10 ++--
 debian/git-buildpackage.install | 72 ++---
 debian/not-installed| 14 +++---
 debian/rules|  2 +-
 4 files changed, 49 insertions(+), 49 deletions(-)

diff --git a/debian/git-buildpackage-rpm.install b/debian/git-buildpackage-rpm.install
index 503e495a..f79d4f17 100644
--- a/debian/git-buildpackage-rpm.install
+++ b/debian/git-buildpackage-rpm.install
@@ -1,6 +1,6 @@
 usr/bin/gbp-builder-mock /usr/share/git-buildpackage/
-usr/lib/python3.?/dist-packages/gbp/rpm usr/lib/python3/dist-packages/gbp/
-usr/lib/python3.?//dist-packages/gbp/scripts/import_srpm.py usr/lib/python3/dist-packages/gbp/scripts/
-usr/lib/python3.?/dist-packages/gbp/scripts/pq_rpm.py usr/lib/python3/dist-packages/gbp/scripts/
-usr/lib/python3.?/dist-packages/gbp/scripts/buildpackage_rpm.py usr/lib/python3/dist-packages/gbp/scripts/
-usr/lib/python3.?/dist-packages/gbp/scripts/rpm_ch.py usr/lib/python3/dist-packages/gbp/scripts/

Bug#993670: linux-image-5.10.0-8-686: Screen corruption using radeon kernel driver

[Mikhail Krylov]

On Mon, Apr 18, 2022 at 05:21:28PM +0200, Diederik de Haas wrote:
> Can you still reproduce this issue with a more recent kernel?

Yup, tried with linux-image-5.17.0-1-686_5.17.3-1_i386.deb a few moments
ago, unfortunately, the problem still persists.

> There was another suggestion: "setting radeon.agpmode=-1 on the kernel
> command line (in grub)"
> If a recent kernel hasn't fixed it, does the other suggestion fix the issue?

For me, the only thing it does is that it disables acceleration.
Basically everything that uses it, like openarena stops working, even
some 2d apps because they use glamor I guess.


signature.asc
Description: PGP signature

Bug#1010059: whiptail doesn't react to input in sudo shell pipe since Bookworm

[MichaIng]

Package: whiptail
Version: 0.52.21-5

Since Debian Bookworm, it is not possible anymore to control whiptail 
dialogs when being passed through a sudo pipe to the shell, e.g.:

---
echo 'whiptail --msgbox test 20 80' | sudo bash
---
This is often used when executing remote installer shell scripts, like:
---
curl -sSfL https://install.something.org | sudo bash
---
Whether using bash or dash or another shell to pipe the command(s) to 
and/or as parent shell to call the whole pipe from, doesn't matter. The 
same works well on Debian Bullseye and before.


The following cases work without issues, either omitting sudo, using a 
command substitution instead of a pipe (leaving STDIN untouched) or 
using "dialog" instead of whiptail:

---
echo 'whiptail --msgbox test 20 80' | bash
sudo bash -c "$(echo 'whiptail --msgbox test 20 80')"
echo 'dialog --msgbox test 20 80' | sudo bash
---

I'm not sure whether something changed in sudo, in whiptail/newt 
(nothing visible in changelog) or in some other used system library. But 
since it is affecting a common use case for whiptail explicitly, I'm 
reporting it here. It generally seems to be related to how STDIN is 
handled through shell pipes and sudo and how whiptail uses it (given 
that "dialog" is not affected).


Best regards,

Micha

Bug#1010060: buster-pu: package mutt/1.10.1-2.1+deb10u6

[Salvatore Bonaccorso]

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

Hi SRM'ers, hi Antonio

I prepared an update for mutt, fixing CVE-2022-1328, a buffer-overflow
in uudecoder.

Performed a manual test with the poc mbox provided by Tavis in
https://gitlab.com/muttmua/mutt/-/issues/404 .

Attached is the debdiff respectively for the upload.

Regards,
Salvatore
diff -Nru mutt-1.10.1/debian/changelog mutt-1.10.1/debian/changelog
--- mutt-1.10.1/debian/changelog2021-01-25 19:10:07.0 +0100
+++ mutt-1.10.1/debian/changelog2022-04-23 15:00:14.0 +0200
@@ -1,3 +1,10 @@
+mutt (1.10.1-2.1+deb10u6) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix uudecode buffer overflow (CVE-2022-1328) (Closes: #1009734)
+
+ -- Salvatore Bonaccorso   Sat, 23 Apr 2022 15:00:14 +0200
+
 mutt (1.10.1-2.1+deb10u5) buster-security; urgency=high
 
   * debian/patches:
diff -Nru mutt-1.10.1/debian/patches/series mutt-1.10.1/debian/patches/series
--- mutt-1.10.1/debian/patches/series   2021-01-25 19:10:07.0 +0100
+++ mutt-1.10.1/debian/patches/series   2022-04-23 15:00:14.0 +0200
@@ -19,3 +19,4 @@
 security/CVE-2020-28896.patch
 security/CVE-2021-3181.patch
 upstream/imap-preauth-and-ssh-tunnel.patch
+upstream/Fix-uudecode-buffer-overflow.patch
diff -Nru 
mutt-1.10.1/debian/patches/upstream/Fix-uudecode-buffer-overflow.patch 
mutt-1.10.1/debian/patches/upstream/Fix-uudecode-buffer-overflow.patch
--- mutt-1.10.1/debian/patches/upstream/Fix-uudecode-buffer-overflow.patch  
1970-01-01 01:00:00.0 +0100
+++ mutt-1.10.1/debian/patches/upstream/Fix-uudecode-buffer-overflow.patch  
2022-04-23 15:00:14.0 +0200
@@ -0,0 +1,43 @@
+From: Kevin McCarthy 
+Date: Tue, 5 Apr 2022 11:05:52 -0700
+Subject: Fix uudecode buffer overflow.
+Origin: 
https://gitlab.com/muttmua/mutt/-/commit/e5ed080c00e59701ca62ef9b2a6d2612ebf765a5
+Bug: https://gitlab.com/muttmua/mutt/-/issues/404
+Bug-Debian: https://bugs.debian.org/1009734
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-1328
+
+mutt_decode_uuencoded() used each line's initial "length character"
+without any validation.  It would happily read past the end of the
+input line, and with a suitable value even past the length of the
+input buffer.
+
+As I noted in ticket 404, there are several other changes that could
+be added to make the parser more robust.  However, to avoid
+accidentally introducing another bug or regression, I'm restricting
+this patch to simply addressing the overflow.
+
+Thanks to Tavis Ormandy for reporting the issue, along with a sample
+message demonstrating the problem.
+---
+ handler.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/handler.c b/handler.c
+index d1b4bc73a58f..c97cf0cb527e 100644
+--- a/handler.c
 b/handler.c
+@@ -404,9 +404,9 @@ static void mutt_decode_uuencoded (STATE *s, LOFF_T len, 
int istext, iconv_t cd)
+ pt = tmps;
+ linelen = decode_byte (*pt);
+ pt++;
+-for (c = 0; c < linelen;)
++for (c = 0; c < linelen && *pt;)
+ {
+-  for (l = 2; l <= 6; l += 2)
++  for (l = 2; l <= 6 && *pt && *(pt + 1); l += 2)
+   {
+   out = decode_byte (*pt) << l;
+   pt++;
+-- 
+2.35.2
+

Bug#1010058: bullseye-pu: package mutt/2.0.5-4.1+deb11u1

[Salvatore Bonaccorso]

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

Hi SRM'ers, hi Antonio

I prepared an update for mutt, fixing CVE-2022-1328, a buffer-overflow
in uudecoder.

Performed a manual test with the poc mbox provided by Tavis in
https://gitlab.com/muttmua/mutt/-/issues/404 .

Attached is the debdiff respectively for the upload.

Regards,
Salvatore
diff -Nru mutt-2.0.5/debian/changelog mutt-2.0.5/debian/changelog
--- mutt-2.0.5/debian/changelog 2021-06-06 21:11:36.0 +0200
+++ mutt-2.0.5/debian/changelog 2022-04-23 14:44:09.0 +0200
@@ -1,3 +1,10 @@
+mutt (2.0.5-4.1+deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix uudecode buffer overflow (CVE-2022-1328) (Closes: #1009734)
+
+ -- Salvatore Bonaccorso   Sat, 23 Apr 2022 14:44:09 +0200
+
 mutt (2.0.5-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mutt-2.0.5/debian/patches/series mutt-2.0.5/debian/patches/series
--- mutt-2.0.5/debian/patches/series2021-06-06 21:11:36.0 +0200
+++ mutt-2.0.5/debian/patches/series2022-04-23 14:44:09.0 +0200
@@ -14,3 +14,4 @@
 upstream/980924-updated-german-translation.patch
 upstream/985152-body-color-slowness.patch
 upstream/Fix-seqset-iterator-when-it-ends-in-a-comma.patch
+upstream/Fix-uudecode-buffer-overflow.patch
diff -Nru mutt-2.0.5/debian/patches/upstream/Fix-uudecode-buffer-overflow.patch 
mutt-2.0.5/debian/patches/upstream/Fix-uudecode-buffer-overflow.patch
--- mutt-2.0.5/debian/patches/upstream/Fix-uudecode-buffer-overflow.patch   
1970-01-01 01:00:00.0 +0100
+++ mutt-2.0.5/debian/patches/upstream/Fix-uudecode-buffer-overflow.patch   
2022-04-23 14:44:09.0 +0200
@@ -0,0 +1,43 @@
+From: Kevin McCarthy 
+Date: Tue, 5 Apr 2022 11:05:52 -0700
+Subject: Fix uudecode buffer overflow.
+Origin: 
https://gitlab.com/muttmua/mutt/-/commit/e5ed080c00e59701ca62ef9b2a6d2612ebf765a5
+Bug: https://gitlab.com/muttmua/mutt/-/issues/404
+Bug-Debian: https://bugs.debian.org/1009734
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-1328
+
+mutt_decode_uuencoded() used each line's initial "length character"
+without any validation.  It would happily read past the end of the
+input line, and with a suitable value even past the length of the
+input buffer.
+
+As I noted in ticket 404, there are several other changes that could
+be added to make the parser more robust.  However, to avoid
+accidentally introducing another bug or regression, I'm restricting
+this patch to simply addressing the overflow.
+
+Thanks to Tavis Ormandy for reporting the issue, along with a sample
+message demonstrating the problem.
+---
+ handler.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/handler.c b/handler.c
+index d1b4bc73a58f..c97cf0cb527e 100644
+--- a/handler.c
 b/handler.c
+@@ -404,9 +404,9 @@ static void mutt_decode_uuencoded (STATE *s, LOFF_T len, 
int istext, iconv_t cd)
+ pt = tmps;
+ linelen = decode_byte (*pt);
+ pt++;
+-for (c = 0; c < linelen;)
++for (c = 0; c < linelen && *pt;)
+ {
+-  for (l = 2; l <= 6; l += 2)
++  for (l = 2; l <= 6 && *pt && *(pt + 1); l += 2)
+   {
+   out = decode_byte (*pt) << l;
+   pt++;
+-- 
+2.35.2
+

Bug#1010057: digikam: Failed when generated data-base

[Hoareau Jean Pierre]

Package: digikam
Version: 4:7.6.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,
I installed Debian "Bookworm" in order to test this version. When launching
"Digikam" I get a database loading/generation error. Below is the digikam
report file.
In advance I thank you.
Jean Pierre

Application: digiKam (digikam), signal: Segmentation fault

[KCrash Handler]
#4  0x7fcc44ec91b1 in QReadWriteLock::tryLockForWrite(int) () from
/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7fcc4625106b in ?? () from /lib/x86_64-linux-gnu/libQt5Sql.so.5
#6  0x7fcc46c30a33 in ?? () from /usr/lib/digikam/libdigikamcore.so.7.6.0
#7  0x7fcc46c30b5d in ?? () from /usr/lib/digikam/libdigikamcore.so.7.6.0
#8  0x7fcc46c38fce in ?? () from /usr/lib/digikam/libdigikamcore.so.7.6.0
#9  0x7fcc44eccf1f in QThreadStorageData::finish(void**) () from
/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x7fcc44ec70ed in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7fcc44ec79c9 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7fcc43034d80 in start_thread () from /lib/x86_64-linux-
gnu/libpthread.so.0
#13 0x7fcc44ade76f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 11 (Thread 0x7fcc0d04c640 (LWP 16462) "digikam:gdrv0"):
#1  0x7fcc4303ac30 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x7fcc20649beb in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#3  0x7fcc20649847 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x7fcc43034d80 in start_thread () from /lib/x86_64-linux-
gnu/libpthread.so.0
#5  0x7fcc44ade76f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 10 (Thread 0x7fcc0d84d640 (LWP 16461) "digikam:sh5"):
#1  0x7fcc4303ac30 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x7fcc20649beb in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#3  0x7fcc20649847 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x7fcc43034d80 in start_thread () from /lib/x86_64-linux-
gnu/libpthread.so.0
#5  0x7fcc44ade76f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 9 (Thread 0x7fcc0e04e640 (LWP 16460) "digikam:sh4"):
#1  0x7fcc4303ac30 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x7fcc20649beb in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#3  0x7fcc20649847 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x7fcc43034d80 in start_thread () from /lib/x86_64-linux-
gnu/libpthread.so.0
#5  0x7fcc44ade76f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 8 (Thread 0x7fcc189fa640 (LWP 16459) "digikam:sh3"):
#1  0x7fcc4303ac30 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x7fcc20649beb in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#3  0x7fcc20649847 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x7fcc43034d80 in start_thread () from /lib/x86_64-linux-
gnu/libpthread.so.0
#5  0x7fcc44ade76f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 7 (Thread 0x7fcc191fb640 (LWP 16458) "digikam:sh2"):
#1  0x7fcc4303ac30 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x7fcc20649beb in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#3  0x7fcc20649847 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x7fcc43034d80 in start_thread () from /lib/x86_64-linux-
gnu/libpthread.so.0
#5  0x7fcc44ade76f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 6 (Thread 0x7fcc199fc640 (LWP 16457) "digikam:sh1"):
#1  0x7fcc4303ac30 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x7fcc20649beb in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#3  0x7fcc20649847 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x7fcc43034d80 in start_thread () from /lib/x86_64-linux-
gnu/libpthread.so.0
#5  0x7fcc44ade76f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 5 (Thread 0x7fcc1a1fd640 (LWP 16456) "digikam:sh0"):
#1  0x7fcc4303ac30 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x7fcc20649beb in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#3  0x7fcc20649847 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x7fcc43034d80 in start_thread () from /lib/x86_64-linux-
gnu/libpthread.so.0
#5  0x7fcc44ade76f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 4 (Thread 0x7fcc1a9fe640 (LWP 16455) "digikam:disk$0"):
#1  0x7fcc4303ac30 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x7fcc20649beb in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#3  0x7fcc20649847 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x7fcc43034d80 in start_thread () from /lib/x86_64-linux-
gnu/libpthread.so.0
#5  

Bug#1009367: libnss3 file location changes

[Jeremy Bicha]

On Tue, Apr 19, 2022 at 2:15 PM Stephan Verbücheln
 wrote:
>
> Another hint:
>
> There are hardcoded paths in the following file:
> ~/.pki/nssdb/pkcs11.txt
>
> e.g.:
> > library=/usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
>
> To me it is not clear who creates that file, nss or evolution.

I believe libnss3 creates that file and needs to be able to handle it.
libnss3 might need to add a symlink directory to handle the old name.

I'm uploading a new evolution version and closing this bug. Backup
that file. If you still have the bug with evolution 3.44.1-2 with that
file (but not with that file moved or removed), I recommend filing a
serious bug against libnss3.

Note this from the debian/changelog for libsnss3 2:3.72-1
  * debian/libnss3.lintian-overrides.in, debian/rules,
nss/cmd/shlibsign/shlibsign.c, nss/lib/pk11wrap/pk11load.c,
nss/lib/util/secload.c, nss/cmd/shlibsign/Makefile,
nss/cmd/shlibsign/manifest.mn: Stop putting freebl, softokn, etc. in a
subdirectory. It's a deviation from upstream that is causing more problems
than it's worth keeping. Closes: #737855, #846012, #979159.

Thanks,
Jeremy Bicha

Bug#1001163: git-buildpackage: gbp push: tries to overwrite upstream and pristine-tar branches with older content (and fails)

[Antonio Terceiro]

Control: tag -1 + patch

Hi, the attached patch fixes this issue on my side.
From fa3db36fc4ba264b364873636a282ef16ba3c99f Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Sat, 23 Apr 2022 08:56:52 -0300
Subject: [PATCH] push: skip pristine-tar push if already present remotely

When one is working on an older branch (stable update or backport), the
pristine-tar branch may already contain new commits after the one
corresponding to the upstream version in question.

Closes: #1001163
---
 gbp/scripts/push.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gbp/scripts/push.py b/gbp/scripts/push.py
index d6876e26..63a06a20 100755
--- a/gbp/scripts/push.py
+++ b/gbp/scripts/push.py
@@ -172,8 +172,10 @@ def main(argv):
 if options.pristine_tar:
 commit, _ = repo.get_pristine_tar_commit(source)
 if commit:
-ref = 'refs/heads/pristine-tar'
-to_push['refs'].append((ref, get_push_src(repo, ref, commit)))
+target = repo.get_merge_branch('pristine-tar')
+if not repo.branch_contains(target, commit, remote=True):
+ref = 'refs/heads/pristine-tar'
+to_push['refs'].append((ref, get_push_src(repo, ref, commit)))
 
 if do_push(repo, [dest], to_push, dry_run=options.dryrun):
 retval = 0
-- 
2.35.1



signature.asc
Description: PGP signature

Bug#1010056: ncl: FTBFS on riscv64

[Bo YU]

Source: ncl
Version: 6.6.2-10
Severity: normal
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Dear Maintainer,

The debian-buildd on riscv64 for ncl package is fail:

```
...
ln -sf LINUX config/DEBIAN
echo 'n' | ./Configure -v
*** WARNING:There is a previous configuration saved.

Overwrite existing configuration? (n)
Enter Return(default), y(yes), n(no), or q(quit) >
Building Top-level Makefile with current configuration options

Making ymake from Makefile.ini in ./config first
make[2]: Entering directory '/<>/config'
cc -O -Wdate-time -D_FORTIFY_SOURCE=2  -c -o ymake-filter.o ymake-filter.c
cc -O -o ymake-filter ymake-filter.o
make[2]: Leaving directory '/<>/config'

Continuing in: /<>
./config/ymake : Unknown machine type
Unable to build Makefile - fix above errors and re-run.

Terminating configuration procedure
/usr/bin/make Makefiles includes depend
make[2]: Entering directory '/<>'
make[2]: *** No rule to make target 'Makefiles'.  Stop.
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:103: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:9: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

Build finished at 2022-03-22T22:49:31Z
```
The full build log is:

https://buildd.debian.org/status/fetch.php?pkg=ncl=riscv64=6.6.2-10=1647989379=0

Bug#1009367: libnss3 file location changes

[Jeremy Bicha]

On Sat, Apr 23, 2022 at 6:48 AM Stephan Verbücheln
 wrote:
> This patch is probably also related:
> https://sources.debian.org/patches/evolution/3.44.1-1/02_nss_paths.patch/

I guess I'll just drop that patch then.

Thank you,
Jeremy Bicha

Bug#1010055: ITP: base16384 -- Encode binary file to printable utf16be, and vise versa.

[fumiama]

Package: wnpp
Severity: wishlist
Owner: fumiama 

* Package name: base16384
  Version : 2.2.0
  Upstream Author : fumiama 
* URL : https://launchpad.net/base16384
* License : GPLv3
  Programming Lang: C
  Description : Encode binary file to printable utf16be, and vise versa.

We use 16384 Chinese characters (from \u4E00 to \u8DFF) as the "alphabet",
just like what base64 did.
If length of the data has a remainder after mod 7,
we will use \u3Dxx to present it with xx ranging from 01 to 06.

 - I designed this base64-like algorithm and had published it
   to my lauchpad PPA https://code.launchpad.net/~fumiama/+archive/ubuntu/ppa
   It seems to work well so that I hope to see more people
   who can use this util easily by entering apt-get directly.

 - I have read the wiki and found that in order to pubish my
   package to Debian, I am requested to get a sponsor for it.
   So I will file a RFS bug report later.

Bug#1009965: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder not working anymore

[Holger Schröder]

I have found the problem.

For some reason, part of the firmware with Debian 5.17 is not loaded
during boot. Manually loading the firmware fixes the problem and
everything works again. I have absolutely no idea why.

[...]


[   27.227512] si2168 12-0064: firmware: direct-loading firmware
dvb-demod-si2168-b40-01.fw
[   27.227515] si2168 12-0064: downloading firmware from file
'dvb-demod-si2168-b40-01.fw'
[   27.876124] si2168 12-0064: firmware version: B 4.0.11
[   27.887847] si2157 14-0060: found a 'Silicon Labs Si2157-A30 ROM 0x50'
[   27.887929] si2157 14-0060: firmware: failed to load
dvb-tuner-si2157-a30-01.fw (-2)
[   27.887931] si2157 14-0060: Can't continue without a firmware.
[   27.906139] si2157 14-0060: found a 'Silicon Labs Si2157-A30 ROM 0x50'
[   27.906145] si2157 14-0060: firmware: failed to load
dvb-tuner-si2157-a30-01.fw (-2)
[   27.906147] si2157 14-0060: Can't continue without a firmware.
[...]


...

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

[Andreas Metzler]

On 2022-04-22 Andrius Merkys  wrote:
> Hello,

> For me tbb 2020.3-1 fails to build in sid chroot with tbb.diff applied.
> First of all, build runs into missing symbols. I managed to get past
> this by removing them:

> --- a/debian/libtbbmalloc2.symbols.amd64
> +++ b/debian/libtbbmalloc2.symbols.amd64
> @@ -2,8 +2,6 @@ libtbbmalloc.so.2 libtbbmalloc2 #MINVER#
>   MallocInitializeITT@Base 2017~U7
>   _Z9parseFileILi100ELi1EEvPKcRAT0__K13parseFileItem@Base 2018~U6
>   _Z9parseFileILi100ELi2EEvPKcRAT0__K13parseFileItem@Base 2018~U6
> - (optional)_ZN11MallocMutex11scoped_lockD1Ev@Base 2020.3
> - (optional)_ZN11MallocMutex11scoped_lockD2Ev@Base 2020.3
>   _ZN3rml10pool_msizeEPNS_10MemoryPoolEPv@Base 2019~U4
>   _ZN3rml10pool_resetEPNS_10MemoryPoolE@Base 2017~U7
>   _ZN3rml11pool_createElPKNS_13MemPoolPolicyE@Base 2017~U7

Hello Andrius,

That is unnecessary. - The whole point of (optional) is that
dpkg-gensymbols will not *fail* when if these symbols are missing. It
only warns about them. See deb-src-symbols(5).

> After that, build fails at dh_shlibdeps step:

>dh_shlibdeps
> dpkg-shlibdeps: error: cannot find library libtbbmalloc.so.2 needed by
> debian/libtbbmalloc2/usr/lib/${DEB_HOST_MULTIARCH}/libtbbmalloc_proxy.so.2
> (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')

You need to 
chmod +x debian/libtbbmalloc2.install
after applying the patch to activate dh_exec.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1010054: prometheus-blackbox-exporter: ignores --log.level= commandline flag

[Tobias Klausmann]

Package: prometheus-blackbox-exporter
Version: 0.19.0-2
Severity: normal

Dear Maintainer,

This is essentially the same bug as #1002729, and likely caused by
broken vendoring.

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

Kernel: Linux 5.16.0-6-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages prometheus-blackbox-exporter depends on:
ii  adduser3.121
ii  debconf [debconf-2.0]  1.5.79
ii  init-system-helpers1.62
ii  libc6  2.33-7
ii  libcap2-bin1:2.44-1

prometheus-blackbox-exporter recommends no packages.

prometheus-blackbox-exporter suggests no packages.

-- Configuration Files:
/etc/prometheus/blackbox.yml changed:
modules:
  http_2xx:
prober: http
http:
  http_post_2xx:
prober: http
http:
  method: POST
  tcp_connect:
prober: tcp
  pop3s_banner:
prober: tcp
tcp:
  query_response:
  - expect: "^+OK"
  tls: true
  tls_config:
insecure_skip_verify: false
  ssh_banner:
prober: tcp
tcp:
  query_response:
  - expect: "^SSH-2.0-"
  irc_banner:
prober: tcp
tcp:
  query_response:
  - send: "NICK prober"
  - send: "USER prober prober prober :prober"
  - expect: "PING :([^ ]+)"
send: "PONG ${1}"
  - expect: "^:[^ ]+ 001"
  icmp:
prober: icmp


-- debconf information:
  prometheus-blackbox-exporter/want_cap_net_raw: false

Bug#1010053: php-pecl-http FTBFS: PHP_DEFAULT_VERSION cannot be empty

[Adrian Bunk]

Source: php-pecl-http
Version: 4.2.1+php8-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=php-pecl-http=4.2.1%2Bphp8-2%2Bb1

...
 fakeroot debian/rules clean
PHP_DEFAULT_VERSION_DEFAULT := "8.1"
PHP_DEFAULT_VERSION_OVERRIDE := "7.4"
AVAILABLE_PHP_VERSIONS := "8.1"
/usr/share/dh-php/pkg-pecl.mk:39: *** PHP_DEFAULT_VERSION cannot be empty.  
Stop.
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit 
status 2

Bug#1009865: transition: octave

[Rafael Laboissière]

* Sébastien Villemot  [2022-04-22 11:19]:


Le jeudi 21 avril 2022 à 09:57 +0200, Sébastien Villemot a écrit :

Le mercredi 20 avril 2022 à 12:06 +0200, Sebastian Ramacher a écrit :

On 2022-04-19 15:57:14 +0200, Sébastien Villemot wrote:

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-oct...@lists.debian.org

Please schedule a transition for octave. The new major upstream release 
(7.1.0), currently in experimental, changes the ABI.


Please go ahead


Thanks. The new version of octave was uploaded to unstable and built on 
all release architectures.


The transition is mostly over. I suggest to remove octave-mpi and 
octave-level-set from testing, and call it a day!


Thanks, Sébastien!

Version 0.3.1~git.2019.04.13-4 of the octave-level-set package, just 
uploaded to unstable, seems to build correctly against Octave 7.1.


Best,

Rafael

Bug#1009865: transition: octave

[Sébastien Villemot]

Le samedi 23 avril 2022 à 12:40 +0200, Rafael Laboissière a écrit :
> * Sébastien Villemot  [2022-04-22 11:19]:
> 
> > Le jeudi 21 avril 2022 à 09:57 +0200, Sébastien Villemot a écrit :
> > > Le mercredi 20 avril 2022 à 12:06 +0200, Sebastian Ramacher a écrit :
> > > > On 2022-04-19 15:57:14 +0200, Sébastien Villemot wrote:
> > > > > Package: release.debian.org
> > > > > Severity: normal
> > > > > User: release.debian@packages.debian.org
> > > > > Usertags: transition
> > > > > X-Debbugs-Cc: debian-oct...@lists.debian.org
> > > > > 
> > > > > Please schedule a transition for octave. The new major upstream 
> > > > > release 
> > > > > (7.1.0), currently in experimental, changes the ABI.
> > > > 
> > > > Please go ahead
> > > 
> > > Thanks. The new version of octave was uploaded to unstable and built on 
> > > all release architectures.
> > 
> > The transition is mostly over. I suggest to remove octave-mpi and 
> > octave-level-set from testing, and call it a day!
> 
> Thanks, Sébastien!
> 
> Version 0.3.1~git.2019.04.13-4 of the octave-level-set package, just 
> uploaded to unstable, seems to build correctly against Octave 7.1.

Great, thanks. Then you should probably close #1009180.

I now realize that two packages (octave-parallel and bart) fail their
autopkgtest against the new octave. I’ll have a look next week.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org




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

Bug#1010052: mysql-8.0 FTBFS: error: ‘size_t’ has not been declared

[Adrian Bunk]

Source: mysql-8.0
Version: 8.0.23-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=mysql-8.0=8.0.23-3%2Bb2

...
In file included from 
/<>/components/mysqlbackup/backup_page_tracker.h:29,
 from 
/<>/components/mysqlbackup/backup_page_tracker.cc:26:
/<>/include/mysql/components/services/page_track_service.h:58:36: 
error: ‘size_t’ has not been declared
   58 |size_t buf_len, int num_pages,
  |^~
In file included from 
/<>/include/mysql/components/services/page_track_service.h:27,
 from 
/<>/components/mysqlbackup/backup_page_tracker.h:29,
 from 
/<>/components/mysqlbackup/backup_page_tracker.cc:26:
/<>/include/mysql/components/services/page_track_service.h:139:59: 
error: ‘size_t’ has not been declared
  139 | uint64_t *stop_id, unsigned char *buffer, size_t 
buffer_len,
  |   ^~
/<>/include/mysql/components/service.h:102:58: note: in definition 
of macro ‘DECLARE_METHOD’
  102 | #define DECLARE_METHOD(retval, name, args) retval(*name) args
  |  ^~~~
...

Bug#1009367: libnss3 file location changes

[Stephan Verbücheln]

This patch is probably also related:
https://sources.debian.org/patches/evolution/3.44.1-1/02_nss_paths.patch/

Regards

Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

[Guillem Jover]

Hi!

On Fri, 2022-04-22 at 20:16:02 +0200, Thorsten Glaser wrote:
> On Fri, 22 Apr 2022, Mark Hindley wrote:
> > > Or Replaces: but that has downsides on deinstallation.
> > 
> > Yes. And I am unclear how dpkg would behave if sysvinit-core was installed
> > Replacing the manpages-l10n versions but then manpages-l10n was upgraded.
> 
> Hm. Given that manpages-l10n would *not* Replaces sysvinit-core,
> I’d… say/hope ☺ that those of sysvinit-core take precedence. But
> I have to admit… I actually am not sure. Asking the experts ☻

Replaces works as it would be expected, yes. So as long as a package
contains the field, even if a replaced package gets installed/upgraded
later then it will be kept being replaced. But as has been mentioned,
and on their own, they have the problem of leaving the system w/o those
replaced files if the replacing package gets removed or swapped.

I just checked the context for this report, and I think the better
option would be for systemd to ship their own translated man pages
(with appropriate Replaces/Breaks). (Helge have you considered or
tried that approach with upstream?) So that when someone switches
between sysvinit and systemd (or another init system providing the
same binaries), the translated man pages always correspond with the
actual original man pages and tools. I also think diversions or
alternatives do not seem appropriate as long as the commands themselves
are not handled in the same way.

Thanks,
Guillem

Bug#1010051: ghostscript: crash converting PDF to PNG

[Jeff]

Control: tags unblock -1 by 1007752
Control: notforwarded -1
Control: tags block 1009448 by -1


OpenPGP_signature
Description: OpenPGP digital signature

Bug#968036: samba: segfault with aio_pthread

[Michael Tokarev]

Control: tag -1 + moreinfo

On Fri, 07 Aug 2020 10:33:25 +0200 "Josep M. Perez"  
wrote:

Package: samba
Version: 2:4.12.5+dfsg-3
Severity: normal
Tags: upstream
X-Debbugs-Cc: josep.m.pe...@gmail.com

Dear Maintainer,

   * What led up to the situation?
Enabled aio_pthread.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Access by a Mac OS client seems to crash smbd from time to time.


aio_pthread appears to work in samba version in bullseye now. But
I can't test a MacOS client, I don't have any around. Can you verify
it is still failing?

Thanks,

/mjt

Bug#1010051: ghostscript: crash converting PDF to PNG

[Jeff]

Control: tags -1 - bookworm confirmed fixed-upstream ftbfs
thanks


OpenPGP_signature
Description: OpenPGP digital signature

Bug#998328: smbclient: missing alternative for smbspool_krb5_wrapper cups backend

[Michael Tokarev]

On Tue, 02 Nov 2021 15:17:42 +0100 Laurent Grawet  wrote:

Package: smbclient
Version: 2:4.13.5+dfsg-2
Severity: normal

Dear Maintainer,

   * What led up to the situation? no way to choose between smb and 
smbspool_krb5_wrapper cups backend
   * What exactly did you do (or not do) that was effective (or
 ineffective)? add alternative
   * What was the outcome of this action? success


According to the upstream comments, this appears to be not how
this stuff supposed to work in the first place.  But I'm not
sure.


This is how I've configured the new alternative:

update-alternatives --install /usr/lib/cups/backend/smb \
cups-backend-smb \
/usr/lib/x86_64-linux-gnu/samba/smbspool_krb5_wrapper 50


FWIW, we moved smbspool_krb5_wrapper from /usr/lib/$triple/samba/
to /usr/libexec/ in 4.16. Having an arch-specific path there is
definitely not nice.

/mjt

Bug#865846: src:xpuzzles: New upstream release (8.0.5)

[Florian Ernst]

Control: retitle -1 xpuzzles: New upstream release (8.4.0)

Hello Varun,

On Sun, Jun 25, 2017 at 09:19:27AM +0200, Florian Ernst wrote:
> there is a new upstream release on a new homepage, cf.
> , thus not noticed by uscan.

By now upstream is at 8.4.0. However, considering that the last
maintainer upload for xpuzzles dates back to 2013(!), despite several
upstream releases and an unacknowledged NMU since then and a removal
from testing due to RC-bugginess, I assume you are not working on this
package anymore.

Please let me know whether you have any plans for xpuzzles. As a former
maintainer of this package I'd very much wish to see it in better shape.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#993347: samba: recent systemd update (DSA-4942-1) makes samba-ad-dc complain about PID's.

[Michael Tokarev]

Control: tag -1 + moreinfo

So, as suggested by FeRD, has it been fixed by subsequent samba release(s)?
Louis, can you test a more recent version, or are you on stable/bullseye now
(which still does not have the mentioned fix)?

It looks like this issue has been fixed by 4.14...

Thanks,

/mjt

Bug#1009726: bullseye-pu: package samba/2:4.13.13+dfsg-1+deb11u4

[Michael Tokarev]

23.04.2022 11:28, Michael Tokarev wrote:
...

This also fixes a *sporaric* (rare) broken build which actually
happened with previous security update: #1006935, #1009855, #1002059


The #1002059 slipped there by a mistake. It is a different problem,
most likely a misconfiguration on the OP side. So I had to remove
mention of this bug# from the changelog. The rest of it is okay.
Please excuse me for the extra noise. There's just too many bugs -
still open and being closed by this update too.

Thanks,

/mjt

Bug#1009914: Acknowledgement (telegnome does not fetch page images)

[Renzo Davoli]

It is a package dependency problem.

telegnome requires gvfs-backends to work properly.

renzo

Bug#1008312: clementine: diff for NMU version 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2.1

[Florian Ernst]

On Thu, Apr 14, 2022 at 06:23:53PM +0200, Florian Ernst wrote:
> Please note that this bug also affects current stable, i.e. bullseye, and
> should be fixed there as well, as per
> .

JFTR, this will now be tracked in .

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1009726: bullseye-pu: package samba/2:4.13.13+dfsg-1+deb11u4

[Michael Tokarev]

I had to update the package in order to fix a serious build issue which lead
to a broken build of the previous security update of samba.  Here's the
new version of the bullseye-pu proposal.  I also added buglinks to the
changelog for every upstream patch I added.

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Debian Samba Maintainers 

This also fixes a *sporaric* (rare) broken build which actually
happened with previous security update: #1006935, #1009855, #1002059

Here's the proposed samba package update for bullseye.
I picked up a few patches which were missing when we
did security updates: we only picked up the security-
related patches from upstream but missed bugfixes.
Evem missed a known regression caused by two of the
security fixes in there (#999876, #1001053).

[ Reason ]
The reason for this update is simple: to fix quite some
bugs accumulated in there. Including one serious data
corruption issue.  The bugs being fixed are:

 #999876, winbind fails to start with `allow trusted domains: no`
  regression after a security fix
 #1001053 MIT-kerberos auth broken after 4.13.13+dfsg-1~deb11u2
  regression after a security fix
 #1004691 CVE-2021-43566: mkdir race condition allows share escape
 #1005642 possible data corruption due to windows client
  cache poisoning
 #998423 server coredump possible with share names containing
  %-variable substitutions
 #953530 unable to install samba on non-systemd system due to missing
  /run/samba dir before running samba tools

This also fixes a *sporaric* (rare) broken build which actually
happened with previous security update: #1006935, #1009855, #1002059

[ Tests ]
All code changes are coming from the upstream stable releases.
I included *all* changes from actual released 4.13.17 upstream
stable series (with all the known regressions there fixed),
except of the changes for parts we do not use (to lib/ldb/ -
this is our separate ldb package). So for the tests, this
release is much closer to the the one which survived the
excellent upstream testsuite and which has been tested
worldwide (what we had in bullseye-security before is some
mix from there).

Other code changes which are from releases later than 4.13.17
(which is the last upstream stable release for the 4.13 series)
are also taken from upstream stable fixes but destined for
later series.

The whole patch set has been running at our sites for quite
a while, for one it fixed the data corruption issue which
hit us hard (#1005642). We're running this since Feb-2022.

And we already run this release on all our production systems
with all the changes included (except it is using the UNRELEASED
build) for quite some time.

There's just one non-code change in there, #953530 - mkdir
/run/samba in postinst before invoking samba. I did verify
this actually fixes the issue (inability to install samba
on a non-systemd system), but this one does not affect
systems that are upgrading samba, as this directory is
already there.

[ Risks ]
There are risks, as with any complex piece of software.
Overall this release should be less risky than current
release in bullseye-security due to the fixes it missed.

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

[ Changes ]

>From the d/changelog:

  * fix the order of everything during build by exporting PYTHONHASHSEED=1
for waf.  This should fix the broken i386 build of the last security
upload. Closes: #1006935, #1009855, #1002059

This is a build procedure fix as described in the previous message
to this bugreport, which hit the stable-security i386 build (all
3 bugs are due to this broken build).

  * Import the left-over patches from 4.13.17 upstream stable branch:
   - s3-winbindd-fix-allow-trusted-domains-no-regression.patch
 https://bugzilla.samba.org/show_bug.cgi?id=14899
 Closes: #999876, winbind fails to start with `allow trusted domains: no`
   - IPA-DC-add-missing-checks.patch
 https://bugzilla.samba.org/show_bug.cgi?id=14903
   - CVE-2020-25717-s3-auth-fix-MIT-Realm-regression.patch
 https://bugzilla.samba.org/show_bug.cgi?id=14922
 Closes: #1001053, MIT-kerberos auth broken after 4.13.13+dfsg-1~deb11u2
   - dsdb-Use-DSDB_SEARCH_SHOW_EXTENDED_DN-when-searching.patch
 https://bugzilla.samba.org/show_bug.cgi?id=14656
 https://bugzilla.samba.org/show_bug.cgi?id=14902
   - s3-smbd-Fix-mkdir-race-condition-allows-share-escape.patch
 https://bugzilla.samba.org/show_bug.cgi?id=13979
 Closes: #1004691, CVE-2021-43566: mkdir race condition allows share escape

This brings us up to the upstream 4.13.17, - I verified both the result
after applying all the d/patches/ patches, and every individual patch
from there.  We are now at 4.13.17 release *except* of the version number
and the 

Bug#1010050: bullseye-pu: package clementine/1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1

[Florian Ernst]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Thomas Pierson 

[ Reason ]
Clementine fails to start if the package libqt5sql5-sqlite is not
installed, i.e. clementine is missing a Depends. This was reported in
#1008312, an identical fix has already been uploaded to Unstable.

[ Impact ]
Users need to realize that a Depends is missing that they need to
install manually. As it is, clementine might simply fail to start.
Clementine's error messages indicate that something is missing, but
finding the relevant missing package is hard for end users.

[ Tests ]
There are no code changes at all, clementine just gains an explicit
Depends on a package that most QT users will already have installed
anyways. I'm running the updated package on my local Bullseye just fine.

[ Risks ]
No code changes at all, a trivial fix, and the newly added Depends on
libqt5sql5-sqlite can be fulfilled on all release archs. There had been
a binNMU in Stable that had me worrying whether the versioning of the
proposed upload was correct, but according to apt/dpkg it all works as
intended, cf.
| ~/debian/temp/clementine $ apt policy clementine
| clementine:
|   Installed: 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1
|   Candidate: 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1
|   Version table:
|  1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2.1 50
|  50 http://deb.debian.org/debian unstable/main amd64 Packages
|  1.4.0~rc1+git347-gfc4cb6fc7+dfsg-2 50
|  50 http://deb.debian.org/debian testing/main amd64 Packages
|  *** 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1 100
| 100 /var/lib/dpkg/status
|  1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+b1 990
| 990 http://deb.debian.org/debian bullseye/main amd64 Packages
|  1.3.1+git609-g623a53681+dfsg-1 990
| 990 http://deb.debian.org/debian buster/main amd64 Packages
| ~/debian/temp/clementine $ dpkg --compare-versions 
'1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1' gt 
'1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+b1' && echo true
| true

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

[ Changes ]
Add explicit Depends on libqt5sql5-sqlite.

[ Other info ]
In the past other packages were impacted similarly and also fixed this
by adding an explicit Depends, e.g.
- kaffeine 1.0~pre3-1 (updated in kaffeine 2.0.3-1)
- kstars 4:16.08.3-2, #854516
- ktouch 4:19.08.3-2, LP#1790955

I'll upload once I receive your approval.

Cheers,
Flo
diff -Nru clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog
--- clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog
2020-10-27 11:30:27.0 +0100
+++ clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/changelog
2022-04-23 09:29:26.0 +0200
@@ -1,3 +1,10 @@
+clementine (1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+deb11u1) bullseye; 
urgency=medium
+
+  * Non-maintainer upload.
+  * Add explicit Depends on libqt5sql5-sqlite (Closes: #1008312)
+
+ -- Florian Ernst   Sat, 23 Apr 2022 09:29:26 +0200
+
 clementine (1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1) unstable; urgency=medium
 
   * New upstream snapshot.
diff -Nru clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control 
clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control
--- clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control  2020-10-27 
11:30:27.0 +0100
+++ clementine-1.4.0~rc1+git347-gfc4cb6fc7+dfsg/debian/control  2022-04-23 
09:12:37.0 +0200
@@ -38,6 +38,7 @@
 Package: clementine
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends},
+ libqt5sql5-sqlite,
  gstreamer1.0-plugins-base,
  gstreamer1.0-plugins-good,
  gstreamer1.0-plugins-ugly


signature.asc
Description: PGP signature

Bug#1009726: broken build of samba_4.13.13+dfsg-1~deb11u3 on i386

[Michael Tokarev]

Hello!

It turned out the security-uploaded build of samba on i386 is broken.
There were several reports about smbd segfaulting at startup or other
weirdness. This is specific to i386 build, the x64 build is fine (and
I know nothing about the other architectures).

An example bugreport is #1006935 - it has several items in the list
of broken things, but this list is definitely not complete.
Also #1009855 #1002059.

I tried to rebuild the same source package in a local clean bullseye
chroot, apparently with the same versions of everything, in the same
environment, and I'm getting *significantly* different binaries.
Updating just one package - switching from debian-built one into my
locally-built one immediately fixes the problem for me, samba starts
working as it should without weird errors or crashes.

The issue at hand seems to be the usage of python hashes in samba
build procedure for everything including lists of include or library
paths, lists of object files for link and everything. By default,
python hashes are randomly-ordered, - this means the order of all
this is unpredictable and each time we're getting VERY different
binaries.

Since samba overrides many system-provided functions, and the order
of objects to link is important, in this particular build we got
an order which made it use wrong functions in the end, and the
thing started to behave in a weird way.

Upstream tried to fix this by using PYTHONHASHSEED=1 (which *still*
gives an order which depends on the architecture, but this is a
different issue).

So we have to fix this one in bullseye.

I already prepared a bullseye-pu version of samba - #1009726 -
the bug#), which does not include this fix. I'll update it today
(the fix is trivial) and resubmit.  The bullseye-pu version has
some more fixes than is usually okay to bring to security@ but
most of them are worth the effort.

Now since the prob is quite serious, maybe we can fix this some
faster way?

Thanks,

/mjt

Bug#1010049: qt6-base-dev: should provide a QT_HOST_PATH directory for cross building

[Helmut Grohne]

Package: qt6-base-dev
Version: 6.2.4+dfsg-4
X-Debbugs-Cc: debian-cr...@lists.debian.org
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:qt6-base src:qt6-charts src:qt6-declarative 
src:qt6-quick3d

qt6-charts (for example) fails to cross build from source. You can see a
failure at
https://crossqa.debian.net/build/qt6-charts_6.2.4-2_mipsel_20220423044846.log.
The crucial bit is:

| CMake Error at /usr/lib/mipsel-linux-gnu/cmake/Qt6/QtSetup.cmake:224 
(message):
|   You need to set QT_HOST_PATH to cross compile Qt.

I think this makes it relatively obvious what needs to happen to fix it:
We should provide QT_HOST_PATH. This is where the problems begin.
According to https://doc.qt.io/qt-6/cmake-variable-qt-host-path.html,
QT_HOST_PATH should point to the qt6 installation and include e.g. moc.
Debian's qt6 moc is installed as /usr/lib/qt6/libexec/moc by
qt6-base-dev-tools. It's good that this has been split into a
Multi-Arch: foreign package already. However, that path is
architecture-independent and thus likely not suitable for QT_HOST_PATH.
I expect that QT_HOST_PATH also needs to point to architecture-dependent
files (e.g. libraries). Qt5 has faced as similar problem and thus added
symlink farms to qtbase5-dev in /usr/lib//qt5/bin pointing to
the moc from qtbase5-dev-tools. I think we need a similar symlink farm
for Qt6, but I don't know what Qt6 expects from a QT_HOST_PATH.

So this raises multiple questions:
 * What should QT_HOST_PATH be?
   + /usr/lib//qt6
   + /usr/lib/
   + Something else?
 * How do we have to structure the contents of QT_HOST_PATH?
   + Where precisely do tools like moc and rcc have to be located?
   + What other files are required to be located?

I request assistance from the Qt6 maintainers in figuring this out and
providing answers to the questions above. I hope that we can
constructively work this out together in a similar way that Lisandro and
Dmitry made cross building work for Qt5. At that time, none of the
involved parties knew how it would work, but combining the knowledge
resulted in a solution. Thank you for considering. I've written down
what I know.

Helmut

Bug#1009448: libpdf-builder-perl: FTBFS: dh_auto_test: error: make -j8 test TEST_VERBOSE=1 returned exit code 2

[Jeff]

In test 13, libpdf-builder-perl produces the attached PDF, which neither 
Firefox nor Evince complains about, and prior to v9.56.0, ghostscript 
accepted happily.


With v9.56.1:

$ gs -q -dNOPAUSE -dBATCH -sDEVICE=pnggray -g20x20 -dPDFFitPage 
-dUseCropBox -sOutputFile=out.png out.pdf

Error: /typecheck in --runpdf--
Operand stack:
   --dict:6/14(L)--   --dict:6/14(L)--   --dict:6/14(L)--   MediaBox 
--nostringval--   20.0   20.0   20.0   20.0   false   20.0   2

Execution stack:
   %interp_exit   .runexec2   --nostringval--   runpdf 
--nostringval--   2   %stopped_push   --nostringval--   runpdf   runpdf 
  false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1 
3   %oparray_pop   1977   1   3   %oparray_pop   1978   1   3 
%oparray_pop   runpdf   runpdf   2   1   1   runpdf 
%for_pos_int_continue   runpdf   runpdf   runpdf

Dictionary stack:
   --dict:765/1123(ro)(G)--   --dict:0/20(G)--   --dict:76/200(L)-- 
--dict:18/20(L)--

Current allocation mode is local
Last OS error: No such file or directory
GPL Ghostscript 9.56.1: Unrecoverable error, exit code 1
free(): double free detected in tcache 2

As ghostscript is only used by the tests for comparison purposes, and 
this does not affect the output of libpdf-builder-perl, I propose that 
we forward this to ghostscript and skip these two tests until we have a fix.


out.pdf
Description: Adobe PDF document


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010048: fs-uae-launcher: GUI is corrupted.

[waxhead]

Package: fs-uae-launcher
Version: 3.0.5+dfsg-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: waxh...@dirtcellar.net

Dear Maintainer,

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

   * What led up to the situation?

Tried to start fs-uae-launcher, the GUI looks "corrupted" like below...

++
|[start] [][][]  |
||
|+-+ |
|[cfgwindow] |
|| | |
|+-+ |
++

A start button, a config windows and some widgets overlapping [][][].


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

I tried to resize the window and update all packages.

   * What was the outcome of this action?

The GUI is still corrupted... No change.

   * What outcome did you expect instead?

Nothing really, was hoping it would "fix" itself by a resize, but it did not.

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


-- 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-6-amd64 (SMP w/4 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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fs-uae-launcher depends on:
ii  fs-uae  3.1.66-1
ii  python3 3.10.4-1
ii  python3-pyqt5   5.15.6+dfsg-1+b2
ii  python3-pyqt5.qtopengl  5.15.6+dfsg-1+b2
ii  python3-setuptools  59.6.0-1.2

fs-uae-launcher recommends no packages.

fs-uae-launcher suggests no packages.

-- no debconf information

Bug#1010047: RM: icu-le-hb -- RoM; abandoned and unused project

[GCS]

Package: ftp.debian.org
Severity: normal

Hi FTP Masters,

This package, icu-le-hb existed to give time to other projects for
functionality transition in ICU. The affected packages finished the
transition and this become an abandoned, obsolete project. Please
remove it from the archives.

Thanks,
Laszlo/GCS

Bug#1007905: transition: icu

[GCS]

On Fri, Apr 22, 2022 at 7:30 PM Sebastian Ramacher  wrote:
> Control: tags -1 = confirmed
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-icu.html
>
> On 2022-04-13 17:24:20 +0200, László Böszörményi wrote:
> > LibreOffice self-testing, especially its break iterator test fails for
> > the Lao language. Otherwise everything was fine. But I think I might
> > redo the rebuilds (only on amd64 now) to test everything with the
> > final release of ICU. If that's not mandatory, I think ICU is quite OK
> > for a transition soon.
>
> Please go ahead
 Thanks! Quick status update. ICU uploaded (with an additional
functionality and one security fix from upstream) and built on all
release and other !kfreebsd architectures already (well, alpha still
building it).
There's an autopkgtest regression with rspamd on i386 with its
'install' check: it is installed and started, but curl can't connect
to the listening socket; I don't see it's due to ICU and I think I'll
ask for its testing again.
Package boost1.74 was binNMUed already, rebuilt on all architectures,
expect on hppa where its bootstrap failed with 'Unknown target type
EXE'. Doesn't sound ICU related.
Matching pyicu was also uploaded and built on all possible
architectures. I'm going to file an RM bug for icu-le-hb for being an
abandoned (and unused) project for a while now. Meaning these two
packages don't need a binNMU.

I have to attend an event this afternoon but will continue watching
this transition and act if needed.

Regards,
Laszlo/GCS