Bug#1028118: transition: rocksdb

[GCS]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi RMs,

Small transition of RocksDB to version 7.8.3 as the affected packages
are limited to balboa and sortmerna. Both build fine on amd64 with
this new RocksDB version.
While version 7.8.3 [1] has some new features, but has a bunch of bug
fixes that would be good to have for Bookworm. The only drawback is
sortmerna which is no longer built on i386 [2] since the end of last
November and can't migrate to testing due to this. Reason seems to be
either architecture misdetection or just that it doesn't support i386
architectures anymore. Failing message is:
error: inlining failed in call to ‘always_inline’ ‘_mm_set1_epi8’:
target specific option mismatch

I hope this transition gets green light despite this dependency
problem that needs to be resolved anyway. Main reason is a specific
memory corruption error fix in the 7.8.1 version of RocksDB.

Thanks for considering,
Laszlo/GCS
[1] https://github.com/facebook/rocksdb/releases/tag/v7.8.3
[2] https://buildd.debian.org/status/logs.php?pkg=sortmerna=i386

Bug#1028117: libvirt-daemon-system: Libvirtd missing dnsmasq package dependency

[huakim]

Package: libvirt-daemon-system
Version: 8.10.0-1+b1
Severity: important
X-Debbugs-Cc: fiji...@gmail.com

Dear Maintainer,

Please, move the dnsmasq-base package from recommends to depencies 
of the package libvirt-daemon-system,
because without dnsmasq binary libvirt won't start

