Bug#1061170: sudo: sends mail when aborting

[Thorsten Glaser]

Package: sudo
Version: 1.9.5p2-3+deb11u1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

When typing “sudo somecommandwithatypo”, pressing Enter, and then
realising you’d done a typo and hitting ^C to abort, sudo sends an
eMail that “a password is required” nowadays.

This is a regression against older versions which did not send an
eMail in those cases.


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

Kernel: Linux 5.10.0-27-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages sudo depends on:
ii  libaudit1   1:3.0-2
ii  libc6   2.31-13+deb11u7
ii  libpam-modules  1.4.0-9+deb11u1
ii  libpam0g1.4.0-9+deb11u1
ii  libselinux1 3.1-3
ii  lsb-base11.1.0
ii  zlib1g  1:1.2.11.dfsg-2+deb11u2

sudo recommends no packages.

sudo suggests no packages.

-- Configuration Files:
/etc/sudoers [Errno 13] Permission denied: '/etc/sudoers'
/etc/sudoers.d/README [Errno 13] Permission denied: '/etc/sudoers.d/README'

-- no debconf information

Bug#1061169: aptitude: "aptitude install debhelper-compat" fails with "virtual package provided by: debhelper debhelper debhelper"

[Askar Safin]

Package: aptitude
Version: 0.8.13-5+b1
Severity: normal

Steps to reproduce:
- Create fresh sid system
- Type "aptitude install debhelper-compat"

The command will fail with the following absolutely absurd message:

# aptitude install debhelper-compat
"debhelper-compat" is a virtual package provided by:
  debhelper debhelper debhelper debhelper debhelper 
You must choose one to install.
Unable to apply some actions, aborting

apt works correctly


-- Package-specific info:
Terminal: xterm
$DISPLAY not set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 13.2.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.4
  libsigc++ version: 2.12.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.4.20240113
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffcf0934000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7fb020e0)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7fb020dc6000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7fb020d91000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fb020d88000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7fb020c86000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fb020b14000)
libboost_iostreams.so.1.83.0 => 
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.83.0 (0x7fb020afa000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fb0208c9000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fb020673000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fb020594000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fb02057)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb02038c000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fb02036d000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fb02035a000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fb02032a000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7fb020304000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7fb020243000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fb02020e000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7fb02012c000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7fb01ffe4000)
libxxhash.so.0 => /lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7fb01ffd1000)
/lib64/ld-linux-x86-64.so.2 (0x7fb02148)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fb01ffc7000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7fb01ffb9000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7fb01ff9)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.13-5
ii  libapt-pkg6.0 2.7.8
ii  libboost-iostreams1.83.0  1.83.0-2+b2
ii  libc6 2.37-13
ii  libcwidget4   0.5.18-6+b1
ii  libgcc-s1 13.2.0-9
ii  libncursesw6  6.4+20240113-1
ii  libsigc++-2.0-0v5 2.12.1-1
ii  libsqlite3-0  3.44.2-1
ii  libstdc++613.2.0-9
ii  libtinfo6 6.4+20240113-1
ii  libxapian30   1.4.22-1

Versions of packages aptitude recommends:
pn  libdpkg-perl
ii  sensible-utils  0.0.20

Versions of packages aptitude suggests:
pn  apt-xapian-index
pn  aptitude-doc-en | aptitude-doc  
pn  debtags 
pn  tasksel 

-- no debconf information

Bug#1061168: grub-common: update-grub2 breaks root= directive when / is a BTRFS raid1 on LVM with other LVs using raidintegrity

[Patrick Plenefisch]

I should also mention that the grub configuration isn't really the system I
tested this on, though it is mounted in /srv/chroot/mebsuta

That system is Debian 12

Bug#1061168: grub-common: update-grub2 breaks root= directive when / is a BTRFS raid1 on LVM with other LVs using raidintegrity

[Patrick Plenefisch]

Package: grub-common
Version: 2.06-3~deb11u6
Severity: important
Tags: upstream
X-Debbugs-Cc: simonp...@gmail.com


If you have an LVM setup with a VG that contains a raidintegrity=y volume, and
two other volumes that form a BTRFS raid1 filesystem, and the BTRFS filesystem
is the root filesystem, then update-grub2 will generate grub.cfg with:

linux [...] root=/dev/lvm/btrfs1
/dev/lvm/btrfs2 [..]

instead of:
linux [...] root=/dev/lvm/btrfs1 [..]

or
linux [...] root=UUID=[...] [..]

Note: that is a newline in the configuration file, so the config file is broken

When doing this, update-grub2 will spit out several errors about unknown nodes
(listing the raidintegrity volumes) and disks (the id's for the first LV in the
VG)

To create a LVM system that fails in this way, first assemble a VG called
myGrubBreakingVG with two PVs in it. Then run:
lvcreate -L 128MiB -n theRaidVol --mirrors 1 --type raid1 --raidintegrity y
myGrubBreakingVG
lvcreate -L 5GiB -n btrfsSideA myGrubBreakingVG
lvcreate -L 5GiB -n btrfsSideB myGrubBreakingVG
mkfs.btrfs -m raid1 -d raid1 /dev/myGrubBreakingVG/btrfsSideA
/dev/myGrubBreakingVG/btrfsSideB

Then you can mount the btrfs volumes, and debootstrap a system into it, chroot,
and inside that chroot update grub will fail as described


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sde1 / btrfs rw,noatime,ssd,space_cache,subvolid=461,subvol=/root-subvol 0 0
/dev/mapper/lvm-polluxHome /home btrfs 
rw,noatime,ssd,space_cache,subvolid=5,subvol=/ 0 0
/dev/mapper/lvm-codemop /home/patrick/code btrfs 
rw,noatime,ssd,space_cache,subvolid=257,subvol=/code 0 0
/dev/sdd1 /boot/efi vfat 
rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
/dev/sdc1 /boot/efi2 vfat 
rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
/dev/sdb1 /boot/efi3 vfat 
rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
/dev/mapper/lvm-coldSnow /home/patrick/bigfiles btrfs 
rw,noatime,space_cache,subvolid=839,subvol=/@bigfiles 0 0
/dev/sdh1 /media/patrick/Ventoy exfat 
rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro
 0 0
/dev/sdg1 /media/patrick/FastNloose ext4 
rw,nosuid,nodev,relatime,errors=remount-ro 0 0
/dev/sdg3 /media/patrick/HeptMigf btrfs 
rw,nosuid,nodev,relatime,space_cache,subvolid=5,subvol=/ 0 0
/dev/mapper/molasses-stripeFast /media/patrick/StripedFast ext4 
rw,nosuid,nodev,relatime,errors=remount-ro,stripe=64 0 0
/dev/mapper/mebsuta-mebsutaRoot /srv/chroot/mebsuta btrfs 
rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/@rootfs 0 0
/dev/nvme1n1p3 /srv/chroot/mebsuta/boot ext4 rw,relatime 0 0
/dev/mapper/molasses-stripeFast /srv/chroot/mebsuta/mnt ext4 
rw,relatime,errors=remount-ro,stripe=64 0 0
/dev/mapper/lvm-coldSnow /media/patrick/ColdSnowStorage btrfs 
rw,relatime,space_cache,subvolid=5,subvol=/ 0 0
/dev/mapper/molasses-photos /media/patrick/Photos btrfs 
rw,nosuid,nodev,relatime,space_cache,subvolid=5,subvol=/ 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod btrfs
set root='hd3,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd3,gpt1 
--hint-efi=hd3,gpt1 --hint-baremetal=ahci3,gpt1  
2331b700-3f81-4711-b5d2-19b22456cd0d
else
  search --no-floppy --fs-uuid --set=root 2331b700-3f81-4711-b5d2-19b22456cd0d
fi
font="/root-subvol/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ 

Bug#995670: ITP: zig -- General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software

[Maytham Alsudany]

Hi Nick,

On Sat, 2024-01-20 at 13:58 +0900, Nick Hastings wrote:
> I updated the package to Zig 0.10.1. The RFS bug still still open.

You should probably try to ping bage and ask them to have a look at your RFS
once more. Software written in Zig keeps popping up, for example, wayprompt.

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012286
> 
> I'll likely not even try packaging 0.11 or newer until it can once again
> bootstrap. However I don't expect that to happen anytime soon.

Kind regards,
Maytham


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

Bug#995670: ITP: zig -- General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software

[Nick Hastings]

Hi,

* Maytham Alsudany  [240117 11:37]:
>
> Are you still working on the zig package?
> I'd be happy to help you fix any problems that remain.

I updated the package to Zig 0.10.1. The RFS bug still still open.

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

I'll likely not even try packaging 0.11 or newer until it can once again
bootstrap. However I don't expect that to happen anytime soon.

Nick.

Bug#1061167: RFP: spitbol -- SPITBOL is an extremely high performance implementation of the SNOBOL4 language

[John Hasler]

Package: wnpp
Severity: wishlist

* Package name: spitbol
  Version : V4.0f (Jan 2024)
  Upstream Contact: Cheyenne Wills 
* URL : https://github.com/spitbol/x64
* License : GPL
  Programming Lang: C, assembler
  Description : SPITBOL is an extremely high performance implementation of 
the SNOBOL4 language

   With the SNOBOL4 language, you can manipulate text and search for 
patterns
   in a simple and natural manner. SNOBOL4 is a completely general
   programming language, and its magic extends far beyond the world of
   text processing. Concise and powerful programs are easy to write. In
   addition, SNOBOL4's pattern programming provides a new way to work
   with computers.

   For information about differences between SNOBOL4, SNOBOL4+, and
   Spitbol (and differences between various Spitbol implementations)
   please refer to the Macro SPITBOL manual.

The original manual:
http://www.snobol4.com/spitbol360/spitbol_360_manual.pdf

This classic powerful text processing language belongs in Debian.

I do not intend to maintain it.  I might be able to provide some limited
assistance.

Bug#1061166: qt6-gtk-platformtheme: GTK Theme not applied on wayland unless QT_QPA_PLATFORM=xcb is set

[Kostadin Shishmanov]

Package: qt6-gtk-platformtheme
Version: 6.6.1+dfsg-6
Severity: normal
X-Debbugs-Cc: koce...@tutanota.com

Dear Maintainer,

When using Gnome/Wayland, if you install qt6-gtk-platformtheme, and try to run
qbittorrent for example, you can notice that it's using a generic qt6 theme,
and not the one that the system is using. Cursor size is also messed up. This
can be worked around by setting `QT_QPA_PLATFORM=xcb`. The environmental
variable is not needed when using X11.

Steps to reproduce:
1. Have a working GNOME setup
2. Log into a wayland session
3. Install qt6-gtk-platformtheme and qbittorrent
4. Run qbittorrent and notice that the theme is all messed up.
5. Try running it as follows: `QT_QPA_PLATFORM=xcb qbittorrent` or start it
from an X11 session, and notice that the proper theming is applied.


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 qt6-gtk-platformtheme depends on:
ii  libc6   2.37-13
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-3
ii  libglib2.0-02.78.3-1
ii  libgtk-3-0  3.24.39-1
ii  libpango-1.0-0  1.51.0+ds-3
ii  libqt6core6 [qt6-base-private-abi]  6.6.1+dfsg-6
ii  libqt6gui6  6.6.1+dfsg-6
ii  libstdc++6  13.2.0-9
ii  libx11-62:1.8.7-1

qt6-gtk-platformtheme recommends no packages.

qt6-gtk-platformtheme suggests no packages.

-- no debconf information

Bug#1061165: qt5-gtk-platformtheme: GTK Theme not applied on wayland unless QT_QPA_PLATFORM=xcb is set

[Kostadin Shishmanov]

Package: qt5-gtk-platformtheme
Version: 5.15.10+dfsg-6
Severity: normal
X-Debbugs-Cc: koce...@tutanota.com

Dear Maintainer,

When using Gnome/Wayland, if you install qt5-gtk-platformtheme, and try to run
keepassxc for example, you can notice that it's using a generic qt5 theme, and
not the one that the system is using. Cursor size is also messed up. This can
be worked around by setting `QT_QPA_PLATFORM=xcb`. The environmental variable
is not needed when using X11.

Steps to reproduce:
1. Have a working GNOME setup
2. Log into a wayland session
3. Install qt5-gtk-platformtheme and keepassxc
4. Run keepassxc and notice that the theme is all messed up.
5. Try running it as follows: `QT_QPA_PLATFORM=xcb keepassxc` or start it from
an X11 session, and notice that the proper theming is applied.


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 qt5-gtk-platformtheme depends on:
ii  libc6  2.37-13
ii  libglib2.0-0   2.78.3-1
ii  libgtk-3-0 3.24.39-1
ii  libpango-1.0-0 1.51.0+ds-3
ii  libqt5core5a [qtbase-abi-5-15-10]  5.15.10+dfsg-6
ii  libqt5dbus55.15.10+dfsg-6
ii  libqt5gui5 5.15.10+dfsg-6
ii  libstdc++6 13.2.0-9
ii  libx11-6   2:1.8.7-1

qt5-gtk-platformtheme recommends no packages.

qt5-gtk-platformtheme suggests no packages.

-- no debconf information

Bug#942314: RFP: gst-plugins-rs -- GStreamer plugins written in Rust

[Matthias Geiger]

On Mon, 14 Oct 2019 16:06:59 +0300 =?utf-8?q?Sebastian_Dr=C3=B6ge?= 
 wrote:

> Package: wnpp
> Severity: wishlist
>
> * Package name : gst-plugins-rs
> Version : 0.5.0
> Upstream Author : Sebastian Dröge 
> * URL : https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs
> * License : LGPL, MIT/Apache-2.0
> Programming Lang: Rust
> Description : GStreamer plugins written in Rust
>
> The GStreamer project is starting to write various extension plugins 
in the
> Rust programming language. There are a few useful ones now at this 
point and

> it would be good to start packaging them.
>
> I personally don't have the time for maintaining this also in Debian in
> addition to all the other GStreamer packages (help welcome!) but would be
> happy to assist anybody who wants to start packaging gst-plugins-rs.
>
> The package should probably be maintained as part of the Debian Rust 
team:

> https://wiki.debian.org/Teams/RustPackaging
> See there also for the Rust-specific packaging policy.
>

