Bug#1017463: wajig: Please restore automatic installation of bash-completion script
Thanks for the report. This has been fixed in 4.0.12 on https://github.com/gjwgit/wajig and to be uploaded to Debian repository shortly.
Bug#1040519: bookworm-pu: package samba/2:4.17.9+dfsg-0+deb12u1
07.07.2023 10:58, Jonathan Wiltshire wrote: Control: tag -1 confirmed On Fri, Jul 07, 2023 at 10:03:07AM +0300, Michael Tokarev wrote: [ Reason ] Here's the next stable/bugfix release of samba, 4.17.9. As has been the case with samba stable/bugfix releases, this one is of an excellent quality, well tested and with all changes well selected as well. Please go ahead with the full proposal (upstream and your package fixes). Uploaded just now instead of yesterday, - I wanted to verify once more it is in a good shape after the above two additional modifications. Thank you! /mjt
Bug#455854: evince: bad text selection behaviour - characters clipped and text overwritten
Control: notfixed -1 43.1-3 Control: fixed -1 22.12.0-2 On Fri, 2023-07-07 at 10:58 +0800, Paul Wise wrote: > Control: fixed -1 43.1-3 Woops, that is the evince version not the poppler version, fixing. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1040622: systemd-sysv: reboot doesn't honor the grub-reboot settings; reboot -f does
Package: systemd-sysv Version: 252.6-1 Severity: normal Dear Maintainer, * What led up to the situation? I was updating the gce-xfstests[1] test appliance to Debian Bookworm from Debian Bullseye. [1] https://thunk.org/gce-xfstests * What exactly did you do (or not do) that was effective (or ineffective)? Unfortunately kexec has not been reliable ever since sometime after the 5.4 kernel, at least on Google Compute Engine VM's. (About 30-40% of the time, the VM hangs after the kexec; about 10% of the time, the machine is up, but it is very slow and limping, and /proc/interrupts shows that some interrupt channel is going wild. This is no doubt the kernel bug interacting with some virtual hardware in the GCE VM, but I've never been able to debug it.) Because of issues with kexec, the primary way that I reboot into the kernel that I want to test is to install the kernel as a dpkg package, and then examine /boot/grub/grub.cfg to find out where it was inserted into the grub's menu listing, and then run a command like "grub-reboot 1>4", where the number is found by examing the grub.cfg file. An example of this works can be found here[2]. [2] https://github.com/tytso/xfstests-bld/blob/9bae3253d57456987d995cf85379e9165e054381/test-appliance/files/usr/local/lib/gce-load-kernel#L169 This works *just* *fine* when using Debian Bullseye (which is using systemd 247.3-7+deb11u2). * What was the outcome of this action? Unfortunately, this no longer works in Debian Bookworm (with systemd 252.6-1). In Debian Bookworm, the grub-reboot(8) setting is ignored after triggering a reboot via /sbin/reboot. Connecting to the serial console, it appears that "reboot" is going through some code path that does NOT involve triggering a BIOS message and going through grub, where (assuming the GRUB_TIMEOUT is set to some non-zero value like 15) the grub menu would be displayed, and after 15 seconds, it would boot the kernel specified by grub-reboot, and then clear the next_entry entry in /boot/grub/grubenv. Instead, systemd appears to boot the default kernel, ignoring /boot/grub/grubenv, so I don't enter the kernel which I had just installed, and had selected via the grub-reboot(8) command. Looking at /boot/grub/grubenv, it still has the "next_entry=1>4" set by grub-reboot(8), so it appears that /boot/grub/grubenv is being completely ignored by reboot. *However*, it is properly handled if I use reboot -f. The "reboot -f" command will briefly show the BIOS version information, and then the Grub Menu, and then will boot the kernel selected by grub-reboot(8), and afterwords the next_entry field is cleared from /boot/grub/grubenv. So this is not a "grub" problem, but in the reboot path selected by systemd when doing a clean shutdown via the "reboot" command. As near as I can tell, grub is being bypassed, or at least grub is getting called in some way whic causes it to ignore the /boog/grub/grubenv parameter. In Debian Bookworm, "reboot" works like "reboot -f", in that we go through the BIOS initialization step, printing the BIOS version, and then grub is invoked in such a way that /boot/grub/grubenv is honored. * What outcome did you expect instead? The "reboot" command should go through the normal, full reboot sequence, such that grub-reboot(8) works correctly. As a workaround, I've replaced reboot sleep 60 with sync /boot sync sleep 1 reboot -f sleep 60 However, it would be desirable to let the system go through a full, clean shutdown, with file systems properly unmounted or remounted read-only in the case of the root file system. -- System Information: Debian Release: 12.0 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd-sysv depends on: ii systemd 252.6-1 Versions of packages systemd-sysv recommends: ii libnss-systemd 252.6-1 ii libpam-systemd 252.6-1 systemd-sysv suggests no packages. -- no debconf information
Bug#1040621: binutils-mipsen: missing shlib dependencies
Source: binutils-mipsen Version: 10+c3 Severity: grave Justification: renders package unusable mips* binutils tools crash on startup: $ mips64el-linux-gnuabi64-as mips64el-linux-gnuabi64-as: error while loading shared libraries: libsframe.so.0: cannot open shared object file: No such file or directory The culprit is: $ ldd /usr/lib/x86_64-linux-gnu/libopcodes-2.40.50-mips64el.20230611.so libsframe.so.0 => not found which would be prevented by package relationships/DAK/etc, had the dependency on libsframe be included in binaries you produce. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.2-00035-g5920c330f094 (SMP w/64 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#1040620: quickplot will not read input file
Package: quickplot Version: 1.0.1~rc-1+b3 Any attempt to read an input file or pipe fails with the error message: Failed to read file /home/brent/quickplot/plot.dat: lseek() failed A workaround is the link the quickplot binary with the upstream libsndfile-1.0.28 rather than the libsndfile-1.0.31 packaged with Debian 11 For instance, after installing libsndfile-1.0.28 in /usr/local/lib, quickplot will work if started with this shell script: #!/bin/sh #force linkage with our local version of libsndfile # (1.0.28 rather than Debian's 1.0.31) LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH exec /usr/bin/quickplot "$@" I am using Debian 11 on x86 (tested both 32 or 64-bit) with various Linux 5.x kernels. -- Brent Roman MBARI Software Engineer Tel: (831) 775-1808 mailto:br...@mbari.org http://www.mbari.org/~brent
Bug#1040619: vesa.4: some remarks and editorial fixes for the manual
Package: xserver-xorg-video-vesa
Version: 1:2.5.0-1+b1
Severity: minor
Tags: patch
Dear Maintainer,
here are some notes and editorial fixes for the man page.
-.-.
The difference between the formatted outputs can be seen with:
nroff -man >
nroff -man >
diff -u
and for groff, using
"groff -man -Z" instead of "nroff -man"
Add the option "-t", if the file contains a table.
-.-.
Output from "mandoc -T lint vesa.4":
mandoc: vesa.4:51:66: STYLE: whitespace at end of input line
-.-.
Wrong distance between sentences.
Separate the sentences and subordinate clauses; each begins on a new
line. See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").
The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.
Remember coding: Only one command ("sentence") on each (logical) line.
E-mail: Easier to quote exactly the relevant lines.
Generally: Easier to edit the sentence.
Patches: Less unaffected text.
The amount of space between sentences in the output can then be
controlled with the ".ss" request.
50:Clear the screen on mode set. Some BIOSes seem to be broken in the
52:clear the screen during mode setting. If you experience problems try
53:to turn this option off. Default: on.
-.-.
The name of a man page is set in bold type and the section in roman (see
man-pages(7)).
26:Please refer to xorg.conf(5) for general configuration
56:Xorg(1), xorg.conf(5), Xserver(1), X(7)
-.-.
Output from "test-nroff -man -b -ww -z -rCHECKSTYLE=3":
[ "test-groff" is a developmental version of "groff" ]
Input file is ./vesa.4
Output from "test-groff -b -mandoc -dAD=l -rF0 -rHY=0 -t -w w -z
-rSTYLECHECK=3":
troff: backtrace: file '':51
troff::51: warning: trailing space in the line
-.-.
--- vesa.4 2023-07-08 01:47:15.0 +
+++ vesa.4.new 2023-07-08 02:04:38.0 +
@@ -23,9 +23,10 @@ The
driver supports most VESA-compatible video cards. There are some known
exceptions, and those should be listed here.
.SH CONFIGURATION DETAILS
-Please refer to xorg.conf(5) for general configuration
-details. This section only covers configuration details specific to this
-driver.
+Please refer to
+.BR xorg.conf (5)
+for general configuration details.
+This section only covers configuration details specific to this driver.
.PP
The driver auto-detects the presence of VESA-compatible hardware. The
.B ChipSet
@@ -47,12 +48,17 @@ Enable or disable use of the shadow fram
This option is recommended for performance reasons.
.TP
.BI "Option \*qModeSetClearScreen\*q \*q" boolean \*q
-Clear the screen on mode set. Some BIOSes seem to be broken in the
-sense that the newly set video mode is bogus if they are asked to
-clear the screen during mode setting. If you experience problems try
-to turn this option off. Default: on.
+Clear the screen on mode set.
+Some BIOSes seem to be broken in the sense
+that the newly set video mode is bogus
+if they are asked to clear the screen during mode setting.
+If you experience problems try to turn this option off.
+Default: on.
.SH "SEE ALSO"
-Xorg(1), xorg.conf(5), Xserver(1), X(7)
+.BR Xorg (1),
+.BR xorg.conf (5),
+.BR Xserver (1),
+.BR X (7)
.SH AUTHORS
Authors include: Paulo Ce\'sar Pereira de Andrade.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.3.7-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1),
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages xserver-xorg-video-vesa depends on:
ii libc6 2.37-3
ii xserver-xorg-core [xorg-video-abi-25] 2:21.1.7-3
xserver-xorg-video-vesa recommends no packages.
xserver-xorg-video-vesa suggests no packages.
-- no debconf information
Bug#1040618: xwayland: xwininfo, xkill doesn't change cursor when prompted to click
Package: xwayland Version: 2:22.1.9-1 Severity: important Dear Maintainer, I set up a keyboard shortcut to xkill in GNOME when I was in Debian bookworm. The shortcut worked there (the cursor changed to cross in order to select window to be killed). Then I upgraded to recent testing, at which xkill doesn't change cursor anymore. I have another DE installed (KDE) and can confirm this regression still occurs there. This regression doesn't occur on GNOME on Xorg session, hence reporting this as xwayland bug. Looking through journalctl, I see: ``` Jul 08 08:15:39 debian systemd[4747]: Started app-gnome-xkill-6559.scope - Application launched by gsd-media-keys. Jul 08 08:15:40 debian systemd[4747]: Started app-gnome-xkill-6564.scope - Application launched by gsd-media-keys. Jul 08 08:15:41 debian systemd[4747]: Reached target gnome-session-x11-services.target - GNOME session X11 services. Jul 08 08:15:41 debian gnome-shell[6576]: The XKEYBOARD keymap compiler (xkbcomp) reports: Jul 08 08:15:41 debian gnome-shell[6576]: > Warning: Unsupported maximum keycode 708, clipping. Jul 08 08:15:41 debian gnome-shell[6576]: > X11 cannot support keycodes above 255. Jul 08 08:15:41 debian gnome-shell[6576]: Errors from xkbcomp are not fatal to the X server Jul 08 08:15:41 debian systemd[4747]: Starting org.gnome.SettingsDaemon.XSettings.service - GNOME XSettings service... Jul 08 08:15:46 debian dnsmasq-dhcp[1664]: Ignoring domain mail for DHCP host name ohmymail Jul 08 08:15:47 debian systemd[4747]: Started org.gnome.SettingsDaemon.XSettings.service - GNOME XSettings service. Jul 08 08:15:47 debian systemd[4747]: Reached target gnome-session-x11-services-ready.target - GNOME session X11 services. Jul 08 08:15:48 debian gnome-shell[4944]: ATK Bridge is disabled but a11y has already been enabled. Jul 08 08:15:49 debian xkill[6564]: xkill: unable to grab cursor Jul 08 08:15:49 debian xkill[6564]: Select the window whose client you wish to kill with button 1 ``` Thanks. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.38-local (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xwayland depends on: ii libc6 2.36-9 ii libdrm2 2.4.115-1 ii libepoxy0 1.5.10-1 ii libgbm1 22.3.6-1+deb12u1 ii libgcrypt20 1.10.2-2 ii libgl1 1.6.0-1 ii libpixman-1-0 0.42.2-1 ii libtirpc3 1.3.3+ds-1 ii libwayland-client0 1.21.0-1 ii libxau6 1:1.0.9-1 ii libxcvt00.1.2-1 ii libxdmcp6 1:1.1.2-3 ii libxfont2 1:2.0.6-1 ii libxshmfence1 1.3-1 ii xserver-common 2:21.1.7-3 xwayland recommends no packages. xwayland suggests no packages. -- no debconf information
Bug#1040617: Spelling error in the upstream web address and a new version
Package: xorg-docs-core Version: 1:1.7.1-1.2 Severity: normal Dear Maintainer, A '/' is missing between 'org' and 'releases' There is a new version 1.7.2 from 2022-04-04. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.3.7-1 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) xorg-docs-core depends on no packages. xorg-docs-core recommends no packages. Versions of packages xorg-docs-core suggests: pn xorg-docs -- no debconf information
Bug#986545: ITP: gnome-tour -- A modern introduction and tour to GNOME
Control: owner -1 jeremy.bi...@canonical.com Control: retitle -1 ITP: gnome-tour -- A modern introduction and tour to GNOME This is blocked on ftpmasters letting rust-libadwaita-sys (and afterwards rust-libadwaita) into Debian. Meanwhile, I am uploading this to Ubuntu. My packaging is at https://salsa.debian.org/gnome-team/gnome-tour Thank you, Jeremy Bícha
Bug#1040586: krita: Krita Comics Manager crashes creating new template or page
Package: krita Version: 1:5.1.5+dfsg-2 Followup-For: Bug #1040586 X-Debbugs-Cc: fenix...@gmail.com Patch: yes Dear Maintainer, I have been doing some test and it seems that something changed the way floats are cast automatically to integers. I have done a force casting and this workaround works for me. I attach patch showing the changes. But I really don't where this come from. My knowledge about PyQt5 and Krita is limited. I hope this helps to find a better fix. Greetings. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages krita depends on: ii krita-data1:5.1.5+dfsg-2 ii libc6 2.37-3 ii libexiv2-27 0.27.6-1 ii libfftw3-double3 3.3.10-1 ii libgcc-s1 13.1.0-6 ii libgif7 5.2.1-2.5 ii libgsl27 2.7.1+dfsg-5 ii libheif1 1.16.2-1+b1 ii libimath-3-1-29 3.1.6-1 ii libjpeg62-turbo 1:2.1.5-2 ii libjxl0.7 0.7.0-10 ii libkf5completion5 5.107.0-1 ii libkf5configcore5 5.107.0-1 ii libkf5configgui5 5.107.0-1 ii libkf5coreaddons5 5.107.0-1 ii libkf5crash5 5.107.0-1 ii libkf5guiaddons5 5.107.0-1 ii libkf5i18n5 5.107.0-1 ii libkf5itemviews5 5.107.0-1 ii libkf5widgetsaddons5 5.107.0-1 ii libkf5windowsystem5 5.107.0-1 ii libkseexpr4 4.0.4.0-4 ii libkseexprui4 4.0.4.0-4 ii liblcms2-22.14-2 ii libmypaint-1.5-1 1.6.0-2 ii libopencolorio2.1 2.1.2+dfsg1-4+b3 ii libopenexr-3-1-30 3.1.5-5 ii libopenjp2-7 2.5.0-2 ii libpng16-16 1.6.40-1 ii libpoppler-qt5-1 22.12.0-2+b1 ii libpython3.11 3.11.4-1 ii libqt5core5a 5.15.8+dfsg-12 ii libqt5dbus5 5.15.8+dfsg-12 ii libqt5gui55.15.8+dfsg-12 ii libqt5multimedia5 5.15.8-2 ii libqt5network55.15.8+dfsg-12 ii libqt5printsupport5 5.15.8+dfsg-12 ii libqt5qml55.15.8+dfsg-3 ii libqt5quick5 5.15.8+dfsg-3 ii libqt5quickwidgets5 5.15.8+dfsg-3 ii libqt5sql55.15.8+dfsg-12 ii libqt5sql5-sqlite 5.15.8+dfsg-12 ii libqt5svg55.15.8-3 ii libqt5widgets55.15.8+dfsg-12 ii libqt5x11extras5 5.15.8-2 ii libqt5xml55.15.8+dfsg-12 ii libquazip5-1 0.9.1-3 ii libraw20 0.20.2-2.1 ii libstdc++613.1.0-6 ii libtiff6 4.5.1-1 ii libturbojpeg0 1:2.1.5-2 ii libwebp7 1.2.4-0.2 ii libx11-6 2:1.8.6-1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages krita recommends: ii krita-gmic 2.9.4-4+b4 ii python3-pyqt55.15.9+dfsg-1 ii python3-sip 4.19.25+dfsg-5+b1 ii qml-module-qtmultimedia 5.15.8-2 Versions of packages krita suggests: ii colord 1.4.6-2.2 ii ffmpeg 7:5.1.3-1 pn krita-l10n -- no debconf information --- comics_project_manager_docker.py 2023-07-08 02:12:56.806462080 +0200 +++ comics_project_manager_docker_fix.py 2023-07-08 02:03:24.677998546 +0200 @@ -93,7 +93,8 @@ topSizeThumbnail = ((rect.height()-imageSize.height())/2)+rect.top() thumbImage = icon.pixmap(imageSizeHighDPI).toImage() thumbImage.setDevicePixelRatio(self.devicePixelRatioF) -painter.drawImage(QRect(leftSideThumbnail, topSizeThumbnail, imageSize.width(), imageSize.height()), thumbImage) + +painter.drawImage(QRect(int(leftSideThumbnail), int(topSizeThumbnail), int(imageSize.width()), int(imageSize.height())), thumbImage) labelWidth = rect.width()-decoratonSize.width()-(margin*3) @@ -136,8 +137,8 @@ descRect = QRect(textRect.left(), textRect.bottom()+margin, labelWidth, (rect.bottom()-margin) - (textRect.bottom()+margin)) if textRect.bottom()+metrics.height() < rect.bottom(): -textRect.setBottom(textRect.bottom()+(margin/2)) -textRect.setLeft(textRect.left()-(margin/2)) +textRect.setBottom(int(textRect.bottom()+(margin/2))) +textRect.setLeft(int(textRect.left()-(margin/2))) painter.setOpacity(0.4) painter.drawLine(textRect.bottomLeft(), textRect.bottomRight()) painter.setOpacity(1.0) --- comics_template_dialog.py 2023-07-08 02:12:45.802376577 +0200 +++ comics_template_dialog_fix.py 2023-07-08 01:50:55.808011929 +0200 @@ -296,8 +296,8 @@ bB = self.bleedBottomUnit.pixelsForUnit(self.bleedBottom.value(), self.DPI.value()) mT = self.marginTopUnit.pixelsForUnit(self.marginTop.value(), self.DPI.value())
Bug#944488: +1 to include this patch
I would also welcome the inclusion of this patch. I'm using it for two or three years now in production and had no problems with it.
Bug#1040616: ITP: rocm-validation-suite -- AMD GPU system validation tools
Package: wnpp Severity: wishlist Owner: Cordell Bloor X-Debbugs-Cc: debian-de...@lists.debian.org, c...@slerp.xyz, debian...@lists.debian.org * Package name: rocm-validation-suite Version : 5.6.0 * URL : https://github.com/ROCm-Developer-Tools/ROCmValidationSuite * License : Expat Programming Lang: C++ Description : AMD GPU system validation tools The ROCm Validation Suite (RVS) is a collection of utilities for verifying the correct functioning of the AMD GPUs installed on a system. It provides system administrators with tests, benchmarks and other tools for troubleshooting common problems found in high-performance computing environments. . RVS provides utilities for querying GPU properties, monitoring GPU information, monitoring the PCI Express link speeds and power, querying relevent PCI Express bus properties for a GPU, verifying the GPU SBIOS mapping, benchmarking peer-to-peer links between GPUs, benchmarking the PCI Express bus, stress-testing installed GPUs, stress-testing the system PSU, verifying GPU memory to detect hardware errors, and benchmarking device global memory. This package provides a variety of tools for checking the correct functioning of AMD GPU hardware, which would be valuable for ensuring that malfunctioning hardware and misconfigured systems are identified. It is useful for ruling out hardware problems when unexpected software behaviours are encountered. This package is part of AMD's ROCm stack and will be maintained under the Debian AI team umbrella.
Bug#1040615: ibus: Misplaced candidate window in gtk4 apps
Package: ibus Version: 1.5.27-5 Severity: important Control: forwarded -1 https://github.com/ibus/ibus/issues/2522 When using an IBus input method in gtk4 applications such as nautilus or gnome-text-editor, the candidate window does not show up right below the cursor as expected, but rather a bit random. The issue was originally reported upstream against Debian 12, and I have confirmed it in Debian testing. I also see the issue in Ubuntu 22.04 with ibus 1.5.26 and Ubuntu 23.04 with ibus 1.5.28. The upstream issue focuses on ibus-libpinyin, but the problem is present with e.g. ibus-mozc and ibus-anthy as well. In all those cases the issue is only present in x11 sessions, while it works as expected in Wayland. However, in Ubuntu's development version the issue is present in both x11 and Wayland. -- Gunnar Hjalmarsson
Bug#1040614: debian-reference: typo 'kerrnel'
Package: debian-reference Severity: normal Dear Maintainer, debian reference contains the typo 'kerrnel', search for that string and please fix it.
Bug#1040613: whois.1: some remarks and editorial fixes for the manual
Package: whois
Version: 5.5.17
Severity: minor
Tags: patch
Dear Maintainer,
here are some notes and editorial fixes for the man page.
-.-.
The difference between the formatted outputs can be seen with:
nroff -man >
nroff -man >
diff -u
and for groff, using
"groff -man -Z" instead of "nroff -man"
-.-.
Output from "mandoc -T lint whois.1":
mandoc: whois.1:45:2: WARNING: skipping paragraph macro: PP empty
mandoc: whois.1:58:2: WARNING: skipping paragraph macro: PP empty
-.-.
Mark a full stop (.) and the exclamation mark (!) with "\&",
if it does not mean an end of a sentence.
This is a preventive action,
the paragraph could be reshaped, e.g., after changes.
When typing, one does not always notice when the line wraps after the
period.
There are too many examples of input lines in manual pages,
that end with an abbreviation point.
This marking is robust, and independent of the position on the line.
It corresponds to "\ " in TeX, and to "@:" in Texinfo.
210:When querying the Verisign gTLDs (e.g. .com, .net...) thin registry servers
-.-.
Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.
188:.I -q sources
234:.IR "-T dn" .
-.-.
Add a comma (or \&) after "e.g." and "i.e.", or use English words
(man-pages(7).
Abbreviation points should be protected against being interpreted as
an end of sentence, if they are not, and that independent of the
current place on the line.
210:When querying the Verisign gTLDs (e.g. .com, .net...) thin registry servers
-.-.
Wrong distance between sentences.
Separate the sentences and subordinate clauses; each begins on a new
line. See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").
The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.
Remember coding: Only one command ("sentence") on each (logical) line.
E-mail: Easier to quote exactly the relevant lines.
Generally: Easier to edit the sentence.
Patches: Less unaffected text.
The amount of space between sentences in the output can then be
controlled with the ".ss" request.
N.B
The number of lines affected is too large to be in the patch.
53:ask for the specified object. If no guess can be made it will connect to
80:whois server authoritative for that request. This works for IP addresses,
109:Disable objects filtering. (Show the e-mail addresses.)
125:update serial number. It is useful to obtain Near Real Time Mirroring
stream.
139:Return primary key attributes only. An exception is the
143:objects, which is always returned. Another exception are all
210:When querying the Verisign gTLDs (e.g. .com, .net...) thin registry servers
243:servers. This may or may not be the behaviour intended by the user.
252:to find a server before applying the normal rules. Each line of the
283:of objects are located. If the variable does not exist then
-.-.
Protect a period (.) or a apostrophe (') with '\&' from becoming a
control character, if it could end up at the start of a line (by
splitting the line into more lines).
210:When querying the Verisign gTLDs (e.g. .com, .net...) thin registry servers
-.-.
Split a punctuation from a single argument, if a two-font macro is meant
131:.I ATTR[,ATTR]...
183:.I SOURCE[,SOURCE]...
197:.I TYPE[,TYPE]...
-.-.
Output from "test-nroff -man -b -ww -z -rCHECKSTYLE=3":
[ "test-groff" is a developmental version of "groff" ]
Input file is ./whois.1
Output from "test-groff -b -mandoc -dAD=l -rF0 -rHY=0 -t -w w -z
-rSTYLECHECK=3":
troff: backtrace: '/home/bg/git/groff/build/s-tmac/an.tmac':613: macro 'BR'
troff: backtrace: file '':17
troff::17: warning: trailing space in the line
troff: backtrace: '/home/bg/git/groff/build/s-tmac/an.tmac':613: macro 'BR'
troff: backtrace: file '':20
troff::20: warning: trailing space in the line
troff: backtrace: '/home/bg/git/groff/build/s-tmac/an.tmac':613: macro 'BR'
troff: backtrace: file '':23
troff::23: warning: trailing space in the line
-.-.
--- whois.1 2023-07-07 22:29:42.0 +
+++ whois.1.new 2023-07-07 23:02:31.0 +
@@ -42,7 +42,6 @@ whois \- client for the whois directory
.B whois \-\-version
-.PP
.SH DESCRIPTION
.B whois
searches for an object in a
@@ -55,11 +54,10 @@ ask for the specified object. If no gues
for NIC handles or
.I whois.arin.net
for IPv4 addresses and network names.
-.PP
.SH OPTIONS
.TP 8
.B \-h \c
-.IR HOST ", "\c
+.IR HOST ,
.BI \-\-host= HOST
Connect to
.IR HOST .
@@ -68,7 +66,7 @@ Connect to
Do not display the legal disclaimers that some registries like to show you.
.TP 8
.B \-p \c
-.IR PORT ", "\c
+.IR PORT ,
.BI \-\-port= PORT
Connect to
.IR PORT .
@@ -106,7 +104,8 @@ Also search all the mirrored databases.
Return brief IP address ranges with abuse contact.
.TP 8
.B \-B
-Disable objects filtering. (Show the e-mail addresses.)
+Disable objects filtering.
+(Show the e-mail addresses.)
.TP 8
.B \-c
Bug#1040525: Lighttpd disregards ssl.dh-file setting
On Fri, Jul 07, 2023 at 09:28:24AM +, Alain Knaff wrote: > Package: lighttpd > Version: 1.4.69-1 > > Since our upgrade to Debian 12, lighttpd now uses insecure > Diffie-Hellman parameters > c90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63 > b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d5 > 1c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899f > a5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39 > a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d6 > 70c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b > 2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2 > 261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb8 > 50458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94 > e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18 > 177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce > 0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186 > af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fb > ecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2 > d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c0 > 8f4df435c934063199 What are you sharing? What command did you use to obtain this info? Please clarify why you think this is insecure. This does not look like lighttpd mod_openssl default DH parameters used since lighttpd 1.4.56. Since lighttpd 1.4.56, lighttpd mod_openssl configures default DH parameters to use RFC 7919 FFDHE2048 2048-bit group https://git.lighttpd.net/lighttpd/lighttpd1.4/commit/10c65e88f773d361db48e0135e1f4be3a932bf83 RFC 7919: https://datatracker.ietf.org/doc/html/rfc7919#appendix-A.1 Nowadays, FFDHE3072 is preferred, and a future version of lighttpd may change lighttpd mod_openssl to use FFDHE3072 by default in the future. Please note: if using GnuTLS (with lighttpd mod_gnutls) or using mbedTLS (with lighttpd mod_mbedtls), the Diffie-Hellman group is chosen to be secure according to RFC7919 DH parameter negotiation, and there is no default set by lighttpd. > And this despite having pointed ssl.dh-file to a self generated dh param > file, as described in https://weakdh.org/sysadmin.html That page is out-dated, at least for lighttpd. Since lighttpd 1.4.68, if you are using ssl.cipher-list specified in https://weakdh.org/sysadmin.html, then you are WEAKENING the cipher list now used by default since lighttpd 1.4.68. https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68 > In Debian 11, an identical configuration was using our locally generated > secure dh parameters. Since lighttpd 1.4.65 (released Jun 2022), lighttpd has been announcing the future scheduled removal of ssl.dh-file. https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_65 https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_66 https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_67 The removal of ssl.dh-file occurred in lighttpd 1.4.68 (Jan 2023) https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68 As linked in the lighttpd release notes: See https://wiki.lighttpd.net/Docs_SSL for replacements with `ssl.openssl.ssl-conf-cmd`, but prefer lighttpd defaults instead. Since lighttpd 1.4.68, use ssl.openssl.ssl-conf-cmd "DHParameters" to specify your own DH parameters file, as ssl.dh-file has been removed. If you have custom DH parameters, then please review RFC7919 and modern security papers to make sure what you think is secure is still considered secure by experts, as the use of parameters derived from "safe" primes is strongly recommended. It is my understanding that FFDHE3072 is the current recommendation if you are going to set explicit DH parameters. Cheers, Glenn
Bug#1040604: r8168-dkms: Module r8168-dkms does not override r8169 under linux mint 21.1
On 07/07/2023 21.33, EC wrote: Package: r8168-dkms Version: 8.049.02-1ubuntu1.1 I installed r8168-dkms from the Synaptics repository. I tried to blacklist r8169 unsuccessfully. I ended up with the same driver as before. I expected a driver which supports gigabyte speeds. Please report this directly to Mint, the kernel is always a very distribution specific thing. There is nothing I can do about it in Debian. The output of 'dkms status' might be interesting, too. Andreas
Bug#1040612: bluez: D-Bus policy is installed in /etc instead of /usr
Package: bluez Version: 5.66-1 Tags: patch Dear bluez maintainers, bluez and bluez-mesh install their D-Bus policy files in `/etc/dbus-1`. Since Debian 9 the standard directory for package-installed dbus policies is `/usr/share/dbus-1`. See: https://bugs.debian.org/1006631 Lintian complains with `dbus-policy-in-etc`. A patch to fix this issue is available at https://salsa.debian.org/bluetooth-team/bluez/-/merge_requests/5 Regards, -- Gioele Barabucci
Bug#1038056: boswars: Depends on SDL 1.2
port to SDL2 is happening right now https://codeberg.org/boswars/boswars/commits/branch/master In the meantime I've imported Version 2.8 from 2023/6/26 on Salsa. Greetings
Bug#1040572: wmnut: broken symlink: /usr/share/doc/wmnut/README -> README.asciidoc
On 2023-07-07, at 19:43:23 +0200, Andreas Beckmann wrote: > during a test with piuparts I noticed your package ships (or creates) > a broken symlink: > > 0m20.4s ERROR: FAIL: Broken symlinks: > /usr/share/doc/wmnut/README -> README.asciidoc (wmnut) Whoops. Thanks for the pointer. Will fix. J. signature.asc Description: PGP signature
Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)
On Thu, 2023-06-01 at 11:18 -0500, Limonciello, Mario wrote:
> +Lyude, Lukas, Karol
>
> On 5/31/2023 6:40 PM, Nick Hastings wrote:
> > Hi,
> >
> > * Nick Hastings [230530 16:01]:
> > > * Mario Limonciello [230530 13:00]:
> >
> > > > As you're actually loading nouveau, can you please try nouveau.runpm=0
> > > > on
> > > > the kernel command line?
> > > I'm not intentionally loading it. This machine also has intel graphics
> > > which is what I prefer. Checking my
> > > /etc/modprobe.d/blacklist-nvidia-nouveau.conf
> > > I see:
> > >
> > > blacklist nvidia
> > > blacklist nvidia-drm
> > > blacklist nvidia-modeset
> > > blacklist nvidia-uvm
> > > blacklist ipmi_msghandler
> > > blacklist ipmi_devintf
> > >
> > > So I thought I had blacklisted it but it seems I did not. Since I do not
> > > want to use it maybe it is better to check if the lock up occurs with
> > > nouveau blacklisted. I will try that now.
> > I blacklisted nouveau and booted into a 6.1 kernel:
> > % uname -a
> > Linux xps 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08)
> > x86_64 GNU/Linux
> >
> > It has been running without problems for nearly two days now:
> > % uptime
> > 08:34:48 up 1 day, 16:22, 2 users, load average: 1.33, 1.26, 1.27
> >
> > Regards,
> >
> > Nick.
>
> Thanks, that makes a lot more sense now.
>
> Nick, Can you please test if nouveau works with runtime PM in the
> latest 6.4-rc?
>
> If it works in 6.4-rc, there are probably nouveau commits that need
> to be backported to 6.1 LTS.
>
> If it's still broken in 6.4-rc, I believe you should file a bug:
>
> https://gitlab.freedesktop.org/drm/nouveau/
>
>
> Lyude, Lukas, Karol
>
> This thread is in relation to this commit:
>
> 24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
>
> Nick has found that runtime PM is *not* working for nouveau.
>
> If you recall we did 24867516f06d because 5775b843a619 was
> supposed to have fixed it.
Gotcha, I guess keep me updated since it seems like things -might- be working
from what I gathered here? Happy to look further if they find that 6.4-rc is
broken though
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Bug#1039591: logcheck: prompting due to modified conffiles which were not modified by the user: /etc/logcheck/header.txt
https://salsa.debian.org/debian/logcheck/-/merge_requests/18 now has
the patch for this
On Thu, 29 Jun 2023 at 21:36, Richard Lewis
wrote:
>
> I think you might be missing one md5sum - I found 4 versions in the git repos
>
> #
> for x in $(git log debian/header.txt | awk '/commit/{print $2}'); do
> git show $x:debian/header.txt | md5sum ; done
>
> d9206d89f2f8d85d346a23da90459862 -
> a32fc12d69628d96756fd3af3f8b3ecd -
> dbc1e8d136180d247b572f6a19c4e92e -
> 1bc54d3bfb0d1e61104d5780a318ced2 -
> #
>
> the top one being the current version, the middle two the same as you
> found and the one at the end '1bc54...' is from a commit dated
> 2004-04-19 (which might mean when woody was stable, i think, although
> this seems to be the date cvs2svn was run)
>
> presumably, we can then remove all this in trixie (if anyone remembers)
>
> On Wed, 28 Jun 2023 at 13:29, Andreas Beckmann wrote:
> >
> > New version of the patch fixing a wrong checksum. Now logcheck upgrade
> > paths starting from ancient releases look clean ;-)
> >
> > Andreas
Bug#959145: Done with this
On 6/20/23 2:24 AM, Ben Westover wrote: > Even before trying to package this program, I couldn't get it to > build on architectures other than amd64, which is kind of > unacceptable. So, I did some more research after this, and I found out some things: 1. One of the libraries it uses only supports 64 bit architectures, and another only supports x86 (and ARM after I got a patch merged), so only the amd64 and arm64 architectures would be supported. 2. The build script for the GUI arbitrarily won't let you build on ARM64 unless you're on macOS. In my bug report [1], the Proton team didn't give any practical reason for this other than "ARM on Linux is not supported" even though it builds and runs fine once you apply a one-line change to that build script to allow ARM builds on Linux. So, with a simple patch, you can upgrade the number of supported architectures from 1 to 2. That 64-bit-only library is pretty annoying. -- Ben Westover [1] https://github.com/ProtonMail/proton-bridge/issues/398 OpenPGP_signature Description: PGP signature
Bug#1040364: orphan-sysvinit-scripts: add triggers to restart daemons
On Wed, 5 Jul 2023 21:56:14 +0200 (CEST) Thorsten Glaser wrote: > On Wed, 5 Jul 2023, g...@libero.it wrote: > > >But [o-s-s] should also invoke-rc.d try-restart, for > >perfection. > > I don’t think so. I think the postinst of the services in question > restart the service, and that ought to “just work”, independent of > the init system in use, as long as an initsystem-compatible service > initscript is present (no matter whether it’s in the package itself > or in a separate one). > > After all, not all packages restart services on upgrade; some pak‐ > kages contain more than one service, not all of which are restarted > always, etc. > even if debhelper is changed to inject maintscripts regardless of the *.init script file in the source, non default actions are passed to dh_installinit in the rules file, so in the case of an uncooperative maintainer, there is no way for debhelper to know that it has to inject non-default actions in the snippets. > bye, > //mirabilos
Bug#1040611: RFS: dbus-c++/0.9.0-12~exp1 [QA] -- C++ API for D-Bus
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dbus-c++": * Package name : dbus-c++ Version : 0.9.0-12~exp1 Upstream contact : Andreas Volz * URL : https://sourceforge.net/projects/dbus-cplusplus/ * License : LGPL-2.1, GPL-3+ * Vcs : https://salsa.debian.org/debian/dbus-cplusplus Section : libs The source builds the following binary packages: libdbus-c++-1-0v5 - C++ API for D-Bus (runtime library with independent main loop) libdbus-c++-bin - C++ API for D-Bus (utilities) libdbus-c++-dev - C++ API for D-Bus (development package) libdbus-c++-doc - C++ API for D-Bus (documentation) libdbus-c++-ecore-1-0 - C++ API for D-Bus (runtime library with Ecore main loop) libdbus-c++-glib-1-0 - C++ API for D-Bus (runtime library with GLib main loop) libdbus-c++-ecore-1-0 and libdbus-c++-glib-1-0 are both new packages which is why dbus-c++ has to go through experimental/NEW. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dbus-c++/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dbus-c++/dbus-c++_0.9.0-12~exp1.dsc You can also find and review the individual commits in my Git repository at: https://salsa.debian.org/uhle/dbus-cplusplus Changes since the last upload: dbus-c++ (0.9.0-12~exp1) experimental; urgency=medium . * QA upload. * Move libdbus-c++-ecore-1.so.* and libdbus-c++-glib-1.so.* to their own binary packages libdbus-c++-ecore-1-0 and libdbus-c++-glib-1-0 resp. to avoid pulling in e.g. Ecore libraries (and their dependencies) on systems where these libraries are not needed. (Closes: 1018772) * Add lintian override for "library-not-linked-against-libc". Thank you in advance! Best regards, Thomas Uhle
Bug#1040610: lcf.1: some remarks and editorial fixes for the manual
Package: ucf
Version: 3.0043+nmu1
Severity: minor
Tags: patch
Dear Maintainer,
here are some notes and editorial fixes for the man page.
-.-.
The difference between the formatted outputs can be seen with:
nroff -man >
nroff -man >
diff -u
and for groff using
"groff -man -Z" instead of "nroff -man"
-.-.
Output from "mandoc -T lint lcf.1":
mandoc: lcf.1:1:52: STYLE: whitespace at end of input line
mandoc: lcf.1:2:14: STYLE: whitespace at end of input line
mandoc: lcf.1:3:71: STYLE: whitespace at end of input line
mandoc: lcf.1:11:23: STYLE: whitespace at end of input line
mandoc: lcf.1:12:23: STYLE: whitespace at end of input line
mandoc: lcf.1:13:4: STYLE: whitespace at end of input line
mandoc: lcf.1:50:11: STYLE: whitespace at end of input line
mandoc: lcf.1:54:19: STYLE: whitespace at end of input line
mandoc: lcf.1:55:24: STYLE: whitespace at end of input line
mandoc: lcf.1:69:6: STYLE: whitespace at end of input line
mandoc: lcf.1:75:2: WARNING: skipping paragraph macro: PP after SH
-.-.
Change -- in x--y to \(em (em-dash), or, if an
option, to \-\-
60:.B "-h, --help"
63:.B "-n, --no-action"
67:.B "-d [n], --debug [n]"
72:.B "-v, --verbose"
-.-.
Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.
60:.B "-h, --help"
63:.B "-n, --no-action"
67:.B "-d [n], --debug [n]"
72:.B "-v, --verbose"
-.-.
Wrong distance between sentences.
Separate the sentences and subordinate clauses; each begins on a new
line. See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").
The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.
Remember coding: Only one command ("sentence") on each (logical) line.
E-mail: Easier to quote exactly the relevant lines.
Generally: Easier to edit the sentence.
Patches: Less unaffected text.
The amount of space between sentences in the output can then be
controlled with the ".ss" request.
48:the installed version corresponds to a historical version. lcf uses
53:expected to live. Specifically, the historical md5sums are looked for
64:Dry run. Print the actions that would be taken if the script is
70:(n defaults to 1). This turns on copious debugging information.
82:There are no bugs. Any resemblance thereof is delirium. Really.
-.-.
Use \(en for a dash (en-dash) between space characters, not a minus
(\-) or a hyphen (-), except in the NAME section.
lcf.1:33:.\" Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
-.-.
The name of a man page is set in bold type and the section in roman (see
man-pages(7)).
80:ucf.conf(5).
-.-.
Name of a manual is set in bold, the section in roman.
See man-pages(7).
79:ucf(1)
-.-.
Output from "test-nroff -man -b -ww -z -rCHECKSTYLE=3":
[ "test-groff" is a developmental version of "groff" ]
Input file is ./lcf.1
Output from "test-groff -b -mandoc -dAD=l -rF0 -rHY=0 -t -w w -z
-rSTYLECHECK=3":
troff: backtrace: file '':50
troff::50: warning: trailing space in the line
troff: backtrace: file '':54
troff::54: warning: trailing space in the line
-.-.
--- lcf.1 2023-07-07 21:07:36.0 +
+++ lcf.1.new 2023-07-07 21:25:41.0 +
@@ -1,6 +1,6 @@
-.\" -*- Mode: Nroff -*-
-.\" lcf.1 ---
-.\" Author : Manoj Srivastava ( sriva...@green-gryphon.com )
+.\" -*- Mode: Nroff -*-
+.\" lcf.1 ---
+.\" Author : Manoj Srivastava ( sriva...@green-gryphon.com )
.\" Created On : Fri Feb 1 11:17:32 2002
.\" Created On Node : glaurung.green-gryphon.com
.\" Last Modified By : Manoj Srivastava
@@ -8,9 +8,9 @@
.\" Last Machine Used: glaurung.internal.golden-gryphon.com
.\" Update Count : 28
.\" Status : Unknown, Use with caution!
-.\" HISTORY :
-.\" Description :
-.\"
+.\" HISTORY :
+.\" Description :
+.\"
.\" Copyright (c) 2002 Manoj Srivastava
.\"
.\" This is free documentation; you can redistribute it and/or
@@ -30,7 +30,7 @@
.\"
.\" You should have received a copy of the GNU General Public
.\" License along with this manual; if not, write to the Free
-.\" Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+.\" Software Foundation, Inc., 59 Temple Place \(en Suite 330, Boston, MA
.\" 02111-1307, USA.
.\"
.\" $Id: lcf.1,v 1.1 2002/02/26 20:12:06 srivasta Exp $
@@ -45,41 +45,45 @@ lcf \- Determine which of the historical
.SH DESCRIPTION
This script, given a destination file name, and a directory containing
md5sums of historical versions of the file, attempts to determine if
-the installed version corresponds to a historical version. lcf uses
+the installed version corresponds to a historical version.
+lcf uses
the same algorithm that ucf uses, and should exhibit the same
-behaviour.
+behaviour.
.PP
The source directory is the place where historical md5sums are
-expected to live.
Bug#1037198: locales: please parallelise locale-gen
Hi, On 2023-06-15 22:19, наб wrote: > Hi! > > On Thu, Jun 15, 2023 at 09:26:43PM +0200, Aurelien Jarno wrote: > > On 2023-06-07 16:04, наб wrote: > > > Posting as a bug per comment from Andrej; originally posted 2022-05-06 as > > > https://salsa.debian.org/glibc-team/glibc/-/merge_requests/7 > > > > > > Patch based on current Salsa HEAD attached, incl. analysis. > > > > Thanks for the patch. I looks good, I have a comment though. > > > MemFree: in /proc/meminfo is available on all supported Debian kernels, > > > and, indeed, exactly what procps free(1) uses > > What is the reason to use MemFree instead of MemAvailable. > That's what procps free(1) used, and all Debian kernels > (kFreeBSD, Hurd, Linux) supported it. > > > The Linux > > kernel tends to maintain MemFree close to 0 by using the free RAM as > > cache. MemAvailable also includes reclaimable memory blocks like cache > > or inactive pages and therefore sounds better suited. > Since I first posted this, procps free(1) started using MemAvailable to > evaluate free/used, so sure. I don't feel strongly either way. > > A Hurd image from 2021 I have (bullseye branding) and the 2023 release > (bookworm branding) don't have MemAvailable, neither does kFreeBSD 10 > (from the 2017 installer ISO; appears to be the latest from > https://wiki.debian.org/Debian_GNU/kFreeBSD). > > I've updated the Salsa revision and am including an updated patch here, > which overrides MemFree with MemAvailable if available. Please note that I had to revert that patch in glibc 2.37-5 as it corrupts /usr/lib/locale/locale-archive and breaks systems during upgrade. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1040452: Log and rescue tips
Hi, On 2023-07-07 19:22, Raúl Sánchez Siles wrote: > Hello: > > I also came accross this and I had hard time to find out how to unlock the > system. Fortunately I didn't have to reboot or suspend it and I have a > couple of yakuake tabs opened so I could try several this. The command that > lead me here was an `apt update && apt full-upgrade` I'm attaching the apt > log (1040452_install_log.txt) that eventually lead to a almost unusable > system ( even ls core dumped, attached backtrace 1040452_ls_backtrace.txt) > > In this broken state setting LC_ALL=C allowed all commands to work. > > In order to unbreak the system I had to do the following: > > ``` > cd /var/cache/apt/archives > LC_ALL=C sudo apt reinstall ./locales_2.37-3_all.deb ./ > libc6_2.37-3_amd64.deb ./libc6_2.37-3_i386.deb ./libc6-dbg_2.37-3_amd64.deb > ./libc6-dev_2.37-3_amd64.deb ./libc6-i386_2.37-3_amd64.deb ./libc-dev- > bin_2.37-3_amd64.deb ./libc6-dev-i386_2.37-3_amd64.deb ./libc6-dev- > x32_2.37-3_amd64.deb ./libc6-x32_2.37-3_amd64.deb > ``` > After this I could perform a regular `apt update && apt full-upgrade` Thanks for all the details, that helped to find the issue. It appears that the issue is not linked to the new upstream version, but has been added by the parallelization of the locale-gen code, introduced in glibc 2.37-2. It sometimes generate correupted locale-archive file depending on the number of locales generated and the number of CPU available, plus some randomness. This will be reverted in the next upload. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1040609: traceroute.db.1: some remarks and editorial fixes for the manual
Package: traceroute
Version: 1:2.1.2-1
Severity: minor
Tags: patch
Dear Maintainer,
here are some notes and fixes for the man page.
-.-.
The difference between the formatted outputs can be seen with:
nroff -man >
nroff -man >
diff -u
and for groff using
"groff -man -Z" instead of "nroff -man"
-.-.
Output from "mandoc -T lint traceroute.db.1":
mandoc: traceroute.db.1:77:82: STYLE: input text line longer than 80 bytes:
unreachable" (or TCP...
mandoc: traceroute.db.1:148:2: WARNING: skipping paragraph macro: br before sp
mandoc: traceroute.db.1:150:2: WARNING: skipping paragraph macro: br after sp
mandoc: traceroute.db.1:157:2: WARNING: skipping paragraph macro: br before sp
mandoc: traceroute.db.1:159:2: WARNING: skipping paragraph macro: br after sp
mandoc: traceroute.db.1:234:2: WARNING: skipping paragraph macro: br before sp
mandoc: traceroute.db.1:236:2: WARNING: skipping paragraph macro: br after sp
mandoc: traceroute.db.1:241:2: WARNING: skipping paragraph macro: br before sp
mandoc: traceroute.db.1:243:2: WARNING: skipping paragraph macro: br after sp
mandoc: traceroute.db.1:252:2: WARNING: skipping paragraph macro: br before sp
mandoc: traceroute.db.1:254:2: WARNING: skipping paragraph macro: br after sp
mandoc: traceroute.db.1:260:72: STYLE: whitespace at end of input line
mandoc: traceroute.db.1:269:2: WARNING: skipping paragraph macro: br before sp
mandoc: traceroute.db.1:271:2: WARNING: skipping paragraph macro: br after sp
mandoc: traceroute.db.1:346:17: STYLE: unterminated quoted argument
mandoc: traceroute.db.1:348:17: STYLE: unterminated quoted argument
mandoc: traceroute.db.1:362:93: STYLE: input text line longer than 80 bytes:
Specifies some metho...
mandoc: traceroute.db.1:394:2: WARNING: skipping paragraph macro: br before sp
mandoc: traceroute.db.1:396:2: WARNING: skipping paragraph macro: br after sp
mandoc: traceroute.db.1:525:37: STYLE: whitespace at end of input line
mandoc: traceroute.db.1:576:2: WARNING: skipping paragraph macro: PP after SH
-.-.
Input file is traceroute.db.1, case 1
Remove space characters at the end of lines.
Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".
260:hop. The resulting value is used as a timeout for the probe, instead of
525:Intended to bypass firewall as well.
-.-.
Change -- in x--y to \(em (em-dash), or, if an
option, to \-\-
142:.B \-d, --debug
145:.B \-F, --dont-fragment
169:.BI \-f " first_ttl" ", --first=" first_ttl
172:.BI \-g " gateway" ", --gateway=" gateway
187:.BI \-i " interface" ", --interface=" interface
193:.BI \-m " max_ttl" ", --max-hops=" max_ttl
198:.BI \-N " squeries" ", --sim-queries=" squeries
210:.BI \-p " port" ", --port=" port
222:.BI \-t " tos" ", --tos=" tos
229:.BI \-l " flow_label" ", --flowlabel=" flow_label
232:.BI \-w " max\fR[\fB,\fIhere\fB,\fInear\fR]" ", --wait="
max\fR[\fB,\fIhere\fB,\fInear\fR]
292:.BI \-q " nqueries" ", --queries=" nqueries
301:.BI \-s " source_addr" ", --source=" source_addr
306:.BI \-z " sendwait" ", --sendwait=" sendwait
341:.BI \-M " method" ", --module=" name
361:.BI \-O " option" ", --options=" options
379:.BI \-P " protocol" ", --protocol=" protocol
-.-.
Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.
13:.BR "" [ "-i device" "] [" "-m max_ttl" "] [" "-p port" "] [" "-s src_addr" ]
16:.BR "" [ "-q nqueries" "] [" "-N squeries" "] [" "-t tos" ]
19:.BR "" [ "-l flow_label" "] [" "-w waittimes" "] [" "-z sendwait" "] ["
"-UL" "] [" "-D" ]
22:.BR "" [ "-P proto" "] [" "--sport=port" "] [" "-M method" "] [" "-O
mod_options" ]
25:.BR "" [ "--mtu" "] [" "--back" ]
335:.B \-N\ 1\fR\ -w\ 5 .
346:.BR "" ( "-I" ) "
348:.BR "" ( "-T" ) "
358:.BR "" ( "-I " means " -M icmp" ,
413:a common practice). It is printed as a negate value in a form of '-NUM' .
567:.B \-N\ 1\fR\ -w\ 5 .
609:.B ping -R
-.-.
Add a comma (or \&) after "e.g." and "i.e.", or use English words
(man-pages(7).
Abbreviation points should be protected against being interpreted as
an end of sentence, if they are not, and that independent of the
current place on the line.
582:implementation), i.e.
-.-.
Wrong distance between sentences.
Separate the sentences and subordinate clauses; each begins on a new
line. See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").
The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.
Remember coding: Only one command ("sentence") on each (logical) line.
E-mail: Easier to quote exactly the relevant lines.
Generally: Easier to edit the sentence.
Patches: Less unaffected text.
The amount of space between sentences in the output can then be
controlled with the ".ss" request.
N.B
The number of lines affected is too large to be in the patch.
42:way to a given host. It utilizes the IP protocol's time to live (TTL) field
69:for IPv4 and 80 for IPv6).
Bug#1040137: yajl 2.1.0-3+deb11u1 flagged for acceptance
package release.debian.org tags 1040137 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: yajl Version: 2.1.0-3+deb11u1 Explanation: memory leak security fix
Bug#1040502: rime-luna-pinyin 0.0~git20230204.79aeae2-3~deb12u1 flagged for acceptance
package release.debian.org tags 1040502 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: rime-luna-pinyin Version: 0.0~git20230204.79aeae2-3~deb12u1 Explanation: install missing pinyin schema data
Bug#1040505: rime-cantonese 0.0~git20230209.e0295fa-2~deb12u1 flagged for acceptance
package release.debian.org tags 1040505 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: rime-cantonese Version: 0.0~git20230209.e0295fa-2~deb12u1 Explanation: sort words and characters by frequency
Bug#1036676: transition: nvidia-cuda-toolkit 12
On 07/07/2023 22.30, Sebastian Ramacher wrote: Have all bugs been filed for these issues? Yes. The FTBFS ones are already autoremoved. mumax3 builds, but has a hardcoded dependency on a CUDA 11 library. I'm currently testing nvidia-cuda-samples 12 ... Andreas
Bug#1039030: transition: qtbase-abi-5-15-10
Control: tags -1 confirmed On 2023-06-24 23:13:44 +0300, Dmitry Shachnev wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > Control: block -1 by 1038402 1038737 > Control: affects -1 + src:qtbase-opensource-src > > Dear Release team, > > We skipped Qt 5.15.9 release because of the freeze, so now I would like to > upgrade from 5.15.8 to 5.15.10 — a version which was published on June 6th. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1036676: transition: nvidia-cuda-toolkit 12
Control: tags -1 moreinfo On 2023-05-24 12:07:19 +0200, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > The switch from CUDA 11 to CUDA 12 seems to have bigger impact on the > dependencies, thus I'm going to block this bug with the corresponding > FTBFS bugs. > (There are no binNMUs to be scheduled by the release team as > nvidia-cuda-toolkit is in non-free.) > > First rebuild test with 12.0.0: > FAILamd64 astra-toolbox/sid > OK amd64 bart-cuda/sid > FAILamd64 eztrace-contrib/sid > OK amd64 hwloc-contrib/sid > FAILamd64 magma/sid > OK amd64 mumax3/sid > OK amd64 nvidia-nccl/sid > OK amd64 pycuda/sid > FAILamd64 pyhst2/sid > OK amd64 pyvkfft/sid > FAILamd64 relion-cuda/sid > FAILamd64 slurm-wlm-contrib/sid > FAILamd64 starpu-contrib/sid > FAILamd64 tomopy/sid Have all bugs been filed for these issues? Cheers -- Sebastian Ramacher
Bug#1040608: [solid-pop3d] Hardcoded connection ratelimit, "per source limit exceeded"
Package: solid-pop3d Version: 0.15-31 Severity: normal Hello, If the user connects too often to the POP3 server, solid-pop3d will eventually refuse connections with a log message that "per source limit exceeded". This is really weird and inconvenient. There is no word in man spop3d.conf about such limit being present or how to configure or disable it. In my case this is a trusted network and users, and they must be allowed to connect as often as they like. -- With respect, Roman
Bug#1037166: libelementary-data: versions of libelementary1 and libelementary-data don't match on ia64
Hello Ross, thank you for your immediate response! I am sorry for the delay in my reply. On Wed, 7 Jun 2023, Ross Vandegrift wrote: Control: tags -1 wontfix Hi Thomas, On Tue, Jun 06, 2023 at 08:42:18PM +0200, Thomas Uhle wrote: > So libelementary1 (version 1.25.1-1) expects to have libelementary-data from > version 1.25.1-1 as well which is but from version 1.26.3-1 in the > repositories. That is why this dependency cannot be fulfilled on i64. That's correct - EFL requires all of its components to be upgraded jointly. And Debian likes to build arch-indep packages separately from arch-dependent. Building the binary packages separately from one another is not an issue. I think the culprit is that the arch:all packages are uploaded before the build of a corresponding architecture-dependent package has succeeded. That is why I have started a new ticket (#1040598 [2]) to ask the FTP masters and maintainers for help. > That is why some packages currently fail to build on Debian's ia64 build > servers although they would compile if libelementary1 could be installed > along with libefl-all-dev. So I see two options: could you please either > compile src:efl on ia64 using gcc-10 as long as the newer gcc versions are > crashing, or could you please put back libelementary-data from version > 1.25.1-1 into the ia64 repository. I don't think either plan is workable. Requiring gcc 10 is a temporary fix, and is more drastic than I'm keen to accommodate. I do understand that. And reverting libelementary-data won't work either - afaik, I'd have to do a new source upload which would fail due to this bug. Yes indeed, it would most likely. My second option was more about asking to copy the old version 1.25.1-1 of libelementary-data back to the ia64 repository because it is still there in the pool of the FTP servers because of oldstable (bullseye). Yet I understand that this is nothing that you can do, so again I asked the FTP masters and maintainers for help. I think this requires fixing the bugs in gcc > 10. You might ask about this on debian-i...@lists.debian.org though the thread at [1] makes me doubt you'll get a fix. Sorry, Ross [1] - https://lists.debian.org/debian-ia64/2023/05/msg0.html Thank you for the hint! Cheers, Thomas [2] https://bugs.debian.org/1040598
Bug#1040607: ubuntu-packaging-guide-html-*: broken symlinks: /usr/share/doc/ubuntu-packaging-guide-html-*/_static/*-stemmer.js -> ../../../ubuntu-packaging-guide/_static/*-stemmer.js
Source: ubuntu-packaging-guide Version: 1.0.4 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Control: affects -1 + ubuntu-packaging-guide-html-de ubuntu-packaging-guide-html-es ubuntu-packaging-guide-html-fr ubuntu-packaging-guide-html-bt-br ubuntu-packaging-guide-html-ru Hi, during a test with piuparts I noticed your package ships (or creates) broken symlinks: 0m18.4s ERROR: FAIL: Broken symlinks: /usr/share/doc/ubuntu-packaging-guide-html-de/_static/base-stemmer.js -> ../../../ubuntu-packaging-guide/_static/base-stemmer.js (ubuntu-packaging-guide-html-de) /usr/share/doc/ubuntu-packaging-guide-html-de/_static/german-stemmer.js -> ../../../ubuntu-packaging-guide/_static/german-stemmer.js (ubuntu-packaging-guide-html-de) /usr/share/doc/ubuntu-packaging-guide-html-de/singlehtml/_static/base-stemmer.js -> ../../../../ubuntu-packaging-guide/_static/base-stemmer.js (ubuntu-packaging-guide-html-de) /usr/share/doc/ubuntu-packaging-guide-html-de/singlehtml/_static/german-stemmer.js -> ../../../../ubuntu-packaging-guide/_static/german-stemmer.js (ubuntu-packaging-guide-html-de) base-stemmer.js and $lang-stemmer.js do not exist in ubuntu-packaging-guide-common cheers, Andreas
Bug#1040335: transition: gnustep-sqlclient
Control: tags -1 confirmed On 2023-07-04 18:07:11 +0300, Yavor Doganov wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: gnustep-sqlcli...@packages.debian.org > Control: affects -1 + src:gnustep-sqlclient > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-gnustep-sqlclient.html > > We would like to have release team's permission to update the > gnustep-sqlclient library (libsqlclient1.8 -> 1.9). > The only rdep is adun.app, it builds fine and can be safely binNMUed. Please go ahead Cheers -- Sebastian Ramacher
Bug#1040520: libheif1: Please don't split plugins in separate packages
Control: severity -1 normal On 2023-07-07 10:10:36 +0200, Helmut Grohne wrote: > Hi, > > On Fri, Jul 07, 2023 at 09:46:39AM +0200, Christian Marillat wrote: > > Severity: serious > > I believe that this is the wrong severity for this bug and it should be > downgraded. As I am not otherwise involved with this package, I'll leave > that up to maintainer and/or release team. Indeed, downgrading. Cheers -- Sebastian Ramacher
Bug#1040605: python3-django-ckeditor: broken symlink: /usr/lib/python3/dist-packages/ckeditor/static/ckeditor/galleriffic -> ../../../../../../share/javascript/galleriffic
Package: python3-django-ckeditor Version: 6.1.0+ds-1 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink: 0m41.2s ERROR: FAIL: Broken symlinks: /usr/lib/python3/dist-packages/ckeditor/static/ckeditor/galleriffic -> ../../../../../../share/javascript/galleriffic (python3-django-ckeditor) The target needs to be /usr/share/javascript/jquery-galleriffic ^^^ cheers, Andreas
Bug#1040604: r8168-dkms: Module r8168-dkms does not override r8169 under linux mint 21.1
Package: r8168-dkms Version: 8.049.02-1ubuntu1.1 Severity: important X-Debbugs-Cc: eric.bugrep...@gmail.com Dear Maintainer, I installed r8168-dkms from the Synaptics repository. I tried to blacklist r8169 unsuccessfully. I ended up with the same driver as before. I expected a driver which supports gigabyte speeds. Thanks a lot for considering this issue. -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-76-generic (SMP w/1 CPU thread) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages r8168-dkms depends on: ii dkms 2.8.7-2ubuntu2.1mint1 r8168-dkms recommends no packages. r8168-dkms suggests no packages. -- no debconf information
Bug#1040593: kodi: CVE-2023-30207
Control: fixed -1 2:20.0~rc2+dfsg-2 Dear Moritz, Thanks for the report! I fixed it proactively back in 20.0~rc2+dfsg-2 so only oldstable and oldstable-bpo are affected. I will upload the backport from bookworm to bullseye-bpo soon. -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#1040603: transmission: Please package 4.0.3
Source: transmission Version: 4.0.2-1 Severity: wishlist transmission 4.0.3 was released in April. Please package it. https://github.com/transmission/transmission/releases/ Thank you, Jeremy Bícha
Bug#1040602: python3-flask-appbuilder: broken symlink: /usr/lib/python3/dist-packages/flask_appbuilder/static/appbuilder/css/themes/solar.css -> ../../../../../../../../share/javascript/bootswatch/sol
Package: python3-flask-appbuilder Version: 4.1.4+ds-3 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink: 0m59.6s ERROR: FAIL: Broken symlinks: /usr/lib/python3/dist-packages/flask_appbuilder/static/appbuilder/css/themes/solar.css -> ../../../../../../../../share/javascript/bootswatch/solar/bootstrap.min.css (python3-flask-appbuilder) There are two possible candidates in python3-flask-bootstrap: /usr/lib/python3/dist-packages/flask_bootstrap/static/bootstrap4/css/bootswatch/solar/bootstrap.min.css /usr/lib/python3/dist-packages/flask_bootstrap/static/bootstrap5/css/bootswatch/solar/bootstrap.min.css cheers, Andreas
Bug#1040601: python3-typedload-doc: broken symlink: /usr/share/doc/python3-typedload/docs/README.md -> ../README.md
Package: python3-typedload-doc Version: 2.24-1 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink: 0m32.5s ERROR: FAIL: Broken symlinks: /usr/share/doc/python3-typedload/docs/README.md -> ../README.md (python3-typedload-doc) cheers, Andreas
Bug#1040600: python-aiodogstatsd-doc: broken symlink: /usr/share/doc/python-aiodogstatsd-doc/html/fonts/FontAwesome.otf -> ../../../../fonts-font-awesome/fonts/fontawesome-webfont.oft
Package: python-aiodogstatsd-doc Version: 0.16.0-2 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink: 0m18.8s ERROR: FAIL: Broken symlinks: /usr/share/doc/python-aiodogstatsd-doc/html/fonts/FontAwesome.otf -> ../../../../fonts-font-awesome/fonts/fontawesome-webfont.oft (python-aiodogstatsd-doc) There is no .otf version of fontawesome-webfont (and .oft is an unknown font extension ..). You probably want to target /usr/share/fonts/opentype/font-awesome/FontAwesome.otf cheers, Andreas
Bug#1040001: adds unnecessarily strict versioned Depends on r-base-core
Control: reopen -1 Thanks for watching me, Bas. Am Fri, Jul 07, 2023 at 05:09:31PM +0200 schrieb Sebastiaan Couwenberg: > It seems that dh-r (20230707) should have closed #1040515 instead of the > transition bug report (#1040001). -- http://fam-tille.de
Bug#1040599: pampi: broken symlinks: /usr/share/pampi/presentations/assets/fonts/Andika-R.woff, /usr/share/pampi/presentations/assets/tools/D3/d3.min.js
Package: pampi Version: 1.1+dfsg1-7 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) broken symlinks: 1m22.2s ERROR: FAIL: Broken symlinks: /usr/share/pampi/presentations/assets/fonts/Andika-R.woff -> ../../../../fonts-sil-andika/woff/Andika-R.woff (pampi) /usr/share/pampi/presentations/assets/tools/D3/d3.min.js -> ../../../../../javascript/d3/d3..min.js (pampi) fonts-sil-andika renamed the font file to Andika-Regular.woff and you should minimize the dots in the .js target ;-) cheers, Andreas
Bug#1040598: dak: upload of arch:all packages may make architecture-dependend packages uninstallable
Package: ftp.debian.org Severity: normal Usertags: dak Dear FTP masters and maintainers, arch:all packages are currently built on amd64 buildds and then uploaded to all Debian repositories (for sid) without taking into account whether the build of an accompanying architecture-dependent binary package has already succeeded or not. This behavior is okay if only arch:all binary packages are built from the corresponding source package. But if the build on amd64 has been successful but not on ia64 for instance, then the arch:all packages are uploaded to the ia64 repository as well although the other arch:ia64 packages from the same source cannot be updated, and there it is, a version mismatch. This might lead to a situation where an architecture-dependent binary package cannot be installed any longer if it depends on an arch:all package that recently has been updated, that is the case for libelementary1:ia64 for instance (cf. #1037166 [1]). In this case, libelementary1:ia64 is still at version 1.25.1-1 because src:efl fails to build because any gcc > 10 crashes during the build on ia64 (cf. [2]). On the other hand, libelementary-data:all has been built on amd64 and so has always been updated (also incl. ia64), currently being at version 1.26.3-1. But libelementary1:ia64 depends on libelementary-data:all with exactly the same source version. I'd like to ask you two things: 1. Could you please fix the ia64 repository to refer to libelementary-data version 1.25.1-1 again? 2. Could you please implement something into dak that automatically checks if a corresponding architecture-dependent build was successful and then maybe defer the upload of successfully built arch:all packages to the repository for this very architecture if this architecture-dependent build has failed? If there would be such a mechanism, then a situation like this could be prevented in the future. Anyway, you might think that this issue might somehow be related to #915948 [3]. But I have the feeling that this issue has still a different aspect which is why I have started this new ticket. Thank you for your comprehension and support! Best regards, Thomas Uhle [1] https://bugs.debian.org/1037166 [2] https://buildd.debian.org/status/package.php?p=efl=ia64 [3] https://bugs.debian.org/915948
Bug#1040597: orthanc: CVE-2023-33466
Source: orthanc X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for orthanc. CVE-2023-33466[0]: | Orthanc before 1.12.0 allows authenticated users with access to the | Orthanc API to overwrite arbitrary files on the file system, and in | specific deployment scenarios allows the attacker to overwrite the | configuration, which can be exploited to trigger Remote Code | Execution (RCE). https://discourse.orthanc-server.org/t/security-advisory-for-orthanc-deployments-running-versions-before-1-12-0/3568 If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-33466 https://www.cve.org/CVERecord?id=CVE-2023-33466 Please adjust the affected versions in the BTS as needed.
Bug#1040595: yt-dlp: CVE-2023-35934
Source: yt-dlp X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for yt-dlp. CVE-2023-35934[0]: | yt-dlp is a command-line program to download videos from video | sites. During file downloads, yt-dlp or the external downloaders | that yt-dlp employs may leak cookies on HTTP redirects to a | different host, or leak them when the host for download fragments | differs from their parent manifest's host. This vulnerable behavior | is present in yt-dlp prior to 2023.07.06 and nightly | 2023.07.06.185519. All native and external downloaders are affected, | except for `curl` and `httpie` (version 3.1.0 or later). At the | file download stage, all cookies are passed by yt-dlp to the file | downloader as a `Cookie` header, thereby losing their scope. This | also occurs in yt-dlp's info JSON output, which may be used by | external tools. As a result, the downloader or external tool may | indiscriminately send cookies with requests to domains or paths for | which the cookies are not scoped. yt-dlp version 2023.07.06 and | nightly 2023.07.06.185519 fix this issue by removing the `Cookie` | header upon HTTP redirects; having native downloaders calculate the | `Cookie` header from the cookiejar, utilizing external downloaders' | built-in support for cookies instead of passing them as header | arguments, disabling HTTP redirectiong if the external downloader | does not have proper cookie support, processing cookies passed as | HTTP headers to limit their scope, and having a separate field for | cookies in the info dict storing more information about scoping | Some workarounds are available for those who are unable to upgrade. | Avoid using cookies and user authentication methods. While | extractors may set custom cookies, these usually do not contain | sensitive information. Alternatively, avoid using `--load-info- | json`. Or, if authentication is a must: verify the integrity of | download links from unknown sources in browser (including redirects) | before passing them to yt-dlp; use `curl` as external downloader, | since it is not impacted; and/or avoid fragmented formats such as | HLS/m3u8, DASH/mpd and ISM. https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-v8mc-9377-rwjj https://github.com/yt-dlp/yt-dlp/commit/1ceb657bdd254ad961489e5060f2ccc7d556b729 https://github.com/yt-dlp/yt-dlp/commit/3121512228487c9c690d3d39bfd2579addf96e07 https://github.com/yt-dlp/yt-dlp/commit/f8b4bcc0a791274223723488bfbfc23ea3276641 If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-35934 https://www.cve.org/CVERecord?id=CVE-2023-35934 Please adjust the affected versions in the BTS as needed.
Bug#1040596: phog: broken symlink: /etc/phog/logo.png -> /usr/share/images/vendor-logos/logo-text-version-64.png
Package: phog Version: 0.1.3-2 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink: 1m17.0s ERROR: FAIL: Broken symlinks: /etc/phog/logo.png -> /usr/share/images/vendor-logos/logo-text-version-64.png (phog) cheers, Andreas
Bug#1040593: kodi: CVE-2023-30207
Source: kodi X-Debbugs-CC: t...@security.debian.org Severity: normal Tags: security Hi, The following vulnerability was published for kodi. CVE-2023-30207[0]: | A divide by zero issue discovered in Kodi Home Theater Software 19.5 | and earlier allows attackers to cause a denial of service via use of | crafted mp3 file. https://github.com/xbmc/xbmc/issues/22378 https://github.com/xbmc/xbmc/pull/22391 https://github.com/xbmc/xbmc/commit/dbc00c500f4c4830049cc040a61c439c580eea73 If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-30207 https://www.cve.org/CVERecord?id=CVE-2023-30207 Please adjust the affected versions in the BTS as needed.
Bug#1040594: libcoap3: CVE-2023-30362
Source: libcoap3 X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for libcoap3. CVE-2023-30362[0]: | Buffer Overflow vulnerability in coap_send function in libcoap | library 4.3.1-103-g52cfd56 fixed in 4.3.1-120-ge242200 allows | attackers to obtain sensitive information via malformed pdu. https://github.com/obgm/libcoap/issues/1063 https://github.com/obgm/libcoap/commit/e242200f0af2a418dc9f69eee543feacc13cd851 If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-30362 https://www.cve.org/CVERecord?id=CVE-2023-30362 Please adjust the affected versions in the BTS as needed.
Bug#1040592: node-dottie: CVE-2023-26132
Source: node-dottie X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for node-dottie. CVE-2023-26132[0]: | Versions of the package dottie before 2.0.4 are vulnerable to | Prototype Pollution due to insufficient checks, via the set() | function and the current variable in the /dottie.js file. https://security.snyk.io/vuln/SNYK-JS-DOTTIE-3332763 https://github.com/mickhansen/dottie.js/commit/7d3aee1c9c3c842720506e131de7e181e5c8db68 If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-26132 https://www.cve.org/CVERecord?id=CVE-2023-26132 Please adjust the affected versions in the BTS as needed.
Bug#1040591: postgresql-15-tablelog: broken symlink: /usr/share/doc/postgresql-15-tablelog/README.md -> table_log.md
Package: postgresql-15-tablelog Version: 0.6.3-2 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink: 0m23.2s ERROR: FAIL: Broken symlinks: /usr/share/doc/postgresql-15-tablelog/README.md -> table_log.md (postgresql-15-tablelog) cheers, Andreas
Bug#1040590: ITP: tecla -- keyboard layout viewer for the GNOME desktop
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-gtk-gn...@lists.debian.org Owner: jeremy.bi...@canonical.com Package Name: tecla Version: 45~alpha Upstream Author: Red Hat License: GPL-2+ Programming Lang: C Description: keyboard layout viewer for the GNOME desktop This app is a basic keyboard layout viewer for integration with the GNOME desktop. Other Info -- This package will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/tecla It is expected that Tecla will be a dependency of GNOME Shell & the GNOME Settings app (gnome-control-center) for GNOME 45 later this year. Tecla is a basic app written in GTK4 & libadwaita and would replace gkbd-capplet (provided by libgnomekbd) for the GNOME desktop. Thanks, Jeremy Bícha
Bug#1040589: psychopy: broken symlink: /usr/lib/python3/dist-packages/psychopy/app/Resources/fonts/DejaVuSerif.ttf -> ../../../../../../../share/texlive/texmf-dist/fonts/truetype/public/dejavu/DejaVuS
Package: psychopy Version: 2022.1.3+dfsg-1 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink. >From the attached log (scroll to the bottom...): 2m46.6s ERROR: FAIL: Broken symlinks: /usr/lib/python3/dist-packages/psychopy/app/Resources/fonts/DejaVuSerif.ttf -> ../../../../../../../share/texlive/texmf-dist/fonts/truetype/public/dejavu/DejaVuSerif.ttf (psychopy) The link should target /usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf from fonts-dejavu-core which the package already depends on. cheers, Andreas
Bug#1040583: execnet: implicitly depends on python3-py
* Scott Talbert [2023-07-07 14:40]: On Fri, 7 Jul 2023, Timo Röhling wrote: Source: execnet Version: 1.9.0-2 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [Scott: Apologies that I missed this earlier, and thanks for fixing apipkg so quickly] Hey Timo, I already fixed this in execnet 1.9.0-2 (this log appears to be from execnet 1.9.0-1) after you reported the problem on apipkg. Oops, my bad! I'll close this, then. -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1040500: routine-update: Don't create d/salsa-ci.yml file
I'd say thanks for opening the bug entry, because I was not well aware of the latest best practices with using salsa ci, nor was I aware that it was possible to refer to a generic forge-wide pipeline. I'll try this on a bunch of packages to see how this works. As far as I can read, having d/salsa-ci.yml remains useful for packages that include customisations, like excluding unworkable test items, or running the pipeline against stable. But this should remain exceptional. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Ayreon - Intergalactic Space Crusaders signature.asc Description: PGP signature
Bug#1040583: execnet: implicitly depends on python3-py
On Fri, 7 Jul 2023, Timo Röhling wrote: Source: execnet Version: 1.9.0-2 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [Scott: Apologies that I missed this earlier, and thanks for fixing apipkg so quickly] Hey Timo, I already fixed this in execnet 1.9.0-2 (this log appears to be from execnet 1.9.0-1) after you reported the problem on apipkg. Scott
Bug#1040588: quorum: broken symlink: /usr/share/doc/quorum/README -> README.md
Package: quorum Version: 1.1.2-1 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink: 0m12.8s ERROR: FAIL: Broken symlinks: /usr/share/doc/quorum/README -> README.md (quorum) cheers, Andreas
Bug#1040587: rdp-classifier-doc: broken symlink: /usr/share/doc/rdp-classifier-doc/api/jquery/jquery-3.5.1.js -> ../../../../javascript/jquery/query.js
Package: rdp-classifier-doc Version: 2.10.2-6 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink: 0m17.0s ERROR: FAIL: Broken symlinks: /usr/share/doc/rdp-classifier-doc/api/jquery/jquery-3.5.1.js -> ../../../../javascript/jquery/query.js (rdp-classifier-doc) The target needs to be *j*query.js cheers, Andreas
Bug#1040221: toot: auth output needs a raw option
control: tags -1 upstream * Jonathan Carter 'j...@debian.org' via 33Mail [2023-07-07 17:34]: > On 2023/07/03 19:51, Sandro Tosi wrote: > > It would be nice if you could report all the issues you opened > > upstream at the link above and forward > > (https://www.debian.org/Bugs/server-control#forwarded) the debian bugs > > to the upstream once. > > +1, that would be ideal, we don't write code for toot or add new features > for it in Debian, we package the upstream version, and might carry some bug > fixes in the form of patches until they're fixed upstream, but other than > that, I suggest filing ideas for improvement on the upstream bug tracker. > > thanks and keep well! I’m not keen on using MS Github. The 2fa system blocks me because the registered email address there forces me to login to an account with a typically broken CAPTCHA. I also have ethical problems with using Microsoft assets. I understand the frustration though. I wouldn’t want your job. I’m glad the Debian BTS gives an easy way to report bugs so they are at least captured somewhere. There are plans to move the toot upstream bug tracker to a more accessible location (Sourceforge). Is there any issue with letting the bugs sit until that happens? I suppose the worst that could happen is they get archived during the wait, but at least they’re still reachable after archiving. I’ve noticed other maintainers being (understandably) reluctant to forward bugs upstream. What can be improved in the Debian BTS? It seems automation is lacking. Shouldn’t there be a simple control signal to the BTS to say “forward this upstream”, and the machinery does the rest? There is a developer tag “upstream”: https://www.debian.org/Bugs/Developer#tags Suppose that tag is applied to the bug reports I submitted. Would it help the management of the bug reports? Perhaps we could use that to tag bug reports waiting to be forwarded so they can be filtered out in searches, and so someone willing and able to use MS assets could perhaps use that tag to query bugs to forward.
Bug#960538: RFP ffsend
Hi Alexandre, from a first glance it looks like ffsend-api is missing as dependency. Unfortunately it's considered deprecated; I opened an issue upstream about it. I hope upstream considers a switch and it can make it into trixie. regards, --- Matthias Geiger (werdahias) -BEGIN PGP PUBLIC KEY BLOCK- mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69 ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7 T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1 /4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi 7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8 sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds 5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1 bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5 MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR 4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6 fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4 QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7 OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx +gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5 ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39 HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/ /LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR 04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg== =onWA -END PGP PUBLIC KEY BLOCK-
Bug#1037135: please update to latest upstream version (>> 4.2.0) and confirm intent to maintain package
Hey! Thanks for dropping the email to this address, and apologies for causing trouble by letting the previous address go dead. I stopped updating the package because the docs of modus-themes are licensed such that they cannot be added to Debian repos anymore. They'll have to be split and moved to debian-contrib. I do not know how to do this, and haven't looked into it since I last tried. I shall try to get it done soon(TM). Bremner had suggested we can let go of the docs for now. If I cannot figure things out in time, perhaps we can explore this path as well. In any case, I shall be attempting to upgrade soon. Sent with Proton Mail secure email. --- Original Message --- On Thursday, July 6th, 2023 at 04:11, Nicholas D Steeves wrote: > Hi Dhavan, > > I'm forwarding this to your new email address, so there will be a record > about how to contact you: > > Nicholas D Steeves s...@debian.org writes: > > > Source: modus-themes > > Version: 1.0.2-1 > > Severity: normal > > X-Debbugs-Cc: Dhavan Vaidya qu...@codingquark.com > > > > Hi Dhavan, > > > > I hope this email finds you in good health. Are you still interested > > in maintaining modus-themes? The repository hasn't seen any activity > > since 2021, the current stable upstream version is now 4.2.0, and this > > makes it look like the package is effectively unmaintained. > > > Please note that modus-themes is currently a salvaging candidate: > > https://wiki.debian.org/PackageSalvaging > > Regards, > Nicholas
Bug#986357: Please improve package description
Hi! On Sat, 2023-02-25 at 03:58:34 +, peter green wrote: > As far as the current description goes, I think it's generally not > too bad but I think there are some minor improvements that could be > made. […] > * I feel it lacks a bit in "big picture", I *think* sqv is the main > command line tool for the sequoia project. If that is the case > it would be nice to say so expliciltly and upfront. The main CLI is sq. The sqv CLI is intended to be the equivalent of gpgv, as in a verification only tool, where the full blown thing is not necessary. > Also since > people will be comparing it with gpg it might be an idea to point > out explicitly whether things like web of trust support are > included. AFAIK there's a separate sq-wot tool for this. Other related projects include sq-keyring-linter and sqop, or even the GnuPG Chameleon, or openpgp-cert-d among others. > * I'm not sure a list of subcommands belongs in a package > description or if the description would be better sticking > to describing functionality. Given that the CLI is still in flux, I guess for now it might be helpful, but perhaps a more descriptive one might be better, dunno. Thanks, Guillem
Bug#1040586: krita: Krita Comics Manager crashes creating new template or page
Package: krita
Version: 1:5.1.5+dfsg-2
Severity: normal
X-Debbugs-Cc: fenix...@gmail.com
Dear Maintainer,
* What led up to the situation?
Creating new page with Krita Comic Manager Docker plugin throws exceptions:
* How reproduce the error:
1) Open Comics Manager Docker from Settings/Dockers.
2) Create new project.
3) Create new page and Create Template. We get error.
If you paste a previous template, you get other error creating a new page.
These is the errors:
1) Creating a new template throws:
TypeError
Python 3.11.4: /usr/bin/python3
Fri Jul 7 20:12:19 2023
A problem occurred in a Python script. Here is the sequence of
function calls leading up to the error, in the order they occurred.
/usr/share/krita/pykrita/comics_project_management_tools/comics_template_dialog.py
in
slot_create_template(self=)
112
113 if create.exec_() == QDialog.Accepted:
114 if (create.prepare_krita_file()):
115 self.fill_templates()
116
create =
create.prepare_krita_file = >
/usr/share/krita/pykrita/comics_project_management_tools/comics_template_dialog.py
in
prepare_krita_file(self=)
298 mB =
self.marginBottomUnit.pixelsForUnit(self.marginBottom.value(),
self.DPI.value())
299
300 template = Application.createDocument((wBase + bL + bR), (hBase +
bT + bB), self.templateName.text(), "RGBA", "U8", "sRGB built-in",
self.DPI.value())
301
302 backgroundName = i18n("Background")
template undefined
builtinApplication =
Application.createDocument =
wBase = 2480.314960629921
bL = 59.055118110236215
bR = 59.055118110236215
hBase = 3507.874015748031
bT = 118.11023622047243
bB = 118.11023622047243
self =
self.templateName =
self.templateName.text =
self.DPI =
self.DPI.value =
TypeError: createDocument(self, int, int, str, str, str, str, float): argument
1 has unexpected type 'float'
__cause__ = None
__class__ =
__context__ = None
__delattr__ =
__dict__ = {}
__dir__ =
__doc__ = 'Inappropriate argument type.'
__eq__ =
__format__ =
__ge__ =
__getattribute__ =
__getstate__ =
__gt__ =
__hash__ =
__init__ =
__init_subclass__ =
__le__ =
__lt__ =
__ne__ =
__new__ =
__reduce__ =
__reduce_ex__ =
__repr__ =
__setattr__ =
__setstate__ =
__sizeof__ =
__str__ =
__subclasshook__ =
__suppress_context__ = False
__traceback__ =
add_note =
args = ("createDocument(self, int, int, str, str, str, str, float):
argument 1 has unexpected type 'float'",)
with_traceback =
The above is a description of an error in a Python program. Here is
the original traceback:
Traceback (most recent call last):
File
"/usr/share/krita/pykrita/comics_project_management_tools/comics_template_dialog.py",
line 114, in slot_create_template
if (create.prepare_krita_file()):
^^^
File
"/usr/share/krita/pykrita/comics_project_management_tools/comics_template_dialog.py",
line 300, in prepare_krita_file
template = Application.createDocument((wBase + bL + bR), (hBase + bT + bB),
self.templateName.text(), "RGBA", "U8", "sRGB built-in", self.DPI.value())
^^^
TypeError: createDocument(self, int, int, str, str, str, str, float): argument
1 has unexpected type 'float'
2) Creating a page using a previous template throws:
TypeError
Python 3.11.4: /usr/bin/python3
Fri Jul 7 20:15:31 2023
A problem occurred in a Python script. Here is the sequence of
function calls leading up to the error, in the order they occurred.
/usr/share/krita/pykrita/comics_project_management_tools/comics_project_manager_docker.py
in
paint(self=, painter=,
option=,
index=)
94 thumbImage = icon.pixmap(imageSizeHighDPI).toImage()
95 thumbImage.setDevicePixelRatio(self.devicePixelRatioF)
96 painter.drawImage(QRect(leftSideThumbnail, topSizeThumbnail,
imageSize.width(), imageSize.height()), thumbImage)
97
98 labelWidth = rect.width()-decoratonSize.width()-(margin*3)
painter =
painter.drawImage =
global QRect =
leftSideThumbnail = 19.0
topSizeThumbnail = 4.0
imageSize = PyQt5.QtCore.QSize(90, 128)
imageSize.width =
imageSize.height =
thumbImage =
TypeError: arguments did not match any overloaded call:
QRect(): too many arguments
QRect(aleft: int, atop: int, awidth: int, aheight: int): argument 1 has
unexpected type 'float'
QRect(atopLeft: QPoint, abottomRight: QPoint): argument 1 has unexpected type
'float'
QRect(atopLeft: QPoint, asize: QSize): argument 1 has unexpected type 'float'
QRect(a0: QRect): argument 1 has unexpected type 'float'
__cause__ = None
__class__ =
__context__ = None
__delattr__ =
__dict__ = {}
__dir__ =
__doc__ =
Bug#1000101: eterm: depends on obsolete pcre3 library
Bastian Germann wrote: > Hi, > > I am uploading a NMU to fix this. The debdiff is attached. > > Sincerely, > Bastian Thank you so much for fixing this. I am planing to review build dependences to removed those no needed. Sincerely, Jose
Bug#1040585: ruby-kitchen-salt: broken symlink: /usr/share/rubygems-integration/all/gems/kitchen-salt-0.6.3/docs/README.md -> ../README.md
Package: ruby-kitchen-salt Version: 0.7.0-1 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink: 0m25.2s ERROR: FAIL: Broken symlinks: /usr/share/rubygems-integration/all/gems/kitchen-salt-0.6.3/docs/README.md -> ../README.md (ruby-kitchen-salt) This looks like the version in the path has not been updated, the package is already at 0.7.0. cheers, Andreas
Bug#1040584: seek-bzip: broken symlinks: /usr/bin/seek-bunzip, /usr/bin/seek-table
Package: seek-bzip Version: 1.0.5-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) broken symlinks: 0m22.5s ERROR: FAIL: Broken symlinks: /usr/bin/seek-bunzip -> ../share/nodejs/@openpgp/seek-bzip/bin/seek-bunzip (seek-bzip) /usr/bin/seek-table -> ../share/nodejs/@openpgp/seek-bzip/bin/seek-bzip-table (seek-bzip) cheers, Andreas
Bug#1040583: execnet: implicitly depends on python3-py
Source: execnet
Version: 1.9.0-2
Severity: serious
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
[Scott: Apologies that I missed this earlier, and thanks for fixing apipkg
so quickly]
Dear maintainer,
your package implicitly depends on python3-py for its autopkgtest, which used
to be provided by python3-pytest. However, pytest has dropped that dependency,
breaking your autopkgtest and possibly your package.
Note that you can replace py.test.foo with pytest.foo and avoid the
dependency on python3-py altogether.
Cheers
Timo
- ---
Relevant excerpt from
https://ci.debian.net/data/autopkgtest/testing/amd64/e/execnet/35449822/log.gz
23s ERRORS
23s ___ ERROR collecting testing/test_channel.py
___
23s /usr/lib/python3/dist-packages/_pytest/runner.py:341: in from_call
23s result: Optional[TResult] = func()
23s /usr/lib/python3/dist-packages/_pytest/runner.py:372: in
23s call = CallInfo.from_call(lambda: list(collector.collect()), "collect")
23s /usr/lib/python3/dist-packages/_pytest/python.py:531: in collect
23s self._inject_setup_module_fixture()
23s /usr/lib/python3/dist-packages/_pytest/python.py:545: in
_inject_setup_module_fixture
23s self.obj, ("setUpModule", "setup_module")
23s /usr/lib/python3/dist-packages/_pytest/python.py:310: in obj
23s self._obj = obj = self._getobj()
23s /usr/lib/python3/dist-packages/_pytest/python.py:528: in _getobj
23s return self._importtestmodule()
23s /usr/lib/python3/dist-packages/_pytest/python.py:617: in _importtestmodule
23s mod = import_path(self.path, mode=importmode,
root=self.config.rootpath)
23s /usr/lib/python3/dist-packages/_pytest/pathlib.py:565: in import_path
23s importlib.import_module(module_name)
23s /usr/lib/python3.11/importlib/__init__.py:126: in import_module
23s return _bootstrap._gcd_import(name[level:], package, level)
23s :1204: in _gcd_import
23s ???
23s :1176: in _find_and_load
23s ???
23s :1147: in _find_and_load_unlocked
23s ???
23s :690: in _load_unlocked
23s ???
23s /usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:178: in
exec_module
23s exec(co, module.__dict__)
23s testing/test_channel.py:9: in
23s from test_gateway import _find_version
23s :1176: in _find_and_load
23s ???
23s :1147: in _find_and_load_unlocked
23s ???
23s :690: in _load_unlocked
23s ???
23s /usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:178: in
exec_module
23s exec(co, module.__dict__)
23s testing/test_gateway.py:17: in
23s from test_serializer import _find_version
23s :1176: in _find_and_load
23s ???
23s :1147: in _find_and_load_unlocked
23s ???
23s :690: in _load_unlocked
23s ???
23s /usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:178: in
exec_module
23s exec(co, module.__dict__)
23s testing/test_serializer.py:150: in
23s @py.test.mark.parametrize(["tp_name", "repr"], simple_tests)
23s E AttributeError: module 'py' has no attribute 'test'
23
-BEGIN PGP SIGNATURE-
iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSoVEsACgkQ+C8H+466
LVm89wv8Cz9wo+zRK8AHwz/BRiAITe4M+3+kuoi8JnlypnmSRaicPx00Ynpv7Kxu
dMBnZVzpxeZjcTwpYaFyjYerX9nwCrRwCAqlYsup/p+50eWc3BjuLi8Ob6PD58zj
ikVzaO+4GNyBmVkAi30HiYem6UZ6jPaPwbJ0Td0aqX2thJWW9bhdnwtACgI1rsoJ
R9NF3US/YHyu3A7ewzREU0Kgq+pMh/VTqHqUV50NVxllTPLdZn7kKm94yTcI2R49
ivwrAiFlnZjNXAfETUJ7UU22Af3xRwVH806o4UU5VG0ytPWpTkDA7o8Qgtz0K2kv
/+P9e7Sp7SbGjYanx4mdc49r8HzkpbI/60dmYCILBDx4UxyxccWCTw7YQnPs5CN5
81WRHx3CXJQpZ7TzVk4+SBRMK7+xkMYnqxmWl55+ffSkMGWGpmqnaMz2zCqSQKUq
OijAxNyAnQ80WxkidCDXfXw2PiSaT3jZAlI6VWyGNFK8mOVFuxad/eHd5CFpktaB
IkRR4iLU
=ZzQ2
-END PGP SIGNATURE-
Bug#1040582: stress-ng: improve the build dependencies (more availability, linux-any markers)
Source: stress-ng Version: 0.16.00-1 Severity: minor Tags: patch Hi, some of the build dependencies can be improved: - what is specific for Linux ought to be better marked as "linux-any", rather than excluding non-Linux architectures - some of the them are actually available on non-Linux too Attached there is a patch to improve them, with some extra details in the changelog. Thanks, -- Pino diff -Nru stress-ng-0.16.00/debian/changelog stress-ng-0.16.00/debian/changelog --- stress-ng-0.16.00/debian/changelog +++ stress-ng-0.16.00/debian/changelog @@ -1,3 +1,17 @@ +stress-ng (0.16.00-2) UNRELEASED; urgency=medium + + [ Pino Toscano ] + * Update/improve the build dependencies: +- enable libkeyutils-dev also on ia64, as it is available there as well +- enable libjudy-dev, libxxhash-dev, and libglvnd-dev on all the + architectures, as they are not specific to a certain OS +- switch the build dependencies that exist only on Linux from + "!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64" to "linux-any": + libkeyutils-dev, libapparmor-dev, apparmor, libaio-dev, libcap-dev, + libsctp-dev, libatomic1, libkmod-dev, libgbm-dev + + -- Colin Ian King Fri, 07 Jul 2023 19:47:54 +0200 + stress-ng (0.16.00-1) unstable; urgency=medium * Makefile: bump version to 0.16.00 diff -Nru stress-ng-0.16.00/debian/control stress-ng-0.16.00/debian/control --- stress-ng-0.16.00/debian/control +++ stress-ng-0.16.00/debian/control @@ -12,19 +12,19 @@ libgcrypt20-dev, libjpeg-dev, libmpfr-dev, - libkeyutils-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64 !linux-ia64], - libapparmor-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - apparmor [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libaio-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libcap-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libsctp-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], + libkeyutils-dev [linux-any], + libapparmor-dev [linux-any], + apparmor [linux-any], + libaio-dev [linux-any], + libcap-dev [linux-any], + libsctp-dev [linux-any], libipsec-mb-dev [amd64], - libjudy-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libatomic1 [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libkmod-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libxxhash-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libglvnd-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libgbm-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64] + libjudy-dev, + libatomic1 [linux-any], + libkmod-dev [linux-any], + libxxhash-dev, + libglvnd-dev, + libgbm-dev [linux-any] Homepage: https://github.com/ColinIanKing/stress-ng Package: stress-ng
Bug#1040581: mdp: implicitly depends on python3-py
Source: mdp Version: 3.6-2 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package implicitly depends on python3-py for its autopkgtest, which used to be provided by python3-pytest. However, pytest has dropped that dependency, breaking your autopkgtest and possibly your package. Note that you can replace py.test.foo with pytest.foo and avoid the dependency on python3-py altogether. Cheers Timo - --- Relevant excerpt from https://ci.debian.net/data/autopkgtest/testing/amd64/m/mdp/35449827/log.gz 29s ERRORS 29s _ ERROR collecting mdp/test/test_NormalizingRecursiveExpansionNode.py __ 29s ImportError while importing test module '/tmp/autopkgtest-lxc.lsh0veg9/downtmp/build.Ujr/src/mdp/test/test_NormalizingRecursiveExpansionNode.py'. 29s Hint: make sure your test modules/packages have valid Python names. 29s Traceback: 29s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 29s return _bootstrap._gcd_import(name[level:], package, level) 29s mdp/test/test_NormalizingRecursiveExpansionNode.py:10: in 29s import py.test 29s E ModuleNotFoundError: No module named 'py.test'; 'py' is not a package 29s ___ ERROR collecting mdp/test/test_RecursiveExpansionNode.py ___ 29s ImportError while importing test module '/tmp/autopkgtest-lxc.lsh0veg9/downtmp/build.Ujr/src/mdp/test/test_RecursiveExpansionNode.py'. 29s Hint: make sure your test modules/packages have valid Python names. 29s Traceback: 29s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 29s return _bootstrap._gcd_import(name[level:], package, level) 29s mdp/test/test_RecursiveExpansionNode.py:11: in 29s import py.test 29s E ModuleNotFoundError: No module named 'py.test'; 'py' is not a package -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSoUowACgkQ+C8H+466 LVlvMAwA1FH2THkigYTPZWTpOOaeAsktk6oq/KMg9iDEmAoiX9gSHi2MrE4m/Syw AlRvWE0UVGRgwCgVUtq1c2DNkG8u78HILvoHDo0y76at/NwdaGV7mDkSyDrlFfhx elFxFVixX6MwMf6lHmX5TB+zP2oDLbybhfWxB7qqR9P5Ep2bEzZTYnTYbGHG7QN9 1Gg+7WqTMwohVBF++HdUTVe036HBlJOO4opqvnF2go1GA0ZoRw2rbNi6kiEiti/Y Dzhb9k4H77T9d2McqLCDmwrbGwoYQVcpKaJM5kLEWuNZxuqQPGmuDV3KDO3CQ7pZ K1EZxvkgW5HY5t6wl2ucQVZ3IOioi+2dDoT2OikURdz9zR+1dzvde1o/HojvySET /X5YHb+Vn/aOpR0tm4dUbJo8mugQGHzZJSwrfj0Fd9AYScpjGMYorFcMTZGPGIiw 5Qvqg0PFmmsmugcEEyPNovxdi9InAdMaZQ8SAOP+HDVUTUCxQiYwb8WrVKbpxo7m tyQMjG4F =CTSA -END PGP SIGNATURE-
Bug#1040580: oz: implicitly depends on python3-py
Source: oz
Version: 0.17.0-5.1
Severity: serious
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear maintainer,
your package implicitly depends on python3-py for its autopkgtest, which used
to be provided by python3-pytest. However, pytest has dropped that dependency,
breaking your autopkgtest.
Note that you can replace py.test.foo with pytest.foo and avoid the
dependency on python3-py altogether.
Cheers
Timo
- ---
Relevant excerpt from
https://ci.debian.net/data/autopkgtest/testing/amd64/o/oz/35449828/log.gz
50s ERRORS
50s ERROR collecting tests/factory/test_factory.py
50s tests/factory/test_factory.py:34: in
50s import py.test
50s E ModuleNotFoundError: No module named 'py.test'; 'py' is not a package
50s
50s During handling of the above exception, another exception occurred:
50s /usr/lib/python3/dist-packages/_pytest/runner.py:341: in from_call
50s result: Optional[TResult] = func()
50s /usr/lib/python3/dist-packages/_pytest/runner.py:372: in
50s call = CallInfo.from_call(lambda: list(collector.collect()), "collect")
50s /usr/lib/python3/dist-packages/_pytest/python.py:531: in collect
50s self._inject_setup_module_fixture()
50s /usr/lib/python3/dist-packages/_pytest/python.py:545: in
_inject_setup_module_fixture
50s self.obj, ("setUpModule", "setup_module")
50s /usr/lib/python3/dist-packages/_pytest/python.py:310: in obj
50s self._obj = obj = self._getobj()
50s /usr/lib/python3/dist-packages/_pytest/python.py:528: in _getobj
50s return self._importtestmodule()
50s /usr/lib/python3/dist-packages/_pytest/python.py:617: in _importtestmodule
50s mod = import_path(self.path, mode=importmode,
root=self.config.rootpath)
50s /usr/lib/python3/dist-packages/_pytest/pathlib.py:565: in import_path
50s importlib.import_module(module_name)
50s /usr/lib/python3.11/importlib/__init__.py:126: in import_module
50s return _bootstrap._gcd_import(name[level:], package, level)
50s :1204: in _gcd_import
50s ???
50s :1176: in _find_and_load
50s ???
50s :1147: in _find_and_load_unlocked
50s ???
50s :690: in _load_unlocked
50s ???
50s /usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:178: in
exec_module
50s exec(co, module.__dict__)
50s tests/factory/test_factory.py:37: in
50s sys.exit(1)
50s E SystemExit: 1
50s --- Captured stdout
50s Unable to import py.test. Is py.test installed?
50s __ ERROR collecting tests/guest/test_guest.py
__
50s tests/guest/test_guest.py:34: in
50s import py.test
50s E ModuleNotFoundError: No module named 'py.test'; 'py' is not a package
50s
50s During handling of the above exception, another exception occurred:
50s /usr/lib/python3/dist-packages/_pytest/runner.py:341: in from_call
50s result: Optional[TResult] = func()
50s /usr/lib/python3/dist-packages/_pytest/runner.py:372: in
50s call = CallInfo.from_call(lambda: list(collector.collect()), "collect")
50s /usr/lib/python3/dist-packages/_pytest/python.py:531: in collect
50s self._inject_setup_module_fixture()
50s /usr/lib/python3/dist-packages/_pytest/python.py:545: in
_inject_setup_module_fixture
50s self.obj, ("setUpModule", "setup_module")
50s /usr/lib/python3/dist-packages/_pytest/python.py:310: in obj
50s self._obj = obj = self._getobj()
50s /usr/lib/python3/dist-packages/_pytest/python.py:528: in _getobj
50s return self._importtestmodule()
50s /usr/lib/python3/dist-packages/_pytest/python.py:617: in _importtestmodule
50s mod = import_path(self.path, mode=importmode,
root=self.config.rootpath)
50s /usr/lib/python3/dist-packages/_pytest/pathlib.py:565: in import_path
50s importlib.import_module(module_name)
50s /usr/lib/python3.11/importlib/__init__.py:126: in import_module
50s return _bootstrap._gcd_import(name[level:], package, level)
50s :1204: in _gcd_import
50s ???
50s :1176: in _find_and_load
50s ???
50s :1147: in _find_and_load_unlocked
50s ???
50s :690: in _load_unlocked
50s ???
50s /usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:178: in
exec_module
50s exec(co, module.__dict__)
50s tests/guest/test_guest.py:37: in
50s sys.exit(1)
50s E SystemExit: 1
50s --- Captured stdout
50s Unable to import py.test. Is py.test installed?
50s _ ERROR collecting tests/ozutil/test_ozutil.py
_
50s tests/ozutil/test_ozutil.py:7: in
50s import py.test
50s E ModuleNotFoundError: No module named 'py.test'; 'py' is not a package
50s
50s During handling of the above exception, another exception occurred:
50s /usr/lib/python3/dist-packages/_pytest/runner.py:341: in from_call
50s result:
Bug#1040579: python-gflanguages: implicitly depends on python3-pkg-resources
Source: python-gflanguages Version: 0.4.0-2 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package implicitly depends on python3-pkg-resources for its autopkgtest, which used to be provided through python3-pytest. However, pytest has dropped that dependency, breaking your autopkgtest and possibly your package. Note that pkg_resources is deprecated in favor of importlib.resources [1], which is part of the Python Standard Library and has better performance. Cheers Timo [1] https://docs.python.org/3/library/importlib.resources.html - --- Relevant excerpt from https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-gflanguages/35451512/log.gz 21s ERRORS 21s ERROR collecting tests/test_gflanguages_api.py 21s ImportError while importing test module '/tmp/autopkgtest-lxc.ll4xso7j/downtmp/autopkgtest_tmp/tests/test_gflanguages_api.py'. 21s Hint: make sure your test modules/packages have valid Python names. 21s Traceback: 21s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 21s return _bootstrap._gcd_import(name[level:], package, level) 21s tests/test_gflanguages_api.py:17: in 21s from pkg_resources import resource_filename 21s E ModuleNotFoundError: No module named 'pkg_resources' -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSoUVQACgkQ+C8H+466 LVnOPgv+POeeVi0QGha7bcbH+IHbS2MJURn3XWaTpodBHfnaHg1lpNr93o+WejYc 288aNe+f2pWXGvTlkBat0rock+hfeJO+oYo2akhRJ+OGams9QV+Jh/vXCFv7VkQk 2hZ9Py4xjHTpQggU3u36I6Au5j+JPbG152vKc3vbdCtD6CBjeSPD4a3GMciWVsmP q+EGRxtq8WtNGtHvDDwVdgezeElCzrylDZoJjJOZgIweBYfLVFlTP1d96oMOYfHm 5o6t/C41xJsJjThOD1H3aFIjFdOcooCvxPg0Q5ye3sLOm4udROzF7CnBFqxI44GO D0rwq3yNCFk6wZdHDBJEKglf6WlxoPGSdZ1z9asaXCjw9CBda8NDLFWZ1XCxcPRq 5LX4CrdUIgHtF6r90aW/79VxJYSs9ADKDBdleoOk3Y3xb4VIrkah3nBSuyq1W1rb AJb3/UL7x9HMbE2f5TfQj9xrkHDBT665qOCRdvUqskF2DutAW4SIWqykyVqcxyzy nympYQkE =Qa60 -END PGP SIGNATURE-
Bug#1040578: python-molotov: implicitly depends on python3-pkg-resources
Source: python-molotov Version: 2.1-5 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package implicitly depends on python3-pkg-resources for its autopkgtest, which used to be provided through python3-pytest. However, pytest has dropped that dependency, breaking your autopkgtest and possibly your package. Note that pkg_resources is deprecated in favor of importlib.resources [1], which is part of the Python Standard Library and has better performance. Cheers Timo [1] https://docs.python.org/3/library/importlib.resources.html - --- Relevant excerpt from https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-molotov/35451514/log.gz 29s ERRORS 29s _ ERROR collecting molotov/tests/test_slave.py _ 29s ImportError while importing test module '/tmp/autopkgtest-lxc.jd5622c7/downtmp/build.Iu1/src/molotov/tests/test_slave.py'. 29s Hint: make sure your test modules/packages have valid Python names. 29s Traceback: 29s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 29s return _bootstrap._gcd_import(name[level:], package, level) 29s molotov/tests/test_slave.py:9: in 29s from molotov.slave import main 29s molotov/slave.py:9: in 29s import pkg_resources 29s E ModuleNotFoundError: No module named 'pkg_resources' -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSoUPYACgkQ+C8H+466 LVnfGgwAt3Qsym11wXf2B7CPM1F3o83JXU+eRenaZAWSYJfRf8686l4Sby4ybgIW Ig0B4tY8LLqfVl86gKJ/H6URvj/8TodfyWzZA24duzG7MnAN778qPXCxFrI7N5DQ VTn9lmOnXJAegQpY7b6HyXLdsUu9571AWd0MiJPWIOIY5NHeRrBcssce9bJwOJmV hTLQxj0WTE7KvDiE9D+ZTox7uu17XKlYnawxLfp/mU2yKty83MVz88VTd7cezhNB mJEPvRubHRDUyPem48asEUZcpsgqXfcZ1nclijPAhpS2joY6M0K9JTAdLfaAl699 uP/ddgJFk9h13fbIOG4zuP5ljTdiakp8jI6tIsa4xzVv9k56yHs0efaRS4pCNm6q ldfdjXzEsHSnjdDT5xnzKT/VxpBp3dyTg602+2Pt5ZXxDJ00TI/Tvx+3boYZCtnJ AO17sJT1eufrYsyKnfYuw+3v1WvvEvJdY4AiMrbVZIclttL9v615BtMwOflim/yn SIeVMd8h =riny -END PGP SIGNATURE-
Bug#1040577: toot: color lost when piping
Package: toot Version: 0.27.0-1 Severity: minor Tags: upstream X-Debbugs-Cc: debbug.t...@sideload.33mail.com CLI output is normally in color but when piping the output to another tool, the color is lost. It’s useful to be able to pipe to “less -R”, which is a pager that preserves ANSI control codes and thus color. Apparently toot is detecting the pipeline as non-interactive and automatically stripping out the color codes even when the “--no-color” option is not supplied. It may be deliberate & it’s probably a sensible default behavior. But if that’s going to be the default then we need a way to force color. The convention is typically a “--color=always” option. -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'testing'), (990, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages toot depends on: ii python3 3.9.2-3 ii python3-bs4 4.9.3-1 ii python3-requests 2.25.1+dfsg-2 ii python3-urwid 2.1.2-1 ii python3-wcwidth 0.1.9+dfsg1-2 toot recommends no packages. toot suggests no packages. -- no debconf information
Bug#1040576: python-mongomock: implicitly depends on python3-pkg-resources
Source: python-mongomock Version: 4.1.2-1 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package implicitly depends on python3-pkg-resources for its autopkgtest, which used to be provided through python3-pytest. However, pytest has dropped that dependency, breaking your autopkgtest and possibly your package. Note that pkg_resources is deprecated in favor of importlib.resources [1], which is part of the Python Standard Library and has better performance. Cheers Timo [1] https://docs.python.org/3/library/importlib.resources.html - --- Relevant excerpt from https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-mongomock/35451515/log.gz 24s ERRORS 24s ___ ERROR collecting tests/test__bulk_operations.py 24s ImportError while importing test module '/tmp/autopkgtest-lxc.2jeup6d8/downtmp/build.egq/src/tests/test__bulk_operations.py'. 24s Hint: make sure your test modules/packages have valid Python names. 24s Traceback: 24s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 24s return _bootstrap._gcd_import(name[level:], package, level) 24s tests/test__bulk_operations.py:3: in 24s import mongomock 24s mongomock/__init__.py:79: in 24s from mongomock.__version__ import __version__ 24s mongomock/__version__.py:1: in 24s import pkg_resources 24s E ModuleNotFoundError: No module named 'pkg_resources' 24s __ ERROR collecting tests/test__client_api.py __ 24s ImportError while importing test module '/tmp/autopkgtest-lxc.2jeup6d8/downtmp/build.egq/src/tests/test__client_api.py'. 24s Hint: make sure your test modules/packages have valid Python names. 24s Traceback: 24s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 24s return _bootstrap._gcd_import(name[level:], package, level) 24s tests/test__client_api.py:16: in 24s import mongomock 24s mongomock/__init__.py:79: in 24s from mongomock.__version__ import __version__ 24s mongomock/__version__.py:1: in 24s import pkg_resources 24s E ModuleNotFoundError: No module named 'pkg_resources' 24s ERROR collecting tests/test__collection_api.py 24s ImportError while importing test module '/tmp/autopkgtest-lxc.2jeup6d8/downtmp/build.egq/src/tests/test__collection_api.py'. 24s Hint: make sure your test modules/packages have valid Python names. 24s Traceback: 24s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 24s return _bootstrap._gcd_import(name[level:], package, level) 24s tests/test__collection_api.py:15: in 24s import mongomock 24s mongomock/__init__.py:79: in 24s from mongomock.__version__ import __version__ 24s mongomock/__version__.py:1: in 24s import pkg_resources 24s E ModuleNotFoundError: No module named 'pkg_resources' 24s _ ERROR collecting tests/test__database_api.py _ 24s ImportError while importing test module '/tmp/autopkgtest-lxc.2jeup6d8/downtmp/build.egq/src/tests/test__database_api.py'. 24s Hint: make sure your test modules/packages have valid Python names. 24s Traceback: 24s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 24s return _bootstrap._gcd_import(name[level:], package, level) 24s tests/test__database_api.py:7: in 24s import mongomock 24s mongomock/__init__.py:79: in 24s from mongomock.__version__ import __version__ 24s mongomock/__version__.py:1: in 24s import pkg_resources 24s E ModuleNotFoundError: No module named 'pkg_resources' 24s ERROR collecting tests/test__gridfs.py 24s ImportError while importing test module '/tmp/autopkgtest-lxc.2jeup6d8/downtmp/build.egq/src/tests/test__gridfs.py'. 24s Hint: make sure your test modules/packages have valid Python names. 24s Traceback: 24s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 24s return _bootstrap._gcd_import(name[level:], package, level) 24s tests/test__gridfs.py:6: in 24s import mongomock 24s mongomock/__init__.py:79: in 24s from mongomock.__version__ import __version__ 24s mongomock/__version__.py:1: in 24s import pkg_resources 24s E ModuleNotFoundError: No module named 'pkg_resources' 24s __ ERROR collecting tests/test__mongomock.py ___ 24s ImportError while importing test module '/tmp/autopkgtest-lxc.2jeup6d8/downtmp/build.egq/src/tests/test__mongomock.py'. 24s Hint: make sure your test modules/packages have valid Python names. 24s Traceback: 24s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 24s return _bootstrap._gcd_import(name[level:], package, level) 24s tests/test__mongomock.py:13: in 24s import mongomock 24s mongomock/__init__.py:79: in 24s from mongomock.__version__
Bug#1040575: shaarli: missing dependency on fonts-fork-awesome
Package: shaarli Version: 0.12.1+dfsg-8 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink: 0m47.8s ERROR: FAIL: Broken symlinks: /usr/share/shaarli/tpl/default/fonts/forkawesome-webfont.woff -> ../../../../fonts-fork-awesome/fonts/forkawesome-webfont.woff (shaarli) /usr/share/shaarli/tpl/default/fonts/forkawesome-webfont.woff2 -> ../../../../fonts-fork-awesome/fonts/forkawesome-webfont.woff2 (shaarli) Is shaarli missing a dependency on fonts-fork-awesome ? cheers, Andreas
Bug#1040574: python-qrcode: implicitly depends on python3-pkg-resources
Source: python-qrcode
Version: 7.4.2-2
Severity: serious
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear maintainer,
your package implicitly depends on python3-pkg-resources for its autopkgtest,
which used to be provided through python3-pytest. However, pytest has dropped
that dependency, breaking your autopkgtest and possibly your package.
Note that pkg_resources is deprecated in favor of importlib.resources [1],
which is part of the Python Standard Library and has better performance.
Cheers
Timo
[1] https://docs.python.org/3/library/importlib.resources.html
- ---
Relevant excerpt from
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-qrcode/35451521/log.gz
26s === FAILURES
===
26s _ ScriptTest.test_bad_factory
__
26s
26s self =
26s mock_stderr =
26s
26s @mock.patch("sys.stderr")
26s def test_bad_factory(self, mock_stderr):
26s > self.assertRaises(SystemExit, main, "testtext --factory
fish".split())
26s
26s tests/test_script.py:68:
26s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _
26s
26s def main(args=None):
26s if args is None:
26s args = sys.argv[1:]
26s > from pkg_resources import get_distribution
26s E ModuleNotFoundError: No module named 'pkg_resources'
26s
26s /usr/lib/python3/dist-packages/qrcode/console_scripts.py:43:
ModuleNotFoundError
26s ___ ScriptTest.test_factory
26s
26s self =
26s mock_stdout =
26s
26s @mock.patch("sys.stdout")
26s def test_factory(self, mock_stdout):
26s > main("testtext --factory svg".split())
26s
26s tests/test_script.py:64:
26s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _
26s
26s args = ['testtext', '--factory', 'svg']
26s
26s def main(args=None):
26s if args is None:
26s args = sys.argv[1:]
26s > from pkg_resources import get_distribution
26s E ModuleNotFoundError: No module named 'pkg_resources'
26s
26s /usr/lib/python3/dist-packages/qrcode/console_scripts.py:43:
ModuleNotFoundError
26s ScriptTest.test_factory_drawer
26s
26s self =
26s mock_stderr = <_io.StringIO object at 0x7faec4596b90>
26s
26s @mock.patch("sys.stderr", new_callable=io.StringIO)
26s def test_factory_drawer(self, mock_stderr):
26s > main("testtext --factory svg --factory-drawer circle".split())
26s
26s tests/test_script.py:98:
26s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _
26s
26s args = ['testtext', '--factory', 'svg', '--factory-drawer', 'circle']
26s
26s def main(args=None):
26s if args is None:
26s args = sys.argv[1:]
26s > from pkg_resources import get_distribution
26s E ModuleNotFoundError: No module named 'pkg_resources'
26s
26s /usr/lib/python3/dist-packages/qrcode/console_scripts.py:43:
ModuleNotFoundError
26s __ ScriptTest.test_factory_drawer_bad
__
26s
26s self =
26s mock_stderr = <_io.StringIO object at 0x7faec4b97e20>
26s
26s @mock.patch("sys.stderr", new_callable=io.StringIO)
26s def test_factory_drawer_bad(self, mock_stderr):
26s with self.assertRaises(SystemExit):
26s > main("testtext --factory svg --factory-drawer sobad".split())
26s
26s tests/test_script.py:93:
26s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _
26s
26s def main(args=None):
26s if args is None:
26s args = sys.argv[1:]
26s > from pkg_resources import get_distribution
26s E ModuleNotFoundError: No module named 'pkg_resources'
26s
26s /usr/lib/python3/dist-packages/qrcode/console_scripts.py:43:
ModuleNotFoundError
26s _ ScriptTest.test_factory_drawer_none
__
26s
26s self =
26s mock_stderr = <_io.StringIO object at 0x7faec4595e10>
26s
26s @mock.patch("sys.stderr", new_callable=io.StringIO)
26s @unittest.skipIf(not Image, "Requires PIL")
26s def test_factory_drawer_none(self, mock_stderr):
26s with self.assertRaises(SystemExit):
26s > main("testtext --factory pil --factory-drawer nope".split())
26s
26s tests/test_script.py:85:
26s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _
26s
26s def main(args=None):
26s if args is None:
26s args = sys.argv[1:]
26s > from pkg_resources import get_distribution
26s E ModuleNotFoundError: No module named 'pkg_resources'
26s
26s /usr/lib/python3/dist-packages/qrcode/console_scripts.py:43:
ModuleNotFoundError
26s ScriptTest.test_isatty
Bug#1040573: python-screed: implicitly depends on python3-pkg-resources
Source: python-screed Version: 1.0.5-4 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package implicitly depends on python3-pkg-resources for its autopkgtest, which used to be provided through python3-pytest. However, pytest has dropped that dependency, breaking your autopkgtest and possibly your package. Note that pkg_resources is deprecated in favor of importlib.resources [1], which is part of the Python Standard Library and has better performance. Cheers Timo [1] https://docs.python.org/3/library/importlib.resources.html - --- Relevant excerpt from https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-screed/35451522/log.gz 24s ERRORS 24s __ ERROR collecting screed/tests/test_attriberror.py ___ 24s ImportError while importing test module '/tmp/autopkgtest-lxc.ocsondrc/downtmp/autopkgtest_tmp/screed/tests/test_attriberror.py'. 24s Hint: make sure your test modules/packages have valid Python names. 24s Traceback: 24s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 24s return _bootstrap._gcd_import(name[level:], package, level) 24s screed/__init__.py:39: in 24s from pkg_resources import get_distribution, DistributionNotFound 24s E ModuleNotFoundError: No module named 'pkg_resources' 24s ERROR collecting screed/tests/test_convert.py _ 24s ImportError while importing test module '/tmp/autopkgtest-lxc.ocsondrc/downtmp/autopkgtest_tmp/screed/tests/test_convert.py'. 24s Hint: make sure your test modules/packages have valid Python names. 24s Traceback: 24s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 24s return _bootstrap._gcd_import(name[level:], package, level) 24s screed/__init__.py:39: in 24s from pkg_resources import get_distribution, DistributionNotFound 24s E ModuleNotFoundError: No module named 'pkg_resources' 24s ___ ERROR collecting screed/tests/test_db.py ___ 24s ImportError while importing test module '/tmp/autopkgtest-lxc.ocsondrc/downtmp/autopkgtest_tmp/screed/tests/test_db.py'. 24s Hint: make sure your test modules/packages have valid Python names. 24s Traceback: 24s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 24s return _bootstrap._gcd_import(name[level:], package, level) 24s screed/__init__.py:39: in 24s from pkg_resources import get_distribution, DistributionNotFound 24s E ModuleNotFoundError: No module named 'pkg_resources' 24s ___ ERROR collecting screed/tests/test_dictionary.py ___ 24s ImportError while importing test module '/tmp/autopkgtest-lxc.ocsondrc/downtmp/autopkgtest_tmp/screed/tests/test_dictionary.py'. 24s Hint: make sure your test modules/packages have valid Python names. 24s Traceback: 24s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 24s return _bootstrap._gcd_import(name[level:], package, level) 24s screed/__init__.py:39: in 24s from pkg_resources import get_distribution, DistributionNotFound 24s E ModuleNotFoundError: No module named 'pkg_resources' 24s __ ERROR collecting screed/tests/test_dna.py ___ 24s ImportError while importing test module '/tmp/autopkgtest-lxc.ocsondrc/downtmp/autopkgtest_tmp/screed/tests/test_dna.py'. 24s Hint: make sure your test modules/packages have valid Python names. 24s Traceback: 24s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 24s return _bootstrap._gcd_import(name[level:], package, level) 24s screed/__init__.py:39: in 24s from pkg_resources import get_distribution, DistributionNotFound 24s E ModuleNotFoundError: No module named 'pkg_resources' 24s _ ERROR collecting screed/tests/test_fasta.py __ 24s ImportError while importing test module '/tmp/autopkgtest-lxc.ocsondrc/downtmp/autopkgtest_tmp/screed/tests/test_fasta.py'. 24s Hint: make sure your test modules/packages have valid Python names. 24s Traceback: 24s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 24s return _bootstrap._gcd_import(name[level:], package, level) 24s screed/__init__.py:39: in 24s from pkg_resources import get_distribution, DistributionNotFound 24s E ModuleNotFoundError: No module named 'pkg_resources' 24s _ ERROR collecting screed/tests/test_fasta_recover.py __ 24s ImportError while importing test module '/tmp/autopkgtest-lxc.ocsondrc/downtmp/autopkgtest_tmp/screed/tests/test_fasta_recover.py'. 24s Hint: make sure your test modules/packages have valid Python names. 24s Traceback: 24s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 24s return _bootstrap._gcd_import(name[level:], package, level) 24s screed/__init__.py:39: in 24s from pkg_resources import get_distribution,
Bug#1036712: Replaces without Breaks or Conflicts harmful?
Helmut Grohne dixit: >> > rng-tools-debian >> >> Also false positive: >> >> Replaces: intel-rng-tools, rng-tools >> Breaks: rng-tools (>= 5migratf), rng-tools (<< 5migrate) >> Conflicts: intel-rng-tools > >This is *not* a false positive, but a real issue. It replaces any >rng-tools, but breaks only a subset. This would have to be fixed to No, because the not-broken subset Depends on rng-tools-debian. (It’s a transitional package.) So, while it cannot be seen by “just” inspecting rng-tools-debian, all possible combinations are covered. (Also, the transition is done and rng-tools is gone.) bye, //mirabilos -- /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against ╳ HTML eMail! Also, ╱ ╲ header encryption!
Bug#1040571: segno: implicitly depends on python3-pkg-resources
Source: segno Version: 1.5.2-2 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package implicitly depends on python3-pkg-resources for its autopkgtest, which used to be provided through python3-pytest. However, pytest has dropped that dependency, breaking your autopkgtest and possibly your package. Note that pkg_resources is deprecated in favor of importlib.resources [1], which is part of the Python Standard Library and has better performance. Cheers Timo [1] https://docs.python.org/3/library/importlib.resources.html - --- Relevant excerpt from https://ci.debian.net/data/autopkgtest/testing/amd64/s/segno/35454502/log.gz 17s ERRORS 17s ___ ERROR collecting test_plugin.py 17s ImportError while importing test module '/tmp/autopkgtest-lxc.83hwvtoe/downtmp/autopkgtest_tmp/tests/test_plugin.py'. 17s Hint: make sure your test modules/packages have valid Python names. 17s Traceback: 17s /usr/lib/python3/dist-packages/_pytest/python.py:617: in _importtestmodule 17s mod = import_path(self.path, mode=importmode, root=self.config.rootpath) 17s /usr/lib/python3/dist-packages/_pytest/pathlib.py:565: in import_path 17s importlib.import_module(module_name) 17s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 17s return _bootstrap._gcd_import(name[level:], package, level) 17s :1204: in _gcd_import 17s ??? 17s :1176: in _find_and_load 17s ??? 17s :1147: in _find_and_load_unlocked 17s ??? 17s :690: in _load_unlocked 17s ??? 17s /usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:178: in exec_module 17s exec(co, module.__dict__) 17s test_plugin.py:13: in 17s import pkg_resources 17s E ModuleNotFoundError: No module named 'pkg_resources' -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSoTmIACgkQ+C8H+466 LVlu4QwAmsq5VA66wZS6FW39j4G1914q62JgYiqAVU2fWkkK6NjMIRamOyzjn5fS tj6crNVc5gTWS86PM3uHk895caanjUsuv7lGQeoFcRC5EW5WpTff2v5cCLQM7xIN yaQasX3pEPlJkawD8DMjLXYmNoL5cpC+uJTObLgS5aKSNfFryKpKRqgeDKQTHIzF mvwTx8iMQEad6Jp3kDtaFL8Aa4Rvz/BnK8Q50cyr3ien4FnbmdEIRZKCPGdCQlRq zF2BgWlXCzYZyBUzmeC9tP8Ie/6ekDQ0o90HNI+BAHOA21ZUXj9ZDhGFksiNb0Ie 4RtpJjWNKftTP/l5kZcdDdQ/HjXpNnKSSv2Bc+M8cpZk0OU2zT8Q92oy54Ot/jo6 MZFP2ZUnVEi6ryxNT4ZxEiQoCm6l+CFrF23R6AJSdGM4ttpcZfGMDl1JRiaBzolH 5fFOneMMqJ6rydyXKOvY2sKxpaN6xWS+TQpFMxRwxc3fu11pBiuPqM5HAbWUQxpT y6fNt06t =SAzV -END PGP SIGNATURE-
Bug#1040563: bookworm-pu: package node-tough-cookie/4.0.0-2+deb12u1
Control: tag -1 moreinfo On Fri, Jul 07, 2023 at 09:01:40PM +0400, Yadd wrote: > [ Reason ] > node-tough-cookie is vulnerable to prototype pollution How has this been fixed in unstable? You'll need an upload there anyway for version ordering. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1040572: wmnut: broken symlink: /usr/share/doc/wmnut/README -> README.asciidoc
Package: wmnut Version: 0.67-2 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink: 0m20.4s ERROR: FAIL: Broken symlinks: /usr/share/doc/wmnut/README -> README.asciidoc (wmnut) cheers, Andreas
Bug#1040570: obs-server: broken symlink: /usr/share/doc/obs-server/README.SETUP -> ../README.md
Package: obs-server Version: 2.9.4-9 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink: 1m9.9s ERROR: FAIL: Broken symlinks: /usr/share/doc/obs-server/README.SETUP -> ../README.md (obs-server) cheers, Andreas
Bug#1040142: aide 0.18.3-1+deb12u2 flagged for acceptance
package release.debian.org tags 1040142 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: aide Version: 0.18.3-1+deb12u2 Explanation: fix child directory processing on equal match
Bug#1040569: opendrop: broken symlink: /usr/share/icons/hicolor/256x256/apps/opendrop.png -> ../../../../../lib/python3/dist-packages/opendrop/res/images/icon_256x256.png
Package: opendrop Version: 3.3.1-5 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink: 2m5.1s ERROR: FAIL: Broken symlinks: /usr/share/icons/hicolor/256x256/apps/opendrop.png -> ../../../../../lib/python3/dist-packages/opendrop/res/images/icon_256x256.png (opendrop) cheers, Andreas
Bug#1040568: weresync: implicitly depends on python3-py
Source: weresync Version: 1.0.9-2 Severity: serious -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package implicitly depends on python3-py for its autopkgtest, which used to be provided by python3-pytest. However, pytest has dropped that dependency, breaking your autopkgtest. Note that you can replace py.test.foo with pytest.foo to avoid a dependency on python3-py altogether. Cheers Timo Relevant excerpt from https://ci.debian.net/data/autopkgtest/testing/amd64/w/weresync/35454503/log.gz 24s autopkgtest [16:48:55]: test main: [--- 24s Traceback (most recent call last): 24s File "/tmp/autopkgtest-lxc.ypwky37d/downtmp/build.9Em/src/debian/tests/main", line 4, in 24s py.test.cmdline.main() 24s ^^^ 24s AttributeError: module 'py' has no attribute 'test' 24s autopkgtest [16:48:55]: test main: ---] 25s autopkgtest [16:48:56]: test main: - - - - - - - - - - results - - - - - - - - - - 25s main FAIL non-zero exit status 1 25s autopkgtest [16:48:56]: test main: - - - - - - - - - - stderr - - - - - - - - - - 25s Traceback (most recent call last): 25s File "/tmp/autopkgtest-lxc.ypwky37d/downtmp/build.9Em/src/debian/tests/main", line 4, in 25s py.test.cmdline.main() 25s ^^^ 25s AttributeError: module 'py' has no attribute 'test' 25s autopkgtest [16:48:56]: summary 25s main FAIL non-zero exit status 1 -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSoTK0ACgkQ+C8H+466 LVl5TwwAj+0qd9bKB3+/kZsBSL0nfVxCosZRPQfC/FiTTZmeA4cVs1Kc2lmp1k3T 3K6JXCAO9gNLlAfeewTi8gK1h6yPQgUV6RFgFVEj3k9jZazvg5lTLGMhN7m4iE6w pctwAq7I8Ijf3Xe3YXmWEpzL84RkEjtskRm+FEqc8wmSUYeeMjPTtJjM4M1QpLfa xxdOzfFiww/Y+xmbrjm9ENQbW94jeoqQ3/paLasrBGZhf0+MLNHsVNFg+LpcXdzv zg5U+zOLWyGio//l6LYF8rPE4s607bHfPGGHQRA8gbYhPVa6En49B+/U/Iv1patw mW0iM8J66IBLkVhRELBQ0Crqm9hoPxSzzEB+2Hm4FU1neXsTfBvG1R0+kDrPXSev Qnvzf1bGH26Gcy8w5Y5Kz/m5D9U5KDrjOrWxpY63gA4FcAhtoDvmjG4K3n/YBdrA en3eCgUpaKCVMbztxkk+W9wEIIazEiWwbA5uTnx4wVP5Q9lUIwXmt3wKGl1NEBPW wAChb6EQ =tWmj -END PGP SIGNATURE-
Bug#1040567: odoo-16: missing Depends: fonts-glyphicons-halflings
Package: odoo-16 Version: 16.0.0+dfsg.1-1.1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink. >From the attached log (scroll to the bottom...): 2m17.8s ERROR: FAIL: Broken symlinks: /usr/lib/python3/dist-packages/odoo/addons/web/static/lib/bootstrap/fonts/glyphicons-halflings-regular.eot -> ../../../../../../../../../../share/fonts-glyphicons/glyphicons-halflings-regular.eot (odoo-16) /usr/lib/python3/dist-packages/odoo/addons/web/static/lib/bootstrap/fonts/glyphicons-halflings-regular.ttf -> ../../../../../../../../../../share/fonts-glyphicons/glyphicons-halflings-regular.ttf (odoo-16) /usr/lib/python3/dist-packages/odoo/addons/web/static/lib/bootstrap/fonts/glyphicons-halflings-regular.woff -> ../../../../../../../../../../share/fonts-glyphicons/glyphicons-halflings-regular.woff (odoo-16) /usr/lib/python3/dist-packages/odoo/addons/web/static/lib/bootstrap/fonts/glyphicons-halflings-regular.woff2 -> ../../../../../../../../../../share/fonts-glyphicons/glyphicons-halflings-regular.woff2 (odoo-16) cheers, Andreas
Bug#1040452: Log and rescue tips
m0 libtss2-tcti-swtpm0 libtss2-tctildr0 libvirt-clients libvirt-daemon libvirt-daemon-config-network libvirt-daemon-config-nwfilter libvirt-daemon-driver-lxc libvirt-daemon-driver-qemu libvirt-daemon-driver-vbox libvirt-daemon-driver-xen libvirt-daemon-system libvirt-daemon-system-systemd libvirt-l10n libvirt-login-shell libvirt0 libwbclient0 linux-headers-amd64 linux-image-amd64 locales lsb-release mediainfo mesa-va-drivers mesa-va-drivers:i386 mesa-vdpau-drivers mesa-vdpau-drivers:i386 mesa-vulkan-drivers mesa-vulkan-drivers:i386 nmap nmap-common pipewire pipewire-bin python3 python3-all python3-all-dev python3-autopep8 python3-cairo python3-dev python3-exceptiongroup python3-ldb python3-lxml python3-minimal python3-pathspec python3-pil python3-pil.imagetk python3-pkg-resources python3-prompt-toolkit python3-protobuf python3-pytest python3-samba python3-setuptools qml-module-qtwebengine qt5-gtk-platformtheme qt5-qmake qt5-qmake-bin qtbase5-dev qtbase5-dev-tools qtwebengine5-dev-tools rkdeveloptool samba-common samba-common-bin samba-dsdb-modules samba-libs smbclient strawberry tzdata xfce4-helpers xfce4-settings xxd yt-dlp 191 actualizados, 9 nuevos se instalar??n, 2 para eliminar y 5 no actualizados. Se necesita descargar 212 MB/372 MB de archivos. Se utilizar??n 341 MB de espacio de disco adicional despu??s de esta operaci??n. N: Omitiendo el fichero ??graphics-drivers-ubuntu-ppa-focal.list-no?? del directorio ??/etc/apt/sources.list.d/??, ya que tiene una extensi??n de nombre de fichero no v??lida N: Omitiendo el fichero ??yannubuntu-ubuntu-boot-repair-eoan.list-no?? del directorio ??/etc/apt/sources.list.d/??, ya que tiene una extensi??n de nombre de fichero no v??lida ??Desea continuar? [S/n] Des:1 http://deb.debian.org/debian sid/main amd64 libc6-i386 amd64 2.37-4 [2.455 kB] Des:2 http://deb.debian.org/debian sid/main amd64 libc-dev-bin amd64 2.37-4 [45,3 kB] Des:3 http://deb.debian.org/debian sid/main amd64 libc6-dev amd64 2.37-4 [1.901 kB] Des:4 http://deb.debian.org/debian sid/main amd64 libc6-dev-i386 amd64 2.37-4 [1.348 kB] Des:5 http://deb.debian.org/debian sid/main amd64 libc6-dev-x32 amd64 2.37-4 [1.519 kB] Des:6 http://deb.debian.org/debian sid/main amd64 libc6-x32 amd64 2.37-4 [2.587 kB] Des:7 http://deb.debian.org/debian sid/main amd64 libc6-dbg amd64 2.37-4 [7.427 kB] Des:8 http://deb.debian.org/debian sid/main i386 libc6 i386 2.37-4 [2.622 kB] Des:9 http://deb.debian.org/debian sid/main amd64 libc6 amd64 2.37-4 [2.753 kB] Des:10 http://deb.debian.org/debian sid/main amd64 libc-bin amd64 2.37-4 [600 kB] Des:11 http://deb.debian.org/debian sid/main amd64 libc-l10n all 2.37-4 [707 kB] Des:12 http://deb.debian.org/debian sid/main amd64 locales all 2.37-4 [3.909 kB] 54% [12 locales 1.122 kB/3.909 kB 29%] 129 kB/s 24min 8s^Des:13 http://deb.debian.org/debian sid/main amd64 ca-certificates-java all 20230707 [11,7 kB] Des:14 http://deb.debian.org/debian sid/main amd64 libgcab-1.0-0 amd64 1.6-1 [30,0 kB] Des:15 http://deb.debian.org/debian sid/main amd64 libpipewire-0.3-modules amd64 0.3.73-1 [703 kB] Des:16 http://deb.debian.org/debian sid/main amd64 libpipewire-0.3-0 amd64 0.3.73-1 [258 kB] Des:17 http://deb.debian.org/debian sid/main amd64 libspa-0.2-modules amd64 0.3.73-1 [586 kB] Des:18 http://deb.debian.org/debian sid/main amd64 pipewire amd64 0.3.73-1 [91,1 kB] Des:19 http://deb.debian.org/debian sid/main amd64 pipewire-bin amd64 0.3.73-1 [325 kB] Des:20 http://d
Bug#1040566: logol: broken symlink /usr/share/logol/lib/biojava.jar -> ../../java/biojava.jar
Package: logol Version: 1.7.9+dfsg-6 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink: 0m42.9s ERROR: FAIL: Broken symlinks: /usr/share/logol/lib/biojava.jar -> ../../java/biojava.jar (logol) libbiojava-java (which is not in the dependencies) does no longer provide a jar file with this name. The missing .jar probably causes something to not work. If that is not the case, please lower the severity. cheers, Andreas
Bug#1040565: libgtk-3-doc: broken symlinks: /usr/share/doc/libgtk-3-{dev,doc}/pango -> ../libpango1.0-doc/pango
Package: libgtk-3-doc Version: 3.24.37-2 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink. >From the attached log (scroll to the bottom...): 0m14.6s ERROR: FAIL: Broken symlinks: /usr/share/doc/libgtk-3-dev/pango -> ../libpango1.0-doc/pango (libgtk-3-doc) /usr/share/doc/libgtk-3-doc/pango -> ../libpango1.0-doc/pango (libgtk-3-doc) libpango1.0-doc does no longer have /usr/share/doc/libpango1.0-doc/pango cheers, Andreas
Bug#1040564: libortools-dev: missing Depends: libortools8 (= ${binary:Version})
Package: libortools-dev Version: 8.2+ds-6 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) broken symlinks: 0m39.7s ERROR: FAIL: Broken symlinks: /usr/lib/x86_64-linux-gnu/libflatzinc.so -> libflatzinc.so.8 (libortools-dev) /usr/lib/x86_64-linux-gnu/libortools.so -> libortools.so.8 (libortools-dev) cheers, Andreas
Bug#1040563: bookworm-pu: package node-tough-cookie/4.0.0-2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: node-tough-coo...@packages.debian.org
Control: affects -1 + src:node-tough-cookie
[ Reason ]
node-tough-cookie is vulnerable to prototype pollution
[ Impact ]
Littel security issue
[ Tests ]
Test updated, passed
[ Risks ]
No risk, patch is trivial and tested
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
Create new object instead of using default {}
Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 3652359..a8e8b7e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-tough-cookie (4.0.0-2+deb12u1) bookworm; urgency=medium
+
+ * Team upload
+ * Fix prototype pollution (Closes: CVE-2023-26136)
+
+ -- Yadd Fri, 07 Jul 2023 20:57:36 +0400
+
node-tough-cookie (4.0.0-2) unstable; urgency=medium
* Team upload
diff --git a/debian/patches/CVE-2023-26136.patch
b/debian/patches/CVE-2023-26136.patch
new file mode 100644
index 000..05e6372
--- /dev/null
+++ b/debian/patches/CVE-2023-26136.patch
@@ -0,0 +1,71 @@
+Description: Fix prototype pollution
+ CVE-2023-26136
+Author: Yadd
+Forwarded: not-needed
+Last-Update: 2023-07-07
+
+--- a/lib/memstore.js
b/lib/memstore.js
+@@ -39,7 +39,7 @@
+ constructor() {
+ super();
+ this.synchronous = true;
+-this.idx = {};
++this.idx = Object.create(null);
+ if (util.inspect.custom) {
+ this[util.inspect.custom] = this.inspect;
+ }
+@@ -109,10 +109,10 @@
+
+ putCookie(cookie, cb) {
+ if (!this.idx[cookie.domain]) {
+- this.idx[cookie.domain] = {};
++ this.idx[cookie.domain] = Object.create(null);
+ }
+ if (!this.idx[cookie.domain][cookie.path]) {
+- this.idx[cookie.domain][cookie.path] = {};
++ this.idx[cookie.domain][cookie.path] = Object.create(null);
+ }
+ this.idx[cookie.domain][cookie.path][cookie.key] = cookie;
+ cb(null);
+@@ -144,7 +144,7 @@
+ return cb(null);
+ }
+ removeAllCookies(cb) {
+-this.idx = {};
++this.idx = Object.create(null);
+ return cb(null);
+ }
+ getAllCookies(cb) {
+--- a/test/cookie_jar_test.js
b/test/cookie_jar_test.js
+@@ -669,4 +669,29 @@
+ }
+ }
+ })
++ .addBatch({
++"Issue #282 - Prototype pollution": {
++ "when setting a cookie with the domain __proto__": {
++topic: function() {
++ const jar = new tough.CookieJar(undefined, {
++rejectPublicSuffixes: false
++ });
++ // try to pollute the prototype
++ jar.setCookieSync(
++"Slonser=polluted; Domain=__proto__; Path=/notauth",
++"https://__proto__/admin;
++ );
++ jar.setCookieSync(
++"Auth=Lol; Domain=google.com; Path=/notauth",
++"https://google.com/;
++ );
++ this.callback();
++},
++"results in a cookie that is not affected by the attempted prototype
pollution": function() {
++ const pollutedObject = {};
++ assert(pollutedObject["/notauth"] === undefined);
++}
++ }
++}
++ })
+ .export(module);
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..67af372
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2023-26136.patch
Bug#1040562: libcalcium-doc: broken symlinks: /usr/share/doc/libcalcium-doc/html/_static/*.js -> ../../../../javascript/sphinxdoc/1.0/*.js
Package: libcalcium-doc
Version: 0.4.1-3
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts
Hi,
during a test with piuparts I noticed your package ships (or creates)
broken symlinks:
0m18.9s ERROR: FAIL: Broken symlinks:
/usr/share/doc/libcalcium-doc/html/_static/doctools.js ->
../../../../javascript/sphinxdoc/1.0/doctools.js (libcalcium-doc)
/usr/share/doc/libcalcium-doc/html/_static/jquery.js ->
../../../../javascript/sphinxdoc/1.0/jquery.js (libcalcium-doc)
/usr/share/doc/libcalcium-doc/html/_static/language_data.js ->
../../../../javascript/sphinxdoc/1.0/language_data.js (libcalcium-doc)
/usr/share/doc/libcalcium-doc/html/_static/searchtools.js ->
../../../../javascript/sphinxdoc/1.0/searchtools.js (libcalcium-doc)
/usr/share/doc/libcalcium-doc/html/_static/underscore.js ->
../../../../javascript/sphinxdoc/1.0/underscore.js (libcalcium-doc)
These links are manually created via debian/libcalcium-doc.links with no
dependency on the package containing the targeted files.
If the package were using dh_sphinxdoc it would take care of these
symlinks and provide a ${sphinxdoc:Depends} substvar that could be used
to get the required dependencies.
cheers,
Andreas
Bug#1032289: libdiplay-info: Keep out of the Bookworm release
On Fri, Jul 7, 2023 at 11:05 AM Marc Dequènes (Duck) wrote: > Thanks Jeremy, totally forgot to close it. Could you upload the version from Experimental to Unstable? Thank you, Jeremy Bícha
