Bug#1014794: tootle: (security) Doxxing issue: user agent (“application”) appears in status

[anonymous coward]

Package: tootle
Version: 1.0-alpha2-1
Severity: normal
X-Debbugs-Cc: debbug.too...@sideload.33mail.com

When a status/toot is composed, the user is given no control over what
populates the “application” field. This adds to users’
fingerprints.

I’ve been doxxed and it was revealed that the user agent was a crucial
factor.



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

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

Versions of packages tootle depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  elementary-xfce-icon-theme   0.15.2-1
ii  libc62.31-13
ii  libcairo21.16.0-5
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libgee-0.8-2 0.20.4-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libhandy-1-0 1.0.3-2
ii  libjson-glib-1.0-0   1.6.2-1
ii  libsoup2.4-1 2.72.0-2

tootle recommends no packages.

tootle suggests no packages.

-- no debconf information

Bug#1014730: liburi-perl: Breaks apt-cacher with "Can't locate Regexp/IPv6.pm" error

[Mark Hindley]

Niko,

On Mon, Jul 11, 2022 at 09:26:12PM +0300, Niko Tyni wrote:
> [apt-cacher maintainers: the context here is that URI.pm introduced an
> optional dependency on Regexp::IPv6 by requiring it in an eval block,
> but the apt-cacher __DIE__ handler exits when the require fails.]

Thanks for including me.

> On Mon, Jul 11, 2022 at 05:35:17PM +0200, gregor herrmann wrote:
> 
> > So we have:
> > - do nothing
> > - patch URI to restart the default signal handler in the eval
> > - (reassign? and) do something in apt-cacher
> 
> I'm not really sure if there's a consensus on best practices around
> $SIG{__DIE__}.

I agree, although perlvar suggests it should be avoided completely:

 Having to even think about the $^S variable in your exception handlers
 is simply wrong.  $SIG{__DIE__} as currently implemented invites
 grievous and difficult to track down errors.  Avoid it and use an
 "END{}" or CORE::GLOBAL::die override instead.

I don't know when that was added. I don't remember reading it before.

> IMO apt-cacher is the one that should be fixed, rather
> than demanding that all the modules it uses need to reset and restore
> $SIG{__DIE__} before catching exceptions.
> 
> >From 'perldoc -f die' :
> 
> You can arrange for a callback to be run just before the "die"
> does its deed, by setting the $SIG{__DIE__} hook. The associated
> handler is called with the exception as an argument, and can
> change the exception, if it sees fit, by calling "die" again.
> See "%SIG" in perlvar for details on setting %SIG entries, and
> "eval" for some examples. Although this feature was to be run only
> right before your program was to exit, this is not currently so:
> the $SIG{__DIE__} hook is currently called even inside "eval"ed
> blocks/strings! If one wants the hook to do nothing in such
> situations, put
> 
> die @_ if $^S;
> 
> as the first line of the handler (see "$^S" in perlvar). Because
> this promotes strange action at a distance, this counterintuitive
> behavior may be fixed in a future release.
> 
> Corresponding untested patch against apt-cacher attached.

The problem with this approach is that errors from apt-cacher's own evals will
be skipped as well.

Mark

Bug#1014793: linux-image-5.10.0-16-amd64: Kernel crashes while serving NFS

[Arne Nordmark]

Package: src:linux
Version: 5.10.127-1
Severity: normal

Dear Maintainer,

The new kernel in Debian 11.4 seems unstable and crashes when serving 
NFS. On two different computers, these lockups happens within minutes, 
typically when a client runs firefox on an NFS-mounted home directory. 
Typically the servers lock up without any printout, but on one occasion, 
the following was logged:


jul 10 08:35:13 ano4 kernel: general protection fault, probably for 
non-canonical address 0x2f48514544455145:  [#1] SMP PTI
jul 10 08:35:13 ano4 kernel: CPU: 2 PID: 1244 Comm: nfsd Not tainted 
5.10.0-16-amd64 #1 Debian 5.10.127-1
jul 10 08:35:13 ano4 kernel: Hardware name: System manufacturer System 
Product Name/P5Q DELUXE, BIOS 220105/21/2009

jul 10 08:35:13 ano4 kernel: RIP: 0010:fsnotify+0x2d9/0x570
jul 10 08:35:13 ano4 kernel: Code: 78 08 44 0b 30 44 0b 68 40 48 83 c1 
01 48 83 f9 04 75 d9 66 66 66 66 90 44 8b 4c 24 1c 44 89 e8 f7 d0 45 21 
f1 41 85 c1 74 4f <49> 8b 3f 48 8b 07 48 85 c0 0f 84 0a 01 00 00 48 8d 
7c 24 38 44 89

jul 10 08:35:13 ano4 kernel: RSP: 0018:abe901fa3bc8 EFLAGS: 00010202
jul 10 08:35:13 ano4 kernel: RAX: bab6aebe RBX: 0001 
RCX: 0004
jul 10 08:35:13 ano4 kernel: RDX: 00035a00 RSI: 0001 
RDI: 2f48514544455145
jul 10 08:35:13 ano4 kernel: RBP: abe901fa3c20 R08: 0001 
R09: 0002
jul 10 08:35:13 ano4 kernel: R10: 0002 R11: 0002 
R12: 0002
jul 10 08:35:13 ano4 kernel: R13: 45495141 R14: 424d6757 
R15: 2f48514544455145
jul 10 08:35:13 ano4 kernel: FS:  () 
GS:939527d0() knlGS:
jul 10 08:35:13 ano4 kernel: CS:  0010 DS:  ES:  CR0: 
80050033
jul 10 08:35:13 ano4 kernel: CR2: 560b8cee4000 CR3: 0001034da000 
CR4: 000406e0

jul 10 08:35:13 ano4 kernel: Call Trace:
jul 10 08:35:13 ano4 kernel:  __fsnotify_parent+0xe7/0x2d0
jul 10 08:35:13 ano4 kernel:  ? ext4_buffered_write_iter+0xce/0x160 [ext4]
jul 10 08:35:13 ano4 kernel:  ? do_iter_readv_writev+0x152/0x1b0
jul 10 08:35:13 ano4 kernel:  do_iter_write+0xc8/0x1b0
jul 10 08:35:13 ano4 kernel:  nfsd_vfs_write+0x175/0x510 [nfsd]
jul 10 08:35:13 ano4 kernel:  nfsd4_write+0x135/0x1b0 [nfsd]
jul 10 08:35:13 ano4 kernel:  nfsd4_proc_compound+0x40d/0x680 [nfsd]
jul 10 08:35:13 ano4 kernel:  nfsd_dispatch+0xd3/0x180 [nfsd]
jul 10 08:35:13 ano4 kernel:  svc_process_common+0x3d4/0x6d0 [sunrpc]
jul 10 08:35:13 ano4 kernel:  ? nfsd_svc+0x320/0x320 [nfsd]
jul 10 08:35:13 ano4 kernel:  svc_process+0xb7/0xf0 [sunrpc]
jul 10 08:35:13 ano4 kernel:  nfsd+0xe8/0x140 [nfsd]
jul 10 08:35:13 ano4 kernel:  ? nfsd_destroy+0x60/0x60 [nfsd]
jul 10 08:35:13 ano4 kernel:  kthread+0x11b/0x140
jul 10 08:35:13 ano4 kernel:  ? __kthread_bind_mask+0x60/0x60
jul 10 08:35:13 ano4 kernel:  ret_from_fork+0x22/0x30
jul 10 08:35:13 ano4 kernel: Modules linked in: dm_snapshot dm_bufio tun 
cpufreq_ondemand cpufreq_powersave cpufreq_conservative 
cpufreq_userspace aes_generic libaes crypto_simd cryptd glue_helper cbc 
cts rpcsec_gss_krb5 sit tunnel4 ip_tunnel nft_nat sch_fq_codel rc_pinnacl
e_pctv_hd em28xx_rc rc_core si2157 si2168 i2c_mux em28xx_dvb dvb_core 
snd_hda_codec_analog snd_hda_codec_generic ledtrig_audio ivtv_alsa 
tuner_simple tuner_types snd_hda_codec_hdmi wm8775 snd_hda_intel tda9887 
tda8290 snd_intel_dspcfg tea5767 soundwire_intel tuner 
soundwire_generic_allocation snd_soc_core snd
_compress soundwire_cadence cx25840 snd_hda_codec ivtv snd_hda_core 
snd_hwdep soundwire_bus em28xx kvm_intel radeon tveeprom snd_pcm cx2341x 
kvm ttm videodev snd_timer snd irqbypass soundcore drm_kms_helper mc 
serio_raw evdev cec i2c_algo_bit iTCO_wdt intel_pmc_bxt 
iTCO_vendor_support pcspkr watchdog sg acpi_
cpufreq asus_atk0110 button nft_chain_nat nf_nat nft_reject_inet 
nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_counter nft_ct
jul 10 08:35:13 ano4 kernel:  nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 
coretemp firewire_sbp2 nf_tables nfnetlink loop nfsd parport_pc ppdev 
nfs_acl lockd lp auth_rpcgss parport grace drm fuse sunrpc configfs 
ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 raid10 raid4
56 async_raid6_recov async_memcpy async_pq async_xor async_tx xor 
raid6_pq libcrc32c crc32c_generic raid0 multipath linear dm_mod raid1 
md_mod sd_mod hid_generic t10_pi ata_generic crc_t10dif 
crct10dif_generic st crct10dif_common usbhid pata_marvell hid ahci 
libahci mpt3sas firewire_ohci firewire_core aic7xxx
 crc_itu_t libata skge ehci_pci uhci_hcd scsi_transport_spi lpc_ich 
i2c_i801 sky2 ehci_hcd psmouse i2c_smbus raid_class scsi_transport_sas 
usbcore scsi_mod usb_common floppy

jul 10 08:35:13 ano4 kernel: ---[ end trace 159cb95f57d30ea4 ]---
jul 10 08:35:13 ano4 kernel: RIP: 0010:fsnotify+0x2d9/0x570
jul 10 08:35:13 ano4 kernel: Code: 78 08 44 0b 30 44 0b 68 40 48 83 c1 
01 48 83 f9 04 75 d9 66 66 66 66 90 44 8b 4c 24 1c 44 89 e8 f7 d0 45 21 
f1 41 85 c1 74 4f 

Bug#1014749: Thanks

[Christian Ehrhardt]

Odd, we had piuparts running as part of the CI pipeline every time.
Thank you for the report, we will have a look...

Bug#983715: libitext5-java: Please add itext-xtra too

[tony mancill]

On Sun, Feb 28, 2021 at 08:15:09PM +0100, Thomas Uhle wrote:
> Package: libitext5-java
> Version: 5.5.13-1
> Severity: normal
> 
> Dear maintainers,
> 
> when building a binary package next time, please also add the jar file and
> Maven files for itext-xtra.

Hi Thomas,

itext-xtra has Apache Commons Imaging [1] as a build dependency, which
is not yet packaged for Debian.  However, the build system and
dependencies for Commons Imaging look okay, so this feasible for
bookworm (assuming the copyright is clear).

Cheers,
tony

[1] https://commons.apache.org/proper/commons-imaging/index.html

Bug#722923: Fonts used as character sets are not supported

[Olly Betts]

Control: severity -1 wishlist
Control: tags -1 +help

On Fri, Sep 20, 2013 at 04:15:29PM +0200, Sébastien Hinderer wrote:
> Hello Olly, thanks for your e-mail.
> 
> > I'm not expecting absolute proof, but it'd be good to test it on a
> > selection of word documents, and compare output with and without
> > the patch.
> 
> Okay, will do once the patch is ready, which as I said will not happen
> shortly because it's a lot of work.

Did you give up on the idea of working on a patch for this?

> > It might be worth trying some of the other options (if you haven't
> > already).
> 
> So far I tried catdoc and maybe wordview, which were not more
> successful.
> 
> > wv has a command line extractor (wvText), which in my experience handles
> > some files better than antiword (and others less well).  Sadly it isn't
> > actively maintained upstream either these days (last release was just
> > under 3 years ago).  ISTR antiword is faster than wvText.  
> > 
> > There's wv2, but that doesn't come with a command line tool - it's
> > just a library.  That's also not active upstream (last release nearly 4
> > years ago).
> > 
> > There's also unoconv which uses libreoffice to do the extraction - that
> > means the extraction code is actively maintained upstream, and it seems
> > to work with most files I've tried.  The downside is it is rather slow
> > and memory hungry, and I've found it randomly fails sometimes.  I think
> > the issues stem from trying to remote control libreoffice, which of
> > course thinks it's a GUI application rather than a command line tool
> > or library.
> 
> Will give a new look to all these, thanks. I think libreoffice also
> misses the conversion.

There's also now lloconv as an alternative way to use libreoffice to
convert files.

But I checked lloconv and wvText and they produce similar output to
antiword with your example file, so it seems none of the available tools
on Linux handle such files.

> I don't knowbutthis font-as-codepag trick
> seemsnot very well supported. It looks as if people aremostly unaware of
> the problem. Perhaps i's because it has been used only for exotic fonts
> such as tibetan and sanskrit ones.

I know it used to be used in a more limited way for Maori which has
macrons on some vowels - in the days of 8-bit character sets it was
common to instead use vowels with umlauts and a font which displayed
these as macrons.  This variant of the trick is less problematic though
as most characters match and the ones which don't are at least visually
similar to the correct character.

However font-as-codepage really doesn't seem a very common trick, so I'm
lowering the severity to wishlist.

I've also tagged it "help" so it's more discoverable as a bug looking
for a patch.

Cheers,
Olly

Bug#1014792: purelibc: ftbfs on riscv64("error: ‘__NR_fork’ undeclared")

[Bo YU]

Source: purelibc
Version: 1.0.5-1
Severity: normal
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear purelibc Maintainer,
The package has a ftbfs issue on riscv64:

```
/<>/syscalls.c: In function ‘fork’:
/<>/syscalls.c:1026:30: error: ‘__NR_fork’ undeclared (first use 
in this function)
 1026 | return _pure_syscall(__NR_fork);
  |  ^
/<>/syscalls.c:1026:30: note: each undeclared identifier is 
reported only once for each function it appears in
/<>/syscalls.c: In function ‘select’:
/<>/syscalls.c:1198:30: error: ‘__NR_select’ undeclared (first use 
in this function)
 1198 | return 
_pure_syscall(__NR_select,n,readfds,writefds,exceptfds,timeout);
  |  ^~~
/usr/include/unistd.h: In function ‘fork’:
/<>/syscalls.c:1028:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 1028 | }
  | ^
/usr/include/riscv64-linux-gnu/sys/select.h: In function ‘select’:
/<>/syscalls.c:1209:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 1209 | }
```

The full buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=purelibc&arch=riscv64&ver=1.0.5-1&stamp=1651106695&raw=0

The patch attached is to fix the isssue and I can build riscv64 on
my locally real riscv64 hardware(Unmatched board) with it.

Please review it carefully and let me konw if you need my assistant to
do more tests, thanks.

Bo
-- 
Best Regards,

--- a/syscalls.c
+++ b/syscalls.c
@@ -1016,7 +1016,7 @@
 		return -1;
 	else
 		return child_tid;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || defined(__riscv) && __riscv_xlen==64
 	int child_tid;
 	if (_pure_syscall(__NR_clone, NULL, CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, &child_tid) < 0)
 		return -1;
@@ -1193,10 +1193,9 @@
 #ifdef __NR_epoll_create1
 int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout){
 #if defined(__x86_64__) || defined(__s390x__) || \
-	defined(__alpha__) || defined(__ia64__) || \
-	(defined(__riscv) && __riscv_xlen==64)
+	defined(__alpha__) || defined(__ia64__) 
 	return _pure_syscall(__NR_select,n,readfds,writefds,exceptfds,timeout);
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) || defined(__riscv) && __riscv_xlen==64
 	if (timeout == NULL)
 		return pselect(n,readfds,writefds,exceptfds,NULL,NULL);
 	else {


signature.asc
Description: PGP signature

Bug#1014648: digikam: Unable to display .heic correctly

[Steven Robbins]

On Monday, July 11, 2022 1:38:31 A.M. CDT Christian Marillat wrote:

> After a rebuild under pbuilder, I confirm that libheif-dev is missing
> from Build-Depends. Adding libheif-dev in Build-Depends fix this issue.

Thank you for debugging this.  I have uploaded -2 with the added build-
depends.

For what it's worth: on my system your HEIC file displayed correctly even with 
digikam 7.7.0-1.  Weird!

-Steve



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

Bug#1014791: qa.debian.org: udd: debian maintainer dashboard shows nothing when onlyrecent=on is checked

[Vagrant Cascadian]

Package: qa.debian.org
Severity: normal
X-Debbugs-Cc: Vagrant Cascadian 

I use UDD all the time, huge thanks!

I recently noticed a little checkbox on the Debian Maintainer Dashboard
page which I use regularly, and it seemed to be exactly what I wanted
today:

  "Packages recently touched: hide packages not uploaded during the last month"

But when I check this box, it shows no packages at all, even though
without it checked, it shows packages I updated in the last couple days:

  https://udd.debian.org/dmd/?email1=vagrant%40debian.org&onlyrecent=on

  vs.

  https://udd.debian.org/dmd/?email1=vagrant%40debian.org

onlyrecent=on sounds like a useful feature, so would love to use it!


Thanks again for such a tremendously useful service!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1014729: glibc 2.34 breaks wcc autopkgtest on amd64: open: Invalid argument

[Michael Hudson-Doyle]

On Tue, 12 Jul 2022 at 04:30, Aurelien Jarno  wrote:

> On 2022-07-11 10:06, Michael Hudson-Doyle wrote:
> > It looks like a no-change rebuild fixed this in Ubuntu fwiw.
>
> Thanks, I confirm that in Debian too. Do you have an idea why? It could
> be a missing or too loose dependency.
>

No. I got as far as reading
https://github.com/endrazine/wcc/blob/master/README.md and then was
completely unsurprised that it depends on the details of everything. It
would probably be quite fun to dig into why it's failing but I don't really
have the time for that today.

Cheers,
mwh

Bug#948712: Pinebook Pro also uses this chip

[Adam Borowski]

Pinebook Pro also wants this firmware, and it's definitely not a raspi,
and it doesn't have /boot/firmware either.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ What kind of a drug are "base" and "red pill"?  I think acid is
⢿⡄⠘⠷⠚⠋⠀ LSD, which would make base... ?  Judging from the behaviour of
⠈⠳⣄ those "based and redpilled", something nasty.

Bug#1014790: installation-reports: Pinebook Pro: first partition overwrites u-boot, lacks bootable flag

[Adam Borowski]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: kilob...@angband.pl

Boot method: µSD
Image version: daily, pinebookpro + partition.img

Machine: Pinebook Pro
Partitions:
Model: MMC DA4128 (sd/mmc)
Disk /dev/mmcblk2: 122138624kiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start End   Size  File system NameFlags
 1  1024kiB   16384kiB  15360kiB  u-boot
 2  16384kiB  515072kiB 498688kiB ext4bootboot, 
legacy_boot, esp
 3  515072kiB 117702656kiB  117187584kiB  btrfs
 4  117702656kiB  122137600kiB  4434944kiBlinux-swap(v1)  swap

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[E]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [E]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[ ]


Missing firmware for the network card; it was not present anywhere among
suggested places, only later I learned it's package "raspi-firmware" (which
doesn't play well with any non-raspi because of /boot/firmware).

I've succeeded the installation using a dock that included ethernet, further
d-i boots used usb tethering.


The main problem was in the partitioner: it starts the first partition at
1MB, which overwrites u-boot.  On Rockchip boxen, the loader wants u-boot
starting at sector 16384 (ie, 8MB).  Rounding up to an aligned value, I'd
recommend starting the first partition at 16MB.

Some doc on teh Interwebs suggests creating a dummy partition so nothing
tries to write there -- I've done so.


The other problem is the boot partition not flagged as bootable; this
results in u-boot config not being found.


The kernel's boot hanged in an unobvious place long before trying to
mount disks (despite the same version but different build working for
d-i); upon seeing that 5.19-rc4 from experimental works fine I didn't
bother debugging 5.18 as we'll upgrade once Linus releases 5.19.


After all this long fighting, it appears that the Pinebook Pro works fine.
I invite you to gawp at it at the DebConf :)