> It will be required to also package various dependencies as part of this.

gst-plugin-gtk4 has landed in debian; gst-plugin-gif is being prepared. 
I have not yet enabled the build of the library (as of now this is just 
the rust code shipped as package); can you shed some light on this? As 
far as I understand those can then be dynamically loaded by gstreamer ? 
Today I just realized that they work as plugins.


Enabling them  *should* be trivial; it's just another trip through new.

best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061157: RFS: mini-httpd/1.30-7 -- Small HTTP server

[Nicholas D Steeves]

Control: owner -1 !

Hi Alexandru,

Happy New Year!  I'll sponsor this one.

In the future please use "reportbug sponsorship-requests" and enter my
email at the "Enter any additional addresses this report should be sent
to; press ENTER after each address. Press ENTER on a blank line to
continue" step, because the method you use doesn't let the additional
recipient[s] reply to the bug.  If you want to use another method,
please add the following pseudoheader:

X-Debbugs-Cc: additional@recipient addresses@list ie@me

Gentle reminder not to push tags until the package has been accepted
into the archive.  It would also be nice to see you use end punctuation
again.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1059177: makedev: move files from / to /usr

[Chris Hofstaedtler]

On Wed, Dec 20, 2023 at 11:53:15PM +0100, Chris Hofstaedtler wrote:
> Source: makedev
[..]
> your package installs MAKEDEV directly into /sbin. For the ongoing
> Debian UsrMerge effort [1] it should move to /usr/sbin in the trixie
> cycle.

I've uploaded the patch as makedev_2.3.1-97.1_source.changes to
DELAYED/7, and pushed an "nmu" branch to salsa.d.o.

Chris

Bug#1057771: battery-stats: delegate placement of systemd/udev files to pkg-config data

[Chris Hofstaedtler]

Control: tags -1 + pending

On Fri, Dec 08, 2023 at 11:46:40AM +0100, Chris Hofstaedtler wrote:
> Source: battery-stats
[..]

> your package installs files related to systemd and udev, into /lib.
> These files need to be moved to /usr/lib as part of Debian's
> usr-merge effort [1].
[..]
> The same patch can be found here as a salsa merge request:
>   https://salsa.debian.org/debian/battery-stats/-/merge_requests/3

I've uploaded this (together with the fixes from master and the
janitor) as an NMU to DELAYED/7. The equivalent branch is called
"nmu".

Chris

Bug#1061164: cron: with a black background, /etc/supercat/spcrc-crontab makes default text invisible

[Vincent Lefevre]

Package: cron
Version: 3.0pl1-183
Severity: normal

Using spc with the provided /etc/supercat/spcrc-crontab config file
makes default text invisible with a black background.

Example:

  echo '6 5 * * * foo > /dev/null' | spc -t crontab

gives "6 5 * * * foo". The remaining is invisible. Note that using the
-r spc option (to reverse black and white) doesn't change anything.

I suppose that this is due to

Blackblk   (.*)

IMHO, the color of the default text shouldn't be changed (changing it
seems rather unusual).

-- Package-specific info:
--- EDITOR:
not set

--- /usr/bin/editor:
/usr/bin/nano

--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 47840 2024-01-18 09:51:30 /usr/bin/crontab

--- /var/spool/cron:
drwxr-xr-x 5 root root 4096 2023-12-25 03:13:01 /var/spool/cron

--- /var/spool/cron/crontabs:
drwx-wx--T 2 root crontab 4096 2024-01-15 15:44:54 /var/spool/cron/crontabs

--- /etc/cron.d:
drwxr-xr-x 2 root root 4096 2024-01-20 00:09:14 /etc/cron.d

--- /etc/cron.daily:
drwxr-xr-x 2 root root 4096 2024-01-20 00:09:14 /etc/cron.daily

--- /etc/cron.hourly:
drwxr-xr-x 2 root root 4096 2024-01-20 00:09:15 /etc/cron.hourly

--- /etc/cron.monthly:
drwxr-xr-x 2 root root 4096 2024-01-20 00:09:15 /etc/cron.monthly

--- /etc/cron.weekly:
drwxr-xr-x 2 root root 4096 2024-01-20 00:09:15 /etc/cron.weekly


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

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

Versions of packages cron depends on:
ii  cron-daemon-common   3.0pl1-183
ii  init-system-helpers  1.66
ii  libc62.37-13
ii  libpam-runtime   1.5.2-9.1
ii  libpam0g 1.5.2-9.1+b1
ii  libselinux1  3.5-1+b2
ii  sensible-utils   0.0.20

Versions of packages cron recommends:
ii  postfix [mail-transport-agent]  3.8.4-1
ii  supercat0.5.7-1

Versions of packages cron suggests:
ii  anacron2.3-39+b1
pn  checksecurity  
ii  logrotate  3.21.0-2

Versions of packages cron is related to:
pn  libnss-ldap   
pn  libnss-ldapd  
pn  libpam-ldap   
pn  libpam-mount  
pn  nis   
pn  nscd  

-- no debconf information

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

Bug#1025857: Deprecated; replaced by github.com/go-webauthn/webauthn

[Mathias Gibbens]

Control: tags -1 + pending

  golang-github-go-webauthn-webauthn is now packaged, and I have
updated golang-github-canonical-candid to use the new library.
Currently there are no other rdeps on this library, so once candid
migrates to testing, I'll file the RM bug.

Mathias


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

Bug#1061163: git-review: please remove extraneous dependency on python3-six & python3-mock

[Alexandre Detiste]

Package: git-review
Version: 2.3.1-2
Severity: normal

Hi,

I've started using git-review.

I think I like it.


Debian package needs a tiny clean-up:

$ git clone https://salsa.debian.org/openstack-team/third-party/git-review
$ cd git-review/
$ grep six -r
debian/control: python3-six,
debian/control: python3-six,
$

Also python3-mock: it uses unittest.mock



Greetings

Alexandre



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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git-review depends on:
ii  git   1:2.43.0-1
ii  python3   3.11.4-5+b1
ii  python3-requests  2.31.0+dfsg-1
ii  python3-six   1.16.0-4

git-review recommends no packages.

git-review suggests no packages.

-- no debconf information

Bug#1061162: pypdf2: Do not release with Trixie

[Scott Kitterman]

Source: pypdf2
Version: 2.12.1-4
Severity: serious
Tags: upstream
Justification: Maintainer opinion

PyPDF2 has been replaced by pypdf upstream.  We should not release this
package with Trixie.  Rdepends should be either ported or removed.

Scott K

Bug#1061161: bookworm-pu: package pypdf2/2.12.1-3

[Scott Kitterman]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
CVE fix.

[ Impact ]
Users still vulernable to security issue.

[ Tests ]
Upstream has an extensive test suite, although we don't include a test
specifically for this issue.  All tests pass on bookworm locally.

[ Risks ]
Risk is negligible.  Code is trivial.  Fix has been available for 8
months upstream.  The same code is in pypdf and there have been no
issues reported with it (stable update for it is pending as well).

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Add a patch to apply the upstream fix for the issue.

[ Other info ]
This looks like an NMU in bookworm, but I just adopted the package.  I
did not include the maintainer changes in the stble-update since that
seemed to get beyone a minimal fix.

Scott K
diff -Nru pypdf2-2.12.1/debian/changelog pypdf2-2.12.1/debian/changelog
--- pypdf2-2.12.1/debian/changelog  2023-01-13 16:38:55.0 -0500
+++ pypdf2-2.12.1/debian/changelog  2024-01-19 17:32:34.0 -0500
@@ -1,3 +1,12 @@
+pypdf2 (2.12.1-3+deb12u1) bookworm; urgency=medium
+
+  * Prevent infinite loop when no character follows after a comment (Closes:
+#1040339)
+- Addresses CVE-2023-36464
+- Add d/p/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch
+
+ -- Scott Kitterman   Fri, 19 Jan 2024 17:32:34 -0500
+
 pypdf2 (2.12.1-3) unstable; urgency=medium
 
   * disable two more network tests
diff -Nru 
pypdf2-2.12.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch
 
pypdf2-2.12.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch
--- 
pypdf2-2.12.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch
1969-12-31 19:00:00.0 -0500
+++ 
pypdf2-2.12.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch
2024-01-19 17:30:16.0 -0500
@@ -0,0 +1,21 @@
+From: Scott Kitterman 
+Date: Mon, 15 Jan 2024 11:34:11 -0500
+Subject: Prevent infinite loop when no character follows after a comment
+https://security-tracker.debian.org/tracker/CVE-2023-36464
+---
+ PyPDF2/generic/_data_structures.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+Index: pypdf/PyPDF2/generic/_data_structures.py
+===
+--- pypdf.orig/PyPDF2/generic/_data_structures.py
 pypdf/PyPDF2/generic/_data_structures.py
+@@ -733,7 +733,7 @@ class ContentStream(DecodedStreamObject)
+ # encountering a comment -- but read_object assumes that
+ # following the comment must be the object we're trying to
+ # read.  In this case, it could be an operator instead.
+-while peek not in (b"\r", b"\n"):
++while peek not in (b"\r", b"\n", b""):
+ peek = stream.read(1)
+ else:
+ operands.append(read_object(stream, None, 
self.forced_encoding))
diff -Nru pypdf2-2.12.1/debian/patches/series 
pypdf2-2.12.1/debian/patches/series
--- pypdf2-2.12.1/debian/patches/series 2023-01-13 16:38:30.0 -0500
+++ pypdf2-2.12.1/debian/patches/series 2024-01-19 17:30:16.0 -0500
@@ -1 +1,2 @@
 disable-network-tests.patch
+0003-Prevent-infinite-loop-when-no-character-follows-afte.patch

Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.

[Guillem Jover]

Hi!

On Fri, 2024-01-19 at 14:13:07 +, Aidan wrote:
> On Fri, 19 Jan 2024, 00:08 Guillem Jover,  wrote:
> > …regardless of whether this is or not the last blocking issue, I'd
> > still very much appreciate if you could rename the project and tool
> > upstream. :)

> I shall rename the tool to remove "dpkg". Unless there are any objections
> I'm going to rename it to:
> "debpic: DEbian Build Package In Container"

That looks better, yes, and thank you for considering doing that!

(Also the pic part also evokes into my mind "image" which seems apt in
this context. :)

Thanks,
Guillem

Bug#1022540: build-essential: please add riscv64 support

[Bastian Germann]

On Wed, 13 Sep 2023 12:59:02 +0200 Matthias Klose  wrote:
the package won't migrate, afaiu. we have to have a testing pocket first. I 
don't want to upload a package which is not able to migrate.


What is the status of this? The referenced bug is closed by now.

Bug#1061160: feed2toot: please ship some of the upstream documentation

[Jonathan Dowland]

Package: feed2toot
Version: 0.17-1
Severity: normal

Hi there,

feed2toot (the package) is almost undocumented (thank you for the
manpage!)

The upstream source has a docs/ directory, and a README.md. Crucially,
these describe how to construct a minimally functional feed2toot.ini.

Please consider shipping them (source and rendered) in the Debian
package.

Bug#1054137: apt: let dh_installsystemd choose the location of units

[Michael Biebl]

Hi Julian

On Tue, 9 Jan 2024 19:53:20 +0100 Julian Andres Klode  
wrote:

On Tue, Jan 09, 2024 at 07:49:48PM +0100, Julian Andres Klode wrote:
> On Tue, Jan 09, 2024 at 06:46:14PM +0100, Chris Hofstaedtler wrote:
> > Dear APT Maintainers,
> > 
> > On Tue, Oct 17, 2023 at 04:36:19PM +0200, Helmut Grohne wrote:

> > [Move systemd files to /usr]
> > > I'm attaching a patch for your convenience.
> > 
> > Could I ask you to apply this patch some time soon, please?
> 
> No, the patch is currently not in an actionable state to my

> knowledge, we spend a couple hours trying to sort things out
> in October or so but didn't get anywhere.
> 
> And there's urgent RC bug fixing in python-apt I

> do need to finish up first before I can wrap my head around
> this again.

FWIW, I'm more inclined to move the files to /usr manually, that
avoids all the risky business we identified trying to whack
dh_installsystemd into shape to install that successfully.



Could you be more specific here?
Where and how and why exactly did you need to override dh_installsystemd?

dh_installsystemd should be the primary interface for installing debian 
specific unit files (and handling upstream provided unit files) and we'd 
like to improve it if possible.


Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061158: ITP: discord-rpc -- library for Discord Rich Presence integration

[David James]

Hi Mathias, 

That is very kind of you. When it clears lintian and I have tested it against 
Citra I will let you know.
 
Thanks again.
 
David

Bug#1059767: aptfs: isolation-machine autopkgtest fails: find: ‘target/bash’: Invalid argument

[Chris Lamb]

Paul Gevers wrote:

>   72s lr-xrwSrwt 3 root root 0 Jan  1  1970 zypper-common -> zypper
>   72s lr-xrwSrwt 3 root root 0 Jan  1  1970 zypper-doc -> zypper
>   72s dr-x-wSr-t 3 root root 0 Jan  1  1970 zytrax
>   72s dr-x-wSr-t 3 root root 0 Jan  1  1970 zziplib
>   72s lr-xrwSrwt 3 root root 0 Jan  1  1970 zziplib-bin -> zziplib
>   72s dr-x-wSr-t 3 root root 0 Jan  1  1970 zzuf
>   72s dr-x-wSr-t 3 root root 0 Jan  1  1970 zzz-to-char
>   72s dr-x-wSr-t 3 root root 0 Jan  1  1970 zzzeeksphinx
>   72s find: ‘target/bash’: Invalid argument
>   72s target/bash
>   73s autopkgtest [17:05:06]: test 0001-smoketest: ---]

Just to mention that I have been looking into this, but I am a little
stymied as it seems to work okay here. What is very curious is that
the directory listing works (ie. we can infer that zzuf, zzz-to-char,
zzzeeksphinx, etc. has been obtained via APT), but the package
download is not working.

Still, I should also mention that I am not using, developing or
(genuinely) supporting aptfs any longer, so the real solution here
might be to remove the package.


Best wishes,

-- 
  o
⬋   ⬊  Chris Lamb
   o o reproducible-builds.org 
⬊   ⬋
  o

