Bug#985699: xtensor: tests fail on less common architectures

[Drew Parsons]

Source: xtensor
Followup-For: Bug #985699

0.23.10-10 skips the test_xnpy tests on s390x, hppa, powerpc, ppc64,
sparc64.

That just ignores the problem, enabling the package to build and get
tested by other packages on these arches. It doesn't fix the problem.

Bug#994911: error modifying deb822 object while iterating

[Niels Thykier]

On Thu, 23 Sep 2021 00:43:50 + Jelmer Vernooij 
wrote:
> Package: python3-debian
> Version: 0.1.41
> Severity: normal
> 
> Modifying a deb822 file while iterating over it results in a RuntimeError:
> 
> ...
>   File 
> "/home/jelmer/src/debian-janitor/python-debian/lib/debian/_deb822_repro/parsing.py",
>  line 2208, in iter_keys
> yield from self._kvpair_elements
> RuntimeError: dictionary keys changed during iteration
> 
> (This doesn't happen with the default deb822 implementation)
> 
> [...]


Hi,

Can you provide the code snippet that triggers this bug?

As I understand it, this is "normal" for a dict depending on the exact
usage, which is why I would like to see what you were doing when you
triggered the bug. :)

Example with dict:

 d = {'a': 1, 'b': 2}
 for e in d:
> ...   if d[e] == 2:
> ... d['z'] = 1
> ... 
> Traceback (most recent call last):
>   File "", line 1, in 
> RuntimeError: dictionary changed size during iteration
 for e in d:
> ... d[e] = 2
> ... 
 


Thanks,
~Niels

Bug#996016: libreoffice: fails to send email

[Alex]

Package: libreoffice
Severity: normal

Dear Maintainer,

When I created a document in libreoffice and when I would send it as 
mail attachment, Libreoffice simply doesn't open my mailprogram defined 
in KDE.
When I start libreoffice in a shell, I got error messages when sending 
the document as mail. In fact, I defined Thunderbird as my mail program 
in KDE->Settings.

The error message I got is:

moz=/usr/bin/thunderbird
FOPTS=-L
Befehlzeile: if file -L /usr/bin/thunderbird | grep script > /dev/null 
&& grep [NM]PL /usr/bin/thunderbird > /dev/null

/usr/lib/libreoffice/program/senddoc: 64: file: Permission denied
3
$1=/usr/bin/thunderbird
/usr/bin/thunderbird -compose 
subject='FEO',attachment='file:///tmp/lu3553l027nu.tmp/lu3553l027nx.tmp/FEO.ods'

$2=subject='FEO',attachment='file:///tmp/lu3553l027nu.tmp/lu3553l027nx.tmp/FEO.ods'
/usr/lib/libreoffice/program/senddoc: 77: /usr/bin/thunderbird: 
Permission denied


I modified the script senddoc with several echo commands to get an 
output which component is causing the error.
As you can see, I got a permission denied on /usr/bin/thunderbird. I 
checked the permissions and those seemed to be ok, and when I start 
thunderbird directly in the shell, it will start.
So I disabled apparmor. I completely uninstalled it and after a reboot, 
the sending by mail attachment works as expected.


This is only an ugly workaround to get it work again, so help please.

Thank you

-- System Information:
Debian Release: 11.1
APT prefers stable
APT policy: (700, 'stable'), (500, 'stable-updates'), (500, 
'stable-security')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

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

Versions of packages libreoffice depends on:
ii libreoffice-base 1:7.0.4-4
ii libreoffice-calc 1:7.0.4-4
ii libreoffice-core 1:7.0.4-4
ii libreoffice-draw 1:7.0.4-4
ii libreoffice-impress 1:7.0.4-4
ii libreoffice-math 1:7.0.4-4
ii libreoffice-report-builder-bin 1:7.0.4-4
ii libreoffice-writer 1:7.0.4-4
ii python3-uno 1:7.0.4-4

Versions of packages libreoffice recommends:
ii fonts-crosextra-caladea 20130214-2.1
ii fonts-crosextra-carlito 20130920-1.1
ii fonts-dejavu 2.37-2
ii fonts-liberation 1:1.07.4-11
ii fonts-liberation2 2.1.3-1
ii fonts-linuxlibertine 5.3.0-6
ii fonts-noto-core 20201225-1
ii fonts-noto-extra 20201225-1
ii fonts-noto-mono 20201225-1
ii fonts-noto-ui-core 20201225-1
pn fonts-sil-gentium-basic 
ii libreoffice-java-common 1:7.0.4-4
pn libreoffice-nlpsolver 
ii libreoffice-report-builder 1:7.0.4-4
pn libreoffice-script-provider-bsh 
pn libreoffice-script-provider-js 
pn libreoffice-script-provider-python 
ii libreoffice-sdbc-mysql 1:7.0.4-4
ii libreoffice-sdbc-postgresql 1:7.0.4-4
pn libreoffice-wiki-publisher 

Versions of packages libreoffice suggests:
ii cups-bsd 2.3.3op2-3+deb11u1
ii default-jre [java8-runtime] 2:1.11-72
ii firefox-esr 78.15.0esr-1~deb11u1
ii ghostscript 9.53.3~dfsg-7+deb11u1
ii gnupg 2.2.27-2
pn gpa 
ii gstreamer1.0-libav 1.18.4-3
ii gstreamer1.0-plugins-bad 1.18.4-3
ii gstreamer1.0-plugins-base 1.18.4-2
ii gstreamer1.0-plugins-good 1.18.4-2
ii gstreamer1.0-plugins-ugly 1.18.4-2
ii hunspell-de-at [hunspell-dictionary] 20161207-9
ii hunspell-de-ch [hunspell-dictionary] 20161207-9
ii hunspell-de-de [hunspell-dictionary] 20161207-9
ii hunspell-en-us [hunspell-dictionary] 1:2019.10.06-1
ii hyphen-de [hyphen-hyphenation-patterns] 1:7.1.0~rc3-3
ii imagemagick 8:6.9.11.60+dfsg-1.3
ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3
ii libgl1 1.3.2-1
pn libofficebean-java 
pn libreoffice-gnome | libreoffice-plasma 
pn libreoffice-grammarcheck 
ii libreoffice-help-de [libreoffice-help] 1:7.0.4-4
ii libreoffice-l10n-de [libreoffice-l10n] 1:7.0.4-4
pn libreoffice-librelogo 
ii libsane1 1.0.31-4.1
ii libxrender1 1:0.9.10-1
ii myspell-fr-gut [myspell-dictionary] 1:1.0-32.1
ii mythes-de [mythes-thesaurus] 20160424-4
ii mythes-de-ch [mythes-thesaurus] 20160424-4
pn openclipart2-libreoffice | openclipart-libreoffice 
ii openjdk-11-jre [java8-runtime] 11.0.12+7-2
pn pstoedit 
ii thunderbird 1:78.14.0-1~deb11u1
pn unixodbc 

Bug#996020: openscad: Buffer overflows in STL parser (CVE-2020-28599, CVE-2020-28600)

[Kristian Nielsen]

Package: openscad
Version: 2019.01~RC2-2
Severity: important

There is a bug in the import() function in OpenSCAD when importing STL
files. Certain invalid files can cause out-of-bounds accesses, potentially
causing arbitrary code execution.

The bug is associated with these CVEs:

  https://security-tracker.debian.org/tracker/CVE-2020-28599
  https://security-tracker.debian.org/tracker/CVE-2020-28600

As seen in these links, the bug affects the openscad version in buster (and
stretch), but is fixed in newer upstream releases (meaning bullseye,
testing, and unstable are unaffected). The upstream fix is in this git
commit 07ea60f82e94a155f4926f17fad8e8366bc74874:

  
https://github.com/openscad/openscad/commit/07ea60f82e94a155f4926f17fad8e8366bc74874

This commit contains the fix to the C++ source code. It also adds tests to
the testsuite which test for this bug.

This is considered a minor security issue. The plan is to get it fixed in
buster through a point release.

 - Kristian.

-- Package-specific info:
Output of /usr/share/bug/openscad:
$ glxinfo |grep 'OpenGL .* string:'
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) UHD Graphics 620 (KBL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.3.5
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.3.5
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.3.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

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

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

Versions of packages openscad depends on:
ii  lib3mf11.8.1+ds-4
ii  libboost-filesystem1.74.0  1.74.0-9
ii  libboost-program-options1.74.0 1.74.0-9
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu67]  1.74.0-9
ii  libc6  2.31-13
ii  libcairo2  1.16.0-5
ii  libdouble-conversion3  3.1.5-6.1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.4+dfsg-1
ii  libgcc-s1  10.2.1-6
ii  libgl1 1.3.2-1
ii  libglew2.1 2.1.0-4+b1
ii  libglib2.0-0   2.66.8-1
ii  libglu1-mesa [libglu1] 9.0.1-1
ii  libgmp10   2:6.2.1+dfsg-1
ii  libharfbuzz0b  2.7.4-1
ii  libhidapi-libusb0  0.10.1+dfsg-1
ii  libmpfr6   4.1.0-3
ii  libopencsg11.4.2-3
ii  libqscintilla2-qt5-15  2.11.6+dfsg-2
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gamepad5 5.15.2-2
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5multimedia5  5.15.2-3
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libspnav0  0.2.3-1+b2
ii  libstdc++6 10.2.1-6
ii  libx11-6   2:1.7.2-1
ii  libxml22.9.10+dfsg-6.7
ii  libzip41.7.3-1

Versions of packages openscad recommends:
ii  openscad-mcad  2019.05-1

Versions of packages openscad suggests:
pn  geomview  
pn  librecad  
ii  meshlab   2020.09+dfsg1-1
ii  openscad-testing  2021.01-2

-- no debconf information

Bug#996017: synfigstudio: New version availabe (bug fixing)

[Davide Prina]

Package: synfigstudio
Version: 1.4.0+dfsg-1+b1
Severity: wishlist
X-Debbugs-Cc: davide.pr...@gmail.com

Dear mainteiner,

there is a new version (1.4.2 2021.07.29) available.
Version 1.4.1 and 1.4.2 fix a lot of bugs of version 1.4.0 present in
Debian.

see the Changelog here
https://github.com/synfig/synfig/blob/v1.4.2/ChangeLog.md

I don't want to report bugs in Debian that are already fixed in 1.4.2
version.

Ciao
Davide

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

Kernel: Linux 5.14.9-dp-20211009 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 synfigstudio depends on:
ii  libatkmm-1.6-1v52.28.2-1
ii  libc6   2.32-4
ii  libcairo2   1.16.0-5
ii  libcairomm-1.0-1v5  1.12.2-4
ii  libgcc-s1   11.2.0-8
ii  libglib2.0-02.70.0-1+b1
ii  libglibmm-2.4-1v5   2.66.1-1
ii  libgtk-3-0  3.24.30-3
ii  libgtkmm-3.0-1v53.24.5-1
ii  libmlt++7   7.0.1-3
ii  libpangomm-1.4-1v5  2.46.1-1
ii  libsigc++-2.0-0v5   2.10.4-2
ii  libstdc++6  11.2.0-8
ii  libsynfig0a 1.4.0+dfsg-2.1
ii  libxml++2.6-2v5 2.40.1-3

Versions of packages synfigstudio recommends:
ii  synfig-examples  1.4.0+dfsg-2.1

synfigstudio suggests no packages.

-- no debconf information

Bug#995923: Forwarded upstream

[Diederik de Haas]

Control: forwarded -1 https://lore.kernel.org/all/4974503.Y8KB3sNASq@bagend/

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

Bug#993624: RM: eckit [armel i386 armhf mipsel] -- ROM; 32-bit archs no longer supported

[Sebastiaan Couwenberg]

On Fri, 03 Sep 2021 20:50:51 +0100 Alastair McKinstry wrote:
> Please remove the 32-bit archs - they are no longer supported upstream

