Bug#1056764: grub-efi-amd64: can't boot with GRUB 2.12~rc1-12

[Mate Kukri]

Hello,

Just letting you know that the 2.12 merge is in progress, and GRUB
2.12 (non-rc1) will be available in Debian the (hopefully) not too
distant future.

Mate

On Fri, Jan 12, 2024 at 9:18 PM  wrote:
>
> Good day,
>
> does grub 2.12 (without rc1) help? There are a good pile of fixups
> between rc1 and release. E.g.
> https://git.savannah.gnu.org/cgit/grub.git/commit/?h=grub-2.12=1f5b180742ff2706bc3a696d115ddbc677ec75b9
> or
> https://git.savannah.gnu.org/cgit/grub.git/commit/?h=grub-2.12=67ae3981dc5113e5af3a0539174bcd7eab8f7722
> could help.
>
> Additionally, the ZFS fixes are needed to boot from volumes touched by
> ZFS 2.2 ( https://github.com/openzfs/zfs/issues/13873 ), so migrating to
> 2.12 is helpful in either case.
>
> Best regards,
> Michael Fritscher
>
> On Sat, 25 Nov 2023 17:36:41 -0500 Nicolas Haller
>  wrote:
> > Package: grub-efi-amd64
> > Version: 2.06-13
> > Severity: critical
> > Justification: breaks the whole system
> >
> > Dear Maintainer,
> >
> > My old laptop (Lenovo 11e) runs Sid and all was right before I updated
> > it the other day (I don't do that very often). After that upgrade, GRUB
> > wasn't able to load any kernel with the pretty much generic error
> > "Error: can't load image". The version of GRUB was 2.12~rc1-12.
> > If I try to boot again, GRUB tells me that I need to load the image
> > first (I guess it somehow ignores the linux command and sends that when
> > trying to load the initrd).
> >
> > I tried to reinstall grub, grub-install /dev/sda, update-grub, reinstall
> > the kernel, update-initramfs from the rescue mode but nothing worked.
> > The "file" command was able to read the vmlinuz file and none seemed
> > truncated. The system has one partition with both / and /boot and isn't
> > running out of space.
> > I did not see any error message during those operation besides GRUB
> > saying it wasn't able to update EFI parameters.
> >
> > I don't know if there is a way to get more logs or error message during
> > the boot explaining why it wasn't able to load the image.
> >
> > I tried to get the last version of GRUB from Bookworm, that is
> > 2.06-13, and now I'm able to boot. The kernel version did not change,
> >   the only change I did is to downgrade GRUB (and dependencies apt was
> >   asking for).
> >
> > I'm not sure which GRUB package I should use for reporting so I took the
> > one that seems the most specific to my system. Apologies if it is not
> > correct.
> >
> > Let me know if you need more info.
> >
> > Thanks,
> >
> > --
> > Nicolas Haller
> >
> > *** Reporter, please consider answering these questions, where appropriate 
> > ***
> >
> >* What led up to the situation?
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >* What was the outcome of this action?
> >* What outcome did you expect instead?
> >
> > *** End of the template - remove these template lines ***
> >
> >
> > -- Package-specific info:
> >
> > *** BEGIN /proc/mounts
> > /dev/sda2 / ext4 rw,relatime,errors=remount-ro 0 0
> > /dev/sda1 /boot/efi vfat 
> > rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
> >  0 0
> > *** END /proc/mounts
> >
>
> ___
> Pkg-grub-devel mailing list
> pkg-grub-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-grub-devel

Bug#1033112: CVE bugs in commonmark

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 Jeroen Ooms 

Hi Jeroen,

I'd like to bring some bugs to your attention that were filed against
the Debian packaged commonmark.  All these bugs got at least one CVE bug
number:

  https://bugs.debian.org/1033112  CVE-2023-22483 CVE-2023-22484 CVE-2023-22485 
CVE-2023-22486
  https://bugs.debian.org/1034173  CVE-2023-26485 CVE-2023-2482
  https://bugs.debian.org/1041099  CVE-2023-37463

It might perfectly be the case that you even have dealt with those
issues but it would be great if you could mention those fixed issues in
some changelog document to let us know we can close the according
Debian bugs.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1060807: zfp: please compile zfp with -DBIT_STREAM_WORD_TYPE=uint8

[Antonio Valentino]

Dear Frederic,

On Sun, 14 Jan 2024 18:53:02 +0100 
=?utf-8?q?Picca_Fr=C3=A9d=C3=A9ric-Emmanuel?=  wrote:

Source: zfp
Severity: important

Dear Maintainer,

since the upload of zfp 1.0.1, the test of hdf5plugin are failing

look at here

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

It seems to me that the zfp library should be recompile with the previous flag.

thanks

Frederic.


PS: Il also recompiled locally h5z-zfp and now the unit test is also failling 
with these errors

H5Dcreate failed at line 405, errno=2 (No such file or directory)
 [ESC[31;01mFAILEDESC[0m]
./test_write_plugin zfpmode=2 prec=16 ...HDF5-DIAG: Error 
detected in HDF5 (1.10.10) thread 1:
  #000: ../../../src/H5D.c line 140 in H5Dcreate2(): unable to create dataset
major: Dataset
minor: Unable to initialize object


[CUT]


  #011: ../../../src/H5Z.c line 852 in H5Z__prepare_prelude_callback_dcpl(): 
unable to apply filter
major: Data filters
minor: Error from filter 'can apply' callback
  #012: ../../../src/H5Z.c line 753 in H5Z__prelude_callback(): error during 
user callback



the configuration of ZFP was changed in order to be able to run the ZFP 
automatic test suite.
Apparently, the test code assumes `BIT_STREAM_WORD_TYPE=uint64` (see 
also [1]).

If I revert the change I will need to disable many the ZFP tests.
Apparently the problem seems to be linked to specific testing code bot 
on the ZFP and the python-hdf5plugin side.
Honestly I cannot say what is the more appropriate configuration for 
`BIT_STREAM_WORD_TYPE`.


How do you propose to proceed?


[1] https://github.com/LLNL/zfp/issues/51

kind regards
--
Antonio Valentino

Bug#1043532: Forwarded upstream: r-bioc-rhdf5: autopkgtest fails on s390x: 64-bit integer attributes are not read correctly

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/grimbough/rhdf5/issues/138


-- 
http://fam-tille.de

Bug#1060830: ITP: gpu-burn -- Multi-GPU CUDA stress test

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: gpu-burn
  Version : 0+git20240115+ds
  Upstream Authors: Ville Timonen
  URL : https://github.com/wilicc/gpu-burn
* License : BSD-2-clause
  Description : Multi-GPU CUDA stress test
 This allows you to run a stress test on your GPUs. Memory usage can
 be controlled by absolute number or percentage. Also allows to run
 on specific GPU, useful if you have mixed multi GPU system.

Bug#747824: RFP: atom -- hackable editor

[Otto Kekäläinen]

Control: outlook -1 Superseded by Pulsar ITP #1060778

Seems there was a lot of interest in this Atom ITP. I just wanted to
let you know that I filed an ITP[1] for packaging Pulsar, which
superseded Atom[2].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060778
[2] https://optimizedbyotto.com/post/pulsar-best-text-file-and-code-editor/

Bug#1060829: fricas: please add support for loong64

[wuruilong]

Source: fricas
Version: 1.3.8-8
Severity: normal
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

Please refer to the attached patch to support the loong64 arch.

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 fricas (1.3.8-8) unstable; urgency=medium
 .
   * rewrite strcpy lines in sockio-c.c to work around fortify object size
 detection bug.  As previously written, size available in pad was
 incorrectly calculated as 14.
Author: Camm Maguire 

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By: 
Last-Update: 2024-01-15

--- fricas-1.3.8.orig/config/config.guess
+++ fricas-1.3.8/config/config.guess
@@ -964,6 +964,9 @@ EOF
 k1om:Linux:*:*)
echo "$UNAME_MACHINE"-unknown-linux-"$LIBC"
exit ;;
+loongarch64:Linux:*:*)
+   echo "$UNAME_MACHINE"-unknown-linux-"$LIBC"
+   exit ;;
 m32r*:Linux:*:*)
echo "$UNAME_MACHINE"-unknown-linux-"$LIBC"
exit ;;
--- fricas-1.3.8.orig/config/config.sub
+++ fricas-1.3.8/config/config.sub
@@ -265,6 +265,7 @@ case $basic_machine in
| k1om \
| le32 | le64 \
| lm32 \
+| loong64 | loongarch64 \
| m32c | m32r | m32rle | m68000 | m68k | m88k \
| maxq | mb | microblaze | microblazeel | mcore | mep | metag \
| mips | mipsbe | mipseb | mipsel | mipsle \

Bug#702162: RFP: estonianidcard -- Metapackage installing all the packages for Estonian ID card support

[Otto Kekäläinen]

Hi!

On a quick review of the deb packages offered at
https://www.id.ee/en/article/install-id-software/ and the related
source code https://github.com/open-eid and documentation
https://open-eid.github.io/ I did not spot any reason why it could not
be properly packaged for Debian officially.

If this RFP had more +1's I might do it.

Are there enough Debian/Ubuntu users in Estonia to justify the effort?

Bug#842420: Status of packaging Electron?

[Otto Kekäläinen]

Hi!

I am a big fan of Pulsar[1] so I filed the ITP[2] for it which led me
to dive into the status of Electron[3] and NodeJS and JavaScript in
Debian in general.

Electron seems already to be shipped[4] among others in FreeBSD ports,
Arch, Manjaro, Nix and OpenSUSE, but not in Fedora or Debian. The
approach in Debian seems to be that each npm module is converted into
a deb package, and thus the JS team has 1700+ packages to maintain[5].
Electron packaging has been pending for the past 7 years due to this
packaging dependency requirement I assume.

So I guess the logical next step is just to map out all dependencies
of Electron (and Pulsar) and then simply get each npm module they
depend on packaged one-by-one?

Can somebody who has a working setup of js_task_edit.py[6] update the
Electron wiki page and also create a new one for Pulsar?

And once we have the list we can start using npm2deb[7] and following
the NodeJS packaging guide[8] we just package the modules and see how
far we get with reasonable effort?

- Otto

[1] https://optimizedbyotto.com/post/pulsar-best-text-file-and-code-editor/
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060778
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842420
[4] https://repology.org/project/electron/versions
[5] 
https://qa.debian.org/developer.php?login=pkg-javascript-de...@lists.alioth.debian.org
[6] https://wiki.debian.org/Javascript/Nodejs/Tasks
[7] https://wiki.debian.org/Javascript/Nodejs/Npm2Deb
[8] https://wiki.debian.org/Javascript/Nodejs/Manual

Bug#1060828: xsecurelock new release available

[Edgar Yllescas]

Package: xsecurelock
Version: 1.5.1-1
Severity: normal

version 1.9.0 was released last month but the debian package tracker is unable
to find the new release, it may be caused by the upstream decision of adding
the "v" prefix to the version number or some change to github's url format,
please consider taking the time to update the package in the debian repos to
the latest upstream as the releases since 1.5.1 have added bug fixes and
features that would result appreciated on systems running xsecurelock.

regards and have a great day.


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 6 (excalibur/ceres)
Release:6
Codename:   excalibur ceres
Architecture: x86_64

Kernel: Linux 6.6.8-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages xsecurelock depends on:
ii  dash   0.5.12-6
ii  libc6  2.37-13
ii  libpam0g   1.5.2-9.1
ii  libx11-6   2:1.8.7-1
ii  libxcomposite1 1:0.4.5-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxft22.3.6-1
ii  libxmuu1   2:1.1.3-3
ii  libxrandr2 2:1.5.2-2+b1
ii  libxss11:1.2.3-1
ii  x11-xserver-utils  7.7+10

xsecurelock recommends no packages.

Versions of packages xsecurelock suggests:
ii  mplayer  2:1.5+svn38446-1
ii  mpv  0.37.0-1
pn  xscreensaver-data
pn  xscreensaver-data-extra  
pn  xscreensaver-gl  
pn  xscreensaver-gl-extra

-- no debconf information

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Helmut Grohne]

On Sun, Jan 14, 2024 at 06:36:29PM +0100, Francesco Poli wrote:
> Of course, I have!   ;-)
> 
> For privacy reasons: I don't want other users to be able to enter my
> home directory and to read any file within it that I might have
> forgotten with world-readable permissions!

I agree that this is good practice. It's just that working with
namespaces tends to make this annoying. We're still in search for a more
satisfying solution. For now, I'm happy to have identified the cause of
your failure.

> the final touches to sid_amd64.img will be put with the file in its
> intended destination directory, which is /home/${USER}/mysubdir, since
> the command-line argument was "sid_amd64.img", a relative path to a
> file directly within the current working directory (~/mysubdir).

That command that fails is mkfs.ext4. This command is run inside the
user namespace that mmdebstrap creates for constructing the chroot. The
uids 0 to 65535 inside the user namespace correspond to your first
subuid range that is large enough. The mkfs.ext4 operation is performed
by the root user inside the user namespace. In the initial namespace
that root user is your first subuid. In particular, it is not your user
but a different user and this user has no permission to access your
output image.

> And these final touches require all parent directories (up to the root
> directory) to be world-executable.

Technically speaking, this is a sufficient but not strictly necessary
precondition. What we actually needs is your first subuid to be able to
open the output image for writing. This is difficult to achieve. The
method implemented in mmdebstrap-autopkgtest-build-qemu is to
temporarily change the ownership of the output image to the first
subuid. While chown is normally a privileged operation, you can chown
inside your namespace if both the original owner and the new owner are
mapped inside your user namespace. This is not the case for the
namespace that mmdebstrap creates, but before calling mmdebstrap, we
construct another namespace suitable for performing this chown.

What we don't do is adjust the permission of leading directory
components. The ability for opening the output image depends on both the
final component having a +w bit in an appropriate place (and since we
care fully chose the owner this is u+w) and leading directory components
being +x (and since these are neither owned by the first subuid nor the
first subgid, it amounts to o+x).

> In other words, the user would need:
> 
>   $ stat -c "%a %n" ~/mysubdir ~ /home /
>   771 /home/${USER}/mysubdir
>   701 /home/${USER}
>   755 /home
>   755 /
> 
> rather than:
> 
>   $ stat -c "%a %n" ~/mysubdir ~ /home /
>   770 /home/${USER}/mysubdir
>   700 /home/${USER}
>   755 /home
>   755 /
> 
> Is that correct?
> Or am I completely off-track?

This is one way to establish the actual precondition. Let me suggest
some alternatives. One is storing the output image outside $HOME. If you
put it into /tmp and the move it from /tmp into your home, that should
work as well. Another is using ACLs. You might add an ACL that
specifically grants your subuid range execute permission on your home
but not every user.

The available options to improve this are not super nice. A simple
workaround is creating the output image as a temporary file inside the
namespace and then copying it out. This will perform a 1GB copy
operation that we'd like to avoid (and rather construct the filesystem
in-place) for performance reasons, but maybe usability beats
performance? I'm also not sure how mmdebstrap downloads sparse files. It
might make them un-sparse and that'd be quite bad for this use case as
you'd write 25GB of zeros. Another option could be using fuse. In
principle, we could have a fuse driver running in the initial namespace
that just serves the output image. Then inside the namespace we could
mount this fuse filesystem (which becomes a regular file, not a
directory) and write to it. Having the fuse driver run in one namespace
and the fuse mount in a different namespace resolves the permission
problem. This is all non-trivial to implement though. The plumbing isn't
up to the task. Maybe there are other options that I don't see at this
time?

> It looks like it worked, but, unfortunately, it (again) fails to be
> usable with autopkgtest:
> 
>   $ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out  --summary 
> ./${SRCPKG}_autopkgtest.summary --apt-upgrade -B ./${SRCPKG}_amd64.changes -- 
> qemu --overlay-dir /dev/shm ~/Downloads/sid_amd64.img
>   autopkgtest [18:24:23]: starting date and time: 2024-01-14 18:24:23+0100
>   autopkgtest [18:24:23]: version 5.32
>   autopkgtest [18:24:23]: host ${HOST}; command line: /usr/bin/autopkgtest 
> --output-dir './${SRCPKG}_autopkgtest.out' --summary 
> './${SRCPKG}_autopkgtest.summary' --apt-upgrade -B 
> './${SRCPKG}_amd64.changes' -- qemu --overlay-dir /dev/shm 
> ${HOME}/Downloads/sid_amd64.img
>   qemu-system-x86_64: terminating on signal 15 from pid 