Bug#1056841: pymatgen: ftbfs with cython 3.0.x

[Andreas Tille]

Am Fri, Jan 19, 2024 at 08:22:21PM +0100 schrieb Drew Parsons:
> On 2024-01-19 18:52, Drew Parsons wrote:
> > 
> > Hi Andreas, could you push your upstream and pristine-tar branches?
> > Otherwise we can't use your 2023.12.18 branch.
> 
> I see what you mean.  The tag is there, the orig tarball can be regenerated
> with
> gbp export-orig.

Good to know that you can work what is on Salsa - I have removed my local clone.

Good luck
   Andreas. 

-- 
http://fam-tille.de

Bug#1061158: ITP: discord-rpc -- library for Discord Rich Presence integration

[Mathias Gibbens]

Hi David,

  I would be willing to review and sponsor this package when it's
ready. Feel free to ping me directly (no need to open a RFS bug.)

  openrct2 can use this library for Discord integration, but that is
currently disabled in the Debian builds. I haven't tried to package
this library because I'm not really a Discord user, and the library
itself is deprecated in favor of Discord's GameSDK. However, as there
are now two concrete cases where this would be useful in Debian (Citra
and openrct2), if you're willing to do the work, I will help by
sponsoring the upload.

Mathias


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

Bug#1061159: sdaps: FTBFS: command 'sdaps_clean_i18n' has no such option 'all'

[Aurelien Jarno]

Source: sdaps
Version: 1.9.8-0.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

sdaps fails to build from source. From my build log on amd64:

| dpkg-buildpackage: info: source package sdaps
| dpkg-buildpackage: info: source version 1.9.8-0.1
| dpkg-buildpackage: info: source distribution unstable
|  dpkg-source --before-build .
| dpkg-buildpackage: info: host architecture amd64
|  fakeroot debian/rules clean
| dh clean --with python3 --buildsystem=pybuild
|dh_auto_clean -O--buildsystem=pybuild
| I: pybuild base:305: python3.11 setup.py clean 
| error: error in 
/<>/.pybuild/cpython3_3.11_sdaps/.pydistutils.cfg: command 
'sdaps_clean_i18n' has no such option 'all'
| E: pybuild pybuild:391: clean: plugin distutils failed with: exit code=1: 
python3.11 setup.py clean 
| dh_auto_clean: error: pybuild --clean -i python{version} -p 3.11 returned 
exit code 13
| make: *** [debian/rules:7: clean] Error 25
| dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned 
exit status 2

The full build log for riscv64 is also available here:
https://buildd.debian.org/status/fetch.php?pkg=sdaps=riscv64=1.9.8-0.1%2Bb1=1705322530=0

The reproducible builds also show the same issue:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/sdaps_1.9.8-0.1.rbuild.log.gz

Regards
Aurelien

Bug#1061158: ITP: discord-rpc -- library for Discord Rich Presence integration

[David James]

Package: wnpp
Severity: wishlist
Owner: David James 
X-Debbugs-Cc: debian-de...@lists.debian.org, davidjamescastor...@proton.me

* Package name: discord-rpc
  Version : 3.4.0
  Upstream Contact: Discord, Inc
* URL : https://github.com/discord/discord-rpc
* License : MIT
  Programming Lang: C, C++, CMake, Python
  Description : library for Discord Rich Presence integration

This is a library for integrating Discord features into games and 
applications. For example, it allows an application to connect to Discord and 
show in-game activity on a user's profile.

It is also a Citra dependency. There are multiple FOSS projects
aside from Citra that also integrate this library and could make use of this 
package if they were ever packaged themselves (e.g. Duckstation, PCSX2 etc.).

I would be maintaining this package myself, but would need a sponsor.

Bug#1042364: fixed in syncthing 1.27.2~ds4-1

[Thomas Butz]

Hey Félix, thanks for your work!

We add the missing MIT license file to https://github.com/calmh/incontainer as 
reported.

Is there anything else the Syncthing project can do to help?

Bug#1061157: RFS: mini-httpd/1.30-7 -- Small HTTP server

[Alexandru Mihail]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "mini-httpd":

 * Package name : mini-httpd
   Version  : 1.30-7
   Upstream contact : Jef Poskanzer j...@mail.acme.com
 * URL  : https://www.acme.com/software/mini_httpd
 * License  : BSD-2-clause
 * Vcs  : https://salsa.debian.org/debian/mini-httpd
   Section  : web

The source builds the following binary packages:

  mini-httpd - Small HTTP server

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

  https://mentors.debian.net/package/mini-httpd/

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

  dget -x
https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-7.dsc

Changes since the last upload:

 mini-httpd (1.30-7) unstable; urgency=medium
 .
   * Modified mini-httpd.postinst to not copy
 /usr/share/doc/mini-httpd/examples/index.html into
 /var/www/html/index.html if it's not readable,
 fixing weird edge cases where docker's dpkg
 cleans up /usr/share/*/examples beforehand,
 (Closes: #1061070)
   * Created 0011-fix-typo-in-documentation-maxage
 which clears confusion regarding the maxage
 config & cli option, the actual name for the
 variable being max_age in mini_httpd.c.
 The patch modifies documentation and
 help output to reflect this reality.
 (Closes: #1018900)

Regards,
-- 
  Alexandru Mihail


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

Bug#1061154: neovim: Enable luajit on arm64

[James McCoy]

On Fri, Jan 19, 2024 at 04:50:07PM +, Michael Fladischer wrote:
> please enable luajit on arm64.
> I did a test-build on my arm64 machine and it worked as expected with luajit
> enabled.

Thanks for testing.  I know although LuaJIT was available on arm64
before, it didn't actually work well.  Looks like the recent update may
have resolved those issues.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1061156: ansible-core: CVE-2024-0690

[Salvatore Bonaccorso]

Source: ansible-core
Version: 2.14.13-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/ansible/ansible/pull/82565
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ansible-core.

CVE-2024-0690[0]:
| possible information leak in tasks that ignore ANSIBLE_NO_LOG
| configuration


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-0690
https://www.cve.org/CVERecord?id=CVE-2024-0690
[1] https://github.com/ansible/ansible/pull/82565
[2] 
https://github.com/ansible/ansible/commit/beb04bc2642c208447c5a936f94310528a1946b1

Regards,
Salvatore

Bug#1061097: pam: CVE-2024-22365: pam_namespace: protect_dir(): use O_DIRECTORY to prevent local DoS situations

[Salvatore Bonaccorso]

Hi Sam,

On Thu, Jan 18, 2024 at 08:41:29AM +0100, Salvatore Bonaccorso wrote:
> Source: pam
> Version: 1.5.2-9.1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: found -1 1.5.2-6+deb12u1
> Control: found -1 1.5.2-6
> Control: found -1 1.4.0-9+deb11u1
> Control: found -1 1.4.0-9
> 
> Hi,
> 
> The following vulnerability was published for pam.
> 
> CVE-2024-22365[0]:
> | pam_namespace: protect_dir(): use O_DIRECTORY to prevent local DoS
> | situations
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2024-22365
> https://www.cve.org/CVERecord?id=CVE-2024-22365
> [1] 
> https://github.com/linux-pam/linux-pam/commit/031bb5a5d0d950253b68138b498dc93be69a64cb
> [2] https://github.com/linux-pam/linux-pam/releases/tag/v1.6.0

Note the issue does not warrant a DSA, but ideally we have it fixed
already in the upcoming point releases.

I have prepared debdiffs to propose to SRM, see attached.

But for that we would need first the fix to land into unstable. What
would be the plan here? Would you move 1.6.0 soonish to unstable,
1.5.3-1 + CVE patch or rather do a patch on top of 1.5.2-9.1 in
unstable? For the later I could propose based on the done work as well
a NMU to unstable.

The point release, though not yet announced, is planned for early in
February, so hope we can manage it.

Regards,
Salvatore
diff -Nru pam-1.4.0/debian/changelog pam-1.4.0/debian/changelog
--- pam-1.4.0/debian/changelog  2021-08-26 21:11:23.0 +0200
+++ pam-1.4.0/debian/changelog  2024-01-18 08:53:14.0 +0100
@@ -1,3 +1,11 @@
+pam (1.4.0-9+deb11u2) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * pam_namespace: protect_dir(): use O_DIRECTORY to prevent local DoS
+situations (CVE-2024-22365) (Closes: #1061097)
+
+ -- Salvatore Bonaccorso   Thu, 18 Jan 2024 08:53:14 +0100
+
 pam (1.4.0-9+deb11u1) bullseye; urgency=medium
 
   * Fix syntax error in libpam0g.postinst when a systemd unit fails,
diff -Nru 
pam-1.4.0/debian/patches/pam_namespace-protect_dir-use-O_DIRECTORY-to-prevent.patch
 
pam-1.4.0/debian/patches/pam_namespace-protect_dir-use-O_DIRECTORY-to-prevent.patch
--- 
pam-1.4.0/debian/patches/pam_namespace-protect_dir-use-O_DIRECTORY-to-prevent.patch
 1970-01-01 01:00:00.0 +0100
+++ 
pam-1.4.0/debian/patches/pam_namespace-protect_dir-use-O_DIRECTORY-to-prevent.patch
 2024-01-18 08:53:14.0 +0100
@@ -0,0 +1,60 @@
+From: Matthias Gerstner 
+Date: Wed, 27 Dec 2023 14:01:59 +0100
+Subject: pam_namespace: protect_dir(): use O_DIRECTORY to prevent local DoS
+ situations
+Origin: 
https://github.com/linux-pam/linux-pam/commit/031bb5a5d0d950253b68138b498dc93be69a64cb
+Bug-Debian: https://bugs.debian.org/1061097
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-22365
+
+Without O_DIRECTORY the path crawling logic is subject to e.g. FIFOs
+being placed in user controlled directories, causing the PAM module to
+block indefinitely during `openat()`.
+
+Pass O_DIRECTORY to cause the `openat()` to fail if the path does not
+refer to a directory.
+
+With this the check whether the final path element is a directory
+becomes unnecessary, drop it.
+---
+ modules/pam_namespace/pam_namespace.c | 18 +-
+ 1 file changed, 1 insertion(+), 17 deletions(-)
+
+diff --git a/modules/pam_namespace/pam_namespace.c 
b/modules/pam_namespace/pam_namespace.c
+index 2528cff86da3..f72d6718901e 100644
+--- a/modules/pam_namespace/pam_namespace.c
 b/modules/pam_namespace/pam_namespace.c
+@@ -1201,7 +1201,7 @@ static int protect_dir(const char *path, mode_t mode, 
int do_mkdir,
+   int dfd = AT_FDCWD;
+   int dfd_next;
+   int save_errno;
+-  int flags = O_RDONLY;
++  int flags = O_RDONLY | O_DIRECTORY;
+   int rv = -1;
+   struct stat st;
+ 
+@@ -1255,22 +1255,6 @@ static int protect_dir(const char *path, mode_t mode, 
int do_mkdir,
+   rv = openat(dfd, dir, flags);
+   }
+ 
+-  if (rv != -1) {
+-  if (fstat(rv, ) != 0) {
+-  save_errno = errno;
+-  close(rv);
+-  rv = -1;
+-  errno = save_errno;
+-  goto error;
+-  }
+-  if (!S_ISDIR(st.st_mode)) {
+-  close(rv);
+-  errno = ENOTDIR;
+-  rv = -1;
+-  goto error;
+-  }
+-  }
+-
+   if (flags & O_NOFOLLOW) {
+   /* we are inside user-owned dir - protect */
+   if (protect_mount(rv, p, idata) == -1) {
+-- 
+2.43.0
+
diff -Nru pam-1.4.0/debian/patches/series pam-1.4.0/debian/patches/series
--- pam-1.4.0/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ 

Bug#1056841: pymatgen: ftbfs with cython 3.0.x

[Drew Parsons]

On 2024-01-19 18:52, Drew Parsons wrote:


Hi Andreas, could you push your upstream and pristine-tar branches?
Otherwise we can't use your 2023.12.18 branch.



I see what you mean.  The tag is there, the orig tarball can be 
regenerated with

gbp export-orig.

Bug#1058040: pymatgen: FTBFS with Python 3.12

[Drew Parsons]

Source: pymatgen
Followup-For: Bug #1058040

No, other way around. The new monty is causing the problem.
Will need to patch or upgrade pymatgen.

Bug#1016694: favicon.ico on packges.debian.org

[Laura Arjona Reina]

Hello

Thanks for the report. This was already reported in bug #1016694 (in 
CC), and I have committed the change in the packages repo:


https://salsa.debian.org/webmaster-team/packages/-/commit/4a1f6cc787af10d1207d3127d679e93b48fcd99b

I leave open the bug because this still needs to be deployed in 
packages.debian.org


Kind regards


El 12/1/24 a las 3:18, Nick Hastings escribió:

Hi,

http://packages.debian.org suggests emailing this list for problems with
that web site.

I noticed that packages.debian.org uses a different favicon.ico to that
of www.debian.org. The reason that I noticed is because the
packages.debian.org favicon does not look so great when rendered on a
dark background.

I wonder if could be updated to use the same one as www.debian.org?

Note that there are other pages under debian.org that suffer this same
problem and I have been attempting to contact the relevant people with
mixed success. Eg https://search.debian.org/

Cheers,

Nick.


--
Laura Arjona Reina

Bug#1058040: pymatgen: FTBFS with Python 3.12

[Drew Parsons]

Source: pymatgen
Followup-For: Bug #1058040

Sounds like it will need the new version of monty

Bug#1016694: favicon.ico on packges.debian.org

[Laura Arjona Reina]

Hello

Thanks for the report. This was already reported in bug #1016694 (in 
CC), and I have committed the change in the packages repo:


https://salsa.debian.org/webmaster-team/packages/-/commit/4a1f6cc787af10d1207d3127d679e93b48fcd99b 



I leave open the bug because this still needs to be deployed in 
packages.debian.org


Kind regards


El 12/1/24 a las 3:18, Nick Hastings escribió:

Hi,

http://packages.debian.org suggests emailing this list for problems with
that web site.

I noticed that packages.debian.org uses a different favicon.ico to that
of www.debian.org. The reason that I noticed is because the
packages.debian.org favicon does not look so great when rendered on a
dark background.

