Bug#999485: FYI

[Rich]

FYI to anyone with a Pi 400, stealing the raspi-firmware from sid
(raspi-firmware_1.20220331+ds-1 as of this writing) and rebooting results
in working wifi on bullseye.

Cherrypicking these three files on their own from upstream rpi-firmware
didn't, so still something to be debugged about what needs to change...

- Rich

Bug#1009941: RM: python-lsp-flake8 -- ROM; functionality already present in python-lsp-server

[Jochen Sprickerhof]

Package: ftp.debian.org
Severity: normal

Hi,

please remove python-lsp-flake8 from unstable. It was never part of a
stable release, there are no rdepends and the functionality is already
present in python-lsp-server which it depends on anyhow.

Thanks!

Jochen

Bug#1009624: RM: pdal -- ROM; Should not be in Debian

[Sebastiaan Couwenberg]

On 4/13/22 09:30, Bas Couwenberg wrote:

facet-analyser still has a build dependency on libpdal-dev and a patch for this 
is available in #1007131. The package hasn't seen any activity since its 
initial upload and has unsatisfied dependencies on the only arch where binaries 
are available preventing testing migration. This package should not be a 
blocker for the removal of pdal.


facet-analyser finally got a new upload which removes the pdal build 
dependency amongst other changes.


This removes the last of the pdal rdeps.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1009940: wine64-development-preloader: cannot install in parallel with wine32-development-preloader

[Ernesto Domato]

Package: wine64-development-preloader
Version: 6.19~repack-2
Severity: important
X-Debbugs-Cc: edo...@gmail.com

Hi,

Trying to update wine64-development-preloader to version 6.22~repack-1 in
parallel resulted in broken status since it tries to overwrite

/usr/lib/wine-development/wine-preloader

which is also on the package wine32-development-preloader.

If both packages can't coexist, then the should conflict with each other.

Greets.
Ernesto


-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-development.

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

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

Versions of packages wine64-development-preloader depends on:
ii  wine64-development  6.22~repack-1

wine64-development-preloader recommends no packages.

wine64-development-preloader suggests no packages.

Versions of packages wine-development depends on:
ii  wine32-development  6.22~repack-1
ii  wine64-development  6.22~repack-1

Versions of packages wine-development suggests:
ii  dosbox0.74-3-4
pn  exe-thumbnailer | kio-extras  
ii  playonlinux   4.3.4-2
pn  q4wine
ii  winbind   2:4.16.0+dfsg-6
ii  wine-binfmt   6.0.3~repack-1
ii  winetricks20220411-1

Versions of packages libwine-development depends on:
ii  libasound2   1.2.6.1-2+b1
ii  libc62.33-7
ii  libcapi20-3  1:3.27-3+b1
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.11.1+dfsg-1
ii  libglib2.0-0 2.72.1-1
ii  libgphoto2-6 2.5.27-1
ii  libgphoto2-port122.5.27-1
ii  libgstreamer-plugins-base1.0-0   1.20.1-1
ii  libgstreamer1.0-01.20.1-1
ii  libldap-2.5-02.5.11+dfsg-1
ii  libopenal1   1:1.19.1-2
ii  libpcap0.8   1.10.1-4
ii  libpulse015.0+dfsg1-4
ii  libudev1 250.4-1
ii  libunwind8   1.3.2-2
ii  libvkd3d11.2-11
ii  libx11-6 2:1.7.5-1
ii  libxext6 2:1.3.4-1
ii  libz-mingw-w64   1.2.12+dfsg-1
ii  ocl-icd-libopencl1 [libopencl1]  2.2.14-3

Versions of packages libwine-development recommends:
ii  fonts-liberation   1:1.07.4-11
ii  fonts-wine 6.0.3~repack-1
ii  gstreamer1.0-plugins-good  1.20.1-1
ii  libasound2-plugins 1.2.6-1
ii  libcups2   2.4.1op1-2
ii  libdbus-1-31.14.0-1
ii  libgl1 1.4.0-1
ii  libgl1-mesa-dri21.3.8-1
ii  libgnutls303.7.4-2
ii  libgssapi-krb5-2   1.19.2-2+b1
ii  libkrb5-3  1.19.2-2+b1
ii  libodbc2   2.3.9-5
ii  libosmesa6 21.3.8-1
ii  libsdl2-2.0-0  2.0.20+dfsg-2
ii  libv4l-0   1.22.1-3
ii  libvkd3d-shader1   1.2-11
ii  libvulkan1 1.3.204.1-2
ii  libxcomposite1 1:0.4.5-1
ii  libxcursor11:1.2.0-2
ii  libxfixes3 1:6.0.0-1
ii  libxi6 2:1.8-1
ii  libxinerama1   2:1.1.4-3
ii  libxrandr2 2:1.5.2-1
ii  libxrender11:0.9.10-1
ii  libxxf86vm11:1.1.4-1+b2

Versions of packages libwine-development suggests:
pn  cups-bsd   
ii  gstreamer1.0-libav 1.20.1-1
ii  gstreamer1.0-plugins-bad   1.20.1-1
ii  gstreamer1.0-plugins-ugly  1.20.1-1
ii  ttf-mscorefonts-installer  3.8

Versions of packages wine32-development depends on:
ii  libc62.33-7
ii  libwine-development  6.22~repack-1

Versions of packages wine32-development recommends:
ii  wine-development  6.22~repack-1

Versions of packages wine32-development suggests:
ii  wine32-development-preloader  6.22~repack-1

Versions of packages wine64-development depends on:
ii  libc62.33-7
ii  libwine-development  6.22~repack-1

Versions of packages wine64-development recommends:
ii  wine-development6.22~repack-1
ii  wine32-development  6.22~repack-1

wine64-development suggests no packages.

Versions of packages wine64-development-preloader is related to:
pn  dxvk 
pn  dxvk-wine32-development  
pn  dxvk-wine64-development  
ii  fonts-wine   6.0.3~repack-1

-- no debconf information

Bug#1009253: www.debian.org: remove debian-www list from the footer; direct people to the contact page instead

[Paul Wise]

Hi debian-l10n-english folks,

I'm looking for advice on how to reword the footer on the Debian
website. I want to drop debian-www from the contact information in the
website footer, directing people to the contact page on the website
instead, which should empower them to find a better contact for their
enquiry rather than defaulting to the debian-www mailing list.

Everything I have come up with seems a bit awkward or repetitive to me,
so I am hoping someone on this list can come up with something better.

The proposal is in #1009253 and quoted below.

On Sun, 2022-04-10 at 09:21 +0800, Paul Wise wrote:

> Package: www.debian.org
> Severity: important
> 
> I would like to remove the debian-www list from the footer, since it
> tends to attract off-topic mails about things other than the Debian
> website from people who email the first address they find.
> 
> It would be better if those mails would be directed to the right place
> in the first place, so that debian-www readers don't have to redirect
> the user support requests to debian-user, package issues to bugs etc.
> 
> I believe that the existing Debian contact page does a reasonable job
> of directing people to the right place for their query. There is
> certainly room for improvement (for eg it partially duplicates the
> support page but doesn't link to it) but that can happen in a new bug.
> 
>    https://www.debian.org/contact
> 
> I suggest we replace this text:
> 
>    To report a problem with the web site, please e-mail our publicly
>    archived mailing list debian-...@lists.debian.org in English.
>    For other contact information, see the Debian contact page.
> 
> With text similar to this:
> 
>    Getting in contact with Debian is documented on our contact page.
> 
> I haven't been able to come up with any good text that doesn't seem
> repetitive, so I am hoping someone else can come up with it, or perhaps
> we should discuss this on the debian-l10n-english mailing list.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1009939: sip6: AttributeError: 'YaccProduction' object has no attribute 'parser_manager'

[Bas Couwenberg]

Source: sip6
Version: 6.6.1+dfsg-1
Severity: serious
Control: affects -1 src:qgis

Dear Maintainer,

Since the upgrade to 6.6.1+dfsg-1 qgis FTBFS:

 FAILED: python/analysis/build/_analysis/sip_analysispart0.cpp 
python/analysis/build/_analysis/sip_analysispart1.cpp 
python/analysis/build/_analysis/sip_analysispart2.cpp 
python/analysis/build/_analysis/sip_analysispart3.cpp 
python/analysis/build/_analysis/sip_analysispart4.cpp 
python/analysis/build/_analysis/sip_analysispart5.cpp 
python/analysis/build/_analysis/sip_analysispart6.cpp 
python/analysis/build/_analysis/sip_analysispart7.cpp 
python/analysis/build/_analysis/sip_analysispart8.cpp 
python/analysis/build/_analysis/sip_analysispart9.cpp 
python/analysis/build/_analysis/sip_analysispart10.cpp 
python/analysis/build/_analysis/sip_analysispart11.cpp 
python/analysis/build/_analysis/sip_analysispart12.cpp 
python/analysis/build/_analysis/sip_analysispart13.cpp 
python/analysis/build/_analysis/sip_analysispart14.cpp 
python/analysis/build/_analysis/sip_analysispart15.cpp 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart0.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart1.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart2.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart3.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart4.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart5.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart6.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart7.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart8.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart9.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart10.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart11.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart12.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart13.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart14.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart15.cpp
 
 cd /<>/debian/build/python/analysis && /usr/bin/cmake -E echo && 
/usr/bin/sip-build --no-protected-is-public --pep484-pyi --no-make 
--concatenate=16 --qmake=/usr/lib/i386-linux-gnu/qt5/bin/qmake 
--include-dir=/<>/debian/build/python 
--include-dir=/usr/lib/python3/dist-packages/PyQt5/bindings && /usr/bin/cmake 
-E touch 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart0.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart1.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart2.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart3.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart4.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart5.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart6.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart7.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart8.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart9.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart10.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart11.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart12.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart13.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart14.cpp
 
/<>/debian/build/python/analysis/build/_analysis/sip_analysispart15.cpp
 
 Querying qmake about your Qt installation...
 These bindings will be built: analysis.
 Generating the analysis bindings...
 sip-build: An internal error occurred...
 Traceback (most recent call last):
   File "/usr/bin/sip-build", line 33, in 
 sys.exit(load_entry_point('sip==6.6.1', 'console_scripts', 'sip-build')())
   File "/usr/lib/python3/dist-packages/sipbuild/tools/build.py", line 37, in 
main
 handle_exception(e)
   File "/usr/lib/python3/dist-packages/sipbuild/exceptions.py", line 81, in 
handle_exception
 raise e
   File "/usr/lib/python3/dist-packages/sipbuild/tools/build.py", line 34, in 
main
 project.build()
   File "/usr/lib/python3/dist-packages/sipbuild/project.py", line 249, in build
 self.builder.build()
   File "/usr/lib/python3/dist-packages/sipbuild/builder.py", line 48, in build
 self._generate_bindings()
   File "/usr/lib/python3/dist-packages/sipbuild/builder.py", line 277, in 
_generate_bindings
 buildable = bindings.generate()
   File "/usr/lib/python3/dist-packages/sipbuild/bindings.py", line 166, in 
generate
 spec, sip_files = parse(self.sip_file, SIP_VERSION, encoding,
   File "/usr/lib/python3/dist-packages/sipbuild/generator/parser/parser.py", 
line 35, in parse
 protected_is_public, 

Bug#826044: Hangs in apt hook with a zombie - problem still exists in debian10

[zm5s-trnc]

Tried to install debian11 needrestart-3.5 package, no problem regarding 
dependencies, but problem still the same.



  ├─sshd,13265
  │   └─sh,14854 -c /usr/bin/python 
/root/.ansible/tmp/ansible-tmp-1650508029.18-25277-93685447926498/AnsiballZ_apt.py 
&& sleep 0
  │   └─python,14855 
/root/.ansible/tmp/ansible-tmp-1650508029.18-25277-93685447926498/AnsiballZ_apt.py
  │   └─aptitude,15365 -y -o Dpkg::Options::=--force-confdef -o 
Dpkg::Options::=--force-confold safe-upgrade
  │   ├─aptitude,21577 -y -o 
Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold 
safe-upgrade
  │   │   └─sh,21578 -c test -x 
/usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke || true
  │   │   └─frontend,21579 -w 
/usr/share/debconf/frontend /usr/sbin/needrestart

  │   │   └─(needrestart,21583)
  │   └─{aptitude},15381

needrestart,21583 gets zombie-fied

We can move on if we kill the parent process frontend,21579

Bug#1009938: Audio output switching no longer works after upgrade to GNOME 42

[Josh Triplett]

Package: gnome-control-center
Version: 1:42.0-3
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

After upgrading to GNOME 42, the options in gnome-control-center to
switch the audio output device no longer functions; sound always goes to
the headphone port in my dock if plugged in, or my HDMI monitor otherwise,
without the option to switch back and forth with both plugged in.

The option still exists, but changing its value doesn't change where
audio goes.

- Josh Triplett

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

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

Versions of packages gnome-control-center depends on:
ii  accountsservice   22.07.5-1
ii  apg   2.2.3.dfsg.1-5+b2
ii  colord1.4.6-1
ii  desktop-base  11.0.3
ii  desktop-file-utils0.26-1
ii  gnome-control-center-data 1:42.0-3
ii  gnome-desktop3-data   42.0-2
ii  gnome-settings-daemon 42.1-3
ii  gsettings-desktop-schemas 42.0-1
ii  libaccountsservice0   22.07.5-1
ii  libadwaita-1-01.1.0-1
ii  libc6 2.33-7
ii  libcairo2 1.16.0-5
ii  libcolord-gtk4-1  0.3.0-3
ii  libcolord21.4.6-1
ii  libcups2  2.4.1op1-2
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.13.1-4.4
ii  libgcr-base-3-1   3.40.0-4
ii  libgdk-pixbuf-2.0-0   2.42.8+dfsg-1
ii  libglib2.0-0  2.72.1-1
ii  libgnome-bg-4-1   42.0-2
ii  libgnome-bluetooth-ui-3.0-13  42.0-5
ii  libgnome-desktop-4-1  42.0-2
ii  libgnome-rr-4-1   42.0-2
ii  libgnutls30   3.7.4-2
ii  libgoa-1.0-0b 3.44.0-1
ii  libgoa-backend-1.0-1  3.44.0-1
ii  libgsound01.0.3-2
ii  libgtk-3-03.24.33-1
ii  libgtk-4-14.6.2+ds-1
ii  libgtop-2.0-112.40.0-2
ii  libgudev-1.0-0237-2
ii  libibus-1.0-5 1.5.26-4
ii  libkrb5-3 1.19.2-2+b1
ii  libmalcontent-0-0 0.10.4-1
ii  libmm-glib0   1.18.6-2
ii  libnm01.36.4-2
ii  libnma-gtk4-0 1.8.38-1
ii  libpango-1.0-01.50.6+ds-2
ii  libpangocairo-1.0-0   1.50.6+ds-2
ii  libpolkit-gobject-1-0 0.105-33
ii  libpulse-mainloop-glib0   15.0+dfsg1-4
ii  libpulse0 15.0+dfsg1-4
ii  libpwquality1 1.4.4-1+b1
ii  libsecret-1-0 0.20.5-2
ii  libsmbclient  2:4.16.0+dfsg-6
ii  libudisks2-0  2.9.4-1
ii  libupower-glib3   0.99.17-1
ii  libwacom9 2.2.0-1
ii  libx11-6  2:1.7.5-1
ii  libxi62:1.8-1
ii  libxml2   2.9.13+dfsg-1

Versions of packages gnome-control-center recommends:
pn  cracklib-runtime  
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.26.1-2
ii  gnome-online-accounts 3.44.0-1
ii  gnome-user-docs   42.0-1
ii  gnome-user-share  3.34.0-5
ii  iso-codes 4.9.0-1
pn  libnss-myhostname 
pn  malcontent-gui
ii  network-manager-gnome 1.26.0-1
ii  policykit-1   0.105-33
pn  power-profiles-daemon 
ii  pulseaudio-module-bluetooth   15.0+dfsg1-4
pn  realmd
ii  rygel 0.40.3-1+b1
ii  rygel-tracker 0.40.3-1+b1
ii  system-config-printer-common  1.5.16-1

Versions of packages gnome-control-center suggests:
ii  gnome-software   42.0-1
pn  gstreamer1.0-pulseaudio  
ii  x11-xserver-utils7.7+9

-- no debconf information

Bug#1009918: virtualbox memset symbol fix

[Jan Nordholz]

Hi,

the attached one-liner diff fixes the symbol issue and enables me to run
my Virtualbox VMs again. (However, I didn't check how the addition of
this flag to CXXFLAGS affects the rest of R0 compilation - on the other
hand, it's already there in CFLAGS.)

The missing 'memset' symbol is caused by a compiler-generated call to
memset(), not by an actual call in the source code - my guess is that
g++ emits it to optimize this loop that was added for 6.1.34:

=
--- ./virtualbox-6.1.32-dfsg/src/VBox/Devices/Network/DevE1000.cpp  
2022-01-13 19:55:54.0 +0100
+++ ./virtualbox-6.1.34-dfsg/src/VBox/Devices/Network/DevE1000.cpp  
2022-03-23 00:43:01.0 +0100
@@ -5462,6 +5543,17 @@
 AssertMsgFailed(("Impossible descriptor type!"));
 continue;
 }
+if (fInvalidPacket)
+{
+for (int index = pThis->iTxDCurrent; index < i; ++index)
+pThis->afTxDValid[index] = false; /* Make sure all descriptors 
for this packet are skipped by processing */
+LogFlow(("%s e1kLocateTxPacket: marked %d descriptors as 
invalid\n", pThis->szPrf, i - pThis->iTxDCurrent));
+LogFlow(("%s e1kLocateTxPacket: RET true cbTxAlloc=%d 
cbPacket=%d%s%s\n",
+ pThis->szPrf, pThis->cbTxAlloc, cbPacket,
+ pThis->fGSO ? " GSO" : "", fTSE ? " TSE" : ""));
+pTxdc->nextPacket = i;
+return true;
+}
 if (pDesc->legacy.cmd.fEOP)
 {
 /*
=

Feel free to forward upstream.

Best regards
Jan
--- a/Config.kmk	2022-04-21 01:17:47.0 +0200
+++ b/Config.kmk	2022-04-21 02:00:52.203003760 +0200
@@ -4509,7 +4509,7 @@
 	$(VBOX_GCC_fno-stack-protector) -fno-common $(VBOX_GCC_fvisibility-inlines-hidden) $(VBOX_GCC_fvisibility-hidden) \
 	-fno-rtti $(VBOX_GCC_IPRT_FMT_CHECK)
 TEMPLATE_VBoxR0_CFLAGS.amd64= -m64 -mno-red-zone -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -fasynchronous-unwind-tables -ffreestanding
-TEMPLATE_VBoxR0_CXXFLAGS.amd64  = -m64 -mno-red-zone -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -fasynchronous-unwind-tables
+TEMPLATE_VBoxR0_CXXFLAGS.amd64  = -m64 -mno-red-zone -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -fasynchronous-unwind-tables -ffreestanding
 TEMPLATE_VBoxR0_CXXFLAGS.freebsd= -ffreestanding
  if $(VBOX_GCC_VERSION_CC) < 30400
   TEMPLATE_VBoxR0_DEFS += RT_WITHOUT_PRAGMA_ONCE

Bug#826044: needrestart: Hangs in apt hook with a zombie - problem still exists in debian10

[zm5s-trnc]

Problem still exists in debian 10

After installing needrestart and doing a apt upgrade you get the following :

[...]
Setting up libirs161:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u7) ...
Setting up bind9-host (1:9.11.5.P4+dfsg-5.1+deb10u7) ...
Setting up dnsutils (1:9.11.5.P4+dfsg-5.1+deb10u7) ...
Processing triggers for libc-bin (2.28-10+deb10u1) ...
Processing triggers for mime-support (3.62) ...
Scanning processes...
Scanning candidates...

Failed to check for processor microcode upgrades.

Restarting services...
 invoke-rc.d cron restart
 invoke-rc.d nagios-nrpe-server restart
 invoke-rc.d nullmailer restart
 invoke-rc.d open-vm-tools restart
 invoke-rc.d openntpd restart
 invoke-rc.d snmpd restart
 invoke-rc.d ssh restart
 invoke-rc.d syslog-ng restart
 invoke-rc.d ulogd2 restart
 invoke-rc.d unbound restart

No containers need to be restarted.

User sessions running outdated binaries:
 root @ /dev/pts/0: bash[10397]

Message from root@kddns-sv03-stage on (none) at 18:09 ...

Your session is running obsolete binaries or libraries as listed below.
Please consider a relogin or restart of the affected processes!

 1    bash[10397]

EOF
 root @ /dev/tty1: getty[2053]
 root @ /dev/tty2: getty[2054]
 root @ /dev/tty3: getty[2055]
 root @ /dev/tty4: getty[2056]
 root @ /dev/tty5: getty[2057]
 root @ /dev/tty6: getty[2058]

There it sits ad-vitam... you can only do a ctrl+c to get out of it.

The faulty process :

  ├─sshd,10395
  │   └─bash,10397
  │   └─apt-get,10865 upgrade -y
  │   └─apt-get,12265 upgrade -y
  │   └─sh,12266 -c test -x 
/usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke || true
  │   └─frontend,12267 -w /usr/share/debconf/frontend 
/usr/sbin/needrestart

  │   └─(needrestart,12277)


As you can expect this is a problem for automation or running a Ansible 
playbook ... kinda defeats the purpose of a non-interactive action, not 
to mention the fact that it shouldn't happen in the first place.

Bug#1009937: ITP: quick-lint-js -- JavaScript linter

[strager]

Package: quick-lint-js
Severity: wishlist
Description: find bugs in JavaScript programs
License: GPL-3
Upstream author: me 
URL: https://quick-lint-js.com/
Source URL: 
https://c.quick-lint-js.com/releases/2.4.1/source/quick-lint-js-2.4.1.tar.gz

quick-lint-js finds bugs in your JavaScript code.

I have a Debian package ready and will upload it to mentors.debian.net soon.

Matthew "strager" Glazar

Bug#1009936: dash: dpkg-reconfigure does not prompt to ask whether dash should be the system shell

[Azure]

Package: dash
Version: 0.5.11+git20210903+057cd650a4ed-8
Severity: normal

Dear Maintainer,

I noticed by /bin/sh was pointing to dash rather than bash, and tried
to use dpkg-reconfigure dash to change it (as suggested in the
NEWS.Debian.gz file).

It didn't prompt me and the /bin/sh link to dash remained. I tried
using dpkg-divert to remove it manually which worked, but when I tried
dpkg-reconfigure dash again it just put the diversion back in place.

(I removed and set the link manually after that, which is why the
Shell line says by /bin/sh is /usr/bin/bash.)

Thank you.


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

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

Versions of packages dash depends on:
ii  debianutils  5.7-0.1
ii  dpkg 1.21.7
ii  libc62.33-7

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: false

Bug#1000837: krb5: differing build paths trigger different documentation

[Sam Hartman]

Hi.
I've looked over your report and baffling patch.
This is really strange, and I don't have much to add.

It seems like it might be related to the pathsubst rules in
src/doc/Makefile.in.
But I don't see the build directory getting used there.

Bug#1009837: xdotool: new upstream release available

[Daniel Kahn Gillmor]

Control: tags 1009837 + help

Thanks for the nudge, Matti--

On Mon 2022-04-18 15:56:16 -0400, Matti Klock wrote:
> In 2021, xdotool issued its first release in five years, and it includes some 
> new features:
>
> https://github.com/jordansissel/xdotool/releases
>
> It's been stable for a few months. Packaging the new version would be awesome.

I took a look at this and tried to figure out whether i could package
it.  sadly, it looks like there's some pretty ugly ABI breakage, which i
reported upstream:

   https://github.com/jordansissel/xdotool/issues/387

I pushed a debian/experimental branch to
https://salsa.debian.org/debian/xdotool that tries to repair the ABI
breakage to some degree (it's imperfect, but also trying to not be super
invasive), but it doesn't pass the expected tests, and i haven't looked
into it further.

If someone else wants to try to figure out what's breaking, i'd welcome
any assistance.

 --dkg


signature.asc
Description: PGP signature

Bug#1009934: openssl: reproducible-builds: Embeded compiler flags contain build paths

[Vagrant Cascadian]

Source: openssl
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The compiler flags usually contain the build path on Debian package
builds, and openssl embeds the compiler flags used in various binaries:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/diffoscope-results/openssl.html

  /usr/lib/libcrypto.so.1.1

  
compiler:·gcc·-fPIC...-ffile-prefix-map=/build/1st/openssl-1.1.1n=.·-fstack-...
  vs.
  
compiler:·gcc·-fPIC...-ffile-prefix-map=/build/2/openssl-1.1.1n/2nd=.·-fstack-...


The attached patch fixes this by adjusting util/mkbuildinf.pl to strip
the buildpath out and replace it with the with the placeholder string
"BUILDPATH".


Unfortunately, there are other outstanding issues affecting the
reproducibility of openssl, but applying this patch should reduce the
differences, making it easier to debug the remaining issues.


Thanks for maintaining openssl!


live well,
  vagrant
From 04cb9131bd4a7193a94a70fcfcf8132bff2d0fd8 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 20 Apr 2022 22:26:55 +
Subject: [PATCH] util/mkbuildinf.pl: Replace build path in cflags with a
 placeholder string.

The compiler flags are embedded in various binary files, which on
debian systems typically includes -ffile-prefix-map or
-fdebug-prefix-map which contains the full build path.

https://tests.reproducible-builds.org/debian/issues/unstable/records_build_flags_issue.html
---
 util/mkbuildinf.pl | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/util/mkbuildinf.pl b/util/mkbuildinf.pl
index 1c273872be..2231700f95 100755
--- a/util/mkbuildinf.pl
+++ b/util/mkbuildinf.pl
@@ -8,8 +8,15 @@
 
 use strict;
 use warnings;
+use Cwd;
+use File::Basename;
 
 my ($cflags, $platform) = @ARGV;
+
+my $abs_srcdir = dirname(dirname(Cwd::realpath($0)));
+# replace full path to build directory with string BUILDDIR, passed
+# via -ffile-prefix-map, -fdebug-prefix-map or -fmacro-prefix-map
+$cflags =~ s/prefix-map=$abs_srcdir=/prefix-map=BUILDDIR=/ ;
 $cflags = "compiler: $cflags";
 
 my $date = gmtime($ENV{'SOURCE_DATE_EPOCH'} || time()) . " UTC";
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1008443: golang-github-smartystreets-assertions: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8 github.com/smartystreets/assertions github.com/smartystreets/assert

[Guillem Jover]

Hi!

On Sat, 2022-04-16 at 23:06:39 +0200, Drew Parsons wrote:
> I don't understand the version scheme for this package.
> 
> The Debian version is 1.10.1, which was released 1 Apr 2019.
> 
> After that, many more versions were released, but with "older" version
> numbers.  The most recent was v1.2.1, released on 29 Sep 2021.

It seems like upstream changed the versioning scheme. I've filed a
report there asking if they can prepare a release with a greater
version:

  

Otherwise, the options would be to use something like 1.10.1+really1.2.1,
until upstream catches up with the current version in Debian; or using
an epoch, after consultation with d-d, which would be unfortunate.

Thanks,
Guillem

Bug#1009916: [venv] creation failed because of mising loca/bin/python

[stefanor]

Hi julien.puydt (2022.04.20_15:51:50_+)
> ERROR Virtual environment creation failed, executable /tmp/build-env-
> nu5yo_4s/local/bin/python missing

That was easy enough to work-around by selecting the posix_prefix
sysconfig layout in python3-build.

See: https://github.com/pypa/build/pull/463

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1009933: mumble-server: Failed to read /etc/letsencrypt/live//...

[fips]

Package: mumble-server
Version: 1.3.4-1
Severity: normal
X-Debbugs-Cc: i...@geilerschas.at

Dear Maintainer,

mumble-server complains about, not being able to read the certificates, certbot 
created for my
nginx server.

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

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

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

* I wanted to properly verifiy my domain via letsencrypt, since I
  already use a Webserver anyways.

* Honestly, the workaround to the issue was fairly obvious: just change the
  permissions to given directories/files, given in the error messages:
  $ chmod 755 /etc/letsencrypt/live/
  $ chmod 755 /etc/letsencrypt/archive/
  $ chmod 744 /etc/letsencrypt/archive/privkey1.pem
  
  However, this seems quite lazy and insecure?! At least letyencrypt
  discourages this "workaround", so I wanted to report it just to be sure.
  Especially since this "workaround" is specifically mentioned in your WIKI:
  https://wiki.mumble.info/wiki/Obtaining_a_Let%27s_Encrypt_Murmur_Certificate

* It works, but I am not happy/convinced

* I am not sure if this issue is more related to letsencrypt/certbot
  then to mumble-server to be honest, but since mumble-server is the
  first program for me to show this kind of issue, I decided to report
  it here. Also, I didn't come accross this issue under Debian 10.
  I would have expected mumble-server to work out of the box with these
  certificates, especially since I have the feeling it did work already.

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

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

Versions of packages mumble-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  libavahi-compat-libdnssd1  0.8-5
ii  libc6  2.31-13+deb11u3
ii  libcap21:2.44-1
ii  libgcc-s1  10.2.1-6
ii  libprotobuf23  3.12.4-1
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5sql5 5.15.2+dfsg-9
ii  libqt5sql5-sqlite  5.15.2+dfsg-9
ii  libqt5xml5 5.15.2+dfsg-9
ii  libssl1.1  1.1.1n-0+deb11u1
ii  libstdc++6 10.2.1-6
ii  libzeroc-ice3.73.7.5-2
ii  lsb-base   11.1.0

mumble-server recommends no packages.

mumble-server suggests no packages.

-- Configuration Files:
/etc/mumble-server.ini changed [not included]

-- debconf information excluded

Bug#1000837: krb5: differing build paths trigger different documentation

[Vagrant Cascadian]

On 2021-11-29, Vagrant Cascadian wrote:
> I have not observed this in the tests.reproducible-builds.org history,
> although krb5 currently FTBFS

And now that the FTBFS is fixed, it does appear on
tests.reproducible-builds.org for amd64, i386, arm64 and armhf
architectures for both unstable and experimental, where build paths are
varied:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/krb5.html

The same source built in the current testing suite (bookworm) build
reproducibly, where build paths are not varied.


> For some odd reason the different build path ends up in one build
> consistently removing a space in a few places:
>
> ./usr/share/doc/krb5-doc/appdev/refs/api/krb5_get_init_creds_opt_set_pa.html
>
> -This function allows thecaller to supply options for...
> +This function allows the caller to supply options for...
>
> "thecaller" vs. "the caller".
...
> I try to avoid submitting bugs without patches, but this one is baffling
> enough I hope to get more eyes on it!

Still as perplexed as before!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1009932: RM: gjots2 -- RoQA; Depends on Python 2, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove gjots2. It still depends on Python 2 and is thus removed
from testing since 2019, the last maintainer upload dates back to 2018.

Cheers,
Moritz

Bug#1009931: gmp: reproducible-builds: Embedded build paths in various files

[Vagrant Cascadian]

Source: gmp
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in various files:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/gmp.html

  /usr/include/x86_64-linux-gnu/gmp.h

  
#define·__GMP_CFLAGS·"-g·-O2·-ffile-prefix-map=/build/1st/gmp-6.2.1+dfsg=.·-fstack-..."
  vs.
  
#define·__GMP_CFLAGS·"-g·-O2·-ffile-prefix-map=/build/2/gmp-6.2.1+dfsg/2nd=.·-fstack-..."

  /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1

  /build/1st/gmp-6.2.1+dfsg/build/mpn/tmp-add_n.s:97
  vs.
  /build/2/gmp-6.2.1+dfsg/2nd/build/mpn/tmp-add_n.s:97

The attached patches fix this by replacing the build path with
"BUILDPATH" from in debian/rules, and passing a --debug-prefix-map
argument to use relative paths via ASMFLAGS in configure.


With these patches applied gmp should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining gmp!


live well,
  vagrant
From df942b2fed320e95465625870e8832574a37ab5e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 20 Apr 2022 21:33:25 +
Subject: [PATCH 1/2] debian/rules: Pass ASMFLAGS with debug-prefix-map to
 configure.

The absolute build path can be embedded in generated assembly
code. Instead, passing --debug-prefix-map is used to adjust the
absolute paths to relative paths within the source code.

https://tests.reproducible-builds.org/debian/issues/build_path_captured_in_assembly_objects_issue.html
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 164d9e3..905d95b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -89,7 +89,7 @@ configure-stamp:
 	mkdir -p build
 	cd build && ../configure $(confflags_ma) \
 	AR=$(AR) CC="$(CC)" CFLAGS="$(CFLAGS)" \
-	CXX="$(CXX)" CXXFLAGS="$(CXXFLAGS)"
+	CXX="$(CXX)" CXXFLAGS="$(CXXFLAGS)" ASMFLAGS="--debug-prefix-map=$(CURDIR)=."
 	touch $@
 
 build: build-stamp
-- 
2.35.2

From df301d96468c6248f103b6c16270aeb379e3b3fd Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 20 Apr 2022 21:38:46 +
Subject: [PATCH 2/2] debian/rules: Replace embedded build path in gmp.h with a
 placeholder string.

Frequently builds of debian packages are done in a randomized
directory path which is unlikely to be present on the end-user
system.

https://reproducible-builds.org/docs/build-path/
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 905d95b..9304487 100755
--- a/debian/rules
+++ b/debian/rules
@@ -117,6 +117,9 @@ install: build-stamp install-prep
 	# so override it at install.
 	$(MAKE) DESTDIR=`pwd`/debian/tmp includeexecdir=/usr/include/$(DEB_HOST_MULTIARCH) -C build install
 
+	# Replace embedded build path with a placeholder string
+	sed -i -e "s,$(CURDIR),BUILDPATH,g" debian/tmp/usr/include/$(DEB_HOST_MULTIARCH)/gmp.h
+
 	dh_install -plibgmp10 usr/lib/*/libgmp.so.*
 	dh_install -plibgmpxx4ldbl usr/lib/*/libgmpxx.so.*
 
-- 
2.35.2



signature.asc
Description: PGP signature

Bug#1009269: Should sphinx-patchqueue be removed?

[Moritz Mühlenhoff]

severity 1009269 normal
reassign 1009269 ftp.debian.org
retitle 1009269 RM: sphinx-patchqueue -- RoM; obsolete, no rdeps
thx

Am Wed, Apr 20, 2022 at 06:42:45PM +1000 schrieb Dmitry Smirnov:
> On Monday, 11 April 2022 4:28:40 AM AEST Moritz Muehlenhoff wrote:
> > Source: sphinx-patchqueue
> > Version: 0.5.0-2
> > Severity: serious
> > 
> > Your package came up as a candidate for removal from Debian:
> > 
> > - Still depends on Python 2 and thus removed from testing since 2019
> > - No remaining reverse dependencies
> > - Last upload in 2015
> 
> Yes, it would be great to remove the package please.
> It should be trivial to update it for Python3 but I could never get to
> do that due to lack of time. The package was originally introduced as a
> dependency for something and I can't even remember what was that...
> 
> IMHO safe to remove. Thanks.

Ack, reassigning for removal.

Cheers,
Moritz

Bug#1009929: RM: lxmms2 -- RoQA; Depends on xmms2, which is going away

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove lxmms2. It's a wrapper around xmms2, which itself is dead upstream
ad incompatible with ffmpeg 5 and will be removed from bookworm (and eventually 
the
archive).

Cheers,
Moritz

Bug#1009930: Drop Suggests on xmms2

[Moritz Muehlenhoff]

Source: playerctl
Version: 2.4.1-1
Severity: normal

Hi,
please remove the Suggests: on xmms2. It will not be part of bookworm (#1005902)
and eventually removed from the archive.

Cheers,
Moritz

Bug#1009928: postinst runs unbound-resolvconf even with disabled/masked unbound

[Michael Tokarev]

20.04.2022 23:56, Petr Cech wrote:

Package: unbound
Version: 1.15.0-4
Severity: normal

Hi,
I have unbound installed but masked in systemd. So when postinst of
unbound runs unbound-resolvconf.service I end up with "broken"
resolv.conf pointing to localhost but with no running resolver.
I'm not sure, if the fix should be in unbound-resolvconf.service
file or the postinst should check if unbound is enabled.


Hello Petr!  Thank you for the bug report!

Can you say if it worked correctly before?  I don't know how unbound-resolvconf
is supposed to work to start with, I'm new with unbound package and haven't yet
managed to look at the resolvconf service at all.

To me if the thing is tied to unbound, maybe unbound-resolvconf should depend
on unbound somehow.  Or maybe, if you disable unbound, you should disable (mask)
unbound-resolvconf *too* (just don't know about it).

I'll take a look, - as I said, for now I don't even know what's the purpose of
this additional service. When I first come across it, it looked somewhat 
unusual.

(The thing is installed the usual way, using dh_installsystemd, so postinst
fragment is generated automatically)

But overall, what's the purpose of installing unbound if it is not used as a
service?  I'm curious as of how people use software whey install.

(FWIW, for some years I used my own version of unbound.service which worked
correctly with chroot, - something which has been broken for quite some time
and is hopefully fixed in 1.15).

Thanks,

/mjt

Bug#1009928: postinst runs unbound-resolvconf even with disabled/masked unbound

[Petr Cech]

Package: unbound
Version: 1.15.0-4
Severity: normal

Hi,
I have unbound installed but masked in systemd. So when postinst of
unbound runs unbound-resolvconf.service I end up with "broken"
resolv.conf pointing to localhost but with no running resolver.
I'm not sure, if the fix should be in unbound-resolvconf.service
file or the postinst should check if unbound is enabled.

Regards
Petr


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

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

Versions of packages unbound depends on:
ii  adduser  3.121
ii  init-system-helpers  1.62
ii  libc62.34-0experimental4
ii  libevent-2.1-7   2.1.12-stable-5
ii  libnghttp2-141.43.0-1
ii  libprotobuf-c1   1.3.3-1+b2
ii  libpython3.103.10.4-3
ii  libssl1.11.1.1n-1
ii  libsystemd0  250.4-1
ii  lsb-base 11.1.0

Versions of packages unbound recommends:
ii  dns-root-data  2021011101
ii  openssl3.0.2-1

Versions of packages unbound suggests:
ii  apparmor  3.0.4-2

-- no debconf information

Bug#1009856: chrony: Support refclock in /etc/chrony/sources.d

[Vincent Blut]

Hi Stephan,

Le 2022-04-19 12:10, Stephan Austermühle a écrit :
> Package: chrony
> Version: 4.0-8+deb11u2
> Severity: important
> 
> Dear Maintainer,
> 
> please consider adding support for 'refclock' in /etc/chrony/sources.d.
> 
> Some compute providers (Azure, Hetzner, KVM) support PTP as a
> high-precision alternative to NTP but that feature requires to
> configure a refclock in chrony.
> 
> Example (works for Azure, Hetzner, and KVM):
> 
>   refclock PHC /dev/ptp0 poll 2 dpoll -2 offset 0
> 
> Note that using PTP usually requires loading a corresponding Linux
> kernel module, too (e.g., ptp_kvm).

Please specify your hardware reference clock in /etc/chrony/chrony.conf.
Only NTP sources (i.e. sources declared by the peer, pool and server
directives) can be specified in /etc/chrony/sources.d.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1009927: krb5: deprecated encryption type for master_key_type

[Andreas Hasenack]

Package: krb5
Version: 1.19.2-2
Severity: normal

Dear Maintainer,

when creating a new realm using `krb5_newrealm`, the following warning
is logged in /var/log/syslog:

Apr 20 20:43:16 kdc krb5kdc[3136]: Stash file /etc/krb5kdc/stash uses
DEPRECATED enctype des3-cbc-sha1!

This comes from the kdc.conf template in
/usr/share/krb5-kdc/kdc.conf.template which has "master_key_type =
des3-hmac-sha1".

Maybe it's time to update that encryption type? The kdc.conf manpage
says that the current default is "aes256-cts-hmac-sha1-96". The sample
kdc.conf in the documentation at
https://web.mit.edu/kerberos/krb5-latest/doc/admin/install_kdc.html#kdc-conf
suggests just "master_key_type = aes256-cts".

I understand there may be important upgrade path considerations. Given
all the care and precautions that are shown for migrating away from
single DES in 
https://web.mit.edu/kerberos/krb5-latest/doc/admin/advanced/retiring-des.html,
changing the default master key type for fresh installs might also
require careful planning and thought, but at some point this process
must start. And upstream is now flagging DES3 as deprecated already.

Bug#1009926: ruby-git: CVE-2022-25648

[Salvatore Bonaccorso]

Source: ruby-git
Version: 1.9.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/ruby-git/ruby-git/pull/569
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ruby-git.

CVE-2022-25648[0]:
| The package git before 1.11.0 are vulnerable to Command Injection via
| git argument injection. When calling the fetch(remote = 'origin', opts
| = {}) function, the remote parameter is passed to the git fetch
| subcommand in a way that additional flags can be set. The additional
| flags can be used to perform a command injection.


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-25648
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25648
[1] https://github.com/ruby-git/ruby-git/pull/569
[2] https://security.snyk.io/vuln/SNYK-RUBY-GIT-2421270
[3] 
https://github.com/ruby-git/ruby-git/commit/291ca0946bec7164b90ad5c572ac147f512c7159

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1009925: haskell-devscripts: missing support for DEB_SETUP_GHC_CONFIGURE_ARGS

[Scott Talbert]

Package: haskell-devscripts
Version: 0.16.11
Severity: important

Dear Maintainer,

haskell-devscripts seems to have lost support for using the
DEB_SETUP_GHC_CONFIGURE_ARGS variable in debian/rules for adding arguments to
the GHC configure invocation.  The haskell-yaml package, for example, uses this 
for setting a build flag.

You can see in the recent reproducibility logs [1] that this package has
started to FTBFS because the flag isn't being provided and the package's
binaries are not being built.

[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/haskell-yaml.html

Thanks,
Scott

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Sean Whitton]

Hello,

On Wed 20 Apr 2022 at 03:31PM +01, Matthew Vernon wrote:

> ===Rationale
>
> There are two "rename" programs - the perl rename, and the util-linux
> rename. Debian and its derivatives have shipped the perl rename as
> /usr/bin/rename, whilst other distributions (e.g. Fedora) have shipped
> the util-linux rename thus. The two implementations are incompatible.
> Users might reasonably desire both implementations to be available on
> the same system; they are designed to meet different needs.
>
> Backwards-compatibility (and the lack of a compelling argument that
> rename from util-linux should replace perl rename) means that
> /usr/bin/rename in Debian should remain the perl rename.
>
> Prior to bullseye, util-linux's rename was shipped as
> /usr/bin/rename.ul; Debian's users who wish to use util-linux's rename
> will expect it to be in this location.
>
> ===End Rationale
>
> ===Begin Resolution A
> The Technical Committee overrides the util-linux maintainer, and
> requires that util-linux's rename should be shipped as
> /usr/bin/rename.ul in a binary package built from src:util-linux. The
> package containing rename.ul must not conflict with the rename package
> nor divert /usr/bin/rename.
> ===End Resolution A
>
> ===Begin Resolution B
> The Technical Committee overrides the util-linux maintainer, and
> requires that util-linux's rename should be shipped in a binary package
> built from src:util-linux. If this package Conflicts with the rename
> package, then it must not contain any other binaries.
> ===End Resolution B
>
> ===Begin Resolution N
> None of the above
> ===End Resolution N

I vote

A > B > N

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1009924: node-d3: please ship a sort of libjs-d3 package

[Paul Gevers]

Source: node-d3
Version: 5.16.0-5
Severity: normal

Dear maintainers,

Recently I switched my cacti Depends from libjs-d3 to node-d3 because
the version of libjs-d3 is incredibly old. However, my users don't
need all of node to run cacti. Could you also provide a package that
only ships the Javascript file that would be needed for use cases such
as cacti? (Because libjs-d3 exist, I'm not sure if you'd want to use a
different name, or if src:node-d3 should just take over the binary
from src:libjs-d3).

Paul

Bug#1009680: ghostscript breaks ocrmypdf autopkgtest: seemingly multiple issues

[Nilesh Patra]

Hi,

On Thu, 14 Apr 2022 14:23:43 -0700 Sean Whitton  
wrote:
> control: reassign -1 ghostscript
> control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=705187
> control: retitle -1 Ghostscript 9.56 removes hidden (e.g. OCR) text layers 
> when refrying with NEWPDF=true
> 
> Hello,
> 
> On Thu 14 Apr 2022 at 11:13AM +02, Paul Gevers wrote:
> 
> > With a recent upload of ghostscript the autopkgtest of ocrmypdf fails in
> > testing when that autopkgtest is run with the binary packages of
> > ghostscript from unstable. It passes when run with only packages from
> > testing. In tabular form:
> >
> > passfail
> > ghostscriptfrom testing9.56.0~dfsg-1
> > ocrmypdf   from testing13.4.0+dfsg-1
> > all others from testingfrom testing
> >
> > I copied some of the output at the bottom of this report.
> >
> > Currently this regression is blocking the migration of ghostscript to
> > testing [1]. Due to the nature of this issue, I filed this bug report
> > against both packages. Can you please investigate the situation and
> > reassign the bug to the right package?
> >
> > More information about this bug and the reason for filing it can be found on
> > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> It's a regression in Ghostscript.
> 
> OCRmyPDF has made a release including a workaround but the test suite
> for that fails, so I can't upload it yet.  But in any case this bug is
> not one in OCRmyPDF.

Looks like it has been resolved upstream[1] as I see in the ticket[2].
Jonas, could you please consider to upload a fix?

I personally use ghostscript and would very much like to see this bug being 
fixed.

[1]: https://bugs.ghostscript.com/show_bug.cgi?id=705187
[2]: 
http://git.ghostscript.com/?p=ghostpdl.git;h=fa895673a942caefb81efe1c922407a46d6780c9

Best, Nilesh


signature.asc
Description: PGP signature

Bug#999738: Sample research tag, untested

[Felix Lechner]

diff --git a/lib/Lintian/Check/Languages/Guile/DynamicLink.pm
b/lib/Lintian/Check/Languages/Guile/DynamicLink.pm
new file mode 100644
index 00..dcbd250139
--- /dev/null
+++ b/lib/Lintian/Check/Languages/Guile/DynamicLink.pm
@@ -0,0 +1,68 @@
+# languages/guile/dynamic-link -- lintian check script -*- perl -*-
+
+# Copyright © 2021 Felix Lechner
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, you can find it on the World Wide
+# Web at http://www.gnu.org/copyleft/gpl.html, or write to the Free
+# Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+# MA 02110-1301, USA.
+
+package Lintian::Check::Languages::Guile::DynamicLink;
+
+use v5.20;
+use warnings;
+use utf8;
+
+use Const::Fast;
+usa List::SomeUtils qw(uniq);
+
+use Moo;
+use namespace::clean;
+
+with 'Lintian::Check';
+
+const my $LEFT_SQUARE_BRACKET => q{[};
+const my $RIGHT_SQUARE_BRACKET => q{]};
+
+sub visit_installed_files {
+my ($self, $item) = @_;
+
+return
+  unless $item->name =~ m{ [.] scm $}x
+  || $item->interpreter eq 'guile';
+
+# slurping contents for now
+my $contents = $item->decoded_utf8;
+return
+  unless length $contents;
+
+my @libraries
+  = ($contents
+  =~ m{ [(] define \s+ \S+ \s+ [(] dynamic-link \s+ "([^"]+)"
[)] [)] }gx
+  );
+
+$self->hint('guile-dynamic-link', $_,
+$LEFT_SQUARE_BRACKET . $item->name . $RIGHT_SQUARE_BRACKET)
+  for uniq @libraries;
+
+return;
+}
+
+1;
+
+# Local Variables:
+# indent-tabs-mode: nil
+# cperl-indent-level: 4
+# End:
+# vim: syntax=perl sw=4 sts=4 sr et

diff --git a/tags/g/guile-dynamic-link.tag b/tags/g/guile-dynamic-link.tag
new file mode 100644
index 00..d1faa0b92d
--- /dev/null
+++ b/tags/g/guile-dynamic-link.tag
@@ -0,0 +1,7 @@
+Tag: guile-dynamic-link
+Severity: classification
+Check: languages/guile/dynamic-link
+Explanation: Guile tries to load this shared library via a Scheme
expression like
+ (define libglib (dynamic-link "libglib-2.0")).
+See-Also:
+ Bug#999738

Bug#1009923: src:cvise: fails to migrate to testing for too long: build depends on package that fails to migrate

[Paul Gevers]

Source: cvise
Version: 2.4.0-2.1
Severity: serious
Control: close -1 2.4.0-3
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:cvise has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. In the last upload you switch to 
use llvm-toolchain-14 for the build, but that's not ready to migrate to 
testing yet.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=cvise



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009922: src:python-biopython: fails to migrate to testing for too long: new Depends not migrating to testing

[Paul Gevers]

Source: python-biopython
Version: 1.79+dfsg-1
Severity: serious
Control: close -1 1.79+dfsg-3
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1003933

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:python-biopython has been trying to 
migrate for 61 days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=python-biopython



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996965: Request for maintainer access to salsa group

[Nilesh Patra]

On Wed, Apr 20, 2022 at 08:57:15PM +0200, Andreas Tille wrote:
> > Great.
> > However, I am on a (sort of) VAC these days and wouldn't have time to 
> > package
> > these soonish.
> > @Andreas, could you start with one if you have free cycles?
> 
> My grandchildren are here until Sunday - so no for this week.

Sure - looks like we are all busy :)

> Meanwhile I would love to have any clue how we can associate the Debian
> font with the absolutely cryptic bslib font name.  My current strategy
> is to rather try with the upstream fonts and see what ftpmaster might
> think about this [...]

If you want to check ftp master's views, please uploade sooner (than later)

Regards, Nilesh


signature.asc
Description: PGP signature

Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm

[Andreas Tille]

Hi Amul,

I guess a new upstream version will fix this.  Are you able to prepare
the latest version?

Kind regards

   Andreas.

Am Wed, Apr 20, 2022 at 11:13:31AM +0100 schrieb Neil Williams:
> Source: fis-gtm
> Version: 6.3-014-3
> Severity: important
> Tags: security
> X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerabilities were published for fis-gtm.
> 
> CVE-2021-44492[0]:
> | An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS
> | GT.M through V7.0-000. Using crafted input, attackers can cause a type
> | to be incorrectly initialized in the function f_incr in
> | sr_port/f_incr.c and cause a crash due to a NULL pointer dereference.
> 
> 
> CVE-2021-44493[1]:
> | An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS
> | GT.M through V7.0-000. Using crafted input, an attacker can cause a
> | call to $Extract to force an signed integer holding the size of a
> | buffer to take on a large negative number, which is then used as the
> | length of a memcpy call that occurs on the stack, causing a buffer
> | overflow.
> 
> 
> CVE-2021-44494[2]:
> | An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS
> | GT.M through V7.0-000. Using crafted input, an attacker can cause
> | calls to ZRead to crash due to a NULL pointer dereference.
> 
> 
> CVE-2021-44495[3]:
> | An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS
> | GT.M through V7.0-000. Using crafted input, an attacker can cause a
> | NULL pointer dereference after calls to ZPrint.
> 
> 
> CVE-2021-44496[4]:
> | An issue was discovered in FIS GT.M through V7.0-000 (related to the
> | YottaDB code base). Using crafted input, an attacker can control the
> | size variable and buffer that is passed to a call to memcpy. An
> | attacker can use this to overwrite key data structures and gain
> | control of the flow of execution.
> 
> 
> CVE-2021-44497[5]:
> | An issue was discovered in FIS GT.M through V7.0-000 (related to the
> | YottaDB code base). Using crafted input, can cause the bounds of a for
> | loop to be miscalculated, which leads to a use after free condition a
> | pointer is pushed into previously free memory by the loop.
> 
> 
> CVE-2021-44498[6]:
> | An issue was discovered in FIS GT.M through V7.0-000 (related to the
> | YottaDB code base). Using crafted input, attackers can cause a type to
> | be incorrectly initialized in the function f_incr in sr_port/f_incr.c
> | and cause a crash due to a NULL pointer dereference.
> 
> 
> CVE-2021-44499[7]:
> | An issue was discovered in FIS GT.M through V7.0-000 (related to the
> | YottaDB code base). Using crafted input, an attacker can cause a call
> | to $Extract to force an signed integer holding the size of a buffer to
> | take on a large negative number, which is then used as the length of a
> | memcpy call that occurs on the stack, causing a buffer overflow.
> 
> 
> CVE-2021-44500[8]:
> | An issue was discovered in FIS GT.M through V7.0-000 (related to the
> | YottaDB code base). A lack of input validation in calls to eb_div in
> | sr_port/eb_muldiv.c allows attackers to crash the application by
> | performing a divide by zero.
> 
> 
> CVE-2021-44501[9]:
> | An issue was discovered in FIS GT.M through V7.0-000 (related to the
> | YottaDB code base). Using crafted input, an attacker can cause calls
> | to ZRead to crash due to a NULL pointer dereference.
> 
> 
> CVE-2021-44502[10]:
> | An issue was discovered in FIS GT.M through V7.0-000 (related to the
> | YottaDB code base). Using crafted input, an attacker can control the
> | size of a memset that occurs in calls to util_format in
> | sr_unix/util_output.c.
> 
> 
> CVE-2021-44503[11]:
> | An issue was discovered in FIS GT.M through V7.0-000 (related to the
> | YottaDB code base). Using crafted input, an attacker can cause a call
> | to va_arg on an empty variadic parameter list, most likely causing a
> | memory segmentation fault.
> 
> 
> CVE-2021-44504[12]:
> | An issue was discovered in FIS GT.M through V7.0-000 (related to the
> | YottaDB code base). Using crafted input, an attacker can cause a size
> | variable, stored as an signed int, to equal an extremely large value,
> | which is interpreted as a negative value during a check. This value is
> | then used in a memcpy call on the stack, causing a memory segmentation
> | fault.
> 
> 
> CVE-2021-44505[13]:
> | An issue was discovered in FIS GT.M through V7.0-000 (related to the
> | YottaDB code base). Using crafted input, an attacker can cause a NULL
> | pointer dereference after calls to ZPrint.
> 
> 
> CVE-2021-44506[14]:
> | An issue was discovered in FIS GT.M through V7.0-000 (related to the
> | YottaDB code base). A lack of input validation in calls to do_verify
> | in sr_unix/do_verify.c allows attackers to attempt to jump to a NULL
> | pointer by corrupting a function pointer.
> 
> 
> CVE-2021-44507[15]:
> | An issue was discovered in FIS GT.M through V7.0-000 (related 

Bug#1009921: procenv: apparmor not reported (outdated release)

[Dave Love]

Package: procenv
Version: 0.51-0.2
Severity: normal
X-Debbugs-Cc: none, Dave Love 

I'm reporting this since it's somewhat Debian(/Ubuntu)-specific.

There's currently no report of the apparmor status (or, I think selinux)
due to an autoconf bug which was fixed in v0.60.  There are various
enhancements in recent versions that would be worth an update too.

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

Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN, 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 procenv depends on:
ii  libc62.31-13+deb11u3
ii  libcap2  1:2.44-1
ii  libnuma1 2.0.12-1+b1
ii  libselinux1  3.1-3

procenv recommends no packages.

procenv suggests no packages.

-- no debconf information

Bug#996965: Request for maintainer access to salsa group

[Andreas Tille]

Hi,

Am Wed, Apr 20, 2022 at 11:13:07PM +0530 schrieb Nilesh Patra:
> On Fri, Apr 15, 2022 at 01:24:31PM -0400, Eric Brown wrote: 
> > I have gone ahead and opened RFP bugs for the fonts which are not in Debian
> > but needed by r-cran-bslib (referred to by Nilesh above).
> 
> Thank you very much for finding me and tracking me here.
> 
> > Nunito Sans https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009730
> > Neucha https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009729
> > News Cycle  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009707
> 
> Great.
> However, I am on a (sort of) VAC these days and wouldn't have time to package
> these soonish.
> @Andreas, could you start with one if you have free cycles?

My grandchildren are here until Sunday - so no for this week.

Meanwhile I would love to have any clue how we can associate the Debian
font with the absolutely cryptic bslib font name.  My current strategy
is to rather try with the upstream fonts and see what ftpmaster might
think about this since even if we have the fonts I have no idea what to
do after we have converted these to woff format.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

[Helge Kreutzmann]

Hello Mark,
On Wed, Apr 20, 2022 at 07:25:16PM +0100, Mark Hindley wrote:
> Thanks. I was expecting this after  #1001908 and your contribution to sysvinit
> upstream.
> 
> On Wed, Apr 20, 2022 at 05:45:47PM +0200, Helge Kreutzmann wrote:
> > For the benefit of Sysvinit using Debian users, it would be great if
> > you could enable the translations of the man pages during package
> > build;
> 
> I have had a quick look and I think the upstream support for this is still
> incomplete. Shouldn't there be a rule for building translated manpages in
> man/Makefile?

I did not yet check the details, I just had a quick look. I can check
more in detail in the weekend.

> > My request:
> > ===
> > The only solution I can imagine is the Alternatives system, so we
> > identify which man pages conflict and both manpages-l10n and sysvinit
> > establish alternatives for those translations.
> 
> The other possibility might be dpkg-diverts. Perhaps that depends on how many
> conflicts there actually are/will be. I will try to quantify that more
> accurately.

That is an interesting idea. Than I wait for your analysis, thanks.

Greetings

 Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

[Thorsten Glaser]

On Wed, 20 Apr 2022, Mark Hindley wrote:

> > The only solution I can imagine is the Alternatives system, so we
> > identify which man pages conflict and both manpages-l10n and sysvinit
> > establish alternatives for those translations.
> 
> The other possibility might be dpkg-diverts. Perhaps that depends on how many
> conflicts there actually are/will be. I will try to quantify that more
> accurately.

Or Replaces: but that has downsides on deinstallation.

The scenario would be:

• manpages-de and sysvinit-core ship the same files
• sysvinit-core Replaces: manpages-de (but NOT the other way around)

On deinstalling sysvinit-core, the files from manpages-de would not
be reinstated (which they would with dpkg-divert, which is the one
I’d have considered instead). For many packages, this is unattractive.

Realistically, people who install both on Debian *now* (that is, sid
or bookworm+) will not switch to systemd _afterwards_ so I estimate
that we can go with a Replaces-based solution.

If not dpkg-divert IMHO is the way to go.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Helmut Grohne]

On Wed, Apr 20, 2022 at 03:31:13PM +0100, Matthew Vernon wrote:
> ===Begin Resolution A
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary
> package built from src:util-linux. The package containing rename.ul must not
> conflict with the rename package nor divert /usr/bin/rename.
> ===End Resolution A
> 
> ===Begin Resolution B
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped in a binary package built from
> src:util-linux. If this package Conflicts with the rename package, then it
> must not contain any other binaries.
> ===End Resolution B
> 
> ===Begin Resolution N
> None of the above
> ===End Resolution N

I vote A > B > N.

Helmut


signature.asc
Description: PGP signature

Bug#1009789: closed by Debian FTP Masters (reply to Nilesh Patra ) (Bug#1009789: fixed in bmtk 1.0.4+ds-3)

[Paul Gevers]

Hi,

On 20-04-2022 19:36, Debian Bug Tracking System wrote:

  bmtk (1.0.4+ds-3) unstable; urgency=medium
  .
* Team Upload.
* d/t/control: Run tests only on amd64 since
  bmtk is not available elsewhere (Closes: #1009789)


I'm sorry, I should have caught that and I should have instead added a 
hint (just in case it because available on different architectures in 
the future).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

[Mark Hindley]

Helge,

Thanks. I was expecting this after  #1001908 and your contribution to sysvinit
upstream.

On Wed, Apr 20, 2022 at 05:45:47PM +0200, Helge Kreutzmann wrote:
> For the benefit of Sysvinit using Debian users, it would be great if
> you could enable the translations of the man pages during package
> build;

I have had a quick look and I think the upstream support for this is still
incomplete. Shouldn't there be a rule for building translated manpages in
man/Makefile?

> My request:
> ===
> The only solution I can imagine is the Alternatives system, so we
> identify which man pages conflict and both manpages-l10n and sysvinit
> establish alternatives for those translations.

The other possibility might be dpkg-diverts. Perhaps that depends on how many
conflicts there actually are/will be. I will try to quantify that more
accurately.

Best wishes

Mark

Bug#1009670: installation-reports: Mostly working installation on rockpro64

[Diederik de Haas]

On Thursday, 14 April 2022 05:02:26 CEST Vagrant Cascadian wrote:
> On 2022-04-13, Vagrant Cascadian wrote:
> > I will admit I used a tained image that added a couple modules for
> > HDMI output on another platform (rock64); I'll check without the extra
> > modules and report back if they're needed.
> 
> Grahpical installer seems to work out of the box on rockpro64, yay!

Do you know what's the status wrt Bullseye installer and the RockPro64?
Does it work? Does HDMI output work? Or is a serial adapter needed?

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

Bug#1005500: argh: FTBFS: doctest.h:1398:92: error: use of deleted function ‘doctest::detail::Expression_lhs >::Expression_lhs(doctest::detail::Expression

[Nilesh Patra]

Control: retitle -1 doctest breaks argh build: doctest.h:1398:92: error: use of 
deleted function ‘doctest::detail::Expression_lhs 
>::Expression_lhs(doctest::detail::Expression_lhs >&&)’
Control: reassign -1 src:doctest

Fixing BTS mess-ups from my prev email.

Best, Nilesh


signature.asc
Description: PGP signature

Bug#1005500: argh: FTBFS: doctest.h:1398:92: error: use of deleted function ‘doctest::detail::Expression_lhs >::Expression_lhs(doctest::detail::Expression

[Nilesh Patra]

Control: retitle -1 doctest
Control: reassign -1 doctest
Control: affects -1 argh
Control: tags -1 - help
Control: forwarded -1 https://github.com/doctest/doctest/issues/630

On Thu, 17 Mar 2022 09:56:54 +0100 Andreas Tille  wrote:
> Control: tags -1 help
> Control: tags -1 upstream
> Control: forwarded -1 https://github.com/adishavit/argh/issues/72

As upstream noticed in this comment, turns out this is problem with doctest
itself[0]. Upstream opened and issue about the same[1] and fixed this in a PR[2]

Jonas if you are reading this, if possible
could you please apply the corresponding patch and upload doctest?

[0]: https://github.com/adishavit/argh/issues/72#issuecomment-1073683712
[1]: https://github.com/doctest/doctest/issues/630
[2]: https://github.com/doctest/doctest/pull/634

Thanks,
Nilesh


signature.asc
Description: PGP signature

Bug#1009907: Smbclient error: "Failed to mount Window share: invalid argument"

[Michael Tokarev]

Control: reassign -1 gvfs-backends 1.50.0-1
Control: tag -1 + upstream patch

20.04.2022 16:06, Salis, Antonello (NFOD) wrote:

Package: smbclient
   Version: 2:4.16.0+dfsg-6

Debian testing

When I try to browse Windows folders with Nautilus or Nemo i get "Failed to 
mount Window share: invalid argument".
This never happened before last week.
Found a similar topic here:https://bbs.archlinux.org/viewtopic.php?id=275179


This appears to be this issue: https://gitlab.gnome.org/GNOME/gvfs/-/issues/611
and this fix: https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/138

I'm reassigning this to gvfs.  Hopefully I doing it right :)

Thank you for the bugreport!

/mjt

Bug#1008016: ITP: safe-network -- network routing and service daemon for the Safe Network

[Jonas Smedegaard]

0.58.13 draft 2, needs embedding 212 crates (131 missing, 56 outdated, 
23 ahead, 2 outdated and broken); Builds in ~65 minutes; Runs but help 
needed to properly test functionality

Thanks for the interest and encouragements shown at the Safenet forum 
https://safenetforum.org/t/will-maidsafe-be-in-debian-repositories

Package upgraded to newest upstream release, and nudged to use more 
packaged crates (i.e. reduce amount of embedded packages).

Main task continues to be to keep package up-to-date with upstream 
releases and try relace more embedded crates with packaged ones.

You can help by testing this draft package (either build it yourself or 
tell if you want access to binary packages I've built) and provide 
feedback on how well it works for you.

You can also help by joining the Rust team in Debian and contribute to 
unbreaking/upgrading/adding needed crate packages, as listed here: 
https://salsa.debian.org/debian/safe-network/-/blob/debian/latest/debian/TODO


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1009920: Internal error: Could not resolve keysym XF86EmojiPicker

[積丹尼 Dan Jacobson]

Package: x11-xkb-utils
Version: 7.7+5

https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/156#note_1347383
says
   Internal error: Could not resolve keysym XF86EmojiPicker
might be a Debian bug.

Bug#1009907: Smbclient error: "Failed to mount Window share: invalid argument"

[Michael Tokarev]

20.04.2022 19:44, Michael Tokarev wrote:
..

An interesting find.  I quickly browsed there, but don't immediately see a
solution in there. I'll take a closer look.


This appears to be the fix: 
https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/138
(which is in gnome-vfs).

But does smbclient work for you?

Thanks,

/mjt

Bug#999550: RFS: rserpooldemo/3.0.6~test0-1

[Bastian Germann]

Control: tags -1 moreinfo

On Wed, 9 Feb 2022 14:47:31 +0100 Bastian Germann  wrote:

d/copyright
===
Missing copyright statement of src/background/gimp-scripts/Make-Text

rserpooldemo-management.install
===
/etc/system-info.d and /etc/system-maintenance.d are very generic names for 
configuration files.
What justifies having them with these names?


Please comment on these. I am tagging moreinfo to get this off the todo list.

Bug#1009907: Smbclient error: "Failed to mount Window share: invalid argument"

[Michael Tokarev]

20.04.2022 16:06, Salis, Antonello (NFOD) wrote:

Package: smbclient
   Version: 2:4.16.0+dfsg-6

Debian testing

When I try to browse Windows folders with Nautilus or Nemo i get "Failed to 
mount Window share: invalid argument".
This never happened before last week.


Does smbclient work by itself for you?


Found a similar topic here:https://bbs.archlinux.org/viewtopic.php?id=275179


An interesting find.  I quickly browsed there, but don't immediately see a
solution in there. I'll take a closer look.

Ironically, the smbclient I built locally from the current samba package
does not work for me at all: it says

 protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE

after asking me for a password - when I try to connect to a share or
get a list of shares.  So far I don't know what it is.. :)

/mjt

Bug#1009918: Virtualbox package is broken

[Aso Renji]

Package: virtualbox
Version: 6.1.34-dfsg-1
Severity: grave

New version of virtualbox in sid release can't run any virtual machine, 
because "Unable to locate imported symbol 'memset' ". See 
https://www.virtualbox.org/ticket/20904 for detail. Just remove 6.1.34 
and return 6.1.32.

Bug#1009917: gtk4 applications randomly crash

[ZenWalker]

Package: libgtk-4-1
Version: 4.6.2+ds-1
Severity: grave
Tags: patch
X-Debbugs-Cc: s...@riseup.net

Unable to run these applications 10 times without crash with mobian pinephone:

megapixels, gnome-calculator, and gnome-clocks and probably more gtk4 apps

the crash, running in terminal:

Gsk:ERROR:../../../gsk/gl/gskglcommandqueue.c:1266:gsk_gl_command_queue_create_render_target:
 assertion failed (glCheckFramebufferStatus (GL_FRAMEBUFFER) == 
GL_FRAMEBUFFER_COMPLETE): (0x8cd6 == 0x8cd5)
Bail out! 
Gsk:ERROR:../../../gsk/gl/gskglcommandqueue.c:1266:gsk_gl_command_queue_create_render_target:
 assertion failed (glCheckFramebufferStatus (GL_FRAMEBUFFER) == 
GL_FRAMEBUFFER_COMPLETE): (0x8cd6 == 0x8cd5)
Aborted (core dumped)

The issue in gtk repo:
https://gitlab.gnome.org/GNOME/gtk/-/issues/4763

This patch fixes the bug:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4570.patch


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.15-sunxi64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 libgtk-4-1 depends on:
ii  adwaita-icon-theme42~really41.0-1
ii  hicolor-icon-theme0.17-2
ii  libc6 2.33-7
ii  libcairo-gobject2 1.16.0-5
ii  libcairo-script-interpreter2  1.16.0-5
ii  libcairo2 1.16.0-5
ii  libcloudproviders00.3.1-2
ii  libcolord21.4.6-1
ii  libcups2  2.4.1op1-2
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.13.1-4.4
ii  libfribidi0   1.0.8-2.1
ii  libgdk-pixbuf-2.0-0   2.42.8+dfsg-1
ii  libglib2.0-0  2.72.0-1+b1
ii  libgraphene-1.0-0 1.10.8-1
ii  libgtk-4-common   4.6.2+ds-1
ii  libharfbuzz0b 2.7.4-1
ii  libjpeg62-turbo   1:2.1.2-1
ii  libpango-1.0-01.50.6+ds-2
ii  libpangocairo-1.0-0   1.50.6+ds-2
ii  libpangoft2-1.0-0 1.50.6+ds-2
ii  libpng16-16   1.6.37-3
ii  libtiff5  4.3.0-6
ii  libwayland-client01.20.0-1
ii  libwayland-egl1   1.20.0-1
ii  libx11-6  2:1.7.5-1
ii  libxcursor1   1:1.2.0-2
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.4-1
ii  libxfixes31:6.0.0-1
ii  libxi62:1.8-1
ii  libxinerama1  2:1.1.4-3
ii  libxkbcommon0 1.4.0-1
ii  libxrandr22:1.5.2-1
ii  shared-mime-info  2.1-2

Versions of packages libgtk-4-1 recommends:
ii  iso-codes4.9.0-1
ii  libgtk-4-bin 4.6.2+ds-1
ii  librsvg2-common  2.52.5+dfsg-3+b1

Versions of packages libgtk-4-1 suggests:
ii  gvfs  1.50.0-1
pn  libgtk-4-media-gstreamer | libgtk-4-media-ffmpeg  

-- no debconf information

Bug#1009916: [venv] creation failed because of mising loca/bin/python

[julien . puydt]

Package: python3-venv
Version: 3.10.4-1

I tried to take upstream jupyter-packaging (I'm trying to package
it...). I installed all deps:
Build-Depends: debhelper-compat (= 13),
   dh-python,
   python3-all,
   python3-build ,
   python3-deprecation,
   python3-packaging,
   python3-pytest ,
   python3-pytest-mock ,
   python3-setuptools,
   python3-tomlkit,
   python3-venv 


Then running "pytest-3" gives what's below. Notice: /tmp/build-env-
nu5yo_4s doesn't seem to exist at all when I check after the error, so
I don't really know what to check / how to debug the issue.

Cheers,

J.Puydt

= test session starts
==
platform linux -- Python 3.10.4, pytest-6.2.5, py-1.10.0, pluggy-1.0.0
rootdir: /home/jpuydt/Debian/build/jupyter-packaging-0.12.0
plugins: hypothesis-6.36.0, mock-3.6.1
collected 66 items

tests/test_build_api.py ..FF  
[ 12%]
tests/test_core_functions.py ...  
[ 22%]
tests/test_datafiles_install.py ss
[ 37%]
tests/test_datafiles_paths.py 
[ 50%]
tests/test_deprecated.py ...s.s   
[ 65%]
tests/test_install.py sss 
[ 69%]
tests/test_is_stale.py ...
[ 86%]
tests/test_main.py .  
[ 87%]
tests/test_utility_functions.py   
[100%]

=== FAILURES
===
__ test_build_package
__

make_package = .do_stuff at
0x7f471b7c5ea0>

def test_build_package(make_package):
package_dir = make_package()
pyproject = package_dir / "pyproject.toml"
text = pyproject.read_text(encoding="utf-8")
text = text.replace("setuptools.build_meta",
"jupyter_packaging.build_api")
text += TOML_CONTENT
pyproject.write_text(text, encoding="utf-8")
package_dir.joinpath("foo.py").write_text(FOO_CONTENT,
encoding="utf-8")
>   check_call([sys.executable, "-m", "build"], cwd=package_dir)

/home/jpuydt/Debian/build/jupyter-packaging-
0.12.0/tests/test_build_api.py:128: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ 

popenargs = (['/usr/bin/python3', '-m', 'build'],)
kwargs = {'cwd': PosixPath('/tmp/pytest-of-jpuydt/pytest-
6/test_build_package0/package')}
retcode = 1, cmd = ['/usr/bin/python3', '-m', 'build']

def check_call(*popenargs, **kwargs):
"""Run command with arguments.  Wait for command to complete. 
If
the exit code was zero then return, otherwise raise
CalledProcessError.  The CalledProcessError object will have
the
return code in the returncode attribute.

The arguments are the same as for the call function.  Example:

check_call(["ls", "-l"])
"""
retcode = call(*popenargs, **kwargs)
if retcode:
cmd = kwargs.get("args")
if cmd is None:
cmd = popenargs[0]
>   raise CalledProcessError(retcode, cmd)
E   subprocess.CalledProcessError: Command
'['/usr/bin/python3', '-m', 'build']' returned non-zero exit status 1.

/usr/lib/python3.10/subprocess.py:369: CalledProcessError
- Captured stdout call 
-
* Creating venv isolated environment...

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/build/__main__.py", line 372, in
main
built = build_call(
  File "/usr/lib/python3/dist-packages/build/__main__.py", line 229, in
build_package_via_sdist
sdist = _build(isolation, builder, outdir, 'sdist',
config_settings, skip_dependency_check)
  File "/usr/lib/python3/dist-packages/build/__main__.py", line 140, in
_build
return _build_in_isolated_env(builder, outdir, distribution,
config_settings)
  File "/usr/lib/python3/dist-packages/build/__main__.py", line 104, in
_build_in_isolated_env
with _IsolatedEnvBuilder() as env:
  File "/usr/lib/python3/dist-packages/build/env.py", line 104, in
__enter__
executable, scripts_dir = _create_isolated_env_venv(self._path)
  File "/usr/lib/python3/dist-packages/build/env.py", line 258, in
_create_isolated_env_venv
executable, script_dir, purelib =
_find_executable_and_scripts(path)
  File "/usr/lib/python3/dist-packages/build/env.py", line 303, in
_find_executable_and_scripts
raise RuntimeError(f'Virtual environment creation failed,
executable {executable} missing')
RuntimeError: Virtual environment creation failed, executable
/tmp/build-env-nu5yo_4s/local/bin/python missing

ERROR Virtual environment creation failed, executable 

Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

[Helge Kreutzmann]

Source: sysvinit
Version: 3.03
Severity: wishlist

For better understanding, I provide some background and afterwards my
exact proposal (request).

On myself
=
I'm maintainer of (amongst others) manpages-l10n (localized man pages)
and offered to continue the German translation for sysvinit upstream.

Background:
===
Until recently (i.e. before manpges-l10n version 4.13-1 released in 
February) the translations from Sysvinit were shipped, even if Systemd 
had a man page of the same name. This caused user confusion (see 
#1001908) and therefor manpages-l10n (i.e. manpages-de, manpages-fr, 
manpages-pl, ..) now ship the translation of the systemd man pages 
always.

An example for this is shutdown(8).

When resolving this issue, upstream agreed to accept the man page
translations for its man pages, so they are not lost.

I monitored the sourceware repository, but apparently those files did
not appear there, but in github, therefor I could not post an advanced
warning to you, apologizes.

For the benefit of Sysvinit using Debian users, it would be great if
you could enable the translations of the man pages during package
build; if you need any help on this please ask me and I can have a
look. However, this will create file conflicts if systemd ships a man
page of the same name (which is definitly translated into German but
possibly other languages). 

Simply conflicting manpages-de, manpages-pl, ... won't work, as
manpages-l10n ships translations for over 100 upstream projects, so
forcing it out on Systemvinit systems would not be very nice to users
(they e.g. loose all man-pages translations, mutt, groff, ...).

My request:
===
The only solution I can imagine is the Alternatives system, so we
identify which man pages conflict and both manpages-l10n and sysvinit
establish alternatives for those translations. Except for German I
expect little updates for other languages, so this system would be
rather static.

If there are better ways to have both sysvinit and manpages-de
(manpages-es, manpages-fr, ..) on the same system at the same time,
then of course I would prefer this. Otherwise bear with me, as a
package maintainer I haven't used the alternatives system so far.

Once this is in place, you enable the translations in sysvinit
packages and users of sysvinit in other languages can read their
correct man pages again (as they did for the last 25 years in German,
other languages simmilarly).

This bug mainly serves to get the ball rolling before the file
conflicts appear and we can coordinate our uploads and packages. Of
course, we can discuss this off-bug, if you prefer.



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

Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Gunnar Wolf]

Thank you very much for drafting the ballot, Matthew!

Matthew Vernon dijo [Wed, Apr 20, 2022 at 03:31:13PM +0100]:
> ===Begin Resolution A
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary
> package built from src:util-linux. The package containing rename.ul must not
> conflict with the rename package nor divert /usr/bin/rename.
> ===End Resolution A
> 
> ===Begin Resolution B
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped in a binary package built from
> src:util-linux. If this package Conflicts with the rename package, then it
> must not contain any other binaries.
> ===End Resolution B
> 
> ===Begin Resolution N
> None of the above
> ===End Resolution N

I vote A > B > N

Thanks!


signature.asc
Description: PGP signature

Bug#1009903: unbound: /etc/resolvconf/update.d/unbound is enabled by default after upgrade

[Vincent Lefevre]

Control: tag -1 - moreinfo

(really removing the tag, which was not done due to bug 746206)

On 2022-04-20 16:48:57 +0300, Michael Tokarev wrote:
> Thinking about it I expect the same behavior, to preserve whatever
> local permission changes are made.  In this case: if you already
> had this file enabled for resolvconf, the new version stays enabled
> too.

I would agree for a merge of the changes by the maintainer, but
not when the user decides to revert his local changes. I've opened
a bug against dpkg (bug 1009913), with also the possibility of
letting the user decide (splitting the first option into two
different choices).

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

Bug#1009914: telegnome does not fetch page images

[Renzo Davoli]

Package: telegnome
Version: 0.3.6-1
Severity: important
X-Debbugs-Cc: re...@cs.unibo.it

Dear Maintainer,

   * What led up to the situation?
 one of the latest updates of dependent packages

telegnome does not work any more. The only message I get is:
WARNING **: 17:01:40.546: http.vala:62: Unable to fetch 
'http://www.servizitelevideo.rai.it/televideo/pub/tt4web/Nazionale/16_9_page-100.png':
 The specified location is not supported

The URL is valid and I can read the page if I retrieve its contents by a 
browser.

Thank you in advance.

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

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

Versions of packages telegnome depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.72.1-1
ii  libgtk-3-0   3.24.33-1
ii  libuuid1 2.38-4

telegnome recommends no packages.

telegnome suggests no packages.

-- no debconf information

Bug#1009880: fio: New upstream version available (3.30)

[Martin Steigerwald]

Hi Salvatore.

Am Dienstag, dem 19.04.2022 um 21:25 +0200 schrieb Salvatore Bonaccorso:

[…]
> There is a new upstream version available for fio, 3.30 at time of
> writing. If you have time, can you upload the new version to unstable?

Thanks for letting me know.

I prepared fio-3.30 and uploaded the results to the Salsa repo.

I asked my sponsor Sven to upload it. He may be busy so it may take a
while.

Best,

Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
www.proact.de
Südwestpark 43 •
90449 Nürnberg •
Germany
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
René Schülein
 •
Jonas Hasselberg
 •
Linda Höljö
#ThePowerOfData  |
#ThePowerOfTogether

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Please read more in Proacts’ 
privacy notice,

Bug#1009913: dpkg: when the user reverts to the package maintainer's version of a conffile, the execute bit is not propagated

[Vincent Lefevre]

Package: dpkg
Version: 1.21.7
Severity: normal

In an upgrade, the user may get a prompt like that and answer yes
to install the package maintainer's version of a conffile, thus
reverting all changes done he had done:

Configuration file '/etc/resolvconf/update.d/unbound'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** unbound (Y/I/N/O/D/Z) [default=N] ? Y
Installing new version of config file /etc/resolvconf/update.d/unbound ...
[...]

However, if the user had changed the execute permission, e.g. to
enable the script after modifying it, the execute permission is
not restored to the default one.

The execute permission is part of the file, thus should be propagated
like the contents.

The current behavior is an issue since a script may be disabled
by default because it could be incorrect until the user has
adapted it for his own usage. And the message like

  Installing new version of config file /etc/resolvconf/update.d/unbound ...

(letting the user think that the conffile is reverted to the default,
without informing him that the execute bit is not copied) is
misleading.

An alternative solution would be a 5th option, splitting the

Y or I  : install the package maintainer's version

choice, when there is a difference for the execute permission.

-- Package-specific info:

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-5
ii  libc62.33-7
ii  liblzma5 5.2.5-2.1
ii  libselinux1  3.3-1+b2
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-4

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.4.5
pn  debsig-verify  

-- no debconf information

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

Bug#1009912: RM: ruby-clean-test, ruby-gli -- ROM; abandoned upstream

[duck]

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


Quack,

On behalf of the Ruby Team, please remove these two packages which are 
dead

upstream: respectively archived since 2020 and upstream site vanished.

ruby-gli is the only rdepends of ruby-clean-test and itself has none.

If they are not broken yet they probably will with the new version of
ruby-faker we plan to upload. They have 0 popcon.

Regards.
\_o<

--
Marc Dequènes

Bug#947399: marked as pending in yuzu

[Bastian Germann]

Control: tags -1 - pending

Bug#1009398: rnetclient: FTBFS: dh_auto_test: error: make -j8 check VERBOSE=1 returned exit code 2

[Thadeu Lima de Souza Cascardo]

Package: rnetclient
Version: 2017.1-1+b2
Followup-For: Bug #1009398

This is caused by libgcrypt working under FIPS mode by default, unless
its global_init has been called. That requires gcry_check_version to be
called, as one of the possibilities.

Here is an attached debpatch.


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

Kernel: Linux 5.10.0-11-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rnetclient depends on:
ii  libc62.33-7
ii  libgcrypt20  1.10.1-2
ii  libgnutls30  3.7.4-2
ii  zlib1g   1:1.2.11.dfsg-4

rnetclient recommends no packages.

rnetclient suggests no packages.

-- no debconf information
Index: rnetclient-2017.1/decfile.c
===
--- rnetclient-2017.1.orig/decfile.c
+++ rnetclient-2017.1/decfile.c
@@ -489,6 +489,7 @@ char * rnet_decfile_get_file_hash(struct
 {
char *hash;
size_t len;
+   gcry_check_version(NULL);
if (gcry_md_test_algo(GCRY_MD_MD5))
return NULL;
len = gcry_md_get_algo_dlen(GCRY_MD_MD5);

Bug#1008870: [Pkg-electronics-devel] Bug#1008870: openocd: segfault when using stm32f1x config

[Matsievskiy S.V.]

I guess the problem was with some underlying library. I had openocd
segfault on two machines (both on testing) and now everything works.
I've also openocd from 0.11.0-1 source and it works too.

The issue may be closed now.

-- 
Best regards,
Sergey Matsievskiy
> 


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

Bug#1009773: matrix-synapse: updating the package rewrites /etc/matrix-synapse/conf.d/server_name.yaml with wrong domain name

[Hubert Chathi]

On Sun, 17 Apr 2022 10:16:59 +0200, Alessandro Polverini  
said:

> The installer on every update rewrites the content of the file
> /etc/matrix-synapse/conf.d/server_name.yaml setting server_name with
> the host name of the server it's running.

That's not correct.  It sets server_name to the value set in debconf.
To change it, run "dpkg-reconfigure matrix-synapse" as root.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#1009891: hexchat locks up hard when connecting to bip server

[Steven Rostedt]

On Wed, 20 Apr 2022 09:43:56 -0400
Steven Rostedt  wrote:

> I am running the latest 5.17.3 (vanilla stable kernel build, with no
> modifications) on my workstation, and a 5.15 debian kernel on my laptop.
> That shouldn't affect anything, but you never know. I can reboot my
> workstation to an older kernel and see if that makes any difference.

I rebooted to a 5.10 Debian kernel and it still has the same lockup.
Strange that it works on my laptop but not my workstation.

Oh, and xchat can connect to the bip proxy without issue. As a workaround,
I'm currently just using xchat on my workstation instead of hexchat.

-- Steve

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Matthew Vernon]

Hi,

I hereby call for a vote on the following ballot. Unless a TC member 
objects to calling for a vote, voting lasts for a week, or until the 
result is no longer in doubt.


===Rationale

There are two "rename" programs - the perl rename, and the util-linux 
rename. Debian and its derivatives have shipped the perl rename as 
/usr/bin/rename, whilst other distributions (e.g. Fedora) have shipped 
the util-linux rename thus. The two implementations are incompatible. 
Users might reasonably desire both implementations to be available on 
the same system; they are designed to meet different needs.


Backwards-compatibility (and the lack of a compelling argument that 
rename from util-linux should replace perl rename) means that 
/usr/bin/rename in Debian should remain the perl rename.


Prior to bullseye, util-linux's rename was shipped as 
/usr/bin/rename.ul; Debian's users who wish to use util-linux's rename 
will expect it to be in this location.


===End Rationale

===Begin Resolution A
The Technical Committee overrides the util-linux maintainer, and 
requires that util-linux's rename should be shipped as 
/usr/bin/rename.ul in a binary package built from src:util-linux. The 
package containing rename.ul must not conflict with the rename package 
nor divert /usr/bin/rename.

===End Resolution A

===Begin Resolution B
The Technical Committee overrides the util-linux maintainer, and 
requires that util-linux's rename should be shipped in a binary package 
built from src:util-linux. If this package Conflicts with the rename 
package, then it must not contain any other binaries.

===End Resolution B

===Begin Resolution N
None of the above
===End Resolution N

I vote A > B > N

Regards,

Matthew


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008870: [Pkg-electronics-devel] Bug#1008870: openocd: segfault when using stm32f1x config

[Matsievskiy S.V.]

I used RISCV's fork https://github.com/riscv-mcu/riscv-openocd.

-- 
Best regards,
Sergey Matsievskiy


On Wed, 2022-04-20 at 09:42 +0100, Jonathan McDowell wrote:
> On Sun, Apr 03, 2022 at 12:26:05PM +0300, Matsievskiy S.V. wrote:
> > Package: openocd
> > Version: 0.11.0-1
> > Severity: important
> > X-Debbugs-Cc: seregaxvm.m...@gmail.com
> > 
> > Dear Maintainer,
> > 
> > OpenOCD segfaults when using target/stm32f1x.cfg configuration. I
> > do not
> > experience this issue with newer version built from source (Open
> > On-Chip
> > Debugger 0.11.0+dev-02226-gf6ffede8b).
> > 
> > dmesg entry:
> > [ 7388.531636] openocd[36055]: segfault at 14 ip 7f64e097b12d
> > sp
> > 7ffdde27a090 error 4 in libusb-1.0.so.0.3.0[7f64e0974000+f000]
> > 
> > Way to reproduce:
> > 1. Connect STLinkV2
> > 2. Run command openocd -f openocd.cfg (file is attached)
> 
> I don't have STLinkV2 hardware so am unable to reproduce. Can you
> confirm the upstream git version you're using - I don't see
> "f6ffede8b"
> in the usptream git tree.
> 
> Also, if you're able to, can you try recompiling the 0.11.0 Debian
> package on your system just to narrow down that it's a fix upstream
> we're looking for rather than a build issue? I *think* it's going to
> be
> cff0e417da58adef1ceef9a63a99412c2cc87ff3 that's the issue, which
> means
> the problem won't exist in bullseye (libusb-1.0 is at 1.0.24).
> 
> J.
> 


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

Bug#1009911: RM: elog -- ROM; No active maintainership, insecure version in Debian

[Roger Kalt]

Package:ftp.debian.org
Severity: normal

I think elog should be removed from Debian. There are several open CVEs
for the elog package in Debian. These are resolved in the most recent
upstream version of elog.
But since there is no active maintainership, it is better to remove the
outdated and insecure version of elog from Debian.

Bug#1009903: unbound: /etc/resolvconf/update.d/unbound is enabled by default after upgrade

[Michael Tokarev]

20.04.2022 16:18, Vincent Lefevre wrote:

On 2022-04-20 15:27:16 +0300, Michael Tokarev wrote:

..

This is exactly what dpkg does: it preserves local permission
changes for conffilies, even if you tell it to replace your locally-
modified conffile with a new conffile coming from the updated
package.


Where is this documented (in the case a new conffile is installed)?


I've no idea Vincent.  I just looked at what it does, -- it copies
permissions and ownership from current conffile to new.

Thinking about it I expect the same behavior, to preserve whatever
local permission changes are made.  In this case: if you already
had this file enabled for resolvconf, the new version stays enabled
too.

You may ask dpkg people about this.  I don't really care if it is
documented or not.

/mjt

Bug#1009891: hexchat locks up hard when connecting to bip server

[Steven Rostedt]

On Wed, 20 Apr 2022 14:05:23 +0900
Marc Dequènes (duck)  wrote:

> Quack Seven,
> 
> I'm involved with bip packaging and upstream and we wondered what 
> version of bip you are using. Did you upgrade bip recently?

Actually I did. I updated both my server with bip and my workstation with
hexchat at the same time.

> We have yet no reason to think that it could be triggered by a bug in 
> bip, just checking. Clearly hexchat should behave better anyway.
> 
> Can you reproduce this problem by connecting directly to the IRC server?

No, the problem does not exist when connecting directly to my bip server.

I just tested on my laptop which also has hexchat 2.16 (same version), and
it connects to my server's bip proxy just fine.

I am running the latest 5.17.3 (vanilla stable kernel build, with no
modifications) on my workstation, and a 5.15 debian kernel on my laptop.
That shouldn't affect anything, but you never know. I can reboot my
workstation to an older kernel and see if that makes any difference.

-- Steve

Bug#1009910: libnss-gw-name: Outdated VCS information, maybe move to salsa.d.o?

[Gioele Barabucci]

Source: libnss-gw-name
Version: 0.3-3

Dear Debian QA group, maintainers of libnss-gw-name,

the current VCS information stored in the `debian/control` is outdated 
(see https://tracker.debian.org/pkg/libnss-gw-name). The host 
git.nomeata.de is no longer available.


The upstream author has a Git mirror (that includes a `debian/` 
directory) at


https://github.com/nomeata/libnss-gw-name

Could you please mirror that Git repo on salsa.debian.org and update the 
VCS fields in the `debian/control`?


(Alternatively the package could be dropped altogether. The author of 
libnss-gw-name does not plan on maintaining the upstream project.)


Regards,

--
Gioele Barabucci

Bug#980921: Pages in HTML5

[Laura Arjona Reina]

Hi all
I have added a basic5.wml and template5.wml templates in
/english/templates/debian to start using them in the files that already have
HTML5 tags.

https://salsa.debian.org/webmaster-team/webwml/-/commit/8dc031327d5b4147c02030aac97866283094286d

I have changed mainpage.wml to use the new templates (mainpage.wml is only used
in the homepage).

https://salsa.debian.org/webmaster-team/webwml/-/commit/a10f9519aee4f29278a7c597da8071cd42f9df97


I have updated the recent_list.wml template so the datetime values are produced
in correct format.

https://salsa.debian.org/webmaster-team/webwml/-/commit/2597b5a9d1a8517d803da5ed03b87ac8cf24a11e

I have checked my tests with the homepage with https://validator.w3.org/ and
looks fine.

I'll try to have a look at the validation script and move other pages to use
these html5 templates, and fix the issues that arise.

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

Bug#1009903: unbound: /etc/resolvconf/update.d/unbound is enabled by default after upgrade

[Vincent Lefevre]

On 2022-04-20 15:27:16 +0300, Michael Tokarev wrote:
> 20.04.2022 15:16, Michael Tokarev wrote:
> > > A possible cause might be that unbound is confused by the old status
> > > of this script (i.e. if it was set to be executable in the past)
> > > during the copy of the package maintainer's version.
> 
> This is exactly what dpkg does: it preserves local permission
> changes for conffilies, even if you tell it to replace your locally-
> modified conffile with a new conffile coming from the updated
> package.

Where is this documented (in the case a new conffile is installed)?

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

Bug#1009907: Smbclient error: "Failed to mount Window share: invalid argument"

[Salis, Antonello (NFOD)]

Package: smbclient
  Version: 2:4.16.0+dfsg-6

Debian testing

   When I try to browse Windows folders with Nautilus or Nemo i get "Failed to 
mount Window share: invalid argument".
This never happened before last week.
Found a similar topic here: https://bbs.archlinux.org/viewtopic.php?id=275179

Bug#1009906: haproxy: HTTPS proxyfied requests randomly delayed by 50 seconds (default timeout server)

[Ludovic Pouzenc]

Package: haproxy
Version: 2.2.9-2+deb11u3
Severity: important
X-Debbugs-Cc: bugrepo...@pouzenc.fr

Dear Maintainer,

We have a (Wordpress) PHP web-site hosted on 3 LAMP nodes. We use haproxy to 
load-balance the incomming web trafic.
We've got 240k lines of apache2 access log yesterday.

The problem can be reproduced with a test infra without any concurrent user
 and a basic test.php thats readfile("jquery.min.js")
 and a basic index.html referencing multiple (24) times the test.php
 to have Firefox starting multiple HTTP requests in parallel.

The problem is hard or impossible to trigger with Firefox with http2 enabled.
The problem is easy to reproduce with firefox forced in http/1.1 mode.
The problem doesn't show with a echo "Hello World" in test.php,
 it seems that the response size is important. 30kio is enough to trigger it 
for sure.

Out of 25 requests (including GET /), Firefox will get results about 20 of 
them, and about 4 will be delayed by a huge amount of 50 seconds.
(50 seconds if haproxy have : default timeout server 5).

I tried nbproc 1 and nbthreads 1 with no improvements.
I tried haproxy 2.4.15-1~bpo11+1 and it DOES fix the situation without changing 
anything else.

  # apt install -t bullseye-backports haproxy

I didn't find any bugreports mentionning major troubles in "basic" usage of 
haproxy.
I post it here to get someone else luck with Googling about the troubles I hit.

I can't find exactly what line in haproxy changelog could correspond to this.
I think I can try, if useful, to find the smallest configuration that breaks.
PHP seems unrelated. Direct access to the apache don't show up any trouble.

It may be broken in Ubuntu 21.04 (hirsute) and Ubuntu 21.10 (impish) also.

Thanks for all the fish,
Ludovic

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

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

Versions of packages haproxy depends on:
ii  adduser  3.118
ii  dpkg 1.20.9
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u3
ii  libcrypt11:4.4.18-4
ii  libgcc-s110.2.1-6
ii  liblua5.3-0  5.3.3-1.1+b1
ii  libpcre2-8-0 10.36-2
ii  libssl1.11.1.1n-0+deb11u1
ii  libsystemd0  247.3-7
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2+deb11u1

haproxy recommends no packages.

Versions of packages haproxy suggests:
pn  haproxy-doc  
pn  vim-haproxy  

-- Configuration Files:
/etc/haproxy/haproxy.cfg changed:
global
log /dev/loglocal0
log /dev/loglocal1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd 
listeners
stats timeout 30s
user haproxy
group haproxy
daemon
# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
# See: 
https://ssl-config.mozilla.org/#server=haproxy=2.0.3=intermediate
ssl-default-bind-ciphers 
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites 
TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
defaults
log global
modehttp
option  httplog
option  dontlognull
timeout connect 5000
timeout client  5
timeout server  5
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
frontend http
bind *:80
mode http
# redirects to https
redirect scheme https if !{ ssl_fc }
default_backend http
frontend https
bind *:443 ssl crt /etc/haproxy/certs/ alpn h2,http/1.1
mode http
# [some acl with our IPs stripped here]
   default_backend http
backend http
balance roundrobin
# ensures the forwarded request includes the actual client IP address
option forwardfor
#defines the check HAProxy uses to test if a web server is still valid for 
forwarding requests
option httpchk
http-check send meth GET uri /
# use cookies for sticky sessions
cookie SRVNAME insert indirect nocache
server www1 192.168.120.41:443 cookie s1 check ssl 

Bug#1009466: openlp: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13

[Bastian Germann]

Control: tags -1 upstream patch

This was already handled with 
https://gitlab.com/openlp/openlp/-/commit/54ad75426825cdd977f770b12a62ee92218b82d6
and will be included with the next release.

Bug#1008973: linux-image-amd64: Very slow wireless with MEDIATEK 7961

[Julien Negros]

Hi Vincent,

Not sure I installed the right one 
(https://packages.debian.org/sid/linux-image-5.17.0-1-amd64-unsigned) 
but I couldn't find another.


Same issue for me, I even fell like it's worse :/

Le 19/04/2022 à 15:53, Vincent Blut a écrit :

Control: tags -1 moreinfo

Hi,

Le 2022-04-05 14:39, Xavier Chantry a écrit :

Package: linux-image-amd64
Version: 5.10.84-1
Severity: important
X-Debbugs-Cc: chantry.xav...@gmail.com

Dear Maintainer,

We have a problem with MEDIATEK 7961 wireless on Levono P14s with AMD
Ryzen.

With 5.10 kernel on debian stable the wireless just does not work, so we
installed kernel 5.16 from testing.

With kernel 5.16 the wireless is so slow that it's unusable, each
internet query takes several seconds. A simple ping to google.com varies
from 100ms to 3000ms.

With kernel 5.17 it's slighly better but the ping still goes up to
600ms.

With kernel 5.15 however, it works quite good, Internet is very usable,
ping varies from 3ms to 30ms.
(on the same network, the P14s with Intel wireless does better and is
always under 10ms).

It looks like big changes were made to the mt7921e driver in 5.16
according to Phoronix :
The Mediatek MT7921 WiFi driver has added support for 6GHz WiFi, active
state power management (ASPM), and other improvements.

And it looks like this caused a big regression with MEDIATEK 7961.

Besides the network performance problem on 5.16, suspend/resume is also
broken, while it works perfectly on 5.15.


Le 2022-04-06 10:19, Christoph Martin a écrit :

I have the same Problem with an P14s and Mediathek 7921e.
There is even about 30% package loss.

Christoph

Am 05.04.22 um 14:39 schrieb Xavier Chantry:


With kernel 5.16 the wireless is so slow that it's unusable, each
internet query takes several seconds. A simple ping to google.com varies
from 100ms to 3000ms.

With kernel 5.17 it's slighly better but the ping still goes up to
600ms.


Le 2022-04-15 14:19, Julien Negros a écrit :

Hi,

Same issue here, switching to linux-image-5.15.0-0.bpo.3-amd64 did the
trick. Hope the next kernel version fixes this problem !

Cheers
--
Julien Négros
  
Linux 5.17.3 (uploaded to unstable earlier today) includes a lot of fixes for

Mediatek WLAN devices. Could you please check if that kernel fixes the slowness
you are seeing?

Cheers,
Vincent


--
Julien Négros

Administrateur Système

01 81 80 23 80 / 580


Logo Enercoop

CETTE ANNÉE
Suivez-nous sur le chemin de la sobriété énergétique
Découvrez notre bwatt à outils ici
,pour faire des économies
d'énergie !

Bug#1009905: openjdk-18-jre-headless installation fails with dependency problems

[Martin Schröder]

Package: openjdk-18-jre-headless
Version: 18~36ea-1

I am trying to create a docker image based on sid-slim
with openjdk-18-jre-headless. This fails with

Setting up ca-certificates-java (20190909) ...
head: cannot open '/etc/ssl/certs/java/cacerts' for reading: No such
file or directory
/var/lib/dpkg/info/ca-certificates-java.postinst: line 101: java:
command not found
dpkg: error processing package ca-certificates-java (--configure):
installed ca-certificates-java package post-installation script
subprocess returned error exit status 127
dpkg: dependency problems prevent configuration of
openjdk-18-jre-headless:amd64:
openjdk-18-jre-headless:amd64 depends on ca-certificates-java (>=
20190405~); however:
 Package ca-certificates-java is not configured yet.

dpkg: error processing package openjdk-18-jre-headless:amd64 (--configure):
dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.33-7) ...
Processing triggers for ca-certificates (20211016) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

/etc/ca-certificates/update.d/jks-keystore: 82: java: not found
E: /etc/ca-certificates/update.d/jks-keystore exited with code 1.
done.
Processing triggers for sgml-base (1.30) ...
Setting up libfontconfig1:amd64 (2.13.1-4.4) ...
Processing triggers for libc-bin (2.33-7) ...
Errors were encountered while processing:
ca-certificates-java
openjdk-18-jre-headless:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#1009903: unbound: /etc/resolvconf/update.d/unbound is enabled by default after upgrade

[Michael Tokarev]

Control: severity -1 normal
Control: tag -1 + moreinfo

20.04.2022 14:11, Vincent Lefevre wrote:

Package: unbound
Version: 1.15.0-3
Severity: important

In the upgrade to unbound 1.15.0-3, I chose to replace the script
to the default one (following the recent discussions, I intend to
revert to the default status):

Configuration file '/etc/resolvconf/update.d/unbound'
  ==> Modified (by you or by a script) since installation.
  ==> Package distributor has shipped an updated version.
What would you like to do about it ?  Your options are:
 Y or I  : install the package maintainer's version
 N or O  : keep your currently-installed version
   D : show the differences between the versions
   Z : start a shell to examine the situation
  The default action is to keep your current version.
*** unbound (Y/I/N/O/D/Z) [default=N] ? Y
Installing new version of config file /etc/resolvconf/update.d/unbound ...
Installing new version of config file /etc/unbound/unbound.conf ...
Setting up libunbound8:amd64 (1.15.0-3) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for libc-bin (2.33-7) ...

but contrary to what is said, the script is enabled by default:

-rwxr-xr-x 1 root root 1327 2022-04-19 12:54:02 /etc/resolvconf/update.d/unbound


The .deb file in debian has this file with permissions 0644. You can
see it in the build log file -- eg
https://buildd.debian.org/status/fetch.php?pkg=unbound=amd64=1.15.0-3=1650407026=0

which has this when displaying contents of the files:

-rw-r--r-- root/root  1327 2022-04-19 10:54 
./etc/resolvconf/update.d/unbound

so it comes exactly as it should, there's nothing do do there.


A possible cause might be that unbound is confused by the old status
of this script (i.e. if it was set to be executable in the past)
during the copy of the package maintainer's version.


That's a possibility, tho unbound here can not be confused, as
it does not handle conffiles. Dpkg does that.

What WAS the permissions of this file on your system before
the upgrade - was it executable (enabled) before or not?

Thanks,

/mjt

Bug#1007901: Bug#1007899: network-manager: L2TP-VPN doesn't work with network-manager version 1.36.2-1 (works with 1.34.0-1)

[Douglas Kosovic]

Hi Marcel ,

I was about to close this still open bug (which was cloned from a bug that was 
closed), but decided to check the forum link you posted first :
https://debianforum.de/forum/viewtopic.php?t=183809

and noticed you said there you were still having an issue with 
network-manager-l2tp and network-manager 1.36.4-2.

Sorry to hear that network-manager 1.36.4-2 didn't solve your issue and wish I 
heard it here earlier. Unfortunately I'm not able to reproduce the bug with 
Debian Sid, but happy to look into it.

I suspect it is an issue with strongswan, do you have the issue if you switch 
to libreswan? e.g. :

   sudo apt install libreswan


To revert back to strongswan, issue:

   sudo apt install strongswan


If it works with libreswan, I suspect the strongswan issue with network-manager 
version 1.36 is with one of its modules.




Cheers,
Doug

Bug#1009903: unbound: /etc/resolvconf/update.d/unbound is enabled by default after upgrade

[Vincent Lefevre]

Package: unbound
Version: 1.15.0-3
Severity: important

In the upgrade to unbound 1.15.0-3, I chose to replace the script
to the default one (following the recent discussions, I intend to
revert to the default status):

Configuration file '/etc/resolvconf/update.d/unbound'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** unbound (Y/I/N/O/D/Z) [default=N] ? Y
Installing new version of config file /etc/resolvconf/update.d/unbound ...
Installing new version of config file /etc/unbound/unbound.conf ...
Setting up libunbound8:amd64 (1.15.0-3) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for libc-bin (2.33-7) ...

but contrary to what is said, the script is enabled by default:

-rwxr-xr-x 1 root root 1327 2022-04-19 12:54:02 /etc/resolvconf/update.d/unbound

A possible cause might be that unbound is confused by the old status
of this script (i.e. if it was set to be executable in the past)
during the copy of the package maintainer's version.

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

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

Versions of packages unbound depends on:
ii  adduser  3.121
ii  init-system-helpers  1.62
ii  libc62.33-7
ii  libevent-2.1-7   2.1.12-stable-5
ii  libnghttp2-141.43.0-1
ii  libprotobuf-c1   1.3.3-1+b2
ii  libpython3.103.10.4-3
ii  libssl1.11.1.1n-1
ii  libsystemd0  250.4-1
ii  lsb-base 11.1.0

Versions of packages unbound recommends:
ii  dns-root-data  2021011101
ii  openssl1.1.1n-1

Versions of packages unbound suggests:
ii  apparmor  3.0.4-2

-- no debconf information

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

Bug#973471: look has unpredictable behavior

[Yair Yarom]

Package: util-linux
Version: 2.36.1-8+deb11u1
Followup-For: Bug #973471

Hello,

The issue is that currently "look" is broken on debian/bullseye. I don't know
whether this package needs to be updated or the dictionary package(s).

Attached is a patch that removes the default -d and -f when no dictionary file
is given, which seems to mitigate this issue.

Regards,
Yair.

-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (990, 'stable'), (910, 'stable-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.104-aufs-3 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_IL.UTF-8, LC_CTYPE=en_IL.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB:en
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages util-linux depends on:
ii  libaudit1  1:3.0-2
ii  libblkid1  2.36.1-8+deb11u1
ii  libc6  2.31-13+deb11u3
ii  libcap-ng0 0.7.9-2.2+b1
ii  libcrypt1  1:4.4.18-4
ii  libmount1  2.36.1-8+deb11u1
ii  libpam0g   1.4.0-9+deb11u1
ii  libselinux13.1-3
ii  libsmartcols1  2.36.1-8+deb11u1
ii  libsystemd0247.3-7
ii  libtinfo6  6.2+20201114-2
ii  libudev1   247.3-7
ii  libuuid1   2.36.1-8+deb11u1
ii  login  1:4.8.1-1
ii  zlib1g 1:1.2.11.dfsg-2

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
ii  kbd 2.3.0-3
pn  util-linux-locales  

-- Configuration Files:
/etc/pam.d/runuser [Errno 2] No such file or directory: '/etc/pam.d/runuser'
/etc/pam.d/runuser-l [Errno 2] No such file or directory: '/etc/pam.d/runuser-l'
/etc/pam.d/su changed [not included]
/etc/pam.d/su-l changed [not included]

-- no debconf information
--- a/misc-utils/look.1
+++ b/misc-utils/look.1
@@ -69,15 +69,13 @@
 .TP
 .BR \-d , " \-\-alphanum"
 Use normal dictionary character set and order, i.e., only blanks and
-alphanumeric characters are compared.  This is on by default if no file is
-specified.
+alphanumeric characters are compared.
 
 Note that blanks have been added to dictionary character set for
 compatibility with \fBsort \-d\fR command since version 2.28.
 .TP
 .BR \-f , " \-\-ignore\-case"
-Ignore the case of alphabetic characters.  This is on by default if no file is
-specified.
+Ignore the case of alphabetic characters.
 .TP
 .BR \-t , " \-\-terminate " \fIcharacter\fR
 Specify a string termination character, i.e., only the characters
--- a/misc-utils/look.c
+++ b/misc-utils/look.c
@@ -141,8 +141,8 @@
string = *argv++;
file = *argv;
break;
-   case 1: /* But set -df by default. */
-   dflag = fflag = 1;
+   case 1: /* But set -df by default (except on 
debian) */
+   //dflag = fflag = 1;
string = *argv;
break;
default:

Bug#1009902: ITP: pyqt6-webengine -- Python bindings for the Qt WebEngine framework

[Dmitry Shachnev]

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

* Package name: pyqt6-webengine
  Version : 6.3.0
  Upstream Author : Riverbank Computing Limited 
* URL : https://riverbankcomputing.com/software/pyqtwebengine/intro
* License : GPL
  Programming Lang: SIP
  Description : Python bindings for the Qt WebEngine framework

PyQt6-WebEngine is a set of Python bindings for The Qt Company’s Qt WebEngine
framework. The framework provides the ability to embed web content in
applications and is based on the Chrome browser. The bindings sit on top of
PyQt6 and are implemented as three separate modules corresponding to the
different libraries that make up the framework.

I am going to maintain it in the Debian Python Team, like pyqt5webengine.
Packaging will be here:

https://salsa.debian.org/python-team/packages/pyqt6-webengine/

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1009901: Update php-league-flysystem to newer version

[Katharina Drexel]

Package: php-league-flysystem
Version: 1.1.3-4
Severity: normal

Hello,

for building a newer php-laravel-framework I need a more recent 
php-league-flysystem (>=3 instead of 1.X).
For being able to continue I built one from 3.0.17 (following salsa repo):
  https://github.com/sunflowerbofh/flysystem/tree/debian

If that (or a corrected version) could go to unstable I would be very pleased. 
I can also provide a .dsc file if needed.

Thanks+Regards
Katharina

-- 

Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm

[Neil Williams]

Source: fis-gtm
Version: 6.3-014-3
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerabilities were published for fis-gtm.

CVE-2021-44492[0]:
| An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS
| GT.M through V7.0-000. Using crafted input, attackers can cause a type
| to be incorrectly initialized in the function f_incr in
| sr_port/f_incr.c and cause a crash due to a NULL pointer dereference.


CVE-2021-44493[1]:
| An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS
| GT.M through V7.0-000. Using crafted input, an attacker can cause a
| call to $Extract to force an signed integer holding the size of a
| buffer to take on a large negative number, which is then used as the
| length of a memcpy call that occurs on the stack, causing a buffer
| overflow.


CVE-2021-44494[2]:
| An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS
| GT.M through V7.0-000. Using crafted input, an attacker can cause
| calls to ZRead to crash due to a NULL pointer dereference.


CVE-2021-44495[3]:
| An issue was discovered in YottaDB through r1.32 and V7.0-000 and FIS
| GT.M through V7.0-000. Using crafted input, an attacker can cause a
| NULL pointer dereference after calls to ZPrint.


CVE-2021-44496[4]:
| An issue was discovered in FIS GT.M through V7.0-000 (related to the
| YottaDB code base). Using crafted input, an attacker can control the
| size variable and buffer that is passed to a call to memcpy. An
| attacker can use this to overwrite key data structures and gain
| control of the flow of execution.


CVE-2021-44497[5]:
| An issue was discovered in FIS GT.M through V7.0-000 (related to the
| YottaDB code base). Using crafted input, can cause the bounds of a for
| loop to be miscalculated, which leads to a use after free condition a
| pointer is pushed into previously free memory by the loop.


CVE-2021-44498[6]:
| An issue was discovered in FIS GT.M through V7.0-000 (related to the
| YottaDB code base). Using crafted input, attackers can cause a type to
| be incorrectly initialized in the function f_incr in sr_port/f_incr.c
| and cause a crash due to a NULL pointer dereference.


CVE-2021-44499[7]:
| An issue was discovered in FIS GT.M through V7.0-000 (related to the
| YottaDB code base). Using crafted input, an attacker can cause a call
| to $Extract to force an signed integer holding the size of a buffer to
| take on a large negative number, which is then used as the length of a
| memcpy call that occurs on the stack, causing a buffer overflow.


CVE-2021-44500[8]:
| An issue was discovered in FIS GT.M through V7.0-000 (related to the
| YottaDB code base). A lack of input validation in calls to eb_div in
| sr_port/eb_muldiv.c allows attackers to crash the application by
| performing a divide by zero.


CVE-2021-44501[9]:
| An issue was discovered in FIS GT.M through V7.0-000 (related to the
| YottaDB code base). Using crafted input, an attacker can cause calls
| to ZRead to crash due to a NULL pointer dereference.


CVE-2021-44502[10]:
| An issue was discovered in FIS GT.M through V7.0-000 (related to the
| YottaDB code base). Using crafted input, an attacker can control the
| size of a memset that occurs in calls to util_format in
| sr_unix/util_output.c.


CVE-2021-44503[11]:
| An issue was discovered in FIS GT.M through V7.0-000 (related to the
| YottaDB code base). Using crafted input, an attacker can cause a call
| to va_arg on an empty variadic parameter list, most likely causing a
| memory segmentation fault.


CVE-2021-44504[12]:
| An issue was discovered in FIS GT.M through V7.0-000 (related to the
| YottaDB code base). Using crafted input, an attacker can cause a size
| variable, stored as an signed int, to equal an extremely large value,
| which is interpreted as a negative value during a check. This value is
| then used in a memcpy call on the stack, causing a memory segmentation
| fault.


CVE-2021-44505[13]:
| An issue was discovered in FIS GT.M through V7.0-000 (related to the
| YottaDB code base). Using crafted input, an attacker can cause a NULL
| pointer dereference after calls to ZPrint.


CVE-2021-44506[14]:
| An issue was discovered in FIS GT.M through V7.0-000 (related to the
| YottaDB code base). A lack of input validation in calls to do_verify
| in sr_unix/do_verify.c allows attackers to attempt to jump to a NULL
| pointer by corrupting a function pointer.


CVE-2021-44507[15]:
| An issue was discovered in FIS GT.M through V7.0-000 (related to the
| YottaDB code base). A lack of parameter validation in calls to memcpy
| in str_tok in sr_unix/ztimeoutroutines.c allows attackers to attempt
| to read from a NULL pointer.


CVE-2021-44508[16]:
| An issue was discovered in FIS GT.M through V7.0-000 (related to the
| YottaDB code base). A lack of NULL checks in calls to ious_open in
| sr_unix/ious_open.c allows attackers to crash the application by
| dereferencing a NULL 

Bug#1009865: transition: octave

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/octave-7.1.html

On 2022-04-19 15:57:14 +0200, Sébastien Villemot wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-oct...@lists.debian.org
> 
> Dear Release Team,
> 
> Please schedule a transition for octave. The new major upstream release
> (7.1.0), currently in experimental, changes the ABI. 
> 
> Reverse dependencies have been rebuilt against the new version, and bugs 
> filed:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=octave7;users=debian-oct...@lists.debian.org
> 
> Most of them are now fixed. Only three are left, one of which concerning a
> package not in testing (octave-tisean), and the other two concerning leaf
> packages for which there is no obvious fix, and that could temporarily be
> removed from testing.

Please go ahead

Cheers

> 
> Ben file:
> 
> title = "octave";
> is_affected = .depends ~ "octave-abi-56" | .depends ~ "octave-abi-57";
> is_good = .depends ~ "octave-abi-57";
> is_bad = .depends ~ "octave-abi-56";
> 
> Cheers,
> 
> --
> ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
> ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
> ⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
> ⠈⠳⣄  https://www.debian.org

-- 
Sebastian Ramacher

Bug#1009888: [Pkg-rust-maintainers] Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package

[Fabian Grünbichler]

On April 20, 2022 12:33 am, Peter Michael Green wrote:
> Package: rust-h2
> Version: 0.1.26-1
> X-debbugs-cc: d...@jones.dk
> 
> I noticed that Jonas had set a number of bugs about broken rust packages as
> blockers of 900928, so I decided to take a look at some of them. I fixed up
> bytemuck, image and related packages.
> 
> I then started looking at reqwest which lead me to h2 (which has been broken
> since the tokio 1.x transition but noone ever got around to filing a 
> bug) which
> lead me to http which jonas recently NMU'd.
> 
> I feel I need to comment on the technical details of the NMU, I should 
> preface
> this by saying that I don't think it's unreasonable to 0-day NMU a minimal
> fix for a long term RC issue, even if (as was not the case here but was the
> case for some of the other NMUs noone ever bothered to actually file the
> RC bug).
> 
> However, this NMU did considerably more than just add a minimal fix for
> the rc issue. Most painfullly, the "orig" tarball for the new upstream 
> version
> appears to have been derived from upstream git rather than from crates.io
> and this breaks our workflow. If you are going to 0-day stuff please keep
> your uploads minimal. If you want to do more invasive NMUs please give
> the maintainers a chance to respond.
> 
> Fortunately it seems the answer is to move to an even newer upstream
> version. The only reverse dependencies of rust-http seem to be the
> h2/hyper stack which badly needs an update to move away from tokio
> 0.x. I have already committed the http update to debcargo-conf and may
> upload it at some point.
> 
> Unfortunately moving back up the stack I ran into another issue. h2 and
> hyper have grown a new dependency on tracing. While I am I am happy to
> help with fixing existing rust packages, I am reluctant to take 
> responsibility
> for a new package unless it's something I personally use.
> 
> So this is where I personally tap out on h2/hyper until/unless someone
> packages tracing.

we use this stack (h2/hyper) downstream, I can take care of it over the 
coming weeks. tracing is unfortunately still rather in-flux, so it will 
likely see frequent upgrades.

Bug#1009899: ITP: genimage -- The Image Creation Tool

[Sudip Mukherjee]

Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 
X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com

* Package name: genimage
  Version : v15
  Upstream Author : many
* URL : https://github.com/pengutronix/genimage
* License : GPL-2.0
  Programming Lang: C
  Description : The Image Creation Tool

genimage is a tool to generate multiple filesystem and flash/disk
images from a given root filesystem tree. It also supports creating
flash/disk images out of different file-system images and files.

I am using it as part of my current project in $dayjob. Its a
necessary tool to create images with u-boot.
I can maintain it.


--
Regards
Sudip

Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package

[Jonas Smedegaard]

Quoting Peter Michael Green (2022-04-20 00:33:07)
> I noticed that Jonas had set a number of bugs about broken rust 
> packages as blockers of 900928, so I decided to take a look at some of 
> them. I fixed up bytemuck, image and related packages.

Thanks, much appreciated.


> I feel I need to comment on the technical details of the NMU, I should 
> preface this by saying that I don't think it's unreasonable to 0-day 
> NMU a minimal fix for a long term RC issue, even if (as was not the 
> case here but was the case for some of the other NMUs noone ever 
> bothered to actually file the RC bug).
> 
> However, this NMU did considerably more than just add a minimal fix 
> for the rc issue. Most painfullly, the "orig" tarball for the new 
> upstream version appears to have been derived from upstream git rather 
> than from crates.io and this breaks our workflow. If you are going to 
> 0-day stuff please keep your uploads minimal. If you want to do more 
> invasive NMUs please give the maintainers a chance to respond.

Thanks for elaborating on the kinds of pain my NMU caused.  That is 
helpful.

(In hindsight I could have made a smaller non-problematic NMU by fixing 
only the FTBFS issue, ignoring the security issue)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1009269: Should sphinx-patchqueue be removed?

[Dmitry Smirnov]

On Monday, 11 April 2022 4:28:40 AM AEST Moritz Muehlenhoff wrote:
> Source: sphinx-patchqueue
> Version: 0.5.0-2
> Severity: serious
> 
> Your package came up as a candidate for removal from Debian:
> 
> - Still depends on Python 2 and thus removed from testing since 2019
> - No remaining reverse dependencies
> - Last upload in 2015

Yes, it would be great to remove the package please.
It should be trivial to update it for Python3 but I could never get to
do that due to lack of time. The package was originally introduced as a
dependency for something and I can't even remember what was that...

IMHO safe to remove. Thanks.

-- 
Cheers,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Frederick Douglass, a former slave, witnessed and described that exact
phenomenon among his fellow slaves, many of whom were proud of how hard
they worked for their masters and how faithfully they did as they were
told. From their perspective, a runaway slave was a shameful thief,
having "stolen" himself from the master.
 -- Larken Rose, The Most Dangerous Superstition

---

Corman-Drosten review report: understanding PCR testing fraud.
 -- https://cormandrostenreview.com/


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

Bug#1008668: bug #1008668: tomcat9: logrotated is not able to truncate catalina.out

[Evren Yurtesen]

Nevermind my previous idea. It does not work as the /var/log/tomcat9 is group 
writable by `adm` group. Causes the following problem: :(


# logrotate -f /etc/logrotate.d/tomcat9
error: skipping "/var/log/tomcat9/catalina.out" because parent directory has 
insecure permissions (It's world writable or writable by group which is not 
"root") Set "su" directive in config file to tell logrotate which user/group 
should be used for rotation.



From: Evren Yurtesen
Sent: Thursday, April 14, 2022 10:39:58 PM
To: Markus Koschany; Utkarsh Gupta
Cc: 1008...@bugs.debian.org
Subject: Re: bug #1008668: tomcat9: logrotated is not able to truncate 
catalina.out


Hi Markus,


You are quite right. The root cause of the issue is Ubuntu dropping privileges 
of rsyslogd to `syslog` user. This change was done way back in ~2009 in Ubuntu 
package.


https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/388608 (which does not 
explain the benefits very clearly, but my assumption is an attempt at improving 
security).


As you put it adequately. There are other Debian packages also use rsyslogd. 
This change in Ubuntu's rsyslog configuration should be effecting those also. I 
had a quick look using apt-file for packages which put configurations to 
/etc/rsyslog.d. The ones I checked does not seem to specify a certain 
user/group in rsyslog config.  This cause files to be owned as root:adm and 640 
permission in Debian which is the default according to `/etc/rsyslog.conf` and 
in Ubuntu they would be owned by Ubuntu's default settings automatically as 
well.


Could it be more acceptable if the 'fileOwner="tomcat"' setting was simply 
removed from rsyslog config of tomcat9? In addition,  'create 640 tomcat adm' 
and ' su tomcat adm' settings could be removed from logrotate config of tomcat9?


One advantage for Debian is that `tomcat` itself can't read the log files 
anymore. This could be considered more secure. But not that it would help much, 
as tomcat9 package triple-logs everything. First through syslog to 
catalina.out, then directly to catalina.-MM-DD.log in a different format. 
Of course nowadays a third time through journald. :)


Thanks,
Evren


From: Markus Koschany 
Sent: Thursday, April 14, 2022 5:31:49 PM
To: Utkarsh Gupta; Evren Yurtesen
Cc: 1008...@bugs.debian.org
Subject: Re: bug #1008668: tomcat9: logrotated is not able to truncate 
catalina.out

Am Donnerstag, dem 14.04.2022 um 16:23 +0530 schrieb Utkarsh Gupta:
> Hi Emmanuel,
>
> We have bug #1008668 that's causing problems on the Ubuntu side and is
> also reproducible via the Debian package (essentially, it's the same
> in both places).

Hi Utkarsh,

I have been trying to reproduce this problem but on an up-to-date Debian system
running tomcat9 version 9.0.58-1 I cannot reproduce it. catalina.out is
truncated when I run

logrotate -f /etc/logrotate.d/tomcat9

The logrotate file changes the permissions to "su tomcat adm" which is
sufficient to operate on tomcat9 log files. I'm not familiar with the Ubuntu
differences when it comes to logrotate and rsyslogd but I suppose that is the
underlying issue here. It would be strange if we had to change the permissions
to syslog adm because other Debian packages also own log files with their
specific users and then does not cause any problems too.

Thus said I am not against fixing this for Ubuntu but the current approach
seems wrong to me.

Regards,

Markus

Bug#1009898: O: dropwatch -- tool for detecting and diagnosing dropped network packets

[Dmitry Smirnov]

Package: wnpp
Severity: normal
X-Debbugs-CC: debian-de...@lists.debian.org

Package "dropwatch" needs new maintainer.

I have no understanding with upstream and unable to spare any time for this
package any more. Please adopt this package if you care for it.

-- 
Regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Freedom is the freedom to say that two plus two make four. If that is
granted, all else follows.
 -- George Orwell

---

Corman-Drosten review report: understanding PCR testing fraud.
 -- https://cormandrostenreview.com/


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

Bug#1008870: [Pkg-electronics-devel] Bug#1008870: openocd: segfault when using stm32f1x config

[Jonathan McDowell]

On Sun, Apr 03, 2022 at 12:26:05PM +0300, Matsievskiy S.V. wrote:
> Package: openocd
> Version: 0.11.0-1
> Severity: important
> X-Debbugs-Cc: seregaxvm.m...@gmail.com
> 
> Dear Maintainer,
> 
> OpenOCD segfaults when using target/stm32f1x.cfg configuration. I do not
> experience this issue with newer version built from source (Open On-Chip
> Debugger 0.11.0+dev-02226-gf6ffede8b).
> 
> dmesg entry:
> [ 7388.531636] openocd[36055]: segfault at 14 ip 7f64e097b12d sp
> 7ffdde27a090 error 4 in libusb-1.0.so.0.3.0[7f64e0974000+f000]
> 
> Way to reproduce:
> 1. Connect STLinkV2
> 2. Run command openocd -f openocd.cfg (file is attached)

I don't have STLinkV2 hardware so am unable to reproduce. Can you
confirm the upstream git version you're using - I don't see "f6ffede8b"
in the usptream git tree.

Also, if you're able to, can you try recompiling the 0.11.0 Debian
package on your system just to narrow down that it's a fix upstream
we're looking for rather than a build issue? I *think* it's going to be
cff0e417da58adef1ceef9a63a99412c2cc87ff3 that's the issue, which means
the problem won't exist in bullseye (libusb-1.0 is at 1.0.24).

J.

-- 
"Time for bed" said Zebedee.  "Yours or mine" said Florence.

Bug#1009896: RM: ruby-ghi -- RoM; obsolete

[Dmitry Smirnov]

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

Please remove "ruby-ghi" from "unstable".

The package is obsolete and no longer maintained upstream.

Thanks.

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

---

The difference between technology and slavery is that slaves are fully
aware that they are not free.
 -- Nassim Nicholas Taleb

---

COVID-19: PCR-based testing produces enough false positive results to make
positive results highly unreliable over a broad range of real-world
scenarios.
https://www.medrxiv.org/content/10.1101/2020.04.26.20080911v3


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

Bug#1008653: backintime-qt: upstream works fine

[Leonardo Canducci]

Package: backintime-qt
Followup-For: Bug #1008653

I've installed backintime-qt from github (it's pretty straightforward,
just donwload the source and build two deb files with the provided
makedeb.sh) and it works fine.

Please update this package. I'm by no means a developer but it seems
like a trivial fix.

Leonardo

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

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

Versions of packages backintime-qt depends on:
ii  backintime-common1.3.2
ii  libnotify-bin0.7.9-3
ii  policykit-1  0.105-33
ii  python3  3.10.4-1
ii  python3-dbus.mainloop.pyqt5  5.15.6+dfsg-1+b2
ii  python3-pyqt55.15.6+dfsg-1+b2
ii  x11-utils7.7+5

Versions of packages backintime-qt recommends:
ii  python3-secretstorage  3.3.2-1

Versions of packages backintime-qt suggests:
ii  meld  3.20.4-2

-- no debconf information

Bug#1009894: new upstream versions

[Harald Dunkel]

Package: qmmp
Version: 1.4.4-1

Upstream provides new versions 1.5.4 and 2.0.4, see

 https://qmmp.ylsoftware.com/
 https://sourceforge.net/projects/qmmp-dev/

Would it be possible to upgrade the Debian package? I can help.

Regards
Harri