Bug#1010494: Re: Bug#1010494: RFS: usbrelay/1.0-1 -- USB HID relay driver

[Michal Sojka]

On Thu, May 05 2022, Tobias Frost wrote:
> I've just gave you access rights to the repo on salsa, you should be able to
> commit directly.
> For the review and upload, an git reference or mentors upload will works both
> for me.

[...]

> ✔. You can remove the "moreinfo" tag on this bug to signal that it is ready.

Thanks Tobias. Yesterday, Jan offered me off-list to review and possibly
upload the package, so I'll work with him and announce the result here.

-Michal

Bug#976308: ITA: cfengine3 -- tool for configuring and maintaining network machines

[Paul Gevers]

Hi,

Release Team member here going over RC bugs for bookworm.

On Wed, 1 Dec 2021 16:45:18 +0300 Fabio Tranchitella  
wrote:

I will upload the updated package for cfengine3 in the next few days.


What's the status?

cfengin3 has an RC bug #852674, but is not eligible for autoremoval due 
to its key package status.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010589: cgreen: links to libraries from binutils which are not considered stable

[Paul Gevers]

Source: cgreen
Version: 1.5.1-1
Severity: serious
X-Debbugs-Cc: gin...@debian.org, d...@debian.org

Dear maintainer,

Quoting from bug #949570:
Your package should not use the private binutils shared libraries.  If
it cannot be dropped, then please link those statically and document
it with the Built-Using tag in the binary package.

libbfd and libopcodes seem to be considered as a private interface
because their API/ABI is too unstable. This is stated in the
description:

Description: GNU binary utilities (BFD development files)
 This package includes header files and static libraries necessary to build
 programs which use the GNU BFD library, which is part of binutils.  Note
 that building Debian packages which depend on the shared libbfd is Not
 Allowed.

Paul

Bug#1010588: src:webcamoid: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: webcamoid
Version: 8.8.0+dfsg-1
Severity: serious
Control: close -1 9.0.0-3
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1007738

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:webcamoid has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. The blocking issue has already 
been reported in bug #1007738: your autopkgtest regressed.


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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010494: Re: Bug#1010494: RFS: usbrelay/1.0-1 -- USB HID relay driver

[Tobias Frost]

On Wed, May 04, 2022 at 01:27:23AM +0200, Michal Sojka wrote:
> Hi Jan and Tobias,
> 
> @Jan good to hear from you.
> @Tobias, thanks for useful suggestions, see my reactions below.
> 
> On Tue, May 03 2022, Jan Dittberner wrote:
> > As you might have guessed I'm busier than I would like and do usually need a
> > bit of time to respond.
> >
> > It would have been a good idea to contact me directly or via a wishlist bug
> > requesting a package update. I would have answered a wishlist bug
> > requesting an usbrelay upstream version update. The RFS came a bit
> > surprisingly. A short mail before starting the work would have been nice. I
> > had contact with Darryl Bond in the past and responded to his
> > requests.
> 
> I apologize for not contacting you. I'm also in contact with Darryl Bond
> and I understood that he tried to contact you recently, but without
> success. It might have been my misunderstanding.
> 
> > I would be happy to have a co-maintainer for usbrelay. @Michal you may add
> > yourself to Uploaders if you are interested in taking care of the package in
> > the future.
> 
> Yes, I'll add myself. I'm using this software quite extensively and will
> be happy to help with packaging.

\o/

> @Jan How shall I proceed now? I've implemented the changes suggested by
> Tobias, but I need to test the result again with the hardware, for which
> I'll need a day or two. What then? Shall I upload a new version to
> mentors.d.o or send salsa merge request or both?

I've just gave you access rights to the repo on salsa, you should be able to
commit directly.
For the review and upload, an git reference or mentors upload will works both
for me.

> > Please run lintian with the flags -i -v -E --pedantic to get the maximum
> > output. I recommend using pbuilder or sbuild to build in a clean
> > environment. I usually use sbuild in combination with git-buildpackage to do
> > my package builds. Both sbuild and pbuilder can lintian automatically after
> > a finished package build.
> 
> Thanks.
> 
> On Tue, May 03 2022, Tobias Frost wrote:
> > Ok, let me check the package: (I'm using the mentors version for the review)
> > - As said earlier, depending if you want a Team upload or follow the ITS, 
> > this
> >   needs some entry in d/changelog, depending how you want to proceed...
> > - debian/io.github.darrylb123.usbrelay.metainfo.xml should possible brought 
> > upstream,
> >   shouldn't it (no need to change for the upload, but I guess this is
> >   not debian specific)
> 
> I'll send that (as well as other parts) upstream. I first wanted to know
> what changes are required for Debian and then send the final version
> upstream.
> 
> > - d/rules
> >- (bikeshed -- no need to change) I'd prefer to use d/clean instead of
> >  overriding the clean target; overrides are harder to maintain :)
> 
> I didn't notice this possibility - it's definitely nicer!
> 
> > - the man page is still in the debian directory -- it can be deleted as
> >   it is now part of upstream.
> 
> Upstream has usbrelay.1, I've added usbrelayd.8. As mentioned above,
> I'll send it upstream later.

ok, I've missed that little detail that those are different manpages..
Sorry for the noise.

> > - same for the udev rules.
> 
> Upstream rules are slightly different - looser permissions, different group.

Ok, that created my confusion... For conciseness, I'd recommend to patch the
file instead of having a copy.

> > - d/usbrelay.install has a hard-coded architecture-dependent path. That 
> > will break build on
> >   archs != amd64.
> 
> Good catch.
> 
> > - d/postinst (and postrm):
> >   The username is not correct. According to Debian Policy, 4.9.1, it must 
> > start with an "_"
> >   I guess also that you don't want/need a homedirectory for that uses, so 
> > its $HOME
> >   should be /nonexistent in this case. (Policy 9.2.3)
> >   HOWEVER, let me suggest something else:
> >   Use the DynamicUser feature from systemd:
> >
> > DynamicUser=yes
> > SupplementaryGroups=plugdev
> >
> >   in the service file should make postint/postrm no longer be needed.
> 
> That's definitely a good thing.
> 
> > - Lintian has a few remarks: (my related remarks in brackets)
> > W: usbrelay source: no-nmu-in-changelog
> > W: usbrelay source: source-nmu-has-incorrect-version-number 1.0-1
> >   (will be gone once the changelog mentions the team upload or after the 
> > salvage procedure is done)
> > I: usbrelay source: debian-rules-parses-dpkg-parsechangelog (line 20)
> >   (see abovr)
> > I: usbrelay source: older-debian-watch-file-standard 3
> >   (could be updated to version 4, just s/3/4/ in the header)
> 
> done
> 
> > I: usbrelayd: package-supports-alternative-init-but-no-init.d-script 
> > lib/systemd/system/usbrelayd.service
> >   (can be ignored)
> > I: usbrelay source: patch-not-forwarded-upstream 
> > debian/patches/0002-Mention-README-in-the-man-page.patch
> > I: usbrelay source: patch-not-forwarded-upstream debian/patches/gcc9.patch
> >   

Bug#1010587: RM: lizardfs -- ROM; obsolete; FTBFS

[Dmitry Smirnov]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: debian-de...@lists.debian.org
Control: affects -1 src:lizardfs

Please remove "lizardfs" from "unstable".

The package is no longer properly maintained upstream and it FTBFS here
in Debian.

Thanks.

LizardFS users should migrate to MooseFS.

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

The end cannot justify the means for the simple and obvious reason that the
means employed determine the nature of the ends produced.
 -- Aldous Huxley

---

"Increased emergency cardiovascular events among under-40 population in
Israel during vaccine rollout and third COVID-19 wave" (2022-04-28)
 -- https://www.nature.com/articles/s41598-022-10928-z#Sec14

"MIT study has found a 25% increase in cardiovascular events in young
people during the vaccine rollout. Excess deaths are associated with
vaccine rollouts all over the world." -- Dr. Simone Gold


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

Bug#1010586: RM: node-lolex/5.1.2+ds-3

[Yadd]

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

Hi,

node-lolex has no more reverse dependencies and is broken with nodejs
16. Could you remove it from testing to allow nodejs migration ?

Details:
 * Deprecated: renamed to @sinonjs/fake-timers (node-sinon)
 * ROM-RM: 1010512
 * RC-Bug: 1010513

Cheers,
Yadd

Bug#1010585: prusa-slicer: Add support for 3mf mime type

[Dan Letzeisen]

Package: prusa-slicer
Version: 2.4.2+dfsg-1
Severity: wishlist

Dear Maintainer,

Please consider adding support for 'application/vnd.ms-3mfdocument' mime type 
in your package. This way, filenames with a .3mf extension will open in Prusa 
Slicer instead of being detected as zip files.
Note: upstream supports this mime type, and it may be a side effect of bug 
1004132.

Adding this to prusa-slicer.sharedmimeinfo should work:


3D Manufacturing Format Document





And, of course, modify prusa-slicer.desktop accordingly.

Thank you


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

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages prusa-slicer depends on:
ii  fonts-noto-hinted  20201225-1
ii  libboost-chrono1.74.0  1.74.0-14+b1
ii  libboost-filesystem1.74.0  1.74.0-14+b1
ii  libboost-iostreams1.74.0   1.74.0-14+b1
ii  libboost-locale1.74.0  1.74.0-14+b1
ii  libboost-log1.74.0 1.74.0-14+b1
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu71]  1.74.0-14+b1
ii  libboost-thread1.74.0  1.74.0-14+b1
ii  libc6  2.33-7
ii  libcurl3-gnutls7.83.0-1
ii  libdbus-1-31.14.0-1
ii  libexpat1  2.4.8-1
ii  libgcc-s1  12-20220428-1
ii  libgl1 1.4.0-1
ii  libglew2.2 2.2.0-4
ii  libglib2.0-0   2.72.1-1
ii  libgmp10   2:6.2.1+dfsg-3
ii  libgtk-3-0 3.24.33-1
ii  libilmbase25   2.5.7-2
ii  libmpfr6   4.1.0-3
ii  libnlopt0  2.7.1-4+b1
ii  libopenvdb8.1  8.1.0-3
ii  libpng16-161.6.37-5
ii  libstdc++6 12-20220428-1
ii  libtbb22020.3-1
ii  libwxbase3.0-0v5   3.0.5.1+dfsg-4
ii  libwxgtk3.0-gtk3-0v5   3.0.5.1+dfsg-4

prusa-slicer recommends no packages.

prusa-slicer suggests no packages.

-- no debconf information

Bug#1008354: fossil: FTBFS: ./conftest__.c:3: undefined reference to `sqlite3_open'

[Nobuhiro Ban]

Dear Maintainer,

This is a bug in the fossil configure tool, and fixed in upstream:
commit: https://fossil-scm.org/home/info/8af827342f4c4a77
forum: https://fossil-scm.org/forum/info/549da79dd9

cf. https://www.sqlite.org/src/info/4cbb3e3efeb40cc4


Regards,
Nobuhiro Ban

Bug#952810: Intent to adopt ebib

[Aymeric Agon-Rambosson]

Hello Mr. Whitton,

First of all, thank you for your work as maintainer of ebib.

I use ebib regularly, and I am ready to adopt it. In fact, I 
already have a completely debian-compliant and lintian-clean 
package of the last upstream version in my private debian archive, 
that I have been using for the past week without errors so far.


I am no debian maintainer or developer. This would be my first 
package to maintain (with parsebib, for which I have applied 
earlier). I have no preference whatsoever between joining the 
emacsen team or taking the package out of the team's hand. I could 
however be interested later in helping maintain other emacs 
packages, and even adding new ones. Would joining the emacsen team 
be the best course of action for this purpose ?


What should I do next ?

Aymeric Agon-Rambosson

Bug#1007867: O: parsebib

[Aymeric Agon-Rambosson]

Hello Mr. Whitton,

First of all, thank you for your work as maintainer of parsebib.

I use parsebib regularly, and I am ready to adopt it. In fact, I 
already have a completely debian-compliant and lintian-clean 
package of the last upstream version in my private debian archive, 
that I have been using for the past week without errors so far.


I am no debian maintainer or developer. This would be my first 
package to maintain. I have no preference whatsoever between 
joining the emacsen team or taking the package out of the team's 
hand. I could however be interested later in helping maintain 
other emacs packages, and even adding new ones. Would joining the 
emacsen team be the best course of action for this purpose ?


What should I do next ?

Aymeric Agon-Rambosson

Bug#1010584: ITS: rlwrap

[Thomas Ward]

Source: rlwrap
Severity: important

Hello.

The rlwrap package has a seriously outdated version of rlwrap and 
multiple bugs open against it indicating it needs to be updated to a 
newer version of rlwrap in order to fix those.


The last activity by the sole listed maintainer, Mike Miller 
, shows that no activity has been done on the 
package since 2018 when they uploaded 0.43-1 to the repositories [1].


There has been no activity on the Salsa repository since two years ago 
(which did some packaging cleanup, rules changes, some Salsa CI changes, 
etc. back in April of 2020) and no release updates since 0.43-1.  [2]  
There were staged 0.43-2 packaging changes (debhelper changes, 
misspellings, cleanup of metadata fields, etc.) done by Janitor but 
nothing ever landed (and remains in UNRELEASED).


Upstream between 2017 and 2021 did not have any activity, however 
upstream began rereleasing versions starting with 0.44 in 2021.  [3]


Further, according to the contributions pages of the sole maintainer 
Mike Miller [4], there has been no activity since December 2020 by the 
individual.  This may not reflect all activity, but is a pretty good 
indicator there's been "limited activity" from the DD in question, so I 
have CC'd the MIA team on this as well.


I emailed the Maintainer over a week ago as well, asking if they needed 
assistance or would like me to help comaintain the package - I have not 
received any response to that inquiry.



---

According to the rules for Package Salvaging [5] [6] a package is 
eligible for salvaging based on certain criterion.


The criterion that this package meets are, in my belief, as follows:

 1. There are open bugs AND missing upstream releases of the rlwrap 
software, including bugs where there are substantially large issues that 
are acknowledged but not updated/fixed,
 2. A new package upload of a newer version of rlwrap is needed to fix 
these issues, and

 3. The following additional criterion:
    - There has been no activity regarding the package for 6 months 
other than bugs and a response from over 2 years ago on it, and
    - Bugs exist for more than one major missing upstream version in 
that 0.44 is needed to be packaged (or later) to fix the readline bugs 
that're happening and have been persistent for over 2 years.


Under these eligibility criterion, the package is eligible for salvaging.

If the original maintainer can be reached, and would prefer to simply 
add me as a co-maintainer, I would be willing to accept that.  However, 
if the original maintainer would like to relinquish management, or 
cannot be reached, I would accept taking over the package and its 
maintenance in Debian.



Thomas



[1]: https://tracker.debian.org/pkg/rlwrap
[2]: https://salsa.debian.org/debian/rlwrap/-/commits/master
[3]: https://github.com/hanslub42/rlwrap/tags
[4]: https://contributors.debian.org/contributor/mtmiller/
[5]: 
https://wiki.debian.org/PackageSalvaging#Eligibility_requirements_for_a_package
[6]: 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-a-package-is-eligible-for-package-salvaging


OpenPGP_0x5B8AD6F4C26A.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006753: dkms modules not rebuilt on kernel upgrades with unattended upgrades

[Trent W. Buck]