I wonder if could be updated to use the same one as www.debian.org?

Note that there are other pages under debian.org that suffer this same
problem and I have been attempting to contact the relevant people with
mixed success. Eg https://search.debian.org/

Cheers,

Nick.



--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#1061155: cron: "crontab -e" does not report "unsafe" mail and so job output can be lost

[Jonathan H N Chin]

Package: cron
Version: 3.0pl1-182
Severity: grave
Justification: causes non-serious data loss

Dear Maintainer,


   * What led up to the situation?

1. A user ran "crontab -e"

2. He added the line (note the space):

MAILTO=a...@example.org, b...@example.com


3. He saved and exited

4. No errors were reported to the user.


   * What was the outcome of this action?

Subsequently, jobs ran but output was discarded.

/var/log/syslog contains "UNSAFE MAIL" messages which the user cannot see.


   * What outcome did you expect instead?

At step 4, crontab should have reported an error to the user
and not applied the update.



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

Kernel: Linux 5.15.0-91-generic (SMP w/1 CPU thread)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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)

Versions of packages cron depends on:
ii  cron-daemon-common   3.0pl1-182
ii  init-system-helpers  1.66
ii  libc62.37-13
ii  libpam-runtime   1.5.2-9.1
ii  libpam0g 1.5.2-9.1+b1
ii  libselinux1  3.5-1+b2
ii  sensible-utils   0.0.20

Versions of packages cron recommends:
ii  exim4-daemon-heavy [mail-transport-agent]  4.97-4+b1

Versions of packages cron suggests:
pn  anacron
pn  checksecurity  
ii  logrotate  3.21.0-2

Versions of packages cron is related to:
pn  libnss-ldap   
pn  libnss-ldapd  
pn  libpam-ldap   
pn  libpam-mount  
pn  nis   
pn  nscd  

-- no debconf information

Bug#1061091: syntax/fortran.vim: incorrectly highlights identifiers, when they contain some keyword

[Francesco Poli]

On Fri, 19 Jan 2024 00:26:08 +0100 Francesco Poli wrote:

> On Thu, 18 Jan 2024 07:56:08 -0500 James McCoy wrote:
> 
> [...]
> > The latest upload has already fixed this.  It should migrate to testing
> > as part of the ongoing Perl transition.
> 
> Thanks a lot for your very prompt reply!
> I'll wait for the Perl transition to be completed and then I'll see.
[...]

I've just upgraded vim-runtime (along with many other
Perl-transition-related packages) and I can confirm that Fortran syntax
highlighting works again!

Thanks again for dealing with this bug report.
Bye!:-)


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


pgpp50ocSG06P.pgp
Description: PGP signature

Bug#799392: closed by Debian FTP Masters (reply to Martin Buck ) (Bug#799392: fixed in calc 2.15.0.4-1)

[Francesco Poli]

On Fri, 19 Jan 2024 02:39:14 + Debian Bug Tracking System wrote:

[...]
>* New upstream version 2.15.0.4
>  Closes: #799392 - document the need to use '-p' in scripts, see
>  https://github.com/lcn2/calc/issues/133 for details).
[...]

Thank you so much for checking and closing the bug report!

The following script works correctly:

  $ cat calc_script.cal 
  #!/usr/bin/calc -q -p -f

  n = eval(prompt("Enter a number: ")) ;
  printf("%r\n", n+1) ;


So it just needed the '-p' option to be added to the shebang...
Nice!

Thanks again and bye!   :-)


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


pgpdVMr80YrTL.pgp
Description: PGP signature

Bug#921150: RFS: golang-github-arduino-go-paths-helper [ITP]

[Nicolas Peugnet]

On Thu, 8 Apr 2021 21:56:35 +0100 Rock Storm  wrote:

Hi Nilesh,

