Bug#1008784: upgrade-system: Please restore cron.daily snippet for non-systemd systems

[Martin-Éric Racine]

On Fri, Apr 1, 2022 at 5:48 PM Mark Hindley  wrote:
> Package: upgrade-system
> Version: 1.9.0.0
> Severity: normal
>
> The latest version of upgrade-system removed the cron.daily snippet in favour 
> of
> systemd timers.
>
> The cron.daily snippet was still used and useful on non-systemd systems. 
> Please
> consider restoring it for the benefit of those users.

Is there such a thing as Debian systems that don't run off systemd nowadays?

The key problem is APT updating its lists several times in a row
whenever cron.daily is run i.e. via every package that installs a
similar snipet either via cron or via apt.conf.d, which quickly
becomes redundant.

Which part of the cron snipet specifically do you find essential?

Martin-Éric

Bug#1008796: miniupnpd: compile miniupnpd also with IGD v1 only

[Yangfl]

Control: tags -1 moreinfo

On Fri, 01 Apr 2022 20:41:29 +0200 Matteo Croce 
wrote:
> Package: miniupnpd
> Version: 2.2.1-1
> Severity: normal
>
> Dear Maintainer,
>
> miniupnpd has the force_igd_desc_v1 config option to use the v1 IGD
descriptor.
> Unfortunately, the runtime behaviour differs between the daemon compiled
with
> and without --igd2, even when force_igd_desc_v1 set.
> This makes the daemon non interoperable with some devices.
> Please consider adding another package like miniupnpd-igd1, where the
daemon
> is compiled without --igd2.
>
How differs? This should be considered as an upstream bug.

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Johannes Schauer Marin Rodrigues]

Quoting Christian Kastner (2022-03-23 21:36:59)
> On 2022-03-23 12:43, Johannes Schauer Marin Rodrigues wrote:
> > Quoting Francesco Poli (2022-03-23 00:09:21)
> > Full: the problem with the current version of 
> > mmdebstrap-autopkgtest-build-qemu
> > is, that it can only build qemu images for the native architecture. This is
> > because it relies on guestfish. Guestfish will never be able to operate on
> > foreign architecture qemu guests. This is because:
> > 
> >  - guestfish sets architecture specific options at compile time. This means
> >that every guestfish binary can only be used for qemu guests of the same
> >architecture as that binary and this cannot be changed at runtime
> > 
> >  - guestfish relies on another program called supermin. Essentially, 
> > supermin
> >assembles a minimal chroot which is then loaded as qemu boots and then
> >carries out the guestfish operations. Since supermin just copies binaries
> >from the host, it cannot create foreign chroots either.
> 
> This is unfortunate, as otherwise guestfish would be universal, but it's
> understandable.
> 
> I initially wondered whether foreign architecture guestfish/supermin
> binaries couldn't be run through qemu-user-static, but that solution
> would be just far too hacky I think.

I think how "hacky" it is depends on how you look at it. The advantage is, that
then you only have to maintain the "native" codepath which you run under
emulation if you want a foreign arch binary. I just tried it out and it seems
to work as expected. Big downside: running qemu (from guestfish) inside qemu
(from qemu-user-static) is *ralllyy sloow*. XD

But I think it's a good idea to have for the sake of symmetry. We'd then have:

 - guestfish
 - fastest method when creating a native image
 - slowest method when creating a foreign image
 - initramfs
 - medium speed for both native and foreign images

Then the new tool could have a --method switch with possible values:

 - "auto" choose guestfish if installed for native images and initramfs
   otherwise
 - "guestfish" forces guestfish for native and foreign
 - "initramfs" forces initramfs for native and foreign

> > A disadvantage is, that this only works for architectures for which qemu 
> > knows
> > how to boot them without kernel and initrd from the outside. This means that
> > mips* and s390x are not supported and neither are most of the Debian ports
> > architectures. I don't know how to solve this other than by teaching
> > autopkgtest-virt-qemu that now it needs three input files: the kernel, the
> > initrd and the rootfs.
> 
> Since these are QEMU options, I think autopkgtest-virt-qemu's existing
> --qemu-options could be used to supply kernel/initrd/rootfs?

Yes, that might work. Though from reading the autopkgtest-virt-qemu man page I
think this will not support paths with spaces. On the other hand, the man page
also says that additional arguments can be supplied via a file that contains
one argument per line.

> > Another disadvantage is, that the output can never be bit-by-bit
> > reproducible because grub-install is unreproducible.
> > 
> > I've worked on this in context with replacing vmdb2 in 
> > autopkgtest-build-qemu
> > so that sbuild-qemu-create (maintained by Christian Kastner) can be run 
> > without
> > superuser privileges.  We've tried to approach the vmdb2 author but Lars is
> > reluctant to include such drastic changes:
> > https://gitlab.com/larswirzenius/vmdb2/-/issues/62
> > 
> > So I'll probably release yet another 
> > https://wiki.debian.org/SystemBuildTools
> > because the existing solutions don't do what I want. The closest is probably
> > debos which can be run without being root because everything is done inside
> > qemu. But it also doesn't solve the hard problem of installing a bootloader,
> > leaving it to the user: https://github.com/go-debos/debos/issues/137
> 
> I think this is a fantastic idea, not just because sbuild-qemu would be
> a major beneficiary but because there is a general gap here: there
> currently is no tool that can easily create images (1) without root and
> (2) for arbitrary architectures.
> 
> Having such a tool would enable many upstreams to easily test their
> software on other architectures, e.g. via GitHub Actions. PowerPC and
> RISC-V are interesting contenders but only the fewest projects test
> them. However, our buildds and debci discover issues all the time.
> 
> Additionally,  it's really useful to have an on-demand, throwaway
> porterbox when you need one. I probably use sbuild-qemu-boot more than
> sbuild-qemu, and the former is just a QEMU launcher. I use it even for
> native architectures because it's basically a container-like workspace
> where I can do Bad Stuff without fear of polluting or trashing my system.
> 
> I've run out of ideas how to easily solve this, other than what
> Francesco suggested (e.g. create a base with FAI or preseed.cfg, then
> finalize by running comman

Bug#1008817: libphonenumber8: breaks evolution

[Christoph Anton Mitterer]

Package: libphonenumber8
Version: 8.12.46-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)


Hi.

8.12.46-1 causes evolution to fail:
$ evolution
evolution: symbol lookup error: /usr/lib/x86_64-linux-gnu/libphonenumber.so.8: 
undefined symbol: _ZN4absl7debian213hash_internal9HashState5kSeedE

Downgrading to 8.12.44-1 fixes the issue.

Cheers,
Chris.



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

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

Versions of packages libphonenumber8 depends on:
ii  libabsl20210324  0~20210324.2-2
ii  libc62.33-7
ii  libgcc-s112-20220319-1
ii  libicu67 67.1-7
ii  libprotobuf233.12.4-1+b3
ii  libstdc++6   12-20220319-1

libphonenumber8 recommends no packages.

libphonenumber8 suggests no packages.

-- no debconf information

Bug#1008816: ITP: kwin-bismuth -- KDE Plasma extension for tiling windows

[Blake Lee]

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

* Package name: kwin-bismuth
  Version : 3.0.0
  Upstream Author : Mikhail Zolotukhin 
* URL : https://github.com/Bismuth-Forge/bismuth
* License : Expat, GPL-3+, CC-BY-4.0, LGPL-3.0+
  Programming Lang: RypeScript, C++, QML
  Description : KDE Plasma extension for tiling windows

Description: KDE Plasma extension for tiling windows
 KDE Plasma add-on, that tiles your windows automatically
 and lets you manage them via keyboard,
 similarly to i3, Sway or dwm.

 This package extends the kwin WM to allow for tiling windows.
 I have used many different tiling scripts for kwin and in
 my opinion this is by far the best one.

 I plan on maintaining this on my GitLab, but I would have
 no issue maintaining it with a team. I believe this is probably
 an area for the KDE Extras Team.

 I will need a sponsor to upload this package.

Bug#1008815: Followup: screencast starts the first time but creates empty

[Josh Triplett]

file
Reply-To: 

Following up on this: the *first* time I try starting a screencast after
restarting GNOME, it appears to start, and shows a recording icon in the
top bar, but the resulting file is empty (0 bytes), and the log says:

"Error stopping screencast: Timeout was reached"

The second and subsequent times, I get the previously reported error,
and the screencast doesn't appear to even start, and no file gets
created at all.

Bug#1008815: Unable to record screencast: "Error starting screencast"

[Josh Triplett]

Package: gnome-shell
Version: 42.0-2
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

When trying to record a screencast, I got the following non-specific
error in the logs:

gnome-shell[787]: Error starting screencast

And the screencast didn't start recording.



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  evolution-data-server3.44.0-3
ii  gir1.2-accountsservice-1.0   22.07.5-1
ii  gir1.2-adw-1 1.1.0-1
ii  gir1.2-atk-1.0   2.38.0-1
ii  gir1.2-atspi-2.0 2.44.0-3
ii  gir1.2-freedesktop   1.72.0-1+b1
ii  gir1.2-gcr-3 3.40.0-4
ii  gir1.2-gdesktopenums-3.0 42.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.8+dfsg-1
ii  gir1.2-gdm-1.0   42.0-1
ii  gir1.2-geoclue-2.0   2.5.7-3
ii  gir1.2-glib-2.0  1.72.0-1+b1
ii  gir1.2-gnomebluetooth-3.042.0-3
ii  gir1.2-gnomedesktop-3.0  42.0-1
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.20.1-1
ii  gir1.2-gtk-3.0   3.24.33-1
ii  gir1.2-gtk-4.0   4.6.2+ds-1
ii  gir1.2-gweather-4.0  4.0.0-1
ii  gir1.2-ibus-1.0  1.5.26-2
ii  gir1.2-mutter-10 42.0-3
ii  gir1.2-nm-1.01.36.4-1
ii  gir1.2-nma-1.0   1.8.36-1
ii  gir1.2-pango-1.0 1.50.6+ds-2
ii  gir1.2-polkit-1.00.105-33
ii  gir1.2-rsvg-2.0  2.52.5+dfsg-3+b1
ii  gir1.2-soup-2.4  2.74.2-3
ii  gir1.2-upowerglib-1.00.99.17-1
ii  gir1.2-webkit2-4.0   2.36.0-2
ii  gnome-backgrounds42.0-1
ii  gnome-settings-daemon42.1-2
ii  gnome-shell-common   42.0-2
ii  gsettings-desktop-schemas42.0-1
ii  gstreamer1.0-pipewire0.3.49-1
ii  libatk-bridge2.0-0   2.38.0-4
ii  libatk1.0-0  2.38.0-1
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libecal-2.0-13.44.0-3
ii  libedataserver-1.2-263.44.0-3
ii  libgcr-base-3-1  3.40.0-4
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libgirepository-1.0-11.72.0-1+b1
ii  libgjs0g 1.72.0-2
ii  libgles2 1.4.0-1
ii  libglib2.0-0 2.72.0-1
ii  libglib2.0-bin   2.72.0-1
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-1942.0-1
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.33-1
ii  libgtk-4-1   4.6.2+ds-1
ii  libical3 3.0.14-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-10-0   42.0-3
ii  libnm0   1.36.4-1
ii  libpango-1.0-0   1.50.6+ds-2
ii  libpangocairo-1.0-0  1.50.6+ds-2
ii  libpolkit-agent-1-0  0.105-33
ii  libpolkit-gobject-1-00.105-33
ii  libpulse-mainloop-glib0  15.0+dfsg1-4
ii  libpulse015.0+dfsg1-4
ii  libsecret-1-00.20.5-2
ii  libsystemd0  250.4-1
ii  libwayland-server0   1.20.0-1
ii  libx11-6 2:1.7.4-1
ii  libxfixes3   1:6.0.0-1
ii  python3  3.10.4-1

Versions of packages gnome-shell recommends:
pn  bolt  
pn  chrome-gnome-shell
ii  gdm3  42.0-1
ii  gkbd-capplet  3.26.1-2
ii  gnome-con

Bug#1008813: ITP: cargo-strip -- subcommand that reduces the size of Rust binaries

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: cargo-strip
  Version : 0.2.2
  Upstream Author : Guillaume Valadon 
* URL : https://github.com/guedou/cargo-strip/issues
* License : MIT/X,
  Programming Lang: rust
  Description : subcommand that reduces the size of Rust binaries

subcommand that reduces the size of Rust binaries
 As of Rust 1.59, the charge command is now able to remove a binary.
 This can be activated in your Cargo.toml.

Bug#983146: 983146 RFS: bung/3.2.4-1 [ITP] -- backup next generation

[Charles]

Dear Tobias

Further to your 13 Nov 2021 message above ...

The orig.tar.gz file is now in the required format

The source build now has a watch file

The git is publicly available at https://github.com/CharlesMAtkinson/bung

The orig.tar.gz file is available from 
https://github.com/CharlesMAtkinson/bung_debian_packaging/releases


Dear Geert

You asked for proof that feedback gets follow-up.  This is it, not as 
quickly as I would have liked.  Migration to github and automating the 
release and publication procedures was not trivial


Best

Charles

Bug#1008812: Consider reducing dependency level on chrom*?

[Bryce Harrington]

Source: node-puppeteer
Severity: wishlist

node-puppeteer has a build-dependency on chromium and chromium-sandbox,
which are not carried in Ubuntu, so a sync of this package into Ubuntu
failed and had to be removed (LP: #1967048).

Even though Ubuntu doesn't carry these, the package might still be of
utility for e.g. controlling remote chromium, or working with 3rd party
installations of it.

Other Debian packages that rely on chrom* list those depends as
Suggests/Enhances.  Would it be possible to consider doing similarly for
node-puppeteer?


Example:
Package: chrome-gnome-shell
...
Suggests: chromium | chromium-browser, firefox
Breaks: firefox (<< 56), firefox-esr (<< 56)
Enhances: chromium, chromium-browser, firefox

Thanks,
Bryce


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

Kernel: Linux 5.4.0-99-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1008267: pkg-perl-autopkgtest: use.t: reading debian/tests/pkg-perl/use-whitelist too restrained?

[gregor herrmann]

On Sat, 26 Mar 2022 16:01:00 +0100, gregor herrmann wrote:

> I'll leave it a bit to give others a chance to check as well.

No reactions so far, so I assume everyone else is happy :)

Merged & uploaded, thanks again!


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1008751: pytest-mpi: autopkgtest regression: versioned test depends only in experimental

[Drew Parsons]

Thanks Andrey.  I'll review how these other packages have handled it and 
see if it's simple to just patch pytest-mpi as you suggested.


Drew


On 2022-04-01 18:56, Andrey Rahmatullin wrote:

On Fri, Apr 01, 2022 at 06:04:38PM +0200, Drew Parsons wrote:

From
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources:

flufl.lock

Doesn't support Sybil 3.x in sid. The latest version, 7.0, supports it.
It's most likely easy to patch the sid version.


pytest-mpi

-


python-parsel

The fix is committed upstream but there was no release since then. It
should be easy to backport the fix.


python-public
Doesn't support Sybil 3.x in sid. The latest version, 3.0.1, supports 
it.

It's most likely easy to patch the sid version.


python-scrapy
Fixed upstream but the upload is postponed until the next bugfix 
release.

It should be easy to backport the fix.


python-testfixtures

Should work.

Bug#1008811: Won't start without python3-dbus (misses dependency)

[Daniel Leidert]

Package: snapper-gui
Version: 0git.960a94834f-3.1
Severity: serious

snapper-gui doesn't start without python3-dbus:

$ snapper-gui 
Traceback (most recent call last):
  File "/usr/bin/snapper-gui", line 33, in 
sys.exit(load_entry_point('snappergui==0.1', 'gui_scripts', 
'snapper-gui')())
  File "/usr/bin/snapper-gui", line 25, in importlib_load_entry_point
return next(matches).load()
  File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
module = import_module(match.group('module'))
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 972, in _find_and_load_unlocked
  File "", line 228, in _call_with_frames_removed
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 790, in exec_module
  File "", line 228, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/snappergui/__init__.py", line 1, in 

import dbus
ModuleNotFoundError: No module named 'dbus'

It seems this dependency is missing.

Regards, Daniel


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

Kernel: Linux 5.10.0-13-amd64 (SMP w/12 CPU threads)
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 snapper-gui depends on:
ii  gir1.2-gtksource-3.0  3.24.11-2
ii  python3   3.9.2-3
ii  snapper   0.8.15-1

snapper-gui recommends no packages.

snapper-gui suggests no packages.

-- no debconf information

Bug#1005912: hydrogen: autopkgtest regression on arm64 and ppc64el: H2Core::Instrument::dequeue(): Assertion `__queued > 0' failed.

[Nicholas D Steeves]

Control: forwarded -1 https://github.com/hydrogen-music/hydrogen/issues/1505

Forwarded 27 Feb 2022, but forgot to update this bug.  

Adrian and Reinhard, feel free to skip to "To Adrian and Reinhard:" :-)

Reply follows inline:

Paul Gevers  writes:

> Hi Nicholas,
>
> Thanks for reaching out.
>

You're welcome!  Sorry for my delay replying, and thank you very much
for your quick reply.

> On 24-02-2022 06:13, Nicholas D Steeves wrote:
>> Paul and Debian CI team, do you know if a dummy alsa driver (and dummy
>> sequencer driver) can be enabled on DebCI systems?
>
> You are in control of your testbed, can't you do this in your test? Or 
> can you only do this in isolation-machine testbeds (not sure how this 
> driver thing works)? 

I was thinking that this would require a `modprobe snd-dummy`, and I'm
assuming loading arbitrary kernel modules is blocked on DebCI systems.
It's been a few months since I contacted the CI Team about
isolation-machines, but they're not yet ready for use either.