Trent W. Buck wrote:
> I can reproduce this issue.
> It has bitten me 3 or 4 times.
> I think happens every time the ABI bumps (5.10-n → 5.10-n+1).
> 
> For me, the timeline is this:
> 
>   1. unattended-upgrades installs new kernel
>   2. kernel postinst builds new initrd
>   3. unattended-upgrades installs new headers
>   4. kernel postinst new zfs.ko

PS: from unattended-upgrades-dpkg.log, I'm pretty sure the problem is "above" 
dpkg, but
I'm not clear if it's in unattended-upgrades or in apt.

If it's happening in the apt layer,
I guess that is because linux-image-N-amd64 does not Depends on 
linux-headers-N-amd64.
So apt thinks it can do 2 separate dpkg runs, and (sometimes?) in the wrong 
order?

If that's what happens, it's unreasonable to add stronger dependencies, 
because
then EVERYONE will be forced to install headers.

Is it reasonable for unattended-upgrades to have a special-case safety net 
for this?
Something like

 If unattended-upgradse is upgrading a kernel AND a headers,
 then ensure headers installs first.

Bug#1006753: dkms modules not rebuilt on kernel upgrades with unattended upgrades

[Trent W. Buck]

I can reproduce this issue.
It has bitten me 3 or 4 times.
I think happens every time the ABI bumps (5.10-n → 5.10-n+1).

For me, the timeline is this:

  1. unattended-upgrades installs new kernel
  2. kernel postinst builds new initrd
  3. unattended-upgrades installs new headers
  4. kernel postinst new zfs.ko

Because #2 happens before #4, I get an initrd that says

Failed to load ZFS modules.
Manually load the modules and exit.

⋮

(initramfs)

Attached are the detailed logs.

Note that unattended-upgrades runs once, but dpkg appears to run twice.
This might explain why triggers are run in the wrong order?


Please note that

  • linux-headers-amd64 is installed.
This is not simply "unattended-upgrades doesn't upgrade the header package"

  • No backport kernels are involved.
This is not simply "unattended-upgrades is a bit weird for bpo kernels"
adduser 3.118
alsa-topology-conf  1.2.4-1
alsa-ucm-conf   1.2.4-2
amd64-microcode 3.20191218.1
ansible 2.10.7+merged+base+2.10.8+dfsg-1
apparmor2.13.6-10
apt 2.2.4
apt-listbugs0.1.35
apt-listchanges 3.24
apt-utils   2.2.4
aptitude0.8.13-3
aptitude-common 0.8.13-3
augeas-lenses   1.12.0-2
base-files  11.1+deb11u3
base-passwd 3.5.51
bash5.1-2+b3
bash-completion 1:2.11-2
binutils2.35.2-2
binutils-common:amd64   2.35.2-2
binutils-x86-64-linux-gnu   2.35.2-2
bolt0.9.1-1
bsd-mailx   8.1.2-0.20180807cvs-2
bsdextrautils   2.36.1-8+deb11u1
bsdmainutils12.1.7+nmu3
bsdutils1:2.36.1-8+deb11u1
build-essential 12.9
busybox 1:1.30.1-6+b3
bzip2   1.0.8-4
ca-certificates 20210119
calendar12.1.7+nmu3
collectd-core   5.12.0-7
collectd-utils  5.12.0-7
console-setup   1.205
console-setup-linux 1.205
coreutils   8.32-4+b1
cpio2.13+dfsg-4
cpp 4:10.2.1-1
cpp-10  10.2.1-6
cryptsetup  2:2.3.7-1+deb11u1
cryptsetup-bin  2:2.3.7-1+deb11u1
cryptsetup-initramfs2:2.3.7-1+deb11u1
cryptsetup-run  2:2.3.7-1+deb11u1
curl7.74.0-1.3+deb11u1
cyber-zfs-backup0.3
dash0.5.11+git20200708+dd9ef66-5
dbus1.12.20-2
dbus-user-session   1.12.20-2
dctrl-tools 2.24-3+b1
debconf 1.5.77
debconf-i18n1.5.77
debian-archive-keyring  2021.1.1
debian-security-support 1:11+2021.03.19
debianutils 4.11.2
debsums 3.0.2
dictionaries-common 1.28.4
diffutils   1:3.7-5
dirmngr 2.2.27-2+deb11u1
distro-info-data0.51+deb11u1
dkms2.8.4-3
dmidecode   3.3-2
dmsetup 2:1.02.175-2.1
dosfstools  4.2-1
dpkg1.20.9
dpkg-dev1.20.9
dropbear-bin2020.81-3
dropbear-initramfs  2020.81-3
e2fsprogs   1.46.2-2
efibootmgr  17-1
eject   2.36.1-8+deb11u1
emacs   1:27.1+1-3.1
emacs-bin-common1:27.1+1-3.1
emacs-common1:27.1+1-3.1
emacs-el1:27.1+1-3.1
emacs-nox   1:27.1+1-3.1
emacsen-common  3.0.4
etckeeper   1.18.16-1
exfat-fuse  1.3.0-2
exfat-utils 1.3.0-2
fakeroot1.25.3-1.1
fdisk   2.36.1-8+deb11u1
file1:5.39-3
findutils   4.8.0-1
firmware-amd-graphics   20210315-3
firmware-linux  20210315-3
firmware-linux-free 20200122-1
firmware-linux-nonfree  20210315-3
firmware-misc-nonfree   20210315-3
firmware-realtek20210315-3
fontconfig  2.13.1-4.2
fontconfig-config   2.13.1-4.2
fonts-dejavu-core   2.37-2
fonts-lato  2.0-2.1
fuse2.9.9-5
fwupd   1.5.7-4
fwupd-amd64-signed  1.5.7+4
g++ 4:10.2.1-1
g++-10  10.2.1-6
gcc 4:10.2.1-1
gcc-10  10.2.1-6
gcc-10-base:amd64   10.2.1-6
gcc-9-base:amd649.3.0-22
gdisk   1.0.6-1.1
gettext-base0.21-4
gir1.2-glib-2.0:amd64   1.66.1-1+b1
git 1:2.30.2-1
git-man 1:2.30.2-1
gnupg   2.2.27-2+deb11u1
gnupg-l10n  2.2.27-2+deb11u1
gnupg-utils 2.2.27-2+deb11u1
gpg 2.2.27-2+deb11u1
gpg-agent   2.2.27-2+deb11u1
gpg-wks-client  2.2.27-2+deb11u1
gpg-wks-server  2.2.27-2+deb11u1
gpgconf 2.2.27-2+deb11u1
gpgsm   2.2.27-2+deb11u1
gpgv2.2.27-2+deb11u1
grep3.6-1
groff-base  1.22.4-6
gsasl-common1.10.0-4
gzip1.10-4+deb11u1
hdparm  9.60+ds-1
hostname3.23
how-can-i-help  17
htop3.0.5-7
ieee-data   20210605.1
ifupdown0.8.36
init1.60
init-system-helpers 1.60
initramfs-tools 0.140
initramfs-tools-core0.140
install-info6.7.0.dfsg.2-6
intel-microcode 3.20220207.1~deb11u1
iproute25.10.0-4
iputils-ping3:20210202-1
isc-dhcp-client 4.4.1-2.3
isc-dhcp-common 4.4.1-2.3
iucode-tool 2.3.1-1
javascript-common   11+nmu1
kbd 2.3.0-3
keyboard-configuration  1.205
klibc-utils 2.0.8-6.1
kmod28-1
knot-dnsutils   3.0.5-1
knot-host   3.0.5-1
ldnsutils   1.7.1-2+b1
less551-2
libacl1:amd64   2.2.53-10
libapparmor1:amd64  2.13.6-10
libapt-pkg6.0:amd64 2.2.4
libarchive13:amd64  3.4.3-2+deb11u1
libargon2-1:amd64   0~20171227-0.2
libasan6:amd64  10.2.1-6
libasound2:amd641.2.4-1.1
libasound2-data 1.2.4-1.1
libassuan0:amd642.5.3-7.1
libatasmart4:amd64  0.19-5
libatomic1:amd64

Bug#1008951: openldap FTBFS on musl-linux-any: conflicting declaration of calloc

[Ryan Tandy]

Control: tag -1 upstream moreinfo

Hi Helmut,

Thanks for the analysis and patch, and sorry for the slow response.

