Bug#1062821: ola: NMU diff for 64-bit time_t transition
Hi Lucas,
On Sat, Feb 03, 2024 at 02:39:49PM -0300, Lucas Kanashiro wrote:
> Source: ola
> Version: 0.10.9.nojsmin-4
> Severity: serious
> Tags: patch pending sid trixie
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
>
> NOTICE: these changes must not be uploaded to unstable yet!
>
> Dear maintainer,
>
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> ola as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
Would it make sense for me to contact upstream and ask if they do
certain things? They're quite knowledgeable and might know.
If not, then no worries, but I thought I'd ask.
Thanks,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1036884: Schedule
On 2/7/24 08:10, Mattias Ellert wrote: Personally I think it would have made more sense to file these bugs with minor or normal severity (since they are simply informational at this stage) and then upgrade them to serious when the transition starts (at which point they become RC). I'd downgrade the severity to important like we do for FTBFS bugreports of rdeps involved in not yet started transitions. Once the transition starts with the upload of dpkg to unstable the severity should be raised to serious. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1063379: RM: r-bioc-shortread [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: r-bioc-shortr...@packages.debian.org, 1063...@bugs.debian.org Control: affects -1 + src:r-bioc-shortread Hi, as requested in the r-bioc-rhtslib (bug #1063376) removal for 32-bit architectures for this package the 32bit architectures need to be removed as well. Kind regards and thanks a lot for your work as ftpmaster Andreas.
Bug#1062570: libpng1.6: NMU diff for 64-bit time_t transition
control: found -1 1.6.40-3 On Sun, 4 Feb 2024 11:05:46 +0100 Gianfranco Costamagna wrote: control: affects -1 1.6.40-3 G. On Thu, 01 Feb 2024 23:12:06 + Steve Langasek wrote: > Source: libpng1.6 > Version: 1.6.42-1 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > libpng1.6 as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for libpng1.6 > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. > > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE > Locale: LANG=C, 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) OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063378: RM: r-bioc-variantannotation [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: r-bioc-variantannotat...@packages.debian.org, 1063...@bugs.debian.org Control: affects -1 + src:r-bioc-variantannotation Hi, as requested in the r-bioc-rhtslib (bug #1063376) removal for 32-bit architectures for this package the 32bit architectures need to be removed as well. Kind regards and thanks a lot for your work as ftpmaster Andreas.
Bug#1063377: RM: r-bioc-rsamtools [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: r-bioc-rsamto...@packages.debian.org, 1063...@bugs.debian.org Control: affects -1 + src:r-bioc-rsamtools Hi, as requested in the r-bioc-rhtslib (bug #1063376) removal for 32-bit architectures for this package the 32bit architectures need to be removed as well. Kind regards and thanks a lot for your work as ftpmaster Andreas.
Bug#1036884: Schedule
Hi! The earliest of the RC bugs filed for this transition have now been unresolved long enough to trigger AUTORM threats. This is unfortunate, since the maintainers can't do anything to fix them, since they are un-fixable until the required changes to the default compiler flags are implemented. In order for threats of removal not to trigger maintainers to blindly applying the proposed patches and uploading to unstable to close the bugs, you should either start the transition now or downgrade the severity of the bugs. Personally I think it would have made more sense to file these bugs with minor or normal severity (since they are simply informational at this stage) and then upgrade them to serious when the transition starts (at which point they become RC). Do you have an estimate when the uploads to unstable will start? Mattias signature.asc Description: This is a digitally signed message part
Bug#1063376: RM: r-bioc-rhtslib [armel armhf i386 hppa m68k powerpc sh4] -- ROM; No support of 32 bit architectures any more
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: r-bioc-rhts...@packages.debian.org, 1063...@bugs.debian.org, debia...@bugs.debian.org Control: affects -1 + src:r-bioc-rhtslib Hi, as per bug #1063275 the time_t transition would be quite hard for the r-bioc-htslib package. Since this kind of package is typically not used on 32bit architectures I've just uploaded r-bioc-htslib restricted to 64bit architectures where time_t transition is not needed. Please remove the binaries for 32bit architectures from the Debian archive. I'm aware that r-bioc-htslib has has the following rdepends: r-bioc-rsamtools r-bioc-variantannotation r-bioc-shortread I will file removal according requests for 32 bit architectures successively to clean up the archive once I get a bug number for this bug to keep it in CC. Thanks a lot for your work as ftpmaster Andreas.
Bug#1061341: Fwd: Bug#1061341: cyrus-common: identified for time_t transition but no ABI in shlibs
On 2/7/24 06:31, ellie timoney wrote:
Hi Xavier,
On Mon, 29 Jan 2024, at 9:59 AM, ellie timoney wrote:
On Thu, 25 Jan 2024, at 3:53 PM, Yadd wrote:
yes there are other errors because some .h require unavailable .h like
config.h
Ooh interesting, I'll have a look
I'm still working on this, but the more I work on it, the more of it turns out
to need fixing...
I think for now, it makes sense for you to proceed with the packaging changes
assuming that 32 bit Cyrus will _not_ be ABI compatible when recompiled with 64
bit time_t. From the original email, I think that means you'll need to set up
strict version dependencies between the cyrus-common, cyrus-admin and
cyrus-clients packages, so that people can't partially upgrade and wind up with
conflicts.
Cheers,
ellie
Hi,
dependencies are already strict (= ${binary:Version}).
To be able to render cyrus-dev headers compatible with ABI test, I'll
have to remove the following (missing config.h,...):
/usr/include/cyrus/bufarray.h
/usr/include/cyrus/charset.h
/usr/include/cyrus/command.h
/usr/include/cyrus/crc32.h
/usr/include/cyrus/cyr_qsort_r.h
/usr/include/cyrus/glob.h
/usr/include/cyrus/imapurl.h
/usr/include/cyrus/mappedfile.h
/usr/include/cyrus/procinfo.h
/usr/include/cyrus/rfc822tok.h
/usr/include/cyrus/sieve/sieve_err.h
/usr/include/cyrus/sieve/sieve_interface.h
/usr/include/cyrus/sqldb.h
/usr/include/cyrus/tok.h
/usr/include/cyrus/vparse.h
/usr/include/cyrus/wildmat.h
Bug#1025518: bullseye-pu: package capnproto/0.7.1-1+deb11u1
On Tue, Feb 06, 2024 at 06:01:43PM +, Jonathan Wiltshire wrote: > On Tue, Jul 25, 2023 at 10:19:50PM +0100, Jonathan Wiltshire wrote: > > Control: tag -1 moreinfo > > > > On Mon, Dec 05, 2022 at 11:22:51PM -0800, tony mancill wrote: > > > As the upstream author notes in [3], the issue is present in inlined > > > code, thus applications built against capnproto must be rebuilt against > > > the patched version. > > > > This doesn't immediately make any of us enthusiastic, it has to be said... > > Can we get the proposed debdiff at least please? > > > > The hazards are: > > - ftbfs in the rdeps in stable > > - much reduced testing of proposed-updates vs. for example sid/testing > > > > > The issue for unstable and bookworm is being addressed via an > > > upload to experimental [4] and a subsequent transition [5]. Easy > > > enough... > > > > > > For stable (and old-stable), we need to introduce 0.7.1, a new upstream > > > version that generates a (new) libcapnp-0.7.1 binary package to address > > > the vulnerability. Once those are present in the archive, we can > > > trigger rebuilds of the reverse dependencies. At this time I am asking > > > for bullseye. > > > > > > [ Reason ] > > > This is to address CVE-2022-46149 [1]. > > > > > > [ Impact ] > > > Packages built with capnproto in bullseye will remain potentially > > > vulnerable to the CVE. > > > > > > [ Tests ] > > > I have built the package in a clean bullseye chroot and then used ratt to > > > rebuilt the (8) bullseye r-deps: > > > > > > - clickhouse_18.16.1+ds-7.2 > > > - harvest-tools_1.3-6 > > > - laminar_1.0-3 > > > - librime_1.6.1+dfsg1-1 > > > - mash_2.2.2+dfsg-2 > > > - mir_1.8.0+dfsg1-18 > > > - rr_5.4.0-2 > > > - sonic-visualiser_4.2-1 > > > > laminar in particular doesn't seem to have much maintainer attention. If > > there are problems with the rdeps on rebuild are you going to be in a > > position to resolve them? That's a fair question and I don't have a ready answer other than it depends on how much attention is needed. I am a member of the backports ACL now (I wasn't when this was filed), so I can help with uploads, but I don't have a history with the r-deps. > > > [ Risks ] > > > The upstream author has stated that there are no known vulnerable > > > applications, yet advises that all capnproto users rebuild their > > > applications using patched versions of capnproto. > > > > An abundance of caution? Otherwise the statements seem at odds with each > > other. Agreed. I don't have a strong sense for the security risk to end users. > > > If this is not amenable to stable-proposed-updates, would you recommend > > > backports? > > > > I'm not sure a transition in backports is going to be well received either. > > Let's start with the debdiff and at least know what we're looking at. > > Ping? Thank you for the gentle reminder. I parsed the "not well received" comment and somehow skimmed past the request for the debdiff, got busy, etc... The full debdiff is attached, but it's mostly comprised of non-functional build system and autoconf drift. A pared-down diff with only the packaging and true (semantic) upstream changes is attached as well. Thank you, tony diff -Nru capnproto-0.7.0/aclocal.m4 capnproto-0.7.1/aclocal.m4 --- capnproto-0.7.0/aclocal.m4 2018-08-28 18:13:57.0 -0700 +++ capnproto-0.7.1/aclocal.m4 2022-11-29 07:55:16.0 -0800 @@ -1,6 +1,6 @@ -# generated automatically by aclocal 1.16.1 -*- Autoconf -*- +# generated automatically by aclocal 1.16.3 -*- Autoconf -*- -# Copyright (C) 1996-2018 Free Software Foundation, Inc. +# Copyright (C) 1996-2020 Free Software Foundation, Inc. # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, @@ -20,7 +20,7 @@ If you have problems, you may need to regenerate the build system entirely. To do so, use the procedure documented by the package, typically 'autoreconf'.])]) -# Copyright (C) 2002-2018 Free Software Foundation, Inc. +# Copyright (C) 2002-2020 Free Software Foundation, Inc. # # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, @@ -35,7 +35,7 @@ [am__api_version='1.16' dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to dnl require some minimum version. Point them to the right macro. -m4_if([$1], [1.16.1], [], +m4_if([$1], [1.16.3], [], [AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl ]) @@ -51,14 +51,14 @@ # Call AM_AUTOMAKE_VERSION and AM_AUTOMAKE_VERSION so they can be traced. # This function is AC_REQUIREd by AM_INIT_AUTOMAKE. AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION], -[AM_AUTOMAKE_VERSION([1.16.1])dnl +[AM_AUTOMAKE_VERSION([1.16.3])dnl m4_ifndef([AC_AUTOCONF_VERSION], [m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl _AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))]) # AM_AUX_DIR_EXPAND
Bug#1061814: [Debichem-devel] Bug#1061814: add patch
Hi, On 2024-02-07 07:29, Matthias Klose wrote: this is fixed upstream, and in experimental. however you also have to drop the dependency on python3-distutils. patch at http://launchpadlibrarian.net/713215440/openmm_8.0.0+dfsg-6build1_8.0.0+dfsg-6ubuntu1.diff.gz Thanks for a patch. I have already filed a transition bug for openmm [1] (experimental -> unstable). Thus since this issue is already fixed in experimental I do not think it is worth fixing in unstable. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062666 Best, Andrius
Bug#1063375: upgrade-reports: Update 2/5/2024 caused ERR_ADDRESS_UNREACHABLE in any browser for some sites, e.g. jw.org
Package: upgrade-reports Severity: important X-Debbugs-Cc: dan_rob...@hotmail.com (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) My previous release is: Debian 11.X I am upgrading to: Debian 11.9 and later Debian 12.4 Archive date: Initially it was a minor update Upgrade date: 2/5/2024 uname -a before upgrade: uname -a after upgrade: Method: Chrome, Firefox, Chromium, Brave Contents of /etc/apt/sources.list: - Were there any non-Debian packages installed before the upgrade? If so, what were they? I don't know - Was the system pre-update a 'pure' system only containing packages from the previous release? If not, which packages were not from that release? I don't know - Did any packages fail to upgrade? No - Were there any problems with the system after upgrading? Apparently not Further Comments/Problems: "Initially it was a minor update on February 5, 2024 that caused me to not be able to access several internet sites that I previously accessed without problem, such as "jw.org" (there are some that I can access, such as google.com) and using different browsers (Chrome and Firefox for example), although I can access those same sites from Android or Windows devices on the same local network. I thought that if I updated to the next major version (Debian 12) I would reinstall everything new and that perhaps the error was not in that version, but unfortunately the problem persists." Please attach the output of "COLUMNS=200 dpkg -l" (or "env COLUMNS ...", depending on your shell) from before and after the upgrade so that we know what packages were installed on your system.
Bug#1061814: add patch
Control: tags -1 + patch this is fixed upstream, and in experimental. however you also have to drop the dependency on python3-distutils. patch at http://launchpadlibrarian.net/713215440/openmm_8.0.0+dfsg-6build1_8.0.0+dfsg-6ubuntu1.diff.gz
Bug#1063374: RFP: HTMX - high power tools for HTML
Package: wnpp Severity: wishlist * Package name: libjs-htmx Version : 1.9.10 Upstream Authors : Big Sky Software * URL : https://github.com/bigskysoftware/htmx * License : 0BSD Programming Lang: JavaScript Description : A JavaScript library to enhance the features of HTML HTML has only two elements that communicate with the server - and . HTMX allows all elements to send AJAX requests to the server. It also allows DOM manipulation by replacing HTML elements with the response from the server. This can significantly enhance the user experience of traditional multi-page web applications. . htmx allows you to access AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext. . htmx has no runtime dependencies. It can be used by web applications written in any programming language. The license is Zero-Clause BSD. Links: 1. https://htmx.org -- Regards, Joseph Nuthalapati
Bug#1063373: mc-data: modarin thin mc skins are incorrect / behind upstream modarin
Package: mc-data Version: 3:4.8.30-1 Severity: normal X-Debbugs-Cc: shtetldik+shm...@gmail.com Dear Maintainer, I noticed that modarin256-defbg-thin.ini, modarin256-thin.ini (and both root variants of them) are outdated and and also have typos which results in some interface elements being not set. If you compare it to upstream suppprted skins like modarin256-defbg.ini, you'll notice differences in these sections: [widget-panel], [widget-scrollbar], [widget-editor]. They should simply be synced up with non thin ones, keeping only differences in [Lines] section. See below patch for for an example how modarin256-defbg.ini can be fixed. Regards, Shmerl. --- a/modarin256-defbg-thin.ini +++ b/modarin256-defbg-thin.ini @@ -28,7 +28,7 @@ # modarcon16root # modarcon16root-defbg # - like everything running in a 16-color terminal, these skins look ugly -# and are no subsitute for the 256-color versions. As some terminals don't +# and are no substitute for the 256-color versions. As some terminals don't # support using dark gray as background color, i used a black background # and adjusted the remaining colors accordingly. # @@ -81,6 +81,7 @@ disabled = color246;color239 #inputhistory = #commandhistory = +shadow = color240;color0 [dialog] _default_ = color252;color239 @@ -164,21 +165,23 @@ removed = ;color234 error = color231;color160 -[widget-common] -sort-sign-up = ↑ -sort-sign-down = ↓ - [widget-panel] -hiddenfiles-sign-show = • -hiddenfiles-sign-hide = ○ -history-prev-item-sign = « -history-next-item-sign = » -history-show-list-sign = ^ +sort-up-char = ↑ +sort-down-char = ↓ +hiddenfiles-show-char = • +hiddenfiles-hide-char = ○ +history-prev-item-char = « +history-next-item-char = » +history-show-list-char = ^ -[widget-scollbar] +[widget-scrollbar] first-vert-char = ↑ last-vert-char = ↓ first-horiz-char = « last-horiz-char = » current-char = ■ background-char = ▒ + +[widget-editor] +window-state-char = * +window-close-char = X -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.4-dirty (SMP w/32 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN 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) LSM: AppArmor: enabled -- no debconf information
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
Hi! On Tue, 2024-02-06 at 15:42:33 +0100, Helmut Grohne wrote: > On Tue, Feb 06, 2024 at 11:34:07AM +0100, Adrien Nader wrote: > > Providing two APIs makes me quite uneasy due to having core components > > that would behave differently from the rest of the distribution. It > > sounds like something that will come back to bite for a long time. > > Can you elaborate? Yes, I'm not sure I understand either. This is what symbol versioning makes possible, even providing different variants for the same symbol, see for example glibc or libbsd. In any case, if going the bi-ABI path, I think upstream should get involved, and the shape of this decided with them. In addition the library should also be built with LFS by the upstream build system, which it does not currently, to control its ABI. > Keep in mind that for all the 64bit architectures, there is no abi > difference as the symbol is only added for those architectures, that > currently use a 32bit ino_t. > > I checked on codesearch.d.n and there are very few users on this API; > > actually, none I think. Per > > https://codesearch.debian.net/search?q=matchpathcon_filespec_add=1=1 > > - box64 mentions that API but the "code" is commented-out, > > - busybox uses it in the "setfiles" applet which isn't built, > > - android-platform-external-libselinux has it in headers but also has > > its own implementation > > > > That should hopefully give more freedom although I'm not sure what would > > be the preferred route. > > And here you are arguing that there are no practical users of the added > symbol, so with luck, we'd be adding an unused symbol on armhf. With bad > luck, we'd have some users and for those users we'd be ABI-incompatible > with the rest of the world on armhf. I think there are only three ways to go about this, excluding the t64 attempt: 1) Build the library with LFS unconditionally (except on i386). As there are no users in Debian, this would not break there, but would break for any external packages and locally unpackaged users of the library. 2) Bump the SONAME, ideally coordinate with upstream or alternatively with a Debian specific one. This does not break locally built packages nor locally unpackaged code linking against the library. 3) Build the library with LFS support (everywhere including i386), and on systems w/o built-in LFS, make the old symbol use 32-bit ino_t, and add a new symbol that uses 64-bit ino_t. This preserves the ABI, for external packages and locally unpackaged code linking against the library. I think the three options would cause no upgrade issues, as they include either no SONAME bump (option 1 and 3), or an actual SONAME bump (option 2) with no file conflicts involved. Personally I'd like to be able to cleanly and safely build dpkg with time64 everywhere (including i386, otherwise the port will not be even installable), so my preference is for options that make that possible (2 and 3), and from those the one with best backwards compatibility with was the main concern for excluding i386 from the time64 transition would be option 3. So I think that would be the preferred option here. If you'd like assistance with trying to get a proposal for 3 to present upstream I could look into that. But I think they should be involved early on to see what they'd like to see and what they might outright reject. Thanks, Guillem
Bug#1063368: kate: Shift-key not working
Hello, On 07/02/2024 00:50, Patrick Franz wrote: Hej, Am Dienstag, 6. Februar 2024, 22:10:47 CET schrieb Dominik: Package: kate Version: 4:22.12.3-1 Severity: important Dear Maintainer, The shift key has no effect when writing (e.g. Shift+a results in 'a' instead of 'A'). Some general observations about the probelm itself: - Caps lock works. - Shift hotkeys work (e.g. Shift+Left in order to mark the character left of the cursor). - Alt Gr has the same problem (I changed my keybooard layout to german and Alt Gr+q prints 'q' instead of '@'). - Some other applications have the same issue (e.g. kwrite, vlc, texstudio, wireshark). I think all my Qt-applications do, but Qt might also be unrelated. Other applications such as xfce4-terminal or firefox work flawlessly. With "distrobox" I created a container for debian stable (like mine) and debian testing, and the problem occurs only in the "stable" conteiner. Therefore, I don't think it's some configuration error of mine. Also, this suggests that the bug has been fixed in more recent package versions. However, those are not available yet for stable via apt upgrade. stable: image: quay.io/toolbx-images/archlinux-toolbox:latest Qt-Version (kate): 5.15.8 kate-Version: 22.12.3 testing: image: docker.io/library/debian:testing Qt-Version (kate): 5.15.10 kate-Version: 23.08.1 I'm slightly confused about which system you are actually running and how you do that (natively or in a container). Because your "Debian stable" seems to be some Arch container. I have a native desktop system which I upgraded from Debian 11 to 12 bookworm a couple of days ago. Something during the upgrade-process must've broken it. I use distrobox only for testing/comparison purposes. The quay.io link was a Debian container from the Archlinux repo, but even with the container docker (docker.io/library/debian:stable-backports) this issue persists. Also, I cannot reproduce the issue on Debian Stable and I don't remember this ever being an issue. Since using a newer package fixes the problem it has to be a bug - which only appears in combination with my system configuration. Unfortunately, I don't know which parts of my configuration might trigger this bug or how to make the bug reproducible on other systems. I've tried everything I know in trying to narrow the problem down, so if you have any suggestions/questions I'd be happy to try/answer them. Dominik
Bug#1063146: fai-setup-storage: New dependency on /usr/lib/fai/subroutines
I can add a Depends or Recommends on fai-client for the package fai-setup-storage. What do you think is better? -- regards Thomas
Bug#1063146: fai-setup-storage: New dependency on /usr/lib/fai/subroutines
Hi Stephen, thanks for the report. setup-storage does not need fai-client if you use the option -D and specify the list of disks. So it's not always needed. But I will prepare a patch for it. -- regards Thomas
Bug#1061853: ttconv doesn't run any tests during the build and as autopkg test
Control: severity -1 serious dh_auto_test -i -O--buildsystem=pybuild I: pybuild base:240: cd /<>/.pybuild/cpython3_3.10/build; python3.10 -m unittest discover -v -- Ran 0 tests in 0.000s OK this will fail with Python 3.12, exiting with value 5. Please discover the tests properly.
Bug#1063372: python-tzlocal doesn't run any tests during the build, and as autopkg test
Package: src:python-tzlocal Version: 5.2-1.1 Severity: important python-tzlocal doesn't run any tests during the build, and as autopkg test. It looks like the switch from standard unittest to pytest wasn't implemented.
Bug#1063368: kate: Shift-key not working
Hej, Am Dienstag, 6. Februar 2024, 22:10:47 CET schrieb Dominik: > Package: kate > Version: 4:22.12.3-1 > Severity: important > > Dear Maintainer, > > The shift key has no effect when writing (e.g. Shift+a results in 'a' > instead of 'A'). > > Some general observations about the probelm itself: > - Caps lock works. > - Shift hotkeys work (e.g. Shift+Left in order to mark the character > left of the cursor). - Alt Gr has the same problem (I changed my > keybooard layout to german and Alt Gr+q prints 'q' instead of '@'). - > Some other applications have the same issue (e.g. kwrite, vlc, > texstudio, wireshark). I think all my Qt-applications do, but Qt > might also be unrelated. Other applications such as xfce4-terminal or > firefox work flawlessly. > > With "distrobox" I created a container for debian stable (like mine) > and debian testing, and the problem occurs only in the "stable" > conteiner. Therefore, I don't think it's some configuration error of > mine. Also, this suggests that the bug has been fixed in more recent > package versions. However, those are not available yet for stable via > apt upgrade. > > stable: > image: quay.io/toolbx-images/archlinux-toolbox:latest > Qt-Version (kate): 5.15.8 > kate-Version: 22.12.3 > > testing: > image: docker.io/library/debian:testing > Qt-Version (kate): 5.15.10 > kate-Version: 23.08.1 I'm slightly confused about which system you are actually running and how you do that (natively or in a container). Because your "Debian stable" seems to be some Arch container. Also, I cannot reproduce the issue on Debian Stable and I don't remember this ever being an issue. -- Med vänliga hälsningar Patrick Franz
Bug#1004135: plantuml: please update to a newer upstream version
Package: plantuml Version: 1:1.2020.2+ds-3 Followup-For: Bug #1004135 X-Debbugs-Cc: deltal...@gmail.com Dear Maintainer, Current version in Debian is close to be 4 years outdated and it seems that updating it will fix some CVE bugs. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.13-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plantuml depends on: ii default-jre-headless 2:1.17-75 ii libavalon-framework-java 4.2.0+ds-1 ii libbatik-java 1.17+dfsg-1 ii libcommons-io-java2.11.0-2 ii libcommons-logging-java 1.3.0-1 ii libfop-java 1:2.8-2 ii libjlatexmath-java1.0.7-3 ii libxml-commons-external-java 1.4.01-6 ii libxmlgraphics-commons-java 2.8-2 Versions of packages plantuml recommends: ii graphviz 2.42.2-8 plantuml suggests no packages. -- no debconf information
Bug#1063371: nmu: golang-github-go-jose-go-jose, golang-github-tinylib-msgp
Control: tags -1 bookworm-backports signature.asc Description: This is a digitally signed message part
Bug#1063371: nmu: golang-github-go-jose-go-jose, golang-github-tinylib-msgp
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Tags: bookworm-backports Control: affects -1 + src:golang-github-go-jose-go-jose Control: affects -1 + src:golang-github-tinylib-msgp nmu golang-github-go-jose-go-jose_3.0.1-2~bpo12+1 . amd64 . bookworm-backports . -m "Build on buildd" nmu golang-github-tinylib-msgp_1.1.9-1~bpo12+1 . amd64 . bookworm-backports . -m "Build on buildd" I would like for the amd64 builds to happen on official buildds, rather than relying on my amd64 upload as part of processing through BACKPORTS-NEW. I'm not sure when the next update in unstable to either package will be, so I'd like to schedule a binNMU. Thanks, Mathias signature.asc Description: This is a digitally signed message part
Bug#959867: ifup kills dhclient on if-up.d script failure
I was recently bitten by this as well. It was particularly bad in my case: on a headless server, with the network connection being my only way in---and the problem was not with the main Ethernet interface, but with a separate WireGuard one that I was not using (both marked as "auto"). The eno1 interface got a DHCP connection without issue. But the wg0 config had a post-up routing-setup bug that I'd missed in earlier testing. As the syslog excerpt below shows, the failure to bring up wg0 caused *all* of the "Raise network interfaces" task to be walked back. And as this only killed dhclient and left eno1 configured, I thought all was fine... until the system dropped off the network twelve hours later. (It's also clear that dhclient was killed uncleanly, because the next time it runs, you get a "Removed stale PID file" message.) The "FIB table does not exist" error is where things start to go wrong: 2024-02-05T22:19:06.343712-05:00 darkstar systemd[1]: Starting networking.service - Raise network interfaces... 2024-02-05T22:19:06.377118-05:00 darkstar dhclient[620]: Internet Systems Consortium DHCP Client 4.4.3-P1 2024-02-05T22:19:06.377147-05:00 darkstar ifup[620]: Internet Systems Consortium DHCP Client 4.4.3-P1 2024-02-05T22:19:06.377154-05:00 darkstar ifup[620]: Copyright 2004-2022 Internet Systems Consortium. 2024-02-05T22:19:06.377159-05:00 darkstar ifup[620]: All rights reserved. 2024-02-05T22:19:06.377164-05:00 darkstar ifup[620]: For info, please visit https://www.isc.org/software/dhcp/ 2024-02-05T22:19:06.377178-05:00 darkstar dhclient[620]: Copyright 2004-2022 Internet Systems Consortium. 2024-02-05T22:19:06.377190-05:00 darkstar dhclient[620]: All rights reserved. 2024-02-05T22:19:06.377201-05:00 darkstar dhclient[620]: For info, please visit https://www.isc.org/software/dhcp/ 2024-02-05T22:19:06.377213-05:00 darkstar dhclient[620]: 2024-02-05T22:19:06.675691-05:00 darkstar dhclient[620]: Listening on LPF/eno1/XX:XX:XX:XX:XX:XX 2024-02-05T22:19:06.675765-05:00 darkstar ifup[620]: Listening on LPF/eno1/XX:XX:XX:XX:XX:XX 2024-02-05T22:19:06.675783-05:00 darkstar ifup[620]: Sending on LPF/eno1/XX:XX:XX:XX:XX:XX 2024-02-05T22:19:06.675796-05:00 darkstar ifup[620]: Sending on Socket/fallback 2024-02-05T22:19:06.675831-05:00 darkstar dhclient[620]: Sending on LPF/eno1/XX:XX:XX:XX:XX:XX 2024-02-05T22:19:06.675863-05:00 darkstar dhclient[620]: Sending on Socket/fallback 2024-02-05T22:19:06.675919-05:00 darkstar dhclient[620]: DHCPREQUEST for 192.168.1.2 on eno1 to 255.255.255.255 port 67 2024-02-05T22:19:06.675956-05:00 darkstar ifup[620]: DHCPREQUEST for 192.168.1.2 on eno1 to 255.255.255.255 port 67 2024-02-05T22:19:09.219179-05:00 darkstar kernel: [6.436538] e1000e :00:1f.6 eno1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx 2024-02-05T22:19:09.219201-05:00 darkstar kernel: [6.436674] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready 2024-02-05T22:19:11.467192-05:00 darkstar dhclient[620]: DHCPREQUEST for 192.168.1.2 on eno1 to 255.255.255.255 port 67 2024-02-05T22:19:11.467252-05:00 darkstar ifup[620]: DHCPREQUEST for 192.168.1.2 on eno1 to 255.255.255.255 port 67 2024-02-05T22:19:11.470106-05:00 darkstar dhclient[620]: DHCPACK of 192.168.1.2 from 192.168.1.1 2024-02-05T22:19:11.470172-05:00 darkstar ifup[620]: DHCPACK of 192.168.1.2 from 192.168.1.1 2024-02-05T22:19:11.509438-05:00 darkstar dhclient[620]: bound to 192.168.1.2 -- renewal in 21284 seconds. 2024-02-05T22:19:11.509497-05:00 darkstar ifup[620]: bound to 192.168.1.2 -- renewal in 21284 seconds. 2024-02-05T22:19:11.575017-05:00 darkstar kernel: [8.793246] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information. 2024-02-05T22:19:11.575027-05:00 darkstar kernel: [8.793252] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld . All Rights Reserved. 2024-02-05T22:19:11.589364-05:00 darkstar ifup[689]: Error: ipv4: FIB table does not exist. 2024-02-05T22:19:11.589373-05:00 darkstar ifup[689]: Flush terminated 2024-02-05T22:19:11.589765-05:00 darkstar ifup[583]: ifup: failed to bring up wg0 2024-02-05T22:19:11.599118-05:00 darkstar systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE 2024-02-05T22:19:11.663575-05:00 darkstar systemd[1]: networking.service: Failed with result 'exit-code'. 2024-02-05T22:19:11.664060-05:00 darkstar systemd[1]: Failed to start networking.service - Raise network interfaces. 2024-02-05T22:19:11.664996-05:00 darkstar systemd[1]: Reached target network.target - Network. 2024-02-05T22:19:11.665371-05:00 darkstar systemd[1]: Reached target network-online.target - Network is Online.
Bug#1063365: src:python-cryptography: unsatisfied build dependency in testing: librust-pyo3-0.19-dev
Jeremy, please have a look, thanks On Tue, Feb 6, 2024 at 3:39 PM Paul Gevers wrote: > > Source: python-cryptography > Version: 41.0.7-2 > Severity: serious > Tags: sid trixie > User: debian...@lists.debian.org > Usertags: edos-uninstallable > > Dear maintainer(s), > > Dose [1] is reporting a build issue with your package, it's missing a > build dependency. Obviously your build dependencies shouldn't be > removed from testing, but unfortunately there are multiple scenarios > where that can happen nevertheless. To uphold our social contract, > Debian requires that packages can be rebuild from source in the suite > we are shipping them, so currently this is a serious issue with your > package in testing. > > Can you please investigate the situation and figure out how to resolve > it? Regularly, if the build dependency is available in unstable, > helping the maintainer of your Build-Depends to enable migration to > testing is a great way to solve the issue. If your build dependency is > gone from unstable and testing, you'll have to fix the build process > in some other way. > > Paul > > Note: this bug report was sent after some quick manual checks using a > template. Please reach out to me if you believe I made a mistake in my > process. > > [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html > -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#1003098: joe: diff for NMU version 4.6-1.2
Control: tags 1003098 + pending
Dear maintainer,
I've prepared an NMU for joe (versioned as 4.6-1.2) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.
Regards.
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
diff -Nru joe-4.6/debian/changelog joe-4.6/debian/changelog
--- joe-4.6/debian/changelog 2023-02-14 23:52:07.0 +0100
+++ joe-4.6/debian/changelog 2024-02-06 22:21:39.0 +0100
@@ -1,3 +1,11 @@
+joe (4.6-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix "crash at encoding prompt":
+Add patch from upstream repo (closes: #1003098).
+
+ -- gregor herrmann Tue, 06 Feb 2024 22:21:39 +0100
+
joe (4.6-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru joe-4.6/debian/patches/005_crash_encoding_completion.patch joe-4.6/debian/patches/005_crash_encoding_completion.patch
--- joe-4.6/debian/patches/005_crash_encoding_completion.patch 1970-01-01 01:00:00.0 +0100
+++ joe-4.6/debian/patches/005_crash_encoding_completion.patch 2024-02-06 17:05:56.0 +0100
@@ -0,0 +1,60 @@
+Description: Fix "Completion at encoding prompt crashes"
+Origin: https://sourceforge.net/p/joe-editor/mercurial/ci/72ca4cecf0aef6348287f5541c03c5a34c87226c/
+Bug: https://sourceforge.net/p/joe-editor/bugs/391/
+Bug-Debian: https://bugs.debian.org/1003098
+
+--- a/joe/options.c
b/joe/options.c
+@@ -1011,7 +1011,7 @@
+ /* Load first from global (NOTE: Order here does not matter.) */
+ if (!chpwd(buf) && (t = rexpnd(wildcard))) {
+ for (x = 0; x < aLEN(t); ++x) {
+-*zrchr(t[x], '.') = 0;
++if (extension) *zrchr(t[x], '.') = 0;
+ for (y = 0; y < aLEN(ary); ++y)
+ if (!zcmp(t[x], ary[y]))
+ break;
+@@ -1020,6 +1020,7 @@
+ }
+
+ varm(t);
++ t = NULL;
+ }
+ }
+
+@@ -1031,7 +1032,7 @@
+
+ if (!chpwd(buf) && (t = rexpnd(wildcard))) {
+ for (x = 0; x < aLEN(t); ++x) {
+- *zrchr(t[x],'.') = 0;
++ if (extension) *zrchr(t[x],'.') = 0;
+ for (y = 0; y < aLEN(ary); ++y)
+ if (!zcmp(t[x],ary[y]))
+ break;
+@@ -1040,6 +1041,7 @@
+ }
+
+ varm(t);
++t = NULL;
+ }
+ }
+ }
+@@ -1050,7 +1052,7 @@
+ t = jgetbuiltins(wildcard);
+
+ for (x = 0; x < aLEN(t); ++x) {
+- *zrchr(t[x], '.') = 0;
++ if (extension) *zrchr(t[x], '.') = 0;
+ for (y = 0; y < aLEN(ary); ++y)
+ if (!zcmp(t[x], ary[y]))
+ break;
+@@ -1058,6 +1060,9 @@
+ ary = vaadd(ary, vsncpy(NULL, 0, sv(t[x])));
+ }
+ }
++
++ varm(t);
++ t = NULL;
+ }
+
+ varm(t);
diff -Nru joe-4.6/debian/patches/series joe-4.6/debian/patches/series
--- joe-4.6/debian/patches/series 2016-11-06 14:42:00.0 +0100
+++ joe-4.6/debian/patches/series 2024-02-06 16:36:05.0 +0100
@@ -2,3 +2,4 @@
002_mail_jsf_ugly.patch
003_setlocale_codeset.patch
004_debcontrol_syntax.patch
+005_crash_encoding_completion.patch
signature.asc
Description: Digital Signature
Bug#1063369: aide: Don't require s-nail to send email, other setups (e.g. postfix+bsd-mailx) work as well
Package: aide Version: 0.18.3-1+deb12u2 Severity: normal Dear Maintainers, since Debian Bookworm, aide refuses to send emails by default if s-nail is not installed. The documentation (README.Debian.gz in aide-common) falsely claims that /usr/lib/sendmail requires suid and that this affects bsd-mailx. Well, first of all, bsd-mailx doesn't even provide /usr/lib/sendmail, so this is misleading. In addition, there are (popular) MTAs that don't install /usr/lib/sendmail with the suid bit set, e.g. postfix. I have postfix configured to send out mail via a smarthost only, without any local mail delivery. I also disabled the smtpd daemon listening on port 25, so mail is sent via mailx/sendmail. And that works just fine with aide, even as non-root under systemd. I have set MAILCMD="/usr/bin/mailx" in /etc/default/aide in order to "convince" aide to send mail despite not having s-nail installed. The downside is that my custom MAILSUBJ is ignored now since Debian Bookworm. I would suggest to not hardcode a (soft) dependency on s-nail into the script. I think it would be better to merely warn people upon upgrading that sending mail may not work as non-root under systemd if the MTA requries suid and that s-nail might solve that. But don't add artificial restrictions or checks. If mail delivery breaks for some, then they know they need s-nail, but the rest can just keep using their known MTA setup. Kind regards, Timo
Bug#1063149: [Pkg-samba-maint] Bug#1063149: "SyntaxWarning: invalid escape sequence '\s'" errors on updating
On Mon, 2024-02-05 at 15:57 +0300, Michael Tokarev wrote: > 05.02.2024 14:51, Daniel Vacek: > > Setting up python3-samba (2:4.19.4+dfsg-3) > > .../usr/lib/python3/dist- > > packages/samba/tests/dns_forwarder_helpers/server.py:80:SyntaxWarni > > ng: invalid escape sequence '\s' > .. > > I guess this could be backported till new upstream version is > > packaged. > > This is a wontfix for now. I already did similar fix before for > #1057668(added a backported patch python-fix-invalid-escape- > sequences.patch). > These are just warnings, a minor annoyance, nothing more.Hopefully > will be fixed by the next upstream version. > /mjt Daniel and Erwan, While I know it isn't standard Debian practice, please report this kind of thing upstream to the Samba bugzilla if possible. In this case I will note that this is fixed in Samba master and will be released in Samba 4.20. commit 26ff87dcfeaf5a2aff5f28c0aa5d99437c79a68cAuthor: Joseph Sutton < josephsut...@catalyst.net.nz>Date: Mon Sep 11 11:59:34 2023 +1200 python:tests: Fix invalid escape sequencesSigned-off-by: Joseph Sutton Reviewed-by: Andrew Bartlett (Why any code under 'tests' is being installed onto production systems is a different matter, probably worthy of a different bug in both places). Andrew Bartlett -- Andrew Bartlett (he/him) https://samba.org/~abartlet/ Samba Team Member (since 2001) https://samba.org Samba Team Leadhttps://catalyst.net.nz/services/samba Catalyst.Net Ltd Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group company Samba Development and Support: https://catalyst.net.nz/services/samba Catalyst IT - Expert Open Source Solutions
Bug#1063356: Acknowledgement (debdelta: `debdelta-upgrade` generates file with wrong name (encoded + as %2b))
Oh, and I finally did manage to recover the output where I noticed the problem (from a script which runs debdelta-upgrade` followed by `aptitude upgrade`): [...] Recreated debs are saved in the directory /var/cache/apt/archives Deltas: 1 present and 0 not, downloaded so far: time 0.23sec, size 10kB, speed 43kB/sec. Need to get 21kB of deltas. Downloaded, time 0.04sec, speed 311kB/sec, libzbar0_0.23.92-7_0.23.92-7+deb12u1_amd64.debdelta Patching done, time 0.14sec, speed 886k/sec (script 0.11sec 1153k/sec)(unaccounted 0.03sec) Created,time 0.14sec, speed 886kB/sec, libzbar0_0.23.92-7%2bdeb12u1_amd64.deb Delta-upgrade statistics: downloaded deltas, size 21kB time 0sec speed 79kB/sec patching to debs, size 126kB time 0sec speed 885kB/sec total resulting debs, size 126kB time 0sec virtual speed 132kB/sec Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be upgraded: libzbar0 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 130 kB of archives. After unpacking 0 B will be used. Do you want to continue? [Y/n/?] Get: 1 http://security.debian.org stable-security/main amd64 libzbar0 amd64 0.23.92-7+deb12u1 [130 kB] Fetched 130 kB in 0s (880 kB/s) Retrieving bug reports... Done Parsing Found/Fixed information... Done Reading changelogs... Done (Reading database ... 465771 files and directories currently installed.) Preparing to unpack .../libzbar0_0.23.92-7+deb12u1_amd64.deb ... Unpacking libzbar0:amd64 (0.23.92-7+deb12u1) over (0.23.92-7) ... Setting up libzbar0:amd64 (0.23.92-7+deb12u1) ... Processing triggers for libc-bin (2.36-9+deb12u4) ... [...] - Stefan
Bug#1063368: kate: Shift-key not working
Package: kate Version: 4:22.12.3-1 Severity: important Dear Maintainer, The shift key has no effect when writing (e.g. Shift+a results in 'a' instead of 'A'). Some general observations about the probelm itself: - Caps lock works. - Shift hotkeys work (e.g. Shift+Left in order to mark the character left of the cursor). - Alt Gr has the same problem (I changed my keybooard layout to german and Alt Gr+q prints 'q' instead of '@'). - Some other applications have the same issue (e.g. kwrite, vlc, texstudio, wireshark). I think all my Qt-applications do, but Qt might also be unrelated. Other applications such as xfce4-terminal or firefox work flawlessly. With "distrobox" I created a container for debian stable (like mine) and debian testing, and the problem occurs only in the "stable" conteiner. Therefore, I don't think it's some configuration error of mine. Also, this suggests that the bug has been fixed in more recent package versions. However, those are not available yet for stable via apt upgrade. stable: image: quay.io/toolbx-images/archlinux-toolbox:latest Qt-Version (kate): 5.15.8 kate-Version: 22.12.3 testing: image: docker.io/library/debian:testing Qt-Version (kate): 5.15.10 kate-Version: 23.08.1 Sorry if I made any errors in posting this bug report, as it appears to be fixed in more recent kate versions. I dont know anything about the inner working or policies of debian. -- 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.1.0-17-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.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 kate depends on: ii kate5-data 4:22.12.3-1 ii kio 5.103.0-1 ii ktexteditor-katepart 5.103.0-1.1 ii libc62.36-9+deb12u4 ii libkf5activities55.103.0-1 ii libkf5bookmarks5 5.103.0-1 ii libkf5completion55.103.0-1 ii libkf5configcore55.103.0-2 ii libkf5configgui5 5.103.0-2 ii libkf5configwidgets5 5.103.0-1 ii libkf5coreaddons55.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5dbusaddons55.103.0-1 ii libkf5guiaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5iconthemes55.103.0-1 ii libkf5jobwidgets55.103.0-1 ii libkf5kiocore5 5.103.0-1 ii libkf5kiofilewidgets55.103.0-1 ii libkf5kiogui55.103.0-1 ii libkf5kiowidgets55.103.0-1 ii libkf5newstuff5 5.103.0-1 ii libkf5newstuffcore5 5.103.0-1 ii libkf5newstuffwidgets5 5.103.0-1 ii libkf5parts5 5.103.0-1 ii libkf5service-bin5.103.0-1 ii libkf5service5 5.103.0-1 ii libkf5syntaxhighlighting55.103.0-3 ii libkf5texteditor55.103.0-1.1 ii libkf5textwidgets5 5.103.0-1 ii libkf5wallet-bin 5.103.0-1 ii libkf5wallet55.103.0-1 ii libkf5widgetsaddons5 5.103.0-1 ii libkf5windowsystem5 5.103.0-1 ii libkf5xmlgui55.103.0-1 ii libkuserfeedbackcore11.2.0-2 ii libkuserfeedbackwidgets1 1.2.0-2 ii libqt5concurrent55.15.8+dfsg-11 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 libqt5sql5 5.15.8+dfsg-11 ii libqt5widgets5 5.15.8+dfsg-11 ii libqt5xml5 5.15.8+dfsg-11 ii libstdc++6 12.2.0-14 ii plasma-framework 5.103.0-1+deb12u1 ii qml-module-org-kde-kquickcontrolsaddons 5.103.0-1 ii qml-module-qtquick-layouts 5.15.8+dfsg-3 ii qml-module-qtquick2 5.15.8+dfsg-3 Versions of packages kate recommends: ii sonnet-plugins 5.103.0-1 Versions of packages kate suggests: pn darcs pn exuberant-ctags ii git
Bug#1063367: RFS: python-qmix/1.0.6-7 -- Quantum Mixing software
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: kd8...@gmail.com Dear mentors, I am looking for a sponsor for my package "python-qmix": * Package name : python-qmix Version : 1.0.6-7 Upstream contact : John Garrett * URL : https://github.com/garrettj403/QMix * License : GPL-3 * Vcs : https://salsa.debian.org/yogu/python-qmix Section : python The source builds the following binary packages: python3-qmix - Quantum Mixing software To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-qmix/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-qmix/python-qmix_1.0.6-7.dsc Changes since the last upload: python-qmix (1.0.6-7) unstable; urgency=medium . * Included patch for removing python3-numba depends. * Removed python3-numba from d/control and d/tests/control. * Added 2024 to debian/* in copyright. Regards, -- Yogeswaran Umasankar
Bug#1055966: bookworm-pu: package openvpn-dco-dkms/0.0+git20230324-1+deb12u1 (or 0.0+git20231103-0+deb12u1?)
Hi Jonathan, On Tue, Nov 14, 2023 at 11:26:54PM +0100, Bernhard Schmidt wrote: [ Reason ] openvpn-dco-dkms packages an accelerator kernel module for OpenVPN (OpenVPN data channel offload). There is one annoying bug tracked as Bug#1055809 where on heavily loaded TCP servers a refcount issue might occur and the module will become unusable. This request was approved but not uploaded in time for the previous point release (12.5). Should it be included in 12.6, or should this request be abandoned and closed? Sorry, my bad, I'm getting old. I'm still interested. Considering the version in unstable is currently 0.0+git20231103-1 should the upload be versioned 0.0+git20231103-0+deb12u1 (like originally proposed) or 0.0+git20231103-1~deb12u1 ? Bernhard
Bug#1057107: bullseye-pu: package libssh2/1.9.0-2
Hi Nicolas, On Tue, Feb 06, 2024 at 01:46:04PM -0500, Nicolas Mora wrote: > Control: tag - moreinfo > > Thanks, > > Sorry, it seems that I'm not very well aware of the BTS process, according > to [1] this is how I should untag the bug. > > [1] https://www.debian.org/Bugs/server-control If you provide the moreinfo which was requested, then you can remove the tag as follows (or with an equivalent control command, e.g. using -1 for the bug if directly interacting with the bug). tags 1057107 - moreinfo Hope this helps, too bad we missed for this upload the 11.9. Regards, Salvatore
Bug#1062189: simple-cdd: Linux Kernel of generated ISO (.udeb) and Kernel to be installed (.deb) don't match
Fortunately, I was able to find a workaround. At least for my case, the DebianInstaller was complaining about kernel modules. So I tried to add these via the variable kernel_packages in the NAME.conf file. My d-i is of version v.6.1.0-15, so I added the following di packages by stating: kernel_packages="linux-image-amd64 kernel-image-6.1.0-15-amd64-di efi-modules-6.1.0-15-amd64-di ext4-modules-6.1.0-15-amd64-di md-modules-6.1.0-15-amd64-di sata-modules-6.1.0-15-amd64-di nic-modules-6.1.0-15-amd64-di" Depending on your needs, I guess you might need other kernel modules. Also note linux-image-amd64 in the beginning, that's the default value for kernel_packages. With this additional setting, the DebianInstaller does not complain anymore and produces a functional installation! Not a real solution though. Why doesn't Simple-CDD pull these packages automatically? And why doesn't it pull the latest stable d-i version (v6.1.0-17 at the time of writing) in the first place? On Sun, 4 Feb 2024 15:54:10 +0100 Sietze van Buuren wrote: > I have observed similar behavior. > > Also trying to build on and for Debian 12 (Bookworm). Simple-CDD finishes > successfully, but fails to create a working installer. > The installer complains that it can't find any matching kernel modules. > > Kernel version for the Debian Installer: > /tmp/simple-cdd/tmp/cd-build/bookworm/CD1/install.amd/vmlinuz: Linux kernel > x86 boot executable bzImage, version 6.1.0-15-amd64 ( > debian-ker...@lists.debian.org) #1 SMP PREEMPT_DYNAMIC Debian 6.1.66-1 > (2023-12-09), RO-rootFS, swap_dev 0x7, Normal VGA > Kernel version to be installed: > /tmp/simple-cdd/tmp/cd-build/bookworm/CD1/pool/main/l/linux-signed-amd64/linux-image-6.1.0-17-amd64_6.1.69-1_amd64.deb > > I tried to replace the to be installed kernel version > linux-image-6.1.0-17-amd64 with linux-image-6.1.0-15-amd64 to no avail. > (Using Vagrant's instructions here: > https://lists.debian.org/debian-custom/2009/03/msg6.html). > > Any suggestions for a workaround? > > On Wed, 31 Jan 2024 17:02:50 +0100 Marcel Bosling < > marcel.bosl...@steinert.de> wrote: > > Package: simple-cdd > > Version: 0.6.9 > > Severity: important > > X-Debbugs-Cc: marcel.bosl...@steinert.de > > > > When building on/for Debian 12, the kernel to start d-i is > kernel-image-6.1.0-16-amd64-di_6.1.67-1_amd64.udeb > > but linux-image-6.1.0-17-amd64_6.1.69-1_amd64.deb (from security) is the > installation candidate resulting in d-i not being able > > to find a proper kernel during installation. > > > > Funnily kernel-image-6.1.0-17-amd64-di_6.1.69-1_amd64.udeb exists in > > > > > http://security.debian.org/debian-security/pool/updates/main/l/linux-signed-amd64/kernel-image-6.1.0-17-amd64-di_6.1.69-1_amd64.udeb > > > > but is not considered while creating the image. > > > > > > > > -- 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.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT) > > 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) > > LSM: AppArmor: enabled > > > > Versions of packages simple-cdd depends on: > > ii dctrl-tools 2.24-3+b1 > > ii debian-cd 3.2.1
Bug#1063366: src:syncthing: fails to migrate to testing for too long: new Build-Depends not migrating
Source: syncthing Version: 1.19.2~ds1-3 Severity: serious Control: close -1 1.27.2~ds4-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:syncthing has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable Build-Depends on a new package that needs manual actions before it can migrate. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=syncthing OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063334: iraf: IRAF's desktop file has disappeared
Hi Peter, oops, the desktop file and the icon were forgotten when the installation procedure was changed in 2.17.1. I will upload a new Debian package with these files included. The "irafcl" script is mentioned in /usr/share/docs/iraf/README.Debian; I agree that this is not the first place to look (although it is the canonical path for Debian specific READMEs). For the next upstream version it is planned to also switch to irafcl (but still have compatibility links for cl/ecl); this should be described in the upstream release notes then. I am happy to get suggestions on how to improve this. Thank you for the report! Best Ole
Bug#1063365: src:python-cryptography: unsatisfied build dependency in testing: librust-pyo3-0.19-dev
Source: python-cryptography Version: 41.0.7-2 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063364: nvidia-cuda-samples: autopkgtest needs update for new version of linux
Source: nvidia-cuda-samples Version: 12.1~dfsg-1 Severity: serious X-Debbugs-CC: li...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:linux Dear maintainer(s), With a recent upload of linux the autopkgtest of nvidia-cuda-samples fails in testing when that autopkgtest is run with the binary packages of linux from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing6.6.15-2 nvidia-cuda-samplesfrom testing12.1~dfsg-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of linux to testing [1]. Of course, linux shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in linux was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from linux should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-cuda-samples/42760273/log.gz 1664s I: Testing binary package nvidia-fs-dkms 1664s I: Trying to install build dependency nvidia-current/525.147.05 for 6.6.15-amd64 1664s Sign command: /lib/modules/6.6.15-amd64/build/scripts/sign-file 1664s Signing key: /var/lib/dkms/mok.key 1664s Public certificate (MOK): /var/lib/dkms/mok.pub 1664s Certificate or key are missing, generating self signed certificate for MOK... 1664s Creating symlink /var/lib/dkms/nvidia-current/525.147.05/source -> /usr/src/nvidia-current-525.147.05 1664s 1664s Building module: 1665s Cleaning build area... 1686s env NV_VERBOSE=1 make -j64 modules KERNEL_UNAME=6.6.15-amd64..(bad exit status: 2) 1686s Error! Bad return status for module build on kernel: 6.6.15-amd64 (x86_64) 1686s Consult /var/lib/dkms/nvidia-current/525.147.05/build/make.log for more information. 1686s autopkgtest [06:12:31]: test dkms-autopkgtest-nvidia-fs OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063363: nvidia-graphics-drivers: autopkgtest needs update for new version of linux
Source: nvidia-graphics-drivers Version: 525.147.05-5 Severity: serious X-Debbugs-CC: li...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:linux Dear maintainer(s), With a recent upload of linux the autopkgtest of nvidia-graphics-drivers fails in testing when that autopkgtest is run with the binary packages of linux from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing6.6.15-2 nvidia-graphics-drivers from testing525.147.05-5 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of linux to testing [1]. Of course, linux shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in linux was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from linux should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-graphics-drivers/42760274/log.gz 810s # MODPOST /usr/src/modules/nvidia-kernel/Module.symvers 810sscripts/mod/modpost -M -m -o /usr/src/modules/nvidia-kernel/Module.symvers -T /usr/src/modules/nvidia-kernel/modules.order -i Module.symvers -e 811s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_unlock' 811s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock' 811s make[6]: *** [/usr/src/linux-headers-6.6.15-common/scripts/Makefile.modpost:145: /usr/src/modules/nvidia-kernel/Module.symvers] Error 1 811s make[5]: *** [/usr/src/linux-headers-6.6.15-common/Makefile:1890: modpost] Error 2 811s make[4]: *** [/usr/src/linux-headers-6.6.15-common/Makefile:246: __sub-make] Error 2 811s make[4]: Leaving directory '/usr/src/linux-headers-6.6.15-cloud-amd64' 811s make[3]: *** [Makefile:246: __sub-make] Error 2 811s make[3]: Leaving directory '/usr/src/linux-headers-6.6.15-common' 811s make[2]: *** [Makefile:82: modules] Error 2 811s make[2]: Leaving directory '/usr/src/modules/nvidia-kernel' 811s make[1]: *** [debian/rules:39: binary-modules] Error 2 811s make[1]: Leaving directory '/usr/src/modules/nvidia-kernel' 811s make: *** [/usr/share/modass/include/common-rules.make:56: kdist_build] Error 2 811s tput: No value for $TERM and no -T specified 811s BUILD FAILED! 811s tput: No value for $TERM and no -T specified 811s See /var/cache/modass/nvidia-kernel-source.buildlog.6.6.15-cloud-amd64.1707198843 for details. 811s Build failed. Press Return to continue... 811s I: nvidia-kernel does not support the 6.6.15-rt-amd64 kernel (!CONFIG_PREEMPT_RT) 811s I: Summary: 811s I: FAIL nvidia-kernel 6.6.15-amd64 (7) 811s I: FAIL nvidia-kernel 6.6.15-cloud-amd64 (7) 811s I: SKIP nvidia-kernel 6.6.15-rt-amd64 (!CONFIG_PREEMPT_RT) 811s autopkgtest [05:58:24]: test m-a-autopkgtest OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063362: nvidia-graphics-drivers-tesla: autopkgtest needs update for new version of linux
Source: nvidia-graphics-drivers-tesla Version: 525.147.05-5 Severity: serious X-Debbugs-CC: li...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:linux Dear maintainer(s), With a recent upload of linux the autopkgtest of nvidia-graphics-drivers-tesla fails in testing when that autopkgtest is run with the binary packages of linux from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing6.6.15-2 nvidia-graphics-drivers-tesla from testing525.147.05-5 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of linux to testing [1]. Of course, linux shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in linux was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from linux should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-graphics-drivers-tesla/42735533/log.gz 202s # MODPOST /usr/src/modules/nvidia-tesla-kernel/Module.symvers 202sscripts/mod/modpost -M -m -o /usr/src/modules/nvidia-tesla-kernel/Module.symvers -T /usr/src/modules/nvidia-tesla-kernel/modules.order -i Module.symvers -e 203s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_unlock' 203s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock' 203s make[6]: *** [/usr/src/linux-headers-6.6.15-common/scripts/Makefile.modpost:145: /usr/src/modules/nvidia-tesla-kernel/Module.symvers] Error 1 203s make[5]: *** [/usr/src/linux-headers-6.6.15-common/Makefile:1890: modpost] Error 2 203s make[4]: *** [/usr/src/linux-headers-6.6.15-common/Makefile:246: __sub-make] Error 2 203s make[4]: Leaving directory '/usr/src/linux-headers-6.6.15-cloud-amd64' 203s make[3]: *** [Makefile:246: __sub-make] Error 2 203s make[3]: Leaving directory '/usr/src/linux-headers-6.6.15-common' 203s make[2]: *** [Makefile:82: modules] Error 2 203s make[2]: Leaving directory '/usr/src/modules/nvidia-tesla-kernel' 203s make[1]: *** [debian/rules:39: binary-modules] Error 2 203s make[1]: Leaving directory '/usr/src/modules/nvidia-tesla-kernel' 203s make: *** [/usr/share/modass/include/common-rules.make:56: kdist_build] Error 2 203s tput: No value for $TERM and no -T specified 203s BUILD FAILED! 203s tput: No value for $TERM and no -T specified 203s See /var/cache/modass/nvidia-tesla-kernel-source.buildlog.6.6.15-cloud-amd64.1707107102 for details. 203s Build failed. Press Return to continue... 203s I: nvidia-tesla-kernel does not support the 6.6.15-rt-amd64 kernel (!CONFIG_PREEMPT_RT) 203s I: Summary: 203s I: FAIL nvidia-tesla-kernel 6.6.15-amd64 (7) 203s I: FAIL nvidia-tesla-kernel 6.6.15-cloud-amd64 (7) 203s I: SKIP nvidia-tesla-kernel 6.6.15-rt-amd64 (!CONFIG_PREEMPT_RT) 203s autopkgtest [04:25:29]: test m-a-autopkgtest OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056331: qemu-user-static: fails to run any binary with message "error while loading shared libraries" on Apple Silicon
Control: tag -1 forwarded https://gitlab.com/qemu-project/qemu/-/issues/1591 FWIW.
Bug#1063361: nvidia-graphics-drivers-tesla-470: autopkgtest needs update for new version of linux
Source: nvidia-graphics-drivers-tesla-470 Version: 470.223.02-3 Severity: serious X-Debbugs-CC: li...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:linux Dear maintainer(s), With a recent upload of linux the autopkgtest of nvidia-graphics-drivers-tesla-470 fails in testing when that autopkgtest is run with the binary packages of linux from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing6.6.15-2 nvidia-graphics-drivers-tesla-470 from testing470.223.02-3 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of linux to testing [1]. Of course, linux shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in linux was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from linux should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-graphics-drivers-tesla-470/42735534/log.gz 320s # MODPOST /var/lib/dkms/nvidia-tesla-470/470.223.02/build/Module.symvers 320sscripts/mod/modpost -M -m -o /var/lib/dkms/nvidia-tesla-470/470.223.02/build/Module.symvers -T /var/lib/dkms/nvidia-tesla-470/470.223.02/build/modules.order -i Module.symvers -e 320s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_unlock' 320s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock' 320s make[4]: *** [/usr/src/linux-headers-6.6.15-common/scripts/Makefile.modpost:145: /var/lib/dkms/nvidia-tesla-470/470.223.02/build/Module.symvers] Error 1 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1062044: qemu 7.2+dfsg-7+deb12u5 flagged for acceptance
package release.debian.org tags 1062044 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: qemu Version: 7.2+dfsg-7+deb12u5 Explanation: revert patch causing regressions in suspend / resume functionality
Bug#1063360: RM: ruby-ami -- RoQA; low popcon, no upstream activity, orphaned
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ruby-...@packages.debian.org Control: affects -1 + src:ruby-ami Dear ftpmasters, recently ruby-ami has been orphaned [0]. It has no reverse (build) dependencies and a very low popcon. The only maintainer upload was in 2016. 2016 was also the last time there was an upstream commit. The previous maintainer is also okay with an RM [0]. Thanks and kind regards, Reiner [0] #1063021
Bug#1063359: gdb-mingw-w64: FTBFS on arm64 due to arch-specific build flag: -mbranch-protection=standard
Source: gdb-mingw-w64 Version: 13 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: sid trixie ftbfs patch User: debian-...@lists.debian.org Usertags: arm64 Hi, arm64 now has an architecture-specific flag among the default build flags: -mbranch-protection=standard. gdb-mingw-w64 calls dpkg-buildflags on the build system, which on arm64 looks like this: $ dpkg-buildflags --get CFLAGS -g -O2 -ffile-prefix-map=/tmp/gdb-mingw-w64-13=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard The output of the above command is then passed to the configure script of the various targets (i686-w64-mingw32 and x86_64-w64-mingw32), resulting in the following FTBFS on arm64: checking for i686-w64-mingw32-gcc... i686-w64-mingw32-gcc-posix checking whether the C compiler works... no configure: error: in `/tmp/gdb-mingw-w64-13/build-gdbserver/i686-w64-mingw32/gnulib': configure: error: C compiler cannot create executables See `config.log' for more details And indeed config.log points out the issue: i686-w64-mingw32-gcc-posix: error: unrecognized command-line option '-mbranch-protection=standard' I propose in the attached patch to use DEB_HOST_ARCH and ensure that i686-specific flags are used when building for i686, ditto for amd64. Emanuele diff -Nru gdb-mingw-w64-13/debian/changelog gdb-mingw-w64-13+nmu1/debian/changelog --- gdb-mingw-w64-13/debian/changelog 2023-09-29 17:54:37.0 +0200 +++ gdb-mingw-w64-13+nmu1/debian/changelog 2024-02-06 20:23:38.0 +0100 @@ -1,3 +1,11 @@ +gdb-mingw-w64 (13+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Use DEB_HOST_ARCH to avoid setting potentially arch-specific build flags. +Closes: -1. + + -- Emanuele Rocca Tue, 06 Feb 2024 20:23:38 +0100 + gdb-mingw-w64 (13) unstable; urgency=medium * Switch from the obsolete libncurses5-dev build-dependency to diff -Nru gdb-mingw-w64-13/debian/rules gdb-mingw-w64-13+nmu1/debian/rules --- gdb-mingw-w64-13/debian/rules 2023-09-29 13:47:46.0 +0200 +++ gdb-mingw-w64-13+nmu1/debian/rules 2024-02-06 20:23:38.0 +0100 @@ -69,6 +69,7 @@ override_dh_auto_configure-arch: unpack-stamp set -e; \ for target in $(targets); do \ + host_arch=$(shell echo $target | grep -q ^i686 && echo i686 || echo amd64); \ mkdir -p $(build_gdb_dir)/$$target; \ cd $(build_gdb_dir)/$$target; \ $(upstream_dir)/configure \ @@ -77,7 +78,7 @@ --with-system-readline --with-system-zlib \ --enable-tui --with-expat --with-python=python3 \ --target=$$target --disable-werror \ - $(shell $(dpkg_buildflags_arch) --export=cmdline); \ + $(shell DEB_HOST_ARCH=$host_arch $(dpkg_buildflags_arch) --export=cmdline); \ done # We're only interested in gdbserver; that also requires gnulib, libiberty, and gdbsupport @@ -85,6 +86,7 @@ override_dh_auto_configure-indep: unpack-stamp set -e; \ for target in $(targets); do \ + host_arch=$(shell echo $target | grep -q ^i686 && echo i686 || echo amd64); \ for project in $(gdbserver_projects); do \ mkdir -p $(build_gdbserver_dir)/$$target/$$project; \ cd $(build_gdbserver_dir)/$$target/$$project; \ @@ -93,22 +95,24 @@ --host=$$target --target=$$target \ CC=$$target-gcc-posix CXX=$$target-g++-posix \ --disable-werror \ -$(shell $(dpkg_buildflags_indep) --export=cmdline); \ +$(shell DEB_HOST_ARCH=$host_arch $(dpkg_buildflags_indep) --export=cmdline); \ done; \ done override_dh_auto_build-arch: set -e; \ for target in $(targets); do \ - $(shell $(dpkg_buildflags_arch) --export=sh); \ + host_arch=$(shell echo $target | grep -q ^i686 && echo i686 || echo amd64); \ + $(shell DEB_HOST_ARCH=$host_arch $(dpkg_buildflags_arch) --export=sh); \ dh_auto_build --parallel -B$(build_gdb_dir)/$$target -- V=1; \ done override_dh_auto_build-indep: set -e; \ for target in $(targets); do \ + host_arch=$(shell echo $target | grep -q ^i686 && echo i686 || echo amd64); \ for project in $(gdbserver_projects); do \ - $(shell $(dpkg_buildflags_indep) --export=sh); \ + $(shell DEB_HOST_ARCH=$host_arch $(dpkg_buildflags_indep) --export=sh); \ dh_auto_build --parallel -B$(build_gdbserver_dir)/$$target/$$project -- V=1; \ done; \ done
Bug#1062783: libxfce4ui FTCBFS: fails running gtk-doc scanner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2024-02-05 at 20:38 +0100, Helmut Grohne wrote: > Is this line of reasoning convincing to you? Yes indeed, thanks for the explanation then. I'll import the diff to our repository. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXCi3YACgkQ3rYcyPpX RFt4dwf/bXtVCuA9JN+o5DvMscBqVph819yDX7yz3FJJHmDxGOEJpm8qexb/buP1 I0KDPA5AVrEtMpDkJUzRfggg9wIjG1vEo//pIhEPrSZZdTnBA59aQe/2tKnfItX8 7JRORtZQ8AG3wvHg5ZfUXDlSqXgQyGFjD7doNpVpgGvUXEHcGJH5jO07OXI6UgYK OgnGsMCPxhjYlOOhZHubfzVra59i2/8B0QZicNqsA0PtTFsw7hsLbXO/jGa+dRft tbET8DzwYCuO8sjAqEMQY6z6+k0uWp3JwjjVGhaaRtDYbg4xaiD3J8Z2C7Lj5s9h uiLFEE3RHiFcIGcHR1ehXpBOm6DlVA== =f4R0 -END PGP SIGNATURE-
Bug#1057107: bullseye-pu: package libssh2/1.9.0-2
Control: tag +1 moreinfo Thanks,
Bug#1063358: c-blosc2 tests fail with bus errors on armhf
Package: src:c-blosc2 Version: 2.13.1+ds-1 Severity: important Tags: sid trixie c-blosc2 tests fail with bus errors on armhf, only seen on the Ubuntu buildds, which have the alignment checks turned on in the kernel. The following tests FAILED: 1 - test_plugin_test_ndlz (Bus error) 2 - test_plugin_test_zfp_acc_float (Bus error) 3 - test_plugin_test_zfp_prec_float (Bus error) 4 - test_plugin_test_zfp_rate_float (Bus error) 5 - test_plugin_test_zfp_rate_getitem (Bus error) 6 - test_plugin_test_ndcell (Bus error) 7 - test_plugin_ndmean_repart (Bus error) 8 - test_plugin_ndmean_mean (Bus error) 9 - test_plugin_bytedelta (Bus error) 11 - test_b2nd_append (Bus error) 12 - test_b2nd_copy (Bus error) 14 - test_b2nd_delete (Bus error) 15 - test_b2nd_full (Bus error) 16 - test_b2nd_get_slice (Bus error) 17 - test_b2nd_get_slice_buffer (Bus error) 18 - test_b2nd_insert (Bus error) 22 - test_b2nd_resize (Bus error) 23 - test_b2nd_roundtrip (Bus error) 24 - test_b2nd_save (Bus error) 25 - test_b2nd_serialize (Bus error) 26 - test_b2nd_set_slice_buffer (Bus error) 27 - test_b2nd_squeeze (Bus error) 28 - test_b2nd_squeeze_index (Bus error) 30 - test_b2nd_zeros (Bus error) 310 - test_fill_special (Bus error) Errors while running CTest make[2]: *** [Makefile:94: test] Error 8 make[2]: Leaving directory '/<>/obj-arm-linux-gnueabihf' I also checked that building with or without link time optimization doesn't make any difference.
Bug#1057107: bullseye-pu: package libssh2/1.9.0-2
Control: tag -1 moreinfo Thanks,
Bug#1051466: bookworm-pu: package ovn/23.03.1-1~deb12u1
On Tue, 6 Feb 2024 at 18:13, Jonathan Wiltshire wrote: > > Hi, > > On Fri, Sep 08, 2023 at 01:32:05PM +0200, Frode Nordahl wrote: > > We would like to upload the latest stable point release of ovn 23.03 > > to bookworm-p-u. Stable release branches are maintained upstream with > > the intention of providing bug fixes only and no compatibility > > breakages, and with automated non-trivial CI jobs that also cover > > Debian and Ubuntu. > > > > Debdiff attached. Packaging updated with gbp/salsa config for new > > bookworm stable branch and in-flight patches to fix an issue with > > unnecessary logging breaking one of the tests introduced in the point > > release. > > This request was approved but not uploaded in time for the previous point > release (12.5). Should it be included in 12.6, or should this request be > abandoned and closed? Sorry, I missed that this was already approved and I was waiting for a go-ahead. I have done the upload just now.
Bug#1057107: bullseye-pu: package libssh2/1.9.0-2
Control: tag - moreinfo Thanks, Sorry, it seems that I'm not very well aware of the BTS process, according to [1] this is how I should untag the bug. [1] https://www.debian.org/Bugs/server-control
Bug#1022043: Race condition downloading index files.
I've managed to reproduce this issue when many hosts hit apt-cacher-ng
at the same time.
Attached a patch which fixes it for me - this is a quick and hacky
patch!
Sent debug logs of a run that reproduces this problem and a run with
this patch applied directly to the maintainer.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 024f6a0..011ab42 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,5 +1,7 @@
cmake_minimum_required(VERSION 3.1)
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
+
# try to set the best C++ language level
set(CMAKE_CXX_STANDARD 20)
# let it take the lowest version, we need some precursor of C++14x
diff --git a/src/job.cc b/src/job.cc
index a2025cc..5c003a9 100644
--- a/src/job.cc
+++ b/src/job.cc
@@ -662,6 +662,18 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
else
m_sFileLoc=theUrl.sHost+theUrl.sPath;
+ // Here we serialize multiple clients trying to download the
+ // same file. Only one thread at a time per URL is allowed to
+ // proceed further in this function.
+ Lockstuff g{h.getRequestUrl()};
+
+ // Check if another job is running. If so link to that.
+ if(g.stuff->otherThread) {
+ m_pItem = m_pParentCon.GetItemRegistry()->Create(m_sFileLoc, ESharingHow::ALWAYS_TRY_SHARING, fileitem::tSpecialPurposeAttr{});
+ USRDBG("Linked to other job");
+ return;
+ }
+
fileitem::tSpecialPurposeAttr attr {
! cfg::offlinemode && data_type == FILE_VOLATILE,
m_bIsHeadOnly,
@@ -697,8 +709,14 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
if(cfg::trackfileuse && fistate >= fileitem::FIST_DLGOTHEAD && fistate < fileitem::FIST_DLERROR)
m_pItem.get()->UpdateHeadTimestamp();
- if(fistate==fileitem::FIST_COMPLETE)
+ if(fistate==fileitem::FIST_COMPLETE) {
+ // Tell everybody waiting for this thread to complete
+ // where to get their m_pItem and register a cleanup
+ // when this job completes.
+ g.setReturnValue(m_pItem.get());
+ m_ipc = std::make_unique(h.getRequestUrl());
return; // perfect, done here
+ }
if(cfg::offlinemode) { // make sure there will be no problems later in SendData or prepare a user message
// error or needs download but freshness check was disabled, so it's really not complete.
@@ -759,6 +777,11 @@ void job::Prepare(const header , string_view headBuf, cmstring& callerHostname
USRERR("PANIC! Error creating download job for " << m_sFileLoc);
return report_overload(__LINE__);
}
+ // Tell everybody waiting for this thread to complete
+ // where to get their m_pItem and register a cleanup
+ // when this job completes.
+ g.setReturnValue(m_pItem.get());
+ m_ipc = std::make_unique(h.getRequestUrl());
}
}
catch (const std::bad_alloc&) // OOM, may this ever happen here?
@@ -1190,4 +1213,58 @@ void job::AppendMetaHeaders()
<< "\r\nServer: Debian Apt-Cacher NG/" ACVERSION "\r\n"
"\r\n";
}
+
+job::Lockstuff::Lockstuff(const std::string& url_): url(url_) {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ while(true) {
+ auto [it, ins] = inProgress.insert({url, nullptr});
+ if(!ins) {
+ stuff = it->second;
+ if (stuff->otherThread) {
+break;
+ }
+ // Someone is already downloading this. Add ourselves to the waiters.
+ stuff->cv.wait(g._guard);
+ } else {
+ stuff = it->second = std::make_shared();
+ owner = true;
+ break;
+ }
+ }
+}
+
+void job::Lockstuff::setReturnValue(tFileItemPtr tfip) {
+ LOGSTARTFUNC;
+ if (const auto& it = inProgress.find(url); it != inProgress.end()) {
+ stuff->otherThread = tfip;
+ }
+}
+
+job::Lockstuff::~Lockstuff() {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ if(owner) {
+ stuff->cv.notify_all();
+ // After notify_all, any waiting threads are guaranteed to
+ // be blocked on inProgressLock, not on the condition so
+ // it's safe to delete it. However we have to use shared
+ // pointers because we don't know how long it will take the
+ // waiters to read the tFileItemPtr;
+ if (!stuff->otherThread) {
+ inProgress.erase(url);
+ }
+ }
+}
+
+job::inProgressCleanup::~inProgressCleanup() {
+ lockuniq g{inProgressLock};
+ LOGSTARTFUNC;
+ if (const auto& it = inProgress.find(url); it != inProgress.end()) {
+ inProgress.erase(it);
+ }
+}
+
+std::map> job::inProgress;
+base_with_mutex job::inProgressLock;
}
diff --git a/src/job.h b/src/job.h
index cb162a6..97446e2 100644
--- a/src/job.h
+++ b/src/job.h
@@ -16,6 +16,39 @@ class header;
class job
{
+private:
+ // Lock controlling access to inProgress
+ static base_with_mutex inProgressLock;
+
+ // The data that we store in inProgress
+ struct Stuff {
+ std::condition_variable cv;
+ tFileItemPtr otherThread = 0;
+ };
+
+ // Map from URL to Stuff for in progress jobs that are requesting this file.
+ // The entry is "owned" by the job that added it and it is deleted when the job completes.
+ static std::map> inProgress;
+
+ // Where all the real work is done.
+ struct Lockstuff {
+ const std::string
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
06.02.2024 20:55, Adam D. Barratt : On Tue, 2024-02-06 at 20:49 +0300, Michael Tokarev wrote: .. The change isn't small per se, as the commit is rather large (mostly due to many changed tests, - it changes order of output in quite some places). Here's the diffstat: monitor/qmp.c | 17 + qapi/qmp-dispatch.c | 24 +- -- This is the relevant bit for size IMO. If you're happy with the result then please upload as soon as you're ready. Yes, I'm happy with the result. Well, - as much as one can be happy here, choosing between one bug or another, - but it is at least a status-quo and we don't have known regressions in debian stable due to this. I just re-ran upstream testsuite just to be extra sure, and am running my bunch of guests as well, everything works as expected so far. I wont try to reproduce the issues this patch (which I'm reverting) fixed, though ;) Uploaded +deb12u5 now, waiting to be picked up. Thank you for the patience and all the work! /mjt
Bug#1043412: bookworm-pu: package quicktext/5.6
Hi, On Sun, Aug 27, 2023 at 02:37:30PM +0100, Jonathan Wiltshire wrote: > Control: tag -1 moreinfo > > On Thu, Aug 10, 2023 at 04:13:22PM +0200, Mechtilde Stehmann wrote: > > This package is an extension to thunderbird. After thunderbird > > will be updated to version 115.* in bookwork > > it is necessary to update this extension too. > > Thunderbird is not 115 in bookworm at present, and I'm not aware of > currently plans for that to change. Have I missed something? I guess it is now; do you still intend to update this package in bookworm to suit? Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1055966: bookworm-pu: package openvpn-dco-dkms/0.0+git20230324-1+deb12u1 (or 0.0+git20231103-0+deb12u1?)
Hi, On Tue, Nov 14, 2023 at 11:26:54PM +0100, Bernhard Schmidt wrote: > [ Reason ] > openvpn-dco-dkms packages an accelerator kernel module for OpenVPN (OpenVPN > data channel offload). There is one annoying bug tracked as Bug#1055809 where > on > heavily loaded TCP servers a refcount issue might occur and the module will > become unusable. This request was approved but not uploaded in time for the previous point release (12.5). Should it be included in 12.6, or should this request be abandoned and closed? Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1049988: bookworm-pu: package riemann-c-client/1.10.4-2
Hi, On Thu, Aug 17, 2023 at 01:01:01PM -1000, Romain Tartière wrote: > [ Reason ] > Due to improper return value checks, when communicating with a remote > server over TLS riemann-c-client sometimes send the same data fragment > multiple times, resulting in the server receiving a malformed payload. > > This happen with all versions of TLS, but TLS 1.3 trigger this bad > behaviour more often. With more and more services using TLS 1.3, this > problem is more and more prevalent. > > [ Impact ] > When the client send a large payload over TLS faster than the network > can send it, the improper return value checks cause portions of that > data to be send multiple times to the server. When the transfer > eventually finish, the server detect that the payload is invalid and > drop the connection. The client will then reconnect and retry the > transfer that might fail again and again. > > Beside error messages in the server logs, these data corrupt data > transfer cause an unexpectedly hight bandwidth usage. This request was approved but not uploaded in time for the previous point release (12.5). Should it be included in 12.6, or should this request be abandoned and closed? Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1062654: openjdk-17-jre-headless: Segfault in jspawnhelper
I got the same problem on bullseye. the package was upgraded from 17.0.9+9-1~deb11u1 to 17.0.10+7-1~deb11u1 (bullseye-security) on the 6th of february (with unattended-upgrades). It broke my jenkins instance because it could not fetch git repo anymore. Downgrading to 17.0.7+7-1~deb11u1 solve the problem. # apt-cache policy openjdk-17-jre-headless | grep "Installed" Installed: 17.0.10+7-1~deb11u1 # /usr/lib/jvm/java-17-openjdk-amd64/lib/jspawnhelper Segmentation fault # apt install openjdk-17-jre-headless=17.0.7+7-1~deb11u1 ... # apt-cache policy openjdk-17-jre-headless | grep "Installed" Installed: 17.0.7+7-1~deb11u1 # /usr/lib/jvm/java-17-openjdk-amd64/lib/jspawnhelper This command is not for general use and should only be run as the result of a call to ProcessBuilder.start() or Runtime.exec() in a java application -- Hubert Pineault
Bug#1051466: bookworm-pu: package ovn/23.03.1-1~deb12u1
Hi, On Fri, Sep 08, 2023 at 01:32:05PM +0200, Frode Nordahl wrote: > We would like to upload the latest stable point release of ovn 23.03 > to bookworm-p-u. Stable release branches are maintained upstream with > the intention of providing bug fixes only and no compatibility > breakages, and with automated non-trivial CI jobs that also cover > Debian and Ubuntu. > > Debdiff attached. Packaging updated with gbp/salsa config for new > bookworm stable branch and in-flight patches to fix an issue with > unnecessary logging breaking one of the tests introduced in the point > release. This request was approved but not uploaded in time for the previous point release (12.5). Should it be included in 12.6, or should this request be abandoned and closed? Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1060774: bullseye-pu: netatalk/3.1.12~ds-8+deb11u2
Hi, On Tue, Jan 16, 2024 at 08:30:52AM +, Daniel Markstedt wrote: > 2024年1月16日 (火) 02:53, Adam D. Barratt > <[a...@adam-barratt.org.uk](mailto:2024年1月16日 (火) 02:53, Adam D. Barratt < href=)> 送信: > > > Control: tags -1 + moreinfo > > > > On Sun, 2024-01-14 at 06:23 +, Daniel Markstedt wrote: > >> CVE-2022-22995 > >> Ref. advisory: https://netatalk.sourceforge.io/CVE-2022-22995.php > >> > >> The attached patch can be applied to Debian oldstable to address the > >> vulnerability. > >> > > > > In order to approve an upload, we need to see a full source debdiff of > > the proposed new package, not just the isolated patch. Please remove > > the moreinfo tag when providing that. > > Adam, thanks for following up on this request. > I will work on a debdiff when I’m back home this coming weekend. > Right now I’m working offsite without access to a personal computer. Ping? It's now too late for 11.9 but your request can be considered for 11.10 if you send a debdiff. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1062654: openjdk-17-jre-headless: Segfault in jspawnhelper
I got the same problem on bullseye. the package was upgraded from 17.0.9+9-1~deb11u1 to 17.0.10+7-1~deb11u1 on the 6th of february (with unattended-upgrades). It broke my jenkins instance because it could not fetch git repo anymore. Downgrading to 17.0.7+7-1~deb11u1 solve the problem. # apt-cache policy openjdk-17-jre-headless | grep "Installed" Installed: 17.0.10+7-1~deb11u1 # /usr/lib/jvm/java-17-openjdk-amd64/lib/jspawnhelper Segmentation fault # apt install openjdk-17-jre-headless=17.0.7+7-1~deb11u1 ... # apt-cache policy openjdk-17-jre-headless | grep "Installed" Installed: 17.0.7+7-1~deb11u1 # /usr/lib/jvm/java-17-openjdk-amd64/lib/jspawnhelper This command is not for general use and should only be run as the result of a call to ProcessBuilder.start() or Runtime.exec() in a java application -- Hubert Pineault
Bug#1057107: bullseye-pu: package libssh2/1.9.0-2
Hi, On Tue, Dec 19, 2023 at 07:52:02PM -0500, Nicolas Mora wrote: > Hello, > > Thank you for the feedback, the new attached debdiff should fix these. Sorry, your message was not seen in time for 11.9 because the request is still tagged moreinfo. It will be considered for 11.10. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1049982: bullseye-pu: package riemann-c-client/1.10.4-2+b2
Hi, On Thu, Aug 17, 2023 at 10:17:48AM -1000, Romain Tartière wrote: > [ Reason ] > Due to improper return value checks, when communicating with a remote > server over TLS riemann-c-client sometimes send the same data fragment > multiple times, resulting in the server receiving a malformed payload. > > This happen with all versions of TLS, but TLS 1.3 trigger this bad > behaviour more often. With more and more services using TLS 1.3, this > problem is more and more prevalent. > > > [ Impact ] > When the client send a large payload over TLS faster than the network > can send it, the improper return value checks cause portions of that > data to be send multiple times to the server. When the transfer > eventually finish, the server detect that the payload is invalid and > drop the connection. The client will then reconnect and retry the > transfer that might fail again and again. > > Beside error messages in the server logs, these data corrupt data > transfer cause an unexpectedly hight bandwidth usage. This request was approved but not uploaded in time for the previous point releases (11.8 and 11.9). Should it be included in 11.10, or should this request be abandoned and closed? Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1025518: bullseye-pu: package capnproto/0.7.1-1+deb11u1
On Tue, Jul 25, 2023 at 10:19:50PM +0100, Jonathan Wiltshire wrote: > Control: tag -1 moreinfo > > On Mon, Dec 05, 2022 at 11:22:51PM -0800, tony mancill wrote: > > As the upstream author notes in [3], the issue is present in inlined > > code, thus applications built against capnproto must be rebuilt against > > the patched version. > > This doesn't immediately make any of us enthusiastic, it has to be said... > Can we get the proposed debdiff at least please? > > The hazards are: > - ftbfs in the rdeps in stable > - much reduced testing of proposed-updates vs. for example sid/testing > > > The issue for unstable and bookworm is being addressed via an > > upload to experimental [4] and a subsequent transition [5]. Easy > > enough... > > > > For stable (and old-stable), we need to introduce 0.7.1, a new upstream > > version that generates a (new) libcapnp-0.7.1 binary package to address > > the vulnerability. Once those are present in the archive, we can > > trigger rebuilds of the reverse dependencies. At this time I am asking > > for bullseye. > > > > [ Reason ] > > This is to address CVE-2022-46149 [1]. > > > > [ Impact ] > > Packages built with capnproto in bullseye will remain potentially > > vulnerable to the CVE. > > > > [ Tests ] > > I have built the package in a clean bullseye chroot and then used ratt to > > rebuilt the (8) bullseye r-deps: > > > > - clickhouse_18.16.1+ds-7.2 > > - harvest-tools_1.3-6 > > - laminar_1.0-3 > > - librime_1.6.1+dfsg1-1 > > - mash_2.2.2+dfsg-2 > > - mir_1.8.0+dfsg1-18 > > - rr_5.4.0-2 > > - sonic-visualiser_4.2-1 > > laminar in particular doesn't seem to have much maintainer attention. If > there are problems with the rdeps on rebuild are you going to be in a > position to resolve them? > > > [ Risks ] > > The upstream author has stated that there are no known vulnerable > > applications, yet advises that all capnproto users rebuild their > > applications using patched versions of capnproto. > > An abundance of caution? Otherwise the statements seem at odds with each > other. > > > If this is not amenable to stable-proposed-updates, would you recommend > > backports? > > I'm not sure a transition in backports is going to be well received either. > Let's start with the debdiff and at least know what we're looking at. Ping? -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1057084: bullseye-pu: package nvidia-graphics-drivers-tesla-450/450.248.02-4~deb11u1
Hi, On Wed, Nov 29, 2023 at 02:38:08PM +0100, Andreas Beckmann wrote: > [ Reason ] > The Tesla 450 driver series has reached End of Life. I'd like to turn it > into transitional packages to ease switching to the Tesla 470 driver > series. We did the same with the Tesla 460 series after that reached EoL > last year. The 470 series supports a superset of GPUs, so this switch is > not a regression in terms of supported devices or features. This request was approved but not uploaded in time for the previous point release (11.9). Should it be included in 11.10, or should this request be abandoned and closed? -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
On Tue, 2024-02-06 at 20:49 +0300, Michael Tokarev wrote: > 06.02.2024 20:33, Adam D. Barratt: > > On Tue, 2024-02-06 at 19:37 +0300, Michael Tokarev wrote: > > > problematic upstream commit (on master) is this one: > > > https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 > > > Technically we already froze p-u for 12.5 on Sunday evening, as > > previously announced. If you could get an upload just fixing that > > single issue with a small change uploaded today then I'd be tempted > > to > > accept it anyway. > > Oh. I knew we're getting late, but not *that* late. > The point release(s) are on Saturday, and we always freeze a week beforehand. > The change isn't small per se, as the commit is rather large (mostly > due to many changed tests, - it changes order of output in quite some > places). Here's the diffstat: > > monitor/qmp.c | 17 + > qapi/qmp-dispatch.c | 24 +- > -- This is the relevant bit for size IMO. If you're happy with the result then please upload as soon as you're ready. Regards, Adam
Bug#1037188: bullseye-pu: package git/2.30.2-1+deb11u3
Hi, On Sun, Oct 08, 2023 at 01:05:24PM +0100, Jonathan Wiltshire wrote: > On Thu, Jul 27, 2023 at 03:52:52PM +0200, Andreas Beckmann wrote: > > Control: tag -1 - moreinfo > > > > On 08/07/2023 19.25, Adam D. Barratt wrote: > > > It looks like not all of the postinst was removed - was that > > > intentional? It's presumably harmless, but now leads to a lintian > > > warning, which is why I noticed. :-) > > > > That git-el.postinst code was already removed by > > c4b054cf0e debian: drop support for upgrades from pre-1.7.9.5 versions > > (Mon Dec 28 20:13:48 2020 -0800) > > and I missed the opportunity to simply delete the whole file when I > > backported > > 67b73aadeb debian: remove git-el package (Mon May 31 15:03:12 2021 -0700). > > The remaining bits should be harmless (it's a postinst script for a package > > no longer in d/control), but if you prefer, I can reupload with the cruft > > bits removed, too. Should save a few brain cycles on future updates ;-) > > Yes please; I'll reject the existing upload in a moment so you can re-use > the version. There hasn't been any movement on this bug for the previous point release 11.8 nor the frozen 11.9. Should it be included in 11.10, or should this request be abandoned and closed? Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1029008: Bug#1009879: security update needed for pypdf2 in bullseye (CVE-2022-24859)?
Control: close -1 Hi, On Tue, Jul 25, 2023 at 10:26:06PM +0100, Jonathan Wiltshire wrote: > Control: tag -1 confirmed > > Hi, > > On Mon, Jan 16, 2023 at 07:41:21AM +0100, László Böszörményi wrote: > > On Mon, Jan 16, 2023 at 6:38 AM Salvatore Bonaccorso > > wrote: > > > On Sun, Jan 15, 2023 at 04:57:24PM -0500, Daniel Kahn Gillmor wrote: > > > > I was looking into CVE-2022-24859 and pypdf2, and trying to figure out > > > > whether the version in bullseye is still vulnerable, as it appears to be > > > > according to the security tracker: > > [...] > > > It is still unfixed in bullseye TTBOMK, but would not warrant a DSA. > > Indeed, it's not yet fixed for Bullseye and doesn't warrant a DSA as > > the max impact is an infinite loop in the user's own process. > > > > > Can you propose a fix for it with cherry-picking the pull request > > > changes for the next bullseye point release? > > Correct, it needs to go via Bullseye point update. I attached the > > short change which has the original commit as Salvatore noted. > > Either of the proposed diffs is fine; please go ahead. This package has not been uploaded in time for two consecutive point releases now, so I am closing the request. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1023740: bullseye-pu: package python-scciclient/0.8.0-2
Control: close -1 On Wed, Nov 09, 2022 at 01:00:15PM +0100, Thomas Goirand wrote: > [ Reason ] > This patch fixes the lack of TLS verification with scciclient. > > [ Impact ] > Man in the middle attack is possible without this patch. This package has not been uploaded in time for two consecutive point releases now, so I am closing the request. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
06.02.2024 20:33, Adam D. Barratt: On Tue, 2024-02-06 at 19:37 +0300, Michael Tokarev wrote: problematic upstream commit (on master) is this one: https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 Technically we already froze p-u for 12.5 on Sunday evening, as previously announced. If you could get an upload just fixing that single issue with a small change uploaded today then I'd be tempted to accept it anyway. Oh. I knew we're getting late, but not *that* late. The change isn't small per se, as the commit is rather large (mostly due to many changed tests, - it changes order of output in quite some places). Here's the diffstat: monitor/qmp.c | 17 + qapi/qmp-dispatch.c | 24 +--- tests/qemu-iotests/060.out|4 ++-- tests/qemu-iotests/071.out|4 ++-- tests/qemu-iotests/081.out| 16 tests/qemu-iotests/087.out| 12 ++-- tests/qemu-iotests/108.out|2 +- tests/qemu-iotests/109|4 ++-- tests/qemu-iotests/109.out| 78 +- tests/qemu-iotests/117.out|2 +- tests/qemu-iotests/120.out|2 +- tests/qemu-iotests/127.out|2 +- tests/qemu-iotests/140.out|2 +- tests/qemu-iotests/143.out|2 +- tests/qemu-iotests/156.out|2 +- tests/qemu-iotests/176.out| 16 tests/qemu-iotests/182.out|2 +- tests/qemu-iotests/183.out|4 ++-- tests/qemu-iotests/184.out| 32 tests/qemu-iotests/185|6 +++--- tests/qemu-iotests/185.out| 45 + tests/qemu-iotests/191.out| 16 tests/qemu-iotests/195.out| 16 tests/qemu-iotests/223.out| 12 ++-- tests/qemu-iotests/227.out| 32 tests/qemu-iotests/247.out|2 +- tests/qemu-iotests/273.out|8 tests/qemu-iotests/308|4 ++-- tests/qemu-iotests/308.out|2 +- tests/qemu-iotests/tests/qsd-jobs.out |4 ++-- 30 files changed, 173 insertions(+), 201 deletions(-) (as you can see, first two are the gist of it, the rest are the consequences). I'm including a complete revert of this single commit together with all the testsuite changes, ie, exactly as it is, - while the upstream testsuite isn't used in debian directly, it still works, and I'm running it right now locally just to be sure (though it definitely worked before that commit has been initially applied, so it should be okay). Presumably the bugs being fixed by that commit already exist in bookworm's qemu, so not including the commit isn't a regression? Yes, exactly, that's why I wrote about the status-quo. Please also attach a debdiff against the previous upload. Attached.diff -Nru qemu-7.2+dfsg/debian/changelog qemu-7.2+dfsg/debian/changelog --- qemu-7.2+dfsg/debian/changelog 2024-01-30 19:15:04.0 +0300 +++ qemu-7.2+dfsg/debian/changelog 2024-02-06 20:38:06.0 +0300 @@ -1,3 +1,12 @@ +qemu (1:7.2+dfsg-7+deb12u5) bookworm; urgency=medium + + * +revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch +Revert a single upstream change in 7.2.9 which, while fixed a few qemu +lockup bugs, introduced a regression in suspend-resume-hibernate cycle +(triggered by cryptsetup autopkgtest) + + -- Michael Tokarev Tue, 06 Feb 2024 20:38:06 +0300 + qemu (1:7.2+dfsg-7+deb12u4) bookworm; urgency=medium [ Michael Tokarev ] diff -Nru qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch --- qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch 1970-01-01 03:00:00.0 +0300 +++ qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch 2024-02-06 20:36:21.0 +0300 @@ -0,0 +1,1544 @@ +From 84a139b0289470994f8a518034d69186f5ad5bb9 Mon Sep 17 00:00:00 2001 +From: Michael Tokarev +Date: Tue, 6 Feb 2024 20:35:22 +0300 +Subject: [PATCH] Revert "monitor: only run coroutine commands in + qemu_aio_context" + +This reverts commit 8ec90598e922a604c222bdbc6289bed7279dced6. +Causes a regression at least in suspend-resume-hibernate cycle, +let's revert it to restore the status quo for now. +--- + monitor/qmp.c | 17 ++ + qapi/qmp-dispatch.c | 24 + + tests/qemu-iotests/060.out| 4 +- +
Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup
Control: tag -1 moreinfo Hi, On Fri, Sep 29, 2023 at 12:22:41AM +1000, Hugh McMaster wrote: > After discussing the timing of Debian 12.2 with a release manager, I’ll > revert the change shortly. > What's your plan at this point? We have skipped this update in two point releases now and it needs a resolution. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Whilst I am not an expert on this transition or the abi-compliance-checker, a quick look at the logs[1] suggests this is a tool configuration issue and src:consolekit2 may not require t64 migration. Can you clarify? Thanks Mark [1] https://adrien.dcln.fr/misc/armhf-time_t/2024-02-03T09:18:00/logs/libconsolekit-dev/time_t/log.txt
Bug#698988: O: nvi - 4.4BSD re-implementation of vi
Hi Tobias! On 2024-02-05 10:43, Tobias Heider wrote: > On Sat, Jan 26, 2013 at 12:38:07AM +, Stuart Prescott wrote: >> >> The maintainer for the "nvi" package has indicated that he is unable to >> maintain this package for the time being. I'm marking this package as >> orphaned >> now. > > Looks like this is still orphaned over ten years later. > > As an active nvi user I would love to step up and help, but the biggest > problem I see is that the choice of upstream project. Since the original > is gone there isn't a clear successor. > > The BSDs all have their own forks which diverged over time (and those don't > build on Linux). > The other two options there are today are https://repo.or.cz/nvi.git which > d/control currently points to and more recently > https://github.com/lichray/nvi2. > > The first has a very low commit frequency (last commit was 2020, before > that 2016) and sticks very closely to the original source. nvi2 has added > new features such as multibyte support and is starting to receive bug fixes > and features from the different *BSD forks. > > I have been thinking of proposing a new package for nvi2 but maybe it would > make more sense to move this one to the more active upstream. It looks like > some of the issues we are carrying patches for in Debian might be fixed there > already and if not they seem active enough to merge our fixes. > > What would be the best way forward here? ITA and eventually switch the > upstream > or start a new package and let this one continue its slow death? I think making the O bug and ITA and switching upstream is right thing to do here, maybe explaining the history of the package in README.source. I can't think think of a reasonable use case where nvi2 would not be a suitable drop-in replacement for nvi; if neither can you (knowing the editor way better than me!), then I'd say go for the switch. I'll be happy reviewing/sponsoring if needed. Cheers, Paride
Bug#1063357: rust-ahash - debian and cargo dependencies inconsistent.
Package: rust-ahash
Version: 0.8.7-3
rust-ahash has a cargo dependency on
const-random = { version = "0.1.17", optional = true } but the debian dependency
is librust-const-random-0.1+default-dev (>= 0.1.12). This discrepancy is causing
autopkgtest failures in Ubuntu.
There is also a similar discrepancy with the once-cell dependency,
this doesn't seem to be causing any actual problems but I figured
it may as well be updated at the same time.
a debdiff updating the Debian dependencies is attached.diff -Nru rust-ahash-0.8.7/debian/changelog rust-ahash-0.8.7/debian/changelog
--- rust-ahash-0.8.7/debian/changelog 2024-02-01 20:50:15.0 +
+++ rust-ahash-0.8.7/debian/changelog 2024-02-06 15:36:46.0 +
@@ -1,3 +1,11 @@
+rust-ahash (0.8.7-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Update debian dependencies on rust-const-random and rust-once-cell crates
+to match cargo dependencies.
+
+ -- Peter Michael Green Tue, 06 Feb 2024 15:36:46 +
+
rust-ahash (0.8.7-3) unstable; urgency=medium
* add patch cherry-picked upstream to fix test
diff -Nru rust-ahash-0.8.7/debian/control rust-ahash-0.8.7/debian/control
--- rust-ahash-0.8.7/debian/control 2024-01-18 21:07:25.0 +
+++ rust-ahash-0.8.7/debian/control 2024-02-06 15:36:46.0 +
@@ -6,7 +6,7 @@
dh-cargo (>= 25),
librust-atomic-polyfill-1+default-dev ,
librust-cfg-if-1+default-dev ,
- librust-const-random-0.1+default-dev (>= 0.1.12) ,
+ librust-const-random-0.1+default-dev (>= 0.1.17) ,
librust-criterion-0.3+default-dev ,
librust-criterion-0.3+html-reports-dev ,
librust-fnv-1+default-dev ,
@@ -15,7 +15,7 @@
librust-hashbrown-0.12+default-dev ,
librust-hex-0.4+default-dev (>= 0.4.2) ,
librust-no-panic-0.1+default-dev ,
- librust-once-cell-1+alloc-dev (>= 1.13.1) ,
+ librust-once-cell-1+alloc-dev (>= 1.18.0) ,
librust-once-cell-1+atomic-polyfill-dev ,
librust-rand-0.8+default-dev ,
librust-seahash-4+default-dev ,
@@ -37,9 +37,9 @@
Depends:
librust-atomic-polyfill-1+default-dev,
librust-cfg-if-1+default-dev,
- librust-const-random-0.1+default-dev (>= 0.1.12),
+ librust-const-random-0.1+default-dev (>= 0.1.17),
librust-getrandom-0.2+default-dev (>= 0.2.7),
- librust-once-cell-1+alloc-dev (>= 1.13.1),
+ librust-once-cell-1+alloc-dev (>= 1.18.0),
librust-once-cell-1+atomic-polyfill-dev,
librust-serde-1+default-dev (>= 1.0.117),
librust-version-check-0.9+default-dev (>= 0.9.4),
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Michael, On Tue, Jan 30, 2024 at 01:24:19AM +, mwhud...@debian.org wrote: > Source: consolekit2 > Version: 1.2.6-3 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t This patch appears to be broken and all the experimental builds FTBFS[1]. In addition, the bug severity is triggering autoremoval[2] That seems a sub-optimal combination. I am minded to reduce the bug severity. But I will wait for your response if you have a better suggestion. Thanks Mark [1] https://buildd.debian.org/status/package.php?p=consolekit2=experimental [2] https://udd.debian.org/cgi-bin/autoremovals.cgi
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
On Tue, 2024-02-06 at 19:37 +0300, Michael Tokarev wrote: > e problematic upstream commit (on master) is this one: > https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 > It has links to 2 bugs it is fixing, and there are quite a few > other bugs which are fixed too. > > I can add a revert of this single commit (with all tests) for debian > stable (for deb12u5 release) on top of current deb12u4. I think > this would be best, despite the way it goes, - first the change is > added in v7.2.9.diff, and next removed in a followup revert, - > because this way we follow upstream releases, and this patch > will be easy to remove in subsequent update. [...] > re thing, if the solution will be found in a couple of days, > I'll try to push that one instead, but it also depends on the > complexity and possible risks there, and timeline. Technically we already froze p-u for 12.5 on Sunday evening, as previously announced. If you could get an upload just fixing that single issue with a small change uploaded today then I'd be tempted to accept it anyway. Presumably the bugs being fixed by that commit already exist in bookworm's qemu, so not including the commit isn't a regression? Please also attach a debdiff against the previous upload. Regards, Adam
Bug#1063356: debdelta: `debdelta-upgrade` generates file with wrong name (encoded + as %2b)
Package: debdelta Version: 0.67 Severity: normal Dear Maintainer, I happened to notice that after debdelta created a deb file for libzbar0, `apt` downloaded it nevertheless. So I went to check /var/cache and sure enough: % l /var/cache/apt/archives/libzbar0_0.23.92-7* -rw-r--r-- 1 root root 129748 jan 4 2023 /var/cache/apt/archives/libzbar0_0.23.92-7_amd64.deb -rw-r--r-- 1 root root 129788 jan 14 11:18 /var/cache/apt/archives/libzbar0_0.23.92-7+deb12u1_amd64.deb -rw-r--r-- 1 root root 129788 fv 4 08:50 /var/cache/apt/archives/libzbar0_0.23.92-7%2bdeb12u1_amd64.deb % As you can see, what happened is that `debdelta-upgrade` incorrectly named the generated file `libzbar0_0.23.92-7%2bdeb12u1_amd64.deb`, i.e. encoded the `+` as a `%2b`. Stefan -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debdelta depends on: ii binutils 2.40-2 ii bzip2 1.0.8-5+b1 ii libbz2-1.01.0.8-5+b1 ii libc6 2.36-9+deb12u4 ii python3 3.11.2-1+b1 ii python3-requests 2.28.1+dfsg-1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages debdelta recommends: pn bsdiff ii gnupg2 2.2.40-1.1 ii gpg-agent [gnupg-agent] 2.2.40-1.1 ii python3-apt 2.6.0 ii python3-debian 0.1.49 pn xdelta ii xdelta3 3.0.11-dfsg-1.2 ii xz-utils [lzma] 5.4.1-0.2 Versions of packages debdelta suggests: pn debdelta-doc -- no debconf information
Bug#698988: O: nvi - 4.4BSD re-implementation of vi
On 2024-02-05 Tobias Heider wrote: [...] > As an active nvi user I would love to step up and help, but the biggest > problem I see is that the choice of upstream project. Since the original > is gone there isn't a clear successor. > The BSDs all have their own forks which diverged over time (and those don't > build on Linux). > The other two options there are today are https://repo.or.cz/nvi.git which > d/control currently points to and more recently > https://github.com/lichray/nvi2. > The first has a very low commit frequency (last commit was 2020, before > that 2016) and sticks very closely to the original source. nvi2 has added > new features such as multibyte support and is starting to receive bug fixes > and features from the different *BSD forks. > I have been thinking of proposing a new package for nvi2 but maybe it > would make more sense to move this one to the more active upstream. > It looks like some of the issues we are carrying patches for in Debian > might be fixed there already and if not they seem active enough to > merge our fixes. > What would be the best way forward here? ITA and eventually switch the > upstream or start a new package and let this one continue its slow > death? Hello Thomas, On one hand it depends on whether there is significant value in keeping the other nvi around, i.e. a significant part of the userbase would be reluctant to switch. (I have no opinion on that I use vim ;-) On the other hand reducing the number of QA-maintained packages is a strong argument for switching. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1063170: nettle: NMU diff for 64-bit time_t transition
On 2024-02-05 Niels Möller wrote: > Graham Inggs writes: >> we have identified nettle as a source package shipping runtime >> libraries whose ABI either is affected by the change in size of >> time_t, or could not be analyzed via abi-compliance-checker (and >> therefore to be on the safe side we assume is affected). [...] > However, this code is in the *libhogweed* so-file, so transitioning > *libnettle* is probably not needed. [...] The analysis looked at the headers and ... | In multi-library packages, there is no reliable way to map from a set of | headers in a dev package to specific shared libraries in a runtime library | package that's not additionally computationally prohibitive; we therefore | conservatively assume that if any headers from a source package show | time_t ABI changes, all the runtime library packages from the source | package are affected by the transition. cu Andreas
Bug#1051010: lwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
So I have been reading up on flatpak documentation: https://docs.flatpak.org/en/latest/ Reading this it is clear that at least for the moment flatbox sandboxing is more of a line in the sand than the Berlin wall. This explains why the portals config is so hard to test. I attach the two necessary files. I don't know how to test any further and I cannot progress the bug report any more without salsa access. The idea behind the portal file is that lwm would try to use any portal available. I am very certain no new dependencies should be added. I would expect users of lwm are unlikely to be interested in portals and unlikely to have the the xdg-dekstop-portal process running. That said I do think the package should do its best to support users who do want to use flatpak so long as no extra cost to using the package is added. lwm.desktop Description: application/desktop [preferred] default=*
Bug#1063355: ronn: -m and --date options do not work
Package: ronn Version: 0.9.1-3 Severity: normal X-Debbugs-Cc: rstan...@rsiny.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Two problems: With PAGER and MAMPAGER Not set: ronn -m --style=man sample.3.ronn more: invalid option -- 'i' Try 'more --help' for more information. --date option does not work trying all options: --date="2024-02-06" --date=2024-02-06 --date=`date "+%Y-%m-%d"` mtime file in same directory with one line: 2024-02-06 Output file only displays: February 2024 * What exactly did you do (or not do) that was effective (or ineffective)? As listed above, both options failed. * What was the outcome of this action? I could not use either option * What outcome did you expect instead? more command should have worked without the 'i' option, Typo?. --date option should have replaced "February 2024" with "2024-02-06" *** End of the template - remove these template lines *** -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ronn depends on: ii ruby 1:3.1 ii ruby-ronn 0.9.1-3 ronn recommends no packages. ronn suggests no packages. -- no debconf information
Bug#1063151: igb: unpredictable interface names for four port nic
On Tue, 06 Feb 2024 17:27:24 +0100 Valentin wrote: > eth0: Policy *slot* yields "ens6f0". > eth0: Could not set AlternativeName= or apply AlternativeNamesPolicy=, > ignoring: File exists eth0: > /usr/lib/udev/rules.d/80-net-setup-link.rules:11 NAME 'ens6f0' eth0: > /usr/lib/udev/rules.d/99-systemd.rules:68 RUN '/lib/systemd/systemd-sysctl > --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name > --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name' eth0: > sd-device: Created db file '/run/udev/data/n69' for > '/devices/pci:00/:00:1c.0/:01:00.0/net/eth0' ens6f0: Failed to > rename network interface 69 from 'eth0' to 'ens6f0': File exists It looks like your BIOS is reporting the same PCIe Slot for both your igb and Broadcom network cards. I assume one of your Broadcom network interfaces is already named ens6f0. In fact., this might be a BIOS issue... whats the output of `sudo dmidecode -t9`? Best solution for you is probably to set all or some network interface names manually, see https://wiki.debian.org/ NetworkInterfaceNames#CUSTOM_SCHEMES_USING_.LINK_FILES Yes, I think Valentin is correct in his analysis. This looks like a BIOS issue which you might want to report to your vendor. I would follow Valentin's advice and use cutom link files that e.g. determine the names based on the MAC address. Afaics, there is nothing actionable on the udev side here, which is why I'm inclined to close the bug report. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1025062: systemd-resolved Provides: resolvconf, but is missing the isc-dhcp-client integration from resolvconf
Control: severity -1 important On Mon, 5 Feb 2024 07:18:30 -0300 Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?= wrote: > El 31/01/24 a las 18:47, Antoine Durand-Gasselin escribió: > > On Mon, 8 May 2023 00:43:30 +0100 Ken Milmore > > wrote: > > > I was motivated to try fixing this after installing systemd-resolved > > on bookworm and finding that my DNS was completely broken. > > > > > > I have tested the Ubuntu hook scripts with DHCP enabled for both IPv4 > > and/or IPv6. They work well for me so far. > > > > > > I have attached a source patch against isc-dhcp master on Salsa. This > > just adds the verbatim hook scripts from Ubuntu. > > > [...] > > > > > > > Dear Debian ISC DHCP Maintainers, > > > > Broken DNS after installing systemd-resolved is quite annoying. > > Ubuntu has come up with a fix for that, so is there anything blocking > > using the same fix here ? > > Hi! > > Sorry, I am not sure why I have missed this. I'll process this later > today. Since there is some /usr-merge-related changes already applied in experimental, I've pushed to experimental too, and will upload to unstable (and then bookworm), once it is safe to move all the changes. Also, bumping the severity to important, since this bug breaks some DNS resolution setups. Cheers, and thanks for your patience, -- Santiago signature.asc Description: PGP signature
Bug#1063354: ITP: h2orestart -- LibreOffice import filter for Hancom HWP document
Package: wnpp Severity: wishlist Owner: Changwoo Ryu X-Debbugs-Cc: debian-de...@lists.debian.org, debian-l10n-kor...@lists.debian.org * Package name: h2orestart Version : 0.6.0 Upstream Contact: https://github.com/ebandal/H2Orestart * URL : https://github.com/ebandal/H2Orestart * License : GPL-3.0-or-later Programming Lang: Java Description : LibreOffice import filter for Hancom HWP document This enhances LibreOffice Writer to read Hancom Office documents, as known as HWP, which are widely used especially by South Korean government organizations. . It supports the HWP v5 format or the HWPx format only. It doesn't work for the ancient HWP v3 format.
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
03.02.2024 12:47, Michael Tokarev wrote: It looks like we broke suspend/resume in this version of qemu. Oops. Is that related to the cryptsetup failure, or a separate issue? Yes, it is related to cryptsetup autopkgtest failure. It looks like this is the only place where suspend/resume code in qemu is actually being used, - it's rather rare to suspend (hybernate) a virtual machine, and cryptsetup performs testing of how the encrypted filesystem is unlocked (or not) on resume. So, while the problematic upstream commit fixes quite a few real potential qemu lockups, it introduces a new lockup in suspend- resume-hibernate cycle. The problem isn't understood yet, and we're getting close to the 12.5 release. The problematic upstream commit (on master) is this one: https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 It has links to 2 bugs it is fixing, and there are quite a few other bugs which are fixed too. I can add a revert of this single commit (with all tests) for debian stable (for deb12u5 release) on top of current deb12u4. I think this would be best, despite the way it goes, - first the change is added in v7.2.9.diff, and next removed in a followup revert, - because this way we follow upstream releases, and this patch will be easy to remove in subsequent update. Alternatively we probably can ignore cryptsetup autopkgtest failure, but this smells somewhat wrong, I think it's better to restore the status quo for now, even in such a weird way (applying and reverting a patch). What do you think? Sure thing, if the solution will be found in a couple of days, I'll try to push that one instead, but it also depends on the complexity and possible risks there, and timeline. Thanks, /mjt
Bug#1063151: igb: unpredictable interface names for four port nic
> eth0: Policy *slot* yields "ens6f0". > eth0: Could not set AlternativeName= or apply AlternativeNamesPolicy=, > ignoring: File exists eth0: > /usr/lib/udev/rules.d/80-net-setup-link.rules:11 NAME 'ens6f0' eth0: > /usr/lib/udev/rules.d/99-systemd.rules:68 RUN '/lib/systemd/systemd-sysctl > --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name > --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name' eth0: > sd-device: Created db file '/run/udev/data/n69' for > '/devices/pci:00/:00:1c.0/:01:00.0/net/eth0' ens6f0: Failed to > rename network interface 69 from 'eth0' to 'ens6f0': File exists It looks like your BIOS is reporting the same PCIe Slot for both your igb and Broadcom network cards. I assume one of your Broadcom network interfaces is already named ens6f0. In fact., this might be a BIOS issue... whats the output of `sudo dmidecode -t9`? Best solution for you is probably to set all or some network interface names manually, see https://wiki.debian.org/ NetworkInterfaceNames#CUSTOM_SCHEMES_USING_.LINK_FILES Cheers, Valentin
Bug#1063353: groff-base: man page only in b/w: colouring using LESS_TERMCAP_* broke on update
Package: groff-base
Version: 1.23.0-3
Severity: normal
X-Debbugs-Cc: mpar...@gmx.net
I have a /etc/profile.d/less-termcaps.sh file containing
> export TERM=${TERM:-linux}
> export LESS_TERMCAP_us=$(tput bold; tput setaf 5) # underline start: bold,
magenta
> export LESS_TERMCAP_ue=$(tput sgr0) # underline end: norm
>
> export LESS_TERMCAP_so=$(tput bold; tput rev; tput setaf 2; tput setab 0) #
standout mode start: bright green, reverse
> export LESS_TERMCAP_se=$(tput rmso; tput sgr0) # standout mode end: reset
>
> export LESS_TERMCAP_mb=$(tput bold; tput setaf 5) # blinking start: bold,
magenta
> export LESS_TERMCAP_md=$(tput bold; tput setaf 6) # bold mode start: bold,
cyan
> export LESS_TERMCAP_me=$(tput sgr0) # mode end: reset
>
> export LESS_TERMCAP_mr=$(tput rev)
> export LESS_TERMCAP_mh=$(tput dim; tput setab 5)
> export LESS_TERMCAP_ZN=$(tput ssubm)
> export LESS_TERMCAP_ZV=$(tput rsubm)
> export LESS_TERMCAP_ZO=$(tput ssupm)
> export LESS_TERMCAP_ZW=$(tput rsupm)
>
> export LESS_TERMCAP_ZZ=$(tput sgr0) # reset: do not litter 'env' output
That results in nice coloring of man pages. That broke with 1.23, rolling back
to 1.22 fixed it.
I've seen some other report (#1059536) about lots of changes even though I have
only a mild idea of what all these codes mean.. hope there'll be a fix.. thx
bye ; )
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (510, 'unstable'), (509, 'experimental'), (500,
'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500,
'oldstable-security'), (500, 'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.13-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN,
TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages groff-base depends on:
ii libc6 2.37-14
ii libgcc-s1 14-20240201-1
ii libstdc++614-20240201-1
ii libuchardet0 0.0.8-1
groff-base recommends no packages.
Versions of packages groff-base suggests:
ii groff 1.22.4-10
-- no debconf information
Bug#1063352: ITP: ngspetsc -- a PETSc interface for NGSolve
Package: wnpp Severity: wishlist Owner: Drew Parsons X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org, francesco.balla...@unicatt.it * Package name: ngspetsc Version : git HEAD Upstream Contact: Umberto Zerbinati * URL : https://github.com/NGSolve/ngsPETSc * License : MIT Programming Lang: Python Description : a PETSc interface for NGSolve ngsPETSc is a PETSc interface for NGSolve. It extends the utility of meshes generated by netgen and interfaces with finite element solvers such as dolfinx (fenicsx) as well as NGSolve, Firedrake. To be maintained by the Debian Science team alongside netgen. Co-maintained with Francesco Ballarin.
Bug#1061357: python3-spglib: spglib python package not identified by dh_python3
Hi, On 2024-01-23 01:18, Drew Parsons wrote: But I notice that python3-spglib doesn't provide the .dist-info directory that most other python packages provide. I guess dh-python is using the dist-info mechanism to identify packages. Perhaps we should file a bug against dh-python for it to run something like "dpkg -S/usr/lib/python3/dist-packages/" if it doesn't find a dist-info entry. In the meantime, I figure spglib's lack of dist-info occurs because it's a cmake build rather than a python setuptools build, in which case the problem sits alongside Bug#1061263. I have uploaded spglib 2.2.0-3 with sort of dual buildsystem where python package is built by pybuild. Thus now dist-info is present in the binary package. I did not close this bug as I have not attempted to rebuilt pymatgen yet. If you do and find the "Cannot find package that provides spglib" message gone, please close this bug. Best, Andrius
Bug#1063151: igb: unpredictable interface names for four port nic
Dear Valentin, On Tue, Feb 06, 2024 at 03:58:45PM +0100, Valentin wrote: > I suspect the issue might be somewhere in your udev configuration. > > You can get the evaluated udev rules by running 'udevadm test ' > > So running 'udevadm test /sys/class/net/ens6f2' and 'udevadm test /sys/class/ > net/eth0' and comparing outputs should tell you/everyone else whats different > for those devices and why they use different naming schemes. Output of both commands attached… > The old ethX names depend on the order of initialization and is therefore > unstable. > The new format (e.g. ens6f2) depends on pci device numbers and is stable. Yes, unstable are old names, right Some errors are reported for eth0 interface: eth0: Policy *slot* yields "ens6f0". eth0: Could not set AlternativeName= or apply AlternativeNamesPolicy=, ignoring: File exists eth0: /usr/lib/udev/rules.d/80-net-setup-link.rules:11 NAME 'ens6f0' eth0: /usr/lib/udev/rules.d/99-systemd.rules:68 RUN '/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name' eth0: sd-device: Created db file '/run/udev/data/n69' for '/devices/pci:00/:00:1c.0/:01:00.0/net/eth0' ens6f0: Failed to rename network interface 69 from 'eth0' to 'ens6f0': File exists The bug should be reassigned to udev. Thank you very much for tip! -- Zito Trying to open "/etc/systemd/hwdb/hwdb.bin"... Trying to open "/etc/udev/hwdb.bin"... Trying to open "/usr/lib/systemd/hwdb/hwdb.bin"... Trying to open "/lib/systemd/hwdb/hwdb.bin"... Trying to open "/lib/udev/hwdb.bin"... === trie on-disk === tool version: 252 file size:12210802 bytes header size 80 bytes strings2564306 bytes nodes 9646416 bytes Loading kernel module index. Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy Found container virtualization none. Using default interface naming scheme 'v252'. Parsed configuration file "/usr/lib/systemd/network/99-default.link" Parsed configuration file "/usr/lib/systemd/network/73-usb-net-by-mac.link" Created link configuration context. Reading rules file: /usr/lib/udev/rules.d/50-firmware.rules Reading rules file: /usr/lib/udev/rules.d/50-udev-default.rules Reading rules file: /usr/lib/udev/rules.d/55-dm.rules Reading rules file: /usr/lib/udev/rules.d/56-dm-parts.rules Reading rules file: /usr/lib/udev/rules.d/56-lvm.rules Reading rules file: /usr/lib/udev/rules.d/60-autosuspend.rules Reading rules file: /usr/lib/udev/rules.d/60-block.rules Reading rules file: /usr/lib/udev/rules.d/60-bridge-network-interface.rules Reading rules file: /usr/lib/udev/rules.d/60-cdrom_id.rules Reading rules file: /usr/lib/udev/rules.d/60-drm.rules Reading rules file: /usr/lib/udev/rules.d/60-evdev.rules Reading rules file: /usr/lib/udev/rules.d/60-fido-id.rules Reading rules file: /usr/lib/udev/rules.d/60-infiniband.rules Reading rules file: /usr/lib/udev/rules.d/60-input-id.rules Reading rules file: /usr/lib/udev/rules.d/60-kpartx.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-alsa.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-input.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-storage-dm.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-storage-tape.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-storage.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-v4l.rules Reading rules file: /usr/lib/udev/rules.d/60-qemu-guest-agent.rules Reading rules file: /usr/lib/udev/rules.d/60-sensor.rules Reading rules file: /usr/lib/udev/rules.d/60-serial.rules Reading rules file: /usr/lib/udev/rules.d/64-btrfs.rules Reading rules file: /usr/lib/udev/rules.d/68-del-part-nodes.rules Reading rules file: /usr/lib/udev/rules.d/69-lvm.rules Reading rules file: /usr/lib/udev/rules.d/70-camera.rules Reading rules file: /usr/lib/udev/rules.d/70-joystick.rules Reading rules file: /usr/lib/udev/rules.d/70-memory.rules Reading rules file: /usr/lib/udev/rules.d/70-mouse.rules Reading rules file: /usr/lib/udev/rules.d/70-power-switch.rules Reading rules file: /usr/lib/udev/rules.d/70-touchpad.rules Reading rules file: /usr/lib/udev/rules.d/70-uaccess.rules Reading rules file: /usr/lib/udev/rules.d/71-seat.rules Reading rules file: /usr/lib/udev/rules.d/73-seat-late.rules Reading rules file: /usr/lib/udev/rules.d/73-special-net-names.rules Reading rules file: /usr/lib/udev/rules.d/75-net-description.rules Reading rules file: /usr/lib/udev/rules.d/75-probe_mtd.rules Reading rules file: /usr/lib/udev/rules.d/78-sound-card.rules Reading rules file: /usr/lib/udev/rules.d/80-debian-compat.rules Reading rules file: /usr/lib/udev/rules.d/80-drivers.rules Reading rules file: /usr/lib/udev/rules.d/80-ifupdown.rules Reading rules file: /usr/lib/udev/rules.d/80-net-setup-link.rules Reading rules file: /usr/lib/udev/rules.d/81-net-dhcp.rules Reading rules file:
Bug#1059476: anyone?
Hello, anyone?
Bug#1063151: igb: unpredictable interface names for four port nic
I suspect the issue might be somewhere in your udev configuration. You can get the evaluated udev rules by running 'udevadm test ' So running 'udevadm test /sys/class/net/ens6f2' and 'udevadm test /sys/class/ net/eth0' and comparing outputs should tell you/everyone else whats different for those devices and why they use different naming schemes. The old ethX names depend on the order of initialization and is therefore unstable. The new format (e.g. ens6f2) depends on pci device numbers and is stable. Cheers, Valentin
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
On Tue, Feb 06, 2024 at 11:34:07AM +0100, Adrien Nader wrote: > Providing two APIs makes me quite uneasy due to having core components > that would behave differently from the rest of the distribution. It > sounds like something that will come back to bite for a long time. Can you elaborate? Keep in mind that for all the 64bit architectures, there is no abi difference as the symbol is only added for those architectures, that currently use a 32bit ino_t. > I checked on codesearch.d.n and there are very few users on this API; > actually, none I think. Per > https://codesearch.debian.net/search?q=matchpathcon_filespec_add=1=1 > - box64 mentions that API but the "code" is commented-out, > - busybox uses it in the "setfiles" applet which isn't built, > - android-platform-external-libselinux has it in headers but also has > its own implementation > > That should hopefully give more freedom although I'm not sure what would > be the preferred route. And here you are arguing that there are no practical users of the added symbol, so with luck, we'd be adding an unused symbol on armhf. With bad luck, we'd have some users and for those users we'd be ABI-incompatible with the rest of the world on armhf. Helmut
Bug#1063351: Missing dependencies in lollypop package
Package: lollypop Version: 1.4.37-1 There is a possibility of missing dependencies in this package. After a fresh install of lollypop (sudo apt install lollypop), the app is not able to add any music files to the library. Also not able to play by opening audio files directly from the file manager. Running lollypop in debug mode (lollypop -d) gave several of the following error, [ERROR] 2024-02-06 15:16:30 AlbumArtwork::__get_pixbuf_from_tags(): gst-core-error-quark: Your GStreamer installation is missing a plug-in. (12) Installing the rhythmbox package makes lollypop work, which leads me to believe that several crucial dependencies weren't installed before. Purging rhythmbox (sudo apt purge rhythmbox) without removing its dependencies doesn't break lollypop. But "sudo apt autoremove" does, which solidifies my suspicion of missing dependencies during install. All or some of the dependencies of rhythmbox which are necessary to lollypop and hence attached herewith. PS: This is my first ever bug report, pardon me if I broke any etiquettes in reporting a bug. I'm using Debian 12, 6.1.0-17 kernel. Also note that my machine has xfce instead of gnome and perhaps these dependencies are native to gnome. Possible dependencies bubblewrap docbook-xml fonts-dejavu fonts-dejavu-extra gir1.2-javascriptcoregtk-4.0 gir1.2-peas-1.0 gir1.2-rb-3.0 gir1.2-soup-2.4 gir1.2-webkit2-4.0 gsfonts gstreamer1.0-plugins-bad gstreamer1.0-plugins-good gstreamer1.0-plugins-ugly gstreamer1.0-x imagemagick-6-common libatomic1 libdirectfb-1.7-7 libdjvulibre-text libdjvulibre21 libdmapsharing-3.0-2 libdv4 libfftw3-double3 libfluidsynth3 libfreeaptx0 libgpod-common libgpod4 libgrilo-0.3-0 libgssdp-1.6-0 libgstreamer-plugins-bad1.0-0 libgupnp-1.6-0 libgupnp-igd-1.0-4 libharfbuzz-icu0 libhyphen0 libimath-3-1-29 libinstpatch-1.0-2 libjavascriptcoregtk-4.0-18 libjavascriptcoregtk-4.1-0 libjxr-tools libjxr0 libldacbt-enc2 liblqr-1-0 liblrdf0 libltc11 libmagickcore-6.q16-6 libmagickcore-6.q16-6-extra libmagickwand-6.q16-6 libmanette-0.2-0 libmjpegutils-2.1-0 libmodplug1 libmpeg2encpp-2.1-0 libmplex2-2.1-0 libneon27 libnice10 libopencore-amrnb0 libopencore-amrwb0 libopenexr-3-1-30 libopenh264-7 libopenni2-0 libpeas-1.0-0 libpeas-common libpipewire-0.3-0 libpipewire-0.3-common libraptor2-0 librhythmbox-core10 libsbc1 libsgutils2-1.46-2 libsidplay1v5 libsoundtouch1 libsoup-gnome2.4-1 libspa-0.2-modules libspandsp2 libsrtp2-1 libv4l-0 libv4lconvert0 libvo-aacenc0 libvo-amrwbenc0 libwavpack1 libwebkit2gtk-4.0-37 libwebkit2gtk-4.1-0 libwildmidi2 libwmflite-0.2-7 libwoff1 libwpe-1.0-1 libwpebackend-fdo-1.0-1 libyajl2 libyelp0 libzbar0 libzxing2 media-player-info python3-distro python3-mako python3-markupsafe rhythmbox-data sgml-data timgm6mb-soundfont xdg-dbus-proxy xdg-desktop-portal xdg-desktop-portal-gtk yelp yelp-xsl
Bug#1063146: fai-setup-storage: New dependency on /usr/lib/fai/subroutines
Actually it's worse than that. Even with the fai-client package installed I cannot run fai-disk-info With version 6.0 I get: /usr/lib/fai/fai-disk-info sda with version 6.2 I get: /usr/lib/fai/fai-disk-info bash: set_bootstick: command not found bash: once_only: command not found bash: all_disks_and_size: command not found bash: checkdisk: command not found which in turn breaks the setup-storage utility. Regards, Stephen Quinney On Mon, 5 Feb 2024 at 11:45, Stephen Quinney wrote: > > Package: fai-setup-storage > Version: 6.2 > Severity: important > X-Debbugs-Cc: step...@jadevine.org.uk > > We use the fai-setup-storage utility in a standalone way (i.e. not > with the rest of FAI) as part of our local installation and > configuration scripts. This has always worked perfectly up to version > 6.0. > > With the recent changes in 6.2 the fai-disk-info script now requires > /usr/lib/fai/subroutines which is in the fai-client package but there > is no dependency declared. If the fai-client package is not installed > setup-storage will now completely fail to run. > > Regards, > > Stephen Quinney > > -- 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.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages fai-setup-storage depends on: > ii e2fsprogs 1.47.0-2 > pn liblinux-lvm-perl > ii libparse-recdescent-perl 1.967015+dfsg-4 > ii parted3.5-3 > ii perl 5.36.0-7+deb12u1 > > Versions of packages fai-setup-storage recommends: > ii lvm2 2.03.16-2 > pn mdadm > > Versions of packages fai-setup-storage suggests: > ii cryptsetup 2:2.6.1-4~deb12u1 > ii dmsetup2:1.02.185-2 > ii dosfstools 4.2-1 > pn jfsutils > ii ntfs-3g1:2022.10.3-1+b1 > pn reiserfsprogs > pn xfsprogs
Bug#1063350: lists.debian.org: Request for new mailinglist: debian-debtags
Package: lists.debian.org Severity: wishlist X-Debbugs-Cc: bir...@debian.org Hi, for communication about managing and developing the debtags.debian.org service, we would like to have a new Debian mailinglist: Name: debian-debtags Rationale: main communication about the debtags.d.o Debian service Short description: debtags, the Debian package tagging system Long description: Discussions and development of debtags, the Debian package tagging system. Category: Developers Subscription Policy: open Post Policy: open Web Archive: yes cheers, Birger
Bug#1063349: libamd-comgr2 exports wrong symbol version
Package: libamd-comgr2 Version: 5.2.3-2 Severity: important As discussed in this thread [1], libamd-comgr2 exports amd_comgr_get_isa_count@1.8 when upstream is at @2.0. This is because the symbol was erroneously not removed from @1.8 when it was added to @2.0 when the ABI changed. The discrepancy between upstream and our version needs to be resolved. [1] https://lists.debian.org/debian-ai/2024/01/msg00087.html
Bug#1063348: O: pdfkit
Package: wnpp Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org Control: affects -1 src:pdfkit I am no longer interested in this package and no else in the Debian Python Team expressed interest it taking it over, so orphaning. The package itself is in reasonable shape. Upstream includes the following warning in the Git version of the package README: This library has been deprecated to match the wkhtmltopdf project status. Scott K
Bug#1063347: ITP: td -- telegram client library
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: "Ying-Chun Liu (PaulLiu)" Severity: wishlist * Package name: td Version : 1.8.0 Upstream Contact: https://github.com/tdlib/td * URL : https://core.telegram.org/tdlib * License : Boost Software License 1.0 Programming Lang: C++ Description : telegram database library TDLib (Telegram Database Library) is a cross-platform, fully functional Telegram client. This library helps third-party developers create their own custom apps using the Telegram platform. OpenPGP_0x44173FA13D05.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
