Bug#1060217: plocate command blocks waiting io_uring operation
tag 1060217 + unreproducible thanks On Mon, Jan 08, 2024 at 12:01:07AM +0100, Manolis Stamatogiannakis wrote: > So, feel free to mark this as unreproducible for now. Doing so, thanks. I could probably see if Debian has a porterbox where I can reproduce this, but I'm not too optimistic (and I don't have a lot of extra time to dedicate to this right now, unfortunately). > Since you are also the author of plocate, it may make sense to expose the > -DWITHOUT_URING flag > through meson to make compiling without io_uring a bit more > straightforward. (Trival patch attached.) That doesn't really sound like a good long-term solution, though. :-) If there really is a bug here, and it is in plocate, it should “just” be fixed. Especially since most users are unlikely to go in and recompile their packages with such flags. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#1060175: qemu-system-i386: Display 'sdl' is not available.
08.01.2024 00:53, Thorsten Glaser : Michael Tokarev dixit: Gosh. Are you serious or is this some sort of a joke (it's not 1st April yet). I’m serious. This change has been made in version 1:2.12+dfsg-2 (Apr-2018), there's a news item about it. This same news item explains the reason and how to deal with it. Hmh, NEWS items are not shown when doing a fresh install on bullseye. And even then, searching for SDL case-insensitively in that file does not even show it. ... I see. You're coming from even older, pre-historic time than I thought :) Long time ago qemu-system had SDL UI as the only available local guest UI. Later on that one has been basically replaced with GTK - SDL were difficult to maintain and it didn't support most new things. But later on, in parallel to GTK, SDL2 UI has been introduced. That one hasn't been enabled in debian qemu for quite some time, because people complained about too much extra dependencies already for a headless install (qemu already pulled in lots of X11 stuff). Only after it has become possible to split whole UI display support into a separate package, so that main qemu-system does not depend on any graphics library, I enabled SDL2 display - now in *parallel* with GTK, and with GTK being the default (since this one is much more complete and has less bugs than SDL2). Sure you can request -display sdl explicitly, maybe only if there's some bug in gtk display and you want to check if it works better with sdl, - but qemu always had good default from the available options. All this is history still, for a few debian releases it is not relevant already. For a new install, qemu-system-foo Recommends qemu-system-gui package for a reason. If you disable installing recommends, you're supposed to at least check which packages it recommends before saying some feature is missing, - maybe it's in some recommends. You're the *first* person to complain about this since the split! :) BTW, in the current package in sid, I refined an old change (don't remember if it already was in bullseye or not) which suggests to install an additional package if a requested display is known but not available, like this: $ qemu-system-x86_64 -display sdl qemu-system-x86_64: Display 'sdl' is not available. Perhaps you want to install qemu-system-gui package? (for a few places, not just for display - or else it was spewing some errors due to missing other modules). Bullseye is definitely too old to add such changes though. /mjt
Bug#1060244: use of unitialized value $params{"action"} in gitweb.cgi
Package: gitweb
Version: 1:2.39.2-1.1
Severity: minor
Tags: patch
```
gitweb.cgi: Use of uninitialized value $params{"action"} in string eq at
/usr/lib/cgi-bin/gitweb.cgi line 1432.
```
Patch is attached.
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gitweb depends on:
ii git 1:2.42.0-1
ii libcgi-pm-perl 4.57-1
ii perl5.36.0-9
Versions of packages gitweb recommends:
ii libhttp-date-perl 6.05-2
ii lynx 2.9.0dev.12-1
ii nginx [httpd] 1.24.0-2
Versions of packages gitweb suggests:
pn git-doc
ii nginx [httpd-cgi] 1.24.0-2
--
.''`. martin f. krafft
: :' : proud Debian developer
`. `'` http://people.debian.org/~madduck
`- Debian - when you have better things to do than fixing systems
--- /tmp/gitweb.cgi 2024-01-08 08:32:37.267888437 +0100
+++ /usr/lib/cgi-bin/gitweb.cgi 2024-01-08 08:34:06.427008372 +0100
@@ -1427,13 +1427,16 @@
$href .= "/".esc_path_info($params{'project'});
delete $params{'project'};
- # since we destructively absorb parameters, we keep this
- # boolean that remembers if we're handling a snapshot
- my $is_snapshot = $params{'action'} eq 'snapshot';
+# since we destructively absorb parameters, we keep
+# this boolean that remembers if we're handling a
+# snapshot (see next conditional)
+my $is_snapshot = 0;
# Summary just uses the project path URL, any other action is
# added to the URL
if (defined $params{'action'}) {
+$is_snapshot = $params{'action'} eq 'snapshot';
+
$href .= "/".esc_path_info($params{'action'})
unless $params{'action'} eq 'summary';
delete $params{'action'};
Bug#933981: cdrom: USB, KVM create connect/disconnect loop in level1 (repair) install
On Mon, 05 Aug 2019 14:28:47 -0400 Tom Sullivan wrote: > Package: cdrom > Severity: grave > Tags: d-i > Justification: renders package unusable > > Dear Maintainer, > > * What led up to the situation? > > I had another machine that gave kernel panic while upgrading from Stretch to > Buster. Use of Graphical install was also a problem during re-install due to > destroyed system. (I reported this issue in another report.) Thus, I chose to > upgrade an identical machine from level 1 (Debain Repair in GRUB2 boot menu). > > * What exactly did you do (or not do) that was effective (or > ineffective)? > > The scrolling log in the command line display showed repeated > connect/disconnect loops for USB devices (of many kinds). This applied also to > USB mice and keyboards connected via KVM. > > For what it was worth, I used a local cache of the DVDs on the machine's hard > drive. > > Unplugged all USB, plugged in single USB keyboard only, and directly, not via > KVM. > > * What was the outcome of this action? > > Upgraded fine with just the keyboard directly plugged into USB. > > * What outcome did you expect instead? > > Correct handling of USB, without issues. > > > > > -- System Information: > Debian Release: 10.0 > APT prefers stable > APT policy: (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), > LANGUAGE=en_US.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Sent from my iPhone
Bug#1056457: python-ase's autopkg tests fail with Python 3.12
Control: severity -1 important Hi s3v Thank you for all the links to the upstream commits. I have applied them, and python-ase now builds successfully (closing #1056184). However, since spglib stopped building its extension for all supported Python versions (see #1057858) testing python-ase against Python 3.12 now fails with: 531s INTERNALERROR> Traceback (most recent call last): 531s INTERNALERROR> File "/usr/lib/python3/dist-packages/spglib/spglib.py", line 41, in 531s INTERNALERROR> from spglib import _spglib as spg 531s INTERNALERROR> ImportError: cannot import name '_spglib' from partially initialized module 'spglib' (most likely due to a circular import) (/usr/lib/python3/dist-packages/spglib/__init__.py) Therefore, I let python-ase only test against the default Python version [1], and lower the severity of this bug, until either Python 3.12 is the default, or spglib builds its extension for all supported Python versions again. Regards Graham [1] https://salsa.debian.org/debichem-team/python-ase/-/commit/b33055fd68da81e1806e7a0f0dd65dc5b53fc3b2
Bug#1058814: flint-arb: FTBFS: /<>/fmpz_extras.h:208:1: error: static declaration of ‘fmpz_ui_pow_ui’ follows non-static declaration
Control: tags -1 upstream Control: forwarded -1 https://github.com/fredrik-johansson/arb/issues/454 -- http://fam-tille.de
Bug#1059663: closed by Thomas Goirand (Cloud not reproduce)
Control: reopen -1 Still failing with python-editor/1.0.3-5. On Sun, 7 Jan 2024 at 15:48, Debian Bug Tracking System wrote: > I couldn't reproduce this. There's no autopkgtest in this package, but > the autopkgtest-pkg-python, which I believe is only doing an import of > the python module, which worked for me. Please try with python3-defaults/3.11.6-1 (i.e. with Python 3.12 as a supported version).
Bug#1039607: libjansi-java: causes maven to always output escape character
On Thu, Jan 04, 2024 at 10:22:02PM -0800, tony mancill wrote: > However, for the short-term, I believe we can achieve the desired > behavior and fix the issue for most use cases by > > 1. Patching the mvn wrapper script in our maven package to set > jansi.mode=force (and thus colorize output) unless the --batch-mode > option is provided. > > 2. Moving forward with the current jansi package in experimental. > > That restores the desired --batch-mode behavior but maintains > colorized output by default and during Debian package builds. I am preparing an upload of maven to experimental (version 3.8.7-2~exp1) that implements the changes described above. I will push the packaging changes to the debian/experimental branch in the Salsa repo. The patch for mvn can be found here: https://salsa.debian.org/java-team/maven/-/blob/4501966b3678135deacca45bc1a918380f6dac47/debian/patches/03_jansi_behavior.patch When used in conjunction with the jansi package in experimental, the behavior is: **output is colorized** mvn **output is non-colorized** mvn -B mvn --batch-mode The patched mvn script also checks for MAVEN_JANSI_PROPERTY in the environment, which allows users to override the behavior if desired. I don't expect this to be needed very often, but it may be useful if we modify the behavior of jansi in the future, and I wanted there to be an escape valve if the patched behavior is problematic for some unforeseen use case. The invocations below demonstrate the behavior of Debian's jansi that led to the patch in 2.4.0-2, i.e., that without the native jansi libraries or -Djansi.mode=force, the default TTY detection fails and results in non-colorized output. MAVEN_JANSI_PROPERTY="" mvn MAVEN_JANSI_PROPERTY= mvn For completeness: MAVEN_JANSI_PROPERTY="-Djansi.mode=default" mvn --> non-colorized MAVEN_JANSI_PROPERTY="-Djansi.mode=strip" mvn--> non-colorized MAVEN_JANSI_PROPERTY="-Djansi.mode=force" mvn--> colorized With these changes, we shouldn't need the patched maven-debian-helper I proposed previously, since the output of Maven invoked during builds will be colorized. I believe this will address the issues reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039607 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059147 Feedback welcome. We can coordinate here before any migrations from experimental to unstable. Thanks, tony signature.asc Description: PGP signature
Bug#1060242: Debian bluez_5.71.orig.tar.xz is different to upstream bluez-5.71.tar.xz
Package: bluez Version: 5.71-1 Debian's bluez_5.71.orig.tar.xz seems to have different contents from the upstream release bluez-5.71.tar.xz http://deb.debian.org/debian/pool/main/b/bluez/bluez_5.71.orig.tar.xz https://mirrors.edge.kernel.org/pub/linux/bluetooth/bluez-5.71.tar.xz I'm guessing Debian has snapshotted the git tag instead? Admittedly you *should* be able to do that IMHO, it's just a feature of the BlueZ project that they release significantly cleansed tarballs that are different to the tag they came from. Still, I suggest Debian should be using the official upstream release tarballs in future.
Bug#790562: Ghostscript: File has unbalanced q/Q operators (too many Q's)
On Tue, 30 Jun 2015 09:17:06 +0100 supp...@compress-pdf.co.uk wrote: > package: ghostscript > version: 9.06~dfsg-2 > > When running ghostscript, the following errors are being generated in > great quantity: > stderr: " File has unbalanced q/Q operators (too many Q's) " > > resulting in log files filling the disk. > > Additionally, kernel soft lockup warnings appear: > kernel:[406101.560749] BUG: soft lockup - CPU#4 stuck for 31s! [gs:21647] > > > Command being run is: > > gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/screen > -dNOPAUSE -dQUIET -dBandBufferSpace=5 -dBandSpace=10 > -dBATCH -sOutputFile='out.pdf' 'in.pdf' > > > It may be related to this bug on the ghostscript bug tracker flagged as > resolved: > http://bugs.ghostscript.com/show_bug.cgi?id=694310 In the absence of an example file, I will assume you are correct that this is the upstream bug noted. That fix is now in Debian, so I'll close this bug. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1000113: kodi: depends on obsolete pcre3 library
Hi Yavor, Thanks for the patch! Greatly appreciated!!! Upstream we discussed the pcre PR and there is an old branch porting some stuff to std::regex. I have checked that branch but some problems remained. I can test your patch because I am both the user and the maintainer as you requested. -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#1000113: kodi: depends on obsolete pcre3 library
Control: tags -1 + patch
Please find attached a patch; I did my best to test it.
I believe the changes to the CRegExp class (xbmc/utils/RegExp.*) are
sane; they are tested in xbmc/utils/test/TestRegexp.cpp and some other
test programs that use CRegExp. I added three more test cases:
invalid pattern, UTF-8 compilation/matching, and JIT. The latter two
should pass on all the buildds since PCRE2 is built everywhere with
Unicode support, and on those architectures where JIT support is not
available, m_JitSupported will be false so the related functions in
the methods RegComp and PrivateRegFind will not be invoked.
Furthermore, according to the PCRE2 documentation, an application
doesn't need to check explicitly for JIT support because all of the
PCRE2 JIT-related functions have dummy placeholders and silently do
nothing if JIT support is not available.
The changes to CFTPParse (xbmc/filesystem/FTPParse.cpp) are clumsy,
overly verbose code; I'm not proud of it at all. I tried to minimize
casting as much as possible. AFAICS it's used only to obtain an ftp
directory contents. I tried adding some directories from
ftp.gnustep.org as source, but of course there are no media files
there. Then I installed an FTP server and populated /srv/ftp/ with
some video files. Kodi displays their properties and plays them, but
I cannot be sure that CFTPParse methods are actually used. I can't
put breakpoints in gdb as the app runs in fullscreen mode and I don't
know how to switch to normal mode. (In hindsight, I guess I could
have added some printf statements but it's too late now and the beast
takes nearly 4 hours to build on my machine.) An unpleasant obstacle
was that Kodi frequently crashes my videocard driver (nouveau) which
made testing very frustrating.
I guess the patch needs more testing and a closer look by someone
familiar with this package (ideally both as a user and maintainer), on
a machine that is capable of running Kodi.
Please let me know if there are problems that require correction.
Description: Port to PCRE2.
Bug-Debian: https://bugs.debian.org/1000113
Author: Yavor Doganov
Forwarded: no
Last-Update: 2024-01-07
---
--- kodi-20.2+dfsg.orig/cmake/modules/FindPCRE.cmake
+++ kodi-20.2+dfsg/cmake/modules/FindPCRE.cmake
@@ -77,45 +77,34 @@
else()
# Populate paths for find_package_handle_standard_args
- find_path(PCRE_INCLUDE_DIR pcre.h)
+ find_path(PCRE_INCLUDE_DIR pcre2.h)
- find_library(PCRECPP_LIBRARY_RELEASE NAMES pcrecpp)
- find_library(PCRECPP_LIBRARY_DEBUG NAMES pcrecppd)
-
- find_library(PCRE_LIBRARY_RELEASE NAMES pcre)
- find_library(PCRE_LIBRARY_DEBUG NAMES pcred)
+ find_library(PCRE_LIBRARY_RELEASE NAMES pcre2-8)
endif()
else()
if(PKG_CONFIG_FOUND)
- pkg_check_modules(PC_PCRE libpcrecpp QUIET)
+ pkg_check_modules(PC_PCRE libpcre2-8 QUIET)
endif()
-find_path(PCRE_INCLUDE_DIR pcrecpp.h
+find_path(PCRE_INCLUDE_DIR pcre2.h
PATHS ${PC_PCRE_INCLUDEDIR})
-find_library(PCRECPP_LIBRARY_RELEASE NAMES pcrecpp
- PATHS ${PC_PCRE_LIBDIR})
-find_library(PCRE_LIBRARY_RELEASE NAMES pcre
+find_library(PCRE_LIBRARY_RELEASE NAMES pcre2-8
PATHS ${PC_PCRE_LIBDIR})
-find_library(PCRECPP_LIBRARY_DEBUG NAMES pcrecppd
- PATHS ${PC_PCRE_LIBDIR})
-find_library(PCRE_LIBRARY_DEBUG NAMES pcred
- PATHS ${PC_PCRE_LIBDIR})
set(PCRE_VERSION ${PC_PCRE_VERSION})
endif()
include(SelectLibraryConfigurations)
- select_library_configurations(PCRECPP)
select_library_configurations(PCRE)
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(PCRE
-REQUIRED_VARS PCRECPP_LIBRARY PCRE_LIBRARY
PCRE_INCLUDE_DIR
+REQUIRED_VARS PCRE_LIBRARY PCRE_INCLUDE_DIR
VERSION_VAR PCRE_VERSION)
if(PCRE_FOUND)
-set(PCRE_LIBRARIES ${PCRECPP_LIBRARY} ${PCRE_LIBRARY})
+set(PCRE_LIBRARIES ${PCRE_LIBRARY})
set(PCRE_INCLUDE_DIRS ${PCRE_INCLUDE_DIR})
if(WIN32)
set(PCRE_DEFINITIONS -DPCRE_STATIC=1)
@@ -166,5 +155,5 @@
endif()
endif()
- mark_as_advanced(PCRE_INCLUDE_DIR PCRECPP_LIBRARY PCRE_LIBRARY)
+ mark_as_advanced(PCRE_INCLUDE_DIR PCRE_LIBRARY)
endif()
--- kodi-20.2+dfsg.orig/xbmc/utils/RegExp.h
+++ kodi-20.2+dfsg/xbmc/utils/RegExp.h
@@ -13,16 +13,8 @@
#include
#include
-/* make sure stdlib.h is included before including pcre.h inside the
- namespace; this works around stdlib.h definitions also living in
- the PCRE namespace */
-#include
-
-namespace PCRE {
-struct real_pcre_jit_stack; // forward declaration for PCRE without JIT
-typedef struct real_pcre_jit_stack pcre_jit_stack;
-#include
-}
+#define PCRE2_CODE_UNIT_WIDTH 8
+#include
class CRegExp
{
Bug#1060241: ITP: qhotkey -- global hotkey library for desktop qt-applications
Package: wnpp Severity: wishlist Owner: Carlos Henrique Lima Melara X-Debbugs-Cc: debian-de...@lists.debian.org, charlesmel...@riseup.net * Package name: qhotkey Version : 1.5.0+git20230418.cd72a01 Upstream Contact: https://github.com/Skycoder42/QHotkey/issues/new * URL : https://github.com/Skycoder42/QHotkey * License : BSD-3-clause Programming Lang: C++ Description : global hotkey library for desktop qt-applications QHotkey is a class that can be used to create hotkeys/global shortcuts, aka shortcuts that work everywhere, independent of the application state. This means your application can be active, inactive, minimized or not visible at all and still receive the shortcuts. This is a dependency of QOwnNotes. The initial idea is to maintain under debian/ namespace on salsa. Cheers, Charles
Bug#1055087: golang-1.21: Add support for loong64
On Sun, 7 Jan 2024 03:50:13 +0800 Shengjing Zhu wrote: > On Tue, Oct 31, 2023 at 4:39 PM chenguoqi wrote: > > > > Package: golang-1.21 > > Version: 1.21.3 > > Severity: wishlist > > Tags: patch > > User: debian-loonga...@lists.debian.org > > Usertags: loong64 > > > > Hi, > > > > Golang upstream supports loong64 starting from Go1.19 version, and currently > > > > all dependencies for building golang-1.21 package on debian sid have been > > > > met. Golang-1.21 on loong64 can now be built. > > > > Could you look at the failures when bootstrapping Go 1.22? > https://buildd.debian.org/status/fetch.php?pkg=golang-1.22=loong64=1.22%7Erc1-2=170456=0 > > -- > Shengjing Zhu > Hi, Shengjing Zhu: This error is caused by the missing file /usr/include/loongarch64-linux-gnu/asm/errno.h in the build environment. This file is provided by the package linux-libc-dev. I checked the latest linux-libc -dev, this header file is already included, just reinstall linux-libc-dev to solve this error． -- Best regards, Guoqi Chen 本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.
Bug#704112: ghostscript: gs -dEPSCrop doesn't work
On Thu, 28 Mar 2013 02:21:25 +0100 Sebastien Desreux wrote: > I do realize that the PS file above is not an EPS. Yet this option also worked > for PS files with AFPL gs and then ESP gs. Besides, a search for "crop" on > http://ghostscript.com/doc/7.07/Use.htm > yielded only the EPS case. > It seems clear that the option EPSCrop is for EPS input, so this doesn't seem like a bug. Though I sympathise that it may be an irritating change in behaviour if it did used to work previously. -Steve signature.asc Description: This is a digitally signed message part.
Bug#731164: ghostscript: ps2pdf makes highlighted/annotated text unreadable by poppler-based PDF viewers
On Saturday, January 6, 2024 11:58:56 A.M. CST Vincent Lefevre wrote: > But all xpdf, > zathura and atril have no issues with the file generated by the > current ps2pdf. This confirms a good change in ghostscript. Excellent! Thanks for the additional testing and feedback! -Steve signature.asc Description: This is a digitally signed message part.
Bug#1060239: RM: pstotext -- ROM; No upstream, superceeded by ps2ascii
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: pstot...@packages.debian.org Control: affects -1 + src:pstotext The pstotext package was removed from testing in 2018 due to grave bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895513 It has been orphaned since then, with no visible interest https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898667 The last upstream release was 2004 and there is no trace of upstream on the internet that I can see. There's a wayback capture from mid 2007 but it was removed shortly afterwards. https://web.archive.org/web/20070609094538/http://www.cs.wisc.edu/~ghost/doc/ pstotext.htm Thus I suggest this package should be completely removed from Debian.
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
At the end of the weekend, I think packaging for Incus is at the point that we're ready for an upload to NEW once golang-github- canonical-lxd-dev clears. I have applied a patch to disable the loki logging integration for the time being and return an error if someone tries to configure it. Basic functionality seems to be working on my sid box: * Container creation/use/deletion * VM creation/use/deletion * lxd-to-incus for containers and VMs - Side note: I feel that currently lxd-to-incus is a bit aggressive in blindly renaming /var/lib/lxd/, /var/log/lxd/, and /var/cache/lxd/, as that breaks LXD if you try to re-start it after the migration and didn't auto-purge it at the end of lxd-to-incus. However, as I think the only time someone would run lxd-to-incus is in advance of removing LXD, I don't know if it's really too much of an issue to worry about or not... Untested are things like various storage backends, cluster mode, etc. I also went through and cleaned up the debian/ directory. If anyone else wants to play with the current packaging, I've pushed everything up to salsa. Mathias signature.asc Description: This is a digitally signed message part
Bug#1060238: cpufrequtils: loadcpufreq does not support current debian kernel
Package: cpufrequtils
Version: 008-2
Severity: important
Tags: patch
X-Debbugs-Cc: 1700011...@pku.edu.cn
Dear Maintainer,
loadcpufreq is an init.d script of cpufrequtils to load cpufreq governors'
kernel modules, but it does not work anymore after kernel 6.6.
The reason is that:
Current loadcpufreq does not support compressed kernel modules of cpufreq
governors, because such modules end with ( for example ) .ko.xz rather than
.ko, and this condition is not included in the script.
After kernel 6.6 , Debian official kernal use config CONFIG_MODULE_COMPRESS_XZ
, which means that all kernel modules are compressed with xz. So that now
loadcpufreq does not work for current Debian kernel.Cpufreq governor modules
will not be loaded.
To fix the problem:
We need to do just very little bit of changes of script to fix that problem.
The revised script is attached here. Just replace /etc/init.d/loadcpufreq with
this file please.
-- System Information:
Debian Release: 12.4
APT prefers testing
APT policy: (700, 'testing'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'stable'), (100, 'bookworm-fasttrack'), (100,
'bookworm-backports-staging'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.9-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.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 cpufrequtils depends on:
ii debconf [debconf-2.0] 1.5.82
ii init-system-helpers1.65.2
ii libc6 2.36-9+deb12u3
ii libcpufreq0008-2
ii sysvinit-utils [lsb-base] 3.06-4
cpufrequtils recommends no packages.
cpufrequtils suggests no packages.
-- Configuration Files:
/etc/init.d/loadcpufreq changed [not included]
-- debconf information:
cpufrequtils/enable: true
#!/bin/sh
### BEGIN INIT INFO
# Provides: loadcpufreq
# Required-Start:$remote_fs $syslog
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Description: Load kernel modules needed to enable cpufreq scaling
# Description: Make it possible to save power by reducing
#the CPU speed when there is little to do.
### END INIT INFO
# License: GNU General Public License.
#
# Based on scripts found in the powernowd package version
# 0.97-1ubuntu6 on Ubuntu.
#
# This script is an interim solution until the default Debian packages
# will load the proper kernel modules at boot time. Track #396117,
# #342014 and #367307 to see status on this.
# http://0pointer.de/blog/projects/dmi-based-module-autoloading.html>
# claim the later kernels support autoloading of these modules, so I
# guess In the future this script can be dropped. [pere 2007-05-12]
PATH=/sbin:/bin:/usr/sbin:/usr/bin
NAME=loadcpufreq
# Get lsb functions
. /lib/lsb/init-functions
[ -f /etc/default/rcS ] && . /etc/default/rcS
# Set a default value
ENABLE="true"
[ -f /etc/default/loadcpufreq ] && . /etc/default/loadcpufreq
set -e
# if not enabled then exit gracefully
[ "$ENABLE" = "true" ] || exit 0
MODPROBE="modprobe -b"
load_detected_cpufreq_modules() {
#if /usr/sbin/laptop-detect; then LAPTOP=1; fi
CPUINFO=/proc/cpuinfo
IOPORTS=/proc/ioports
if [ ! -f $CPUINFO ] ; then
echo "$CPUINFO not detected..." >&2
return
fi
MODEL_NAME=$(grep '^model name' "$CPUINFO" | head -1 | sed -e 's/^.*: //;')
MODEL_ID=$(grep -E '^model[[:space:]]+:' "$CPUINFO" | head -1 | sed -e
's/^.*: //;')
CPU=$(grep -E '^cpud[^:]+:' "$CPUINFO" | head -1 | sed -e 's/^.*: //;')
VENDOR_ID=$(grep -E '^vendor_id[^:]+:' "$CPUINFO" | head -1 | sed -e
's/^.*: //;')
CPU_FAMILY=$(sed -e '/^cpu family/ {s/.*: //;p;Q};d' $CPUINFO)
MODULE=
MODULE_FALLBACK=acpi-cpufreq
# Two modules for PIII-M depending the chipset.
# modprobe speedstep-ich$EXT || modprobe speestep-smi$EXT
# would be another way
if [ -f $IOPORTS ] && grep -q 'Intel .*ICH' $IOPORTS ; then
PIII_MODULE=speedstep-ich
else
PIII_MODULE=speedstep-smi
fi
case "$VENDOR_ID" in
GenuineIntel*)
# If the CPU has the est flag, it supports enhanced
# speedstep and should use the acpi-cpufreq driver
if [ "$(grep est $CPUINFO)" ]; then
MODULE=acpi-cpufreq
elif [ $CPU_FAMILY = 15 ]; then
# Right. Check if it's a P4 without est.
# Could be speedstep-ich, or could be p4-clockmod.
MODULE=speedstep-ich;
# Disabled for now - the latency tends to be bad
# enough to make it fairly pointless.
# echo "FREQDRIVER=p4-clockmod" >/etc/default/powernowd
# to override this
# if [ $LAPTOP = "1" ]; then
# MODULE_FALLBACK=p4-clockmod;
# fi
else
Bug#1060237: openjdk-17-jre-zero cannot be installed anymore
Package: openjdk-17-jre-zero Version: 17.0.9+9-2 Severity: normal Hey. Since upgrading the other OpenJDK packages to 17.0.10~6ea-1, openjdk-17-jre-zero is uninstallable. Cheers, Chris.
Bug#1060236: openjdk-8 adds zero build for loong64
Package: openjdk-8 Version: 8u392-ga-1 Severity: wishlist Tags: patch User: debian-loonga...@lists.debian.org Usertags: loong64 Dear Maintainers, I hope this email finds you well. We would like to add openjdk-8 zero build support for loong64. The attached patch includes three parts of changes: (1) Add the loong64 variable to debian/rules and debian/control. (2) Backport the code in JDK-8270517 and JDK-8315020 due to the backport of JDK-8270517 is request for review right now, so we need to handle it additionally. (3) patches/loong64-autoconf-config.diff adds loongarch info. Thank you for your time and consideration of this request. Thanks, Leslie Zhai support-zero-build-for-loong64.patch Description: Binary data
Bug#1060233: libc6: Missing libdl.so
Dear Aurelien, > Starting with glibc 2.34, libdl is an empty library. Therefore only a > libdl.a is provided to support linking with -ldl. At bullseye, I explicitly needed to use libdl e.g. with constructs like export LD_LIBRARY_PATH=/somewhere export LD_PRELOAD='libdl.so gconf_client_get_string.so' with code using dlopen() to then replace (modify?) library calls. You suggest that there is no longer a need to explicitly preload libdl: great, will simplify all my instances. (Until then, the useless symlink allows the scripts to work as before.) Also: why provide the "empty" libdl.so.2 object, still? Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Join the Union and fight for a better University: www.nteu.au/join
Bug#1060202: glibc - autopkgtest flacky on arm64
On 2024-01-07 21:59, Paul Gevers wrote: > Hi, > > On 07-01-2024 18:21, Aurelien Jarno wrote: > > > Timeout while building: > > > https://ci.debian.net/packages/g/glibc/unstable/arm64/41516611/ > > > > There are indeed many failures with cc1 getting killed, it seems that it > > started around 2024-01-02. I haven't spotted any change to the toolchain > > nor kernel version. > > > > I am not able to reproduce the issue, so it is very likely linked to > > debci. Would it be possible to now why cc1 get killed? OOM? timeout? > > I extracted the attached journal piece indicating OOM. > Thanks that's very useful. It appears that the tgmath3-fma test got killed after using 2611964kB. In practice it needs a few MB more, and that's not something that has changed recently, it needs about the same amount of memory with gcc-12 from bookworm. This test is known to take a lot of memory to compile, and on amd64, it needs around 3.2GB. I am still not sure why it got killed on arm64 and not on other debci workers, there as still swap available. Actually looking at the munin plot, it seems that the arm64 debci workers stopped using swap around September 2023 contrary to the other architectures. The good news is that it seems that gcc-13 needs a bit less RAM to compile that file. We can switch to it once we get glibc 2.38 into testing. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1060235: rsync: --ignore-existing and --size-only have no effect when combined with -t
Package: rsync Version: 3.2.7-1 Severity: normal Dear Maintainer, Excected outcome: I wanted to preserve the time of modification for files that did not exist on target, but do not change files that already exist, even if the modification times differ. Attempted action: I thought that rsync with -t and --ignore-existing would be a perfect fit for that; their summary taken from rsync --help: --times, -t preserve modification times --ignore-existing skip updating files that exist on receiver Actual result: I compared the output of two commands: rsync -rlv --dry-run dir1 dir2 and rsync -rlv --ignore-existing --dry-run dir1 dir2 print the same 3 files, which indeed do not exist on the target. However, rsync -rlvt --dry-run dir1 dir2 and rsync -rlvt --ignore-existing --dry-run dir1 dir2 print a few hundred files. Most of them, with the exception of the mentioned 3, exist in dir2. It seems that --ignore-existing takes no effect when combined with -t: the number of lines returned is the same in both cases. Case of --size-only: I expanded the above combination with --size-only (--help: skip files that match in size), which in my opinion should be sufficient for my use-case on its own, but it didn't help either. Summary: Apparently combining the -t option with --ignore-exisitng or --size-only renders the latter useless. Assuming the best case, their --help strings are inprecise enough that their wrong behaviour is assumed. -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 rsync depends on: ii init-system-helpers1.65.2 ii libacl12.3.1-3 ii libc6 2.36-9+deb12u3 ii liblz4-1 1.9.4-1 ii libpopt0 1.19+dfsg-1 ii libssl33.0.11-1~deb12u2 ii libxxhash0 0.8.1-1 ii libzstd1 1.5.4+dfsg2-5 ii lsb-base 11.6 ii sysvinit-utils [lsb-base] 3.06-4 ii zlib1g 1:1.2.13.dfsg-1 rsync recommends no packages. Versions of packages rsync suggests: ii openssh-client 1:9.2p1-2+deb12u2 ii openssh-server 1:9.2p1-2+deb12u2 ii python3 3.11.2-1+b1 pn python3-braceexpand -- no debconf information
Bug#1060234: uwsgi: Please add debian/uwsgi.pydist for dh-python3 map
Package: uwsgi Version: 2.0.23-1 Severity: normal X-Debbugs-Cc: Debian Python Team Hi, A python module wanting uwsgi server would depend on "uWSGI", but dh-python3 won't know what is the corresponding debian package name, unless this file exists: /usr/share/python3/dist/uwsgi.pydist with this line in it: uWSGI uwsgi; PEP386 it would be great if uwsgi installed that file. Jérémy -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (101, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 uwsgi depends on: ii sysvinit-utils [lsb-base] 3.08-5 ii uwsgi-core 2.0.23-1 uwsgi recommends no packages. uwsgi suggests no packages. -- no debconf information
Bug#1060233: libc6: Missing libdl.so
Hi, On 2024-01-08 10:39, Paul Szabo wrote: > Package: libc6 > Version: 2.36-9+deb12u3 > Severity: normal > > At bookworm, libdl.so is missing. The file > /usr/lib/x86_64-linux-gnu/libdl.so.2 > is provided, but there is no symlink > .../libdl.so -> .../libdl.so.2 > > Easily corrected with command: > ln -s libdl.so.2 /usr/lib/x86_64-linux-gnu/libdl.so > > At bullseye, libdl.so.2 was in package libc6, while the symlink libdl.so > was in libc6-dev Starting with glibc 2.34, libdl is an empty library. Therefore only a libdl.a is provided to support linking with -ldl. > (which seems somewhat wrong already). No, the .so symlink has to be in the -dev package, according to Debian Policy 8.4. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1060233: libc6: Missing libdl.so
Package: libc6 Version: 2.36-9+deb12u3 Severity: normal At bookworm, libdl.so is missing. The file /usr/lib/x86_64-linux-gnu/libdl.so.2 is provided, but there is no symlink .../libdl.so -> .../libdl.so.2 Easily corrected with command: ln -s libdl.so.2 /usr/lib/x86_64-linux-gnu/libdl.so At bullseye, libdl.so.2 was in package libc6, while the symlink libdl.so was in libc6-dev (which seems somewhat wrong already). Cheers, Paul Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5+pk12.50 (SMP w/64 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libc6 depends on: ii libgcc-s1 12.2.0-14 Versions of packages libc6 recommends: ii libidn2-0 2.3.3-1+b1 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.82 ii glibc-doc 2.36-9+deb12u3 ii libc-l10n 2.36-9+deb12u3 ii libnss-nis 3.1-4 ii libnss-nisplus 1.3-4 ii locales2.36-9+deb12u3 -- debconf information: * libraries/restart-without-asking: true glibc/kernel-not-supported: glibc/disable-screensaver: * glibc/restart-failed: * glibc/upgrade: true glibc/kernel-too-old: glibc/restart-services:
Bug#1060219:
I think maybe I responded to the wrong email address a moment ago. At the risk of double-posting, again: Like this. W fg + w bg. This is under plain Openbox with no further DE (although one is installed, Xfce I think, I never boot to it) under X under Debian 12. I never had this problem under Ubuntu 18.04, so it's not likely to be hardware. Hmmm . . . it occurs to me - there are some statements in the theme that are gtk deprecated. They're apparently just ignored and have never given me any problem, but they do put out error messages to stderr and have for years. GTK-error this & GTK-error that. I have to 2>/dev/null yad in all my scripts to shut it up. Could it be that they have finally gone from deprecations merely discouraged to breaking things? I can explore that if you think it likely, but it seems unlikely to be the culprit, since xvkbd reverts to normal colors the moment I click any non-letter, non-number key (space or backspace for example). But when I click a letter or number key, it switches to this. -- Sent with Tuta; enjoy secure & ad-free emails: https://tuta.com
Bug#824603: Close Resolved
I think this could be closed Resolved? I have "important" added to my "AptListbugs::Severities" and warned before installing meld. No issues here running /usr/bin/meld 3.22.0-2 with Python 3.11 from stable repo.
Bug#1060217: plocate command blocks waiting io_uring operation
Forgot to attach the patch. Classic. Best regards, Manolis On Mon, 8 Jan 2024 at 00:01, Manolis Stamatogiannakis wrote: > Hi Steinar, > > Thanks for the fast response. > > On Sun, 7 Jan 2024 at 20:48, Steinar H. Gunderson > wrote: > >> On Sun, Jan 07, 2024 at 08:21:35PM +0200, Manolis Stamatogiannakis wrote: >> > I am trying to get plocate to run on an old ARM-based NAS running Debian >> > bookworm. Building the database with updatedb works fine, but plocate >> > command itself blocks forever without giving any results back. >> > >> > I attached gdb to the process, and the source of the problem appears to >> > be related to the use of io_uring. >> > >> > Trying to understand what is going on, I ran plocate under strace as >> > root. Surprisingly, it ran without blocking. >> >> This is interesting, but fundamentally pretty impossible to debug from my >> side. It sounds very much like a timing-related bug, which is probably why >> strace affects it (everything goes much slower); another common case is >> that >> one attaches strace to a running process, which causes the io_uring >> syscall >> to return EINTR, which gets things running again. >> >> Is this reproducible every time? >> > > Yes, it is reproducible every time. > > I understand this may be very hard to reproduce/debug on your side without > access to similar hardware. > One could probably try reproducing the behaviour with cpulimit + QEMU, but > it's not a guaranteed > hit, and I don't really expect anyone to spend their time on that. > > For now, I'm quite content with having a workaround, and I opened the bug > mostly to have the > issue and the workaround documented for anyone else that may be affected. > If more people turn out to have the same issue on armel, we'll probably > also have more input for > a source-based fix. > > So, feel free to mark this as unreproducible for now. > > Since you are also the author of plocate, it may make sense to expose the > -DWITHOUT_URING flag > through meson to make compiling without io_uring a bit more > straightforward. (Trival patch attached.) > > > >> >> >* reports an error for not being able to access the database when run >> > under strace as user (which sounds like the expected behaviour) >> >> Yes, this is expected. >> >> > Architecture: armel (armv5tel) >> > Kernel: Linux 6.1.0-17-marvell (UP) >> >> Is this even supported by Debian anymore? >> >> > It's definitely a niche platform, but it appears to be supported: > https://www.debian.org/releases/stable/i386/ch02s01.en.html > > >> /* Steinar */ >> -- >> Homepage: https://www.sesse.net/ > > > > Best regards, > Manolis > plocate-without-uring.diff Description: Binary data
Bug#1060217: plocate command blocks waiting io_uring operation
Hi Steinar, Thanks for the fast response. On Sun, 7 Jan 2024 at 20:48, Steinar H. Gunderson wrote: > On Sun, Jan 07, 2024 at 08:21:35PM +0200, Manolis Stamatogiannakis wrote: > > I am trying to get plocate to run on an old ARM-based NAS running Debian > > bookworm. Building the database with updatedb works fine, but plocate > > command itself blocks forever without giving any results back. > > > > I attached gdb to the process, and the source of the problem appears to > > be related to the use of io_uring. > > > > Trying to understand what is going on, I ran plocate under strace as > > root. Surprisingly, it ran without blocking. > > This is interesting, but fundamentally pretty impossible to debug from my > side. It sounds very much like a timing-related bug, which is probably why > strace affects it (everything goes much slower); another common case is > that > one attaches strace to a running process, which causes the io_uring syscall > to return EINTR, which gets things running again. > > Is this reproducible every time? > Yes, it is reproducible every time. I understand this may be very hard to reproduce/debug on your side without access to similar hardware. One could probably try reproducing the behaviour with cpulimit + QEMU, but it's not a guaranteed hit, and I don't really expect anyone to spend their time on that. For now, I'm quite content with having a workaround, and I opened the bug mostly to have the issue and the workaround documented for anyone else that may be affected. If more people turn out to have the same issue on armel, we'll probably also have more input for a source-based fix. So, feel free to mark this as unreproducible for now. Since you are also the author of plocate, it may make sense to expose the -DWITHOUT_URING flag through meson to make compiling without io_uring a bit more straightforward. (Trival patch attached.) > > >* reports an error for not being able to access the database when run > > under strace as user (which sounds like the expected behaviour) > > Yes, this is expected. > > > Architecture: armel (armv5tel) > > Kernel: Linux 6.1.0-17-marvell (UP) > > Is this even supported by Debian anymore? > > It's definitely a niche platform, but it appears to be supported: https://www.debian.org/releases/stable/i386/ch02s01.en.html > /* Steinar */ > -- > Homepage: https://www.sesse.net/ Best regards, Manolis
Bug#1059805: clucene-core: please apply LibreOffice patch to alllow not writing random timestamps into generated files, making them unreproducible
Followup-For: Bug #1059805 X-Debbugs-Cc: r...@debian.org, t...@libreoffice.org On Thu, 4 Jan 2024 19:40:09, I wrote: > Please note: I haven't tested the patch yet, hence not adding a > 'patch' tag to this bug yet - I'm building libreoffice locally after > installing the patched+compiled clucene package, and will inspect the > help indexes constructed by the build. Feedback / review / > alternative approach suggestions are welcome. I'd underanticipated the build time requirements here (although I have read since then that 24h or so is not unexpected for a first build) - so I don't know if/when I'll get around to testing it properly. Is there another way I could go about confirming whether my patch could work for libreoffice, or to get some help doing that? (also note: I hadn't noticed that this bugthread already had the 'patch' tag applied)
Bug#1056380: Same issue under Ubuntu 22.04, reprepro hangs on Ubuntu package, unzstd process waiting
Christoph and Thomas, Please try 5.3.1-3 on your machines. If it works, you might want to trigger Ubuntu's stable update process. I will not publish a stable update for Debian but if another DD wants to do it, please go ahead. Cheers, Bastian
Bug#1060232: calamares: Installing in an LVM volume renders installation unusable
Package: calamares Severity: important X-Debbugs-Cc: cqu...@arcor.de I have tried to use the calamares based installer from the ISO image debian- live-12.4.0-amd64-xfce.iso and selected a LVM volume to make the installation. That volume was there before the installation started. I realized that the installer didn't offer a way to configure the volumes (at least it wasn't obvious to me) but I could anyway proceed with the installation selecting the existing volume. The installation went fine but when I rebooted the system I ended up with an unbootable system because the initrd didn't have support for LVM. -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE=es_ES:es Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages calamares depends on: ii kpackagetool55.103.0-1 pn libboost-python1.74.0 pn libboost-python1.74.0-py311 ii libc62.36-9+deb12u3 ii libcrypt11:4.4.33-2 ii libgcc-s112.2.0-14 ii libkf5configcore55.103.0-2 ii libkf5coreaddons55.103.0-1 ii libkf5package5 5.103.0-1 ii libkf5parts5 5.103.0-1 ii libkpmcore12 22.12.3-1 ii libparted2 3.5-3 ii libpwquality11.4.5-1+b1 ii libpython3.113.11.2-6 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5dbus5 5.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5network5 5.15.8+dfsg-11 ii libqt5qml5 5.15.8+dfsg-3 ii libqt5quick5 5.15.8+dfsg-3 ii libqt5quickwidgets5 5.15.8+dfsg-3 ii libqt5svg5 5.15.8-3 ii libqt5webkit55.212.0~alpha4-30 ii libqt5widgets5 5.15.8+dfsg-11 ii libqt5xml5 5.15.8+dfsg-11 ii libstdc++6 12.2.0-14 pn libyaml-cpp0.7 ii os-prober1.81 Versions of packages calamares recommends: pn btrfs-progs ii squashfs-tools 1:4.5.1-1 calamares suggests no packages.
Bug#1004677: dh-golang: Please support skipping specific tests
Package: dh-golang Version: 1.62 Followup-For: Bug #1004677 This seems easy to do, since go1.20 it is possible to do go test -skip -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (101, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 dh-golang depends on: ii debhelper 13.11.9 ii libdpkg-perl 1.22.2 ii perl 5.36.0-10+b1 dh-golang recommends no packages. dh-golang suggests no packages. -- no debconf information
Bug#1060231: calamares: launching the installer from live image XFCE ISO shows a message about unstrusted application
Package: calamares Severity: minor X-Debbugs-Cc: cqu...@arcor.de I have used the debian-live-12.4.0-amd64-xfce.iso image to try a live Debian system with XFCE. I then launched the installer icon and a somehow scary message shows up: "Untrusted application launcher The desktop file "install-debian.desktop" is in an insecure location and not marked as executable. If you do not trust this program click Cancel. Exec=install-debian" I clicked in "Launch Anyway" and thinks worked fine, but I guess someone else might be deterred from installing Debian due to the somehow scary message. -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE=es_ES:es Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages calamares depends on: ii kpackagetool55.103.0-1 pn libboost-python1.74.0 pn libboost-python1.74.0-py311 ii libc62.36-9+deb12u3 ii libcrypt11:4.4.33-2 ii libgcc-s112.2.0-14 ii libkf5configcore55.103.0-2 ii libkf5coreaddons55.103.0-1 ii libkf5package5 5.103.0-1 ii libkf5parts5 5.103.0-1 ii libkpmcore12 22.12.3-1 ii libparted2 3.5-3 ii libpwquality11.4.5-1+b1 ii libpython3.113.11.2-6 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5dbus5 5.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5network5 5.15.8+dfsg-11 ii libqt5qml5 5.15.8+dfsg-3 ii libqt5quick5 5.15.8+dfsg-3 ii libqt5quickwidgets5 5.15.8+dfsg-3 ii libqt5svg5 5.15.8-3 ii libqt5webkit55.212.0~alpha4-30 ii libqt5widgets5 5.15.8+dfsg-11 ii libqt5xml5 5.15.8+dfsg-11 ii libstdc++6 12.2.0-14 pn libyaml-cpp0.7 ii os-prober1.81 Versions of packages calamares recommends: pn btrfs-progs ii squashfs-tools 1:4.5.1-1 calamares suggests no packages.
Bug#1060230: amdgpu: screen goess black for a few seconds and after it goes back again the WM is unresponsive
Package: src:linux Version: 6.5.10-1~bpo12+1 Severity: important X-Debbugs-Cc: cqu...@arcor.de I have installed 6.5.0-0.deb12.4-amd64 kernel packae from backports bookworm to better support my AMD Radeon 780M iGPU. For a few seconds the screen went completely black and the computer was unresponsive. After that the screen showed again the desktop, I could move the mouse but clicking on windows and typing with the keyboard didn't have any effect. I am using XFCE4 desktop and at the moment this happened I was using my laptop screen (2880x1800) and a Dell external monitor with resolution 2560x1440. journalctl shows the following error message from the kernel: ene 07 22:23:00 hostname kernel: [drm:gfx_v11_0_priv_reg_irq [amdgpu]] *ERROR* Illegal register access in command stream ene 07 22:23:00 hostname kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=2168138, emitted seq=2168141 ene 07 22:23:00 hostname kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process thunderbird pid 16057 thread thunderbir:cs0 pid 16149 ene 07 22:23:00 hostname kernel: amdgpu :03:00.0: amdgpu: GPU reset begin! ene 07 22:23:00 hostname kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 ene 07 22:23:00 hostname kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue ene 07 22:23:00 hostname kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 ene 07 22:23:00 hostname kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue ene 07 22:23:00 hostname kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 ene 07 22:23:00 hostname kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue ene 07 22:23:01 hostname kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 ene 07 22:23:01 hostname kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue ene 07 22:23:01 hostname kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 ene 07 22:23:01 hostname kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue ene 07 22:23:01 hostname kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 ene 07 22:23:01 hostname kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue ene 07 22:23:01 hostname kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 ene 07 22:23:01 hostname kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue ene 07 22:23:01 hostname kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 ene 07 22:23:01 hostname kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue ene 07 22:23:01 hostname kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 ene 07 22:23:01 hostname kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue ene 07 22:23:01 hostname kernel: [drm:gfx_v11_0_hw_fini [amdgpu]] *ERROR* failed to halt cp gfx ene 07 22:23:01 hostname kernel: amdgpu :03:00.0: amdgpu: MODE2 reset ene 07 22:23:01 hostname kernel: amdgpu :03:00.0: amdgpu: GPU reset succeeded, trying to resume ene 07 22:23:01 hostname kernel: [drm] PCIE GART of 512M enabled (table at 0x0080FFD0). ene 07 22:23:01 hostname kernel: amdgpu :03:00.0: amdgpu: SMU is resuming... ene 07 22:23:01 hostname kernel: amdgpu :03:00.0: amdgpu: SMU is resumed successfully! ene 07 22:23:01 hostname kernel: [drm] DMUB hardware initialized: version=0x08000500 ene 07 22:23:01 hostname kernel: [ cut here ] ene 07 22:23:01 hostname kernel: WARNING: CPU: 1 PID: 13081 at drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:1527 dp_retrieve_lttpr_cap+0x16f/0x1a0 [amdgpu] ene 07 22:23:01 hostname kernel: Modules linked in: r8152 btrfs blake2b_generic xor raid6_pq ufs qnx4 hfsplus hfs cdrom minix msdos jfs xfs libcrc32c ctr ccm rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cma> ene 07 22:23:01 hostname kernel: hid_multitouch evdev serio_raw msr ledtrig_pattern parport_pc ppdev lp parport fuse loop efi_pstore configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic> ene 07 22:23:01 hostname kernel: CPU: 1 PID: 13081 Comm: kworker/u16:2 Not tainted 6.5.0-0.deb12.4-amd64 #1 Debian 6.5.10-1~bpo12+1 ene 07 22:23:01 hostname kernel: Hardware name: TUXEDO TUXEDO Pulse 14 Gen3/R14FA1, BIOS 8.06
Bug#1060175: qemu-system-i386: Display 'sdl' is not available.
Michael Tokarev dixit: > Gosh. Are you serious or is this some sort of a joke (it's not 1st April > yet). I’m serious. > This change has been made in version 1:2.12+dfsg-2 (Apr-2018), there's > a news item about it. This same news item explains the reason and how > to deal with it. Hmh, NEWS items are not shown when doing a fresh install on bullseye. And even then, searching for SDL case-insensitively in that file does not even show it. Searching for 2\.12 also does not find it. Indeed there are only two NEWS entries, 1:5.0-9 and 1.7.0+dfsg-2, no others. So no, I have n̲o̲ idea how to “deal with it”. > Do you think that during all these almost 6 years, it's possible that > no one else has noticed this "much harder to use"? I'm *very* doubt > it's possible. Not sure; I only noticed because I was using qemu from the command line as opposed to with libvirt (in order to try a new OS), on a system that did not have qemu installed before. So, how do I get SDL display working in bullseye? > You install things without recommends, - it's assumed you know what > you're doing and you have minimal knowledge where to look at in case > of issues like this one (hint: take a look at Recommends: of the > packages with reduced functionality). I did, but it just showed an optional GTK+3 GUI, which I do not want to use. I avoid GTK+ stuff in general, GTK+3 especial. > Install qemu-system-gui package and be done with this. I want the classic SDL interface. > BTW, please try to not use -i386, it is significantly less tested > target than -x86_64. Perhaps, but when specifically emulating for a 32-bit system that needs such a CPU this is the correct one to use. > Also, "sdl" display type *appeared* with the qemu-system-gui split, > since it were possible to add more dependencies for -gui without > adding them to "headless setup". If you added this sideswipe for the reason I guess, then no, you’re wrong. I *was* able to discover the “sdl” display from the qemu error message and the manpage. I am not able to find out how to proceed from there with just that (nor, see above, the NEWS file). bye, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜ also warum machen die xorg Jungs eigentlich alles kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…
Bug#1060229: fuse,fuse3,ntfs-3g: migrate dpkg-statoverride for UsrMerge?
Package: fuse,fuse3,ntfs-3g
X-Debbugs-CC: Laszlo Boszormenyi (GCS) , Helmut Grohne
Hello Laszlo!
fuse, fuse3, and ntfs-3g use dpkg-statoverride on aliased paths in
/bin: /bin/fusermount, /bin/fusermount3.
They do so in their postinst scripts, only checking if a
statoverride exists. If not, they run chmod on some programs.
The postinst does not add a statoverride.
As you know, these paths need to become canonicalized to /usr/{...}.
When this happens, the old dpkg-statoverride entries stop working.
Now my question: do you think it is worth migrating any such
dpkg-statoverride automatically?
If not, how should users/admins who previously created an override
be informed about this problem? Some suggestions might be:
- NEWS.Debian entry
- trixie Release Notes
What do you think?
I've started working on UsrMerge patches for fuse and fuse3. Those
patches would need to take into account the question above, and also
the file loss problem between fuse and fuse3.
Additional context: the three packages are the only packages in this
"problem space". One other package uses dpkg-statoverride on an
aliased path, but it also creates the override - what we decide here
might influence that package, but probably not.
I hope to hearing from you about this soon,
Chris
Bug#1060228: qt6-multimedia: Cmake config for MultimediaQuickPrivate is not packaged
Source: qt6-multimedia Version: 6.4.2-11 Severity: normal X-Debbugs-Cc: rob...@griebl.org Hi, The Debian Qt6 MM packages are not shipping with a cmake config for the private module "MultimediaQuickPrivate". While you normally do not have to deal with this private module, you definitely DO need it when using qmltc to compile QML code using QtMultiMedia QML types, as qmltc generates code that includes private headers from there: Failed to find required Qt component "MultimediaQuickPrivate". [cmake] [cmake] Expected Config file at [cmake] "/usr/lib/x86_64-linux-gnu/cmake/Qt6MultimediaQuickPrivate/Qt6MultimediaQuickPrivateConfig.cmake" [cmake] does NOT exist [cmake] Thanks for looking into this, Robert -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-4-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1039011: python3-breezy: does not needs python3-six anymore
After the nmu, python3-six is back. I don't know anything about Bazaar ... I don't know what happened. Greetings
Bug#1060219: xvkbd: Fn keys are usually white on white & change color depending on what key is clicked.
Hello, Lew_Rockwell_Fan via Pkg-a11y-devel, le dim. 07 janv. 2024 14:34:49 -0500, a ecrit: >* What outcome did you expect instead? I hoped the color scheme would > become stable, or at least usable. White on white is not usable. It's also an > eye sore, almost literally. white on white? Could you post a screenshot? This is what I am getting. Which graphical environment are you using? (desktop? Xorg? Wayland?) Samuel
Bug#1016730: ITP: netbird -- VPN management platform built on top of WireGuard
Any update on this package? If not packaged yet, I'd like to work on it. Thanks, -- Liang Guo
Bug#1060226: live-build: binary_grub_cfg cannot handle more than two kernels
Package: live-build
Version: 1:20231215
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: deb...@bobrosbag.nl
Dear Maintainer,
When installing more than two kernels I get an error:
basename: extra operand ‘chroot/boot/vmlinuz-6.6.7-1-liquorix-amd64’
Try 'basename --help' for more information.
This originates from scripts/build/binary_grub_cfg
I look through the code and the code seems to be written for one kernel. It
still works with two kernels (because basename accepts two parameters) but
fails when three or more kernels are present.
I attached a patch.
-- Package-specific info:
-- System Information:
Debian Release: 12.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'proposed-updates'), (500, 'stable'), (100, 'bookworm-fasttrack'), (100,
'bookworm-backports-staging')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.10-1-liquorix-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_NL.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages live-build depends on:
ii cpio 2.13+dfsg-7.1
ii debootstrap 1.0.133~bpo12+1
Versions of packages live-build recommends:
ii apt-utils 2.6.1
ii bzip2 1.0.8-5+b1
ii cryptsetup 2:2.6.1-4~deb12u1
ii file1:5.44-3
ii live-boot-doc 1:20230131
ii live-config-doc 11.0.4
ii live-manual 2:20151217.2
ii live-manual-epub [live-manual] 2:20151217.2
ii live-manual-html [live-manual] 2:20151217.2
ii live-manual-odf [live-manual] 2:20151217.2
ii live-manual-pdf [live-manual] 2:20151217.2
ii live-manual-txt [live-manual] 2:20151217.2
ii rsync 3.2.7-1
ii systemd-container 254.5-1~bpo12+3
ii wget1.21.3-1+b2
ii xz-utils5.4.1-0.2
Versions of packages live-build suggests:
ii e2fsprogs 1.47.0-2
ii mtd-utils 1:2.1.5-1
ii parted 3.5-3
-- no debconf information
--- binary_grub_cfg 2023-12-15 11:03:16.937803714 +0100
+++ binary_grub_cfg.new 2023-12-15 11:02:47.527301806 +0100
@@ -114,7 +114,7 @@
# Default entries
DEFAULT_FLAVOUR="$(echo ${LB_LINUX_FLAVOURS} | awk '{ print $1 }')"
-DEFAULT_KERNEL="$(basename chroot/boot/vmlinuz-*${DEFAULT_FLAVOUR})"
+DEFAULT_KERNEL="$(basename $(ls chroot/boot/vmlinuz-*${DEFAULT_FLAVOUR} | tail
-1))"
DEFAULT_INITRD="initrd.img-$(echo ${DEFAULT_KERNEL} | sed -e 's|vmlinuz-||')"
KERNEL_LIVE="/${INITFS}/${DEFAULT_KERNEL}"
@@ -137,9 +137,9 @@
if [ "${_AMD64_686_NUMBER}" -ge 2 ] ; then
# Default entries
- AMD64_KERNEL="$(basename chroot/boot/vmlinuz-*amd64)"
+ AMD64_KERNEL="$(basename $(ls chroot/boot/vmlinuz-*amd64 | tail -1))"
AMD64_INITRD="initrd.img-$(echo ${AMD64_KERNEL} | sed -e
's|vmlinuz-||')"
- _686_KERNEL="$(basename chroot/boot/vmlinuz-*686)"
+ _686_KERNEL="$(basename $(ls chroot/boot/vmlinuz-*686 | tail -1))"
_686_INITRD="initrd.img-$(echo ${_686_KERNEL} | sed -e 's|vmlinuz-||')"
Grub_live_autodetect_menu_entry "Live system (autodetect)" \
Bug#1060202: glibc - autopkgtest flacky on arm64
Hi, On 07-01-2024 18:21, Aurelien Jarno wrote: Timeout while building: https://ci.debian.net/packages/g/glibc/unstable/arm64/41516611/ There are indeed many failures with cc1 getting killed, it seems that it started around 2024-01-02. I haven't spotted any change to the toolchain nor kernel version. I am not able to reproduce the issue, so it is very likely linked to debci. Would it be possible to now why cc1 get killed? OOM? timeout? I extracted the attached journal piece indicating OOM. Failed test: https://ci.debian.net/packages/g/glibc/testing/arm64/40439311/ This one is too old, the date is not in the journal anymore. Paul Jan 03 22:53:54 ci-worker-arm64-03 kernel: dpkg-query invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0 Jan 03 22:53:54 ci-worker-arm64-03 kernel: CPU: 1 PID: 2152163 Comm: dpkg-query Tainted: GW 6.4.0-0.deb12.2-arm64 #1 Debian 6.4.4-3~bpo12+1 Jan 03 22:53:54 ci-worker-arm64-03 kernel: Hardware name: OpenStack Foundation OpenStack Nova, BIOS 0.0.0 02/06/2015 Jan 03 22:53:54 ci-worker-arm64-03 kernel: Call trace: Jan 03 22:53:54 ci-worker-arm64-03 kernel: dump_backtrace+0xa0/0x128 Jan 03 22:53:54 ci-worker-arm64-03 kernel: show_stack+0x20/0x38 Jan 03 22:53:54 ci-worker-arm64-03 kernel: dump_stack_lvl+0x48/0x60 Jan 03 22:53:54 ci-worker-arm64-03 kernel: dump_stack+0x18/0x28 Jan 03 22:53:54 ci-worker-arm64-03 kernel: dump_header+0x4c/0x218 Jan 03 22:53:54 ci-worker-arm64-03 kernel: oom_kill_process+0x148/0x308 Jan 03 22:53:54 ci-worker-arm64-03 kernel: out_of_memory+0xec/0x5a0 Jan 03 22:53:54 ci-worker-arm64-03 kernel: __alloc_pages+0xca0/0xde8 Jan 03 22:53:54 ci-worker-arm64-03 kernel: alloc_pages+0xb4/0x160 Jan 03 22:53:54 ci-worker-arm64-03 kernel: folio_alloc+0x24/0x68 Jan 03 22:53:54 ci-worker-arm64-03 kernel: filemap_alloc_folio+0x144/0x160 Jan 03 22:53:54 ci-worker-arm64-03 kernel: __filemap_get_folio+0xf0/0x2f8 Jan 03 22:53:54 ci-worker-arm64-03 kernel: filemap_fault+0x49c/0x998 Jan 03 22:53:54 ci-worker-arm64-03 kernel: __do_fault+0x44/0x230 Jan 03 22:53:54 ci-worker-arm64-03 kernel: __handle_mm_fault+0xb8c/0x1238 Jan 03 22:53:54 ci-worker-arm64-03 kernel: handle_mm_fault+0x160/0x290 Jan 03 22:53:54 ci-worker-arm64-03 kernel: do_page_fault+0x270/0x490 Jan 03 22:53:54 ci-worker-arm64-03 kernel: do_translation_fault+0x54/0x70 Jan 03 22:53:54 ci-worker-arm64-03 kernel: do_mem_abort+0x4c/0xa8 Jan 03 22:53:54 ci-worker-arm64-03 kernel: el0_ia+0x70/0x148 Jan 03 22:53:54 ci-worker-arm64-03 kernel: el0t_64_sync_handler+0xc4/0x120 Jan 03 22:53:54 ci-worker-arm64-03 kernel: el0t_64_sync+0x190/0x198 Jan 03 22:53:54 ci-worker-arm64-03 kernel: Mem-Info: Jan 03 22:53:54 ci-worker-arm64-03 kernel: active_anon:644290 inactive_anon:541258 isolated_anon:0 active_file:488 inactive_file:211 isolated_file:0 unevictable:0 dirty:10 writeback:0 slab_reclaimable:84360 slab_unreclaimable:712733 mapped:536 shmem:947 pagetables:3927 sec_pagetables:0 bounce:0 kernel_misc_reclaimable:0 free:31884 free_pcp:100 free_cma:0 Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 active_anon:2577160kB inactive_anon:2165032kB active_file:1952kB inactive_file:844kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:2144kB dirty:40kB writeback:0kB shmem:3788kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 6144kB writeback_tmp:0kB kernel_stack:4512kB pagetables:15708kB sec_pagetables:0kB all_unreclaimable? no Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 DMA free:36984kB boost:0kB min:17152kB low:21440kB high:25728kB reserved_highatomic:0KB active_anon:1498272kB inactive_anon:1194072kB active_file:792kB inactive_file:436kB unevictable:0kB writepending:4kB present:3145728kB managed:3080192kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB Jan 03 22:53:54 ci-worker-arm64-03 kernel: lowmem_reserve[]: 0 0 4929 4929 Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 Normal free:90552kB boost:0kB min:27900kB low:34872kB high:41844kB reserved_highatomic:0KB active_anon:1078488kB inactive_anon:971360kB active_file:28kB inactive_file:1176kB unevictable:0kB writepending:36kB present:5242880kB managed:5047724kB mlocked:0kB bounce:0kB free_pcp:364kB local_pcp:0kB free_cma:0kB Jan 03 22:53:54 ci-worker-arm64-03 kernel: lowmem_reserve[]: 0 0 0 0 Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 DMA: 1014*4kB (UME) 1017*8kB (UME) 304*16kB (UME) 327*32kB (UME) 95*64kB (UME) 28*128kB (UME) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 37184kB Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 Normal: 219*4kB (E) 994*8kB (UE) 1709*16kB (UE) 1672*32kB (UE) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB
Bug#1060084: [Pkg-puppet-devel] Bug#1060084: puppet-agent: Resource type 'Cron' was not found, even after puppet-module-puppetlabs-cron-core installed
Control: forcemerge 1054664 1060084 On 2024-01-06 08:55:04, Will Partain wrote: > Antoine Beaupré wrote: > >> Is there any specific reason why you feel this should be adressed in a >> different bug report than the above? > > Hi, Antoine -- stumbling into the "bug"? again, I realized it was probably > more likely a puppet agent bug, not the cron_core module. > > My understanding of the Debian bugs process is very slight. But I know it is > a wondrously good thing! Regards to all, Right, no problem! For future reference, I think in this case it would have been preferable to just reuse the existing bug report, by replying to it. So I'll be merging the two bugs, feel free to reply to any one of the two. :) a. -- May your trails be crooked, winding, lonesome, dangerous, leading to the most amazing view. May your mountains rise into and above the clouds. - Edward Abbey
Bug#1021950: Please upgrade Bazel to version 5.0.0
Package: bazel-bootstrap Version: 4.2.3+ds-9 Followup-For: Bug #1021950 Hi, Bazel 7.0 has been released. And this is set to LTS. Could you update to 7.0 [0]? Best regards, Nobuhiro [0]: https://github.com/bazelbuild/bazel/releases/tag/7.0.0
Bug#1060225: protobuf: Install proto_api.h
Source: protobuf Version: 3.21.12-8 Severity: wishlist For some reason, protobuf doesn't apparently install python/google/protobuf/proto_api.h anywhere. For example https://github.com/pybind/pybind11_protobuf uses it with an #include which it assumes to find under "python" directory after fetching it with cmake. For packaging use that won't work and it'd help to have it available in protobuf's packages. I'm not quite sure whether python3-protobuf or libprotobuf-dev would be a better choice. Probably latter.
Bug#1060220: rootskel: Can't stick to pure vga textmode any more
Samuel Thibault, le dim. 07 janv. 2024 21:24:23 +0100, a ecrit: > Samuel Thibault, le dim. 07 janv. 2024 21:14:53 +0100, a ecrit: > > https://www.debian.org/releases/stable/i386/ch05s02.en.html#idm1171 > > > > documents a way to keep the pure vga text mode, but this doesn't seem to > > be working any more: vga=normal fb=false doesn't seem to be effective > > any more, vga=normal does indeed keep the textmode vga, but then even > > with fb=false the fbcon still gets triggered. I tried to manually set > > TERM_TYPE=dumb with the same result. > > > > Any idea what nowadays could be triggering the fbcon? > > Note: this is new in bookworm, bullseye doesn't pose the problem. > > I assigned the bug to rootskel, but not much has changed for it between > the two, so probably the bug isn't there, but I don't really know where > to look at otherwise. Could it be udev? Would there be a way to disable that? Samuel
Bug#1060224: bluetoothd started segfaulting
Package: bluez Version: 5.71-1 Severity: normal On upgrade to this version, bluetoothd started segfaulting frequently: [ 59.628624] input: Avantree SP750 (AVRCP) as /devices/virtual/input/input26 [ 97.073761] bluetoothd[838]: segfault at 561314652a23 ip 56167406a375 sp 7fffb128a200 error 4 in bluetoothd[561674048000+ec000] likely on CPU 11 (core 5, socket 0) [ 97.073799] Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 20 4c 8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08 [ 219.074962] input: Avantree SP750 (AVRCP) as /devices/virtual/input/input27 [ 241.708695] bluetoothd[4477]: segfault at 55c5369dc8d4 ip 55c069877375 sp 7fff8f7198c0 error 4 in bluetoothd[55c069855000+ec000] likely on CPU 0 (core 0, socket 0) [ 241.708725] Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 20 4c 8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08 To reproduce this crash all I have to do is: 1. connect to the bluetooth device 2. use it briefly 3. stop using it and wait 5 seconds Based on the timing, the crash probably occurs when it's put into power save mode. I have downgraded to 5.70-1.1, which does not have this problem. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.9-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 bluez depends on: ii dbus [default-dbus-system-bus] 1.14.10-3+b1 ii init-system-helpers 1.66 ii kmod31-1 ii libasound2 1.2.10-3 ii libc6 2.37-13 ii libdbus-1-3 1.14.10-3+b1 ii libdw1 0.190-1+b1 ii libglib2.0-02.78.3-1 ii libreadline88.2-3 ii libudev1255.2-3 ii udev255.2-3 bluez recommends no packages. Versions of packages bluez suggests: pn pulseaudio-module-bluetooth -- Configuration Files: /etc/bluetooth/main.conf changed: [General] Experimental = true [BR] [LE] [GATT] [CSIS] [AVDTP] [Policy] AutoEnable=true [AdvMon] -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#1060223: receptor: Flaky tests TestCreatePing due to environment
Package: receptor Version: 1.4.3-3 Severity: important These tests fail depending on the environment, for example if the firewall policy is drop or reject, or perhaps depending on how localhost resolves (ipv6 or ipv4). --- FAIL: TestCreatePing (15.01s) --- PASS: TestCreatePing/NetceptorShutdown_Error (2.00s) --- FAIL: TestCreatePing/SubscribeUnreachable_Error (0.00s) --- FAIL: TestCreatePing/CreatePing_Success (0.00s) --- PASS: TestCreatePing/ListenPacket_Error (0.00s) --- FAIL: TestCreatePing/ReadFrom_Error (2.00s) --- PASS: TestCreatePing/WriteTo_Error (0.00s) --- PASS: TestCreatePing/Timeout_Error (10.00s) --- PASS: TestCreatePing/User_Cancel_Error (1.00s) I'll disable them. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (101, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 receptor depends on: ii golang-github-creack-pty-dev 1.1.21-1 ii golang-github-fortytw2-leaktest-dev 1.3.0-1.1 ii golang-github-fsnotify-fsnotify-dev 1.7.0-1 ii golang-github-ghjm-cmdline-dev0.1.2-3 ii golang-github-golang-jwt-jwt-dev 5.0.0+really4.5.0-1 ii golang-github-golang-mock-dev 1.6.0-2 ii golang-github-google-shlex-dev0.0~git20191202.e7afc7f-1 ii golang-github-gorilla-websocket-dev 1.5.1-1 ii golang-github-lucas-clemente-quic-go-dev [golang 0.38.2-1 -github-quic-go-quic-go-dev] ii golang-github-minio-highwayhash-dev 1.0.2-2 ii golang-github-pbnjay-memory-dev 0.0~git20210728.7b4eea6-2 ii golang-github-rogpeppe-go-internal-dev1.12.0-1 ii golang-github-songgao-water-dev 0.0~git20200317.2b4b6d7-1 ii golang-github-vishvananda-netlink-dev 1.1.0.125.gf243826-4 ii golang-golang-x-net-dev 1:0.19.0+dfsg-1 ii golang-gopkg-yaml.v2-dev 2.4.0-4 ii golang-k8s-api-dev0.29.0-1 ii golang-k8s-apimachinery-dev 0.29.0-1 ii golang-k8s-client-go-dev 0.29.0-1 ii libc6 2.37-13 receptor recommends no packages. receptor suggests no packages. -- Configuration Files: /etc/receptor/receptor.conf changed [not included]
Bug#1060222: aide-common: 31_aide_php-fpm defines PHPVERSION 2.2 instead of 8.2
Package: aide-common Version: 0.18.6.2.20231120-2 Severity: normal Dear Maintainer, The config file 31_aide_php-fpm defines PHPVERSION as 2.2 instead of 8.2. -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (810, 'stable-security'), (810, 'stable'), (809, 'proposed-updates'), (710, 'oldstable-security'), (710, 'oldstable'), (709, 'oldstable-proposed-updates'), (310, 'testing'), (200, 'unstable'), (160, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-16-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages aide-common depends on: ii aide0.18.6.2.20231120-2 ii debconf [debconf-2.0] 1.5.82 ii liblockfile11.17-1+b1 ii systemd [systemd-sysusers] 252.19-1~deb12u1 ii ucf 3.0043+nmu1 Versions of packages aide-common recommends: ii bsd-mailx [mailx] 8.1.2-0.20220412cvs-1 ii s-nail 14.9.24-2 ii systemd-cron [cron-daemon] 2.3.0-1~bpo12+1 aide-common suggests no packages. -- debconf information excluded
Bug#1060220: rootskel: Can't stick to pure vga textmode any more
Samuel Thibault, le dim. 07 janv. 2024 21:14:53 +0100, a ecrit: > Source: rootskel > Version: 1.136 > Severity: important > Tags: a11y > > Hello, > > https://www.debian.org/releases/stable/i386/ch05s02.en.html#idm1171 > > documents a way to keep the pure vga text mode, but this doesn't seem to > be working any more: vga=normal fb=false doesn't seem to be effective > any more, vga=normal does indeed keep the textmode vga, but then even > with fb=false the fbcon still gets triggered. I tried to manually set > TERM_TYPE=dumb with the same result. > > Any idea what nowadays could be triggering the fbcon? Note: this is new in bookworm, bullseye doesn't pose the problem. I assigned the bug to rootskel, but not much has changed for it between the two, so probably the bug isn't there, but I don't really know where to look at otherwise. Samuel
Bug#1060221: linux-image-6.5.0-5-arm64: gcc13 crashes in parallel builds; fixed with the 6.6.9 kernel
Package: src:linux Version: 6.5.13-1 Severity: normal Dear Maintainer, I am running Debian testing in a Parallels VM (6 cores, 8GB memory) running on Macbook Air M2 15" (10 cores, 24GB memory). gcc13 is sig faulting when building xfsprogs or the Linux kernel when using make -j6. Building xfsprogs using make -j2 doesn't crash. It crashes both using Debian testing or a Debian bookworm chroot. The fact that it crashes less often when the system is more lightly loaded, and the gcc crash was not deterministic; that is, if I rerun the make, gcc will crash on a *different* source file, aroused my suspicions. Hence, I decided to try installing linux-image-6.6.9-arm64 from Debian unstable. This made the problem go away. The fact that there is some kind of non-determinstic userspace program (gcc13's cc1) which is resolved when using the 6.6.9 LTS kernel may mean that there is some kind of issue with the mm subsystem under memory pressure, or with the swap codepath, etc. So this may be causing some other kinds of potential silent data corruption with 6.5.13 when running under load. (No, it's not the ext4 corruption issue, since (a) that's not applicable to 6.5.13, and (b) that corruption issue involved O_SYNC / O_DIRECT writes when extending the file, and gcc doesn't use either O_SYNC or O_DIRECT writes. This might be an issue with SQL Server, but not gcc, mysql, nor postgres.) I normally wouldn't bother filing a bug, but the Debian testing's kernel is currently being blocked by a transition, and I don't know how long it's going to take to resolve the transition issue. Also, this bug may be affecting more people than just me, so I figured it would be good to give a heads up, especially since whatever the transition bug might happen to be (I don't pretend to understand it, and I wasn't able to find any information after doing some web serches), I didn't have any problem installing a newer kernel from sid. -- Package-specific info: ** Kernel log: boot messages should be attached I don't have it handy since journald has a non-persistent boot. If you really want it, though, I can boot back to the 6.5 kernel and get it extracted out. ** Model information Parallels VM runing on a Macbook Air M2 15" ** Network interface configuration: *** /etc/network/interfaces: source /etc/network/interfaces.d/* auto lo iface lo inet loopback ** PCI devices: 00:01.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] Subsystem: Parallels, Inc. 82801I (ICH9 Family) HD Audio Controller [1ab8:0400] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:02.0 USB controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller [8086:265c] (rev 02) (prog-if 20 [EHCI]) Subsystem: Parallels, Inc. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller [1ab8:0400] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:05.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network device [1af4:1000] Subsystem: Parallels, Inc. Virtio network device [1ab8:0001] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: virtio-pci 00:09.0 Unassigned class [ff00]: Parallels, Inc. Virtual Machine Communication Interface [1ab8:4000] Subsystem: Parallels, Inc. Virtual Machine Communication Interface [1ab8:0400] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: prl_tg Kernel modules: prl_tg 00:0a.0 VGA compatible controller [0300]: Red Hat, Inc. Virtio 1.0 GPU [1af4:1050] (rev 01) (prog-if 00 [VGA controller]) Subsystem: Parallels, Inc. Virtio 1.0 GPU [1ab8:0010] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: virtio-pci ** USB devices: Bus 003 Device 003: ID 203a:fffb PARALLELS Virtual Keyboard Bus 003 Device 002: ID 203a:fffc PARALLELS Virtual Mouse Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 004: ID 203a:fffa PARALLELS Virtual Printer (snap) Bus 001 Device 003: ID
Bug#1060220: rootskel: Can't stick to pure vga textmode any more
Source: rootskel Version: 1.136 Severity: important Tags: a11y Hello, https://www.debian.org/releases/stable/i386/ch05s02.en.html#idm1171 documents a way to keep the pure vga text mode, but this doesn't seem to be working any more: vga=normal fb=false doesn't seem to be effective any more, vga=normal does indeed keep the textmode vga, but then even with fb=false the fbcon still gets triggered. I tried to manually set TERM_TYPE=dumb with the same result. Any idea what nowadays could be triggering the fbcon? Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.6.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1060205: castxml: BD-Uninstallable: castxml build-depends on missing: libclang-17-dev:mips64el
Control: block -1 by #1056116 Hi Sebastian, > castxml build-depends on missing: > - libclang-17-dev:mips64el Thanks for the heads up, I'm afraid this is a bit out of hands right now. According to bug entries #1059465 and #1056116, llvm-toolchain-16 and -17 fail to build on mips64el at the moment. Also, the llvm-toolchain-15 is not planned to ship with trixie if I trust #1058812. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `-on air: Apple Pie - Letters Of A Deadman - Part III - … signature.asc Description: PGP signature
Bug#1060217: plocate command blocks waiting io_uring operation
On Sun, Jan 07, 2024 at 08:21:35PM +0200, Manolis Stamatogiannakis wrote: > I am trying to get plocate to run on an old ARM-based NAS running Debian > bookworm. Building the database with updatedb works fine, but plocate > command itself blocks forever without giving any results back. > > I attached gdb to the process, and the source of the problem appears to > be related to the use of io_uring. > > Trying to understand what is going on, I ran plocate under strace as > root. Surprisingly, it ran without blocking. This is interesting, but fundamentally pretty impossible to debug from my side. It sounds very much like a timing-related bug, which is probably why strace affects it (everything goes much slower); another common case is that one attaches strace to a running process, which causes the io_uring syscall to return EINTR, which gets things running again. Is this reproducible every time? >* reports an error for not being able to access the database when run > under strace as user (which sounds like the expected behaviour) Yes, this is expected. > Architecture: armel (armv5tel) > Kernel: Linux 6.1.0-17-marvell (UP) Is this even supported by Debian anymore? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#1058945: python3-secretstorage: please do not depend on dbus package
Hi, On Sun, 2024-01-07 at 22:15 +0300, Dmitry Shachnev wrote: > On Sun, Jan 07, 2024 at 07:31:48PM +0100, Ansgar wrote: > > > gnome-keyring | alternatives is in Recommends, not in Depends. > > > > > > The reason for that is because someone may want to use secretstorage > > > with a different server that is not listed there, and we do not have a > > > virtual package name that any such implementation can provide (like e.g. > > > notification-daemon is provided by 14 different packages). > > > > So will you add a virtual package and a strict dependency? AFAIU it is > > about as uesless without one of these providers as it is without Dbus. > > I think you really don't want it to be a strict dependency, do you? I would prefer no such dependency, yes. I'm just wondering why dbus and the provider of the dbus interface are handled differently. > Your analogy doesn't 100% apply to Python world. In C, if you link to some > library, your application won't start when that library is not installed. > However, in Python, it's quite easy to make imports optional. And Keyring > does exactly this, "import keyring" will not fail if python3-secretstorage > is not installed. In C one can load optional plugins as well, but it is more work to implement, yes. > Similarly, I see that poetry imports keyring not on the top level, but in > the code where it's actually needed [1], and poetry will start when keyring > is not installed, so maybe poetry should Recommend python3-keyring, not > depend on it. Maybe that too, but this can get harder for users to find: assume Poetry still depends on python3-keyring, but python3-secretstorage. Then it is hard to find out that python3-secretstorage might need to be installed in order to store credentials in gnome-keyring (or others). > But anyway, if you insist that python3-secretstorage should not depend on > dbus-related packages, I can demote that to Recommends. For most users > that shouldn't make any difference because we have Recommends enabled by > default. Will that work for you? I would assume that pretty much everyone who wants to use the DBus secret store with gnome-keyring, kwallet or keepassxc has a GUI with DBus already installed. So "Suggests:" would be enough. The question of libraries depending on services comes up from time to time again, so it might be better to decide on a general policy for this. I've started a thread on -devel@ for this: https://lists.debian.org/msgid-search/da70d4ba9cae7261698718b2d50303be50d074c2.ca...@43-1.org (link should work in ~20 minutes or so). Ansgar
Bug#1060219: xvkbd: Fn keys are usually white on white & change color depending on what key is clicked.
Package: xvkbd Version: 4.1-2 Severity: normal X-Debbugs-Cc: p...@tutanota.de Dear Maintainer, * What led up to the situation? Using xvkbd * What exactly did you do (or not do) that was effective (or ineffective)? Fiddled with all the opetions under "properties," none of which made any difference. Also rebooted if that counts. * What was the outcome of this action? Unchanged. * What outcome did you expect instead? I hoped the color scheme would become stable, or at least usable. White on white is not usable. It's also an eye sore, almost literally. -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xvkbd depends on: ii libc6 2.36-9+deb12u3 ii libx11-6 2:1.8.4-2+deb12u2 ii libxaw7 2:1.0.14-1 ii libxmu6 2:1.1.3-3 ii libxt61:1.2.1-1.1 ii libxtst6 2:1.2.3-1.1 Versions of packages xvkbd recommends: ii lxterminal [x-terminal-emulator]0.4.0-2 ii rxvt-unicode [x-terminal-emulator] 9.30-2+b4 ii xterm [x-terminal-emulator] 379-1 ii zutty [x-terminal-emulator] 0.14.0.20230218+dfsg1-1 Versions of packages xvkbd suggests: ii wamerican 2020.12.07-2 ii wbritish 2020.12.07-2 -- debconf-show failed
Bug#1058945: python3-secretstorage: please do not depend on dbus package
On Sun, Jan 07, 2024 at 07:31:48PM +0100, Ansgar wrote: > > gnome-keyring | alternatives is in Recommends, not in Depends. > > > > The reason for that is because someone may want to use secretstorage > > with a different server that is not listed there, and we do not have a > > virtual package name that any such implementation can provide (like e.g. > > notification-daemon is provided by 14 different packages). > > So will you add a virtual package and a strict dependency? AFAIU it is > about as uesless without one of these providers as it is without Dbus. I think you really don't want it to be a strict dependency, do you? > > I can suggest two solutions: > > > > 1. Replace python3-keyring → python3-secretstorage Depends with Recommends. > > 2. Keep it Depends, but add some alternatives, e.g. python3-secretstorage > > | python3-keyrings.alt. > > > > Will any of that work for you? > > I think that is still fundamentally wrong. > > A program X linking a library (classic C libraries or python3-* stuff; > implementation doesn't matter) will result in a relation "X depends > libY". > > But that doesn't say anything about if users actually will use "libY". > > For example, consider libY as a library speaking to Pulseaudio, libZ a > library speaking to jack2d. The application X now links libY and libZ > as it has support for audio output via libY or libZ; it can also output > audio via ALSA. > > Installing X thus installs libY and libZ. > > Clearly libY is useless without PA and libZ useless without Jack in the > same way as python3-keyring is useless without Dbus + Secret Service > backend. > > Should libY thus depend on Dbus + Pulseaudio and libZ depend on jackd? > That would result in a user wanting to install X having to install > Dbus, Pulseaudio and Jack. That is in particular two audio servers > that will then be enabled by default. > > As Debian tries to build packages with as much optional stuff as > possible enabled, this would happen very often (we have more sound > servers...). > > Is that useful? I think not and think libraries *must not* depend on > services for that reason. If soemthing explicitly depends on a service, > it should be an application, not some library. Your analogy doesn't 100% apply to Python world. In C, if you link to some library, your application won't start when that library is not installed. However, in Python, it's quite easy to make imports optional. And Keyring does exactly this, "import keyring" will not fail if python3-secretstorage is not installed. So, if some users of python3-keyring don't need python3-secretstorage, we can make it Recommends, not Depends. Similarly, I see that poetry imports keyring not on the top level, but in the code where it's actually needed [1], and poetry will start when keyring is not installed, so maybe poetry should Recommend python3-keyring, not depend on it. But anyway, if you insist that python3-secretstorage should not depend on dbus-related packages, I can demote that to Recommends. For most users that shouldn't make any difference because we have Recommends enabled by default. Will that work for you? [1]: https://sources.debian.org/src/poetry/1.7.1%2Bdfsg-1/src/poetry/utils/password_manager.py/#L48 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060218: xmobar: cannot run with Wireless plugin
Package: xmobar Version: 0.46-2 Severity: normal Dear Maintainer, After removing libiw-dev dependency (#1058738) xmobar fails to run with Wireless plugin in the config file. Best regards, Dominik -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.9-amd64 (SMP w/12 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 xmobar depends on: ii libasound2 1.2.10-3 ii libc62.37-13 ii libcairo21.18.0-1 ii libffi8 3.4.4-2 ii libglib2.0-0 2.78.3-1 ii libgmp10 2:6.3.0+dfsg-2 ii libharfbuzz0b8.0.1-1 ii libpango-1.0-0 1.51.0+ds-3 ii libpangocairo-1.0-0 1.51.0+ds-3 ii libpng16-16 1.6.40-3 ii libx11-6 2:1.8.7-1 ii libxext6 2:1.3.4-1+b1 ii libxft2 2.3.6-1 ii libxinerama1 2:1.1.4-3 ii libxpm4 1:3.5.17-1 ii libxrandr2 2:1.5.2-2+b1 ii libxrender1 1:0.9.10-1.1 ii libxss1 1:1.2.3-1 ii zlib1g 1:1.3.dfsg-3 xmobar recommends no packages. Versions of packages xmobar suggests: ii xmonad 0.17.2-1+b1 -- no debconf information
Bug#1058945: python3-secretstorage: please do not depend on dbus package
On Sun, 2024-01-07 at 18:23 +0300, Dmitry Shachnev wrote: > On Sat, Jan 06, 2024 at 07:50:47PM +0100, Ansgar wrote: > > Now try not to install an init system, dbus, ... in a application > > container wanting to use python3-poetry to install some Python > > application. > > > > And this still doesn't ensure that: > > 1. dbus is actually running in the context where python3-secretstorage is > > used, > > 2. the Dbus interface python3-secretstorage wants to talk to is actually > > provided by a service > > > > (For 2. it doesn't even have a Depends: gnome-keyring | alternatives > > either which is inconsistent with the dependency on Dbus...) > > gnome-keyring | alternatives is in Recommends, not in Depends. > > The reason for that is because someone may want to use secretstorage > with a different server that is not listed there, and we do not have a > virtual package name that any such implementation can provide (like e.g. > notification-daemon is provided by 14 different packages). So will you add a virtual package and a strict dependency? AFAIU it is about as uesless without one of these providers as it is without Dbus. > > Also it's unknown whether that is actually useful or not (as python3- > > secretstorage is just a library that could not be relevant at all as > > the application's user might not actually want to manage secrets via > > keepassxc). > > > > It seems excessive to *always* require all of this to be installed for > > *any* use of python3-poetry (which can optionally use python3- > > secretstorage if that is even required). bash doesn't depend on gnome- > > terminal either just because one needs some terminal to run it in ;-) > > I think python3-secretstorage is completely useless without D-Bus. I think you miss my point: The dependency currently says "python3-poetry is useless without Dbus". > So maybe this dependency chain should be cut at a higher level, e.g. > between python3-keyring and python3-secretstorage. > > I am also the uploader of python3-keyring, so we can discuss it here. > > I can suggest two solutions: > > 1. Replace python3-keyring → python3-secretstorage Depends with Recommends. > 2. Keep it Depends, but add some alternatives, e.g. python3-secretstorage > | python3-keyrings.alt. > > Will any of that work for you? I think that is still fundamentally wrong. A program X linking a library (classic C libraries or python3-* stuff; implementation doesn't matter) will result in a relation "X depends libY". But that doesn't say anything about if users actually will use "libY". For example, consider libY as a library speaking to Pulseaudio, libZ a library speaking to jack2d. The application X now links libY and libZ as it has support for audio output via libY or libZ; it can also output audio via ALSA. Installing X thus installs libY and libZ. Clearly libY is useless without PA and libZ useless without Jack in the same way as python3-keyring is useless without Dbus + Secret Service backend. Should libY thus depend on Dbus + Pulseaudio and libZ depend on jackd? That would result in a user wanting to install X having to install Dbus, Pulseaudio and Jack. That is in particular two audio servers that will then be enabled by default. As Debian tries to build packages with as much optional stuff as possible enabled, this would happen very often (we have more sound servers...). Is that useful? I think not and think libraries *must not* depend on services for that reason. If soemthing explicitly depends on a service, it should be an application, not some library. Ansgar
Bug#1060207: [Debian-med-packaging] Bug#1060207: ncbi-acc-download: please remove extraneous dependency on python3-mock
Hi Alexandre, Alexandre Detiste, on 2024-01-07: > For some reason Salsa doesn't let me push to this one reposotiry. The default branch is protected by default for Developers (in Salsa vernacular) and lower, so bumped you to Maintainer (still in Salsa vernacular). You should be able to push fixes now. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `-on air: Klaus Schulze - Nowhere - Now Here signature.asc Description: PGP signature
Bug#1060217: plocate command blocks waiting io_uring operation
Package: plocate Version: 1.1.18-1 Severity: important Tags: upstream X-Debbugs-Cc: msta...@gmail.com Dear Maintainer, I am trying to get plocate to run on an old ARM-based NAS running Debian bookworm. Building the database with updatedb works fine, but plocate command itself blocks forever without giving any results back. I attached gdb to the process, and the source of the problem appears to be related to the use of io_uring. Trying to understand what is going on, I ran plocate under strace as root. Surprisingly, it ran without blocking. The same behaviour was observed after self-compiling the latest plocate (v1.1.21), which is why I am also tagging the issue for the upstream. More details on the observed behaviour of plocate: * blocks waiting some io_uring operation when run directly as root/user * does not not block when run under strace as root * reports an error for not being able to access the database when run under strace as user (which sounds like the expected behaviour) I recompiled the latest plocate with io_uring support disabled in meson.build, and the program worked fine. Operation may be slower this way, but at least it works. -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 6.1.0-17-marvell (UP) Locale: LANG=C.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plocate depends on: ii adduser 3.134 ii libatomic1 12.2.0-14 ii libc6 2.36-9+deb12u3 ii libgcc-s1 12.2.0-14 ii libstdc++6 12.2.0-14 ii liburing2 2.3-3 ii libzstd11.5.4+dfsg2-5 plocate recommends no packages. Versions of packages plocate suggests: ii powermgmt-base 1.37 ii systemd-sysv252.19-1~deb12u1
Bug#1060216: ITP: python-django-solo -- Singleton objects helper for Django
Package: wnpp Severity: wishlist Owner: Jérémy Lal X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team * Package name: python-django-solo Version : 2.1.0 Upstream Contact: https://github.com/lazybird/django-solo/issues * URL : https://github.com/lazybird/django-solo * License : CC-BY-3.0 Programming Lang: Python Description : Singleton objects helper for Django Solo helps to enforce instantiating only one instance of a model in Django. Singletons are database tables with only one row. . Django is a high-level Python web development framework. This package will be maintained by python team, is used by awx. Also seems to be a good django module.
Bug#1060215: gweled: please drop dpkg-statoverride call
Package: gweled Version: 1.0~alpha-1 Hi, gweled's postinst calls dpkg-statoverride, to remove an old statoverride. This was added in 2018, so all systems should already have this cleanup done. Please drop this dpkg-statoverride fragment: # The package used to install an override if [ "$(sudo dpkg-statoverride --list /usr/games/gweled)" = "root games 2755 /usr/games/gweled" ]; then dpkg-statoverride --remove /usr/games/gweled fi I'll note that at the time of writing, this means you can drop the entire postinst. Thanks, Chris
Bug#1060005: cifs-utils: Copy file with cp, hangs with a kernel NULL pointer dereference.
Package: src:linux Version: 6.1.69-1 Followup-For: Bug #1060005 Dear Maintainer, I'm running Debian 12 6.1.0-17, having recently upgraded from 6.1.0-16. On my machine, running cp on a file on my NAS causes the computer to hang for a few seconds before reporting "Killed". The cifs share becomes non-responsive afterward, requiring a reboot. I can reproduce it every time by choosing specific files. The problem does not occur if I boot with kernel 6.1.0-16 or earlier. Changing the SMB version does not appear to make a difference. I tried SMB 2.1, 3.0, 3.1, and 3.1.1. Other command line file operations cause similar issues. Running rm on the NAS sometimes returns without error, but without removing the file. Other times, rm hangs and the NAS becomes non-responsive. Once the NAS is non-responsive, umount reports it as busy unless the -l flag is used. In a GUI file manager like Konquerer or Dolphin, attempting to copy causes the file manager to hang. Rebooting requires Debian to disconnect the non- responsive NAS and kill the still-pending cp or rm file process underlying the GUI command. Using a GUI application to perform "Save As" appears to be fine. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: ASUS product_name: System Product Name product_version: System Version chassis_vendor: Default string chassis_version: Default string bios_vendor: American Megatrends Inc. bios_version: 1303 board_vendor: ASUSTeK COMPUTER INC. board_name: ROG MAXIMUS Z790 HERO board_version: Rev 1.xx ** Network interface configuration: *** /etc/network/interfaces: source /etc/network/interfaces.d/* auto lo iface lo inet loopback ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:a700] (rev 01) Subsystem: ASUSTeK Computer Inc. Device [1043:8882] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:06.0 PCI bridge [0604]: Intel Corporation Raptor Lake PCIe 4.0 Graphics Port [8086:a74d] (rev 01) (prog-if 00 [Normal decode]) Subsystem: ASUSTeK Computer Inc. Raptor Lake PCIe 4.0 Graphics Port [1043:8882] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:0a.0 Signal processing controller [1180]: Intel Corporation Raptor Lake Crashlog and Telemetry [8086:a77d] (rev 01) Subsystem: ASUSTeK Computer Inc. Raptor Lake Crashlog and Telemetry [1043:8882] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: intel_vsec Kernel modules: intel_vsec 00:0e.0 RAID bus controller [0104]: Intel Corporation Volume Management Device NVMe RAID Controller Intel Corporation [8086:a77f] DeviceName: RAID Controller Subsystem: ASUSTeK Computer Inc. Volume Management Device NVMe RAID Controller Intel Corporation [1043:8882] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: vmd Kernel modules: vmd 00:14.0 USB controller [0c03]: Intel Corporation Device [8086:7a60] (rev 11) (prog-if 30 [XHCI]) DeviceName: USB Controller Subsystem: ASUSTeK Computer Inc. Device [1043:8882] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: mei_me, xhci_pci 00:14.2 RAM memory [0500]: Intel Corporation Device [8086:7a27] (rev 11) Subsystem: ASUSTeK Computer Inc. Device [1043:8882] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:14.3 Network controller [0280]: Intel Corporation Device [8086:7a70] (rev 11) Subsystem: Intel Corporation Device [8086:0094] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: iwlwifi Kernel modules: iwlwifi 00:15.0 Serial bus controller
Bug#1059919: DEP17: move ifupdown files to /usr
Hi!
On Wed, 2024-01-03 at 16:56:36 +0100, Helmut Grohne wrote:
> Source: ifupdown
> Version: 0.8.41
> Tags: patch
> User: helm...@debian.org
> Usertags: dep17m2
> ifupdown still is part of the debootstrap package set. I know you want
> to change this, but since it still is, it should be converted for the
> /usr-move (DEP17) sooner rather than later. I'm attaching a patch and
> note that it wasn't entirely trivial. I expect that dumat will not moan
> about it in any way, but giving it some project exposure in experimental
> for volunteers to test might not be the worst of ideas. As with similar
> patches, this should not be uploaded to bookworm-backports, so you may
> want to use dh_movetousr instead.
The provided patch seems to be missing canonicalization for the lib/
scripts from `inet6.defn` which will break downstreams of this project
that are not aliasing directories, and in Debian would fail to be located
if a user reading the code passed them to «dpkg -S» for example.
I had a patch locally (yet untested, but I'm happy to do that) to make
the program accesses relative, which should increase portability and
make these more independent of the system filesystem layout. For the
programs and lib/ scripts owned by this project though this seems
unnecessary as the destination is controlled by the build system
machinery, so those could perhaps be replaced at build/install time to
make them coherent, but that seemed like more work. :) But I'm happy to
switch to that approach if you'd prefer. Alternatively they could simply
be hardcoded to the new locations.
The original patch in this bug report could then perhaps be adapted on
top of the one I'm attaching here (or a variation of it). Otherwise I
can provide parts of it independently on top of the original patch, as
a MR or similar.
Thanks,
Guillem
From 6044af67053f8aa9ebf4e8aa3d6b9ce1c640212e Mon Sep 17 00:00:00 2001
From: Guillem Jover
Date: Sun, 3 Dec 2023 02:51:43 +0100
Subject: [PATCH] Use relative names when executing programs
This switches program invocations to use relative names, so that we are
then not concerned about the filesystem layout of the system we are
installing into.
While for programs we ship and install we will know the end destination
and could simply replace that at build or install time, that seemed more
effort than simply making all usage relative.
---
Makefile| 8 +---
debian/ifupdown-hotplug | 2 +-
examples/network-interfaces | 5 +++--
examples/pcmcia-compat.sh | 4 +++-
execute.c | 2 +-
inet6.defn | 6 +++---
6 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/Makefile b/Makefile
index 0ce2fa3..85c887e 100644
--- a/Makefile
+++ b/Makefile
@@ -3,9 +3,11 @@ CFLAGS ?= -Wall -W -Wno-unused-parameter -g -O2
ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
BASEDIR ?= $(DESTDIR)
+PKGLIBDIR ?= /lib/ifupdown
CFLAGS += -std=c99 -D_DEFAULT_SOURCE
CFLAGS += -D'IFUPDOWN_VERSION="$(VERSION)"'
+CFLAGS += -D'PKGLIBDIR="$(PKGLIBDIR)"'
DEFNFILES := inet.defn ipx.defn inet6.defn can.defn
@@ -26,9 +28,9 @@ install :
install -m 0755 ifup ${BASEDIR}/sbin
ln -s /sbin/ifup ${BASEDIR}/sbin/ifdown
ln -s /sbin/ifup ${BASEDIR}/sbin/ifquery
- install -D -m 0755 settle-dad.sh $(BASEDIR)/lib/ifupdown/settle-dad.sh
- install -D -m 0755 wait-for-ll6.sh $(BASEDIR)/lib/ifupdown/wait-for-ll6.sh
- install -D -m 0755 wait-online.sh $(BASEDIR)/lib/ifupdown/wait-online.sh
+ install -D -m 0755 settle-dad.sh $(BASEDIR)$(PKGLIBDIR)/settle-dad.sh
+ install -D -m 0755 wait-for-ll6.sh $(BASEDIR)$(PKGLIBDIR)/wait-for-ll6.sh
+ install -D -m 0755 wait-online.sh $(BASEDIR)$(PKGLIBDIR)/wait-online.sh
clean :
rm -f *.o $(patsubst %.defn,%.c,$(DEFNFILES)) *~
diff --git a/debian/ifupdown-hotplug b/debian/ifupdown-hotplug
index 6e5f6c5..f53b87b 100755
--- a/debian/ifupdown-hotplug
+++ b/debian/ifupdown-hotplug
@@ -1,6 +1,6 @@
#!/bin/sh -e
#
-# run /sbin/{ifup,ifdown} with the --allow=hotplug option.
+# run {ifup,ifdown} with the --allow=hotplug option.
#
PATH='/sbin:/bin:/usr/sbin:/usr/bin'
diff --git a/examples/network-interfaces b/examples/network-interfaces
index d8bba2b..3dd1d7e 100644
--- a/examples/network-interfaces
+++ b/examples/network-interfaces
@@ -119,14 +119,15 @@
# Note, this won't work unless you specifically change the file
# /etc/pcmcia/network to look more like:
#
+# PATH="$PATH:/sbin:/usr/sbin"
# if [ -r ./shared ] ; then . ./shared ; else . /etc/pcmcia/shared ; fi
# get_info $DEVICE
# case "$ACTION" in
# 'start')
-# /sbin/ifup $DEVICE
+# ifup $DEVICE
# ;;
# 'stop')
-# /sbin/ifdown $DEVICE
+# ifdown $DEVICE
# ;;
# esac
# exit 0
diff --git a/examples/pcmcia-compat.sh b/examples/pcmcia-compat.sh
index 4b31fdb..a45a236 100644
--- a/examples/pcmcia-compat.sh
+++ b/examples/pcmcia-compat.sh
@@ -1,5 +1,7 @@
#!/bin/sh
Bug#1060214: mirror listing update for repository.su
Package: mirrors Severity: minor User: mirr...@packages.debian.org Usertags: mirror-list Submission-Type: update Site: repository.su Archive-architecture: amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: repository.su Country: RU Russian Federation Location: Nizhny Novgorod Sponsor: Dmitry Shishkin https://dmitry.sh Comment: This address is a replacement for the existing mirror mirror.surf Trace Url: http://repository.su/debian/project/trace/ Trace Url: http://repository.su/debian/project/trace/ftp-master.debian.org Trace Url: http://repository.su/debian/project/trace/repository.su
Bug#1060213: puredata-import: This Pd object is deprecated and superseeded
Package: puredata-import Severity: normal X-Debbugs-Cc: peterpar...@fastmail.com Dear Maintainer, the [import] object is a specific feature of the old pd-extended distribution. The object has by now become redundant as there is [declare]. See the discussion at https://lists.puredata.info/pipermail/pd-list//2024-01/132865.html -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-17-rt-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages puredata-import depends on: ii libc6 2.36-9+deb12u3 ii puredata 0.54.1+ds-2~bpo12+1 ii puredata-core 0.54.1+ds-2~bpo12+1 Versions of packages puredata-import recommends: pn pd-libdir puredata-import suggests no packages.
Bug#1060212: pd-pmpd: Update to current version 0.12 and remove recommendation of package puredata-import
Package: pd-pmpd Version: 0.9-7 Severity: normal X-Debbugs-Cc: peterpar...@fastmail.com Dear Maintainer, * What led up to the situation? The current version of the pd-pmpd package on Debian stable is 0.9-7 while the upstream software is already at 0.12. pd-pmpd furthermore recommends puredata-import, which is deprectated, see discussion at https://lists.puredata.info/pipermail/pd-list//2024-01/132865.html -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-17-rt-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages pd-pmpd depends on: ii libc6 2.36-9+deb12u3 pn pd-libdir ii puredata-core [pd] 0.54.1+ds-2~bpo12+1 Versions of packages pd-pmpd recommends: pn pd-import pd-pmpd suggests no packages.
Bug#1060202: glibc - autopkgtest flacky on arm64
Hi, On 2024-01-07 13:56, Bastian Blank wrote: > Package: glibc > Version: 2.37-13 > Severity: important > > Currently the autopkgtest on arm64 fails sometimes. > > Timeout while building: > https://ci.debian.net/packages/g/glibc/unstable/arm64/41516611/ There are indeed many failures with cc1 getting killed, it seems that it started around 2024-01-02. I haven't spotted any change to the toolchain nor kernel version. I am not able to reproduce the issue, so it is very likely linked to debci. Would it be possible to now why cc1 get killed? OOM? timeout? > Failed test: > https://ci.debian.net/packages/g/glibc/testing/arm64/40439311/ This is likely due to a too loaded host. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1060170: ITP: sirit -- library for runtime SPIR-V assembly
Sending this message to the bug that I mistakenly sent to Andreas Pappacoda alone. Dear Andrea, Thank you for the info. I did wonder what that was about regarding yuzu and sirit. I won't proceed further with this unless things change upstream. Regards, David
Bug#1060201: qa.debian.org: [udd] carnivore_emails is lacking lots of entries
Am Sun, Jan 07, 2024 at 05:58:36PM +0100 schrieb Lucas Nussbaum: > > See https://salsa.debian.org/qa/udd/-/blob/master/udd/carnivore_gatherer.py. Found this meanwhile. > > This statement could be easily turned into injects and would be a first > > approach to enhance > > the carnivore_emails table with more ids. > > > > If you give some green light I could create such a statement and maybe more > > enhancements > > by looking into more tables. > > Please don't: the correct way to fix that is to improve the source data > (in quantz:/org/qa.debian.org/carnivore) I have not found this code in Salsa. Is it true that the Python2 code I can find at quantz:/org/qa.debian.org/carnivore is the code source of carnivore? Kind regards Andreas. -- http://fam-tille.de
Bug#915583: about html_static_path
Hello, On Fri 29 Dec 2023 at 07:08am +01, Stéphane Blondon wrote: > Yes, html_static_path must be set but it's already the case in conf.py.in: > https://sources.debian.org/src/debian-policy/4.6.2.0/policy/conf.py.in/#L105 > > I guess conf.py is generated from conf.py.in so we only need to keep > the current setup. That line is commented out, though. Are you saying it takes on its default value in that case? -- Sean Whitton signature.asc Description: PGP signature
Bug#1060201: qa.debian.org: [udd] carnivore_emails is lacking lots of entries
Hi, On 07/01/24 at 14:21 +0100, Andreas Tille wrote: > > I tried to analyse closed bugs using done_email via carnivore_emails but > > realised > > that this table is lacking lots of entries where I could easily add several > > from > > my own memory: > > [...] > > > I wonder how the carnivore_* tables are filled and whether you want me > > to draft some INSERT statements filling up the most relevant emails > > where I would volunteer to sort the according IDs. See https://salsa.debian.org/qa/udd/-/blob/master/udd/carnivore_gatherer.py. carnivore is a service managed by the QA team (or the MIA team?). UDD just imports what is being produced in quantz:/org/qa.debian.org/carnivore (see quantz:/org/qa.debian.org/carnivore/report in particular) > This statement could be easily turned into injects and would be a first > approach to enhance > the carnivore_emails table with more ids. > > If you give some green light I could create such a statement and maybe more > enhancements > by looking into more tables. Please don't: the correct way to fix that is to improve the source data (in quantz:/org/qa.debian.org/carnivore) Lucas
Bug#1060211: libncurses-dev: ncurses6-config manpage references curses(3X)
Package: libncurses-dev Version: 6.4+20231209-1 Severity: minor The ncurses6-config manpage references curses(3X) rather than ncurses(3NCURSES) as it should. , | $ man ncursesw6-config | grep -A1 "SEE ALSO" | SEE ALSO |ncurses(3NCURSES) | $ man ncurses6-config | grep -A1 "SEE ALSO" | SEE ALSO |curses(3X) ` The reason is that ncurses6-config.1 is installed directly from the build tree via debian/libncurses-dev.manpages, while ncursesw6-config.1 has been changed by "make install". We have been doing this for many years, it goes all the way back to version 5.7+20100313-1. Compare commit c8d4cb3d2f99 where this scheme was introduced: , | Author: Sven Joachim | Date: Sun Mar 14 08:36:49 2010 +0100 | | Install ncursesw5-config manpage | | Since we're calling "make install.libs" rather than "make install" in | the obj-wide directory, ncursesw5-config.1 does not get installed into | debian/tmp. So we let dh_installman do the job. `
Bug#1002876: darktable: embeds libraw
Package: darktable Version: 4.6.0-1 Followup-For: Bug #1002876 Hi David, the attached patch removes src/external/LibRaw and builds the package using the system libraw. Regards, Tino -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.1 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages darktable depends on: ii libavif161.0.3-1 ii libc62.37-7 ii libcairo21.16.0-7 ii libcolord-gtk1 0.3.0-4 ii libcolord2 1.4.6-2.2 ii libcups2 2.4.2-5 ii libcurl3-gnutls 8.2.1-2 ii libexiv2-27 0.27.6-1 ii libgcc-s113.2.0-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.77.3-1 ii libgomp1 13.2.0-3 ii libgphoto2-6 2.5.30-1 ii libgphoto2-port122.5.30-1 ii libgraphicsmagick-q16-3 1.4+really1.3.41-1 ii libgtk-3-0 3.24.38-4 ii libheif1 1.17.1-1+b1 ii libicu72 72.1-3 ii libimath-3-1-29 3.1.9-3 ii libjpeg62-turbo 1:2.1.5-2 ii libjson-glib-1.0-0 1.6.6-1 ii libjxl0.70.7.0-10 ii liblcms2-2 2.14-2 ii liblensfun1 0.3.4-1 ii liblua5.4-0 5.4.6-1 ii libopenexr-3-1-303.1.5-5.1 ii libopenjp2-7 2.5.0-2 ii libosmgpsmap-1.0-1 1.2.0-2 ii libpango-1.0-0 1.51.0+ds-2 ii libpangocairo-1.0-0 1.51.0+ds-2 ii libpng16-16 1.6.40-1 ii libportmidi0 1:217-6.1 ii libpugixml1v51.13-0.2 ii libraw23 0.21.1-7 ii librsvg2-2 2.54.7+dfsg-2 ii libsdl2-2.0-02.28.3+dfsg-1 ii libsecret-1-00.21.0-1 ii libsqlite3-0 3.43.0-1 ii libstdc++6 13.2.0-3 ii libtiff6 4.5.1+git230720-1 ii libwebp7 1.3.2-0.3 ii libwebpmux3 1.3.2-0.3 ii libx11-6 2:1.8.6-1 ii libxml2 2.9.14+dfsg-1.3 ii libxrandr2 2:1.5.2-2+b1 ii zlib1g 1:1.2.13.dfsg-3 darktable recommends no packages. darktable suggests no packages. -- no debconf information diff --git a/debian/clean b/debian/clean index 1293eb533..279b62423 100644 --- a/debian/clean +++ b/debian/clean @@ -2,3 +2,4 @@ doc/usermanual/profiled_final.fo doc/usermanual/profiled_final.xml doc/usermanual/usermanual.pdf src/external/lua/ +src/external/LibRaw/ diff --git a/debian/control b/debian/control index 9d8ca2306..8f2b9d266 100644 --- a/debian/control +++ b/debian/control @@ -31,6 +31,7 @@ Build-Depends: cmake, libportmidi-dev, libpugixml-dev, libsdl2-dev, + libraw-dev, librsvg2-dev, libsecret-1-dev, libsoup2.4-dev, diff --git a/debian/rules b/debian/rules index 24268394a..35abb0e1a 100755 --- a/debian/rules +++ b/debian/rules @@ -20,7 +20,11 @@ endif dh $@ override_dh_auto_configure: cmake/version.cmake - dh_auto_configure -- -DBINARY_PACKAGE_BUILD=1 -DCMAKE_BUILD_TYPE=Release -DRAWSPEED_ENABLE_LTO=ON + dh_auto_configure -- \ + -DBINARY_PACKAGE_BUILD=1 \ + -DCMAKE_BUILD_TYPE=Release \ + -DRAWSPEED_ENABLE_LTO=ON \ + -DDONT_USE_INTERNAL_LIBRAW=ON describe-current-version: git describe --tags upstream | sed 's,^release-,,;s,-,+,;s,-,~,;'
Bug#1052800: parso: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Control: forwarded -1 https://github.com/davidhalter/parso/issues/222
thanks
Dear Maintainer,
After adding:
export PYBUILD_BEFORE_TEST=cp conftest.py {build_dir}
in debian/rules, tests pass with Python 3.11 but still fail with
Python 3.12.
I've opened an issue upstream.
...
make[1]: Leaving directory '/build/parso-0.8.3'
dh_auto_test -O--buildsystem=pybuild
I: pybuild pybuild:310: cp conftest.py
/build/parso-0.8.3/.pybuild/cpython3_3.12_parso/build
I: pybuild base:305: cd /build/parso-0.8.3/.pybuild/cpython3_3.12_parso/build;
python3.12 -m pytest test
test
session starts
platform linux -- Python 3.12.1, pytest-7.4.4, pluggy-1.3.0
rootdir: /build/parso-0.8.3/.pybuild/cpython3_3.12_parso/build
configfile: pytest.ini
collected 1348 items
test/test_cache.py .
[ 0%]
test/test_diff_parser.py
..
[ 6%]
test/test_dump_tree.py ..
[ 7%]
test/test_error_recovery.py .
[ 8%]
test/test_file_python_errors.py .
[ 8%]
test/test_fstring.py
.
[ 13%]
test/test_get_code.py .
[ 14%]
test/test_grammar.py .
[ 14%]
test/test_load_grammar.py ...
[ 15%]
test/test_normalizer_issues_files.py .
[ 17%]
test/test_old_fast_parser.py ...
[ 19%]
test/test_param_splitting.py ...
[ 19%]
test/test_parser.py
.
[ 29%]
.
[ 30%]
test/test_parser_tree.py
...
[ 35%]
test/test_pep8.py ...
[ 36%]
test/test_pgen2.py
..
[ 45%]
.
[ 56%]
test/test_prefix.py ..
[ 57%]
test/test_python_errors.py
...FF.
[ 66%]
FF..FFF.F.F..
[ 78%]
.
[ 87%]
test/test_tokenize.py
...
[ 97%]
.
[ 97%]
test/test_utils.py ...
[100%]
Bug#1032495: I think this is still relevant
Hi, I hope I am not misunderstanding this, but I think I've got the same problem with [2949072.463008] audit: type=1400 audit(1704633046.887:50): apparmor="DENIED" operation="open" profile="kea-dhcp4" name="/run/kea/kea-dhcp4.kea-dhcp4.pid" pid=3589658 comm="kea-dhcp4" requested_mask="r" denied_mask="r" fsuid=124 ouid=124 ii kea-dhcp4-server 2.2.0-6 arm64IPv4 DHCP server /ralph
Bug#1060210: ITP: python-djangorestframework-yaml -- YAML parser and renderer for Django REST Framework
Package: wnpp Severity: wishlist Owner: Jérémy Lal X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team * Package name: python-djangorestframework-yaml Version : 3.0.1 Upstream Contact: José Padilla , Xavier Francisco * URL : https://github.com/Qu4tro/drf-yaml * License : BSD-3-clause Programming Lang: Python Description : YAML parser and renderer for Django REST Framework This library exports a parser class and a renderer for the Django REST Framework, allowing YAML parsing et serialization. . Django REST framework is a powerful and flexible toolkit for building Web APIs. This package is maintained in python team. It is a dependency of awx, and might also be useful for django rest framework users. I'm packaging the fork under the name of the original, because the fork only did maintenance, and the original has been inactive for four years.
Bug#1060192: tracker.debian.org: SSL connection extremely slow and sometimes timing out
Hello Raphael, Am Sun, Jan 07, 2024 at 02:23:02PM +0100 schrieb Raphael Hertzog: > On Sun, 07 Jan 2024, Helge Kreutzmann wrote: > > Package: tracker.debian.org > > Severity: important > > > > Yesterday and today connections to packages.debian.org is *extremely* > > packages.debian.org is entirely unrelated to tracker.debian.org. It's > managed by the web team AFAIK. Thanks for clarification, I wasn't aware of this. > That said if the issue was at the TLS connection level, it's likely > the DSA team that can help... but since the issue is gone, I wonder > whether we shouldn't just close the bug, in particular since the DSA > team doesn't use the bug tracker. Well, it happend yesterday, and today again. But since they don't use the BTS, the bug could be closed. How should I properly report this if/once it appears again? Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#1060209: libopenzwave1.6 install hundreds of data files and images in /etc
Package: libopenzwave1.6 Version: 1.6.1914+ds-1 Severity: minor libopenzwave1.6 currently installs 1489 in /etc, including 635 PNG images, 9 JPEG images, and 1 Zip file. These files are obviously not conffiles but are treated as such. Could they be moved under /usr, for example under /usr/share/openzwave? Regards, -- Gioele Barabucci
Bug#986971: Still doesn't work
Dear Erik,
I just checked whether this makes a difference, but sendxmpp still fails
here:
```
date|sendxmpp -d -t mar...@mdosch.de
sendxmpp: config: 'password' => 'REDACTED'
sendxmpp: config: 'jserver' => 'mdosch.de'
sendxmpp: config: 'username' => 'schlepptop'
XML::Stream: new: hostname = (schlepptop)
XML::Stream: SetCallBacks: tag(node) func(CODE(0x558378f5c220))
XMPP::Conn: xmppCallbackInit: start
XMPP::Conn: SetCallBacks: tag(message) func(CODE(0x558378f5c310))
XMPP::Conn: SetCallBacks: tag(presence) func(CODE(0x558379ebb4c8))
XMPP::Conn: SetCallBacks: tag(iq) func(CODE(0x558378f5c688))
XMPP::Conn: SetPresenceCallBacks: type(subscribe) func(CODE(0x558379ebb408))
XMPP::Conn: SetPresenceCallBacks: type(unsubscribe) func(CODE(0x558379f0dc58))
XMPP::Conn: SetPresenceCallBacks: type(subscribed) func(CODE(0x558379eb1d30))
XMPP::Conn: SetPresenceCallBacks: type(unsubscribed) func(CODE(0x558378f5c4f0))
XMPP::Conn: SetDirectXPathCallBacks:
xpath(/[@xmlns="urn:ietf:params:xml:ns:xmpp-tls"]) func(CODE(0x558379ebbeb8))
XMPP::Conn: SetDirectXPathCallBacks:
xpath(/[@xmlns="urn:ietf:params:xml:ns:xmpp-sasl"]) func(CODE(0x558379ebb618))
XMPP::Conn: xmppCallbackInit: stop
sendxmpp: ssl_verify: 1
sendxmpp: tls_ca_path:
XMPP::Conn: Connect: host(mdosch.de:5222) namespace(jabber:client)
XMPP::Conn: Connect: timeout(10)
XML::Stream: Connect: type(tcpip)
XML::Stream: Connect: Got a connection
XML::Stream: Send: ()
XML::Stream: Read: buff(262144)
XMPP::Conn: Connect: connection made
XML::Stream: SetCallBacks: tag(node) func(CODE(0x558379ebb600))
XML::Stream: Send: ()
XML::Stream: Read: buff()
XML::Stream: TLSClientProceed: Convert normal socket to SSL
XML::Stream: TLSClientProceed: sock(IO::Socket::INET=GLOB(0x558379f1d410))
XML::Stream: LoadSSL: Load the IO::Socket::SSL module
XML::Stream: LoadSSL: Success
XML::Stream: TLSClientProceed: ssl_sock(IO::Socket::INET=GLOB(0x558379f1d410))
XML::Stream: TLSClientProceed: SSL: We are secure
XML::Stream: Read: buff(3
:Ҷ|,Vod)
XML::Stream: Read: buff()
XML::Stream: Read: ERROR
sendxmpp: Connect: 1
Use of uninitialized value $sid in hash element at
/usr/share/perl5/XML/Stream.pm line 1828.
XMPP::Conn: AuthIQAuth: old school auth
XMPP::Conn: SendAndReceiveWithID: object(Net::XMPP::IQ=HASH(0x558378f5c7f0))
XMPP::Conn: SendWithID: id(netjabber-0)
XMPP::Conn: SendWithID: in(schlepptop)
XMPP::Conn: RegisterID: tag(iq) id(netjabber-0)
XMPP::Conn: SendWithID: out(schlepptop)
XMPP::Conn: SendXML: sent(schlepptop)
Use of uninitialized value $sid in concatenation (.) or string at
/usr/share/perl5/XML/Stream.pm line 2739.
Use of uninitialized value $sid in hash element at
/usr/share/perl5/XML/Stream.pm line 2741.
XML::Stream: Send: (schlepptop)
Use of uninitialized value $sid in concatenation (.) or string at
/usr/share/perl5/XML/Stream.pm line 1667.
Use of uninitialized value $sid in hash element at
/usr/share/perl5/XML/Stream.pm line 1668.
Use of uninitialized value in concatenation (.) or string at
/usr/share/perl5/XML/Stream.pm line 1668.
Use of uninitialized value $sid in hash element at
/usr/share/perl5/XML/Stream.pm line 1670.
Use of uninitialized value $sid in hash element at
/usr/share/perl5/XML/Stream.pm line 1672.
Use of uninitialized value in numeric eq (==) at /usr/share/perl5/XML/Stream.pm
line 1672.
Use of uninitialized value $sid in hash element at
/usr/share/perl5/XML/Stream.pm line 1674.
Use of uninitialized value $sid in hash element at
/usr/share/perl5/XML/Stream.pm line 1677.
Use of uninitialized value $sid in hash element at
/usr/share/perl5/XML/Stream.pm line 2619.
Use of uninitialized value $sid in concatenation (.) or string at
/usr/share/perl5/XML/Stream.pm line 2739.
Use of uninitialized value $sid in hash element at
/usr/share/perl5/XML/Stream.pm line 2741.
XMPP::Conn: SendAndReceiveWithID: sent with id(netjabber-0)
XMPP::Conn: WaitForID: id(netjabber-0)
XMPP::Conn: ReceivedID: id(netjabber-0)
XMPP::Conn: ReceivedID: nope...
XMPP::Conn: WaitForID: haven't gotten it yet... let's wait for more packets
XMPP::Conn: Process: timeout(1)
Use of uninitialized value in concatenation (.) or string at
/usr/share/perl5/XML/Stream.pm line 1439.
Use of uninitialized value in numeric eq (==) at /usr/share/perl5/XML/Stream.pm
line 1442.
Use of uninitialized value $status{"newconnection"} in numeric eq (==) at
/usr/share/perl5/XML/Stream.pm line 1505.
Use of uninitialized value in subtraction (-) at /usr/share/perl5/XML/Stream.pm
line 1506.
XML::Stream: Send: ( )
Use of uninitialized value in concatenation (.) or string at
/usr/share/perl5/XML/Stream.pm line 1668.
Use of uninitialized value in numeric eq (==) at /usr/share/perl5/XML/Stream.pm
line 1672.
Use of uninitialized value in hash element at
/usr/share/perl5/Net/XMPP/Connection.pm line 433.
Use of uninitialized value in hash element at
/usr/share/perl5/Net/XMPP/Connection.pm line 440.
XMPP::Conn: ReceivedID: id(netjabber-0)
XMPP::Conn: ReceivedID: nope...
XMPP::Conn:
Bug#1060208: ITP: dds-ktx -- header-only library for reading KTX format textures
Package: wnpp Severity: wishlist Owner: David James X-Debbugs-Cc: debian-de...@lists.debian.org, davidjamescastor...@proton.me * Package name: dds-ktx Version : 1.1 Upstream Contact: Sepehr Taghdisian * URL : https://github.com/septag/dds-ktx * License : BSD Programming Lang: C Description : header-only library for reading KTX format textures I am continuing to package Citra. This package is the second of (now three) dependencies I need to package in order to do this. DDS-KTX is a texture format used to store textures (overview: https://www.khronos.org/ktx/). This library allows an application to parse a file in this format and convert it for use in OpenGL or Vulkan shaders. The source also comes with a small application to demonstrate the library's abilities. This source package would therefore build two packages: dds-ktx-header - the single header file that Citra will build against dds-ktx-ctexviewer - the demo application I am looking to maintain this package myself, but would need a sponsor to upload it for me.
Bug#1059648: sip4: autopkgtest failure with Python 3.12
Hi Gregor! On Sun, Jan 07, 2024 at 03:40:49PM +0100, Gregor Riepl wrote: > I can reproduce that, although I should mention that the segfault happens > during teardown, not when the module is loaded: > > >>> import sip > >>> print(sip) > '/usr/lib/python3/dist-packages/sip.cpython-312-x86_64-linux-gnu.so'> > >>> > > Program received signal SIGSEGV, Segmentation fault. > 0x00513a8d in PyMem_Free () > (gdb) bt > #0 0x00513a8d in PyMem_Free () > #1 0x7f73de6feaf9 in sip_api_free (mem=) at > ./siplib/siplib.c:2241 > #2 0x7f73de710c6d in sipOMFinalise (om=) at > ./siplib/objmap.c:69 > #3 0x7f73de6febaf in finalise () at ./siplib/siplib.c:2143 > #4 0x004591ab in ?? () > #5 0x00662d77 in Py_RunMain () > #6 0x006232eb in Py_BytesMain () > #7 0x7f73deba66ca in __libc_start_call_main (main=main@entry=0x623240, > argc=argc@entry=1, argv=argv@entry=0x7ffd043a59b8) at > ../sysdeps/nptl/libc_start_call_main.h:58 > #8 0x7f73deba6785 in __libc_start_main_impl (main=0x623240, argc=1, > argv=0x7ffd043a59b8, init=, fini=, > rtld_fini=, stack_end=0x7ffd043a59a8) > at ../csu/libc-start.c:360 > #9 0x00623171 in _start () Yes, I saw the same. In SIP 6, there were 3 commits to add support for Python 3.12, but the code diverged a lot so it's not trivial to backport them to SIP 4. > I'd also like to point out that SIP4 is no longer supported upstream. The > current version is 6.8.1, which is already packaged for Debian. > https://www.riverbankcomputing.com/software/sip/download > > > SIP v4 is no longer supported. This is the last release. > > sip-4.19.25.tar.gz > > Cura was made fit for PyQt6 and SIP6 in April 2022, and I think 5.0 has all > the needed changes. I will investigate if we can drop the dependency on > python3-sip-dev. As far as I can see, there are no other users of SIP4 in > Debian, so maybe it can be dropped completely after fixing Cura. Unfortunately there are other users: $ reverse-depends src:sip4 -r sid Reverse-Recommends == * krita [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] Reverse-Depends === * gnuradio [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] * meteo-qt [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] * python3-pykdl [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] * python3-python-qt-binding (for python3-sip-dev) * python3-python-qt-binding (for sip-dev) * qutebrowser (for python3-sip) * tulip [amd64 arm64 i386 mips64el ppc64el s390x] * vistrails (for python3-sip) $ reverse-depends -b src:sip4 -r sid Reverse-Testsuite-Triggers == * geophar (for python3-sip) Reverse-Build-Depends = * ball (for python3-sip-dev) * geophar (for python3-sip) * guidata (for python3-sip) * krita (for python3-sip-dev) * libarcus (for python3-sip-dev) * libsavitar(for python3-sip-dev) * openstructure (for sip-dev) * orocos-kdl(for python3-sip-dev) * pynest2d (for python3-sip-dev) * pyqwt3d (for python3-sip-dev) * stimfit (for python3-sip-dev) * tulip (for python3-sip-dev) Reverse-Build-Depends-Indep === * eric (for python3-sip-dev) krita and pyqwt3d have open bugs to move to sip6, but I will need to file bugs for the other packages too. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1058945: python3-secretstorage: please do not depend on dbus package
Hi Ansgar! On Sat, Jan 06, 2024 at 07:50:47PM +0100, Ansgar wrote: > That doesn't help much unless one takes special care. This is what > installing python3-poetry in a Podman container looks like: > [...] > > Now try not to install an init system, dbus, ... in a application > container wanting to use python3-poetry to install some Python > application. > > And this still doesn't ensure that: > 1. dbus is actually running in the context where python3-secretstorage is > used, > 2. the Dbus interface python3-secretstorage wants to talk to is actually > provided by a service > > (For 2. it doesn't even have a Depends: gnome-keyring | alternatives > either which is inconsistent with the dependency on Dbus...) gnome-keyring | alternatives is in Recommends, not in Depends. The reason for that is because someone may want to use secretstorage with a different server that is not listed there, and we do not have a virtual package name that any such implementation can provide (like e.g. notification-daemon is provided by 14 different packages). > Also it's unknown whether that is actually useful or not (as python3- > secretstorage is just a library that could not be relevant at all as > the application's user might not actually want to manage secrets via > keepassxc). > > It seems excessive to *always* require all of this to be installed for > *any* use of python3-poetry (which can optionally use python3- > secretstorage if that is even required). bash doesn't depend on gnome- > terminal either just because one needs some terminal to run it in ;-) I think python3-secretstorage is completely useless without D-Bus. So maybe this dependency chain should be cut at a higher level, e.g. between python3-keyring and python3-secretstorage. I am also the uploader of python3-keyring, so we can discuss it here. I can suggest two solutions: 1. Replace python3-keyring → python3-secretstorage Depends with Recommends. 2. Keep it Depends, but add some alternatives, e.g. python3-secretstorage | python3-keyrings.alt. Will any of that work for you? Some background: python3-keyring has different backends. In Debian, the following may be relevant: - The Secret Service backend (using python3-secretstorage). The major implementations of Secret Service interface are GNOME Keyring, KWallet and KeePassXC. - The legacy KWallet D-Bus backend (KWallet supports Secret Service in recent versions, so the usefulness of it is limited). - File-based backends provided by python3-keyrings.alt. The plain-text file backend is insecure and not recommended; the encrypted file backend is using getpass() to get the password so it can be used in CLI applications, but less useful in GUI ones. See also some related discussion in this Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/python-secretstorage/+bug/2041695 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060207: ncbi-acc-download: please remove extraneous dependency on python3-mock
Source: ncbi-acc-download Severity: minor Tags: patch Hi, For some reason Salsa doesn't let me push to this one reposotiry. Please apply the patch in attachment. Greetings tchet@brix /tmp/ncbi-acc-download $ git push Énumération des objets: 11, fait. Décompte des objets: 100% (11/11), fait. Compression par delta en utilisant jusqu'à 2 fils d'exécution Compression des objets: 100% (6/6), fait. Écriture des objets: 100% (6/6), 541 octets | 270.00 Kio/s, fait. Total 6 (delta 4), réutilisés 0 (delta 0), réutilisés du pack 0 remote: GitLab: You are not allowed to push code to protected branches on this project. To salsa.debian.org:med-team/ncbi-acc-download.git ! [remote rejected] master -> master (pre-receive hook declined) erreur : impossible de pousser des références vers 'salsa.debian.org:med-team/ncbi-acc-download.git' tchet@brix /tmp/ncbi-acc-download $ -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) >From a9e98b0af541b52a4a938a84c750c372304f0819 Mon Sep 17 00:00:00 2001 From: Alexandre Detiste Date: Sun, 7 Jan 2024 16:07:18 +0100 Subject: [PATCH] remove extraneous dependency on python3-mock --- debian/control | 1 - debian/tests/control | 1 - 2 files changed, 2 deletions(-) diff --git a/debian/control b/debian/control index fd76cd1..ead4ce7 100644 --- a/debian/control +++ b/debian/control @@ -8,7 +8,6 @@ Build-Depends: debhelper-compat (= 13), python3-all, python3-biopython (>= 1.79), python3-coverage, - python3-mock, python3-pytest, python3-pytest-cov, python3-pytest-mock, diff --git a/debian/tests/control b/debian/tests/control index 2602436..6826be6 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -1,7 +1,6 @@ Tests: run-param-test Depends: @, python3-biopython, - python3-mock, python3-pytest, python3-pytest-cov, python3-pytest-mock, -- 2.43.0
Bug#1060206: olive-editor: FTBFS: CMake Generate step failed.
Source: olive-editor Version: 20230614+ds-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/fetch.php?pkg=olive-editor=amd64=20230614%2Bds-1=1704354645=0 -- Configuring done (1.5s) CMake Error at ext/KDDockWidgets/src/CMakeLists.txt:306 (target_link_libraries): Target "kddockwidgets" links to: Qt5::WidgetsPrivate but the target was not found. Possible reasons include: * There is a typo in the target name. * A find_package call is missing for an IMPORTED target. * An ALIAS target is missing. -- Generating done (0.3s) CMake Warning: Manually-specified variables were not used by the project: CMAKE_EXPORT_NO_PACKAGE_REGISTRY CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY FETCHCONTENT_FULLY_DISCONNECTED CMake Generate step failed. Build files cannot be regenerated correctly. Cheers -- Sebastian Ramacher
Bug#1060205: castxml: BD-Uninstallable: castxml build-depends on missing: libclang-17-dev:mips64el
Source: castxml Version: 0.6.2-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/package.php?p=castxml Dependency installability problem for castxml on mips64el: castxml build-depends on missing: - libclang-17-dev:mips64el Cheers -- Sebastian Ramacher
Bug#1059648: sip4: autopkgtest failure with Python 3.12
Hi Graham, sip4's autopkgtests fail with Python 3.12 [1]. I've copied what I hope is the relevant part of the log below. [1] https://ci.debian.net/packages/s/sip4/testing/amd64/ 22s autopkgtest [20:09:51]: test autodep8-python3: [--- 22s Testing with python3.12: 22s 22s bash: line 1: 1865 Segmentation fault $py -c "import sip; print(sip)" 22s autopkgtest [20:09:51]: test autodep8-python3: ---] I can reproduce that, although I should mention that the segfault happens during teardown, not when the module is loaded: >>> import sip >>> print(sip) '/usr/lib/python3/dist-packages/sip.cpython-312-x86_64-linux-gnu.so'> >>> Program received signal SIGSEGV, Segmentation fault. 0x00513a8d in PyMem_Free () (gdb) bt #0 0x00513a8d in PyMem_Free () #1 0x7f73de6feaf9 in sip_api_free (mem=) at ./siplib/siplib.c:2241 #2 0x7f73de710c6d in sipOMFinalise (om=) at ./siplib/objmap.c:69 #3 0x7f73de6febaf in finalise () at ./siplib/siplib.c:2143 #4 0x004591ab in ?? () #5 0x00662d77 in Py_RunMain () #6 0x006232eb in Py_BytesMain () #7 0x7f73deba66ca in __libc_start_call_main (main=main@entry=0x623240, argc=argc@entry=1, argv=argv@entry=0x7ffd043a59b8) at ../sysdeps/nptl/libc_start_call_main.h:58 #8 0x7f73deba6785 in __libc_start_main_impl (main=0x623240, argc=1, argv=0x7ffd043a59b8, init=, fini=, rtld_fini=, stack_end=0x7ffd043a59a8) at ../csu/libc-start.c:360 #9 0x00623171 in _start () I'd also like to point out that SIP4 is no longer supported upstream. The current version is 6.8.1, which is already packaged for Debian. https://www.riverbankcomputing.com/software/sip/download > SIP v4 is no longer supported. This is the last release. > sip-4.19.25.tar.gz Cura was made fit for PyQt6 and SIP6 in April 2022, and I think 5.0 has all the needed changes. I will investigate if we can drop the dependency on python3-sip-dev. As far as I can see, there are no other users of SIP4 in Debian, so maybe it can be dropped completely after fixing Cura.
Bug#967257: ardour: depends on deprecated GTK 2
Upcoming Ardour 8.3 no longer depends on GTK2. Current Ardour/git (8.2-34-g4f5a801209) already dropped the dependency. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060204: ipvsadm: install files into /usr (DEP17)
Source: ipvsadm Version: 1:1.31-1 Severity: normal Tags: patch User: helm...@debian.org Usertags: dep17m2 Please find a patch attached to install aliased files into /usr, for the currently ongoing UsrMerge effort [1]. It has been build-tested and checked by dumat. Please review it and upload to unstable during the trixie cycle, preferably before the time_t-64bit transition. Note: this should not be backported to bookworm. If you intend to backport, please use dh_movetousr instead. If your package will rename/split/move its binaries (packages) during trixie, please then upload to experimental and get in touch with the UsrMerge driver, please see the wiki [1]. Chris [1] https://wiki.debian.org/UsrMerge diff -Nru ipvsadm-1.31/debian/changelog ipvsadm-1.31/debian/changelog --- ipvsadm-1.31/debian/changelog 2020-01-05 21:33:49.0 +0100 +++ ipvsadm-1.31/debian/changelog 2024-01-07 12:43:09.0 +0100 @@ -1,3 +1,10 @@ +ipvsadm (1:1.31-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install aliased files into /usr (DEP17 M2) (Closes: #-1) + + -- Chris Hofstaedtler Sun, 07 Jan 2024 12:43:09 +0100 + ipvsadm (1:1.31-1) unstable; urgency=medium * [950ed21] New upstream version 1.31 diff -Nru ipvsadm-1.31/debian/ipvsadm.init ipvsadm-1.31/debian/ipvsadm.init --- ipvsadm-1.31/debian/ipvsadm.init 2020-01-05 21:10:55.0 +0100 +++ ipvsadm-1.31/debian/ipvsadm.init 2024-01-07 12:43:09.0 +0100 @@ -15,7 +15,7 @@ #includes lsb functions . /lib/lsb/init-functions -IPVSADM="/sbin/ipvsadm" +IPVSADM="/usr/sbin/ipvsadm" IPVSADM_RULES="/etc/ipvsadm.rules" IPVSADM_CONFIG="/etc/default/ipvsadm" SYNCID="0" diff -Nru ipvsadm-1.31/debian/ipvsadm.install ipvsadm-1.31/debian/ipvsadm.install --- ipvsadm-1.31/debian/ipvsadm.install 2020-01-05 21:10:55.0 +0100 +++ ipvsadm-1.31/debian/ipvsadm.install 2024-01-07 12:43:07.0 +0100 @@ -1,4 +1,4 @@ debian/ipvsadm.rules etc/ -ipvsadm sbin/ -ipvsadm-restore sbin/ -ipvsadm-save sbin/ +ipvsadm usr/sbin/ +ipvsadm-restore usr/sbin/ +ipvsadm-save usr/sbin/
Bug#1059295: RFP: gfxstream -- wrapper for graphics streams across VirtIO
Control: retitle -1 ITP: gfxstream -- wrapper for graphics streams across VirtIO Hi， On Fri, Dec 22, 2023 at 8:45 PM Alex Bennée wrote: > > Package: wnpp > Severity: wishlist > > * Package name: gfxstream > Version : v0.1.2 > Upstream Author : Google > * URL or Web page : > https://android.googlesource.com/platform/hardware/google/gfxstream > * License : Apache2 > Description : wrapper for graphics streams across VirtIO > > This package (and the supporting aemu and rutabagga_ffi bindings) is > needed if we want to compile QEMU with rutabaga support - hence support > Vulkan and Wayland over virtio-gpu. > > We have some notes for building in tree here in the meantime: > > https://linaro.atlassian.net/wiki/spaces/ORKO/pages/28985622530/Building+QEMU+with+virtio-gpu+and+rutabaga+gfx I would like to package it. But I lack experience in packaging similar packages so may I need some guidance from here if need. Thanks, Bo > > -- > Alex Bennée > Virtualisation Tech Lead @ Linaro >
Bug#1060156: acl: move files to /usr for DEP17
Source: acl Followup-For: Bug #1060156 Hi, I'm wondering why you decided to keep the acl.postinst and acl.postrm files, their contents appear to be of no use on a usrmerged system (to the best of my knowledge). Is that intentional? Trixie only supports usrmerged layouts.
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
(sorry for the very late response, I only noticed your message just now) I did come to the conclusion that Werkzeug 2.3.x has some bigger changes that will break most of the existing packages in some way. The main differences to Werkzeug 3.x than isn't that big. Ok, that makes sense! Although, I'm not 100% convinced that updating to 2.3 in the short run to fix some currently broken packages, and then focusing on upgrading to 3.x isn't a better choice. 2.3 is also closer to 3.x, so that may make a transition smoother. Because a updated flask-login and other (updated) packages have also underlying changes that require than a updated package of Werkzeug. And some upstream projects did change their source in a way so they can deal different versions of Werkzeug. So a usual update is magical fixing build issues we did have in older versions against recent Flask/Werkzeug versions. Ok, now I get what mean. Thanks for the clarification and sorry for the confusion.
Bug#1060192: tracker.debian.org: SSL connection extremely slow and sometimes timing out
On Sun, 07 Jan 2024, Helge Kreutzmann wrote: > Package: tracker.debian.org > Severity: important > > Yesterday and today connections to packages.debian.org is *extremely* packages.debian.org is entirely unrelated to tracker.debian.org. It's managed by the web team AFAIK. That said if the issue was at the TLS connection level, it's likely the DSA team that can help... but since the issue is gone, I wonder whether we shouldn't just close the bug, in particular since the DSA team doesn't use the bug tracker. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Bug#1060201: qa.debian.org: [udd] carnivore_emails is lacking lots of entries
Control: usertag -1 udd
Am Sun, Jan 07, 2024 at 01:38:35PM +0100 schrieb Andreas Tille:
> Package: qa.debian.org
> Severity: normal
>
> Hi,
>
> I tried to analyse closed bugs using done_email via carnivore_emails but
> realised
> that this table is lacking lots of entries where I could easily add several
> from
> my own memory:
>
> SELECT done_email, COUNT(*) FROM (
> SELECT done_email FROM archived_bugs WHERE id IN (SELECT id FROM (SELECT
> ab.id, ce.id AS ce_id
> FROM archived_bugs ab
> LEFT JOIN carnivore_emails ce ON ce.email = ab.done_email
> ) noid WHERE ce_id IS NULL ) AND done_email NOT IN
> ('ftpmas...@ftp-master.debian.org','nore...@salsa.debian.org','unknown')
> ) miss GROUP BY done_email
> ORDER BY count DESC
> ;
>
>done_email | count
> +---
> goth...@sapo.pt| 5221
> ba...@quantz.debian.org| 2665
> d...@cs.tu-berlin.de | 2555
> kit...@northeye.org| 2371
> m...@linux.it| 2056
> herb...@gondor.apana.org.au| 1900
> da...@merkel.debian.org| 1788
> daniel.baum...@progress-technologies.net | 1393
> m...@stro.at| 1327
> b...@fs.tum.de | 1278
> debian-...@adam-barratt.org.uk | 1155
> cche...@cheney.cx | 1031
> sramac...@respighi.debian.org | 992
> ...
> zweistei...@gmx.de | 1
> (9075 rows)
>
> I wonder how the carnivore_* tables are filled and whether you want me
> to draft some INSERT statements filling up the most relevant emails
> where I would volunteer to sort the according IDs.
>
> Kind regards
>Andreas.
BTW, its probably pretty easy to resolve >900 of these missing e-mails:
CREATE TEMPORARY TABLE missing_in_carnivore_emails AS
SELECT done_email, COUNT(*) FROM (
SELECT done_email FROM archived_bugs WHERE id IN (SELECT id FROM (SELECT ab.id,
ce.id AS ce_id
FROM archived_bugs ab
LEFT JOIN carnivore_emails ce ON ce.email = ab.done_email
) noid WHERE ce_id IS NULL ) AND done_email NOT IN
('ftpmas...@ftp-master.debian.org','nore...@salsa.debian.org','unknown')
) miss GROUP BY done_email
ORDER BY count DESC
;
SELECT DISTINCT done_name, done_email, cn.id FROM
(SELECT BTRIM(done_name, '"') AS done_name, done_email FROM archived_bugs) ab
LEFT JOIN carnivore_names cn ON cn.name = ab.done_name
WHERE done_email in (SELECT done_email FROM missing_in_carnivore_emails WHERE
count > 10)
AND done_name IS NOT NULL AND done_name != ''
AND id IS NOT null
;
done_name| done_email
| id
-+-+--
Camm Maguire| c...@enhanced.com
| 6158
Ross Vandegrift | r...@kallisti.us
| 734
Michael Ablassmeier | a...@grinser.de
| 2751
Neil McGovern | maul...@halon.org.uk
| 3708
Torsten Landschoff | tors...@pclab.ifg.uni-kiel.de
| 6320
Agney Lopes Roth Ferraz | ag...@users.sourceforge.net
| 4000
Galen Hazelwood | gal...@micron.net
| 1241
Anand Kumria| wildf...@progsoc.org
| 4175
Adam Rogoyski | rogoy...@cs.utexas.edu
| 1102
Christophe Barbe| christophe.ba...@ufies.org
| 2054
Yann Dirson | ydir...@fr.alcove.com
| 5804
Arjan Oosting | arjanoost...@home.nl
| 5366
Julian Gilbey | j.d.gil...@qmw.ac.uk
| 3875
Norman Jordan | njor...@shaw.ca
| 3513
Michael Piefel | pie...@informatik.hu-berlin.de
|
Frederic Lepied | lep...@debian.org
| 2460
...
Neil Williams | li...@codehelp.co.uk
| 1552
Christopher Martin | chrsm...@freeshell.org
| 2754
Andrew Lenharth | a...@cs.washington.edu
| 3085
(922 rows)
This statement could be easily turned into injects and would be a first
approach to enhance
the
Bug#1060203: RFS: dde-store/1.2.3+dfsg-2.1 [NMU] [RC] -- DDE Store for Deepin Desktop Environment
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "dde-store": * Package name : dde-store Version : 1.2.3+dfsg-2.1 Upstream contact : dekzi * URL : https://github.com/dekzi/dde-store * License : GPL-3, GPL-3+ * Vcs : https://salsa.debian.org/openarun/dde-store Section : utils The source builds the following binary packages: dde-store - DDE Store for Deepin Desktop Environment To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dde-store/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dde-store/dde-store_1.2.3+dfsg-2.1.dsc Changes since the last upload: dde-store (1.2.3+dfsg-2.1) unstable; urgency=medium . * Non-maintainer upload. * Cherry-pick upstream commit fix ftbfs. (Closes: #1059237) -- Regards, -- Bo YU signature.asc Description: PGP signature
Bug#1060202: glibc - autopkgtest flacky on arm64
Package: glibc Version: 2.37-13 Severity: important Currently the autopkgtest on arm64 fails sometimes. Timeout while building: https://ci.debian.net/packages/g/glibc/unstable/arm64/41516611/ Failed test: https://ci.debian.net/packages/g/glibc/testing/arm64/40439311/ -- There is an order of things in this universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