> And why would only arm64 need it?
>

My request for snd-dummy on DebCI isn't arm64 specific; I noticed that
jackd2 doesn't have autopkgtest enabled, and hypothesised that missing
audio hardware was the reason why.  Jackd2 maintainers are now in CC
because would know better than I :-)

To Adrian and Reinhard: Is there any reason why jackd2 doesn't have an
autopkgtest enabled?  For example, is it because it's missing functional
tests, or because DebCI systems are missing something?  Could Hydrogen
be used to provide functional tests for jack2?  Is it too much of a
hassle and do you recommend just disabling autopkgtests for
audio-related packages?

>> This would make the
>> testbed more comparable to a real system and increase the value of the
>> tests for multimedia packages.  If not, please feel free to skip to the
>> bottom of this email.
>
> To be honest, I don't really like tweaking the hosts, as other 
> autopkgtest instances outside our control would need to learn to do this 
> too.
>

I completely understand, and the only way this request would be
justifiable is if it provided a meaningful boost in quality assurance
for audio-related packages.

>> When I run autopkgtests locally they now error due to missing audio
>> hardware where previously they passed, and this wasn't the case when the
>> package was uploaded.
>
> The test on ppc64el now passed after several failure due to segmentation 
> faults. Not sure if this is now a highly flaky test, or just that the 
> issue has been fixed in the mean time on ppc64el
>

When I contacted upstream, I learned that the cause may be that the CLI
utilities are poorly maintained.  Is this sufficient justification for
disabling the autopkgtests ie: that it's due diligence and not laziness?

>> It looks to me like "allow-stderr" is no longer
>> sufficient to allow the export-to-wav functional test to pass, eg:
>> 
>> (E) JackAudioDriver::init Unknown status with JACK server.
>> (E) ::H2Core::AudioOutput* H2Core::createDriver(const QString&) Error 
>> starting audio driver [audioDriver::init()]
>> (E) AlsaAudioDriver::connect ALSA: cannot open audio device hw:0:No such 
>> file or directory
>> (E) AlsaAudioDriver::connect ALSA: cannot open audio device default:No such 
>> file or directory
>> (E) ::void H2Core::audioEngine_startAudioDrivers() Error starting audio 
>> driver [audioDriver::connect()]
>> (E) ::void H2Core::audioEngine_startAudioDrivers() Using the NULL output 
>> audio driver
>> (E) ::void* H2Core::alsaMidiDriver_thread(void*) Error opening ALSA 
>> sequencer: No such file or directory
>
> But this text is also there on passing tests. So either that's no 
> problem, or the test doesn't fail while it should.
>