Meow!
-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20220628-02:02:00"
X_INSTALLATION_MEDIUM=netboot-gtk

==
Installer hardware-summary:
==
uname -a: Linux khazad-dum 5.18.0-2-arm64 #1 SMP Debian 5.18.5-1 (2022-06-16) 
aarch64 GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: xHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 5.18.0-2-arm64 xhci-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: xHCI Host Controller [1d6b:0003]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 03
usb-list:Manufacturer: Linux 5.18.0-2-arm64 xhci-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.18.0-2-arm64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 02: USB2.0 Hub [05e3:0608]
usb-list:Level 01 Parent 01 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 03: USB OPTICAL MOUSE  [18f8:0f97]
usb-list:Level 02 Parent 02 Port 00  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Interface 00: Class 03(HID  ) Subclass 01 Protocol 02 Driver usbhid
usb-list:Interface 01: Class 03(HID  ) Subclass 00 Protocol 01 Driver usbhid
usb-list: 
usb-list: Bus 03 Device 04: USB Camera [0c45:6321]
usb-list:Level 02 Parent 02 Port 01  Class ef(misc ) Subclass 02 Protocol 01
usb-list:Manufacturer: Sonix Technology Co., Ltd.
usb-list:Interface 00: Class 0e(video) Subclass 01 Protocol 00 Driver 
usb-list:Interface 01: Class 0e(video) Subclass 02 Protocol 00 Driver 
usb-list: 
usb-list: Bus 04 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.18.0-2-arm64 ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-li

Bug#1014789: rdiff-backup-fs: reproducible-builds: embedded build paths in /usr/bin/rdiff-backup-fs

[Vagrant Cascadian]

Source: rdiff-backup-fs
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in /usr/bin/rdiff-backup-fs:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/rdiff-backup-fs.html

  /build/1st/rdiff-backup-fs-1.0.0/rdiff-backup-fs.c:43
  vs.
  /build/2/rdiff-backup-fs-1.0.0/2nd/rdiff-backup-fs.c:43

The attached patches fix this by updating to using debhelper compat 13
which sets various compiler flags by default, patching configure.ac to
take EXTRA_CFLAGS, and passing EXTRA_CFLAGS to configure in
debian/rules.


With these patches applied, rdiff-backup-fs should build reproducibly on
tests.reproducible-builds.org!


live well,
  vagrant
From cc979a98912da5099859c5337d2c7de5bb7aac9d Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 11 Jul 2022 23:13:08 +
Subject: [PATCH 1/3] Update to debhelper compat 13.

---
 debian/compat  | 1 -
 debian/control | 2 +-
 debian/rules   | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)
 delete mode 100644 debian/compat

diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index 7f8f011..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-7
diff --git a/debian/control b/debian/control
index c6d57ea..b4fa00f 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: rdiff-backup-fs
 Section: utils
 Priority: extra
 Maintainer: Debian QA Group 
-Build-Depends: debhelper (>= 7.0.50~), autotools-dev, libz-dev, libfuse-dev, pkg-config, dh-autoreconf
+Build-Depends: debhelper-compat (= 13), libz-dev, libfuse-dev, pkg-config
 Standards-Version: 3.9.2
 Homepage: http://code.google.com/p/rdiff-backup-fs/
 
diff --git a/debian/rules b/debian/rules
index 21dfdfb..955dd78 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,4 +10,4 @@
 #export DH_VERBOSE=1
 
 %:
-	dh --with autoreconf $@ 
+	dh $@
-- 
2.36.1

From 20475bdd718c6baca6bd832dc92ef37821bec195 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 11 Jul 2022 23:13:49 +
Subject: [PATCH 2/3] configure.ac: Support passing EXTRA_CFLAGS when setting
 LIBS and CFLAGS variables.

---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7f7482a..ae26bde 100644
--- a/configure.ac
+++ b/configure.ac
@@ -46,8 +46,8 @@ AC_TYPE_SIZE_T
 dnl checking type of system to provide proper compile and linking flags
 
 case ${host} in
-*-*-linux-*|*-*-k*bsd*-*)	AC_SUBST(CFLAGS, ["-Wall -g -O3 `pkg-config --cflags fuse`"])
-			AC_SUBST(LIBS, ["$LIBS `pkg-config --cflags --libs fuse` -lz"]);;
+*-*-linux-*|*-*-k*bsd*-*)	AC_SUBST(CFLAGS, ["$EXTRA_CFLAGS -Wall -g -O3 `pkg-config --cflags fuse`"])
+			AC_SUBST(LIBS, ["$LIBS $EXTRA_CFLAGS `pkg-config --cflags --libs fuse` -lz"]);;
 *-*-bsd-*)		AC_SUBST(CFLAGS, ["-Wall -g -O3 `pkg-config --cflags fuse`"])
 			AC_SUBST(LIBS, ["$LIBS `pkg-config --cflags --libs fuse` -lz"]);;
 *-*-darwin*)	AC_SUBST(CFLAGS, ["-Wall -g -O3 `pkg-config --cflags fuse`"])
-- 
2.36.1

From 8f52af0fa9e957c8eff1797aaf57d8bb9233af47 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 11 Jul 2022 23:15:45 +
Subject: [PATCH 3/3] debian/rules: Set EXTRA_CFLAGS in dh_auto_configure
 override.

This allows passing the default compiler flags, such as
-ffile-prefix-map which is used to avoid embedding the build path.
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 955dd78..608d0b6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,3 +11,6 @@
 
 %:
 	dh $@
+
+override_dh_auto_configure:
+	EXTRA_CFLAGS="$(CFLAGS)" dh_auto_configure
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1013671: vlc: Video display in a separate window, even if 'integrate video in main video' is enabled

[Grand T]

Hello
The tips is not 100% efficient.
guy@debian:~/.config/vlc$ grep vout vlcrc
#vout=
vout=xcb_x11
guy@debian:~/.config/vlc$

apt policy vlc
vlc:
  Installé : 3.0.17.4-4+b1
  Candidat : 3.0.17.4-4+b1
 Table de version :
 *** 3.0.17.4-4+b1 500
500 https://cdn-aws.deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
 3.0.17.4-4 990
990 https://cdn-aws.deb.debian.org/debian bookworm/main amd64 Packages
 3.0.17.4-0+deb11u1 990
990 https://cdn-aws.deb.debian.org/debian-security 
bullseye-security/main amd64 Packages
500 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 Packages


Time to time the video opens in two windows, one for the video, one for the 
audio

Bug#1014787: paraview: no render view created

[Wojciech Aniszewski]

Package: paraview
Version: 5.10.1-2
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

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

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

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

Paraview 5.10.1-2 upon launch should display the visualization window (a 
"Layout"). Then, after loading external data or using any data source, it 
should be rendered in the main layout window. Instead, nothing happens, no 
rendering is shown, using other views (such as spreadsheet, etc.) is also 
impossible, Paraview windows is no longer refreshed, making it completely 
unusable.

I will add I'm on a Thinkpad T14, gen1, AMD. I can anclose the lspci etc., for 
now it suffices to say the video card is shown as, (lspci):

07:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Renoir (rev d1)

regards
WA





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

Kernel: Linux 5.18.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
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 paraview depends on:
ii  libavcodec59   7:5.0.1-3
ii  libavformat59  7:5.0.1-3
ii  libavutil577:5.0.1-3
ii  libc6  2.33-7
ii  libdouble-conversion3  3.1.7-4
ii  libexpat1  2.4.8-1
ii  libfreetype6   2.12.1+dfsg-3
ii  libgcc-s1  12.1.0-2
ii  libgdal31  3.5.0+dfsg-1+b1
ii  libgl2ps1.41.4.2+dfsg1-2
ii  libglew2.2 2.2.0-4
ii  libglx01.4.0-1
ii  libhdf5-103-1  1.10.7+repack-4+b1
ii  libjpeg62-turbo1:2.1.2-1
ii  liblz4-1   1.9.3-2
ii  liblzma5   5.2.5-2.1
ii  libnetcdf191:4.9.0-2
ii  libogg01.3.5-1
ii  libopengl0 1.4.0-1
ii  libopenmpi34.1.4-1
ii  libpng16-161.6.37-5
ii  libpython3.10  3.10.5-1
ii  libpython3.9   3.9.13-1
ii  libqt5core5a   5.15.4+dfsg-3
ii  libqt5gui5 5.15.4+dfsg-3
ii  libqt5help55.15.4-2
ii  libqt5network5 5.15.4+dfsg-3
ii  libqt5widgets5 5.15.4+dfsg-3
ii  libstdc++6 12.1.0-2
ii  libswscale67:5.0.1-3
ii  libtheora0 1.1.1+dfsg.1-16
ii  libtiff5   4.4.0-2
ii  libx11-6   2:1.7.5-1
ii  libxcursor11:1.2.1-1
ii  libxml22.9.14+dfsg-1
ii  python3-autobahn   22.1.1+dfsg1-2
ii  python3-matplotlib 3.5.2-1
ii  python3-mpi4py 3.1.3-2
ii  python3-six1.16.0-3
ii  python3-twisted22.4.0-2
ii  tcl [tclsh]8.6.11+1
ii  zlib1g 1:1.2.11.dfsg-4

Versions of packages paraview recommends:
ii  mpi-default-bin  1.14
ii  paraview-doc 5.10.1-2
ii  python3-paraview [python3-paraview]  5.10.1-2

Versions of packages paraview suggests:
ii  h5utils 1.13.1-4
ii  hdf5-tools  1.10.7+repack-4+b1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEENHZ/67ZMjPXjhgdLxBIgNKxmSF4FAmLMgewACgkQxBIgNKxm
SF4mQgf+PyAScbQMwrMi/95gbK2hWhXsi4FJy0SD6PdMXPXUiTAyh8KDW1ufx9XB
CG6+vQnUzZ8LrbxeIvHplZx+n8QN3PTgRNLrGidum7rpaetXd9359FjSQpLwnuWI
nAqa0KxM0HnD9e5o847QZz2/3EBgzcuOVAYrMQeqY4BBo01D2XTs+Dfgt1dd+cLf
/ZJFGubcS8eFRwMzSeimOsUk07LFTKOP2GnSwqsHoL5sHOZUZs+Op+Pi9reGBdjA
KRqPSJFM+KQRpTeE9QRFr47t1unlQq7b+e7TeeQejHYLcu5Kuo/5PrAsWoCjfByo
gJSkruQZgMjJovaktKnTZIdA1eDpjQ==
=OP7V
-END PGP SIGNATURE-

Bug#1014735: rpcsvc-proto: The /usr/include/rpc/* files is not included

[Aurelien Jarno]

Hi,