Looks like this cannot happen until at least fckit & metkit are also
removed from these architectures:

 $ dak rm -Rn -b -a armel,i386,armhf,mipsel \
   eckit libeckit-dev libeckit-utils libeckit0d
 W: -a/--architecture implies -p/--partial.
 Will remove the following packages from unstable:

 libeckit-dev |   1.16.3-1 | armel, armhf, i386, mipsel
 libeckit-utils |   1.16.3-1 | armel, armhf, i386, mipsel
 libeckit0d |   1.16.3-1 | armel, armhf, i386, mipsel

 Maintainer: Alastair McKinstry 

 --- Reason ---

 --

 Checking reverse dependencies...
 # Broken Depends:
 fckit: libfckit0d
 metkit: libmetkit-dev
 libmetkit-utils
 libmetkit0d

 # Broken Build-Depends:
 atlas-ecmwf: libeckit-dev (>= 1.4.7-7)
 fckit: libeckit-dev (>= 1.15.4-1~)
 fdb: libeckit-dev
 metkit: libeckit-dev (>= 1.16.0-1~)
 metview: libeckit-dev (>= 1.10.1~)
 odc: libeckit-dev (>= 1.16.0-1~)

 Dependency problem found.

Kind Regards,

Bas

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

Bug#994911: error modifying deb822 object while iterating

[Niels Thykier]

On Sun, 10 Oct 2021 08:41:55 +0200 Niels Thykier  wrote:
> On Thu, 23 Sep 2021 00:43:50 + Jelmer Vernooij 
> wrote:
> > Package: python3-debian
> > Version: 0.1.41
> > Severity: normal
> > 
> > Modifying a deb822 file while iterating over it results in a RuntimeError:
> > 
> > ...
> >   File 
> > "/home/jelmer/src/debian-janitor/python-debian/lib/debian/_deb822_repro/parsing.py",
> >  line 2208, in iter_keys
> > yield from self._kvpair_elements
> > RuntimeError: dictionary keys changed during iteration
> > 
> > (This doesn't happen with the default deb822 implementation)
> > 
> > [...]
> 
> 
> Hi,
> 
> Can you provide the code snippet that triggers this bug?
> 
> As I understand it, this is "normal" for a dict depending on the exact
> usage, which is why I would like to see what you were doing when you
> triggered the bug. :)
> 
> Example with dict:
> 
>  d = {'a': 1, 'b': 2}
>  for e in d:
> > ...   if d[e] == 2:
> > ... d['z'] = 1
> > ... 
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > RuntimeError: dictionary changed size during iteration
>  for e in d:
> > ... d[e] = 2
> > ... 
>  
> 
> 
> Thanks,
> ~Niels
> 
> 

Thinking some more about, this *might* be fixed as a side effect of:

https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/69/diffs?commit_id=2832d2fc306b10f56ff910e6e1cf990ccdb9e9b4

(but it is hard to tell for sure without the concrete code you were using)

Feel free to cherry-pick that commit out of the branch/MR if you need it. :)

Thanks,
~Niels

Bug#996019: debootstrap: bootstrap of ubuntu impish is failing

[Sylvestre Ledru]

Package: debootstrap
Version: 1.0.124
Severity: normal

Dear Maintainer,

$ sudo debootstrap impish impish 
https://www-ftp.lip6.fr/pub/linux/distributions//Ubuntu/archive/ 
I: impish uses zstd compression, setting --extractor=ar option
I: Retrieving InRelease 
I: Retrieving Packages 
I: Validating Packages
[...]
I: Validating zlib1g 1:1.2.11.dfsg-2ubuntu7
I: Chosen extractor for .deb packages: ar
I: Extracting base-files...
I: Extracting base-passwd...
E: Extracting .//var/cache/apt/archives/base-passwd_3.5.51_amd64.deb requires 
the zstdcat command, which is not available

adding --include=zstd doesn't fix the issue
[...]
I: Retrieving zstd 1.4.8+dfsg-2.1
I: Validating zstd 1.4.8+dfsg-2.1
I: Chosen extractor for .deb packages: ar
I: Extracting base-files...
I: Extracting base-passwd...
E: Extracting .//var/cache/apt/archives/base-passwd_3.5.51_amd64.deb requires 
the zstdcat command, which is not available

Thanks,
Sylvestre

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'oldstable-updates'), (500, 
'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages debootstrap depends on:
ii  wget  1.21-1+b1

Versions of packages debootstrap recommends:
pn  arch-test   
ii  debian-archive-keyring  2021.1.1
ii  gnupg   2.2.27-2

Versions of packages debootstrap suggests:
ii  binutils2.37-7
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  
ii  xz-utils5.2.5-2
pn  zstd

-- no debconf information

Bug#995934: python-gevent: diff for NMU version 20.9.0-2.1

[GCS]

On Sat, Oct 9, 2021 at 7:25 AM Sandro Tosi  wrote:
> On Fri, Oct 8, 2021 at 3:12 PM László Böszörményi (GCS)  
> wrote:
> >  I can't devote enough time to this package. Feel free any of you
> > taking this package to the Python Team and maintain it there.
>
> I can help maintain this package, just because I maintain one of its
> rdeps. Do you have a git repo you're using to package python-gevent?
> if so, we can migrate that under
> https://salsa.debian.org/python-team/packages (if not, we're going to
> create it from the source packages).
 Long story short, I don't have one.

> Do you still want to be in the Uploaders list?
 It's up to your decision. I can't devote time to the package. You can
put me there, but don't expect much work.

> since we're talking about this, did you give it a thought if you want
> to start maintaining your other python packages under the DPT
> umbrella?
 Will think about it and let you know soon, sending separate emails about those.

Regards,
Laszlo/GCS

Bug#955407: linux-image-4.19.0-8-amd64: "Uhhuh. NMI received for unknown reason" on AMD Ryzen

[Diederik de Haas]

On Saturday, 9 October 2021 21:28:19 CEST Diederik de Haas wrote:
> I'll try later whether I can reliably reproduce it with hibernate mode.

That appears to be the case. Hibernated my PC yesterday and started it up
today. After some time, I got the msgs again, this time also in dmesg:

# dmesg | tail -n15
[248910.645828] pl2303 5-4:1.0: pl2303 converter detected
[248910.645936] PM: hibernation: Basic memory bitmaps freed
[248910.645937] OOM killer enabled.
[248910.645938] Restarting tasks ... done.
[248910.647538] PM: hibernation: hibernation exit
[248910.650035] snd_hda_codec_hdmi hdaudioC0D0: HDMI: ELD buf size is 0, force 
128
[248910.650051] snd_hda_codec_hdmi hdaudioC0D0: HDMI: invalid ELD data byte 0
[248910.672631] usb 5-4: pl2303 converter now attached to ttyUSB0
[248910.672669] pl2303 5-3:1.0: pl2303 converter detected
[248910.699625] usb 5-3: pl2303 converter now attached to ttyUSB1
[248910.699669] pl2303 5-2:1.0: pl2303 converter detected
[248910.726626] usb 5-2: pl2303 converter now attached to ttyUSB2
[249275.040414] Uhhuh. NMI received for unknown reason 2c on CPU 0.
[249275.040417] Do you have a strange power saving mode enabled?
[249275.040417] Dazed and confused, but trying to continue

HTH,
  Diederik

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

Bug#995903: console logs

[V V]

Hello.
More details on that:
1) Attempt to open downloads:
[2323:2323:1010/125446.121796:ERROR:CONSOLE(146)] "Uncaught TypeError:
Cannot read properties of undefined (reading 'length')", source:
chrome://downloads/manager.js
2) Attempt to open history:
[2323:2323:1010/125644.918153:ERROR:CONSOLE(283)] "Uncaught TypeError:
Cannot read properties of undefined (reading 'querying')", source:
chrome://history/history_list.js (283)
[2323:2323:1010/125644.924414:ERROR:CONSOLE(431)] "Uncaught TypeError:
Cannot read properties of undefined (reading 'length')", source:
chrome://history/history_list.js (431)
[2323:2323:1010/125644.929009:ERROR:CONSOLE(1)] "Uncaught TypeError: Cannot
read properties of undefined (reading 'substr')", source:
chrome://resources/polymer/v3_0/polymer/polymer_bundled.min.js (1)

Probable upstream bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=1249296

With best regards,
Vladimir

Bug#996018: linux-image-5.10.0-9-amd64: linux/i2c/i2c-hid.h: Aucun fichier ou dossier de ce type

[Jonas]

Package: src:linux
Version: 5.10.70-1
Severity: important

Dear Maintainer,

I can't use kernel 5.10 cat I have a building module error

===
$ sudo dpkg-reconfigure linux-image-5.10.0-9-amd64
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 5.10.0-9-amd64:
Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
make -j8 KERNELRELEASE=5.10.0-9-amd64 -C /lib/modules/5.10.0-9-amd64/build
M=/var/lib/dkms/asus/1.0/build/src modules...(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.10.0-9-amd64 (x86_64)
Consult /var/lib/dkms/asus/1.0/build/make.log for more information.
.
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.10.0-9-amd64



$ cat /var/lib/dkms/asus/1.0/build/make.log
DKMS make.log for asus-1.0 for kernel 5.10.0-9-amd64 (x86_64)
dim. 10 oct. 2021 12:17:37 CEST
make : on entre dans le répertoire « /usr/src/linux-headers-5.10.0-9-amd64 »
  CC [M]  /var/lib/dkms/asus/1.0/build/src/hid-asus.o
  CC [M]  /var/lib/dkms/asus/1.0/build/src/i2c-hid.o
/var/lib/dkms/asus/1.0/build/src/i2c-hid.c:42:10: fatal error:
linux/i2c/i2c-hid.h: Aucun fichier ou dossier de ce type
   42 | #include 
  |  ^
compilation terminated.
make[2]: *** [/usr/src/linux-headers-5.10.0-9-common/scripts/Makefile.build:285
: /var/lib/dkms/asus/1.0/build/src/i2c-hid.o] Erreur 1
make[2]: *** Attente des tâches non terminées
make[1]: *** [/usr/src/linux-headers-5.10.0-9-common/Makefile:1846 :
/var/lib/dkms/asus/1.0/build/src] Erreur 2
make: *** [/usr/src/linux-headers-5.10.0-9-common/Makefile:185 : __sub-make]
Erreur 2
make : on quitte le répertoire « /usr/src/linux-headers-5.10.0-9-amd64 »


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: ASUSTeK COMPUTER INC.
product_name: N501VW
product_version: 1.0   
chassis_vendor: ASUSTeK COMPUTER INC.
chassis_version: 1.0   
bios_vendor: American Megatrends Inc.
bios_version: N501VW.300
board_vendor: ASUSTeK COMPUTER INC.
board_name: N501VW
board_version: 1.0   

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th 
Gen Core Processor Host Bridge/DRAM Registers [8086:1910] (rev 07)
Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v5/E3-1500 v5/6th Gen 
Core Processor Host Bridge/DRAM Registers [1043:1080]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor PCIe 
Controller (x16) [8086:1901] (rev 07) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 
[8086:191b] (rev 06) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. HD Graphics 530 [1043:1080]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 07)
Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v5/E3-1500 v5/6th Gen 
Core Processor Thermal Subsystem [1043:1080]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device