Has this been reported upstream yet? I searched and didn't find this 
specific issue, but it looks like upstream have fixed at least two other 
musl-specific issues recently [ITS#9648, ITS#9650].


Before applying a patch for this in Debian, I'd at least like to know 
whether and how upstream intend to address the issue. I'd rather not 
take a patch if it has no future upstream.


thanks,
Ryan

[ITS#9648]: https://bugs.openldap.org/show_bug.cgi?id=9648
[ITS#9650]: https://bugs.openldap.org/show_bug.cgi?id=9650

Bug#1010582: varnish: New upstream release 7.1.0

[Luís Cunha dos Reis Infante da Câmara]

Package: varnish
Version: 6.6.1-1
Severity: serious

Dear Maintainer,

A new upstream release 7.1.0 is available, that fixes CVE-2022-23959.

I need this version for it to be automatically synced into Ubuntu 
Kinetic

(see https://bugs.launchpad.net/ubuntu/+source/varnish/+bug/1971504).

Kind regards,
Luís Infante da Câmara

Bug#1005083: Chromium 99 update

[Timothy Pearson]

As a quick update, I'm starting another push (small at first) to try to get 
some of the more downstream-invasive changes upstream.  Starting with the build 
config generators, as downstream distros can only patch in the entire generated 
config which gets messy.

https://chromium-review.googlesource.com/c/chromium/src/+/3626304
https://chromium-review.googlesource.com/c/chromium/src/+/3627862
https://chromium-review.googlesource.com/c/chromium/src/+/3626305

Let's see how those three are received and plan from there...

Bug#1010580: acp drivers

[Vincent Blut]

Hi Mario,

Le 2022-05-04 16:04, Limonciello, Mario a écrit :
> Package: linux
> Version: 5.17.3
> 
> Currently the kernel config by default does not configure these two options:
> # CONFIG_SND_SOC_AMD_ACP5x is not set
> # CONFIG_SND_SOC_AMD_ACP6x is not set
> 
> Ideally these should both be set to "m".
> 
> ACP5x is for supporting the ACP in the Steam Deck.
> ACP6x is for supporting the DMIC in notebooks with Ryzen 6000.

This is on my TODO list.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1010570: binaries in source without related source

[Tino Mettler]

Am Wed, May 04, 2022 at 22:12:20 +0200 schrieb Tino Mettler:
> Am Wed, May 04, 2022 at 15:17:05 -0400 schrieb Antoine Beaupré:
> 
> [...]
> 
> > maybe we could just use a +ds tarball then. add the files to redact in
> > debian/copyright and then uscan will just do the right thing for us, no
> > need to worry about the git stuff.
> 
> We need the images/ and tips/ folders from the upstream git repository.
> 
> This script would work. I already prepared a package using the +dfsg upstream
> source generated by the script. The resources are compiles during
> build, the result looks good.

I forgot to git add the upgrade.py. Furthermore, Damon mentioned
install.py. And yes, it contains another binary blob (the same ZIP
archive as upgrade.py, I guess).

Here is an improved script:

#!/bin/sh -ex

git reset --hard $1
VERSION=$(sed '/^-/,$d' CHANGES.md | tail -n 1 | cut -d' ' -f1)

echo > upgrade.py
echo > install.py
git add upgrade.py install.py
git rm raphodo/qrc_resources.py
git commit -m "Remove source files with embedded binary blobs"

git archive HEAD --prefix=rapid-photo-downloader-$VERSION/ -o 
../rapid-photo-downloader_${VERSION}+dfsg.orig.tar.xz

Regards,
Tino

Bug#726363: No longer displays Unicode characters

[Negar Taheri]

On Mon, 14 Oct 2013 16:36:32 -0700 Josh Triplett 
wrote:
> Package: gnome-terminal
> Version: 3.8.4-1
> Severity: important
>
> (I don't know if this bug lies with gnome-terminal or with something it
> depends on.)
>
> After upgrading to GNOME 3.8 in latest unstable, gnome-terminal no
> longer displays Unicode characters, including line-drawing characters;
> they show up as unknown-character symbols, question marks, or similar.
> For example, tools like mutt, tree, or wget produce piles of
> unknown-character symbols, one per UTF-8 byte.
>
> wget, for instance, prints Unicode single-quotes around the filename it
> prints, which consist of the UTF-8 bytes e2 80 98 and e2 80 99.  Those
> show up as three unknown-character symbols.
>
> I'm running gnome-terminal in the C.UTF-8 locale, and I haven't changed
> that.
>
> - Josh Triplett
>
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages gnome-terminal depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.16.1-1
> ii  gconf-service3.2.6-1
> ii  gnome-terminal-data  3.8.4-1
> ii  gsettings-desktop-schemas3.8.2-2
> ii  libatk1.0-0  2.10.0-2
> ii  libc62.17-93
> ii  libdconf10.16.1-1
> ii  libgconf-2-4 3.2.6-1
> ii  libglib2.0-0 2.36.4-1
> ii  libgtk-3-0   3.8.4-1
> ii  libpango-1.0-0   1.32.5-5+b1
> ii  libuuid1 2.20.1-5.5
> ii  libvte-2.90-91:0.34.8-1
> ii  libx11-6 2:1.6.2-1
>
> Versions of packages gnome-terminal recommends:
> ii  dbus-x11  1.6.16-1
> ii  gvfs  1.16.3-1+b1
> ii  yelp  3.8.1-2
>
> gnome-terminal suggests no packages.
>
> -- no debconf information
>
>

Bug#930966: ITP: pwnat -- allows clients behind NATs to communicate

[Samuel Henrique]

I have reviewed the packaging of Nilson Silva
 but it got blocked as I'm not sure this
package is a good fit for our official repos.

I could find issues on upstream's Github where people are talking
about how the method pwnat uses is outdated (upstream even wrote a
replacement, called slipstream)[0].

pwnat doesn't work with new routers (as of at least 2017), it might
not work with CGNAT, and it relies on the fact that the IP address
3.3.3.3 is unreachable (I'm not sure if a host on 3.3.3.3 would break
pwnat or not, but ISPs might be blocking this too now).

Some links for those issues:
https://github.com/samyk/pwnat/issues/18#issuecomment-703373953
https://github.com/samyk/pwnat/issues/17#issue-619482494
https://github.com/samyk/pwnat/issues/10#issuecomment-282223632

Since I didn't went all the way into the rabbit hole when doing my
analysis, I could be wrong and in fact pwnat will work in most of the
cases, if that's the case, please reply to this bug with details.

Thanks,

[0] https://github.com/samyk/slipstream

-- 
Samuel Henrique 

Bug#999225: cl-getopt: diff for NMU version 1.2.0-3.2

[Marcos Talau]

Control: tags 999225 + patch
Control: tags 999225 + pending

Dear maintainer,

I've prepared an NMU for cl-getopt (versioned as 1.2.0-3.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u cl-getopt-1.2.0/debian/changelog cl-getopt-1.2.0/debian/changelog
--- cl-getopt-1.2.0/debian/changelog
+++ cl-getopt-1.2.0/debian/changelog
@@ -1,3 +1,10 @@
+cl-getopt (1.2.0-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999225).
+
+ -- Marcos Talau   Thu, 28 Apr 2022 13:00:53 -0300
+
 cl-getopt (1.2.0-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u cl-getopt-1.2.0/debian/rules cl-getopt-1.2.0/debian/rules
--- cl-getopt-1.2.0/debian/rules
+++ cl-getopt-1.2.0/debian/rules
@@ -43,5 +43,7 @@
 
 binary: binary-indep
 
+build-arch: build
+build-indep: build
 
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#1010535: cyrus-imapd: FTBFS against openssl 3

[Dan Bungert]

I ended up sending a PR to upstream anyhow, even though it was tested against
the source from Debian.  We'll see that they say.

https://github.com/cyrusimap/cyrus-imapd/pull/4075

-Dan

Bug#918984: fuse3 still not co-installable with fuse

[Paul Gevers]

Hi,

Just for the record in this bug, the versioned Provides was implemented 
before the release of bullseye, so that didn't solve the problem 
Sebastian mentioned.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010570: binaries in source without related source

[Tino Mettler]

Am Wed, May 04, 2022 at 15:17:05 -0400 schrieb Antoine Beaupré:

[...]

> maybe we could just use a +ds tarball then. add the files to redact in
> debian/copyright and then uscan will just do the right thing for us, no
> need to worry about the git stuff.

We need the images/ and tips/ folders from the upstream git repository.

This script would work. I already prepared a package using the +dfsg upstream
source generated by the script. The resources are compiles during
build, the result looks good.

#!/bin/sh -ex

git reset --hard $1
VERSION=$(sed '/^-/,$d' CHANGES.md | tail -n 1 | cut -d' ' -f1)

echo > upgrade.py
git rm raphodo/qrc_resources.py
git commit -m "Remove source files with embedded binary blobs"

git archive HEAD --prefix=rapid-photo-downloader-$VERSION/ -o 
../rapid-photo-downloader_${VERSION}+dfsg.orig.tar.xz

Regards,
Tino

Bug#1010579: RFS: shotwell/0.30.15-2 -- digital photo organizer

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name: shotwell
   Version : 0.30.15-2
   Upstream Author : Jim Nelson 
   URL : https://wiki.gnome.org/Apps/Shotwell
   License : LGPL-2.1
   Vcs : https://jff.email/cgit/shotwell.git
   Section : gnome

The source builds the following binary packages:

  shotwell - digital photo organizer
  shotwell-common - digital photo organizer - common files

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/s/shotwell/shotwell_0.30.15-2.dsc

or from 

 git https://jff.email/cgit/shotwell.git?h=release%2Fdebian%2F0.30.15-2

 

Changes since the last upload:

 shotwell (0.30.15-2) unstable; urgency=medium
 .
   * New debian/patches/0110-use_relative_lib_path.patch:
 - Use relative path for libs (Closes: #1010571).
   Thanks to Neil McGovern .
   * Remove trailing whitespace from debian/rules.
   * Rename lintian tag non-dev-pkg-with-shlib-symlink to
 link-to-shared-library-in-wrong-package.


CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#991328: NGINX patch for CVE pending in Salsa

[Thomas Ward]

Control: tags -1 + pending

Looks like, at first glance the patchset applies properly in 1.20.2 
(3-line offset but no fuzz) as is.  I've pushed this into Salsa so it's 
pending in UNRELEASED 1.20.2-2 at the moment in Salsa.



Thomas


On 5/4/22 15:44, Salvatore Bonaccorso wrote:

Hi Thomas,

On Wed, May 04, 2022 at 07:22:22PM +, Thomas Ward wrote:

You are correct - bage@ saying this was fixed and should've been
included in changelogs in the RFS threw me off.  The fix requires
new commands and essentially 'functionality' added which is probably
why it wasn't added in upstream.  I could've sworn I included this
patch pre-upload but that might've been my fault that it didn't get
included, which is also my fault.

I can either backport this, or we can wait for the next nginx stable
release 1.22 which should be coming "sometime soon" unless F5 has
changed the development/release schedule.  In which case unmarking
this as fixed and keeping it open is going to be necessary.  I
believe we only track nginx stable (the even number releases) not
mainline, which may have led to this.

I'll prep a backported patch, if it imports cleanly.  If it doesn't,
we'll have to wait for 1.22 release of NGINX OSS.

Many thanks for your quick confirmation! I do not think it's
particularly pressing, if the fix does not apply or is not
backportable to 1.20.x then when ready moving to 1.22 is fine. Ideally
the fix is applied for bookworm.

Thanks for working on those updates!

Regards,
Salvatore

Bug#959155: shotwell: please provide a version of shotwell without webkit

[Jörg Frings-Fürst]

Hello,

as already written, this is a proposal that needs to be implemented by
the upstream. I therefore close the bug here.


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#991328: closed by Thomas Ward ()

[Salvatore Bonaccorso]

Hi Thomas,

On Wed, May 04, 2022 at 07:22:22PM +, Thomas Ward wrote:
> You are correct - bage@ saying this was fixed and should've been
> included in changelogs in the RFS threw me off.  The fix requires
> new commands and essentially 'functionality' added which is probably
> why it wasn't added in upstream.  I could've sworn I included this
> patch pre-upload but that might've been my fault that it didn't get
> included, which is also my fault.
> 
> I can either backport this, or we can wait for the next nginx stable
> release 1.22 which should be coming "sometime soon" unless F5 has
> changed the development/release schedule.  In which case unmarking
> this as fixed and keeping it open is going to be necessary.  I
> believe we only track nginx stable (the even number releases) not
> mainline, which may have led to this.
> 
> I'll prep a backported patch, if it imports cleanly.  If it doesn't,
> we'll have to wait for 1.22 release of NGINX OSS.

Many thanks for your quick confirmation! I do not think it's
particularly pressing, if the fix does not apply or is not
backportable to 1.20.x then when ready moving to 1.22 is fine. Ideally
the fix is applied for bookworm.

Thanks for working on those updates!

Regards,
Salvatore

Bug#1010578: osmo-mgw: FTBFS if systemd is in build environment

[Dan Bungert]

Package: osmo-mgw
Version: 1.9.0+dfsg1-3
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Dear Maintainer,

If systemd is present in the build environment, the following output will be
observed during build:

dh_missing: warning: lib/systemd/system/osmo-mgw.service exists in debian/tmp
but is not installed to anywhere
dh_missing: error: missing files, aborting

This appears to be due to an unexpected upstream systemd service file, that is
then not covered by the existing debhelper commands.

There are several options to avoid this, including
* add the entry to not-installed
* configure with argument --with-systemdsystemunitdir=no, which cause the
  install step to not provide the upstream systemd service file
* adjust the package to use the upstream systemd service file

I propose using the --with-systemdsystemunitdir=no configuration.  See below.

-Dan

diff -Nru osmo-mgw-1.9.0+dfsg1/debian/rules osmo-mgw-1.9.0+dfsg1/debian/rules
--- osmo-mgw-1.9.0+dfsg1/debian/rules   2022-03-16 14:59:47.0 -0600
+++ osmo-mgw-1.9.0+dfsg1/debian/rules   2022-05-04 13:34:46.0 -0600
@@ -15,6 +15,10 @@
 %:
dh $@ --with autoreconf

+override_dh_auto_configure:
+   # Use the packaging-provided systemd unit file
+   dh_auto_configure -- --with-systemdsystemunitdir=no
+
 override_dh_auto_test:
dh_auto_test || (find . -name testsuite.log -exec cat {} \; ; false)

Bug#991328: closed by Thomas Ward ()

[Thomas Ward]

You are correct - bage@ saying this was fixed and should've been included in 
changelogs in the RFS threw me off.  The fix requires new commands and 
essentially 'functionality' added which is probably why it wasn't added in 
upstream.  I could've sworn I included this patch pre-upload but that might've 
been my fault that it didn't get included, which is also my fault.

I can either backport this, or we can wait for the next nginx stable release 
1.22 which should be coming "sometime soon" unless F5 has changed the 
development/release schedule.  In which case unmarking this as fixed and 
keeping it open is going to be necessary.  I believe we only track nginx stable 
(the even number releases) not mainline, which may have led to this.

I'll prep a backported patch, if it imports cleanly.  If it doesn't, we'll have 
to wait for 1.22 release of NGINX OSS.



Thomas


-Original Message-
From: Salvatore Bonaccorso  On Behalf Of 
Salvatore Bonaccorso
Sent: Wednesday, May 4, 2022 15:16
To: 991...@bugs.debian.org; Thomas Ward 
Cc: Moritz Mühlenhoff 
Subject: Re: Bug#991328 closed by Thomas Ward  ()

Control: reopen -1

Hi Thomas,

On Wed, May 04, 2022 at 04:45:03PM +, Debian Bug Tracking System wrote:
> Control: fixed -1 1.20.2-1
> 
> This is fixed in the 1.20.2 upload.  I forgot to add it to the 
> changelog before uploading to ftp-master though, whoops.  It's in the 
> process of building now in Unstable.

Are you sure about that? The commit
http://hg.nginx.org/nginx/rev/ec1071830799 does not seem to have landed in 
upstream 1.20.2 but only in 1.21.0 is implementing the mitigations?

Regards,
Salvatore

Bug#1010570: binaries in source without related source

[Antoine Beaupré]

On 2022-05-04 21:06:38, Tino Mettler wrote:
>> Am 04.05.2022 um 20:17 schrieb Antoine Beaupré :
>> 
>> On 2022-05-04 20:07:28, Tino Mettler wrote:
>>> Hi,
>>> 
>>> the upstream git repository has no release tags, so I guess that we
>>> have to drop uscan support and create the upstream source archive with
>>> a selfmade script.
>> 
>> we could lay down release tags ourselves if we can figure out what those
>> are... 
>
> Hi,
>
> that would be an option. I'm currently crafting a script that creates a 
> tarball. Just removing upgrade.py doesn't work, because it is referenced in 
> the translations and that will cause a build errors. Replacing it with an 
> empty file works, and should not affect Debian users.

maybe we could just use a +ds tarball then. add the files to redact in
debian/copyright and then uscan will just do the right thing for us, no
need to worry about the git stuff.

-- 
La guerre, c'est le massacre d'hommes qui ne se connaissent pas,
au profit d'hommes qui se connaissent mais ne se massacreront pas.
- Paul Valéry

Bug#991328: closed by Thomas Ward ()

[Salvatore Bonaccorso]

Control: reopen -1

Hi Thomas,

On Wed, May 04, 2022 at 04:45:03PM +, Debian Bug Tracking System wrote:
> Control: fixed -1 1.20.2-1
> 
> This is fixed in the 1.20.2 upload.  I forgot to add it to the changelog
> before uploading to ftp-master though, whoops.  It's in the process of
> building now in Unstable.

Are you sure about that? The commit
http://hg.nginx.org/nginx/rev/ec1071830799 does not seem to have
landed in upstream 1.20.2 but only in 1.21.0 is implementing the
mitigations?

Regards,
Salvatore

Bug#1010573: node-modern-syslog: FTBFS on mipsel

[Adrian Bunk]

Control: reassign -1 node-yaml 2.0.1-1
Control: retitle -1 node-yaml: Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package 
subpath './types' is not defined by "exports" in 
/usr/share/node_modules/yaml/package.json
Control: affects -1 src:node-modern-syslog src:node-tap-parser

On Wed, May 04, 2022 at 07:13:29PM +0200, Sebastian Ramacher wrote:
>...
> https://buildd.debian.org/status/fetch.php?pkg=node-modern-syslog=mipsel=1.2.0-3%2Bb1=1651678779=0
> 
> gyp info ok 
> make[1]: Leaving directory '/<>'
>dh_auto_test --buildsystem=nodejs -a
>   mkdir -p node_modules
>   ln -s ../. node_modules/modern-syslog
>   /bin/sh -ex debian/tests/pkg-js/test
> + tap --no-cov test/test-compat.js test/test-core.js test/test-openlog.js 
> test/test-setmask.js test/test-stream.js test/test-syslog.js
> node:internal/modules/cjs/loader:488
>   throw e;
>   ^
> 
> Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './types' is not 
> defined by "exports" in /usr/share/node_modules/yaml/package.json
> at new NodeError (node:internal/errors:371:5)
> at throwExportsNotFound (node:internal/modules/esm/resolve:453:9)
> at packageExportsResolve (node:internal/modules/esm/resolve:731:3)
> at resolveExports (node:internal/modules/cjs/loader:482:36)
> at Function.Module._findPath (node:internal/modules/cjs/loader:522:31)
> at Function.Module._resolveFilename 
> (node:internal/modules/cjs/loader:919:27)
> at Function.Module._load (node:internal/modules/cjs/loader:778:27)
> at Module.require (node:internal/modules/cjs/loader:1005:19)
> at require (node:internal/modules/cjs/helpers:102:18)
> at Object. 
> (/usr/share/nodejs/tap-yaml/lib/types/index.js:1:15) {
>   code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
> }
> dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1
> make: *** [debian/rules:13: binary-arch] Error 25

This is not specific to mipsel or node-modern-syslog:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-modern-syslog.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-tap-parser.html

I cannot judge which package is technically at fault, but the breakage 
is due to node-yaml 2.0.1-1.

> Cheers

cu
Adrian

Bug#1010570: binaries in source without related source

[Tino Mettler]

> Am 04.05.2022 um 20:17 schrieb Antoine Beaupré :
> 
> On 2022-05-04 20:07:28, Tino Mettler wrote:
>> Hi,
>> 
>> the upstream git repository has no release tags, so I guess that we
>> have to drop uscan support and create the upstream source archive with
>> a selfmade script.
> 
> we could lay down release tags ourselves if we can figure out what those
> are... 

Hi,

that would be an option. I'm currently crafting a script that creates a 
tarball. Just removing upgrade.py doesn't work, because it is referenced in the 
translations and that will cause a build errors. Replacing it with an empty 
file works, and should not affect Debian users.

Regards,
Tino

Bug#901952: fixing pristine-tar w.r.t. changed tar escaping

[Paul Gevers]

Hi all,

On Sun, 31 Mar 2019 03:13:28 +0200 "Bernhard R. Link" 
 wrote:

* Bernhard R. Link  [190330 07:58]:
> I'm looking into #901952 (pristine-tar failing to checkout out old files
> with non-printable unicode characters) and think that might be solved
> with the attached patches, by calling tar with --null and giving it
> a copy of the manifest file that is unescaped and NUL-terminated.
> 
> What I haven't looked into yet is whether it will break files

> generated with 1.46, as that the format incompatibly without
> changing the version of the delta (though perhaps that can be
> mitigated by an additional variant at checkout time).
> 
> What are your opinions on that? Is this worth trying to get into buster?


Attached version with some small fixes, more tests convering those
changes (and compatibility with previous versions), and an additional
variant run on checkout time to also handle files commited with 1.46.

Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


I'm pretty sure that the fix for bug #933031 (in pristine-tar) works 
around the issue. Shall we close this bug as won't fix?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#993660: firefox-esr: FTBFS and embeded copy of code

[Paul Gevers]

Control: tag -1 - ftbfs
Control: tag 993659 - ftbfs

Hi Bastien,

On Sat, 04 Sep 2021 11:46:35 + "=?utf-8?q?Bastien_Roucari=C3=A8s?=" 
 wrote:

Source: src:firefox-esr
Version: FTBFS and embdeded copy
Severity: serious
Tags: upstream ftbfs
Control: clone -1 -2
Control: affects -2 src:firefox


Did you intent to have -2 (this bug 993660) reassigned to src:firefox 
instead? Now these two bugs are just clones against the firefox-esr 
source package.


Also, ftbfs is used when the build fails, not when the build is not 
building all binary artifacts, we don't have a tag for that.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010577: RM: plastimatch [i386] -- NBS; Build dependency libinsighttoolkit5-dev is only available on amd64

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

plastimatch (1.9.3+dfsg.1-3) unstable; urgency=medium
...
  [ Andreas Tille ]
  * Switch (Build-)Depends from libinsighttoolkit4-dev to
libinsighttoolkit5-dev
...
 -- Étienne Mollier   Thu, 28 Apr 2022 12:28:28 +0200

Bug#1010576: akonadi-server: Akonadi/Kontact hangs after resuming from standby

[CH]

Package: akonadi-server
Version: 4:21.12.3-2
Severity: normal
X-Debbugs-Cc: gi...@leonde.de

Dear Maintainer,

kontact reliably gets unusable after resmuing from standby. I've been using
kontact for years, and I think this started with the update of KDE Framework to
5.90,
The UI is still responsive, but accessing mails or switching folders does not
have any effect. Switching to a different folder will display a progress page
and a spinning cog as the folder icon, but nothing else will ever happen, even
after hours. Quitting Kontact also doesn't work in this situation, I have to
kill it.

To get kontact working after resuming, I have to
- kill kontact
- stop akonadi
- kill mariadb
- start kontact

What does not help is:
- kill kontact
- start kontact
(same situation as before)

Neither:
- kill kontact
- stop akonadi
- start kontact

(This fails because akonadictl stop does not terminate mariadb. It does delete
the socket file though, so the new akonadi instance cannot talk to it).

Note that when kontact/akonadi hangs after resume, I can access mariadb just
fine. It's just that the chain mariadb <-> akonadi <-> kontact is somehow
broken.

Thanks!


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

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

Versions of packages akonadi-server depends on:
ii  akonadi-backend-mysql4:21.12.3-2
ii  libaccounts-qt5-11.16-2
ii  libc62.33-7
ii  libgcc-s112-20220428-1
ii  libkf5akonadiprivate5abi2 [libkf5akonadiprivate5-21.12]  4:21.12.3-2
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-21.12]  4:21.12.3-2
ii  libkf5configcore55.90.0-1
ii  libkf5coreaddons55.90.0-1
ii  libkf5crash5 5.90.0-1
ii  libkf5i18n5  5.90.0-1
ii  libqt5core5a 5.15.2+dfsg-16+b1
ii  libqt5dbus5  5.15.2+dfsg-16+b1
ii  libqt5gui5   5.15.2+dfsg-16+b1
ii  libqt5network5   5.15.2+dfsg-16+b1
ii  libqt5sql5   5.15.2+dfsg-16+b1
ii  libqt5widgets5   5.15.2+dfsg-16+b1
ii  libqt5xml5   5.15.2+dfsg-16+b1
ii  libstdc++6   12-20220428-1

akonadi-server recommends no packages.

Versions of packages akonadi-server suggests:
ii  akonadi-backend-mysql   4:21.12.3-2
pn  akonadi-backend-postgresql  
pn  akonadi-backend-sqlite  

-- no debconf information

Bug#1010575: qt6-base_6.2.4 QLibraryInfo path issue

[Steven Trabert]

Package: qt6-base
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
X-Debbugs-Cc: tstev...@gmail.com

Dear Maintainer,

   * What led up to the situation?
 The situation requires the dynamic loader to use symbolic links, like
 often is done on usr-merged systems.  It was previously fixed in Debian,
 but the required configuration parameter was dropped when converting
 from Qt5 configure to Qt6 cmake.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 An effective fix, that is widely used on Linux distributions, is to
 disable the relocatble feature when generating the build system.
   * What was the outcome of this action?
 Disabling the relocatable feature results in the correct paths being
 returned by QLibraryInfo, and Qt WebEngine finding it's resources.
   * What outcome did you expect instead?
 This was the desired outcome.

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

This patch is needed to fix paths on usr-merged systems like Ubuntu jammy.
Without this patch QLibraryInfo can return incorrect paths.  This can lead to
"Qt WebEngine resources not found", and a loss of functionality.  This patch
was previously applied to the Debain Qt5 package 5.14.2+dfsg-3 to closes:
#961554.  The issue is further discussed in
https://bugs.launchpad.net/ubuntu/+source/qt6-base/+bug/1970057



  * Make QLibraryInfo tolerant of symbolic links in loader search path
(LP: #1970057).


Thanks for considering the patch.


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

Kernel: Linux 5.15.0-27-generic (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru qt6-base-6.2.4+dfsg/debian/control qt6-base-6.2.4+dfsg/debian/control
--- qt6-base-6.2.4+dfsg/debian/control  2022-04-11 11:33:56.0 -0600
+++ qt6-base-6.2.4+dfsg/debian/control  2022-05-02 13:21:10.0 -0600
@@ -1,7 +1,6 @@
 Source: qt6-base
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Qt/KDE Maintainers 

+Maintainer: Debian Qt/KDE Maintainers 
 Uploaders: Patrick Franz 
 Build-Depends: cmake (>= 3.18~),
debhelper-compat (= 13),
diff -Nru qt6-base-6.2.4+dfsg/debian/rules qt6-base-6.2.4+dfsg/debian/rules
--- qt6-base-6.2.4+dfsg/debian/rules2022-04-11 11:32:44.0 -0600
+++ qt6-base-6.2.4+dfsg/debian/rules2022-05-02 13:20:45.0 -0600
@@ -71,6 +71,7 @@
-DFEATURE_system_png=ON \
-DFEATURE_system_libb2=ON \
-DFEATURE_rpath=OFF \
+   -DFEATURE_relocatable=OFF \
$(extra_cmake_args)
 
 

Bug#986590: Still reproducible

[Anton Gladky]

The bug is still reproducible. This time on armhf [1] and in CI [2].

[1] 
https://buildd.debian.org/status/fetch.php?pkg=dbus-test-runner=armhf=19.04.0-1%7Eexp1=1651644822=0
[2] https://salsa.debian.org/debian/dbus-test-runner/-/jobs/2731578

Regards

Anton

Bug#1010570: binaries in source without related source

[Antoine Beaupré]

On 2022-05-04 20:07:28, Tino Mettler wrote:
> Hi,
>
> the upstream git repository has no release tags, so I guess that we
> have to drop uscan support and create the upstream source archive with
> a selfmade script.

we could lay down release tags ourselves if we can figure out what those
are... 

Bug#1010570: binaries in source without related source

[Tino Mettler]

Hi,

the upstream git repository has no release tags, so I guess that we
have to drop uscan support and create the upstream source archive with
a selfmade script.

Regards,
Tino

Bug#1010570: binaries in source without related source

[Antoine Beaupré]

On 2022-05-04 19:29:24, Tino Mettler wrote:
> Am Wed, May 04, 2022 at 13:03:19 -0400 schrieb Antoine Beaupré:
>
> [...]
>
>> Maybe a solution that wouldn't involve upstream would be to change the
>> way we generate the tarball, from git instead of the upstream tarball.
>> 
>> After all, if we're going to rebuild thing from scratch ourselves
>> anyways...
>
> I also think that would be the way to go, as the upstream author is
> currently fighting with health issues.
>
> https://github.com/damonlynch/rapid-photo-downloader/issues/73#issuecomment-1117546807

Oh dear yeah, screw that. Let's not bother that poor upstream
already. :)

Let's make a new tarball with the upstream git repo instead, can you try
that?

Thanks!

a.

-- 
Any sufficiently advanced technology is indistinguishable from magic.
- Arthur C. Clarke

Bug#1010574: node-yaml: does not export as commonjs

[Jérémy Lal]

Package: node-yaml
Version: 2.0.1-1
Severity: important

Hi,

require('yaml')
doesn't work.

I'm available to sort this out, of course.


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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
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#1010573: node-modern-syslog: FTBFS on mipsel

[Sebastian Ramacher]

Source: node-modern-syslog
Version: 1.2.0-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=node-modern-syslog=mipsel=1.2.0-3%2Bb1=1651678779=0

gyp info ok 
make[1]: Leaving directory '/<>'
   dh_auto_test --buildsystem=nodejs -a
mkdir -p node_modules
ln -s ../. node_modules/modern-syslog
/bin/sh -ex debian/tests/pkg-js/test
+ tap --no-cov test/test-compat.js test/test-core.js test/test-openlog.js 
test/test-setmask.js test/test-stream.js test/test-syslog.js
node:internal/modules/cjs/loader:488
  throw e;
  ^

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './types' is not defined 
by "exports" in /usr/share/node_modules/yaml/package.json
at new NodeError (node:internal/errors:371:5)
at throwExportsNotFound (node:internal/modules/esm/resolve:453:9)
at packageExportsResolve (node:internal/modules/esm/resolve:731:3)
at resolveExports (node:internal/modules/cjs/loader:482:36)
at Function.Module._findPath (node:internal/modules/cjs/loader:522:31)
at Function.Module._resolveFilename 
(node:internal/modules/cjs/loader:919:27)
at Function.Module._load (node:internal/modules/cjs/loader:778:27)
at Module.require (node:internal/modules/cjs/loader:1005:19)
at require (node:internal/modules/cjs/helpers:102:18)
at Object. (/usr/share/nodejs/tap-yaml/lib/types/index.js:1:15) {
  code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}
dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1
make: *** [debian/rules:13: binary-arch] Error 25


Cheers
-- 
Sebastian Ramacher

Bug#955832: Simple removal of deps does not work

[Anton Gladky]

Unfortunately simple removal of dependency causes
build failures [1]. The patch is here [2].

[1] https://salsa.debian.org/debian/dbus-test-runner/-/jobs/2733096
[2] 
https://salsa.debian.org/debian/dbus-test-runner/-/commit/78d2155fdb2bc904471b910a37b5c9a4bc69c63a

Thanks

Anton

Bug#1010570: binaries in source without related source

[Antoine Beaupré]

On 2022-05-04 17:41:42, Tino Mettler wrote:
> Hi,
>
> the images used to generate qrc_resources.py are present in the
> upstream git repository, but not in the release tarballs. Once they are
> copied into the source directory of the Debian package,
> qrc_resources.py can be regenerated using pyrcc5 (the PyQT resource
> compiler).
>
> I opened an issue in the upstream git repository and described the
> nature of this bug.  I also asked if it is possible to provide signed
> release tarballs with the images included.

Maybe a solution that wouldn't involve upstream would be to change the
way we generate the tarball, from git instead of the upstream tarball.

After all, if we're going to rebuild thing from scratch ourselves
anyways...

Bug#1010556: undefined symbol extract_begin

[Louis-Philippe Véronneau]

Thanks for reporting this bug. I confirm I can reproduce it on my system
running unstable. Never caught it since I was running the poppler plugin.

I'll have a closer look at this in the coming days.

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

Bug#1010572: apt-cacher-ng: breaks deb.torproject.org

[Celejar]

Package: apt-cacher-ng
Version: 3.7.4-1~bpo11+1
Severity: normal
X-Debbugs-Cc: cele...@gmail.com

The upstream Tor Project repository,
https://deb.torproject.org/torproject.org, works when accessed directly,
but not when accessed via apt-cacher-ng:

Err:1 https://deb.torproject.org/torproject.org sid InRelease
  Certificate verification failed: The certificate is NOT trusted. The 
certificate issuer is unknown.  Could not handshake: Error in the certificate 
verification. [IP: xx.xx.xx.xx 3142]

I don't know if they're doing something wrong, or apt-cacher-ng is. I do
not know if this is related to:

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

but other third party repos using HTTPS and CNAMES (e.g.,
https://download.vscodium.com/debs) seem to work fine.

The Tor Project documentation:

https://support.torproject.org/apt/tor-deb-repo/

-- Package-specific info:

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

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

Versions of packages apt-cacher-ng depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.77
ii  dpkg 1.20.9
ii  libbz2-1.0   1.0.8-4
ii  libc-ares2   1.17.1-1+deb11u1
ii  libc62.31-13+deb11u3
ii  libevent-2.1-7   2.1.12-stable-1
ii  libevent-pthreads-2.1-7  2.1.12-stable-1
ii  libfuse2 2.9.9-5
ii  libgcc-s110.2.1-6
ii  liblzma5 5.2.5-2.1~deb11u1
ii  libssl1.11.1.1n-0+deb11u1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-7
ii  libwrap0 7.6.q-31
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2+deb11u1

Versions of packages apt-cacher-ng recommends:
ii  ca-certificates  20210119

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.8-5
pn  doc-base  

-- Configuration Files:
/etc/apt-cacher-ng/acng.conf changed [not included]
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information:
* apt-cacher-ng/tunnelenable: false
  apt-cacher-ng/gentargetmode: No automated setup
  apt-cacher-ng/proxy: keep
  apt-cacher-ng/port: keep
  apt-cacher-ng/cachedir: keep
  apt-cacher-ng/bindaddress: keep

Bug#1010558: jetty9: FTBFS An API incompatibility was encountered while executing org.apache.maven.plugins:maven-assembly-plugin

[Emmanuel Bourg]

Le 04/05/2022 à 13:10, Markus Koschany a écrit :


I have just discovered that jetty9 fails to build from source.

An API incompatibility was encountered while executing 
org.apache.maven.plugins:maven-assembly-plugin

Probably some recently upgraded reverse-dependency is to blame here.


Thank you for reporting the issue Markus, this is caused by an 
incompatibility in plexus-archiver/4.2.7-1. The fix will be uploaded soon.


Emmanuel Bourg

Bug#1006530: mariadb-10.6: FTBFS on x32: undefined reference to misc functions and files (regression from MariaDB 10.5)

[Otto Kekäläinen]

Thanks John for researching this!

Since you are close to solving it, would you like to finalize it by
submitting a MR at
https://salsa.debian.org/mariadb-team/mariadb-server?

https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian

Bug#1010488: win32-loader: please annotate the wine Build-Depends with

[Thomas Gaugler]

Fixed with the following commit:

Bug#1010131: RFS: md2term/0.0.7-1 [ITP] -- Markdown parser for highlights and colors in terminal

[Adam Borowski]

On Sun, Apr 24, 2022 at 08:44:17PM -0300, Braulio wrote:
>  * Package name: md2term
>Version : 0.0.7-1
>Upstream Author : https://codeberg.org/blau_araujo/md2term/issues
>  * URL : https://codeberg.org/blau_araujo/md2term

>   md2term - Markdown parser for highlights and colors in terminal

I'm afraid that, despite LANG=C.UTF-8, this program talks to me in some
heathen language I don't know.  Same for its man page...

Localized man pages are fine in /usr/share/man/es/ but I wouldn't expect
them in the default path.  The vast majority of users don't speak Spanish,
while using developer tools without a knowledge of English is a losing
proposition.

A tool for eg. filling Spanish tax forms would be reasonable to use entirely
a non-English language, but md2term is supposed to be useful to everyone.

If translating the program and/or making it locale-aware would be too hard
in the short term, I'd at least add a big fat warning in the description.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Eight legs good, four legs bad! -- when your drider pwns a
⣾⠁⢠⠒⠀⣿⡁ smelly goodie centaur.
⢿⡄⠘⠷⠚⠋⠀ Rearkick OP -- my grandpa's brother-in-law got one-shotted
⠈⠳⣄ from full hp in RL, please nerf!

Bug#1009196: [Dev-luatex] Bug#1009196: texlive-binaries: Reproducible content of .fmt files

[Roland Clobus]

On 04/05/2022 15:16, luigi scarso wrote:
On Wed, May 4, 2022 at 3:09 PM Roland Clobus 
On 19/04/2022 09:52, luigi scarso wrote:

Thank you very much for your patch, I will check it this weekend.

Have you found the time already to review my patch? [1]



Yes, Hans and I are discussing.
If possible, I would like to use a --reproducible switch at the command 
line.


Adding a commandline argument is sometimes proposed by the development 
teams, instead of using SOURCE_DATE_EPOCH. I would rather suggest to use 
SOURCE_DATE_EPOCH, which is already in the code base, instead of adding 
a new code path.


If you find the time, please read the documentation on SOURCE_DATE_EPOCH 
[1] and the page that mentions a checklist [2].


The short summary: SOURCE_DATE_EPOCH has been standardized and is 
primarily intended to be used by rebuilders of the binaries, not the 
developers or end-users.


In the past, when SOURCE_DATE_EPOCH was getting established, texlive 
additionally added FORCE_SOURCE_DATE=1. Nowadays, if it can be avoided, 
I would recommend to use only SOURCE_DATE_EPOCH.
See [3] for all uses of FORCE_SOURCE_DATE_ in Debian. As you can see, it 
is mainly used in several tests to ensure that packages have output that 
can be compared against a reference.


With kind regards,
Roland Clobus

[1] https://reproducible-builds.org/docs/source-date-epoch/
[2] 
https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables#Checklist

[3] https://codesearch.debian.net/search?q=FORCE_SOURCE_DATE=0


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010568: busco: missing dependencies on hmmer and prodigal

[Andreas Tille]

Control: tags -1 pending

Hi Andrius,

Am Wed, May 04, 2022 at 05:59:01PM +0300 schrieb Andrius Merkys:
> I have installed busco and attempted calculating coverage of a genome of
> interest:
> 
> $ busco -i GCA_000742995.1_ASM74299v1_genomic.fna -l
> xanthomonadales_odb10 -o xanthomonadales -m genome
> 
> busco first crashed due to missing hmmsearch executable, then, after
> installing hmmer, due to missing prodigal executable. I propose adding
> hmmer and prodigal as dependencies of busco.

Adding these is easy.  Would you mind adding either this fna file (or
some similar example) to the test suite enabling us to test that package
properly in autopkgtest?

(And feel free to do a team upload if you are in that mood.)

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#1010571: shotwell: No pubishing plugins available

[Neil McGovern]

Package: shotwell
Version: 0.30.15-1
Severity: important

Dear Maintainer,

When trying to publish some photos, shotwell complains that there aren't
any compatable publishing plugins enabled. Looking in Edit ->
Preferences -> Plugins, none appear.

From the terminal, the following errors occur:
(shotwell:257710): GLib-GIO-CRITICAL **: 16:14:53.825: g_file_get_child: 
assertion '!g_path_is_absolute (name)' failed
(shotwell:257710): GLib-GIO-CRITICAL **: 16:14:53.825: g_file_get_child: 
assertion 'G_IS_FILE (file)' failed
(shotwell:257710): GLib-GIO-CRITICAL **: 16:14:53.825: g_file_get_child: 
assertion 'G_IS_FILE (file)' failed
L 257710 2022-05-04 16:14:53 [CRT] plugins_search_for_plugins: assertion 
'G_TYPE_CHECK_INSTANCE_TYPE (dir, g_file_get_type ())' failed

https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1969439 may also
hold some clues.

Thanks,
Neil

-- Package-specific info:

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

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

Versions of packages shotwell depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.0-1
ii  dbus-x11 [dbus-session-bus]   1.14.0-1
ii  dconf-cli 0.40.0-3
ii  libc6 2.33-7
ii  libcairo-gobject2 1.16.0-5
ii  libcairo2 1.16.0-5
ii  libexif12 0.6.24-1
ii  libgcr-base-3-1   3.40.0-4
ii  libgcr-ui-3-1 3.40.0-4
ii  libgdata220.18.1-2
ii  libgdk-pixbuf-2.0-0   2.42.8+dfsg-1
ii  libgee-0.8-2  0.20.5-2
ii  libgexiv2-2   0.14.0-1
ii  libglib2.0-0  2.72.1-1
ii  libgphoto2-6  2.5.27-1
ii  libgphoto2-port12 2.5.27-1
ii  libgstreamer-plugins-base1.0-01.20.1-1
ii  libgstreamer1.0-0 1.20.1-1
ii  libgtk-3-03.24.33-1
ii  libgudev-1.0-0237-2
ii  libjson-glib-1.0-01.6.6-1
ii  libpango-1.0-01.50.6+ds-2
ii  libpangocairo-1.0-0   1.50.6+ds-2
ii  libraw20  0.20.2-2
ii  librsvg2-common   2.52.5+dfsg-3+b1
ii  libsoup2.4-1  2.74.2-3
ii  libsqlite3-0  3.38.2-1
ii  libunity9 7.1.4+19.04.20190319-6
ii  libwebkit2gtk-4.0-37  2.36.0-3+b1
ii  libxml2   2.9.13+dfsg-1+b1
ii  shotwell-common   0.30.15-1

shotwell recommends no packages.

shotwell suggests no packages.

-- no debconf information

-- 


signature.asc
Description: PGP signature

Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory

[Andreas Tille]

Hi Johannes,

Am Wed, May 04, 2022 at 04:12:49PM +0200 schrieb Johannes Schauer Marin 
Rodrigues:
> Quoting Andreas Tille (2022-05-04 16:07:27)
> > I'm an3as in IRC but I do not lurk in IRC usually.
> 
> Ah, nice word play in the nick. :)

I invented it at DebConf Argentina and Spanish speaking people get it
pretty easy. ;-)

> > Well, I think I could do this in the source only upload.  I just pushed that
> > change to Git[1] to make sure we will not forget this.
> 
> I think this should be a Breaks+Replaces with exactly version 3.6.7-1. There 
> is
> no reason to make libdcmtk17 not be co-installable with other versions of
> libdcmtk16, no? The file-conflict is only with libdcmtk16 (= 3.6.7-1).

Fixed in Git.
 
> > Roling back to dcmtk-3.6.7+really3.6.6 would remain an option anyway if this
> > will be more convenient for you.
> 
> Well, yes, it would be more convenient for me, but you are doing the work, so
> I'm not going to make any demands. :D I think the stronger reason to go roll
> back to dcmtk-3.6.7+really3.6.6 is, that Sebastian Ramacher as a release team
> member pointed out that they would prefer that option.

I think I'll go that route then (but probably tomorrow).  BTW, I had (again)
a look into ants and think the new upstream version can help to fix the
open RC bugs.  I once worked on this but at that point of time we did not
yet had insighttoolkit5.  Now the issue hopefully boiled down to some issue
I've reported upstream[1].

As a general remark:  The Debian Med team tries to take over and salvage
all NeuroDebian packages - but its quite some work in addition to the
many packages we just have.

Kind regards

 Andreas.

[1] https://github.com/ANTsX/ANTs/issues/1353

-- 
http://fam-tille.de

Bug#1010569: firejail: with the firefox profile, /etc/resolv.conf is not updated, making DNS resolution fail

[Vincent Lefevre]

On 2022-05-04 17:00:38 +0200, Vincent Lefevre wrote:
> I spent some time figuring why I could not connect to the SNCF
> wifi portal, and then, after connecting with another web browser,
> getting DNS failures. After looking at /etc/resolv.conf by joining
> the sandbox with a shell, I could see that it had not been updated
> after the switch to a different wifi network.

According to the upstream bug, the bug was introduced in July 2021,
which explains why I did not have such issues in the past.

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

Bug#1010570: binaries in source without related source

[Antoine Beaupre]

Package: rapid-photo-downloader
Version: 0.9.26-2
Severity: normal

I'm not sure about this, but it seems to me that `upgrade.py` and
`qrc_resources.py` ship binary data as source code.

This is normally a red flag in Debian packages, because source code
should typically be text file that are humanly understandable, or at
least usable with free software tools.

Basing myself on the excellent investigation done by Tino Mettler:

https://salsa.debian.org/debian/rapid-photo-downloader/-/merge_requests/2#note_307363

... i t seems like the `upgrade.py` file is fairly innocuous: it's
actually an encoded ZIP file that has .mo files generated from the
provided .po files. I'm not sure that needs to be removed, as there is
probably an obvious source for those.

The other file, `qrc_resources.py`, is more problematic. It bundles
binary data like images and those don't seem to have an associated
source in the source code. It's unclear if that file could be
redistributed as is, as it's clearly not modifiable, and would
possibly be a license violation.

It seems like the source images for that file are missing from the
upstream source as well, crucially. Normally, we should be able to
recompile that file from source, but because those images are missing,
it's not possible.

I'm not an expert on those issues as I used to be, so I'm not sure
about all this, but it seemed important to flag this as an issue on
the package.

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

Kernel: Linux 5.10.0-13-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 rapid-photo-downloader depends on:
ii  gir1.2-gexiv2-0.10 0.12.1-1
ii  gir1.2-glib-2.01.66.1-1+b1
ii  gir1.2-gstreamer-1.0   1.18.4-2.1
ii  gir1.2-gudev-1.0   234-1
ii  gir1.2-notify-0.7  0.7.9-3
ii  gir1.2-udisks-2.0  2.9.2-2+deb11u1
ii  gstreamer1.0-libav 1.18.4-3
ii  gstreamer1.0-plugins-good  1.18.4-2
ii  libgphoto2-6   2.5.27-1
ii  libimage-exiftool-perl 12.16+dfsg-2
ii  libmediainfo0v520.09+dfsg-2
ii  libqt5svg5 5.15.2-3
ii  python33.9.2-3
ii  python3-arrow  1.2.1-1
ii  python3-babel  2.8.0+dfsg.1-7
ii  python3-colour 0.1.5-2
ii  python3-dateutil   2.8.1-6
ii  python3-easygui0.98.1-1
ii  python3-gi 3.38.0-2
ii  python3-gphoto21.9.0-1+b2
ii  python3-gphoto2cffi [python3-gphoto2]  0.4.3~a1-1.1+b1
ii  python3-psutil 5.8.0-1
ii  python3-pymediainfo5.0.3-1
ii  python3-pyqt5  5.15.2+dfsg-3
ii  python3-requests   2.25.1+dfsg-2
ii  python3-sortedcontainers   2.1.0-2
ii  python3-tenacity   6.2.0-4
ii  python3-tornado6.1.0-1+b1
ii  python3-xdg0.27-2
ii  python3-zmq20.0.0-1+b1
ii  qt5-image-formats-plugins  5.15.2-2

Versions of packages rapid-photo-downloader recommends:
ii  libraw-bin  0.20.2-1

rapid-photo-downloader suggests no packages.

-- debconf-show failed

Bug#872741: ants: frequent test failures on amd64

[Andreas Tille]

Control: block -1 by 909833

-- 
http://fam-tille.de

Bug#909833: ants FTBFS with gcc 8

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/ANTsX/ANTs/issues/1353

Hi,

I've started checking whether we can save ants inside Debian.  The
Debian Med team tries to take over packages from NeuroDebian and take
over responsibility.  The situation of ants became better since
insighttoolkit5 became available but there is a remaining build issue
which was reported upstream.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#884710: ants: FTBFS: URL using bad/illegal format or missing URL

[Andreas Tille]

Control: block -1 by 909833


-- 
http://fam-tille.de

Bug#905417: ants: broken symlink: /usr/bin/jointfusion -> ../lib/ants/jointfusion

[Andreas Tille]

Control: block -1 by 909833

-- 
http://fam-tille.de

Bug#1010569: firejail: with the firefox profile, /etc/resolv.conf is not updated, making DNS resolution fail

[Vincent Lefevre]

Package: firejail
Version: 0.9.68-3
Severity: important
Tags: upstream security
Forwarded: https://github.com/netblue30/firejail/issues/5010
X-Debbugs-Cc: Debian Security Team 

I spent some time figuring why I could not connect to the SNCF
wifi portal, and then, after connecting with another web browser,
getting DNS failures. After looking at /etc/resolv.conf by joining
the sandbox with a shell, I could see that it had not been updated
after the switch to a different wifi network.

Note: With my config, I had no issues when switching to the wifi
hotspot of my phone, only with the SNCF wifi, probably because it
filters UDP (making unbound unusable).

In addition to DNS failures, this could be a security issue in case
the IP address of the DNS server was a local one, so that this IP
address could become the one of some random user on the new network.

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

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

Versions of packages firejail depends on:
ii  libapparmor1  3.0.4-2
ii  libc6 2.33-7
ii  libselinux1   3.3-1+b2

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.68-3
ii  iproute2   5.17.0-2
ii  iptables   1.8.7-1
ii  xauth  1:1.1.1-1
ii  xdg-dbus-proxy 0.1.3-1
ii  xpra   3.1-1+b5
ii  xvfb   2:21.1.3-2+b1

firejail suggests no packages.

-- no debconf information

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

Bug#1010568: busco: missing dependencies on hmmer and prodigal

[Andrius Merkys]

Package: busco
Version: 5.3.1-1

Dear Maintainer,

I have installed busco and attempted calculating coverage of a genome of
interest:

$ busco -i GCA_000742995.1_ASM74299v1_genomic.fna -l
xanthomonadales_odb10 -o xanthomonadales -m genome

busco first crashed due to missing hmmsearch executable, then, after
installing hmmer, due to missing prodigal executable. I propose adding
hmmer and prodigal as dependencies of busco.

Andrius

Bug#1010567: mirror listing update for fastmirror.pp.ua

[Ivan Barabash]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: fastmirror.pp.ua
Type: leaf
Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc 
ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Ivan Barabash 
Country: UA Ukraine




Trace Url: http://fastmirror.pp.ua/debian/project/trace/
Trace Url: http://fastmirror.pp.ua/debian/project/trace/ftp-master.debian.org
Trace Url: http://fastmirror.pp.ua/debian/project/trace/fastmirror.pp.ua

Bug#1010128: Workaround

[Benjamin Bänziger]

On Tue, 03 May 2022 09:06:50 + Stephan =?ISO-8859-1?Q?Verb=FCcheln?=
 wrote:

Quick and dirty workaround for broadcom-sta-dkms on kernel 5.17:


I can confirm that the broadcom-sta-dkms is compiling again after
applying the patch.

Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory

[Johannes Schauer Marin Rodrigues]

Quoting Andreas Tille (2022-05-04 16:07:27)
> I'm an3as in IRC but I do not lurk in IRC usually.

Ah, nice word play in the nick. :)

> > So it seems that the right way forward would be an upload of
> > dcmtk-3.6.7+really3.6.6.
> > 
> > And then not forgetting the Breaks+Replaces from libdcmtk17 on libdcmtk16 (=
> > 3.6.7-1)
> 
> Well, I think I could do this in the source only upload.  I just pushed that
> change to Git[1] to make sure we will not forget this.

I think this should be a Breaks+Replaces with exactly version 3.6.7-1. There is
no reason to make libdcmtk17 not be co-installable with other versions of
libdcmtk16, no? The file-conflict is only with libdcmtk16 (= 3.6.7-1).

> Roling back to dcmtk-3.6.7+really3.6.6 would remain an option anyway if this
> will be more convenient for you.

Well, yes, it would be more convenient for me, but you are doing the work, so
I'm not going to make any demands. :D I think the stronger reason to go roll
back to dcmtk-3.6.7+really3.6.6 is, that Sebastian Ramacher as a release team
member pointed out that they would prefer that option.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory

[Andreas Tille]

Hi,

Am Wed, May 04, 2022 at 03:34:43PM +0200 schrieb Johannes Schauer Marin 
Rodrigues:
> 
> I asked in #debian-release and Sebastian Ramacher writes:
> 
> 15:27 < Sebastinas> libdcmtk17 will also need Breaks+Replaces on the 
> libdcmtk16 version with the .so.17 files.
> 15:29 < Sebastinas> At least odil is involved in one ongoing transition, so 
> the binNMU for icu may have broken that.
> 15:29 < Sebastinas> I'd appreciate a revert.

I'm an3as in IRC but I do not lurk in IRC usually.

Its obvious that I did also this in a hurry.
 
> So it seems that the right way forward would be an upload of
> dcmtk-3.6.7+really3.6.6.
> 
> And then not forgetting the Breaks+Replaces from libdcmtk17 on libdcmtk16 (=
> 3.6.7-1)

Well, I think I could do this in the source only upload.  I just pushed
that change to Git[1] to make sure we will not forget this.  Roling back
to dcmtk-3.6.7+really3.6.6 would remain an option anyway if this will be
more convenient for you.

Kind regards

 Andreas.


[1] 
https://salsa.debian.org/med-team/dcmtk/-/commit/42df3f97b29e95646d2df5dc427cf03588664163

-- 
http://fam-tille.de

Bug#854714: trocla: FTBFS randomly (failing tests)

[Antoine Beaupré]

On 2019-04-08 12:43:21, Santiago Vila wrote:
> --- a/spec/trocla_spec.rb
> +++ b/spec/trocla_spec.rb
> @@ -66,12 +66,6 @@ describe "Trocla" do
>  expect(pwd.length).to eq(16)
>  expect(pwd).not_to match(/[={}\[\]\?%\*()&!]+/)
>end
> -  it 'is possible to combine profiles but first profile wins 3' do
> -pwd = @trocla.password('some_test','plain', 'profiles' => 
> ['mysql','login'])
> -expect(pwd).not_to be_empty
> -expect(pwd.length).to eq(32)
> -expect(pwd).to match(/[+%\/@=\?_.,:]+/)
> -  end
>  end
>end

I think a possibly more portable patch could be something like this,
what do you think?

diff --git i/spec/trocla_spec.rb w/spec/trocla_spec.rb
index 2826916..6fc263a 100644
--- i/spec/trocla_spec.rb
+++ w/spec/trocla_spec.rb
@@ -72,6 +72,7 @@
   expect(pwd).not_to match(/[={}\[\]\?%\*()&!]+/)
 end
 it 'is possible to combine profiles but first profile wins 3' do
+  skip
   pwd = @trocla.password('some_test3','plain', 'profiles' => 
['mysql','login'])
   expect(pwd).not_to be_empty
   expect(pwd.length).to eq(32)


That way if changes in the function are less likely to cause a conflict
and more likely to apply with fuzz... We could even give context for the
skip, I think, but my ruby is ... rare, and so is documentation on
rspec, IMHO.

a.

-- 
The United States is a nation of laws:
badly written and randomly enforced.
- Frank Zappa

Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory

[Johannes Schauer Marin Rodrigues]

Hi Andreas,

Quoting Andreas Tille (2022-05-04 14:57:25)
> > Will you take care of making sure that reverse dependencies are binNMU-ed?
> 
> I admit I would use the chance to to real team uploads and check the
> other dependencies manually.  Your finding with ant makes me suspicious
> about some of the other dependencies.  However, what do you think about
> asking ftpmaster for rejecting what is currently in new, re-upload 3.6.6
> to unstable and do a proper migration via experimental.  Currently the
> package is sitting in new and we have this chance.  Or do you think it
> is OK to force this "non-transition" somehow and leave things as they are
> now?  What does this mean from your blender perspective?

I asked in #debian-release and Sebastian Ramacher writes:

15:27 < Sebastinas> libdcmtk17 will also need Breaks+Replaces on the libdcmtk16 
version with the .so.17 files.
15:29 < Sebastinas> At least odil is involved in one ongoing transition, so the 
binNMU for icu may have broken that.
15:29 < Sebastinas> I'd appreciate a revert.

So it seems that the right way forward would be an upload of
dcmtk-3.6.7+really3.6.6.

And then not forgetting the Breaks+Replaces from libdcmtk17 on libdcmtk16 (=
3.6.7-1)

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1009196: [Dev-luatex] Bug#1009196: texlive-binaries: Reproducible content of .fmt files

[luigi scarso]

On Wed, May 4, 2022 at 3:09 PM Roland Clobus  wrote:

> Hello luigi, list,
>
> > On 19/04/2022 09:52, luigi scarso wrote: >> Thank you very much for your
> patch, I will check it this weekend.
> Have you found the time already to review my patch? [1]
>

Yes, Hans and I are discussing.
If possible, I would like to use a --reproducible switch at the command
line.

-- 
luigi

Bug#1009196: [Dev-luatex] Bug#1009196: texlive-binaries: Reproducible content of .fmt files

[Roland Clobus]

Hello luigi, list,


On 19/04/2022 09:52, luigi scarso wrote: >> Thank you very much for your patch, 
I will check it this weekend.

Have you found the time already to review my patch? [1]

With kind regards,
Roland Clobus

[1] https://mailman.ntg.nl/pipermail/dev-luatex/2022-April/006659.html


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory

[Andreas Tille]

Hi Johannes,

Am Wed, May 04, 2022 at 12:22:50PM +0200 schrieb Johannes Schauer Marin 
Rodrigues:
> Quoting Andreas Tille (2022-05-04 11:25:20)
> > Aaargh, sorry for my sloppyness.  I did not expect a SONAME bump connected
> > with micro-Version bump.  An updated package is in new.
> 
> thanks a lot for this very quick fix!

You are welcome and for sure I'm keen on fixing what I messed up before.
 
> I think the problem is that package-name-doesnt-match-sonames is overridden 
> and
> thus you didn't have Lintian tell you that there was a problem. That would've
> probably have happened to me as well.

Well, if I'm creating library packages I'm using d-shlibs which even
breaks at build time in these cases.  I would have even converted this
package right now, but this does not work since no static library is
build.  I admit I simply underestimated the number of dependencies
which I should habe checked.

> Will you take care of making sure that reverse dependencies are binNMU-ed?

I admit I would use the chance to to real team uploads and check the
other dependencies manually.  Your finding with ant makes me suspicious
about some of the other dependencies.  However, what do you think about
asking ftpmaster for rejecting what is currently in new, re-upload 3.6.6
to unstable and do a proper migration via experimental.  Currently the
package is sitting in new and we have this chance.  Or do you think it
is OK to force this "non-transition" somehow and leave things as they
are now?  What does this mean from your blender perspective?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#1010564: audacious-plugins: Add global hotkey plugin for Qt interface

[darutoko]

Package: audacious-plugins
Version: 4.1-2
Severity: wishlist

Dear Maintainer,

please add "qthotkey" plugin to this package. It will allow to use
Global Hotkeys with Qt interface version of the Audacious.

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

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

Versions of packages audacious-plugins depends on:
ii  audacious-plugins-data4.1-2
ii  libasound21.2.6.1-2+b1
ii  libaudcore5   4.1-2
ii  libaudgui54.1-2
ii  libaudqt2 4.1-2
ii  libaudtag34.1-2
ii  libavcodec58  7:4.4.2-1
ii  libavformat58 7:4.4.2-1
ii  libavutil56   7:4.4.2-1
ii  libbs2b0  3.1.0+dfsg-5
ii  libc6 2.33-7
ii  libcairo2 1.16.0-5
ii  libcddb2  1.3.2-7
ii  libcdio-cdda2 10.2+2.0.0-1+b2
ii  libcdio19 2.1.0-3
ii  libcue2   2.2.1-4
ii  libcurl3-gnutls   7.82.0-2
ii  libfaad2  2.10.0-2
ii  libflac8  1.3.4-1
ii  libfluidsynth32.2.5-1
ii  libgcc-s1 12-20220428-1
ii  libgdk-pixbuf-2.0-0   2.42.8+dfsg-1
ii  libgl11.4.0-1
ii  libglib2.0-0  2.72.1-1
ii  libgtk2.0-0   2.24.33-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.20~dfsg-1+b1
ii  liblirc-client0   0.10.1-6.3
ii  libmms0   0.6.4-3
ii  libmodplug1   1:0.8.9.0-3
ii  libmp3lame0   3.100-3
ii  libmpg123-0   1.29.3-1
ii  libneon27-gnutls  0.32.2-1
ii  libnotify40.7.11-2
ii  libogg0   1.3.4-0.1
ii  libopenmpt0   0.6.3-1
ii  libpango-1.0-01.50.6+ds-2
ii  libpangocairo-1.0-0   1.50.6+ds-2
ii  libpulse0 15.0+dfsg1-4
ii  libqt5core5a  5.15.2+dfsg-16+b1
ii  libqt5gui55.15.2+dfsg-16+b1
ii  libqt5multimedia5 5.15.2-3
ii  libqt5widgets55.15.2+dfsg-16+b1
ii  libsamplerate00.2.2-1
ii  libsdl2-2.0-0 2.0.22+dfsg-1
ii  libsidplayfp6 2.3.1-1
ii  libsndfile1   1.0.31-2
ii  libsndio7.0   1.8.1-1.1
ii  libsoxr0  0.1.3-4
ii  libstdc++612-20220428-1
ii  libvorbis0a   1.3.7-1
ii  libvorbisenc2 1.3.7-1
ii  libvorbisfile31.3.7-1
ii  libwavpack1   5.4.0-1
ii  libx11-6  2:1.7.5-1
ii  libxcomposite11:0.4.5-1
ii  libxml2   2.9.13+dfsg-1+b1
ii  libxrender1   1:0.9.10-1
ii  zlib1g1:1.2.11.dfsg-4

Versions of packages audacious-plugins recommends:
ii  audacious  4.1-2

audacious-plugins suggests no packages.

-- no debconf information

Bug#1008315: xpad: "segmentation fault xpad" on start

[Jeroen Ploemen]

Control: tags -1 - moreinfo + confirmed upstream
Control: forwarded -1 https://bugs.launchpad.net/xpad/+bug/1971568

> Attached is the gdb backtrace.

Thanks, that helped narrow things down. It appears the crash is
triggered by enabling the 'Use colors from theme' option (in xpad
prefs, under Layout).

To get the application to start again, rename or remove the settings
file ~/.config/xpad/default-style and things should work again as
long as you don't select the aforementioned option.


pgpIXV0O8gzV6.pgp
Description: OpenPGP digital signature

Bug#1010340: git: Fails to clone and pull from existign repositories

[Axel Beckert]

Control: severity -1 important

Hi Andrea,

Andrea Palazzi wrote:
> Turns out it'a Qemu issue: with -accel hax hardware acceleration I
> have this error, if I use -accel tcg it works without issues.

Interesting find, thanks for these details!

> I think this bug report can ble closed then.

Not sure, but it surely can be downgraded. Done so.

The question is (and I can't answer that) if Debian generally supports
running under these settings or if git has some (hopefully
deactivatable) optimizations which fail under these settings.

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

Bug#1010563: netdata: Add package for freeimpi plugin

[Ross Burton]

Package: netdata
Version: 1.29.3-4
Severity: wishlist

There is a freeimpi collector plugin:

https://learn.netdata.cloud/docs/agent/collectors/freeipmi.plugin

It would be useful if this was built.


-- 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-10-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages netdata depends on:
ii  netdata-core  1.29.3-4
ii  netdata-plugins-bash  1.29.3-4
ii  netdata-web   1.29.3-4

Versions of packages netdata recommends:
ii  netdata-plugins-nodejs  1.29.3-4
ii  netdata-plugins-python  1.29.3-4

netdata suggests no packages.

-- no debconf information

Bug#1010561: mirror listing update for fastmirror.pp.ua

[Ivan Barabash]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: fastmirror.pp.ua
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Ivan Barabash 
Country: UA Ukraine




Trace Url: http://fastmirror.pp.ua/debian/project/trace/
Trace Url: http://fastmirror.pp.ua/debian/project/trace/ftp-master.debian.org
Trace Url: http://fastmirror.pp.ua/debian/project/trace/fastmirror.pp.ua

Bug#1010560: emacs-gtk: after some time, middle-click pastes different contents from the primary selection

[Vincent Lefevre]

Package: emacs-gtk
Version: 1:27.1+1-3.1+b1
Severity: normal

I have an Emacs running, and a middle-click pastes text that is not
the primary selection (note: it is not the content of the clipboard
either, as seen with Ctrl-Y). Changing the primary selection by
selecting something else in an xterm does not solve this issue.
Running a different Emacs instance does not show this issue, thus
the bug is in Emacs and is visible under some unknown conditions.

I could eventually avoid the issue without restarting Emacs by
selecting some text in the running Emacs.

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

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

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common 1:27.1+1-3.1+b1
ii  emacs-common 1:27.1+1-3.1
ii  libacl1  2.3.1-1
ii  libasound2   1.2.6.1-2+b1
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.14.0-1
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.11.1+dfsg-2
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libgif7  5.2.1-2.4
ii  libglib2.0-0 2.72.1-1
ii  libgmp10 2:6.2.1+dfsg-3
ii  libgnutls30  3.7.4-2
ii  libgpm2  1.20.7-10
ii  libgtk-3-0   3.24.33-1
ii  libharfbuzz0b2.7.4-1+b1
ii  libice6  2:1.0.10-1
ii  libjansson4  2.14-2
ii  libjpeg62-turbo  1:2.1.2-1
ii  liblcms2-2   2.12~rc1-2
ii  libm17n-01.8.0-4
ii  libotf1  0.9.16-3
ii  libpango-1.0-0   1.50.6+ds-2
ii  libpng16-16  1.6.37-5
ii  librsvg2-2   2.52.5+dfsg-3+b1
ii  libselinux1  3.3-1+b2
ii  libsm6   2:1.2.3-1
ii  libsystemd0  250.4-1
ii  libtiff5 4.3.0-7
ii  libtinfo66.3+20220423-1
ii  libx11-6 2:1.7.5-1
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:6.0.0-1
ii  libxml2  2.9.13+dfsg-1+b1
ii  libxrender1  1:0.9.10-1
ii  zlib1g   1:1.2.11.dfsg-4

emacs-gtk recommends no packages.

Versions of packages emacs-gtk suggests:
ii  emacs-common-non-dfsg  1:27.1+1-2

-- no debconf information

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

Bug#1010559: Security updates don't need to have urgency=high

[Enrico Zini]

Package: developers-reference
Version: 11.0.21
Severity: normal
Tags: patch

Hello,

in this thread[1] it turned out that security updates don't need to have
urgency=high, so I'm attaching a patch that removes the mention.

[1] https://lists.debian.org/debian-lts/2022/05/msg7.html

Thanks,

Enrico

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

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

developers-reference depends on no packages.

Versions of packages developers-reference recommends:
ii  debian-policy4.5.1.0
ii  libjs-sphinxdoc  3.4.3-2
ii  sensible-utils   0.0.14

Versions of packages developers-reference suggests:
ii  chromium [www-browser] 101.0.4951.41-1~deb11u1
ii  doc-base   0.11.1
ii  firefox-esr [www-browser]  91.8.0esr-1~deb11u1
ii  w3m [www-browser]  0.5.3+git20210102-6

-- no debconf information
>From 9a80bb88199118bff99caa7278fffcb93dee430a Mon Sep 17 00:00:00 2001
From: Enrico Zini 
Date: Wed, 4 May 2022 13:23:28 +0200
Subject: [PATCH] Remove requirement that security uploads have urgency=high

It seems that this is obsolete and not relevant anymore. Details are in
this thread: https://lists.debian.org/debian-lts/2022/05/msg7.html
---
 source/pkgs.rst | 2 --
 1 file changed, 2 deletions(-)

diff --git a/source/pkgs.rst b/source/pkgs.rst
index 8665f99..1689fda 100644
--- a/source/pkgs.rst
+++ b/source/pkgs.rst
@@ -949,8 +949,6 @@ Be sure to verify the following items:
|codename-security| (e.g. |codename-stable-security|).
Do not target *distribution*\ ``-proposed-updates`` or ``stable``!
 
--  The upload should have **urgency=high**.
-
 -  Make descriptive, meaningful changelog entries. Others will rely on
them to determine whether a particular bug was fixed. Add ``closes:``
statements for any **Debian bugs** filed. Always include an external
-- 
2.30.2

Bug#1010558: jetty9: FTBFS An API incompatibility was encountered while executing org.apache.maven.plugins:maven-assembly-plugin

[Markus Koschany]

Package: jetty9
Version: 9.4.46-1
Severity: serious
X-Debbugs-Cc: a...@debian.org

Hi,

I have just discovered that jetty9 fails to build from source.

An API incompatibility was encountered while executing 
org.apache.maven.plugins:maven-assembly-plugin

Probably some recently upgraded reverse-dependency is to blame here.

Markus

Bug#1010557: src:zd1211-firmware: fails to migrate to testing for too long: non-free doesn't autobuild by default

[Paul Gevers]

Source: zd1211-firmware
Version: 1:1.5-7
Severity: serious
Control: close -1 1:1.5-8
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:zd1211-firmware has been trying to migrate 
for 61 days [2]. Hence, I am filing this bug. Your package is in the 
non-free part of the archive where packages don't get automatically 
build. Although I appreciate we normally upload source only, that 
doesn't happen by default work for non-free, albeit in some cases that 
can be "fixed" [3]. If [3] doesn't work for you, please upload a self 
built binary (you don't need to upload source in that case).


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=zd1211-firmware
[3] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010556: undefined symbol extract_begin

[Sven Bartscher]

Control: severity -1 grave

Hi,

I'm raising the severity of this to grave, since it renders the entire 
package qpdfview-pdf-mupdf-plugin unusable for its sole purpose of 
opening PDF files.


Regards
Sven

On Wed, 4 May 2022 12:17:04 +0200 Sven Bartscher  
wrote:

Package: qpdfview-pdf-mupdf-plugin
Version: 0.4.18-6
Severity: important


Hi,

opening PDFs using qpdfview-pdf-mupdf-plugin doesn't work for me. When I 
try to do it, qpdfview displays these error messages in the GUI:


Could not load plug-in for file type 'PDF'!

Could not open 'some.pdf'.

On the console I get the following more helpful messages:

$  LC_ALL=C qpdfview some.pdf
Could not load local plug-in: "/usr/bin/libqpdfview_pdf.so"
"The shared library was not found."
Could not load global plug-in: "/usr/lib/qpdfview/libqpdfview_pdf.so"
"The shared library was not found."
Could not load local plug-in: "/usr/bin/libqpdfview_fitz.so"
"The shared library was not found."
Could not load global plug-in: "/usr/lib/qpdfview/libqpdfview_fitz.so"
"Cannot load library /usr/lib/qpdfview/libqpdfview_fitz.so: 
(/usr/lib/qpdfview/libqpdfview_fitz.so: undefined symbol: extract_begin)"


Looks to me like libqpdfview_fitz.so is missing some dynamic linking 
dependency.


Regards
Sven

-- System Information:
Debian Release: bookworm/sid
   APT prefers testing-debug
   APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')

Architecture: amd64 (x86_64)

Kernel: Linux 5.17.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages qpdfview-pdf-mupdf-plugin depends on:
ii  libc62.33-7
ii  libgcc-s112-20220428-1
ii  libjbig2dec0 0.19-3
ii  libjpeg62-turbo  1:2.1.2-1
ii  libmujs1 1.1.3-4
ii  libopenjp2-7 2.4.0-6
ii  libqt5core5a 5.15.2+dfsg-16+b1
ii  libqt5gui5   5.15.2+dfsg-16+b1
ii  libqt5widgets5   5.15.2+dfsg-16+b1


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010471: [Pkg-javascript-devel] Bug#1010471: Bug#1010471: Bug#1010471: eslint: please move Recommends to Depends

[Jérémy Lal]

Le lun. 2 mai 2022 à 12:48, Jérémy Lal  a écrit :

>
>
> Le lun. 2 mai 2022 à 12:24, Jonas Smedegaard  a écrit :
>
>> Quoting Jérémy Lal (2022-05-02 11:59:15)
>> > Le lun. 2 mai 2022 à 11:54, Jonas Smedegaard  a écrit :
>> >
>> > > Quoting Jérémy Lal (2022-05-02 11:45:36)
>> > > > I stand by saying as it is, putting those packages:
>> > > > node-chalk
>> > > > node-strip-ansi
>> > > > node-text-table
>> > > > in Recommends just breaks the default functionality of eslint.
>> > >
>> > > Ignoring recommends breaks systems.
>> > >
>> >
>> > eslint is a build-dependency of enigmail (nothing odd about that).
>> > When sbuild builds a package, it doesn't install recommended packages
>> > of build-dependencies ?
>>
>> Correct: Build environments need recommendations explicitly declared as
>> build-dependencies, when needed.
>>
>
> I don't discuss the usefulness of Recommends.
>
> I'm trying to argue why in the particular case of eslint and of those
> three packages
> (mentioned above) you put in Recommends, it breaks eslint for other
> packages
> Build-Depending on eslint.
>
> Adding those Recommends in Build-Depends is not a good practice, IMO,
> for this reasons:
> - separation of concerns
> - Build-Depends eslint does not install Recommends resulting in a broken
> eslint
> - when some eslint recommends change, build-dependent packages will just
> break again !
> - worse (because undetectable) build-dependent packages will uselessly
> build-depend on
> no longer required packages.
>
> Is there a strong reason to put those three packages in Recommends ?
> The economy of installing three additional small packages is outweighed by
> the
> over-engineering needed to cope with it.
>

Because of that, I think it's desirable to ask for eslint maintainer (Jonas)
to also maintain packages Build-Depending on eslint... or at least, maintain
these packages's Build-Dependencies, because only the eslint maintainer
knows
what he meant to go in there, for eslint to work.

Jérémy

Bug#986709: rsnapshot is stable, not dead

[Christian Britz]

Dear maintainer,

could you please give some hints, why you actually think the package is
unmaintainable or whre we can find information about this? This would be
usefull for everyone considering to adopt it.

Bug#1010556: undefined symbol extract_begin

[Sven Bartscher]

Package: qpdfview-pdf-mupdf-plugin
Version: 0.4.18-6
Severity: important


Hi,

opening PDFs using qpdfview-pdf-mupdf-plugin doesn't work for me. When I 
try to do it, qpdfview displays these error messages in the GUI:


Could not load plug-in for file type 'PDF'!

Could not open 'some.pdf'.

On the console I get the following more helpful messages:

$  LC_ALL=C qpdfview some.pdf
Could not load local plug-in: "/usr/bin/libqpdfview_pdf.so"
"The shared library was not found."
Could not load global plug-in: "/usr/lib/qpdfview/libqpdfview_pdf.so"
"The shared library was not found."
Could not load local plug-in: "/usr/bin/libqpdfview_fitz.so"
"The shared library was not found."
Could not load global plug-in: "/usr/lib/qpdfview/libqpdfview_fitz.so"
"Cannot load library /usr/lib/qpdfview/libqpdfview_fitz.so: 
(/usr/lib/qpdfview/libqpdfview_fitz.so: undefined symbol: extract_begin)"


Looks to me like libqpdfview_fitz.so is missing some dynamic linking 
dependency.


Regards
Sven

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')

Architecture: amd64 (x86_64)

Kernel: Linux 5.17.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages qpdfview-pdf-mupdf-plugin depends on:
ii  libc62.33-7
ii  libgcc-s112-20220428-1
ii  libjbig2dec0 0.19-3
ii  libjpeg62-turbo  1:2.1.2-1
ii  libmujs1 1.1.3-4
ii  libopenjp2-7 2.4.0-6
ii  libqt5core5a 5.15.2+dfsg-16+b1
ii  libqt5gui5   5.15.2+dfsg-16+b1
ii  libqt5widgets5   5.15.2+dfsg-16+b1
ii  libstdc++6   12-20220428-1

qpdfview-pdf-mupdf-plugin recommends no packages.

qpdfview-pdf-mupdf-plugin suggests no packages.

-- no debconf information


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory

[Johannes Schauer Marin Rodrigues]

Hi Andreas,

Quoting Andreas Tille (2022-05-04 11:25:20)
> Aaargh, sorry for my sloppyness.  I did not expect a SONAME bump connected
> with micro-Version bump.  An updated package is in new.

thanks a lot for this very quick fix!

I think the problem is that package-name-doesnt-match-sonames is overridden and
thus you didn't have Lintian tell you that there was a problem. That would've
probably have happened to me as well.

Will you take care of making sure that reverse dependencies are binNMU-ed?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1010555: cloud-init - Fails to read generated Azure keys from metadata service

[Bastian Blank]

Package: cloud-init
Version: 20.4.1-2+deb11u1
Severity: important

cloud-init fails to read keys provided by the new metadata service
sometimes.  In those instances, stray \r\n are embedded and should be
stripped.

See https://bugs.launchpad.net/cloud-init/+bug/1910835

Bastian

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

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

Versions of packages cloud-init depends on:
ii  fdisk   2.38-4
ii  gdisk   1.0.9-1
pn  ifupdown
ii  isc-dhcp-client 4.4.2-P1-1+b1
ii  locales 2.33-7
ii  lsb-base11.1.0
ii  lsb-release 11.1.0
pn  net-tools   
ii  procps  2:3.3.17-7+b1
ii  python3 3.10.4-1
pn  python3-configobj   
ii  python3-jinja2  3.0.3-1
pn  python3-jsonpatch   
pn  python3-jsonschema  
pn  python3-netifaces   
ii  python3-oauthlib3.2.0-1
ii  python3-requests2.27.1+dfsg-1
ii  python3-yaml5.4.1-1+b1
ii  util-linux  2.38-4

Versions of packages cloud-init recommends:
pn  cloud-guest-utils  
pn  eatmydata  
ii  sudo   1.9.10-3

Versions of packages cloud-init suggests:
ii  btrfs-progs  5.16.2-1+b1
ii  e2fsprogs1.46.5-2
pn  xfsprogs 

Bug#1010552: texlive-lang-other: Execution of "latex ethiodoc.tex" raises errors at the occurrence of "{\eth :}".

[Hilmar Preuße]

Am 04.05.2022 um 09:08 teilte alberto mit:

Hi alberto,


Dear Maintainer,

In order to learn how to use "ethiop" I started by compiling the
ethiodoc.tex available in the doc.

However, the plain compilation gives errors at the occurrence of {\eth :}




IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource.


Consider to do this; we (Debian TeX maintainers) probably won't do so.

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory

[Andreas Tille]

Hi,

Am Wed, May 04, 2022 at 10:56:57AM +0200 schrieb Johannes Schauer Marin 
Rodrigues:
> > I'm going to rebuild all reverse dependencies and see if anything breaks
> > and report back to you in case I find any FTBFS caused by the new dcmtk
> > version.
> 
> the following source package build depend on libdcmtk-dev:
> 
> aeskulap, amide, ants, biosig, cmtk, dicomscope, elastix, insighttoolkit4,
> insighttoolkit5, itksnap, mia, odil, odin, openimageio, orthanc, orthanc-wsi,
> plastimatch
> 
> I cannot test insighttoolkit4 or insighttoolkit5 because my system lacks the
> resources to successfully build either source package (No space left on
> device).

This is really a hard one.
 
> ants FTBFS but is broken beyond repair and hasn't been in testing since 2017.

I'd vote for a removal of ants.
 
> itksnap FTBFS for for an unrelated reason (#1010549).
> 
> plastimatch FTBFS because of a missing build dependency on
> libinsighttoolkit5-dev: 
> https://buildd.debian.org/status/package.php?p=plastimatch
> 
> It seems the new dcmtk version did not just bump ABI but also changed its API
> (the DcmTransportLayerStatus enum including TCS_ok was removed from dcmlayer.h
> and defining INCLUDE_{CSTRING,CSTDLIB,CSTDIO} now raises an error), so some
> patches were necessary:
> 
> biosig: #1010545
> orthanc: #1010554
> 
> Mathieu, since you filed #1010474 (upgrading dcmtk to 3.6.7) could you help
> clean this up?

I wished some warning would have been added.  I'm not that involved into
those medical imaging tools and a deeply regret that I have messed up things
that heavily.

> For example maybe you find a solution to get orthanc to
> successfully compile again (I X-Debbugs-Cc-ed you on the last bug). Currently,
> the testsuite fails with:
> 
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libdcmdata.so: 
> undefined reference to symbol 'inflateEnd'
> /usr/bin/ld: /lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO 
> missing from command line
> collect2: error: ld returned 1 exit status
> 
> Which may be something that we have to fix in dcmtk?

Mathieu, could you say something about this?  Wouldn't it be better
to upload dcmtk-3.6.7+really3.6.6 and go a more sensible route?
 
> Note, that I'm not a Debian Med team member. I'm just putting my time here,
> because the last dcmtk upload broke blender (because it depends on 
> openimageio)
> which in turn hampers my work on the MNT Reform system image. So for me this 
> is
> just one big yak shave...

I can absolutely understand your situation.  Medical imaging is also
kind of yak shaving for me - well, may be re-shaving by updating
packages others prepared.  But obviously I'm trapping fully into wide
open pitfalls.

Sorry again to pull several people into this 
Andreas.


> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory

[Andreas Tille]

Control: tags -1 pending

Aaargh, sorry for my sloppyness.  I did not expect a SONAME
bump connected with micro-Version bump.  An updated package is
in new.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory

[Johannes Schauer Marin Rodrigues]

Hi,

On Tue, 03 May 2022 22:17:24 +0200 Johannes Schauer Marin Rodrigues 
 wrote:
> thanks for your upload of the new upstream version of dcmtk.  Unfortunately,
> I think this is missing a proper transition because the ABI and thus the
> SONAME changed. This can also be seen in the autopkgtests of biosig, odil and
> odin which all fail with a similar error right now:
> 
> biosig & odil: ImportError: libdcmdata.so.16: cannot open shared object file: 
> No such file or directory
> 
> odin: gencoil: error while loading shared libraries: libdcmimgle.so.16: 
> cannot open shared object file: No such file or directory
> 
> This is because the new upstream version bumped the SONAME from 16 to
> 17. This means, that the binary package name should also change from
> libdcmtk16 to libdcmtk17. This probably would've been caught by
> lintian if package-name-doesnt-match-sonames wasn't overridden in
> debian/libdcmtk16.lintian-overrides... :/
> 
> The package should've probably first been uploaded to experimental,
> would go through binary-NEW and create a auto-dcmtk transition. I'm
> unsure how to clean this up now that the package has already been
> uploaded to unstable.
> 
> I'm going to rebuild all reverse dependencies and see if anything breaks
> and report back to you in case I find any FTBFS caused by the new dcmtk
> version.

the following source package build depend on libdcmtk-dev:

aeskulap, amide, ants, biosig, cmtk, dicomscope, elastix, insighttoolkit4,
insighttoolkit5, itksnap, mia, odil, odin, openimageio, orthanc, orthanc-wsi,
plastimatch

I cannot test insighttoolkit4 or insighttoolkit5 because my system lacks the
resources to successfully build either source package (No space left on
device).

ants FTBFS but is broken beyond repair and hasn't been in testing since 2017.

itksnap FTBFS for for an unrelated reason (#1010549).

plastimatch FTBFS because of a missing build dependency on
libinsighttoolkit5-dev: 
https://buildd.debian.org/status/package.php?p=plastimatch

It seems the new dcmtk version did not just bump ABI but also changed its API
(the DcmTransportLayerStatus enum including TCS_ok was removed from dcmlayer.h
and defining INCLUDE_{CSTRING,CSTDLIB,CSTDIO} now raises an error), so some
patches were necessary:

biosig: #1010545
orthanc: #1010554

Mathieu, since you filed #1010474 (upgrading dcmtk to 3.6.7) could you help
clean this up? For example maybe you find a solution to get orthanc to
successfully compile again (I X-Debbugs-Cc-ed you on the last bug). Currently,
the testsuite fails with:

/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libdcmdata.so: 
undefined reference to symbol 'inflateEnd'
/usr/bin/ld: /lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO missing 
from command line
collect2: error: ld returned 1 exit status

Which may be something that we have to fix in dcmtk?

Note, that I'm not a Debian Med team member. I'm just putting my time here,
because the last dcmtk upload broke blender (because it depends on openimageio)
which in turn hampers my work on the MNT Reform system image. So for me this is
just one big yak shave...

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1006530: mariadb-10.6: FTBFS on x32: undefined reference to misc functions and files (regression from MariaDB 10.5)

[John Paul Adrian Glaubitz]

Hi!

> On Tue, 15 Mar 2022 15:22:15 +1100 Daniel Black  wrote:
>> The error is earlier in the logs:
>>
>> -- Looking for sched_getcpu - found
>> -- Could NOT find PMEM (missing: PMEM_LIBRARIES PMEM_INCLUDE_DIR)
>> CMake Error at storage/innobase/CMakeLists.txt:345 (MESSAGE):
>> WITH_PMEM=ON cannot be satisfied
>>
>> When the configure stage fails, the builds outputs the
>> CMakeOutput/Error logs to complement this error earlier in the logs.
>> In this case its not useful but other times it is.
>>
>> so the architecture test in debian/rules isn't right as it adds 
> WITH_PMEM=ON.
>>
> 
> WITH_PMEM=ON doesn't seem explicitly added to the options on x32, so I'm 
> wondering if WITH_PMEM=OFF shouldn't be added explicitly on 
> architectures where libpmem is not available/supported

The problem here is the use of DEB_HOST_ARCH_CPU which is "amd64" on x32. It
has to be DEB_HOST_ARCH. Changing it to DEB_HOST_ARCH fixes the problem for me.

For consistency, I would also fix the use here:

# Cross building requires stack direction instruction
ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
ifneq (,$(filter $(DEB_HOST_ARCH_CPU),alpha amd64 arm arm64 i386 ia64 m68k 
mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64))
CMAKEFLAGS += -DSTACK_DIRECTION=-1
endif
ifneq (,$(filter $(DEB_HOST_ARCH_CPU),hppa))
CMAKEFLAGS += -DSTACK_DIRECTION=1
endif
endif

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1010554: orthanc: FTBFS with dcmtk >= 3.6.7

[Johannes Schauer Marin Rodrigues]

Source: orthanc
Version: 1.10.1+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: jo...@debian.org, ma...@debian.org

Hi,

orthanc FTBFS with dcmtk 3.6.7 from unstable:

/<>/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp:110:118:
 error: ‘TCS_ok’ was
not declared in this scope
  110 |   if 
(tls->addTrustedCertificateFile(trustedCertificatesPath.c_str(), 
DCF_Filetype_PEM /*opt_keyFi
leFormat*/) != TCS_ok)
  |
   ^~
/<>/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp:116:104:
 error: ‘TCS_ok’ was
not declared in this scope
  116 |   if (tls->setPrivateKeyFile(ownPrivateKeyPath.c_str(), 
DCF_Filetype_PEM /*opt_keyFileFormat*/) !=
 TCS_ok)
  |
 ^~
/<>/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp:122:106:
 error: ‘TCS_ok’ was
not declared in this scope
  122 |   if (tls->setCertificateFile(ownCertificatePath.c_str(), 
DCF_Filetype_PEM /*opt_keyFileFormat*/)
!= TCS_ok)
  |
   ^~
/<>/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp:135:72:
 error: ‘TCS_ok’ was n
ot declared in this scope
  135 |   if (tls->setTLSProfile(TSP_Profile_BCP195 /*opt_tlsProfile*/) != 
TCS_ok)
  |
^~
/<>/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp:140:36:
 error: could not convert ‘DcmTLSTransportLayer::activateCipherSuites()()’ from 
‘OFCondition’ to ‘bool’
  140 |   if (tls->activateCipherSuites())
  |   ~^~
  ||
  |OFCondition
make[4]: *** [CMakeFiles/OrthancFramework.dir/build.make:1941: 
CMakeFiles/OrthancFramework.dir/<>/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp.o]
 Error 1


The attached debdiff fixes above problem but the testsuite still fails with:

[100%] Linking CXX executable UnitTests
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libdcmdata.so: 
undefined reference to symbol 'inflateEnd'
/usr/bin/ld: /lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO missing 
from command line
collect2: error: ld returned 1 exit status

Maybe this has to be fixed in dcmtk but I'm not sure. Because my patch
is not complete I'm not tagging this bug with patch.

Thanks!

cheers, josch
diff -Nru orthanc-1.10.1+dfsg/debian/changelog 
orthanc-1.10.1+dfsg/debian/changelog
--- orthanc-1.10.1+dfsg/debian/changelog2022-03-23 21:05:58.0 
+0100
+++ orthanc-1.10.1+dfsg/debian/changelog2022-05-04 10:13:08.0 
+0200
@@ -1,3 +1,10 @@
+orthanc (1.10.1+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * add patch to build with dcmtk >= 3.6.7 (closes: #XXX)
+
+ -- Johannes Schauer Marin Rodrigues   Wed, 04 May 2022 
10:13:08 +0200
+
 orthanc (1.10.1+dfsg-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru orthanc-1.10.1+dfsg/debian/patches/dcmtk-3.6.7 
orthanc-1.10.1+dfsg/debian/patches/dcmtk-3.6.7
--- orthanc-1.10.1+dfsg/debian/patches/dcmtk-3.6.7  1970-01-01 
01:00:00.0 +0100
+++ orthanc-1.10.1+dfsg/debian/patches/dcmtk-3.6.7  2022-05-04 
10:13:08.0 +0200
@@ -0,0 +1,40 @@
+--- a/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp
 b/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp
+@@ -107,19 +107,19 @@ namespace Orthanc
+ new DcmTLSTransportLayer(tmpRole /*opt_networkRole*/, NULL 
/*opt_readSeedFile*/,
+  OFFalse /*initializeOpenSSL, done by 
Orthanc::Toolbox::InitializeOpenSsl()*/));
+ 
+-  if (tls->addTrustedCertificateFile(trustedCertificatesPath.c_str(), 
DCF_Filetype_PEM /*opt_keyFileFormat*/) != TCS_ok)
++  if (tls->addTrustedCertificateFile(trustedCertificatesPath.c_str(), 
DCF_Filetype_PEM /*opt_keyFileFormat*/).bad())
+   {
+ throw OrthancException(ErrorCode_BadFileFormat, "Cannot parse PEM 
file with trusted certificates for DICOM TLS: " +
+trustedCertificatesPath);
+   }
+ 
+-  if (tls->setPrivateKeyFile(ownPrivateKeyPath.c_str(), DCF_Filetype_PEM 
/*opt_keyFileFormat*/) != TCS_ok)
++  if (tls->setPrivateKeyFile(ownPrivateKeyPath.c_str(), DCF_Filetype_PEM 
/*opt_keyFileFormat*/).bad())
+   {
+ throw OrthancException(ErrorCode_BadFileFormat, "Cannot parse PEM 
file with private key for DICOM TLS: " +
+ownPrivateKeyPath);
+   }
+ 
+-  if (tls->setCertificateFile(ownCertificatePath.c_str(), 
DCF_Filetype_PEM /*opt_keyFileFormat*/) != TCS_ok)
++  if (tls->setCertificateFile(ownCertificatePath.c_str(), 
DCF_Filetype_PEM /*opt_keyFileFormat*/).bad())
+   {
+ throw OrthancException(ErrorCode_BadFileFormat, "Cannot parse PEM 
file with own certificate for DICOM TLS: " +
+   

Bug#1004258: modem-manager-gui: segfaults on launch

[Graham Inggs]

Hi Matteo, Mykola

What make/model modem do you have?  I am unable to reproduce this with
a Huawei E3276.

Regards
Graham

Bug#1010553: transition: dlib

[Pierre Gruet]

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

Dear Release team,

I would like to request a transition slot for dlib, which has been accepted in
experimental and builds well inside. I changed the name of the binary lib
package after an ABI breakage.
The automatic ben file at
https://release.debian.org/transitions/html/auto-dlib.html
looks good.

Three reverse dependencies:
- seer
- plastimatch
- openturns
All of them build fine against the new package, so binNMU will be enough for
the three of them.

Best regards,

-- 
Pierre

Bug#1010485: plocate PRUNE_BIND_MOUNTS incompatible with btrfs subvolumes

[Julian Andres Klode]

On Tue, May 03, 2022 at 08:59:31PM +0200, Steinar H. Gunderson wrote:
> On Tue, May 03, 2022 at 07:59:48PM +0200, Julian Andres Klode wrote:
> > I fail to see how naming it @root instead of @, or @screwedup for that
> > matter makes a difference.
> 
> Try it. :-)

I tried something else...

> 
> > This is a significant regression for users coming from mlocate. They had
> > working locate
> 
> No, did they not. The mlocate updatedb code had broken bind mount detection
> after the switch from /etc/mtab to /proc/mountinfo, which specifically broke
> btrfs subvolumes:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746943
> 
> > If you prefer to keep plocate broken with btrfs in Debian,
> 
> Please stop misrepresenting the issue. plocate isn't broken with btrfs,
> but you can configure btrfs subvolumes in a way such that plocate
> (and basically any other tool that tries to skip bind mounts) will not work
> in the default configuration.

Removing the /mnt mount of the / root volume makes it work:

$ grep btrfs /proc/self/mountinfo
32 1 0:28 /@ / rw,relatime shared:1 - btrfs /dev/mapper/ubuntu--vg-root 
rw,compress=zstd:3,ssd,space_cache,subvolid=256,subvol=/@
143 32 0:28 /@apt /var/cache/apt/archives rw,relatime shared:79 - btrfs 
/dev/mapper/ubuntu--vg-root 
rw,compress=zstd:3,ssd,space_cache,subvolid=273,subvol=/@apt
146 32 0:28 /@squid /var/cache/squid-deb-proxy rw,relatime shared:81 - btrfs 
/dev/mapper/ubuntu--vg-root 
rw,compress=zstd:3,ssd,space_cache,subvolid=274,subvol=/@squid
142 32 0:28 /@log /var/log rw,relatime shared:83 - btrfs 
/dev/mapper/ubuntu--vg-root 
rw,compress=zstd:3,ssd,space_cache,subvolid=344,subvol=/@log
2734 32 0:28 /@/snap /snap rw,relatime shared:1 - btrfs 
/dev/mapper/ubuntu--vg-root 
rw,compress=zstd:3,ssd,space_cache,subvolid=256,subvol=/@
4560 32 0:28 /@/var/snap /var/snap rw,relatime shared:1 - btrfs 
/dev/mapper/ubuntu--vg-root 
rw,compress=zstd:3,ssd,space_cache,subvolid=256,subvol=/@
140 32 0:28 / /mnt rw,relatime shared:77 - btrfs /dev/mapper/ubuntu--vg-root 
rw,compress=zstd:3,ssd,space_cache,subvolid=5,subvol=/

It's not clar to me why that would make a difference but this is
all very confusing and needs further investigation. Like it only
reads mountinfo and stats / why would the existence of /mnt make
a difference to it - did it read "/" on the LHS and took it too mean
a bind mount of "/@" because "/@" is mounted at "/"? Clearly subvolumes
create confusing paths.

That /mnt mountpoint is anormal, but normally apt-btrfs-snapshot
mounts to a temporary directory temporarily to create a snapshot
(however they get leftover sometimes); whereas snapper uses a
different layout where / is the / and snapshots are kept in
/.snapshots or something, so it's not affected.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1010552: texlive-lang-other: Execution of "latex ethiodoc.tex" raises errors at the occurrence of "{\eth :}".

[alberto]

Package: texlive-lang-other
Version: 2021.20220204-1
Severity: normal

Dear Maintainer,

In order to learn how to use "ethiop" I started by compiling the
ethiodoc.tex available in the doc.

However, the plain compilation gives errors at the occurrence of {\eth :}



-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 alberto alberto 9334 Feb 18  2007 /home/alberto/texmf/ls-R
-rw-r--r-- 1 root root 2878 Apr 13 16:54 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Sep  4  2021 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Feb  4 23:04 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Feb  4 23:04 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Sep  4  2021 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Feb  4 23:04 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Feb  4 23:04 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3557 Mar 17 19:44 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Sep  2  2018 mktex.cnf
-rw-r--r-- 1 root root 475 Sep  4  2021 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 texlive-lang-other depends on:
ii  fonts-sil-padauk   5.000-3
ii  fonts-tlwg-garuda-otf  1:0.7.3-1
ii  fonts-tlwg-kinnari-otf 1:0.7.3-1
ii  fonts-tlwg-laksaman-otf1:0.7.3-1
ii  fonts-tlwg-loma-otf1:0.7.3-1
ii  fonts-tlwg-mono-otf1:0.7.3-1
ii  fonts-tlwg-norasi-otf  1:0.7.3-1
ii  fonts-tlwg-purisa-otf  1:0.7.3-1
ii  fonts-tlwg-sawasdee-otf1:0.7.3-1
ii  fonts-tlwg-typewriter-otf  1:0.7.3-1
ii  fonts-tlwg-typist-otf  1:0.7.3-1
ii  fonts-tlwg-typo-otf1:0.7.3-1
ii  fonts-tlwg-umpush-otf  1:0.7.3-1
ii  fonts-tlwg-waree-otf   1:0.7.3-1
ii  tex-common 6.17
ii  texlive-base   2021.20220204-1
ii  texlive-binaries   2021.20210626.59705-1

texlive-lang-other recommends no packages.

texlive-lang-other suggests no packages.

Versions of packages tex-common depends on:
ii  dpkg  1.21.7
ii  ucf   3.0043

Versions of packages tex-common suggests:
ii  debhelper  13.6

Versions of packages texlive-lang-other is related to:
ii  tex-common6.17
ii  texlive-binaries  2021.20210626.59705-1

-- no debconf information