On 2022-07-11 22:18, Magnus Danielson wrote:
> Hi,
> 
> On 7/11/22 18:30, Aurelien Jarno wrote:
> > control: tag -1 + moreinfo
> > 
> > Hi,
> > 
> > On 2022-07-11 02:46, Magnus Danielson wrote:
> > > Package: rpcsvc-proto
> > > Version: 1.4.2-4
> > > Severity: grave
> > > Justification: renders package unusable
> > rpcsvc-proto is used to build many packages in Debian, so I doubt it is
> > completely unusable.
> Fair enough, but for my purpose it failed completely. Of the options given
> by text in recommended tool reportbug this was closest to my experienced
> situation.
> > 
> > > Dear Maintainer,
> > > 
> > > Template answers first, for your convenience.
> > > 
> > >     * What led up to the situation?
> > > 
> > > Rebuilding an application using rpcgen.
> > > 
> > >     * What exactly did you do (or not do) that was effective (or
> > >   ineffective)?
> > > 
> > > Run rpcgen, then tried to compile the produced files.
> > > 
> > >     * What was the outcome of this action?
> > > 
> > > Any of the /usr/include/rpc/* header-files referenced such as
> > > #include 
> > > etc. fail to include, all the related definitions missing causes large
> > > amount
> > > of compile errors.
> > Could you please give me more details about the issue? Ideally copy and
> > paste the error message.
> make
> rpcgen core.x
> gcc -DHAVE_CONFIG_H -I. -I. -I.    -Wall -g -O2 -c core_svc.c
> In file included from core_svc.c:6:
> core.h:9:10: fatal error: rpc/rpc.h: No such file or directory
>     9 | #include 
>   |  ^~~
> compilation terminated.
> make: *** [Makefile:514: core_svc.o] Error 1
> 
> So, here rpcgen process the core.x, outputting core_clnt.c, core_svc.c,
> core_xdr.c and core.h.

Ok, so that's definitely the issue of the SunRPC removal from glibc.

> The next step is to compile these, and for the case of core_svc.c this fails
> because
> 
> #include 
> 
> which is generated by rpcgen (there is no such reference in core.x) and thus
> needed by users for rpcgen.
> 
> I think it is fair to assume that when using rpcgen, the associated
> headerfiles needed to compile is either directly or indirectly in the
> package (or dependencies of the package).
 
> > My guess is that your problem is not related to rpcsvc-proto itself
> > which just provides rpcgen and related header files, but with the
> > removal of the SunRPC implementation for glibc. You need to switch to
> > the TI RPC implementation instead (using the libtirpc-dev package).
> 
> Which does not work out, since rpcgen does generate the dependence to
> /usr/include/rpc/* and the installed libtirpc-dev delivers the files in
> /usr/include/tirpc/rpc/* so despite being installed, gcc does not find it,
> and the rpcgen produces files that does not compile.

Given the SunRPC library has been removed from glibc, you definitely
need to use pkg-config to get the correct link time flags to link
your code against libtirpc. Therefore changes are needed to your
project, whether you want it or not. You can therefore do the same
changes for the includes.

There are multiple compatible RPC libraries (which actually predates the
SunRPC removal), and users are able to select the one they prefer by
using the correct include and link flags.

Note that most open source projects have already been updated to
automatically switch to an alternative RPC implementation since the
first distribution removed the SunRPC support more than 4 years ago (at
this time this was still an opt-in on the glibc side).

> > >     * What outcome did you expect instead?
> > > 
> > > Nice compile as headerfiles is found.
> > > 
> > > This is most likely a consequence of repackaging the rpc-part. Looking 
> > > back
> > > at
> > > the stable version of libc6 the header files is there in libc6-dev, but 
> > > for
> > > testing and unstable they are not. I expect that using these this would
> > > work.
> > > If the headerfiles is in another package, dependence on that should be in
> > > place.
> > The files that are removed from libc6-dev are the ones related to the
> > removed SunRPC implementation. libc6-dev (indirectly) depends on
> > libtirpc3-dev so the replacement header files should be available on
> > your system. That said it is not a one to one replacement, so you need
> > to use pkgconfig to get the compile and link flags.
> 
> Which is documented where for this change?

The changes is documented on the Debian side in changelog.Debian.gz and
on the upstream side in NEW.gz. That said, I agree that I failed to
properly document the changes with details instructions about how to
convert existing code in the NEWS.Debian.gz file.

> The repackaging caused generated code that did work fail to work. It seems

Just to be clear, this is not a repackaging. This is a *removal* of the
SunRPC support from glibc. The TI RPC library was already packaged in
Debian, and we just provided support for rpcgen (through the
rpcsvc-proto fork). The other alternative would have to just remove
an

Bug#1014741: libgd-perl: GD and GD2 image formats are disabled in libgd3 package

[Guyang "Alex" Mao]

That's honestly what I did to get my usecases working again.

I also removed the other 2-3 places gd/gd2 are mentioned but I'm not sure 
those break anything.


cheers,

On Mon, 11 Jul 2022, gregor herrmann wrote:


But I don't have enough knowledge about this stuff that I would feel
confident to blindly upload.

Bug#1014741: libgd-perl: GD and GD2 image formats are disabled in libgd3 package

[gregor herrmann]

Control: tag -1 + patch

On Mon, 11 Jul 2022 17:55:29 +0200, gregor herrmann wrote:

> I also note that the tests (which use the samples (which call the 
> export_format
> function (which has line 515 of Graph.pm))) also fail by now:
> 
> #   Failed test at t/samples.t line 21.
> # died: gdImageGdPtr error at 
> /build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
> # Compilation failed in require at t/samples.t line 17.

With this change

#v+
% cat debian/patches/disable-old-formats.patch 
--- a/Graph.pm
+++ b/Graph.pm
@@ -514,7 +514,7 @@
 $g->colorAllocate(0,0,0);
 $g->$_() 
};
-} qw(gif png jpeg xbm xpm gd gd2);
+} qw(gif png jpeg xbm xpm);
 wantarray ? @f : $f[0];
 }
 
#v-

the tests indeed pass.
But I don't have enough knowledge about this stuff that I would feel
confident to blindly upload.


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#1014198: deepin-movie-reborn: diff for NMU version 5.7.15-3.1

[Sebastian Ramacher]

Control: tags 1014198 + patch
Control: tags 1014198 + pending

Dear maintainer,

I've prepared an NMU for deepin-movie-reborn (versioned as 5.7.15-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru deepin-movie-reborn-5.7.15/debian/changelog deepin-movie-reborn-5.7.15/debian/changelog
--- deepin-movie-reborn-5.7.15/debian/changelog	2022-04-12 11:00:15.0 +0200
+++ deepin-movie-reborn-5.7.15/debian/changelog	2022-07-11 22:33:15.0 +0200
@@ -1,3 +1,11 @@
+deepin-movie-reborn (5.7.15-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Remove manual dependencies on libav* (Closes: #1014198)
+These dependencies are already added by ${shlibs:Depends}.
+
+ -- Sebastian Ramacher   Mon, 11 Jul 2022 22:33:15 +0200
+
 deepin-movie-reborn (5.7.15-3) unstable; urgency=medium
 
   * debian/patches:
diff -Nru deepin-movie-reborn-5.7.15/debian/control deepin-movie-reborn-5.7.15/debian/control
--- deepin-movie-reborn-5.7.15/debian/control	2022-04-12 09:48:53.0 +0200
+++ deepin-movie-reborn-5.7.15/debian/control	2022-07-11 22:33:14.0 +0200
@@ -47,9 +47,6 @@
 Package: deepin-movie
 Architecture: any
 Depends:
- libavcodec58 (>=7:4.0),
- libavformat58 (>=7:4.1),
- libavutil56 (>=7:4.0),
  libdmr0.1 (= ${binary:Version}),
  libffmpegthumbnailer4v5,
  libmpris-qt5-1 (>=0.1.0.1),
@@ -92,9 +89,6 @@
 Architecture: any
 Multi-Arch: same
 Depends:
- libavcodec58 (>=7:4.0),
- libavformat58 (>=7:4.1),
- libavutil56 (>=7:4.0),
  libffmpegthumbnailer4v5,
  libmpris-qt5-1 (>=0.1.0.1),
  libmpv1 (>=0.29),


signature.asc
Description: PGP signature

Bug#1013896: qtbase-opensource-src: Use KDE Qt as upstream instead of qt.io

[Shmerl]

On Tue, 28 Jun 2022 23:10:24 +0300 Dmitry Shachnev 
wrote:
> Hi Shmerl!
> Because KDE does not make any releases, and because some patches break
ABI,
> we decided to cherry-pick only individual patches that our users request.
>
> However, we made an exception for Qt Wayland, and the current Qt Wayland
> package in testing includes all patches from KDE up to 2022-05-14. This
should
> fix the issues with Wayland session.
>
> Are there any other patches you want to have?
>
> --
> Dmitry Shachnev

I know Wayland Qt patches are critical for stable Plasma experience,
but I'm not an expert on all of these.

May be some communication between upstream KDE developers and Debian
team would be good here? Expecting users to know what patches are important
isn't a very reliable method.

Thanks!

Shmerl.

Bug#1014186: blueman: leaves stray "Connected" and "Disconnected" popup windows

[Celejar]

On Mon, 11 Jul 2022 09:53:50 +0200
Christopher Schramm  wrote:

> Alright, so...
> 
> according to your first test and as expected a notification daemon does 
> not seem to be available. According to your report, you do have 
> notification-daemon installed, so running 
> /usr/lib/notification-daemon/notification-daemon in your desktop session 
> should solve that. Desktop environments often include a specific daemon. 
> notification-daemon is Gnome's. Plasma, Xfce, LxQt, MATE, Cinnamon etc. 
> have their own and the respective packages all provide 
> notification-daemon, see 
> https://packages.debian.org/bookworm/notification-daemon. A common 
> choice by folks on i3 and similar is dunst.

Thanks for the explanation - I'm using Xfce4, so I guess I'd want
xfce4-notifyd

> As no notification daemon seems to be running, blueman uses its fallback 
> and shows a GTK MessageDialog. Just like any GTK window, they should get 
> decorated by the window manager by default. A simple test in Python (run 
> with python3 -c as before or just in the interactive interpreter), 
> independent of blueman:
> 
> from gi.repository import Gtk
> Gtk.MessageDialog().show()
> Gtk.main()

No decorations.

> Boiled down to a GTK Window (MessageDialog is a special case of a Window):
> 
> from gi.repository import Gtk
> Gtk.Window().show()
> Gtk.main()

Decorations.

> Both should show decorations, as that's the default 
> (https://docs.gtk.org/gtk3/method.Window.set_decorated.html). I can 
> force missing decoration with:
> 
> from gi.repository import Gtk
> Gtk.Window(decorated=False).show()
> Gtk.main()
> 
> Maybe you can make it work with the opposite:
> 
> from gi.repository import Gtk
> Gtk.Window(decorated=True).show()
> Gtk.main()

Still no decorations (with Gtk.MessageDialog(decorated=True).show()
followed by Gtk.main())

> That's totally unexpected, though, and you seem to have a more generic 
> issue between GTK and your window manager, unrelated to blueman.

Okay, so this is probably some sort of GTK / Xfce4 problem? Should I
report it against some other package (which?), or reassign this report?

-- 
Celejar

Bug#1014784: libprimesieve10: unneccessary Provides+Conflicts renders shared library not-coinstallable

[Sebastian Ramacher]

Package: libprimesieve10
Version: 8.0+ds-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
Justification: Policy §8

libprimesieve10 and libprimesieve9 both declare Provides+Conflicts:
libprimesieve. This causes the shared library packages libprimesieve10
and libprimesieve9 unable to be installed at the same time. This makes
the upgrade from bullseye to bookworm unnecessarily more complex.

Please remove the Provides+Conflicts.

Cheers
-- 
Sebastian Ramacher

Bug#1014785: dojo: CVE-2021-23450

[Moritz Mühlenhoff]

Source: dojo
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for dojo.

CVE-2021-23450[0]:
| All versions of package dojo are vulnerable to Prototype Pollution via
| the setObject function.

https://github.com/advisories/GHSA-m8gw-hjpr-rjv7
Fixed by: 
https://github.com/dojo/dojo/commit/b7b8b279f3e082e9d4b54144fe831bdc77b2e0c9

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-23450
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23450

Please adjust the affected versions in the BTS as needed.

Bug#1014783: faust: CVE-2021-41736 CVE-2021-41737

[Moritz Mühlenhoff]

Source: faust
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerabilities were published for faust.

CVE-2021-41736[0]:
| Faust v2.35.0 was discovered to contain a heap-buffer overflow in the
| function realPropagate() at propagate.cpp.

https://github.com/grame-cncm/faust/issues/653

CVE-2021-41737[1]:
No description was found (try on a search engine)

https://github.com/grame-cncm/faust/issues/653

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-41736
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41736
[1] https://security-tracker.debian.org/tracker/CVE-2021-41737
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41737

Please adjust the affected versions in the BTS as needed.

Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting

[Celejar]

Package: xscreensaver
Version: 6.02+dfsg1-2
Severity: important

I have been using xscreensaver for years. Recently (a few weeks or
months ago), it has stopped activating when the "Preview" button is
clicked and (rather more importantly) as per the delay specified via the
"Blank after" setting. It still activates fine via command line
invocation ("xscreensaver-command -activate"), and when the system goes to
sleep (hibernate).

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

Kernel: Linux 5.18.0-2-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)
LSM: AppArmor: enabled

Versions of packages xscreensaver depends on:
ii  init-system-helpers  1.64
ii  libatk1.0-0  2.38.0-1
ii  libc62.33-7
ii  libcrypt11:4.4.28-1
ii  libglib2.0-0 2.72.3-1
ii  libgtk2.0-0  2.24.33-2
ii  libpam0g 1.4.0-13
ii  libpango-1.0-0   1.50.7+ds-1
ii  libsystemd0  251.2-8
ii  libx11-6 2:1.7.5-1
ii  libxext6 2:1.3.4-1
ii  libxft2  2.3.4-1
ii  libxi6   2:1.8-1
ii  libxinerama1 2:1.1.4-3
ii  libxml2  2.9.14+dfsg-1
ii  libxrandr2   2:1.5.2-2+b1
ii  libxt6   1:1.2.1-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data6.02+dfsg1-2

Versions of packages xscreensaver recommends:
ii  gsfonts-x11   0.28
ii  libjpeg-turbo-progs   1:2.1.2-1
ii  perl  5.34.0-5
ii  wamerican [wordlist]  2020.12.07-2

Versions of packages xscreensaver suggests:
ii  chromium [www-browser]   103.0.5060.53-1
ii  firefox [www-browser]102.0-1
pn  fortune  
pn  gdm3 | kdm-gdmcompat 
ii  lynx [www-browser]   2.9.0dev.10-1
pn  qcam | streamer  
pn  xdaliclock   
pn  xfishtank
pn  xscreensaver-data-extra  
pn  xscreensaver-gl  
pn  xscreensaver-gl-extra

-- Configuration Files:
/etc/pam.d/xscreensaver changed:
auth sufficient pam_u2f.so cue debug
@include common-auth
@include common-account


-- no debconf information

Bug#1014781: momd crashing due to error in HypervisorInterfaces/libvirtInterface.py

[Huf]

Package: mom
Version: 0.6.0-2
Severity: grave
Tags: patch
Justification: renders package unusable

Hello Dear Maintainer,

Looks like momd is "broken" in bullseye :-(
Service is failling every start with exception :
Jul 11 20:48:21 minas-anor momd[149966]:   File 
"/usr/lib/python3/dist-packages/mom/HypervisorInterfaces/libvirtInterface.py", 
line 128, in _domainGetPid
Jul 11 20:48:21 minas-anor momd[149966]: matches = 
re.findall(r"^\s*(\d+)\s+.*" + uuid, p1, re.M)
Jul 11 20:48:21 minas-anor momd[149966]:   File 
"/usr/lib/python3.9/re.py", line 241, in findall
Jul 11 20:48:21 minas-anor momd[149966]: return _compile(pattern, 
flags).findall(string)
Jul 11 20:48:21 minas-anor momd[149966]: TypeError: cannot use a string 
pattern on a bytes-like object

Comparing with current code for libvirtInterface.py in mom github 
https://github.com/oVirt/mom/blob/master/mom/HypervisorInterfaces/libvirtInterface.py
I made modification in libvirtInterface.py line 128
#p1 = Popen(["ps", "axww"], stdout=PIPE).communicate()[0]
p1 = Popen(["ps", "axww"], stdout=PIPE).communicate()[0].decode("utf-8")

Sorry for not attaching a patch file, not sure it is needed for this change

After this little change momd is now working correctly and tacking care of VM 
ballooning :-)

For the moment, i'm only using KVM + momd + balloning on test servers
(that's why i only discovered the issue now)
don't know if some other users are impacted in production.
I suppose bug is related to python 3.9, but not shure at all

Think a little "patch" release will be needed for debian package


Thank you for your time maintaining debian :-))




Here more complete log extract if needed
Jul 11 20:48:21 minas-anor momd[149966]: 2022-07-11 20:48:21,840 - 
mom.GuestManager - ERROR - Guest Manager crashed
Jul 11 20:48:21 minas-anor momd[149966]: Traceback (most recent call last):
Jul 11 20:48:21 minas-anor momd[149966]:   File 
"/usr/lib/python3/dist-packages/mom/GuestManager.py", line 86, in run
Jul 11 20:48:21 minas-anor momd[149966]: 
self._spawn_guest_monitors(domain_list)
Jul 11 20:48:21 minas-anor momd[149966]:   File 
"/usr/lib/python3/dist-packages/mom/GuestManager.py", line 112, in 
_spawn_guest_monitors
Jul 11 20:48:21 minas-anor momd[149966]: info = 
self.hypervisor_iface.getVmInfo(id)
Jul 11 20:48:21 minas-anor momd[149966]:   File 
"/usr/lib/python3/dist-packages/mom/HypervisorInterfaces/libvirtInterface.py", 
line 189, in getVmInfo
Jul 11 20:48:21 minas-anor momd[149966]: data['pid'] = 
self._domainGetPid(data['uuid'])
Jul 11 20:48:21 minas-anor momd[149966]:   File 
"/usr/lib/python3/dist-packages/mom/HypervisorInterfaces/libvirtInterface.py", 
line 128, in _domainGetPid
Jul 11 20:48:21 minas-anor momd[149966]: matches = 
re.findall(r"^\s*(\d+)\s+.*" + uuid, p1, re.M)
Jul 11 20:48:21 minas-anor momd[149966]:   File "/usr/lib/python3.9/re.py", 
line 241, in findall
Jul 11 20:48:21 minas-anor momd[149966]: return _compile(pattern, 
flags).findall(string)
Jul 11 20:48:21 minas-anor momd[149966]: TypeError: cannot use a string pattern 
on a bytes-like object
Jul 11 20:48:26 minas-anor momd[149966]: 2022-07-11 20:48:26,825 - mom - ERROR 
- Thread 'GuestManager' has exited



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

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

Versions of packages mom depends on:
ii  libvirt-daemon 7.0.0-3
ii  libvirt-daemon-system  7.0.0-3
ii  procps 2:3.3.17-5
ii  python33.9.2-3
ii  python3-libvirt7.0.0-2
ii  python3-six1.16.0-2

mom recommends no packages.

mom suggests no packages.

-- Configuration Files:
/etc/momd.conf changed [not included]

-- no debconf information

Bug#962932: ITP: plumpy -- Python workflows library

[Bastian Germann]

On Tue, 16 Jun 2020 07:56:34 +0300 mer...@debian.org wrote:

plumpy is required by aiida-core (ITP #901392). However, packaging of plumpy is 
currently blocked by its incompatibility with python3-tornado >= 5 [1].

I plan to maintain plumpy together with the DPMT.

[1] https://github.com/aiidateam/plumpy/issues/72


This is resolved with v0.16.0. Do you still want to package plumby?

Bug#1014780: ruby-kubeclient: CVE-2022-0759

[Moritz Mühlenhoff]

Source: ruby-kubeclient
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for ruby-kubeclient.

CVE-2022-0759[0]:
| A flaw was found in all versions of kubeclient up to (but not
| including) v4.9.3, the Ruby client for Kubernetes REST API, in the way
| it parsed kubeconfig files. When the kubeconfig file does not
| configure custom CA to verify certs, kubeclient ends up accepting any
| certificate (it wrongly returns VERIFY_NONE). Ruby applications that
| leverage kubeclient to parse kubeconfig files are susceptible to Man-
| in-the-middle attacks (MITM).

https://bugzilla.redhat.com/show_bug.cgi?id=2058404
https://github.com/ManageIQ/kubeclient/issues/554
https://github.com/ManageIQ/kubeclient/pull/556
https://github.com/ManageIQ/kubeclient/issues/555
https://github.com/ManageIQ/kubeclient/pull/556

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-0759
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0759

Please adjust the affected versions in the BTS as needed.

Bug#1014779: angular.js: CVE-2022-25844

[Moritz Mühlenhoff]

Source: angular.js
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for angular.js.

CVE-2022-25844[0]:
| The package angular after 1.7.0 are vulnerable to Regular Expression
| Denial of Service (ReDoS) by providing a custom locale rule that makes
| it possible to assign the parameter in posPre: ' '.repeat() of
| NUMBER_FORMATS.PATTERNS[1].posPre with a very high value. **Note:** 1)
| This package has been deprecated and is no longer maintained. 2) The
| vulnerable versions are 1.7.0 and higher.

https://snyk.io/vuln/SNYK-JS-ANGULAR-2772735

Notably, the website states that AngularJS support ended in January 2022
and that angular.io is the successor?

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-25844
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25844

Please adjust the affected versions in the BTS as needed.

Bug#1014778: gradle: CVE-2021-32751

[Moritz Mühlenhoff]

Source: gradle
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for gradle.

CVE-2021-32751[0]:
| Gradle is a build tool with a focus on build automation. In versions
| prior to 7.2, start scripts generated by the `application` plugin and
| the `gradlew` script are both vulnerable to arbitrary code execution
| when an attacker is able to change environment variables for the user
| running the script. This may impact those who use `gradlew` on Unix-
| like systems or use the scripts generated by Gradle in thieir
| application on Unix-like systems. For this vulnerability to be
| exploitable, an attacker needs to be able to set the value of
| particular environment variables and have those environment variables
| be seen by the vulnerable scripts. This issue has been patched in
| Gradle 7.2 by removing the use of `eval` and requiring the use of the
| `bash` shell. There are a few workarounds available. For CI/CD systems
| using the Gradle build tool, one may ensure that untrusted users are
| unable to change environment variables for the user that executes
| `gradlew`. If one is unable to upgrade to Gradle 7.2, one may generate
| a new `gradlew` script with Gradle 7.2 and use it for older versions
| of Gradle. Fpplications using start scripts generated by Gradle, one
| may ensure that untrusted users are unable to change environment
| variables for the user that executes the start script. A vulnerable
| start script could be manually patched to remove the use of `eval` or
| the use of environment variables that affect the application's
| command-line. If the application is simple enough, one may be able to
| avoid the use of the start scripts by running the application directly
| with Java command.

https://github.com/gradle/gradle/security/advisories/GHSA-6j2p-252f-7mw8

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-32751
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32751

Please adjust the affected versions in the BTS as needed.

Bug#1014777: libgig: CVE-2021-32294

[Moritz Mühlenhoff]

Source: libgig
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libgig.

CVE-2021-32294[0]:
| An issue was discovered in libgig through 20200507. A heap-buffer-
| overflow exists in the function RIFF::List::GetSubList located in
| RIFF.cpp. It allows an attacker to cause code Execution.

https://github.com/drbye78/libgig/issues/1

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-32294
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32294

Please adjust the affected versions in the BTS as needed.

Bug#1014776: tinyobjloader: CVE-2020-28589

[Moritz Mühlenhoff]

Source: tinyobjloader
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for tinyobjloader.

CVE-2020-28589[0]:
| An improper array index validation vulnerability exists in the LoadObj
| functionality of tinyobjloader v2.0-rc1 and tinyobjloader development
| commit 79d4421. A specially crafted file could lead to code execution.
| An attacker can provide a malicious file to trigger this
| vulnerability.

https://talosintelligence.com/vulnerability_reports/TALOS-2020-1212

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-28589
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28589

Please adjust the affected versions in the BTS as needed.

Bug#1014774: jupyterhub: CVE-2020-36191

[Moritz Mühlenhoff]

Source: jupyterhub
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for jupyterhub.

CVE-2020-36191[0]:
| JupyterHub 1.1.0 allows CSRF in the admin panel via a request that
| lacks an _xsrf field, as demonstrated by a /hub/api/user request (to
| add or remove a user account).

https://github.com/jupyterhub/jupyterhub/issues/3304

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-36191
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-36191

Please adjust the affected versions in the BTS as needed.

Bug#1014647: ITP: abpoa -- adaptive banded Partial Order Alignment

[Bastian Germann]

parsnp 1.7.4 does no longer need this because it comes with 
https://github.com/marbl/parsnp/pull/117

Bug#990662: nouveau 0000:01:00.0: firmware: failed to load nouveau/nvd9_fuc084 (-2)

[Andreas Beckmann]

On 11/07/2022 18.35, Mathieu Malaterre wrote:

Since the nvidia* package do the heavy lifting of downloading locally
binary, it would make sense to add yet-another package for firmware
related within the group.


Putting a downloader package in contrib under the Nvidia Team umbrella 
is fine, but someone needs to come up with an initial implementation.
A quick glance at the script gave me the impression that you need to 
extract firmware from the 340xx legacy or older drivers.
Looking at existing packages (e.g. firmware-b43-installer), a name of 
firmware-nouveau-installer might work.


Andreas

Bug#1014772: puppet: CVE-2021-27025

[Moritz Mühlenhoff]

Source: puppet
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for puppet.

CVE-2021-27025[0]:
| A flaw was discovered in Puppet Agent where the agent may silently
| ignore Augeas settings or may be vulnerable to a Denial of Service
| condition prior to the first 'pluginsync'.

https://puppet.com/security/cve/cve-2021-27025
https://github.com/puppetlabs/puppet/commit/da8b73edca174309a9bef5f62cd276933fe733e8
 (6.25.1)

This is too intrusive to backport (and has limited impact)
to released suites, but still filing a bug to track it.

This can be closed when puppet-agent 7 gets uploaded to unstable.   

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-27025
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27025

Please adjust the affected versions in the BTS as needed.

Bug#1013526: libtickit-widget-scrollbox-perl: FTBFS: dh_auto_test: error: /usr/bin/perl Build test --verbose 1 returned exit code 255

[Niko Tyni]

On Sun, Jul 03, 2022 at 05:20:17PM +0300, Niko Tyni wrote:
> On Sat, Jun 25, 2022 at 10:09:46AM +0300, Damyan Ivanov wrote:
> > Control: retitle -1 libtickit-widget-scrollbox-perl: intermittent memory 
> > corruption in t/02input-key.t and t/03input-mouse.t
> > 
> > I can reproduce this when running 02input-key.t and 03input-key.t in 
> > a loop. The symptom is the same - "malloc_consolidate(): unaligned 
> > fastbin chunk detected" error message and the tests exits with Wstat 
> > 134 after saying "All 14 subtests passed".
> > 
> > Wstat 134 is SIGABRT. Looks like a memory corruption of some sort.
> 
> We're seeing this too in Perl 5.36 test rebuilds. Possibly it's even
> more reproducible there, seems to always fail for us.
> 
>   
> http://perl.debian.net/rebuild-logs/perl-5.36-throwaway/libtickit-widget-scrollbox-perl_0.11-1/libtickit-widget-scrollbox-perl_0.11-1_amd64-2022-06-14T06:54:08Z.build

Update: I was able to build it on perl_5.36.0-2 / amd64, so
apparently no real Perl 5.36 relation after all.
-- 
Niko

Bug#1014771: jupyter-notebook: CVE-2022-24758

[Moritz Mühlenhoff]

Source: jupyter-notebook
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for jupyter-notebook.

CVE-2022-24758[0]:
| The Jupyter notebook is a web-based notebook environment for
| interactive computing. Prior to version 6.4.9, unauthorized actors can
| access sensitive information from server logs. Anytime a 5xx error is
| triggered, the auth cookie and other header values are recorded in
| Jupyter server logs by default. Considering these logs do not require
| root access, an attacker can monitor these logs, steal sensitive
| auth/cookie information, and gain access to the Jupyter server.
| Jupyter notebook version 6.4.x contains a patch for this issue. There
| are currently no known workarounds.

https://github.com/jupyter/notebook/security/advisories/GHSA-m87f-39q9-6f55
https://github.com/jupyter/notebook/commit/c219ce43c1ea25123fa70d264e7735bdf4585b1e
 (6.4.10)

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-24758
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24758

Please adjust the affected versions in the BTS as needed.

Bug#1014286: perl/experimental: FTBFS on mips64el: test failures

[Niko Tyni]

Control: severity -1 normal

On Sun, Jul 03, 2022 at 10:41:16PM +0300, Niko Tyni wrote:
> On Sun, Jul 03, 2022 at 04:29:22PM +0300, Niko Tyni wrote:
> > Source: perl
> > Version: 5.36.0-1
> > Severity: serious
> > Tags: ftbfs
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.36-transition
> > X-Debbugs-Cc: debian-m...@lists.debian.org
> > 
> > The perl package in experimental fails to build from source
> > on mips64el.
> > 
> >   https://buildd.debian.org/status/package.php?p=perl&suite=experimental
> > 
> > It looks like the perl binary dies with SIGSEGV in thread related tests
> > during the test suite. This happened twice on different buildds.
> > 
> > I'm running a test build now on eller.d.o to see if it's reproducible.
> 
> The package builds fine for me on eller, though it failed twice in the
> same way on the buildds (mipsel-osuosl-0[13]).
> 
> @debian-mips: any ideas? Could somebody please check if the package
> builds for you?

We now have two successful builds on mips64el buildds, so presumably
this is not a regression in perl.

Lowering the severity for now.
-- 
Niko Tyni   nt...@debian.org

Bug#1014770: jss: CVE-2021-4213

[Moritz Mühlenhoff]

Source: jss
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for jss.

CVE-2021-4213[0]:

https://bugzilla.redhat.com/show_bug.cgi?id=2042900
https://github.com/dogtagpki/jss/commit/5922560a78d0dee61af8a33cc9cfbf4cfa291448
 (v5.2.0-beta1)
https://github.com/dogtagpki/jss/commit/3aabe0e9d59b0a42e68ac8cd0468f9c5179967d2
 (v5.2.0-beta1)

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-4213
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4213

Please adjust the affected versions in the BTS as needed.

Bug#1014730: liburi-perl: Breaks apt-cacher with "Can't locate Regexp/IPv6.pm" error

[Niko Tyni]

[apt-cacher maintainers: the context here is that URI.pm introduced an
optional dependency on Regexp::IPv6 by requiring it in an eval block,
but the apt-cacher __DIE__ handler exits when the require fails.]

On Mon, Jul 11, 2022 at 05:35:17PM +0200, gregor herrmann wrote:

> So we have:
> - do nothing
> - patch URI to restart the default signal handler in the eval
> - (reassign? and) do something in apt-cacher

I'm not really sure if there's a consensus on best practices around
$SIG{__DIE__}.  IMO apt-cacher is the one that should be fixed, rather
than demanding that all the modules it uses need to reset and restore
$SIG{__DIE__} before catching exceptions.

>From 'perldoc -f die' :

You can arrange for a callback to be run just before the "die"
does its deed, by setting the $SIG{__DIE__} hook. The associated
handler is called with the exception as an argument, and can
change the exception, if it sees fit, by calling "die" again.
See "%SIG" in perlvar for details on setting %SIG entries, and
"eval" for some examples. Although this feature was to be run only
right before your program was to exit, this is not currently so:
the $SIG{__DIE__} hook is currently called even inside "eval"ed
blocks/strings! If one wants the hook to do nothing in such
situations, put

die @_ if $^S;

as the first line of the handler (see "$^S" in perlvar). Because
this promotes strange action at a distance, this counterintuitive
behavior may be fixed in a future release.

Corresponding untested patch against apt-cacher attached.
-- 
Niko Tyni   nt...@debian.org
>From 33013c19088fa3a43e468ef41aa0d1298e63d233 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Mon, 11 Jul 2022 21:18:43 +0300
Subject: [PATCH] Handle eval blocks in unsuspecting libraries

$SIG{__DIE__} can get called from eval blocks - don't bail out if so.

Bug-Debian: https://bugs.debian.org/1014730
---
 apt-cacher | 1 +
 1 file changed, 1 insertion(+)

diff --git a/apt-cacher b/apt-cacher
index a8c00cb..8c1fe88 100755
--- a/apt-cacher
+++ b/apt-cacher
@@ -1253,6 +1253,7 @@ sub write_error_log {
 }
 
 sub die_handler {
+die @_ if $^S; # called from an eval block
 my ($msg) = @_;
 write_error_log("error [$$]: $msg");
 sendrsp(HTTP::Response->new(502, 'apt-cacher internal error (died)', ['Connection' => 'close'])) if $con;
-- 
2.30.2

Bug#1014769: netty: CVE-2021-37136 CVE-2021-37137

[Moritz Mühlenhoff]

Source: netty
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for netty.

CVE-2021-37136[0]:
| The Bzip2 decompression decoder function doesn't allow setting size
| restrictions on the decompressed output data (which affects the
| allocation size used during decompression). All users of Bzip2Decoder
| are affected. The malicious input can trigger an OOME and so a DoS
| attack

https://github.com/netty/netty/security/advisories/GHSA-grg4-wf29-r9vv
Fixed by: 
https://github.com/netty/netty/commit/41d3d61a61608f2223bb364955ab2045dd5e4020 
(netty-4.1.68.Final)

CVE-2021-37137[1]:
| The Snappy frame decoder function doesn't restrict the chunk length
| which may lead to excessive memory usage. Beside this it also may
| buffer reserved skippable chunks until the whole chunk was received
| which may lead to excessive memory usage as well. This vulnerability
| can be triggered by supplying malicious input that decompresses to a
| very big size (via a network stream or a file) or by sending a huge
| skippable chunk.

https://github.com/netty/netty/security/advisories/GHSA-9vjp-v76f-g363
Fixed by: 
https://github.com/netty/netty/commit/6da4956b31023ae967451e1d94ff51a746a9194f 
(netty-4.1.68.Final)

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-37136
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-37136
[1] https://security-tracker.debian.org/tracker/CVE-2021-37137
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-37137

Please adjust the affected versions in the BTS as needed.

Bug#1014710: gegl: CVE-2018-10111 CVE-2018-10112

[Moritz Mühlenhoff]

Am Mon, Jul 11, 2022 at 09:30:56AM +0200 schrieb Jeremy Bicha:
> fixed 1014710 0.3.34-1

Why do you believe 0.3.34 is fixed? The Gitlab issue referenced
still shows it as unfixed?

Cheers,
Moritz

Bug#1014584: lintian: False positive binary-nmu-debian-revision-in-source and source-nmu-has-incorrect-version-number with Ubuntu version

[Mattia Rizzolo]

On Fri, Jul 08, 2022 at 01:34:49PM +0200, Axel Beckert wrote:
> Hi,
> 
> Alberto Contreras wrote:
> > When I invoke `lintian` over a package with a version like
> > `22.2-64-g1fcd55d6-0ubuntu1~22.10.1` it emits
> > `binary-nmu-debian-revision-in-source` and
> > `source-nmu-has-incorrect-version-number` source warnings.  This looks like

ISTR that source-nmu-* just wasn't issued under ubuntu (i.e. with
--profile=ubutnu), did it start to be issued now?  I don't have any
recollection about binary-nmu-*

If I dreamt the whole thing, then perhaps it should be done, because the
concept of NMU doesn't exist in Ubuntu, so the tag as a whole doesn't
make sense.

That said, AFAIK -0ubuntu1~22.10.1 is not a formally documented version
anywhere, though I have seen it a few times.

Alberto: what kind of upload is this?  22.10 is the current dev version,
so it's not some kind of backport.  With such context, I can guess that
this is some kind of package that your team is maintianing for multiple
ubuntu branches, in which case I'd expect you to follow the SRU
versioning, which prescribe -0ubuntu0.22.10.1 instead.
https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging


I must also add that using . instead of ~ is fraught with catches, as
documented by, for example, 
https://lintian.debian.org/tags/dfsg-version-with-period
So I'd advocate a change in that policy, which hasn't been touched for
at least a decade (when I started contributing to ubuntu packages…)

> Note to myself: There's a similar albeit not identical issue reported
> in https://bugs.debian.org/1001399.

♥ Axel :)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1014768: gnuradio: FTBFS on mipsel: undefined reference to `__atomic_load_8'

[Sebastian Ramacher]

Source: gnuradio
Version: 3.10.3.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=gnuradio&arch=mipsel&ver=3.10.3.0-1&stamp=1657488517&raw=0

FAILED: gr-blocks/lib/blocks_qa_block_tags.cc 
: && /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized 
-fcx-limited-range -O3 -DNDEBUG -Wl,-z,relro 
gr-blocks/lib/CMakeFiles/blocks_qa_block_tags.cc.dir/qa_block_tags.cc.o -o 
gr-blocks/lib/blocks_qa_block_tags.cc  
-Wl,-rpath,/<>/obj-mipsel-linux-gnu/gr-blocks/lib:/<>/obj-mipsel-linux-gnu/gnuradio-runtime/lib:/<>/obj-mipsel-linux-gnu/gnuradio-runtime/lib/pmt
  gr-blocks/lib/libgnuradio-blocks.so.3.10.3.0  
/usr/lib/mipsel-linux-gnu/libboost_unit_test_framework.so.1.74.0  
gnuradio-runtime/lib/libgnuradio-runtime.so.3.10.3.0  
gnuradio-runtime/lib/pmt/libgnuradio-pmt.so.3.10.3.0  
/usr/lib/mipsel-linux-gnu/libboost_program_options.so.1.74.0  
/usr/lib/mipsel-linux-gnu/libboost_thread.so.1.74.0  
/usr/lib/mipsel-linux-gnu/libboost_atomic.so.1.74.0  
/usr/lib/mipsel-linux-gnu/libspdlog.so.1.9.2  -lpthread  
/usr/lib/mipsel-linux-gnu/libfmt.so.8.1.1  -Wl,--as-needed  
/usr/lib/mipsel-linux-gnu/libgmpxx.so  /usr/lib/mipsel-linux-gnu/libgmp.so  
-lrt  /usr/lib/mipsel-linux-gnu/libvolk.so.2.5.1  -ldl  -lm  
/usr/lib/mipsel-linux-gnu/libsndfile.so && :
/usr/bin/ld: gr-blocks/lib/libgnuradio-blocks.so.3.10.3.0: undefined reference 
to `__atomic_load_8'
/usr/bin/ld: gr-blocks/lib/libgnuradio-blocks.so.3.10.3.0: undefined reference 
to `__atomic_store_8'
collect2: error: ld returned 1 exit status
[403/1743] /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK 
-DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_TEST_DYN_LINK -DBOOST_TEST_MAIN 
-DBOOST_THREAD_DYN_LINK -DBOOST_UNIT_TEST_FRAMEWORK_DYN_LINK -DFMT_LOCALE 
-DFMT_SHARED -DGR_MPLIB_GMP -DGR_PERFORMANCE_COUNTERS -DHAVE_SF_FORMAT_OPUS 
-DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DSPDLOG_SHARED_LIB 
-I/<>/gr-blocks/lib/../include 
-I/<>/gnuradio-runtime/lib/../include 
-I/<>/obj-mipsel-linux-gnu/gnuradio-runtime/lib/../include 
-I/<>/gnuradio-runtime/lib/pmt/../../include -isystem 
/usr/include/python3.10 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized 
-fcx-limited-range -O3 -DNDEBUG -std=c++17 -MD -MT 
gr-blocks/lib/CMakeFiles/blocks_qa_gr_flowgraph.cc.dir/qa_gr_flowgraph.cc.o -MF 
gr-blocks/lib/CMakeFiles/blocks_qa_gr_flowgraph.cc.dir/qa_gr_flowgraph.cc.o.d 
-o gr-blocks/lib/CMakeFiles/blocks_qa_gr_flowgraph.cc.dir/qa_gr_flowgraph.cc.o 
-c /<>/gr-blocks/lib/qa_gr_flowgraph.cc
[404/1743] /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK 
-DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_TEST_DYN_LINK -DBOOST_TEST_MAIN 
-DBOOST_THREAD_DYN_LINK -DBOOST_UNIT_TEST_FRAMEWORK_DYN_LINK -DFMT_LOCALE 
-DFMT_SHARED -DGR_MPLIB_GMP -DGR_PERFORMANCE_COUNTERS -DHAVE_SF_FORMAT_OPUS 
-DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DSPDLOG_SHARED_LIB 
-I/<>/gr-blocks/lib/../include 
-I/<>/gnuradio-runtime/lib/../include 
-I/<>/obj-mipsel-linux-gnu/gnuradio-runtime/lib/../include 
-I/<>/gnuradio-runtime/lib/pmt/../../include -isystem 
/usr/include/python3.10 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized 
-fcx-limited-range -O3 -DNDEBUG -std=c++17 -MD -MT 
gr-blocks/lib/CMakeFiles/blocks_qa_gr_hier_block2_derived.cc.dir/qa_gr_hier_block2_derived.cc.o
 -MF 
gr-blocks/lib/CMakeFiles/blocks_qa_gr_hier_block2_derived.cc.dir/qa_gr_hier_block2_derived.cc.o.d
 -o 
gr-blocks/lib/CMakeFiles/blocks_qa_gr_hier_block2_derived.cc.dir/qa_gr_hier_block2_derived.cc.o
 -c /<>/gr-blocks/lib/qa_gr_hier_block2_derived.cc
[405/1743] /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK 
-DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_TEST_DYN_LINK -DBOOST_TEST_MAIN 
-DBOOST_THREAD_DYN_LINK -DBOOST_UNIT_TEST_FRAMEWORK_DYN_LINK -DFMT_LOCALE 
-DFMT_SHARED -DGR_MPLIB_GMP -DGR_PERFORMANCE_COUNTERS -DHAVE_SF_FORMAT_OPUS 
-DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DSPDLOG_SHARED_LIB 
-I/<>/gr-blocks/lib/../include 
-I/<>/gnuradio-runtime/lib/../include 
-I/<>/obj-mipsel-linux-gnu/gnuradio-runtime/lib/../include 
-I/<>/gnuradio-runtime/lib/pmt/../../include -isystem 
/usr/include/python3.10 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized 
-fcx-limited-range -O3 -DNDEBUG -std=c++17 -MD -MT 
gr-blocks/lib/CMakeFiles/blocks_qa_gr_top_block.cc.dir/qa_gr_top_block.cc.o -MF 
gr-blocks/lib/CMakeFiles/blocks_qa_gr_top_block.cc.dir/qa_gr_top_block.cc.o.d 

Bug#1014767: qemu: CVE-2021-3735

[Moritz Mühlenhoff]

Source: qemu
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for qemu.

CVE-2021-3735[0]:
ahci: deadlock issue leads to denial of service

No upstream fix currently:  
https://bugzilla.redhat.com/show_bug.cgi?id=1997184

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3735
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3735

Please adjust the affected versions in the BTS as needed.

Bug#1014766: lxml: CVE-2022-2309

[Moritz Mühlenhoff]

Source: lxml
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for lxml.

CVE-2022-2309[0]:
| NULL Pointer Dereference allows attackers to cause a denial of service
| (or application crash). This only applies when lxml is used together
| with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not
| affected. It allows triggering crashes through forged input data,
| given a vulnerable code sequence in the application. The vulnerability
| is caused by the iterwalk function (also used by the canonicalize
| function). Such code shouldn't be in wide-spread use, given that
| parsing + iterwalk would usually be replaced with the more efficient
| iterparse function. However, an XML converter that serialises to C14N
| would also be vulnerable, for example, and there are legitimate use
| cases for this code sequence. If untrusted input is received (also
| remotely) and processed via iterwalk function, a crash can be
| triggered.

https://huntr.dev/bounties/8264e74f-edda-4c40-9956-49de635105ba/
https://github.com/lxml/lxml/commit/86368e9cf70a0ad23cccd5ee32de847149af0c6f 
(lxml-4.9.1)

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-2309
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2309

Please adjust the affected versions in the BTS as needed.

Bug#1014765: httpie: CVE-2022-0430

[Moritz Mühlenhoff]

Source: httpie
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for httpie.

CVE-2022-0430[0]:
| Exposure of Sensitive Information to an Unauthorized Actor in GitHub
| repository httpie/httpie prior to 3.1.0.

https://huntr.dev/bounties/dafb2e4f-c6b6-4768-8ef5-b396cd6a801f
Fixed by: 
https://github.com/httpie/httpie/commit/65ab7d5caaaf2f95e61f9dd65441801c2ddee38b
 (3.1.0)

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-0430
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0430

Please adjust the affected versions in the BTS as needed.

Bug#1014764: guestfs-tools: CVE-2022-2211

[Moritz Mühlenhoff]

Source: guestfs-tools
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for guestfs-tools.

CVE-2022-2211[0]:
Buffer overflow in get_keys leads to Dos

https://bugzilla.redhat.com/show_bug.cgi?id=2100862
https://listman.redhat.com/archives/libguestfs/2022-June/029274.html
https://listman.redhat.com/archives/libguestfs/2022-June/029277.html

https://github.com/libguestfs/libguestfs-common/commit/35467027f657de76aca34b48a6f23e9608b23a57
Documentation: 
https://github.com/libguestfs/libguestfs/commit/99844660b48ed809e37378262c65d63df6ce4a53

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-2211
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2211

Please adjust the affected versions in the BTS as needed.

Bug#1014763: dput-ng: dcut rm generates invalid commands

[Mark Brown]

Package: dput-ng
Version: 1.33
Severity: normal

I have tried to delete some uploads using commands like

dcut rm --searchdirs -f zlib_1.2.12.dfsg-0.1.dsc

however I'm told that there are errors showing up in the logs on
ftp-master saying

Jul 11 17:18:33 /broonie-1657559146.commands contains no or bad 
Uploader: field: 

Using -O to collect a commands file shows that it's generating files
like:

| Archive: ftp.upload.debian.org
| Commands:
|  rm --searchdirs zlib_1.2.12.dfsg-0.1.dsc

which just don't have an Uploader: field.

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

Kernel: Linux 5.10.0-13-amd64 (SMP w/56 CPU threads)
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)
LSM: AppArmor: enabled

Versions of packages dput-ng depends on:
ii  python3   3.9.2-3
ii  python3-dput  1.33

dput-ng recommends no packages.

Versions of packages dput-ng suggests:
pn  dput-ng-doc  
pn  python3-twitter  

-- no debconf information

Bug#1014762: dput-ng: Handling of .changes files for rm is unclear

[Mark Brown]

Package: dput-ng
Version: 1.33
Severity: normal

The documentation for the rm option gives examples like

dcut rm -f DELAYED/X-day/foobar.deb

which indicate that dcut rm takes a list of files on the command line
and will assemble a commands file for itself.  For most files this seems
to work fine however if a .changes file specified then dcut appears to
try to read the .changes file:

| $ dcut rm --searchdirs -f zlib_1.2.12.dfsg-0.1_source.changes
| Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/)
| [Errno 2] No such file or directory: 'zlib_1.2.12.dfsg-0.1_source.changes'

rather than trying to delete the .changes file.

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

Kernel: Linux 5.10.0-13-amd64 (SMP w/56 CPU threads)
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)
LSM: AppArmor: enabled

Versions of packages dput-ng depends on:
ii  python3   3.9.2-3
ii  python3-dput  1.33

dput-ng recommends no packages.

Versions of packages dput-ng suggests:
pn  dput-ng-doc  
pn  python3-twitter  

-- no debconf information

Bug#1012674: NMU: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)

[Mark Brown]

On Mon, Jul 11, 2022 at 06:54:13PM +0200, Bastian Germann wrote:
> Am 11.07.22 um 18:40 schrieb Mark Brown:
> > On Mon, Jul 11, 2022 at 06:16:31PM +0200, Bastian Germann wrote:

> > > I have uploaded zlib 1.2.12.dfsg-0.1 with the changes attached to 
> > > DELAYED/3.

> > Why?  Please drop this.

> Okay. When are you going to address this bug then?
> It has been a month not reacting to the RC bug.
> I think this is not acceptable for a key package such as zlib.

I'm not sure what there is to react to here other than doing an upload;
it's a packaging thing more than something causing active breakage for
users and we're nowhere near to doing a release yet so there didn't seem
a huge sense of urgency here so I'd been going to roll it into packaging
the new upstream release.  The bug gives the air of being from an audit
and in those cases you do have to balance keeping people up to date with
creating noise for submitters and there's been no followup requests for
status or anything.

I have been hoping that we're going to get another upstream release
which rolls in some of the fixes for the string of problems that people
have been having with the security fix release that was recently done
though that is looking depressingly unlikely and so I need to figure out
what needs backporting.  Given the release schedule startng to kick off
at the beginning of next year it'll be some time this year, I'd guess
some time this quarter.

In any case this upload isn't a targetted fix for the individual issue,
it's got a whole bunch of other unrelated changes including a new
upstream release which are clearly out of scope.  Like I say I have
substantial concerns about the new upstream release so that having been
rolled in is especially worrying.


signature.asc
Description: PGP signature

Bug#1014761: gopls: Use specific version for gopls package

[Shengjing Zhu]

Control: tag -1 wontfix

On Tue, Jul 12, 2022 at 1:03 AM Laurent Cheylus  wrote:
>
> Package: gopls
> Version: 1:0.1.11+ds-2
> Severity: normal
>
> Dear Maintainer,
>
> I'm using gopls package version 0.1.11+ds-2 as Go Language Server for my Go
> projects. This package is built from sources of golang-golang-x-tools package.
>
> The gopls version for Debian package (here 0.1.11) came from these sources but
> on the original GitHub repository, these both packages have different 
> versions :
>
> - one for golang/tools (used as version for golang-golang-x-tools Debian 
> package)
> - one for gopls
>
> See https://github.com/golang/tools/tags => currently, gopls version is 0.9.0.
>
> $ go list -m golang.org/x/tools@latest
> golang.org/x/tools v0.1.11
>
> $ go list -m golang.org/x/tools/gopls@latest
> golang.org/x/tools/gopls v0.9.0
>
> I built a local gopls version from Git sources for tag 0.9.0 :
>
> $ ./gopls version
> golang.org/x/tools/gopls v0.9.0
> golang.org/x/tools/gopls@(devel)
>
>
> Please, could you modify the Debian build scripts to use the correct version 
> for
> gopls package ? => build of package gopls_0.9.0

Unfortunately, no.

We build gopls and other tools from one source, so they have the same version.
Upstream's multi tag system on one source repository model really
doesn't fit for the Debian package.

-- 
Shengjing Zhu

Bug#1014684: FTBFS with fmtlib 9.0.0

[Dave Steele]

Control: forwarded -1 https://github.com/cryfs/cryfs/issues/432

Bug#1014684: FTBFS with fmtlib 9.0.0

[Dave Steele]

Control: -1 forwarded https://github.com/cryfs/cryfs/issues/432
Thanks

On Sun, Jul 10, 2022 at 5:33 AM Shengjing Zhu  wrote:
> I have uploaded fmtlib 9.0.0 to experimental. During rebuild the reverse
> dependencies, your package FTBFS.
>

Bug#990428: bonding now completely broken

[Dirk Jost]

Hiya,

since roughly last week bonding is completely broken for me, whatever way I’m 
using it. Neither via the slave or the master option it works now.
Is there any new synthax, we are supposed to use?

Cheers,
Dirk.

Gesendet von Mail für Windows

Bug#1014761: gopls: Use specific version for gopls package

[Laurent Cheylus]

Package: gopls
Version: 1:0.1.11+ds-2
Severity: normal

Dear Maintainer,

I'm using gopls package version 0.1.11+ds-2 as Go Language Server for my Go
projects. This package is built from sources of golang-golang-x-tools package.

The gopls version for Debian package (here 0.1.11) came from these sources but
on the original GitHub repository, these both packages have different versions :

- one for golang/tools (used as version for golang-golang-x-tools Debian 
package)
- one for gopls

See https://github.com/golang/tools/tags => currently, gopls version is 0.9.0.

$ go list -m golang.org/x/tools@latest
golang.org/x/tools v0.1.11

$ go list -m golang.org/x/tools/gopls@latest
golang.org/x/tools/gopls v0.9.0

I built a local gopls version from Git sources for tag 0.9.0 :

$ ./gopls version
golang.org/x/tools/gopls v0.9.0
golang.org/x/tools/gopls@(devel)


Please, could you modify the Debian build scripts to use the correct version for
gopls package ? => build of package gopls_0.9.0


Thanks for your work for Debian Go packaging, Laurent


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

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

Versions of packages gopls depends on:
ii  libc6  2.33-7

gopls recommends no packages.

gopls suggests no packages.

-- no debconf information

Bug#1014760: lirc: zotac remote control not working properly

[Sebastian Kemper]

Package: lirc
Version: 0.10.1-6.3
Severity: normal
Tags: patch
X-Debbugs-Cc: sebastian...@gmx.net

Dear Maintainer,

Can you kindly include the patch in [1] in the lirc package? It makes
the Zotac remote control work properly. Without the patch the key
entries via the remote are very sluggish and accompanied by the
following messages in syslog:

May 18 20:29:39 xbmc lircd-0.10.1[1036]: Info: zotac initializing 
'/dev/usb/hiddev0'
May 18 20:29:39 xbmc lircd[1036]: lircd-0.10.1[1036]: Error: (zotac_repeat) too 
many repetitions
May 18 20:29:39 xbmc lircd-0.10.1[1036]: Error: (zotac_repeat) too many 
repetitions

I followed the Howto in [2] to add this one-line change to the lirc
package (using quilt) and since I installed this updated deb package my
remote behaves nicely.

Thanks for your consideration!

[1] 
https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/sysutils/lirc/patches/lirc-0001-fix-zotac-poll.patch
[2] https://wiki.debian.org/BuildingTutorial

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (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 lirc depends on:
ii  libasound2   1.2.4-1.1
ii  libc62.31-13+deb11u3
ii  libftdi1-2   1.5-5+b1
ii  libgcc-s110.2.1-6
ii  liblirc-client0  0.10.1-6.3
ii  liblirc0 0.10.1-6.3
ii  libportaudio219.6.0-1.1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-7
ii  libusb-0.1-4 2:0.1.12-32
ii  libusb-1.0-0 2:1.0.24-3
ii  lsb-base 11.1.0
ii  python3  3.9.2-3

Versions of packages lirc recommends:
ii  gir1.2-vte-2.91  0.62.3-1
ii  python3-gi   3.38.0-2
ii  python3-yaml 5.3.1-5
ii  systemd  247.3-7

Versions of packages lirc suggests:
pn  ir-keytable  
pn  lirc-compat-remotes  
pn  lirc-doc 
pn  lirc-drv-irman   
pn  lirc-x   
pn  setserial

-- Configuration Files:
/etc/lirc/irexec.lircrc changed [not included]
/etc/lirc/lirc_options.conf changed [not included]
/etc/lirc/lircd.conf.d/devinput.lircd.conf [Errno 2] No such file or directory: 
'/etc/lirc/lircd.conf.d/devinput.lircd.conf'

-- no debconf information
>From 79e2494e4880d0446bf837c8bbca0b01baac4ed4 Mon Sep 17 00:00:00 2001
From: Matthias Reichl 
Date: Wed, 8 Apr 2020 11:27:11 +0200
Subject: [PATCH] plugins/zotac: fix poll timeout

poll requires a negative timeout value for infinite waits.
See https://sourceforge.net/p/lirc/tickets/327/

Signed-off-by: Matthias Reichl 
---
 plugins/zotac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/plugins/zotac.c b/plugins/zotac.c
index ac528c67..4a66acf5 100644
--- a/plugins/zotac.c
+++ b/plugins/zotac.c
@@ -352,7 +352,7 @@ static void* zotac_repeat(void* arg)
if (pressed)
sel = curl_poll(&pfd, 1, delay_ms);
else
-   sel = curl_poll(&pfd, 1, 0);
+   sel = curl_poll(&pfd, 1, -1);
switch (sel) {
case 1:
// Data ready in device's file
-- 
2.20.1

Bug#1012674: NMU: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)

[Bastian Germann]

Am 11.07.22 um 18:40 schrieb Mark Brown:

On Mon, Jul 11, 2022 at 06:16:31PM +0200, Bastian Germann wrote:


I have uploaded zlib 1.2.12.dfsg-0.1 with the changes attached to DELAYED/3.


Why?  Please drop this.


Okay. When are you going to address this bug then?
It has been a month not reacting to the RC bug.
I think this is not acceptable for a key package such as zlib.

Bug#1012674: NMU: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)

[Mark Brown]

On Mon, Jul 11, 2022 at 06:16:31PM +0200, Bastian Germann wrote:

> I have uploaded zlib 1.2.12.dfsg-0.1 with the changes attached to DELAYED/3.

Why?  Please drop this.  


signature.asc
Description: PGP signature

Bug#1014759: libgd-dev: Missing dependency on libwebp-dev?

[gregor herrmann]

Package: libgd-dev
Version: 2.3.3-3
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

libgd-perl currently FTBFS with:

   dh_auto_configure
/usr/bin/perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 
-ffile-prefix-map=/build/libgd-perl-2.76=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
"LD=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/build/libgd-perl-2.76=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
-Wl,-z,now"
Package libwebp was not found in the pkg-config search path.
Perhaps you should add the directory containing `libwebp.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libwebp', required by 'gdlib', not found
 at Makefile.PL line 530.
*** can not find package gdlib
*** check that it is properly installed and available in PKG_CONFIG_PATH
 at Makefile.PL line 530.
dh_auto_configure: error: /usr/bin/perl Makefile.PL INSTALLDIRS=vendor 
"OPTIMIZE=-g -O2 -ffile-prefix-map=/build/libgd-perl-2.76=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 
-ffile-prefix-map=/build/libgd-perl-2.76=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,-z,relro -Wl,-z,now" returned exit code 1
make: *** [debian/rules:9: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


This looks like a missing dependency on libwebp-dev in libgd-dev?

Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmLMU0dfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qga1nxAAk/qMHxSQyfA2hcJapgq7SkSBkaHKDeWUD97kmy5Rtl0F/PuDHq0vZDMl
8BAiWzUEAOeingb3+BobJgWJmyAmGJltHND5jmTP0cI9tptgSO4UAeTNDXI29Oxc
L6g2UXTdkMGSLL9cDGxrfqukgWKRZD9Bx1zuAUNgOJ4Y7BhTE1rWUQ5BIM601qHD
sZJh0+SfmiiAEX0fsfqA06jk5rGQ9I0CXU8sM36xCfPTKNRYCz6pDiS5Qkgtq7ez
qz7BCyFDyn6mu6Qg1XsCLboaEu8/DfSM/Ky5p38ateGLhBHHL7nk6pueYsPobzSm
Icb3M8CfsNLQ+iAw76iqDMKfMGJ0Pgn5jDPgVi+9iVKI+Sxxlt/zYSGAMrCVwjyf
OKxQip5ks624LzvSUhjRGDeE+AVvw7IJr2AwrV//G1u+F9/tqQrI/lqlQsOzE6Fg
BQuh9a3Xukdby8rrULo0DKhcWmaVglZtTh3LXha+9IJ3GbJ1VUrGY5M47BCvp4sB
GWyVCPXtCceN4lP9CfsHn9CUrb8BcDub2vKiHMThfiwMnS4x7XRYR3UC2+jEXd7X
xXBv631wtQ5xE9ltoXu1Rugi1NbBl1BNrrmi1dXf2jXqXu67OF6lzFEpJdpYlML8
6fBWp9L0PfZ7ZIFKAqfnhnmFPwFsVXxyhDQIY0Lg1JbJ9AnyN5A=
=O34F
-END PGP SIGNATURE-

Bug#990662: nouveau 0000:01:00.0: firmware: failed to load nouveau/nvd9_fuc084 (-2)

[Mathieu Malaterre]

Dear Debian NVIDIA Maintainers,

Is there any interest in maintaining a nvidia-firmware package within
Debian NVIDIA group maintenance ? It seems some of the nvidia firmware
blob cannot be maintained within firmware-misc-nonfree:

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990662#12

Since the nvidia* package do the heavy lifting of downloading locally
binary, it would make sense to add yet-another package for firmware
related within the group.

Thanks for comments,

-M

Bug#1014758: steam fails to install on debian sid/unstable due to to borken dependencies

[Nils Jacobs]

Package: steam
Version: 1:1.0.0.74-1
Severity: important
X-Debbugs-Cc: oj002...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
   just running apt install steam
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   I just tried to install steam
   * What was the outcome of this action?
   apt fails with the following dependency issue:
   $ sudo apt install steam
   Paketlisten werden gelesen… Fertig
   Abhängigkeitsbaum wird aufgebaut… Fertig
   Statusinformationen werden eingelesen… Fertig
   Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
   Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
   Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
   nicht erstellt wurden oder Incoming noch nicht verlassen haben.
   Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

   Die folgenden Pakete haben unerfüllte Abhängigkeiten:
   libgl1-mesa-dri:i386 : Hängt ab von: libllvm14:i386 soll aber nicht 
installiert werden
   E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene 
defekte Pakete.

   somewhat english summary: libgl1-mesa-dri:i386 depends on libllvm14:i386 but 
should not be installed 
   * What outcome did you expect instead?
   a successful installation of steam

   another way to install steam that aptitude provides:
   16) libllvm14 [1:14.0.6-1 (now, unstable) -> 1:14.0.5-1 (testing)]
   so really looks like a dependency issue with llm14
*** End of the template - remove these template lines ***


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

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

Versions of packages steam depends on:
pn  curl   
ii  debconf [debconf-2.0]  1.5.79
ii  file   1:5.41-4
ii  libc6  2.33-8
ii  libgcc-s1 [libgcc1]12.1.0-5
ii  libgl1 1.4.0-1
ii  libgl1-mesa-dri22.1.3-1
ii  libgpg-error0  1.45-2
ii  libstdc++6 12.1.0-5
ii  libudev1   251.2-8
ii  libx11-6   2:1.7.5-1
ii  libxcb-dri3-0  1.14-3
ii  libxcb11.14-3
ii  libxi6 2:1.8-1
ii  libxinerama1   2:1.1.4-3
ii  xz-utils   5.2.5-2.1

Versions of packages steam recommends:
ii  bubblewrap   0.6.2-1
ii  ca-certificates  20211016
ii  fontconfig   2.13.1-4.4
ii  fonts-liberation 1:1.07.4-11
ii  i965-va-driver [va-driver]   2.4.1+dfsg1-1
ii  intel-media-va-driver [va-driver]22.4.3+dfsg1-1
ii  konsole [x-terminal-emulator]4:22.04.1-1
ii  libasound2-plugins   1.2.7.1-1
ii  libegl1  1.4.0-1
ii  libgbm1  22.1.3-1
ii  libsdl2-2.0-02.0.22+dfsg-6
ii  libva2   2.15.0-1
ii  libxss1  1:1.2.3-1
ii  mesa-va-drivers [va-driver]  22.1.3-1
ii  mesa-vulkan-drivers  22.1.3-1
pn  steam-devices
ii  va-driver-all2.15.0-1
ii  xdg-desktop-portal   1.14.4-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.0-1
ii  xdg-utils1.1.3-4.1
ii  xterm [x-terminal-emulator]  372-1
pn  zenity   

Versions of packages steam suggests:
pn  nvidia-driver-libs  
pn  nvidia-vulkan-icd   
ii  pipewire0.3.54-2

Bug#990662: Steps

[Mathieu Malaterre]

Local steps for me were:

% wget 
https://raw.githubusercontent.com/envytools/firmware/master/extract_firmware.py
% wget 
https://download.nvidia.com/XFree86/Linux-x86_64/340.108/NVIDIA-Linux-x86_64-340.108.run
% sh NVIDIA-Linux-x86_64-340.108.run --extract-only
% python3 extract_firmware.py
% sudo mkdir /lib/firmware/nouveau
% sudo cp nvd9_fuc084 /lib/firmware/nouveau

Bug#1014729: glibc 2.34 breaks wcc autopkgtest on amd64: open: Invalid argument

[Aurelien Jarno]

On 2022-07-11 10:06, Michael Hudson-Doyle wrote:
> It looks like a no-change rebuild fixed this in Ubuntu fwiw.

Thanks, I confirm that in Debian too. Do you have an idea why? It could
be a missing or too loose dependency.

> On Mon, 11 Jul 2022 at 09:54, Aurelien Jarno  wrote:
> 
> > Source: glibc, wcc
> > Control: found -1 glibc/2.34-0experimental4
> > Control: found -1 wcc/0.0.2+dfsg-4.1
> > Severity: important
> > Tags: experimental
> >
> > Dear maintainers,
> >
> > The autopkgtest of wcc fails in sid on amd64 when that autopkgtest is
> > run with the binary packages of glibc from experimental. It passes when
> > run with only packages from sid. In tabular form:
> >
> >passfail
> > glibc  from sid2.34-0experimental4
> > wccfrom sid0.0.2+dfsg-4.1
> > all others from sidfrom sid
> >
> > I copied some of the output at the bottom of this report.
> >
> > Currently this regression is blocking the transition to glibc 2.34. Due
> > to the nature of this issue, I filed this bug report against both
> > packages. Can you please investigate the situation and reassign the bug
> > to the right package?
> >
> > More information about this bug and the reason for filing it can be found
> > on
> > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> >
> > Regards
> > Aurelien
> >
> > https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wcc/23455379/log.gz
> >
> >
> > autopkgtest [14:35:47]: test wsh-libs.wsh: [---
> > open: Invalid argument
> >
> > [1;32m[SIGSEGV] Read00700101[1;34m(address not mapped to
> > object)
> > [0mbash: line 1:  2061 Segmentation fault
> > /tmp/autopkgtest-lxc.yfun0_rb/downtmp/build.xHo/src/debian/tests/wsh-libs.wsh
> > 2> >(tee -a /tmp/autopkgtest-lxc.yfun0_rb/downtmp/wsh-libs.wsh-stderr >&2)
> > > >(tee -a /tmp/autopkgtest-lxc.yfun0_rb/downtmp/wsh-libs.wsh-stdout)
> > autopkgtest [14:35:47]: test wsh-libs.wsh: ---]
> > autopkgtest [14:35:47]: test wsh-libs.wsh:  - - - - - - - - - - results -
> > - - - - - - - - -
> > wsh-libs.wsh FAIL non-zero exit status 139
> >

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

Bug#1014735: rpcsvc-proto: The /usr/include/rpc/* files is not included

[Aurelien Jarno]

control: tag -1 + moreinfo

Hi,

On 2022-07-11 02:46, Magnus Danielson wrote:
> Package: rpcsvc-proto
> Version: 1.4.2-4
> Severity: grave
> Justification: renders package unusable

rpcsvc-proto is used to build many packages in Debian, so I doubt it is
completely unusable.

> Dear Maintainer,
> 
> Template answers first, for your convenience.
> 
>    * What led up to the situation?
> 
> Rebuilding an application using rpcgen.
> 
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Run rpcgen, then tried to compile the produced files.
> 
>    * What was the outcome of this action?
> 
> Any of the /usr/include/rpc/* header-files referenced such as
> #include 
> etc. fail to include, all the related definitions missing causes large
> amount
> of compile errors.

Could you please give me more details about the issue? Ideally copy and
paste the error message.

My guess is that your problem is not related to rpcsvc-proto itself
which just provides rpcgen and related header files, but with the
removal of the SunRPC implementation for glibc. You need to switch to
the TI RPC implementation instead (using the libtirpc-dev package).

>    * What outcome did you expect instead?
> 
> Nice compile as headerfiles is found.
> 
> This is most likely a consequence of repackaging the rpc-part. Looking back
> at
> the stable version of libc6 the header files is there in libc6-dev, but for
> testing and unstable they are not. I expect that using these this would
> work.
> If the headerfiles is in another package, dependence on that should be in
> place.

The files that are removed from libc6-dev are the ones related to the
removed SunRPC implementation. libc6-dev (indirectly) depends on
libtirpc3-dev so the replacement header files should be available on
your system. That said it is not a one to one replacement, so you need
to use pkgconfig to get the compile and link flags.

> Package-testing should actually include a dummy-application that generates
> through rpcgen and then compiles it successfully. Then this error would be
> caught. Another approach would be to check that the same header files gets
> installed from previous packaging and new packaging. Both methods would be
> recommended to create fail-safes and quick turn-around for package
> maintainers.

Don't hesitate to provide a patch doing that.

Regards
Aurelien

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

Bug#1014741: libgd-perl: GD and GD2 image formats are disabled in libgd3 package

[gregor herrmann]

Control: tag -1 - moreinfo + confirmed ftbfs
Control: severity -1 serious

On Mon, 11 Jul 2022 11:02:10 +0200, gregor herrmann wrote:

> I have to admit that I'm a bit confused: It is filed against libgd-perl
> and you mention a Graph.pm file -- but such a file doesn't exist in
> this package.
> 
> Could you please clarify which exact error you are seein in which
> exact file (and maybe in which exact package)?

Thanks for reassigning to libgd-graph-perl!

I also note that the tests (which use the samples (which call the export_format
function (which has line 515 of Graph.pm))) also fail by now:

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

#   Failed test at t/samples.t line 21.
# died: gdImageGdPtr error at 
/build/libgd-graph-perl-1.54~ds/blib/lib/GD/Graph.pm line 515.
# Compilation failed in require at t/samples.t line 17.

# 

Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon

[duck]

Quack,

On 2022-07-04 14:11, Johannes Schauer Marin Rodrigues wrote:

how is the packaging going? Are you still intending to package it? Is 
there

already a git repository on salsa?


Sorry, I've been delayed but I still intend to get this in :-).

Regards.
\_o<

--
Marc Dequènes

Bug#1014453: [Pkg-samba-maint] Bug#1014453: samba: error 22 when attempting to mount a share from linux-5.18.8 or newer client

[Julian Sikorski]

Am 11.07.22 um 17:31 schrieb Michael Tokarev:

06.07.2022 14:12, Julian Sikorski wrote:

Package: samba
Version: 2:4.13.13+dfsg-1~deb11u3
Severity: important
Tags: patch
X-Debbugs-Cc: beleg...@gmail.com

Dear Maintainer,

After updating my client to kernel 5.18.8, I was no longer able to 
mount samba shares hosted by my debian install. I was getting mount 
error 22.
Upon discussing the problem on linux-cifs [1], it was discovered that 
the issue can be fixed by a patch available in samba versions 4.15 and 
later [2]. I can confirm that adding this patch to the debian 4.13 
package fixes the issue too. Please add this patch to the package.


[1] 
https://lore.kernel.org/linux-cifs/8ccad303-7489-d90a-2255-ca36b7253...@gmail.com/T/#t 

[2] 
https://git.samba.org/?p=samba.git;a=commitdiff;h=147dd9d58a429695a3b6c6e45c8b0eaafc67908a 



As far as I can see, this fix is included in samba 4.16 which is 
currently in

testing and in bullseye-backports.  Kernel 5.18 is not in bullseye.

I think you can use samba from bpo to fix this one. I don't have plans
to make another 4.13 in bullseye for now.  And I don't really know what
do do with this bugreport which can already be closed since it is fixed
in testing...

Thanks,

/mjt
Thanks for responding. As I am not familiar with Debian's update 
policies, please excuse if these are obvious questions.
Are there plans to get samba 4.16 into bullseye-updates? Or will the fix 
only be included in bookworm? While kernel 5.18 is not in bullseye yet, 
we are specifically talking about client-server situation, meaning that 
the client is not unlikely to be running to be a different OS than the 
server. For me it is armbian on the server and fedora on the client. The 
patch exposing the bug only got into 5.18 stable tree, not to the older 
ones, so the issue is likely limited in scope at the moment. It might 
become more prevalent as more clients upgrade the kernel.


Best regards,
Julian

Bug#1014730: liburi-perl: Breaks apt-cacher with "Can't locate Regexp/IPv6.pm" error

[gregor herrmann]

Thanks for your investigations and mails, that makes it a bit clearer
for me :)

Still, I'm not sure how to proceed:


On Mon, 11 Jul 2022 11:11:16 +0100, Niko Tyni wrote:

> apt-cacher is using $SIG{__DIE__}, which triggers even in eval blocks,
> and doing an exit(1) from there.
[…]
> I'd say this is not a bug in liburi-perl.


On Mon, 11 Jul 2022 12:15:12 +0200, Robert Luberda wrote:

> Yes, but it looks like apt-cacher seems to set its own SIG{__DIE__} handler.
[…]
> I've just checked that adding
>   local $SIG{__DIE__};
> here (i.e. before the require line) fixes the issue with apt-cacher for me.

Thanks!
 
> > But may as well move libregexp-ipv6-perl to Depends, I guess.
> Probably yes, but IMHO it would be better to restore default __DIE__
> handler.

Hm, ok …


So we have:
- do nothing
- patch URI to restart the default signal handler in the eval
- (reassign? and) do something in apt-cacher


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#1014453: [Pkg-samba-maint] Bug#1014453: samba: error 22 when attempting to mount a share from linux-5.18.8 or newer client

[Michael Tokarev]

06.07.2022 14:12, Julian Sikorski wrote:

Package: samba
Version: 2:4.13.13+dfsg-1~deb11u3
Severity: important
Tags: patch
X-Debbugs-Cc: beleg...@gmail.com

Dear Maintainer,

After updating my client to kernel 5.18.8, I was no longer able to mount samba 
shares hosted by my debian install. I was getting mount error 22.
Upon discussing the problem on linux-cifs [1], it was discovered that the issue 
can be fixed by a patch available in samba versions 4.15 and later [2]. I can 
confirm that adding this patch to the debian 4.13 package fixes the issue too. 
Please add this patch to the package.

[1] 
https://lore.kernel.org/linux-cifs/8ccad303-7489-d90a-2255-ca36b7253...@gmail.com/T/#t
[2] 
https://git.samba.org/?p=samba.git;a=commitdiff;h=147dd9d58a429695a3b6c6e45c8b0eaafc67908a


As far as I can see, this fix is included in samba 4.16 which is currently in
testing and in bullseye-backports.  Kernel 5.18 is not in bullseye.

I think you can use samba from bpo to fix this one. I don't have plans
to make another 4.13 in bullseye for now.  And I don't really know what
do do with this bugreport which can already be closed since it is fixed
in testing...

Thanks,

/mjt

Bug#863325: Processed: ITA: pngnq -- tool for optimizing PNG (Portable Network Graphics) images

[肖盛文]

Hi Andreas,

    Is the bug #863325 forget to close?

I just fint that pngnq is team maintained by Debian PhotoTools Team 
 and you are Uploaders.



Thanks!

xiao sheng wen

在 2022/7/11 22:33, Debian Bug Tracking System 写道:

Processing control commands:


owner -1 !

Bug #863325 [wnpp] O: pngnq -- tool for optimizing PNG (Portable Network 
Graphics) images
Owner recorded as xiao sheng wen(肖盛文).

retitle -1 ITA: pngnq -- tool for optimizing PNG (Portable

Bug #863325 [wnpp] O: pngnq -- tool for optimizing PNG (Portable Network 
Graphics) images
Changed Bug title to 'ITA: pngnq -- tool for optimizing PNG (Portable' from 'O: 
pngnq -- tool for optimizing PNG (Portable Network Graphics) images'.


--
肖盛文 xiao sheng wen
https://www.atzlinux.com  《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page:https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa:https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014756: ITP: libcrypt-openssl-guess-perl -- module for guessing OpenSSL include path

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcrypt-openssl-guess-perl
  Version : 0.15
  Upstream Author : Takumi Akiyama 
* URL : https://metacpan.org/release/Crypt-OpenSSL-Guess
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for guessing OpenSSL include path

Crypt::OpenSSL::Guess provides helpers to guess OpenSSL include path on any
platform.

Crypt::OpenSSL::* modules should use it in their Makefile.PL.

In Debian Crypt::OpenSSL::Guess is packaged as some CPAN distributions
require it at build time.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#889635: debhelper: dh_installsystemd - please support templated unit files

[Victor Westerhuis]

Package: debhelper
Version: 13.8
Followup-For: Bug #889635

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I second the request to support templated unit files. My MR for 
init-system-helpers to support enabling template units with a default instance
was accepted two days ago [0].

There's two possible action dh_installsystemd could take for a template unit 
with a default instance: 1. Only run the enable, purge and unmask actions on 
postinst, because these are actions that don't require an instance. 2. Do the 
actions in option 1, but additionally parse the DefaultInstance line and run 
start, stop, and restart actions as well.

Option 1 is also available for template units without instance, so that has 
broader applicability than just template units with a default instance. If 
there's interest, I'd be willing to try to code an implementation of either or 
both options.

Regards,

Victor Westerhuis

[0]: https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/20

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmLMNVATHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+w89D/4ntsR/5YpIWZz7vaHUUn6aCimVT0/2
4TvPKieEMXixiJNMbHSs0y6l4ssezWMZbbGxQoH+Xiua0zZDij7drGuZgXSmAyjB
Aoo9OHnWfikvc5NzVjiY8po/xW48r2C0ALpgxx8kG5wdJTR0frtj7zx9c3iuaois
hfMuGNxF+lBw9jZ9CFNC2rPLrA5cQvTsdWknhfkz1UsAcOoblFOAv/3g+GNjSZLb
JUwCdCWrmlozUAB0hSV3mK2scGlf57ndXwr/NbNIXk1yNpfOmK8v5Y2QBaFzn8z6
GbpBc0ewHPVObjPlRLizJxt+DBdjga7ZtoDE5i9EJXayr/eA6Z7MD+JRYd5STup5
64zoYPKaujt97cLnLimaJv8xaTLGMh7XBFx5k7XkHtUCm5yqDK3hJZKJL5FTTrkI
GEjX+vT7LKe4CmsNkGFrooAvmRb1DR2fruXB0D6OSl4MjxqLYMaQB7puAV1sQA2L
xv+ie5RiqTEfHzRNI/If43nb+y/0jjrbsdZ6KJ4PlmppGfSq3rW0r9ErXpp9/RNN
CcAOfMw+f8rvosGNXehgy58SljDN486D+JA6H44Gvg5Qp/POr64pg4Tsek1rxonU
TtEF7K4DMQT5BC3oHRWp6u5Uy698MeR1njSKmel9cLob8e14vppEXw6OO3hplcw9
NbyDDW/HQlGFEQ==
=6ak0
-END PGP SIGNATURE-

Bug#1013313: Acknowledgement (libisoburn: Add autopkgtest)

[Alexandre Ghiti]

Sorry I'm really late here: I really appreciate your work here guys, thank
you very much, I'll sync the debian package in Ubuntu whenever available.

Thank you again,

Alex

On Tue, Jun 21, 2022 at 2:15 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1013313:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013313.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Libburnia packagers 
>
> If you wish to submit further information on this problem, please
> send it to 1013...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 1013313: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013313
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#1014400: libisofs: Add symbol file

[Alexandre Ghiti]

Hey Thomas,

Thanks for the quick answer (you may even be too fast for me :)).

On Tue, Jul 5, 2022 at 4:37 PM Thomas Schmitt  wrote:

> Hi,
>
> do i get it right that the format is specified by
>   https://wiki.debian.org/Projects/ImprovedDpkgShlibdeps
> ?
>
> If so, then the goal of having the file
>
>   "In many cases, the dependency generated is too strict as the
>application doesn't necessarily use the newly-added symbols which
>justify the dependency bump in the shlibs file."
>
> collides with the upstream version check of libisoburn towards libisofs.
> libisoburn will not work with a libisofs version that is older than
> seen at compile time.
> The minimum version at compile time is defined in libisoburn.h (i.e.
> part of the API):
>
>   /** The minimum version of libisofs to be used with this version of
> libisoburn
>   at compile time.
>   @since 0.1.0
>   */
>   #define isoburn_libisofs_req_major  1
>   #define isoburn_libisofs_req_minor  5
>   #define isoburn_libisofs_req_micro  4
>
> So if the Debian packaging software decides on its own that libisofs-1.5.2
> is enough at package build time, then compilation will fail.
>