Bug#1060827: hxtools has an undeclared file conflict on /usr/bin/xmlformat

[Helmut Grohne]

Package: hxtools
Version: 20231224-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + xmlformat-perl xmlformat-ruby

hxtools has an undeclared file conflict. This may result in an unpack
error from dpkg.

The file /usr/bin/xmlformat is contained in the packages
 * hxtools/20231224-1 as present in unstable
 * xmlformat-perl
   * 1.04-2.1 as present in bullseye
   * 1.04-3 as present in bookworm|trixie|unstable
 * xmlformat-ruby
   * 1.04-2.1 as present in bullseye
   * 1.04-3 as present in bookworm|trixie|unstable

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1030223: gobject-introspection: make cross-compilation possible

[Helmut Grohne]

Hi Simon,

On Sun, Jan 14, 2024 at 02:30:54PM +, Simon McVittie wrote:
> I'm testing an implementation of that. arch-test needs specific
> porting for each new architecture because of how it's written,
> so I'm not intending to use that directly, but it's easy to add a
> precompiled arch-test-like binary of the host architecture to the
> gobject-introspection binary package, and have the wrapper script try
> to invoke it and see what happens.

Thank you!

> Right - if we decide that qemu is not so good for some pair of (real,
> emulated) architectures, and actually we'd prefer to use some other
> user-space emulator like FEX or box86 for a particular pair, I don't
> want to have to make new sourceful changes in all 238 source packages[1]
> that produce public GIR/typelibs, plus however many packages produce
> private GIR/typelibs. It seems like it would be better to only change
> src:gobject-introspection and O(1) other packages.

You definitely managed to convince me that having the dependency on
gobject-introspection itself is preferrable.

> If the cross-toolchain team implements such a thing, it would be fine to
> add it as an alternative dependency in a later version. I'd prefer not to
> do that while it's still hypothetical, because until there's a concrete
> implementation we'd have no way to test it.

The draft on how this might work sounds quite nice. Of course, the devil
is in the detail, but my takeaway here is that there is a relatively
easy way forward for extending this mechanism to avoid a lock-in on
qemu and that extension does not require uploading tons of packages. My
fear was that your qemu dependency would make us inflexible for
extending it in future, but you successfully argued that it is actually
the other way round. For the reasons you give, I agree that going with
the direct qemu dependency is a good way to do it now.

> Another option (which could perhaps be combined with this) would be for
> the cross-toolchain team to define an interface to "the preferred way to
> run executables from architecture A if they can't be run directly", and
> then gobject-introspection could try that in preference to qemu. Meson
> calls this an "EXE wrapper", which seems like as good a name as any other.

Please allow me to defer this. I think we'll end up with a better
interface if we can gain experience with the moving parts in practice.
Your way of extending gobject-introspection will yield this experience
and hopefully we'll encounter another user of this scheme (again hard
coding qemu initially). And then, I hope to remember reading this
excellent mail of yours with that gained experience.

> - For the trivial case, cross-exe-wrapper-TUPLE:ARCH, where TUPLE and
>   ARCH match, contains a /usr/bin/TUPLE-exe-wrapper which just runs its
>   arguments as-is
>   (like a trivial shell script that just does an 'exec "$@"')

I am thinking that perhaps this exe-wrapper could try forwarding to a
location in /etc (that normally does not exist) first and then fall back
to the behavior you describe. That way an administrator may supply an
external exe-wrapper and thus configure the wrapping for the entire
chroot solving the choice part that I took issue with.

> For the gobject-introspection use-case it would be possible to skip the
> cross-exe-wrapper package name and make g-i depend directly on
> cross-exe-wrapper-${local:DEB-HOST-GNU-TYPE}, but I think we would need
> the intermediate package name anyway if you want to be able to add
> Build-Depends: cross-exe-wrapper , for use-cases where the upstream
> build system will invoke TUPLE-exe-wrapper itself.

Yes. Please move forward with what you have without waiting for your
sketched cross-exe-wrapper machinery to appear.

> A Lintian check could make sense, perhaps? It could have a table of
> package names that should not be directly (build-)depended on, each with
> its allowed exceptions if any, for example:
> 
> gobject-introspection-%-endian src:gobject-introspection
> gobject-introspection-bin src:gobject-introspection
> libmutter% src:budgie-desktop src:gnome-remote-desktop src:gnome-shell 
> src:mutter
> liburweb0 src:urweb
> lighttpd-modules-% src:lighttpd
> perl-modules-% src:perl
> python-dev-is-% src:what-is-python
> python-is-% src:what-is-python
> python3-minimal python3
> python3.%-minimal python3.%

libbinutils src:binutils

The examples you give sound sensible, but I think lintian is not a
useful place to store it. The people best knowing these properties are
the respective package maintainers and not the (dormant) lintian
maintainers. Unfortunately, lintian does not have an archive-wide view,
so storing this outside lintian makes it difficult to check. The more I
look at problems like these, the more I think we should have some other
tool next to lintian that has an archive-wide view and can check such
properties. I'm also guilty of having written two specialized tools in
this area: the multiarch hinter and dumat are both specialized 

Bug#991259: b4: fails with dns.exception.Timeout

[Uwe Kleine-König]

Hello Ricardo,

On 14.01.24 23:42, Ricardo Ribalda wrote:

Since version 0.7, b4 does not use its own dnsfunc, and does not crashes
on DNS errors...

Could you try with your ISP DNS using the latest version of b4 in the
Debian tree?


It seems my ISP fixed their DNS server and reply to TCP queries, so I 
cannot (easily and) reliably test if the problem is gone.


I willing to believe you that b4 improved here, so feel free to close 
the bug.


Best regards
Uwe

Bug#1057506: intellij-community-idea: FTBFS with default Java 21

[tony mancill]

On Mon, Jan 15, 2024 at 05:08:13PM +1300, Vladimir Petko wrote:
> Dear Maintainers,
> 
>   Would it be possible to consider a merge request[1] that addresses this 
> issue?
> 
> Best Regards,
>  Vladimir.
> 
>  [1] 
> https://salsa.debian.org/java-team/intellij-community-idea/-/merge_requests/5

Merged and uploaded.  Thank you for your contribution!

Bug#1059936: Tracked down `behavior of -n is non-portable`

[Alexander Huynh]

I believe the offending line is in the `klibc` package, after some 
tracing: https://salsa.debian.org/kernel-team/klibc/-/blob/2078f63fe594652d42e19060b05aa03966fbd8a5/debian/initramfs-tools/hooks/klibc-utils#L31

--
Alex

Bug#237925: ITP: cdemu -- CD drive emulator for Linux

[Christoph Anton Mitterer]

Hey Matteo.

Are you still working on packaging CDemu for Debian?

If not, Robert Ayrapetyan indicated interest in taking the ITP over:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=237925#84


Cheers,
Chris

Bug#1057506: intellij-community-idea: FTBFS with default Java 21

[Vladimir Petko]

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this issue?

Best Regards,
 Vladimir.

 [1] 
https://salsa.debian.org/java-team/intellij-community-idea/-/merge_requests/5

Bug#1060826: ITP: Mousai: Identify songs in seconds

[Chris Talbot]

Package: wnpp
Severity: wishlist
Owner: Chris Talbot 

* Package name: mousai
  Version : 0.7.6
  Upstream Author : Dave Patrick Caberto
* URL : https://github.com/SeaDve/Mousai
* License : GPL 3.0+
  Programming Lang: Rust
  Description : Identify songs in seconds 

Mousai is an app that allows you to identify a song after
listening to it in the microhpone.

This package will be maintained by the Mobian team.

Bug#1060172: xserver-xorg-core: Screen remains desperately black after starting Xorg on Thinkpad X201s

[Stefan Monnier]

> Xorg refuses to work on my Thinkpad X201s nowadays, tho it used to work just
> fine a year or so ago.  Wayland still works fine.
> The observed behavior is that when GDM3 starts up (using Xorg because
> I have set `WaylandEnable=false` in its config file) at the end of the
> boot process, the screen becomes black and remains so.
> I can use the keyboard to suspend and resume the machine, but I'm flying 
> blind.

I found a workaround.
If I create a file `/etc/X11/xorg.conf` with the following contents:

% cat /etc/X11/xorg.conf
# Workaround for Debian bug#1005359.
Section "Device"
Identifier "modesetting"
Driver "modesetting"
Option "UseGammaLUT" "false"
EndSection
%

then the Xorg server comes up fine.

As the comment indicate, I took this workaround from bug#1005359, so
maybe the two bugs should be merged.

(I hadn't tried this earlier since I presumed that the hardware was
sufficiently different between my X201s and my Librem mini that the
bugs would also be different).


Stefan

Bug#1060820: ITP: golang-github-cyberphone-json-canonicalization -- JSON Canonicalization Scheme (JCS) (Go library)

[Reinhard Tartler]

On Sun, Jan 14, 2024 at 8:36 PM Simon Josefsson  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Simon Josefsson 
>
> * Package name: golang-github-cyberphone-json-canonicalization
>   Version : 0.0~git20220623.57a0ce2-1
>   Upstream Author : Anders Rundgren
> * URL : https://github.com/cyberphone/json-canonicalization
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : JSON Canonicalization Scheme (JCS) (Go library)
>
>
I contemplated packaging this library in the past, but found it actually
contains
a lot of other stuff I didn't nede. In the end, I ended up packaging
https://salsa.debian.org/debian/golang-webpki-org-jsoncanonicalizer
which seems to be what the proposed package is "repackaing".

In a way, I went straight for the source, I guess.

Best,
-rt

Bug#1060825: libpam-zfs: prompts for password for passwordless user, accepts empty

[наб]

Package: libpam-zfs
Version: 2.2.2-3
Severity: normal

Dear Maintainer,

On a graphical session, I was prompted for a passphrase;
when there is no passphrase, there's just a login button.

For something easy to reproduce:
  $ sudo getent shadow
  [sudo] password for user:
  user::19736:0:9:7:::
this is obviously wrong.

Best,
наб

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

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

Versions of packages libpam-zfs depends on:
ii  libc62.37-13
ii  libnvpair3linux  2.2.2-3
ii  libpam-runtime   1.5.2-9.1
ii  libpam0g 1.5.2-9.1+b1
ii  libssl3  3.1.4-2
ii  libzfs4linux 2.2.2-3

libpam-zfs recommends no packages.

libpam-zfs suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1060824: tailspin - upcoming rust-terminal-size update.

[Peter Green]

Package: tailspin

I intend to update rust-terminal-size in unstable to 0.3 soon
(probablly a week or so).

Tailspin upstream already uses 0.3, and your Cargo.toml already
allows 0.3, so this should be a simple matter of tweaking the
Debian build-dependency.

I've tested that the package builds with the build-depenency
tweaked, if you want to do further testing the new version
of terminal-size has been uploaded to experimental.

Bug#1060823: baler: Update debian/control for loong64

[Zhang Na]

Source: baler
Version: 1.3.0-1
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Please update debian/control for loong64, thanks!


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 2425b38cb0d0a926ae1c4f7c5c5d7e85b1103797 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Mon, 15 Jan 2024 02:23:00 +
Subject: [PATCH] Update debian/control for loong64

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index f94651a..8f5cb41 100644
--- a/debian/control
+++ b/debian/control
@@ -20,7 +20,7 @@ Homepage: https://github.com/baler-collaboration/baler/
 
 Package: python3-baler
 Section: python
-Architecture: amd64 arm64 ppc64el s390x riscv64
+Architecture: amd64 arm64 loong64 ppc64el s390x riscv64
 Multi-Arch: foreign
 Depends:
  ${python3:Depends},
-- 
2.43.0

Bug#1060822: choose-mirror: please add support for loong64

[wuruilong]

Source: choose-mirror
Version: 2.125
Severity: normal
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

Please modify Mirrors.masterlist to support loong64 architecture

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

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

Bug#1060821: openjdk-11 adds zero build for loong64

[Leslie Zhai]

Package: openjdk-11
Version: 11.0.22~6ea-1
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64


Dear Maintainers,
I hope this email finds you well. We would like to add openjdk-8 zero build 
support for loong64.

The attached patch includes three parts of changes:
(1) Add the loong64 variable to debian/rules and debian/control.
(2) patches/loong64-autoconf-config.diff adds loongarch info.

Thank you for your time and consideration of this request.

Thanks,

Leslie Zhai



support-zero-build-for-loong64.patch
Description: Binary data

Bug#1057430:

[john faulk]

I can't seem to figure why, it compiles fine on my machine. the error
you're showing is due to libsdbus-c++-dev being missing from your
system. If this is not in the build-deps, a simple fix would be to add
this package to them.

Bug#1060820: ITP: golang-github-cyberphone-json-canonicalization -- JSON Canonicalization Scheme (JCS) (Go library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-cyberphone-json-canonicalization
  Version : 0.0~git20220623.57a0ce2-1
  Upstream Author : Anders Rundgren