Thank you for you offer. I'm sorry, I completely forgot about this bugs.
I wanted these libraries (#921150 and #922528) to be uploaded in order
to package the latest 'arduino-builder'. However, we finally decided to
keep the current version since 'arduino-builder' will be superseded by
'arduino-cli' in the near future anyway.

I would not close the ITPs nor remove the work from Salsa since I suspect
they will be necessary for 'arduino-cli' though I haven't looked into
this yet. I guess the RFS (#934515) could be closed as "wontfix" and/or
tagged as "bullseye-ignore" and simply left open for later. I'm easy.


Hi,

I would be very interested by the addition of 'arduino-cli' to the 
Debian repository. Indeed, the now deprecated 'arduino-builder' does not 
support newer Arduino boards like the Nano 33 family and I suspect more 
of them.


It seems the 'arduino-cli' package is nearing a 1.0.0 stable release, 
and it is already a very capable tool, so it might be interesting to 
start packaging its dependencies.


I don't think I will be able to help packaging, but I could help testing 
packages for sure.

--
Nicolas Peugnet

Bug#1060965: q2-feature-classifier: FTBFS due to qiime AttributeError: module 'bibtexparser' has no attribute 'bparser'

[Étienne Mollier]

Control: reassign -1 src:qiime 2022.11.1-2
Control: affects -1 + q2-feature-classifier
Control: merge -1 1060987

This is another manifestation of #1060987, this time affecting
q2-feature-classifier:
> /usr/lib/python3/dist-packages/qiime2/core/cite.py:26: in load
> parser = bp.bparser.BibTexParser()
> E   AttributeError: module 'bibtexparser' has no attribute 'bparser'

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-


signature.asc
Description: PGP signature

Bug#1060987: q2cli: FTBFS: AttributeError: module 'bibtexparser' has no attribute 'bparser'

[Étienne Mollier]

Control: reassign -1 src:qiime/2022.11.1-2
Control: retitle -1 qiime: FTBFS: AttributeError: module 'bibtexparser' has no 
attribute 'bparser'
Control: affects -1 + q2cli

This looks to be the main issue:
> /usr/lib/python3/dist-packages/qiime2/core/cite.py:26: in load
> parser = bp.bparser.BibTexParser()
> E   AttributeError: module 'bibtexparser' has no attribute 'bparser'

Since update of bibtexparser to 2.0.0b, the bparser has been
either removed or not reimplemented yet.  The documentation
exposed in the bibtexparser source code gives little clue how to
migrate from that particular situation.  Quick lookup at
contemporary qiime source code[1] shows the invocation is still
around as of today, so an upstream version bump won't help yet.

Maybe an option could be to avoid attemting to apply the bibtex
parser customization when the bparser does not exist anymore?
I'm not entirely confident on the side effects downstream.  Only
other option I can think of would be to wait and see how the
bibtexparser v2.0.0 release will behave if there are planned
changes on the parser or unicode customizations front.

[1]: https://github.com/qiime2/qiime2/blob/dev/qiime2/core/cite.py

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/3, please excuse my verbosity
   `-on air: Fish - Little Man What Now?


signature.asc
Description: PGP signature

Bug#1056841: pymatgen: ftbfs with cython 3.0.x

[Drew Parsons]

On 2024-01-16 17:55, Andreas Tille wrote:

Control: tags -1 pending

Hi,

I've applied the patch in Git and also tried to upgrade to latest
upstream since there is a chance that other Python3.12 issues might be
fixed.  Unfortunately the upgrade is all but straightforward and
I gave up finally over the changes in the sphinx documention where
finally some files are missing.  I've created a branch 2023.12.18
which fails with

  Sphinx error:
  root file /build/pymatgen-2023.12.18+dfsg1/docs/apidoc/index.rst not 
found


I hope that my preliminary work might be helpful for the package
but I have to give up now due to time constraints.

Hope this helps
   Andreas.


Hi Andreas, could you push your upstream and pristine-tar branches?
Otherwise we can't use your 2023.12.18 branch.

Drew

Bug#1061148: apt: option -a has several meanings and is unusable

[David Kalnischkies]

On Fri, Jan 19, 2024 at 05:10:40PM +0100, Vincent Lefevre wrote:
> The -a=... version is not documented in the manual, only -a alone,

Compare -t, which also doesn't say -t=foo. Probably mostly due to -t foo
working as well or just because the manpages like their inconsistencies
and would deserve some love, but who has the time to not just complain
but also actually write all of it…


(reordered for posterity)

>-a, --host-architecture
>This option controls the architecture packages are built for by
>apt-get source --compile and how cross-builddependencies are
>satisfied.
> 
> There are 2 verbs "controls" and "are built". And I don't see how
> to parse "for by".

A package is "built for" the given (with -a) host architecture by
"apt-get source --compile" – aka its instructed to cross-compile
a package for the given host architecture instead of doing a "normal"
compile where host and build architecture are the same.

So, "apt-get source -b -a armhf foo" will (simplified) build a
"foo_armhf.deb" on your (likely amd64) machine to be used on another
(probably less powerful) armhf machine. Similar for build-dep, just
that this won't build anything but interprets certain dependencies
differently.

Using the option properly requires preparations that would fill their
own manpage to explain properly and its certainly not APTs place to do
that as it is just a tiny cog in the cross-machinery.


> Still, I don't see what this option does.

So, long story short: You would if you would need that option, but you
don't need it, so you don't.

--print-uris prints URIs; nowhere is explained what URI stands
for, it is just assumed that people who need it will know.

Hey, quick, what is a "build profile" and can you name a few?
Now go and ask that question another user and see how that goes.


>By default is it not set which means that the host
>architecture is the same as the build architecture (which is
>defined by APT::Architecture). Configuration Item:
>APT::Get::Host-Architecture.

> In the next sentence: "is it". Should this be
> "it is"? The comma is missing before "which".

Perhaps it should, "is it not" has the hint of a question. In German
I would write such a sentence without a comma as the added phrase isn't
[that] optional, but not sure if a German – or English – teacher would
actually agree on me claiming "definition phrase", which are not
separated by commas in both languages. Could easily be done without
a which if we were really trying.

Doesn't matter that much through as I would agree that the manpage(s)
need a revamp, but certainly not by me and not based on this. For this
specific option in particular, 99% of the user base are probably better
served if we were to remove its documentation entirely.

What about the 1%? Well, they deserve to write the patches to improve
the manpage and potentially fixup the translations (depending on how
much they reword here).

[Case in point, the option as documented doesn't work for years and
 nobody noticed – because 1% was an overstatement already; fixed in git]


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1055194: transition: openturns

[Pierre Gruet]

Dear Release Team,

I think this bug can be closed now, as the transition has been done.

I am not doing it myself in case I might have missed something...

Best,

--
Pierre


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061151: asymptote: should run tests at build time

[Sven Joachim]

On 2024-01-19 17:11 +0100, Sven Joachim wrote:

> Source: asymptote
> Version: 2.86+ds1-1
>
> Your package has a test suite that probably should be run at build time,
> but it is not.  I looked at the git repository and found that it has
> been disabled since at least 2015:
>
> ,
> | $ git show f69991bf3
> | commit f69991bf3cf85c0560ac93a2b24d96ce67c061d9
> | Author: Norbert Preining 
> | Date:   Tue Jun 23 08:41:59 2015 +0900
> |
> | do not do testing
> |
> | diff --git a/debian/rules b/debian/rules
> | index 6d9d7387..2d52d8f6 100755
> | --- a/debian/rules
> | +++ b/debian/rules
> | @@ -22,6 +22,9 @@ override_dh_auto_install:
> | make install-asy DESTDIR=$(CURDIR)/debian/tmp
> | dh_installtex -pasymptote
> |
> | +override_dh_auto_test:
> | +   : do nothing here, otherwise make tries to compile prc/test.cc
> | +
> |  override_dh_clean:
> | dh_clean
> | rm --force doc/latexusage.pdf doc/latexusage.dvi 
> doc/TeXShopAndAsymptote.dvi doc/CAD.dvi
> `
>
> This leaves me rather puzzled: why exactly would it bad if make tries to
> compile prc/test.cc?

Out of curiosity, I removed the dh_auto_test override and built the
package with "sbuild --no-arch-all".  This ran the test suite where
various files were compiled, but not prc/test.cc.  The build was
successful.

This was on amd64, and I have not tested binary-indep or full builds.
You may want to upload to experimental first to see how other
architectures work.

Cheers,
   Sven

Bug#1061154: neovim: Enable luajit on arm64

[Michael Fladischer]

Package: neovim
Version: 0.9.5-4
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

please enable luajit on arm64.
I did a test-build on my arm64 machine and it worked as expected with luajit
enabled.

Regards,
Michael


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

Kernel: Linux 5.10.110-rockchip-rk3588 (SMP w/8 CPU threads)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_DK.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages neovim depends on:
ii  libc62.37-13
ii  liblua5.1-0  5.1.5-9
ii  libmsgpackc2 4.0.0-3
ii  libtermkey1  0.22-1
ii  libtree-sitter0  0.20.8-2
ii  libunibilium42.1.0-3
ii  libuv1   1.46.0-3
ii  libvterm00.3.3-1
ii  lua-bitop1.0.2-7
ii  lua-luv  1.44.2-0-1
ii  neovim-runtime   0.9.5-4

Versions of packages neovim recommends:
ii  python3-pynvim   0.5.0-1
pn  xclip | xsel | wl-clipboard  
ii  xxd  2:9.1.0016-1

Versions of packages neovim suggests:
ii  universal-ctags [ctags]  5.9.20210829.0-1
pn  vim-scripts  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmWqqD8bHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqWUoIALT6fWmo65O6dx7Gd8X9
Z9/Ko0vxNkqcQ2VA+oABNWaxQydfS+w2HHCzKuufdm7IkX9sFCIag7EIf5ioJb4i
HUhJPf6kmcsNaNcEGk8u1Mef7MfCGICHfrX5KtgxanJFytZNr0JAH7I2rD75epqB
5aQiocw8MQeckTZqrhcrVdL75LYdjXrZcc/zfQmo84/aEMztO3Gq9+iiv/xCaUKv
1Bzuv2N6xFwe9nSDa99HO9eAuusfytWTV3fiqM7R9cOuNCNsQ/CWcebePZup1l1h
v2Ek7ppYSgXjAwIzEKFsaT2kzUcElODiY1clwq1kjEav5R0CFw2BDp/9V9wTUsbq
0Oo=
=vlpc
-END PGP SIGNATURE-

Bug#1061148: apt: option -a has several meanings and is unusable

[Julian Andres Klode]

On Fri, Jan 19, 2024 at 05:10:40PM +0100, Vincent Lefevre wrote:
> On 2024-01-19 16:43:24 +0100, Julian Andres Klode wrote:
> > On Fri, Jan 19, 2024 at 03:43:25PM +0100, Vincent Lefevre wrote:
> > > Package: apt
> > > Version: 2.7.9
> > > Severity: normal
> > > 
> > > In the apt-get(8) man page:
> > > 
> > >apt-get [-asqdyfmubV] [-o=config_string] [-c=config_file]
> > >[-t=target_release] [-a=architecture] {update | upgrade |
> > >dselect-upgrade | dist-upgrade |
> > >install pkg [{=pkg_version_number | /target_release}]...  |
> > >remove pkg...  | purge pkg...  |
> > >source pkg [{=pkg_version_number | /target_release}]...  |
> > >build-dep pkg [{=pkg_version_number | /target_release}]... 
> > >  |
> > >download pkg [{=pkg_version_number | /target_release}]...  
> > > |
> > >check | clean | autoclean | autoremove | {-v | --version} |
> > >{-h | --help}}
> > > 
> > > So option -a appears both as a single option -a and as -a=architecture.
> > > 
> > > In the apt(8) man page, only the second form is listed, but for both
> > > commands, it is unusable:
> > > 
> > > # apt-get -a=i386 install libfontconfig-dev
> > > E: Command line option 'a' [from -a=i386] is not understood in 
> > > combination with the other options.
> > > 
> > > # apt -a=i386 install libfontconfig-dev
> > > E: Command line option 'a' [from -a=i386] is not understood in 
> > > combination with the other options.
> > 
> > -a in that sense is an argument to build-dep and family (source --build,
> > satisfy). It is short for host-architecture, and makes no sense in any
> > other command.
> 
> Perhaps this should be explicitly documented. And the error message
> should be clarified (note: "install" is a command, not an option).
> 
> > You seem to be trying to install libfontconfig-dev:i386
> 
> OK, but I was looking at an option to install several packages
> (package list to be copy-pasted) for a foreign architecture
> without much typing.
> 
> > We haven't explained that it works outside of source --compile and
> > build-dep (i.e. in satisfy) but I fail to see how you get to try
> > to pass this to install after reading the manual page.
> 
> The -a=... version is not documented in the manual, only -a alone,
> but even for that, I don't understand the manual; the grammar seems
> incorrect:
> 
>-a, --host-architecture
>This option controls the architecture packages are built for by
>apt-get source --compile and how cross-builddependencies are
>satisfied. By default is it not set which means that the host
>architecture is the same as the build architecture (which is
>defined by APT::Architecture). Configuration Item:
>APT::Get::Host-Architecture.
> 
> There are 2 verbs "controls" and "are built". And I don't see how
> to parse "for by". In the next sentence: "is it". Should this be
> "it is"? The comma is missing before "which". Still, I don't see
> what this option does.

apt-get source --compile compiles packages. For cross-compilation,
you need to set the host architecture. This option controls that.

And yes this is just runaway without punctuation, but uh wording
is hard and we really just want to rewrite all manual pages from
scratch.

Then you'll see -a, --host-architecture in the apt-build-dep
and apt-source and apt-satisfy manual pages (maybe they are all
the same, who knows).


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

Bug#1061063: armhf: h5py's tests expose unaligned memory accesses during the build

[Drew Parsons]

Source: h5py
Followup-For: Bug #1061063
Control: forwarded 1061063 https://github.com/h5py/h5py/issues/1927

The problem was raised upstream at
https://github.com/h5py/h5py/issues/1927

Makes it difficult to test if we can't reproduce it on all armhf
environments.

A patch was suggested for the upstream report but has already been
applied (fix-unaligned-access.patch).

I'm not sure that we can do much more than that, since we can't
reproduce the bug on debian armhf systems.

Bug#1061153: ITP: sigsum-go -- tools for public and transparent logging of signed checksums

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: sigsum-go
  Version : 1.7.1-1
  Upstream Author : The Sigsum Project Authors
* URL : https://git.glasklar.is/sigsum/core/sigsum-go
* License : BSD-2-Clause
  Programming Lang: Go
  Description : tools for public and transparent logging of signed checksums

 The goal of Sigsum is to provide building blocks that can be used to
 enforce public logging of signed checksums.
 .
 This package contains the sigsum-key, sigsum-submit, sigsum-verify,
 and sigsum-monitor command line tools.

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

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

/Simon


signature.asc
Description: PGP signature

Bug#1061152: asymptote: autopkgtest should test installed package

[Sven Joachim]

Package: asymptote
Version: 2.86+ds1-1

Your package's autopkgtest runs the upstream test suite which is nice.
However, it first builds the program and then tests that, rather than
the package from the archive.  This is not very useful, as changes in
reverse dependencies could cause breakage at runtime which might vanish
after a rebuild.

In #1061151 I have requested that the test suite be run at build time.

Cheers,
   Sven

Bug#1061146: Unintended effect of Patch

[Carlos Castro]

The media keys on a Apple MacBook 5.2 "mute", "volume down" and "volume up"
now work!
they did not work before, but after the patch was installed and the
corresponding keyboard "Portuguese (Macintosh)" is selected via the menu on
Gnome Wayland
If other layout is select, only tested "Portuguese" and "en", the referred
media keys stop working.

Bug#1060897: Bug #1060897: furo: documentation generated with Debian's furo package doesn't work standalone

[Georges Khaznadar]

Hi,

I patched the file src/furo/__init__.py, to enforce the attribute
type="module" when the script furo.js is embedded in a web page.
Then the syntax 
   import * as Gumshoe from "./gumshoe-patched.js"
is accepted.

I hope that the release 2023.09.10+dfsg-4 can fix the bug definitely.

Best regards,   Georges.

On Fri, 19 Jan 2024 14:16:31 +0100 Raphael Hertzog  wrote:
> Control: reopen -1
> 
> On Fri, 19 Jan 2024, Debian Bug Tracking System wrote:
> >  furo (2023.09.10+dfsg-3) unstable; urgency=medium
> >  .
> >* included the code from normalize.css into furo.css instead of
> >  the include directive. Closes: #1060897
> 
> Thanks for this fix! Unfortunately, this only solves one of the two
> problems that I reported in #1060897 (I know that I should have opened two
> bugs...).
> 
> The other one was about the javascript in furo.js failing to execute (at
> least in Firefox in unstable) with this error message:
> 
> Uncaught SyntaxError: import declarations may only appear at top level of a 
> module
> 
> As I said in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060897#10
> that import statement is not present in a regular furo.js as built
> by the upstream build system because the file is post-processed and
> minified. Ex here:
> https://pradyunsg.me/furo/_static/scripts/furo.js
> 
> So I assume we need to post-process the file in some similar way to get it
> to work or tweak the way we import the code to allow the import statement
> to work but I'm not a big fan of diverting too much from upstream and we
> are doing this a lot here (but it's often unavoidable with all packages
> relying on the node ecosystem in some way). :-(
> 
> Cheers,
> -- 
>   ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
>   ⣾⠁⢠⠒⠀⣿⡁
>   ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
>   ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
> 
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1061148: apt: option -a has several meanings and is unusable

[Vincent Lefevre]

On 2024-01-19 16:43:24 +0100, Julian Andres Klode wrote:
> On Fri, Jan 19, 2024 at 03:43:25PM +0100, Vincent Lefevre wrote:
> > Package: apt
> > Version: 2.7.9
> > Severity: normal
> > 
> > In the apt-get(8) man page:
> > 
> >apt-get [-asqdyfmubV] [-o=config_string] [-c=config_file]
> >[-t=target_release] [-a=architecture] {update | upgrade |
> >dselect-upgrade | dist-upgrade |
> >install pkg [{=pkg_version_number | /target_release}]...  |
> >remove pkg...  | purge pkg...  |
> >source pkg [{=pkg_version_number | /target_release}]...  |
> >build-dep pkg [{=pkg_version_number | /target_release}]...  |
> >download pkg [{=pkg_version_number | /target_release}]...  |
> >check | clean | autoclean | autoremove | {-v | --version} |
> >{-h | --help}}
> > 
> > So option -a appears both as a single option -a and as -a=architecture.
> > 
> > In the apt(8) man page, only the second form is listed, but for both
> > commands, it is unusable:
> > 
> > # apt-get -a=i386 install libfontconfig-dev
> > E: Command line option 'a' [from -a=i386] is not understood in combination 
> > with the other options.
> > 
> > # apt -a=i386 install libfontconfig-dev
> > E: Command line option 'a' [from -a=i386] is not understood in combination 
> > with the other options.
> 
> -a in that sense is an argument to build-dep and family (source --build,
> satisfy). It is short for host-architecture, and makes no sense in any
> other command.

Perhaps this should be explicitly documented. And the error message
should be clarified (note: "install" is a command, not an option).

> You seem to be trying to install libfontconfig-dev:i386

OK, but I was looking at an option to install several packages
(package list to be copy-pasted) for a foreign architecture
without much typing.

> We haven't explained that it works outside of source --compile and
> build-dep (i.e. in satisfy) but I fail to see how you get to try
> to pass this to install after reading the manual page.

The -a=... version is not documented in the manual, only -a alone,
but even for that, I don't understand the manual; the grammar seems
incorrect:

   -a, --host-architecture
   This option controls the architecture packages are built for by
   apt-get source --compile and how cross-builddependencies are
   satisfied. By default is it not set which means that the host
   architecture is the same as the build architecture (which is
   defined by APT::Architecture). Configuration Item:
   APT::Get::Host-Architecture.

There are 2 verbs "controls" and "are built". And I don't see how
to parse "for by". In the next sentence: "is it". Should this be
"it is"? The comma is missing before "which". Still, I don't see
what this option does.

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

Bug#1061151: asymptote: should run tests at build time

[Sven Joachim]

Source: asymptote
Version: 2.86+ds1-1

Your package has a test suite that probably should be run at build time,
but it is not.  I looked at the git repository and found that it has
been disabled since at least 2015:

,
| $ git show f69991bf3
| commit f69991bf3cf85c0560ac93a2b24d96ce67c061d9
| Author: Norbert Preining 
| Date:   Tue Jun 23 08:41:59 2015 +0900
|
| do not do testing
|
| diff --git a/debian/rules b/debian/rules
| index 6d9d7387..2d52d8f6 100755
| --- a/debian/rules
| +++ b/debian/rules
| @@ -22,6 +22,9 @@ override_dh_auto_install:
| make install-asy DESTDIR=$(CURDIR)/debian/tmp
| dh_installtex -pasymptote
|
| +override_dh_auto_test:
| +   : do nothing here, otherwise make tries to compile prc/test.cc
| +
|  override_dh_clean:
| dh_clean
| rm --force doc/latexusage.pdf doc/latexusage.dvi 
doc/TeXShopAndAsymptote.dvi doc/CAD.dvi
`

This leaves me rather puzzled: why exactly would it bad if make tries to
compile prc/test.cc?

Note that the test suite is run in an autopkgtest since version
2.73+ds-2, so it apparently works.

Cheers,
   Sven

Bug#1061148: apt: option -a has several meanings and is unusable

[Julian Andres Klode]

On Fri, Jan 19, 2024 at 03:43:25PM +0100, Vincent Lefevre wrote:
> Package: apt
> Version: 2.7.9
> Severity: normal
> 
> In the apt-get(8) man page:
> 
>apt-get [-asqdyfmubV] [-o=config_string] [-c=config_file]
>[-t=target_release] [-a=architecture] {update | upgrade |
>dselect-upgrade | dist-upgrade |
>install pkg [{=pkg_version_number | /target_release}]...  |
>remove pkg...  | purge pkg...  |
>source pkg [{=pkg_version_number | /target_release}]...  |
>build-dep pkg [{=pkg_version_number | /target_release}]...  |
>download pkg [{=pkg_version_number | /target_release}]...  |
>check | clean | autoclean | autoremove | {-v | --version} |
>{-h | --help}}
> 
> So option -a appears both as a single option -a and as -a=architecture.
> 
> In the apt(8) man page, only the second form is listed, but for both
> commands, it is unusable:
> 
> # apt-get -a=i386 install libfontconfig-dev
> E: Command line option 'a' [from -a=i386] is not understood in combination 
> with the other options.
> 
> # apt -a=i386 install libfontconfig-dev
> E: Command line option 'a' [from -a=i386] is not understood in combination 
> with the other options.

-a in that sense is an argument to build-dep and family (source --build,
satisfy). It is short for host-architecture, and makes no sense in any
other command.

You seem to be trying to install libfontconfig-dev:i386

We haven't explained that it works outside of source --compile and
build-dep (i.e. in satisfy) but I fail to see how you get to try
to pass this to install after reading the manual page.

The help output obviously can't tell you which commands support
which arguments.

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

Bug#1040603: Bug#1042027: transmission 4.0.5-1

[Alexandre Rossi]

Hi,

> > please push this packaging effort to a personal (but publicly
> > accessible) git repo on salsa, so that i can cherry pick the changes i
> > like, thanks
> 
> Here:
> 
> 
> https://salsa.debian.org/niol/transmission/-/tree/master-candidate?ref_type=heads

I've also updated my pull request to make it easier to review cherry-picking
the appropriate change.

https://salsa.debian.org/debian/transmission/-/merge_requests/16

Thanks,

Alex

Bug#1061150: php8.3: Move disabling the upstream GC routine to a patch to improve documentation

[Athos Ribeiro]

Package: php8.3
Severity: normal
Tags: patch
X-Debbugs-Cc: athos.ribe...@canonical.com

Dear Maintainer,

as discussed in
https://salsa.debian.org/php-team/php/-/merge_requests/11, moving the
logic to disable the upstream GC routine from d/rules to a patch would
improve documenting such change withing the ini files.

This should fix #831752.

I am now refreshing
https://salsa.debian.org/php-team/php/-/merge_requests/11 (PHP 8.1) for
PHP 8.3 at
https://salsa.debian.org/php-team/php/-/merge_requests/16/diffs?commit_id=f456e0d1e96e2db901a82bc6c5b0591a0ef32416

Thanks!

Bug#1061149: php8.3: Broken PHP_EXTRA_VERSION logic in d/rules

[Athos Ribeiro]

Package: php8.3
Severity: normal
Tags: patch
X-Debbugs-Cc: athos.ribe...@canonical.com

Dear Maintainer,

The PHP_EXTRA_VERSION variable used to be configured in debian/rules
before PHP 7.4. After this, the upstream configure.ac file changed and
the sed command in debian/rules became a no-op.

This patch restores the former behaviour to set the PHP_EXTRA_VERSION
with the debian release so the internal PHP version will be the same as
the package version:

https://salsa.debian.org/php-team/php/-/merge_requests/14

However, a fix for a related upstream issue at
https://bugs.php.net/bug.php?id=79026 has been merged
(https://github.com/php/php-src/commit/d35df89c357dafdfc383e1272c4121a416ac3482)
and is available in php 8.3.x.

Hence, we could consider the following fix:
https://salsa.debian.org/php-team/php/-/merge_requests/16/diffs?commit_id=412633246bab5d04cda3aba747612ba9f3a5f62f

This may be specially useful for users who want to inspect (from within
their PHP code) if specific fixes are available in stable releases.

Bug#1061148: apt: option -a has several meanings and is unusable

[Vincent Lefevre]

Package: apt
Version: 2.7.9
Severity: normal

In the apt-get(8) man page:

   apt-get [-asqdyfmubV] [-o=config_string] [-c=config_file]
   [-t=target_release] [-a=architecture] {update | upgrade |
   dselect-upgrade | dist-upgrade |
   install pkg [{=pkg_version_number | /target_release}]...  |
   remove pkg...  | purge pkg...  |
   source pkg [{=pkg_version_number | /target_release}]...  |
   build-dep pkg [{=pkg_version_number | /target_release}]...  |
   download pkg [{=pkg_version_number | /target_release}]...  |
   check | clean | autoclean | autoremove | {-v | --version} |
   {-h | --help}}

So option -a appears both as a single option -a and as -a=architecture.

In the apt(8) man page, only the second form is listed, but for both
commands, it is unusable:

# apt-get -a=i386 install libfontconfig-dev
E: Command line option 'a' [from -a=i386] is not understood in combination with 
the other options.

# apt -a=i386 install libfontconfig-dev
E: Command line option 'a' [from -a=i386] is not understood in combination with 
the other options.

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (/etc/apt/preferences.d/no-adobe-flash-plugin present, but not submitted) --


-- (/etc/apt/preferences.d/no-pipewire present, but not submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/local-i386.list present, but not submitted) --


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

Kernel: Linux 6.6.11-amd64 (SMP w/12 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 apt depends on:
ii  adduser 3.137
ii  base-passwd 3.6.3
ii  debian-archive-keyring  2023.4
ii  gpgv2.2.40-1.1+b1
ii  libapt-pkg6.0   2.7.9
ii  libc6   2.37-13
ii  libgcc-s1   13.2.0-9
ii  libgnutls30 3.8.3-1
ii  libseccomp2 2.5.5-1
ii  libstdc++6  13.2.0-9
ii  libsystemd0 255.2-4

Versions of packages apt recommends:
ii  ca-certificates  20230311

Versions of packages apt suggests:
ii  apt-doc 2.7.9
ii  aptitude0.8.13-5+b1
ii  dpkg-dev1.22.2
ii  gnupg   2.2.40-1.1
ii  powermgmt-base  1.37

-- no debconf information

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

Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.

[Aidan]

Thanks for taking the time to comment Guillem.

On Fri, 19 Jan 2024, 00:08 Guillem Jover,  wrote:

> Hi!
>
> On Thu, 2024-01-18 at 23:14:49 +, Aidan wrote:
> > On Thu, Jan 18, 2024 at 6:30 PM David Kalnischkies wrote:
> > > On Thu, Jan 18, 2024 at 02:35:40PM +, Aidan wrote:
> > > > I am looking for a sponsor for my package "dpkg-buildenv":
> > >
> > > Similar to my recent "veto" of apt-verify in #1059267, which was
> > > subsequently ignored and pushed into the archive anyhow, I would
> > > like to call into question the naming of the package/application…
> > >
> > > There are various "dpkg-build*" tools already that grabbing 'env' feels
> > > wrong (I would confuse it probably with 'flag' on a bad day),
> especially
> > > if that isn't at least discussed with dpkg maintainers (I at least see
> > > no mention of it on the list) and given that this is something that
> > > "just" works with Docker.
>
> Just by chance I had seen the mail on the mentors list, but thanks for
> the heads-up, because I tend to look there very sporadically!
>
> My reaction was pretty similar TBH. There's enough confusion with
> things like dpkg-reconfigure and dpkg-preconfigure and other packages
> that have also grabbed from the dpkg-* namespace, which I'd like to
> reduce. In this case, it would remove the possibility to use such name
> in the future, creates confusion, and it looks like a layer violation,
> because it's setting up apt, containers and stuff which should be
> sitting on top and not below dpkg.
>

That's a good point about it looking like a layer violation.


>
> > > As explained in the other bug, there is no veto and as you can see its
> > > easy to completely ignore me (and anyone else) but I wanted to say it
> > > anyhow, so that nobody is surprised later on.
>
> > Thanks for taking a look David.
> > For the name I choose "dpkg'' because it stands for "debian package" and
> > dpkg-buildenv is intrinsically related to debian packaging.
> > However I understand the usage of dpkg may imply the package has been
> > officially created and maintained by the dpkg developers.
>
> Yes, see above. I also appreciate naming is hard, :) but all other
> similar implementations could have claimed the same about using dpkg-*,
> and I think josch questions are also relevant, even though I also
> understand that even among all other options, none might seem
> completely suitable to you. But…
>
> > If the package's name was the last blocking issue preventing adoption in
> > Debian then I would spend the time to rename it.
>
> …regardless of whether this is or not the last blocking issue, I'd
> still very much appreciate if you could rename the project and tool
> upstream. :)


I shall rename the tool to remove "dpkg". Unless there are any objections
I'm going to rename it to:
"debpic: DEbian Build Package In Container"





>
> Thanks,
> Guillem
>

Bug#1061147: python3-pandas-flavor: Package short description ends in long description, leaving both incomplete

[Beatrice Torracca]

Package: python3-pandas-flavor
Severity: minor

Hi,

the package description of  python3-pandas-flavor actually has the short 
description only reading "Pandas Flavor allows you add" which is not a complete 
description.

This sentence continues in the long description. As such even the long 
description by itself is not correct.

The short description and the long one should be each self-sufficient; there 
are rules in the debian policy for their format.

Thanks for the packaging work,

beatrice

Bug#1061133: libsoup3: Build profiles don't actually work

[Simon McVittie]

On Fri, 19 Jan 2024 at 12:34:24 +0100, John Paul Adrian Glaubitz wrote:
> Could you perform a new upload of libsoup3 within the next days so I can
> bootstrap the package for sh4 again?

It isn't my highest priority, but I'll try to get that far down my queue
at some point.

(Or other GNOME team maintainers are very welcome to take over if someone
prioritizes it higher, I don't have any particular sense of ownership
over this package.)

smcv

Bug#1014862: vdr-plugin-markad: FTBFS: Cannot find (any matches for) "command/markad"

[Christoph Martin]

notfound 1014862 3.4.5-1
thanks

In the current build this bug does not exist.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061143: gobject-introspection: FTBFS with Python 3.12 as default

[Simon McVittie]

On Fri, 19 Jan 2024 at 15:15:23 +0200, Graham Inggs wrote:
> On Fri, 19 Jan 2024 at 14:46, Simon McVittie  wrote:
> > I would guess that the problem is that it still uses python3-distutils
> > (that's being worked on upstream, but slower than I would like), but even
> > though that package Provides python3.12-distutils, it doesn't contain
> > an implementation.
> 
> Matthias Klose found an upstream commit [1] which I've just tested
> now, and it seems to be the only thing needed to get the tests
> passing.

Thanks, I'll apply that for now.

I think a better solution is probably the one I proposed in
https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/443
but that's still waiting for upstream review.

smcv

Bug#1061143: gobject-introspection: FTBFS with Python 3.12 as default

[Simon McVittie]

On Fri, 19 Jan 2024 at 12:46:41 +, Simon McVittie wrote:
> On Fri, 19 Jan 2024 at 13:54:26 +0200, Graham Inggs wrote:
> > gobject-introspection FTBFS with Python 3.12 as the default version.
> > I've copied what I hope is the relevant part of the log below.
> 
> This is not a very helpful log, I hope it gives more information earlier
> or later?

It does give more useful information earlier in the log, which is that
at least one of these tests (possibly all of them) fail with:

--- stderr ---
Traceback (most recent call last):
  File 
"/home/smcv/src/debian/gobject-introspection/tests/warn/warningtester.py", line 
14, in 
from giscanner.annotationparser import GtkDocCommentBlockParser
  File 
"/home/smcv/src/debian/gobject-introspection/giscanner/annotationparser.py", 
line 117, in 
from .message import Position, warn, error
  File "/home/smcv/src/debian/gobject-introspection/giscanner/message.py", line 
26, in 
from . import utils
  File "/home/smcv/src/debian/gobject-introspection/giscanner/utils.py", line 
385, in 
import distutils.cygwinccompiler
  File "/usr/lib/python3/dist-packages/_distutils_hack/__init__.py", line 97, 
in find_spec
return method()
   
  File "/usr/lib/python3/dist-packages/_distutils_hack/__init__.py", line 104, 
in spec_for_distutils
import importlib.abc
  File "/usr/lib/python3.12/importlib/abc.py", line 18, in 
from .resources import abc as _resources_abc
  File "/usr/lib/python3.12/importlib/resources/__init__.py", line 3, in 

from ._common import (
  File "/usr/lib/python3.12/importlib/resources/_common.py", line 8, in 
import inspect
  File "/usr/lib/python3.12/inspect.py", line 145, in 
import ast
  File "/home/smcv/src/debian/gobject-introspection/_build/giscanner/ast.py", 
line 27, in 
from . import message
ImportError: attempted relative import with no known parent package
==

> > Although Python 3.12 is not yet the default in Debian unstable, you
> > should be able to reproduce the failure by editing:
> > 
> > /usr/share/python3/debian_defaults
> > 
> > or by exporting DEBPYTHON3_DEFAULT=3.12 during the build.
> 
> Thanks, I had been wondering how maintainers of packages that use a single
> Python version were meant to test this!

That was not enough, but I was able to reproduce the failure by
doing those steps, installing python3.12-dev, and
"ln -fns python3.12 /usr/bin/python3".

smcv

Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable

[Arno Lehmann]

Hi all,

I have now installed an early 6.1 kernel:

$ uname -a
Linux Zwerg 6.1.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 
(2023-01-07) x86_64 GNU/Linux


and not updated anything else. Also, still running with PCIe power 
management in non-default:


# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.1.0-1-amd64 root=/dev/mapper/Zwerg--vg-root ro 
pcie_aspm=off quiet



Let's see how long this works :-) Or, rather, how much patience I have. 
Failures were between few hours and up to four weeks apart...


Cheers,

Arno

--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

Bug#1061141: gobject-introspection: missing versioned dependencies on python3

[Simon McVittie]

On Fri, 19 Jan 2024 at 14:10:17 +0200, Graham Inggs wrote:
> Adding the following lines to debian/rules worked for me:
> 
> override_dh_python3:
> dh_python3 /usr/lib/$(DEB_HOST_MULTIARCH)/gobject-introspection/giscanner/

In fact we were already doing the equivalent of this, but only for the
gobject-introspection package, so it regressed with the split into
gobject-introspection-bin. I'll fix that in the next upload to unstable.

Thanks,
smcv

Bug#1060897: Bug #1060897: furo: documentation generated with Debian's furo package doesn't work standalone

[Raphael Hertzog]

Control: reopen -1

On Fri, 19 Jan 2024, Debian Bug Tracking System wrote:
>  furo (2023.09.10+dfsg-3) unstable; urgency=medium
>  .
>* included the code from normalize.css into furo.css instead of
>  the include directive. Closes: #1060897

Thanks for this fix! Unfortunately, this only solves one of the two
problems that I reported in #1060897 (I know that I should have opened two
bugs...).

The other one was about the javascript in furo.js failing to execute (at
least in Firefox in unstable) with this error message:

Uncaught SyntaxError: import declarations may only appear at top level of a 
module

As I said in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060897#10
that import statement is not present in a regular furo.js as built
by the upstream build system because the file is post-processed and
minified. Ex here:
https://pradyunsg.me/furo/_static/scripts/furo.js

So I assume we need to post-process the file in some similar way to get it
to work or tweak the way we import the code to allow the import statement
to work but I'm not a big fan of diverting too much from upstream and we
are doing this a lot here (but it's often unavoidable with all packages
relying on the node ecosystem in some way). :-(

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1061143: gobject-introspection: FTBFS with Python 3.12 as default

[Graham Inggs]

Hi Simon

On Fri, 19 Jan 2024 at 14:46, Simon McVittie  wrote:
> I would guess that the problem is that it still uses python3-distutils
> (that's being worked on upstream, but slower than I would like), but even
> though that package Provides python3.12-distutils, it doesn't contain
> an implementation.

Matthias Klose found an upstream commit [1] which I've just tested
now, and it seems to be the only thing needed to get the tests
passing.

Regards
Graham


https://gitlab.gnome.org/GNOME/gobject-introspection/-/commit/fb6f33082a42202c55dc3d5cbc984cc9b6b01629

Bug#1061146: xkb-data: no pt keyboard layout mathes stencil on macbook 2009 and macbook pro 2013

[Carlos Castro]

Package: xkb-data
Version: 2.38-2
Severity: minor
Tags: patch
X-Debbugs-Cc: cgecas...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
Trying to configure keyboard on macbook
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Modified keyboard // Layout variant for Mac, by Ricardo Cabral
.
xkb_symbols "mac"
to match stencil and also to match keys in MacOS X keyboard layout
   * What was the outcome of this action?
keys match stencil and mac layout
   * What outcome did you expect instead?

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


-- 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/2 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information
default partial alphanumeric_keys
xkb_symbols "basic" {

include "latin(type4)"
name[Group1]="Portuguese";

key  { [ section, bar,  notsign,  
notsign ] };
key  { [ 3,  numbersign,   sterling, 
sterling ] };
key  { [ 4,  dollar,section,   
dollar ] };
key  { [apostrophe,question,  backslash, 
questiondown ] };
key  { [ guillemotleft,  guillemotright,   dead_cedilla,  
dead_ogonek ] };

key  { [  plus,asterisk, dead_diaeresis,   
dead_abovering ] };
key  { [dead_acute,  dead_grave, dead_tilde,  
dead_macron ] };
key  { [dead_tilde, dead_circumflex, dead_grave,   
dead_breve ] };

key  { [section   ] };

key  { [  ccedilla,Ccedilla, dead_acute, 
dead_doubleacute ] };
key  { [ masculine, ordfeminine,dead_circumflex,   
dead_caron ] };

key  { [  less, greater,  backslash,
backslash ] };

include "level3(ralt_switch)"
};

partial alphanumeric_keys
xkb_symbols "nodeadkeys" {

include "pt(basic)"
name[Group1]="Portuguese (no dead keys)";

key  { [ guillemotleft,  guillemotright,cedilla,   
ogonek ] };
key  { [  plus,asterisk,   quotedbl, 
quotedbl ] };
key  { [ acute,   grave   
] };
key  { [asciitilde, asciicircum   
] };
key  { [  ccedilla,Ccedilla,  acute,  
doubleacute ] };
key  { [ masculine, ordfeminine,asciicircum,
caron ] };
key  { [ minus,  underscore,  dead_belowdot, 
abovedot ] };
};

// Layout variant for Mac, by Ricardo Cabral .
partial alphanumeric_keys
xkb_symbols "mac" {

include "pt(basic)"
name[Group1]= "Portuguese (Macintosh)";

key  { [ section,  plusminus,section, 
   plusminus ] };
key  { [ 1, exclamation,  0x0100F8FF  
 ] };
key  { [ 2,quotedbl,  at, 
  0x0100FB01 ] };
key  { [ 3,  numbersign,EuroSign, 
  0x0100FB02 ] };
key  { [ 4,  dollar,sterling, 
cent ] };
key  { [ 5, percent,  0x01002030, 
infinity ] };
key  { [ 6,   ampersand,  0x01B6, 
  0x01002022 ] };
key  { [ 7,   slash,  0x01F7, 
  0x01002044 ] };
key  { [ 8,   parenleft, bracketleft, 
   braceleft ] };
key  { [ 9,  parenright,bracketright, 
  braceright ] };
key  { [ 0,   equal,  0x01002260, 
  0x01002248 ] };
key  { [apostrophe,question, section, 
questiondown ] };
key  { [  plus,asterisk,   plusminus, 
  0x010025CA ] };
key  { [ q,   Q,  0x01000153, 
  0x01000152 ] };
key  { [ w,   W,  0x01002211, 
  0x01002211 ] };
key  { [ e,   E,  ae, 
  AE ] };
key  { [ r,   R,  registered, 
  registered ] };
key  { [ t,   T,   trademark, 
   trademark ] };
key  { [ y,   Y, yen, 
 yen ] };
key  { [ u,   U,  dagger, 
doubledagger ] };
key  { [ i,  

Bug#1061145: debmake: use python3 command for Python 3 packages instead of python command

[Ernesto Domato]

Package: debmake
Version: 4.4.0-3
Severity: normal
X-Debbugs-Cc: edom...@gmail.com

Hi,

When I tried to use debmake to package a Python 3 only application, and even
when I force it
to -b":python3", debmake try to run "python setup.py" which is wrong and should
use "python3 setup.py"

Thanks.
Ernesto


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

Kernel: Linux 6.6.11-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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debmake depends on:
ii  devscripts  2.23.7
ii  dpkg-dev1.22.2
ii  python3 3.11.6-1
ii  python3-debian  0.1.49
ii  rsync   3.2.7-1+b1

Versions of packages debmake recommends:
ii  build-essential  12.10
ii  curl 8.5.0-2
ii  strace   6.5-0.1
ii  wget 1.21.4-1+b1

Versions of packages debmake suggests:
ii  autotools-dev 20220109.1
pn  ccache
pn  cmake 
ii  debmake-doc   1.17-9
pn  dgit  
ii  dh-autoreconf 20
ii  dh-python 6.20231223
ii  eatmydata 131-1
pn  gem2deb   
ii  git   1:2.43.0-1
pn  git-buildpackage  
ii  gitk  1:2.43.0-1
pn  javahelper
ii  lintian   2.116.3
ii  mc3:4.8.30-1
ii  quilt 0.67+really0.67-4
pn  rpm2cpio  
ii  sbuild0.85.4

-- no debconf information

Bug#1061143: gobject-introspection: FTBFS with Python 3.12 as default

[Simon McVittie]

On Fri, 19 Jan 2024 at 13:54:26 +0200, Graham Inggs wrote:
> gobject-introspection FTBFS with Python 3.12 as the default version.
> I've copied what I hope is the relevant part of the log below.

This is not a very helpful log, I hope it gives more information earlier
or later? If not, we'll have to teach its build system to show the actual
test output somewhere.

I would guess that the problem is that it still uses python3-distutils
(that's being worked on upstream, but slower than I would like), but even
though that package Provides python3.12-distutils, it doesn't contain
an implementation.

Depending on python3-setuptools | python3 (<< 3.12) would maybe work?

> Although Python 3.12 is not yet the default in Debian unstable, you
> should be able to reproduce the failure by editing:
> 
> /usr/share/python3/debian_defaults
> 
> or by exporting DEBPYTHON3_DEFAULT=3.12 during the build.

Thanks, I had been wondering how maintainers of packages that use a single
Python version were meant to test this!

smcv

Bug#1061144: python3: README.Debian references python3.6 despite installed version being python3.11

[Clinch, Graham]

Package: python3
Version: 3.11.2-1+b1
Severity: minor

Dear Maintainer,

/usr/share/doc/{libpython3-stdlib,python3,python3-minimal}/README.Debian
direct readers to find further documentation in /usr/share/doc/python3.6/
but that path is not available (because the installed version of Python is 
3.11).

I suspect that this comes from python3-defaults:
https://salsa.debian.org/cpython-team/python3-defaults/-/blob/master/debian/README.Debian


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

Kernel: Linux 6.1.0-17-amd64 (SMP w/1 CPU thread; 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 python3 depends on:
ii  libpython3-stdlib  3.11.2-1+b1
ii  python3-minimal3.11.2-1+b1
ii  python3.11 3.11.2-6

python3 recommends no packages.

Versions of packages python3 suggests:
pn  python3-doc   
pn  python3-tk
pn  python3-venv  

-- no debconf information

Bug#1056457: python-ase's autopkg tests fail with Python 3.12

[Andrius Merkys]

Hi Graham,

On Mon, 8 Jan 2024 08:46:45 +0200 Graham Inggs  wrote:

However, since spglib stopped building its extension for all supported
Python versions (see #1057858) testing python-ase against Python 3.12
now fails with:

531s INTERNALERROR> Traceback (most recent call last):
531s INTERNALERROR>   File
"/usr/lib/python3/dist-packages/spglib/spglib.py", line 41, in

531s INTERNALERROR> from spglib import _spglib as spg
531s INTERNALERROR> ImportError: cannot import name '_spglib' from
partially initialized module 'spglib' (most likely due to a circular
import) (/usr/lib/python3/dist-packages/spglib/__init__.py)

Therefore, I let python-ase only test against the default Python
version [1], and lower the severity of this bug, until either Python
3.12 is the default, or spglib builds its extension for all supported
Python versions again.


Maybe an alternative solution would be to only disable spglib-related 
test cases for Python 3.12. It seems that spglib is not an essential 
dependency for python-ase, thus the remaining test cases could still be 
ran to ensure package's integrity on Python 3.12.



[1] 
https://salsa.debian.org/debichem-team/python-ase/-/commit/b33055fd68da81e1806e7a0f0dd65dc5b53fc3b2

Best wishes,
Andrius

Bug#1061141: gobject-introspection: missing versioned dependencies on python3

[Graham Inggs]

Control: tags -1 + patch

Adding the following lines to debian/rules worked for me:

override_dh_python3:
dh_python3 /usr/lib/$(DEB_HOST_MULTIARCH)/gobject-introspection/giscanner/

Bug#1061142: ITP: python-crispy-bootstrap4 -- Bootstrap 4 template pack for django-crispy-forms

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-crispy-bootstrap4
  Version : 2023.1
  Upstream Contact: David Smith
* URL : https://github.com/django-crispy-forms/crispy-bootstrap4
* License : Expat
  Programming Lang: Python
  Description : Bootstrap 4 template pack for django-crispy-forms

 Bootstrap4 template pack for django-crispy-forms. This template pack was
 included with the core django-crispy-forms package until version 2.0.

I intend to maintain it as part of DPT.

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmWqYmAbHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqJG8H/3zBQeDFQDOpA7zyIKvm
ycvac4e+Dfzj4cmodrsJOwUYKxQ2w1Y7P+wkoia+7RjdEDLn/qdbauii2JPyNxww
1p3OnA1MMjx1SHXy0BQos7Zdt0I7xGugpVAuX8Cv/rhDYNW6bF+GCI7glzlxvMGg
AzjfJwr5Xnl7AoGl1G/OzHJdnlVfcpbBEnYtNZcdzP0igfrpTzXbdNP28AIy1iU1
we/pgbGGM6exd/yxAMmvYAwIrXO4KPMMjUyGcDjljb8pcPYeDYPwPZBMP1ZtD3ML
4JOG8pwm6+NgjZVmfybhutVG5/4UWRywGk2zr2lGFlZMwmIsYZzGCyuZLUsGrL7T
DYU=
=EBwq
-END PGP SIGNATURE-

Bug#1061143: gobject-introspection: FTBFS with Python 3.12 as default

[Graham Inggs]

Source: gobject-introspection
Version: 1.78.1-11
Severity: important
User: debian-pyt...@lists.debian.org
Usertags: python3.12

Hi Maintainer

gobject-introspection FTBFS with Python 3.12 as the default version.
I've copied what I hope is the relevant part of the log below.

Although Python 3.12 is not yet the default in Debian unstable, you
should be able to reproduce the failure by editing:

/usr/share/python3/debian_defaults

or by exporting DEBPYTHON3_DEFAULT=3.12 during the build.

Regards
Graham


 1/65 cmph-bdz-test   OK  0.01s
 2/65 gthash-test OK  0.01s
 3/65 gi-testerEverything-1.0.typelib OK  0.03s
 4/65 gi-testerGIMarshallingTests-1.0.typelib OK  0.03s
 5/65 test_offsets.py OK  0.06s
 6/65 warn-annotationparser   FAIL0.07s
exit status 1
>>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>>>  UNINSTALLED_INTROSPECTION_SRCDIR=/<> 
>>> PYTHONPATH=/<>/_build:/<>/_build/giscanner 
>>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
>>> MALLOC_PERTURB_=37 TOP_BUILDDIR=/<>/_build /usr/bin/python3 
>>> warningtester.py annotationparser.h

 7/65 warn-callback-missing-scope FAIL0.05s
exit status 1
>>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>>>  UNINSTALLED_INTROSPECTION_SRCDIR=/<> 
>>> PYTHONPATH=/<>/_build:/<>/_build/giscanner 
>>> MALLOC_PERTURB_=164 
>>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
>>> TOP_BUILDDIR=/<>/_build /usr/bin/python3 warningtester.py 
>>> callback-missing-scope.h

 8/65 warn-callback-invalid-scope FAIL0.06s
exit status 1
>>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>>>  UNINSTALLED_INTROSPECTION_SRCDIR=/<> 
>>> PYTHONPATH=/<>/_build:/<>/_build/giscanner 
>>> MALLOC_PERTURB_=32 
>>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
>>> TOP_BUILDDIR=/<>/_build /usr/bin/python3 warningtester.py 
>>> callback-invalid-scope.h

 9/65 warn-invalid-allow-none FAIL0.04s
exit status 1
>>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>>>  UNINSTALLED_INTROSPECTION_SRCDIR=/<> 
>>> PYTHONPATH=/<>/_build:/<>/_build/giscanner 
>>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
>>> TOP_BUILDDIR=/<>/_build MALLOC_PERTURB_=8 /usr/bin/python3 
>>> warningtester.py invalid-allow-none.h

10/65 warn-invalid-array  FAIL0.05s
exit status 1
>>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>>>  UNINSTALLED_INTROSPECTION_SRCDIR=/<> 
>>> PYTHONPATH=/<>/_build:/<>/_build/giscanner 
>>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
>>> MALLOC_PERTURB_=243 TOP_BUILDDIR=/<>/_build /usr/bin/python3 
>>> warningtester.py invalid-array.h

11/65 warn-invalid-closureFAIL0.05s
exit status 1
>>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>>>  UNINSTALLED_INTROSPECTION_SRCDIR=/<> 
>>> PYTHONPATH=/<>/_build:/<>/_build/giscanner 
>>> MALLOC_PERTURB_=146 
>>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
>>> TOP_BUILDDIR=/<>/_build /usr/bin/python3 warningtester.py 
>>> invalid-closure.h

12/65 warn-invalid-constructorFAIL0.05s
exit status 1
>>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>>>  UNINSTALLED_INTROSPECTION_SRCDIR=/<> 
>>> PYTHONPATH=/<>/_build:/<>/_build/giscanner 
>>> MALLOC_PERTURB_=254 
>>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
>>> TOP_BUILDDIR=/<>/_build /usr/bin/python3 warningtester.py 
>>> invalid-constructor.h

13/65 warn-invalid-element-type   FAIL0.04s
exit status 1
>>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>>>  UNINSTALLED_INTROSPECTION_SRCDIR=/<> MALLOC_PERTURB_=244 
>>> PYTHONPATH=/<>/_build:/<>/_build/giscanner 
>>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
>>> TOP_BUILDDIR=/<>/_build /usr/bin/python3 warningtester.py 
>>> invalid-element-type.h

14/65 warn-invalid-method FAIL0.05s
exit status 1
>>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>>>  UNINSTALLED_INTROSPECTION_SRCDIR=/<> 
>>> PYTHONPATH=/<>/_build:/<>/_build/giscanner 
>>> MALLOC_PERTURB_=99 
>>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
>>> TOP_BUILDDIR=/<>/_build /usr/bin/python3 warningtester.py 
>>> invalid-method.h

15/65 warn-invalid-nullable   FAIL0.05s
exit status 1
>>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>>>  UNINSTALLED_INTROSPECTION_SRCDIR=/<> 
>>> 

Bug#1061141: gobject-introspection: missing versioned dependencies on python3

[Graham Inggs]

Source: gobject-introspection
Version: 1.78.1-11
Severity: important
User: debian-pyt...@lists.debian.org
Usertags: python3.12

Hi Maintainer

The gobject-introspection-bin binary package ships the file:

/usr/lib//gobject-introspection/giscanner/_giscanner.cpython-311-.so

It has a dependency on python3:any, but it should have the following
versioned dependencies instead:

python3 (<< 3.12), python3 (>= 3.11~)

Regards
Graham

Bug#1061133: libsoup3: Build profiles don't actually work

[John Paul Adrian Glaubitz]

Hi Simon,

On Fri, 2024-01-19 at 10:47 +, Simon McVittie wrote:
> > From a quick look at libsoup3, it seems like it might only need
> > GNUTLS for part of the test suite, and therefore needs to pass
> > -Dpkcs11_tests=disabled to meson via dh_auto_configure (overriding
> > -Dauto_features=enabled) whenever both of these profiles are disabled?
> 
> Yes, this. Please see the commit that I'm about to push (the commit hook
> should set this bug as pending when I do).

Thanks for the very quick fix.

Could you perform a new upload of libsoup3 within the next days so I can
bootstrap the package for sh4 again?

Thanks,
Adrian

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

Bug#1052345: src:binutils-mipsen: fails to migrate to testing for too long: FTBFS

[YunQiang Su]

It's now buildable.

Bug#1060897: standalone is permitted, when the local web server is in use

[Georges Khaznadar]

Hello,

I deleted the first line in the file furo.css, which contained 
« @import url(/javascript/normalize.css/normalize.css); »
and replaced it by the contents of the file normalize.css

The release 2023.09.10+dfsg-3 might fix the bug, please feel free to
reopen it, if it doesn't.

Best regards,   Georges.

On Fri, 19 Jan 2024 09:46:57 +0100 Raphael Hertzog  wrote:
> Hi,
> 
> On Thu, 18 Jan 2024, Georges Khaznadar wrote:
> > On Thu, 18 Jan 2024 13:55:20 +0100 Raphael Hertzog  
> > wrote:
> > > [...] reported here and that you can see here:
> > > https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/docs/_build/html/index.html
> > 
> > when I browse this URL with the debugger's console active, I see that:
> > 
> > The resource from 
> > “https://hertzog.pages.debian.net/javascript/normalize.css/normalize.css” 
> > was blocked due to MIME type (“text/html”) mismatch 
> > (X-Content-Type-Options: nosniff).
> > 
> > Probably, it the webserver is configured to serve normalize.css as MIME
> > type "text/css", the issue might be fixed.
> 
> No, this is unrelated. The URL you list is just not valid. This domain
> is managed by GitLab Pages and anything generated by the CI must
> be self-contained in 
> https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/
> 
> The fact that you have hardcoded an absolute link to
> "/javascript/normalize.css/normalize.css" (which might work on a default
> installation of a Debian server) means the resource is now looked up
> outside of its artifact directory, and there's just nothing there
> that can understand the purpose of its URL. You could have received
> an error 404 just as well but you got something else presumably because
> GitLab Pages has a number of hardening features to avoid malicious
> behaviour.
> 
> Cheers,
> -- 
>   ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
>   ⣾⠁⢠⠒⠀⣿⡁
>   ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
>   ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
> 
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#229775: apt 2.7.7: build-dep doesn't work if priority is 499

[Askar Safin]

I tried aptitude and it works! Thank you for your help!
aptitude behaves properly in example from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229775#66 (message
66).
Moreover, stretch's aptitude version behaves properly (i. e. in the way I need).

So, my problem is solved.

But I still think "man apt_preferences" is incomplete. Please, add to
the first page of the manual something like this: "apt's
priority-aware dependency resolution algorithm is simplistic.
Sometimes it is unable to find any solution. If you find yourself in
such situation, consider using aptitude, it has advanced resolution
algorithm"

-- 
Askar Safin

Bug#1061133: libsoup3: Build profiles don't actually work

[Simon McVittie]

On Fri, 19 Jan 2024 at 00:51:50 +, Simon McVittie wrote:
> On Fri, 19 Jan 2024 at 01:17:36 +0100, John Paul Adrian Glaubitz wrote:
> > it seems that specifying multiple
> > build profiles for a build dependency means that the build dependency is
> > removed only if all of the specified profiles are activated.
> 
> It can work either way. You can either write
> 
> dep  

FYI, this is the one libsoup3 is using (correctly for its particular
situation), and it means:

(!nocheck) || (!noinsttest)

> or
> dep 

whereas this one would mean

(!nocheck) && (!noinsttest)

and that would be wrong for what libsoup3 is doing.

Unfortunately, comparing with architecture restrictions doesn't
work as a mnemonic for which way round this is, because positive
architecture restrictions like [amd64 i386] are "||", but negative
architecture restrictions like [!m68k !sh4] are "&&". This makes sense
for architectures because you can only be one architecture at a time,
but build profiles can be set or not set independently of each other,
so they need a more elaborate syntax.

> > This, however, means that that the "nocheck" profile has to be there to
> > boostreap libsoup3 which deactivates "libgnutls28-dev" which makes the
> > build fail since this build dependency is mandatory.
> 
> *That* sounds like the real bug here. In what way does it fail?

Steps to reproduce (on amd64 but I don't think that matters), in a
minimal-ish chroot/container (I used debian:sid-slim in Podman):

# apt update
# apt upgrade
# apt build-dep . --arch-only -Pnocheck,noinsttest
# dpkg-buildpackage -B -Pnocheck,noinsttest

Expected result:
- it builds
- build-time tests (dh_auto_test) are skipped
- the libsoup-3.0-tests package is not generated

Actual result:
../meson.build:293:13: ERROR: Dependency "gnutls" not found, tried pkgconfig

> From a quick look at libsoup3, it seems like it might only need
> GNUTLS for part of the test suite, and therefore needs to pass
> -Dpkcs11_tests=disabled to meson via dh_auto_configure (overriding
> -Dauto_features=enabled) whenever both of these profiles are disabled?

Yes, this. Please see the commit that I'm about to push (the commit hook
should set this bug as pending when I do).

smcv

Bug#1055848: Reproducing

[Alastair McKinstry]

I've now been able to setup autopkgtest locally based on sbuild.

I get failures in an autopkgtest (sbuild sid) chroot, but not when I do 
a clean pbuilder chroot via sid to do "pbuilder login".


Investigating the differences between what should be identical chroots.


Alastair

--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie

Bug#1061140: Cross-building against sqlite3 broken for riscv64

[Jan Kiszka]

Package: release.debian.org

Please align the uploaded versions of sqlite3 packages so that
cross-building against some lib of this source is working for riscv64.

TIA,
Jan

Bug#1060897: standalone is permitted, when the local web server is in use

[Raphael Hertzog]

Hi,

On Thu, 18 Jan 2024, Georges Khaznadar wrote:
> On Thu, 18 Jan 2024 13:55:20 +0100 Raphael Hertzog  wrote:
> > [...] reported here and that you can see here:
> > https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/docs/_build/html/index.html
> 
> when I browse this URL with the debugger's console active, I see that:
> 
> The resource from 
> “https://hertzog.pages.debian.net/javascript/normalize.css/normalize.css” was 
> blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: 
> nosniff).
> 
> Probably, it the webserver is configured to serve normalize.css as MIME
> type "text/css", the issue might be fixed.

No, this is unrelated. The URL you list is just not valid. This domain
is managed by GitLab Pages and anything generated by the CI must
be self-contained in 
https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/

The fact that you have hardcoded an absolute link to
"/javascript/normalize.css/normalize.css" (which might work on a default
installation of a Debian server) means the resource is now looked up
outside of its artifact directory, and there's just nothing there
that can understand the purpose of its URL. You could have received
an error 404 just as well but you got something else presumably because
GitLab Pages has a number of hardening features to avoid malicious
behaviour.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#895874: git-email: Should depend on libmailtools-perl for Mail::Address

[Askar Safin]

Package: git-email
Version: 1:2.43.0-1
Followup-For: Bug #895874
X-Debbugs-Cc: jrnie...@gmail.com, safinas...@gmail.com

The bug is still present in modern versions of git-email.
I. e. after 6 years it is still not fixed.

I did some experiments and I figured that the following 3
packages should be added to "Depends":

libmailtools-perl libauthen-sasl-perl ca-certificates

They are required for sending mail


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

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

Versions of packages git-email depends on:
ii  git  1:2.43.0-1

Versions of packages git-email recommends:
ii  libauthen-sasl-perl2.1700-1
pn  libemail-valid-perl
ii  libio-socket-ssl-perl  2.084-1
ii  libmailtools-perl  2.21-2
ii  libnet-smtp-ssl-perl   1.04-2
ii  perl   5.38.2-3

Versions of packages git-email suggests:
pn  git-doc  

-- no debconf information

Bug#1060672: kodi: High CPU usage even when idle

[Vasyl Gello]

Control: forwarded -1 https://github.com/xbmc/xbmc/issues/24539

Hello Giuseppe,

I opened an issue [1] and hope to resolve your issue with there.

[1] https://github.com/xbmc/xbmc/issues/24539

-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1060672: kodi: High CPU usage even when idle

[Giuseppe Sacco]

Hello Vasyl,
here is some information and a stack trace of the kodi thread that keep
consuming CPU.

>From what I understand, the problem is in the renderer code, but I am calling
kodi in standalone, so I think the renderer should not used at all.

top output (with thread view):
---
top - 08:23:42 up 12 days, 17:25,  1 user,  load average: 0,17, 0,34, 0,54
Threads: 507 total,   1 running, 506 sleeping,   0 stopped,   0 zombie
%Cpu(s):  3,9 us,  0,6 sy,  0,0 ni, 94,0 id,  0,5 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :  32005,4 total,   3096,0 free,   5365,6 used,  26530,5 buff/cache
MiB Swap:   1904,0 total,681,9 free,   1222,1 used.  26639,7 avail Mem

PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
3517230 giuseppe  20   0 2901040 108596  43788 S  11,6   0,3  9,02 kodi.bin
3517231 giuseppe  21   1 2901040 108596  43788 S   0,0   0,3   0:00.00 Announce
3517236 giuseppe  21   1 2901040 108596  43788 S   0,0   0,3   0:37.17 Lirc
3517279 giuseppe  21   1 2901040 108596  43788 S   0,0   0,3   0:49.54 libinput
3517280 giuseppe  39  19 2901040 108596  43788 S   0,0   0,3   0:00.00 
kodi.bi:disk$0
3517281 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:16.58 
kodi.bin:gdrv0
3517282 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:02.67 ActiveAE
3517283 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:01.61 AESink
3517284 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:00.00 
FDEventMonitor
3517301 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:45.26 
DetectDVDMedia
3517302 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:22.80 kodi.bin
3517303 giuseppe  21   1 2901040 108596  43788 S   0,0   0,3   1:35.60 
PeripBusUSBUdev
3517304 giuseppe  21   1 2901040 108596  43788 S   0,3   0,3  15:36.00 
PeripBusCEC
3517305 giuseppe  21   1 2901040 108596  43788 S   0,0   0,3   0:02.54 
PeripBusAddon
3517306 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3  14:05.19 
PeripEventScan
3517307 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:00.87 kodi.bin
3517308 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:46.74 kodi.bin
3517309 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:03.63 kodi.bin
3517310 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:02.75 kodi.bin
3517311 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:06.63 kodi.bin
3517312 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:02.63 kodi.bin
3517313 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:04.14 kodi.bin
3517314 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:00.78 kodi.bin
3517318 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:11.37 
EventServer
3517319 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:10.68 TCPServer
3517320 giuseppe  21   1 2901040 108596  43788 S   0,0   0,3   0:03.45 kodi.bin
3517331 giuseppe  20   0 2901040 108596  43788 S   0,0   0,3   0:02.15 kodi.bin
3517225 giuseppe  20   02576836836 S   0,0   0,0   0:00.00 kodi
---

systemd output:
---
$ systemctl status kodi
● kodi.service - Kodi DLNA server
 Loaded: loaded (/etc/systemd/system/kodi.service; enabled; preset: enabled)
 Active: active (running) since Mon 2024-01-15 19:51:25 CET; 3 days ago
   Main PID: 3517222 (kodi-standalone)
  Tasks: 29 (limit: 38330)
 Memory: 164.8M
CPU: 9h 2min 20.842s
 CGroup: /system.slice/kodi.service
 ├─3517222 /bin/sh /usr/bin/kodi-standalone
 ├─3517225 /bin/sh /usr/bin/kodi --standalone
 └─3517230 /usr/lib/x86_64-linux-gnu/kodi/kodi.bin --standalone

gen 15 19:51:26 mantide kodi-standalone[3517230]: 
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping 
unlock
gen 15 19:51:26 mantide kodi-standalone[3517230]: 
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping 
unlock
gen 16 16:32:17 mantide kodi-standalone[3517230]: WARNING: Unhandled message: 
interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, 
member=ActivatableServicesChanged
gen 16 16:32:18 mantide kodi-standalone[3517230]: WARNING: Unhandled message: 
interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, 
member=ActivatableServicesChanged
gen 16 16:32:20 mantide kodi-standalone[3517230]: WARNING: Unhandled message: 
interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, 
member=ActivatableServicesChanged
gen 16 16:32:23 mantide kodi-standalone[3517230]: WARNING: Unhandled message: 
interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, 
member=ActivatableServicesChanged
gen 16 16:32:39 mantide kodi-standalone[3517230]: WARNING: Unhandled message: 
interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, 
member=ActivatableServicesChanged
gen 16 16:38:59 mantide