In an ideal world, the symbols should be backward compatible and then the
'symbols' mechanism should be enough: I'm curious, why would it be
different here?


> If the package manager decides that libisofs-1.5.2 is good enough at
> run time, then the start-up of libisoburn will fail.
> Both failures are intentional and make function isoburn_initialize()
> as ugly as paranoid.
>
> https://sources.debian.org/src/libisoburn/1.5.4-2/libisoburn/burn_wrap.c/#L74
>
>
In general i don't think it is worthwhile to offer old versions of
> libisofs to programs which get installed on a system where a newer
> version is available.
>
>
Ok I see, and in addition, the 3 libraries (libburn, libisofs, libisoburn)
belong to the same project so that would be weird if they are not updated
at the same time.


> -
>
> The .symbols file looks like maintainance effort, if it shall express
> more than the existing .ver file (i.e. the list of ABI symbols of
> the current version).
>

And given that it is additional maintenance, I'd agree with you that it may
not be necessary.


>
> Google is not overly helpful with search test ".symbols".
> Is that file format specific to Debian and its derivatives or does it
> play a role in more generic build facilities ?
>
>
I can't really say, let's wait for the package maintainer on this.


> The API description in libisofs.h contains information about the version
> where a symbol appeared first (IIRC starting with 0.6.2 of 2008). So it
> would be possible to create a more differenciated .symbols file than
> attributing any symbol to version 1.5.4.
>
> But if it is only to tell the Debian package build software that really,
> really 1.5.4 is the version to use, then i'd propose to generate the
> .symbols file freshly in the course of package generation.
>
> (Bystanding DDs please tell me where in ./debian this can be done.
> I would use a shell script that creates .symbols from .ver.
> In this case it would be nice if that script could learn the upstream
> version automatically, so that it has not to be changed with each version.
> Of course, some dh_ magic would be welcome too.)
>
>
> Have a nice day :)
>
> Thomas
>
>