* URL : https://github.com/cyberphone/json-canonicalization
* License : Apache-2.0
  Programming Lang: Go
  Description : JSON Canonicalization Scheme (JCS) (Go library)

 Cryptographic operations like hashing and signing depend on that the
 target data does not change during serialization, transport, or parsing.
 By applying the rules defined by JCS (JSON Canonicalization Scheme),
 data provided in the JSON [RFC8259
 (https://tools.ietf.org/html/rfc8259)] format can be exchanged "as is",
 while still being subject to secure cryptographic operations. JCS
 achieves this by building on the serialization formats for JSON
 primitives as defined by ECMAScript [ES (https://ecma-
 international.org/ecma-262/)], constraining JSON data to the I-JSON
 [RFC7493 (https://tools.ietf.org/html//rfc7493)] subset, and through a
 platform independent property sorting scheme.
 .
 Public RFC: (https://tools.ietf.org/html/rfc8785)
 .
 The JSON Canonicalization Scheme concept in a nutshell:
 .
  * Serialization of primitive JSON data types using methods compatible
with ECMAScript's JSON.stringify()
  * Lexicographic sorting of JSON Object properties in a *recursive*
process
  * JSON Array data is also subject to canonicalization, *but element
order remains untouched*

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-cyberphone-json-canonicalization

/Simon


signature.asc
Description: PGP signature

Bug#1060819: ITP: golang-github-zeebo-errs -- errs is a package for making errors friendly and easy

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-zeebo-errs
  Version : 1.3.0-1
  Upstream Author : Jeff Wendling
* URL : https://github.com/zeebo/errs
* License : Expat
  Programming Lang: Go
  Description : errs is a Go library for making errors friendly and easy

 errs is a package for making errors friendly and easy.  Errors come
 with a stack trace that is only printed when a "+" character is used in
 the format string. This should retain the benefits of being able to
 diagnose where and why errors happen, without all of the noise of
 printing a stack trace in every situation.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-zeebo-errs/

/Simon


signature.asc
Description: PGP signature

Bug#1060818: ITP: in-toto-golang -- framework for software supply chain integrity

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: in-toto-golang
  Version : 0.9.0-1
  Upstream Author : Aditya Sirish, Christian Rebischke, Lukas Pühringer, et al
* URL : https://github.com/in-toto/in-toto-golang
* License : Apache-2.0
  Programming Lang: Go
  Description : framework for software supply chain integrity

 Go implementation of in-toto

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/in-toto-golang/

/Simon



signature.asc
Description: PGP signature

Bug#1001989: RFP: golang-github-grafana-dskit -- Distributed systems kit

[Mathias Gibbens]

Control: retitle -1 RFP: golang-github-grafana-dskit -- Distributed systems kit
Control: noowner -1

  This library is no longer required to build Incus, so I no longer
have a need to work on packaging it. So, converting to a RFP for anyone
else to pickup in the future.

  I have pushed my current packaging work to salsa:
https://salsa.debian.org/go-team/packages/golang-github-grafana-dskit/.

  Some notes of further work required as of today:

  * Depends on golang-github-go-redis-redis-dev (>= 8.11.5)

  * Might depend on golang-github-sercand-kuberesolver-dev (>= 5.1.1)

  * Depends on golang-github-hashicorp-consul-dev, which was RM'ed in #1055054

  * Depends on golang-github-uber-jaeger-client-go-dev, which I have
asked to be RM'ed for the time being in #1060811 (the library is
deprecated and vendors a bunch of stuff, so I don't want it in the
archive without being actively used; refer to that package's
README.source for more details)

  * Patches have been applied to use older versions of grpc and etcd as
currently packaged

Mathias


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

Bug#1060817: ITP: golang-github-spiffe-go-spiffe -- Golang library for SPIFFE support

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-spiffe-go-spiffe
  Version : 2.1.6-1
  Upstream Author : Agustín Martínez Fayó, Andrew Harding, et al
* URL : https://github.com/spiffe/go-spiffe
* License : Apache-2.0
  Programming Lang: Go
  Description : Golang library for SPIFFE support

 This library is a convenient Go library for working with SPIFFE
 (https://spiffe.io/).
 .
 It leverages the SPIFFE Workload API
 (https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Workload_API.md),
 providing high level functionality that includes:
 .
  * Establishing mutually authenticated TLS (**mTLS**) between workloads
powered by SPIFFE.
  * Obtaining and validating X509-SVIDs
(https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md) and
JWT-SVIDs (https://github.com/spiffe/spiffe/blob/main/standards/JWT-
SVID.md).
  * Federating trust between trust domains using SPIFFE bundles

(https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Trust_Domain_and_Bundle.md#3-
spiffe-bundles).
  * Bundle management.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-spiffe-go-spiffe/

/Simon


signature.asc
Description: PGP signature

Bug#1058671: [debian-mysql] Bug#1058671: mariadb-server: [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.

[Otto Kekäläinen]

FYI: Discussion about this continued in
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/61

Bug#1060816: ITP: golang-github-shibumi-go-pathspec -- gitignore-style pathspec pattern matching in Go

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-shibumi-go-pathspec
  Version : 1.3.0-1
  Upstream Author : Sander van Harmelen, Christian Rebischke
* URL : https://github.com/shibumi/go-pathspec
* License : Apache-2.0
  Programming Lang: Go
  Description : gitignore-style pathspec pattern matching in Go

 go-pathspec implements gitignore-style pattern matching for paths.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-shibumi-go-pathspec/

/Simon


signature.asc
Description: PGP signature

Bug#1025956: u-boot-menu: Allow automatic sync of DTBs when /boot is a separate partition

[Vagrant Cascadian]

On 2022-12-12, Arnaud Ferraris wrote:
> It is common practice for /boot to be on a separate partition, requiring DTBs
> to be synced to this partition for u-boot to be able to access them.

Thanks for working on this!

> From: Arnaud Ferraris 
> Date: Mon, 12 Dec 2022 13:57:47 +0100
> Subject: [PATCH 1/2] u-boot-update: split config file reading to a separate
>  script
>
> The logic of reading the configuration file and determining whether
> `/boot` is on a separate partition can be useful to other scripts, such
> as the kernel postinst/postrm ones. This commit moves this code to a
> separate, source-able script to make it more easily reusable.
...
>  debian/u-boot-menu.install |  1 +
>  read-config| 70 ++
>  u-boot-update  | 70 +-
>  3 files changed, 72 insertions(+), 69 deletions(-)
>  create mode 100644 read-config

Conceptually this change looks fine to me, though needs a bit of a
refresh.


> From: Arnaud Ferraris 
> Date: Mon, 12 Dec 2022 14:14:27 +0100
> Subject: [PATCH 2/2] Allow to automatically sync DTBs when /boot is on a
>  separate partition
>
> Having `/boot` on a separate partition is a very common use-case,
> requiring device tree binary files to be copied over to this partition
> as `u-boot` won't be searching other partitions for those.
>
> Up until now, users had to manually copy (and potentially edit) the
> provided `zz-sync-dtb` example script if their system was using a
> separate `/boot` partition, which isn't practical.
>
> This patch implements a way to automate this synchronization process
> in such cases, and remove the synchronized files when the corresponding
> kernel is removed as well.

Yay!

> In order to maintain the current behaviour, this feature is disabled by
> default and must be enabled by setting the `U_BOOT_SYNC_DTBS`
> configuration variable to `true`.

Mixed feelings on weather it should be guarded in the long-term, but
that makes sense at least at when first introducing this...


> diff --git a/debian/u-boot-menu.install b/debian/u-boot-menu.install
> index 695129f..4816e32 100644
> --- a/debian/u-boot-menu.install
> +++ b/debian/u-boot-menu.install
> @@ -1,4 +1,4 @@
> -read-config usr/share/u-boot-menu
> -u-boot-update   usr/sbin
> -zz-u-boot-menu  etc/kernel/postinst.d
> -zz-u-boot-menu  etc/kernel/postrm.d
> +read-config usr/share/u-boot-menu
> +u-boot-update   usr/sbin
> +postinst/zz-u-boot-menu etc/kernel/postinst.d
> +postrm/zz-u-boot-menu   etc/kernel/postrm.d

As mentioned, please minimize the whitespace differences on a rebase or
refresh of this patch.


> diff --git a/default b/default
> index 2e29c83..21801b4 100644
> --- a/default
> +++ b/default
> @@ -13,4 +13,4 @@
>  #U_BOOT_FDT_DIR="/usr/lib/linux-image-"
>  #U_BOOT_FDT_OVERLAYS=""
>  #U_BOOT_FDT_OVERLAYS_DIR="/boot/dtbo/"
> -
> +#U_BOOT_SYNC_DTBS="false"

I almost wish to kill off /etc/default/u-boot entirely... all of the
defaults are commented out and could instead be shipped in
/usr/share/u-boot-menu/conf.d/default.conf rather than embedded in the
u-boot-update script (or the new read-config snippet).


> diff --git a/postinst/zz-u-boot-menu b/postinst/zz-u-boot-menu
...
> diff --git a/postrm/zz-u-boot-menu b/postrm/zz-u-boot-menu

Those looked reasonable at a quick glance.


> diff --git a/u-boot-update.8 b/u-boot-update.8
> index 12852ee..3f47c1b 100644
> --- a/u-boot-update.8
> +++ b/u-boot-update.8
> @@ -111,7 +111,8 @@ The default is 50.
>  .IP "U_BOOT_FDT_DIR=""\fB/usr/lib/linux-image-\fR""" 4
>  This variable specifies the unversioned stem of paths
>  where U\-BOOT should look for the flattened device tree binaries.
> -Default is '/usr/lib/linux-image-'.
> +Default is '/usr/lib/linux-image-', or '/dtb-' when u\-boot\-update
> +detects /boot is on a separate partition.

... and the configuration has U_BOOT_SYNC_DTBS=true (described later)?
E.g. it does not detect a /boot partition unless U_BOOT_SYNC_DTBS=true?


So it seems at the very least it needs a refresh, but looking over it
all it looks conceptually good.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1025956: u-boot-menu: Allow automatic sync of DTBs when /boot is a separate partition

[Vagrant Cascadian]

On 2023-11-13, Arnaud Ferraris wrote:
> Le 18/05/2023 à 17:42, Vagrant Cascadian a écrit :
>> 
>> Unfortunately, this will have to wait till after bookworm release,
>> currently scheduled for June.
>
> Gentle ping with the hope that you (or Jonas) have some bandwidth to 
> take a look at this patch ;)

Sorry it has taken so long to get a look at these ... especially because
the patches no longer apply. :(

I noticed a few whitespace changes in the original patch that almost
hide some of the changes; this patch is involved enough that it would be
nice to reduce these to make it easier to review, for example:

diff --git a/debian/u-boot-menu.install b/debian/u-boot-menu.install
index 695129f..4816e32 100644
--- a/debian/u-boot-menu.install
+++ b/debian/u-boot-menu.install
@@ -1,4 +1,4 @@
-read-config usr/share/u-boot-menu
-u-boot-update   usr/sbin
-zz-u-boot-menu  etc/kernel/postinst.d
-zz-u-boot-menu  etc/kernel/postrm.d
+read-config usr/share/u-boot-menu
+u-boot-update   usr/sbin
+postinst/zz-u-boot-menu etc/kernel/postinst.d
+postrm/zz-u-boot-menu   etc/kernel/postrm.d

My guess is this was to align with the longer lines, but I'd personally
rather see just the two lines of diff rather than rewriting the whole
file.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1059654: RM: tablix2 -- RoQA; orphaned; upstream deprecation notice; very low popcon

[Bastian Germann]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: tablix2 -- RoQA; orphaned; upstream deprecation notice; 
very low popcon

Please remove tablix2. It is orphand, has a deprecation notice on its website, 
and has a very low popcon.

Bug#1060815: ITP: relic -- digitally sign Linux/Java/Windows packages

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: relic
  Version : 7.6.1-1
  Upstream Author : SAS Institute, Inc.
* URL : https://github.com/sassoftware/relic
* License : Apache-2.0
  Programming Lang: Go
  Description : digitally sign Linux/Java/Windows packages

 relic is a multi-tool and server for package signing and working with
 hardware security modules (HSMs).
 .
 Package types
 .
  * RPM - RedHat packages
  * DEB - Debian packages
  * JAR - Java archives
  * EXE (PE/COFF) - Windows executable
  * MSI - Windows installer
  * appx, appxbundle - Windows universal application
  * CAB - Windows cabinet file
  * CAT - Windows security catalog
  * XAP - Silverlight and legacy Windows Phone applications
  * PS1, PS1XML, MOF, etc. - Microsoft Powershell scripts and modules
  * manifest, application - Microsoft ClickOnce manifest
  * VSIX - Visual Studio extension
  * Mach-O - macOS/iOS signed executables
  * DMG, PKG - macOS disk images / installer packages
  * APK - Android package
  * PGP - inline, detached or cleartext signature of data
 .
 Token types
 .
 relic can work with several types of token:
 .
  * pkcs11 - Industry standard PKCS#11 HSM interface using shared object
files
  * Cloud services - AWS, Azure and Google Cloud managed keys
  * scdaemon - The GnuPG scdaemon service can enable access to OpenPGP
cards (such as Yubikey NEO)
  * file - Private keys stored in a password-protected file
 .
 Features
 .
 Relic is primarily meant to operate as a signing server, allowing
 clients to authenticate with a TLS certificate and sign packages
 remotely. It can also be used as a standalone signing tool.
 .
 Other features include:
 .
  * Generating and importing keys in the token
  * Importing certificate chains from a PKCS#12 file
  * Creating X509 certificate signing requests (CSR) and self-signed
certificates
  * Limited X509 CA support -- signing CSRs and cross-signing certificates
  * Creating simple PGP public keys
  * RSA and ECDSA supported for all signature types
  * Verify signatures, certificate chains and timestamps on all supported
package types
  * Sending audit logs to an AMQP broker, with an optional sealing
signature
  * Save token PINs in the system keyring
 .
 Linux, Windows and MacOS are supported. Other platforms probably work as
 well.
 .
 relic is tested using libsofthsm2 and Gemalto SafeNet Network HSM (Luna
 SA).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/relic

/Simon


signature.asc
Description: PGP signature

Bug#1060814: inetutils-ftpd: No inetd dependency

[Scott]

Package: inetutils-ftpd
Version: 2:2.0-1+deb11u
Severity: minor

Dear Maintainer,

   * What led up to the situation?

    installed package, then attempted to open connection, received 
no reply from ftpd service


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

    determined no inetd installed
    selected ftpd-ssl package which depends on openbsd-inetd

   * What was the outcome of this action?

    received reply from ftpd service

-- System Information:
Debian Release: 11.8
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldstable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages inetutils-ftpd depends on:
ii  libc6    2.31-13+deb11u7
ii  libcrypt1    1:4.4.18-4
ii  libpam0g 1.4.0-9+deb11u1
ii  libwrap0 7.6.q-31
ii  netbase  6.3
ii  rsyslog [system-log-daemon]  8.2102.0-2+deb11u1

inetutils-ftpd recommends no packages.

inetutils-ftpd suggests no packages.

Bug#991259: b4: fails with dns.exception.Timeout

[Ricardo Ribalda]

Hi Uwe.

Since version 0.7, b4 does not use its own dnsfunc, and does not crashes
on DNS errors...

Could you try with your ISP DNS using the latest version of b4 in the
Debian tree?

Thanks!


signature.asc
Description: PGP signature

Bug#1054829: php-fpdf: FTBFS: make: *** [/usr/share/quilt/quilt.make:23: unpatch] Error 1

[Bastian Germann]

Control: fixed -1 php-fpdf/3:1.8.4.dfsg-2

Bug#1060698: [Pkg-auth-maintainers] Bug#1060698: Bug#1060698: yubioath-desktop: Doesn't see yubikeys anymore.

[Florian Schlichting]

Hi Sébastien,

On Sun, Jan 14, 2024 at 02:36:38PM +0100, Sébastien Noel wrote:
> for what it's worth, i have been running yubioath with this patch
> for ~11 months, so I would feel confident to ship it in Debian
> and take responsibility for it

very good, I'm going to prepare an upload that includes your patch and
will close #1060698 now.

Florian

Bug#1060689: libspreadsheet-parsexlsx-perl 0.27-2.1+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libspreadsheet-parsexlsx-perl
Version: 0.27-2.1+deb11u1

Explanation: fix possible memory bomb [CVE-2024-22368]

Bug#1060688: libspreadsheet-parsexlsx-perl 0.27-3+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1060688 = bookworm pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libspreadsheet-parsexlsx-perl
Version: 0.27-3+deb12u1

Explanation: fix possible memory bomb [CVE-2024-22368]

Bug#1060433: apktool 2.7.0+dfsg-6+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1060433 = bookworm pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: apktool
Version: 2.7.0+dfsg-6+deb12u1

Explanation: prevent arbitrary file writes with malicious resource names 
[CVE-2024-21633]

Bug#1056358: needrestart 3.6-4+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1056358 = bookworm pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: needrestart
Version: 3.6-4+deb12u1

Explanation: fix microcode check regression on AMD CPUs

Bug#1053816: nftables 0.9.8-3.1+deb11u2 flagged for acceptance

[Jonathan Wiltshire]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nftables
Version: 0.9.8-3.1+deb11u2

Explanation: fix incorrect bytecode generation

Bug#1037219: imagemagick 6.9.11.60+dfsg-1.3+deb11u2 flagged for acceptance

[Jonathan Wiltshire]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: imagemagick
Version: 6.9.11.60+dfsg-1.3+deb11u2

Explanation: various security fixes [CVE-2021-20241 CVE-2021-20243 
CVE-2021-20244 CVE-2021-20245 CVE-2021-20246 CVE-2021-20309 CVE-2021-3574 
CVE-2021-39212 CVE-2021-4219 CVE-2022-1114 CVE-2022-28463 CVE-2022-32545 
CVE-2022-32546]

Bug#1060813: ITP: golang-github-qur-ar -- Golang ar archive file library

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-qur-ar
  Version : 0.0~git20130629.282534b-1
  Upstream Author : Blake Smith, Julian Phillips
* URL : https://github.com/qur/ar
* License : Expat
  Programming Lang: Go
  Description : Golang ar archive file library

 Golang ar (archive) file reader
 .
 This is a simple library for reading and writing ar
 (http://en.wikipedia.org/wiki/Ar_(Unix)) files in common format. It is
 influenced heavily in style and interface from the golang tar
 (http://golang.org/pkg/archive/tar/) package.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-qur-ar

/Simon


signature.asc
Description: PGP signature

Bug#1060812: ima-evm-utils: New upstream location

[Bastian Germann]

Source: ima-evm-utils
Version: 1.4-1
Severity: wishlist

Please update to the latest version on the new upstream location 
https://github.com/mimizohar/ima-evm-utils.

Bug#599678:

[abibou bio kpo]

Bonsoir svp je veux jouer ça ne marche pas comment je vais faire ?

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

On Sun, 2024-01-14 at 19:35:40 +0100, Guillem Jover wrote:
> Perfect, thanks. I've force pushed the new changes to the previous
> branch. How about then the following output?
> 
> ,---
> Warning: Source package barnowl is part of ongoing transitions:
> 
>   auto-perl perl-5.38
> 

Was wondering now whether it would be better to linkify the list of
transitions, such as:

,---
Warning: Source package barnowl is part of ongoing transitions:

  
  

[…]
`---

Although that seems a bit more noisy, but provides more context. I'm
not sure though how stable those URLs should be considered to be.

> If the upload does not solve issues caused by these transitions, then it
> might disrupt them by adding delays or entangling them. For more information,
> please read:
> 
>   
> 
> Note: If you are aware of this and do not want to be warned, you can disable
> this hook from the config file, set the one-off environment variable
> DUPLOAD_SKIP_TRANSITION_CHECK=1, or alternatively you can reply to the
> following prompt.
> 

(I think I'll be adding some generic way to skip specific hooks,
because this is a common pattern among them, something like
--skip-hooks=a,b and DUPLOAD_SKIP_HOOKS=a,b.)

> Continue anyway? (yes/NO) 
> Ok, aborting the upload.
> 
> `---

Thanks,
Guillem

Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed

[Luca Boccassi]

On Sun, 14 Jan 2024 at 19:30, Pascal Hambourg  wrote:
>
> On 11/01/2024 at 12:56, Luca Boccassi wrote:
> >
> > Yes it is a firmware feature, so it depends on the hardware, and in all
> > drives I know of that will be the case, yes. From that point of view,
> > to me it doesn't seem that far away from dm-crypt using the CPU's AES-
> > NI to actually encrypt/decrypt data, or anything else implemented in
> > hardware/firmware that the installer now supports out of the box with
> > non-free-firmware being enabled by default. If I am trusting Intel to
> > handle my data in their wifi firmware, and in their CPU microcode, and
> > memory controllers, and whatever else is on my hardware, it seems
> > strange to start worrying once the line is crossed into the NVME
> > firmware...
>
> Correct me if I'm wrong, but aren't CPUs and wifi controllers
> pass-through devices which do not persistently store encryption keys or
> data and whose encrypted output can be inspected to check if they are
> doing the right thing so that you do not have to blindly trust them ?
>
> Self-encrypted drives persistently store encryption keys and data. Can
> their encrypted output reliably be inspected ? Can they be trusted if
> the manufacturer implemented some hidden mechanism allowing to recover
> the data when customers lost their password (like BIOS manufacturers do)
> which will be leaked sooner or later ?

Most definitely wrong. If your threat model is "hardware vendor will
spend hundreds of millions of dollars to get at me" then your cpu
vendor, memory controller vendor, etc etc can do that too, so you
better not use this nor any other type of hardware acceleration, ever.
The good news is, if you are writing on a Debian bug tracker then you
are not even remotely interesting enough for any hardware manufacturer
to spend even a tiny fraction of that, so it's all good.

Bug#1060811: RM: golang-github-uber-jaeger-client-go -- ROM; no longer needed, deprecated upstream

[Mathias Gibbens]

Package: ftp.debian.org
Severity: normal

  Please remove golang-github-uber-jaeger-client-go. It was packaged
solely to support the packaging of golang-github-grafana-dskit (bug
#1001989) which had been required for the packaging of Incus. However,
upstream Incus has removed the dependency on golang-github-grafana-
dskit, so I no longer need to package it.

  Given that golang-github-uber-jaeger-client-go is deprecated and
packaged solely to support golang-github-grafana-dskit, I would prefer
to not have it linger around in the archive when nothing depends on it.
It has never been included in a stable release, and there are no
reverse build deps in unstable.

Thanks,
Mathias


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

Bug#1060810: ITP: golang-github-sassoftware-go-rpmutils -- Golang implementation of parsing RPM packages

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-sassoftware-go-rpmutils
  Version : 0.2.0-1
  Upstream Author : SAS Institute, Inc.
* URL : https://github.com/sassoftware/go-rpmutils
* License : Apache-2.0
  Programming Lang: Go
  Description : Golang implementation of parsing RPM packages

 go-rpmutils is a library written in go (http://golang.org) for parsing
 and extracting content from RPMs (http://www.rpm.org).
 .
 go-rpmutils provides a few interfaces for handling RPM packages. There is
 a highlevel Rpm struct that provides access to the RPM header and CPIO
 (https://en.wikipedia.org/wiki/Cpio) payload. The CPIO payload can be
 extracted to a filesystem location via the ExpandPayload function or
 through a Reader interface, similar to the tar implementation
 (https://golang.org/pkg/archive/tar/) in the go standard library.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-sassoftware-go-rpmutils

/Simon


signature.asc
Description: PGP signature

Bug#1060809: RFS: hm/18.0-1 [ITP] -- Reference software for HEVC

[Joachim Bauch]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: pkg-multimedia-maintain...@lists.alioth.debian.org
X-Debbugs-Cc: sramac...@debian.org

(CC'ing pkg-multimedia-maintainers as the group where I'm planning to
maintain it and Sebastian who sponsored other packages from me)

Dear mentors,

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

 * Package name : hm
   Version  : 18.0-1
   Upstream contact : https://hevc.hhi.fraunhofer.de/
 * URL  : https://vcgit.hhi.fraunhofer.de/jvet/HM
 * License  : public-domain, BSD-3-clause
 * Vcs  : https://salsa.debian.org/multimedia-team/hm
   Section  : video

The source builds the following binary packages:

  hm - Reference software for HEVC - standard bitdepth
  hm-highbitdepth - Reference software for HEVC - high bitdepth
  hm-config - Reference software for HEVC - config files
  hm-doc - Reference software for HEVC - documentation

Note: the packaging files (for now) are available at

https://salsa.debian.org/fancycode/hm

I'm planning to move this to the "multimedia-team" group once packaging
is final.

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


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

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

  dget -x https://mentors.debian.net/debian/pool/main/h/hm/hm_18.0-1.dsc

Changes for the initial release:

 hm (18.0-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1060678)

Thanks and best regards,
  Joachim


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060808: rustc: debian/rules source_orig-stage0 fails on 1.70.0

[Fab Stz]

Package: rustc
Version: 1.70.0+dfsg1
Severity: normal

Dear Maintainer,

I was trying to run this script as suggested in debian/README.source

LC_ALL=C upstream_bootstrap_arch="i386" debian/rules source_orig-stage0

But it fails as follows:

QUILT_PATCHES=debian/patches quilt push -aq; x=$?; if [ $x = 2 ]; then exit 0;
else exit $x; fi
File series fully applied, ends at patch ubuntu-ignore-arm-doctest.patch
/usr/bin/make -f debian/rules clean
make[1]: Entering directory '/build/rustc-1.70.0+dfsg1'
dh clean --parallel
   debian/rules override_dh_auto_clean
make[2]: Entering directory '/build/rustc-1.70.0+dfsg1'
rm -f -rf build tmp debian/cargo_home config.stamp config.mk Makefile
rm -f -rf debian/rustc-tests.log debian/config.toml debian/*.stamp
rm -f -rf src/bootstrap/bootstrap.pyc src/bootstrap/__pycache__
src/etc/__pycache__/ config.toml
make[2]: Leaving directory '/build/rustc-1.70.0+dfsg1'
   debian/rules override_dh_clean
make[2]: Entering directory '/build/rustc-1.70.0+dfsg1'
# Upstream contains a lot of these
dh_clean -XCargo.toml.orig
make[2]: Leaving directory '/build/rustc-1.70.0+dfsg1'
make[1]: Leaving directory '/build/rustc-1.70.0+dfsg1'
debian/make_orig-stage0_tarball.sh
Traceback (most recent call last):
  File "/build/rustc-1.70.0+dfsg1/debian/get-stage0.py",
line 31, in 
main(sys.argv)
  File "/build/rustc-1.70.0+dfsg1/debian/get-stage0.py",
line 28, in main
bootstrap.bootstrap(False)
  File
"/build/rustc-1.70.0+dfsg1/src/bootstrap/bootstrap.py",
line 858, in bootstrap
build.verbose = args.verbose != 0

AttributeError: 'bool' object has no attribute 'verbose'
make: *** [debian/rules:483: source_orig-stage0] Error 1


-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 
'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 
'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 
'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 
'unstable'), (93, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages rustc depends on:
ii  binutils  2.40-2
ii  gcc   4:12.2.0-3
ii  libc6 2.36-9+deb12u3
ii  libc6-dev [libc-dev]  2.36-9+deb12u3
ii  libgcc-s1 12.2.0-14
ii  libstd-rust-dev   1.63.0+dfsg1-2

Versions of packages rustc recommends:
ii  cargo0.66.0+ds1-1
ii  llvm-14  1:14.0.6-12

Versions of packages rustc suggests:
pn  clang-14  
pn  lld-14

-- no debconf information

Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed

[Pascal Hambourg]

On 11/01/2024 at 12:56, Luca Boccassi wrote:


Yes it is a firmware feature, so it depends on the hardware, and in all
drives I know of that will be the case, yes. From that point of view,
to me it doesn't seem that far away from dm-crypt using the CPU's AES-
NI to actually encrypt/decrypt data, or anything else implemented in
hardware/firmware that the installer now supports out of the box with
non-free-firmware being enabled by default. If I am trusting Intel to
handle my data in their wifi firmware, and in their CPU microcode, and
memory controllers, and whatever else is on my hardware, it seems
strange to start worrying once the line is crossed into the NVME
firmware...


Correct me if I'm wrong, but aren't CPUs and wifi controllers 
pass-through devices which do not persistently store encryption keys or 
data and whose encrypted output can be inspected to check if they are 
doing the right thing so that you do not have to blindly trust them ?


Self-encrypted drives persistently store encryption keys and data. Can 
their encrypted output reliably be inspected ? Can they be trusted if 
the manufacturer implemented some hidden mechanism allowing to recover 
the data when customers lost their password (like BIOS manufacturers do) 
which will be leaked sooner or later ?

Bug#1053348: atop gets a segmentation fault

[Tiger!P]

On Sat, Jan 13, 2024 at 09:55:46PM +0100, Marc Haber wrote:
> On Mon, Oct 02, 2023 at 12:50:04PM +0200, Tiger!P wrote:
> > I ran `atop 2` for some time and then it got a segmentation fault.
> > Because it didn't create a core file, I changed settings to get a
> > core file and started atop in the same way.
> 
> Does this still happen with the new atop version in sid?

I have not seen a segfault with 2.10.0-1 yet.
I have updated atop to 2.10.0-1 on multiple system and will report when
I see a crash again.

Tiger!P

Bug#1060651: mc: doesn't fully resize itself if reading directory while terminal's resized

[Michael Gold]

On Sat, Jan 13, 2024 at 04:47:00 +, Michael Gold wrote:
> Simply sticking a "return" at the top of rotate_dash() makes the problem
> unreproducible, and gives me a PASS from the test case.

Setting g->winch_pending in group_init() also works, and I don't imagine
it would have any negative effect.

-- Michael


signature.asc
Description: PGP signature

Bug#1059924: should we actually ship sudo_logsrvd

[Alexander Reichle-Schmehl]

Hi!

* Marc Haber  [240103 19:12]:
> (1)
> remove sudo_logsrvd from the package with no replacement?

Please no, I know at least one user: Me!

> (2)
> move sudo_logsrvd to its own package with proper systemd unit etc bla
> foo

That sounds like a good idea, given that it is not a very common use
case.

I can start to work on that solution.


> An independent solution would be to continue shipping sudo.deb in a
> minimal configuration, and having a new sudo-extended.deb that can
> support plugins, SSL, bells and whistles, but just with supported sudo
> => sudo-extended migration path and explicitly not providing a migration
> path back from sudo-extended to plain sudo. But all this can only be
> done after sudo-ldap is gone as this is a horrible mess to package that
> we NEED to get rid of.

I willing to help get sudo-logsrvd and sudo-extendended packaged.
Looking at the package... My first instinct would be to extend sudo-ldap
with openssl, and split sudo-logsrvd from that package, and then rename
sudo-ldap to sudo-extended.

However I'm not using sudo with ldap and never used that package.  Would
that be a valid approach?  Or anything else I can help with helping with
the getting rid of sudo-ldap?


Best regards,
  Alexander

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

On Sun, 2024-01-14 at 19:12:03 +0100, Paul Gevers wrote:
> On 14-01-2024 18:46, Guillem Jover wrote:
> > I think that would be great, I guess the message from the hook could
> > give some very basic and generic guidance, and point to this page for
> > more in-depth explanation of what to do, what else to check etc. But in
> > any case an initial version sounds good, as that can always be tuned,
> > or extended/improved later on. :)
> 
> Initial version. Please consider the name too, moving now is easier than
> later:
> https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook

Perfect, thanks. I've force pushed the new changes to the previous
branch. How about then the following output?

,---
Warning: Source package barnowl is part of ongoing transitions:

  auto-perl perl-5.38

If the upload does not solve issues caused by these transitions, then it
might disrupt them by adding delays or entangling them. For more information,
please read:

  

Note: If you are aware of this and do not want to be warned, you can disable
this hook from the config file, set the one-off environment variable
DUPLOAD_SKIP_TRANSITION_CHECK=1, or alternatively you can reply to the
following prompt.

Continue anyway? (yes/NO) 
Ok, aborting the upload.

`---

Thanks,
Guillem

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Paul Gevers]

Hi

On 14-01-2024 18:46, Guillem Jover wrote:

I think that would be great, I guess the message from the hook could
give some very basic and generic guidance, and point to this page for
more in-depth explanation of what to do, what else to check etc. But in
any case an initial version sounds good, as that can always be tuned,
or extended/improved later on. :)


Initial version. Please consider the name too, moving now is easier than 
later:

https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060807: zfp: please compile zfp with -DBIT_STREAM_WORD_TYPE=uint8

[Picca Frédéric-Emmanuel]

Source: zfp
Severity: important

Dear Maintainer,

since the upload of zfp 1.0.1, the test of hdf5plugin are failing

look at here

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

It seems to me that the zfp library should be recompile with the previous flag.

thanks

Frederic.


PS: Il also recompiled locally h5z-zfp and now the unit test is also failling 
with these errors

H5Dcreate failed at line 405, errno=2 (No such file or directory)
 [ESC[31;01mFAILEDESC[0m]
./test_write_plugin zfpmode=2 prec=16 ...HDF5-DIAG: Error 
detected in HDF5 (1.10.10) thread 1:
  #000: ../../../src/H5D.c line 140 in H5Dcreate2(): unable to create dataset
major: Dataset
minor: Unable to initialize object
  #001: ../../../src/H5Dint.c line 328 in H5D__create_named(): unable to create 
and link to dataset
major: Dataset
minor: Unable to initialize object
  #002: ../../../src/H5L.c line 1542 in H5L_link_object(): unable to create new 
link to object
major: Links
minor: Unable to initialize object
  #003: ../../../src/H5L.c line 1785 in H5L__create_real(): can't insert link
major: Links
minor: Unable to insert object
  #004: ../../../src/H5Gtraverse.c line 830 in H5G_traverse(): internal path 
traversal failed
major: Symbol table
minor: Object not found
  #005: ../../../src/H5Gtraverse.c line 607 in H5G__traverse_real(): traversal 
operator failed
major: Symbol table
minor: Callback failed
  #006: ../../../src/H5L.c line 1590 in H5L__link_cb(): unable to create object
major: Links
minor: Unable to initialize object
  #007: ../../../src/H5Oint.c line 2459 in H5O_obj_create(): unable to open 
object
major: Object header
minor: Can't open object
  #008: ../../../src/H5Doh.c line 287 in H5O__dset_create(): unable to create 
dataset
major: Dataset
minor: Unable to initialize object
  #009: ../../../src/H5Dint.c line 1196 in H5D__create(): I/O filters can't 
operate on this dataset
major: Invalid arguments to routine
minor: Unable to initialize object
  #010: ../../../src/H5Z.c line 891 in H5Z_can_apply(): unable to apply filter
major: Data filters
minor: Error from filter 'can apply' callback
  #011: ../../../src/H5Z.c line 852 in H5Z__prepare_prelude_callback_dcpl(): 
unable to apply filter
major: Data filters
minor: Error from filter 'can apply' callback
  #012: ../../../src/H5Z.c line 753 in H5Z__prelude_callback(): error during 
user callback
major: Data filters
minor: Error from filter 'can apply' callback
  #013: H5Zzfp.c line 158 in H5Z_zfp_can_apply(): ZFP lib not compiled with 
-DBIT_STREAM_WORD_TYPE=uint8
major: Data filters
minor: Unable to initialize object
H5Dcreate failed at line 405, errno=2 (No such file or directory)
 [ESC[31;01mFAILEDESC[0m]



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

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

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

On Sun, 2024-01-14 at 18:22:16 +0100, Paul Gevers wrote:
> On 14-01-2024 17:43, Guillem Jover wrote:
> >https://wiki.debian.org/Teams/ReleaseTeam/Transitions
> > 
> > but it looks like that one is targeted more to maintainers that start
> > or drive the transitions instead of someone that might upload a
> > package which is part or affected by that transition?
> 
> Indeed. I had the same idea when I replied earlier, but I think we'd need a
> new (wiki) page for this. If we happen to agree here, I'm fine with creating
> an initial version.

I think that would be great, I guess the message from the hook could
give some very basic and generic guidance, and point to this page for
more in-depth explanation of what to do, what else to check etc. But in
any case an initial version sounds good, as that can always be tuned,
or extended/improved later on. :)

Thanks,
Guillem

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Francesco Poli]

On Sat, 13 Jan 2024 22:09:22 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> Quoting Johannes Schauer Marin Rodrigues (2024-01-13 20:18:34)
[...]
> > The problem occurs for Francesco when
> > using either /tmp or /dev/shm as a temporary directly. By default, those two
> > locations should have the desired permission bits set. Lets check whether
> > world-execute permissions are set for all directories up until root. I have
> > this:
> > 
> > $ stat -c "%a %n" / /dev /dev/shm /tmp
> > 755 /
> > 755 /dev
> > 1777 /dev/shm
> > 1777 /tmp
> > 
> > Francesco, what are the world execute permissions on all path components up
> > to /tmp and /devv/shm in your case?

Just like yours:

  $ stat -c "%a %n" / /dev /dev/shm /tmp
  755 /
  755 /dev
  1777 /dev/shm
  1777 /tmp


> 
> scratch what I said in your last mail. Your problem is with the creation of 
> the
> image and not with the temporary chroot directory. What Helmut said is likely
> correct and exactly the problem you are facing. To verify, you could run the
> command you posted initially inside your $HOME directory and show us the
> permission bits of your $HOME. Mine are these:
> 
> stat -c "%a %n" $HOME
> 711 /home/josch
> 
> I assume in your case, you have a 0 at the end of the octal permissions?

Of course, I have!   ;-)

For privacy reasons: I don't want other users to be able to enter my
home directory and to read any file within it that I might have
forgotten with world-readable permissions!

So, the answer to your question is that I indeed have 0 at the end of
the octal permissions:

  $ stat -c "%a %n" $HOME
  700 /home/$USER


OK, please let me understand.

mmdebstrap-autopkgtest-build-qemu creates a chroot within the temporary
directory (TMPDIR=/dev/shm, in my case), but then performs some further
operations (such as mkfs.ext4) on the image file, which is being
created in the directory the user wanted it to be.

Hence, if the user issues the command

  $ cd ~/mysubdir
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--boot=efi sid sid_amd64.img

the final touches to sid_amd64.img will be put with the file in its
intended destination directory, which is /home/${USER}/mysubdir, since
the command-line argument was "sid_amd64.img", a relative path to a
file directly within the current working directory (~/mysubdir).

And these final touches require all parent directories (up to the root
directory) to be world-executable.
In other words, the user would need:

  $ stat -c "%a %n" ~/mysubdir ~ /home /
  771 /home/${USER}/mysubdir
  701 /home/${USER}
  755 /home
  755 /

rather than:

  $ stat -c "%a %n" ~/mysubdir ~ /home /
  770 /home/${USER}/mysubdir
  700 /home/${USER}
  755 /home
  755 /

Is that correct?
Or am I completely off-track?


I tried to do everything within /dev/shm, with:

  $ cd /dev/shm
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=2G --boot=efi sid sid_amd64.img
  [...]
  cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
  I: running special hook: download vmlinuz '/dev/shm/tmp.hhjurdQFhk/kernel'
  I: running special hook: download initrd.img '/dev/shm/tmp.hhjurdQFhk/initrd'
  I: running --customize-hook in shell: sh -c 'mount --bind "$1" "$1/mnt"' exec 
/dev/shm/mmdebstrap.PeOPcJxciV
  I: running --customize-hook in shell: sh -c 'mount --bind "$1/mnt/mnt" 
"$1/mnt/dev"' exec /dev/shm/mmdebstrap.PeOPcJxciV
  I: running --customize-hook in shell: sh -c '/sbin/mkfs.ext4 -d "$1/mnt" -L 
autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 'sid_amd64.img' 
'2G'' exec /dev/shm/mmdebstrap.PeOPcJxciV
  mke2fs 1.47.0 (5-Feb-2023)
  Creating filesystem with 524288 4k blocks and 131072 inodes
  Filesystem UUID: 6d0afa2d-5ee5-4a45-b2ef-1bdb74315ad7
  Superblock backups stored on blocks: 
  32768, 98304, 163840, 229376, 294912
  
  Allocating group tables: done
  Writing inode tables: done
  Creating journal (16384 blocks): done
  Copying files into the device: done
  Writing superblocks and filesystem accounting information: done 
  
  I: running --customize-hook in shell: sh -c 'umount --lazy "$1/mnt"' exec 
/dev/shm/mmdebstrap.PeOPcJxciV
  I: cleaning package lists and apt cache...
  done
  done
  I: removing tempdir /dev/shm/mmdebstrap.PeOPcJxciV...
  I: success in 120.0573 seconds
  determined efi vma alignment as 0x0001000
  determined minimum efi vma offset as 5603221504
  mkfs.fat 4.2 (2021-01-31)
  Checking that no-one is using this disk right now ... OK
  
  Disk sid_amd64.img: 2.13 GiB, 2281718784 bytes, 4456482 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  
  >>> Script header accepted.
  >>> Script header accepted.
  >>> Created a new GPT disklabel (GUID: 39BDEF0B-9FF8-4DB9-921B-FA7A6C2CDB54).
  

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Francesco Poli]

On Fri, 12 Jan 2024 23:39:34 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> could you try applying this patch and then try again:
> 
> --%<-
> --- a/mmdebstrap-autopkgtest-build-qemu
> +++ b/mmdebstrap-autopkgtest-build-qemu
> @@ -302,17 +302,12 @@ if test -n "$SCRIPT"; then
> '--customize-hook=rm -f "$1/userscript"'
>  fi
>  
> -EXT4_OFFSET_BYTES=$(( (FAT_OFFSET_SECTORS + FAT_SIZE_SECTORS) * 512))
> -EXT4_OPTIONS="offset=$EXT4_OFFSET_BYTES,assume_storage_prezeroed=1"
>  set -- "$@" \
> "--customize-hook=download vmlinuz '$WORKDIR/kernel'" \
> "--customize-hook=download initrd.img '$WORKDIR/initrd'" \
> -   '--customize-hook=mount --bind "$1" "$1/mnt"' \
> -   '--customize-hook=mount --bind "$1/mnt/mnt" "$1/mnt/dev"' \
> -   '--customize-hook=/sbin/mkfs.ext4 -d "$1/mnt" -L autopkgtestvm -E 
> '"'$EXT4_OPTIONS' '$IMAGE' '$SIZE'" \
> -   '--customize-hook=umount --lazy "$1/mnt"' \
> +   --format=ext2 \
> "$RELEASE" \
> -   /dev/null
> +   "$IMAGE"
>  
>  test -n "$MIRROR" && set -- "$@" "$MIRROR"
>  test -n "$KEYRING" && set -- "$@" "--keyring=$KEYRING"
> @@ -320,6 +315,9 @@ test -n "$KEYRING" && set -- "$@" "--keyring=$KEYRING"
>  echo "mmdebstrap $*"
>  mmdebstrap "$@" || die "mmdebstrap failed"
>  
> +EXT4_OFFSET_BYTES=$(( (FAT_OFFSET_SECTORS + FAT_SIZE_SECTORS) * 512))
> +fallocate --insert-range --offset=0 --length=$EXT4_OFFSET_BYTES "$IMAGE"
> +
>  unshare -U -r --map-groups=auto chown 0:0 "$IMAGE"
>  chmod "$(printf %o "$(( 0666 - 0$(umask) ))")" "$IMAGE"
>  
> -->%-

I have just tried.

But the result is not clear to me.
The image generation seems to succeed:

  $ cd ~/Downloads
  $ TMPDIR=/dev/shm ./test/mmdebstrap-autopkgtest-build-qemu \
--size=2G --boot=efi sid sid_amd64.img 
  [...]
  cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
  I: running special hook: download vmlinuz '/dev/shm/tmp.3NxJ7PeIpL/kernel'
  I: running special hook: download initrd.img '/dev/shm/tmp.3NxJ7PeIpL/initrd'
  I: cleaning package lists and apt cache...
  done
  done
  I: approximating disk usage...
  I: creating tarball...
  copying from tar archive -
  I: done
  I: removing tempdir /dev/shm/mmdebstrap.Dgp1UFANSi...
  I: success in 125.7682 seconds
  determined efi vma alignment as 0x0001000
  determined minimum efi vma offset as 5603221504
  mkfs.fat 4.2 (2021-01-31)
  Checking that no-one is using this disk right now ... OK
  
  Disk sid_amd64.img: 638.58 MiB, 669594624 bytes, 1307802 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  
  >>> Script header accepted.
  >>> Script header accepted.
  >>> Created a new GPT disklabel (GUID: EEDDF652-1EF3-4E3D-9994-1FD7E76B640A).
  sid_amd64.img1: Created a new partition 1 of type 'EFI System' and of size 
127 MiB.
  sid_amd64.img2: Created a new partition 2 of type 'Linux filesystem' and of 
size 510 MiB.
  Partition #2 contains a ext2 signature.
  sid_amd64.img3: Done.
  
  New situation:
  Disklabel type: gpt
  Disk identifier: EEDDF652-1EF3-4E3D-9994-1FD7E76B640A
  
  Device  Start End Sectors  Size Type
  sid_amd64.img1   2048  262143  260096  127M EFI System
  sid_amd64.img2 262144 1306623 1044480  510M Linux filesystem
  
  The partition table has been altered.
  Syncing disks.
  $ echo $?
  0
  $ ls -lF --si sid_amd64.img 
  -rw-r-xrwx 1 $USER $USER 670M Jan 14 17:21 sid_amd64.img*

However, if I attempt to use the resulting image, autopkgtest
fails:

  $ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out  --summary 
./${SRCPKG}_autopkgtest.summary --apt-upgrade -B ./${SRCPKG}_amd64.changes -- 
qemu --overlay-dir /dev/shm ~/Downloads/sid_amd64.img
  autopkgtest [17:27:29]: starting date and time: 2024-01-14 17:27:29+0100
  autopkgtest [17:27:29]: version 5.32
  autopkgtest [17:27:29]: host ${HOST}; command line: /usr/bin/autopkgtest 
--output-dir './${SRCPKG}_autopkgtest.out' --summary 
'./${SRCPKG}_autopkgtest.summary' --apt-upgrade -B './${SRCPKG}_amd64.changes' 
-- qemu --overlay-dir /dev/shm ${HOME}/Downloads/sid_amd64.img
  qemu-system-x86_64: terminating on signal 15 from pid 115770 
(/usr/bin/python3)
  : failure: timed out waiting for 'login prompt on serial console'
  autopkgtest [17:28:29]: ERROR: testbed failure: unexpected eof from the 
testbed


Was it just a test to investigate further?
Or did it have a chance to produce a usable image?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp3i3hxNJ1Ye.pgp
Description: PGP signature

Bug#1060772: [Python-modules-team] Bug#1060772: python3-jupyterlab: Using node-corepack downloads yarnpkg from Internet

[Roland Mas]

Le 14/01/2024 à 05:20, Yadd a écrit :

Hi,

the patch 0003-Use-system-provided-yarn.js.patch replaces missing
yarn.js by node-corepack. Please keep in mind that
node-corepack/../yarn.js is a wrapper that downloads yarnpkg from
Internet instead of using Debian's one.


Hi Yadd,

I spent some time trying to patch things all around so as to get the 
build to run offline, but I must confess I got myself lost in the maze 
of commands and helper tools. In the end I think my source package tried 
to use the yarn.js provided by node-corepack in some places, the one 
provided by yarnpkg in others, and pkgjs-install-minimal in yet others. 
They all seem subtly incompatible (especially with regards to --offline 
behaviour), and I think it would be better if someone more fluent than 
me in Yarn and related tools were to tackle this problem.


I pushed to Salsa the last state of the packaging before I started 
getting completely lost, any help would be most welcome :-)


Roland.

Bug#1060326: reverse dependencies

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi IOhannes,

there are reverse dependencies that need to be taken care of:


Checking reverse dependencies...
# Broken Depends:
obs-3d-effect: obs-3d-effect
obs-advanced-scene-switcher: obs-advanced-scene-switcher
obs-ashmanix-blur-filter: obs-ashmanix-blur-filter
obs-ashmanix-countdown: obs-ashmanix-countdown
obs-color-monitor: obs-color-monitor
obs-command-source: obs-command-source
obs-downstream-keyer: obs-downstream-keyer
obs-gradient-source: obs-gradient-source
obs-move-transition: obs-move-transition
obs-ptz: obs-ptz
obs-scene-as-transition: obs-scene-as-transition
obs-scene-collection-manager: obs-scene-collection-manager
obs-scene-notes-dock: obs-scene-notes-dock
obs-scene-tree-view: obs-scene-tree-view
obs-source-clone: obs-source-clone
obs-source-copy: obs-source-copy
obs-time-source: obs-time-source
obs-transition-table: obs-transition-table
obs-vintage-filter: obs-vintage-filter
obs-websocket: obs-websocket

# Broken Build-Depends:
looking-glass: libobs-dev
obs-3d-effect: libobs-dev (29 >=)
obs-advanced-scene-switcher: libobs-dev (26.1.2 >=)
obs-ashmanix-blur-filter: libobs-dev
obs-ashmanix-countdown: libobs-dev (29 >=)
obs-color-monitor: libobs-dev (29 >=)
obs-command-source: libobs-dev (29 >=)
obs-downstream-keyer: libobs-dev (29 >=)
obs-gradient-source: libobs-dev (29 >=)
obs-move-transition: libobs-dev (28.0.1 >=)
obs-ptz: libobs-dev
obs-scene-as-transition: libobs-dev (29 >=)
obs-scene-collection-manager: libobs-dev (28.0.1 >=)
obs-scene-notes-dock: libobs-dev (29 >=)
obs-scene-tree-view: libobs-dev (29 >=)
obs-source-clone: libobs-dev (29 >=)
obs-source-copy: libobs-dev (29 >=)
obs-time-source: libobs-dev
obs-transition-table: libobs-dev (29 >=)
obs-vintage-filter: libobs-dev (29 >=)
obs-websocket: libobs-dev (26.1 >=)


In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1060454: reverse dependency

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Anton,

there are reverse dependencies that needs to be taken care of:

Checking reverse dependencies...
# Broken Build-Depends:
pbcopper: libboost1.81-dev
r-cran-openmx: libboost-system1.81-dev


In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Paul Gevers]

Hi,

On 14-01-2024 17:43, Guillem Jover wrote:

   https://wiki.debian.org/Teams/ReleaseTeam/Transitions

but it looks like that one is targeted more to maintainers that start
or drive the transitions instead of someone that might upload a
package which is part or affected by that transition?


Indeed. I had the same idea when I replied earlier, but I think we'd 
need a new (wiki) page for this. If we happen to agree here, I'm fine 
with creating an initial version.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060806: RM: yade [ppc64el i386 s390x] -- ROM; Reducing available archs

[Anton Gladky]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear FTP team,

please remove yade on [ppc64el  i386  s390x].

Thanks

Anton


-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmWkEzwRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wZ6Cg//cGdrVVsF9YBwGq6bhPLbFOH3YwccVmYc
Z0ueERruk0jsw8M2+pzBiMl2PlKCQWrzRRfmdS1Qn0dY0H/vauOOr2kiyC0Fjxso
Fp1tliCdlAgSySlvxPHwS1SKyZvah/ebaSE9XCMtlH4SaNLz+MhnoBENsDhAkBVl
pCT37sB4s67xXF08m4BZL/1Z+V3ePFQJFhfq03NWHXISbukX96B0NO8Rff7b53GL
NJ6OLq6md4ttJUxPPxN9HX+UoBNkO8ND4dhmfLAaz4T7izd2o1+aR5puuFfeSme8
IWbPaRXPNdBkxgC/DPIHCY9wT/vpQrEXt6U0FKfDfRcUXetA1SXKvdLcP/jlJu6R
4/jTjqdOcF4sK0pXTLYpOMI3FPKweKxaTcRzAYLUiWsBCRFot1ugdBmWJjpqOk12
isODVNFFg8AHAnsjvXtqbACKrJB5kQnvbUHE/R59NPNs+ykcmnWzuPYQVGyX9MUP
XZF7cFHlg8/3FHxtJNNEOlbQXOhV6DHh3UeYR/EmAOK3xxZHqcdOzVSDQzf8Qe30
07ppwUNYRpKkXIRNT6+7h7rw3xxfKmBT4rH+iDcPSGnGmEpd3dSThhpg07oQ0+Yp
4k4/N/xn0+YlQsW4oWrbzRaHa40yokW7kBn1BaAEUQOfbO6Ar3y0Nu3qdSaQlxSo
EfNYQzTwWQE=
=7uCp
-END PGP SIGNATURE-

Bug#1059315: tinyxml: CVE-2023-34194 CVE-2023-40462 CVE-2023-40458

[Salvatore Bonaccorso]

Hi,

On Sun, Jan 14, 2024 at 04:41:00PM +, Bastien Roucariès wrote:
> On Sun, 31 Dec 2023 07:14:26 +0100 Salvatore Bonaccorso  
> wrote:
> Hi Guilhem, hi Moritz,
> > Hi Guilhem, hi Moritz,
> > 
> > On Sat, Dec 30, 2023 at 11:26:02PM +0100, Guilhem Moulin wrote:
> > > On Sat, 30 Dec 2023 at 21:02:16 +0100, Felix Geyer wrote:
> > > > There are some minor changes staged in the salsa git repo. It would be 
> > > > good
> > > > to include them as well. Feel free to push the patch to git and upload.
> > > > Alternatively a merge request works as well of course.
> > > 
> > > Thanks for the fast response!  Tagged and uploaded.
> > > 
> > > Security team, if you agree with my assessment that CVE-2023-40462 is a
> > > duplicate of CVE-2023-34194 (but for a separate project that embeds
> > > libxml) and that CVE-2023-40458 is a duplicate of CVE-2021-42260 (but
> > > for a separate project that embeds libxml), I can propose debdiffs for
> > > bullseye and bookworm.
> > 
> > I think the former is correct but still bit biased. We initially had
> > exactly CVE-2023-40462 as NFU and CVE-2023-34194 for tinyxml. I have
> > now commmited
> > https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/7e507c932b999df48f808969c00f07a638e3357b
> > hich does match my understanding for this doubled CVE assignment. The
> > document is actually not very very clear. It still metnions
> > CVE-2023-40462 but does not consistently say "TinyXML as used in".
> > Still hope we can agree the above matches our all udnerstanding.
> > Moritz given you updated back then the entry from NFU and tinyxml, if
> > you still strongly disagree I will revert the above, but I tried to
> > explain my reasoning in the commit message.
> > 
> > Now for CVE-2023-40458 I'm  not sure. Looking back at the references
> > for CVE-2021-42260 and the issue report at
> > https://sourceforge.net/p/tinyxml/bugs/141/ this sensibly match the
> > description for CVE-2023-40458, but will want to see if Moritz has an
> > additional input here.
> > 
> > If this is the case we either have the otpion to mark it really as
> > duplicate (and request a reject from MITRE) or it is again just a
> > ALEOS issue "... tinyxml as used in". Again the table here is not very
> > clear in the report, for the CVE-2023-34194 and CVE-2023-40462 there
> > were explicitly listed the two CVEs with brackeds including the
> > product in the the table, but this is not the case for CVE-2023-40458.
> > 
> > Moritz?
> 
> Any news of this triagging ?

I contacted the involved CNA and they are investigting if that needs
to be considered a dupliate (for CVE-2023-40458 and CVE-2021-42260).

CVE-2023-40462 was already updated.

Regards,
Salvatore

Bug#1058127: python-mpiplus: FTBFS: AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?

[Yogeswaran Umasankar]

Hi,
I created a patch for fixing AttributeError: module 'configparser' has
no attribute 'SafeConfigParser'. In the process I have updated it to the
latest upstream too. I’ve attached the debdiff for you to check out.
Cheers!
diff -Nru python-mpiplus-0.0.1/debian/changelog 
python-mpiplus-0.0.2/debian/changelog
--- python-mpiplus-0.0.1/debian/changelog   2022-11-05 14:33:23.0 
+
+++ python-mpiplus-0.0.2/debian/changelog   2024-01-14 01:30:00.0 
+
@@ -1,3 +1,12 @@
+python-mpiplus (0.0.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream 0.0.2.
+  * Patch for configparser and version issue. (Closes: #1058127)
+  * Included d/tests/pytest to avoid __file__ attribute issues.
+
+ -- Yogeswaran Umasankar   Sun, 14 Jan 2024 01:30:00 +
+
 python-mpiplus (0.0.1-2) unstable; urgency=medium
 
   * Add autopkgtest.
diff -Nru 
python-mpiplus-0.0.1/debian/patches/001_AttributeError-fix-py312.patch 
python-mpiplus-0.0.2/debian/patches/001_AttributeError-fix-py312.patch
--- python-mpiplus-0.0.1/debian/patches/001_AttributeError-fix-py312.patch  
1970-01-01 00:00:00.0 +
+++ python-mpiplus-0.0.2/debian/patches/001_AttributeError-fix-py312.patch  
2024-01-14 01:30:00.0 +
@@ -0,0 +1,30 @@
+Description: Fix for AttributeError: module 'configparser'
+ Revising configparser did not fix the error. Seems mpiplus/_version.py is not
+ compatible with latest setuptools. Time being fix is to set version number in 
setup.py
+Author: Yogeswaran Umasankar 
+Last-Update: 2024-01-14
+
+--- a/versioneer.py
 b/versioneer.py
+@@ -339,9 +339,9 @@ def get_config_from_root(root):
+ # configparser.NoOptionError (if it lacks "VCS="). See the docstring at
+ # the top of versioneer.py for instructions on writing your setup.cfg .
+ setup_cfg = os.path.join(root, "setup.cfg")
+-parser = configparser.SafeConfigParser()
++parser = configparser.ConfigParser()
+ with open(setup_cfg, "r") as f:
+-parser.readfp(f)
++parser.read_file(f)
+ VCS = parser.get("versioneer", "VCS")  # mandatory
+ 
+ def get(parser, name):
+--- a/setup.py
 b/setup.py
+@@ -13,7 +13,7 @@ setup(
+ author='Chodera Lab',
+ description=DOCLINES[0],
+ long_description="\n".join(DOCLINES[2:]),
+-version=versioneer.get_version(),
++version='0.0.2',
+ cmdclass=versioneer.get_cmdclass(),
+ license='MIT',
diff -Nru python-mpiplus-0.0.1/debian/patches/series 
python-mpiplus-0.0.2/debian/patches/series
--- python-mpiplus-0.0.1/debian/patches/series  1970-01-01 00:00:00.0 
+
+++ python-mpiplus-0.0.2/debian/patches/series  2024-01-14 01:30:00.0 
+
@@ -0,0 +1 @@
+001_AttributeError-fix-py312.patch
\ No newline at end of file
diff -Nru python-mpiplus-0.0.1/debian/tests/control 
python-mpiplus-0.0.2/debian/tests/control
--- python-mpiplus-0.0.1/debian/tests/control   2022-10-21 06:30:12.0 
+
+++ python-mpiplus-0.0.2/debian/tests/control   2024-01-14 01:30:00.0 
+
@@ -1,4 +1,4 @@
-Test-Command: pytest-3
+Tests: pytest
 Depends:
  python3-pytest,
  @,
diff -Nru python-mpiplus-0.0.1/debian/tests/pytest 
python-mpiplus-0.0.2/debian/tests/pytest
--- python-mpiplus-0.0.1/debian/tests/pytest1970-01-01 00:00:00.0 
+
+++ python-mpiplus-0.0.2/debian/tests/pytest2024-01-14 01:30:00.0 
+
@@ -0,0 +1,7 @@
+#!/bin/bash
+set -e
+
+for py in $(py3versions --supported 3> /dev/null)
+do
+$py -m pytest -v mpiplus/tests
+done
diff -Nru python-mpiplus-0.0.1/devtools/conda-recipe/meta.yaml 
python-mpiplus-0.0.2/devtools/conda-recipe/meta.yaml
--- python-mpiplus-0.0.1/devtools/conda-recipe/meta.yaml2018-10-24 
21:16:03.0 +
+++ python-mpiplus-0.0.2/devtools/conda-recipe/meta.yaml2023-04-27 
17:21:36.0 +
@@ -17,6 +17,7 @@
   run:
 - python
 - numpy >=1.11
+- mpi4py
 
 test:
   requires:
diff -Nru python-mpiplus-0.0.1/docs/installation.rst 
python-mpiplus-0.0.2/docs/installation.rst
--- python-mpiplus-0.0.1/docs/installation.rst  2018-10-24 21:16:03.0 
+
+++ python-mpiplus-0.0.2/docs/installation.rst  2023-04-27 17:21:36.0 
+
@@ -6,7 +6,8 @@
 Installing via `conda`
 ==
 
-mpiplus is not currently available via `conda`
+.. code-block:: bash
+   $ conda install -c conda-forge mpiplus
 
 
 Development Build
diff -Nru python-mpiplus-0.0.1/environment.yml 
python-mpiplus-0.0.2/environment.yml
--- python-mpiplus-0.0.1/environment.yml1970-01-01 00:00:00.0 
+
+++ python-mpiplus-0.0.2/environment.yml2023-04-27 17:21:36.0 
+
@@ -0,0 +1,12 @@
+name: mpiplus
+channels:
+  - conda-forge
+dependencies:
+  - mpi4py
+  - numpy >=1.11
+  - python
+  # testing
+  - coverage
+  - pytest
+  - pytest-cov
+  - pytest-xdist
diff -Nru python-mpiplus-0.0.1/.github/workflows/ci.yaml 
python-mpiplus-0.0.2/.github/workflows/ci.yaml
--- 

Bug#1060753: exiftags: CVE-2023-50671

[Salvatore Bonaccorso]

Hi,

On Sun, Jan 14, 2024 at 03:54:59PM +0100, László Böszörményi wrote:
> Hi Salvatore,
> 
> On Sat, Jan 13, 2024 at 5:51 PM Salvatore Bonaccorso  
> wrote:
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>  I have fixed some issues, but as I see, not the root causes. Then
> with my fixes I found that the reproducers may crash exiftags later by
> other issues.
> Contacted upstream if he plans to fix these by himself. Waiting for his reply.

Sounds like a good plan if there is (still) some activity from
upstream. I do not think the isuses are particularly urgent, so take
the time it needs to check with upstream availability.

Regards,
Salvatore

Bug#1059315: tinyxml: CVE-2023-34194 CVE-2023-40462 CVE-2023-40458

[Bastien Roucariès]

On Sun, 31 Dec 2023 07:14:26 +0100 Salvatore Bonaccorso  
wrote:
Hi Guilhem, hi Moritz,
> Hi Guilhem, hi Moritz,
> 
> On Sat, Dec 30, 2023 at 11:26:02PM +0100, Guilhem Moulin wrote:
> > On Sat, 30 Dec 2023 at 21:02:16 +0100, Felix Geyer wrote:
> > > There are some minor changes staged in the salsa git repo. It would be 
> > > good
> > > to include them as well. Feel free to push the patch to git and upload.
> > > Alternatively a merge request works as well of course.
> > 
> > Thanks for the fast response!  Tagged and uploaded.
> > 
> > Security team, if you agree with my assessment that CVE-2023-40462 is a
> > duplicate of CVE-2023-34194 (but for a separate project that embeds
> > libxml) and that CVE-2023-40458 is a duplicate of CVE-2021-42260 (but
> > for a separate project that embeds libxml), I can propose debdiffs for
> > bullseye and bookworm.
> 
> I think the former is correct but still bit biased. We initially had
> exactly CVE-2023-40462 as NFU and CVE-2023-34194 for tinyxml. I have
> now commmited
> https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/7e507c932b999df48f808969c00f07a638e3357b
> hich does match my understanding for this doubled CVE assignment. The
> document is actually not very very clear. It still metnions
> CVE-2023-40462 but does not consistently say "TinyXML as used in".
> Still hope we can agree the above matches our all udnerstanding.
> Moritz given you updated back then the entry from NFU and tinyxml, if
> you still strongly disagree I will revert the above, but I tried to
> explain my reasoning in the commit message.
> 
> Now for CVE-2023-40458 I'm  not sure. Looking back at the references
> for CVE-2021-42260 and the issue report at
> https://sourceforge.net/p/tinyxml/bugs/141/ this sensibly match the
> description for CVE-2023-40458, but will want to see if Moritz has an
> additional input here.
> 
> If this is the case we either have the otpion to mark it really as
> duplicate (and request a reject from MITRE) or it is again just a
> ALEOS issue "... tinyxml as used in". Again the table here is not very
> clear in the report, for the CVE-2023-34194 and CVE-2023-40462 there
> were explicitly listed the two CVEs with brackeds including the
> product in the the table, but this is not the case for CVE-2023-40458.
> 
> Moritz?

Any news of this triagging ?

Bastien
> 
> Regards,
> Salvatore
> 
> 


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

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

On Sun, 2024-01-14 at 10:22:21 +0100, Paul Gevers wrote:
> On 10-01-2024 02:23, Guillem Jover wrote:
> > I've had for a while a new hook for dupload that adds a transitions
> > check for Debian hosts, for sourceful uploads targeting unstable (to
> > avoid disrupting buildd or porter uploads, or uninteresting suites).
> > I've just finished polishing it, and the main lingering question I've
> > had all along has been whether you think this would actually be useful
> > and/or desired at all, see below.
> > 
> > The hook is currently using
> > https://release.debian.org/transitions/export/packages.yaml, and
> > prompting in case that source package is part of any ongoing
> > transition.
> 
> Cool.
> 
> > I wondered also whether checking
> > https://ftp-master.debian.org/transitions.yaml would be useful,
> > but I'm not sure whether that is or has ever been used?
> 
> It still works, but it's hardly used. I do have some vague ideas to use it
> again in the future, but that's not going to happen soon I guess.

Ok, then, I might leave this as a comment reference as a potential
future source in case this ever gets used.

> > So I guess my questions would be whether you think this is helpful or
> > useful at all?
> 
> Yes, I do.

Ok, great! :)

> > If so, whether the criteria is adequate or it needs to
> > be changed? Whether this should be a prompt, or maybe only an info or
> > warning? And any other comment or suggestion you might have!
> 
> I'm mostly wondering if the information shown is enough to help people. I'm
> actually surprised how many people don't know how transitions work. What is
> your opinion on the length of the text you could provide? Maybe a link to a
> wiki page with more info particularly for this case?

Ah, right, having a longer description and an external reference would
actually be in line with other similar notices such as:

  https://git.dpkg.org/cgit/dpkg/dupload.git/tree/hooks/debian-source-only#n73
  https://git.dpkg.org/cgit/dpkg/dupload.git/tree/hooks/debian-security-auth#n23

If you have some proposed wording, I'll gladly incorporate that,
otherwise I'll try to come up with something and post it here for
review, with a reference to at least:

  https://release.debian.org/transitions/

and perhaps to:

  https://wiki.debian.org/Teams/ReleaseTeam/Transitions

but it looks like that one is targeted more to maintainers that start
or drive the transitions instead of someone that might upload a
package which is part or affected by that transition?

> Maybe Sebastian can comment on how often he sees interfering uploads to
> judge if it should be a warning or a prompt. If you make this only a
> warning, what are the options of the uploader, canceling?

Hmm, right, just a warning would probably not be very helpful, and if
it gets a pause (with no prompt) then in effect that's kind of a prompt
anyway as you can always Ctrl-C or similar. So probably a prompt might
be the best option, but it's not clear whether that will end up being
very annoying. Probably it would need some easy way to disarm it, say
an env var or similar, instead of requiring to change the config.

> PS: if you're happy with this, should we file wish list bugs against dput
> and dput-ng too?

I think that would be nice, once the above details are more clear. :)

Thanks,
Guillem

Bug#1051018: spectrwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Andrea Bolognani]

On Tue, Jan 09, 2024 at 11:25:50PM +0100, Andrea Bolognani wrote:
> On Tue, Jan 09, 2024 at 10:55:38AM +, Simon McVittie wrote:
> > It's up to you whether to upstream this part. I would personally say
> > that any reason we give for wanting this change in Debian is probably
> > equally valid as a reason for wanting this change upstream. The line
> > I've been drawing for whether to open bugs like this one is that if a
> > window manager installs into /usr/share/xsessions/, then it's declaring
> > itself to be a (very small) desktop environment, therefore it should do
> > "desktop environment" things like expressing a preference for an
> > xdg-desktop-portal backend.
> 
> I'll think about it. Upstream might be reticent to accept such a
> change, so I'll definitely start with the DesktopNames part, which
> shouldn't be controversial, and then possibly follow up with the
> portal part.

Patches for the DesktopNames part submitted upstream.

https://github.com/conformal/spectrwm/pull/556

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1060805: ITP: pusimp -- prevent user-site imports

[Francesco Ballarin]

Package: wnpp
Severity: wishlist
Owner: Francesco Ballarin 
X-Debbugs-Cc: debian-de...@lists.debian.org, francesco.balla...@unicatt.it

* Package name: pusimp
  Version : 0.1.0
  Upstream Contact: Francesco Ballarin 
* URL : https://github.com/python-pusimp/pusimp
* License : MIT
  Programming Lang: Python
  Description : prevent user-site imports

pusimp is a python library to prevent user-site imports of specific
dependencies of a package. The typical scenario for using pusimp is
in combination with a system manager (e.g., apt for Debian), to prevent
dependencies from being loaded from user-site instead of the location
provided by the system manager.

We designed pusimp with in mind the specific use case of the FEniCS
project. It happens often that users post messages at the FEniCS discourse
forum https://fenicsproject.discourse.group/ asking why their ubuntu/debian
installation is not working correctly, and several times this is due to the
presence of user-made installation attempts in user-site locations.
We thus initially plan to use pusimp in the python3-dolfin and
python3-dolfinx packages, but the logic behind pusimp is purposely
simple and general.

The package will be maintained at 
https://salsa.debian.org/python-team/packages/pusimp
in collaboration with my sponsor Drew Parsons and the Debian Python Team

Bug#910664: Acknowledgement (ghc: ghc package can no longer be cross-compiled)

[Ilias Tsitsimpis]

Hi Helmut,

Happy new year!

On Sat, Dec 16, 2023 at 07:34PM, Helmut Grohne wrote:
> I fear this is misleadingly imprecise. If I understand what you write
> later correctly, we always build GHC for the same architecture (i.e. we
> ask configure for build=host), but we may opt for a cross compiler (i.e.
> target!=host). When the ghc Debian package is asked to cross compile,
> what we ask configure instead is natively building a cross compiler. Do
> you confirm?

Yes I confirm. Up until now, this was the way to get both a cross
compiler (the STAGE1_TOOL compiler) and a cross-compiled GHC (the
STAGE2_TOOL compiler) [1], and we installed in the Debian package the
STAGE2_TOOL compiler.

[1] 
https://gitlab.haskell.org/ghc/ghc/-/wikis/building/cross-compiling#terminology-and-background

This changed with the new build-system, and now we get only a cross
compiler both from stage1 and stage2. One can of course argue that this
is the expected output (given we passed build=host) :)

> This is still quite confusing to me. I suppose stage0 is /usr/bin/ghc.
> Do you confirm? Then there should be a _build/stage0 containing the
> stage1 compiler. That stage1 compiler probably is a simple native build
> of the ghc sources at hand, which means that its binary may have a
> different ABI from what the sources expect. That stage1 will be unable
> to use packages, but it can be used to build ghc again. Is that also
> correct? Then that stage1 is used to build a stage2 where the ABI of the
> binary matches the behaviour and this can be used with packages.

> Do I understand correctly that (currently) stage1 is a simple native
> build of the current ghc sources where the binary uses the ABI that
> /usr/bin/ghc generated and doesn't necessarily match the sources? Do I
> also understand that stage2 (stored in _build/stage1) the is a cross
> compiler generating code for $DEB_HOST_ARCH and runnable on
> $DEB_BUILD_ARCH using the ABI given by the current ghc sources?

Yes on all of the above, this is my understanding as well.

> At no point do we (currently) actually cross build using that stage2. Do
> you also confirm?

No we don't. I have tried doing that by:

1. Trying to build stage 3, but the resulting compiler was still a cross
compiler, see [2].

2. Trying to use the resulting stage 2 compiler as a bootstrap compiler
(stage 0) for a new build, see [3].

Both of the above approaches failed. This is where we are currently
blocked, and I admit I haven't tried to move past this.

[2] https://gitlab.haskell.org/ghc/ghc/-/issues/23975#note_526549
[3] https://gitlab.haskell.org/ghc/ghc/-/issues/23975#note_530085

> As far as I can see, the name "STAGE1_TOOL" is misleading and it should
> be called "STAGE2_TOOL" instead. Do you concur? Then a STAGE2_TOOL
> always is something that runs on the build machine and operates on
> $DEB_HOST_ARCH, which seems just about right, no? STAGE2_TOOL not
> necessarily is something we'd want to install into a .deb though. Do you
> agree?

Yes I agree.

> > Calling 'ghc-pkg recache' here is wrong. I suppose we can skip this step
> > if we are cross-compiling (so we can reach the next failure).
> 
> Can you elaborate on why we do not want to reset the package cache here?

What we want to do here is to be able to run ghc-pkg and query the GHC
database for the library ABIs. But this needs to be done for the
HOST/TARGET architecture. I am not really sure if running the
STAGE2_TOOL ghc-pkg here (which runs on the BUILD architecture) will
produce the same ABIs as the STAGE3_TOOL ghc-pkg (if we had one).

> Most of the time, this is true. However, we can also cross build from
> amd64 to i386 or arm64 to armhf (which gets us 64bit address space
> during build) and we can build with a qemu-user-static installed. In
> both cases, we can actually run tests. Therefore the decision whether to
> run tests is left to the builder. Both sbuild and pbuilder default to
> not running tests by automatically adding nocheck to DEB_BUILD_OPTIONS
> when you ask for a cross build. This whole block is conditional to
> DEB_BUILD_OPTIONS not containing nocheck, so the only way this is
> relevant is when a builder overrides this default and thus explicitly
> requests running tests despite performing a cross build. And in that
> case, the proposed patch should make sense, no? Your proposed skipping
> already is implemented via nocheck.

You are right, sbuild by default will pass DEB_BUILD_OPTIONS=nocheck so
no need to explicitly disable our tests. And if one explicitly asks for
them, we can definitely find a way to support this.

> Thank you for considering "my way". You have made a good case for
> understanding the end-to-end process and you definitely convinced me
> that this is necessary. Often times, the incremental process just works
> and here it likely is not ideal, but the discussion still seems to
> advance us and I would be more than happy to continue and improve our
> understanding to reach that state where we make that 

Bug#1050314: Sigstore rekor in Debian

[Simon Josefsson]

Hi

Just a heads-up that I am working on packaging rekor for Debian, current
effort is under way here:

https://salsa.debian.org/jas/golang-github-sigstore-rekor

I will merge it here eventually:

https://salsa.debian.org/go-team/packages/golang-github-sigstore-rekor

It seems like a great number of dependencies are needed, and I'm
chaising them down one by one, although for several it raises new
problems since Debian has old versions of the package and it isn't clear
to me wheter to update the old packages are create new packages for
them, especially since some of them have been renamed so the golang
package names no longer match.

I'm cc'ing both bugs related to this, I think they refer to the same
package really.

/Simon


signature.asc
Description: PGP signature

Bug#1060803: gnome-software: Please don't depend on `software-properties-gtk`

[Matthias Klumpp]

Am So., 14. Jan. 2024 um 15:27 Uhr schrieb Arnaud Ferraris
:
> [...]
> GNOME Software does not depend on the Software Properties app.
> Installing it changes the way GNOME Software works (for example, with
> the source settings).
> [...]

That is false, GNOME Software on Debian does depend on s-p-gtk. The
reason this was implemented is that the PackageKit repository
preferences dialog does not cover all the options needed on a Debian
system, and especially not when used on an Ubuntu system.
Instead of giving users an inferior and possibly broken way of
adjusting package sources, we'd rather provide them with a proper
selection dialog.

I have since fixed a lot of PackageKit issues which caused the native
repo dialog in GS to be an abysmal experience, but tbh, it's still not
a great experience, and it doesn't cover all the features and context
s-p-g provides (that point is a bit less relevant to Debian now than
it is for Ubuntu, and the latter is dropping GS entirely from its
base, so the point for it is certainly weaker than years ago, but I
think it still stands).

> [...]
> For that reason, some people may not want it installed. And, in my
> opinion, Debian developers should not add dependencies to software they
> did not create. If a dependency should be added to GNOME Software, it
> should be done by the GNOME developers.

Certainly not, Debian's job is to integrate software to form a
cohesive operating system, and adding/removing dependencies, changing
compiler flags that affect dependency selection and applying
integration patches is an integral part of that.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1059796: tilda: fails to respond to show/hide command depending on active application

[Sebastian Geiger]

This is a known issue that will be resolved once the D-Bus enabled
update of tilda will reach the distribution. I am planning a new upload
in the next weeks that will ship a new tilda version.

In the mean time, there are two workarounds:

* one is to build tilda from source if you are on Wayland as the current
master branch of tilda already has the D-Bus support.
* another one is to use an Xorg session instead of Wayland.


On 1/1/24 15:48, activityworkshop wrote:

Package: tilda
Version: 1.5.4-1
Severity: normal
X-Debbugs-Cc: deb...@activityworkshop.net

Dear Maintainer,

After upgrade from old-stable to stable, Tilda no longer reliably responds to 
the show/hide shortcut (in my case F12).
If Firefox is running and currently has the focus, then pressing F12 pulls down 
Tilda as expected.  Note that Firefox
would also like to intercept the F12 key but Tilda receives it and acts 
correctly.
If Firefox is running but minimized (no active application), then pressing F12 
does nothing.  Presumably Tilda does not receive the keypress.
If Firefox is running and visible but gedit has the focus, then pressing F12 
does nothing.
If Tilda is pulled-down but gedit has the focus, then pressing F12 does not 
close Tilda as expected.
Changing the configuration to use F2 has no effect on this behaviour, it's not 
specific to F12.
Other applications behave the same as gedit so that Tilda won't open (for 
example Calculator, Files, Meld);
some applications behave the same as Firefox so that Tilda correctly opens (for 
example Gimp, VLC).
Deleting the configuration file(s) under ~/.config/tilda/ and re-setting the 
key has no effect.
All of this worked fine before the upgrade.

Desktop is standard Gnome, using a single monitor which is identified by Tilda as "0 
(XWAYLAND0)".


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

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

Versions of packages tilda depends on:
ii  libc62.36-9+deb12u3
ii  libconfuse2  3.3-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libvte-2.91-00.70.6-2~deb12u1
ii  libx11-6 2:1.8.4-2+deb12u2

tilda recommends no packages.

tilda suggests no packages.

-- no debconf information

Bug#1060753: exiftags: CVE-2023-50671

[GCS]

Hi Salvatore,

On Sat, Jan 13, 2024 at 5:51 PM Salvatore Bonaccorso  wrote:
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
 I have fixed some issues, but as I see, not the root causes. Then
with my fixes I found that the reproducers may crash exiftags later by
other issues.
Contacted upstream if he plans to fix these by himself. Waiting for his reply.

Regards,
Laszlo/GCS

Bug#1030223: gobject-introspection: make cross-compilation possible

[Simon McVittie]

On Thu, 11 Jan 2024 at 14:15:50 +0100, Helmut Grohne wrote:
> On Thu, Jan 11, 2024 at 12:08:53PM +, Simon McVittie wrote:
> > The ${GNU_TYPE}-g-ir-compiler wrapper script (which happens to be written
> > in Python, the same as the upstream g-ir-compiler) explicitly tells
> > g-ir-compiler to run the "dumper" binary under qemu-user if it detects
> > that the Python architecture is not one that can run the host architecture.
> 
> Do I understand correctly that cross building to i386 on amd64 would
> cause this wrapper to run the i386 binary in qemu?

Until today: no, but only because there was a hard-coded special case
for the common i386-on-amd64. Cross-building to armhf on arm64, or to
powerpc on ppc64, *would* have used qemu automatically, even if not
actually necessary.

In the version I hope to upload today: no, because I've added auto-detection
of whether we can execute host binaries as you suggested.

> I agree with the approach taken, but I think g-ir-compiler could be more
> clever. Rather than assume that the host architecture is not runnable
> when it differs from the build architecture, could it detect that? A
> simple way would be invoking arch-test ${DEB_HOST_ARCH}, but it can as
> well compile and run trivial program (as autoconf does all the time).

I'm testing an implementation of that. arch-test needs specific
porting for each new architecture because of how it's written,
so I'm not intending to use that directly, but it's easy to add a
precompiled arch-test-like binary of the host architecture to the
gobject-introspection binary package, and have the wrapper script try
to invoke it and see what happens.

> > I would tend to think that qemu dependencies in Build-Depends are
> > appropriate if and only if it's the source package that is making the
> > choice to invoke qemu.
> 
> The argument is reasonable. Your way of looking at it also lowers
> maintenance cost as we don't have to modify tons of B-D.

Right - if we decide that qemu is not so good for some pair of (real,
emulated) architectures, and actually we'd prefer to use some other
user-space emulator like FEX or box86 for a particular pair, I don't
want to have to make new sourceful changes in all 238 source packages[1]
that produce public GIR/typelibs, plus however many packages produce
private GIR/typelibs. It seems like it would be better to only change
src:gobject-introspection and O(1) other packages.

We will want to make sourceful changes in all of those 238 packages
eventually, to replace libgirepository1.0-dev (which cannot be M-A:same
without breaking some dependent packages) with a cross-friendly
alternative, but I only want to do that once per source package in
most cases.

For some of those packages (the ones where GIR is optional, like
src:flatpak, but not the ones where GIR is required functionality, like
src:gnome-shell) we will eventually also want to add support for ,
and maybe split out gir1.2-NAMESPACE-VERSION-dev into its own binary
package so that the nogir build profile can be a reproducible/"safe"
one - but, again, that should be something we can do once per source
package, not something that we have to repeat every time an implementation
detail changes.

[1] grep-dctrl -FPackage-List -sPackage -e --pattern='gir1\.2-' \
/var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_source_Sources \
| sort -u | wc -l

> I am wondering
> about a middle-ground of having a package can-run-arch being M-A:same
> and having a maintainer script that validates the property. Then you
> could Depends: qemu-user | can-run-arch  (expressing the preference for
> qemu-user) while any builder could still --add-depends=can-run-arch to
> opt out of qemu.

If the cross-toolchain team implements such a thing, it would be fine to
add it as an alternative dependency in a later version. I'd prefer not to
do that while it's still hypothetical, because until there's a concrete
implementation we'd have no way to test it.

Another option (which could perhaps be combined with this) would be for
the cross-toolchain team to define an interface to "the preferred way to
run executables from architecture A if they can't be run directly", and
then gobject-introspection could try that in preference to qemu. Meson
calls this an "EXE wrapper", which seems like as good a name as any other.

Here's a straw-man design, assuming for the sake of concrete examples that
the build architecture is amd64 and the host architecture is riscv64:

- gobject-introspection:riscv64 Depends: cross-exe-wrapper | can-run-arch

- cross-exe-wrapper:riscv64 is M-A:same and Depends on
  cross-exe-wrapper-riscv64-linux-gnu

- cross-exe-wrapper-TUPLE is M-A:foreign (or perhaps a virtual
  package provided by cross-exe-wrapper-bin, which is M-A:foreign)

- For the trivial case, cross-exe-wrapper-TUPLE:ARCH, where TUPLE and
  ARCH match, contains a /usr/bin/TUPLE-exe-wrapper which just runs its
  arguments as-is
  (like a trivial shell script that just does an 'exec 

Bug#1060804: hickle: failing tests with h5py 3.10

[Drew Parsons]

Source: hickle
Version: 5.0.2-7
Severity: serious
Justification: debci

h5py 3.10 is triggering test failure in hickle

 54s  test_H5NodeFilterProxy 

 54s 
 54s h5_data = 
 54s 
 54s def test_H5NodeFilterProxy(h5_data):
 54s """
 54s tests H5NodeFilterProxy class. This class allows to temporarily 
rewrite
 54s attributes of h5py.Group and h5py.Dataset nodes before being 
loaded by
 54s hickle._load method.
 54s """
 54s 
 54s # load data and try to directly modify 'type' and 'base_type' 
Attributes
 54s # which will fail cause hdf5 file is opened for read only
 54s h5_node = h5_data['somedata']
 54s pytest_errclass = KeyError if h5py.__version__ >= '3.9.0' else 
OSError
 54s with pytest.raises(pytest_errclass):
 54s try:
 54s >   h5_node.attrs['type'] = pickle.dumps(list)
 54s 
 54s 
/tmp/autopkgtest-lxc.72qwkxrs/downtmp/build.c7h/src/hickle/tests/test_01_hickle_helpers.py:127:
 
 54s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ 
 54s h5py/_debian_h5py_serial/_objects.pyx:54: in 
h5py._debian_h5py_serial._objects.with_phil.wrapper
 54s ???
 54s h5py/_debian_h5py_serial/_objects.pyx:55: in 
h5py._debian_h5py_serial._objects.with_phil.wrapper
 54s ???
 54s /usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/attrs.py:104: 
in __setitem__
 54s self.create(name, data=value)
 54s /usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/attrs.py:200: 
in create
 54s h5a.delete(self._id, name)
 54s h5py/_debian_h5py_serial/_objects.pyx:54: in 
h5py._debian_h5py_serial._objects.with_phil.wrapper
 54s ???
 54s h5py/_debian_h5py_serial/_objects.pyx:55: in 
h5py._debian_h5py_serial._objects.with_phil.wrapper
 54s ???
 54s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ 
 54s 
 54s >   ???
 54s E   KeyError: 'Unable to delete attribute (no write intent on file)'
 54s 
 54s h5py/_debian_h5py_serial/h5a.pyx:145: KeyError


Sounds like an issue that should be raised upstream,
unless it just means that hickle needs rebuilding against h5py 3.10.



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

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

Bug#1060803: gnome-software: Please don't depend on `software-properties-gtk`

[Arnaud Ferraris]

Package: gnome-software
Version: 45.2-1
Severity: wishlist
X-Debbugs-Cc: juliannfair...@protonmail.com

[Posting this bug report on behalf of juliannfair...@protonmail.com]

Dear Maintainer,

GNOME Software does not depend on the Software Properties app. 
Installing it changes the way GNOME Software works (for example, with 
the source settings).


For that reason, some people may not want it installed. And, in my 
opinion, Debian developers should not add dependencies to software they 
did not create. If a dependency should be added to GNOME Software, it 
should be done by the GNOME developers.


I suggest that `software-properties-gtk` be changed from a dependency of 
`gnome-software` to a recommended package.


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.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 gnome-software depends on:
pn  appstream
pn  apt-config-icons 
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b1
pn  gnome-software-common
ii  gsettings-desktop-schemas45.0-2
ii  libadwaita-1-0   1.4.2-1+b1
ii  libappstream51.0.1-3
ii  libc62.37-13
ii  libcairo21.18.0-1+b1
ii  libfwupd21.9.11-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libglib2.0-0 2.78.3-1
ii  libgtk-4-1   4.12.4+ds-3
pn  libgtk3-perl 
ii  libgudev-1.0-0   238-3
ii  libjson-glib-1.0-0   1.8.0-2
ii  libmalcontent-0-00.11.1-1+b1
pn  libpackagekit-glib2-18   
ii  libpango-1.0-0   1.51.0+ds-3
ii  libpolkit-gobject-1-0123-3
ii  libsoup-3.0-03.4.4-2
ii  libxmlb2 0.3.14-2
pn  packagekit   
pn  software-properties-gtk  

Versions of packages gnome-software recommends:
ii  fwupd  1.9.11-1

Versions of packages gnome-software suggests:
pn  apt-config-icons-hidpi 
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-snap 

Bug#1053281: linux-image-6.5.0-1-amd64: Debian does not boot at cold start on kernel 6.5.0-1-amd64 on Intel NUC 12

[Kazimierz Uromski]

Hi
On kernel 6.6 (linux-image-6.6.9-amd64) the issue is solved - display 
works on cold boot using output handled by both GPU's: CPU-integrated 
Intel Iris Xe (Thunderbolt) and Intel ARC 770M (HDMI).

--
Thanks
Kazimierz

Bug#1060802: stellarium: FTBFS on armel, ppc64el, s390x: unsatisfiable Build-Depends: qtwebengine5-dev (>= 5.15)

[Dmitry Shachnev]

Source: stellarium
Version: 23.4-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: ftbfs

Dear Maintainer,

stellarium 23.4-1 added a new build-dependency on qtwebengine5-dev, which
prevents it from building on some release architectures (and all non-release
ones).

Upstream mentions [1] that Qt WebEngine build-dependency is optional and can
be either detected automatically by the build system, or configured explicitly
using -DENABLE_QTWEBENGINE=ON/OFF [2].

Qt WebEngine is available only amd64, arm64, armhf, i386 and mips64el, and
it's unlikely that this set of architectures will be changed for Qt 5. So you
can limit the build-dependency to these architectures.

[1]: 
https://github.com/Stellarium/stellarium/blob/master/BUILDING.md#linux-without-qtwebengine
[2]: 
https://github.com/Stellarium/stellarium/blob/master/BUILDING.md#supported-cmake-parameters

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#238687: popularity-contest: popularity contest should provide subarch info.

[Bill Allombert]

On Sat, Jan 13, 2024 at 12:51:47PM -0800, Matt Taggart wrote:
> It's been quite a while since this bug was discussed, but I have another use
> case where it might be interesting...
> 
> There has been some recent discussion about "Architecture Variants" and in
> particular amd64 variants. Fedora and Ubuntu are both working on experiments
> with the goal of being able to optimize for newer versions of the amd64
> architecture (and potentially dropping older variants at some point as
> well). Here is a page that gathers info on this idea for Debian
> 
> https://wiki.debian.org/ArchitectureVariants
> 
> Knowing information about which variants our installed base is using would
> help make these decisions easier. The past i386 decisions were a little
> easier because there were particular packages we could look at to get those
> numbers.

Hello Matt, thanks for reviving this bug.

Note that unfortunately, none of the requirement I set up in the my previous
answer to this bug have been addressed.
In particular, there is no official definition of subarchitecture and tool
that report it that popcon could use.

However, I doubt the practicality of reporting subarchitectures:
1/ users might not be running the latest Debian release, and there is no way to 
know
if they plan to upgrade.
2/ the number of users running some subarchitectures is likely to be very small,
which breaks anonymity.

Cheers,
Bill

Bug#914247: Please move library to /usr/lib

[Chris Hofstaedtler]

Hi Laurent,

On Tue, Nov 14, 2023 at 10:21:58AM +0100, Helmut Grohne wrote:
[..]
> In the long term, I recommend Michael's patch.

I've updated Michael's patch and pushed it to salsa:
   https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/8

Best,
Chris

Bug#1060800: ndisc6: install into usrmerged layout (DEP17 M2)

[Chris Hofstaedtler]

> Your package installs files into /bin and /sbin. Please install them
> into the respective locations in /usr instead. See [1] about
> details.

I've pushed a patch to https://salsa.debian.org/debian/ndisc6/-/commits/usrmerge

Please consider applying it.

Chris

Bug#1060698: [Pkg-auth-maintainers] Bug#1060698: yubioath-desktop: Doesn't see yubikeys anymore.

[Sébastien Noel]

Hi Florian,

Le 2024-01-14 13:51, Florian Schlichting a écrit :

Hi Sébastien,

thank you for the patch. I'm not opposed to applying it. In my
superficial testing, it seems to work well. I'm not a user of
yubioath-desktop, though, and while I can help with an occasional
upload, I don't want to feel responsible for it.

Are you able to keep an eye on yubioath-desktop in Debian and, if
necessary, respond to upcoming issues?


for what it's worth, i have been running yubioath with this patch
for ~11 months, so I would feel confident to ship it in Debian
and take responsibility for it


Do you want to submit your patch upstream, so that we can see what they
think, and other distributions can find your work?


Upstream doesn't seems interested; all they do on github is to tag 
issue/mr

about the old codebase with the 'legacy' label & close the issue.

my patches are available here:
https://github.com/twolife/yubioath-desktop-legacy/


Florian


br,
Sébastien

Bug#1060801: SWIG 4.2.0 has been released, package needs updating

[Torsten Landschoff]

Package: swig
Version: 4.1.0-0.3

I just noticed that SWIG 4.2.0 has been released on the last day of 
2023:


https://sourceforge.net/p/swig/news/2023/12/swig-420-released/

The package needs to be updated from the new upstream.

Bug#1060800: ndisc6: install into usrmerged layout (DEP17 M2)

[Chris Hofstaedtler]

Source: ndisc6
Version: 1.0.5-1
User: helm...@debian.org
Usertag: dep17m2

Your package installs files into /bin and /sbin. Please install them
into the respective locations in /usr instead. See [1] about
details.

Chris

[1] https://wiki.debian.org/UsrMerge

Bug#1060798: IPC::Run3::run3 eats the calling process' stdin

[gregor herrmann]

Control: forwarded -1 https://rt.cpan.org/Ticket/Display.html?id=52317

On Sun, 14 Jan 2024 14:04:49 +0100, Christoph Biedl wrote:

> The problem has been around for a long time, I can confirm it's already
> there in Debian 8 ("jessie"). My gut feeling tells me I had already 
> reported that, but I cannot find any traces of that (upstream page is
> not barrier-free so I cannot check there). Also, his caused quite some
> data loss in one of my programs, so possibly the severity
> should be even higher.

There's an CPAN RT ticket at
https://rt.cpan.org/Ticket/Display.html?id=52317

An attempt for a pull request was withdrawn as non-functional, and …
 
> So if all else fails, please place a big fat warning into IPC::Run3's
> manpage to avoid other people get hit by this, too.

… the last step seems to be a suggestion to document the issue:
https://github.com/rjbs/IPC-Run3/pull/10


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1060774: Bug ticket

[Daniel Markstedt]

This is the relevant bug ticket for the netatalk package: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060773

Bug#1060799: libunwind8: installs empty /lib directory

[Chris Hofstaedtler]

Package: libunwind8
Version: 1.6.2-3
User: helm...@debian.org
Usertag: dep17m2

Hi,

your package libunwind8 installs an empty directory: /lib.
As this directory is subject to the currently ongoing UsrMerge
effort[1], please stop installing it.

Thanks,
Chris

Bug#1060773: Filed an upload request to release team

[Daniel Markstedt]

I prepared a deb patch and filed this upload request with the release team:

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

Bug#1058841: libopenobex: diff for NMU version 1.7.2-2.2

[Chris Hofstaedtler]

Control: tags 1058841 + pending


Dear maintainer,

I've prepared an NMU for libopenobex (versioned as 1.7.2-2.2) and
uploaded it to DELAYED/7.
It also includes the Debian Janitor changes from salsa.

I've pushed the same as a branch to:
  https://salsa.debian.org/debian/libopenobex/-/tree/nmu-1058841?ref_type=heads

Chris

diff -Nru libopenobex-1.7.2/debian/changelog libopenobex-1.7.2/debian/changelog
--- libopenobex-1.7.2/debian/changelog	2021-12-20 12:00:45.0 +0100
+++ libopenobex-1.7.2/debian/changelog	2024-01-14 14:06:37.0 +0100
@@ -1,3 +1,20 @@
+libopenobex (1.7.2-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Debian Janitor ]
+  * Trim trailing whitespace.
+  * Fix field name case in debian/copyright (FIles => Files).
+  * Remove constraints unnecessary since buster (oldstable):
++ Build-Depends: Drop versioned constraint on cmake (>= 2.6.3).
++ openobex-apps: Drop conflict with removed package openobex-apps (<<
+  1.7.1-4) in Breaks.
+
+  [ Chris Hofstaedtler ]
+  * Use udev.pc to place udev rules (Closes: #1058841)
+
+ -- Chris Hofstaedtler   Sun, 14 Jan 2024 14:06:37 +0100
+
 libopenobex (1.7.2-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
@@ -52,7 +69,7 @@
 
 libopenobex (1.7.1-5) unstable; urgency=medium
 
-  * Fix build with libc6 2.22. (Closes: #811892) 
+  * Fix build with libc6 2.22. (Closes: #811892)
   * Bump Standards-Version to 3.9.7.
   * Add field of Vcs-Git and Vcs-Browser.
 
@@ -255,7 +272,7 @@
   * Add docbuild patch to be able to build documentation
   * Include documentation in the -dev package
   * Package openobex-apps is not shipped seperately anymore, so include it
-  * Package ircp is not shipped seperately anymore, so include it 
+  * Package ircp is not shipped seperately anymore, so include it
   * Update FSF address
 
  -- Hendrik Sattler   Fri, 10 Feb 2006 12:41:46 +0100
@@ -316,7 +333,7 @@
 the glib dependencies (Closes: #170090)
 
  -- Edd Dumbill   Thu, 21 Nov 2002 22:57:42 +
- 
+
 libopenobex (0.9.8-6) unstable; urgency=low
 
   * Fixed the .so files to be in the right packages
diff -Nru libopenobex-1.7.2/debian/control libopenobex-1.7.2/debian/control
--- libopenobex-1.7.2/debian/control	2021-12-20 11:55:02.0 +0100
+++ libopenobex-1.7.2/debian/control	2024-01-14 14:06:37.0 +0100
@@ -2,10 +2,11 @@
 Priority: optional
 Section: comm
 Maintainer: Nobuhiro Iwamatsu 
-Build-Depends: debhelper-compat (= 13), cmake (>= 2.6.3),
+Build-Depends: debhelper-compat (= 13), cmake,
 	libbluetooth-dev [linux-any], libusb-1.0-0-dev,
 	pkg-config, doxygen, docbook-xml, docbook-xsl,
-	xsltproc, libxml2-utils, graphviz 
+	xsltproc, libxml2-utils, graphviz ,
+	systemd-dev
 Standards-Version: 4.6.0.1
 Homepage: http://sourceforge.net/projects/openobex/
 Vcs-Git: https://salsa.debian.org/debian/libopenobex.git
@@ -52,7 +53,6 @@
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Conflicts: ircp
 Replaces: ircp
-Breaks: openobex-apps (<< 1.7.1-4)
 Description: Applications for OpenOBEX
  The Object Exchange protocol can best be described as binary HTTP.
  OBEX is optimised for ad-hoc wireless links and can be used to exchange
diff -Nru libopenobex-1.7.2/debian/copyright libopenobex-1.7.2/debian/copyright
--- libopenobex-1.7.2/debian/copyright	2021-12-20 11:55:02.0 +0100
+++ libopenobex-1.7.2/debian/copyright	2024-01-14 14:06:37.0 +0100
@@ -120,11 +120,11 @@
 Copyright: 2010, 2011, Hendrik Sattler
 License: GPL-2+
 
-FIles: debian/*
 Copyright: 2002, Schubert 
   2002, Edd Dumbill 
   2016, Nobuhiro Iwamatsu 
 License: GPL-2+
+Files: debian/*
 
 License: GPL-2+
  This program is free software; you can redistribute it and/or modify
diff -Nru libopenobex-1.7.2/debian/libopenobex2.install libopenobex-1.7.2/debian/libopenobex2.install
--- libopenobex-1.7.2/debian/libopenobex2.install	2021-12-20 11:55:02.0 +0100
+++ libopenobex-1.7.2/debian/libopenobex2.install	2024-01-14 14:06:37.0 +0100
@@ -1,3 +1,3 @@
 usr/lib/*/libopenobex.so.*
 usr/sbin/obex-check-device
-lib/udev/rules.d/60-openobex.rules
+${env:deb_udevdir}/rules.d/60-openobex.rules
diff -Nru libopenobex-1.7.2/debian/rules libopenobex-1.7.2/debian/rules
--- libopenobex-1.7.2/debian/rules	2021-12-20 11:57:51.0 +0100
+++ libopenobex-1.7.2/debian/rules	2024-01-14 14:06:37.0 +0100
@@ -6,6 +6,8 @@
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 BUILDDIR = obj-$(DEB_HOST_MULTIARCH)
 
+export deb_udevdir = $(shell pkg-config --variable=udevdir udev | sed s,^/,,)
+
 %:
 	dh $@