date:20220712

Control: tags 1014836 + patch
Control: tags 1014836 + pending

Dear maintainer,

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

Regards.

diff -Nru remrun-0.2.0/debian/changelog remrun-0.2.0/debian/changelog
--- remrun-0.2.0/debian/changelog   2022-03-24 07:56:24.0 -0400
+++ remrun-0.2.0/debian/changelog   2022-07-13 01:40:30.0 -0400
@@ -1,3 +1,10 @@
+remrun (0.2.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Source-only upload. (Closes: #1014836)
+
+ -- Boyuan Yang   Wed, 13 Jul 2022 01:40:30 -0400
+
 remrun (0.2.0-1) unstable; urgency=low
 
   * Initial release. Closes: #1008207


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

Bug#1014842: libgprofng.so: needs to link against -pthread

2022-07-12 Thread Paul Wise

Package: libgprofng0
Version: 2.38.50.20220707-1
Severity: minor
File: /usr/lib/x86_64-linux-gnu/libgprofng.so.0.0.0
User: debian...@lists.debian.org
Usertags: undefined-symbol adequate

libgprofng.so needs to link with -pthread, see the output of adequate,
symtree and objdump below. I detected this on amd64 but the Debian
build log scanner also detected dpkg-buildpackage complaining about it
on several architectures, see the w3m/getbuildlog output below.

I filed this bug at severity minor since I'm not sure if there are any
programs using the libgprofng.so lib and if they already use the 
pthread symbols and link with the -pthread flag or not.

Please note that -pthread has to be used at both compile and link time.

This bug report brought to you by adequate:

https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ lib=/usr/lib/x86_64-linux-gnu/libgprofng.so.0.0.0
$ link=/lib/x86_64-linux-gnu/libpthread-2.33.so
$ pkg="$(dpkg-query --search "$lib" | sed s/:.*//)"
$ src="$(grep-aptavail --no-field-names --show-field Source:Package --field 
Package --exact-match --pattern "$pkg" | sed 's/ .*//')"
$ first="$(printf '%s' "$src" | head --bytes 1)"

$ adequate "$pkg"
libgprofng0:amd64: undefined-symbol 
/usr/lib/x86_64-linux-gnu/libgprofng.so.0.0.0 => pthread_create
libgprofng0:amd64: undefined-symbol 
/usr/lib/x86_64-linux-gnu/libgprofng.so.0.0.0 => pthread_join

$ man adequate | grep -A4 undefined-symbol
   undefined-symbol
   The symbol has not been found in the libraries linked with the 
binary.  Either the binary either needs to be linked with an additional shared 
library, or the dependency
   on the shared library package that provides this symbol is too weak.

   References: Debian Policy §3.5, §8.6, §10.2.

$ lddtree "$lib"
libgprofng.so.0.0.0 => /usr/lib/x86_64-linux-gnu/libgprofng.so.0.0.0 
(interpreter => none)
libopcodes-2.38.50-system.20220707.so => 
/usr/lib/x86_64-linux-gnu/libopcodes-2.38.50-system.20220707.so
libbfd-2.38.50-system.20220707.so => 
/usr/lib/x86_64-linux-gnu/libbfd-2.38.50-system.20220707.so
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1

$ symtree "$lib"
/usr/lib/x86_64-linux-gnu/libgprofng.so.0.0.0
libopcodes-2.38.50-system.20220707.so => 
disassemble_init_for_target,disassembler
libbfd-2.38.50-system.20220707.so => 
bfd_check_format,bfd_close,cplus_demangle,bfd_openr,bfd_init
libz.so.1 => inflateEnd,inflateInit2_,inflate
libdl.so.2 => dlsym
libstdc++.so.6 => 
_ZTVN10__cxxabiv121__vmi_class_type_infoE,_ZNSt6localeD1Ev,_ZSt20__throw_length_errorPKc,_ZSt9terminatev,_ZNSt13runtime_errorD2Ev,_ZNSt8ios_baseD2Ev,_ZNSdD2Ev,_ZTIm,_ZdlPvm,_ZNSt13runtime_errorC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE,__cxa_guard_acquire,_ZNSi7putbackEc,_ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_,_ZNKSt13runtime_error4whatEv,_ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE7_M_syncEPcmm,_ZTVSt15basic_streambufIcSt11char_traitsIcEE,_ZNSt8ios_base4InitD1Ev,_ZTVNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEEE,_ZTTNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEE,_Znam,_ZNSt6localeC1Ev,__cxa_throw,_ZTVN10__cxxabiv117__class_type_infoE,_ZTVN10__cxxabiv119__pointer_type_infoE,_ZTVN10__cxxabiv120__si_class_type_infoE,__cxa_begin_catch,_ZTISt13runtime_error,_ZTVNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEE,__cxa_pure_virtual,_ZTVSi,__cxa_guard_release,_ZNSt8ios_baseC2Ev,__cxa_allocate_exception,__gxx_personality_v0,_ZdaPv,_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1ERKS4_,_Znwm,_ZNSi3getEv,_ZTVSt9basic_iosIcSt11char_traitsIcEE,_ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E,_ZNSt8ios_base4InitC1Ev,_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERmm,__cxa_rethrow,_ZTISt9bad_alloc,_ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base,__cxa_throw_bad_array_new_length,_ZNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEED1Ev,_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_disposeEv,_ZSt15set_new_handlerPFvvE,__cxa_end_catch,_ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base,_ZSt19__throw_logic_errorPKc,__cxa_free_exception
libc.so.6 =>

Bug#1012941: forwarded -1 https://bugs.launchpad.net/grub-customizer/+bug/1981520

2022-07-12 Thread 肖盛文

control: forwarded -1 
https://bugs.launchpad.net/grub-customizer/+bug/1981520



--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon


On 2022-07-13 12:14, Johannes Schauer Marin Rodrigues wrote:


Yes, that's what I did. The last command fails with:


I recreated my workdir and realized the build directory is missing.

I looked into it and you can recreate the missing pieces with (at the 
top dir):

  ./repackage.sh enquote
Then the build worked.

I'm not sure how you ended-up with this error because I cannot run the 
build from the top dir without the above. What extra step did you do? 
does using repackage.sh help?


Sorry, I'm a total beginner with this toolchain,

--
Marc Dequènes

Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon

2022-07-12 Thread Johannes Schauer Marin Rodrigues

Quoting Marc Dequènes (duck) (2022-07-13 04:51:38)
> First, setup the build tools:
> sudo apt-get install devscripts reprepro debootstrap sbuild dh-cargo 
> schroot autopkgtest
> sudo sbuild-createchroot 
> --include=eatmydata,ccache,gnupg,dh-cargo,cargo,lintian,perl-openssl-defaults 
> \
>  --chroot-prefix debcargo-unstable unstable \
>  /srv/chroot/debcargo-unstable-amd64-sbuild 
> http://deb.debian.org/debian
> (you need space for /srv/chroot, or wherever you wish to store the 
> sbuild chroots, and also /var/lib/sbuild/)
> 
> Then the build itself:
> git clone https://salsa.debian.org/duck/debcargo-conf.git
> cd debcargo-conf/build/
> ./build.sh enquote

Yes, that's what I did. The last command fails with:

debcargo failed: Couldn't find any crate matching enquote *
Try `debcargo update` to update the crates.io index.
./build.sh: abort: couldn't find crate enquote

And yes, I ran "debcargo update".

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1011629: minidlna: can't access localhost:8200 - DNS rebinding attack suspected

2022-07-12 Thread Oliver Freyermuth


On Fri, 8 Jul 2022 21:50:32 +0800 =?UTF-8?Q?Marcos_Ra=C3=BAl_Carot?= 
 wrote:

Oh, so there is no way now to access the web page from minidlna? Cheers.


The code (as also used upstream[0]) validates that the hostname in the HTTP 
request consists only of numbers, dots or colons.

Given this change, it seems the only remaining functional way is to visit the 
IPv4 IP address of the minidlna server directly,
e.g. if your server is running at 192.168.178.32, you would visit:
 http://192.168.178.32:8200
in your browser.

An upstream bug about this issue has reported already at:
 https://sourceforge.net/p/minidlna/bugs/346/

[0] 
https://sourceforge.net/p/minidlna/git/ci/c21208508dbc131712281ec5340687e5ae89e940/

Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon


On 2022-07-12 22:39, Johannes Schauer Marin Rodrigues wrote:


you don't happen to have that package for arm64, do you? ;)


Sorry, I do not have this arch around :-/.

I'd like to build it myself no matter what I try running from that 
README I'm

getting:

debcargo failed: Couldn't find any crate matching enquote *
Try `debcargo update` to update the crates.io index.


First, setup the build tools:
sudo apt-get install devscripts reprepro debootstrap sbuild dh-cargo 
schroot autopkgtest
sudo sbuild-createchroot 
--include=eatmydata,ccache,gnupg,dh-cargo,cargo,lintian,perl-openssl-defaults 
\

--chroot-prefix debcargo-unstable unstable \
/srv/chroot/debcargo-unstable-amd64-sbuild 
http://deb.debian.org/debian
(you need space for /srv/chroot, or wherever you wish to store the 
sbuild chroots, and also /var/lib/sbuild/)


Then the build itself:
git clone https://salsa.debian.org/duck/debcargo-conf.git
cd debcargo-conf/build/
./build.sh enquote

Enjoy!

--
Marc Dequènes

Bug#1010165: fixed in grub-customizer 5.2.1-1

2022-07-12 Thread 肖盛文


Hi,

    grub-customizer is a GUI software, It's  to provide convenience to 
our user who didn't know command line.


This software main modify /boot/grub/grub.cfg, this file is produced by 
grub-mkconfig command,


but it is not belong to the grub-common package, this file is owner by 
end user.


User has right to modify grub.cfg, they may use vi or use grub-customizer.


在 2022/7/13 05:35, Julian Andres Klode 写道:

Control: reopen -1
This bug is of course still valid. Any configuration needs to be done
by the grub package itself and not by hacky unendorsed third party
hacks.

It's good the upgrade bug is fixed, but this still does not belong
in Debian IMO.


Regards.

--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014841: libguvcview-2.1-2: Missing Breaks+Replaces header → trying to overwrite '/usr/lib/x86_64-linux-gnu/libgviewaudio-2.0.so.2.0.0', which is also in package libguvcview-2.0-2:amd64 2.0.7-2-1

2022-07-12 Thread Axel Beckert

Package: libguvcview-2.1-2
Severity: serious
Version: 2.0.8-1

Upgrading gucview with the switch to a new library package name
(probably due to an SONAME bump) fails as follows due to missing Breaks
and Replaces headers in libguvcview-2.1-2:

Preparing to unpack .../libguvcview-2.1-2_2.0.8-1_amd64.deb ...
Unpacking libguvcview-2.1-2:amd64 (2.0.8-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libguvcview-2.1-2_2.0.8-1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libgviewaudio-2.0.so.2.0.0', 
which is also in package libguvcview-2.0-2:amd64 2.0.7-2-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

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

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

Bug#1014840: mesa-opencl-icd depends on both libllvm14 and libclc-13

2022-07-12 Thread Ximin Luo

Package: mesa-opencl-icd
Version: 22.0.5-1
Severity: important

Dear Maintainer,

mesa-opencl-icd depends on both libllvm14 and libclc-13

The latter should be upgraded to libclc-14


Versions of packages mesa-opencl-icd depends on:
ii  libc62.33-7
ii  libclang-cpp14   1:14.0.5-1
ii  libclc-131:13.0.1-6
ii  libdrm-amdgpu1   2.4.110-1
ii  libdrm-nouveau2  2.4.110-1
ii  libdrm-radeon1   2.4.110-1
ii  libdrm2  2.4.110-1
ii  libelf1  0.187-1
ii  libexpat12.4.8-1
ii  libgcc-s112.1.0-2
ii  libllvm141:14.0.5-1
ii  libstdc++6   12.1.0-2
ii  libzstd1 1.5.2+dfsg-1
ii  ocl-icd-libopencl1 [libopencl1]  2.2.14-3
ii  zlib1g   1:1.2.11.dfsg-4

mesa-opencl-icd recommends no packages.

mesa-opencl-icd suggests no packages.

Versions of packages xserver-xorg depends on:
ii  x11-xkb-utils  7.7+7
ii  xkb-data   2.35.1-1
ii  xserver-xorg-core  2:21.1.3-2+b1
ii  xserver-xorg-input-all 1:7.7+23
ii  xserver-xorg-input-evdev [xorg-driver-input]   1:2.10.6-2+b1
ii  xserver-xorg-input-libinput [xorg-driver-input]1.2.1-1+b1
ii  xserver-xorg-input-synaptics [xorg-driver-input]   1.9.1-2+b1
ii  xserver-xorg-input-wacom [xorg-driver-input]   1.0.0-3
ii  xserver-xorg-video-all 1:7.7+23
ii  xserver-xorg-video-amdgpu [xorg-driver-video]  22.0.0-2
ii  xserver-xorg-video-ati [xorg-driver-video] 1:19.1.0-2+b1
ii  xserver-xorg-video-cirrus [xorg-driver-video]  1:1.5.3-1+b5
ii  xserver-xorg-video-fbdev [xorg-driver-video]   1:0.5.0-2
ii  xserver-xorg-video-intel [xorg-driver-video]   2:2.99.917+git20210115-1
ii  xserver-xorg-video-mga [xorg-driver-video] 1:2.0.0-1+b1
ii  xserver-xorg-video-nouveau [xorg-driver-video] 1:1.0.17-2
ii  xserver-xorg-video-openchrome [xorg-driver-video]  1:0.6.0-5
ii  xserver-xorg-video-qxl [xorg-driver-video] 0.1.5+git20200331-3
ii  xserver-xorg-video-radeon [xorg-driver-video]  1:19.1.0-2+b1
ii  xserver-xorg-video-vesa [xorg-driver-video]1:2.5.0-1+b1
ii  xserver-xorg-video-vmware [xorg-driver-video]  1:13.3.0-3+b1

Versions of packages xserver-xorg recommends:
ii  libgl1-mesa-dri  22.0.5-1
pn  xserver-xorg-legacy  

Versions of packages xserver-xorg-core depends on:
ii  keyboard-configuration  1.208
ii  libaudit1   1:3.0.7-1+b1
ii  libbsd0 0.11.6-1
ii  libc6   2.33-7
ii  libdbus-1-3 1.14.0-1
ii  libdrm2 2.4.110-1
ii  libegl1 1.4.0-1
ii  libepoxy0   1.5.10-1
ii  libgbm1 22.0.5-1
ii  libgcrypt20 1.10.1-2
ii  libgl1  1.4.0-1
ii  libpciaccess0   0.16-3
ii  libpixman-1-0   0.40.0-1
ii  libselinux1 3.4-1
ii  libsystemd0 251.2-7
ii  libudev1251.2-7
ii  libunwind8  1.3.2-2
ii  libxau6 1:1.0.9-1
ii  libxcvt00.1.1-3
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.5-1
ii  libxshmfence1   1.3-1
ii  udev251.2-7
ii  xserver-common  2:21.1.3-2

Versions of packages xserver-xorg-core recommends:
ii  libgl1-mesa-dri  22.0.5-1
ii  libpam-systemd [logind]  251.2-7
ii  xcvt 0.1.1-3

Versions of packages xserver-xorg-core suggests:
ii  xfonts-100dpi1:1.0.4+nmu1.1
ii  xfonts-75dpi 1:1.0.4+nmu1.1
ii  xfonts-scalable  1:1.0.3-1.2

-- no debconf information

Bug#1014839: coreutils: dd oflag=seek_bytes brokenly interacts with sub-obs= truncation

2022-07-12 Thread наб

Package: coreutils
Version: 8.32-4+b1
Severity: normal

Dear Maintainer,

Consider the following:
  $ printf 'abcdAA' > file
  $ printf '_D' | dd of=file skip=1 iflag=skip_bytes seek=3 oflag=seek_bytes 
status=none

What do you expect file to contain?
I, very obviously, expect to:
  1. seek to position 3
  2. truncate there
  3. skip 1 byte
  4. read the rest => EOF => write it
for "abcD". But it's not: it's 00 00 00 44,
and strace reveals that file was opened with O_TRUNC.

If we repeat the same exercise but spec bs=1 (or obs=1, these are
equivalent for the purposes of this report), we get the expected value
(and see ftruncate(1, 3)).

The same happens for bs=2 and bs=3!

bs=4 yields the original "\0\0\0D" again, though.

I had expected this to be an overzealous and backward interpretation of
the standard, which reads
> If seek= expr is specified, but conv= notrunc is not, the effect of the
> copy shall be to preserve the blocks in the output file over which dd
> seeks, but no other portion of the output file shall be preserved.
but that's not the case, and coreutils appears to have extended this
logically as expected when faced with sub-block seek offsets
(the standard is specced entirely in terms of blocks,
 but if you spec seek_bytes the intent is to obviously preserve
 everything prior to the seek offset, rather than just the sought-over
 blocks ‒ this is demonstrated by bs=2 being fine,
 the counterfactual would be "ab\0D").

This makes me believe this is a simple programming error when optimising
for "pick O_TRUNC instead of ftruncate(1, 0) later", like in
  
https://git.sr.ht/~nabijaczleweli/voreutils/tree/7f7fbb1d95b66e832e339324c298ff5c8721a570/item/cmd/dd.cpp#L373-378
except that it probably checks for
  !(seek_off / obs)
which is, obviously, 0 for 3/≥4.

Best,
наб

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

Kernel: Linux 5.10.0-15-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-13+deb11u3
ii  libgmp10 2:6.2.1+dfsg-1+deb11u1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#948712: [Pkg-raspi-maintainers] Bug#948712: Pinebook Pro also uses this chip

2022-07-12 Thread Karl O. Pinc

Hi,

In the FWIW catagory, I'm following this thread beacuse
installed Debian (11) on an RPI4B using the Debian installer.
Following the instructions:

https://wiki.debian.org/RaspberryPi4?action=show=InstallingDebianOn%2FRaspberryPi%2FRaspberry+Pi+4#Using_EFI_Firmware_and_the_regular_Debian_Installer

and following the link to:

https://forums.raspberrypi.com/viewtopic.php?t=282839


What I found, I think, was that /boot/firmware does not then exist on
the resulting system.  I _believe_ I solved the issue by creating a
symlink.  (Maybe to /boot/UEFI/firmware/ ??)

All this was some time ago and I will have to (eventually)
go back and look at my notes and report back.  (I'd put off
reporting anything until I'd figured out something that worked.
By then I'd forgotten about this thread and was just reminded
by the recent emails.)

I'm not even 100% certain that the rpi firmware package
is relevant.  But I think so, to get wireless working.

Here's hoping that this is useful feedback and not noise.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#1012707: /etc/network/interfaces: only source configuration files using with '.conf' / use 'source /etc/network/interfaces.d/.conf' instead of 'source /etc/network/interfaces.d/*'

2022-07-12 Thread Ben Hutchings

On Tue, 2022-06-14 at 22:52 +0200, Santiago Ruano Rincón wrote:
> El 12/06/22 a las 14:13, Patrick Schleizer escribió:
> > Package: ifupdown
> > Severity: normal
> > 
> > Dear maintainer,
> > 
> > in file /etc/network/interfaces ...
> > 
> > Could you please consider instead of setting the default:
> > 
> > source /etc/network/interfaces.d/*
> > 
> > change suggestion:
> > 
> > source /etc/network/interfaces.d/*.conf
> > 
> > Reason:
> > 
> > When
> > 
> > - text editor (such as kate) create backup files (such as
> > /etc/network/interfaces.d/50_user~ with the tilde at the end)
> > 
> > - local packages by system administrator or Debian derivatives place
> > configuration drop-in snippets in /etc/network/interfaces.d/ folder,
> > 
> > then on upgrades then redundant files might end up in that folder such
> > as those with file extensions '.dpkg-old' or '.dpkg-dist'.
> > 
> > When ifupdown is restarted, an interface is likely to be duplicated
> > leading to ifupdown failure, resulting in a broken network connection.

Is this not what the "source-directory" directive exists for?

It is a bit puzzling that this was added and then not used...

> > 
> > By parsing only configuration files such as with the `*.conf` file
> > extension issues with parsing unexpected files created by editors
> > (backup files) or dpkg are avoided.
> 
> Thanks for your report. I think it makes sens. But for the moment, I am
> pushing it to a separate branch. If I am not wrong, the debian-installer
> installs some files in /etc/network/interfaces.d/, so there must be some
> coordination to avoid issues in future installs.
> 
> Debian Installer Team: it is OK from your side to make the change
> described above?

I grepped the source repositories of d-i packages and found 2 uses of
interfaces.d:

- netboot-assistant has an example command that creates
"/etc/network/interfaces.d/static":
https://salsa.debian.org/installer-team/netboot-assistant/-/blob/master/README.installbox#L62

- netcfg creates /etc/network/interfaces itself, with the wildcard
that's being reported as a bug:
https://salsa.debian.org/installer-team/netcfg/-/blob/master/write_interface.c#L29

So netcfg would probably also have to be changed, whether you decide to
go with *.conf or source-directory.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.


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

Bug#1014584:

2022-07-12 Thread Chad Smith

Hi Axel and Alberto,


Thanks for the conversation on this issue. I just wanted to add a
little context to cloud-init's versioning scheme in Ubuntu.

> That said, AFAIK -0ubuntu1~22.10.1 is not a formally documented version
anywhere, though I have seen it a few times.

For lack of a better word, I'll refer to the `~XX.YY.1` as a
"diminished version suffix".

The diminished version suffix is typically used in a project to which
all applies:
 - the project tends to release an upstream version of a package
[1.2.3-0ubuntu1]
   without any diminished version suffix
 - the project publishes the same functional upstream version to
stable Ubuntu releases

   18.04, 20.04, 22.04, 22.10 [1.2.3-0ubuntu1~XX.YY.1]


When the stable release version is equivalent, minus debian/* release
specific packaging
changes, the package version needs to be able to support an upgrade
path where the
development release version is greater than the last stable release version:

 dpkg  --compare-versions 1.2.3-0ubuntu1 gt 1.2.3-0ubuntu1~22.10.1

  So, those projects[1] tend to use the tilde `~` sort order to establish that
the stable release package version ~22.04.1 is considered less than
the devel release.

This is more common in Ubuntu packages that have an SRU exception

because they are more

likely to publish the same upstream version in multiple Ubuntu releases.


  If these projects were to adopt the dot-delimited .24.10.1
"augmented version suffix",
those projects would also need to ensure that any published version in
the Ubuntu
development release also contains that Ubuntu devel series augmented
suffix .22.10.1.


The docs we used to come up with this sort ordering using the tilde are here
- https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version
(debian_revision)

"""
 The lexical comparison is a comparison of ASCII values modified so
that all the letters
 sort earlier than all the non-letters and so that a tilde sorts
before anything,
 even the end of a part. For example, the following parts are in
sorted order from
 earliest to latest: ~~, ~~a, ~, the empty part, a
"""


> Alberto: what kind of upload is this?  22.10 is the current dev version,
so it's not some kind of backport.  With such context, I can guess that
this is some kind of package that your team is maintaining for multiple
ubuntu branches

Correct Axel. This is just an upload into the Ubuntu devel release
with a release-specific

diminished version syntax. From cloud-init perspective we figured we
could provide

Ubuntu release-specific ~XX.YY.1 to ensure all releases carry the same
general format suffix.

This way a community contributor wanting build their own deb from
upstream direct,
without version suffix, would be able to install the clean upstream
release and upgrade

from what is in-distro in ubuntu.


> ISTR that source-nmu-* just wasn't issued under ubuntu (i.e. with
--profile=ubuntu), did it start to be issued now?  I don't have any
recollection about binary-nmu-*
  All said the nmu lintian warnings seemed to have shown up in lintian
reports within the
last year. In cloud-init we don't correct our lintian warnings as much
as we should, but
we figured we should raise awareness on this issue to get upstream input on how
this should be addressed long term.


Thanks again for helping bring clarity here,

Chad

References

[1] Some Ubuntu packages which use ~XX.YY diminished package version schemes:
python3-distutils, ca-certificates, curtin, cloud-init,
ubuntu-advantage-tools, wslu, libstdc++6

Bug#1014838: mirror submission for mirrors.nexet.hk

2022-07-12 Thread Linkin Shan

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.nexet.hk
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Linkin Shan 
Country: HK Hong Kong
Location: Hong Kong
Sponsor: NEXET LIMITED https://nex.et




Trace Url: http://mirrors.nexet.hk/debian/project/trace/
Trace Url: http://mirrors.nexet.hk/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.nexet.hk/debian/project/trace/mirrors.nexet.hk

Bug#1014243: busybox-syslogd: The 'syslog' daemon is running, but no configuration file can be found.

2022-07-12 Thread Nobuhiro Iwamatsu

Package: busybox-syslogd
Followup-For: Bug #1014243

Hi,

> What led up to the situation? No idea, I've never touched the configuration
> (that I know of)
> 
> What exactly did you do (or not do) that was effective (or ineffective)? not
> sure, it was in a cron daily report.And wasn't in the previous one.
> 
> What was the outcome of this action? received email from Cron Daily with
> subject line :"[rkhunter] DebianTim - Daily report" and in the body of the
> email it states: "Warning: The 'syslog' daemon is running, but no 
> configuration
> file can be found."
> I have no idea where that might be to check it, the man pages point to this
> program for syslog.
> 
> What outcome did you expect instead? Not to get this type of email
> 

The busybox's syslogd provided by Debian does not require a configuration file.
The settings will need to be set with the syslogd command line option.

This warning is output by rkhunter. If you want to control this warning output,
I think you need to control it with rkhunter.

Best regards,
  Nobuhiro

Bug#1014837: distro-info-data: update ELTS data

2022-07-12 Thread Thorsten Glaser

Package: distro-info-data
Version: 0.53
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de, raph...@freexian.com

Current information is:

$ column -ts, https://deb.freexian.com/extended-lts/docs/debian-8-support/ and
https://deb.freexian.com/extended-lts/docs/debian-9-support/ for more.

change jessie eol-elts to 2025-06-30
change stretch eol-elts to 2027-06-30

We don’t know about buster ELTS yet, nor if the other LTS data changed,
but Raphaël would know ☻

(Does update of such metadata qualify for stable updates?)



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

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

-- no debconf information

Bug#1010165: closed by Debian FTP Masters (reply to xiao sheng wen ) (Bug#1010165: fixed in grub-customizer 5.2.1-1)

2022-07-12 Thread Julian Andres Klode

Control: reopen -1

On Tue, Jul 12, 2022 at 07:36:04PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the grub-customizer package:
> 
> #1010165: grub-customizer: Inappropriate package, modifies other package's 
> (conf) files, should be removed from archive
> 
> It has been closed by Debian FTP Masters  
> (reply to xiao sheng wen ).
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters 
>  (reply to xiao sheng wen 
> ) by
> replying to this email.
> 
> 
> -- 
> 1010165: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010165
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Tue, 12 Jul 2022 19:33:49 +
> From: Debian FTP Masters 
> To: 1010165-cl...@bugs.debian.org
> Reply-To: xiao sheng wen 
> Subject: Bug#1010165: fixed in grub-customizer 5.2.1-1
> Message-Id: 
> 

> Date: Mon, 25 Apr 2022 17:35:51 +0200
> From: Julian Andres Klode 
> To: Debian Bug Tracking System 
> Subject: grub-customizer: Inappropriate package, modifies other package's
>  (conf) files, should be removed from archive
> Message-ID: <20220425172100.ga4136...@debian.org>
> Accept-Language: de-DE, de, en-GB, en-US, en
> 
> Package: grub-customizer
> Severity: important
> X-Debbugs-Cc: juli...@ubuntu.com
> 
> As documented in 
> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1969353/comments/5,
> grub-customizer modifies conffileso owned by grub2, thus violating the
> recommendations outlined in Policy 10.7.4.
> 
> The solution is brittle, not integrated with grub2, and should therefore
> not be part of Debian.

This bug is of course still valid. Any configuration needs to be done
by the grub package itself and not by hacky unendorsed third party
hacks. 

It's good the upgrade bug is fixed, but this still does not belong
in Debian IMO.

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


signature.asc
Description: PGP signature

Bug#995886: Intent to NMU cxref to fix reproducibility issues

2022-07-12 Thread Camm Maguire

Greetings, and thank you so much for this contribution!  I've
incorporated into the latest.  Got the EGREP bit to work too, hopefully
:-).

Take care,

Philip Rinn  writes:

> Hi,
>
> On 04.07.22 at 21:22, Philip Rinn wrote:
>> Hi,
>> I intend to nmu cxref with fixes for the reproducibility
>> issues. This would close #995886, #995896, #995953 and #995954.
>> I prepared a version at https://mentors.debian.net/package/cxref/.
>> I do have a sponsor for the upload already and plan to upload it to
>> DELAYED/14.
>
> I forgot to attach the nmudiff here, so let's do it now.
>
> Best,
> Philip
>
> diff -Nru cxref-1.6e/debian/changelog cxref-1.6e/debian/changelog
> --- cxref-1.6e/debian/changelog   2021-01-03 17:31:29.0 +0100
> +++ cxref-1.6e/debian/changelog   2022-07-04 18:08:52.0 +0200
> @@ -1,3 +1,10 @@
> +cxref (1.6e-3.2) unstable; urgency=medium
> +
> +  * Non-maintainer upload by the Reproducible Builds team.
> +  * Fix reproducibility issues (Closes: #995886, #995896, #995953, #995954)
> +
> + -- Philip Rinn   Mon, 04 Jul 2022 18:08:52 +0200
> +
>  cxref (1.6e-3.1) unstable; urgency=medium
>  
>* Non maintainer upload by the Reproducible Builds team.
> diff -Nru 
> cxref-1.6e/debian/patches/0002-cpp-cxref-cpp-configure.in-Use-specific-path-for-EGR.patch
>  
> cxref-1.6e/debian/patches/0002-cpp-cxref-cpp-configure.in-Use-specific-path-for-EGR.patch
> --- 
> cxref-1.6e/debian/patches/0002-cpp-cxref-cpp-configure.in-Use-specific-path-for-EGR.patch
>  1970-01-01 01:00:00.0 +0100
> +++ 
> cxref-1.6e/debian/patches/0002-cpp-cxref-cpp-configure.in-Use-specific-path-for-EGR.patch
>  2022-07-04 18:08:52.0 +0200
> @@ -0,0 +1,34 @@
> +From 0f5bc18bb094b9c199b2471830e2a25ee255c04c Mon Sep 17 00:00:00 2001
> +From: Vagrant Cascadian 
> +Date: Tue, 5 Oct 2021 05:54:24 +
> +Subject: [PATCH 2/2] cpp/cxref-cpp-configure.in: Use specific path for EGREP.
> +
> +This hard-codes the path to grep to ensure reproducible builds
> +regardless of weather the package was built on a usrmerge or
> +non-usrmerge system.
> +
> +Passing EGREP via configure did not appear to work, possibly due to
> +makefile variable inheritance issues, though that would be preferable
> +if it could be made to work.
> +
> +https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
> +---
> + cpp/cxref-cpp-configure.in | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/cpp/cxref-cpp-configure.in b/cpp/cxref-cpp-configure.in
> +index d37764f..ab50792 100755
> +--- a/cpp/cxref-cpp-configure.in
>  b/cpp/cxref-cpp-configure.in
> +@@ -18,7 +18,7 @@
> + # Programs and paths
> + # (Default to the ones from the configure script).
> + 
> +-EGREP="@EGREP@"
> ++EGREP="/bin/egrep -E"
> + 
> + prefix="@prefix@"
> + datarootdir="@datarootdir@"
> +-- 
> +2.30.2
> +
> diff -Nru cxref-1.6e/debian/patches/series cxref-1.6e/debian/patches/series
> --- cxref-1.6e/debian/patches/series  2018-01-30 17:50:37.0 +0100
> +++ cxref-1.6e/debian/patches/series  2022-07-04 18:08:52.0 +0200
> @@ -3,3 +3,4 @@
>  kr-crash-doc
>  c_warning_cleanups_and_defines_for_Float128
>  # CPPFLAGS-hardening-patch
> +0002-cpp-cxref-cpp-configure.in-Use-specific-path-for-EGR.patch
> diff -Nru cxref-1.6e/debian/rules cxref-1.6e/debian/rules
> --- cxref-1.6e/debian/rules   2018-01-30 17:50:37.0 +0100
> +++ cxref-1.6e/debian/rules   2022-07-04 18:08:52.0 +0200
> @@ -16,6 +16,12 @@
>  
>  DPKG_EXPORT_BUILDFLAGS=1
>  
> +# Ensure texlive respects SOURCE_DATE_EPOCH
> +export FORCE_SOURCE_DATE=1
> +
> +# Force locale to avoid differences when building with obscure locales
> +export LC_ALL=C.UTF-8
> +
>  include /usr/share/dpkg/buildflags.mk
>  
>  build: build-arch build-indep
> @@ -61,6 +67,9 @@
>   $(MAKE) install DESTDIR=`pwd`/debian/tmp
>   $(MAKE) docs DESTDIR=`pwd`/debian/tmp
>  
> + # Remove build path from documentation
> + find doc/ -type f -exec sed -i -e "s,$(CURDIR),BUILDPATH,g" '{}' \;
> +
>   mkdir -p debian/tmp/usr/share/cxref
>   mv debian/tmp/etc/cxref/cxref-cpp.defines debian/tmp/usr/share/cxref
>  
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#1010362: cruft-ng: Segmentation fault in cruft-ng

2022-07-12 Thread Marco d'Itri

cruft-ng segfaults for me as well:

...
READING FILES IN DPKG DATABASE
[Detaching after vfork from child process 363152]
diversion of /usr/share/man/man1/perf.1.gz to 
/usr/share/man/man1/perf.wrapper.1.gz by linux-perf

diversion of /usr/share/dict/words to 
/usr/share/dict/words.pre-dictionaries-common by dictionaries-common

diversion of /usr/share/bash-completion/completions/perf to 
/usr/share/bash-completion/completions/perf.wrapper by linux-perf

diversion of /usr/bin/shasum to /usr/bin/shasum.bundled by libdigest-sha-perl

diversion of /usr/share/man/man1/podselect.1.gz to 
/usr/share/man/man1/podselect.bundled.1.gz by libpod-parser-perl

local diversion of /usr/share/applications/calibre-ebook-viewer.desktop to 
/usr/share/applications/calibre-ebook-viewer.desktop.distrib


Program received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
Download failed: Invalid argument.  Continuing without source file 
./string/../sysdeps/x86_64/multiarch/strlen-avx2.S.
74  ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
(gdb) where
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
#1  0x55568e8c in ?? ()
#2  0x555696ee in ?? ()
#3  0x8b5d in ?? ()
#4  0x77a4a81d in __libc_start_main (main=0x8870, argc=1, 
argv=0x7fffde98, init=, fini=, 
rtld_fini=, stack_end=0x7fffde88)
at ../csu/libc-start.c:332
#5  0xaefa in ?? ()
(gdb) 

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1014836: remrun: Source-only upload is needed

Source: remrun
Version: 0.2.0-1
Severity: important
X-Debbugs-CC: r...@debian.org

Dear Debian remrun package maintainer,

According to https://tracker.debian.org/pkg/remrun , your package needs
another source-only upload to be able to migrate to Debian Testing. Please
consider making another package upload to solve this problem. Thanks!

Regards,
Boyuan Yang


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

Bug#1014835: mptcpd: Source-only upload is needed

Source: mptcpd
Version: 0.9-1
Severity: important
X-Debbugs-CC: atthieu.bae...@tessares.net

Dear Debian mptcpd package maintainer,

According to https://tracker.debian.org/pkg/mptcpd , your package needs
another source-only upload to be able to migrate to Debian Testing. Please
consider making another package upload to solve this problem. Thanks!

Regards,
Boyuan Yang


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

Bug#1014834: xfce4-panel-profiles: Source-only upload is needed

Source: xfce4-panel-profiles
Version: 1.0.13-1
Severity: important
X-Debbugs-CC: leandrora...@disroot.org

Dear Debian xfce4-panel-profiles package maintainer,

According to https://tracker.debian.org/pkg/xfce4-panel-profiles , your
package needs another source-only upload to be able to migrate to Debian
Testing. Please consider making another upload to solve this problem. Thanks!

Regards,
Boyuan Yang


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

Bug#1014833: psycopg3: Source-only upload is needed

Source: psycopg3
Version:  3.0.1-1
Severity: important
X-Debbugs-CC: serp...@debian.org

Dear Debian psycopg3 package maintainer,

According to https://tracker.debian.org/pkg/psycopg3 , your package needs
another source-only upload to be able to migrate to Debian Testing. Please
consider making another source-only upload.

Thanks,
Boyuan Yang


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

Bug#1014832: libdecaf: Source-only upload is needed

Source: libdecaf
Version: 1.0.1-1
Severity: important
X-Debbugs-CC: d.fil...@web.de be...@debian.org

Dear Debian libdecaf package maintainers,

According to https://tracker.debian.org/pkg/libdecaf , you package needs
another source-only upload to be able to migrate to Debian Testing. Please
consider making another upload.

Thanks,
Boyuan Yang


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

Bug#1002630: pipewire: enable roc module

2022-07-12 Thread Daniel Lundqvist

Hey,

On Mon, 27 Dec 2021 21:36:43 -0500 nick black  wrote:
> awesome. i've got one now, but it needs some prettification.
> expect it soon.

I'm also interested in this. Is there anything I can do to help?

-- 
daniel

Bug#1014831: android-platform-frameworks-base: aapt2 command does not work at all

2022-07-12 Thread Roger Shimizu

Package: android-platform-frameworks-base
Version: 1:13~beta3-1~exp1
Severity: serious
Justification: must

Dear Maintainer,

aapt2 does not work at all, even `aapt2 version` fails.
So I disabled the aapt2 invoking while building for 1:13~beta3-1~exp1:
- 
https://salsa.debian.org/android-tools-team/android-platform-frameworks-base/-/commit/887382e

Need to fix this issue before uploading to sid.

Cheers,
Roger

Bug#1014830: php-laravel-framework: CVE-2021-37298

Source: php-laravel-framework
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for php-laravel-framework.

CVE-2021-37298[0]:
| Laravel v5.1 was discovered to contain a deserialization vulnerability
| via the component \Mockery\Generator\DefinedTargetClass.

This doesn't seem reported upstream, so please take care of that:   
https://github.com/Stakcery/happywd/issues/1

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-2021-37298
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-37298

Please adjust the affected versions in the BTS as needed.

Bug#1014828: openexr: CVE-2021-3933 CVE-2021-3941 CVE-2021-45942

Source: openexr
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for openexr.

CVE-2021-3933[0]:
| An integer overflow could occur when OpenEXR processes a crafted file
| on systems where size_t  64 bits. This could cause an invalid
| bytesPerLine and maxBytesPerLine value, which could lead to problems
| with application stability or lead to other attack paths.

https://bugzilla.redhat.com/show_bug.cgi?id=2019783
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38912
Fixed by: 
https://github.com/AcademySoftwareFoundation/openexr/commit/5a0adf1aba7d41c6b94ba167c0c4308d2eecfd17

CVE-2021-3941[1]:
| In ImfChromaticities.cpp routine RGBtoXYZ(), there are some division
| operations such as `float Z = (1 - chroma.white.x - chroma.white.y) *
| Y / chroma.white.y;` and `chroma.green.y * (X + Z))) / d;` but the
| divisor is not checked for a 0 value. A specially crafted file could
| trigger a divide-by-zero condition which could affect the availability
| of programs linked with OpenEXR.

https://bugzilla.redhat.com/show_bug.cgi?id=2019789
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39084
https://github.com/AcademySoftwareFoundation/openexr/pull/1153
Fixed by: 
https://github.com/AcademySoftwareFoundation/openexr/commit/a0cfa81153b2464b864c5fe39a53cb03339092ed

CVE-2021-45942[2]:
| OpenEXR 3.1.x before 3.1.4 has a heap-based buffer overflow in
| Imf_3_1::LineCompositeTask::execute (called from
| IlmThread_3_1::NullThreadPoolProvider::addTask and
| IlmThread_3_1::ThreadPool::addGlobalTask). NOTE: db217f2 may be
| inapplicable.

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41416
https://github.com/AcademySoftwareFoundation/openexr/pull/1209
https://github.com/AcademySoftwareFoundation/openexr/commit/11cad77da87c4fa2aab7d58dd5339e254db7937e

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3933
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3933
[1] https://security-tracker.debian.org/tracker/CVE-2021-3941
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3941
[2] https://security-tracker.debian.org/tracker/CVE-2021-45942
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45942

Please adjust the affected versions in the BTS as needed.

Bug#1014829: kerberos-configs: consider setting rdns=false by default

2022-07-12 Thread Andreas Hasenack

Package: kerberos-configs
Version: 2.6
Severity: normal

Dear Maintainer,

According to [1], the upstream implicit default of "rdns = true" is
there for historical reasons only, and upstream suggests to consider
setting it to "false":

"""
Consider setting rdns to false in order to reduce your dependence on
precisely correct DNS information for service hostnames. Turning this
flag off means that service hostnames will be canonicalized through
forward name resolution (which adds your domain name to unqualified
hostnames, and resolves CNAME records in DNS), but not through reverse
address lookup. The default value of this flag is true for historical
reasons only.
"""

In particular, I've seen reports of users failing to join a linux
machine to an Active Directory domain unless they set this parameter
to false. AWS also recommends it in their guide at [2] (note that
"ubuntu" is the same as debian in this context):
"""
Disable Reverse DNS resolution and set the default realm to your
domain's FQDN. Ubuntu Instances must be reverse-resolvable in DNS
before the realm will work. Otherwise, you have to disable reverse DNS
in /etc/krb5.conf as follows:

sudo vi /etc/krb5.conf

[libdefaults]
default_realm = EXAMPLE.COM
rdns = false
"""

I believe indeed this is particularly true for cloud environments,
where reverse dns is not easily controllable, and also in other
environments where you don't own the reverse dns. So maybe it would be
best to default to rdns=false to make kerberos easier for more users?
What are the security implications of this change?

1.
https://web.mit.edu/kerberos/krb5-latest/doc/admin/install_clients.html#client-machine-configuration-files
2.
https://docs.aws.amazon.com/directoryservice/latest/admin-guide/join_linux_instance.html

Bug#1014319: depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or directory

2022-07-12 Thread Michael Biebl


Am 12.07.22 um 20:54 schrieb Salvatore Bonaccorso:

Hi Michael,

On Tue, Jul 12, 2022 at 05:57:41PM +0200, Michael Biebl wrote:

On Sat, 9 Jul 2022 21:02:50 +0200 Salvatore Bonaccorso 
wrote:

On Thu, Jul 07, 2022 at 01:37:53PM +0200, Michael Biebl wrote:

It would thus be great to have the patch in [2] applied and uploaded soon. I
can offer to NMU if available time is an issue.


With that patch MR filled:

https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/64



Thanks for the patch, Sven and thanks for the MR, Salvatore!

Since we haven't received any feedback so far, I've uploaded an NMU with the
patch to DELAYED/5 (debdiff attached)

Ben, please holler if you have any objections and you want me to cancel the
NMU.


personally i would prefer if we can do it a regular kernel-team
upload, there were some other changes pending.

Will ping Ben on IRC to ask. Otherwise I guess the NMU is fine.


Nod, I'm more then happy to cancel the NMU if a regular upload is pending.

Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014816: new upstream (5.13)

2022-07-12 Thread Sam Reed

https://salsa.debian.org/reedy/ustreamer has 5.4 (not uploaded to unstable), 
but trying to build 5.5 or later is currently resulting in some build failures 
locally.

> On 12/07/2022 13:09 BST Daniel Baumann  
> wrote:
> 
>  
> Package: ustreamer
> 
> Hi,
> 
> it would be nice if you could upgrade to the current upstream release
> (5.13).
> 
> Regards,
> Daniel

Bug#1014689: leiningen-clojure breaks cljx-clojure autopkgtest: artifact nrepl:nrepl:jar:0.9.0 has not been downloaded

2022-07-12 Thread Louis-Philippe Véronneau


The autopkgtests pass locally, but britney is stuck in a loop where:

* leiningen-clojure 2.9.1-6 can't migrate because it breaks the 
cljx-clojure autopkgtest
* nrepl-clojure 0.9.0-1 can't migrate because it breaks the cljx-clojure 
autopkgtest

* leiningen-clojure 2.9.1-6 needs nrepl-clojure 0.9.0-1
* the cljx-clojure autopkgtest runs with either leiningen-clojure 
2.9.1-6 or nrepl-clojure 0.9.0-1, but never with both.


In leiningen-clojure 2.9.1-7 I tightened the versioned dependency on 
nrepl-clojure. Hopefully, this should fix the problem.


Waiting it to build and for debci to run to close this bug.

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

Bug#1014319: depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or directory

2022-07-12 Thread Salvatore Bonaccorso

Hi Michael,

On Tue, Jul 12, 2022 at 05:57:41PM +0200, Michael Biebl wrote:
> On Sat, 9 Jul 2022 21:02:50 +0200 Salvatore Bonaccorso 
> wrote:
> > On Thu, Jul 07, 2022 at 01:37:53PM +0200, Michael Biebl wrote:
> > > It would thus be great to have the patch in [2] applied and uploaded 
> > > soon. I
> > > can offer to NMU if available time is an issue.
> > 
> > With that patch MR filled:
> > 
> > https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/64
> 
> 
> Thanks for the patch, Sven and thanks for the MR, Salvatore!
> 
> Since we haven't received any feedback so far, I've uploaded an NMU with the
> patch to DELAYED/5 (debdiff attached)
> 
> Ben, please holler if you have any objections and you want me to cancel the
> NMU.

personally i would prefer if we can do it a regular kernel-team
upload, there were some other changes pending.

Will ping Ben on IRC to ask. Otherwise I guess the NMU is fine.

Regards,
Salvatore

Bug#1014827: Please update python-psycopg2cffi to the latest upstream version

2022-07-12 Thread Sergio Durigan Junior

Source: python-psycopg2cffi
Version: 2.8.1-2
Severity: medium

Hi,

python-psycopg2cffi is currently at version 2.8.1, which is causing
python-django-celery-results' dep8 tests to fail:

--8<---cut here---start->8---
autopkgtest [02:17:03]: test upstream: [---
ALTER ROLE
ALTER ROLE
Traceback (most recent call last):
  File "/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
  File "/usr/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/pytest/__main__.py", line 5, in 
raise SystemExit(pytest.console_main())
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 187, 
in console_main
code = main()
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 145, 
in main
config = _prepareconfig(args, plugins)
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 324, 
in _prepareconfig
config = pluginmanager.hook.pytest_cmdline_parse(
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265, in __call__
return self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult)
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80, in 
_hookexec
return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 55, in 
_multicall
gen.send(outcome)
  File "/usr/lib/python3/dist-packages/_pytest/helpconfig.py", line 102, in 
pytest_cmdline_parse
config: Config = outcome.get_result()
  File "/usr/lib/python3/dist-packages/pluggy/_result.py", line 60, in 
get_result
raise ex[1].with_traceback(ex[2])
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39, in 
_multicall
res = hook_impl.function(*args)
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 1016, 
in pytest_cmdline_parse
self.parse(args)
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 1304, 
in parse
self._preparse(args, addopts=addopts)
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 1206, 
in _preparse
self.hook.pytest_load_initial_conftests(
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265, in __call__
return self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult)
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80, in 
_hookexec
return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 60, in 
_multicall
return outcome.get_result()
  File "/usr/lib/python3/dist-packages/pluggy/_result.py", line 60, in 
get_result
raise ex[1].with_traceback(ex[2])
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39, in 
_multicall
res = hook_impl.function(*args)
  File "/usr/lib/python3/dist-packages/pytest_django/plugin.py", line 335, in 
pytest_load_initial_conftests
_setup_django()
  File "/usr/lib/python3/dist-packages/pytest_django/plugin.py", line 223, in 
_setup_django
django.setup()
  File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
apps.populate(settings.INSTALLED_APPS)
  File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 116, in 
populate
app_config.import_models()
  File "/usr/lib/python3/dist-packages/django/apps/config.py", line 304, in 
import_models
self.models_module = import_module(models_module_name)
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 850, in exec_module
  File "", line 228, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/django/contrib/auth/models.py", line 3, 
in 
from django.contrib.auth.base_user import AbstractBaseUser, BaseUserManager
  File "/usr/lib/python3/dist-packages/django/contrib/auth/base_user.py", line 
49, in 
class AbstractBaseUser(models.Model):
  File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 141, in 
__new__
new_class.add_to_class("_meta", Options(meta, app_label))
  File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 369, in 
add_to_class
value.contribute_to_class(cls, name)
  File "/usr/lib/python3/dist-packages/django/db/models/options.py", line 235, 
in contribute_to_class
self.db_table, connection.ops.max_name_length()
  File "/usr/lib/python3/dist-packages/django/utils/connection.py", line 15, in 
__getattr__
return getattr(self._connections[self._alias], item)
  File "/usr/lib/python3/dist-packages/django/utils/connection.py", line 62, in 
__getitem__
conn =

Bug#1014826: German translation of xwit package description contains typo

2022-07-12 Thread Marco

Package: xwit

Hello,
the package description of xwit is wrong (typo):
"Sammlung einfacher Routinen zum Aufruf einiger X11-Funtionen"

Correct is:
"Sammlung einfacher Routinen zum Aufruf einiger X11-Funktionen"

Is is shown here:
https://packages.debian.org/search?keywords=xwit=names=stable=all
and also if I use apt search xwit.
-- 
Marco

Bug#948712: [Pkg-raspi-maintainers] Bug#948712: Pinebook Pro also uses this chip

2022-07-12 Thread Adam Borowski

On Tue, Jul 12, 2022 at 12:45:11PM +0200, Diederik de Haas wrote:
> On dinsdag 12 juli 2022 01:47:21 CEST Adam Borowski wrote:
> > Pinebook Pro also wants this firmware, and it's definitely not a raspi,
> > and it doesn't have /boot/firmware either.
> 
> Is this about the /lib/firmware/brcm/brcmfmac434* files?
> 
> IMO, that group of files shouldn't be part of this package, but be moved to 
> another firmware package, perhaps firmware-brcm80211?

Yeah, that.

The idea of moving these files to another package seems good; steev proposed
firmware-linux, firmware-brcm80211 would be a more specific fit.
Both packages are maintained by debian-kernel@l.d.o, could you folks
comment please?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ What kind of a drug are "base" and "red pill"?  I think acid is
⢿⡄⠘⠷⠚⠋⠀ LSD, which would make base... ?  Judging from the behaviour of
⠈⠳⣄ those "based and redpilled", something nasty.

Bug#993014: cifs-utils non-parallel FTBFS

2022-07-12 Thread Santiago Vila


tags 993014 + patch
thanks

El 26/8/21 a las 12:31, Helmut Grohne escribió:

| make  install-exec-hook
| make[5]: Entering directory '/<>'
| (cd /<>/debian/cifs-utils/sbin && ln -sf mount.cifs mount.smb3)
| /bin/bash: line 1: cd: /<>/debian/cifs-utils/sbin: No such file 
or directory


Hi. I can reproduce this as well.

For the version in bullseye, I believe the attached patch should be 
enough to fix the problem.


For testing/unstable, I'm confused because the QA page for this package:

https://packages.qa.debian.org/c/cifs-utils.html

says:

Updating cifs-utils fixes old bugs: #993014

but I don't see this is fixed in unstable. Is the QA tracker working 
properly?


Thanks.--- a/Makefile.am
+++ b/Makefile.am
@@ -119,6 +119,7 @@
 SUBDIRS = contrib
 
 install-exec-hook:
+   mkdir -p $(DESTDIR)$(ROOTSBINDIR)
(cd $(DESTDIR)$(ROOTSBINDIR) && ln -sf mount.cifs mount.smb3)
 
 install-data-hook:

Bug#1014509: apt install lets me fill the filesystem

2022-07-12 Thread intrigeri

Julian Andres Klode (2022-07-07):
> My plan is to assume that Installed-Size is close enough to "size in
> /usr", and just compare that with free space in /usr with like a 100MB
> padding.
>
> This does not work for kernels which install in /boot, and if anything
> were to install stuff to /opt or /var and they are on a different FS;
> but it should be correct for most packages on a supported (usrmerged)
> system.

Sounds plenty good enough to me, it would fix the bug in the vast
majority of cases!

Bug#1014815: kiwipy initial packaging


Hi Guilherme,

On 2022-07-12 17:43, Guilherme de Paula Xavier Segundo wrote:

Cool, I'll review your previous packaging, it will be a pleasure.
You can be sure it will help and I thank you for your help.


Good to hear!


Initially what caught my attention was that it was a Python package.
Currently I have focused my studies on this language and I have been
looking to package programs along this line. However we are currently
deploying a queue service in the company and we are between Kafka and
RabbitMQ so I merged those two things.


This makes sense. I have interest in packages depending on kiwipy, thus 
this would be great help to my cause as well.



One question, are you interested in being my Sponsor in this package? If
it's a problem, ignore it.


Sure, just ping me whenever you need a review and upload for this 
package or its dependencies.


Best,
Andrius

Bug#779893: some packaging progress

2022-07-12 Thread Hans-Christoph Steiner




Aloïs and Dmitry have done some work towards packaging this:

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

Bug#1014581: systemd-boot: kernel hook schould use conforming name

2022-07-12 Thread Michael Biebl


Control: tags -1 + moreinfo

Am 08.07.22 um 11:14 schrieb Norbert Lange:

Package: systemd-boot
Version: 251.2-7
Severity: normal
X-Debbugs-Cc: nolang...@gmail.com

Dear Maintainer,

The kernel hook in /etc/kernel/{post,pre}inst.d should
be named correctly, to quote the kernel-handbook [1]:


   hook scripts for boot loaders must be named using

 the prefix zz- and no other packages may use this prefix

so zz-systemd-boot whould be correct.


This looks super ugly :-/
At the very least they should have picked numerical prefixes...

That said, why does the kernel hook need to run late/last? I.e., does 
this actually cause any real issues? If so, can you elaborate.


Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014825: libapiguardian-java: Please update to upstream version 1.1.2


Package: libapiguardian-java
Version: 1.1.0-2
Severity: normal
X-Debbugs-Cc: Tony Mancill 
Control: block 1014823 -1

Dear maintainers,

there is a new release upstream for Hamcrest. The new version 1.1.2 has 
been published on Maven Central as well as on Github at 
https://github.com/apiguardian-team/apiguardian/releases for instance, and 
it would be needed to package the recent version of junit5 (cf. #1014823).

Could you please update the binary package libapiguardian-java in Debian.

Thank you in advance!

Best regards,

Thomas Uhle


-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.0-16-arm64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

libapiguardian-java depends on no packages.

libapiguardian-java recommends no packages.

libapiguardian-java suggests no packages.

Bug#1014319: depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/mkinitramfs_vBlw4a/lib/modules/5.18.0-2-amd64: No such file or directory

2022-07-12 Thread Michael Biebl

On Sat, 9 Jul 2022 21:02:50 +0200 Salvatore Bonaccorso 
 wrote:

On Thu, Jul 07, 2022 at 01:37:53PM +0200, Michael Biebl wrote:
> It would thus be great to have the patch in [2] applied and uploaded soon. I
> can offer to NMU if available time is an issue.

With that patch MR filled:

https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/64



Thanks for the patch, Sven and thanks for the MR, Salvatore!

Since we haven't received any feedback so far, I've uploaded an NMU with 
the patch to DELAYED/5 (debdiff attached)


Ben, please holler if you have any objections and you want me to cancel 
the NMU.


Regards,
Michael
diff -Nru initramfs-tools-0.141/debian/changelog 
initramfs-tools-0.141+nmu1/debian/changelog
--- initramfs-tools-0.141/debian/changelog  2022-04-10 23:39:45.0 
+0200
+++ initramfs-tools-0.141+nmu1/debian/changelog 2022-07-12 17:48:01.0 
+0200
@@ -1,3 +1,14 @@
+initramfs-tools (0.141+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Sven Joachim ]
+  * Copy modules.builtin.modinfo into initramfs.
+As of kmod version 30, depmod issues a warning if this file is missing.
+(Closes: #1014319)
+
+ -- Michael Biebl   Tue, 12 Jul 2022 17:48:01 +0200
+
 initramfs-tools (0.141) unstable; urgency=medium
 
   [ Hideki Yamane ]
diff -Nru initramfs-tools-0.141/mkinitramfs 
initramfs-tools-0.141+nmu1/mkinitramfs
--- initramfs-tools-0.141/mkinitramfs   2022-04-10 21:59:31.0 +0200
+++ initramfs-tools-0.141+nmu1/mkinitramfs  2022-07-12 17:47:56.0 
+0200
@@ -294,10 +294,10 @@
mkdir -p "${DESTDIR}/${d}"
 done
 
-# Copy in modules.builtin and modules.order (not generated by depmod)
+# Copy in modules.builtin, modules.builtin.modinfo and modules.order (not 
generated by depmod)
 # and modules.builtin.bin (generated by depmod, but too late to avoid
 # error messages as in #948257)
-for x in modules.builtin modules.builtin.bin modules.order; do
+for x in modules.builtin modules.builtin.bin modules.builtin.modinfo 
modules.order; do
if [ -f "${MODULESDIR}/${x}" ]; then
cp -p "${MODULESDIR}/${x}" "${DESTDIR}${MODULESDIR}/${x}"
fi


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014824: libhamcrest-java: Please update to upstream version 2.2


Package: libhamcrest-java
Version: 1.3-9
Severity: normal
X-Debbugs-Cc: Tony Mancill 

Dear maintainers,

there is a new release upstream for Hamcrest. The new version 2.2 has 
been published on Maven Central as well as on Github at 
https://github.com/hamcrest/JavaHamcrest/releases for instance, and it 
would be needed to package the recent version of libcommons-imaging-java.

Could you please update the binary package libhamcrest-java in Debian.

Thank you in advance!

Best regards,

Thomas Uhle


-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.0-16-arm64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

libhamcrest-java depends on no packages.

libhamcrest-java recommends no packages.

libhamcrest-java suggests no packages.

Bug#959726: [PATCH] Check sshd_config.d/* for HostKey in postinst

2022-07-12 Thread Daniel Kahn Gillmor

Control: tags 959726 + patch

On Thu 2020-11-05 20:26:30 -0800, Dmitry Borodaenko wrote:
> If you can safely assume that /etc/ssh/sshd_config.d exists you can simply add
> it to the list of files scanned for HostKey.
>
> ---
>  debian/openssh-server.postinst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/debian/openssh-server.postinst b/debian/openssh-server.postinst
> index f45f5851c..aa4bee899 100644
> --- a/debian/openssh-server.postinst
> +++ b/debian/openssh-server.postinst
> @@ -18,7 +18,7 @@ get_config_option() {
>   perl -lne '
>   s/[[:space:]]+/ /g; s/[[:space:]]+$//;
>   print if s/^[[:space:]]*'"$option"'[[:space:]=]+//i' \
> -/etc/ssh/sshd_config
> +/etc/ssh/sshd_config /etc/ssh/sshd_config.d/*
>  }
>  
>  
> -- 
> 2.29.2

Thanks for the suggested fix, Dmitry.  I'm tagging this bug report as
having an associated patch.

Since the default line in /etc/ssh/sshd_config these days is:

   Include /etc/ssh/sshd_config.d/*.conf

then i think the replacement line should also include the trailing
.conf.

That is:


diff --git a/debian/openssh-server.postinst b/debian/openssh-server.postinst
index f45f5851c..aa4bee899 100644
--- a/debian/openssh-server.postinst
+++ b/debian/openssh-server.postinst
@@ -18,7 +18,7 @@ get_config_option() {
perl -lne '
s/[[:space:]]+/ /g; s/[[:space:]]+$//;
print if s/^[[:space:]]*'"$option"'[[:space:]=]+//i' \
-  /etc/ssh/sshd_config
+  /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf
 }
 
 




In a simpler world,  get_config_option() would be done by asking sshd
itself to parse the configuration file and output it in normalized form 
directly:

sshd -T | grep -i "^$option " | cut -f2- -d' '

But unfortunately, sshd -T aborts with a failure (and emits no parsed
configuration at all) if no host keys can be found.

I've submitted https://bugzilla.mindrot.org/show_bug.cgi?id=3460
upstream to suggest an improvement there, but even if that is adopted
upstream, we can't rely on it until it's released.

  --dkg


signature.asc
Description: PGP signature

Bug#1014823: junit5: Please update to upstream version 5.8.2


Package: junit5
Version: 5.3.2-4
Severity: normal
X-Debbugs-Cc: Tony Mancill 

Dear maintainers,

there is a new release upstream for JUnit 5. The new version 5.8.2 has 
been published on Maven Central as well as on Github at 
https://github.com/junit-team/junit5/releases for instance, and it would 
be needed to package the recent version of libcommons-imaging-java.

Could you please update the binary package junit5 in Debian.

Thank you in advance!

Best regards,

Thomas Uhle


-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.0-16-arm64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages junit5 depends on:
ii  libapiguardian-java  1.1.0-2
ii  libopentest4j-java   1.2.0-2
ii  libunivocity-parsers-java2.8.3-2

junit5 recommends no packages.

junit5 suggests no packages.

Bug#1014822: inkscape-textext: Missing dependency on python3-cssselect

2022-07-12 Thread Kumar Appaiah

Package: inkscape-textext
Version: 1.3.0-2
Severity: important

Dear Maintainer,

Please add python3-cssselect to the dependencies.

Thanks.

Kumar


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

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

Versions of packages inkscape-textext depends on:
ii  gir1.2-gtk-3.03.24.34-1
ii  gir1.2-gtksource-3.0  3.24.11-2+b1
ii  inkscape  1.2-1
ii  python3   3.9.2-3
ii  python3-gi3.38.0-2
ii  python3-gi-cairo  3.38.0-2
ii  python3-lxml  4.8.0-1
ii  python3-tk3.9.2-1
ii  texlive-latex-base2022.20220405-2

Versions of packages inkscape-textext recommends:
ii  gir1.2-gtk-3.03.24.34-1
ii  gir1.2-gtksource-3.0  3.24.11-2+b1
ii  python3-gi3.38.0-2
ii  python3-gi-cairo  3.38.0-2

Versions of packages inkscape-textext suggests:
ii  texlive-luatex  2022.20220405-2
ii  texlive-xetex   2022.20220405-2

-- no debconf information

Bug#983715: libitext5-java: Please add itext-xtra too


On Tue, 12 Jul 2022, tony mancill wrote:


Hi Thomas,

itext-xtra has Apache Commons Imaging [1] as a build dependency, which
is not yet packaged for Debian.  However, the build system and
dependencies for Commons Imaging look okay, so this feasible for
bookworm (assuming the copyright is clear).

Cheers,
tony

[1] https://commons.apache.org/proper/commons-imaging/index.html



Hi Tony,

thank you for having a look into this!

Honestly, I hasn't been aware of this dependency. Having a look at 
https://commons.apache.org/proper/commons-imaging/dependencies.html, I 
see that Commons Imaging in turn also depends on the newest versions of 
JUnit 5 (version 5.8.2) and Hamcrest (version 2.2) whereas in Debian, 
the package junit5 still uses upstream version 5.3.2 and the package 
libhamcrest-java uses upstream version 1.3. It would be necessary to go 
back to version 1.0-alpha1 of Commons Imaging from May 2019 to meet the 
version requirements of the dependencies if junit5 and libhamcrest-java 
cannot be updated.
The license of Commons Imaging is the Apache License 2.0, that shouldn't 
be a problem.


So what's next: Should I open a new ticket to request the packaging of 
libcommons-imaging-java or should I wait until the packages junit5 and 
libhamcrest-java are updated?


Best regards,

Thomas

Bug#1014795: libtorrent-rasterbar-dev: pkg-config --libs is wrong, leads to FTBFS, again.

2022-07-12 Thread Christian Marillat

On 12 juil. 2022 10:08, Hilko Bengen  wrote:

> Package: libtorrent-rasterbar-dev
> Version: 2.0.6-4
> Severity: grave
> X-Debbugs-Cc: none, Hilko Bengen 
>
> Dear Maintainer,
>
> apparently the bug described (and fixed) in #1009875 has re-appeared in
> the most recent version.

Hack to fix this bug has been lost.

Fixed again.

Christian

Bug#1014821: python3-hgapi: duplicates python-hglib functionality

2022-07-12 Thread Julien Cristau

Package: python3-hgapi
Severity: normal

Hi,

I'm curious why python-hgapi exists when from its description it sounds
like it's a clone of python-hglib which predates it (at least in the
debian archive) by a number of years?

Thanks,
Julien

Bug#1014779: angular.js: CVE-2022-25844

2022-07-12 Thread GCS

Hi Moritz,

On Mon, Jul 11, 2022 at 9:27 PM Moritz Mühlenhoff  wrote:
> The following vulnerability was published for angular.js.
>
> CVE-2022-25844[0]:
 I don't think this will be fixed officially.

> Notably, the website states that AngularJS support ended in January 2022
> and that angular.io is the successor?
 Quick timeline for clarification. Indeed, Angular.io is the successor
of AngularJS. I think it was first released in 2016. That time
upstream, Google stated the support of AngularJS will end in January,
2018. Maybe because big projects were still using it, the support was
extended to January, 2022 (this year). This time it really finished,
the projects remained online but read-only. The successor, Angular.io
still lives and is developed.
I don't have numbers, but it seems enough big projects still use
AngularJS, at least two commercial companies still support it (one to
the end of [?] 2023, the other till 2027 as I know) for money of
course. That is, I doubt the fix will be publicly available. Google
already supported it for six years after it was deprecated.
What's the option of the Security Team? Should I wait for long if a
fix becomes available or simply ask for the removal of the package in
some months?

Regards,
Laszlo/GCS

Bug#1014815: kiwipy initial packaging

2022-07-12 Thread Guilherme de Paula Xavier Segundo

Andrius,

Cool, I'll review your previous packaging, it will be a pleasure.
You can be sure it will help and I thank you for your help.

Initially what caught my attention was that it was a Python package.
Currently I have focused my studies on this language and I have been
looking to package programs along this line. However we are currently
deploying a queue service in the company and we are between Kafka and
RabbitMQ so I merged those two things.

One question, are you interested in being my Sponsor in this package? If
it's a problem, ignore it.

Thanks.

On 22/07/12 05:35, Andrius Merkys wrote:
> Hi Guilherme,
> 
> On 2022-07-12 17:21, Guilherme de Paula Xavier Segundo wrote:
> > Thank you for your contact.
> > I started kiwipy packaging. But it's okay to give you the ITP.
> > 
> > Do you want me to give you the ITP?
> > 
> > If not, I will follow the packaging and keep the package on the team. At
> > the moment I'm not part of the team yet, but I'm waiting for approval.
> 
> No, I am fine with you having it. I did not notice RFP -> ITP transition, so
> I decided to update and push my local attempt to package kiwipy. Feel free
> to reuse anything, rewrite (once you are in the team) or ignore if you want.
> 
> Just out of curiosity, what caught your interest to kiwipy/plumpy?
> 
> Best,
> Andrius

signature.asc
Description: PGP signature

Bug#1014815: kiwipy initial packaging


Hi Guilherme,

On 2022-07-12 17:21, Guilherme de Paula Xavier Segundo wrote:

Thank you for your contact.
I started kiwipy packaging. But it's okay to give you the ITP.

Do you want me to give you the ITP?

If not, I will follow the packaging and keep the package on the team. At
the moment I'm not part of the team yet, but I'm waiting for approval.


No, I am fine with you having it. I did not notice RFP -> ITP 
transition, so I decided to update and push my local attempt to package 
kiwipy. Feel free to reuse anything, rewrite (once you are in the team) 
or ignore if you want.


Just out of curiosity, what caught your interest to kiwipy/plumpy?

Best,
Andrius

Bug#1014820: shiro: CVE-2022-32532

Source: shiro
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for shiro.

CVE-2022-32532[0]:
| Apache Shiro before 1.9.1, A RegexRequestMatcher can be misconfigured
| to be bypassed on some servlet containers. Applications using
| RegExPatternMatcher with `.` in the regular expression are possibly
| vulnerable to an authorization bypass.

https://www.openwall.com/lists/oss-security/2022/06/28/2

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-2022-32532
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32532

Please adjust the affected versions in the BTS as needed.

Bug#1014819: shiro: CVE-2021-41303

Source: shiro
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for shiro.

CVE-2021-41303[0]:
| Apache Shiro before 1.8.0, when using Apache Shiro with Spring Boot, a
| specially crafted HTTP request may cause an authentication bypass.
| Users should update to Apache Shiro 1.8.0.

https://www.openwall.com/lists/oss-security/2021/09/17/1

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-2021-41303
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41303

Please adjust the affected versions in the BTS as needed.

Bug#1012336: dcm2niix: autopkgtest failure on s390x: 1 computed checksum did NOT match

2022-07-12 Thread Nilesh Patra

Bilal,

Since you added autopkgtest for it, can you take a look and fix?

Thanks.

On Sat, 4 Jun 2022 21:12:59 +0200 Paul Gevers  wrote:
> Source: dcm2niix
> Version: 1.0.20211006-4
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: fails-always
> 
> Dear maintainer(s),
> 
> You recently added an autopkgtest to your package dcm2niix, great. 
> However, it fails on s390x. Currently this failure is blocking the 
> migration to testing [1]. Can you please investigate the situation and 
> fix it?
> 
> I copied some of the output at the bottom of this report. Please be 
> aware that s390x is a big-endian system, so if you are calculating 
> md5sum checksums of generated files, I wouldn't be surprised if they are 
> different by design.
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=dcm2niix
> 
> https://ci.debian.net/data/autopkgtest/testing/s390x/d/dcm2niix/22051251/log.gz
> 
> Chris Rorden's dcm2niiX version v1.0.20211006  (JP2:OpenJPEG) GCC11.3.0 
>   (64-bit Linux)
> Found 85 DICOM file(s)
> Convert 85 DICOM as data/data_pasl_2d_20181218130847_3 (72x72x20x85)
> Conversion required 0.063600 seconds (0.047731 for core code).
> [93m[1mRunning Tests[0m
> data/data_pasl_2d_20181218130847_3.json: OK
> data/data_pasl_2d_20181218130847_3.nii: FAILED
> md5sum: WARNING: 1 computed checksum did NOT match
> autopkgtest [00:00:05]: test run-unit-test
> 

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1014815: kiwipy initial packaging

2022-07-12 Thread Guilherme de Paula Xavier Segundo

Hi Andrius,

Thank you for your contact.
I started kiwipy packaging. But it's okay to give you the ITP.

Do you want me to give you the ITP?

If not, I will follow the packaging and keep the package on the team. At
the moment I'm not part of the team yet, but I'm waiting for approval.

Thanks!

On 22/07/12 04:26, Andrius Merkys wrote:
> Hello,
> 
> I have pushed my initial packaging of kiwipy to salsa [1]. Everyone in
> Python Team are welcome to contribute.
> 
> [1] https://salsa.debian.org/python-team/packages/python-kiwipy
> 
> Best,
> Andrius

signature.asc
Description: PGP signature

Bug#789499: busybox: FTBFS with clang instead of gcc

2022-07-12 Thread Nobuhiro Iwamatsu

Package: busybox
Version: 1:1.35.0-1
Followup-For: Bug #789499

Hi,

latest version of busybox can build with clang.
so, we can close this issue.

Best regards,
 Nobuhiro

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 busybox depends on:
ii  libc6  2.33-8

busybox recommends no packages.

busybox suggests no packages.

-- no debconf information

Bug#1014486: python-etelemetry: autopkgtest regression on amd64; arm64; armhf; i386; ppc64el; s390x: pytest7 migration - non-zero exit status 1

2022-07-12 Thread Nilesh Patra

Hi Pollo,

On Wed, 6 Jul 2022 14:39:13 -0400 =?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?= 
 wrote:
> Source: python-etelemetry
> Version: 0.3.0-1
> Control: affects -1 src:pytest
> [...]
> You can find the CI logs here:
> https://ci.debian.net/packages/d/python-etelemetry/

Nitpicking:
The above link is non-existing. it should be a "p/" instead of a "d/"
in the URL.

Same patterns for other bug reports you filed regarding pytest as well. You
might want to fix your script accordingly.

-- 
Best,
Nilesh

signature.asc
Description: PGP signature

Bug#1014740: [Debichem-devel] Bug#1014740: pdb-tools: mangled manual pages: errors, duplicate text

2022-07-12 Thread Paul Wise

On Tue, 2022-07-12 at 13:36 +0300, Andrius Merkys wrote:

> This was caused by '--version' option not being supported by some of the 
> programs. Fixed in 2.5.0-2 upload.

Looks like there are some more errors for --help, see this command:

$ zgrep -iE -- '-help|not valid' /usr/share/man/man1/pdb_*.1.gz

Also a lot of the manual pages are even more broken now, some of them
contain just an error message from the program and no help text but
that help text was present in the 2.5.0-1 upload. I used diffoscope to
compare the 2.5.0-1 and 2.5.0-2 binaries to notice this.

> Not sure this is necessary undesirable. The upstream wants every program 
> to print a notice on them belonging to a group and suggestion to 
> distribute them as a group, what might be addressed to Debian's 
> derivatives. However, if you think these paragraphs should be moved to 
> package description or debian/README.Debian, this could be done, but 
> will need quite extensive patching.

I think I was not clear enough, I meant that in each individual manual
page, there are paragraphs that were copied a couple of times. However
it seems these all of these issues were fixed in the 2.5.0-2 upload
though, at least according the diffoscope and grep.

$ zgrep 'This program is part of the' /usr/share/man/man1/pdb_*.1.gz | sed 
s/:.*// | sort | uniq -c | sort -n

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon

2022-07-12 Thread Johannes Schauer Marin Rodrigues

Quoting Marc Dequènes (duck) (2022-07-12 14:59:21)
> On 2022-07-12 21:31, Johannes Schauer Marin Rodrigues wrote:
> > the salsa link above is 404. If you share your enquote packaging (cannot
> > find it on salsa) then I'll build and test greetd over here. Feel free to
> > ping me for wlgreet testing as well. I've never packaged rust either so I
> > doubt I'll be helpful with any rust-specific packaging stuff.
> 
> Sorry, the fork was for some reason private but I just fixed it.
> 
> The Rust team packaging practices are a tad special so here is the doc:
>https://salsa.debian.org/rust-team/debcargo-conf#id7
> 
> I can provide the deb somewhere if it's too much of a hassle.

you don't happen to have that package for arm64, do you? ;)

I'd like to build it myself no matter what I try running from that README I'm
getting:

debcargo failed: Couldn't find any crate matching enquote *
Try `debcargo update` to update the crates.io index.

Can you send me some steps to follow?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1014815: kiwipy initial packaging


Hello,

I have pushed my initial packaging of kiwipy to salsa [1]. Everyone in 
Python Team are welcome to contribute.


[1] https://salsa.debian.org/python-team/packages/python-kiwipy

Best,
Andrius

Bug#1014818: jruby: CVE-2021-31810 CVE-2021-32066

Source: jruby
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for jruby.


CVE-2021-31810[0]:
| An issue was discovered in Ruby through 2.6.7, 2.7.x through 2.7.3,
| and 3.x through 3.0.1. A malicious FTP server can use the PASV
| response to trick Net::FTP into connecting back to a given IP address
| and port. This potentially makes curl extract information about
| services that are otherwise private and not disclosed (e.g., the
| attacker can conduct port scans and service banner extractions).

This also affects the gems bundled with jruby:
https://www.ruby-lang.org/en/news/2021/07/07/trusting-pasv-responses-in-net-ftp/
https://github.com/ruby/ruby/commit/3ca1399150ed4eacfd2fe1ee251b966f8d1ee469 
(2.7)

CVE-2021-32066[1]:
| An issue was discovered in Ruby through 2.6.7, 2.7.x through 2.7.3,
| and 3.x through 3.0.1. Net::IMAP does not raise an exception when
| StartTLS fails with an an unknown response, which might allow man-in-
| the-middle attackers to bypass the TLS protections by leveraging a
| network position between the client and the registry to block the
| StartTLS command, aka a "StartTLS stripping attack."

This also affects the gems bundled with jruby:
https://www.ruby-lang.org/en/news/2021/07/07/starttls-stripping-in-net-imap/
https://github.com/ruby/ruby/commit/a21a3b7d23704a01d34bd79d09dc37897e00922a 
(2.7)

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-31810
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31810
[1] https://security-tracker.debian.org/tracker/CVE-2021-32066
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32066

Please adjust the affected versions in the BTS as needed.

Bug#1014817: mercurial: broken fsmonitor extension in 6.2

2022-07-12 Thread Julien Cristau

Package: mercurial
Version: 6.2-1
Severity: serious
Tags: upstream

Upstream commit be9bf75a837c looks like it broke the fsmonitor
extension:
>   File "/usr/lib/python3/dist-packages/hgext/fsmonitor/__init__.py", line 
> 338, in 
> if e._v1_state() != b"n" or e._v1_mtime() == -1
> AttributeError: 'dirstate_tuple' object has no attribute '_v1_state'

Cheers,
Julien

Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon


Quack,

On 2022-07-12 21:31, Johannes Schauer Marin Rodrigues wrote:

the salsa link above is 404. If you share your enquote packaging 
(cannot find
it on salsa) then I'll build and test greetd over here. Feel free to 
ping me
for wlgreet testing as well. I've never packaged rust either so I doubt 
I'll be

helpful with any rust-specific packaging stuff.


Sorry, the fork was for some reason private but I just fixed it.

The Rust team packaging practices are a tad special so here is the doc:
  https://salsa.debian.org/rust-team/debcargo-conf#id7

I can provide the deb somewhere if it's too much of a hassle.

Regards.
\_o<

--
Marc Dequènes

Bug#1014730: liburi-perl: Breaks apt-cacher with "Can't locate Regexp/IPv6.pm" error

2022-07-12 Thread Mark Hindley

Hi,

On Tue, Jul 12, 2022 at 07:31:48AM +0100, Mark Hindley wrote:
> > Corresponding untested patch against apt-cacher attached.
> 
> The problem with this approach is that errors from apt-cacher's own evals will
> be skipped as well.

I think the patch below might be a better approach. It preserves the logging
output which is an important function of die_handler().

Robert, are you able to test this?

Thanks.

Mark

>From ae98977a1747350ee6659408bc8b08c366a7116d Mon Sep 17 00:00:00 2001
From: Mark Hindley 
Date: Tue, 12 Jul 2022 13:25:37 +0100
Subject: [PATCH] Don't exit in die_handler() if called from eval.

$SIG{__DIE__} hook is called from evals.

Closes: #1014730
---
 apt-cacher | 1 +
 1 file changed, 1 insertion(+)

diff --git a/apt-cacher b/apt-cacher
index a8c00cb..56eccf8 100755
--- a/apt-cacher
+++ b/apt-cacher
@@ -1255,6 +1255,7 @@ sub write_error_log {
 sub die_handler {
 my ($msg) = @_;
 write_error_log("error [$$]: $msg");
+return if $^S; # In eval block
 sendrsp(HTTP::Response->new(502, 'apt-cacher internal error (died)', 
['Connection' => 'close'])) if $con;
 exit 1;
 }
-- 
2.35.1

Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon

2022-07-12 Thread Johannes Schauer Marin Rodrigues

Hi,

Quoting Marc Dequènes (duck) (2022-07-12 13:53:47)
> Just to let you know, I now have a working greetd package:
> https://salsa.debian.org/debian/greetd
> 
> The enquote build dependency is missing and I'm trying to get it added 
> in the Rust Team:
>
> https://salsa.debian.org/duck/debcargo-conf/-/commit/c64a4a911fd1f04970d982fa53c2d8db2e9cd2b4
> 
> Once unblocked I'll upload them. I asked Rust folks to have a look since 
> that's my first time packaging Rust; I might make some improvements but 
> hopefully it should not delay things too much.
> 
> agreety is included but I have not tested it as I'm using wlgreet (planned
> next), so if anyone could test it that would be helpful.

the salsa link above is 404. If you share your enquote packaging (cannot find
it on salsa) then I'll build and test greetd over here. Feel free to ping me
for wlgreet testing as well. I've never packaged rust either so I doubt I'll be
helpful with any rust-specific packaging stuff.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1014816: new upstream (5.13)

2022-07-12 Thread Daniel Baumann

Package: ustreamer

Hi,

it would be nice if you could upgrade to the current upstream release
(5.13).

Regards,
Daniel

Bug#1014815: RFP: kiwipy -- Easy remote messaging using RabbitMQ

2022-07-12 Thread Bastian Germann


Package: wnpp
Severity: wishlist
Control: block 962932 by -1

* Package name: kiwipy
  Upstream Author : Martin Uhrin
* URL : https://github.com/aiidateam/kiwipy
* License : GPLv3 and Expat
  Programming Lang: Python
  Description : Easy remote messaging using RabbitMQ

kiwiPy is a library that makes remote messaging using RabbitMQ (and possibly 
other message brokers) easy.
It was designed to support high-throughput workflows in big-data and 
computational science settings.
That said, kiwiPy is entirely general and can be used anywhere where 
high-throughput and robust messaging are needed.

Features
  * Support for 1000s of messages per second
  * Highly robust - no loss of messages on connection interruptions
  * Generic communicator interface with native support for RabbitMQ
  * Supports task queues, broadcasts and RPC
  * Support for both thread and coroutine based communication

Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon


Quack,

Just to let you know, I now have a working greetd package:
  https://salsa.debian.org/debian/greetd

The enquote build dependency is missing and I'm trying to get it added 
in the Rust Team:
  
https://salsa.debian.org/duck/debcargo-conf/-/commit/c64a4a911fd1f04970d982fa53c2d8db2e9cd2b4


Once unblocked I'll upload them. I asked Rust folks to have a look since 
that's my first time packaging Rust; I might make some improvements but 
hopefully it should not delay things too much.


agreety is included but I have not tested it as I'm using wlgreet 
(planned next), so if anyone could test it that would be helpful.


Regards.
\_o<

--
Marc Dequènes

Bug#1014797: FTBFS: test failures with new libgd3

2022-07-12 Thread Andreas Tille

Control: tags -1 upstream
Control: forwarded -1 https://github.com/GMOD/GBrowse/issues/64

Bug#1014814: ITP: onionprobe -- test/monitor tool for Tor Onion Services sites

2022-07-12 Thread Georg Faerber

Package: wnpp
Owner: Georg Faerber 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-privacy-maintain...@lists.alioth.debian.org

Package name: onionprobe
Version : 1.0.0
Upstream Author : Silvio Rhatto 
URL : https://gitlab.torproject.org/tpo/onion-services/onionprobe
License : GNU General Public License v3
Programming Lang: Python
Description : test/monitor tool for Tor Onion Services sites

Onionprobe is a tool for testing and monitoring the status of Tor Onion
Services sites.

It can run a single time or continuously to probe a set of onion
services endpoints and paths, optionally exporting to Prometheus.

This package will be maintained within the Debian Privacy Tools
Maintainers team.

Bug#962932: ITP: plumpy -- Python workflows library


Control: retitle -1 ITP: python-plumpy -- Python workflows library

Hi Bastian,

On 2022-07-11 22:28, Bastian Germann wrote:

On Tue, 16 Jun 2020 07:56:34 +0300 mer...@debian.org wrote:
plumpy is required by aiida-core (ITP #901392). However, packaging of 
plumpy is currently blocked by its incompatibility with 
python3-tornado >= 5 [1].


I plan to maintain plumpy together with the DPMT.

[1] https://github.com/aiidateam/plumpy/issues/72


This is resolved with v0.16.0. Do you still want to package plumby?


Thanks for pinging me regarding this development. I have pushed my 
packaging of python-plumpy v0.21.0 to salsa [2]. However, there still 
are unpackaged dependencies, thus I will have to leave it for later. You 
are welcome to commit to the repository if you need plumpy as well.


[2] https://salsa.debian.org/python-team/packages/python-plumpy

Best,
Andrius

Bug#1014813: RM: ruby-deckar01-task-list -- ROM; Already packaged


Package: ftp.debian.org

Quack,

As pointed out by #1011414, ruby-deckar01-task-list was already packaged 
as ruby-task-list. This is a wrong and misleading naming that led me to 
loose time and energy and today to bother you to get it removed from the 
archive.


Please help me forget about this quickly.
\_o<

--
Marc Dequènes

Bug#948712: [Pkg-raspi-maintainers] Bug#948712: Pinebook Pro also uses this chip

2022-07-12 Thread Diederik de Haas

On dinsdag 12 juli 2022 01:47:21 CEST Adam Borowski wrote:
> Pinebook Pro also wants this firmware, and it's definitely not a raspi,
> and it doesn't have /boot/firmware either.

Is this about the /lib/firmware/brcm/brcmfmac434* files?

IMO, that group of files shouldn't be part of this package, but be moved to 
another firmware package, perhaps firmware-brcm80211?

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

Bug#1011443: faker,ruby-faker: error when trying to install together


Quack,

On 2022-07-06 06:18, Antonio Terceiro wrote:

I just did that. Remember that you need to add Breaks:/Replaces: on 
your

package for upgrades to work.


Thanks Antonio. The initial report did not have this analysis and I did 
not did not have time to dig into it.


Regards.
\_o<

--
Marc Dequènes

Bug#1014740: [Debichem-devel] Bug#1014740: pdb-tools: mangled manual pages: errors, duplicate text


Hello,

Thanks for the report.

On 2022-07-11 05:27, Paul Wise wrote:

The manual pages appear to be a bit mangled.

  * They have errors about options the programs don't expect.


This was caused by '--version' option not being supported by some of the 
programs. Fixed in 2.5.0-2 upload.



  * They have lots of duplicate paragraphs of text.


Not sure this is necessary undesirable. The upstream wants every program 
to print a notice on them belonging to a group and suggestion to 
distribute them as a group, what might be addressed to Debian's 
derivatives. However, if you think these paragraphs should be moved to 
package description or debian/README.Debian, this could be done, but 
will need quite extensive patching.


Best,
Andrius

Bug#1014283: nvidia-tesla-510-driver: nvidia-powerd is missing, but present in original driver

2022-07-12 Thread Alexandr Podgorniy

I copied nvidia-powerd binary and .service files from original driver. 
Most of the time it works as expected, but sometimes nvidia-powerd 
stucks at 100% cpu usage. Maybe it's not a good idea to include it into 
package until it's fixed.

Bug#1014812: RFP: tusd -- implementation of the tus resumable upload protocol

2022-07-12 Thread Georg Faerber

Package: wnpp
Owner: Georg Faerber 
Severity: wishlist

Package name: tusd
Version : 1.9.0
Upstream Author : Transloadit Ltd and Contributors
URL : https://github.com/tus/tusd
License : MIT
Programming Lang: Go
Description : implementation of the tus resumable upload protocol 

tusd is the official reference implementation of the tus resumable
upload protocol. The protocol specifies a flexible method to upload
files to remote servers using HTTP. The special feature is the ability
to pause and resume uploads at any moment allowing to continue
seamlessly after e.g. network interruptions.

It is capable of accepting uploads with arbitrary sizes and storing them
locally on disk, on Google Cloud Storage or on AWS S3 (or any other
S3-compatible storage system). Due to its modularization and
extensibility, support for nearly any other cloud provider could easily
be added to tusd.

Bug#1013671: vlc: Video display in a separate window, even if 'integrate video in main video' is enabled

2022-07-12 Thread Grand T

Hello
Finally I uninstalled and purge VLC .deb package
I try with the flatpak version


flatpak install flathub org.videolan.VLC

Looking for matches…

Required runtime for org.videolan.VLC/x86_64/stable 
(runtime/org.kde.Platform/x86_64/5.15-21.08) found in remote flathub

Do you want to install it? [Y/n]: y


org.videolan.VLC permissions:

ipc network pulseaudio x11 devices file access [1]

dbus access [2] bus ownership [3]


[1] host, xdg-config/kdeglobals:ro, xdg-run/gvfs

[2] com.canonical.AppMenu.Registrar, org.freedesktop.Notifications, 
org.freedesktop.ScreenSaver, org.freedesktop.secrets,

org.kde.kconfig.notify, org.kde.kwalletd, org.kde.kwalletd5, 
org.mpris.MediaPlayer2.Player

[3] org.mpris.MediaPlayer2.vlc



ID Branch Op Remote Download

1. [✓] org.kde.KStyle.Adwaita 5.15-21.08 i flathub 6,6 MB / 6,6 MB

2. [✓] org.kde.Platform.Locale 5.15-21.08 i flathub 426,6 kB / 345,7 MB

3. [✓] org.kde.PlatformTheme.QGnomePlatform 5.15-21.08 i flathub 10,0 MB / 10,0 
MB

4. [✓] org.kde.PlatformTheme.QtSNI 5.15-21.08 i flathub 1,3 MB / 1,3 MB

5. [✓] org.kde.WaylandDecoration.QGnomePlatform-decoration 5.15-21.08 i flathub 
6,1 MB / 10,5 MB

6. [✓] org.kde.Platform 5.15-21.08 i flathub 214,1 MB / 306,9 MB

7. [✓] org.videolan.VLC.Locale stable i flathub 236,6 kB / 13,4 MB

8. [✓] org.videolan.VLC stable i flathub 39,3 MB / 31,5 MB


Installation complete.


flatpak run org.videolan.VLC
VLC media player 3.0.17.4 Vetinari (revision 3.0.13-8-g41878ff4f2)


Flatpak VLC is shipped with kde environment.


No issue, VLC never opens two windows.

video and codec preferences are set to automatic


So the problem is in the deb code not in the settings

Bug#1014811: linux-headers-all metapackage for autopkgtests

2022-07-12 Thread Andreas Beckmann

Source: linux
Version: 4.19.235-1
Severity: wishlist

Hi,

for autopkgtests that test building out-of-tree modules it would be
helpful to have an unversioned metapackage that depends on all kernel
header packages. If that is used as dependency of an autopkgtest,
the test itself can easily enumerate all kernels (/lib/modules/*/build/)
and try to build the module for them.


Andreas

Bug#1014810: owncloud-client: CVE-2021-44537

Source: owncloud-client
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for owncloud-client.

CVE-2021-44537[0]:
| ownCloud owncloud/client before 2.9.2 allows Resource Injection by a
| server into the desktop client via a URL, leading to remote code
| execution.

https://owncloud.com/security-advisories/cve-2021-44537/

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-2021-44537
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44537

Please adjust the affected versions in the BTS as needed.

Bug#1014808: libhttp-daemon-perl: CVE-2022-31081

Source: libhttp-daemon-perl
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libhttp-daemon-perl.

CVE-2022-31081[0]:
| HTTP::Daemon is a simple http server class written in perl. Versions
| prior to 6.15 are subject to a vulnerability which could potentially
| be exploited to gain privileged access to APIs or poison intermediate
| caches. It is uncertain how large the risks are, most Perl based
| applications are served on top of Nginx or Apache, not on the
| `HTTP::Daemon`. This library is commonly used for local development
| and tests. Users are advised to update to resolve this issue. Users
| unable to upgrade may add additional request handling logic as a
| mitigation. After calling `my $rqst = $conn-get_request()` one
| could inspect the returned `HTTP::Request` object. Querying the
| 'Content-Length' (`my $cl = $rqst-header('Content-Length')`) will
| show any abnormalities that should be dealt with by a `400` response.
| Expected strings of 'Content-Length' SHOULD consist of either a single
| non-negative integer, or, a comma separated repetition of that number.
| (that is `42` or `42, 42, 42`). Anything else MUST be rejected.

https://github.com/libwww-perl/HTTP-Daemon/security/advisories/GHSA-cg8c-pxmv-w7cf
Refactoring/renaming prerequisite: 
https://github.com/libwww-perl/HTTP-Daemon/commit/331d5c1d1f0e48e6b57ef738c2a8509b1eb53376
Fixed by: 
https://github.com/libwww-perl/HTTP-Daemon/commit/e84475de51d6fd7b29354a997413472a99db70b2
Fixed by: 
https://github.com/libwww-perl/HTTP-Daemon/commit/8dc5269d59e2d5d9eb1647d82c449ccd880f7fd0
Testcase: 
https://github.com/libwww-perl/HTTP-Daemon/commit/faebad54455c2c2919e234202362570925fb99d1

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-2022-31081
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31081

Please adjust the affected versions in the BTS as needed.

Bug#1014807: ruby-jmespath: CVE-2022-32511

Source: ruby-jmespath
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for ruby-jmespath.

CVE-2022-32511[0]:
| jmespath.rb (aka JMESPath for Ruby) before 1.6.1 uses JSON.load in a
| situation where JSON.parse is preferable.

https://github.com/jmespath/jmespath.rb/pull/55
https://github.com/jmespath/jmespath.rb/commit/e8841280053a9d9a0c90f36223f926c8b9e4ec49
 (v1.6.1)

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-2022-32511
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32511

Please adjust the affected versions in the BTS as needed.

Bug#1014809: ruby-mechanize: CVE-2022-31033

Source: ruby-mechanize
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for ruby-mechanize.

CVE-2022-31033[0]:
| The Mechanize library is used for automating interaction with
| websites. Mechanize automatically stores and sends cookies, follows
| redirects, and can follow links and submit forms. In versions prior to
| 2.8.5 the Authorization header is leaked after a redirect to a
| different port on the same site. Users are advised to upgrade to
| Mechanize v2.8.5 or later. There are no known workarounds for this
| issue.

https://github.com/sparklemotion/mechanize/security/advisories/GHSA-64qm-hrgp-pgr9

Prerequisite to clear credential headers when redirecting to cross site
https://github.com/sparklemotion/mechanize/commit/17e5381032c90caf240ac3d2e52b353f40c18d83
 (v2.8.0)

Fixed by: 
https://github.com/sparklemotion/mechanize/commit/907c778001625cb9daa686d5019c939cb416e45b
 (v2.8.5)

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-2022-31033
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31033

Please adjust the affected versions in the BTS as needed.

Bug#1014806: tortoisehg: uninstallable with mercurial 6.2

2022-07-12 Thread Julien Cristau

Source: tortoisehg
Version: 6.1.1-3
Severity: serious

I uploaded mercurial 6.2-1 to sid yesterday, making thg uninstallable.

Cheers,
Julien

Bug#907946: RFH: frama-c -- Platform dedicated to the analysis of source code written in C

2022-07-12 Thread Niederheitmann Franz RDL UDAS62

On Tue, 04 Sep 2018 11:52:07 +0200 Mehdi Dogguy  wrote:
> Package: wnpp
> Severity: normal
>
> Hi all,
>
> Frama-c is a great tool to perform static analysis on source code
> written in C
> (... write your own analysis plugins and many other neat features). But
> it
> requires time to maintain it properly. I do not have that time anymore
> and I
> do not use Frama-c any longer.
>
> Time permitting, I will continue to upload new releases and fix
> outstanding bugs
> but certainly not in sync with frama-c's release cycle. I am willing to
> mentor
> people familiar with OCaml and willing to maintain Frama-c in the
> future.

HI,

I'm not familiar with OCaml but I'm interested in help.



Regards,

Franz

>
> --
> Mehdi
>
>

Bug#1014804: nmu: srm-ifce 1.24.5-1

2022-07-12 Thread Mattias Ellert

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

The libgfal-srm-ifce1 binary package built from the srm-ifce source
package has a dependency on libssl1.1 on the following architectures:

hppa, m68k, sh4, sparc64

It needs a binNMU for the libssl3 transition on those architectures.

https://packages.debian.org/unstable/libgfal-srm-ifce1

  nmu srm-ifce_1.24.5-1 . hppa m68k sh4 sparc64 . -m 'Rebuild against libssl3'


Mattias



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

Bug#1014803: ruby-yajl: CVE-2022-24795