Bug#863325: ITA: pngnq -- tool for optimizing PNG (Portable Network Graphics) images

[肖盛文]

control: owner -1 !
control: retitle -1 ITA: pngnq -- tool for optimizing PNG (Portable 
Network Graphics) images


--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014755: texlive-lang-czechslovak causes error with wordlflags with emblems

[Petr Nivnický]

Package: texlive-lang-czechslovak
Version: 2019.20200218-1


All flags with emblems (with worldflags package https://ctan.org/pkg/
worldflags) are not generated when Czech or Slovak babel are used. Other 
languages work. All flags without emblems work even with Czech or Slovak 
babel. So, I think this could be related to texlive-lang-czechslovak
package.

Testing document, error repeateble in Gummi, TeXworks and TeXstudio.

\documentclass{article}
\usepackage[english]{babel} % English works
%\usepackage[spanish]{babel} % Spanish works
%\usepackage[czech]{babel} % Czech does NOT work
%\usepackage[slovak]{babel} % Slovak does NOT work
\usepackage{worldflags}

\begin{document}
  \worldflag{SK}
\end{document}

Error:
/usr/share/texmf/tex/latex/worldflags/worldflag_SK.tex:10: Missing number,
treated as zero.



I use Linux Mint 20, 5.4.0-121-generic.