I agree with you now.  This output is marked "(E)", for error, but the
error appears to be elsewhere.  "H2Core::Instrument::dequeue():
Assertion `__queued > 0'" makes me wonder if there's something like a
race somewhere that's causing an off-by-one error...and yes, most likely
in Hydrogen, or introduced by a bad interaction between the
almost-never-used CLI tools and the main Hydrogen engine.

>> The available solutions appear to be 1) Enable a dummy sound card.  2)
>> Ask upstream to support running utility functions such as this wav file
>> export without attempting to bind to hardware.  3) Remove the
>> autopkgtest.  4) Something else.
>
> Again, why only arm64?
>

This is no longer only arm64.  See above: "When I run autopkgtests
locally [amd64 system] they now error".

Thank you again for having this conversation.  I want to support our CI
team and technical excellence rather than just "unblock migration to
testing", but will of course defer to your recommendations.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1006457: Chromium fails to start on aarch64 systems

[MichaIng]

Package: chromium
Version: 99.0.4844.74-1~deb11u1

> Which boards did you test with?

We observed the issue on these boards:
- Odroid C2
- Odroid C4
- Odroid N2+
- Radxa ROCK Pi 4
- Radxa Zero

> What desktops were you using? Was this under X or wayland? Does it 
make a difference if you run chromium with --ozone-platform=x11 or

--ozone-platform=wayland ?  What about --use-gl=desktop ?

We face it on various X11 desktops and via xinit or startx from console. 
Wayland was not tested.


--ozone-platform=x11 and/or --use-gl=desktop do not make a difference.

Best regards,

Micha

Bug#1008808: texlive-games: [chess.sty] Incorrect usage of babel breaks package

[Asher Gordon]

Hi Hilmar,

Hilmar Preuße  writes:

> So you're actively pushed to other packages. Please consider to follow
> this recommendation.

Thanks for the advice. So it seems a better solution would be to use an
alternative package in Scid's generated LaTeX files. I don't think that
should be too difficult. I'll do that when I have the time and send a
report to upstream and/or Debian.

Thanks,
Asher

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me sprea=
d!
   
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature

Bug#1008808: texlive-games: [chess.sty] Incorrect usage of babel breaks package

[Hilmar Preuße]

Control: tags -1 + wontfix

Am 01.04.2022 um 22:38 teilte Asher Gordon mit:

Hi,


The file /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty (used
by the LaTeX files generated by Scid) uses "\input english.sty" instead
of "\usepackage[english]{babel}". This causes a lot of errors when
compiling a LaTeX file that uses the chess package. If the errors are
ignored (e.g. by using "-interaction nonstopmode"), then the compiled
document has a lot of garbage at the start.

Many thanks for the report if you search for the package on CTAN, you'll 
come here: https://www.ctan.org/tex-archive/fonts/chess/chess/


You'll notice that the package is quite old and I'd assume that nobody 
will ever care to change something. Indeed on the upper right corner 
you'll see a note:


"The original (and now somewhat dated) TeX chess font package.

Potential users should consider skak (for alternative fonts, and 
notation support), texmate (for alternative notation support), or 
chessfss (for flexible font choices)."


So you're actively pushed to other packages. Please consider to follow 
this recommendation.


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008718: src:yosys: fails to migrate to testing for too long: FTBFS on mips64el and s390x & autopkgtest regression

[Daniel Gröber]

Hi Paul,

On Thu, Mar 31, 2022 at 10:06:24AM +0200, Paul Gevers wrote:
> 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:yosys has been trying to migrate for 61 days [2].
> Hence, I am filing this bug. Your latest upload failed to build from source
> on mips64el and s390x where it built successfully in the past. The latest
> upload also caused autopgktest regression on all architectures.

Getting myself a porterbox guest account just took ages, I'm on it now :)

> 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.

It seems to me berkeley-abc is to blame for most yosys test suite failures
and particularly the s390x one that's blocking migration. Apparently it has
major problems on big-endian architectures that aren't easily fixed:

https://github.com/YosysHQ/yosys/issues/2645

How would I go about documenting and excluding s390x from building yosys
and is there anything I need to do about the non-offical Debian ports
architectures or can I just let those builds fail without it affecting
yosys' migration?

Thanks,
--Daniel


signature.asc
Description: PGP signature

Bug#1006836: transition: python3.10 as default

[Markus Blatt]

Hi,

Am Wed, Mar 30, 2022 at 12:22:29PM +0200 schrieb Markus Blatt:

I think I figured out what the issue is. The cmake configuration files of all 
opm modules
have an explicit list of libraries that need to be linked with the library of 
the module and
this is always used for linking. This list is only updated if the 
module/package is rebuilt.
All modules built before the transition have a reference to 
/usr/lib/x86_64-linux-gnu/libpython3.9.so which was in the Cmake 
configuration file of opm-common

when they where built. The only way to get rid of them seems to be rebuilding 
all. Hence one
would need to change the dependencies along the following lines

dependency level 3: opm-grid, opm-material, dependency level 4: 
opm-models, opm-uscaling

dependency level 5: opm-simulators (currently level 3)



As there were some packaging improvements lying aroud anyway, I pushed new
releases for opm-grid, opm-material, opm-models, opm-upscaling. They did
build fine and are now installed in sid. I think this should fix the problem
for opm-simulators, once you trigger a rebuild. (At least it work in the 
salsa-ci).

HTH,

Markus

Bug#1008763: (no subject)

[Richard Z]

I think this lint warning is relevant: 
https://lintian.debian.org/tags/package-contains-no-arch-dependent-files?version=2.114.162

Might be best to mark it as 
Architecture: all

Richard

Bug#1008808: texlive-games: [chess.sty] Incorrect usage of babel breaks package

[Asher Gordon]

Package: texlive-games
Version: 2021.20220204-1
Severity: normal
X-Debbugs-Cc: Asher Gordon 
File: /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty

Dear Maintainer,

The file /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty (used
by the LaTeX files generated by Scid) uses "\input english.sty" instead
of "\usepackage[english]{babel}". This causes a lot of errors when
compiling a LaTeX file that uses the chess package. If the errors are
ignored (e.g. by using "-interaction nonstopmode"), then the compiled
document has a lot of garbage at the start.

The following is a minimal example that produces the error:
\documentclass{article}

\usepackage{chess}

\begin{document}

This is a test.

\begin{chess}
  1.~e4 c5 2.~Nf3 Nc6
\end{chess}

\end{document}
The test.fls file produced by
"pdflatex -interaction nonstopmode -recorder test.tex" is attached
below:
PWD /tmp/tmp.mH6e5epKvE
INPUT /etc/texmf/web2c/texmf.cnf
INPUT /usr/share/texmf/web2c/texmf.cnf
INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
INPUT /var/lib/texmf/web2c/pdftex/pdflatex.fmt
INPUT test.tex
OUTPUT test.log
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/english.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel-english/english.ldf
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.def
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/txtbabel.def
INPUT /usr/share/texlive/texmf-dist/fonts/map/fontname/texfonts.map
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/chess/chess20.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/chess/chessf10.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr6.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmsy6.tfm
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT ./test.aux
INPUT test.aux
INPUT test.aux
OUTPUT test.aux
OUTPUT test.pdf
INPUT /var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map
INPUT test.aux
INPUT 
/home/asher/.texlive2021/texmf-var/fonts/pk/ljfour/public/chess/chessf10.600pk
INPUT /usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb
The following change resolves most of the errors:
--- /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty~	2022-04-01 15:57:17.0 -0400
+++ /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty	2022-04-01 16:26:46.228383005 -0400
@@ -61,7 +61,7 @@
 %
 % Do we have language support? Otherwise take default language!
 %
-\ifx\undefined\babel@core@loaded\input english.sty\fi
+\ifx\undefined\babel@core@loaded\usepackage[english]{babel}\fi
 
 
 \def\@set[#1#2](#3){%arguments: [a-h1-8]()
H

Bug#999194: mathtex: diff for NMU version 1.03-1.1

[Marcos Talau]

Control: tags 620375 + pending
Control: tags 999194 + patch
Control: tags 999194 + pending

Dear maintainer,

I've prepared an NMU for mathtex (versioned as 1.03-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u mathtex-1.03/debian/changelog mathtex-1.03/debian/changelog
--- mathtex-1.03/debian/changelog
+++ mathtex-1.03/debian/changelog
@@ -1,3 +1,12 @@
+mathtex (1.03-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to fix a hang due to use of strcpy() on overlapping region.
+Thanks to Steven McDonald. Closes: #620375.
+  * debian/rules: Add build-{arch,indep} (Closes: #999194).
+
+ -- Marcos Talau   Thu, 31 Mar 2022 22:07:51 -0300
+
 mathtex (1.03-1) unstable; urgency=high
 
   * New upstream release.
diff -u mathtex-1.03/debian/rules mathtex-1.03/debian/rules
--- mathtex-1.03/debian/rules
+++ mathtex-1.03/debian/rules
@@ -75,4 +75,6 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+build-arch: build
+build-indep: build
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install configure
diff -u mathtex-1.03/mathtex.1 mathtex-1.03/mathtex.1
--- mathtex-1.03/mathtex.1
+++ mathtex-1.03/mathtex.1
@@ -29,4 +29,4 @@
 On Debian systems, the complete text of the GNU General Public 
 License can be found in /usr/share/common-licenses/GPL. 
  
-.\" created by instant / docbook-to-man, Tue 01 Dec 2009, 19:59 
+.\" created by instant / docbook-to-man 
only in patch2:
unchanged:
--- mathtex-1.03.orig/mathtex.c
+++ mathtex-1.03/mathtex.c
@@ -3455,7 +3455,9 @@
 shift from left or right to accommodate replacement of its nfirst chars by to
 -- */
 if ( tolen < nfirst )			/* shift left is easy */
-  strcpy(from,from+nshift);		/* because memory doesn't overlap */
+  { char *pfrom = from;
+for ( ; *pfrom != '\0'; pfrom++ )
+  *pfrom = *(pfrom+nshift); }
 if ( tolen > nfirst )			/* need more room at start of from */
   { char *pfrom = from+strlen(from);	/* ptr to null terminating from */
 for ( ; pfrom>=from; pfrom-- )	/* shift all chars including null */

Bug#1008807: ksystemstats: Please switch Build-Depends to libsensors-dev (from libsensors4-dev)

[Aurelien Jarno]

Package: ksystemstats
Version: 5.24.4-1
Severity: normal
User: aure...@debian.org
Usertags: libsensors-dev-transition

Dear maintainer,

ksystemstats build-depends on libsensors4-dev, the development package
from lm-sensors. For historical reasons the development package is
versioned. Following the transition of the library to libsensors5 a few
years ago, it made sense to rename the development package to
libsensors-dev.

In that regard a libsensors4-dev is a transitional package depending o
libsensors-dev that is going to be removed soon. Your package therefore
needs an update. The change should just be a matter of running:

  sed -i -e 's/libsensors4-dev/libsensors-dev/g' debian/control

Thanks,
Aurelien

Bug#1008804: RM: googlefontdirectory-tools -- QoRA; Unmaintained; Superceded by src:gftools

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: martinerikwer...@gmail.com debian-fo...@lists.debian.org

Dear Debian FTP Masters,

I am requesting the removal of src:googlefontdirectory-tools (
https://tracker.debian.org/pkg/googlefontdirectory-tools ) from Debian
Unstable.

* Currently googlefontdirectory-tools is RC-Buggy due to dependency on
python2.
* According to
https://github.com/google/fonts/commit/e6f5d843b7547be7fb774c0dbe75da9212934701
, src:googlefontdirectory-tools is now replaced by
https://github.com/googlefonts/tools , which is packaged separately at
https://tracker.debian.org/pkg/gftools .
* Currently googlefontdirectory-tools has no reverse dependencies and
reverse build-dependencies.
* The package popcon is low (22).


As a result, I believe this package removal is feasible. Please let me know
if there are any questions.

Thanks,
Boyuan Yang



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

Bug#1008782: gnome-core: Install gnome-text-editor by default

[Simon McVittie]

Control: clone -1 -2 -3
Control: retitle -2 gnome-console: should be an x-terminal-emulator
Control: forwarded -2 https://gitlab.gnome.org/GNOME/console/-/issues/26
Control: reassign -2 gnome-console
Control: retitle -3 gnome-console: current working directory not detected
Control: forwarded -3 https://gitlab.gnome.org/GNOME/console/-/issues/124
Control: reassign -3 gnome-console

On Fri, 01 Apr 2022 at 09:10:00 -0400, Jeremy Bicha wrote:
> 1. Install gnome-text-editor by default but allow gedit as an alternate for 
> now.
> https://salsa.debian.org/gnome-team/meta-gnome3/-/merge_requests/6
> 
> - GNOME 42 has gnome-text-editor as the only text editor in their core set.

This seems good to me, FWIW.

This seems like it's a bit like the situation in KDE, which has both
kwrite (a simple text editor analogous to Windows Notepad, included in
their equivalent of gnome-core) and kate (a more complicated text editor
for programmers, included in their equivalent of gnome), which share code.

> 2. Allow gnome-console as an alternative to gnome-terminal but keep
> gnome-terminal as the default terminal for now.

I think being an x-terminal-emulator alternative is probably a blocker
for this? (That shouldn't be rocket science: worst-case, we can have a
wrapper script like gnome-terminal does.)

(Bug cloned as -2)

> + New tabs should open with the same working directory as the current
> tab. Works on Fedora; needs something else to work on Debian.

(Bug cloned as -3)

It seems /etc/profile.d/vte-2.91.sh isn't getting sourced: if I "."
that, I get __vte_osc7 added to the precmd_functions array in zsh.
I think all shells in Fedora source /etc/profile.d/* by default, but
that is not true in Debian?

gnome-terminal has a non-upstreamed patch to make the terminal introspect
the current working directory from the terminal's child process instead
of having to rely on the OSC 7 escape sequence, but presumably gnome-console
doesn't have that.

The gnome-terminal patch was sent upstream years ago, but upstream
refused to apply it because they consider vte.sh emitting OSC 7 to be
a better solution; meanwhile, the various shells in Debian don't always
source /etc/profile.d (e.g. bash only when it is a login shell, and zsh
not at all, unless invoked as sh). So we have a deadlock :-(

smcv

Bug#1008803: insighttoolkit4: FTBFS with Python 3.10

[Sebastian Ramacher]

Source: insighttoolkit4
Version: 4.13.3withdata-dfsg2-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

insighttoolkit4 FTBFS:

[ 33%] Building CXX object 
Modules/ThirdParty/VNL/src/vxl/core/vnl/algo/CMakeFiles/itkvnl_algo.dir/vnl_gaussian_kernel_1d.cxx.o
cd /<>/BUILD/Modules/ThirdParty/VNL/src/vxl/core/vnl/algo && 
/usr/bin/c++ -DVXL_LEGACY_ERROR_REPORTING -DVXL_WARN_DEPRECATED 
-DVXL_WARN_DEPRECATED_ONCE -Ditkvnl_algo_EXPORTS 
-I/<>/Modules/ThirdParty/VNL/src/vxl/v3p/netlib 
-I/<>/Modules/ThirdParty/VNL/src/vxl/vcl 
-I/<>/Modules/ThirdParty/VNL/src/vxl/core 
-I/<>/BUILD/Modules/ThirdParty/VNL/src/vxl/v3p/netlib 
-I/<>/BUILD/Modules/ThirdParty/VNL/src/vxl/vcl 
-I/<>/BUILD/Modules/ThirdParty/VNL/src/vxl/core 
-I/<>/Modules/ThirdParty/VNL/src/vxl/v3p/netlib/linalg 
-I/<>/Modules/ThirdParty/VNL/src/vxl/core/vnl/algo 
-I/<>/Modules/ThirdParty/VNL/src/vxl/core/vnl -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/nifti 
-g1  -Wall -Wcast-align -Wdisabled-optimization -Wextra -Wformat=2 
-Winvalid-pch -Wno-format-nonliteral -Wpointer-arith -Wshadow -Wunused 
-Wwrite-strings -funit-at-a-time -Wno-strict-overflow -Wno-deprecated 
-Wno-invalid-offsetof -Woverloaded-virtual -Wstrict-null-sentinel  -w  -fPIC 
-fvisibility=hidden -fvisibility-inlines-hidden   -Wno-undefined-var-template 
-msse2 -MD -MT 
Modules/ThirdParty/VNL/src/vxl/core/vnl/algo/CMakeFiles/itkvnl_algo.dir/vnl_gaussian_kernel_1d.cxx.o
 -MF CMakeFiles/itkvnl_algo.dir/vnl_gaussian_kernel_1d.cxx.o.d -o 
CMakeFiles/itkvnl_algo.dir/vnl_gaussian_kernel_1d.cxx.o -c 
/<>/Modules/ThirdParty/VNL/src/vxl/core/vnl/algo/vnl_gaussian_kernel_1d.cxx
Traceback (most recent call last):
  File "/<>/Wrapping/Generators/SwigInterface/igenerator.py", line 
971, in 
wrappingNamespace = generate_wrapping_namespace(moduleName)
  File "/<>/Wrapping/Generators/SwigInterface/igenerator.py", line 
962, in generate_wrapping_namespace
wrappingNamespace = globalNamespace.namespace('_wrapping_')
  File 
"/<>/CMake/../Modules/ThirdParty/pygccxml/src/pygccxml/declarations/namespace.py",
 line 119, in namespace
self._find_single(
  File 
"/<>/CMake/../Modules/ThirdParty/pygccxml/src/pygccxml/declarations/scopedef.py",
 line 479, in _find_single
norm_keywds = self.__normalize_args(**keywds)
  File 
"/<>/CMake/../Modules/ThirdParty/pygccxml/src/pygccxml/declarations/scopedef.py",
 line 371, in __normalize_args
if isinstance(keywds['name'], collections.Callable) and \
AttributeError: module 'collections' has no attribute 'Callable'

See
https://buildd.debian.org/status/fetch.php?pkg=insighttoolkit4&arch=amd64&ver=4.13.3withdata-dfsg2-1%2Bb1&stamp=1648838331&raw=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1008801: gnucash: FTBFS on armel

[Sebastian Ramacher]

Control: retitle -1 gnucash: FTBFS on armhf

On 2022-04-01 20:53:42 +0200, Sebastian Ramacher wrote:
> Source: gnucash
> Version: 1:4.10-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
> 
> gnucash FTBFS on armel:

armhf of course, sorry

Cheers

> 
>  56/118 Test  #56: test-gnc-numeric .   Passed0.01 sec
> Start  57: test-gnc-timezone
>  57/118 Test  #57: test-gnc-timezone Bus error***Exception:   
> 0.01 sec
> Start  58: test-gnc-datetime
>  58/118 Test  #58: test-gnc-datetime Bus error***Exception:   
> 0.01 sec
> Start  59: test-import-map
> 
> …
> 
> The following tests FAILED:
>57 - test-gnc-timezone (Bus error)
>58 - test-gnc-datetime (Bus error)
> Errors while running CTest
> Output from these tests are in: 
> /<>/.build/Testing/Temporary/LastTest.log
> Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
> make[5]: *** [CMakeFiles/check.dir/build.make:73: CMakeFiles/check] Error 8
> 
> See
> https://buildd.debian.org/status/fetch.php?pkg=gnucash&arch=armhf&ver=1%3A4.10-1&stamp=1648644190&raw=0
> 
> Cheers
> -- 
> Sebastian Ramacher



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1008802: chemps2: FTBFS on armel

[Sebastian Ramacher]

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

chemps2 FTBFS on armel:


cd obj-arm-linux-gnueabi/ && ctest -R "^test3|^test5|^test8"
Test project /<>/obj-arm-linux-gnueabi
Start 3: test3
1/3 Test #3: test3 ***Exception: SegFault 14.74 sec
Start 5: test5
2/3 Test #5: test5    Passed   31.19 sec
Start 8: test8
3/3 Test #8: test8    Passed   15.10 sec

67% tests passed, 1 tests failed out of 3

Total Test time (real) =  61.05 sec

The following tests FAILED:
  3 - test3 (SEGFAULT)
Errors while running CTest
Output from these tests are in: 
/<>/obj-arm-linux-gnueabi/Testing/Temporary/LastTest.log


See
https://buildd.debian.org/status/fetch.php?pkg=chemps2&arch=armel&ver=1.8.11-1%2Bb1&stamp=1648469570&raw=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1008801: gnucash: FTBFS on armel

[Sebastian Ramacher]

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

gnucash FTBFS on armel:

 56/118 Test  #56: test-gnc-numeric .   Passed0.01 sec
Start  57: test-gnc-timezone
 57/118 Test  #57: test-gnc-timezone Bus error***Exception:   
0.01 sec
Start  58: test-gnc-datetime
 58/118 Test  #58: test-gnc-datetime Bus error***Exception:   
0.01 sec
Start  59: test-import-map

…

The following tests FAILED:
 57 - test-gnc-timezone (Bus error)
 58 - test-gnc-datetime (Bus error)
Errors while running CTest
Output from these tests are in: 
/<>/.build/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
make[5]: *** [CMakeFiles/check.dir/build.make:73: CMakeFiles/check] Error 8

See
https://buildd.debian.org/status/fetch.php?pkg=gnucash&arch=armhf&ver=1%3A4.10-1&stamp=1648644190&raw=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1008716: problem with cups

[alain]

i installed hplip :

hplip:
  Installé : 3.21.12+dfsg0-1+b1
  Candidat : 3.21.12+dfsg0-1+b1
 Table de version :
 *** 3.21.12+dfsg0-1+b1 500
        500 http://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
     3.21.12+dfsg0-1 100
        100 http://deb.debian.org/debian testing/main amd64 Packages
hplip-gui:
  Installé : 3.21.12+dfsg0-1
  Candidat : 3.21.12+dfsg0-1
 Table de version :
 *** 3.21.12+dfsg0-1 500
        100 http://deb.debian.org/debian testing/main amd64 Packages
        100 http://deb.debian.org/debian testing/main i386 Packages
        500 http://deb.debian.org/debian unstable/main amd64 Packages
        500 http://deb.debian.org/debian unstable/main i386 Packages
        100 /var/lib/dpkg/status


hp-check

Saving output in log file: /home/alain/hp-check.log

HP Linux Imaging and Printing System (ver. 3.21.12)
Dependency/Version Check Utility ver. 15.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before 
compiling

the HPLIP supplied tarball (.tar.gz or .run) to determine if the proper
dependencies are installed to successfully compile HPLIP.
2. Run-time check mode (-r or --run): Use this mode to determine if a 
distro
supplied package (.deb, .rpm, etc) or an already built HPLIP supplied 
tarball

has the proper dependencies installed to successfully run.
3. Both compile- and run-time check mode (-b or --both) (Default): This 
mode
will check both of the above cases (both compile- and run-time 
dependencies).


Check types:
a. EXTERNALDEP - External Dependencies
b. GENERALDEP - General Dependencies (required both at compile and run 
time)

c. COMPILEDEP - Compile time Dependencies
d. [All are run-time checks]
PYEXT SCANCONF QUEUES PERMISSION

Status Types:
    OK
    MISSING       - Missing Dependency or Permission or Plug-in
    INCOMPAT      - Incompatible dependency-version or Plugin-version

-Traceback (most recent call last):
  File "/usr/bin/hp-check", line 861, in 
    dep.core.init()
  File "/usr/share/hplip/installer/core_install.py", line 523, in init
    self.get_distro()
  File "/usr/share/hplip/installer/core_install.py", line 661, in 
get_distro

    if 'MX' in distro_release_name:

NameError: name 'distro_release_name' is not defined


cat /home/alain/hp-check.log

hp-check[94120]: info: :
hp-check[94120]: info: :[01mHP Linux Imaging and Printing System (ver. 
3.21.12)[0m

hp-check[94120]: info: :[01mDependency/Version Check Utility ver. 15.1[0m
hp-check[94120]: info: :
hp-check[94120]: info: :Copyright (c) 2001-18 HP Development Company, LP
hp-check[94120]: info: :This software comes with ABSOLUTELY NO WARRANTY.
hp-check[94120]: info: :This is free software, and you are welcome to 
distribute it
hp-check[94120]: info: :under certain conditions. See COPYING file for 
more details.

hp-check[94120]: info: :
hp-check[94120]: info: :[01mNote: hp-check can be run in three modes:[0m
hp-check[94120]: info: :1. Compile-time check mode (-c or --compile): 
Use this mode before compiling
hp-check[94120]: info: :the HPLIP supplied tarball (.tar.gz or .run) to 
determine if the proper
hp-check[94120]: info: :dependencies are installed to successfully 
compile HPLIP.
hp-check[94120]: info: :2. Run-time check mode (-r or --run): Use this 
mode to determine if a distro
hp-check[94120]: info: :supplied package (.deb, .rpm, etc) or an already 
built HPLIP supplied tarball
hp-check[94120]: info: :has the proper dependencies installed to 
successfully run.
hp-check[94120]: info: :3. Both compile- and run-time check mode (-b or 
--both) (Default): This mode
hp-check[94120]: info: :will check both of the above cases (both 
compile- and run-time dependencies).

hp-check[94120]: info: :
hp-check[94120]: info: :Check types:
hp-check[94120]: info: :a. EXTERNALDEP - External Dependencies
hp-check[94120]: info: :b. GENERALDEP - General Dependencies (required 
both at compile and run time)

hp-check[94120]: info: :c. COMPILEDEP - Compile time Dependencies
hp-check[94120]: info: :d. [All are run-time checks]
hp-check[94120]: info: :PYEXT SCANCONF QUEUES PERMISSION
hp-check[94120]: info: :
hp-check[94120]: info: :Status Types:
hp-check[94120]: info: :    OK
hp-check[94120]: info: :    MISSING       - Missing Dependency or 
Permission or Plug-in
hp-check[94120]: info: :    INCOMPAT      - Incompatible 
dependency-version or Plugin-version


hp-check[94120]: info: :


alain@sid:~$ lpstat -t
scheduler is running
system default destination: HP-ENVY-5530-series
matériel pour HP-ENVY-5530-series : 
hp:/usb/ENVY_5530_series?serial=CN595530XD06BX

HP-ENVY-5530-series accepte des requêtes depuis ven. 01 avril 2022 17:08:51
printer HP-ENVY-5530-series is idle.  enabled since ven. 01 avril 2022 
17:08:51

Bug#1008800: heartbeat: Build-Depends on libltdl3-dev

[Sebastian Ramacher]

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

heartbeat build-depends on missing:
- libltdl3-dev:amd64

libltdl-dev no longer provides libltdl3-dev. Please adapt Build-Depends.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1008799: fife: FTBFS on mipsel

[Sebastian Ramacher]

Source: fife
Version: 0.4.2-3
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

fife FTBFS on mipsel:

make[3]: Entering directory '/<>/obj-mipsel-linux-gnu'
[  1%] Building CXX object 
CMakeFiles/_fife.dir/CMakeFiles/_fife.dir/fifePYTHON_wrap.cxx.o
/usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK 
-DBOOST_SYSTEM_DYN_LINK -DHAVE_OPENGL -DLOG_ENABLED -DTIXML_USE_STL 
-D_fife_EXPORTS -I/<>/obj-mipsel-linux-gnu 
-I/<>/engine/core -I/<> -I/usr/include/SDL2 
-I/usr/include/AL -I/usr/include/python3.10 -std=c++11 -fPIC -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -g1 -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -Wno-error -O3 
-DNDEBUG -fPIC -MD -MT 
CMakeFiles/_fife.dir/CMakeFiles/_fife.dir/fifePYTHON_wrap.cxx.o -MF 
CMakeFiles/_fife.dir/CMakeFiles/_fife.dir/fifePYTHON_wrap.cxx.o.d -o 
CMakeFiles/_fife.dir/CMakeFiles/_fife.dir/fifePYTHON_wrap.cxx.o -c 
/<>/obj-mipsel-linux-gnu/CMakeFiles/_fife.dir/fifePYTHON_wrap.cxx
virtual memory exhausted: Cannot allocate memory
make[3]: *** [CMakeFiles/_fife.dir/build.make:79: 
CMakeFiles/_fife.dir/CMakeFiles/_fife.dir/fifePYTHON_wrap.cxx.o] Error 1

See
https://buildd.debian.org/status/fetch.php?pkg=fife&arch=mipsel&ver=0.4.2-3%2Bb1&stamp=1648798473&raw=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1008798: gdcm: FTBFS on s390x

[Sebastian Ramacher]

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

gdcm FTBFS on s390x:

[593/642] : && /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -Wl,--as-needed 
Utilities/VTK/Applications/CMakeFiles/gdcm2pnm.dir/gdcm2pnm.cxx.o -o 
bin/gdcm2pnm  bin/libvtkgdcm.so.3.0.11  bin/libgdcmMSFF.so.3.0.11  
/usr/lib/s390x-linux-gnu/libfreetype.so  /usr/lib/s390x-linux-gnu/libz.so  
/usr/lib/s390x-linux-gnu/libexpat.so  
/usr/lib/s390x-linux-gnu/libvtkDomainsChemistryOpenGL2-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libjpeg.so  /usr/lib/s390x-linux-gnu/libpng.so  
/usr/lib/s390x-linux-gnu/libtiff.so  
/usr/lib/s390x-linux-gnu/libvtkFiltersGeneric-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkFiltersHyperTree-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkFiltersParallelDIY2-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkFiltersParallelFlowPaths-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkFiltersParallelGeometry-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkFiltersParallelImaging-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkFiltersParallelMPI-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkFiltersParallelStatistics-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkFiltersPoints-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkFiltersProgrammable-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkFiltersPython-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libpython3.10.so  /usr/lib/libvtkWrappingTools-7.1.a  
/usr/lib/s390x-linux-gnu/libvtkFiltersReebGraph-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkFiltersSMP-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkFiltersSelection-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkFiltersTexture-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkFiltersVerdict-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkverdict-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOAMR-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/hdf5/openmpi/libhdf5.so  
/usr/lib/s390x-linux-gnu/libcrypto.so  /usr/lib/s390x-linux-gnu/libcurl.so  
/usr/lib/s390x-linux-gnu/libsz.so  /usr/lib/s390x-linux-gnu/libdl.so  
/usr/lib/s390x-linux-gnu/libm.so  
/usr/lib/s390x-linux-gnu/openmpi/lib/libmpi.so  
/usr/lib/s390x-linux-gnu/openmpi/lib/libmpi_cxx.so  
/usr/lib/s390x-linux-gnu/hdf5/openmpi/libhdf5_hl.so  
/usr/lib/s390x-linux-gnu/libvtkIOEnSight-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libnetcdf_c++.so  
/usr/lib/s390x-linux-gnu/libnetcdf.so  
/usr/lib/s390x-linux-gnu/libvtkIOExport-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkRenderingGL2PSOpenGL2-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libgl2ps.so  
/usr/lib/s390x-linux-gnu/libvtkIOFFMPEG-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOMovie-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libtheoraenc.so  
/usr/lib/s390x-linux-gnu/libtheoradec.so  /usr/lib/s390x-linux-gnu/libogg.so  
/usr/lib/s390x-linux-gnu/libvtkIOGDAL-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOGeoJSON-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libjsoncpp.so  
/usr/lib/s390x-linux-gnu/libvtkIOImport-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOInfovis-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libxml2.so  
/usr/lib/s390x-linux-gnu/libvtkIOMINC-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOMPIImage-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOMPIParallel-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOParallel-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIONetCDF-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOMySQL-7.1.so.7.1p.1  -lsqlite3  
/usr/lib/s390x-linux-gnu/libvtkIOODBC-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOPLY-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOParallelExodus-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOParallelLSDyna-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOParallelNetCDF-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOParallelXML-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOPostgreSQL-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOTecplotTable-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOVPIC-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkVPIC-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOVideo-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkIOXdmf2-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkxdmf2-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkImagingMorphological-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkImagingStatistics-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkImagingStencil-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkInfovisBoostGraphAlgorithms-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkInteractionImage-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkLocalExample-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkParallelMPI4Py-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkRenderingContextOpenGL2-7.1.so.7.1p.1  
/usr/lib/s390x-linux-gnu/libvtkRenderingExternal-7.1.so.7.1p.1  
/usr/lib/s390x

Bug#1008797: miniupnpd: systemd unit file is broken

[Matteo Croce]

Package: miniupnpd
Version: 1:2.2.1-matteo
Severity: normal
X-Debbugs-Cc: mcr...@linux.microsoft.com

Dear Maintainer,

The miniupnpd.service unit file is broken, because it contains a comment
embedded into a directive:

TasksMax=2 #for /etc/miniupnpd/nft_removeall.sh. miniupnpd alone needs only 1.

And generates the following error:

systemd[1]: /lib/systemd/system/miniupnpd.service:14: Invalid maximum tasks 
value '2 #for /etc/miniupnpd/nft_removeall.sh. miniupnpd alone needs only 1.', 
ignoring: Invalid argument

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

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

Versions of packages miniupnpd depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  lsb-base   11.1.0
ii  miniupnpd-nftables 1:2.2.1-matteo
ii  uuid-runtime   2.36.1-8+deb11u1

miniupnpd recommends no packages.

miniupnpd suggests no packages.

-- debconf information:
* miniupnpd/start_daemon: true
  miniupnpd/force_igd_desc_v1: false
* miniupnpd/listen: br0
* miniupnpd/iface: pppoe-data
  miniupnpd/ip6script: false

Bug#1008796: miniupnpd: compile miniupnpd also with IGD v1 only

[Matteo Croce]

Package: miniupnpd
Version: 2.2.1-1
Severity: normal

Dear Maintainer,

miniupnpd has the force_igd_desc_v1 config option to use the v1 IGD descriptor.
Unfortunately, the runtime behaviour differs between the daemon compiled with
and without --igd2, even when force_igd_desc_v1 set.
This makes the daemon non interoperable with some devices.
Please consider adding another package like miniupnpd-igd1, where the daemon
is compiled without --igd2.

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

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

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


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

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

Versions of packages miniupnpd depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  lsb-base   11.1.0
ii  miniupnpd-nftables 2.2.1-1
ii  uuid-runtime   2.36.1-8+deb11u1

miniupnpd recommends no packages.

miniupnpd suggests no packages.

-- debconf information:
  miniupnpd/force_igd_desc_v1: false
* miniupnpd/start_daemon: false
  miniupnpd/ip6script: false
* miniupnpd/iface: eno1
* miniupnpd/listen:

Bug#1008795: ns3: FTBFS with python 3.10

[Sebastian Ramacher]

Source: ns3
Version: 3.35+dfsg-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

ns3 FTBFS:

[1976/2214] Processing command (${PYTHON}): 
../bindings/python/ns3modulegen-modular.py 
../src/antenna/bindings/modulegen__gcc_LP64.py -> 
src/antenna/bindings/ns3module.cc src/antenna/bindings/ns3module.h 
src/antenna/bindings/ns3modulegen.log
Waf: Leaving directory `/<>/ns-3.35/build-shared'
Build failed
 -> task in 'pybindgen(ns3 module antenna)' failed with exit status 1 (run with 
-v to display more information)
make[1]: *** [debian/rules:56: override_dh_auto_build-arch] Error 1