00:14.0 USB controller [0c03]: Intel Corporation 100 Series/C230 Series Chipset 
Family USB 3.0 xHCI Controller [8086:a12f] (rev 31) (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. 100 Series/C230 Series Chipset Family 
USB 3.0 xHCI Controller [1043:201f]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 Signal processing controller [1180]: Intel Corporation 100 Series/C230 
Series Chipset Family Thermal Subsystem [8086:a131] (rev 31)
Subsystem: ASUSTeK Computer Inc. 100 Series/C230 Series Chipset Family 
Thermal Subsystem 

Bug#996013: transition: poco

[Jochen Sprickerhof]

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

Hi release team,

I would like to transition the new POCO version. The auto generated ben
file looks fine and I have rebuild all reverse dependencies
successfully.

Cheers Jochen

Bug#996014: transition: orocos-kdl

[Jochen Sprickerhof]

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

Hi release team,

I would like to transition orocos-kdl. The auto generated ben file looks
fine and I've rebuild all reverse dependencies successfully.

Cheers Jochen

Bug#993755: libcrypt.so.1: cannot open shared object file when upgrading from Stretch to Sid

[Marco d'Itri]

On Oct 10, Otto Kekäläinen  wrote:

> Yeah, but one should be able to skip at least one release, right? What
No.

> Could you please consider if the libcrypt1 change was done in a way so
> that at least Buster to Bookworm upgrades would work?
This has already been discussed: feel free to do the work required by 
the glibc maintainer.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#922425: submitted #996003 to solve this

[Chris Vogel]

submited 

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

to solve this issue. It is a backport from a patch accepted upstream at GNU 
grub2.

Bug#930603: libdockapp-dev: pkg-config file Requires xext without dependency on libxext-dev

[Jeremy Sowden]

On 2021-10-09, at 18:52:49 +0200, Andreas Metzler wrote:
> On 2021-10-09 Jeremy Sowden  wrote:
> > On 2019-08-13, at 19:09:33 +0200, Andreas Metzler wrote:
> >> On 2019-06-16 Douglas Torrance wrote:
> >>> On Sun, Jun 16, 2019 at 7:30 AM Andreas Metzler wrote:
>  /usr/lib/x86_64-linux-gnu/pkgconfig/dockapp.pc:
>  Requires: x11 xext xpm
>
>  Therefore anything build-depending on libdockapp-dev and using
>  pkg-config to locate the library will FTBFS unless it has a
>  direct b-d on libxext-dev.
> [...]
> >> the respective patch moves "Requires: x11 xext xpm" to
> >> Requires.private.  That does not really fix the bug. pkg-config
> >> --cflags requires that not only Requires but also Requires.private
> >> are is resolvable (even when --static is not present) i.e. xext.pc
> >> would still need to be present.
>
> >> I think this would be the correct fix:
> >> - @echo 'Requires.private: x11 xext xpm' >> $@
> >> + @echo 'Requires.private: x11 xpm' >> $@
> >> + @echo 'Libs.private: -lext' >> $@
>
> > Doesn't that mean that we lose information?  What if libxext is
> > installed in a non-standard location, and we need the -L${libdir} to
> > find it?
>
> > I think the right thing to do is to add a b-d on libxext-dev to
> > libdockapp-dev.
>
>  Adding libxext-dev to libdockapp-dev's Depends would work
> perfectly fine for me.

I've pushed a commit to add the dependency, plus a few other things.

> --- I think it is a little bit of grey area, not and black and
> white. Having xext in Requires.private broke pkgconfig and introduced
> this bug. Some third-party packages needed to work around this and we
> could inflate libdockapp-dev's dependencies to fix it. There is no
> real gain for e.g.  Debian packages in having xext in
> Requires.private.
>
> OTOH for non-dist packages you raise a valid point. However the
> breakage seems to be constrained to a corner case:
>  + xext is installed in non-standard location and this non-standard
>location is a different one than either x11 or xpm
>  + static linking is wanted. (Or we are on an exotic arch which
>requires explicit linking against all indirect deps).

Agreed.

J.


signature.asc
Description: PGP signature

Bug#996016: libreoffice: fails to send email

[Rene Engelhard]

found 996016 1:7.0.4-4

retitlle 996016 ibreoffice: fails to send email with Thunderbird set as
mailer in KDE

tag 996016 + moreinfo

tag 996016 + unreproducible

thanks


Hi,


Am 10.10.21 um 11:30 schrieb Alex:
> Package: libreoffice
> Severity: normal
>
> Dear Maintainer,
>
> When I created a document in libreoffice and when I would send it as
> mail attachment, Libreoffice simply doesn't open my mailprogram
> defined in KDE.
> When I start libreoffice in a shell, I got error messages when sending
> the document as mail. In fact, I defined Thunderbird as my mail
> program in KDE->Settings.
And what is in LO settings?

> As you can see, I got a permission denied on /usr/bin/thunderbird. I
checked the permissions and those seemed to be ok, and when I start
thunderbird directly in the shell, it will start.

> So I disabled apparmor. I completely uninstalled it and after a
> reboot, the sending by mail attachment works as expected.
>
> This is only an ugly workaround to get it work again, so help please.
>
What if you set your mailer as xdg-email? That one is explicitely allowed:


profile libreoffice-senddoc /usr/lib/libreoffice/program/senddoc {
  #include 

  #include 

  /{usr/,}bin/sh    rmix,
  /{usr/,}bin/bash  rmix,
  /{usr/,}bin/dash  rmix,
  /{usr/,}bin/sed   rmix,
  /usr/bin/dirname  rmix,
  /usr/bin/basename rmix,
  /{usr/,}bin/grep  rmix,
  /{usr/,}bin/uname rmix,
  /usr/bin/xdg-open rPUx,
  /usr/bin/xdg-email    rPUx,
  /dev/null rw,
  /usr/lib/libreoffice/program/uri-encode rmpux,
  /usr/share/libreoffice/share/config/* r,
  owner
@{HOME}/.config/libreoffice{,dev}/?/user/uno_packages/cache/log.txt rw,
}


xdg-email will send with your preferred e-mail programm (see man xdg-email).


I just tried it: LOs default has sensible-lomua set. That one opened
Thunderbird in my  GNOME and happily set mail.

case `basename "$MAILER"` in
    sensible-lomua)
    if [ -x /usr/bin/xdg-email ] ; then
    MAILER=/usr/bin/xdg-email
    elif [ -n "$KDE_FULL_SESSION" -a -x /usr/bin/kde-open ] \
   || [ -x /usr/bin/gnome-open ] \
   || [ -x /usr/bin/xdg-open ]; then
    # use an undefined mailer, to trigger the default handling
    MAILER=undefined
    elif [ -n "$GNOME_DESKTOP_SESSION_ID" -a -x /usr/bin/evolution
]; then
    MAILER=/usr/bin/evolution
    elif [ -n "$KDE_FULL_SESSION" -a -x /usr/bin/kmail ]; then
    MAILER=/usr/bin/kmail
    elif [ -x /usr/bin/evolution ]; then
    # default
    MAILER=/usr/bin/evolution
    elif [ -x /usr/bin/icedove ]; then
    # fallback
    MAILER=/usr/bin/icedove
    elif [ -x /usr/bin/thunderbird ]; then
    # fallback
    MAILER=/usr/bin/thunderbird
    fi
    ;;
esac


... using xdg-email.

Regards,


Rene

Bug#982135: ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C

[Jan Mojzis]

Repacked version without exe-binary is in the git repository:
https://salsa.debian.org/debian/bearssl

Best regards,
Jan

> On 5 Oct 2021, at 19:44, Jan Mojzis  wrote:
> 
> Ok
> I understand,
> first i will contact ‘upstream’ to remove the binary from the package.
> 
> Jan
> 
>> On 5 Oct 2021, at 19:03, Bastian Germann  wrote:
>> 
>> Am 05.10.21 um 18:59 schrieb Jan Mojzis:
>>> Hello,
>>> I have removed the patch, it wasn’t good idea.
>>> The exe binary doesn’t affect debian package.
>>> So I just updates the d/source/include-binary file.
>> 
>> Hi Jan,
>> 
>> Actually, it does affect the source package legally. You cannot know without 
>> a long process of reverse engineering what is contained in the binary. Odds 
>> are that it violates the distribution permission of additional software that 
>> is included but not documented.
>> 
>> So if you want the package sponsored by me, you would have to repack, 
>> removing that file from the source package.
>> 
>> Thanks,
>> Bastian
>> 
> 

Bug#996079: gnome-shell-timer: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-timer
Version: 3.38.0-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996080: transition: pcl

[Jochen Sprickerhof]

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

Hi release team,

I would like to transition pcl. The autogenerated ben file looks fine
and ros-perception-pcl builds against the new version. For python-pcl I
will upload a fixed version myself.

Cheers Jochen

Bug#934372: snapd: does not work under cgroup v2 at all

[Stefano Rivera]

Control: forwarded -1 https://bugs.launchpad.net/snapd/+bug/1926283
Control: severity -1 important

Bumping the severity back up, because this breaks unrelated software
(#996036), also re-pointing at the current upstream issue.

SR

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

Bug#996082: vte2.91: vte.terminal.spawn_async emits useless warning by default

[Nis Martensen]

Source: vte2.91
Version: 0.62.3-1
Severity: minor
Tags: upstream
X-Debbugs-Cc: nis.marten...@web.de

According to
https://lazka.github.io/pgi-docs/Vte-2.91/classes/Terminal.html#Vte.Terminal.spawn_sync
spawn_sync is deprecated and one should use spawn_async instead.

After trying to switch reportbug to calling spawn_async, I get this
warning:

(reportbug:22755): VTE-WARNING **: 21:37:42.462:
(../src/vtepty.cc:811):void vte_pty_spawn_with_fds_async(VtePty*, const
char*, const char* const*, const char* const*, const int*, int, const
int*, int, GSpawnFlags, GSpawnChildSetupFunc, gpointer, GDestroyNotify,
int, GCancellable*, GAsyncReadyCallback, gpointer): runtime check
failed: ((spawn_flags & ignored_spawn_flags()) == 0)

Is it necessary to emit this warning even if no special SpawnFlags are
needed for the application?

Bug#996083: filezilla FTBFS with libfilezilla19

[Adrian Bunk]

Source: filezilla
Version: 3.52.2-3
Severity: serious
Tags: ftbfs bookworm sid
Control: close -1 3.55.1-1

https://buildd.debian.org/status/logs.php?pkg=filezilla=3.52.2-3%2Bb1

...
writer.cpp: In member function ‘aio_result file_writer::open(uint64_t, bool, 
aio_base::shm_flag)’:
writer.cpp:309:56: error: cannot convert ‘bool’ to ‘fz::mkdir_permissions’
  309 |   fz::mkdir(fz::to_native(local_path.GetPath()), true, false, 
_created);
  |^
  ||
  |bool
In file included from writer.cpp:3:
/usr/include/libfilezilla/local_filesys.hpp:182:99: note:   initializing 
argument 3 of ‘fz::result fz::mkdir(const native_string&, bool, 
fz::mkdir_permissions, fz::native_string*)’
  182 | result FZ_PUBLIC_SYMBOL mkdir(native_string const& absolute_path, bool 
recurse, mkdir_permissions permissions = mkdir_permissions::normal, 
native_string * last_created = nullptr);
  | 
~~^~~
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -std=c++17 
-DHAVE_CONFIG_H   -I../../config -I/usr/include/p11-kit-1 -DBUILDING_FILEZILLA 
-Wdate-time -D_FORTIFY_SOURCE=2 -fvisibility=hidden -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -c -o ftp/libfzclient_private_la-delete.lo `test 
-f 'ftp/delete.cpp' || echo './'`ftp/delete.cpp
make[4]: *** [Makefile:1351: libfzclient_private_la-writer.lo] Error 1



This is already fixed in the version at mentors.debian.net (#994495).

Bug#996028: [debian-mysql] Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Ondrej Zary]

On Sunday 10 October 2021 16:55:45 Otto Kekäläinen wrote:
> Hello!
> 
> Thanks for reporting. Could you please check if this has been reported
> upstream at jira.mariadb.org?
> 
> There isn't much we can do about InnoDB internals in Debian packaging.
> 

The problem is in the ibdata1 file (about 450MB). Deleted other database 
directories and it still crashes, deleted ibdata1 and it runs.

How to bisect mariadb from git? Tried:
$ git bisect good mariadb-10.3.29
$ git bisect bad mariadb-10.3.31
the build process showed version 10.2 so I aborted it.

Checked out mariadb-10.3.30 but dpkg-buildpackage failed with:
dh_install: mariadb-plugin-cassandra missing files: 
etc/mysql/conf.d/cassandra.cnf

-- 
Ondrej Zary

Bug#996059: [Pkg-rust-maintainers] Bug#996059: exa: missing man page and shell completion scripts

[Sylvestre Ledru]

Le 10/10/2021 à 22:21, Mélanie (ariasuni) a écrit :
> Package: exa
> Version: 0.10.1-1
>
> Upstream bug: https://github.com/ogham/exa/issues/966
>
> Packages contain only the following files:
> /usr/bin/exa
> /usr/share/doc/exa/changelog.Debian.gz
> /usr/share/doc/exa/copyright
> /usr/share/man/man1/exa.1.gz
>
> It lacks the man page exa_colors.5, and the completions for fish, zsh
> and Bash.
>
> Also see:
> – Where the man pages are generated by just in the Justfile:
> https://github.com/ogham/exa/blob/0cebf3ad1c1f051096733f8c3a2d83aa73b5a659/Justfile#L98
> – How it’s done with cargo-deb:
> https://github.com/ogham/exa/blob/0cebf3ad1c1f051096733f8c3a2d83aa73b5a659/Cargo.toml#L65
>
> ___

Thanks for the bug report, I (almost) fixed them in the repo, I will
upload it demain! ;)

Cheers

S

Bug#988461: needrestart: False positive for sddm

[Thomas Liske]

tags 988461 upstream fixed-upstream
thanks


Hi,

thanks for reporting. I've updated the default configuration upstream
to ignore the all memfd mappings. The bugfix will be part of
needrestart 3.6+.


Regards,
Thomas


On Thu, 2021-05-13 at 14:44 +0200, Michail Bachmann wrote:
> Package: needrestart
> Version: 3.5-4
> Severity: normal
> 
> Dear Maintainer,
> 
> when running needrestart it always suggest that sddm needs to be
> restarted,
> even when sddm ist fresly (re-)started and no update has taken place.
> 
> Running needrestart -v gives the following explanation:
> 
> ...
> [main] #1244357 uses deleted /memfd:JITCode:QtQml
> [main] #1244357 is a child of #1244355
> [main] #1244355 exe => /usr/lib/x86_64-linux-gnu/sddm/sddm-helper
> ...
> 
> It looks like the JIT compiled Qt code erroneously triggers the
> detection.
> Adding "qr(^/memfd:JITCode:QtQml)," to the blacklist_mappings
> silences this
> warning. Would you consider to add this exception to the needrestart
> package?
> 
> Regards
> 
> Michail Bachmann
> 
> 
> -- Package-specific info:
> needrestart output:
> 
> checkrestart output:
> 
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
> Locale: LANG=C.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages needrestart depends on:
> ii  binutils   2.35.2-2
> ii  dpkg   1.20.9
> ii  gettext-base   0.21-4
> ii  libintl-perl   1.26-3
> ii  libmodule-find-perl    0.15-1
> ii  libmodule-scandeps-perl    1.30-1
> ii  libproc-processtable-perl  0.59-2+b1
> ii  libsort-naturally-perl 1.03-2
> ii  libterm-readkey-perl   2.38-1+b2
> ii  perl   5.32.1-4
> ii  xz-utils   5.2.5-2
> 
> Versions of packages needrestart recommends:
> ii  libpam-systemd  247.3-5
> 
> Versions of packages needrestart suggests:
> ii  iucode-tool  2.3.1-1
> pn  needrestart-session | libnotify-bin  
> 
> -- no debconf information
> 

Bug#972674: ITP: toolbox -- Unprivileged container development environment

[Andrej Shadura]

Hi,

On Wed, 10 Feb 2021 15:28:29 -0300 Andre Moreira Magalhaes
 wrote:
> Hi,
> 
> I ended up using this packaging as base for Endless OS and pushed
> the updated packaging to
> https://salsa.debian.org/andrunko-guest/toolbox/ (incl. update to
> 0.0.99).
> 
> The packaging still needs some work, specially regarding the two extra
> modules not yet packaged in Debian (see "debian/gocode"), but it works
> fine as is.
> 
> I also checked about using dh-golang but I don't think we should do it
> here tbh, unless upstream changes their build system from meson to go
> (the current repo dir structure doesn't play well with dh-golang).
> 
> I don't plan to work on this anymore atm but thought I'd share our
> changes in case anyone find them useful.

I took your packaging, dropped one of the vendored packages having
updated it in Debian, and uploaded it to NEW.

The Git repository is now located here:
https://salsa.debian.org/debian/podman-toolbox

-- 
Cheers,
  Andrej

Bug#994407: Binaries with same name

[Thomas Liske]

Hi,

@Patrick

this looks like a regression of #752114, doesn't it?


Regards,
Thomas


On Wed, 2021-09-15 at 18:22 +0200, ThePPK wrote:
> Package: needrestart
> Version: 3.5-4
> 
> Needrestart while run once of scripts on 
> /etc/needrestart/hook.d/30-pacman, execute pacman binary (which is
> Arch 
> Linux package manager). In Debian we have a game with this same 
> executable file name, 'pacman' and needrestart create process of
> pacman 
> what run game window.
> It's possible to force change name of pacman game or block running 
> script while pacman (package manager) isn't installed in /sbin/,
> /bin/, 
> /usr/bin/ or /usr/sbin/?
> 

Bug#984138: fs-uae: ftbfs with GCC-11

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

Hi!

On 3/3/21 17:12, Matthias Klose wrote:
> The package fails to build in a test rebuild on at least amd64 with
> gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The
> severity of this report will be raised before the bookworm release,
> so nothing has to be done for the bullseye release.

FWIW, upstream has fixed the issue on the stable branch already [1], see
attached patch. I'm just waiting for the upcoming stable version to be
released.

I'll then uploaded the fixed version immediately.

Adrian

> [1] 
> https://github.com/FrodeSolheim/fs-uae/commit/bf81e7d2a60b2c8646663889e4a4431b988ae972

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
From bf81e7d2a60b2c8646663889e4a4431b988ae972 Mon Sep 17 00:00:00 2001
From: Frode Solheim 
Date: Fri, 8 Oct 2021 11:39:16 +0200
Subject: [PATCH] Work around an incompatibility with C++17

---
 src/dosbox/setup.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/dosbox/setup.h b/src/dosbox/setup.h
index db75ada8..e0a3a75d 100644
--- a/src/dosbox/setup.h
+++ b/src/dosbox/setup.h
@@ -54,6 +54,12 @@ public:

 };
 
+#ifdef FSUAE
+// Work around an incompatibility with C++17. It does not seem like these
+// functions are used anyway.
+#define throw(...) throw()
+#endif
+
 class Value {
 /* 
  * Multitype storage container that is aware of the currently stored type in it.
@@ -113,6 +119,11 @@ private:
 	void set_double(std::string const& in);
 };
 
+#ifdef FSUAE
+#undef throw
+#endif
+
+
 class Property {
 public:
 	struct Changeable { enum Value {Always, WhenIdle,OnlyAtStart};};
-- 
2.33.0

Bug#222334: link to test page

[Thomas Lange]

We may add this link which shows your browser language settings

https://manytools.org/http-html-text/browser-language/

-- 
viele Grüße Thomas

Bug#988027: klibc: sigsetjmp ignores second argument, siglongjmp always restores signals

[Thorsten Glaser]

close 988027
thanks

I guess it works as documented for klibc, even though this is a porting
hindrance so no need to keep this bugreport open. Deliberately closing
per control instead of done as the underlying issue is still present.

Bug#996085: mrtg: Wrong manpage level: mrtglib.1

[Joao Eriberto Mota Filho]

Package: mrtg
Version: 2.17.7-3
Severity: normal
Tags: upstream

Control: forwarded https://github.com/oetiker/mrtg/pull/48

Considering that mrtglib is a Perl Module, the right level for this
manpage is 3.

Eriberto

Bug#995850: lintian: more context is not always a good thing

[Thorsten Glaser]

Felix Lechner dixit:

>By the way, you should also be able to use the wildcards * and ? in
>lieu of the line numbers right now. Please let me know if that works.

So indeed:

-mksh source: debian-watch-uses-insecure-uri 
http://www.mirbsd.org/MirOS/dist/mir/mksh/
+mksh source: debian-watch-uses-insecure-uri 
http://www.mirbsd.org/MirOS/dist/mir/mksh/ (line *)

-mksh: typo-in-manual-page usr/share/man/man1/mksh.1.gz ot to
+mksh: typo-in-manual-page usr/share/man/man1/mksh.1.gz line * ot to

These changes correctly override the issues.

I’ve not yet tested (e.g. by inserting an actual misspelling into the
manpage) whether the asterisk indeed allows anything to come after,
i.e. “line * ot to” isn’t equivalent to “line *”…

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

Bug#996089: lintian: False positive for missing-build-dependency-for-dh-addon (either Build-Depends-Indep or B-D's Provides seem ignored)

[Axel Beckert]

Package: lintian
Version: 2.108.0
Severity: normal

While working on the dhcpy6d package, I noticed the following
error-level tag that lintian emitted:

  E: dhcpy6d source: missing-build-dependency-for-dh-addon python3 => 
python3:any | python3-all:any | python3-dev:any | python3-all-dev:any | 
dh-sequence-python3

But the package does have such a build-dependency:

  Build-Depends-Indep: dh-python

And the dh-python package provides one of the listed dependencies deemed
missing:

  Package: dh-python
  Version: 4.20201102+nmu1
  […]
  Provides: dh-sequence-pypy, dh-sequence-python2, dh-sequence-python3

Not sure if the fact that Build-Depends-Indep is used or the fact that
the build-dependency uses Provides is overseen by lintian.

IIRC, when I uploaded 1.0.5-1 on 15th of August 2021 this tag wasn't
emitted and the package also built fine in pbuilder as well as on the
buildds. No related changes in debian/control since then.

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

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

Versions of packages lintian depends on:
ii  binutils2.37-7
ii  bzip2   1.0.8-4
ii  clzip   1.12-3
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.39-3
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.27-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.26-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdevel-size-perl  0.83-1+b2
ii  libdigest-sha-perl  6.02-1+b3
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libencode-perl  3.12-1
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-2
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.118-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.611-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.13-1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012004-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.08-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.83+ds-1
ii  lzip1.22-4
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.32.1-6
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.37-7
ii  libtext-template-perl  1.60-1

-- no debconf information

Bug#996015: debian-faq: remove obsolete usenet links / Re: Debian FAQ Usenet newsgroup

[Joost van Baal-Ilić]

Package: debian-faq
Severity: normal

Hi Sebul,

On Sun, Oct 10, 2021 at 05:07:34AM +0900, sebul / https://sebuls.blogspot.kr
wrote:
> Hello.
> https://www.debian.org/doc/manuals/debian-faq/support.en.html#s12.2.5
> 12.2.5. Usenet newsgroups
> say Linux Online and LinuxJournal
> But these links say page not found.
> 
> Where is usenet for debian?

These links are obsolete and should be removed.  I don't think there's
a specific usenet group dedicated to Debian; and I'm not quite sure
we should refer to one if such a group would exist.

Thanks for bringing this up.

(Now reporting this in our Bugtracking System; Patches welcome! :-)

Bye,

Joost

Bug#996077: gnome-shell-mailnag: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-mailnag
Version: 40.0-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996078: gnome-shell-pomodoro: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-pomodoro
Version: 0.18.0-0.1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996075: gnome-shell-extension-volume-mixer: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-volume-mixer
Version: 40.0+dfsg-2
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996076: gnome-shell-extension-weather: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-weather
Version: 0.0~git20210509.d714eb1-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#995274: needrestart: false positive: rabbitmq-server

[Thomas Liske]

Hi,

could you please provide the output of `needrestart -lv`?


TIA,
Thomas


On Tue, 2021-09-28 at 20:34 -0300, Antonio Terceiro wrote:
> Package: needrestart
> Version: 3.5-4
> Severity: normal
> 
> Dear Maintainer,
> 
> Recently every time I install something, needrestart seems to think
> that
> rabbitmq-server needs to be restart, even when there were norelated
> upgrades. I tried calling needrestart right after booting, and even
> then
> it reported rabbitmq-server as needing a restart.
> 
> This can easily be reproduced in a clean testin VM:
> 
> 8<8<8<---
> --
> root@host:~# apt update -q=2
> 20 packages can be upgraded. Run 'apt list --upgradable' to see them.
> root@host:~# apt install -q=2 -y needrestart
> [...]
> root@host:~# apt install -q=2 -y rabbitmq-server
> [...]
> Package configuration
> 
> 
> 
> 
> 
>     ┌┤ Daemons using outdated libraries ├─┐
>     │ │
>     │ │
>     │ Which services should be restarted? │
>     │ │
>     │    [*] rabbitmq-server.service  │
>     │ │
>     │ │
>     │     │
>     │ │
>     └─┘
> 
> 
> 
> 
> 
> 
>  systemctl restart rabbitmq-server.service
> 
> No containers need to be restarted.
> 
> No user sessions are running outdated binaries.
> 8<8<8<---
> --
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (500,
> 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
> LANGUAGE=pt_BR:pt:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages needrestart depends on:
> ii  binutils   2.37-7
> ii  dpkg   1.20.9
> ii  gettext-base   0.21-4
> ii  libintl-perl   1.26-3
> ii  libmodule-find-perl    0.15-1
> ii  libmodule-scandeps-perl    1.31-1
> ii  libproc-processtable-perl  0.611-1
> ii  libsort-naturally-perl 1.03-2
> ii  libterm-readkey-perl   2.38-1+b2
> ii  perl   5.32.1-6
> ii  xz-utils   5.2.5-2
> 
> Versions of packages needrestart recommends:
> ii  libpam-systemd  247.9-1
> 
> Versions of packages needrestart suggests:
> ii  iucode-tool    2.3.1-1
> ii  libnotify-bin  0.7.9-3
> 
> -- no debconf information

Bug#931345: nvchecker: autopkgtest regression in June 2019

[Afif Elghraoui]

Hello,

On 11/12/20 2:11 AM, Paul Gevers wrote:
> severity 931345 serious
> user debian...@lists.debian.org
> usertag 931345 timeout
> thanks
> 
> please upload a fixed package.
> 
> The test if timing out nowadays too, so I'll block it from being tested
> to avoid stress on our infrastructure until this bug is fixed.
> 

This bug has been fixed for about a week now but nvchecker still appears
to be blocked from debci. Does that need to be manually changed? I
expected it to be removed automatically once the bug was closed.

thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
https://afif.ghraoui.name

Bug#996036: LXD: snap lxd cgroup noise causes VirtSubproc to fail

[Stefano Rivera]

Hi Paul (2021.10.10_11:59:12_-0700)
> Shouldn't that bug be raised in severity, considering the request you
> are now asking from autopkgtest? I'm not really enthusiastic to add this
> kind of "work around" code for a bug that's already known for 2 years.
> Maybe there should be a warning in snapd to silence that warning?

Yeah, I'm with you on that. It's an annoying message.

Also, found another place I had to hack (my local hacks all got blown
away by the recent autopkgtest upload, so it was a good time to forward
them...)

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272
From 084996eb89aa99f2907ed24b5d4c83f5f7480610 Mon Sep 17 00:00:00 2001
From: Stefano Rivera 
Date: Sun, 10 Oct 2021 10:58:37 -0700
Subject: [PATCH] Ignore innoccuous warnings from snapped lxd

They don't mean that the command has failed
---
 lib/VirtSubproc.py | 4 
 lib/adt_testbed.py | 5 +
 2 files changed, 9 insertions(+)

diff --git a/lib/VirtSubproc.py b/lib/VirtSubproc.py
index bf948e6..01acdaa 100644
--- a/lib/VirtSubproc.py
+++ b/lib/VirtSubproc.py
@@ -186,6 +186,10 @@ def check_exec(argv, downp=False, outp=False, timeout=0, fail_on_stderr=True):
 if status:
 bomb("%s%s failed (exit status %d, stderr %r)" %
  ((downp and "(down) " or ""), argv, status, err))
+# Ignore innoccuous warnings from snapped lxd
+if (err == 'WARNING: cgroup v2 is not fully supported yet, proceeding with '
+   'partial confinement\n'):
+err = ''
 if fail_on_stderr and err:
 bomb("%s unexpectedly produced stderr output `%s'" %
  (argv, err))
diff --git a/lib/adt_testbed.py b/lib/adt_testbed.py
index 9965e5d..909213c 100644
--- a/lib/adt_testbed.py
+++ b/lib/adt_testbed.py
@@ -554,6 +554,11 @@ class Testbed:
 self.command('auxverb_debug_fail')
 self.bomb('testbed auxverb failed with exit code %i' % proc.returncode)
 
+# Ignore innoccuous warnings from snapped lxd
+if (err == 'WARNING: cgroup v2 is not fully supported yet, proceeding '
+   'with partial confinement\n'):
+err = ''
+
 return (proc.returncode, out, err)
 
 def check_exec(self, argv, stdout=False, kind='short'):
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#996028: [debian-mysql] Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Otto Kekäläinen]

> The problem is in the ibdata1 file (about 450MB). Deleted other database 
> directories and it still crashes, deleted ibdata1 and it runs.
>
> How to bisect mariadb from git? Tried:
> $ git bisect good mariadb-10.3.29
> $ git bisect bad mariadb-10.3.31
> the build process showed version 10.2 so I aborted it.
>
> Checked out mariadb-10.3.30 but dpkg-buildpackage failed with:
> dh_install: mariadb-plugin-cassandra missing files: 
> etc/mysql/conf.d/cassandra.cnf

Some dependency was missing and Cassandra was not built. Note that the
upstream repository is not identical to the one in Debian regarding
the contents of debian/ directory. MariaDB builds without a cache take
30 mins each and there are all kinds of things going on. Doing bisect
(fully correctly) on MariaDB is hard even for experienced developers.
Your time is probably better spent doing some other kind of debugging.

I recommend that you file a bug about this upstream, and try to attach
relevant info from the error log, maybe a strace output etc. Upstream
devs will guide you on what to debug next.

One thing you could also try is to start the server with 10.3.29 and
ensure that you have a clean shutdown (SET GLOBAL
innodb_fast_shutdown=0; SHUTDOWN) and only after that start with the
new 10.3.31 binary.

Ref
- https://mariadb.com/kb/en/shutdown/#see-also
- https://www.percona.com/blog/2020/05/07/prepare-mysql-for-a-safe-shutdown/

Bug#996086: RM: pangox-compat/0.0.2-5.1

[Simon McVittie]

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

pangox-compat is dead upstream and should be removed from testing, or
removed from Debian altogether (#947649), but it has been kept in testing
by its high popcon score (the legacy libpango1.0-0 package depended on it,
resulting in lots of installations).

It can't be removed from unstable until drbd-doc stops depending on it or
is removed (#993661), and then gtkmathview stops depending on it or is
removed (#702011); but it can at least be removed from testing.

smcv

Bug#521449: Non-working scripts....

[Eriberto Mota]

Control: tags -1 wontfix

Dear Adam,

Considering these scripts are examples from several people, is very
hard to the upstream keep them updated. Please, think in these files
as ideas to write new scripts.

Regards,

Eriberto

Bug#994275: Reverting breaking changes in debianutils

[Simon McVittie]

On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote:
> The release team has so far protected users of testing from the
> problem by blocking testing migration, but this is not a long-term
> solution.

Adrian asked in #994275 for changes in several topics to be reverted:

- which(1) deprecation
  - deprecation warnings on stderr
  - management via alternatives
  - possible future removal
- tempfile(1) removal
- installkernel(8) moving from /sbin to /usr/sbin
- run-parts(8) moving from /bin to /usr/bin

Which of those topics were your reason for adding a "block debianutils"
hint? Are there any of those topics whose resolution you would consider
to be a prerequisite for letting debianutils migrate to testing again?

The hint references #992399, which is related to tempfile(1), but
#992399 has been closed (via a merge with #992396, which was resolved by
debianutils adding a versioned Breaks on x11-common versions that needed
tempfile). Do the release team consider #992399 to have been adequately
resolved, or do you consider debianutils to still have a RC bug?

If debianutils reinstated tempfile(1) in bookworm, and removed it in
testing/unstable after the release of bookworm, would the release team
consider that to be an adequate transitional period?

Thanks,
smcv

Bug#901307: sphinx-gallery: please make the build mostly reproducible

[Sandro Tosi]

> Friendly ping on this?

this was supposed to be fixed when i uploaded that version. Anyhow,
i've just uploaded 0.10.0 to unstable, can you  check that version
out? if it's still FTBR maybe give a ping upstream about it?

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#996068: gnome-shell-extension-panel-osd: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-panel-osd
Version: 1.0.50.gc032923-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996069: gnome-shell-extension-pixelsaver: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-pixelsaver
Version: 1.24-2
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996053: New Url to package with close of bug in changelog

[Erik A. Brandstadmoen]

I created a new version of the package, which closes this bug in the changelog:

https://github.com/erikbra/grate/releases/download/0.9.4/grate_0.9.4-2_amd64.deb

Regards, Erik B.

Bug#996073: gnome-shell-extension-top-icons-plus: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-top-icons-plus
Version: 27-4
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996074: gnome-shell-extension-trash: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-trash
Version: 0.2.0-git20200326.3425fcf1-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#994275: Reverting breaking changes in debianutils

[Simon McVittie]

On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote:
> More specifically, I am asking the Technical Committee to decide that:

I think this is really 5 separate (but related) requests, each of which
we could either uphold or decline, separately. Do you agree?

> 1. The "which" program must be provided by an essential package.

Constitutionally, I think this would have to be the TC formally offering
advice (under 6.1.5 in the Debian constitution), because the maintainers
of debianutils haven't attempted to remove "which", so there is not
yet any maintainer action that you want us to overrule.

For example, that advice could take the form of saying that if which(1)
is removed from debianutils in future, then we would expect that to be
accompanied by a suitable versioned dependency on a transitively-Essential
package that provides which(1) (either for bookworm, or indefinitely).

Does that sound right to you?

Or are you asking us to go further than that, and say that which(1)
can only be removed from debianutils if it is picked up by a different
Essential package?

> 2. The "which" program must not print any deprecation warnings.

I think that's a request to overrule the maintainer of debianutils
(under 6.1.4). I assume that was your intention?

> 3. The "which" program must not be provided through alternatives.

Also 6.1.4, I think.

> 4. The debianutils package must continue to provide the "tempfile" program.

Also 6.1.4.

Would you be equally happy with a TC resolution that keeps tempfile(1) in
the transitively-Essential set, but not necessarily via debianutils? For
example, we could consider saying that debianutils must either reinstate
tempfile(1), or add a dependency on some other (transitively Essential)
package that provides tempfile(1).

> 5. Programs in debianutils must not be moved to /usr unless there is
>project-wide consensus on packages doing such a move, and premature
>moving must be reverted.

Also 6.1.4.

smcv

Bug#981446: RFA: logcheck -- mails anomalies in the system logfiles to the administrator

[Charles]

Hi

On 10/10/2021 22:09, Hannes von Haugwitz wrote:


@Jose Do you still plan to adopt logcheck? You might want to collaborate
with Richard and Charles to maintain the package all together.


Is there an email list to enable collaboration and discussion?


You can use the #logcheck channel on the OFTC IRC network to collaborate
and discuss logcheck with some users and previous maintainers.

Best regards

Hannes


I am happy to collaborate with Jose and Richard as logcheck maintainers 
and to discuss logcheck in the #logcheck channel on the OFTC IRC network

Bug#996067: gnome-shell-extension-no-annoyance: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-no-annoyance
Version: 0+20210717-12dc667-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996070: gnome-shell-extension-sound-device-chooser: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-sound-device-chooser
Version: 38-2
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996071: gnome-shell-extension-system-monitor: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-system-monitor
Version: 40-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996072: gnome-shell-extension-tilix-dropdown: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-tilix-dropdown
Version: 7-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996081: exa: description on packages.debian.org has last three words formatted as monospace

[ariasuni]

Package: exa
Version: 0.10.1-1

On packages.debian.org, e.g. https://packages.debian.org/sid/exa, exa’s 
description appears like that (in HTML):



exa is an improved file lister with more features and better defaults.
It uses colours to distinguish file types and metadata. It knows about
symlinks, extended attributes, and Git. And it’s small, fast, and just
 one single binary.


The three last words shouldn’t be formatted in any particular way and 
should be displayed with the rest of the sentence.

Bug#364913: still valid?

[Thomas Lange]

Is this bug still valid or can we close this bug?
-- 
regards Thomas

Bug#986507: use grep -a instead of strings(1) (fix check-support-status)

[Thomas Liske]

tags 986507 upstream fixed-upstream
thanks


Hi,

thanks for the hint. I've applied a slitly modified patch upstream to
replace binutils's strings by grep in needrestart 3.6+.

Replacing the bintuils dependency by GNU grep lowers the total
installation size by an order of magnitude.


Regards,
Thomas

On Fri, 2021-10-08 at 15:56 +1100, Trent W. Buck wrote:
> Trent W. Buck wrote:
> > I want check-support-status to be happy, but I need needrestart:
> > 
> >     bash5$ check-support-status
> >     ⋮
> >     * Source:binutils
> >   Details: Only suitable for trusted content; see
> > https://lists.debian.org/msgid-search/87lfqsomtg@mid.deneb.enyo.de
> >     ⋮
> > 
> >     bash5$ aptitude why binutils
> >     i   needrestart Depends binutils
> 
> This annoyed me again today.
> I noticed an even simple patch is to use "grep -ao".
> This is working for me.
> 
> You are already using "grep -a" elsewhere in the script, so
> this is only assuming grep supports -o.
> GNU grep supports both; busybox grep supports neither.

Bug#925358: qemu-user-static: mis-emulates something to do with process/signal handling

[Thorsten Glaser]

Version: 1:5.2+dfsg-11+deb11u1

On Fri, 25 Oct 2019, Thorsten Glaser wrote:

> This now happens with qemu-s390x-static for me as well, which has

Reconfirmed on bullseye, using usr/lib/klibc/bin/mksh from sid’s
mksh_59c-11_s390x.deb binary package. (I’m about to upload -12,
but I assume it’ll not differ.)

I’ve rechecked because I did things in both klibc and mksh in the
meantime to fix things, but this issue is still present.

Using usr/lib/diet/bin/mksh, usr/lib/s390x-linux-musl/bin/mksh
from the binary package work, so it must be something klibc does.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#995274: needrestart: false positive: rabbitmq-server

[Antonio Terceiro]

On Sun, Oct 10, 2021 at 10:51:13PM +0200, Thomas Liske wrote:
> Hi,
> 
> could you please provide the output of `needrestart -lv`?

Sure:

8<8<8<-
$ sudo needrestart -lv
[main] eval /etc/needrestart/needrestart.conf
[main] needrestart v3.5
[main] running in root mode
[Core] Using UI 'NeedRestart::UI::stdio'...
[main] systemd detected
[main] #968 uses deleted /memfd:vmem
[main] #968 is not a child
[Core] #2617 is a NeedRestart::Interp::Python
[Python] #2617: source=/home/terceiro/src/localslackirc/irc.py
[Core] #65382 is a NeedRestart::Interp::Python
[Python] #65382: source=/usr/bin/terminator
[Core] #90184 is a NeedRestart::Interp::Python
[Python] #90184: 
source=/usr/lib/python3/dist-packages/gbp/scripts/supercommand.py
[Core] #90219 is a NeedRestart::Interp::Perl
[Perl] #90219: source=/usr/bin/dpkg-buildpackage
[Core] #90247 is a NeedRestart::Interp::Perl
[Perl] #90247: source=/usr/bin/dh
[Core] #90274 is a NeedRestart::Interp::Python
[Python] #90274: 
source=/home/terceiro/src/debian/python/build-area/typeshed-0.0~git20211009.0142ea8.obsolete.1633904505.3296812/debian/install_stubs.py
[Core] #92031 is a NeedRestart::Interp::Python
[Python] #92031: source file not found, skipping
[Python] #92031:  reduced ARGV: install --system 
--target=debian/python3-typeshed/usr/lib/python3/dist-packages 
/tmp/tmpwowqtmgb/dist/types_httplib2-0.19.1-py3-none-any.whl
[main] #968 exe => /usr/lib/erlang/erts-12.0.4/bin/beam.smp
[main] trying systemctl status
[main] #968 is rabbitmq-server.service

Restarting services...
Services to be restarted:
Restart «rabbitmq-server.service»? [Ynas?] n
Service restarts being deferred:
 systemctl restart rabbitmq-server.service

No containers need to be restarted.

No user sessions are running outdated binaries.
8<8<8<-



signature.asc
Description: PGP signature

Bug#996084: vte2.91: wrong argument list in spawn_async documentation

[Simon McVittie]

On Sun, 10 Oct 2021 at 23:07:35 +0200, Nis Martensen wrote:
> According to
> https://lazka.github.io/pgi-docs/Vte-2.91/classes/Terminal.html#Vte.Terminal.spawn_async
> and
> https://lazka.github.io/pgi-docs/#Vte-2.91/classes/Pty.html#Vte.Pty.spawn_async
> the order of arguments includes:
> ..., spawn_flags, child_setup, timeout, ...
> 
> However, the code does not work when trying to use that argument order,
> the result is: TypeError: Argument 9 does not allow None as a value
> 
> It would be great if the code and its documentation would match.

Debian does not maintain that documentation, and the representation of
C functions in PyGI is really a question for PyGI rather than the specific
C library whose API has been wrapped.

The signature of these functions in C is:

void vte_terminal_spawn_async(VteTerminal *terminal,
  VtePtyFlags pty_flags,
  const char *working_directory,
  char **argv,
  char **envv,
  GSpawnFlags spawn_flags,
  GSpawnChildSetupFunc child_setup,
  gpointer child_setup_data,
  GDestroyNotify child_setup_data_destroy,
  int timeout,
  GCancellable *cancellable,
  VteTerminalSpawnAsyncCallback callback,
  gpointer user_data) _VTE_CXX_NOEXCEPT 
_VTE_GNUC_NONNULL(1) _VTE_GNUC_NONNULL(4);
void vte_pty_spawn_async(VtePty *pty,
 const char *working_directory,
 char **argv,
 char **envv,
 GSpawnFlags spawn_flags,
 GSpawnChildSetupFunc child_setup,
 gpointer child_setup_data,
 GDestroyNotify child_setup_data_destroy,
 int timeout,
 GCancellable *cancellable,
 GAsyncReadyCallback callback,
 gpointer user_data) _VTE_CXX_NOEXCEPT 
_VTE_GNUC_NONNULL(1) _VTE_GNUC_NONNULL(3);

and you can find the GObject-Introspection representation of them in
/usr/share/gir-1.0/Vte-2.91.gir.

It looks as though whatever software generated
https://lazka.github.io/pgi-docs/Vte-2.91 is assuming that the
(child_setup, child_setup_data, child_setup_data_destroy) group
will come out in PyGI as a single argument, child_setup.

However, from the stackoverflow question, it looks like child_setup
and child_setup_data turn into separate arguments in Python, with
only child_setup_data_destroy disappearing.

This seems like a bug in the documentation-generating tool.

smcv

Bug#996087: ITP: typeshed -- collection of library stubs for Python, with static types

[Antonio Terceiro]

Package: wnpp
Severity: wishlist
Owner: Antonio Terceiro 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: typeshed
  Version : n/a
  Upstream Author : Several authors
* URL : https://github.com/python/typeshed
* License : Apache 2.0
  Programming Lang: Python
  Description : collection of library stubs for Python, with static types

 Typeshed contains external type annotations for the Python standard library
 and Python builtins, as well as third party packages as contributed by people
 external to those projects.

 This data can e.g. be used for static analysis, type checking or type
 inference.

 typeshed has been extracted from mypy, and is necessary in order to
 have type checking work for libraries that still don't provide their
 own type anotations. Users are encouraged to install individual types-*
 wheels, but this package will provide all the typing information in a
 single binary package.

 Preliminary packaging available at
 https://salsa.debian.org/terceiro/typeshed and will be moved into the
 Python team soon™.


signature.asc
Description: PGP signature

Bug#995850: lintian: more context is not always a good thing

[Felix Lechner]

Hi,

On Sun, Oct 10, 2021 at 3:33 PM Thorsten Glaser  wrote:
>
> I’ve not yet tested ...
> whether the asterisk indeed allows anything to come after,
> i.e. “line * ot to” isn’t equivalent to “line *”…

I am not sure it's a good feature, but it should work. [1][2]

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Processable/Overrides.pm#L278
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Group.pm#L374

Bug#995392: ghostscript: ps2pdf trashes some characters

[Norbert Preining]

severity 995392 normal
tags 995392 + moreinfo
thanks

Hi all,

first of all, it seems this message didn't make it either to the list or
my computer, just found it by randomly checking transitioning.

Then, this is by far not a grave bug in TL. pdflatex is **not**
affected, since it generated pdf files without using ghostscript.

What might have some problems - and I haven't reproduced this till now
nor tested - is dvi -> ps -> pdf route.

>   * chartest3.tex:  Test: « don't ».
>   * chartest4[ab].tex:  Test: « don't finite float ».
>   * chartest5[ab].tex:  Test: « don't finite float offer affine ».
> where the 4b and 5b versions contain \pdfglyphtounicode commands for
> the ligatures (from glyphtounicode.tex), though the tests below show
> that they do not have any influence here.

Vincent, thanks for the tests, but without explanation or make files or
some hints on **what** you did run, this is not reproducible and
testable.

What I want to see is
* input file
* commands run
* log files of each program run
* what is the problematic output

Thanks

> \documentclass[12pt]{article}
> \usepackage[utf8]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage{lmodern}
> \begin{document}
> \thispagestyle{empty}
> Test: « don't ».
> \end{document}

This document and copy and paste of its content does work fine for me
with
* current sid
* latex/dvips/ps2pdf
* pdflatex

Generated pdf file can be copy/pasted.

I really don't see what is going on, thanks for any explanations.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#996084: vte2.91: wrong argument list in spawn_async documentation

[Nis Martensen]

Source: vte2.91
Version: 0.62.3-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: nis.marten...@web.de

According to
https://lazka.github.io/pgi-docs/Vte-2.91/classes/Terminal.html#Vte.Terminal.spawn_async
and
https://lazka.github.io/pgi-docs/#Vte-2.91/classes/Pty.html#Vte.Pty.spawn_async
the order of arguments includes:
..., spawn_flags, child_setup, timeout, ...

However, the code does not work when trying to use that argument order,
the result is: TypeError: Argument 9 does not allow None as a value

It would be great if the code and its documentation would match.

An example illustrating that there must be in fact two arguments
between the spawn_flags and the timeout can be found here:
https://stackoverflow.com/questions/55105447/virtual-python-shell-with-vte-pty-spawn-async

What is the correct list of arguments that the function takes?

Bug#996082: vte2.91: vte.terminal.spawn_async emits useless warning by default

[Simon McVittie]

Control: tags -1 + moreinfo

On Sun, 10 Oct 2021 at 22:51:10 +0200, Nis Martensen wrote:
> (reportbug:22755): VTE-WARNING **: 21:37:42.462:
> (../src/vtepty.cc:811):void vte_pty_spawn_with_fds_async(VtePty*, const
> char*, const char* const*, const char* const*, const int*, int, const
> int*, int, GSpawnFlags, GSpawnChildSetupFunc, gpointer, GDestroyNotify,
> int, GCancellable*, GAsyncReadyCallback, gpointer): runtime check
> failed: ((spawn_flags & ignored_spawn_flags()) == 0)

What exact function are you calling and what flags are you passing to it?

This warning should not appear unless spawn_flags contains one of the
flags that either are not available here, or have their behaviour
enabled by default anyway and therefore are unnecessary (namely
G_SPAWN_CLOEXEC_PIPES and/or G_SPAWN_DO_NOT_REAP_CHILD).

smcv

Bug#996088: ITP: r-cran-mpoly -- symbolic computing with multivariate polynomials in R

[Torrance, Douglas]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@piedmont.edu,

* Package name: r-cran-mpoly
 Version : 1.1.1
 Upstream Author : David Kahle 
* URL : https://github.com/dkahle/mpoly
* License : GPL
 Programming Lang: R
 Description : symbolic computing with multivariate polynomials in R

mpoly is a simple collection of tools to help deal with multivariate
polynomials symbolically and functionally in R.  Features include term
ordering, creating vectors of polynomials, extracting pieces of polynomials,
arithmetic, derivatives, evaluation, homogenization and dehomogenization, and
many special polynomials.

I intend to maintain this package under the umbrella of the Debian R team.


signature.asc
Description: PGP signature

Bug#996088: RFS: r-cran-mpoly

[Torrance, Douglas]

Control: tags -1 pending

I've just finished packaging r-cran-mpoly, which implements multivariate
polynomials in R.  Since it would be headed for the NEW queue and I'm a DM,
I'm unable to upload it.  Would anyone be able to review/sponsor?

https://salsa.debian.org/r-pkg-team/r-cran-mpoly

Thanks!
Doug


signature.asc
Description: PGP signature

Bug#996090: mrtg: Spelling error in a variable name

[Joao Eriberto Mota Filho]

Package: mrtg
Version: 2.17.7-3
Severity: important
Tags: upstream patch

Control: forwarded -1 https://github.com/oetiker/mrtg/pull/50

The following patch will fix a mistake in source code:



--- a/src/lib/mrtg2/MRTG_lib.pm
+++ b/src/lib/mrtg2/MRTG_lib.pm
@@ -1823,7 +1823,7 @@ sub populateconfcache ($) {
  push @{$$confcache{___updated}}, $hostkey;
 
 $SNMP_Session::suppress_warnings = $snmp_errlevel;
-$Net_SNMP_util::supress_warnings = $net_snmp_errlevel;
+$Net_SNMP_util::suppress_warnings = $net_snmp_errlevel;
 }
 
 sub log2rrd ($$$) {



Regards,

Eriberto

Bug#996022: transgui: Does not connect to 3.00 server, fails with 'Duplicate object member: "status"'

[Eduardo M Kalinowski]

Package: transgui
Version: 5.18.0+dfsg-1+b1
Severity: important
Tags: patch upstream

I upgraded my server that runs transmission-deamon to bullseye, the server is
now running version 3.00-1. This upgrade has rendered the client (running
testing) unable to connect, it fails with the message 'Duplicate object member:
"status"'.

This bug is not specific to Debian, and has been reported upstream at
https://github.com/transmission-remote-gui/transgui/issues/1325 . There's a
patch at https://github.com/transmission-remote-gui/transgui/pull/1329 that has
not been incorporated upstream yet (for over a year now), please consider
including that patch in the Debian package.



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

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

Versions of packages transgui depends on:
ii  libatk1.0-0  2.36.0-2
ii  libc62.32-4
ii  libcairo21.16.0-5
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.0-1+b1
ii  libgtk2.0-0  2.24.33-2
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libx11-6 2:1.7.2-2+b1

transgui recommends no packages.

transgui suggests no packages.

Bug#987160: gap-core: missing gap in /u/l/gap or gac in /u/l/x/gap

[Bill Allombert]

Le Sun, Oct 10, 2021 at 02:02:28PM +0200, Jerome BENOIT a écrit :
> Hello Bill, thanks for the correction and sorry for my late reaction.
> I have just updated the gap-io package accordingly. All looks fine.

Great!

> Meanwhile I have noticed that
> /usr/lib/gap/sysinfo.gap and /usr/lib/x86_64-linux-gnu/gap/sysinfo.gap
> are actually the same files.

Yes. I plan to remove /usr/lib/gap/sysinfo.gap once nobody use it
anymore. And idem for /usr/lib/gap/gac.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#996018: Acknowledgement (linux-image-5.10.0-9-amd64: linux/i2c/i2c-hid.h: Aucun fichier ou dossier de ce type)

[Jonas]

This is not the reason for the absence of kernels 5.10 at startup
After the migration to bullseye it was missing update-grub.

Bug#995990: systemctl --now flag has no effect in two circumstances

[MichaIng]

The LTS team has no interest in fixing this IMHO major usage bug on the 
init system?


Since we didn't see this earlier among user user base, chances are high 
that it has been caused by the last package update (security repo) from 
08 Jul 2021.


I'll try to verify this by pulling an earlier package from the regular 
repo and compare the behaviour with other architectures.


Best regards,

Micha

Bug#996030: transition: libsidplayfp

[GCS]

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

Hi RMs,

 Small transition of libsidplayfp, affecting audacious-plugins, mpd and qmmp.
I will upload its counterpart, sidplayfp when the transition is
allowed to start.

Regards,
Laszlo/GCS

Bug#970880: [Pkg-freeipa-devel] Bug#970880: Bug#970880: freeipa-server: FreeIPA server installation fails with Certificate issuance failed (CA_REJECTED)

[Spencer Olson]

Did some more investigation.  I downloaded the packages that are being used
on centos stream 8.  First I tried my test code with their version of
libssl3.so preloaded:  it failed in the same way as all the others
failed--not surprisingly since its version is much later than the 3.39
version where this changed.

Then, I downloaded and took a look at "dogtag-submit" from the CentOS
Stream 8 (RedHat) certmonger package.  As far as I can tell, their version
of "dogtag-submit" is *not* linked against libcurl-nss.so at all like the
version on debian sid.  Instead, all their certmonger helper programs are
linked against the OpenSSL version (libcurl.so.4).

So, I think that we should just link these against the openssl version, as
the RedHat packages do and get things to work again.

This raises two other issues:
- is there truly a bug in the ssl portion of the nss library?  If so, this
should probably be brought to the attention.
- perhaps the libcurl package ought to be reconfigured such that one can
install the dev packages simultaneously.  Right now, libcurl-nss also makes
a symlink "libcurl.so" that makes it conflict with the libcurl-openssl
package to which the "libcurl.so.x.x" lib belongs to.  I think that the
libcurl-gnutls package might do the same thing.

My next step will be do rebuild freeipa and certmonger with the
libcurl-openssl-dev package in place instead of the libcurl-nss-dev and
then try reinstalling.


On Sat, Oct 9, 2021 at 9:59 PM Spencer Olson  wrote:
>
> Cloned nss repo and did a git bisect:  the first commit that causes
> problems is at the upstream merge of 3.39 (upstream/3.39).
>
> From a very brief perusal of the upstream changes, I see there are
> some edits with respect to TLS1.3--perhaps this is the reason for our
> problems--I haven't yet looked hard at all the upstream changes (or
> tried to bisect the upstream repo yet).
>
> On Sat, Oct 9, 2021 at 12:05 PM Spencer Olson  wrote:
> >
> > Since it doesn't look like any progress has been made on this, I've
> > started to work through some debugging.
> >
> > Right now, it looks like the problem is probably actually due to a
> > change in libnss3.  In fact, the problem appears to be specifically in
> > libssl3.so from the libnss3 package.
> >
> > The problem:
> >   * certmonger has a hard time finishing the certificate requests
> > because it can't seem to authenticate to the dogtag PKI server.
> >
> > Observations:
> >  * When certmonger attempts to request a signed certificate for the
> > renewal agent, it temporarily explicitly uses the ipa-ca-agent
> > certificate which has been temporarily extracted from the
> > /root/ca-agent.p12 storage.
> >  * dogtag-submit attempts to use the CURL library to submit the
> > request, subsequently approve the request, and then poll for its
> > finish.
> >  * The initial request does not use/require an encrypted channel, but
> > the approval and subsequent queries do.
> >  * These attempts to authenticate over this encrypted channel using
> > the client certificate are rejected.
> >
> > Hacks & tests:
> >  * By creating a very small c-program that does the same CURL commands
> > as dogtag-submit from the certmonger package, this same authorization
> > denied can be seen.
> >  * By simply replacing the libssl3.so library, using either LD_PRELOAD
> > or LD_LIBRARY_PATH, from a prior version, the requests succeed.  As of
> > now, I've tried only one other version of libssl3.so (libnss3 3.35
> > from ubuntu 18.04).
> >  * Also, instead of linking against libcurl-nss and manualy replacing
> > the libssl3.so library, success can be found by linking to
> > libcurl-gnutls or libcurl-openssl
> >
> > I suspect that a compile option in libnss3 has to be changed in order
> > for this to work again.
> >
> > Still todo:
> >  * I haven't fully discovered which part/option from libnss3 might have
changed.
> >  * I haven't yet successfully had libnss3 emit much
> > debugging--probably have to recompile with DEBUG=1.

Bug#970880: [Pkg-freeipa-devel] Bug#970880: Bug#970880: Bug#970880: freeipa-server: FreeIPA server installation fails with Certificate issuance failed (CA_REJECTED)

[Timo Aaltonen]

On 10.10.2021 18.41, Spencer Olson wrote:
Did some more investigation.  I downloaded the packages that are being 
used on centos stream 8.  First I tried my test code with their version 
of libssl3.so preloaded:  it failed in the same way as all the others 
failed--not surprisingly since its version is much later than the 3.39 
version where this changed.


Then, I downloaded and took a look at "dogtag-submit" from the CentOS 
Stream 8 (RedHat) certmonger package.  As far as I can tell, their 
version of "dogtag-submit" is *not* linked against libcurl-nss.so at all 
like the version on debian sid.  Instead, all their certmonger helper 
programs are linked against the OpenSSL version (libcurl.so.4).


So, I think that we should just link these against the openssl version, 
as the RedHat packages do and get things to work again.


Hmm, thanks.. indeed certmonger is still built against libcurl4-nss-dev, 
I've changed it to openssl now and see how it goes against gitlab CI..



This raises two other issues:
- is there truly a bug in the ssl portion of the nss library?  If so, 
this should probably be brought to the attention.
- perhaps the libcurl package ought to be reconfigured such that one can 
install the dev packages simultaneously.  Right now, libcurl-nss also 
makes a symlink "libcurl.so" that makes it conflict with the 
libcurl-openssl package to which the "libcurl.so.x.x" lib belongs to.  I 
think that the libcurl-gnutls package might do the same thing.


My next step will be do rebuild freeipa and certmonger with the 
libcurl-openssl-dev package in place instead of the libcurl-nss-dev and 
then try reinstalling.


No need to rebuild freeipa.


--
t

Bug#946826: (no subject)

[Mike Gerber]

notfound 946826 0.11.2-2

fixed 946826 0.11.2-2

thanks


This is fixed in 0.11.2-2 (bullseye).

Bug#983588: xmlgraphics-commons: reproducible builds: Set timezone to UTC when SOURCE_DATE_EPOCH is set

[tony mancill]

On Fri, Oct 08, 2021 at 06:16:33PM -0700, Vagrant Cascadian wrote:
> On 2021-02-26, Vagrant Cascadian wrote:
> 
> This should fix reproducibility issues in several other packages; is
> there anything else I can do to help getting this fix into Debian?

Err.. no, this is 100% on me.  I will prepare an upload soon.

Thank you for the patch!
tony


signature.asc
Description: PGP signature

Bug#996036: LXD: snap lxd cgroup noise causes VirtSubproc to fail

[Paul Gevers]

Hi Stefano,

On 10-10-2021 20:06, Stefano Rivera wrote:
> Unfortunately executing any confined snapped binaries outputs a line on
> stderr:
>> WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
>> confinement

Does this happen on all suites? I thought bullseye defaults to cgroup
v2, so it would surprise me a bit if it would be an error there.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#841744: fail2ban: jail.conf refers to wrong man section

[Mike Gerber]

notfound 841744 0.11.2-2

fixed 841744 0.11.2-2

thanks


This is fixed in 0.11.2-2 (bullseye aka stable) - the man page is now in 
section 5.

Bug#953529: Networking support in Keepassxc

[tony mancill]

On Tue, Oct 27, 2020 at 07:20:38PM -0500, Andreas Kloeckner wrote:
> So I would prefer that networking support is retained in KeepassXC, or
> if it were to be disabled, I would prefer if it were done in a separate
> package, e.g. keepassxc-nonetwork or some such.

A separate binary package would be nice, although I would prefer that
the default binary have networking disabled and users could opt-in by
installing keepassxc-netenabled (or whatever you decide to name it).

Of course, that's just my opinion.  For my systems, I always recompile
the source package with -DWITH_XC_NETWORKING=OFF.

In any event, thank you for maintaining KeePassXC.
tony


signature.asc
Description: PGP signature

Bug#995957: dbconfig-common: Spews "/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead."

[Guilhem Moulin]

Hi elbrus!

On Sun, 10 Oct 2021 at 20:52:51 +0200, Paul Gevers wrote:
> Thanks for the report. I had committed nearly the same change locally.
> Can you elaborate why you removed some "2>&1" strings on top of that?

AFAIK with some `which` implementations one wants to silence the
standard error to avoid “foobar is not found” error messages, but per
current POSIX specs 
that's not needed for `command -v`:

  -v
Write a string to standard output that indicates the pathname or
command that will be used by the shell, in the current shell
execution environment (see Shell Execution Environment), to invoke
command_name, but do not invoke command_name.
[…]
Otherwise, no output shall be written and the exit status shall
reflect that the name was not found.

AFAICT the debianutils maintainer also suggest to use `command -v foobar
>/dev/null` as replacement for `which foobar >/dev/null [2>&1]`.  Its
5.3-1 NEWS entry reads:

  * The 'which' utility will be removed in the future.  Shell scripts
often use it to check whether a command is available.  A more
standard way to do this is with 'command -v'; for example:
  if command -v update-icon-caches >/dev/null; then
update-icon-caches /usr/share/icons/...
  fi
'2>/dev/null' is unnecessary when using 'command': POSIX says "no
output shall be written" if the command isn't found.  It's also
unnecessary for the debianutils version of 'which', and hides the
deprecation warning.

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: subscribe -1

On Sun, 10 Oct 2021 16:13:29 +0200 Ondrej Zary  wrote:
> Package: mariadb-server
> Version: 1:10.3.31-0+deb10u1
> Severity: grave
> Justification: causes non-serious data loss
> 
> Dear Maintainer,
> upgrading mariadb-server from 1:10.3.29-0+deb10u1 to 1:10.3.31-0+deb10u1
failed
> because mariadb failed to start. /var/log/mysql/error.log:
> 
> 2021-10-10 15:12:49 0 [ERROR] InnoDB: corrupted TRX_NO 10002001c6986c3
> 2021-10-10 15:12:49 0 [ERROR] InnoDB: Plugin initialization aborted with
error Data structure corruption
> 2021-10-10 15:12:50 0 [ERROR] Plugin 'InnoDB' init function returned error.
> 2021-10-10 15:12:50 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE
ENGINE failed.
> 2021-10-10 15:12:50 0 [ERROR] Unknown/unsupported storage engine: InnoDB
> 2021-10-10 15:12:50 0 [ERROR] Aborting
> 
> Fortunately, it works after downgrading back to 10.3.29.
> Data does not seem to be corrupted.
> 

For what's it's worth I'm experiencing the same issue on my installation. I
took me some time to find that bug (and I started to dig how to repair innodb
stuff. Good to know downgrading should help, thanks.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFjNSIACgkQ3rYcyPpX
RFsxlQgAo0eUU9T8XaIsYIw/jx4dmbRf9DO8/IxPvFuMw0zkn7JO2LxL61IRIcAa
SDljx7UjnJpTpJ6Nc6XXQ8sU3EIb4qUen1dRME383jcUEAN0Yh3F2cvBmNkjV7bN
rDdRf74leH76uYo9sPIgWnZwy2U2I9HVKhlD3uo2MF53ksem1yVJh3Jvll5w0ZsM
SsMCO2wTjq3RFbc38bqKASSh/+UvXAxxY/6R6bxc+YIWqsim9z8XQ9TKZXdnjPS+
aOcJblZarGOjdC2AwbeT9GVaBoaCx9V9RlQDn3WoMvVhHvjfI32j+tEG1uWnicC/
q1tnUp/9oBnvt8eYDbRY3ny3oC6ylA==
=oOyd
-END PGP SIGNATURE-

Bug#996016: libreoffice: fails to send email

[Rene Engelhard]

[ please always keep the Bug in CC so that discussions about it get
recorded.

Readding. ]


Hi.

Am 10.10.21 um 20:44 schrieb Alex:
> And what is in LO settings?
> LO Settings point to /usr/lib/thunderbird

OK, as I guessed. Then anything can be in KDEs session doesn't matter.

> What if you set your mailer as xdg-email?
>
>
> That works as expected. Thanks.
>
As expected. And xdg-email knows what you want thunderbird :-)

> I just tried it: LOs default has sensible-lomua set. That one opened
>> Thunderbird in my  GNOME and happily set mail.
>>
Although best is to keep it as sensible-lomua which then runs xdg-open
>> case `basename "$MAILER"` in
>>  sensible-lomua)
>>  if [ -x /usr/bin/xdg-email ] ; then
>>  MAILER=/usr/bin/xdg-email

[...]


And as said sensible-lomua (which is the default setting in LO) is more
or less a redirection also defaulting to actually calling xdg-email anyway.


Can we close this as "user configuration error"? :)


Regards,


Rene

Bug#996048: postfix-mta-sts-resolver: autopkgtest doesn't handle new version of ca-certificates nicely: rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL

[Paul Gevers]

Source: postfix-mta-sts-resolver
Version: 1.0.0-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:ca-certificates

[X-Debbugs-CC: debian...@lists.debian.org,
ca-certifica...@packages.debian.org]

Dear maintainer(s),

With a recent upload of ca-certificates the autopkgtest of
postfix-mta-sts-resolver fails in testing when that autopkgtest is run
with the binary packages of ca-certificates from unstable. It passes
when run with only packages from testing. In tabular form:

 passfail
ca-certificates  from testing20211004
postfix-mta-sts-resolver from testing1.0.0-4
all others   from testingfrom testing

I copied some of the output at the bottom of this report. The *warning*
seems to be innocent, but causes the test to fail because by default
autopkgtest considers output on stderr as fatal (without the
allow-stderr restriction).

Currently this regression is blocking the migration of ca-certificates
to testing [1]. Of course, ca-certificates shouldn't just break your
autopkgtest (or even worse, your package), but it seems to me that the
change in ca-certificates was intended and your package needs to update
to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from ca-certificates should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=ca-certificates

https://ci.debian.net/data/autopkgtest/testing/amd64/p/postfix-mta-sts-resolver/15856707/log.gz

autopkgtest [19:39:52]: test run: [---
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain
exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
autopkgtest [19:40:04]: test run: ---]
autopkgtest [19:40:04]: test run:  - - - - - - - - - - results - - - - -
- - - - -
run  FAIL stderr: rehash: warning: skipping
ca-certificates.crt,it does not contain exactly one certificate or CRL



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996049: gnome-shell-extension-dash-to-panel: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-dash-to-panel
Version: 43-2
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996050: gnome-shell-extension-dashtodock: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-dashtodock
Version: 69-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996051: gnome-shell-extension-desktop-icons: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-desktop-icons
Version: 20.04.0+git20200908-8
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996046: gnome-shell-extension-autohidetopbar: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-autohidetopbar
Version: 20210525-2
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996047: gnome-shell-extension-bluetooth-quick-connect: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-bluetooth-quick-connect
Version: 23-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#987160: gap-core: missing gap in /u/l/gap or gac in /u/l/x/gap

[Jerome BENOIT]

Hello Bill, thanks for the correction and sorry for my late reaction.
I have just updated the gap-io package accordingly. All looks fine.
Meanwhile I have noticed that
/usr/lib/gap/sysinfo.gap and /usr/lib/x86_64-linux-gnu/gap/sysinfo.gap
are actually the same files.
Cheers,
Jerome

On Fri, 24 Sep 2021 13:27:28 +0200 Bill Allombert  wrote:

Le Sun, Apr 18, 2021 at 08:40:41PM +0200, Jerome BENOIT a écrit :

Hello Jerome,
I am working on updating GAP to 4.11.1, sorry for the delay.

> > > I have just packaged the last version 4.7.1 of gap-io.
> > > Its build machinery has changed. It now uses a Gap makefile 
Makefile.gappkg .
> > > This makefile implicitly assumes (?=) that the gap and gac are into 
GAPPATH
> > > as passed at configuration time. The GAPPATH is /usr/lib/gap or 
/usr/lib//gap :
> > > the former contains gac, the latter gap. It would be nice to have
> > > both
> at least
> > > in one of the GAPPATH.
> > 
> > Why not set GAPPATH to /usr/bin then ?
> 
> Because GAPPATH is also used to get access to sysinfo.gap .


OK, so if I move gac to /usr/lib//gap, will it work ?

Cheers,
--
Bill. 

Imagine a large red swirl here. 





--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996021: ITP: cvelib -- library and a command line interface for the CVE Services API

[Salvatore Bonaccorso]

Package: wnpp
Owner: Salvatore Bonaccorso 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: cvelib
  Version : 0.4.0
  Upstream Author : Red Hat Security Response Team 
* URL : https://github.com/RedHatProductSecurity/cvelib
* License : Expat
  Programming Lang: Python
  Description : library and a command line interface for the CVE Services 
API

cvelib is a library and a command line interface to interact with the
MITRE CVE Services API, including functions to reserve one or more CVE
IDs for a CNA, filter and list reserved CVEs owned by a CNA, and
administration of user and tokes for a CNA.

This package installs the library for Python 3 and a CLI tool.

Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines?

[Nathaniel Filardo]

It occurs to me, quite belatedly, that it may be worth asking the
author, reviewers, and signers of the change in question their
thoughts on this bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990279

In particular, on ppc64 systems, Linux typically is configured to use
a 64KiB page (i.e., shift 16) rather than 4KiB (shift 12) page.  It
looks, however, that AMDGPU_GPU_PAGE_SIZE is always 4096, and so
something (perhaps in userspace, even, eek?) is requesting
4KiB-but-not-64KiB alignment of this buffer.

Any insight you could offer would be deeply appreciated.
Thanks,
--nwf;

Bug#996027:

[Ahmad Niazi]

ahmadniazi...@gmail.com

Bug#995990: systemctl --now flag has no effect in two circumstances

[MichaIng]

Okay, first I verified that it is an issue on all architectures, even on 
Raspberry Pi with the dedicated Raspbian armv6hf package builds.


Then I sadly found that downgrading all systemd source packages to 
232-25+deb9u12 does not solve the issue. Also I wasn't able to find 
another recent package upgrade which may be related, though I still 
cannot believe that this issue exists for a long time, as we should have 
received more reports from our users.


Is there a history of all updated packages within Debian's APT 
repositories? I have no local upgrade history (apt/dpkg logs), sadly on 
Stretch testing systems.


Upgrading to 241-5~bpo9+1 from Stretch backports btw solves it, though 
this is not applicable in all cases, e.g. Raspbian systems where 
backports are not available.


Best regards,

Micha