Regards, Petr

Bug#1011747: pyjwt: CVE-2022-29217 - Key confusion through non-blocklisted public key formats

[Daniele Tricoli]

Hello Neil,

On 26/05/2022 11:40, Neil Williams wrote:

Source: pyjwt
Version: 2.3.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for pyjwt.

CVE-2022-29217[0]:

[CUT]

Thanks for the report, I'm working on this.

Cheers,

--
Daniele Tricoli
https://mornie.org

Bug#801822: deb-systemd-helper does not support template units (e.g. foo@.service)

[Victor Westerhuis]

Control: tags -1 - patch

On Thu, 03 Feb 2022 16:44:28 +0100 Victor Westerhuis 
 wrote:

I've opened a merge request on Salsa with another possible fix.
It works for me locally, but I would like any feedback if I made a mistake 
somewhere.

I've attached the patch as an attachment and the MR is at 
https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/20.
The MR was merged, but I realise now that the original bug is about 
manipulating instances of template units, which is not what my patch 
addressed.


I've removed the patch tag from this bug report.

--
Victor Westerhuis 


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014754: linux-image-5.10.0-13-amd64: ptrace does not substitute SIGSTOP correctly

[Pavel Labath]

Package: src:linux
Version: 5.10.106-1
Severity: normal
X-Debbugs-Cc: pa...@labath.sk, mgorny@moritz.systems