See
https://buildd.debian.org/status/fetch.php?pkg=ns3&arch=amd64&ver=3.35%2Bdfsg-1%2Bb2&stamp=1648500905&raw=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1008794: gnuradio: FTBFS with python 3.10 as default

[Sebastian Ramacher]

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

gnuradio FTBFS:

if [ -f debian/tmp/usr/share/doc/gnuradio*/config/thrift.conf.example ] ; then \
 install -d debian/gnuradio/usr/share/doc/gnuradio/config &&\
 mv debian/tmp/usr/share/doc/gnuradio*/config/* 
debian/gnuradio/usr/share/doc/gnuradio/config/ ; fi
make[1]: Leaving directory '/<>'
   dh_install -a -O--buildsystem=cmake\+ninja
dh_install: warning: Cannot find (any matches for) "usr/lib/python*" (tried in 
., debian/tmp)

dh_install: warning: gnuradio missing files: usr/lib/python*
dh_install: error: missing files, aborting
make: *** [debian/rules:6: binary-arch] Error 25

See
https://buildd.debian.org/status/fetch.php?pkg=gnuradio&arch=amd64&ver=3.10.1.1-1%2Bb1&stamp=1648812887&raw=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#942622: Would the Games Team adopt Lightyears (pygame based, Python 3 port available)?

[Sandro Tosi]

gentle ping, can the Games team please proceed with the upload of
lightyears? thanks!

On Thu, Sep 16, 2021 at 10:00 AM Sandro Tosi  wrote:
>
> On Thu, Sep 16, 2021 at 7:35 AM Olek Wojnar  wrote:
> >
> > Hi
> >
> > On Wed, Sep 15, 2021, 22:36 Sandro Tosi  wrote:
> >>
> >> > I've moved the package under the games-team [1]. I was going to give you
> >> > access to it but I can't find a Salsa account for you. If you don't have 
> >> > an
> >> > account yet, you can easily create one [2] and let me know your username.
> >> > I'll then give you access to the repository and you can make all of your
> >> > changes. Once you're happy with it, I'll review and upload. Let me know 
> >> > if
> >> > you have any questions!
> >>
> >> what's the hold up with the upload? it's been moved to the games team
> >> more than a year ago, it's under that team maintenance, so please
> >> proceed asap with an upload to fix this RC bug
> >
> >
> > Last I checked, Steve had not created a Salsa account yet. If he has, and 
> > has updated the repo with the new version, I'll be happy to review and 
> > upload!
> >
> > -Olek
> >
> > PS Added Steve to CC since I'm not sure if he's subscribed to this bug.
>
> I do not see a mail from Steve regarding lightyears (at least on the 2
> RC bugs) in more than a year; i suspect waiting longer wont help.
>
> Upstream ported this project to py3k, so now that you've imported this
> in the games team, please proceed with upgrading it to the latest
> version and upload it to unstable, so that we can formalize the
> transition and we can remove the dead repo from the python team org.
>
> Regards,
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1008087: i2pd: I2Pd crashes after running for about 2-5 minutes. It is running on a VPS server with 2 gigs RAM.

[R4SAS]

Hello.

Packages older than 2.41.0 are may crash due to starting of development 
transport protocol SSU2, which is not handled by old versions.
That's why nothing can be done with debian-provided packages with old 
versions.


Use our community repository instead for now, because our Debian 
maintainer didn't updated package for half-year (still 2.39.0 - 
https://salsa.debian.org/yangfl-guest/i2pd), I can't take maintainement 
of package here due to requirement to use real name and contacts, and no 
one wants to take maintainership.


The only way to make it work - update package in all distributions to 
2.41.0.

Bug#1008752: avifile: autopkgtest regression on armhf: Bus error

[Paul Gevers]

Hi,

On 01-04-2022 14:53, Ying-Chun Liu (PaulLiu) wrote:
I need some help. Actually I know this bug for a while but I just cannot 
fix it. I've tried to reproduce the bug on qemu-user-static armhf chroot 
envorionment and PorterBox (abel.debian.org), on both platform the 
autopkgtest just passed without problem.


I think the bug should be easy to locate if I can run gdb and see the 
backtrace when the bus error happened.
But I just cannot reproduce this bug on my side or on porter box. If 
possible I hope to get some core dump when bus error happened on the 
machine that runs the test.


Glad to help, but can you please give me exact commands what you want me 
to run in the testbed? I'm not very familiar with gdb and last time I 
used it is years ago.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008793: fribidi: CVE-2022-25308 CVE-2022-25309 CVE-2022-25310

[Salvatore Bonaccorso]

Source: fribidi
Version: 1.0.8-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.0.5-3.1
Control: found -1 1.0.5-3.1+deb10u1

Hi,

The following vulnerabilities were published for fribidi.

CVE-2022-25308[0], CVE-2022-25309[1] and CVE-2022-25310[2].

The are fixed all on master in git upstream already (but no tagged
version appeared yet including the fixes).

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-25308
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25308
[1] https://security-tracker.debian.org/tracker/CVE-2022-25309
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25309
[2] https://security-tracker.debian.org/tracker/CVE-2022-25310
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25310

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1008760: upgrade-reports: Mouse touchpad elantech broken edge scrolling after upgrade to bullseye

[Paul Gevers]

Control: reassign -1 src:linux

Hi Umut,

After asking around, the suspicion is that this is mostly likely due to 
the kernel, hence I'm reassigning to the linux source package. If this 
was wrong, the kernel maintainers can hopefully help to point where it 
should go.


Paul

On 31-03-2022 22:51, Umut Erdogan wrote:

Package: upgrade-reports
Severity: important
Tags: upstream

Hi debian maintainers!

As by upgrading from buster to bullseye as also by using bullseye live image I
have about 70% of touchpad width acting as edgescrolling area.

I tried the debian 11 gnome and kde images and in both the same effect.

At first I thought that the mouse would not work at all.

But than I realized, that it just was in that area in scrolling mode.

Only if I start to touch it at the remaining left area the mouse pointer worked
as before.

If I do so I can also swipe to the right most areas of the pad.

That means that between buster and bullseye something got broken. Either from
linux kernel or the firmware for elantech.

So for now I switched back from bullseye to buster again until this gets fixed.

Hope this happens until EOL of buster.

Kind regards.

Umut Erdogan



-- System Information:
Debian Release: 10.11
   APT prefers oldstable-updates
   APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, i386

Kernel: Linux 4.19.0-19-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008792: Should vmtk be removed?

[Moritz Muehlenhoff]

Source: vmtk
Version: 1.3+dfsg-2.3
Severity: serious

Your package came up as a candidate for removal from Debian:

- Depends on Python 2 and thus removed from testing since 2019 (current 
upstream 1.4 is fixed, though)
- Last maintainer upload in 2016

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1008791: Should googlefontdirectory-tools be removed?

[Moritz Muehlenhoff]

Source: googlefontdirectory-tools
Version: 20120309.1-1.1
Severity: serious

Your package came up as a candidate for removal from Debian:

- Still depends on Python 2 and thus removed from testing since 2019
- Last maintainer upload in 2015

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1004882: crystal: switch to llvm-toolchain-13

[Paul Gevers]

Hi,

On Wed, 2 Feb 2022 22:42:10 +0100 Sebastian Ramacher 
 wrote:

Source: crystal
Version: 1.2.2+dfsg-1
Severity: important
X-Debbugs-Cc: sramac...@debian.org
Tags: sid bookworm

The current default version of llvm is llvm-toolchain-13. To reduce the
number of llvm versions, please consider switchting to llvm-toolchain-13
(or the unversioned counterpart).


Or if that really doesn't work at this moment, we prefer you to go back 
to llvm-toolchain-11. This package is the second from last package 
holding llvm-toolchain-12 in testing. We'll raise the severity of this 
bug soon.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004883: intel-graphics-compiler: switch to llvm-toolchain-13

[Paul Gevers]

Hi Andreas,

On 01-04-2022 19:12, Andreas Beckmann wrote:
Are there plans to remove llvm-12 from sid, too? Or can it stay there 
(at least as long as it is still buildable and installable)?


As a Release Team member, I don't care so much about packages that stay 
in unstable, but I think Sylvestre will want to remove it there sooner 
rather than later (see #1000941 [1])


You may want to be aware of 
https://lists.debian.org/debian-release/2022/03/msg00887.html


Paul

[1] https://bugs.debian.org/1000941


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004883: intel-graphics-compiler: switch to llvm-toolchain-13

[Andreas Beckmann]

On 25/03/2022 21.48, Paul Gevers wrote:
I've now managed to do the same with llvm-12, so I'd rather introduce 
src:spirv-llvm-translator-12 and src:opencl-clang-12 and leave llvm-11 
alone ;-)


As a Release Team member, I rather have llvm-11 based than llvm-12 base. 
intel-graphics-compiler is the only package why llvm-12 is still in 
testing.


So you'd prefer to add NEW src:spirv-llvm-translator-11 and 
src:opencl-clang-11 in order to get rid of llvm-12 (+rdepends)? IIRC, 
that shouldn't be too difficult.


There does not seem to be any publically visible progress upstream on 
llvm-13 (or later) support :-(


Are there plans to remove llvm-12 from sid, too? Or can it stay there 
(at least as long as it is still buildable and installable)?



Andreas

Bug#1008745: nipy: FTBFS with Python 3.10 as default

[Andreas Tille]

Control: tags -1 upstream
Control: tags -1 help
Control: forwarded -1 https://github.com/nipy/nipy/issues/492

Bug#1008789: node-node-sass: autopkgtest needs update for new version of nodejs: require() of ES modules is not supported.

[Paul Gevers]

Source: node-node-sass
Version: 7.0.1+git20211229.3bb51da+dfsg-1
Severity: serious
X-Debbugs-CC: nod...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:nodejs

Dear maintainer(s),

With a recent upload of nodejs the autopkgtest of node-node-sass fails 
in testing when that autopkgtest is run with the binary packages of 
nodejs from unstable (even with the rebuild binaries from 
node-node-sass). It passes when run with only packages from testing. In 
tabular form:


   passfail
nodejs from testing16.13.2+really14.19.1~dfsg-6
node-node-sass from testing7.0.1+git20211229.3bb51da+dfsg-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of nodejs to testing 
[1]. Of course, nodejs shouldn't just break your autopkgtest (or even 
worse, your package), but it seems to me that the change in nodejs was 
intended and your package needs to update to the new situation.


If this is a real problem in your package (and not only in your 
autopkgtest), the right binary package(s) from nodejs should really add 
a versioned Breaks on the unfixed version of (one of your) package(s). 
Note: the Breaks is nice even if the issue is only in the autopkgtest as 
it helps the migration software to figure out the right versions to 
combine in the tests.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
nodejs/16.13.2+really14.19.1~dfsg-6. I.e. due to versioned dependencies 
or breaks/conflicts.

[1] https://qa.debian.org/excuses.php?package=nodejs

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-node-sass/20479893/log.gz

# Using ./package.(json|yaml)
# Node module name is node-sass
# Build files found: # Test files found: test
# Found debian/tests/pkg-js/files, let's use it
# Files/dir to be installed from source: test
sass-spec
debian/tests/test_modules
# Copy test files
# Copy debian/tests/pkg-js content
'debian/tests/pkg-js' -> 
'/tmp/autopkgtest-lxc.3dgeerq5/downtmp/autopkgtest_tmp/smokeyoCSIg/debian/tests/pkg-js'
'debian/tests/pkg-js/files' -> 
'/tmp/autopkgtest-lxc.3dgeerq5/downtmp/autopkgtest_tmp/smokeyoCSIg/debian/tests/pkg-js/files'
'debian/tests/pkg-js/test' -> 
'/tmp/autopkgtest-lxc.3dgeerq5/downtmp/autopkgtest_tmp/smokeyoCSIg/debian/tests/pkg-js/test'

Found debian/tests/test_modules
'get-stdin' linked into node_modules
# Searching module in /usr/lib/nodejs/node-sass
# Searching module in /usr/lib/x86_64-linux-gnu/nodejs/node-sass
# Found /usr/lib/x86_64-linux-gnu/nodejs/node-sass
# Searching files to link in /usr/lib/x86_64-linux-gnu/nodejs/node-sass
'./bin' -> '/usr/lib/x86_64-linux-gnu/nodejs/node-sass/bin'
'./lib' -> '/usr/lib/x86_64-linux-gnu/nodejs/node-sass/lib'
# subdir node_modules already exists:
# Searching files to link in 
/usr/lib/x86_64-linux-gnu/nodejs/node-sass/node_modules
'./async-foreach' -> 
'/usr/lib/x86_64-linux-gnu/nodejs/node-sass/node_modules/async-foreach'

'./gaze' -> '/usr/lib/x86_64-linux-gnu/nodejs/node-sass/node_modules/gaze'
# subdir get-stdin already exists:
# Searching files to link in 
/usr/lib/x86_64-linux-gnu/nodejs/node-sass/node_modules/get-stdin

ln: failed to create symbolic link './index.js': File exists
### skipping ln: failed to create symbolic link './package.json': File 
exists
### skipping './js-base64' -> 
'/usr/lib/x86_64-linux-gnu/nodejs/node-sass/node_modules/js-base64'
'./sass-graph' -> 
'/usr/lib/x86_64-linux-gnu/nodejs/node-sass/node_modules/sass-graph'
'./scss-tokenizer' -> 
'/usr/lib/x86_64-linux-gnu/nodejs/node-sass/node_modules/scss-tokenizer'
'./stdout-stream' -> 
'/usr/lib/x86_64-linux-gnu/nodejs/node-sass/node_modules/stdout-stream'
'./true-case-path' -> 
'/usr/lib/x86_64-linux-gnu/nodejs/node-sass/node_modules/true-case-path'
'./package.json' -> 
'/usr/lib/x86_64-linux-gnu/nodejs/node-sass/package.json'

'./scripts' -> '/usr/lib/x86_64-linux-gnu/nodejs/node-sass/scripts'
'./src' -> '/usr/lib/x86_64-linux-gnu/nodejs/node-sass/src'
'./vendor' -> '/usr/lib/x86_64-linux-gnu/nodejs/node-sass/vendor'
# Searching module in /usr/share/nodejs/node-sass
# Launch debian/tests/pkg-js/test with sh -ex
+ ls test/api.js+  test/binding.js test/cli.js test/downloadoptions.js 
test/errors.js test/lowlevel.js test/runtime.js test/types.js 
test/useragent.js test/watcher.js

grep -Ev (cli.js|spec.js)
+ mocha test/api.js test/binding.js test/downloadoptions.js 
test/errors.js test/lowlevel.js test/runtime.js test/types.js 
test/useragent.js test/watcher.js

in

Bug#994716: lintian: erroneous unpack-message-for-orig

[Bill Allombert]

On Sun, Sep 19, 2021 at 09:31:42PM +0200, Aurelien Jarno wrote:
> Package: lintian
> Version: 2.106.1
> Severity: normal
> 
> Since recently, I get the following lintian error message on the glibc
> package:
> 
> E: glibc source: unpack-message-for-orig glibc_2.32.orig.tar.xz ar failed for 
> glibc-2.32/htl/libpthread.a
> E: glibc source: unpack-message-for-orig glibc_2.32.orig.tar.xz ar failed for 
> glibc-2.32/htl/libpthread_pic.a
> E: glibc source: unpack-message-for-orig glibc_2.32.orig.tar.xz ar failed for 
> glibc-2.32/htl/libpthread_syms.a
> 
> Those file are not archive, but a linker script. For example
> libpthread.a contains:
> 
> | GROUP(-lpthread_syms)
> | GROUP(-lpthread2 -lrt)
> 
> Lintian should handle this case.

Hello Lintian maintainers,

There are several bugs here
1) not all files ending by '.a' are 'ar' archive files, and this is not
an error.

2) 'unpack-message-for-orig' is used to report error when
unpacking the orig.tar.gz tarball. This is unrelated to what happen here
(an error of "ar" while inspecting binary package), so this tag is
inappropriate.

The combination is a large set of false positive with inappropriate
error messages, just check

https://lintian.debian.org/tags/unpack-message-for-orig?version=2.114.161

Thanks for maintaining Lintian!
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1008751: pytest-mpi: autopkgtest regression: versioned test depends only in experimental

[Andrey Rahmatullin]

On Fri, Apr 01, 2022 at 06:04:38PM +0200, Drew Parsons wrote:
> From
> /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources:
> 
> flufl.lock
Doesn't support Sybil 3.x in sid. The latest version, 7.0, supports it.
It's most likely easy to patch the sid version.

> pytest-mpi
-

> python-parsel
The fix is committed upstream but there was no release since then. It
should be easy to backport the fix.

> python-public
Doesn't support Sybil 3.x in sid. The latest version, 3.0.1, supports it.
It's most likely easy to patch the sid version.

> python-scrapy
Fixed upstream but the upload is postponed until the next bugfix release.
It should be easy to backport the fix.

> python-testfixtures
Should work.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1006743: SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats

[Yuri D'Elia]

Source: python-systemd
Followup-For: Bug #1006743

This issue currently breaks fail2ban for me, which is now defaulting to
python3.10 (via the default python3 dependency).

Bug#1008788: src:deepdiff: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: deepdiff
Version: 3.3.0-3
Severity: serious
Control: close -1 5.6.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1005036

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:deepdiff has been trying to migrate for 61 
days [2]. Hence, I am filing this bug.


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=deepdiff



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008751: pytest-mpi: autopkgtest regression: versioned test depends only in experimental

[Andrey Rahmatullin]

On Fri, Apr 01, 2022 at 05:42:36PM +0200, Drew Parsons wrote:
> Source: pytest-mpi
> Followup-For: Bug #1008751
> X-Debbugs-Cc: Andrey Rahmatullin 
> 
> Hi Andrey,
> 
> I had pytest-mpi 0.6 quietly waiting in experimental for sybil 3 to be
> uploaded.
> 
> I saw that pytest-mpi finally got built (sybil 3 got uploaded), so
> I got enthusiastic and immediately uploaded pytest-mpi to unstable.
> 
> But I didn't think to check first what exactly had enabled pytest-mpi
> 0.6 to build in experimental. I assumed it was updates in unstable,
> but in fact it was python-sybil 3.0.1 from experimental.
> 
> At this point python3-sybil has no other reverse dependencies.
It has 6 reverse build-dependencies, most of which don't support
3.x, at least in sid but maybe at all. They need to be updated or patched
first.

> Therefore in order to work around my premature upload of pytest-mpi
> 0.6, could we now upload python-sybil 3.0.1 to unstable? It should be
> safe to do so since other packages are not using sybil yet.
No, sorry, due to the above.
Can you make pytest-mpi support both APIs? It's usually a simple
try+except ImportError.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#903144: iproute2: ip-link(8) manual page does not explain options for ipvlan

[Diederik de Haas]

On Friday, 1 April 2022 18:20:52 CEST Diederik de Haas wrote:
> Is this issue still present in current versions?
> 
> If so, can you report this issue upstream? I guess the easiest way is
> reporting it on https://github.com/shemminger/iproute2/issues
> 
> Alternatively, I guess it can also be send to net...@vger.kernel.org
> although that seem primarily/only for patch submissions?

I was wrong, don't use github to submit issues, one of which contained:
"Iproute2 does not use github for development, please forward all issues to 
net...@vger.kernel.org"

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

Bug#889720: xauth crashes when directory name matches host name

[Larry Doolittle]

My testing confirms this bug still applies to xauth-1:1.1-1 in Bullseye,
as the status graphic indicates.

Fixed upstream in xauth-1.1.1.  I hope that version can be
packaged in time for Bookworm -- it includes a number of
subtle but important improvements.

Looking at the upstream repo at
  https://gitlab.freedesktop.org/alanc/xauth
the fix for this particular issue was applied in commit c2811c95
by Alex Gendin on Sep 26, 2020.

Triggering the bug was also made less likely with commit 18a3c3a7
by Dr. Tilmann Bubeck on Aug 20, 2020, but that change seems
incomplete in my testing.  I attach a two-line patch that
gives correct output when a file or directory in $PWD happens
to have the same name as $(hostname).

Example, starting with the buggy Debian Bullseye xauth-1.1:

guest@redacted:~/empty$ ls
guest@redacted:~/empty$ ls -l ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory
guest@redacted:~/empty$ xauth list $(hostname -f):0
redacted.localdomain:0  MIT-MAGIC-COOKIE-1  d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ touch $(hostname)
guest@redacted:~/empty$ xauth list $(hostname -f):0
Segmentation fault
guest@redacted:~/empty$ ls -li ~/.Xauthority-*
57941079 -rw--- 2 guest guest 0 Mar 31 13:09 /home/guest/.Xauthority-c
57941079 -rw--- 2 guest guest 0 Mar 31 13:09 /home/guest/.Xauthority-l
guest@redacted:~/empty$ 

Then xauth-1.1.1:

guest@redacted:~/empty$ ls
guest@redacted:~/empty$ ls -l ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory
guest@redacted:~/empty$ xauth-1.1.1 list $(hostname -f):0
redacted.localdomain:0  MIT-MAGIC-COOKIE-1  d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ touch $(hostname)
guest@redacted:~/empty$ xauth-1.1.1 list $(hostname -f):0
xauth-1.1.1: (argv):1:  bad display name "redacted.localdomain:0" in "list" 
command
guest@redacted:~/empty$ ls -li ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory

And finally my patched xauth-1.1.1:

guest@redacted:~/empty$ ls
guest@redacted:~/empty$ ls -l ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory
guest@redacted:~/empty$ xauth-fixed list $(hostname -f):0
redacted.localdomain:0  MIT-MAGIC-COOKIE-1  d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ touch $(hostname)
guest@redacted:~/empty$ xauth-fixed list $(hostname -f):0
redacted.localdomain:0  MIT-MAGIC-COOKIE-1  d41d8cd98f00b204e9800998ecf8427e
guest@redacted:~/empty$ ls -li ~/.Xauthority-*
ls: cannot access '/home/guest/.Xauthority-*': No such file or directory

  - Larry
--- xauth-1.1.1/parsedpy.c	2021-11-28 15:33:47.0 -0800
+++ xauth-1.1.1-lrd/parsedpy.c	2022-03-31 12:20:38.700070442 -0700
@@ -175,14 +175,14 @@
 strncpy(path, displayname, sizeof(path) - 1);
 path[sizeof(path) - 1] = '\0';
 #endif
-if (0 == stat(path, &sbuf)) {
+if (0 == stat(path, &sbuf) && S_ISSOCK(sbuf.st_mode)) {
 family = FamilyLocal;
 } else {
 char *dot = strrchr(path, '.');
 if (dot) {
 *dot = '\0';
 /* screen = atoi(dot + 1); */