-- System Information:
Debian Release: kali-rolling
  APT prefers testing
  APT policy: (1500, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: o386, i386

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser 3.129
ii  debconf [debconf-2.0]   1.5.79
ii  gettext-base0.21-10
ii  iptables1.8.8-1
ii  libvirt-clients 8.10.0-1+b1
ii  libvirt-daemon  8.10.0-1+b1
ii  libvirt-daemon-config-network   8.10.0-1
ii  libvirt-daemon-config-nwfilter  8.10.0-1
ii  libvirt-daemon-system-systemd   8.10.0-1
ii  logrotate   3.21.0-1
ii  policykit-1 122-1

Versions of packages libvirt-daemon-system recommends:
ii  dmidecode3.4-1
ii  dnsmasq-base [dnsmasq-base]  2.88-1
ii  iproute2 6.0.0-1+b1
pn  mdevctl  
ii  parted   3.5-3

Versions of packages libvirt-daemon-system suggests:
pn  apparmor
pn  auditd  
pn  nfs-common  
pn  open-iscsi  
pn  pm-utils
ii  systemd 252.4-1
pn  systemtap   
pn  zfsutils

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

-- debconf information excluded

Bug#925288: please package diff-highlight executable

[Franklin Yu]

Hi maintainers, any update? Is there any plan to include the diff-highlight 
executable in the “git” package?

Bug#1028116: linux-image-6.0.0-4-amd64: Bluetooth no longer working with Mediatek MT7921K chipset

[Matthew McAllister]

Package: src:linux
Version: 6.0.8-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: matthew.mcalliste...@gmail.com

Dear Maintainer,

Bluetooth is no longer usable with this chipset on this kernel version.
/sys/class/bluetooth is not present after booting or rebooting. There are no
lines relating to bluetooth in dmesg. Here is the relevant part of lsmod:
mt7921e32768  0
mt7921_common  94208  1 mt7921e
mt76_connac_lib73728  2 mt7921e,mt7921_common
mt76  106496  3 mt7921e,mt7921_common,mt76_connac_lib
mac80211 1159168  3 mt76,mt7921_common,mt76_connac_lib
cfg80211 1118208  4 mt76,mac80211,mt7921_common,mt76_connac_lib

WiFi *does* continue to work with this chipset. Only bluetooth seems to be
affected.

Matthew


-- Package-specific info:
** Version:
Linux version 6.0.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC 
Debian 6.0.8-1 (2022-11-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.0.0-4-amd64 
root=UUID=07b1d3ad-a765-4cd2-a24d-044a7e997478 ro quiet

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[   71.178040] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.1/:07:00.1/sound/card0/input15
[   71.178071] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:03.1/:07:00.1/sound/card0/input16
[   71.178096] input: HDA NVidia HDMI/DP,pcm=10 as 
/devices/pci:00/:00:03.1/:07:00.1/sound/card0/input17
[   71.178121] input: HDA NVidia HDMI/DP,pcm=11 as 
/devices/pci:00/:00:03.1/:07:00.1/sound/card0/input18
[   71.178145] input: HDA NVidia HDMI/DP,pcm=12 as 
/devices/pci:00/:00:03.1/:07:00.1/sound/card0/input19
[   71.183320] input: HDA Digital PCBeep as 
/devices/pci:00/:00:08.1/:09:00.4/sound/card1/input12
[   71.183344] input: HD-Audio Generic Front Mic as 
/devices/pci:00/:00:08.1/:09:00.4/sound/card1/input20
[   71.183367] input: HD-Audio Generic Rear Mic as 
/devices/pci:00/:00:08.1/:09:00.4/sound/card1/input21
[   71.183390] input: HD-Audio Generic Line as 
/devices/pci:00/:00:08.1/:09:00.4/sound/card1/input22
[   71.183418] input: HD-Audio Generic Line Out Front as 
/devices/pci:00/:00:08.1/:09:00.4/sound/card1/input23
[   71.183439] input: HD-Audio Generic Line Out Surround as 
/devices/pci:00/:00:08.1/:09:00.4/sound/card1/input24
[   71.183460] input: HD-Audio Generic Line Out CLFE as 
/devices/pci:00/:00:08.1/:09:00.4/sound/card1/input25
[   71.183484] input: HD-Audio Generic Front Headphone as 
/devices/pci:00/:00:08.1/:09:00.4/sound/card1/input26
[   71.195072] mt7921e :06:00.0: enabling device ( -> 0002)
[   71.211276] mt7921e :06:00.0: ASIC revision: 79610010
[   71.276498] nvidia: loading out-of-tree module taints kernel.
[   71.276506] nvidia: module license 'NVIDIA' taints kernel.
[   71.276507] Disabling lock debugging due to kernel taint
[   71.283456] nvidia: module verification failed: signature and/or required 
key missing - tainting kernel
[   71.294358] input: UVC Camera (046d:081b) as 
/devices/pci:00/:00:01.2/:02:00.0/usb1/1-3/1-3.1/1-3.1:1.0/input/input27
[   71.294365] mt7921e :06:00.0: firmware: direct-loading firmware 
mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
[   71.294368] mt7921e :06:00.0: HW/SW Version: 0x8a108a10, Build Time: 
20221109110918a

[   71.294406] usbcore: registered new interface driver uvcvideo
[   71.304542] mt7921e :06:00.0: firmware: direct-loading firmware 
mediatek/WIFI_RAM_CODE_MT7961_1.bin
[   71.304545] mt7921e :06:00.0: WM Firmware Version: 01, Build 
Time: 20221109111005
[   71.325478] nvidia-nvlink: Nvlink Core is being initialized, major device 
number 243

[   71.326050] nvidia :07:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
[   71.335981] RAPL PMU: API unit is 2^-32 Joules, 1 fixed counters, 163840 ms 
ovfl timer
[   71.335983] RAPL PMU: hw unit of domain package 2^-16 Joules
[   71.337740] cryptd: max_cpu_qlen set to 1000
[   71.344041] AVX2 version of gcm_enc/dec engaged.
[   71.344075] AES CTR mode by8 optimization enabled
[   71.376111] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  510.108.03  Thu 
Oct 20 05:10:45 UTC 2022
[   71.433031] kvm: support for 'kvm_amd' disabled by bios
[   71.704379] MCE: In-kernel MCE decoding enabled.
[   71.705994] kvm: support for 'kvm_amd' disabled by bios
[   71.713539] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for 
UNIX platforms  510.108.03  Thu Oct 20 05:00:22 UTC 2022
[   71.886819] kvm: support for 'kvm_amd' disabled by bios
[   71.894642] intel_rapl_common: Found RAPL domain package
[   71.894644] intel_rapl_common: Found RAPL domain core
[   71.990590] kvm: support 

Bug#858070: ifupdown: ifdown puts the interface down before removing the IPv6 addresses

[Conrad T. Pino]

Package: ifupdown
Version: 0.8.36
Severity: normal
Tags: ipv4 ipv6

Debian Bug #858070 remains in ifdown version 0.8.36

Multipe static IPv4 and IPv6 address are affected because interface is flushed 
AND downed AFTER EVERY address delete.

admin@hef1v10:~$ cat /etc/network/interfaces.d/ens224
allow-hotplug ens224

iface ens224 inet static
address 64.62.193.70/28

iface ens224 inet static
address 64.62.193.74/28

iface ens224 inet static
address 64.62.193.75/28

iface ens224 inet static
address 64.62.193.76/28

iface ens224 inet static
address 64.62.193.77/28

iface ens224 inet static
address 64.62.193.78/28

iface ipv6all inet6 static
accept_ra 0 # Accept router advertisements 0=off
autoconf 0  # Perform stateless autoconfiguration 0=off
dad-attempts 0  # Duplicate Address Detection attempts
privext 0   # Privacy extensions (RFC3041) 0=off

iface ens224 inet6 static inherits ipv6all
address 2001:470:44:2::403e:c146/64

iface ens224 inet6 static inherits ipv6all
address 2001:470:44:2::403e:c14a/64

iface ens224 inet6 static inherits ipv6all
address 2001:470:44:2::403e:c14e/64

iface ens224 inet6 static inherits ipv6all
address 2001:470:44:2:20c:29ff:fe60:aa05/64

iface ens224 inet6 static inherits ipv6all
address 2001:470:44:2:20c:29ff:feba:79b3/64

iface ens224 inet6 static inherits ipv6all
address 2001:470:44:2:20c:29ff:fee1:45b7/64


admin@hef1v10:~$ sudo ifdown --version
ifdown version 0.8.36

Copyright (c) 1999-2009 Anthony Towns
  2010-2015 Andrej Shadura
  2015-2017 Guus Sliepen

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or (at
your option) any later version.



admin@hef1v10:~$ sudo ifdown --verbose ens224
ifdown: parsing file /etc/network/interfaces.d/ens224
ifdown: configuring interface ens224=ens224 (inet)
/bin/run-parts --verbose /etc/network/if-down.d

/sbin/ip addr del 64.62.193.70/255.255.255.240 broadcast 64.62.193.79 dev 
ens224 label ens224
/sbin/ip -4 addr flush dev ens224
/sbin/ip link set dev ens224 down
/bin/run-parts --verbose /etc/network/if-post-down.d
ifdown: configuring interface ens224=ens224 (inet)
/bin/run-parts --verbose /etc/network/if-down.d

/sbin/ip addr del 64.62.193.74/255.255.255.240 broadcast 64.62.193.79 dev 
ens224 label ens224
RTNETLINK answers: Cannot assign requested address
/sbin/ip -4 addr flush dev ens224
/sbin/ip link set dev ens224 down
/bin/run-parts --verbose /etc/network/if-post-down.d
ifdown: configuring interface ens224=ens224 (inet)
/bin/run-parts --verbose /etc/network/if-down.d

/sbin/ip addr del 64.62.193.75/255.255.255.240 broadcast 64.62.193.79 dev 
ens224 label ens224
RTNETLINK answers: Cannot assign requested address
/sbin/ip -4 addr flush dev ens224
/sbin/ip link set dev ens224 down
/bin/run-parts --verbose /etc/network/if-post-down.d
ifdown: configuring interface ens224=ens224 (inet)
/bin/run-parts --verbose /etc/network/if-down.d

/sbin/ip addr del 64.62.193.76/255.255.255.240 broadcast 64.62.193.79 dev 
ens224 label ens224
RTNETLINK answers: Cannot assign requested address
/sbin/ip -4 addr flush dev ens224
/sbin/ip link set dev ens224 down
/bin/run-parts --verbose /etc/network/if-post-down.d
ifdown: configuring interface ens224=ens224 (inet)
/bin/run-parts --verbose /etc/network/if-down.d

/sbin/ip addr del 64.62.193.77/255.255.255.240 broadcast 64.62.193.79 dev 
ens224 label ens224
RTNETLINK answers: Cannot assign requested address
/sbin/ip -4 addr flush dev ens224
/sbin/ip link set dev ens224 down
/bin/run-parts --verbose /etc/network/if-post-down.d
ifdown: configuring interface ens224=ens224 (inet)
/bin/run-parts --verbose /etc/network/if-down.d

/sbin/ip addr del 64.62.193.78/255.255.255.240 broadcast 64.62.193.79 dev 
ens224 label ens224
RTNETLINK answers: Cannot assign requested address
/sbin/ip -4 addr flush dev ens224
/sbin/ip link set dev ens224 down
/bin/run-parts --verbose /etc/network/if-post-down.d
ifdown: configuring interface ens224=ens224 (inet6)
/bin/run-parts --verbose /etc/network/if-down.d

/sbin/ip -6 addr del 2001:470:44:2::403e:c146/64  dev ens224
RTNETLINK answers: Cannot assign requested address
/sbin/ip -6 addr flush dev ens224
/sbin/ip link set dev ens224 down
/bin/run-parts --verbose /etc/network/if-post-down.d
ifdown: configuring interface ens224=ens224 (inet6)
/bin/run-parts --verbose /etc/network/if-down.d

/sbin/ip -6 addr del 2001:470:44:2::403e:c14a/64  dev ens224
RTNETLINK answers: Cannot assign requested address
/sbin/ip -6 addr flush dev ens224
/sbin/ip link set dev ens224 down
/bin/run-parts --verbose /etc/network/if-post-down.d
ifdown: configuring interface ens224=ens224 (inet6)
/bin/run-parts --verbose /etc/network/if-down.d

/sbin/ip -6 addr del 

Bug#1028115: init: Document requirements for being an alternative pre-dependency of init

[Lorenzo Puliti]

Package: init
Version: 1.65.2
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

Dear i-s-h maintainers,

I intend to ask for the inclusion of runit-init into the pre-dep list
of this package right after the bookworm release. 
For now I'm following the list of suggestions provided by Simon McVittie [1]
in #923450 msg#15; please document your requirements.

Regards,
Lorenzo

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923450

Bug#1028114: Upstream has new versions

[Dan Jacobson]

Package: xdotool
Version: 1:3.20160805.1-5

https://github.com/jordansissel/xdotool/releases has many new versions. Thanks.

Bug#871446: jemalloc: FTBFS on hurd-i386: aligned_alloc test hangs

[Faidon Liambotis]

Hi there,

On Sun, Apr 04, 2021 at 09:57:39PM +0300, Faidon Liambotis wrote:
> On Sun, Apr 04, 2021 at 02:26:16AM +0200, Samuel Thibault wrote:
> > So basically libpthread is trying to initialize itself, calls malloc,
> > which initializes jemalloc, which calls pthread_self, which is not happy
> > that libpthread is not initialized yet, thus calls assert, which tries
> > to malloc as well, which tries (again!) to initialize jemalloc, and
> > gets stuck on mutex_lock. And since this is all happening at very early
> > initialization of libc, interaction with ps etc. is not possible yet.
> > 
> > [...]
> >
> > I'm wondering how this kind of bootstrap issue is solved on Linux? The
> > _dl_allocate_tls code is exactly the same.
> 
> Thanks for looking into this! I'm really out of my depth here. Don't
> assume that the platform settings in configure.ac are the right ones
> either -- I just guesstimated them, and may just as well be something
> there.
> 
> I'd suggest reaching out to upstream directly on either a GitHub issue,
> or their Gitter channel (they're responsive in my experience). Note that
> I haven't sent them debian/patches/hurd.patch as it hasn't been
> functional so far, so it may be worth prefacing your communication with
> the configure.ac settings that we've chosen.
> 
> If you succeed into figuring out the root cause and making jemalloc
> build, happy to prepare a PR to upstream this.

I'm wondering if you've had any chance to look into this. I've just
uploaded 5.3.0-1 to unstable (after a brief stay in experimental, as
5.3.0-1~exp1), and was looking over FTBFSes and open bugs.

Thanks!
Faidon

Bug#1028102: secnet FTBFS: eax-aes-test failure

[Ian Jackson]

Ian Jackson writes ("Want to ignore latest set of libc resolv.conf options"):
> Adrian Bunk writes ("Bug#1028102: secnet FTBFS: eax-aes-test failure"):
> > adns [2238721]: /etc/resolv.conf:15: unknown option `trust-ad'
> 
> This ought to be silently tolerated, not complained about.  (The
> message is only a warning so I think this is not related to the cause
> of the secnet FTBFS.)

This spurious warning is now #1028112.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1028113: ddnet accesses the internet during the build

[Adrian Bunk]

Source: ddnet
Version: 16.4-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ddnet.html

...
[ RUN  ] Jobs.LookupHostWebsocket
2024-01-26 08:45:01 I host_lookup: host='example.com' port=0 1
./src/test/jobs.cpp:109: Failure
Expected equality of these values:
  pJob->m_Result
Which is: -1
  0
[  FAILED  ] Jobs.LookupHostWebsocket (2 ms)
...

Bug#1028112: Want to ignore latest set of libc resolv.conf options

[Ian Jackson]

Package: adns
Version: 1.6.0-2
Severity: important

Adrian Bunk writes ("Bug#1028102: secnet FTBFS: eax-aes-test failure"):
> Source: secnet
> Version: 0.6.5
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/logs.php?pkg=secnet=0.6.5
> https://buildd.debian.org/status/fetch.php?pkg=secnet=amd64=0.6.5%2Bb1=1673039054=0
> 
> ...
> ./eax-aes-test <./eax-aes-test.vectors >eax-aes-test.confirm.new
> spawn:
> Jan  6 21:04:09 Now in PHASE_READCONFIG
> adns [2238721]: /etc/resolv.conf:15: unknown option `trust-ad'

This ought to be silently tolerated, not complained about.  (The
message is only a warning so I think this is not related to the cause
of the secnet FTBFS.)

I should go through the libc manpage and see what else ought to be
added to the "silently ignore" list.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1028102: secnet FTBFS: eax-aes-test failure

[Ian Jackson]

Control: tags -1 confirmed

Thanks for the report.

Adrian Bunk writes ("Bug#1028102: secnet FTBFS: eax-aes-test failure"):
> Source: secnet
> Version: 0.6.5
> Severity: serious
> Tags: ftbfs
...
> adns [2238721]: /etc/resolv.conf:15: unknown option `trust-ad'

This is a red herring, although it ought to be fixed in adns.
It's just a warning message.

> Jan  6 21:04:09 Running hooks for PHASE_SHUTDOWN...
> Jan  6 21:04:09 Now in PHASE_SHUTDOWN
> Jan  6 21:04:09 secnet fatal error: Failed to initialise ADNS: No such file 
> or directory

For my reference, I can repro this with
  dgit -wgf sbuild --arch i386 -c bullseye32
but it works with
  dgit -wgf sbuild  -c bullseye

This is a bit mysterious but with a repro I should be able to debug
it.  I think it might be related to the test suite's use of
an LD_PRELOAD to redirect UDP to AF_UNIX sockets.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1028025: hippotat shouldn't be a native package

[Adrian Bunk]

On Sat, Jan 07, 2023 at 01:11:59AM +, Ian Jackson wrote:
>...
> IMO It doesn't make sense to separately maintain upstream and debian
> branches just to handle a usually-empty difference.  I have often
> integrated NMUs in packages maintained this way and it works well.
>...

I do not even care how you *maintain* it,
I only care how you *export* it to Debian tarballs.

>...
> In such a situation (you're making an NMU with a package I maintain
> this way), if you were to provide me with your git commits, that would
> be welcome.   
>...

There are no git commits.

To avoid introducing regressions when the contents of the previously 
used sources in the Debian package and the contents of some git tree 
differs (this has happened), my only usage of git in NMUs is usually 
git-format-patch to export changes from upstream git to debian/patches/ 

nmudiff(1) sends the diff of my changes to the BTS,
a maintainer can easily git-am this without me having
to learn a gazillion different workflows.

>...
> > being able to split my own changes into separate patches makes it
> > easier for other people to review my changes.
> 
> That is true, if you need to make a substantial NMU.  I'm sure most
> maintainers will almost immediately import such a thing into git.
>...

The exact opposite is usually true:

If there was a maintainer available who would do anything
"almost immediately", there would not have been a need for
an NMU.

Usually the maintainer is either temporarily not available
(happens to most of us) or MIA.

> Ian.

cu
Adrian

Bug#1020215: w3m interprets when not in but in

[Tatsuya Kinoshita]

On 2023-01-06 at 19:31 +0100, Robert Alm Nilsson wrote:
> After using my version of w3m every day since I posted this, the only
> problem I have noticed on a few pages is that it doesn't handle titles
> directly under html tags, so this doesn't work:
>
> Hello

Ah, it should be interpreted as in .

I've installed a patch that only picks a first title as a workaround.

  - https://github.com/tats/w3m/commit/b9c022a8101e6325468bf310d6038df11e5fac67

Thanks for your report.

--
Tatsuya Kinoshita


pgpvdGS3k2laz.pgp
Description: PGP signature

Bug#1028025: hippotat shouldn't be a native package

[Ian Jackson]

Adrian Bunk writes ("Bug#1028025: hippotat shouldn't be a native package"):
> I don't know what your workflow is, e.g. git-archive(1) with 
> export-ignore attribute for debian/ could be used to generate
> the orig.tar.xz.

My upstream release process does not involve tarballs.
I make and publish a git tag.  Downstreams are expected to get the
source code from git.  If they want to make tarballs they can do so.

Then with my Debian hat on, I make a tarball because Debian still
expects tarballs.  dgit does the git to tarball conversion for me.

(I also do a  "cargo publish", which does involve tarballs underneath.
That is quite regrettable, but out of my bailiwick.)

If someone does an NMU in Debian (they are very welcome to) I will
either use the git branch and commits they provided (if they did it
with dgit or otherwise gave me their git branch eg via salsa) or
import it into git ASAP (if they didn't).

IMO It doesn't make sense to separately maintain upstream and debian
branches just to handle a usually-empty difference.  I have often
integrated NMUs in packages maintained this way and it works well.

One way to look at this is that (with my Debian hat on) I am using the
workflow described in dgit-maint-merge(7).

> being able to split my own changes into separate patches makes it
> easier for other people to review my changes.

That is true, if you need to make a substantial NMU.  I'm sure most
maintainers will almost immediately import such a thing into git.

In such a situation (you're making an NMU with a package I maintain
this way), if you were to provide me with your git commits, that would
be welcome.  The most obvious way would be for you to do your NMU with
`dgit push`, but of course you can use a branch or MR on salsa or
something.

If you prefer to stick to the lowest-common-denominator tarballs, as
represented in the Debian ftp archive, then of course that is up to
you.

I hope this clarifies things.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1028111: r-cran-clock: autopkgtest failure on 32bit

[Adrian Bunk]

Source: r-cran-clock
Version: 0.6.1-1
Severity: serious

https://tracker.debian.org/pkg/r-cran-clock

Issues preventing migration:
∙ ∙ autopkgtest for r-cran-clock/0.6.1-1: amd64: Pass, arm64: Pass, armel: 
Regression ♻ , armhf: Regression ♻ , i386: Regression ♻


...
> test_check("clock")
[ FAIL 2 | WARN 29 | SKIP 252 | PASS 1146 ]

══ Skipped tests ═══
• On CRAN (252)

══ Failed tests 
── Failure ('test-posixt.R:151'): can group by 
year/month/day/hour/minute/second ──
date_group(z, "year") (`actual`) not identical to `expect` (`expected`).

actual  | expected 
[1] "-1-12-31 23:56:02" - "0-01-01" [1]
[2] "0-12-31 23:56:02"  - "1-01-01" [2]
[3] "1-12-31 23:56:02"  - "2-01-01" [3]
[4] "2-12-31 23:56:02"  - "3-01-01" [4]
[5] "3-12-31 23:56:02"  - "4-01-01" [5]
── Failure ('test-posixt.R:152'): can group by 
year/month/day/hour/minute/second ──
date_group(z, "year", n = 3) (`actual`) not identical to expect[c(1, 1, 1, 4, 
4)] (`expected`).

actual  | expected 
[1] "-1-12-31 23:56:02" - "0-01-01" [1]
[2] "-1-12-31 23:56:02" - "0-01-01" [2]
[3] "-1-12-31 23:56:02" - "0-01-01" [3]
[4] "2-12-31 23:56:02"  - "3-01-01" [4]
[5] "2-12-31 23:56:02"  - "3-01-01" [5]

[ FAIL 2 | WARN 29 | SKIP 252 | PASS 1146 ]
Error: Test failures
Execution halted
autopkgtest [16:10:54]: test run-unit-test: ---]
autopkgtest [16:10:55]: test run-unit-test:  - - - - - - - - - - results - - - 
- - - - - - -
run-unit-testFAIL non-zero exit status 1
...

Bug#1026389: xfce4: split screen doesn't work anymore

[Bernhard Übelacker]

"With a dragged window" - default as far as I see is on.


I confirm that either with those 4 defaults, or with "with a dragged 
window" off (as you suggested that would fix it), I still have it bugged.



If you still don't get a dragged window filling half of the screen,
then I can't reproduce your issue and don't have a solution.


Is there any other setting that might be affecting?



Hello Alex,
I tried to find out where the magic happens,
and wanted to write it to you.
But I found some strange wiring about the "With a dragged window"
configuration option.

Somehow it is responsible in the configuration file
for "/general/snap_to_windows" and "/general/tile_on_move".
Unfortunately the latter setting can just be changed once,
and that is switching off.

The patch at the bottom would set tile_on_move to true,
if the "With a dragged window" gets switched off.

Kind regards,
Bernhard


(gdb) bt
#0  clientTile (c=0x14d6800, cx=1, cy=224, tile=TILE_LEFT, send_configure=1, 
restore_position=0) at ./src/client.c:3701
#1  0x004c61c8 in clientMoveTile (event=, c=0x14d6800) at 
./src/moveresize.c:862
#2  clientMoveEventFilter (event=0x1323410, data=0xbfab8914) at 
./src/moveresize.c:1063
#3  0x004b4ace in eventXfwmFilter (gdk_xevent=0xbfab871c, gevent=0x149a400, 
data=0x1468d30) at ./src/event_filter.c:175
#4  0xb73693b1 in  () at /lib/i386-linux-gnu/libgdk-3.so.0
...


$ grep -E "To screen.*borders|To other.*windows|With the mouse.*pointer|With 
a.*dragged window" . -Rn -B1 --exclude *.po
...
./settings-dialogs/xfwm4-dialog.glade-1315-  
./settings-dialogs/xfwm4-dialog.glade:1316:With a _dragged window


$ grep -E 
"snap_to_border_check|snap_to_window_check|wrap_workspaces_check|wrap_windows_check"
 . -Rn -B1
...
./settings-dialogs/xfwm4-settings.c-611-  xfconf_g_property_bind 
(settings->priv->wm_channel, "/general/wrap_windows", G_TYPE_BOOLEAN,
./settings-dialogs/xfwm4-settings.c:612:  wrap_windows_check, 
"active");
...
./settings-dialogs/xfwm4-settings.c:617:  g_signal_connect (G_OBJECT 
(wrap_windows_check), "toggled",
./settings-dialogs/xfwm4-settings.c-618-G_CALLBACK 
(cb_wrap_windows_toggled),
...
./settings-dialogs/xfwm4-settings.c:1612  cb_wrap_windows_toggled 
(GtkToggleButton *toggle, XfconfChannel *channel)
./settings-dialogs/xfwm4-settings.c:1613  {
./settings-dialogs/xfwm4-settings.c:1614if (gtk_toggle_button_get_active 
(toggle))
./settings-dialogs/xfwm4-settings.c:1615  xfconf_channel_set_bool (channel, 
"/general/tile_on_move", FALSE);
./settings-dialogs/xfwm4-settings.c:1616  }


$ grep -E 
"wrap_workspaces|wrap_windows|snap_to_border|snap_to_windows|tile_on_move" -Rn 
--include *.xml
...
.config/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml:63:
.config/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml:80:



--- xfwm4-4.18.0.orig/settings-dialogs/xfwm4-settings.c
+++ xfwm4-4.18.0/settings-dialogs/xfwm4-settings.c
@@ -1613,6 +1613,8 @@ cb_wrap_windows_toggled (GtkToggleButton
 {
   if (gtk_toggle_button_get_active (toggle))
 xfconf_channel_set_bool (channel, "/general/tile_on_move", FALSE);
+  else
+xfconf_channel_set_bool (channel, "/general/tile_on_move", TRUE);
 }

Bug#1028110: php-horde-lz4: autopkgtest failure

[Adrian Bunk]

Source: php-horde-lz4
Version: 1.0.10-9
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-horde-lz4/30065605/log.gz

...
autopkgtest [03:59:01]: test phpunit: [---
PHPUnit requires the "dom" extension.
autopkgtest [03:59:02]: test phpunit: ---]
autopkgtest [03:59:02]: test phpunit:  - - - - - - - - - - results - - - - - - 
- - - -
phpunit  FAIL non-zero exit status 1

Bug#1028109: reportbug: More verbose hand-holding for ftp.debian.org reports

[Vagrant Cascadian]

Package: reportbug
Version: 11.6.0
Severity: normal
X-Debbugs-Cc: Vagrant Cascadian 

Thanks for reportbug, it is a great social networking tool!

I was wondering if reportbug could be a little more verbose when
reporting bugs against ftp.debian.org ...

$ reportbug ftp.debian.org
...
What sort of request is this? (If none of these things mean anything to
you, or you are trying to report a bug in an existing package, please
press Enter to exit reportbug.)

 1 ANAIS Package removal - Architecture Not Allowed In Source.
 2 ICE   Package removal - Internal Compiler Error.
 3 NBS   Package removal - Not Built [by] Source.
 4 NPOASRPackage removal - Never Part Of A Stable Release.
 5 NVIU  Package removal - Newer Version In Unstable.
 6 ROM   Package removal - Request Of Maintainer.
 7 ROP   Package removal - Request of Porter.
 8 RoQA  Package removal - Requested by the QA team.
 9 other Not a package removal request, report other problems.
10 override  Change override request.

It walked me through a few steps, and I can guess a bit at what a lot of
these mean, but it was not obvious to me weather I should select NBS,
ANAIS or NVIU to remove some packages ...

I had a package "u-boot" that was no longer provided on some
architectures (armhf and mips) ... but should it be removed from
testing, so that it can migrate to testing?  Should it be removed from
unstable, because the source in testing currently builds this package?
If I pick the wrong one, will it end up removing the source package too?

Thankfully, I do not make these sorts of ftp.debian.org requests very
often... so it would be nice if reportbug nudged me a little more in the
right direction, either by being a little more verbose here, or
providing a link to more detailed information, asking a few more leading
questions, etc.

live well,
  vagrant

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

Kernel: Linux 6.1.0-0-arm64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_CRAP
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 reportbug depends on:
ii  apt2.5.4
ii  python33.10.6-3+b1
ii  python3-reportbug  11.6.0
ii  sensible-utils 0.0.17

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
ii  debconf1.5.80
pn  debsums
pn  dlocate
ii  emacs-bin-common   1:28.2+1-9
ii  exim4-daemon-light [mail-transport-agent]  4.96-12
ii  file   1:5.41-4
ii  gnupg  2.2.40-1
pn  python3-urwid  
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.5.4
ii  file   1:5.41-4
ii  python33.10.6-3+b1
ii  python3-apt2.5.0
ii  python3-debian 0.1.49
ii  python3-debianbts  4.0.1
ii  python3-requests   2.28.1+dfsg-1
ii  sensible-utils 0.0.17

python3-reportbug suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1028108: python-cooler: binary-any FTBFS

[Adrian Bunk]

Source: python-cooler
Version: 0.8.11-5
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=python-cooler=0.8.11-5

...
   debian/rules override_dh_installexamples
make[1]: Entering directory '/<>'
dh_installexamples
cd debian/python3-cooler-examples/usr/share/doc/python3-cooler && tar --create 
--owner=0 --group=0 --numeric-owner --sort=name --mtime="@1672342132" 
--mode=u=wrX,og=rX --file tests.tar.xz tests && rm -rf tests
/bin/sh: 1: cd: can't cd to 
debian/python3-cooler-examples/usr/share/doc/python3-cooler
make[1]: *** [debian/rules:12: override_dh_installexamples] Error 2

Bug#1028107: sigil: versioned dependency on 'sigil-data' is too strict

[Ben Finney]

Package: sigil
Version: 1.9.20+dfsg-1
Severity: important
Justification: renders some versions uninstallable

The binary ‘sigil’ package has a strict versioned dependency on
‘sigil-data’, “Depends: sigil-data (= ${source:Version})”.

This allows precisely one Debian release and will forbit installation if
that version of ‘sigil-data’ is not available.

This causes the package to be uninstallable when, for example, a recompiled
package is released. (Hence the “Severity: important” for this bug report.)

Debian currently has ‘sigil’ version “1.9.20+dfsg-1+b1”, which cannot
install because it “Depends: sigil-data (= 1.9.20+dfsg-1+b1)”, which does
not exist.

Instead, the dependency should be relaxed. Is there a good reason to
version this dependency?

If a version is needed, can it be relaxed to “1.9.20+dfsg~” or similar?

-- 
 \ “Two paradoxes are better than one; they may even suggest a |
  `\ solution.” —Edward Teller |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1028106: RM: u-boot [armhf mips] -- NBS; Removed transitional package on armhf and mips

[Vagrant Cascadian]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: u-b...@packages.debian.org
Control: affects -1 + src:u-boot

Please remove the obsolete "u-boot" transitional meta-package from
unstable for armhf and mips. This should no longer be needed since as of
buster+1[mips] or stretch+1[armhf]. For clarity, all the other u-boot-*
packages should still be kept!

Thanks!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1025234: prometheus: flaky autopkgtest (on 32 bit archs?)

[Daniel Swarbrick]

On 07.01.23 12:40, Adrian Bunk wrote:

Does running the autopkgtests on 32-bit bring more benefits than hassle,
or should they be run only on 64-bit architectures?


As troublesome as the tests are on 32-bit, and as much as it would 
probably be simpler to just blanket disable them in d/rules, I have seen 
other dubious code land occasionally, which would fail on 32-bit.


On several occasions in the past, I have had to patch tests which 
attempted to read numeric values into an untyped int / uint, which would 
overflow on 32-bit. For this reason, I think we still need to keep 
testing on 32-bit, to keep the upstream developers on their toes ;-)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028032: libpipeline1: add support for io_uring_spawn, posix_spawn and vfork+exec where possible

[Colin Watson]

On Fri, Jan 06, 2023 at 11:55:16AM +0800, Paul Wise wrote:
> The new io_uring_spawn mechanism for spawning processes without forking
> should be more efficient than fork+exec, especially when starting small
> processes from large processes. Also posix_spawn and vfork+exec exist.
> 
> https://lwn.net/Articles/908268/
> 
> I think the order of preference for spawning processes should be:
> 
>  * io_uring_spawn: this is Linux-only and only in new versions. Prefer
>    this over posix_spawn in case of an old glibc and new Linux kernel.

What I've heard of this sounds good, but as far as I can tell this is
not in upstream Linux, there are no patches anywhere to be found, no API
documentation, and the only references to the feature I can find
anywhere in a web search are all references to this one presentation
with no further detail.  It's of course possible that I've missed
something, but from what I can see it's far too early to even be able to
decide whether this would be usable, never mind being able to make use
of it on real systems.

>  * posix_spawn: this uses the appropriate mechanisms on each platform,
>    glibc might be changing this to use io_uring_spawn where possible.

I can see a few limitations here:

 * The standard API offers no way to set the working directory of the
   child process, which would be needed for pipecmd_chdir and
   pipecmd_fchdir.  However, glibc 2.29 added
   posix_spawn_file_actions_addchdir_np and
   posix_spawn_file_actions_addfchdir_np as GNU extensions.

 * I'm not totally sure how to translate pipecmd_nice into
   posix_spawn-speak; the documentation is, uh, opaque.  It's probably
   possible.

 * This wouldn't be usable for pipeline commands created using
   pipecmd_new_sequence, as posix_spawn isn't guaranteed to be
   async-signal-safe so can't be called between fork and exec, unlike
   fork.

However, we could always just restrict the conditions under which
posix_spawn is used, much as GLib's g_spawn_* functions do.  None of the
above features are used on mandb's hot path, for instance.

>  * vfork+exec: this is similar to what glibc does for posix_spawn.

If somebody were to present me with a patch for this then I suppose I
might at least consider it (though with a healthy amount of
scepticism!); but it's difficult, and I'm not sure I have the necessary
skills to review it properly.  glibc's posix_spawn implementation has
this moderately fearsome comment at the top:

/* The Linux implementation of posix_spawn{p} uses the clone syscall directly
   with CLONE_VM and CLONE_VFORK flags and an allocated stack.  The new stack
   and start function solves most the vfork limitation (possible parent
   clobber due stack spilling). The remaining issue are:

   1. That no signal handlers must run in child context, to avoid corrupting
  parent's state.
   2. The parent must ensure child's stack freeing.
   3. Child must synchronize with parent to enforce 2. and to possible
  return execv issues.

   The first issue is solved by blocking all signals in child, even
   the NPTL-internal ones (SIGCANCEL and SIGSETXID).  The second and
   third issue is done by a stack allocation in parent, and by using a
   field in struct spawn_args where the child can write an error
   code. CLONE_VFORK ensures that the parent does not run until the
   child has either exec'ed successfully or exited.  */

Do I really want that complexity in libpipeline?  I'm not sure that I
do.  It's certainly not close to being a drop-in replacement for fork.
posix_spawn, maybe with GNU extensions, looks like a more appealing
option.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1016963: Please test u-boot for odroid

[Joost van Zwieten]

Hi Vagrant,

Sorry for the late reply. I've been testing u-boot on the Odroid U3
the last couple of days. Turns out that u-boot doesn't work in stable
(again, sorry!). I've bisected the problem to commit
4963f63fe61f15329d77472a762b1d8bf754d24b (u-boot repo, somewhere
between v2020.10 and v2021.01). Reverting this commit in v2021.01
fixes the problem.

I noticed the following change in u-boot's output. Before said commit:

Kernel image @ 0x4100 [ 0x00 - 0x3fd200 ]
## Flattened Device Tree blob at 4080
   Booting using the fdt blob at 0x4080
   Loading Ramdisk to 4ece6000, end 49f5 ... OK
   Loading Device Tree to 4ecd6000, end 4ece5f41 ... OK

After the commit:

Kernel image @ 0x4100 [ 0x00 - 0x3fd200 ]
## Flattened Device Tree blob at 4080
   Booting using the fdt blob at 0x4080
   Loading Ramdisk to b9b6, end bae799f5 ... OK
   Loading Device Tree to b9b5, end b9b5ff41 ... OK

I've browsed through the source code and found that you can control
the position of the initrd using environment variable `initrd_high`.
Setting this to `0x5000` solves the problem as well in v2021.01
without reverting 4963f63f. Also `0x` works, which according
to u-boot's README disables the relocation of the initrd. The position
of the device tree doesn't seem to matter.

I'm not sure how to proceed with this and any guidance is appreciated,
but given that you're busy with finishing bookworm, I completely
understand that you don't have time for this.

Best, Joost


Op do 29 dec. 2022 om 01:39 schreef Vagrant Cascadian :
>
> On 2022-12-28, Vagrant Cascadian wrote:
> > On 2022-12-22, Vagrant Cascadian wrote:
> >> On 2022-08-20, Vagrant Cascadian wrote:
> >>> On 2022-08-10, Vagrant Cascadian wrote:
>  This bug is just to delay migration to testing while more platforms get
>  tested. If you have a relevent board, please consider testing and
>  reporting the status:
> 
>    https://wiki.debian.org/U-boot/Status
> >
> > I have not received many test results for current or even remotely
> > recent u-boot platforms in Debian, and u-boot has been blocked from
> > migration to testing partly because of this.
> >
> > As the bookworm freeze approaches, this is getting to be... worrysome!
> >
> > If you have access to any of these boards, please consider testing
> > u-boot versions as packaged in debian for versions from debian stable
> > (2021.01*), testing (2022.04*), unstable (2022.10*) and experimental
> > (2023.01-rc*) and updating the wiki page if successful and/or replying
> > to 1016...@bugs.debian.org with a positive confirmation...
> >
> > ...and if not successful, filing bugs against the relevent u-boot-*
> > packages and marking them as blocking 1016963.
>
> odroid
>
> live well,
>   vagrant

Bug#1028105: pkg-config:amd64 does not include necessary default search path

[Allan]

Package: pkg-config:amd64
Version: 1.8.0-12

  When I try to check for a package using pkg-config it is not
  able to find the package even that it is properly installed.
  Current output
  $ pkg-config --modversion gthread-2.0
  Package gthread-2.0 was not found in the pkg-config search path.
  Perhaps you should add the directory containing `gthread-2.0.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'gthread-2.0', required by 'virtual:world', not found

  Workaround
  $ env PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/lib/x86_64-linux-gnu/pkgconfig/"
pkg-config --modversion gthread-2.0
  2.74.4

  Expected output
  $ pkg-config --modversion gthread-2.0
  2.74.4

  The problem is that pkg-config does not know anything about this directory
  since it is not present in its default search directories
  $ pkg-config --variable pc_path pkg-config
  
/usr/local/lib/i386-linux-gnu/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/i386-linux-gnu/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig

  I am using Debian GNU/Linux 6.0.12-1 (2022-12-09), kernel 6.0.0-6-amd64
  and libc6 2.36-7.

Att,
Allan Krama Guimarães

Bug#1025234: prometheus: flaky autopkgtest (on 32 bit archs?)

[Adrian Bunk]

On Fri, Dec 02, 2022 at 05:51:20PM +1300, Daniel Swarbrick wrote:
> Hi Paul,
> 
> I have also noticed the fairly frequent failures of the memory-intensive
> tests on 32-bit, and I am doing my best to keep on top of them with t.Skip()
> patches where appropriate. Several of the tests result in the 4 GiB memory
> footprint threshold being exceeded.

4 GiB is the maximum address space limit, and it is typically only 
available on some architectures with 64-bit kernel (not on real
32-bit hardware).

2 GiB or 3 GiB are typical limits for available address space with 
32-bit kernels (on MIPS it's 2 GiB even with a 64-bit kernel).

> Prometheus itself is still usable on 32-bit, but obviously only up to a
> certain size. The upstream developers don't seem to consider 32-bit when
> writing unit tests, thus the regular addition of new tests which fail.

Does running the autopkgtests on 32-bit bring more benefits than hassle,
or should they be run only on 64-bit architectures?

> Daniel.

cu
Adrian

Bug#1028104: libboost-dev: Boost with C++20 uses unavailable std functions

[R4SAS]

Package: libboost-dev
Version: 1.74.0.3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: r4...@i2pd.xyz

When I'm trying to build upstream i2pd, which uses Boost ASIO using g++ with 
C++20 enabled 
(https://github.com/PurpleI2P/i2pd/commit/a6f9a56e40a40f5a9d153e701a067c5251669ac4),
 g++ throws error:

g++ -g -O2 -ffile-prefix-map=/github/workspace=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -pedantic -std=c++20 -fPIC -DUSE_UPNP 
-D__AES__ -maes -MMD -MP -Ilibi2pd -Ilibi2pd_client -Ii18n 
-DOPENSSL_SUPPRESS_DEPRECATED  -c -o obj/libi2pd/Crypto.o libi2pd/Crypto.cpp
In file included from /usr/include/boost/asio.hpp:23,
 from libi2pd/Timestamp.h:16,
 from libi2pd/TunnelBase.h:14,
 from libi2pd/Crypto.cpp:17:
/usr/include/boost/asio/awaitable.hpp: In constructor 
‘boost::asio::awaitable::awaitable(boost::asio::awaitable&&)’:
/usr/include/boost/asio/awaitable.hpp:68:19: error: ‘exchange’ is not a member 
of ‘std’; did you mean ‘std::__atomic_impl::exchange’?
   68 | : frame_(std::exchange(other.frame_, nullptr))
  |   ^~~~
In file included from /usr/include/c++/12/bits/shared_ptr_atomic.h:33,
 from /usr/include/c++/12/memory:78,
 from libi2pd/Crypto.cpp:13:
/usr/include/c++/12/bits/atomic_base.h:976:7: note: 
‘std::__atomic_impl::exchange’ declared here
  976 |   exchange(_Tp* __ptr, _Val<_Tp> __desired, memory_order __m) 
noexcept
  |   ^~~~

Looks like boost is using deprecated or removed C++20 functions.
Tests are done on latest debian:bookworm docker image.


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

Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages libboost-dev depends on:
ii  libboost1.74-dev  1.74.0-18.1

libboost-dev recommends no packages.

Versions of packages libboost-dev suggests:
pn  libboost-doc  

-- no debconf information

Bug#1027367: (no subject)

[Daniel Swarbrick]

Paraphrasing myself from #1027365, this package's tests will pass (even 
without tzdata present) if "-tags timetzdata" is used, e.g. by  
overriding dh_auto_test.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028103: adduser: [INTL:pt] Update on Portuguese translation of MANPAGE

[Américo Monteiro]

Package: adduser
Version: 3.130
Tags: l10n, patch-
Severity: wishlist

Updated Portuguese translation for  adduser's manpage
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro



adduser_manpage_3.130_pt.po.gz
Description: application/gzip

Bug#1027366: (no subject)

[Daniel Swarbrick]

Paraphrasing myself from #1027365, this package's tests will pass (even 
without tzdata present) if "-tags timetzdata" is used, e.g. by 
overriding dh_auto_test.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028102: secnet FTBFS: eax-aes-test failure

[Adrian Bunk]

Source: secnet
Version: 0.6.5
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=secnet=0.6.5
https://buildd.debian.org/status/fetch.php?pkg=secnet=amd64=0.6.5%2Bb1=1673039054=0

...
./eax-aes-test <./eax-aes-test.vectors >eax-aes-test.confirm.new
spawn:
Jan  6 21:04:09 Now in PHASE_READCONFIG
adns [2238721]: /etc/resolv.conf:15: unknown option `trust-ad'
Jan  6 21:04:09 Running hooks for PHASE_SHUTDOWN...
Jan  6 21:04:09 Now in PHASE_SHUTDOWN
Jan  6 21:04:09 secnet fatal error: Failed to initialise ADNS: No such file or 
directory
 UDP_PRELOAD_DIR=/<>/stest/d-basic-kex/s 
LD_PRELOAD=/<>/stest/udp-preload.sospawn:
reaped secnet in/inside: 2238721 EXIT 2
FINISHING 1
 UDP_PRELOAD_DIR=/<>/stest/d-basic-kex/s 
LD_PRELOAD=/<>/stest/udp-preload.somv -f eax-aes-test.confirm.new 
eax-aes-test.confirm
make[3]: *** [stest/Dir.mk:44: stest/d-basic-kex/ok] Error 1
make[3]: *** Waiting for unfinished jobs
spawn:
Jan  6 21:04:09 Now in PHASE_READCONFIG
adns [2238730]: /etc/resolv.conf:15: unknown option `trust-ad'
Jan  6 21:04:09 Running hooks for PHASE_SHUTDOWN...
Jan  6 21:04:09 Now in PHASE_SHUTDOWN
Jan  6 21:04:09 secnet fatal error: Failed to initialise ADNS: No such file or 
directory
 UDP_PRELOAD_DIR=/<>/stest/d-nonnego-on/s 
LD_PRELOAD=/<>/stest/udp-preload.sospawn:
reaped secnet in/inside: 2238730 EXIT 2
FINISHING 1
 UDP_PRELOAD_DIR=/<>/stest/d-nonnego-on/s 
LD_PRELOAD=/<>/stest/udp-preload.somake[3]: *** [stest/Dir.mk:44: 
stest/d-nonnego-on/ok] Error 1
spawn:
Jan  6 21:04:09 Now in PHASE_READCONFIG
adns [2238742]: /etc/resolv.conf:15: unknown option `trust-ad'
Jan  6 21:04:09 Running hooks for PHASE_SHUTDOWN...
Jan  6 21:04:09 Now in PHASE_SHUTDOWN
Jan  6 21:04:09 secnet fatal error: Failed to initialise ADNS: No such file or 
directory
 UDP_PRELOAD_DIR=/<>/stest/d-nonnego-oo/s 
LD_PRELOAD=/<>/stest/udp-preload.sospawn:
reaped secnet in/inside: 2238742 EXIT 2
FINISHING 1
 UDP_PRELOAD_DIR=/<>/stest/d-nonnego-oo/s 
LD_PRELOAD=/<>/stest/udp-preload.somake[3]: *** [stest/Dir.mk:44: 
stest/d-nonnego-oo/ok] Error 1
make[3]: Leaving directory '/<>'
make[2]: *** [stest/Dir.mk:81: stest/check] Error 2

Bug#1028025: hippotat shouldn't be a native package

[Adrian Bunk]

On Fri, Jan 06, 2023 at 11:01:19AM +, Ian Jackson wrote:
>...
> Adrian Bunk writes ("Bug#1028025: hippotat shouldn't be a native package"):
> > After reading the package description, nothing seems to make
> > this package native other than the main maintainer happening
> > to also be a DD.
> > 
> > Please make the package non-native. There should be no downsides
> > in practice,
> 
> I think the downsides is that I would end up splitting the release
> process in a confusing way, given that I intend to release upstream
> and to Debian simultaneously.

You build an orig.tar.xz without debian/ and then let dpkg generate
a source package with debian.tar.xz.

orig.tar.xz can be released as upstream sources.

I don't know what your workflow is, e.g. git-archive(1) with 
export-ignore attribute for debian/ could be used to generate
the orig.tar.xz.

> > and it avoids weirdnesses like an NMU 1.1.3+nmu1 being
> > a new upstream version that other distributions like Yocto or Fedora
> > might integrate in their distribution as 1.1.3+nmu1-1.
> 
> That would be fine ?

There are also other issues, like lack of patch management in the 
package sources if someone else does a security or stable update
of your package. Which makes the changes harder to review for
other people.

All such issues are not fatal and also affect "real" native package
like dpkg or linitian, but this brings us back into the non-quilt
world of dpkg format 1.0 without the option of proper patch management.

Literally 99% of my uploads are NMU/stable/LTS uploads of packages other 
people maintain, seeing changes from previous NMU/stable/LTS uploads
as series of patches helps me and being able to split my own changes
into separate patches makes it easier for other people to review my
changes.

> Ian.

cu
Adrian

Bug#1027365: golang-github-go-playground-locales: FTBFS in bullseye (missing build-depends on tzdata)

[Daniel Swarbrick]

Aha, reading the docs for the Go tzdata package more thoroughly sheds 
some light on the topic:


> Package tzdata provides an embedded copy of the timezone database. If 
this package is imported anywhere in the program, then if the time 
package cannot find tzdata files on the system, it will use this 
embedded information.

>
> This package should normally be imported by a program's main package, 
not by a library. ...

>
> This package will be automatically imported if you build with -tags 
timetzdata.


Since golang-github-go-playground-locales neither imports time/tzdata, 
nor specifies "-tags timetzdata" anywhere, it stands to reason that this 
FTBFS without the tzdata package available on the system.


All tests pass if "-tags timetzdata" is specified.

So, in keeping with Go's recommendation that time/tzdata should not be 
imported by a library, does it actually make sense to make this package 
Build-Depend on tzdata, when this can be as easily resolved as passing 
"tags timetzdata" to dh_auto_test? It seems like it's the responsibility 
of the app which _uses_ this library to import tzdata - not the 
responsibility of the library itself.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028101: RFS: texinfo/7.0.1-3 -- Documentation system for on-line information and printed output

[Hilmar Preusse]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : texinfo
   Version  : 7.0.1-3
   Upstream contact : Help TexInfo 
 * URL  : https://www.gnu.org/software/texinfo/
 * License  : GFDL-1.3+, GPL-3+
 * Vcs  : https://github.com/debian-tex/texinfo
   Section  : doc

I'm aware of the lintian "source-is-missing" error. The issue has
been forwarded to upstream and will be addressed in next upstream
patch release.

The source builds the following binary packages:

  texinfo - Documentation system for on-line information and printed output
  texinfo-lib - Libraries needed by the texinfo package
  info - Standalone GNU Info documentation browser
  install-info - Manage installed documentation in info format

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

  https://mentors.debian.net/package/texinfo/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/texinfo/texinfo_7.0.1-3.dsc

Changes since the last upload:

 texinfo (7.0.1-3) experimental; urgency=medium
 .
   * Move arch dependent parts of texinfo into separate package
 texinfo-lib.
   * Remove very outdated constraints, pointing to tetex*.
   * Lintian:
 - Migrate lintian overrides to new []-format to get rid of
   "mismatched-override".
 - Remove unused overrides.
 - Add overrides for bogus "very-long-line-length-in-source-file" and
   "source-is missing".
 - Add overrides for bogus "debian-news-entry-has-unknown-version"
 - "license-problem-gfdl-non-official-text": override and fix.
 - Fix "bad-whatis" in texi2dvi.1 manual page.
 - Fix "no-dep5-copyright".

Regards,
-- 
  Hilmar Preusse


signature.asc
Description: PGP signature

Bug#840160: RFP: mullvad-client -- client for VPN service Mullvad

[Ben Finney]

On 06-Jan-2023, Rock Storm wrote:

> A long time ago you requested/volunteered to package the Mullvad client
> app. Did you get anywhere with it?

I did not; the bug report #840160 was correctly retitled to an RFP and I no
longer intend to create or maintain that package.

> May I know what were the issues (if any) why this app never made it into
> the archive?

At the time of declaring the ITP, I was in private communication with the
Mullvad developers. They told me the code was ready to be published as free
software "soon" and that they'd be getting back to me when it was ready.

They did not contact me again, and I don't know anything more from them.

> I thought of packaging and had a look at the app's code on GitHub and it
> looks quite a complex app now written in languages I'm not familiar with
> (yet). So any insights would be appreciated.

I wish you luck! It would be good to get the Mullvad VPN client in shape
for Debian.

-- 
 \ “The greater the artist, the greater the doubt; perfect |
  `\   confidence is granted to the less talented as a consolation |
_o__)   prize.” —Robert Hughes |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1020617: src:openlibm: fails to migrate to testing for too long: FTBFS on armhf and mips64el

[Adrian Bunk]

Hi,

could someone make a maintainer upload with my fix that is already
in salsa git master?

Thanks
Adrian


On Sat, Sep 24, 2022 at 12:46:42PM +0200, Paul Gevers wrote:
> Source: openlibm
> Version: 0.7.0+dfsg-2
> Severity: serious
> Control: close -1 0.8.1+dfsg-2
> Tags: sid bookworm
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 60 days as having a Release Critical bug in testing
> [1]. Your package src:openlibm has been trying to migrate for 61 days [2].
> Hence, I am filing this bug. Your package failed to build from source on
> armhf and mips64el while it built successfully there before.
> 
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on other
> packages, which makes preparing for the release more difficult. Finally, it
> often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that hamper
> the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new bugs,
> there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if that
> version or a later version migrates, this bug will no longer affect testing.
> I have also tagged this bug to only affect sid and bookworm, so it doesn't
> affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to issues
> beyond your control, don't hesitate to contact the Release Team.
> 
> Paul
> 
> [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
> [2] https://qa.debian.org/excuses.php?package=openlibm
rian

Bug#1027365: golang-github-go-playground-locales: FTBFS in bullseye (missing build-depends on tzdata)

[Daniel Swarbrick]

I am able to reproduce the FTBFS in a schroot, sans tzdata package.

However, this is weird, because Go ships with an embedded copy of tzdata 
(https://pkg.go.dev/time/tzdata). AFAICT, this is not stripped out in 
Debian golang-go packages.


Only selected tests fails, and only those which reference certain timezones:

--- FAIL: TestFmtTimeFull (0.00s)
    en_test.go:673: Expected '' Got 'unknown time zone 
America/Toronto'


--- FAIL: TestFmtTimeFull (0.00s)
    ja_test.go:641: Expected '' Got 'unknown time zone Asia/Tokyo'

--- FAIL: TestFmtTimeFull (0.00s)
    ja_JP_test.go:641: Expected '' Got 'unknown time zone Asia/Tokyo'

--- FAIL: TestFmtTimeFull (0.00s)
    ru_RU_test.go:834: Expected '' Got 'unknown time zone 
America/Toronto'


I don't quite understand what America/Toronto has got to do with the 
ru_RU locale, however that zone appears in virtually all other 
"unrelated" tests (albeit commented out). It looks like an oversight 
that it was uncommented in the ru_RU_test.go.


In fact, the _only_ two timezones referred to in this package are 
"America/Toronto" (always commented out except in en_test and 
ru_RU_test.go), and "Asia/Tokyo" - so perhaps it's not just something 
that affects certain timezones, but rather the mere fact that the 
package only refers to a tiny subset of the available timezones.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028071: im-config: Does not start using startx

[Gunnar Hjalmarsson]

On 2023-01-06 14:55, wsy wrote:

Since 0.53-1, /etc/X11/Xsession.d/70im-config_launch checks
"$XDG_SESSION_TYPE" = "x11" before launch. I use startx from console
to start awesome wm, but $XDG_SESSION_TYPE is set to "tty" using
startx. So no ime for me since this version.


Thanks for reporting that so fast! I think I will change it to

[ "$XDG_SESSION_TYPE" != "wayland" ]

and upload instantly so the mistake doesn't make it to testing.

--
Rgds,

Gunnar Hjalmarsson

Bug#1028031: Acknowledgement (Main spamassassin.service file missing)

[Noah Meyerhans]

On 1/5/2023 7:11 PM, Matt Corallo wrote:
Ah, sorry for the noise, the package was split. Seems funny to do in a 
backport.


backports pull changes from what's in bookworm (testing). Nothing was 
"done" in the backport, it was a straight pull.  Preserving bullseye's 
package structure would have been significant packaging work and 
wouldn't constitute a backport or be appropriate for bullseye-backports.


Should the package split get a changelog notice for the bullseye 
upgrade? I'd assume most users of spamassassin actually use the spamd 
feature, so it being silently removed may be surprising for an upgrade.


I guess apt didn't show /usr/share/doc/spamassassin/NEWS.Debian.gz when 
you upgraded, but it's all documented there.


noah

Bug#1028100: Anbox's README.Debian points to a defunct website for downloading images

[Alain Knaff]

Package: anbox
Version: 0.0~git20210106-1

Hi,

In order to use the anbox android emulator, you first need to download
an android image, and put it into /var/lib/anbox/android.img.

/usr/share/doc/anbox/README.Debian gives a source URL for these images:
https://build.anbox.io/android-images
but unfortunately the site seems to be defunct. Name is still defined,
but connection attempts time out.

Please update with an URL that is still valid today

Thanks,

Alain

Bug#1027176: u-boot-amlogic: broken non-EFI boot on amlogic boards

[Vagrant Cascadian]

Control: forwarded 1027176 
https://lists.denx.de/pipermail/u-boot/2023-January/503745.html

On 2023-01-06, Vagrant Cascadian wrote:
> On 2023-01-05, Vagrant Cascadian wrote:
>> There has been some recent discussion in irc.libera.chat #u-boot and
>> #linux-amlogic about this issue, so the possibility of an upstream fix
>> coming is not impossible.
>
> Hopefully we'll see a proper fix coming from upstream... :)

And we may have just that:

  https://lists.denx.de/pipermail/u-boot/2023-January/503745.html

  
https://patchwork.ozlabs.org/project/uboot/list/?series=335240=both=*

Will test shortly...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#608013: recode h..us doesn't replace with ASCII equivalents

[Santiago Vila]

El 5/9/20 a las 0:18, Reuben Thomas escribió:

On Sun, 26 Dec 2010 07:58:49 +0800 jida...@jidanni.org 
 wrote:
 >
 > I note that recode --force h..us causes » to disappear, when it
 > could easily better make a >>, or " like uni2ascii -B.

In other words, doing something with `--force` can go wrong. Not a bug.

 > OK, recode h..utf8|uni2ascii -B works.

And recoding to a charset that contains the relevant characters works.

Conclusion: there's no bug here.


Closing as a non-bug, then.

Thanks a lot.

Bug#1026723: close bugs created by leiningen breakage

[Louis-Philippe Véronneau]

Hi,

These bugs have been fixed with the upload of leiningen 2.10.0-1.

Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027176: u-boot-amlogic: broken non-EFI boot on amlogic boards

[Vagrant Cascadian]

Control: severity 1027176 important

On 2023-01-05, Vagrant Cascadian wrote:
> Control: retitle 1027176 u-boot-amlogic: broken non-EFI boot on amlogic boards
...
> At this point, I am assuming that all the amlogic builds are affected,
> and worst case we include the "noefi" workaround for all boards.

I went ahead and uploaded 2023.01-rc4 to unstable with this as a
workaround.

> There has been some recent discussion in irc.libera.chat #u-boot and
> #linux-amlogic about this issue, so the possibility of an upstream fix
> coming is not impossible.

Hopefully we'll see a proper fix coming from upstream... :)

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1013213: gftools: version outdated, blocking build of cascadia code

[Fabian Greffrath]

On Sun, 17 Jul 2022 15:38:56 +0200 Agathe Porte 
wrote:
> python-gflanguages has been uploaded to NEW.
> 
> Now ITP glyphsets [1] is blocking this upgrade

Now both python-gflanguages and python-glyphsets have fond their way
into Debian.

 - Fabian


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

Bug#952732: recode: Incorrect encoding of some characters when recoding to HTML_1.1

[Santiago Vila]

El 28/2/20 a las 17:33, Paul Courbis escribió:

Le ven. 28 févr. 2020 à 15:45, Reuben Thomas mailto:r...@sc3d.org>> a écrit :

On Fri, 28 Feb 2020 at 09:00, Paul Courbis BV mailto:paul-report...@courbis.net>> wrote:

    * What was the outcome of this action?
    Incorrect HTML code :
    


As far as I can tell from looking at the code, these names are correct for HTML 
1.1. The new names are used in HTML 1.2 
(https://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt 
) and later (and recode 
generates them correctly for those versions too, though recode only recognises 
version 2, not 1.2).

I'm afraid I can't find a spec for HTML 1.1 online; it seems to be so old 
that it's not really considered a standard at all, and in any case there's no 
reason to be using it. I'm reluctant to make any changes without definitive 
documentation: looking at the code, this coding in recode has not changed since 
recode 3.4 in 1994, and François Pinard was pretty careful about this sort of 
thing (and both those letters are in his first language).


My bad
These characters where defined by https://tools.ietf.org/html/rfc1866 
 for HTML 2.0
  and echo "î" | recode UTF_8..HTML_2.0 gives the correct answer


I understand that this was not a bug after all. Closing then without version.

Thanks.

Bug#1028034: Fwd: Re: pipewire | Multi-profile bluetooth headphones show only a2dp profile (#2936)

[Dylan Aïssi]

Thanks!

Le ven. 6 janv. 2023 à 19:57, Bob Hauck  a écrit :
>
> There was apparently a bug already filed and closed about this. Subsequent to 
> my report I received the following note that there is a commit to master that 
> fixes the issue.
>> Distro maintainers including the Debian one were notified on December 27th 
>> that they should consider applying the commit c7b3ef0d but it was during the 
>> holiday season and only a maybe, so I'm not sure if that fix was deployed to 
>> Debian or not.
>

I just uploaded a new package version with this upstream fix.
0.3.63-2 should be available soon in debian/unstable.

Best,
Dylan

Bug#1027298: libreoffice 7.0.4-4+deb11u5 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1027298 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: libreoffice
Version: 7.0.4-4+deb11u5

Explanation: change Croatia's default currency to Euro

Bug#688318: tzdata packages updates consistently cause /etc/timezone to be reset to an undesirable value

[Benjamin Drung]

On Fri, 21 Sep 2012 09:25:50 -0500 Shelby Cain 
wrote:
> Package: tzdata
> Version: 2012e-0ubuntu0.12.04.1
> Severity: important
> 
> Every time an update to the tzdata package is published, it results in
my /etc/timezone being reset from 
> "US/Central" to "America/Chicago".  While technically America/Chicago
is indeed the same timezone, it is 
> unintuitive to say the least considering the fact that I live 929
miles (~1500 km) from Chicago, Illinois.

There are symlinks in /usr/share/zoneinfo for backward compatibility.
US/Central is a symlink pointing to America/Chicago.

The Debian package updates some of those backward compatible symlinks to
their new targets (see convert_timezone in debian/tzdata.config). This
is useful for changes like renaming Kiev to Kyiv. These timezones that
are updated are not presented as option in debconf – except for the
symlinks in US. This is inconsistent and needs to be fixed.

So there are two possible solution:

1. Drop the US area from the debconf template. Then only continents and
oceans remain as areas. This would be more consistent.

2. Drop the US/* timezones from convert_timezone.

It tend to prefer option one (for consistency), but I can see that users
might find option two easier for them.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1028099: [libtepl-6-2] package upgrade error

[Lyndon Brown]

Package: libtepl-6-2
Version: 6.4.0-3
Severity: serious

Ran into an upgrade issue on Sid today. Seems libtepl-6-1 did not get
removed before trying to install libtepl-6-2, causing the libtepl-6-2
install to fail, and consequently cascading failures from there.

Output of first aptitude upgrade command:

```
$ sudo aptitude upgrade
Resolving dependencies...
The following NEW packages will be installed:
  libtepl-6-2{a} 
The following packages will be REMOVED:
  libtepl-6-1{u} 
The following packages will be upgraded:
  gedit gedit-plugin-bookmarks gedit-plugin-bracket-completion 
gedit-plugin-character-map 
  gedit-plugin-code-comment gedit-plugin-color-picker 
gedit-plugin-color-schemer 
  gedit-plugin-draw-spaces gedit-plugin-git gedit-plugin-join-lines 
gedit-plugin-multi-edit 
  gedit-plugin-session-saver gedit-plugin-smart-spaces gedit-plugin-synctex 
  gedit-plugin-terminal gedit-plugin-text-size gedit-plugin-word-completion 
  gedit-plugins-common gnustep-base-common gnustep-base-runtime imagemagick 
  imagemagick-6-common imagemagick-6.q16 libapache-pom-java libbcmail-java 
libbcpkix-java 
  libbcprov-java libbcutil-java libgnustep-base1.28 libmagick++-6.q16-8 
libmagickcore-6.q16-6 
  libmagickwand-6.q16-6 
The following packages are RECOMMENDED but will NOT be installed:
  libmagickcore-6.q16-6-extra 
32 packages upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
Need to get 16.3 MB of archives. After unpacking 1,024 B will be freed.
Do you want to continue? [Y/n/?] y
Get: 1 https://deb.debian.org/debian sid/main amd64 libtepl-6-2 amd64 6.4.0-3 
[122 kB]
Get: 2 https://deb.debian.org/debian sid/main amd64 gedit amd64 43.2-2+b1 [364 
kB]
Get: 3 https://deb.debian.org/debian sid/main amd64 gedit-plugins-common amd64 
43.1-1+b1 [293 kB]
Get: 4 https://deb.debian.org/debian sid/main amd64 gedit-plugin-draw-spaces 
amd64 43.1-1+b1 [19.9 kB]
Get: 5 https://deb.debian.org/debian sid/main amd64 imagemagick-6-common all 
8:6.9.11.60+dfsg-1.4 [165 kB]
Get: 6 https://deb.debian.org/debian sid/main amd64 libmagickcore-6.q16-6 amd64 
8:6.9.11.60+dfsg-1.4 [1,780 kB]
Get: 7 https://deb.debian.org/debian sid/main amd64 libmagickwand-6.q16-6 amd64 
8:6.9.11.60+dfsg-1.4 [407 kB]
Get: 8 https://deb.debian.org/debian sid/main amd64 gedit-plugin-bookmarks 
amd64 43.1-1+b1 [30.6 kB]
Get: 9 https://deb.debian.org/debian sid/main amd64 
gedit-plugin-bracket-completion amd64 43.1-1+b1 [17.9 kB]
Get: 10 https://deb.debian.org/debian sid/main amd64 gedit-plugin-character-map 
amd64 43.1-1+b1 [21.1 kB]
Get: 11 https://deb.debian.org/debian sid/main amd64 gedit-plugin-code-comment 
amd64 43.1-1+b1 [22.0 kB]
Get: 12 https://deb.debian.org/debian sid/main amd64 gedit-plugin-color-picker 
amd64 43.1-1+b1 [22.4 kB]
Get: 13 https://deb.debian.org/debian sid/main amd64 gedit-plugin-color-schemer 
amd64 43.1-1+b1 [18.9 kB]
Get: 14 https://deb.debian.org/debian sid/main amd64 gedit-plugin-git amd64 
43.1-1+b1 [24.4 kB]
Get: 15 https://deb.debian.org/debian sid/main amd64 gedit-plugin-join-lines 
amd64 43.1-1+b1 [22.1 kB]
Get: 16 https://deb.debian.org/debian sid/main amd64 gedit-plugin-multi-edit 
amd64 43.1-1+b1 [28.4 kB]
Get: 17 https://deb.debian.org/debian sid/main amd64 gedit-plugin-session-saver 
amd64 43.1-1+b1 [20.4 kB]
Get: 18 https://deb.debian.org/debian sid/main amd64 gedit-plugin-smart-spaces 
amd64 43.1-1+b1 [10.7 kB]
Get: 19 https://deb.debian.org/debian sid/main amd64 gedit-plugin-synctex amd64 
43.1-1+b1 [20.0 kB]
Get: 20 https://deb.debian.org/debian sid/main amd64 gedit-plugin-terminal 
amd64 43.1-1+b1 [20.6 kB]
Get: 21 https://deb.debian.org/debian sid/main amd64 gedit-plugin-text-size 
amd64 43.1-1+b1 [19.0 kB]
Get: 22 https://deb.debian.org/debian sid/main amd64 
gedit-plugin-word-completion amd64 43.1-1+b1 [24.6 kB]
Get: 23 https://deb.debian.org/debian sid/main amd64 libgnustep-base1.28 amd64 
1.28.1-2 [1,595 kB]
Get: 24 https://deb.debian.org/debian sid/main amd64 gnustep-base-runtime amd64 
1.28.1-2 [445 kB]
Get: 25 https://deb.debian.org/debian sid/main amd64 gnustep-base-common all 
1.28.1-2 [296 kB]
Get: 26 https://deb.debian.org/debian sid/main amd64 imagemagick-6.q16 amd64 
8:6.9.11.60+dfsg-1.4 [338 kB]
Get: 27 https://deb.debian.org/debian sid/main amd64 imagemagick amd64 
8:6.9.11.60+dfsg-1.4 [121 kB]
Get: 28 https://deb.debian.org/debian sid/main amd64 libapache-pom-java all 
29-1 [5,340 B]
Get: 29 https://deb.debian.org/debian sid/main amd64 libbcprov-java all 1.72-2 
[8,225 kB]
Get: 30 https://deb.debian.org/debian sid/main amd64 libbcutil-java all 1.72-2 
[580 kB] 
Get: 31 https://deb.debian.org/debian sid/main amd64 libbcpkix-java all 1.72-2 
[856 kB] 
Get: 32 https://deb.debian.org/debian sid/main amd64 libbcmail-java all 1.72-2 
[149 kB] 
Get: 33 https://deb.debian.org/debian sid/main amd64 libmagick++-6.q16-8 amd64 
8:6.9.11.60+dfsg-1.4 [242 kB]
Fetched 16.3 MB in 12s (1,351 kB/s) 
  

Bug#1028097: mplcursors: remove Build-Depends: libopenblas0 (use libblas-dev instead)

[Drew Parsons]

Actually looking more closely at the source, mplcursors doesn't even use 
BLAS at all.


In that case just remove the libopenblas0 dependency altogether (both 
Build-Depends: and Depends: for the binary package).

Bug#502468: keychain: always starts a new ssh-agent with --inherit any and SSH_AUTH_SOCK not set

[Peter Pentchev]

On Thu, Oct 16, 2008 at 02:09:30PM -0400, Andrew Schulman wrote:
> Package: keychain
> Version: 2.6.8-2
> Severity: normal
> 
> 
> When SSH_AUTH_SOCK is not set, keychain --inherit any never finds
> an existing ssh-agent.  It always starts a new one:
> 
> $ echo $SSH_AUTH_SOCK
> $ cat .keychain/helium-sh
> SSH_AUTH_SOCK=/tmp/ssh-AeUWcuq462/agent.462; export SSH_AUTH_SOCK;
> SSH_AGENT_PID=463; export SSH_AGENT_PID;
> $ pgrep -U andrex ssh-agent
> 463
> $ keychain --inherit any

Hi,

I'm sorry for not replying to this bug report earlier when I adopted
the Debian package of keychain. Also, yeah, I realize that the bug
report was filed a long time ago and you may have moved on.

Still... are you sure that `--inherit any` is what you want to use in
this case? Would `--inherit any-once` not be better? When I try
running keychain after a ~/.keychain/-sh file has already
been created, `--inherit any-once` looks at the file and uses
the already running SSH agent.

Again, sorry for not replying sooner!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1028054: bullseye-pu: package macromoleculebuilder_3.2+dfsg-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2023-01-06 at 16:08 +0200, Andrius Merkys wrote:
> On 2023-01-06 15:18, Adam D. Barratt wrote:
> > Hmmm. How did it manage to build initially, then?
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=macromoleculebuilder=amd64=3.2%2Bdfsg-2=1608131113=0
> >   appears to be the version in bullseye currently, and only
> > mentions
> > docbook-xsl once, in the list of Suggest:ed packages.
> 
> No idea. Maybe some of the dependencies has changed since then?

I guess so.

As you mentioned that you've tested the change, please go ahead.

Regards,

Adam

Bug#1026793: docker.io: --memory-swap not enforced on systemd cgroup driver

[Saj Goonatilleke]

Hi Shengjing,

On 2 Jan 2023, at 6:44, Shengjing Zhu wrote:
> Can't reproduce it on bullseye as well.

You are right:  something is missing from the original report.
Now I am unable to reproduce the problem on the same machine
that first exhibited the problem.

Either this is a case of user error on my part,
or the problem only strikes when some other variable -- so far unknown --
is also present.

I have reinstated our production experiment using the same config from before.
I surveyed one machine by hand and it looked OK.  Data from the others
should trickle in over the coming days.  If everything looks still looks OK,
I suppose we'll just put this one down to PEBKAC.

Will make a note to follow up here next week.

Thank you!

Bug#1028024: libcommons-parent-java: regression between 43-1 and 55-1: Failed to read artifact descriptor for org.apache.commons:commons-compress:jar:debian

[Louis-Philippe Véronneau]

On Fri, 6 Jan 2023 10:22:27 -0500 =?UTF-8?B?SsOpcsO0bWUgQ2hhcmFvdWk=?= 
 wrote:
Looking at the pom.xml diff, it seems that version 55-1 introduced a 
dependency on org.junit/junit-bom, which is not packaged in Debian.


org.junit/junit-bom is packaged in Debian, as part of the junit5 package:

junit5: 
/usr/share/maven-repo/org/junit/junit-bom/debian/junit-bom-debian.pom


It's probably not a good idea to include it as a dependency for 
libcommons-parent-java though...


--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028044: $bf->strip can't strip duplicated flags

[Guillem Jover]

Hi!

On Fri, 2023-01-06 at 16:58:44 +0800, Shengjing Zhu wrote:
> Package: libdpkg-perl
> Version: 1.21.13
> Severity: normal
> X-Debbugs-Cc: z...@debian.org

> Given input `-flto=auto -flto=auto`, $bf->strip($flag, "-flto=auto") returns
> `-flto=auto`.
> However if given `-flto=auto -ffat-lto-objects -flto=auto`, it will return
> `-ffat-lto-objects`. (two -flto=auto are tripped)
> 
> I read the code has `g` in regexp, so I think you want to strip duplicated
> flag. But the regexp pattern is bit buggy when two duplicated flags are 
> together.

Ah, indeed nice catch, this is caused due to the space left at the
beginning which then does not match on the subsequent iteration.
Fixing it for 1.21.18.

> Background:
> 
> In dh-golang, I use $bf->strip to strip lto flags
> https://salsa.debian.org/go-team/packages/dh-golang/-/merge_requests/18
> 
> It works for a while in Debian. But I found Ubuntu still carries an LTO
> patch in the Go compiler. Then I wonder whether my dh-golang hack doesn't
> work for them.
> 
> In Ubuntu, for unknown reason, their dpkg-buildflags gives a duplicated lto
> flags. `-flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects`.
> After $bf->strip($flag, "-ffat-lto-objects -flto=auto"), it becomes 
> `-flto=auto`.
> Still one lto flag left...

This is a problem in the Ubuntu dpkg delta, which they have
kept incorrectly rebasing, and have been applying the off-tree lto patch
even after it got merged upstream, so now they are injecting these twice.
I mentioned this at the time, and reminded the recent person doing the
merge to fix, but that's entirely on their hands.

Thanks,
Guillem

Bug#1026849: ax25-apps: ax25mond(8) manual page contains wrong name

[Nate Bargmann]

* On 2023 06 Jan 12:49 -0600, Daniele Forsi wrote:
> Hello Nate,
> 
> I fixed the wrong name (and some spelling errors) in Salsa:
> https://salsa.debian.org/debian-hamradio-team/ax25-apps

Thanks, Daniele.

> What is the address of the upstream git repository that you tested?

The canonical Git repository is at:

https://linux-ax25.in-berlin.de/cgit/ax25-apps.git/

The libax25 and ax25-tools repositories are accessible from:

https://linux-ax25.in-berlin.de/cgit

The old URL of: linux-ax25.org is said to be having DNS issues and the
main site is now:  https://linux-ax25.in-berlin.de

73, Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Bug#1010918: Intent to NMU uif to fix longstanding l10n bugs

[Helge Kreutzmann]

Hello Mike,
I intend to NMU uif around 2023-01-21 to fix longstanding l10n
bugs. The changelog would be something like the following:

 uif (1.99.0-4.1) UNRELEASED; urgency=medium
 .
   * Non-maintainer upload.
   * Update debconf template translation
 - Dutch translation.
   Thanks to Frans Spiesschaert (Closes: #1010774)
 - French translation.
   Thanks bubu (Closes: #1010918)
 - Brazilian Portuguese translation.
   Thanks Adriano Rafael Gomes (Closes: #1011023)
 - Russian translation.
   Thanks Shilin Aleksej (Closes: #1011641)
 - German translation.
   Thanks Helge Kreutzmann (Closes: #1015153)

Please tell me if you are currently preparing a new release yourself
and would like me to skip the NMU.

Greetings

 Helge

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


signature.asc
Description: PGP signature

Bug#1004011: Kindly upload with debconf translations?

[Helge Kreutzmann]

Hello Lamont,
On Fri, Jan 06, 2023 at 02:11:52PM -0500, Scott Kitterman wrote:
> On Friday, January 6, 2023 1:23:00 PM EST Helge Kreutzmann wrote:
> > Hello Lamont,
> > the development of bookworm is coming to an end. Currently, there are
> > several debconf translations in the BTS:
> > - German (#1004011)
> > - Brazilian Portuguese (#1024200)
> > - Dutch (#1025842,#1004316)
> > 
> > Adding debconf translations is very easy. Simply drop the file in the
> > bug reports in ./debian/po/ and perform an upload.
> > 
> > It would be very kind if you could do this before release, ideally
> > before the freeze.
> > 
> > I tried to rebuild your package, however, I did not suceed:
> 
> Thanks.  That's a relatively easy problem to fix.  I do intend to update the 
> package before the freeze with the debconf translation updates.

Thank you very much!

Greetings

   Helge


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


signature.asc
Description: PGP signature

Bug#1004011: Kindly upload with debconf translations?

[Scott Kitterman]

On Friday, January 6, 2023 1:23:00 PM EST Helge Kreutzmann wrote:
> Hello Lamont,
> the development of bookworm is coming to an end. Currently, there are
> several debconf translations in the BTS:
> - German (#1004011)
> - Brazilian Portuguese (#1024200)
> - Dutch (#1025842,#1004316)
> 
> Adding debconf translations is very easy. Simply drop the file in the
> bug reports in ./debian/po/ and perform an upload.
> 
> It would be very kind if you could do this before release, ideally
> before the freeze.
> 
> I tried to rebuild your package, however, I did not suceed:

Thanks.  That's a relatively easy problem to fix.  I do intend to update the 
package before the freeze with the debconf translation updates.

Scott K

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

Bug#1028098: dballe: binary-all FTBFS

[Adrian Bunk]

Source: dballe
Version: 9.3-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=dballe=all=9.3-2=1672991515=0

...
   dh_missing -i -O-Smeson -O--parallel
dh_missing: warning: usr/include/dballe/dballef.mod exists in debian/tmp but is 
not installed to anywhere 
dh_missing: error: missing files, aborting
...

Bug#1028034: Fwd: Re: pipewire | Multi-profile bluetooth headphones show only a2dp profile (#2936)

[Bob Hauck]

There was apparently a bug already filed and closed about this. Subsequent to 
my report I received the following note that there is a commit to master that 
fixes the issue.

 Original Message 
Subject: Re: pipewire | Multi-profile bluetooth headphones show only a2dp 
profile (#2936)
Date: Friday, January 06, 2023 10:05 AM PST
From: Niklāvs Koļesņikovs (@pinkflames) 
Reply-To: GitLab 

To: b...@haucks.org
References: 

Niklāvs Koļesņikovs commented:
Distro maintainers including the Debian one were notified on December 27th that 
they should consider applying the commit c7b3ef0d but it was during the holiday 
season and only a maybe, so I'm not sure if that fix was deployed to Debian or 
not.
—
View it on GitLab.
You're receiving this email because of your account on gitlab.freedesktop.org. 
Unsubscribe from this thread · Manage all notifications · Help 
{"@context":"http://schema.org","@type":"EmailMessage","action":{"@type":"ViewAction","name":"View
 
Issue","url":"https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2936#note_1711436"}}***>

-- 
Sent from my private email server! @gitlab.freedesktop.org>

Bug#1026120: git-buildpackage: issues with upstreams LFS files

[Guido Günther]

Hi,
On Wed, Dec 21, 2022 at 03:04:43PM +0700, Arnaud Rebillout wrote:
> 
> On 15/12/2022 15:54, Guido Günther wrote:
> > Or use `gbp clone --git-defuse-attributes=off ...` ?
> 
> Indeed! Thanks, I didn't notice this option, and I can confirm that it
> solves the issue (the exact option name is "--defuse-gitattributes=off"
> actually).
> 
> I took the time to look a bit at this option and where it comes from
> (seemingly, the goal is that gbp is compatible with other tools such as
> dgit). There's still something that strikes me.
> 
> IIUC, it's *only* "gbp clone" that will defuse the git attributes.
> 
> So developer A does "gbp import-orig", brings in the offending attributes:
> still they are not defused on their local copy. Then developer B does "gbp
> pull", and then no change: gbp does not defuse attributes during pull, so
> attributes are still enabled. Then developer C does "gbp clone", and they
> possibly get a different working copy, because in this case only, attributes
> are defused.
> 
> It seems that this behavior is prone to create problems, albeit it might be
> detected by CI (not sure what Salsa CI does in details), and it's also kind
> of a niche issue anyway.

Changing git attributes is certainly a problem. If someone wants to send
patches to e.g. warn the user about that, that would be useful. That
said I'd expect maintainers to filter out .gitattributes from imported
tarballs (e.g. via uscan / debian/changelog or gbp itself)

I think what we could do is:

- warn about git found in upsteam repos / tarballs
- warn about changing git attributes
- allow to disable the either of these via d/gbo.conf

> We took a look at our packaging repos in Kali Linux (~ 600 repos), and we
> found 3 of them that are unclean on `gbp clone`. It's solved by setting
> --defuse-gitattributes. So we will probably add this argument to our
> .mrconfig, and make sure to use it all the time. We'll see where it
> gets us.

Are these repos based on upstream's git or on tarballs that got those
gitattributes imported?

> 
> I'm really not familiar with git attributes, so I don't have any
> recommendation, or anything else to say, I'm merely reporting in case it
> helps.

We have some tests that test defusing git attributes in gbp. If there's
any of your use cases missing, feel free to add those. That is often
a good step to document expected behavior.

Cheers,
 -- Guido

Bug#1028041: php-excimer: FTBFS on mipsel

[Adrian Bunk]

On Fri, Jan 06, 2023 at 08:59:08AM +0100, Paul Gevers wrote:
> Source: php-excimer
> Version: 1.0.4-1
> Severity: serious
> Tags: ftbfs
> Justification: FTBFS
> 
> Dear maintainer,
> 
> The php8.2 transition started recently, and while going over the
> packages involved I noticed that your latest upload (currently in
> unstable only) is failing to build from source on mipsel.
> 
> It fails its tests.
> =
> FAILED TEST SUMMARY
> -
> ExcimerProfiler CPU profile [tests/cpu.phpt]
> =
> 
> Please fix ASAP to not block the php8.2 transition.

It built after I gave it back to build on the right buildd,
so it's now rebuilt with PHP 8.2.

The issue might depend on buildd speed, or some weird difference 
between buildds.

> Paul
>...

cu
Adrian

Bug#1026849: ax25-apps: ax25mond(8) manual page contains wrong name

[Daniele Forsi]

Hello Nate,

I fixed the wrong name (and some spelling errors) in Salsa:
https://salsa.debian.org/debian-hamradio-team/ax25-apps

What is the address of the upstream git repository that you tested?

--
73 de IU5HKX Daniele

Bug#1022844: man subsection directories are needed for mandoc(1)

[Alejandro Colomar]

Hello Marcos,

On 1/6/23 19:35, Marcos Fouces wrote:

Hello Alejandro,

Debian policy is clear on this point: manual pages should be assigned
to man[1..9]/ dirs [1]. Lintian also issues error tags when this
behavior is not observed [2].

The desired section expressed through the file extension and the .TH
field is not modified. All .so links are corrected to point to the
corresponding man page.

 From dh_installman(1) manual page:

" ...you tell dh_installman what man pages go in your packages, and it
figures out where to install them based on the section field in their
.TH or .Dt line. If you have a properly formatted .TH or .Dt line, your
man page will be installed into the right directory, with the right
name (this includes proper handling of pages with a subsection, like
3perl, which are placed in man3, and given an extension of .3perl). If
your .TH or .Dt line is incorrect or missing, the program may guess
wrong based on the file extension."

What is the precise drawback of this solution?


There are two (not huge drawbacks, but they exist):

-  mandoc(1) (and possibly other software) understands that if a page is in 
directory manX, it is in section X, so it will for example appear in searches of 
pages in that section.


-  3 is for functions and 3const is for constants, so having them separate makes 
it easier to list all functions and all constants in a system (or at least those 
that are documented in manual pages.




Greetings,
Marcos


Cheers,

Alex



[1] https://www.debian.org/doc/debian-policy/ch-docs.html#manual-pages
[2] https://lintian.debian.org/tags/odd-place-for-manual-page


--



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028097: mplcursors: remove Build-Depends: libopenblas0 (use libblas-dev instead)

[Drew Parsons]

Source: mplcursors
Version: 0.5.2-1
Severity: serious
Justification: debci

mplcursors Build-Depends:libopenblas0

This is bad for several reasons.

Firstly, OpenBLAS is not available on all architectures. In particular
it's not available on armel (and mipsel), and therefore debci testing
on armel fails, due to the missing libopenblas0.  That's why I'm
filing this bug as Severity: serious (debci).

Secondly, it's wrong to specify a specific library binary package in
Build-Depends. Build-Depends should be made using the development
package instead, i.e. Build-Depends: libblas-dev.  Note that is not
Build-Depends: libopenblas-dev, see next point.

Thirdly, in regards to BLAS support, all BLAS packages are
binary-compatible, with the preferred BLAS implementation controllable
using the debian alternatives mechanisms.  Even where OpenBLAS is
available, it may not be the best BLAS implementation for the activity
that a particular system performs.  That is, the local admin might
determine that blis or atlas (or intel-mkl) performs better. Not to
mention the various threaded builds which would generally have better
performance than libopenblas0, which is a serial build.

For this reason, debian packages using blas are usually built against
the generic (slow) libblas-dev.  Then one of the performant BLAS
implementation is installed at runtime by the system administrator.

On your own machine you'll want one of the optimised BLAS
implementations installed (libopenblas0, for instance). So to allow
for this the Build-Depends can include alternatives.  But the first
alternative should be the generic development package, libblas-dev, so
that it's used by the debian buildds to build the package.

Thus, the Build-Depends should be something like

  Build-Depends: libblas-dev | libopenblas-dev | libblis-dev | libatlas-base-dev

Bug#1028096: age: Testing migration

[Vincent Blut]

Package: age
Version: 1.0.0-2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Could you please do a source-only upload to allow age migrate into testing?

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCY7hq6QAKCRAQn1qAt/bg
AVptAP9TMNAyQpnB+7u0mdvQbzjlGelr9k3sSEkZA9tFXpLpkgEAwDmxgam8ANTs
m+p88VrIb3ztacANryS/ge7pQ9Z0xww=
=Tdc/
-END PGP SIGNATURE-

Bug#1022844: man subsection directories are needed for mandoc(1)

[Marcos Fouces]

Hello Alejandro,

Debian policy is clear on this point: manual pages should be assigned
to man[1..9]/ dirs [1]. Lintian also issues error tags when this
behavior is not observed [2].

The desired section expressed through the file extension and the .TH
field is not modified. All .so links are corrected to point to the
corresponding man page. 

>From dh_installman(1) manual page:

" ...you tell dh_installman what man pages go in your packages, and it
figures out where to install them based on the section field in their
.TH or .Dt line. If you have a properly formatted .TH or .Dt line, your
man page will be installed into the right directory, with the right
name (this includes proper handling of pages with a subsection, like
3perl, which are placed in man3, and given an extension of .3perl). If
your .TH or .Dt line is incorrect or missing, the program may guess
wrong based on the file extension."

What is the precise drawback of this solution?

Greetings, 
Marcos

[1] https://www.debian.org/doc/debian-policy/ch-docs.html#manual-pages
[2] https://lintian.debian.org/tags/odd-place-for-manual-page

Bug#1028062: debian-installer: Audio-based Installation - Question for keyboard layout and choice of hot keys

[Luna Jernberg]

Hey!

Saw you on IRC earlier today, thanks for sending the email / reporting
the bug :)

On Fri, Jan 6, 2023 at 4:33 PM Samuel Thibault  wrote:
>
> Hello,
>
> Thanks for the feedback.
>
> Peter Schwede, le ven. 06 janv. 2023 13:18:56 +, a ecrit:
> > 1) The hotkeys aren't read aloud most of the time. The engine appears to 
> > silent ?, < and >.
>
> Yes, that's known, it's #690343. The key bindings are documented in the
> accessibility section of the manual.
> https://d-i.debian.org/manual/fr.amd64/ch05s02.html#idm1310
>
> > I suggest to replace them by j, f (and d for example).
>
> We need these to be possibly usable for answering textual questions.
>
> > 2) Having to use a Germany keyboard, I had to web search for the english 
> > keyboard layout to know what key would repeat the current question. I 
> > suggest to move the question about the keyboard layout up a little.
>
> And conversely people have largely told us that we really need to have
> language/country questions very first, before anything else. I don't
> think we can change that.
>
> Samuel
>

Bug#1020215: w3m interprets when not in but in

[Robert Alm Nilsson]

After using my version of w3m every day since I posted this, the only
problem I have noticed on a few pages is that it doesn't handle titles
directly under html tags, so this doesn't work:

Hello

I don't know if we want to care about that case and I don't think it's
valid HTML but I wanted to let you know.

Bug#1004011: Kindly upload with debconf translations?

[Helge Kreutzmann]

Hello Lamont,
the development of bookworm is coming to an end. Currently, there are
several debconf translations in the BTS:
- German (#1004011)
- Brazilian Portuguese (#1024200)
- Dutch (#1025842,#1004316)

Adding debconf translations is very easy. Simply drop the file in the
bug reports in ./debian/po/ and perform an upload.

It would be very kind if you could do this before release, ideally
before the freeze.

I tried to rebuild your package, however, I did not suceed:
helge@twentytwo:/tmp/postfix-3.7.3$ debuild
 dpkg-buildpackage -us -uc -ui
dpkg-buildpackage: Information: Quellpaket postfix
dpkg-buildpackage: Information: Quellversion 3.7.3-2
dpkg-buildpackage: Information: Quelldistribution unstable
dpkg-buildpackage: Information: Quelle geändert durch Scott Kitterman 

 dpkg-source --before-build .
dpkg-buildpackage: Information: Host-Architektur amd64
dpkg-source: Information: Optionen aus postfix-3.7.3/debian/source/options 
werden verwendet: --extend-diff-ignore=^html/
 debian/rules clean
dh clean
   debian/rules override_dh_auto_clean
make[1]: Verzeichnis „/tmp/postfix-3.7.3“ wird betreten
/usr/bin/make tidy
make[2]: Verzeichnis „/tmp/postfix-3.7.3“ wird betreten
/usr/bin/make -f Makefile.in MAKELEVEL= Makefiles
make: Verzeichnis „/tmp/postfix-3.7.3“ wird betreten
(echo "# Do not edit -- this file documents how Postfix was built for your 
machine."; /bin/sh makedefs) >makedefs.tmp
ATTENTION:
ATTENTION: Unknown system type: Linux 6.0.16
ATTENTION:
make: *** [Makefile.in:34: Makefiles] Fehler 1
make: Verzeichnis „/tmp/postfix-3.7.3“ wird verlassen
make[2]: *** [Makefile:22: Makefiles] Fehler 2
make[2]: Verzeichnis „/tmp/postfix-3.7.3“ wird verlassen
make[1]: *** [debian/rules:227: override_dh_auto_clean] Fehler 2
make[1]: Verzeichnis „/tmp/postfix-3.7.3“ wird verlassen
make: *** [debian/rules:61: clean] Fehler 2
dpkg-buildpackage: Fehler: Unterprozess debian/rules clean lieferte Exitstatus 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui failed

If you tell me how to avoid this I can, if you want, perform an L10N NMU, 
just adding these debconf messages. 

Greetings

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


signature.asc
Description: PGP signature

Bug#942755: /usr/sbin/pppd: pppol2tp plugin segfaults when "dump" option specified

[Marco d'Itri]

On Oct 21, Jamie Thompson  wrote:

> ...and I can confirm that removing the option resolved the issue for 
> me. I cannot comment on the analysis offered on the bug report.
Can you still reproduce this bug with ppp 2.4.9?
If so, then please provide a stack trace with symbols.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1028093: warn about python*-dev dependencies breaking cross compilation

[Jelmer Vernooij]

On Fri, Jan 06, 2023 at 06:54:43PM +0100, Helmut Grohne wrote:
> Joe noticed a repetitive cross build failure. Can we turn that into a
> lintian check?
> 
> Preconditions
>  * A source package builds an architecture-dependent binary package.
>  * The package Build-Depends: python([0-9.]*|3?(-all))-dev without any
>:native or :any qualifier.
> 
> The assumption is that in this case, the package very likely builds a
> Python extension module. For doing so, it needs a build architecture
> Python interpreter and a host architecture Python development package.
> This dependency however will cause both components to be installed for
> the host architecture and for the Python interpreter this tends to fail
> postinst.
> 
> Instead, it should be Build-Depends: &:native, lib& (where "&" is the
> package name previously used). The :native qualifier will cause the
> interpretr to be installed for the build architecture and the second
> dependency will pull the host architecture development package. For
> native builds, there is no difference as the first package depends on
> the second.
> 
> This transformation is quite mechanical, affects many packages and helps
> cross building a lot. I suppose that this could be automated by the
> janitor.

>From the Janitor's point of view, it would be easiest if these were included in
the multi-arch hint output (perhaps as a new type of hint) - since then it
would just be another case to handle in apply-multiarch-hints.

Cheers,

Jelmer

Bug#1023794: libyang2: Update libyang2 to latest master from CESNET

[Marco d'Itri]

On Jan 06, David Lamparter  wrote:

> The only issue I've been running into is the Multi-Arch file conflict on
> libyang/config.h; I had talked to the CESNET people about that but they
> didn't seem to understand the problem very well.
The quick solution is to move the includes to /usr/include//, 
but I did not want to do it in this upload.

I have uploaded the new release and opened a pull request upstream: 
https://github.com/CESNET/libyang/pull/1967 .

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1023053: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#1023053: fixed in bash 5.2-3)

[Helmut Grohne]

Control: reopen -1

Hi Matthias,

On Sat, Dec 31, 2022 at 11:21:07AM +, Debian Bug Tracking System wrote:
> #1023053: bash FTBFS on musl: duplicate definition of strtoimax

Thank you for applying the patch. In order to make a difference, you
also need to regenerate configure at upload time or at build time.

Helmut

Bug#1028094: support gcc-13

[Helmut Grohne]

Package: cross-gcc-dev

Hi,

gcc-13 has entered experimental. Please copy over the gcc-12 patches for
gcc-13. It would be nice if you could rebase them to be applicable, but
as usual, I don't expect them to work in any way and will file patches.

Helmut

Bug#1028093: warn about python*-dev dependencies breaking cross compilation

[Helmut Grohne]

Package: lintian
Version: 2.115.3
Severity: wishlist
X-Debbugs-Cc: Joe Nahmias , Jelmer Vernooij 

Hi,

Joe noticed a repetitive cross build failure. Can we turn that into a
lintian check?

Preconditions
 * A source package builds an architecture-dependent binary package.
 * The package Build-Depends: python([0-9.]*|3?(-all))-dev without any
   :native or :any qualifier.

The assumption is that in this case, the package very likely builds a
Python extension module. For doing so, it needs a build architecture
Python interpreter and a host architecture Python development package.
This dependency however will cause both components to be installed for
the host architecture and for the Python interpreter this tends to fail
postinst.

Instead, it should be Build-Depends: &:native, lib& (where "&" is the
package name previously used). The :native qualifier will cause the
interpretr to be installed for the build architecture and the second
dependency will pull the host architecture development package. For
native builds, there is no difference as the first package depends on
the second.

This transformation is quite mechanical, affects many packages and helps
cross building a lot. I suppose that this could be automated by the
janitor.

Thanks for considering

Helmut

Bug#935378: lektor: Package the admin UI

[Jérôme Charaoui]

Version: 3.3.7-1

As documented in the package description and NEWS, we're currently 
unable to ship the Lektor frontend interface due to missing javascript 
build dependencies to compile the frontend.


The upcoming Lektor 3.4 branch appears to be simplifying the build 
process for the frontend, so I'm keeping this bug open so we revisit 
this next upstream release.


Thanks,

-- Jérôme

Bug#1023217: manpages: Wrongly sorted man pages

[Helge Kreutzmann]

Hello Marcos,
On Fri, Jan 06, 2023 at 06:03:20PM +0100, Marcos Fouces wrote:
> Hello Helge,
> The presence of these *.2 and *.3 manpages in the manpages package
> instead of manpages-dev is to avoid sending broken links in the
> manpages-dev package.

Ok, I see. In fact, I was filtering those broken links out in
manpages-l10n. Might revisit that in the future.

> The source package even provides a script [1] to check for this problem
> and make corrections.
> 
> There is also an example in the manpages-dev package: console_ioctl.4
> is moved to the manpages-dev package because it points to
> ioctl_console.2.

In manpages-l10n Tobias corrected this in the build system manually.

> Unless a better solution is proposed, I think it's best to close this
> bug in a few days.

Well, if this is on purpose, then this bug is not valid. I wrongly
assumed this to be a packaging mistake.

Greetings

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


signature.asc
Description: PGP signature

Bug#995169: Possible fix

[Andreas Voigt]

--- mc-4.8.28.orig/src/subshell/common.c
+++ mc-4.8.28/src/subshell/common.c
@@ -749,7 +749,7 @@ feed_subshell (int how, gboolean fail_on
should_read_new_subshell_prompt = FALSE;
/* we wait up to 1 second if fail_on_error, forever otherwise */
- wtime.tv_sec = 1;
+ wtime.tv_sec = 10;
wtime.tv_usec = 0;
wptr = fail_on_error ?  : NULL;

alternativly you could download my pachted source from
https://github.com/phil2sat/Midnight_Commander.git

and build it with "debuild -uc -us"

phil2sat

Bug#1028092: uwsgi-plugin-php FTBFS with PHP 8.2

[Adrian Bunk]

Source: uwsgi-plugin-php
Version: 0.0.14
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=uwsgi-plugin-php=amd64=0.0.14%2Bb1=1673016841=0

...
/usr/src/uwsgi/plugins/php/php_plugin.c: In function ‘php_uwsgi_startup’:
/usr/src/uwsgi/plugins/php/php_plugin.c:610:13: error: too many arguments to 
function ‘php_module_startup’
  610 | if (php_module_startup(_sapi_module, _module_entry, 
1)==FAILURE) {
  | ^~
In file included from /usr/src/uwsgi/plugins/php/common.h:3,
 from /usr/src/uwsgi/plugins/php/php_plugin.c:1:
/usr/include/php/20220829/main/php_main.h:28:20: note: declared here
   28 | PHPAPI zend_result php_module_startup(sapi_module_struct *sf, 
zend_module_entry *additional_module);
  |^~
...

Bug#1028091: mc: Subshell not starting on heavily modified zsh shell

[phil2sat]

Package: mc
Version: 3:4.8.28-1
Severity: important
X-Debbugs-Cc: phil2...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
pressing ctrl+o to get a subshell while using the kali linux zsh addons on 
a slow pc.
on login it lasts 2-3 seconds until the prompt appeares.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
MC window dissapeared but no shell prompt did come up,
on pressing any key mc window came back in front. No subshell possible

Patched subshell.c to get a little bit more time to settle the shell prompt

--- mc-4.8.28.orig/src/subshell/common.c
+++ mc-4.8.28/src/subshell/common.c
@@ -749,7 +749,7 @@ feed_subshell (int how, gboolean fail_on
 should_read_new_subshell_prompt = FALSE;
 
 /* we wait up to 1 second if fail_on_error, forever otherwise */
-wtime.tv_sec = 1;
+wtime.tv_sec = 10;
 wtime.tv_usec = 0;
 wptr = fail_on_error ?  : NULL;

   * What was the outcome of this action?
After the patch the subshell works as expected

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


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

Kernel: Linux 6.0.0-6-686-pae (SMP w/2 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 mc depends on:
ii  libc6 2.36-7
ii  libext2fs21.46.6~rc1-1+b1
ii  libglib2.0-0  2.74.4-1
ii  libgpm2   1.20.7-10+b1
ii  libslang2 2.3.3-2
ii  libssh2-1 1.10.0-3+b1
ii  mc-data   3:4.8.28-1

Versions of packages mc recommends:
ii  mailcap 3.70+nmu1
ii  perl5.36.0-6
ii  sensible-utils  0.0.17
ii  unzip   6.0-27

Versions of packages mc suggests:
pn  arj
ii  bzip2  1.0.8-5+b1
pn  catdvi | texlive-binaries  
pn  dbview 
pn  djvulibre-bin  
pn  epub-utils 
ii  file   1:5.41-4
pn  genisoimage
pn  gv 
pn  imagemagick
ii  libaspell-dev  0.60.8-4+b1
ii  lynx   2.9.0dev.11-1
pn  odt2txt
ii  poppler-utils  22.08.0-2.1
pn  python 
pn  python-boto
pn  python-tz  
pn  unar   
pn  wimtools   
pn  xpdf | pdf-viewer  
pn  zip

-- no debconf information

Bug#1028090: odoo: contains non-free fonts

[Bastian Germann]

Source: odoo
Severity: serious
Version: 14.0.0+dfsg.3-1.1

odoo contains at least 2 non-free fonts: mnmliconsv21 and Rhesmanisa.
See the upstream bugs
https://github.com/odoo/odoo/issues/6382
https://github.com/odoo/odoo/issues/109361

Please repack to get rid of these fonts.

Bug#1028089: mc: SFTP,failed to open file (-16), after yes for keystore

[phil2sat]

Package: mc
Version: 3:4.8.28-1
Severity: normal
X-Debbugs-Cc: phil2...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
Simple using SFTP as ever

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Opened new SFTP Session, answered YES to store the new athenticity
My bet MC doesnt store the ECDSA fingerprint correctly

   * What was the outcome of this action?
failed to open file (-16)

   * What outcome did you expect instead?
an established SFTP connection

Actually in using scp as workaround (storing key), after that all future 
SFTP sessions to the host does work
And finally building clean 4.8.28-1 from git source the problem is gone.
So something in the Debian pachtes are triggering this error. 
And this bug ist active since at least one year 
Buster/Bullseye/Bookwoorm/Sid all Distros are and all Archs are affected
At least the ones ive tested amd64,i386,arm,ppc64...


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


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

Kernel: Linux 6.0.0-6-686-pae (SMP w/2 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 mc depends on:
ii  libc6 2.36-7
ii  libext2fs21.46.6~rc1-1+b1
ii  libglib2.0-0  2.74.4-1
ii  libgpm2   1.20.7-10+b1
ii  libslang2 2.3.3-2
ii  libssh2-1 1.10.0-3+b1
ii  mc-data   3:4.8.28-1

Versions of packages mc recommends:
ii  mailcap 3.70+nmu1
ii  perl5.36.0-6
ii  sensible-utils  0.0.17
ii  unzip   6.0-27

Versions of packages mc suggests:
pn  arj
ii  bzip2  1.0.8-5+b1
pn  catdvi | texlive-binaries  
pn  dbview 
pn  djvulibre-bin  
pn  epub-utils 
ii  file   1:5.41-4
pn  genisoimage
pn  gv 
pn  imagemagick
ii  libaspell-dev  0.60.8-4+b1
ii  lynx   2.9.0dev.11-1
pn  odt2txt
ii  poppler-utils  22.08.0-2.1
pn  python 
pn  python-boto
pn  python-tz  
pn  unar   
pn  wimtools   
pn  xpdf | pdf-viewer  
pn  zip

-- no debconf information

Bug#1028088: hostapd.*service: please depend on presence on config file

[Daniel Reichelt]

Package: hostapd
Version: 2:2.9.0-21
Severity: normal

Hi *,

the init scripts used to depend on the presence of /etc/hostapd/hostapd.conf.
systemd however tries to continuously start the units unconditionally.

This additional line in the units would be a simple fix:


[Unit]
ConditionFileNotEmpty=/etc/hostapd/hostapd.conf


Thanks!
Daniel

Bug#1028087: pychess: possible non-free chess fonts

[Bastian Germann]

Package: pychess
Severity: important
Version: 1.0.3-1

/usr/share/pychess/pieces/ttf contains 18 fonts by Armando H. Marroquin which 
can be found at several font websites.
However, the license is not clear. Most of them are offered for free personal 
use.
The license grant is not very clear about distributing modified versions or 
commercial use.
I consider them as non-free but variants of them seem to be part of the TeX chessfss package which is licensed under a 
free license.


Upstream removed them (not for license reasons) in the current development 
branch.
Please check if it is possible to import it as a new Debian version or ask for 
a release.
Or just repack and patch.

Bug#1023217: manpages: Wrongly sorted man pages

[Marcos Fouces]

Hello Helge,
The presence of these *.2 and *.3 manpages in the manpages package
instead of manpages-dev is to avoid sending broken links in the
manpages-dev package.

The source package even provides a script [1] to check for this problem
and make corrections.

There is also an example in the manpages-dev package: console_ioctl.4
is moved to the manpages-dev package because it points to
ioctl_console.2.

Unless a better solution is proposed, I think it's best to close this
bug in a few days.

Greetings,
Marcos

[1]https://sources.debian.org/src/manpages/6.02-1/debian/move_links_to_correct_package/

Bug#1016963: Please test u-boot for Mini-X

[Jochen Sprickerhof]

* Vagrant Cascadian  [2023-01-05 12:29]:

On 2023-01-04, Jochen Sprickerhof wrote:

* Vagrant Cascadian  [2022-12-28 16:56]:

If you have access to any of these boards, please consider testing
u-boot versions as packaged in debian for versions from debian stable
(2021.01*), testing (2022.04*), unstable (2022.10*) and experimental
(2023.01-rc*) and updating the wiki page if successful and/or replying
to 1016...@bugs.debian.org with a positive confirmation...

...and if not successful, filing bugs against the relevent u-boot-*
packages and marking them as blocking 1016963.


Mini-X


Works fine with unstable, I've updated the wiki page.


Thanks! Any chance you could also test 2023.01-rc* from experimental? At
this point 2023.01 is the version I am most likely to try to push to
bookworm.


2023.01~rc4+dfsg-2 from unstable also works fine (updated the wiki 
page).


Cheers Jochen


signature.asc
Description: PGP signature

Bug#908274: Multi-host networking software, autopkgtests

[Ian Jackson]

Paul Gevers writes ("Re: Multi-host networking software, autopkgtests"):
> I guess this is best discussed in https://bugs.debian.org/908274 (added 
> in the To)? Maybe with Wouter and other interested parties?

Hmmm.  Well, a way of doing this "officially" in autopkgtest would be
nice.  But:

Think such an "official" thing ought to allow the specification of
different dependencies for the different hosts in the test.  And I
don't much like the mini-DSL suggestion.  Maybe it would be better to
offer the test script an adt virt server interface to control the
"other" hosts.

This all seems very complex.  I definitely want to have something
working before something like that could exist.  Also, I think it
would be a good idea to do something ad-hoc, ideally in a number of
packages, to gain experience so we know what shape the "official"
thing ought to be.

I think therefore that I need to pursue some kind of within-testbed
nesting, as an interim approach at the very least.  I was hoping that
someone else had solved (part of) this problem already...

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1028086: ghostwriter: File backup failed

[craudio]

Package: ghostwriter
Version: 2.1.6+ds-2
Severity: normal
X-Debbugs-Cc: crau...@disroot.org

Dear Maintainer,

Every time a new file is created appears the message "File Backup Failed.
Unknown error".However, the backup is usually done in the/Home/User/Documents

Thank you for your attention!


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

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

Versions of packages ghostwriter depends on:
ii  libc62.36-7
ii  libcmark-gfm-extensions0.29.0.gfm.6  0.29.0.gfm.6-6
ii  libcmark-gfm0.29.0.gfm.6 0.29.0.gfm.6-6
ii  libgcc-s112.2.0-11
ii  libhunspell-1.7-01.7.1-1
ii  libqt5core5a 5.15.7+dfsg-2
ii  libqt5gui5   5.15.7+dfsg-2
ii  libqt5svg5   5.15.7-2
ii  libqt5webchannel55.15.7-2
ii  libqt5webenginewidgets5  5.15.11+dfsg-5
ii  libqt5widgets5   5.15.7+dfsg-2
ii  libstdc++6   12.2.0-11

ghostwriter recommends no packages.

Versions of packages ghostwriter suggests:
pn  cmark 
pn  discount  
ii  hunspell-en-us [hunspell-dictionary]  1:2020.12.07-2
ii  hunspell-pt-br [hunspell-dictionary]  1:7.4.2-1
pn  myspell-dictionary
pn  pandoc
pn  wkhtmltopdf   

-- no debconf information

Bug#1028085: dnf-plugins-core: ships /usr/share/man/man1/needs-restarting.1.gz, already in zypper

[Andreas Beckmann]

Package: dnf-plugins-core
Version: 4.3.1-1~exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
This error may also be triggered by having a predecessor package from
'sid' installed while installing the package from 'experimental'.

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 .../dnf-plugins-core_4.3.1-1~exp1_all.deb ...
  Unpacking dnf-plugins-core (4.3.1-1~exp1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/dnf-plugins-core_4.3.1-1~exp1_all.deb (--unpack):
   trying to overwrite '/usr/share/man/man1/needs-restarting.1.gz', which is 
also in package zypper 1.14.42-2
  Errors were encountered while processing:
   /var/cache/apt/archives/dnf-plugins-core_4.3.1-1~exp1_all.deb


This manpage is the only file conflicting between the two packages.


cheers,

Andreas


zypper=1.14.42-2_dnf-plugins-core=4.3.1-1~exp1.log.gz
Description: application/gzip

Bug#1028073: closed by Stephen Rhodes (Re: Bug#1028073: libonvif: Fix build problem on hurd)

[Petter Reinholdtsen]

[Stephen Rhodes]
> The unneeded header  has been removed from source
> code

Very good.

Note, instead of emailing 1028073-d...@bugs.debian.org to close a bug
before the fix is in Debian, it is custom to add a 'Closes: #1028073'
string in debian/changelog of the upload with the fix.  This will ensure
the correct version is attributed to the fix and that the bug stay open
until the fix is available from the Debian archive.  See
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-bugs-are-closed-by-new-uploads
 >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1028084: guidata FTBFS with Python 3.11 as default version

[Adrian Bunk]

Source: guidata
Version: 2.3.0-1
Severity: serious
Tags: ftbfs
Forwarded: 
Control: affects -1 python3-guidata src:guiqwt

...
dh clean --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:240: python3.10 setup.py clean 
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.10' does not exist -- can't clean it
I: pybuild base:240: python3.11 setup.py clean 
Traceback (most recent call last):
  File "/tmp/guidata-2.3.0/setup.py", line 32, in 
from guidata.utils import get_subpackages, get_package_data
  File "/tmp/guidata-2.3.0/guidata/__init__.py", line 542, in 
import guidata.config
  File "/tmp/guidata-2.3.0/guidata/config.py", line 21, in 
_ = get_translation("guidata")
^^
  File "/tmp/guidata-2.3.0/guidata/configtools.py", line 53, in get_translation
_trans = gettext.translation(
 
TypeError: translation() got an unexpected keyword argument 'codeset'
E: pybuild pybuild:388: clean: plugin distutils failed with: exit code=1: 
python3.11 setup.py clean 
dh_auto_clean: error: pybuild --clean -i python{version} -p "3.10 3.11" 
returned exit code 13
make: *** [debian/rules:6: clean] Error 25



This is also a runtime error:

>>> import guidata.config
Traceback (most recent call last):
  File "", line 1, in 
  File "/tmp/guidata-2.3.0/guidata/__init__.py", line 542, in 
import guidata.config
  File "/tmp/guidata-2.3.0/guidata/config.py", line 21, in 
_ = get_translation("guidata")
^^
  File "/tmp/guidata-2.3.0/guidata/configtools.py", line 53, in get_translation
_trans = gettext.translation(
 
TypeError: translation() got an unexpected keyword argument 'codeset'
>>> 

Bug#1023794: libyang2: Update libyang2 to latest master from CESNET

[David Lamparter]

On Fri, Jan 06, 2023 at 05:14:07PM +0100, Marco d'Itri wrote:
> I have uploaded 1.0.240 and opened a pull request upstream: 
> https://github.com/CESNET/libyang/pull/1966 .
> 
> Switching to the 2.x branch requires more time that I cannot commit 
> right now, but I will be happy to sponsor somebody else's work.
> (Please note that we are VERY close to the transitions freeze!)

I'm a bit confused now.  2.0.112-6 is in Debian testing and doesn't seem
to have major issues.  It's a year old and probably missing a bunch of
performance fixes, but I think functionally it should be fine.

The only issue I've been running into is the Multi-Arch file conflict on
libyang/config.h; I had talked to the CESNET people about that but they
didn't seem to understand the problem very well.

libyang1 is really deprecated at this point, FRR doesn't work with it
anymore, our absolute minimum is 2.0.0.  apt-cache rdepends libyang1
doesn't give me anything else using libyang1 either.  (sysrepo &
netopeer being CESNET projects anyway, they've been updated wy
before FRR...)

On the plus side libyang1 and libyang2 do properly coexist like major
DSO version bumps are supposed to.

Cheers,


-equi

Bug#1023794: libyang2: Update libyang2 to latest master from CESNET

[Marco d'Itri]

On Jan 06, David Lamparter  wrote:

> I'm a bit confused now.  2.0.112-6 is in Debian testing and doesn't seem
No: *I* have been confused, and somehow I missed the 2.x debian 
packaging branch... Let me try to work a bit on the current one.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1023794: libyang2: Update libyang2 to latest master from CESNET

[Marco d'Itri]

I have uploaded 1.0.240 and opened a pull request upstream: 
https://github.com/CESNET/libyang/pull/1966 .

Switching to the 2.x branch requires more time that I cannot commit 
right now, but I will be happy to sponsor somebody else's work.
(Please note that we are VERY close to the transitions freeze!)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1028073: libonvif: Fix build problem on hurd

[Stephen Rhodes]

The header has been removed from source code, as well as other unneeded
headers in that section.
Only  and  are needed.

On Fri, Jan 6, 2023 at 9:33 AM Petter Reinholdtsen  wrote:

>
> Package: libonvif
> Version: 1.4.4-1
> Tags: patch
>
> The code enumerating all network interfaces using getifaddrs() include a
> linux specific header file.  As far as I can tell from getifaddrs(3),
> there is no need for the  include, only the 
> one is needed.  The latter is available on Hurd, while the former is
> not.
>
> This patch get the code building on Debian Hurd.
>
> diff --git a/onvif-gui/src/settingspanel.cpp
> b/onvif-gui/src/settingspanel.cpp
> index b0c6e72..ff0cc52 100644
> --- a/onvif-gui/src/settingspanel.cpp
> +++ b/onvif-gui/src/settingspanel.cpp
> @@ -31,7 +31,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #endif
>
>  #include 
>
> --
> Happy hacking
> Petter Reinholdtsen
>

Bug#1028059: calibre-bin version 6.10.0+dfsg-5 uses unknown compression for control.tar.zst, cannot be installed

[yokota]

Hello,

> Tried to install 6.10.0+dfsg-5 and got the error below:
> calibre-bin_6.10.0+dfsg-5_amd64.deb' uses unknown compression for member 
> 'control.tar.zst', giving up
>
> Forced to cancel upgrade, leaving a number of packages that cannot be
> upgraded as they need the qt6 packages but I need a working calibre.

Sorry, there is some problem in Qt6 transitions. This probrem will fix
in 5 days.
Currently, calibre is works well on "sid" distributions.
"control.tar.zst" is used in Ubuntu package. Use Debian package for
your machine.

There are some options to fix:
1. Hold current "testing" distribution packages. New calibre package
for "testing" distribution will be available in 5 days.

2. Install manually "sid" distribution package from Debian web site.
You must downloads and installs 2 packages.
   (binary package page)
  https://packages.debian.org/sid/calibre
  https://packages.debian.org/sid/calibre-bin
   (package distribution server)
  https://ftp.debian.org/debian/pool/main/c/calibre/
Install package files by super user.
   dpkg -i  calibre_6.10.0+dfsg-5_all.deb
calibre-bin_6.10.0+dfsg-5_amd64.deb

If you don't know what to do,  choose option 1 and wait 5 days or less.

--
YOKOTA