Dear Maintainer,

Using PTRACE_CONT with a signal number should immediately deliver that
signal to the application. This is what happens whenever the
applications is stopped due to some signal other than SIGSTOP. It is
also what happens with SIGSTOPs on other linux distros I tried (this
includes a 5.10-based gentoo kernel), but for some reason, it does not
happen with the debian kernel. I assume this is due to some upstream
bug/quirk, which has since been fixed.

To reproduce, compile&run the attached program:
-
$ g++ repr-stop.cc
$ ./a.out
Unexpectedly stopped with User defined signal 1
a.out: repr-stop.cc:34: void parent(pid_t): Assertion `WIFEXITED(status)' 
failed.
Aborted
-

The expected behavior is for the program to terminate with exit code
zero and print the "hello from %x" message.


-- Package-specific info:
** Version:
Linux version 5.10.0-13-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.106-1 (2022-03-17)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-13-amd64 root=/dev/mapper/VOY-debian ro 
net.ifnames=0 quiet

** Not tainted

** Kernel log:
No relevant messages in kernel log.

** Model information
sys_vendor: HP
product_name: HP ProBook 450 G7
product_version: 
chassis_vendor: HP
chassis_version: 
bios_vendor: HP
bios_version: S71 Ver. 01.07.02
board_vendor: HP
board_name: 86A0
board_version: KBC Version 02.2F.00

** Loaded modules:
tun
ctr
ccm
dm_crypt
cmac
algif_hash
algif_skcipher
af_alg
bnep
btusb
btrtl
btbcm
btintel
bluetooth
uvcvideo
videobuf2_vmalloc
snd_soc_skl_hda_dsp
videobuf2_memops
snd_soc_hdac_hdmi
jitterentropy_rng
videobuf2_v4l2
videobuf2_common
drbg
videodev
ansi_cprng
ecdh_generic
mc
ecc
snd_hda_codec_hdmi
snd_hda_codec_realtek
snd_hda_codec_generic
snd_soc_dmic
snd_sof_pci
snd_sof_intel_byt
snd_sof_intel_ipc
snd_sof_intel_hda_common
snd_sof_xtensa_dsp
intel_pmc_core_pltdrv
intel_pmc_core
snd_sof
snd_sof_intel_hda
snd_soc_hdac_hda
snd_hda_ext_core
snd_soc_acpi_intel_match
snd_soc_acpi
ledtrig_audio
snd_hda_intel
joydev
snd_intel_dspcfg
soundwire_intel
soundwire_generic_allocation
snd_soc_core
snd_compress
x86_pkg_temp_thermal
soundwire_cadence
intel_powerclamp
coretemp
snd_hda_codec
kvm_intel
kvm
iwlmvm
iTCO_wdt
intel_pmc_bxt
hid_multitouch
iTCO_vendor_support
hp_wmi
mmc_block
watchdog
irqbypass
hid_generic
mei_hdcp
crc32_pclmul
intel_rapl_msr
sparse_keymap
wmi_bmof
ghash_clmulni_intel
rapl
intel_cstate
intel_uncore
mac80211
binfmt_misc
snd_hda_core
ahci
libarc4
snd_hwdep
libahci
soundwire_bus
xhci_pci
pcspkr
efi_pstore
libata
xhci_hcd
iwlwifi
snd_pcm
nls_ascii
r8169
i2c_i801
snd_timer
nls_cp437
i2c_smbus
snd
realtek
vfat
mdio_devres
soundcore
fat
cfg80211
libphy
scsi_mod
usbcore
sdhci_pci
mei_me
mei
cqhci
sdhci
processor_thermal_device
intel_lpss_pci
ucsi_acpi
typec_ucsi
i2c_hid
intel_lpss
intel_rapl_common
idma64
mmc_core
rfkill
usb_common
intel_pch_thermal
intel_soc_dts_iosf
tpm_crb
typec
hid
wmi
battery
int3403_thermal
int340x_thermal_zone
tpm_tis
tpm_tis_core
tpm
hp_accel
rng_core
lis3lv02d
acpi_pad
int3400_thermal
hp_wireless
ac
button
acpi_thermal_rel
parport_pc
ppdev
lp
parport
fuse
configfs
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
i915
dm_mod
i2c_algo_bit
drm_kms_helper
cec
crc32c_intel
drm
aesni_intel
nvme
nvme_core
glue_helper
libaes
crypto_simd
cryptd
evdev
t10_pi
crc_t10dif
serio_raw
crct10dif_generic
crct10dif_pclmul
crct10dif_common
video

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Comet Lake-U v1 4c Host 
Bridge/DRAM Controller [8086:9b61] (rev 0c)
Subsystem: Hewlett-Packard Company Comet Lake-U v1 4c Host Bridge/DRAM 
Controller [103c:86a0]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation CometLake-U GT2 
[UHD Graphics] [8086:9b41] (rev 02) (prog-if 00 [VGA controller])
DeviceName: Onboard IGD
Subsystem: Hewlett-Packard Company UHD Graphics [103c:86a0]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 0c)
Subsystem: Hewlett-Packard Company Xeon E3-1200 v5/E3-1500 v5/6th Gen 
Core Processor Thermal Subsystem [103c:86a0]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- 

Bug#1009741: mercurial: flaky autopkgtest which times out on amd64 regularly

[Julien Cristau]

On Mon, May 16, 2022 at 09:08:45PM +0200, Paul Gevers wrote:
> Hi Julien,
> 
> On 16-05-2022 14:10, Julien Cristau wrote:
> > Control: severity -1 normal
> > 
> > On Fri, Apr 15, 2022 at 10:36:54PM +0200, Paul Gevers wrote:
> > > I looked at the results of the autopkgtest of you package because it was
> > > showing up as a regression for the upload of python3-defaults. I noticed
> > > that the test regularly fails on several architectures. Most peculiarly on
> > > amd64, the latest version seems to pass on ci-worker13 (our most powerful
> > > host looking at number of cores, memory and disk space) and fails 
> > > (timeout)
> > > on the other amd64 hosts.

What are the specs of these hosts?  How long are tests allowed to take?

> > > Because the unstable-to-testing migration software now blocks on
> > > regressions in testing, flaky tests, i.e. tests that flip between
> > > passing and failing without changes to the list of installed packages,
> > > are causing people unrelated to your package to spend time on these
> > > tests.
> > > 
> > Which specific tests are you having issues with?
> 
> It seems not at all specific:
> 
> E.g.
> https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/21333636/log.gz
> ends with:
> test-encode.t
> test-encode.t ... # Test test-encode.t
> # Running sh "/tmp/hgtests.qsr01vxk/child797/test-encode.t.sh"
> # Timout reached for process 98896
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/21329273/log.gz
> ends with:
> test-share-bookmarks.t#vfs#normal
> test-share-bookmarks.t#vfs#normal ... # Test
> test-share-bookmarks.t#vfs#normal
> # Timout reached for process 77193
> # Running sh
> "/tmp/hgtests.f1fx8cv7/child370/test-share-bookmarks.t-vfs-normal.sh"
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/20890959/log.gz
> ends with:
> test-debugbackupbundle.t
> test-debugbackupbundle.t ... # Test test-debugbackupbundle.t
> # Running sh "/tmp/hgtests.d5oe121c/child855/test-debugbackupbundle.t.sh"
> # Timout reached for process 100461
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/20858105/log.gz
> ends with:
> test-status.t#dirstate-v1
> test-status.t#dirstate-v1 ... # Test test-status.t#dirstate-v1
> # Timout reached for process 56796
> # Running sh "/tmp/hgtests.p1egbody/child227/test-status.t-dirstate-v1.sh"
> 
AFAICT the above are expected messages, and not errors.  When
autopkgtest itself errors out with "ERROR: timed out on command ..." it
would probably be useful if it showed which processes were running at
the time it gave up so it's maybe a bit easier to tell what got stuck.

> https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/20816570/log.gz
> ends with:
> Failed test-hghave.t: output changed
> Failed test-hgrc.t: output changed
> Failed test-https.t: output changed
> Failed test-parseindex.t: output changed
> Failed test-patchbomb-tls.t: output changed
> Failed test-paths.t: output changed
> Failed test-run-tests.t: output changed
> # Ran 918 tests, 47 skipped, 7 failed.
> python hash seed: 1267217074
> # Timout reached for process 101372
> # Cleaning up HGTMP /tmp/hgtests.fo156zei
> make: *** [Makefile:140: tests] Error 1
> 
> https://ci.debian.net/data/autopkgtest/testing/arm64/m/mercurial/21443035/log.gz
> ends with
> Failed test-convert-bzr.t: output changed
> # Ran 918 tests, 47 skipped, 1 failed.
> python hash seed: 2382336912
> # Timout reached for process 101344
> # Cleaning up HGTMP /tmp/hgtests.a0d42699
> make: *** [Makefile:140: tests] Error 1

These two are actual test failures, not timeouts.  The first set were
fixed in 6.1.2-1; I'm not familiar with the test-convert-bzr.t failure,
could be a race condition in the test.  Either way, it's unrelated to
the "timeouts" issue.

Cheers,
Julien

Bug#1014648: digikam: Unable to display .heic correctly

[Steven Robbins]

On Monday, July 11, 2022 1:02:23 A.M. CDT you wrote:

> (The more problems I see related to major library upgrades in debian,
> the less convinced I am that only supporting a single (major) version
> for all libraries really is a good idea. Then I again I am not the one
> doing the work, so I am definitely not complaining, just thinking.)

100% agree.  The whole reason for the shared library naming scheme is to allow 
simultaneous installs.  I never understood the fetish for wholesale 
"transitions".

-Steve


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

Bug#1014752: ITP: libmodule-extract-version-perl -- module to extract a module version safely

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmodule-extract-version-perl
  Version : 1.115
  Upstream Author : brian d foy 
* URL : https://metacpan.org/release/Module-Extract-VERSION
* License : Artistic-2.0
  Programming Lang: Perl
  Description : module to extract a module version safely

The Module::Extract::VERSION module lets you pull out of module source code
the version number for the module. It assumes that there is only one $VERSION
in the file and the entire $VERSION statement is on the same line.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#1013096: Acknowledgement (linux-image-5.10.0-15-amd64: racoon reports AES missing)

[Buck Huppmann]

This can be closed (please).

As expected, as of upgrading to

linux-image-5.10.0-16-amd64 (= 5.10.127-1)

racoon/setkey are fine again (supposing, because of

> linux-signed-amd64 (5.10.127+1) bullseye; urgency=medium

>- Revert "net: af_key: add check for pfkey_broadcast in function
>  pfkey_process"

as noted in the changelog.gz)

Bug#1014751: libgpaste-2-common: missing Breaks: libgpaste-common

[Andreas Beckmann]

Package: libgpaste-2-common
Version: 42.1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install libgpaste-common/bullseye
  # (1)
  apt-get install libgpaste-2-common/bookworm
  apt-get remove libgpaste-2-common
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /usr/share/locale/*/LC_MESSAGES/GPaste.mo


This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

The libgpaste-2-common package has the following relationships with 
libgpaste-common:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  libgpaste-common

>From the attached log (scroll to the bottom...):

0m24.0s ERROR: FAIL: After purging files have disappeared:
  /usr/share/locale/de/LC_MESSAGES/GPaste.mo owned by: libgpaste-2-common
  /usr/share/locale/es/LC_MESSAGES/GPaste.mo owned by: libgpaste-2-common
  /usr/share/locale/fr/LC_MESSAGES/GPaste.mo owned by: libgpaste-2-common
  /usr/share/locale/ja/LC_MESSAGES/GPaste.mo owned by: libgpaste-2-common
  /usr/share/locale/nb_NO/LC_MESSAGES/GPaste.mo  owned by: libgpaste-2-common
  /usr/share/locale/nl_NL/LC_MESSAGES/GPaste.mo  owned by: libgpaste-2-common
  /usr/share/locale/pt_BR/LC_MESSAGES/GPaste.mo  owned by: libgpaste-2-common
  /usr/share/locale/sv/LC_MESSAGES/GPaste.mo owned by: libgpaste-2-common

0m24.0s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/libgpaste-common.list   not owned


cheers,

Andreas


libgpaste-common=3.38.5-1_libgpaste-2-common=42.1-3.log.gz
Description: application/gzip

Bug#1014750: xfce4-notes-plugin: fails to build twice in a row

[Andreas Beckmann]

Source: xfce4-notes-plugin
Version: 1.9.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

xfce4-notes-plugin/experimental fails to build twice in a row.
Cleaning after the successful first build seems to remove some sources
that cannot be regenerated.

Building the source package after the successful first build (and
subsequent debian/rules clean) reports:

 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building xfce4-notes-plugin using existing 
./xfce4-notes-plugin_1.9.0.orig.tar.bz2
dpkg-source: warning: ignoring deletion of file configure.ac, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file Makefile.in, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file missing, use --include-removal 
to override
dpkg-source: warning: ignoring deletion of file compile, use --include-removal 
to override
dpkg-source: warning: ignoring deletion of file config.h.in, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file configure, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file ltmain.sh, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file install-sh, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file aclocal.m4, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file depcomp, use --include-removal 
to override
dpkg-source: warning: ignoring deletion of file data/Makefile.in, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file data/pixmaps/Makefile.in, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file data/icons/Makefile.in, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file 
data/icons/scalable/Makefile.in, use --include-removal to override
dpkg-source: warning: ignoring deletion of file data/icons/32x32/Makefile.in, 
use --include-removal to override
dpkg-source: warning: ignoring deletion of file data/icons/24x24/Makefile.in, 
use --include-removal to override
dpkg-source: warning: ignoring deletion of file data/icons/22x22/Makefile.in, 
use --include-removal to override
dpkg-source: warning: ignoring deletion of file data/icons/16x16/Makefile.in, 
use --include-removal to override
dpkg-source: warning: ignoring deletion of file data/gtk-3.0/Makefile.in, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file src/Makefile.in, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file lib/icon-button.c, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file lib/Makefile.in, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file lib/hypertextview.c, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file lib/note.c, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file lib/theme-gtkcss.c, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file lib/window.c, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file lib/application.c, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file lib/theme.c, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file lib/window-monitor.c, use 
--include-removal to override
dpkg-source: warning: newly created empty file 'po/.intltool-merge-cache.lock' 
will not be represented in diff
dpkg-source: info: building xfce4-notes-plugin in 
xfce4-notes-plugin_1.9.0-1.debian.tar.xz
dpkg-source: info: building xfce4-notes-plugin in xfce4-notes-plugin_1.9.0-1.dsc

The deletion of configure.ac and lib/*.c looks very suspicious ...
A following debian/rules build is a no-op (no build system is
autodetected) and then dh_install fails due to an empty debian/tmp tree.

 debian/rules build
dh build
   dh_update_autotools_config
   dh_autoreconf
   create-stamp debian/debhelper-build-stamp
 fakeroot debian/rules binary
dh binary
   dh_testroot
   dh_prep
   debian/rules override_dh_install
make[1]: Entering directory '/build/xfce4-notes-plugin-1.9.0'
rm -rf debian/tmp/usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/*.la
dh_install
dh_install: warning: Cannot find (any matches for) "etc" (tried in ., 
debian/tmp)
...


Andreas


xfce4-notes-plugin_1.9.0-1_twice.log.gz
Description: application/gzip

Bug#1014749: Acknowledgement (openvswitch-test,python3-openvswitch: both ship /usr/lib/python3/dist-packages/ovstest/*.py)

[Andreas Beckmann]

openvswitch/experimental fails to clean after a successful build:

 debian/rules clean
py3versions: no X-Python3-Version in control file, using supported versions
dh clean
   debian/rules execute_before_dh_auto_clean
make[1]: Entering directory '/build/openvswitch-2.17.2'
py3versions: no X-Python3-Version in control file, using supported versions
find . -name "*.pyc" -delete
make[1]: Leaving directory '/build/openvswitch-2.17.2'
   dh_autoreconf_clean
   dh_clean
rm: cannot remove './_debian': Is a directory
rm: cannot remove './_dpdk': Is a directory
dh_clean: error: rm -f -- debian/openvswitch-common.substvars 
debian/openvswitch-doc.substvars debian/openvswitch-ipsec.substvars 
debian/openvswitch-ipsec.postrm.debhelper debian/openvswitch-pki.substvars 
debian/openvswitch-source.substvars debian/openvswitch-switch.substvars 
debian/openvswitch-switch.postrm.debhelper 
debian/openvswitch-switch-dpdk.substvars debian/openvswitch-test.substvars 
debian/openvswitch-test.postinst.debhelper 
debian/openvswitch-test.prerm.debhelper 
debian/openvswitch-testcontroller.substvars debian/openvswitch-vtep.substvars 
debian/python3-openvswitch.substvars 
debian/python3-openvswitch.postinst.debhelper 
debian/python3-openvswitch.prerm.debhelper ./_debian ./_dpdk debian/files 
returned exit code 1
make: *** [debian/rules:7: clean] Error 25

Looks like you are missing some trailing '/' in debian/clean
denoting directory trees to be removed.


Andreas

Bug#1014749: openvswitch-test,python3-openvswitch: both ship /usr/lib/python3/dist-packages/ovstest/*.py

[Andreas Beckmann]

Package: openvswitch-test,python3-openvswitch
Version: 2.17.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package python3-openvswitch.
  Preparing to unpack .../python3-openvswitch_2.17.2-1_all.deb ...
  Unpacking python3-openvswitch (2.17.2-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-openvswitch_2.17.2-1_all.deb (--unpack):
   trying to overwrite '/usr/lib/python3/dist-packages/ovstest/__init__.py', 
which is also in package openvswitch-test 2.17.2-1
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-openvswitch_2.17.2-1_all.deb


cheers,

Andreas


openvswitch-test=2.17.2-1_python3-openvswitch=2.17.2-1.log.gz
Description: application/gzip

Bug#1014748: thunderbird (102.0.1): Launching leads to generic Dash icon named "thunderbird-default"

[Krassy Boykinov]

Package: thunderbird
Version: 1:102.0.1-1
Severity: minor

After upgrade to 102.0.1, launching Thunderbird leads to the application
beeing named "thunderbird-default" (with generic icon) in the Gnome Dash.

It is irrelevant if it is started by typing "thunderbird" in the terminal
or clicking on the program icon in the overview
(triggering thunderbird.desktop).

ps still shows correct output: "S 1000  do_sys ? 00:01:37 thunderbird"

aa-status also still confines thunderbird as far as i can tell:
"/usr/lib/thunderbird/thunderbird-bin (152909) 
/usr/lib/thunderbird/thunderbird{,-bin}
 /usr/lib/thunderbird/thunderbird-bin (153003) 
/usr/lib/thunderbird/thunderbird{,-bin}"



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

Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages thunderbird depends on:
ii  debianutils  5.7-0.2
ii  fontconfig   2.13.1-4.4
ii  libasound2   1.2.7.1-1
ii  libatk1.0-0  2.38.0-1
ii  libc62.33-8
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.14.0-1
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.2-4
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.12.1+dfsg-3
ii  libgcc-s112.1.0-5
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.72.3-1
ii  libgtk-3-0   3.24.34-1
ii  libicu71 71.1-3
ii  libnspr4 2:4.34-1
ii  libnss3  2:3.79-1
ii  libpango-1.0-0   1.50.7+ds-1
ii  librnp0  0.16.0-1
ii  libstdc++6   12.1.0-5
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.7.5-1
ii  libx11-xcb1  2:1.7.5-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.4-1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.5-1
ii  x11-utils7.7+5
ii  zenity   3.42.1-2
ii  zlib1g   1:1.2.11.dfsg-4

Versions of packages thunderbird recommends:
ii  hunspell-de-at [hunspell-dictionary]  20161207-9
ii  hunspell-de-ch [hunspell-dictionary]  20161207-9
ii  hunspell-de-de [hunspell-dictionary]  20161207-9
ii  hunspell-en-us [hunspell-dictionary]  1:2020.12.07-2

Versions of packages thunderbird suggests:
ii  apparmor  3.0.4-3
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.19.2-2+b2

-- Configuration Files:
/etc/apparmor.d/usr.bin.thunderbird changed [not included]

-- no debconf information

Bug#840682: dh-exec --with=subst run also strip and filter command

[Craig Small]

On Thu, 13 Oct 2016 21:31:38 +0200 Bastien ROUCARIES <
roucaries.bast...@gmail.com> wrote:
> > dh-exec --with=subst --no-act
> /usr/lib/dh-exec/dh-exec-filter | /usr/lib/dh-exec/dh-exec-subst |
> /usr/lib/dh-exec/dh-exec-strip [input: {0, NULL}, output: {0, NULL}]
>
> instead of
> /usr/lib/dh-exec/dh-exec-subst  [input: {0, NULL}, output: {0, NULL}]
Hi,
Apologies for the delay, I have just took over maintaining dh-exec.

The trick we have here is a lot of packages have now expected that the flag
works this way[1].
Looking at the code, it adds filter, then whatever --with specifies, or
subst,install then strip.

That means the current packages specify install, but mean
filter,install,strip. If I make this change, then it will only do install.
I think only doing install is the right answer, but not sure if there is a
way of doing this but not breaking everything.

 - Craig

1: https://codesearch.debian.net/search?q=dh-exec+--with%3D&literal=1

Bug#1014655: [Pkg-utopia-maintainers] Bug#1014655: libnm0: after upgrade to 1.30.6-1+deb11u1 wifi and bluetooth no longer usable.

[Michael Biebl]

Control: reassign -1 network-manager
Control: forcemerge 1014654 -1

Merging as duplicat of 1014654


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014655: [Pkg-utopia-maintainers] Bug#1014655: libnm0: after upgrade to 1.30.6-1+deb11u1 wifi and bluetooth no longer usable.

[Michael Biebl]

No private, encrypted emails please.

Please post to the public bug tracker.

If you think this is a NM regression, please provide a debug log showing 
the problem.


https://wiki.gnome.org/Projects/NetworkManager/Debugging

I would recommend, that you file this upstream at
https://gitlab.freedesktop.org/NetworkManager/NetworkManager



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014747: node-jest-debbundle: mising Breaks+Replaces: jest (<< 28.1.2~)

[Andreas Beckmann]

Package: node-jest-debbundle
Version: 28.1.2~ds+~cs70.48.26-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'bullseye'.
It installed fine in 'bullseye', then the upgrade to 'bookworm' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../node-jest-debbundle_28.1.2~ds+~cs70.48.26-1_all.deb 
...
  Unpacking node-jest-debbundle (28.1.2~ds+~cs70.48.26-1) over 
(26.6.3+repack+~cs64.44.39-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/node-jest-debbundle_28.1.2~ds+~cs70.48.26-1_all.deb 
(--unpack):
   trying to overwrite 
'/usr/share/nodejs/@bcoe/v8-coverage/dist/lib/ascii.d.ts', which is also in 
package jest 26.6.3+repack+~cs64.44.39-3
  Errors were encountered while processing:
   /var/cache/apt/archives/node-jest-debbundle_28.1.2~ds+~cs70.48.26-1_all.deb


cheers,

Andreas


jest=26.6.3+repack+~cs64.44.39-3_node-jest-debbundle=28.1.2~ds+~cs70.48.26-1.log.gz
Description: application/gzip

Bug#1014730: liburi-perl: Breaks apt-cacher with "Can't locate Regexp/IPv6.pm" error

[Robert Luberda]

gregor herrmann pisze:


I'm a bit surprised, because the new code in 5.11 should behave
better if Regexp::IPv6 is not available:


Yes, but it looks like apt-cacher seems to set its own SIG{__DIE__} handler.



+our $IPv6_re;
+
+sub _looks_like_raw_ip6_address {
+  my $addr = shift;
+
+  if ( !$IPv6_re ) { #-- lazy / runs once / use Regexp::IPv6 if installed
+eval {


I've just checked that adding

  local $SIG{__DIE__};

here (i.e. before the require line) fixes the issue with apt-cacher for me.


+  require Regexp::IPv6;
+  Regexp::IPv6->import( qw($IPv6_re) );
+  1;
+}  ||  do { $IPv6_re = qr/[:0-9a-f]{3,}/; }; #-- fallback: unambitious 
guess




But may as well move libregexp-ipv6-perl to Depends, I guess.


Probably yes, but IMHO it would be better to restore default __DIE__ 
handler.


Regards,
robert

Bug#1014730: liburi-perl: Breaks apt-cacher with "Can't locate Regexp/IPv6.pm" error

[Niko Tyni]

On Mon, Jul 11, 2022 at 10:36:30AM +0200, gregor herrmann wrote:
> On Mon, 11 Jul 2022 00:12:11 +0200, Robert Luberda wrote:

> > The following information is printed into apt-cacher.log:
> > Mon Jul 11 00:02:52 2022|error [18513]: Can't locate Regexp/IPv6.pm in @INC 
> > (you may need to install the Regexp::
> > IPv6 module)
> 
> Thanks for your bug report.
> 
> I'm a bit surprised, because the new code in 5.11 should behave
> better if Regexp::IPv6 is not available:

apt-cacher is using $SIG{__DIE__}, which triggers even in eval blocks,
and doing an exit(1) from there.

  https://sources.debian.org/src/apt-cacher/1.7.26/apt-cacher/#L2251

  https://sources.debian.org/src/apt-cacher/1.7.26/apt-cacher/#L1259

I'd say this is not a bug in liburi-perl.
-- 
Niko Tyni   nt...@debian.org

Bug#970613: ITP: photoprint -- Image printing utility

[Bastian Germann]

The package got rejected. Do you want to try a 2nd time?

Bug#1014681: glewlwyd: Add build dependency to node-react-dom

[Nicolas Mora]

10 juill. 2022 10 h 45 min 13 s Yadd :

> Source: glewlwyd
> Version: 2.7.1-1
> Severity: important
> 
> Hi,
> 
> node-react is going to be split into multiple packages. Please add build
> dependency to node-react-dom to fix test.
> This can be done right now since current node-react provides
> node-react-dom virtual package.
> 
> Regards,
> Yadd
Thanks Yadd for notifying

I won't be able to upload a new package for the next 3 weeks though.

If the package glewlwyd will ftbfs until then, can someone in the team upload a 
fixed package? Otherwise, I'll make the fix in August.

/Nicolas

Bug#1014417: meson: test changes causes FTBFS

[Jeremy Bicha]

Control: forwarded -1 https://github.com/mesonbuild/meson/issues/10577

I linked an upstream meson issue.
See also https://github.com/mesonbuild/meson/issues/10563

A large merge proposal is at
https://github.com/mesonbuild/meson/pull/10580

Jeremy

Bug#1014746: openni-sensor-primesense: ftbfs on riscv64("Unknown machine type: riscv64")

[Bo YU]

Source: openni-sensor-primesense
Version: 5.1.0.41-12
Severity: normal
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org


Dear openni-sensor-primesense Maintainer,

Like openni-sensor-pointclouds[0], there is a possibility of being built
on riscv64 arch for the package also:
```
dh binary-arch --buildsystem=makefile
   dh_update_autotools_config -a -O--buildsystem=makefile
   dh_autoreconf -a -O--buildsystem=makefile
   dh_auto_configure -a -O--buildsystem=makefile
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
cd Platform/Linux/CreateRedist && bash -e RedistMaker
Unknown machine type: riscv64
make[1]: *** [debian/rules:7: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:4: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2
```

The patch attached is to fix the issue and I can build riscv64 package
on my real riscv64 hardware with it. But this patch took a long time 
to work properly for me due to unknown reason.

Please let me know if you need my assistant.

Thank you again!

Bo
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014665
-- 
Best Regards,

--- a/Platform/Linux/CreateRedist/RedistMaker
+++ b/Platform/Linux/CreateRedist/RedistMaker
@@ -37,6 +37,8 @@
 		PLATFORM="Arm" ;;
 	mips*)
 		PLATFORM="Mips" ;;
+	riscv*)
+		PLATFORM="Riscv64" ;;
 	*)
 		echo "Unknown machine type: $MACHINE_TYPE"
 		exit 1
--- a/Platform/Linux/Build/Common/CommonDefs.mak
+++ b/Platform/Linux/Build/Common/CommonDefs.mak
@@ -20,7 +20,9 @@
 else ifneq (,$(findstring ppc,$(MACHINE)))
 	HOST_PLATFORM = Powerpc
 else ifneq (,$(findstring mips,$(MACHINE)))
-HOST_PLATFORM = Mips
+  	HOST_PLATFORM = Mips
+else ifneq (,$(findstring riscv64,$(MACHINE)))
+	HOST_PLATFORM = Riscv64
 else
 	DUMMY:=$(error Can't determine host platform)
 endif
--- /dev/null
+++ b/Platform/Linux/Build/Common/Platform.Riscv64
@@ -0,0 +1,11 @@
+export GLUT_SUPPORTED=1
+
+ifeq "$(CFG)" "Release"
+
+# Optimization level, minus currently buggy optimizing methods (which break bit-exact)
+CFLAGS += -O3 -fno-tree-pre -fno-strict-aliasing
+
+# More optimization flags
+CFLAGS += -ftree-vectorize -ffast-math -funsafe-math-optimizations -fsingle-precision-constant
+
+endif
--- a/Source/Utils/XnSensorServer/SensorServer.cpp
+++ b/Source/Utils/XnSensorServer/SensorServer.cpp
@@ -56,7 +56,7 @@
 	nRetVal = XnSensorServerGetGlobalConfigFile(strConfigDir, strConfigFile, XN_FILE_MAX_PATH);
 	XN_CHECK_RC(nRetVal, "Resolving global config file");
 
-#if (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX || XN_PLATFORM == XN_PLATFORM_LINUX_MIPS)
+#if (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX || XN_PLATFORM == XN_PLATFORM_LINUX_MIPS || XN_PLATFORM == XN_PLATFORM_LINUX_RISCV64)
 	xnLogSetOutputFolder("/var/log/primesense/XnSensorServer/");
 #endif
 
--- a/Source/XnDeviceSensorV2/XnDeviceSensorInit.h
+++ b/Source/XnDeviceSensorV2/XnDeviceSensorInit.h
@@ -57,7 +57,7 @@
 
 	#define XN_SENSOR_USB_MISC_BUFFER_SIZE	0x1000
 	#define XN_SENSOR_USB_MISC_BUFFERS		1
-#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX || XN_PLATFORM == XN_PLATFORM_ANDROID_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_MIPS)
+#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX || XN_PLATFORM == XN_PLATFORM_ANDROID_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_MIPS || XN_PLATFORM == XN_PLATFORM_LINUX_RISCV64)
 	#define XN_SENSOR_USB_IMAGE_BUFFER_SIZE_MULTIPLIER_ISO32
 	#define XN_SENSOR_USB_IMAGE_BUFFER_SIZE_MULTIPLIER_BULK40
 	#define XN_SENSOR_USB_IMAGE_BUFFER_SIZE_MULTIPLIER_LOWBAND_ISO		16
--- a/Source/XnDeviceSensorV2/XnSensorClient.cpp
+++ b/Source/XnDeviceSensorV2/XnSensorClient.cpp
@@ -882,7 +882,7 @@
 	
 #if (XN_PLATFORM == XN_PLATFORM_WIN32)
 	nRetVal = GetModuleDir(strServerDir);
-#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX || XN_PLATFORM == XN_PLATFORM_LINUX_MIPS)
+#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX || XN_PLATFORM == XN_PLATFORM_LINUX