-if (0 == stat(path, &sbuf)) {
+if (0 == stat(path, &sbuf) && S_ISSOCK(sbuf.st_mode)) {
 family = FamilyLocal;
 }
 }

Bug#903144: iproute2: ip-link(8) manual page does not explain options for ipvlan

[Diederik de Haas]

Control: tag -1 upstream

On Sat, 7 Jul 2018 07:52:40 +0900 Ryutaroh Matsumoto 
 wrote:
> Package: iproute2
> Version: 4.17.0-2
> Severity: minor
> 
> When we add ipvlan to a physical interface, like
> 
> /sbin/ip link add link wls3 name ipvlan1 type ipvlan mode l2 bridge
> 
> we can also add options like "l2", "bridge", etc.
> Those options are not explained in ip-link(8) manual page.
> They are explained at
> https://www.kernel.org/doc/Documentation/networking/ipvlan.txt

Is this issue still present in current versions?

If so, can you report this issue upstream? I guess the easiest way is 
reporting it on https://github.com/shemminger/iproute2/issues

Alternatively, I guess it can also be send to net...@vger.kernel.org although 
that seem primarily/only for patch submissions?

Cheers,
  Diederik

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

Bug#1008751: pytest-mpi: autopkgtest regression: versioned test depends only in experimental

[Drew Parsons]

Source: pytest-mpi
Followup-For: Bug #1008751
X-Debbugs-Cc: Andrey Rahmatullin 

On 2022-04-01 17:42, Drew Parsons wrote:


At this point python3-sybil has no other reverse dependencies.
Therefore in order to work around my premature upload of pytest-mpi
0.6, could we now upload python-sybil 3.0.1 to unstable? It should be
safe to do so since other packages are not using sybil yet.



Ah, we should also consider reverse Build-Dependencies.

From 
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources:


flufl.lock
pytest-mpi
python-parsel
python-public
python-scrapy
python-testfixtures


Do you anticipate if these other packages might have any problem working 
with python3-sybil 3.0.1 ?


Drew

Bug#1008785: ITP: fonts-creep -- Pretty sweet 4px wide pixel font

[Agathe Porte]

Hi Roland,

01/04/2022 17:18, Roland Clobus :

The website for creep says:

This repository is no longer being actively maintained (at least not 
extensively). Have a look at some more up to date alternatives:

* raymond-w-ko/creep2
* slavfox/Cozette
* fcambus/spleen
* pico


It looks like the original author of creep has abandoned this font in 
favour of one of these four alternatives. Could you consider a new 
attempt for creep2 or one of the other alternatives?


I already packaged fonts-creep first, then fonts-creep2, but I do not 
know how to resolve #1006953 . Since 
this font is considered as "done" by its author, I think it should still 
be uploaded to Debian but obviously bugs related to upstream will be 
marked wontfix.


At least, this font works on my system, while fonts-creep2 does not.

Bests,

Agata

Bug#1008787: NGINX FTBFS: Lua dependencies missing

[Thomas Ward]

source: nginx
found: 1.18.0-8
severity: serious

The builds for mips64el and s390x are failing to build and thus failing 
to allow 1.18.0-8 to migrate.

Both error with luajit not found errors.


cc -c -fPIC -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 
-DNDK_SET_VAR -I src/core -I src/event -I src/event/modules -I 
src/os/unix -I src/http/modules/perl -I 
/<>/debian/modules/http-ndk/objs -I objs/addon/ndk -I 
/<>/debian/modules/http-ndk/src -I 
/<>/debian/modules/http-ndk/objs -I objs/addon/ndk -I 
/<>/debian/modules/nchan/src -I 
/<>/debian/modules/http-lua/src/api -I /usr/include/lua5.1 
-I /<>/debian/modules/rtmp -I /usr/include/libxml2 -I objs 
-I src/http -I src/http/modules -I src/http/v2 -I 
/<>/debian/modules/http-ndk/src -I src/mail -I src/stream \

    -o objs/addon/src/ngx_http_lua_log.o \
 /<>/debian/modules/http-lua/src/ngx_http_lua_log.c
In file included from 
/<>/debian/modules/http-lua/src/ngx_http_lua_script.h:11,
 from 
/<>/debian/modules/http-lua/src/ngx_http_lua_script.c:13:
/<>/debian/modules/http-lua/src/ngx_http_lua_common.h:20:10: 
fatal error: luajit.h: No such file or directory

   20 | #include 
  |  ^~
compilation terminated.
make[3]: *** [objs/Makefile:2683: objs/addon/src/ngx_http_lua_script.o] 
Error 1

make[3]: *** Waiting for unfinished jobs
In file included from 
/<>/debian/modules/http-lua/src/ngx_http_lua_log.h:12,
 from 
/<>/debian/modules/http-lua/src/ngx_http_lua_log.c:14:
/<>/debian/modules/http-lua/src/ngx_http_lua_common.h:20:10: 
fatal error: luajit.h: No such file or directory

   20 | #include 
  |  ^~


This needs fixed ASAP or it's going to end up with NGINX removed from 
testing because the 'fixed' versions don't build.  This is why it hasn't 
migrated yet.



Thomas

Bug#1008786: RM: freecontact [armel] -- ROM; Does not build on armel where it is not used anyway

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 1008...@bugs.debian.org

Hi,

please remove freecontact binary from armel from the archive.  It does
not build on this architecture (any more) and there is no point in
trying to fix it here since there are no users of this package on this
arch and upstream has orphaned this package so we can not get any help
from there.

Kind regards
Andreas.

Bug#955816: Improve documentation of bridge option

[Diederik de Haas]

Control: forwarded -1 
https://lore.kernel.org/netdev/20200405134859.57232-1-ro...@debian.org/

On 5 Apr 2020 Bastien ROUCARIES  wrote:
> control: forwarded -1 net...@vger.kernel.org

I updated the forwarded address to point to the actual post.

Through that link I found the following one:
https://lore.kernel.org/netdev/20200420095112.1ea28...@hermes.lan/
saying "Applied all these and fixed some old spelling errors on the man page."

I haven't looked up the commit, but I guess it's likely this issue is fixed?

Cheers,
  Diederik

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

Bug#1008751: pytest-mpi: autopkgtest regression: versioned test depends only in experimental

[Drew Parsons]

Source: pytest-mpi
Followup-For: Bug #1008751
X-Debbugs-Cc: Andrey Rahmatullin 

Hi Andrey,

I had pytest-mpi 0.6 quietly waiting in experimental for sybil 3 to be
uploaded.

I saw that pytest-mpi finally got built (sybil 3 got uploaded), so
I got enthusiastic and immediately uploaded pytest-mpi to unstable.

But I didn't think to check first what exactly had enabled pytest-mpi
0.6 to build in experimental. I assumed it was updates in unstable,
but in fact it was python-sybil 3.0.1 from experimental.

At this point python3-sybil has no other reverse dependencies.
Therefore in order to work around my premature upload of pytest-mpi
0.6, could we now upload python-sybil 3.0.1 to unstable? It should be
safe to do so since other packages are not using sybil yet.

I can make the upload myself if you like as a Debian Python Team
member, but you might prefer to do it yourself.

Let me know!

Drew

Bug#912312: [iproute2] Space before subnets in "ip rule" output

[Diederik de Haas]

On Tue, 30 Oct 2018 20:11:59 + Luca Boccassi  wrote:
> Control: tags -1 pending
> 
> Looks like this is fixed in net-next, so it will be done by 4.20.

If it did, I guess the bug can be closed?

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

Bug#1008785: ITP: fonts-creep -- Pretty sweet 4px wide pixel font

[Roland Clobus]

On 01/04/2022 17:01, Agathe Porte wrote:

Package: wnpp
Severity: wishlist
Owner: Agathe Porte 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-fo...@lists.debian.org, 
deb...@microjoe.org

* Package name: fonts-creep
   Version : 0.31+git20210712.d2a9ad0
   Upstream Author : Romeo Van Snick 
* URL : https://github.com/romeovs/creep

...

I intent to maintain this package under the Debian Fonts Team. This
package is introduced because my previous attempt using a fork
(fonts-creep2) seems to not work correctly, so I am packaging the
original.


The website for creep says:

This repository is no longer being actively maintained (at least not 
extensively). Have a look at some more up to date alternatives:

* raymond-w-ko/creep2
* slavfox/Cozette
* fcambus/spleen
* pico


It looks like the original author of creep has abandoned this font in 
favour of one of these four alternatives. Could you consider a new 
attempt for creep2 or one of the other alternatives?


With kind regards,
Roland Clobus


OpenPGP_signature
Description: OpenPGP digital signature

Bug#953810: /usr/bin/xmag: [xmag] Doesn't show the pixel RGB value any more.

[Geert Uytterhoeven]

I'm having the same problem with xmag in Ubuntu.
In fact this is not limited to xmag.  Xfig (1:3.2.7b-2 in Ubuntu)
suffers from a similar issue: when adding a new color by using
"Lookup and Add", xfig may crash with an X_QueryColors badValue trap.

The problem seems to be related to the type of window you're trying
to query a pixel color of:
  - In "classic" X11 apps (xmag, fig2dev, even the icons in the
GNOME taskbar), xmag and fig2dev can query colors fine,
  - In "modern" composed/anti-aliased apps (gnome-terminal, chromium),
X_QueryColors fails.

I do not know if this is a bug in these applications, or in some
other layer (X libs, X server, compositor, ...).

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Bug#1008785: ITP: fonts-creep -- Pretty sweet 4px wide pixel font

[Agathe Porte]

Package: wnpp
Severity: wishlist
Owner: Agathe Porte 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-fo...@lists.debian.org, 
deb...@microjoe.org

* Package name: fonts-creep
  Version : 0.31+git20210712.d2a9ad0
  Upstream Author : Romeo Van Snick 
* URL : https://github.com/romeovs/creep
* License : MIT
  Programming Lang: N/A
  Description : Pretty sweet 4px wide pixel font

 The 'creep' font is a pretty compact font that is only 4 pixels wide. It is
 great for smaller screens, in order to be able to maintain high text density
 on screens reported as small as 11 inches in diagonal.
 .
 Box drawing
 .
 Creep has most of the basic box drawing characters implemented. Therefore
 creep usually works with most ncurses-type programs or with tmux
 window-splitting for example.
 .
 Powerline
 .
 Creep supports all the symbols needed for Lokaltog's awesome powerline plugin
 for vim.
 .
 Sparklines
 .
 Creep has the necessary symbols for creating sparklines. This is cool for
 tools like rainbarf and others.
 .
 Better Haskell syntax
 .
 This font contains characters that can be used to pretty-print Haskell
 symbols, like '>>='.
 .
 Braille and Drawille
 .
 Creep now supports the full braille alphabet, which was an easy thing to do
 because of the clever braille encoding scheme. All of the braille characters
 are simply generated using a little script.

I intent to maintain this package under the Debian Fonts Team. This
package is introduced because my previous attempt using a fork
(fonts-creep2) seems to not work correctly, so I am packaging the
original.

Bug#1008784: upgrade-system: Please restore cron.daily snippet for non-systemd systems

[Mark Hindley]

Package: upgrade-system
Version: 1.9.0.0
Severity: normal

Dear Maintainer,

The latest version of upgrade-system removed the cron.daily snippet in favour of
systemd timers.

The cron.daily snippet was still used and useful on non-systemd systems. Please
consider restoring it for the benefit of those users.

Thanks

Mark

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

Kernel: Linux 5.16.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages upgrade-system depends on:
ii  apt2.4.3
ii  deborphan  1.7.35

Versions of packages upgrade-system recommends:
ii  debsums  3.0.2

Versions of packages upgrade-system suggests:
pn  unattended-upgrades  

-- Configuration Files:
/etc/upgrade-system.conf changed:
CLEANOPTS="autoclean"


-- no debconf information

Bug#1006544: firewall-cmd times out with large blocklists

[Michael Biebl]

Control: forwarded -1 https://github.com/firewalld/firewalld/issues/933

I forwarded this issue upstream.

Eric, the upstream author, suggested to use ipset for large block lists.
See https://www.epilis.gr/en/blog/2017/04/03/ipset-firewalld/

Regards,
Michael

On Sun, 27 Feb 2022 11:56:09 +0100 Felix Niederwanger 
 wrote:

Package: firewalld
Version: 0.9.3-2

## Observation

I'm noticing that `firewalld-cmd --reload` crashes when it has to deal
with a large drop.xml file, as shown here:

root@debian:/etc/firewalld/zones# time firewall-cmd --
reload   
ERROR:dbus.proxies:Introspect error on

:1.28084:/org/fedoraproject/FirewallD1: dbus.exceptions.DBusException:
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible
causes include: the remote applicat
ion did not send a reply, the message bus security policy blocked the
reply, the reply timeout expired, or the network connection was broken.
Error: Message recipient disconnected from message bus without
replying  
 
real15m2.633s

user0m0.273s
sys 0m0.045s


root@debian:/etc/firewalld/zones# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon   
 Loaded: loaded (/lib/systemd/system/firewalld.service; enabled;

vendor preset: enabled)
 Active: failed (Result: signal) since Sun 2022-02-27 10:46:57 CET;
27min
ago
  
   Docs: man:firewalld(1)

Process: 33724 ExecStart=/usr/sbin/firewalld --nofork --nopid
(code=killed, signal=KILL)  
   Main PID: 33724 (code=killed, signal=KILL)

CPU: 15min
20.336s
   
  


Feb 27 10:31:34 debian systemd[1]: Starting firewalld - dynamic
firewall daemon...
Feb 27 10:31:35 debian systemd[1]: Started firewalld - dynamic firewall
daemon.
 
Feb 27 10:46:57 debian systemd[1]: firewalld.service: Main process

exited, code=killed, status=9/KILL
Feb 27 10:46:57 debian systemd[1]: firewalld.service: Failed with
result 'signal'.
Feb 27 10:46:57 debian systemd[1]: firewalld.service: Consumed 15min
20.336s CPU time.


## Reproducer

Find attached to this email my drop.xml list. I tested this bug in a
fresh VM running Debian 10 with all installed updates.

* Put attached drop.xml into /etc/firewalld/zones/drop.xml


OpenPGP_signature
Description: OpenPGP digital signature

Bug#966178: ITP: rkdeveloptool -- tools for working with Rockchip ARM processors through the rockusb protocol

[Christopher Obbard]

Hi Dylan,

I have packaged rkdeveloptool (originally a really long time ago - 
finally found some time to refresh things today!) and the source is 
available here: https://salsa.debian.org/obbardc/rkdeveloptool


Can I request a review and potentially an upload if all is good ?

I guess this time it would be best to move it to the debian salsa 
namespace first - I do not have access there (yet?).



Thanks and all the best,
Chris

Bug#1008778: pcscd: Conflict between Yubikey and Firefox around pcscd

[Ludovic Rousseau]

Le 01/04/2022 à 14:25, Yadd a écrit :

Hi,


Hello,



problem description:
  * Env:
* I'm using a Yubikey to store my GPG key
* I'm using a certificate to access to tracker.debian.org
* I'm running a Debian testing without local changes
  * User-Story:
* when I alternately access TDO and use my YB, the pcscd process
  hangs, consumes a lot of CPU and blocks Firefox. As soon as I kill
  the pcscd process, Firefox starts working again


Maybe you have a conflict between GnuPG and pcscd.
See https://ludovicrousseau.blogspot.com/2019/06/gnupg-and-pcsc-conflicts.html

Tell me if that fixed your issue.

Bye

--
Dr. Ludovic Rousseau

Bug#1008770: gvfsd-http: segfault in libsoup-3.0-0 on_frame_recv_callback()

[Christoph Anton Mitterer]

On Fri, 2022-04-01 at 10:22 +0100, Simon McVittie wrote:
> Fixed in 3.0.6-1 (confirmed with a local build).

Thanks for taking care :-)

Bug#1008783: [sid] virtualenvs placing bin/ and other directories inside local/

[Alex Gaynor]

Package: python3

Starting with the recent upgrade to Python3.10 on sid it appears that
virtualenvs created with virtualenv from PyPI (pip install virtualenv)
do not have bin/ directories inside the virtualenv, instead they have
local/ directories which contain bin/.

This causes tools such as tox to break. Example failing CI run:
https://github.com/pyca/cryptography/runs/5781159972?check_suite_focus=true

This does _not_ seem to impact the virtualenv packaged by debian.

-- 
All that is necessary for evil to succeed is for good people to do nothing.

Bug#1008782: gnome-core: Install gnome-text-editor by default

[Jeremy Bicha]

Package: gnome-core
Version: 1:42+1
X-Debbugs-CC: debian-gtk-gn...@lists.debian.org

I propose 2 changes to the gnome-core metapackage:

1. Install gnome-text-editor by default but allow gedit as an alternate for now.
https://salsa.debian.org/gnome-team/meta-gnome3/-/merge_requests/6

- GNOME 42 has gnome-text-editor as the only text editor in their core set.
- Fedora 36 has switched their default from gnome-text-editor to gedit too.
- Maybe after the Bookworm release, we'd drop the alternate too.

2. Allow gnome-console as an alternative to gnome-terminal but keep
gnome-terminal as the default terminal for now.

- We still have some integration work to do for GNOME Console to be a
reasonable drop-in replacement on Debian.
+ It should be an x-terminal-emulator alternative
https://gitlab.gnome.org/GNOME/console/-/issues/26
+ New tabs should open with the same working directory as the current
tab. Works on Fedora; needs something else to work on Debian.

- GNOME 42 did switch their core set to have gnome-console as the only
terminal in the core set, but glib hasn't been updated to fully
support that. (We will be updating our glib soon to distro patch
that.)

- Fedora 36 kept GNOME Terminal as default. I think their hesitation
would mostly be resolved once Console adds a preferences dialog with
popular customizations. So there's a chance that Console would be more
"competitive" for GNOME 43 so this is something to be thinking about
for a late default switch for Bookworm.

https://pagure.io/fedora-workstation/issue/261


Final note: our metapackages should probably be redone to more closely
match GNOME's upstream metapackages. I suggest this be worked on at
DebConf in a few months.

Thank you,
Jeremy Bicha

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

[Vashta Nerada]

Hi Marcel,

Can you verify that you are not using as a file descriptor the address of the 
struct "compress_params"?

diff --git a/lib/dpkg/compress.c b/lib/dpkg/compress.c
index 43d4fd063..c92324935 100644
--- a/lib/dpkg/compress.c
+++ b/lib/dpkg/compress.c
@@ -930,7 +930,7 @@ static const struct compressor compressor_lzma = {
 #ifdef WITH_LIBZSTD

 static void
-decompress_zstd(int fd_in, int fd_out, const char *desc)
+decompress_zstd(struct compress_params *params, int fd_in, int fd_out, const 
char *desc)
 {
size_t const buf_in_size = ZSTD_DStreamInSize();
void*  const buf_in = m_malloc(buf_in_size);

Regards
Alejandro.

On Fri, 18 Feb 2022 16:20:12 +0100 Marcel Partap  wrote:
> […]
> Follow-up: forgot to set up linking with zstd lib in Makefile.am, thanks to 
> Bernardo Bandos for picking that one up. Commits on my zstd-rebased branch.
> The tests keep failing at `dpkg-deb -c pkg-data-zst.deb`, which fails with
> > dpkg-deb (subprocess): ZSTD_decompressStream error : Unknown frame 
> > descriptor
>
> My efforts poking at it with gdb have been fruitless. The file can be 
> unpacked just fine with `ar` and the data.tar.zst is valid and can be 
> uncompressed, too.
>
> Any ideas?
>
> > https://salsa.debian.org/mpartap-guest/dpkg/-/tree/zstd-rebased
> >
> > Best Regards
> > Marcel 😅
>
>
>

Bug#1008752: avifile: autopkgtest regression on armhf: Bus error

[Ying-Chun Liu (PaulLiu)]

Hi Paul,


I need some help. Actually I know this bug for a while but I just cannot 
fix it. I've tried to reproduce the bug on qemu-user-static armhf chroot 
envorionment and PorterBox (abel.debian.org), on both platform the 
autopkgtest just passed without problem.


I think the bug should be easy to locate if I can run gdb and see the 
backtrace when the bus error happened.
But I just cannot reproduce this bug on my side or on porter box. If 
possible I hope to get some core dump when bus error happened on the 
machine that runs the test.


Yours,
Paul




Paul Gevers 於 2022/4/1 03:31 寫道:

Source: avifile
Version: 1:0.7.48~20090503.ds-23
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of avifile the autopkgtest of avifile fails in 
testing on armhf when that autopkgtest is run with the binary packages 
of avifile from unstable. It passes when run with only packages from 
testing. In tabular form:


   pass    fail
avifile    from testing    1:0.7.48~20090503.ds-23
all others from testing    from testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. 
Can you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be 
found on

https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=avifile

https://ci.debian.net/data/autopkgtest/testing/armhf/a/avifile/20131436/log.gz 



Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.312851570
Setting pipeline to NULL ...
Freeing pipeline ...
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.217510393
Setting pipeline to NULL ...
Freeing pipeline ...
g++ -Wall -g -o test1 test1.cc \
-laviplay -I/usr/include/avifile-0.7 \
-laubio  \
-lm
 : Avifile RELEASE-0.7.48-220318-20:07-../src/configure
 : Available CPU flags: fp asimd evtstrm aes pmull sha1 sha2 
crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs

This binary was compiled for Avifile ver. 1840, the library is ver. 1840
 : Checking: ./test_raw.avi
 : MainHeader: MicroSecPerFrame=4 MaxBytesPerSec=6112800
 PaddingGranularity=0 Flags=[ HAS_INDEX IS_INTERLEAVED ] TotalFrames=250
 InitialFrames=0 Streams=2 SuggestedBufferSize=0 WxH=320x240
 Scale=0 Rate=0 Start=0 Length=0
 : StreamHeader: Type=vids Handler=DIVX Flags=[ ]
 InitialFrames=0 Scale=1 Rate=25 Start=0 Length=250
 SuggestedBufferSize=12413 Quality=0 SampleSize=0 Rect l,r,t,b=0,0,0,0
 : StreamHeader: Type=auds Handler=0x1 Flags=[ ]
 InitialFrames=0 Scale=1 Rate=44100 Start=0 Length=450559
 SuggestedBufferSize=8192 Quality=0 SampleSize=8 Rect l,r,t,b=0,0,0,0
 : Reading index from offset: 5581514
 : Stream 0 vids : DIVX (0x4944) 250 chunks (0.98KB)
 : WARNING: stream header has incorrect dwLength (450559 
-> 450560)

 : Stream 1 auds : Microsoft PCM (0x1) 440 chunks (3.44KB)
 : Initialized video stream (chunk tblsz: 250, fmtsz: 40)
 : Found 7 plugins 
(/usr/lib/arm-linux-gnueabihf/avifile-0.7,A:28,V:36)

 : creating dir: /home/debci/.avm
 : looking for mpeg4  1482049860
 : Created video decoder: FF OpenDivX
 : Initialized audio stream (chunk tblsz: 450560, fmtsz: 18)
 : PCM audio decoder created
bh.biHeight = -240, bh.biWidth = 320
bh.biHeight < 0, correct the value to 240
Movie size: 320 x 240  [YV12]
audio format: 1, Channels: 2, Samples/sec: 44100, Bits/Sample: 32, 
Bytes/sec: 352800

Video Length: 250
Video Pos: 0
Audio Length: 450560
Audio Pos: 0
Decoder YUV capabilities: 0x8080
CAPS is CAP_YV12
TIME 0 0
[mpeg4 @ 0x1ad7e40] Requested frame threading with a custom 
get_buffer2() implementation which is not marked as thread safe. This 
is not supported anymore, make your callback thread-safe.

 : using DR1
Audio read 192 samples, 1536 bytes.
Audio frequency 469.27 hz
Audio read 192 samples, 1536 bytes.
Audio frequency 469.188 hz
Audio read 192 samples, 1536 bytes.
Audio frequency 469.095 hz
Audio read 192 samples, 1536 bytes.
Audio frequency 469.086 hz
Audio read 192 samples, 1536 bytes.
Audio frequency 469.17 hz
Audio read 192 samples, 1536 bytes.
Audio frequency 469.262 hz
Audio read 192 samples, 1536 bytes.
Audio frequency 469.267 hz
Audio read 192 samples, 1536 bytes.
Audio frequency 469.18 hz
Audio read 192 samples, 1536 bytes.
Audio frequency 469.091 hz
Audio read 192 samples, 1536 bytes.
Audio frequency 469.09 hz
TIME 0.04 1
Bus error
autopkgtest [10:24:27]: test decoding-test-mp4-raw



OpenPGP_signature
Description: 

Bug#1008781: nemiver: Intent to remove from Debian

[Jeremy Bicha]

Source: nemiver
Severity: serious
Version: 0.9.6-1.2

I intend to file a removal bug for nemiver soon. It has failed to
build for more than a year. It wasn't autoremoved sooner because it
was included in one of the metapackages in meta-gnome3.

GNOME Builder is the maintained recommended replacement.

Nemiver has been archived upstream, which means that bugfixes,
translations, and even bug reports are no longer accepted:
https://gitlab.gnome.org/Archive/nemiver

Thank you,
Jeremy Bicha

Bug#1008716: lpq / lpr (bis)

[alain]

installation of  some packages :

lpr:

  Installé : 1:2008.05.17.3+nmu1
  Candidat : 1:2008.05.17.3+nmu1
 Table de version :
 *** 1:2008.05.17.3+nmu1 500
        100 http://deb.debian.org/debian testing/main amd64 Packages
        500 http://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
tldr:
  Installé : 0.6.4-1+b5
  Candidat : 0.6.4-1+b5
 Table de version :
 *** 0.6.4-1+b5 500
        100 http://deb.debian.org/debian testing/main amd64 Packages
        500 http://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
N: Impossible de trouver le paquet lpnrg


use :

alain@sid:~$ lpq
lpq: lp: unknown printer

alain@sid:~$ tldr lp
No tldr entry for lp

Bug#1008780: dpkg: protection shouldn't apply to foreign-arch packages

[Stephen Kitt]

Package: dpkg
Version: 1.20.9
Severity: normal

Dear Maintainer,

Protection is applied to foreign-arch packages (e.g. libgcc-s1:i386 on
amd64) even though they aren't relevant to the scenarios that
protection is designed to prevent (as I understand it):

> Protected packages contain mostly important system boot
> infrastructure. Removing them might cause the whole system to be
> unable to boot, so use with caution.

Would it be possible for removal of such packages not to require
--force-remove-protected, at least if the corresponding native arch
package is installed? The latter check isn't useful with libraries
(where, if nothing depends on them, we can be certain that they are
not needed for the system to boot), but would catch situations where
e.g. the system's init is not the native package. (I imagine there's a
better approach to this.)

Regards,

Stephen


-- Package-specific info:

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable'), (100, 'unstable-debug'), (100, 
'testing-debug'), (100, 'unstable'), (100, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13+deb11u3
ii  liblzma5 5.2.5-2
ii  libselinux1  3.1-3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.2.4
ii  debsig-verify  0.23+b2

-- no debconf information

Bug#1008779: ITS: postgrey

[Jordi Mallach]

Source: postgrey
Version: 1.36-5.2
Severity: important
X-Debbugs-Cc: anto...@debian.org

Hi Antonio,

postgrey's last maintainer upload was 4.5 years ago and there have been
a couple NMUs since then, in 2019 and 2021.

I am potentially going to replace greylistd with postgrey at work, so I
had a look at the state of the package, and decided it needed some work
to be suitable for me and for Debian.

Some time ago I spent some hours bringing the packaging up to date:

 - I recovered the last state of the alioth git repo and imported it in
   salsa.debian.org
 - Imported the latest upstream version and adapted existing patchset
 - Removed obsolete bits from the packaging
 - Brought up packaging to current standards, according to Lintian
 - Refreshed the whitelist from upstream git master

The result of this effort can be seen here:
https://salsa.debian.org/jordi/postgrey/-/commits/main

My idea is to move this project under the debian namespace.

I contacted you some time ago via email and IRC, but never got anything
back, so I'm starting the process to salvage the package.

I'd personally prefer to be a comaintaner of the package and have you
around so we share the load, but if you aren't interested in this
package anymore I guess I just take over entirely.

I'll upload the above package to DELAYED/7 in three weeks.

Thank you!
Jordi

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

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

Bug#1008716: lpq / lpr

[alain]

alain@sid:~$ lpq
bash: lpq : commande introuvable

alain@sid:~$ man lpr
Aucune entrée de manuel pour lpr

alain@sid:~$ tldr lp
bash: tldr : commande introuvable

alain@sid:~$ echo "test" | lp
lp: Error - No default destination.

alain@sid:~$ tldr lpr
bash: tldr : commande introuvable

alain@sid:~$ lpq -l
bash: lpq : commande introuvable

alain@sid:~$ lpstat

alain@sid:~$ lpq -abash: lpq : commande introuvable

alain@sid:~$ /usr/bin/lpq
bash: /usr/bin/lpq: Aucun fichier ou dossier de ce type

alain@sid:~$ apt policy lpq
N: Impossible de trouver le paquet lpq

Bug#1008778: pcscd: Conflict between Yubikey and Firefox around pcscd

[Yadd]

Package: pcscd
Version: 1.9.5-3
Severity: important

Hi,

problem description:
 * Env:
   * I'm using a Yubikey to store my GPG key
   * I'm using a certificate to access to tracker.debian.org
   * I'm running a Debian testing without local changes
 * User-Story:
   * when I alternately access TDO and use my YB, the pcscd process
 hangs, consumes a lot of CPU and blocks Firefox. As soon as I kill
 the pcscd process, Firefox starts working again

heers,
Yadd

Bug#1008716: printer

[alain]

my printer no longer works since dpkg update (2 - 3 days ago . it began 
with the 1.21.4 version)



/usr/sbin/lpinfo --make-and-model "hp envy 553" -m
drv:///hpijs.drv/hp-envy_5530_series-hpijs.ppd HP Envy 5530 Series 
hpijs, 3.21.12
hplip-data:0/ppd/hplip/HP/hp-envy_5530_series.ppd HP Envy 5530 Series, 
hpcups 3.21.12
hplip-data:1/ppd/hplip/HP/hp-envy_5530_series.ppd HP Envy 5530 Series, 
hpcups 3.21.12
hplip-data:2/ppd/hplip/HP/hp-envy_5530_series.ppd HP Envy 5530 Series, 
hpcups 3.21.12
hplip-data:3/ppd/hplip/HP/hp-envy_5530_series.ppd HP Envy 5530 Series, 
hpcups 3.21.12
hplip-data:4/ppd/hplip/HP/hp-envy_5530_series.ppd HP Envy 5530 Series, 
hpcups 3.21.12
hplip-data:5/ppd/hplip/HP/hp-envy_5530_series.ppd HP Envy 5530 Series, 
hpcups 3.21.12
hplip-data:6/ppd/hplip/HP/hp-envy_5530_series.ppd HP Envy 5530 Series, 
hpcups 3.21.12
hplip-data:7/ppd/hplip/HP/hp-envy_5530_series.ppd HP Envy 5530 Series, 
hpcups 3.21.12
drv:///hpcups.drv/hp-envy_5530_series.ppd HP Envy 5530 Series, hpcups 
3.21.12

everywhere IPP Everywhere

all of this  is ok . my envy 5536 is  well recognised .

but not in system-config-printer .

i can post photos , if you want ...

the last upgrades :

alain@sid:~$ tail -n 250 /var/log/apt/history.log | grep -iE 
"xauth|cups|dpkg"

Upgrade: cups-browsed:amd64 (1.28.12-1+b1, 1.28.13-1)
Upgrade: cups-filters-core-drivers:amd64 (1.28.12-1+b1, 1.28.13-1)
Upgrade: dpkg-dev:amd64 (1.21.6, 1.21.7), libdpkg-perl:amd64 (1.21.6, 
1.21.7)

Upgrade: dpkg:amd64 (1.21.6, 1.21.7)
Upgrade: cups-filters:amd64 (1.28.12-1+b1, 1.28.13-1)
Upgrade: libcupsfilters1:amd64 (1.28.12-1+b1, 1.28.13-1)
Upgrade: libwacom9:amd64 (2.1.0-2, 2.2.0-1), wine-development:amd64 
(6.17~repack-1, 6.18~repack-1), libwacom-common:amd64 (2.1.0-2, 
2.2.0-1), libxft2:amd64 (2.3.2-2, 2.3.4-1), xauth:amd64 (1:1.1-1, 
1:1.1.1-1), xwayland:amd64 (2:22.1.0-1, 2:22.1.1-1), libxft-dev:amd64 
(2.3.2-2, 2.3.4-1), wine64-development:amd64 (6.17~repack-1, 
6.18~repack-1), wine32-development:i386 (6.17~repack-1, 6.18~repack-1), 
libwine-development:amd64 (6.17~repack-1, 6.18~repack-1), 
libwine-development:i386 (6.17~repack-1, 6.18~repack-1), 
libwacom-bin:amd64 (2.1.0-2, 2.2.0-1), libwacom-dev:amd64 (2.1.0-2, 2.2.0-1)



i understand nothing , could you help me ?


printer plugged (220 Volts and usb ) and on  :

trying to add a printer in system-config-printer

https://i.imgur.com/hbMAMCX.jpg


works perfectly on stable bullseye

do i have to reinstall all the system ?

Bug#1008777: ITP: cobra-cli -- Cobra CLI tool to generate Go applications and commands

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: cobra-cli
  Version : 1.3.0-1
  Upstream Author : Steve Francia
* URL : https://github.com/spf13/cobra-cli
* License : Apache-2.0
  Programming Lang: Go
  Description : Cobra CLI tool to generate Go applications and commands

 Cobra provides its own program that will create your Go application and
 add any commands you want. It's the easiest way to incorporate Cobra into
 your application.


Reason for packaging:
 "cobra" has been dropped from golang-github-spf13-cobra upstream
 since 1.4.0, and has been moved to https://github.com/spf13/cobra-cli
 and renamed as "cobra-cli"

Bug#970687: quodlibet: Confirmed for 4.5.0-1 as well

[Tobias Klausmann]

Package: quodlibet
Version: 4.5.0-1
Followup-For: Bug #970687

Dear Maintainer,

As per subject. Moving /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0 to
where the linker can't see it fixes QL (it does elicit an error message,
but nothing breaks). I have no idea if anything else on my system is
broken by this, but so far everything seems okay. Naturally, this is not
a permanent solution (despite being the only recourse I've had for well
over a year now).

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

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

Versions of packages quodlibet depends on:
ii  exfalso  4.5.0-1
ii  gir1.2-gst-plugins-base-1.0  1.20.1-1
ii  gir1.2-gstreamer-1.0 1.20.1-1
ii  gir1.2-keybinder-3.0 0.3.2-1.1
ii  gstreamer1.0-alsa1.20.1-1
ii  gstreamer1.0-plugins-base1.20.1-1
ii  gstreamer1.0-plugins-good1.20.1-1
ii  gstreamer1.0-plugins-ugly1.20.1-1
ii  python3  3.9.8-1

Versions of packages quodlibet recommends:
ii  gir1.2-gtksource-3.0  3.24.11-2+b1
ii  gir1.2-webkit2-4.02.34.6-1
ii  lxqt-notificationd [notification-daemon]  0.16.0-1
ii  notification-daemon   3.20.0-4+b1
ii  python3-dbus  1.2.18-3+b1
ii  python3-pyinotify 0.9.6-1.3

Versions of packages quodlibet suggests:
ii  gstreamer1.0-plugins-bad  1.20.1-1

-- no debconf information

Bug#1008772: xrdp: Please integrate NMUs and gitlab MR

[Dominik George]

Hi,

> I have just uploaded an NMU prepared by a Kali contributor (in the NM
> queue). Please find the relevant "git am" patches attached. (The two
> patches by Arnaud are also in https://salsa.debian.org/arnaudr/xrdp)
> 
> It fixes CVE-2022-23613 and nothing else.

Thanks a lot!

> I noticed that you have open MR on Gitlab that it would be good to handle.
> There's a former NMU that was never acked and that doesn't appear in
> debian/changelog.
> 
> https://salsa.debian.org/debian-remote-team/xrdp/-/merge_requests

Yep, I am clearly behind on my maintenance work…

I am resolving all of that with the next upload based on the current
upstream version 0.9.19.

-nik


signature.asc
Description: PGP signature

Bug#1008775: [Pkg-javascript-devel] Bug#1008775: node-expat: Odd autopkgtest failure, prevents migration of nodejs

[Jérémy Lal]

On Fri, Apr 1, 2022 at 10:42 AM Jérémy Lal  wrote:

> Source: node-expat
> Version: 2.4.0+ds-1
> Severity: normal
>
> Hi,
>
> while your package's autopkgtests pass, there is an odd failure:
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-expat/20479881/log.gz
>
> sadly, that will prevent migration of nodejs.
> Could you help determine the source of the error ?


A local rebuild + autopkgtest (using sbuild) gives the same test output,
but not the error at the end.
Could it be something about the test environment?

Bug#1008776: intel-media-va-driver: Segmentation fault with gstreamer based applications

[Kai Weber]

Package: intel-media-va-driver
Version: 22.3.0+dfsg1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: kai.weber+deb...@glorybox.de

Dear Maintainer,

since a recent update (can not excalty determine the date) gstreamer based 
applications like totem or gst-play-1.0 itself segfault on video files.

Removing intel-media-va-driver resolves the issue.
Installing intel-media-va-driver-non-free resolves the issue.

Attached is a backtrace. I have no experience getting backtraces. This one was 
achieved after install the intel-media-va-driver-dbgsym package and running

$ export DEBUGINFOD_URLS="https://debuginfod.debian.net";
$ gdb --args gst-play-1.0 /home/kai/Downloads/pony.mp4 --videosink=glimagesink
Thread 14 "qtdemux0:sink" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb77fe640 (LWP 22147)]
0x7fffb5f906be in KernelDll_AllocateStates (pKernelBin=, 
uKernelSize=0, pFcPatchCache=0x0, 
uFcPatchCacheSize=, pDefaultRules=0x0, 
ModifyFunctionPointers=0x0)
at ./media_driver/agnostic/common/vp/kdll/hal_kerneldll.c:2791
Download failed: Invalid argument.  Continuing without source file 
./obj-x86_64-linux-gnu/media_driver/./media_driver/agnostic/common/vp/kdll/hal_kerneldll.c.
2791./media_driver/agnostic/common/vp/kdll/hal_kerneldll.c: No such file or 
directory.
(gdb) set logging file backtrace.log
(gdb) set logging on
Copying output to backtrace.log.
(gdb) bt
...
(gdb) set logging off
Done logging to backtrace.log.
(gdb) quit

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

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

Versions of packages intel-media-va-driver depends on:
ii  libc6   2.33-7
ii  libgcc-s1   12-20220319-1
ii  libigdgmm12 22.1.2+ds1-1
ii  libstdc++6  12-20220319-1
ii  libva2 [libva-driver-abi-1.14]  2.14.0-1

intel-media-va-driver recommends no packages.

intel-media-va-driver suggests no packages.

-- no debconf information
#0  0x7fffb5f906be in KernelDll_AllocateStates (pKernelBin=, 
uKernelSize=0, pFcPatchCache=0x0, 
uFcPatchCacheSize=, pDefaultRules=0x0, 
ModifyFunctionPointers=0x0)
at ./media_driver/agnostic/common/vp/kdll/hal_kerneldll.c:2791
#1  0x7fffb5f82028 in VphalRenderer::Initialize (this=0x7fffa813d480, 
pSettings=0x7fffb77fae80, isApoEnabled=)
at ./media_driver/agnostic/common/vp/hal/vphal_renderer.cpp:1418
#2  0x7fffb5f67a89 in VphalState::Allocate (this=0x7fffa8123e50, 
pVpHalSettings=0x7fffb77fae80)
at ./media_driver/agnostic/common/vp/hal/vphal.cpp:201
#3  0x7fffb61848a2 in DdiVp_InitVpHal (pVpCtx=0x7fffa812add0) at 
./media_driver/linux/common/vp/ddi/media_libva_vp.c:1811
#4  0x7fffb6189460 in DdiVp_InitCtx (pVaDrvCtx=, 
pVpCtx=0x7fffa812add0)
at ./media_driver/linux/common/vp/ddi/media_libva_vp.c:1671
#5  0x7fffb618985e in DdiVp_CreateContext 
(pVaDrvCtx=pVaDrvCtx@entry=0x7fffa8081e20, vaConfigID=vaConfigID@entry=0, 
iWidth=iWidth@entry=0, iHeight=iHeight@entry=0, iFlag=iFlag@entry=0, 
vaSurfIDs=vaSurfIDs@entry=0x0, iNumSurfs=0, 
pVaCtxID=0x7fffb77fb1ac) at 
./media_driver/linux/common/vp/ddi/media_libva_vp.c:3291
#6  0x7fffb6147be2 in DdiMedia_PutImage (ctx=0x7fffa8081e20, surface=0, 
image=, src_x=0, src_y=0, src_width=64, 
src_height=64, dest_x=0, dest_y=0, dest_width=64, dest_height=64) at 
./media_driver/linux/common/ddi/media_libva.cpp:5535
#7  0x7fffd425521c in vaPutImage () from /lib/x86_64-linux-gnu/libva.so.2
#8  0x7fffd42def8d in ?? () from 
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so
#9  0x7fffd429d686 in ?? () from 
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so
#10 0x7fffd42a480e in ?? () from 
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so
#11 0x777ac5cb in ?? () from /lib/x86_64-linux-gnu/libgstbase-1.0.so.0
#12 0x777b014d in ?? () from /lib/x86_64-linux-gnu/libgstbase-1.0.so.0
#13 0x77b912f0 in gst_pad_query () from 
/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#14 0x77b91a1b in gst_pad_peer_query () from 
/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#15 0x77bd14b8 in gst_pad_peer_query_caps () from 
/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#16 0x777afe28 in ?? () from /lib/x86_64-linux-gnu/libgstbase-1.0.so.0
#17 0x77b912f0 in gst_pad_query () from 
/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#18 0x77b91a1b in gst_pad_peer_query () from 
/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#19 0x77bcb858 in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#20 0x77b8

Bug#986739: is it possible to package new upstream "snapshot" ?

[Aloïs Micard]

Control: noowner 986739
Control: noowner 976530

Hello there,

I'm 100% with you on packaging the beta version on Debian. But sadly I have no 
time for Debian lately due to my new job position.
I shouldn't have own the bug for this long, it's my fault. If anyone want to 
work on this and needs sponsoring I can still do it tho.

Cheers,


On 4/1/22 07:04, Andres Cimmarusti wrote:

Any update about this? I'm afraid that at this rate there won't be any package 
by the time Debian 12 enters freeze.

I've tested building the beta snapshots and they are quite reliable (on 
bullseye). I don't understand what's the problem with packaging them.
This is done all the time in Debian, for example "black" a python code auto 
formatter was in beta for a couple of Debian releases (including buster and Bullseye)
https://packages.debian.org/search?keywords=black&searchon=names&suite=all§ion=all 


I hope we can see the dolphin-emu packages in Debian again.

Best regards,
Andrés


--
⢀⣴⠾⠻⢶⣦⠀  Aloïs Micard
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://creekorful.org
⠈⠳⣄  DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008770: gvfsd-http: segfault in libsoup-3.0-0 on_frame_recv_callback()

[Simon McVittie]

Control: retitle -1 gvfsd-http: segfault in libsoup-3.0-0 
on_frame_recv_callback()
Control: reassign -1 libsoup-3.0-0 3.0.5-1

On Fri, 01 Apr 2022 at 04:14:10 +0200, Christoph Anton Mitterer wrote:
> $ eog "http://joscha.com/data/media/cartoons/030602.png";
> gives a segfault.
> Kernel lg:
> Apr 01 04:10:34 heisenberg kernel: gvfsd-http[143860]: segfault at 28 ip 
> 7f6681a04c54 sp 7ffc4704dfe0 error 4 in 
> libsoup-3.0.so.0.0.5[7f66819e4000+5]
> Apr 01 04:10:34 heisenberg kernel: Code: d2 d9 ff ff 49 8b 04 24 41 83 7c 24 
> 78 06 0f b6 40 28 75 1a 83 e0 04 74 18 4c 89 e7 e8 65 f7 ff ff 0f 1f 44 00 00 
> 49 8b 04 24 <0f> b6 40 28 83 e0 04 31 f6 84 c0 48 89 df 40 0f 94 c6 e8 75 e8 
> ff

I can reproduce this. At first glance, it looks most likely to be a
libsoup bug when contacting HTTP2 servers. Backtrace:

#0  0x7fd04fdd1c54 in on_frame_recv_callback
(session=0x55e647d98430, frame=, user_data=0x55e647f0acb0)
at ../libsoup/http2/soup-client-message-io-http2.c:728
#1  0x7fd04f60ce11 in session_call_on_frame_received (frame=0x55e647d985d0, 
session=0x55e647d98430)
at nghttp2_session.c:3310
#2  nghttp2_session_on_data_received (session=session@entry=0x55e647d98430, 
frame=frame@entry=0x55e647d985d0)
at nghttp2_session.c:4986
#3  0x7fd04f61210b in session_process_data_frame (session=0x55e647d98430) 
at nghttp2_session.c:5005
#4  nghttp2_session_mem_recv (session=0x55e647d98430, in=, 
in@entry=0x7eeb6ce0 "", inlen=120)
at nghttp2_session.c:6629
#5  0x7fd04fdcfb29 in io_read
(io=0x55e647f0acb0, blocking=, cancellable=, 
error=)
at ../libsoup/http2/soup-client-message-io-http2.c:441
#6  0x7fd04fdcfc92 in io_read_ready (stream=, 
io=0x55e647f0acb0)
at ../libsoup/http2/soup-client-message-io-http2.c:465
#7  0x7fd04fe80e94 in g_main_dispatch (context=0x55e647b636b0) at 
../../../glib/gmain.c:3417
#8  g_main_context_dispatch (context=0x55e647b636b0) at 
../../../glib/gmain.c:4135
#9  0x7fd04fe81238 in g_main_context_iterate
(context=0x55e647b636b0, block=block@entry=1, dispatch=dispatch@entry=1, 
self=)
at ../../../glib/gmain.c:4211
#10 0x7fd04fe81523 in g_main_loop_run (loop=0x55e647b51930) at 
../../../glib/gmain.c:4411
#11 0x55e6474105a8 in daemon_main ()
#12 0x55e64740fac8 in main ()

This might be the same thing as
https://gitlab.gnome.org/GNOME/libsoup/-/issues/272 which is fixed upstream
in 3.0.6.

> (eog:143850): Handy-WARNING **: 04:10:34.404: Using 
> GtkSettings:gtk-application-prefer-dark-theme together with HdyStyleManager 
> is unsupported. Please use HdyStyleManager:color-scheme instead.
> 
> (eog:143850): GVFS-WARNING **: 04:10:34.850: The peer-to-peer connection 
> failed: Cache invalid, retry (internally handled). Falling back to the 
> session bus. Your application is probably missing --filesystem=xdg-run/gvfsd 
> privileges.

I don't get these warnings, so they seem to be unrelated to the crash.

smcv

Bug#1008775: node-expat: Odd autopkgtest failure, prevents migration of nodejs

[Jérémy Lal]

Source: node-expat
Version: 2.4.0+ds-1
Severity: normal

Hi,

while your package's autopkgtests pass, there is an odd failure:
https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-expat/20479881/log.gz

sadly, that will prevent migration of nodejs.
Could you help determine the source of the error ?

Jérémy


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

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

Bug#806314: samba: OSMC Client has problems using samba with kernel 3.16, but not with kernel 3.2

[Michael Tokarev]

On Thu, 26 Nov 2015 12:45:43 +0100 Jochen Pawletta  wrote:

Package: samba
Version: 2:4.1.17+dfsg-2
Severity: normal

Hello

I have a little problem with my OSMC Client on my Raspberry Pi.
I watch mkv-files which are shared by samba on my Debian 8 server.
The files are 1280x720 H264, nothing special.

My server is on jessie a longer while now, but due to boot problems
I was still on kernel 3.2 ...
Everything works fine as it should.

Recently the boot problems are solved and I am now on kernel 3.16.
Now I have problems watching the same MKV files on my Raspberry Pi.
Often the picture freezes and it takes a few seconds (1-5) before
the video continues. It looks like the data didn't come quickly
enough for a continuous playback.
Also skipping forward takes a little while, much longer as before.

I tried to switch to the old 3.2 kernel, and that does the trick.
The problems went away without any other changes.

...

With the reference to 
https://archlinuxarm.org/forum/viewtopic.php?f=9&t=7692&start=20 ,
apparently it was some arm-specific issue in the kernel tso implementation
in kernel 3.16.

It looks like this prob has nothing to do with samba after all,
and hopefully it has been fixed in kernel since that time.
Let's close this bug report now.

Thank you!

/mjt

Bug#960420: Needs versioned dependency on slop

[Vincent Bernat]

 ❦ 12 May 2020 14:25 +02, Yuri D'Elia:

> I didn't realize maim depended on slop through a dso (I assumed it
> simply called the binary).
>
> slop was updated to 7.5, which broke maim as a result:
>
> maim: error while loading shared libraries: libslopy.so.7.4: cannot
> open shared object file: No such file or directory

Again with the latest upload.

 10:16 ❱ maim
maim: error while loading shared libraries: libslopy.so.7.5: cannot open shared 
object file: No such file or directory

-- 
Your manuscript is both good and original, but the part that is good is not
original and the part that is original is not good.
-- Samuel Johnson

Bug#1008773: ftpsync: Using commands with parameters as hooks breaks ftpsync on bullseye/debian 11

[Raphael Hertzog]

Control: tags -1 + patch

I have prepared a merge request with a fix for this issue:
https://salsa.debian.org/mirror-team/archvsync/-/merge_requests/4

(Note that there's another outstanding merge request there that you might
want to merge too)

I'm attaching the patch as well.
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
>From e714ee57d5ee639e0726829114b2f913f1e8941b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Fri, 1 Apr 2022 09:48:29 +0200
Subject: [PATCH] Properly quote HOOKSCR assignations

Otherwise ftpsync is failing with bash 5.1 with errors like this:
ftpsync: line 276: local: `hook-parameter': not a valid identifier

Closes: #1008773
---
 bin/ftpsync | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bin/ftpsync b/bin/ftpsync
index 99a2ceb..25cefe5 100755
--- a/bin/ftpsync
+++ b/bin/ftpsync
@@ -591,7 +591,7 @@ fi
 
 HOOK=(
 HOOKNR=1
-HOOKSCR=${HOOK1}
+HOOKSCR="${HOOK1}"
 )
 hook $HOOK
 
@@ -651,7 +651,7 @@ while [[ -e ${UPDATEREQUIRED} ]]; do
 
 HOOK=(
 HOOKNR=2
-HOOKSCR=${HOOK2}
+HOOKSCR="${HOOK2}"
 )
 hook $HOOK
 
@@ -720,7 +720,7 @@ while [[ -e ${UPDATEREQUIRED} ]]; do
 
 HOOK=(
 HOOKNR=3
-HOOKSCR=${HOOK3}
+HOOKSCR="${HOOK3}"
 )
 hook $HOOK
 done
@@ -739,7 +739,7 @@ fi
 
 HOOK=(
 HOOKNR=4
-HOOKSCR=${HOOK4}
+HOOKSCR="${HOOK4}"
 )
 hook $HOOK
 
@@ -782,7 +782,7 @@ if [[ ${HUB} = true ]]; then
 
 HOOK=(
 HOOKNR=5
-HOOKSCR=${HOOK5}
+HOOKSCR="${HOOK5}"
 )
 hook $HOOK
 fi
-- 
2.35.1

Bug#1008774: node-path-exists: Please add (back) CommonJS support

[Jérémy Lal]

Package: node-path-exists
Version: 5.0.0-3
Severity: important

Version 5 of this package doesn't support being require()-d.

It's a reverse dep of existing packages like node-sqlite3, which now fails
and prevent migration of nodejs :(

Jérémy


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

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

-- no debconf information

Bug#1008773: ftpsync: Using commands with parameters as hooks breaks ftpsync on bullseye/debian 11

[Raphaël Hertzog]

Package: ftpsync
Version: 20180513+nmu1
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: hert...@debian.org
Control: affects -1 mirrors

In Kali we have started to switch some mirrors to Debian 11 and ftpsync
started to fail with errors like this:

Apr 01 06:19:32 poseidon ftpsync-kali[191329]: Mirrorsync start
Apr 01 06:19:32 poseidon ftpsync-kali[191329]: We got pushed from 192.99.45.140
/home/archvsync/bin/ftpsync: line 276: local: `--regex=^.*\.hook1$': not a 
valid identifier
/home/archvsync/bin/ftpsync: line 276: local: `--arg=kali': not a valid 
identifier
/home/archvsync/bin/ftpsync: line 276: local: `/home/archvsync/hooks': not a 
valid identifier
Apr 01 06:19:32 poseidon ftpsync-kali[191329]: Mirrorsync done with errors

Our ftpsync.conf contains entries like this:

## Configure hooks
HOOK1="run-parts --regex=^.*\\.hook1\$ --arg=kali /home/archvsync/hooks"
HOOK2="run-parts --regex=^.*\\.hook2\$ --arg=kali /home/archvsync/hooks"
HOOK3="run-parts --regex=^.*\\.hook3\$ --arg=kali /home/archvsync/hooks"
HOOK4="run-parts --regex=^.*\\.hook4\$ --arg=kali /home/archvsync/hooks"
HOOK5="run-parts --regex=^.*\\.hook5\$ --arg=kali /home/archvsync/hooks"

>From a quick glance, it looks like the bash version in bullseye doesn't
like some construct. Here's a minimal reproducer:

$ cat ~/tmp/test.sh
#!/bin/bash

set -e
set -u
set -E

hook () {
ARGS='HOOK[@]'
local "${!ARGS}"
echo "HOOKSCR='$HOOKSCR'"
}

HOOK1="run-parts --regex=^.*\\.hook1\$ --arg=kali /home/archvsync/hooks"

HOOK=(
HOOKNR=1
HOOKSCR=${HOOK1}
)
hook $HOOK

In buster it works fine:
$ bash ~/tmp/test.sh
HOOKSCR='run-parts --regex=^.*\.hook1$ --arg=kali /home/archvsync/hooks'
$ echo $?
0

In bullseye it fails:
$ bash ~/tmp/test.sh
/home/rhertzog/tmp/test.sh: line 9: local: `--regex=^.*\.hook1$': not a valid 
identifier
/home/rhertzog/tmp/test.sh: line 9: local: `--arg=kali': not a valid identifier
/home/rhertzog/tmp/test.sh: line 9: local: `/home/archvsync/hooks': not a valid 
identifier
$ echo $?
1

It seems that you can quote the variable assignation for HOOKSCR and it
works again:
HOOK=(
HOOKNR=1
HOOKSCR="${HOOK1}"
)

$ bash ~/tmp/test.sh
HOOKSCR='run-parts --regex=^.*\.hook1$ --arg=kali /home/archvsync/hooks'

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

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

Versions of packages ftpsync depends on:
ii  postfix [mail-transport-agent]  3.6.4-1+b1
ii  rsync   3.2.3-8

Versions of packages ftpsync recommends:
ii  curl  7.82.0-2

ftpsync suggests no packages.

-- no debconf information

Bug#1008716: quirks

[alain]

Linux sid 5.16.0-6-amd64 #1 SMP PREEMPT Debian 5.16.18-1 (2022-03-29) 
x86_64 GNU/Linux
avril 01 08:31:50 sid kernel: i2c i2c-3: adapter quirk: no zero length 
(addr 0x001f, size 0, write)
avril 01 08:31:50 sid kernel: i2c i2c-3: adapter quirk: no zero length 
(addr 0x001e, size 0, write)
avril 01 08:31:50 sid kernel: i2c i2c-3: adapter quirk: no zero length 
(addr 0x001d, size 0, write)
avril 01 08:31:50 sid kernel: i2c i2c-3: adapter quirk: no zero length 
(addr 0x001c, size 0, write)
avril 01 08:31:50 sid kernel: i2c i2c-3: adapter quirk: no zero length 
(addr 0x001b, size 0, write)
avril 01 08:31:50 sid kernel: i2c i2c-3: adapter quirk: no zero length 
(addr 0x001a, size 0, write)
avril 01 08:31:50 sid kernel: i2c i2c-3: adapter quirk: no zero length 
(addr 0x0019, size 0, write)
avril 01 08:31:50 sid kernel: i2c i2c-3: adapter quirk: no zero length 
(addr 0x0018, size 0, write)



alain@sid:~$ sudo dmesg | grep quirks
[    1.479849] xhci_hcd :05:00.1: hcc params 0x0278ffe5 hci version 
0x110 quirks 0x0410
[    1.481241] xhci_hcd :05:00.3: hcc params 0x0278ffe5 hci version 
0x110 quirks 0x0410
[    1.482348] xhci_hcd :0c:00.3: hcc params 0x0278ffe5 hci version 
0x110 quirks 0x0410



alain@sid:~$ ls /etc/modprobe.d/
ath9k_htc.conf  dkms.conf  mdadm.conf  qemu-blacklist.conf

alain@sid:~$ cd /etc/modprobe.d

alain@sid:/etc/modprobe.d$ cat ath9k_htc.conf
options ath9k_htc use_dev_fw=1

alain@sid:/etc/modprobe.d$ cat dkms.conf
# modprobe information used for DKMS modules
#
# This is a stub file, should be edited when needed,
# used by default by DKMS.

alain@sid:/etc/modprobe.d$ cat mdadm.conf
# mdadm module configuration file
# set start_ro=1 to make newly assembled arrays read-only initially,
# to prevent metadata writes.  This is needed in order to allow
# resume-from-disk to work - new boot should not perform writes
# because it will be done behind the back of the system being
# resumed.  See http://bugs.debian.org/415441 for details.

options md_mod start_ro=1

alain@sid:/etc/modprobe.d$ cat qemu-blacklist.conf
blacklist bochs-drm

Bug#1008772: xrdp: Please integrate NMUs and gitlab MR

[Arnaud Rebillout]

On Fri, 1 Apr 2022 08:55:45 +0200 Raphael Hertzog 
 wrote:

> I have just uploaded an NMU prepared by a Kali contributor (in the NM
> queue). Please find the relevant "git am" patches attached. (The two
> patches by Arnaud are also in https://salsa.debian.org/arnaudr/xrdp)

I have opened a MR with the changes: 
https://salsa.debian.org/debian-remote-team/xrdp/-/merge_requests/7/commits


--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1007965: Cyrus IMAP 3.6 Migration Failure

[Petr Vandrovec]

Hi,
 I'm on the same boat.  But it seems that upgrade failure is not
caused by missing utilities, but rather by mailboxes created more than
7 years ago (probably in cyrus 2.x).

Code to upgrade mailboxes
(https://github.com/cyrusimap/cyrus-imapd/blob/add814e90cb2cb5804e5e9c87faca7af253ded4e/imap/mboxlist.c#L5411)
is calling hash_lookup with mbentry->uniqueid - but mbentry->uniqueid
may be NULL, causing NULL pointer dereference and crash.

When I dumped my old mailbox db, I can see that "new" entries have new
% format, with 'I' field, but old ones use legacy format without 'I'
key:

...
user.petr.Inbox2013 0 default petr  lrswipcda
user.petr.Inbox2014 0 default petr  lrswipcda
user.petr.Inbox2015 %(A %(petr lrswipcda) I
ol64w50y514kvpoke32tg6a3 P default V 1569218712 F 1 M 1569218711)
user.petr.Inbox2016 %(A %(petr lrswipcda) I
abommco8w0dxyzyjju8nu2rw P default V 1569218720 F 1 M 1569218719)
...

So to me this looks like upstream problem.  I have applied patch below
on my host, and it seems to have fixed update crash.

--- cyrus-imapd-3.6.0~beta2/imap/mboxlist.c 2022-03-10
15:09:08.0 -0800
+++ cyrus-imapd-3.6.0~beta2.new/imap/mboxlist.c 2022-03-31
23:52:52.427711987 -0700
@@ -5408,6 +5408,9 @@
 mbentry->mbtype |= MBTYPE_LEGACY_DIRS;

 int idx = 0;
+if (mbentry->uniqueid == NULL) {
+mbentry->uniqueid = xstrdup(makeuuid());
+}
 ptrarray_t *pa = hash_lookup(mbentry->uniqueid, urock->ids);
 if (!pa) {
 pa = ptrarray_new();


Also I think it would be nice if update code would create new
mailbox.db.NEW, and then rename .db to db.OLD and db.NEW to db on
success, rather than moving mailbox.db to mailbox.db.OLD, and then
perform upgrade - as then you end up with empty mailbox.db, and so 2nd
upgrade attempt succeeds, deleting mailbox.db.OLD and causing data
loss.

And finally I would suggest adding 'mailbox_legacy_dirs: true' to
imapd.conf on upgrade - if upgrade would not have failed, I would have
been for rude awakening when mailboxes for new users would have moved
into uuid directory without any warning.

Thanks,
Petr

P.S.: Sorry about using gmail, my own email server is now in a bit of
disarray :-(

Bug#1008767: ITS: biabam

[Thierry Randrianiriana]

Hi,

Yes, do it please.

Regards,

On Fri, Apr 1, 2022 at 3:36 AM Boyuan Yang  wrote:

> Source: biabam
> Version: 0.9.7-7.2
> Severity: important
> X-Debbugs-CC: randrianiri...@gmail.com
>
> Dear package biabam maintainer in Debian,
>
> After looking into the package you maintain (biabam,
> https://tracker.debian.org/pkg/biabam ), I found that this package
> received no maintainer updates in the past 11 years and was not in good
> shape. As a result, I am filing an ITS (Intent to Salvage) request
> against your package according to section 5.12 in Debian's Developers'
> Reference [1].
>
> My current plan is to clean up packaging and orphan this package in Debian
> to
> allow possible external contribution.
>
> Please let me know whether you are still willing to maintain this
> package. According to the criteria listed at [2], I will upload a Non-
> maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
> (Apr. 21, 2022) to continue with the package salvaging. If you find it
> necessary to pause the ITS process, please let me know immediately by
> replying this bug report.
>
>
> [1]
>
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> [2] https://wiki.debian.org/PackageSalvaging
>
> --
> Best Regards,
> Boyuan Yang
>