Bug#1055448: RFS: libsilkit/4.0.37-1 [ITP] -- Simulation in the loop kit by Vector
Hi Tobias, Thank you for the quick review. I will try to provide some quick feedback/acknowledgement as well below. On Sun, 12 Nov 2023 11:17:36 +0100 Tobias Frost wrote: > Control: tags -1 moreinfo > > Hi Jan, > > Thanks for your RFS! > as you are listed as upstream contact, let me, as I always do, point you to > https://wiki.debian.org/UpstreamGuide > > As this is your first package your are maintaining, please also read > https://mentors.debian.net/intro-maintainers/ > > This part of the CONTRIBUTING.md concerns me: > We are sorry, but at the moment, we do not accept external contributions >until > wehave established a contribution process. We're working behind the scenes >to > get this ready in the future. Until then, we would kindly ask you to not >open pull > requests. > > This stanca is older than a year (Aug 2022), so when will this happen? > > Sorry to be blunt, but putting a DFSG license on a piece of software and > then saying we do not accept contributions, is (IMHO) not within the > spirit of the Open Source Community, even if it might on paper fullfil > the DFSG. > > This is also problematic for maintaining the package, as how should we, > as Debian, upstream patches, for example if you are go missing for > whatever reasons? Effectively, we would need to maintain a fork, and > that is certainly nothing Vector could want. > > I'd say this brings the RFS very close to the "wontfix" territory, > certainly I will not sponsor this upload, but other sponsors might. > (The review below is partial, done until I saw the README.) > Our team knows that this is not ideal from a community perspective and we are working towards a solution. I will try to get back to you ASAP on these points. > In Debian we do not package every software. So maybe I'll need a salse > pitch here: > - Why does Vector want it in the Debian archives? > - Why would Debian want it to be in the Debian archives? > - Are there other projects using the library that you intend to package > for Debian? > I will probably bundle this with the answer above since both deal with Vectors overall FOSS strategy. > On Mon, Nov 06, 2023 at 12:57:23PM +, > =?UTF-8?Q?Kr=C3=a4...@buxtehude.debian.org wrote: > > > * Package name : libsilkit > > Version : 4.0.37-1 > > Upstream contact : jan.krae...@vector.com > > * URL : https://github.com/vectorgrp/sil-kit > > * License : MIT > > * Vcs : https://github.com/vectorgrp/sil-kit > > Section : libs > > > > The source builds the following binary packages: > > > > libsilkit-dev - Development packages for libsilkit > > libsilkit4 - Simulation in the loop kit by Vector > > > > To access further information about this package, please visit the > > following URL: > > > > https://mentors.debian.net/package/libsilkit/ > > > > Alternatively, you can download the package with 'dget' using this command: For some reason the last part of your email is omitted from the quote, but it seems I missed quite some stuff. Thanks though for the feedback. I will work on a revised version now and update the bug report once it is uploaded. I still have some questions: - Is it permitted to update the libsilkit version (to 4.0.39) within the review process? - The only remaining vendoring is GoogleTest, which is only used for the unit/integration tests which are not shipped by the package. Is this allowed or should we use the systems libraries here as well? - Related, if this is allowed, do we need to include the License information, since we do not ship source files nor object files compiled with these source files in the binary package? Cheers and thanks again for the review, Jan
Bug#1055913: rust-http-body: please provide newer upstream branch v1.0
Source: rust-http-body Version: 0.4.5-1 Severity: normal Tags: upstream Please separately most likely separately rather than upgrading, due to not yet stable) newer upstream branch v1.0 (even if only available as release candidate for now).
Bug#810018: New Essential package procps-base
Hello, For quite some time (since 2006!) there has been a discussion at[1] about changing from the sysvinit-utils version of pidof to the procps one. A quick scan of the various distributions shows that only Debian and Ubuntu (and I assume most other downstreams) use the sysvinit-utils version. So to rehash some old drafts, here's the proposal. What: Create a new package procps-base. This uses the existing procps source package and just enable building of pidof. procps-base will be an Essential package and only contain pidof. Why: This would bring the pidof variant in line with other distributions. sysvinit-utils would no longer need to be Essential (though that's a separate issue) and would only have init-d-script, fstab-decode, and killall5. The majority of usage of pidof is in init or pre/post scripts, which really should be using the LSB pidofproc function. That function in turn optionally uses pidof if the pidfile parameter is not given. That's probably a way forward for sometime in the future to not need procps-base Essential, but it is a way off. sysvinit-utils requires only libc6 while procps-base require libproc-2 but this is the same library used for the ps,top,w etc tools which are installed on most systems. 1: https://bugs.debian.org/810018
Bug#1037135: please update to latest upstream version (>> 4.2.0) and confirm intent to maintain package
On Monday, 10 July 2023 at 03:19, Nicholas D Steeves wrote: > You've got this! :) You're already using a gbp (git-buildpackage) style > git repository so this is very easy. Just use the Files-Excluded > feature of debian/control, and run "gbp import-orig --uscan". I have finally pushed the update! Hopefully the package is built properly. I have verified that docs are indeed excluded. I can update `Uploader` section as well to reflect my new working email, but haven't pushed the change yet. Is it recommended that I do this(it probably is)? Any specific things I should consider? Thanks for the hints, those helped me be super quick about the things. - Dhavan.
Bug#1055912: RFS: python-scienceplots/2.1.0-3 -- Matplotlib styles for scientific figures
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: kd8...@gmail.com Dear mentors, I am looking for a sponsor for my package "python-scienceplots": * Package name : python-scienceplots Version : 2.1.0-3 Upstream contact : John Garrett * URL : https://github.com/garrettj403/SciencePlots * License : Expat * Vcs : https://salsa.debian.org/yogu/python-scienceplots Section : python The source builds the following binary packages: python3-scienceplots - Matplotlib styles for scientific figures To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-scienceplots/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-scienceplots/python-scienceplots_2.1.0-3.dsc Changes since the last upload: python-scienceplots (2.1.0-3) unstable; urgency=medium . * Included PYBUILD_NAME. (Closes: #1055910) * Removed unnecessary depends, pre-depends in binary. * Removed unnecessary files from python3-scienceplots.docs. * Revised copyright License as Expat. Regards, -- Yogeswaran Umasankar
Bug#1032104: Status update
I have traced this bug to a missing memory barrier in the powerpc IPI handling code. io_uring uses task_work_add() to schedule I/O worker creation, which in turn issues an IPI, and when precise timing conditions are met the inconsistent state between the two CPU cores can lead to corruption of userspace data in RAM. I have sent a patch upstream, and created a merge request for Debian here: https://salsa.debian.org/kernel-team/linux/-/merge_requests/907
Bug#1055911: RFS: python-art/6.1-3 -- ASCII art
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: kd8...@gmail.com Dear mentors, I am looking for a sponsor for my package "python-art": * Package name : python-art Version : 6.1-3 Upstream contact : Sepand Haghighi * URL : https://github.com/sepandhaghighi/art * License : Expat * Vcs : https://salsa.debian.org/yogu/python-art Section : python The source builds the following binary packages: python3-art - ASCII art To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-art/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-art/python-art_6.1-3.dsc Changes since the last upload: python-art (6.1-3) unstable; urgency=medium . * Corrected PYBUILD_NAME. (Closes: #1055906) * Removed unnecessary depends, pre-depends in binary. * Removed unnecessary files from python3-art.docs. * Revised copyright License as Expat. Regards, -- Yogeswaran Umasankar
Bug#1055910: python-scienceplots: Missing PYBUILD_NAME
Source: python-scienceplots Version: 2.1.0-2 Severity: normal X-Debbugs-Cc: kd8...@gmail.com PYBUILD_NAME missing and listed unnecessary depends and pre-depends. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.5.0-4-arm64 (SMP w/2 CPU threads) 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
Bug#1055909: VIM: adding "set mouse=" into /etc/vim/vimrc doesn't work
Package: src:vim Version: 2:9.0.2103-1 In general, I love the default settings of VIM, while "set mount=a" is an exception. So I try to add "set mount=" in to /etc/vim/vimrc or /etc/vim/vimrc.local, but it doesn't work. With `vim -V xx.txt`, it shows that the /etc/vim/vimrc is sourced very earlier than files in /usr/share/vim. Maybe, it is the real problem. Yes, I can add "~/.vimrc", while with this file exists, some other config is missing, like setting curse postion to the last edit.
Bug#1055908: nmu: libwx-perl_1:0.9932-8+b2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: libwx-p...@packages.debian.org Control: affects -1 + src:libwx-perl nmu libwx-perl_1:0.9932-8+b2 . ANY . unstable . -m "Rebuild for wxwidgets3.2 (3.2.4+dfsg-1)"
Bug#1055907: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org Control: affects -1 + src:libalien-wxwidgets-perl nmu libalien-wxwidgets-perl_0.69+dfsg-6+b3 . ANY . unstable . -m "Rebuild for wxwidgets3.2 (3.2.4+dfsg-1)"
Bug#1055895: [Pkg-rust-maintainers] Bug#1055895: rust-self-cell: RUSTSEC-2023-0070
Please see https://rustsec.org/advisories/RUSTSEC-2023-0070.html I have read the upstream advisory and the linked bug report and while I don't fully understand the nitty gritty details my understanding of the issue is. * It was discovered that code (which was not marked as unsafe) could mis-use self-cell in a way that invoked undefined behaviour. * This was fixed by adding an additional compile time check which will cause the build to fail in such cases. Based on this understanding I have * Uploaded the new version of rust-self-cell * Performed a rebuild test of the only reverse dependency rust-coreutils, it built successfully, so presumably it is not impacted by this issue.
Bug#1052557: fpc: Compiler bootstrap for more release architectures
Hi! On Sun, Sep 24, 2023 at 07:59:41PM +0200, Paul Gevers wrote: Hi, On 24-09-2023 19:38, Bastian Germann wrote: How is the bootstrap done and is it planned? I recall that bug 551400 and/or 784569 give quite some insight in what needs to be done. I don't have any plans of bootstrapping fpc ever again. If anything, I'd like to see the glibc 'arch' of fpc actually working, then we could support all Debian architectures *and* cross building would probably be easier. But it all has been a while. I would like to add riscv64 and mips64el support for fpc here. But there are some unknown field for me about glibc to support cross build on fpc. Could you share some links where I should to start? Just follow this one? https://wiki.lazarus.freepascal.org/Cross_compiling BR, Bo Paul -- Regards, -- Bo YU signature.asc Description: PGP signature
Bug#1055906: python-art: Incorrect PYBUILD_NAME
Source: python-art Version: 6.1-2 Severity: normal X-Debbugs-Cc: kd8...@gmail.com PYBUILD_NAME should be 'art'. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.5.0-4-arm64 (SMP w/2 CPU threads) 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
Bug#1055905: Build dependencies not installable on (old)stable
On Mon, 2023 Nov 13 21:00-05:00, Andres Salomon wrote: > > That is a harder question to answer. :) > > If you go to https://buildd.debian.org/status/package.php?p=chromium > and select "Bookworm" for the suite, and hit "Go", you can see the > build logs for the latest (bookworm) release. However, I have no idea > how to get build logs for older releases - the "old" link takes you to > older build logs for sid. I suspect that's a bug. Okay, so it's not just me. getbuildlog(1) likewise doesn't work for the (old)stable versions. That would be a pretty flagrant bug, so hopefully someone else will notice and straighten it out. Thanks again!
Bug#1055905: Build dependencies not installable on (old)stable
On Mon, Nov 13 2023 at 08:52:38 PM -05:00:00, Daniel Richard G. wrote: (Where can I find the build logs? Those would have answered this question, and more.) That is a harder question to answer. :) If you go to https://buildd.debian.org/status/package.php?p=chromium and select "Bookworm" for the suite, and hit "Go", you can see the build logs for the latest (bookworm) release. However, I have no idea how to get build logs for older releases - the "old" link takes you to older build logs for sid. I suspect that's a bug.
Bug#1055905: Build dependencies not installable on (old)stable
On Mon, 2023 Nov 13 20:24-05:00, Andres Salomon wrote: > The dependencies are in (old)stable-proposed-updates. For example, add > the following to your /etc/apt/sources.list: > > deb http://deb.debian.org/debian/ bullseye-proposed-updates main > deb-src http://deb.debian.org/debian/ bullseye-proposed-updates main Thanks, I've confirmed that this allows build-dep to succeed on bookworm. (Where can I find the build logs? Those would have answered this question, and more.) > The buildds already use these repos, which is why building chromium > works. Once a new (old)stable point release is made, the packages will > move from (old)stable-proposed-updates into (old)stable. According to > https://lists.debian.org/debian-release/2023/11/msg00136.html , the > next bookworm point release (12.3) should be happening on Dec 9th. This is good to know, as I would have expected a newer compiler to land in -backports.
Bug#1055882: libncurses6: waddnstr() reads n+1 bytes, ought to end at n bytes
On Mon, Nov 13, 2023 at 02:54:06PM +0100, наб wrote:
> Package: libncurses6
> Version: 6.4-4
> Severity: normal
> Tags: patch
...
> I see "while ((*str != '\0') && (n-- > 0)) {" is in the wrong order,
> and ought to be "(n-- > 0) && (*str != '\0')" ‒ only reading from str
> when it's not past the end.
It's a little more complicated than that. The problem was introduced here:
20201205
+ eliminate an additional strlen and wsclen.
+ eliminate an unnecessary strlen in waddnstr() (suggested by Benjamin
Abendroth).
The null terminator should be checked only for the special case where
the passed-in length is negative. I overlooked this case when eliminating
the strlen's. Here's what I have in mind (using a flag to short-circuit
past the test for null terminator):
diff -u -r1.58 lib_addstr.c
--- lib_addstr.c2022/06/11 20:12:04 1.58
+++ lib_addstr.c2023/11/14 01:09:13
@@ -55,16 +55,18 @@
T((T_CALLED("waddnstr(%p,%s,%d)"), (void *) win, _nc_visbufn(astr, n), n));
-if (win && (str != 0)) {
+if (win && (str != 0) && (n != 0)) {
+ bool explicit = (n > 0);
+
TR(TRACE_VIRTPUT | TRACE_ATTRS,
("... current %s", _traceattr(WINDOW_ATTRS(win;
code = OK;
TR(TRACE_VIRTPUT, ("str is not null, length = %d",
- ((n > 0) ? n : (int) strlen(str;
- if (n < 0)
+ (explicit ? n : (int) strlen(str;
+ if (!explicit)
n = INT_MAX;
- while ((*str != '\0') && (n-- > 0)) {
+ while ((explicit || (*str != '\0')) && (n-- > 0)) {
NCURSES_CH_T ch;
TR(TRACE_VIRTPUT, ("*str = %#o", UChar(*str)));
SetChar(ch, UChar(*str++), A_NORMAL);
@@ -228,16 +230,18 @@
T((T_CALLED("waddnwstr(%p,%s,%d)"), (void *) win, _nc_viswbufn(str, n),
n));
-if (win && (str != 0)) {
+if (win && (str != 0) && (n != 0)) {
+ bool explicit = (n > 0);
+
TR(TRACE_VIRTPUT | TRACE_ATTRS,
("... current %s", _traceattr(WINDOW_ATTRS(win;
code = OK;
TR(TRACE_VIRTPUT, ("str is not null, length = %d",
- ((n > 0) ? n : (int) wcslen(str;
- if (n < 0)
+ (explicit ? n : (int) wcslen(str;
+ if (!explicit)
n = INT_MAX;
- while ((*str != L('\0')) && (n-- > 0)) {
+ while ((explicit || (*str != L('\0'))) && (n-- > 0)) {
NCURSES_CH_T ch;
TR(TRACE_VIRTPUT, ("*str[0] = %#lx", (unsigned long) *str));
SetChar(ch, *str++, A_NORMAL);
--
Thomas E. Dickey
https://invisible-island.net
signature.asc
Description: PGP signature
Bug#1055905: Build dependencies not installable on (old)stable
Package: chromium Version: 119.0.6045.123-1~deb12u1 On bookworm, with backports enabled: # apt-get build-dep chromium Reading package lists... Done Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: builddeps:chromium : Depends: lld-16 but it is not installable Depends: clang-16 but it is not installable Depends: clang-format-16 but it is not installable Depends: libclang-rt-16-dev but it is not installable E: Unable to correct problems, you have held broken packages. Where are those LLVM 16 packages supposed to come from? The same situation arises on bullseye. The associated chromium source package pages even notes those packages as "not available": https://packages.debian.org/source/bookworm/chromium https://packages.debian.org/source/bullseye/chromium Also, I cannot find (old)stable build logs for the package at e.g. https://buildd.debian.org/status/logs.php?pkg=chromium=amd64 Is there a different place where I should find them? I was hoping the build logs would shed some light on how these build dependencies were being handled. --Daniel -- Daniel Richard G. || sk...@iskunk.org My ASCII-art .sig got a bad case of Times New Roman.
Bug#1055904: RFP: liblouvre -- C++ library for building Wayland compositors
Package: liblouvre Severity: wishlist * Package name : liblouvre Version : 1.0.0 Upstream Author : Eduardo Hopperdietzel * URL : https://github.com/CuarzoSoftware/Louvre * License : GPL v3.0 Programming Lang : C++11 Description : C++ library for building Wayland compositors Dear Debian Package Maintainers, I hope this message finds you well. I am writing to request the inclusion of the Louvre library in the Debian package repository. Louvre is a high-performance C++ library designed for building Wayland compositors with a strong emphasis on ease of development. Key features of Louvre include: - Implementation of essential Wayland protocols necessary for constructing desktop compositors. - Provision of a default implementation for each signal, event or request, enabling developers to witness functional results from day one and gradually override functionality as needed. - Tools such as a scene and views system for 2D rendering that automatically paints only the damaged regions during a frame. - Support for multi-GPU setups, multi-session (TTY switching), input and graphic backends, and more. - Thanks to its multi-threaded architecture, Louvre maintains a high FPS rate when V-Sync is enabled even during the rendering of complex scenarios, avoiding the typical issue of single-threaded compositors experiencing a drop in FPS during screen vblank. I propose that the Louvre package be divided into the following components within the Debian repository: * liblouvre: This package would exclusively contain the shared library. * liblouvre-dev: This package would provide the development headers. * liblouvre-examples: This package would include the example binaries demonstrating Louvre's capabilities and usage. The Louvre project is well-documented, and build instructions for Debian are available at the following link: https://cuarzosoftware.github.io/Louvre/md_md__downloads.html If you have any questions or require further information, please do not hesitate to contact me. Thank you for your time and consideration. Best regards, Eduardo Hopperdietzel
Bug#967263: aumix: depends on deprecated GTK 2
Bastian Germann, le lun. 13 nov. 2023 21:56:09 +0100, a ecrit: > Am 26.10.23 um 17:31 schrieb Bastian Germann: > > On Tue, 4 Aug 2020 12:46:59 +0200 Samuel Thibault wrote: > > > I had mailed tre...@jpj.net about it in april, without any answer so > > > far. I guess we'll just disable the gtk build. > > > > I have disabled the gtk build in the git repo. > > I am uploading a NMU to DELAYED/10 in order to fix this. > For your convenience I have included all git changes that were made up to > this point. And tagged everything, thanks! Samuel
Bug#1055540: obs-time-source: FTBFS on several archs: linker input file not found
Some tests were made over Debian, Alpine and Fedora and the issue causing the FTBFS is present only on Debian. The Meson finds the libobs, but fails to build using it. Maybe it can be something related to #998853. The upstream doesn't have a solution because he uses Alpine and the build is perfect there (this bug is unreproducible outside of Debian). My solution (or temporary solution): commonly, plugins for OBS are build with CMake, so I made a patch[1] to use it instead of Meson. This solution works fine and it is based in CMakeLists.txt files provided by Exeldro in several plugins, like obs-move-transition[2]. [1] https://salsa.debian.org/debian/obs-time-source/-/blob/debian/master/debian/patches/010_use-cmake.patch [2] https://salsa.debian.org/debian/obs-move-transition/-/blob/debian/master/CMakeLists.txt Eriberto
Bug#1055903: typo in description: assmebly instead of assembly
Source: fp-units-win Version: 3.2.2+dfsg-20 Severity: normal Dear Pascal Packaging Team, The description of fp-units-win-wasm says Free Pascal - Web assmebly support units dependency package % apt-cache search assmebly fp-units-win-wasm - Free Pascal - Web assmebly support units dependency package fp-units-win-wasm-3.2.2 - Free Pascal - Web assmebly support units fp-units-wasm - Free Pascal - Web assmebly support units dependency package fp-units-wasm-3.2.2 - Free Pascal - Web assmebly support units Cheers, -- Bill. Imagine a large red swirl here.
Bug#1055901: [Pkg-raspi-maintainers] Bug#1055901: raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/
On 11/13/23 23:20, Cyril Brulebois wrote: Hilmar Preusse (2023-11-13): Hi, the package fails to install on my system. I simply assumes that /boot/firmware is a mount point and fails if this is not the case. If /boot/firmware is expected to be a mount point the installer should have created it. The system was once installed as bullseye and later upgraded to bookworm. What exactly is your system? What is that rpt suffix? It is an raspi3, not sure if that is the needed information, here comes the apt-cache policy hille@rasppi1:~ $ apt-cache policy raspi-firmware raspi-firmware: Installed: 1:1.20231024+ds-1+rpt1 Candidate: 1:1.20231024+ds-1+rpt1 Version table: *** 1:1.20231024+ds-1+rpt1 500 500 http://archive.raspberrypi.org/debian bookworm/main arm64 Packages 500 http://archive.raspberrypi.org/debian bookworm/main armhf Packages 100 /var/lib/dpkg/status 1.20220830+ds-1 500 500 http://deb.debian.org/debian bookworm/non-free-firmware arm64 Packages 500 http://deb.debian.org/debian bookworm/non-free-firmware armhf Packages Does that help you anyhow? Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055846: texlive-extra-utils: spix is listed in the package description but not installed in package files
Control: severity -1 normal On 11/12/23 15:55, Vincent-Xavier JUMEL wrote: Hi, While I wanted to give spix a try (https://spix.readthedocs.io/en/latest/install/) I've trusted Debian to package it in this specific package, which is reported by `apt show texlive-extra-utils | grep spix` Instead, my shell reported no `/usr/bin/spix` and `dpkg -L texlive-extra-utils | grep spix` shows that spix is installed but misses a link in `/usr/bin/` Could you please fix it ? You may use the script even from the actual location, so the link in /usr/bin ist just for convenience. I'll update the link list soon. Lowering severity to normal. Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055901: [Pkg-raspi-maintainers] Bug#1055901: raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/
Hi, Hilmar Preusse (2023-11-13): > Package: raspi-firmware > Version: 1:1.20231024+ds-1+rpt1 > Severity: serious > Justification: Policy 6.4 > > Hello, > > the package fails to install on my system. I simply assumes that > /boot/firmware is a > mount point and fails if this is not the case. If /boot/firmware is expected > to be a > mount point the installer should have created it. The system was once > installed as > bullseye and later upgraded to bookworm. What exactly is your system? What is that rpt suffix? > Versions of packages raspi-firmware suggests: > ii bluez-firmware 1.2-9+rpt2 > ii firmware-brcm80211 1:20230210-5+rpt1 > ii firmware-misc-nonfree 1:20230210-5+rpt1 Here too. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1055901: Acknowledgement (raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/)
On 11/13/23 23:03, Debian Bug Tracking System wrote: Hi, Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 1055901: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055901. Here is the error message I get: hille@rasppi1:~ $ sudo apt -f install Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 2 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up raspi-firmware (1:1.20231024+ds-1+rpt1) ... Error: missing /boot/firmware, did you forget to mount it? dpkg: error processing package raspi-firmware (--configure): installed raspi-firmware package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of rpi-eeprom: rpi-eeprom depends on raspi-firmware; however: Package raspi-firmware is not configured yet. dpkg: error processing package rpi-eeprom (--configure): dependency problems - leaving unconfigured Processing triggers for initramfs-tools (0.142) ... Errors were encountered while processing: raspi-firmware rpi-eeprom E: Sub-process /usr/bin/dpkg returned an error code (1) Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055902: ITP: multispeech -- Multilingual speech server for Emacspeak
Package: wnpp Severity: wishlist Owner: "Igor B. Poretsky" * Package name: multispeech Version : 4.6.0 Upstream Author : Igor B. Poretsky * URL : https://github.com/poretsky/multispeech * License : GPL-2.0 Programming Lang: C++ Description : Multilingual speech server for Emacspeak Multispeech was primarily designed as a multilingual speech server for Emacspeak, but it can be useful in some other circumstances as well, when multilingual speech feedback is needed. For instance, it can serve as a backend module for Speech Dispatcher. Multispeech produces audible speech, sounds and tone signals according to the commands passed by client. It utilizes third party speech synthesis software to perform actual TTS transformation. The main feature of Multispeech is its facility to recognize language by context and automatically choose proper voice for it. Multispeech in its very early stage was included in Knoppix distribution about 20 years ago. Need sponsorship for upload.
Bug#1055901: raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/
Package: raspi-firmware Version: 1:1.20231024+ds-1+rpt1 Severity: serious Justification: Policy 6.4 Hello, the package fails to install on my system. I simply assumes that /boot/firmware is a mount point and fails if this is not the case. If /boot/firmware is expected to be a mount point the installer should have created it. The system was once installed as bullseye and later upgraded to bookworm. Himar -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 6.1.21-v8+ (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP 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) Versions of packages raspi-firmware depends on: ii dosfstools 4.2-1 ii dpkg1.21.22 raspi-firmware recommends no packages. Versions of packages raspi-firmware suggests: ii bluez-firmware 1.2-9+rpt2 ii firmware-brcm80211 1:20230210-5+rpt1 ii firmware-misc-nonfree 1:20230210-5+rpt1 -- no debconf information
Bug#1051236: proftpd-core: SSH key exchanges fail unexpectedly with "unable to write X bytes of raw data"
Hi, Thanks a lot for the effort. I guess it was worth it since my problem is solved. I've tried again with the latest version of my client and the "official" Debian 12 package and it was still failing. After installing your version of proftpd-basic, proftpd-core, proftpd-mod-crypto and proftpd-mod-wrap, everything is working fine again. On Tue, Nov 7, 2023 at 11:47 PM Hilmar Preuße wrote: > > On 9/4/23 22:10, Jeremy Lecour wrote: > > Hi Jeremy, > > > After upgrading to Debian 12, my SFTP client stopped working with > > errors when connecting. > > > > I've opened a GitHub issue and the problem has been solved. > > https://github.com/proftpd/proftpd/issues/1694 > > > > It will even be backported to the 1.3.8 branch, so I hope that it > > might be available in an upcoming update in Debian 12. > > > > I've put test packages here [1]. Could you try them and report back if > they solve the issue? > > Hilmar > > [1] https://freeshell.de/~hille42/debian_1051236/ > -- > Testmail > -- Jérémy Lecour : https://jeremy.lecour.fr - https://mastodon.evolix.org/@jlecour
Bug#1016430: netgen: New upstream version 6.2.2007 available / why is the version overriden with +really?
Hello Drew, On 11/13/23 14:52, Drew Parsons wrote: Package: netgen Followup-For: Bug #1016430 I've prepared netgen 6.2.2305 in experimental. I guess we might as well close this bug when it gets uploaded to unstable. Still, I'd also be interested to hear what the motivation was for the +really6.2.1905 version. Thank you very much for working on Netgen. (Sorry Tobias for never getting around to replying to this!) For convenience, let me quote for explanation my Nov 2020 Patreon post on this issue, but first TLDR, this was because upstream's use of architecture-specific assembly causing all builds except amd64 to fail, and patching that version was too difficult: The problem, for those who aren't familiar, was that Netgen upstream made several changes which are specific to the x86_64 (amd64) architecture in the 6.2.2006 release I had originally uploaded. Debian builds were only succeeding on amd64 but failing on all the other architectures: i386, armel, armhf, arm64, mipsel, mips64el, ppc64el, and s390x. I was able to fix some of the problems by switching to an older version (thus the version 6.2.2006+really6.2.1905) but that only fixed builds on i386 (aka 32-bit x86.) Problems still remained with the platform-specific usage of _mm_pause() and __rdtsc(). For __rdtsc(), I was able to resolve it with a patch to use C++11's std::chrono::steady_clock. For _mm_pause(), after some research I came up with a patch that uses architecture-specific assembly that corresponds to x86's _mm_pause() behavior. So, since you've gotten it working, there is indeed no reason to hold off on closing this bug and moving forward. Thanks, Kurt
Bug#1055900: ITP: freespeech -- English text preprocessor for MBROLA speech synthesizer
Package: wnpp Severity: wishlist Owner: "Igor B. Poretsky" * Package name: freespeech Version : 1.0m Upstream Author : Steve Isard, Alistair Conkie * URL : https://github.com/poretsky/freespeech * License : GPL Programming Lang: C Description : English text preprocessor for MBROLA speech synthesizer This software originates from the old archive found at http://tcts.fpms.ac.be/synthesis/mbrola/tts/English/fs.a10m.tar.gz. It contains English text to phoneme converter and pronunciation dictionary that being used along with mbrola speech synthesizer can provide full TTS functionality for English language. The mbrola package description in fact mentions freephone as a preprocessor along with cicero and espeak, but freephone itself is a part of this package. Thus, I think, it would be reasonable to have it in Debian as well. Looking for a sponsor to upload.
Bug#1055899: Allow HEIC extension for eog when heif-gdk-pixbuf is installed
Package: bash-completion Version: 1:2.11-6 Control: affects -1 + eog heif-gdk-pixbuf When the package heif-gdk-pixbuf is installed, the Eyes Of GNOME image viewer (eog) can display HEIC files. However, install heif-gdk-pixbuf and eog, open an xterm on Xorg, cd into /tmp, ensure that no files matching the pattern file* are present in /tmp, and then issue the following: $ touch file.jpg $ touch file.heic $ eog file↹ The symbol ↹ means you should hit the [Tab] button on the keyboard. We observe the autocompletion of the above to $ eog file.jpg Now let's replace the last three chars by "h" and hit [Tab] again: $ eog file.h↹ We observe that nothing autocompletes; the result is as before (“$ eog file.h”) despite the existence of a unique file starting with “file.h” (namely, file.heic). We kindly ask that the extensions heic and HEIC be recognized as valid for eog iff heif-gdk-pixbuf is installed. Gratefully, Alma
Bug#1055646: gdb: extremely slow response to basic commands
Hello Tomazzi, On Mon, 13 Nov 2023 at 21:51, tomazzi wrote: > > Hello, > > I've just built gdb "the Debian way", to check what are the differences > in the build process: > $> apt source gdb > $> apt build-dep gdb > $> debuild -b -uc -us > > From debuild output: > > gdb-default: configured with: > ... > --without-babeltrace > --with-babeltrace > ... > gdb-minimal: configured with: > ... > --without-babeltrace > --with-babeltrace > --without-babeltrace > ... > > This looks bad, but the results are even more "interresting": Latest switch is the one that should be in-use > The gdb binary installed in the system (**debsums OK**) reports the > following configuration (the "show configuration" command, differences > only): > > ... > --with-babeltrace > --with-mpfr > --with-xxhash > --with-python=/usr (relocatable) > --with-python-libdir=/usr/lib (relocatable) > --enable-source-highlight > ... > > The newly "debuild" gdb reports something *different*: > ... > --without-babeltrace << this: conflicting build flags > --without-mpfr > --with-xxhash > --without-python > --without-python-libdir > --disable-source-highlight > ... > > > The gdb which I've compiled using ./configure script (so *without* > Debian patches) reports: > ... > --with-babeltrace > --with-mpfr > --without-xxhash << this: libxxhash-dev is installed, but > flag is disabled ? > --with-python=/usr > --with-python-libdir=/usr/lib > --disable-source-highlight << this > ... > Could you share your conclusion or a patch? I quite do not understand what you are trying to say with all those examples. Regards -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Bug#1055898: ITP: rulex -- Pronunciation dictionary for Russian TTS engine
Package: wnpp Severity: wishlist Owner: "Igor B. Poretsky" * Package name: rulex Version : 3.8.0 Upstream Author : Igor B. Poretsky * URL : https://github.com/poretsky/rulex * License : LGPL-2.1 Programming Lang: C Description : Pronunciation dictionary for Russian TTS engine RuLex database is primarily intended for use along with the Ru_tts (https://github.com/poretsky/ru_tts) speech synthesizer in order to improve its pronunciation. This package provides lexical database itself, its data access library and some additional utilities to deal with it. These include text preprocessor rulex and lexholder-ru utility that allows one to browse and alter the database content. Being developed for some years as an open source project RuLex database was eventually used by RHVoice TTS engine (https://github.com/RHVoice/RHVoice). Need a sponsor for upload.
Bug#1016430: netgen: New upstream version 6.2.2007 available / why is the version overriden with +really?
Package: netgen Followup-For: Bug #1016430 I've prepared netgen 6.2.2305 in experimental. I guess we might as well close this bug when it gets uploaded to unstable. Still, I'd also be interested to hear what the motivation was for the +really6.2.1905 version.
Bug#810018: Bug #810018: Consider shipping pidof with procps
On Mon, 13 Nov 2023 at 21:07, Craig Small wrote: > > On Tue, 14 Nov 2023 at 06:09, Mark Hindley wrote: >> >> IIUC, the proposal[1] was to create a new Essential procps-base just >> containing >> pidof. Otherwise bin:procps would have to become Essential itself. Its >> installed >> size is about 20 times larger than sysvinit-util and that wouldn't >> contribute to >> shrinking the Essential set. >> >> I think this approach would also require a debian-devel email announcing the >> addition to the Essential set and I suppose the new src:procps will need a >> trip >> through NEW. > > Good catch, I'll write something up on this as it changes a lot. There are > probably two questions > 1) Does pidof need to be in an Essential package? While a lot of packages do > have pidof in them a lot (but not all) of those are in init scripts. > 2) Does pidof need its own package then I think it's easier and less work for everyone involved to keep it essential for now, and then eventually be scaled back and merged back into the existing package later.
Bug#1055826: bullseye-pu: package crun/0.17+dfsg-1+deb11u2 (bullseye regression)
On Mon, 2023-11-13 at 06:37 +0200, Faidon Liambotis wrote: > On Sun, Nov 12, 2023 at 03:06:34PM +, Adam D. Barratt wrote: > > On Sun, 2023-11-12 at 09:56 +0200, Faidon Liambotis wrote: > > > A change merged into Linux v6.6 broke crun. The change was > > > backported > > > in the stable branch with v6.1.55, the version in bookworm. We > > > fixed > > > crun last week crun 1.8.1-1+deb12u1 (unblock request: #1055241). > > > > > > Salvatore Bonaccorso pointed out that the change was backported > > > into > > > all the stable branches, including v5.10.197, the version now in > > > bullseye. bullseye's crun, v0.17, is also affected, therefore > > > bullseye crun + bullseye Linux (or bullseye crun+bullseye- > > > backports > > > Linux etc.) are now broken as well. > > > > I guess you'd like that pushed via bullseye-updates, once it's > > ready, > > as with the bookworm update? > > Yes please :) > Done, as SUA 244-1. Regards, Adam
Bug#810018: Bug #810018: Consider shipping pidof with procps
On Tue, 14 Nov 2023 at 06:09, Mark Hindley wrote: > IIUC, the proposal[1] was to create a new Essential procps-base just > containing > pidof. Otherwise bin:procps would have to become Essential itself. Its > installed > size is about 20 times larger than sysvinit-util and that wouldn't > contribute to > shrinking the Essential set. > > I think this approach would also require a debian-devel email announcing > the > addition to the Essential set and I suppose the new src:procps will need a > trip > through NEW. > Good catch, I'll write something up on this as it changes a lot. There are probably two questions 1) Does pidof need to be in an Essential package? While a lot of packages do have pidof in them a lot (but not all) of those are in init scripts. 2) Does pidof need its own package then - Craig
Bug#1055765: chromium: Error: Can't open display (armhf) while other platforms (amd64, arm64, i386) are OK
Control: found -1 117.0.5938.149-1~deb12u1 Thanks. More questions below: On Mon, Nov 13 2023 at 08:28:41 PM +01:00:00, Julien Neuhart wrote: I’ve been able to reproduce the issue (e.g., Can’t open display) with versions 117.0.5938.149-1~deb12u1 and 118.0.5993.70-1~deb12u1. uname -a: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP Fri Oct 6 13:20:44 UTC 2023 armv7l3 GNU/Linux Okay, this looks fine. You're running qemu on an Ubuntu x86 host, so inside the VM it sees the Ubuntu kernel but as an armv7l architecture. Chromium's startup script should run `uname -m`, see 'armv7l', and do its 32-bit ARM checks. cat /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 106 model name : Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz Wait, what? Qemu doesn't bother to change /proc/cpuinfo for the VM, so it's going to think it's running an x86 CPU? stepping: 6 microcode : 0x cpu MHz : 2793.437 cache size : 49152 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 21 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap clflushopt avx512cd avx512bw avx512vl xsaveopt xsavec xsaves md_clear bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit mmio_stale_data gds Ugh, nor does it change cpu flags. The chromium script (/usr/bin/chromium) should've errored out with a message about NEON once it saw that the flags it needed in /proc/cpuinfo weren't present. So there's two problems here. Can you please run `bash -x /usr/bin/chromium --version` and provide the output from that? Something's going wrong there. What *should* be happening is that you should be seeing the message: "The hardware on this system lacks support for NEON SIMD extensions. We now require NEON or equivalent architecture extensions on ARM-based machines. See https://lists.debian.org/debian-devel/2023/09/msg00175.html for more information." Instead, it seems to be going ahead and launching chromium, which is likely then getting confused for other reasons. Feel free to use the latest available version of chromium for that test, you don't need to stick with 117 or whatever. Now, there's also the separate question of what qemu's armhf emulation actually supports. It looks like, according to https://www.qemu.org/docs/master/system/qemu-cpu-models.html , you're running qemu in "Host passthrough" mode. That shouldn't work with chromium unless you modify /usr/bin/chromium to not check for NEON/ASIMD, and even then will probably have issues. I only see x86 and mips documented on that page, but I would suggest running qemu with something like "-cpu cortex-a15".
Bug#810018: Bug #810018: Consider shipping pidof with procps
On Mon, 13 Nov 2023 at 19:14, Mark Hindley wrote: > > Craig, > > Thanks for this. > > On Mon, Nov 13, 2023 at 08:08:37PM +1100, Craig Small wrote: > > I'll need the assistance of the sysvinit-utils maintainers (CC'ed) as > >well, as pidof will be moving from that package. > > IIUC, the proposal[1] was to create a new Essential procps-base just > containing > pidof. Otherwise bin:procps would have to become Essential itself. Its > installed > size is about 20 times larger than sysvinit-util and that wouldn't contribute > to > shrinking the Essential set. > > I think this approach would also require a debian-devel email announcing the > addition to the Essential set and I suppose the new src:procps will need a > trip > through NEW. Good point, I had forgot about that detail, thanks for the reminder
Bug#1012720: ITP: golang-k8s-apimachinery -- Handle Kubernetes-like API objects
On Mon, Nov 13, 2023 at 03:09:57PM +0100, Nicolas Schier wrote: > Hi Domenico, Hi Nicolas, > do you still plan to finish the packaging of golang-k8s-apimachinery > shortly? To be honest I'm far from working at this package. > In order to update glab package to v1.35.0 the package is needed; may we > offer help or would it be ok for you if someone else takes-over your > ITP? Please go ahead and hijack the ITP. Thanks! Domenico > Kind regards, > Nicolas > > > On Sun, Jun 12, 2022 at 09:51:03PM +0200, Domenico Andreoli wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Domenico Andreoli > > > > * Package name: golang-k8s-apimachinery > > Version : 1.25.0~alpha0-1 > > Upstream Author : Kubernetes > > * URL : https://github.com/kubernetes/apimachinery > > * License : Apache-2.0 > > Programming Lang: Go > > Description : Handle Kubernetes-like API objects. > > > > This library is a shared dependency for servers and clients to work with > > Kubernetes API infrastructure without direct type dependencies. Its > > first consumers are k8s.io/kubernetes, k8s.io/client-go, and > > k8s.io/apiserver. -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#967263: aumix: depends on deprecated GTK 2
Am 26.10.23 um 17:31 schrieb Bastian Germann: On Tue, 4 Aug 2020 12:46:59 +0200 Samuel Thibault wrote: I had mailed tre...@jpj.net about it in april, without any answer so far. I guess we'll just disable the gtk build. I have disabled the gtk build in the git repo. I am uploading a NMU to DELAYED/10 in order to fix this. For your convenience I have included all git changes that were made up to this point.
Bug#1055646: gdb: extremely slow response to basic commands
Hello, I've just built gdb "the Debian way", to check what are the differences in the build process: $> apt source gdb $> apt build-dep gdb $> debuild -b -uc -us From debuild output: gdb-default: configured with: ... --without-babeltrace --with-babeltrace ... gdb-minimal: configured with: ... --without-babeltrace --with-babeltrace --without-babeltrace ... This looks bad, but the results are even more "interresting": The gdb binary installed in the system (**debsums OK**) reports the following configuration (the "show configuration" command, differences only): ... --with-babeltrace --with-mpfr --with-xxhash --with-python=/usr (relocatable) --with-python-libdir=/usr/lib (relocatable) --enable-source-highlight ... The newly "debuild" gdb reports something *different*: ... --without-babeltrace << this: conflicting build flags --without-mpfr --with-xxhash --without-python --without-python-libdir --disable-source-highlight ... The gdb which I've compiled using ./configure script (so *without* Debian patches) reports: ... --with-babeltrace --with-mpfr --without-xxhash << this: libxxhash-dev is installed, but flag is disabled ? --with-python=/usr --with-python-libdir=/usr/lib --disable-source-highlight << this ... Regards
Bug#1055897: ITP: speakersafetyd -- speaker protection daemon for embedded Linux systems
Package: wnpp Severity: wishlist Owner: Andreas Henriksson X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: speakersafetyd Version : 0.1.4 Upstream Contact: https://github.com/AsahiLinux/speakersafetyd/issues * URL : https://github.com/AsahiLinux/speakersafetyd/ * License : MIT Programming Lang: Rust Description : speaker protection daemon for embedded Linux systems Speaker protection for Apple Silicon (and potentially other) laptops with built-in speakers. The Apple M1, M2, etc laptops do not have protection for melting speakers in hardware, so need this (unlike many other laptops). The implementation is generic enough that it could in the future support other systems as well (eg. many embedded systems might be in the same situation if they have speakers). I hope to maintain this package in the rust-team (with the help of the bananas-team). Preliminary packaging available at: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/560 See also: https://wiki.debian.org/Teams/Bananas Regards, Andreas Henriksson
Bug#1055773: esptool: CVE-2023-46894
Hi Faidon, On Sun, Nov 12, 2023 at 10:17:01AM +0200, Faidon Liambotis wrote: > On Sat, Nov 11, 2023 at 08:51:30AM +0100, Salvatore Bonaccorso wrote: > > The following vulnerability was published for esptool. > > > > CVE-2023-46894[0]: > > | An issue discovered in esptool 4.6.2 allows attackers to view > > | sensitive information via weak cryptographic algorithm. > > > > If I undestand the upstream discussion[1] correctly this is not > > something hich is going to be fixed until the oldest earliest chips > > are not supported anymore. So this bug is merely for documentation > > purpose and can be closed once this support vanishes (or feel free to > > aswer the above, we might then simply mark it as unimportant in the > > security-tracker. > > I'd go one step further, and express that IMHO this is not a security > vulnerability and that it shouldn't have been assigned a CVE in the > first place. > > As you mentioned, based on upstream's comment above, old revisions of > one of the supported chipsets were using AES ECB for secure boot and > flash encryption, but newer ones have switched to newer cryptographic > algorithms. esptool has kept support for the older algorithms, in order > to keep the ability to work with older revisions of the hardware. > > Obviously software shouldn't default or recommend broken cryptographic > ciphers, when it can be avoided. But I don't think it constitutes a > vulnerability to merely implement them, when they are used to interface > with the world as it exists outside of your software, such as for > compatibility with hardware, network protocols etc. > > This is the equivalent of saying that coreutils is vulnerable because it > ships md5sum, an implementation of a broken digest, or that browsers > need a CVE for supporting older TLS ciphers, etc. Or perhaps even that > python-cryptography itself needs a CVE because it ships an > implementation of AES-ECB (or 3DES or whatever) :) > > Let me know if you disagree! Keeping the bug open until I hear from you. Ok, with your reasoning please feel free to close this tracking bug. Regards, Salvatore
Bug#1032207: libpam-modules: Drop pam_userdb
Hi Sam, On Mon, Nov 13, 2023 at 09:16:33AM -0700, Sam Hartman wrote: > Bastian> Your suggestion splitting out and removing after one > Bastian> release would be fine for me. > > > Helmut, I was hoping for a sanity check. thanks for reaching out. > Bastian wants to split out some code from pam. > He wants to move pam_userdb.so into its own package to remove db5.3 from > the pseudo-essential set. In general terms, I welcome this change. Thanks for working on it. I note that db5.3 also is required for building perl and python, so while it may become possible to remove it from the pseudo-essential set, it will likely remain in the bootstrap set. > I've said that I'd be fine with that if we had libpam-modules depend on > the new package for a release. (It might be okay to do something else, > but that would require surveying users or detecting breakage in ways > that require more thought than I would like to spend). I concur. In essence, we'd first add a new binary and source package to the pseudo-essential set and later aim for reducing the dependency and eventually remove that package (and its functionality) from the pseudo-essential set. > Complications: > > * pam is ppseudo-essential > * usrmerge transition (pam libdir is currently /lib) I confirm. Since we are about to move functionality from one package to another and from /lib to /usr/lib, this triggers a DEP17 P1 scenario. > So ignoring essential and usrmerge, I think the new package would > replace/breaks libpam-modules << the split point. I concur. The canonical mitigation is replacing Breaks with Conflicts (dubbed DEP17 M7). You'll quickly figure that this is going to end badly for pseudo-essential packages, because pam will have to Pre-Depends on the new package. Therefore, we may use DEP17 M8. While I am quite convinced that M8 works, I have not implemented it beyond a PoC stage, so pam would be the first package doing. Let me quote the relevant paragraph: | A package that is at risk of loosing files as in P1 can set up a | protective diversion for each affected location in the aliased form. The | replacing preinst script has to set up these temporary diversions. When | the replacing postinst is run, the replaced package is already upgraded | or removed (due to associated Breaks) and it can therefore remove the | protective diversions. These diversions only exist during an upgrade, | but writing the maintainer scripts can be difficult to get right. | Therefore, M7 should be preferred when applicable. So let's say a new libpam-userdb package installs /usr/lib/x86_64-linux-gnu/security/pam_userdb.so, it's preinst will add a diversion for /lib/x86_64-linux-gnu/security/pam_userdb.so and its postinst will remove this diversion. Likewise for any other file that is taken over and also moved from / to /usr. > Do you have advice on what we want to do given usrmerge and essential? I very much want /usr-merge to not impact your work. It definitely will, but let's try to keep that to a minimum. Please prepare your changes in experimental without paying much attention to /usr-merge and then get back to me. You may also attempt to implement M8. I'll be happy to help and/or review. Helmut
Bug#1055896: cod-tools: FTBFS: source.c:33:5: error: ‘SPGCONST’ undeclared (first use in this function); did you mean ‘OP_CONST’?
Source: cod-tools
Version: 3.7.0+dfsg-1
Severity: serious
Tags: ftbfs sid trixie
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
https://buildd.debian.org/status/fetch.php?pkg=cod-tools=s390x=3.7.0%2Bdfsg-1%2Bb4=1699906136=0
make[2]: Entering directory '/<>/src/lib/perl5/COD/SPGLib'
swig -perl5 -Wall -outdir lib/COD/ source.i
cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-unused-value \
-I. -c \
`perl -MConfig -e 'print join(" ", @Config{qw(ccflags optimize
cccdlflags)}, "-I$Config{archlib}/CORE")'` \
source.c source_wrap.c
source.c: In function ‘get_sym_dataset’:
source.c:33:5: error: ‘SPGCONST’ undeclared (first use in this function); did
you mean ‘OP_CONST’?
33 | SPGCONST double lattice[3][3];
| ^~~~
| OP_CONST
source.c:33:5: note: each undeclared identifier is reported only once for each
function it appears in
source.c:33:13: error: expected ‘;’ before ‘double’
33 | SPGCONST double lattice[3][3];
| ^~~
| ;
source.c:36:13: error: ‘lattice’ undeclared (first use in this function); did
you mean ‘lattice_av’?
36 | lattice[i][j] = SvNV( (SV*)
| ^~~
| lattice_av
source.c:44:13: error: expected ‘;’ before ‘double’
44 | SPGCONST double positions[natoms][3];
| ^~~
| ;
source.c:49:13: error: ‘positions’ undeclared (first use in this function)
49 | positions[i][j] = SvNV( (SV*)
| ^
make[2]: *** [Makelocal-SWIG-module:36: source.o] Error 1
Cheers
--
Sebastian Ramacher
Bug#1042866: planner: Frequent segmentation faults
fix have been merged : https://gitlab.gnome.org/World/planner/-/commit/cfca49c41c3368700f519b7e4c388037eaa6f048 Should be available at next release. Let me know if there's still an issue after update.
Bug#1055895: rust-self-cell: RUSTSEC-2023-0070
Source: rust-self-cell Version: 1.0.1-1 Tags: security upstream Justification: user security hole Forwarded: https://github.com/Voultapher/self_cell/issues/49 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi Please see https://rustsec.org/advisories/RUSTSEC-2023-0070.html Regards, Salvatore
Bug#1055765: chromium: Error: Can't open display (armhf) while other platforms (amd64, arm64, i386) are OK
I’ve been able to reproduce the issue (e.g., Can’t open display) with versions 117.0.5938.149-1~deb12u1 and 118.0.5993.70-1~deb12u1. uname -a: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP Fri Oct 6 13:20:44 UTC 2023 armv7l GNU/Linux cat /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 106 model name : Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz stepping: 6 microcode : 0x cpu MHz : 2793.437 cache size : 49152 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 21 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap clflushopt avx512cd avx512bw avx512vl xsaveopt xsavec xsaves md_clear bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit mmio_stale_data gds bogomips: 5586.87 clflush size: 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 106 model name : Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz stepping: 6 microcode : 0x cpu MHz : 2793.437 cache size : 49152 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 21 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgs bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit mmio_stale_data gds bogomips: 5586.87 clflush size: 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: > Le 12 nov. 2023 à 09:10, Andres Salomon a écrit : > > Probably the easiest way is to manually download the chromium and > chromium-common deb packages, and then 'sudo apt install > /path/to/chromium_117.x.y.z-1~deb12u1_armhf.deb > /path/to/chromium-common_117.x.y.z-1~deb12u1_armhf.deb'. > > If you go to > https://snapshot.debian.org/package/chromium/117.0.5938.149-1~deb12u1/ in > your browser, scroll down to the "chromium 117.0.5938.149-1~deb12u1" section, > and then click on the link for "chromium_117.0.5938.149-1~deb12u1_armhf.deb" > (or right click and click 'save link as', or copy the link and supply it to > wget/curl in the qemu environment), it should download it. Do the same thing > in the "chromium-common 117.0.5938.149-1~deb12u1" section. > > https://snapshot.debian.org/package/chromium/118.0.5993.70-1~deb12u1/ has > more armhf deb packages, if the 117 packages aren't broken in your test. > Unfortunately it looks like 118.0.5993.117-1 never successfully built for > armhf on debian 12.. > > > > On Sun, Nov 12 2023 at 08:20:36 AM +01:00:00, Julien Neuhart > wrote: >> Could you guide me on how ton install those versions? As far as I know, they >> are not available in bookworm directly. Thanks! >>> Le 11 nov. 2023 à 21:51, Andres Salomon a écrit : >>> Okay, so not distribution-specific. Between 116 and 119 there were a >>> considerable number of changes in the debian packaging, including switching >>> from clang-14 to clang-16 for build (done in 118.0.5993.117-1~deb12u1) and >>> enabling NEON for armhf (done in 117.0.5938.132-1~deb12u1). My immediate >>> suspicion is the NEON change, so it would helpful if you could try those >>> versions as well and report back. Also, if it turns out to be the NEON >>> change, having the output of `uname -a` and `cat /proc/cpuinfo` (inside of >>> qemu's armhf emulation) would be helpful. >>> On Sat, Nov 11 2023 at 12:08:42 PM +01:00:00, Julien Neuhart >>> wrote: Hello Andres, Thanks for the quick follow up. So I’ve tested with Chromium 116.0.5845.180-1~deb12u1 and it works as expected on Debian 12. Note that I also had to explicitly install the chromium-common package: DEBIAN_FRONTEND=noninteractive apt-get install -y -qq --no-install-recommends chromium-common="116.0.5845.180-1~deb12u1" chromium="116.0.5845.180-1~deb12u1" Distributor ID:Debian
Bug#1055838: gnome: GNOME Text Editor not chosen or listed for text files
On Sun, 12 Nov 2023 at 15:23:10 +, Simon McVittie wrote: > On Sun, 12 Nov 2023 at 14:12:25 +0100, Paul Menzel wrote: > > With Debian sid/unstable and *gnome* 1:44+1, text files, for example with > > the suffix .txt, are opened with LibreOffice Writer and not GNOME Text > > Editor (*gnome-text-editor* 45.0-1). > > This seems to be because /usr/share/applications/gnome-mimeapps.list in > gnome-session-common lists gedit but not gnome-text-editor. A fix is on its way into unstable, and I've proposed a stable-update for Debian 12.3. > > It’s not even listed in the application choices. > > I'm surprised by that, because > /usr/share/applications/org.gnome.TextEditor.desktop does list text/plain > as a supported file type I think I might have misunderstood what you meant by "the application choices". To clarify, Nautilus does not dynamically add a menu item per text editor with labels like "Open With Text Editor", "Open With gedit", "Open With emacs", "Open With gVim" and so on - that is not intended behaviour. It is only intended to have two "Open With" menu entries: the first is for the default application (the same one you would get for a double-click), and the second opens a window where you can choose a non-default application. The behaviour I see is: * Right-click on a plain text file in nautilus (GNOME Files) * The top option is "Open With (some default app) [Return]". The bug you reported is that for you, the app is LibreOffice Writer (and I can reproduce this on a default task-gnome-desktop installation). With the bug fixed, it should be Text Editor (which is the gnome-text-editor package), or possibly gedit. * The second option is "Open With..." with no keyboard shortcut. * If you choose to "Open With...", even before this bug is fixed, you should see "Text Editor" listed under the "Recommended Applications" heading. * After this bug is fixed, "Text Editor" should move up to "Default Application", replacing LibreOffice Writer, which moves down to "Recommended Applications". Is that the same thing you see? If not, please describe what you see in similar detail, and how it differs from what you expect. Thanks, smcv
Bug#810018: Bug #810018: Consider shipping pidof with procps
Craig, Thanks for this. On Mon, Nov 13, 2023 at 08:08:37PM +1100, Craig Small wrote: > I'll need the assistance of the sysvinit-utils maintainers (CC'ed) as >well, as pidof will be moving from that package. IIUC, the proposal[1] was to create a new Essential procps-base just containing pidof. Otherwise bin:procps would have to become Essential itself. Its installed size is about 20 times larger than sysvinit-util and that wouldn't contribute to shrinking the Essential set. I think this approach would also require a debian-devel email announcing the addition to the Essential set and I suppose the new src:procps will need a trip through NEW. >So I'm looking at https://wiki.debian.org/PackageTransition >and assuming procps is 2:4.0.4-2 and sysvinit-utils is 3.08-3 >I would create procps 2:4.0.4-3 with pidof and Breaks: sysvinit-utils >(<< 3.0.8-4) and Replaces: sysvinit-utils (<< 3.0.8-4) >sysvinit-utils maintainers create 3.08-4 without pidof and have Breaks: >procps (<< 2:4.0.4-3) The dependencies would then be:- procps-base: Breaks: sysvinit-utils (<< 3.0.8-4) Replaces: sysvinit-utils (<< 3.0.8-4) sysvinit-utils without pidof: Breaks: procps-base (<< 2:4.0.4-3) I hope I have understood the previous discussions correctly . I am not trying to stand in the way at all, just ensure that this transition is worthwhile and done correctly. With best wishes Mark [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810018#10
Bug#1055894: bookworm-pu: package gnome-session/43.0-1+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: gnome-sess...@packages.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 + src:gnome-session Please consider including my recent gnome-session upload in Debian 12.3. [ Reason ] Open text files in gnome-text-editor if gedit is not installed, fixing https://bugs.debian.org/1055838 [ Impact ] If not fixed, in a default task-gnome-desktop installation, plain text files (including XML, CSS, various programming languages, etc.) default to being opened in Libreoffice Writer (a word processor), and not in GNOME Text Editor (a text editor) as intended. Mitigation: if the system was upgraded from Debian 11, it will probably still have the gedit package installed. If so, plain text files will open in gedit by default, which is an entirely reasonable choice too. For context, GNOME Text Editor is a simple text editor like Windows Notepad, whereas gedit is more of a programmers' editor; which one gets to open text files by default if both are installed is a matter of opinion and taste, but the default on a GNOME desktop ought to be one of those two, and certainly not a word processor. [ Tests ] Manually tested: * Start from a Debian 12 VM with task-gnome-desktop and no other desktop environments * Ensure gedit is *not* installed (by default, it will not be) * echo "Hello, world!" > ~/Documents/hello.txt * nautilus ~/Documents * Right-click hello.txt * Good result: the top choice is "Open With Text Editor [Return]" * Bad result: the top choice is "Open With LibreOffice Writer [Return]" * After verifying good result with the proposed gnome-session installed, additionally install gedit * Right-click hello.txt * Good result: the top choice is "Open With gedit [Return]" * Bad result: anything else [ Risks ] Low risk: no code change, just adjusting desktop-specific defaults for GNOME (including derivatives like Budgie and GNOME Flashback). To minimize observable behaviour changes for systems that were already upgraded from Debian 11 to 12, I have chosen to make gedit the default text editor for GNOME if happens to be installed (no change for upgraded systems), falling back to GNOME Text Editor if gedit is not present (a fresh task-gnome-desktop installation will use this fallback in practice). This is the opposite of my recent upload to unstable, where I made gnome-text-editor higher priority (I think it's reasonable to expect the default text editor to change in a major-version upgrade). [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] d/gnome-mimeapps.list: Fix the bug. It might be helpful to know that values after the equals sign in mimeapps.list are semicolon-delimited lists, and canonically end with a single semicolon after the last item (but it's optional and frequently omitted, particularly for single-item lists). d/gbp.conf: administrivia since this is the first Debian 12 update proposed for this package. diffstat for gnome-session-43.0 gnome-session-43.0 changelog | 21 + gbp.conf|4 +-- gnome-mimeapps.list | 62 ++-- 3 files changed, 54 insertions(+), 33 deletions(-) diff -Nru gnome-session-43.0/debian/changelog gnome-session-43.0/debian/changelog --- gnome-session-43.0/debian/changelog 2022-10-11 19:08:35.0 +0100 +++ gnome-session-43.0/debian/changelog 2023-11-13 18:34:53.0 + @@ -1,3 +1,24 @@ +gnome-session (43.0-1+deb12u1) bookworm; urgency=medium + + * Team upload + * d/gbp.conf: Configure branches for Debian 12 stable updates + * Open text files in gnome-text-editor if gedit is not installed. +The preinstalled text editor for Debian GNOME systems was changed +from gedit in Debian 11 to gnome-text-editor in Debian 12, but this +file was not updated to match, resulting in various plain-text formats +being opened in Libreoffice Writer rather than gnome-text-editor in a +default task-gnome-desktop installation with no further configuration. +To preserve current behaviour for systems that have gedit installed +(perhaps as a result of them having been upgraded from Debian 11 to +12), for all file types that were previously handled with gedit, +continue to use gedit by default if it happens to be installed, +but fall back to gnome-text-editor if gedit is not present. +The preference order is likely to change to gnome-text-editor as +default, with gedit as a fallback, in Debian 13. +(Closes: #1055838) + + -- Simon McVittie Mon, 13 Nov 2023 18:34:53 + + gnome-session (43.0-1) unstable; urgency=medium [ Nathan Pratta Teodosio ] diff -Nru gnome-session-43.0/debian/gbp.conf
Bug#1055893: libsvtav1enc1d1: Cannot overwrite libSvtAv1Enc.so.1, which is also in package libsvtav1enc1:amd64 2:1.5.0-dmo1
Package: libsvtav1enc1d1 Version: 1.7.0+dfsg-2_amd64 Severity: normal X-Debbugs-Cc: swoarr...@gmail.com Dear Maintainer, * What led up to the situation? Regular updating of software using aptitude or Discover. * What exactly did you do (or not do) that was effective (or ineffective)? Updated software * What was the outcome of this action? Several packages held up. * What outcome did you expect instead? -- System Information: Debian Release: trixie/sid APT prefers oldoldstable-updates APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1055892: sunpy: FTBFS in bookworm: leap-second file is expired.
Package: src:sunpy Version: 4.1.2-1 Severity: serious Tags: ftbfs bookworm upstream Dear maintainer: During a rebuild of all packages in bookworm, this package failed to build. The error I got is the same in reproducible-builds: https://tests.reproducible-builds.org/debian/rbuild/bookworm/amd64/sunpy_4.1.2-1.rbuild.log.gz This failure is almost the same as Bug #1055877 in ndcube, so everything I said there applies here as well (we want packages to build always during the lifetime of stable, etc). Sorry, I don't have a patch in this case. Since there are now (at least) two affected packages, maybe it would be worth to think of a common solution for both packages which does not involve skipping each and every test having the time bomb. Thanks.
Bug#1055891: transition: gdal
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: g...@packages.debian.org Control: affects -1 + src:gdal Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Control: block -1 by 1051433 For the Debian GIS team I'd like to transition to GDAL 3.8.0. All reverse dependencies except mysql-workbench rebuilt successfully with GDAL 3.8.0 from experimental as summarized below. mysql-workbench (8.0.32+dfsg-1) FTBFS due to unrelated issues. (#1051433) Transition: gdal libgdal33 (3.7.3+dfsg-1) -> libgdal34 (3.8.0~rc2+dfsg-1~exp1) The status of the most recent rebuilds is as follows. cloudcompare(2.11.3-7.1) OK fiona (1.9.5-1) OK gmt (6.4.0+dfsg-2)OK grass (8.3.1-1) OK libcitygml (2.5.1-1) OK libgeo-gdal-ffi-perl(0.1-3) OK libosmium (2.20.0-1)OK mapcache(1.14.0-2)OK mapnik (3.1.0+ds-4) OK mapproxy(1.16.0+dfsg-1) OK mapserver (8.0.1-2) OK merkaartor (0.19.0+ds-4) OK mysql-workbench (8.0.32+dfsg-1) FTBFS (#1051433) ncl (6.6.2.dfsg.1-2) OK octave-mapping (1.4.2-3) OK openorienteering-mapper (0.9.5-3.1) OK openscenegraph (3.6.5+dfsg1-8) OK paraview(5.11.0+dfsg-2) OK pgsql-ogr-fdw (1.1.4-3) OK pktools (2.6.7.6+ds-4)OK postgis (3.4.0+dfsg-3)OK python-django (3:4.2.6-1) OK qmapshack (1.17.0-1)OK r-cran-rgdal(1.6-7+dfsg-1)OK r-cran-sf (1.0-14+dfsg-1) OK r-cran-terra(1.7-55-1)OK rasterio(1.3.9-2) OK saga(9.2.0+dfsg-1)OK vtk9(9.1.0+really9.1.0+dfsg2-7) OK facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) BD-UNINST libgdal-grass (1:1.0.2-6) OK opencv (4.6.0+dfsg-13) OK osmcoastline(2.4.0-2) OK qgis(3.28.12+dfsg-1) OK sumo(1.18.0+dfsg-3) OK Kind Regards, Bas
Bug#1025956: u-boot-menu: Allow automatic sync of DTBs when /boot is a separate partition
Hi Vagrant, Le 18/05/2023 à 17:42, Vagrant Cascadian a écrit : Unfortunately, this will have to wait till after bookworm release, currently scheduled for June. Gentle ping with the hope that you (or Jonas) have some bandwidth to take a look at this patch ;) Cheers, Arnaud
Bug#1055567: Error: gscan2pdf fails to compile
On 13/11/2023 16:24, Soumyanath Chatterjee wrote: DB<1> use Image::Sane ':all'; Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Image/Sane/Sane.so' for module Image::Sane: /usr/lib/x86_64-linux-gnu/libsane.so.1: undefined symbol: l ibusb_set_option at /usr/share/perl/5.30/XSLoader.pm line 93. at /usr/lib/x86_64-linux-gnu/perl5/5.30/Image/Sane.pm line 144. If that failed, my first question is why you didn't see the same failure from the same line in /usr/share/perl5/Gscan2pdf/Scanner/Options.pm ? What do you see in line 8 of that file? What do you get from ldd /usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Image/Sane/Sane.so ls -l /usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Image/Sane/Sane.so ls -l /usr/lib/x86_64-linux-gnu/libsane.so.1 ? OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055890: cloud-init fails to work when deployed with MAAS due to old python2 based cloud-init.postinst
Package: cloud-init Version: 22.4.2-1 Severity: important Tags: upstream Dear Maintainer, Debian cloud-init is still bundling old python2 based cloud-init.postinst. This fails MAAS based debian deployments as the cloud-init.postinst script fails to run Replacing bundled filed with https://github.com/canonical/cloud-init/raw/ubuntu/devel/debian/cloud-init.postinst fixes the issue. Please update to the latest cloud-init.postinst file. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 6.1.50-current-rockchip64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages cloud-init depends on: ii eject 2.38.1-5+b1 ii fdisk 2.38.1-5+b1 ii gdisk 1.0.9-2.1 ii isc-dhcp-client4.4.3-P1-2 ii locales2.36-9+deb12u1 ii lsb-base 11.6 ii lsb-release12.0-1 ii procps 2:4.0.2-3 ii python33.11.2-1+b1 ii python3-configobj 5.0.8-1 ii python3-jinja2 3.1.2-1 ii python3-jsonpatch 1.32-2 ii python3-jsonschema 4.10.3-1 ii python3-netifaces 0.11.0-2+b1 ii python3-oauthlib 3.2.2-1 ii python3-requests 2.28.1+dfsg-1 ii python3-serial 3.5-1.1 ii python3-yaml 6.0-3+b2 ii sysvinit-utils [lsb-base] 3.06-4 ii util-linux 2.38.1-5+b1 Versions of packages cloud-init recommends: pn cloud-guest-utils pn eatmydata ii sudo 1.9.13p3-1+deb12u1 Versions of packages cloud-init suggests: ii btrfs-progs 6.2-1 ii e2fsprogs1.47.0-2 pn xfsprogs -- debconf information: * cloud-init/datasources: MAAS
Bug#808940: ITP: terraform -- tool for managing cloud infrastructure
On Thu, 26 Oct 2023 13:03:24 +0200 Laurent Bigonville wrote: > retitle 808940 ITP: opentofu -- tool for managing cloud infrastructure > thanks > > On Thu, 24 Dec 2015 14:08:40 +0100 Daniel Stender > wrote: > > Hello, > > > * Package name : terraform > > Version : 0.6.8 > > Upstream Author : Mitchell Hashimoto > > * URL : https://terraform.io/ > > * License : MPL-2.0 > > Programming Lang: Go > > Description : tool for managing cloud infrastructure > > > > Terraform is a tool for launching complex infrastructure like from > cloud providers > > like AWS or DigitlOcean. Like the other tools from HashiCorp > (Vagrant, Packer etc.) > > a simple CLI based program which is very easy to use, employing > configuration files > > for the needed setups. For more info, please see the documentation > and quick intro > > on the site. > > > > Now that hashicorp has changed the licence of their software BSL, I > guess that this RFP should be changed to package opentofu instead? > > https://opentofu.org/ Hello, I am one of the core maintainers of OpenTofu, happy to lend any assistance in packaging. I will note that we are currently only at the alpha stage and are hard at work progressing to a stable release. Christian Mesh
Bug#1032207: libpam-modules: Drop pam_userdb
Bastian> Your suggestion splitting out and removing after one Bastian> release would be fine for me. Helmut, I was hoping for a sanity check. Bastian wants to split out some code from pam. He wants to move pam_userdb.so into its own package to remove db5.3 from the pseudo-essential set. I've said that I'd be fine with that if we had libpam-modules depend on the new package for a release. (It might be okay to do something else, but that would require surveying users or detecting breakage in ways that require more thought than I would like to spend). Complications: * pam is ppseudo-essential * usrmerge transition (pam libdir is currently /lib) So ignoring essential and usrmerge, I think the new package would replace/breaks libpam-modules << the split point. Do you have advice on what we want to do given usrmerge and essential? --Sam
Bug#1055889: RFS: urlview/1b-1 [ITA] -- Extracts URLs from text
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "urlview": * Package name : urlview Version : 1b-1 Upstream contact : https://lists.sr.ht/~nabijaczleweli/urlview-ng * URL : https://sr.ht/~nabijaczleweli/urlview-ng * License : 0BSD, GPL-2+ * Vcs : https://git.sr.ht/~nabijaczleweli/urlview.deb Section : misc The source builds the following binary packages: urlview - Extracts URLs from text To access further information about this package, please visit the following URL: https://mentors.debian.net/package/urlview/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/u/urlview/urlview_1b-1.dsc Changes since the last upload: urlview (1b-1) unstable; urgency=medium . * New maintainer (Closes: #1051204) * d/watch, d/upstream/signing-key.asc: new for urlview-ng upstream * New upstream version 1b (+ changelog & NEWS) (Closes: #127090, #161620, #631481, #690405, #983417, #985259, #988055) * d/system.urlview, d/url_handler.sh, d/patches: remove, merged upstream * d/postrm, d/dhelp, d/README.Debian: remove * d/tests: rewrite * d/rules, d/copyright: new for urlview-ng * d/upstream/metadata: add for urlview-ng Regards, -- наб signature.asc Description: PGP signature
Bug#1055888: efibootmgr: d/control missing upstream source link via Homepage field
Source: efibootmgr Version: 18-1 Severity: normal Tags: patch Dear Maintainer, d/control is missing the Homepage: field, which is supposed to link to the canonical upstream (and it's thus missing from packages.d.o ), which in the case of this package is https://github.com/rhboot/efibootmgr, per README. Patch attached. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled From 47cdd9c41fb276e1307a219f622e25a8af3d160f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= Date: Mon, 13 Nov 2023 17:17:10 +0100 Subject: [PATCH] d/control: add Homepage: field pointing at upstream GitHub X-Mutt-PGP: OS --- debian/control | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/control b/debian/control index 9c91497..b40adb9 100644 --- a/debian/control +++ b/debian/control @@ -5,6 +5,7 @@ Maintainer: Debian UEFI Maintainers Uploaders: Steve McIntyre <93...@debian.org>, Mario Limonciello Build-Depends: debhelper-compat (= 13), pkg-config, libefivar-dev (>= 30), libefiboot-dev (>= 30), libpopt-dev Standards-Version: 4.5.1 +Homepage: https://github.com/rhboot/efibootmgr Vcs-Git: https://salsa.debian.org/efi-team/efibootmgr.git Vcs-Browser: https://salsa.debian.org/efi-team/efibootmgr -- 2.39.2 signature.asc Description: PGP signature
Bug#1055750: gfortran: [armhf] Yield SIGBUS when compiling with -fstack-clash-protection
The attached file bug-1055750.tgz contains a minimal code that triggers the bug on an armhf system : $ ./run * Compile without -fstack-clash-protection & run /usr/bin/ld: warning: /tmp/cc9l2GJa.o: requires executable stack (because the .note.GNU-stack section is executable) * Compile with -fstack-clash-protection & run /usr/bin/ld: warning: /tmp/ccP0miz5.o: requires executable stack (because the .note.GNU-stack section is executable) Program received signal SIGBUS: Access to an undefined portion of a memory object. Backtrace for this error: Bus error * Rafael Laboissière [2023-11-10 15:52]: Package: gfortran Version: 13.2.0-1 Severity: normal Dear Maintainer, The motivation for the present bug report comes from Bug#1055228. Since version 1.22.1 of dpkg-dev was released (on October 30), the plplot package FTBFS due to a failing compilation of one of Fortran examples, which is exercised as a unit test during package building. The package built fine previously. The problem is triggered by the change in dpkg-buildflags, which now includes -fstack-clash-protection in FFLAGS. I am attaching to this bug message a shell script that can reliably trigger the bug on an armhf system. Here is the output: $ ./gfortran-stack-clash-protection-armhf-bug.sh […] Program received signal SIGBUS: Access to an undefined portion of a memory object. Backtrace for this error: Bus error Note that the bug does not happen on amd64. Also, it does not happen on armhf when the option -fstack-clash-protection is not used in the invocation of gfortran. As far as I can tell, the problem is due to a global variable (tr) that is not correctly accessed in a private function (mypltr) of the x09f program. Here is what gdb tells me: $ gdb x09f […] (gdb) run -dev ps -o /dev/null Starting program: /home/rafael/fortran/x09f -dev ps -o /dev/null [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". Program received signal SIGBUS, Bus error. 0x00400dfe in x09f::mypltr (x=0, y=1, xt=1, yt=34) at x09f.f90:193 193 xt = tr(1) * x + tr(2) * y + tr(3) My knowledge of Fortran and gfortran is way too scarce and, therefore, I cannot debug the problem deeper. There may be a programming error in x09f.f90 or this may be a problem with gfortran on armhf when option -fstack-clash-protection is given. Any help will be appreciated. Best, Rafael Laboissière bug-1055750.tgz Description: application/gtar-compressed
Bug#1055887: efibootmgr: d/watch broken (upstream repo moved)
Source: efibootmgr Version: 18-1 Severity: normal Tags: patch Dear Maintainer, I didn't see an upstream source link on packages.d.o, so I went to https://tracker.debian.org/pkg/efibootmgr which says: [high] Problems while searching for a new upstream version uscan had problems while searching for a new upstream version: In debian/watch no matching files for watch line https://github.com/rhinstaller/efibootmgr/releases .*[^n]/(?:|v|version-|r|REL_|rel-|efibootmgr(?:_|-))(\d[^\s/]*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz) Created: 2022-09-23 Last update: 2023-11-13 12:42 Navigating there in a browser shows a 3xx redirect to https://github.com/rhboot/efibootmgr/releases, but, naturally, uscan doesn't follow those. This would be a trivial fix but in GitHub's continued war against its users, "https://github.com/rhboot/efibootmgr/releases; doesn't actually list any of the assets! (I didn't believe it either, curl it and see), of which "efibootmgr-18.tar.bz2" would be the one we want. Thankfully, uscan(1)'s recommended GitHub spelling with looking at /tags and pulling out the autogenerated tarballs works (I don't really see a significant value-add to using upstream's re-packed and re-uploaded .tar.bz2s, they're not even signed): $ uscan -v --no-download uscan info: uscan (version 2.23.4) See uscan(1) for help uscan info: Scan watch files in . uscan info: Check debian/watch and debian/changelog in . uscan info: package="efibootmgr" version="18-1" (as seen in debian/changelog) uscan info: package="efibootmgr" version="18" (no epoch/revision) uscan info: ./debian/changelog sets package="efibootmgr" version="18" uscan info: Process watch file at: debian/watch package = efibootmgr version = 18 pkg_dir = . uscan info: opts: filenamemangle=s%(?:.*?)?v?(?:[-_]?v?(\d[\-+\.:\~\da-zA-Z]*))((?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz)))%efibootmgr-$1$2% uscan info: line: https://github.com/rhboot/efibootmgr/tags (?:.*?/)?v?(?:[-_]?v?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz)) uscan info: Parsing filenamemangle=s%(?:.*?)?v?(?:[-_]?v?(\d[\-+\.:\~\da-zA-Z]*))((?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz)))%efibootmgr-$1$2% uscan info: line: https://github.com/rhboot/efibootmgr/tags (?:.*?/)?v?(?:[-_]?v?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz)) uscan info: Last orig.tar.* tarball version (from debian/changelog): 18 uscan info: Last orig.tar.* tarball version (dversionmangled): 18 uscan info: Requesting URL: https://github.com/rhboot/efibootmgr/tags uscan info: Matching pattern: (?:(?:https://github.com)?\/rhboot\/efibootmgr\/)?(?:.*?/)?v?(?:[-_]?v?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz)) uscan info: Found the following matching hrefs on the web page (newest first): https://github.com/rhboot/efibootmgr/archive/refs/tags/18.tar.gz (18) index=18-1 https://github.com/rhboot/efibootmgr/archive/refs/tags/18.tar.gz (18) index=18-1 https://github.com/rhboot/efibootmgr/archive/refs/tags/18.zip (18) index=18-0 https://github.com/rhboot/efibootmgr/archive/refs/tags/18.zip (18) index=18-0 https://github.com/rhboot/efibootmgr/archive/refs/tags/17.tar.gz (17) index=17-1 https://github.com/rhboot/efibootmgr/archive/refs/tags/17.tar.gz (17) index=17-1 https://github.com/rhboot/efibootmgr/archive/refs/tags/17.zip (17) index=17-0 https://github.com/rhboot/efibootmgr/archive/refs/tags/17.zip (17) index=17-0 https://github.com/rhboot/efibootmgr/archive/refs/tags/16.tar.gz (16) index=16-1 https://github.com/rhboot/efibootmgr/archive/refs/tags/16.tar.gz (16) index=16-1 https://github.com/rhboot/efibootmgr/archive/refs/tags/16.zip (16) index=16-0 https://github.com/rhboot/efibootmgr/archive/refs/tags/16.zip (16) index=16-0 https://github.com/rhboot/efibootmgr/archive/refs/tags/15.tar.gz (15) index=15-1 https://github.com/rhboot/efibootmgr/archive/refs/tags/15.tar.gz (15) index=15-1 https://github.com/rhboot/efibootmgr/archive/refs/tags/15.zip (15) index=15-0 https://github.com/rhboot/efibootmgr/archive/refs/tags/15.zip (15) index=15-0 https://github.com/rhboot/efibootmgr/archive/refs/tags/14.tar.gz (14) index=14-1 https://github.com/rhboot/efibootmgr/archive/refs/tags/14.tar.gz (14) index=14-1 https://github.com/rhboot/efibootmgr/archive/refs/tags/14.zip (14) index=14-0 https://github.com/rhboot/efibootmgr/archive/refs/tags/14.zip (14) index=14-0 https://github.com/rhboot/efibootmgr/archive/refs/tags/13.tar.gz (13) index=13-1 https://github.com/rhboot/efibootmgr/archive/refs/tags/13.tar.gz (13) index=13-1 https://github.com/rhboot/efibootmgr/archive/refs/tags/13.zip (13) index=13-0
Bug#1055886: RFS: ruby-mdl/0.13.0-3 -- Markdown lint tool - transitional dummy package
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ruby-mdl": * Package name : ruby-mdl Version : 0.13.0-3 Upstream contact : ["p...@ipom.com"] * URL : https://github.com/markdownlint/markdownlint * License : MIT * Vcs : https://salsa.debian.org/nbehrnd/ruby-mdl Section : text The source builds the following binary packages: markdownlint - Markdown lint tool ruby-mdl - Markdown lint tool - transitional dummy package To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ruby-mdl/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/ruby-mdl/ruby-mdl_0.13.0-3.dsc Changes since the last upload: ruby-mdl (0.13.0-3) unstable; urgency=medium . * address manpage problem - capitalize TH entry in manpage - provide manpages for ruby-mdl and mdl - add suggest to update mandb after removal of ruby-mdl Regards,
Bug#1039142: busybox: ships sysv-init script without systemd unit
Control: tag -1 + help On Sun, 25 Jun 2023 23:20:24 +0100 bl...@debian.org wrote: Package: busybox Severity: important User: bl...@debian.org Usertags: missing-systemd-service Dear Maintainer(s), busybox has been flagged by Lintian as shipping a sysv-init script without a corresponding systemd unit file. The default init system in Debian is systemd, and so far this worked because a transitional sysv-init-to-unit generator was shipped by systemd. This is in the process of being deprecated and will be removed by the time Trixie ships, so the remaining packages that ship init scripts without systemd units will stop working. There are various advantages to using native units, for example the legacy generator cannot tell the different between a oneshot service and a long running daemon. Also, sanboxing and security features become available for services. For more information, consult the systemd documentation: https://www.freedesktop.org/software/systemd/man/systemd.unit.html You can find the Lintian warning here: https://lintian.debian.org/sources/busybox This site can't be found. But it's ok. So in current state, only udhcpd lacks systemd file. So I tried to provide one. The initscript for udhcpd checks for UDHCPD_ENABLED=yes/no in /etc/default/udhcpd and does nothing if it is not enabled, which is the default. Since there's no way in systemd to check for that (well, there is, with ExecConditional, but it ugly at best), I thought to ship udhcpd.service not enabled by default. Except it doesn't work. With just dh_installsystemd --no-enable, it is still started. With dh_installsystemd --no-enable --no-start, it is started as well, - apparently because initscript is started. Also, with --no-enable --no-start, it is not restarted on upgrades if enabled locally. After doing several iterations, I decided to abandon this attempt, - it just does not work, and I've no time to fight with the tools. If someone has a working recipe for all this madness, please share a patch for d/rules. Tagging with "help" for now. Thanks, /mjt
Bug#1055567: Error: gscan2pdf fails to compile
Please find the output:
Editor support available.
Enter h or 'h h' for help, or 'man perldebug' for more help.
main::(-e:1): l
DB<1> use Image::Sane ':all';
Can't load
'/usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Image/Sane/Sane.so' for
module Image::Sane: /usr/lib/x86_64-linux-gnu/libsane.so.1: undefined
symbol: l
ibusb_set_option at /usr/share/perl/5.30/XSLoader.pm line 93.
at /usr/lib/x86_64-linux-gnu/perl5/5.30/Image/Sane.pm line 144.
Compilation failed in require at (eval
10)[/usr/share/perl/5.30/perl5db.pl:738] line 2.
at (eval 10)[/usr/share/perl/5.30/perl5db.pl:738] line 2.
main::BEGIN() called at (eval
10)[/usr/share/perl/5.30/perl5db.pl:738] line 2
eval {...} called at (eval
10)[/usr/share/perl/5.30/perl5db.pl:738] line 2
eval 'no strict; ($@, $!, $^E, $,, $/, $\\, $^W) =
@DB::saved;package main; $^D = $^D | $DB::db_stop;
use Image::Sane \':all\';;
' called at /usr/share/perl/5.30/perl5db.pl line 738
DB::eval called at /usr/share/perl/5.30/perl5db.pl line 3138
DB::DB called at -e line 1
BEGIN failed--compilation aborted at (eval
10)[/usr/share/perl/5.30/perl5db.pl:738] line 2.
at (eval 10)[/usr/share/perl/5.30/perl5db.pl:738] line 2.
eval 'no strict; ($@, $!, $^E, $,, $/, $\\, $^W) =
@DB::saved;package main; $^D = $^D | $DB::db_stop;
use Image::Sane \':all\';;
' called at /usr/share/perl/5.30/perl5db.pl line 738
DB::eval called at /usr/share/perl/5.30/perl5db.pl line 3138
DB::DB called at -e line 1
DB<2> print SANE_NAME_PAGE_HEIGHT, "\n";
No comma allowed after filehandle at (eval
15)[/usr/share/perl/5.30/perl5db.pl:738] line 2.
at (eval 15)[/usr/share/perl/5.30/perl5db.pl:738] line 2.
eval 'no strict; ($@, $!, $^E, $,, $/, $\\, $^W) =
@DB::saved;package main; $^D = $^D | $DB::db_stop;
print SANE_NAME_PAGE_HEIGHT, "\\n";;
' called at /usr/share/perl/5.30/perl5db.pl line 738
DB::eval called at /usr/share/perl/5.30/perl5db.pl line 3138
DB::DB called at -e line 1
DB<3>
On 12/11/23 22:52, Jeff wrote:
Please start an interactive Perl session with:
perl -d -e 1
Then execute the following:
use Image::Sane ':all';
print SANE_NAME_PAGE_HEIGHT, "\n";
and report the response.
Afterwards, you can quit with q
Bug#1055885: workflow: Package name too generic, please pick something more specific
Source: workflow Severity: normal X-Debbugs-Cc: cru...@debian.org,debian-scie...@lists.debian.org,debian-...@lists.debian.org Hello, "workflow" is a very generic name for a Debian package. In scientific computing there are over 340 workflow systems[0]. Perhaps this source package would better be named "sogou-workflow" and the binary packages likewise renamed "libsogou-workflow-dev", etc.. Thanks, [0] https://s.apache.org/existing-workflow-systems -- Michael R. Crusoe OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055884: ghc: Please update sparc-support patch to fix FTBFS on sparc64
Source: ghc Version: 9.4.7-1 Severity: normal Tags: patch User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hi! src:ghc currently FTBFS on sparc64 since libraries/ghc-boot/GHC/Platform/ArchOS.hs is missing the architecture names for sparc and sparc64 [1]. I have therefore updated the sparc-support patch to address this and also opened a pull request upstream [2]. Can you update the patch for the next upload? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=ghc=sparc64=9.4.7-1=1699776000=0 > [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11599 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Index: ghc-9.4.7/m4/ghc_convert_cpu.m4 === --- ghc-9.4.7.orig/m4/ghc_convert_cpu.m4 +++ ghc-9.4.7/m4/ghc_convert_cpu.m4 @@ -68,6 +68,12 @@ case "$1" in sh4) $2="sh4" ;; + sparc64*) +$2="sparc64" +;; + sparc*) +$2="sparc" +;; vax) $2="vax" ;; Index: ghc-9.4.7/m4/fptools_set_haskell_platform_vars.m4 === --- ghc-9.4.7.orig/m4/fptools_set_haskell_platform_vars.m4 +++ ghc-9.4.7/m4/fptools_set_haskell_platform_vars.m4 @@ -42,7 +42,7 @@ AC_DEFUN([FPTOOLS_SET_HASKELL_PLATFORM_V riscv64) test -z "[$]2" || eval "[$]2=ArchRISCV64" ;; -hppa|hppa1_1|ia64|m68k|nios2|riscv32|rs6000|s390|sh4|vax) +hppa|hppa1_1|ia64|m68k|nios2|riscv32|rs6000|s390|sh4|sparc|sparc64|vax) test -z "[$]2" || eval "[$]2=ArchUnknown" ;; *) Index: ghc-9.4.7/libraries/ghc-boot/GHC/Platform/ArchOS.hs === --- ghc-9.4.7.orig/libraries/ghc-boot/GHC/Platform/ArchOS.hs +++ ghc-9.4.7/libraries/ghc-boot/GHC/Platform/ArchOS.hs @@ -38,6 +38,8 @@ data Arch | ArchPPC | ArchPPC_64 PPC_64ABI | ArchS390X + | ArchSPARC + | ArchSPARC64 | ArchARM ArmISA [ArmISAExt] ArmABI | ArchAArch64 | ArchAlpha @@ -124,6 +126,8 @@ stringEncodeArch = \case ArchPPC_64 ELF_V1 -> "powerpc64" ArchPPC_64 ELF_V2 -> "powerpc64le" ArchS390X -> "s390x" + ArchSPARC -> "sparc" + ArchSPARC64 -> "sparc64" ArchARM ARMv5 _ _ -> "armv5" ArchARM ARMv6 _ _ -> "armv6" ArchARM ARMv7 _ _ -> "armv7"
Bug#967568: libayatana-indicator: depends on deprecated GTK 2
Control: tags -1 patch
Please find a patch attached that drops the GTK 2 flavour.
There is no reverse dependency anymore.diff -Nru libayatana-indicator-0.9.3/debian/changelog
libayatana-indicator-0.9.3/debian/changelog
--- libayatana-indicator-0.9.3/debian/changelog 2022-10-26 00:25:25.0
+0200
+++ libayatana-indicator-0.9.3/debian/changelog 2023-11-13 15:27:03.0
+0100
@@ -1,3 +1,10 @@
+libayatana-indicator (0.9.3-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop GTK 2 support. (Closes: #967568).
+
+ -- Bastian Germann Mon, 13 Nov 2023 15:27:03 +0100
+
libayatana-indicator (0.9.3-1) unstable; urgency=medium
* New upstream release.
diff -Nru libayatana-indicator-0.9.3/debian/control
libayatana-indicator-0.9.3/debian/control
--- libayatana-indicator-0.9.3/debian/control 2022-10-26 00:25:25.0
+0200
+++ libayatana-indicator-0.9.3/debian/control 2023-11-13 15:25:22.0
+0100
@@ -16,7 +16,6 @@
xauth,
xvfb,
libglib2.0-dev (>= 2.37),
- libgtk2.0-dev (>= 2.18),
libgtk-3-dev (>= 2.91.3),
libayatana-ido3-dev (>= 0.9.0),
Standards-Version: 4.6.1
@@ -25,31 +24,6 @@
Vcs-Git: https://salsa.debian.org/debian-ayatana-team/libayatana-indicator.git
Vcs-Browser:
https://salsa.debian.org/debian-edu-ayatana-team/libayatana-indicator
-Package: libayatana-indicator7
-Architecture: any
-Depends: ${shlibs:Depends},
- ${misc:Depends},
-Multi-Arch: same
-Description: panel indicator applet - shared library (GTK-2+ variant)
- The Ayatana Indicators library contains information to build indicators
- to go into modern desktops' indicator applets.
- .
- This package contains the library itself (GTK-2+ variant).
-
-Package: libayatana-indicator-dev
-Section: libdevel
-Architecture: any
-Depends: ${shlibs:Depends},
- ${misc:Depends},
- libgtk2.0-dev (>= 2.12.0),
- libayatana-indicator7 (= ${binary:Version}),
-Description: panel indicator applet - library development files (GTK-2+)
- The Ayatana Indicators library contains information to build indicators
- to go into modern desktops' indicator applets.
- .
- This package contains files that are needed to build GTK-2+ applications
- with Ayatana Indicator support.
-
Package: libayatana-indicator3-7
Architecture: any
Depends: ${shlibs:Depends},
diff -Nru libayatana-indicator-0.9.3/debian/libayatana-indicator7.install
libayatana-indicator-0.9.3/debian/libayatana-indicator7.install
--- libayatana-indicator-0.9.3/debian/libayatana-indicator7.install
2021-11-18 12:51:24.0 +0100
+++ libayatana-indicator-0.9.3/debian/libayatana-indicator7.install
1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/*/libayatana-indicator.so.*
diff -Nru libayatana-indicator-0.9.3/debian/libayatana-indicator7.symbols
libayatana-indicator-0.9.3/debian/libayatana-indicator7.symbols
--- libayatana-indicator-0.9.3/debian/libayatana-indicator7.symbols
2019-11-20 15:18:48.0 +0100
+++ libayatana-indicator-0.9.3/debian/libayatana-indicator7.symbols
1970-01-01 01:00:00.0 +0100
@@ -1,36 +0,0 @@
-libayatana-indicator.so.7 libayatana-indicator7 #MINVER#
-*Build-Depends-Package: libayatana-indicator-dev
- ICON_SIZE@Base 0.6.0
- INDICATOR_NAMES_DATA@Base 0.6.0
- indicator_desktop_shortcuts_get_nicks@Base 0.6.0
- indicator_desktop_shortcuts_get_type@Base 0.6.0
- indicator_desktop_shortcuts_new@Base 0.6.0
- indicator_desktop_shortcuts_nick_exec@Base 0.6.0
- indicator_desktop_shortcuts_nick_exec_with_context@Base 0.6.0
- indicator_desktop_shortcuts_nick_get_name@Base 0.6.0
- indicator_image_helper@Base 0.6.0
- indicator_image_helper_update@Base 0.6.0
- indicator_image_helper_update_from_gicon@Base 0.6.0
- indicator_object_check_environment@Base 0.6.0
- indicator_object_entry_activate@Base 0.6.0
- indicator_object_entry_activate_window@Base 0.6.0
- indicator_object_entry_close@Base 0.6.0
- indicator_object_entry_is_visible@Base 0.6.0
- indicator_object_get_entries@Base 0.6.0
- indicator_object_get_environment@Base 0.6.0
- indicator_object_get_location@Base 0.6.0
- indicator_object_get_position@Base 0.6.0
- indicator_object_get_show_now@Base 0.6.0
- indicator_object_get_type@Base 0.6.0
- indicator_object_new_from_file@Base 0.6.0
- indicator_object_set_environment@Base 0.6.0
- indicator_object_set_visible@Base 0.6.0
- indicator_scroll_direction_get_type@Base 0.6.0
- indicator_service_get_type@Base 0.6.0
- indicator_service_manager_connected@Base 0.6.0
- indicator_service_manager_get_type@Base 0.6.0
- indicator_service_manager_new@Base 0.6.0
- indicator_service_manager_new_version@Base 0.6.0
- indicator_service_manager_set_refresh@Base 0.6.0
- indicator_service_new@Base 0.6.0
- indicator_service_new_version@Base 0.6.0
diff -Nru libayatana-indicator-0.9.3/debian/libayatana-indicator-dev.install
libayatana-indicator-0.9.3/debian/libayatana-indicator-dev.install
---
Bug#1012720: ITP: golang-k8s-apimachinery -- Handle Kubernetes-like API objects
Hi Domenico, do you still plan to finish the packaging of golang-k8s-apimachinery shortly? In order to update glab package to v1.35.0 the package is needed; may we offer help or would it be ok for you if someone else takes-over your ITP? Kind regards, Nicolas On Sun, Jun 12, 2022 at 09:51:03PM +0200, Domenico Andreoli wrote: > Package: wnpp > Severity: wishlist > Owner: Domenico Andreoli > > * Package name: golang-k8s-apimachinery > Version : 1.25.0~alpha0-1 > Upstream Author : Kubernetes > * URL : https://github.com/kubernetes/apimachinery > * License : Apache-2.0 > Programming Lang: Go > Description : Handle Kubernetes-like API objects. > > This library is a shared dependency for servers and clients to work with > Kubernetes API infrastructure without direct type dependencies. Its > first consumers are k8s.io/kubernetes, k8s.io/client-go, and > k8s.io/apiserver. signature.asc Description: PGP signature
Bug#1050854: Please push your changes to python-xarray
Hi Apologies I am swamped on this. Please go ahead and apply. Thanks Alastair On 13/11/2023 12:51, Andreas Tille wrote: Ping? I'd love to apply the patch from the bug report and push everything properly. If I do not hear from you I might consider mass-commiting all the releases you made without pushing to the repository in one single commit and add what I'd like to commit. Kind regards Andreas. Am Tue, Nov 07, 2023 at 09:26:13AM +0100 schrieb Andreas Tille: Hi Alastair, I realised that the Git repository on salsa[1] is lagging a couple of uploads behind the package pool. Please be so kind to push your changes to Salsa. Thanks a lot for your work on this package Andreas. [1] https://salsa.debian.org/science-team/python-xarray -- http://fam-tille.de -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Bug#1055883: faust: better manpage duplication
Source: faust Severity: wishlist Dear Maintainer, currently we make symlinks for the various faust2* backends. man itself can do that as well. see https://lists.debian.org/debian-devel/2023/11/msg00084.html -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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#1055882: libncurses6: waddnstr() reads n+1 bytes, ought to end at n bytes
Package: libncurses6
Version: 6.4-4
Severity: normal
Tags: patch
Dear Maintainer,
Found by valgrind:
$ valgrind ./urlview text text.uv README
...
==1999505== Invalid read of size 1
==1999505==at 0x4872850: waddnstr (in
/usr/lib/x86_64-linux-gnu/libncursesw.so.6.4)
==1999505==by 0x10C26E: main (urlview.c:620)
==1999505== Address 0x4c78fbc is 0 bytes after a block of size 1,052 alloc'd
==1999505==at 0x484582F: realloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1999505==by 0x10BD0D: main (urlview.c:610)
this corresponds to
https://git.sr.ht/~nabijaczleweli/urlview-ng/tree/44240e3b8ed0694f14f40f4b1169359abe452b4b/item/urlview.c#L566-621
which is a big chunk, sorry
(execstatus allocated in EXECAPPENDONE(),
waddnstr() invoked via mvaddnstr() at the end).
but the code amounts to:
#include
#include
#include
int main() {
char * new = malloc(4);
memcpy(new, "dupa", 4);
initscr();
addnstr(new, 4);
endwin();
}
with
$ cc n.c $(pkgconf --cflags --libs ncursesw)
$ valgrind ./a.out > /dev/pts/5
==2022105== Memcheck, a memory error detector
==2022105== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2022105== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==2022105== Command: ./a.out
==2022105==
==2022105== Invalid read of size 1
==2022105==at 0x4872850: waddnstr (in
/usr/lib/x86_64-linux-gnu/libncursesw.so.6.4)
==2022105==by 0x1091AE: main (in /home/nabijaczleweli/uwu/a.out)
==2022105== Address 0x4ab9044 is 0 bytes after a block of size 4 alloc'd
==2022105==at 0x48407B4: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==2022105==by 0x109181: main (in /home/nabijaczleweli/uwu/a.out)
==2022105==
==2022105==
==2022105== HEAP SUMMARY:
==2022105== in use at exit: 813,473 bytes in 228 blocks
==2022105== total heap usage: 238 allocs, 10 frees, 821,440 bytes allocated
==2022105==
==2022105== LEAK SUMMARY:
==2022105==definitely lost: 4 bytes in 1 blocks
==2022105==indirectly lost: 0 bytes in 0 blocks
==2022105== possibly lost: 0 bytes in 0 blocks
==2022105==still reachable: 813,469 bytes in 227 blocks
==2022105== suppressed: 0 bytes in 0 blocks
==2022105== Rerun with --leak-check=full to see details of leaked memory
==2022105==
==2022105== For lists of detected and suppressed errors, rerun with: -s
==2022105== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
I hope this sample is simple enough it's obvious it's correct.
Looking at ncurses-6.4+20230625/ncurses/base/lib_addstr.c:
NCURSES_EXPORT(int)
waddnstr(WINDOW *win, const char *astr, int n)
{
const char *str = astr;
int code = ERR;
T((T_CALLED("waddnstr(%p,%s,%d)"), (void *) win, _nc_visbufn(astr, n),
n));
if (win && (str != 0)) {
TR(TRACE_VIRTPUT | TRACE_ATTRS,
("... current %s", _traceattr(WINDOW_ATTRS(win;
code = OK;
TR(TRACE_VIRTPUT, ("str is not null, length = %d",
((n > 0) ? n : (int) strlen(str;
if (n < 0)
n = INT_MAX;
while ((*str != '\0') && (n-- > 0)) {
NCURSES_CH_T ch;
TR(TRACE_VIRTPUT, ("*str = %#o", UChar(*str)));
SetChar(ch, UChar(*str++), A_NORMAL);
if (_nc_waddch_nosync(win, ch) == ERR) {
code = ERR;
break;
}
}
_nc_synchook(win);
}
TR(TRACE_VIRTPUT, ("waddnstr returns %d", code));
returnCode(code);
}
I see "while ((*str != '\0') && (n-- > 0)) {" is in the wrong order,
and ought to be "(n-- > 0) && (*str != '\0')" ‒ only reading from str
when it's not past the end.
A cursory glance with \bn\b at the rest of the funxions in that file
reveals:
waddchnstr has "for (i = 0; i < n && ChCharOf(astr[i]) != '\0'; ++i) {"
which is correct,
waddnwstr has "while ((*str != L('\0')) && (n-- > 0)) {"
which should also be "while ((n-- > 0) && (*str != L('\0'))) {".
Rebuilding 6.4+20230625-2 with the changes described (obvious diff attached)
fixes the issue
$
LD_LIBRARY_PATH=~/uwu/ncurses-6.4+20230625/obj-wide/usr/lib/x86_64-linux-gnu/
valgrind ./a.out > /dev/pts/5
==2162311== Memcheck, a memory error detector
==2162311== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2162311== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==2162311== Command: ./a.out
==2162311==
==2162311==
==2162311== HEAP SUMMARY:
==2162311== in use at exit: 813,473 bytes in 228 blocks
==2162311== total heap usage: 239 allocs, 11 frees, 821,468 bytes allocated
==2162311==
==2162311== LEAK SUMMARY:
==2162311==definitely lost: 4 bytes in 1 blocks
==2162311==indirectly lost: 0 bytes in 0 blocks
==2162311==
Bug#975405: libwabt.js => sucess but need policy and help
Le lundi 13 novembre 2023, 11:18:42 UTC Markus Koschany a écrit : > Hey, > > Am Montag, dem 13.11.2023 um 09:19 + schrieb Bastien Roucariès: > > [...] > > Apo can I add myself to your package ? Do you care to comaintain with > > javascript team ? > > I assume you are referring to wabt and this bug report [1] ? > > Do you have a solution for the circular dependency that building libwabt.js > would create? > > In general I would be totally fine if you or the Javascript team would > completely take over wabt and binaryen because both of them and emscripten are > closely related. See also #1052003; emscripten FTBFS with binaryen from > experimental. > > Personally I only need wabt and binaryen to build WebAssembly code from source > for the ublock-origin Firefox/Chromium addon but I'm not really interested in > becoming more involved in the Javascript ecosystem. So feel free to take over > both packages and remove me as the maintainer. I think the solution here is build profiles like we other package involving this kind of stuff. Ok will take for it and add javascript team > > Regards, > > Markus > > [1] https://bugs.debian.org/975405 > > signature.asc Description: This is a digitally signed message part.
Bug#1055881: virtualbox-dkms: Linux 6.7-rc1 throws "invalid opcode" during module loading
Package: virtualbox-dkms Version: 7.0.12-dfsg-1 Severity: normal On linux 6.7-rc1 the virtualbox kernelmodules do build without problem, but during boot the kernel throws an "illegal instruction" while loading vboxdrv: [ 18.036170] vboxdrv: loading out-of-tree module taints kernel. [ 18.039745] vboxdrv: Found 2 processor cores/threads [ 18.040619] invalid opcode: [#1] SMP [ 18.040828] CPU: 0 PID: 1974 Comm: modprobe Tainted: G O 6.7.0-rc1-pinguin20231113 #1 [ 18.041044] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H97 Anniversary, BIOS P1.20 12/15/2014 [ 18.041272] RIP: 0010:VBoxHost_RTLogGroupSettings+0x376/0x3f0 [vboxdrv] [ 18.041546] Code: d0 0f 84 8d fe ff ff 89 c6 85 f6 74 e5 0f 0b 41 09 8c 80 bc 00 00 00 48 83 c0 01 48 39 d0 0f 84 70 fe ff ff 89 c6 85 f6 74 e5 <0f> 0b b9 11 00 00 00 eb a0 8b 05 db ed 02 00 85 c0 75 1a 4c 8b 05 [ 18.041840] RSP: 0018:a9a2c1e77a68 EFLAGS: 00010202 [ 18.042158] RAX: 0001 RBX: c0637424 RCX: 0011 [ 18.042488] RDX: 019d RSI: 0001 RDI: 0003 [ 18.042822] RBP: a9a2c1e77ac8 R08: 8ee544150010 R09: c062a7e0 [ 18.043167] R10: 8ee544150010 R11: 000c R12: c0637427 [ 18.043397] R13: 0740 R14: a9a2c1e77c20 R15: [ 18.043635] FS: 7f04f5145040() GS:8ee84fe0() knlGS: [ 18.043879] CS: 0010 DS: ES: CR0: 80050033 [ 18.044129] CR2: 555689427660 CR3: 00010929b005 CR4: 000706f0 [ 18.044386] Call Trace: [ 18.044646] [ 18.044909] ? die+0x2d/0x80 [ 18.045177] ? do_trap+0xeb/0xf0 [ 18.045444] ? VBoxHost_RTLogGroupSettings+0x376/0x3f0 [vboxdrv] [ 18.045740] ? do_error_trap+0x60/0x80 [ 18.046019] ? VBoxHost_RTLogGroupSettings+0x376/0x3f0 [vboxdrv] [ 18.046322] ? exc_invalid_op+0x49/0x60 [ 18.046611] ? VBoxHost_RTLogGroupSettings+0x376/0x3f0 [vboxdrv] [ 18.046923] ? asm_exc_invalid_op+0x16/0x20 [ 18.047222] ? VBoxHost_RTLogGroupSettings+0x376/0x3f0 [vboxdrv] [ 18.047544] ? rtR0MemAllocEx+0x52/0xc0 [vboxdrv] [ 18.047871] VBoxHost_RTLogCreateExV+0x27b/0x470 [vboxdrv] [ 18.048203] VBoxHost_RTLogCreate+0x6a/0x90 [vboxdrv] [ 18.048537] ? rtR0MemAllocEx+0x52/0xc0 [vboxdrv] [ 18.048875] supdrvInitDevExt+0x54/0x320 [vboxdrv] [ 18.049216] VBoxDrvLinuxInit+0x82/0x1000 [vboxdrv] [ 18.049561] ? 0xc05b7000 [ 18.049891] do_one_initcall+0x87/0x2a0 [ 18.050223] do_init_module+0x7d/0x230 [ 18.050561] init_module_from_file+0x81/0xc0 [ 18.050901] idempotent_init_module+0x119/0x230 [ 18.051246] __x64_sys_finit_module+0x4d/0x80 [ 18.051592] do_syscall_64+0x56/0x100 [ 18.051944] ? handle_mm_fault+0xe1/0x1c0 [ 18.052298] ? exc_page_fault+0x276/0x680 [ 18.052655] entry_SYSCALL_64_after_hwframe+0x46/0x4e [ 18.053017] RIP: 0033:0x7f04f4b1eee9 [ 18.053381] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ff 1e 0d 00 f7 d8 64 89 01 48 [ 18.053786] RSP: 002b:7ffe7c2cf7b8 EFLAGS: 0246 ORIG_RAX: 0139 [ 18.054207] RAX: ffda RBX: 556c56beb4e0 RCX: 7f04f4b1eee9 [ 18.054635] RDX: RSI: 556c54d7998b RDI: 0003 [ 18.055069] RBP: R08: 0060 R09: 556c56bec340 [ 18.055508] R10: 0038 R11: 0246 R12: 556c54d7998b [ 18.055947] R13: 0004 R14: 556c56beb560 R15: [ 18.056393] [ 18.056842] Modules linked in: vboxdrv(O+) sha256_ssse3 sha1_ssse3 sha1_generic [ 18.057310] ---[ end trace ]--- [ 18.057775] RIP: 0010:VBoxHost_RTLogGroupSettings+0x376/0x3f0 [vboxdrv] [ 18.058267] Code: d0 0f 84 8d fe ff ff 89 c6 85 f6 74 e5 0f 0b 41 09 8c 80 bc 00 00 00 48 83 c0 01 48 39 d0 0f 84 70 fe ff ff 89 c6 85 f6 74 e5 <0f> 0b b9 11 00 00 00 eb a0 8b 05 db ed 02 00 85 c0 75 1a 4c 8b 05 [ 18.058773] RSP: 0018:a9a2c1e77a68 EFLAGS: 00010202 [ 18.059290] RAX: 0001 RBX: c0637424 RCX: 0011 [ 18.059809] RDX: 019d RSI: 0001 RDI: 0003 [ 18.060328] RBP: a9a2c1e77ac8 R08: 8ee544150010 R09: c062a7e0 [ 18.060852] R10: 8ee544150010 R11: 000c R12: c0637427 [ 18.061373] R13: 0740 R14: a9a2c1e77c20 R15: [ 18.061895] FS: 7f04f5145040() GS:8ee84fe0() knlGS: [ 18.062419] CS: 0010 DS: ES: CR0: 80050033 [ 18.062939] CR2: 555689427660 CR3: 00010929b005 CR4: 000706f0 -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (800, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.1
Bug#857763: udhcpd: Please set FEATURE_UDHCPD_WRITE_LEASES_EARLY in build config
On Tue, 14 Mar 2017 17:25:50 + Sabahattin Gucukoglu wrote: Source: busybox Version: 1:1.22.0-19 Severity: wishlist The dumpleases utility would be made more useful on a system with an SSD if FEATURE_UDHCPD_WRITE_LEASES_EARLY were set at build time, because then you wouldn't need to set a low auto_time (udhcpd.conf option) to get up-to-date lease information from an unprivileged account, without having to first send a signal to udhcpd from root. Please set this build option. I guess it's still too much to write leases file on every DHCP ACK, even 6 years after this bug report has been submitted. What would be useful though, is for dumpleases to send SIGUSR1 to dhcpd before reading the leases file. I guess. Dunno how it would syncronize though. /mjt
Bug#1042609: sphinxcontrib-mermaid: FTBFS with Sphinx 7.1, docutils 0.20: Could not import sphinx.util.SphinxParallelError (exception: No module named 'sphinx.util.SphinxParallelError')
Hi Faidon! On Mon, Nov 13, 2023 at 10:52:58AM +0200, Faidon Liambotis wrote: > Upstream commit 6f8de39¹, the only commit since 0.9.2, replaces > sphinx.util.SphinxParallelError by sphinx.util.DownloadFiles. > > I've verified that backporting this commit makes the package build > successfully in unstable, with Sphinx 7.2.6-2. > > However, the very same commit changes requirements.txt from > "Sphinx>=3.2.1" to "Sphinx<7". > > I'm not sure why. I'm not using, nor am I familiar with this plugin, so > I was hoping someone else that is could perhaps validate whether besides > being able to be built, the package actually works. > > 1: > https://github.com/mgaitan/sphinxcontrib-mermaid/commit/6f8de39a84fddc398542e9d4dc74ba55101e7d5e The SphinxParallelError class is defined in sphinx.errors module. It was available in sphinx.util because that module happened to import it from sphinx.errors, but that is no longer the case since Sphinx 6.1. Probably the author of the linked commit was testing with Sphinx 6.1 (or 6.2), but had different problems with early Sphinx 7 versions (only Sphinx 7.0.1 was available at that moment), so changed the dependency to <7. The change in README.rst looks trivial, so if it helps, I would go ahead and cherry-pick it to our packaging without the requirements.txt change. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1055860: Acknowledgement (elpa-org-contrib: should not bind C-c j)
"Debian Bug Tracking System" writes: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 1055860: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055860. > The offending file is "org-secretary.el", which rebinds several keys reserved for users. It seems to have registered "join" as an autoloaded function from org-secretary.el, which sounds like a pretty bad choice of name. I think I ran it by mistake when attempting to run #'join-line.
Bug#1050854: Please push your changes to python-xarray
Ping? I'd love to apply the patch from the bug report and push everything properly. If I do not hear from you I might consider mass-commiting all the releases you made without pushing to the repository in one single commit and add what I'd like to commit. Kind regards Andreas. Am Tue, Nov 07, 2023 at 09:26:13AM +0100 schrieb Andreas Tille: > Hi Alastair, > > I realised that the Git repository on salsa[1] is lagging a couple of > uploads behind the package pool. Please be so kind to push your changes > to Salsa. > > Thanks a lot for your work on this package > Andreas. > > [1] https://salsa.debian.org/science-team/python-xarray > > -- > http://fam-tille.de > > -- http://fam-tille.de
Bug#1055880: kaidan missing two dependencies
Package: kaidan version: 0.9.1-1 severity: grave justification: fails to start Though fix is easy, missing dependencies are qml-module-org-kde-kquickimageeditor and qml-module-org-kde-kirigami-addons-labs-mobileform After installing these manually, kaidan starts as expected.
Bug#1055877: ndcube: FTBFS in bookworm: leap-second file is expired
A more simple approach would be to modify debian/rules so that (all) the tests are skipped after a certain date, as in the attached patch. Thanks.--- a/debian/rules +++ b/debian/rules @@ -7,6 +7,9 @@ export PYBUILD_TEST_ARGS=../../../ndcube export http_proxy=127.0.0.1:9 export HOME=$(shell mktemp -d) +CURRENT_TS := $(shell date +%s) +EXPIRE_TS := $(shell date +%s -d "2023-12-01") + BUILD_DATE = $(shell LC_ALL=C date -u "+%B %d, %Y" -d "@$(SOURCE_DATE_EPOCH)") SPHINXOPTS := -D html_last_updated_fmt="$(BUILD_DATE)" -D html_show_copyright=0 @@ -36,3 +39,6 @@ override_dh_link: dh_link # Remove duplicates in documentation package jdupes -rl debian/python3-ndcube-doc/usr + +override_dh_auto_test: + [ "$(CURRENT_TS)" -gt "$(EXPIRE_TS)" ] || dh_auto_test
Bug#1036446: Bug1036446: Please enable udhcpc6
Control: tag -1 + pending On Sun, 21 May 2023 04:11:09 +0200 Ben Hutchings wrote: Package: udhcpc Version: 1:1.35.0-4+b2 Severity: wishlist Tags: ipv6 Busybox has a DHCPv6 client (udhcpc6) but this is not included in the Debian packages. Please enable CONFIG_UDHCPC6 and the dependent features. This probably needs udhcpc6 package too, similar to udhcpc package. /mjt
Bug#1055879: ITP: ru-tts -- Compact and portable Russian speech synthesizer
Package: wnpp Severity: wishlist Owner: "Igor B. Poretsky" * Package name: ru-tts Version : 6.2.0 Upstream Author : Igor B. Poretsky * URL : https://github.com/poretsky/ru_tts * License : MIT Programming Lang: C Description : Compact and portable Russian speech synthesizer An alternative implementation of the Phonemophone-5 Russian speech synthesizer by the international laboratory of intelligent systems BelSInt (the Speech Recognition and Synthesis Lab of the Institute of Technical Cybernetics of the Academy of Sciences of the Byelorussian SSR). The source code of the original implementation has been lost. This implementation is the result of a reverse engineering of the SDRV resident speech driver for MS-DOS, and it is officially approved for publication under a free license by Boris Lobanov, who is the head of the laboratory and the author of the design solutions that formed the basis of the speech synthesizer, and Alexander Ivanov, who is an engineer of the laboratory and the developer of the speech synthesizer's the original software implementation. It is extremely fast, compact and portable indeed. Meanwhile, it provides quite decent speech quality. Being implemented as a library, it can easily be used in other applications. Currently need a sponsor for upload.
Bug#1055877: ndcube: FTBFS in bookworm: leap-second file is expired
Package: src:ndcube
Version: 2.0.3-1
Severity: serious
Tags: ftbfs bookworm patch upstream
Dear maintainer:
During a rebuild of all packages in bookworm, this package failed to build
with the following error:
---
files = None
def update_leap_seconds(files=None):
"""If the current ERFA leap second table is out of date, try to update
it.
Uses `astropy.utils.iers.LeapSeconds.auto_open` to try to find an
up-to-date table. See that routine for the definition of "out of date".
In order to make it safe to call this any time, all exceptions are turned
into warnings,
Parameters
--
files : list of path-like, optional
List of files/URLs to attempt to open. By default, uses defined by
`astropy.utils.iers.LeapSeconds.auto_open`, which includes the table
used by ERFA itself, so if that is up to date, nothing will happen.
Returns
---
n_update : int
Number of items updated.
"""
try:
from astropy.utils import iers
table = iers.LeapSeconds.auto_open(files)
return erfa.leap_seconds.update(table)
except Exception as exc:
warn(
f"leap-second auto-update failed due to the following exception:
{exc!r}",
AstropyWarning,
)
E astropy.utils.exceptions.AstropyWarning: leap-second auto-update
failed due to the following exception: IERSStaleWarning('leap-second file is
expired.')
/usr/lib/python3/dist-packages/astropy/time/core.py:3315: AstropyWarning
=== short test summary info
FAILED
../../../ndcube/extra_coords/tests/test_extra_coords.py::test_two_1d_from_lut
= 1 failed, 276 passed, 5 skipped, 27 deselected, 9 xfailed, 2 xpassed in 4.68s
=
E: pybuild pybuild:388: test: plugin distutils failed with: exit code=1: cd
/<>/.pybuild/cpython3_3.11_ndcube/build; python3.11 -m pytest
../../../ndcube
dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit
code 13
make: *** [debian/rules:14: binary-indep] Error 25
dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit
status 2
In reproducible-builds, the same package version (2.0.3-1) builds ok in trixie:
https://tests.reproducible-builds.org/debian/rbuild/trixie/amd64/ndcube_2.0.3-1.rbuild.log.gz
but not the second build, which is tried one month in the future precisely
to catch errors like this one:
https://tests.reproducible-builds.org/debian/logs/trixie/amd64/ndcube_2.0.3-1.build2.log.gz
Note that because exactly the same package version builds ok in trixie but not in
bookworm, we could be tempted to consider this as a bug in the package which provides the
leap-second file, which is "not updated enough in bookworm".
However, I don't think this would be a good idea, as this problem would become
some sort
of time-bomb. We want packages to build ok from source not only at release time
but also
during all the lifetime of bookworm as stable (and if possible, forever), i.e.
users should
not be forced to upgrade all the time so that the packages continue to build ok.
I attach a patch which works for me in bookworm. Please double-check, no
warranty, etc.
Alternatively, all those unconditional skip marks could be
changed to something like this, in pseudocode:
skipif(currentdate >
hardcoded-expiration-date-of-leapsecond-file-at-upload-time)
but I don't really know if it worth the effort.
I'm tagging this as "upstream" because I believe there should be an easier way
to deal with this.
Thanks.commit 079219c8ad4bc798065a28528283f59373be2623
Author: Santiago Vila
Date: Mon Nov 13 13:15:00 2023 +0100
skip-time-bombs
diff --git a/ndcube/extra_coords/tests/test_extra_coords.py
b/ndcube/extra_coords/tests/test_extra_coords.py
index f3463b2..197b934 100644
--- a/ndcube/extra_coords/tests/test_extra_coords.py
+++ b/ndcube/extra_coords/tests/test_extra_coords.py
@@ -158,6 +158,7 @@ def test_single_from_lut(extra_coords_wave):
assert ec.wcs.world_axis_names == ("wave",)
+@pytest.mark.skip(reason="time bomb")
def test_two_1d_from_lut(time_lut):
cube = MagicMock()
cube.dimensions = [10] * u.pix
@@ -174,6 +175,7 @@ def test_two_1d_from_lut(time_lut):
assert ec.wcs.world_axis_names == ("time", "exposure_time")
+@pytest.mark.skip(reason="time bomb")
def test_two_1d_from_lookup_tables(time_lut):
"""
Create ExtraCoords from both tables at once using `from_lookup_tables`
with `physical_types`.
@@ -252,6 +254,7 @@ def test_skycoord_mesh_false(skycoord_2d_lut):
assert ec.wcs.world_axis_names == ("lat", "lon")
+@pytest.mark.skip(reason="time bomb")
def test_extra_coords_index(skycoord_2d_lut, time_lut):
cube = MagicMock()
Bug#1055878: atomix: window doesn't scale to low resolution devices like PinePhonePro
Package: atomix Version: 44.0-3 Severity: normal On a PinePhonePro the window for this game doesn't scale to the 720*1440 display so is unable to show the game screen and the diagram of the required molecule at the same time. Probably the ideal for devices that have a tall thin screen would be to have the Statistics section and the molecule above the game play area. Apart from this the game is very playable on a Linux phone, it's easier on a touch screen than using a mouse. I'll send a screen-shot after the bug is created. -- System Information: Debian Release: trixie/sid Architecture: arm64 (aarch64) Kernel: Linux 6.6-rockchip (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages atomix depends on: ii atomix-data 44.0-3 ii libc6 2.37-12 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-2 ii libglib2.0-02.78.1-3 ii libgnome-games-support-1-3 1.8.2-2 ii libgtk-3-0 3.24.38-5mobian1 atomix recommends no packages. atomix suggests no packages. -- debconf-show failed
Bug#810018: Bug #810018: Consider shipping pidof with procps
On Mon, 13 Nov 2023 at 09:17, Craig Small wrote: > > > On Sat, 11 Nov 2023 at 23:45, Luca Boccassi wrote: >> >> Now that Bookworm has shipped, what about finally finishing this and >> getting rid of this debianism? There is really no reason to delay it >> any longer at this point. Thank you! > > Hi Luca, > I'll need the assistance of the sysvinit-utils maintainers (CC'ed) as well, > as pidof will be moving from that package. Doing this will also bring Debian > (and Ubuntu) in line with most other distributions out there that use pidof > from procps. > > I'm, not going to cover sysvinit-utils moving out of Essential as it doesn't > matter for procps if it is or is not. > > So I'm looking at https://wiki.debian.org/PackageTransition > and assuming procps is 2:4.0.4-2 and sysvinit-utils is 3.08-3 > > I would create procps 2:4.0.4-3 with pidof and Breaks: sysvinit-utils (<< > 3.0.8-4) and Replaces: sysvinit-utils (<< 3.0.8-4) > sysvinit-utils maintainers create 3.08-4 without pidof and have Breaks: > procps (<< 2:4.0.4-3) > > If everyone is in agreement with this, I'll update procps this week. Thank you, LGTM.
Bug#1055875: util-linux: FTBFS on hurd-i386
* Samuel Thibault [231113 12:27]: > Svante Signell, le lun. 13 nov. 2023 12:08:56 +0100, a ecrit: > > util-linux FTBFS on hurd-i386 (built in the past, last successful build was > > 2.39.1-4). > > In general, better discuss directly with upstream. Indeed. Please, generally send (build) fixes upstream and once committed I'll happily take commit ids and apply them in Debian. This is a much better workflow, as the patch will also 'stick' for new versions etc. > They commited a > different fix, as attached: just not include hooks.c on non-linux :) Thank you! > > Samuel > commit 1e0ad14b3ac08d855cda6de346a65f9b834e00db > Author: Karel Zak > Date: Mon Sep 18 13:08:57 2023 +0200 > > build-sys: fix libmount/src/hooks.c use > > Reported-by: Samuel Thibault > Signed-off-by: Karel Zak [..]
Bug#967807: wmcoincoin: depends on deprecated GTK 2
I am uploading a NMU to DELAYED/10 in order to fix this. The debdiff is attached.diff -Nru wmcoincoin-2.6.5.git+23.411d4a3/debian/changelog wmcoincoin-2.6.5.git+23.411d4a3/debian/changelog --- wmcoincoin-2.6.5.git+23.411d4a3/debian/changelog2022-08-25 22:40:55.0 +0200 +++ wmcoincoin-2.6.5.git+23.411d4a3/debian/changelog2023-11-13 12:28:38.0 +0100 @@ -1,3 +1,10 @@ +wmcoincoin (2.6.5.git+23.411d4a3-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Drop wmccc (closes: #967807). + + -- Bastian Germann Mon, 13 Nov 2023 12:28:38 +0100 + wmcoincoin (2.6.5.git+23.411d4a3-2) unstable; urgency=medium * d/control diff -Nru wmcoincoin-2.6.5.git+23.411d4a3/debian/control wmcoincoin-2.6.5.git+23.411d4a3/debian/control --- wmcoincoin-2.6.5.git+23.411d4a3/debian/control 2022-08-25 22:40:55.0 +0200 +++ wmcoincoin-2.6.5.git+23.411d4a3/debian/control 2023-11-13 12:27:23.0 +0100 @@ -6,7 +6,7 @@ Jeremy Sowden Build-Depends: debhelper-compat (= 13), libcurl4-openssl-dev | libcurl-dev, - libgtk2.0-dev, + pkg-config, libimlib2-dev, libx11-dev, libxext-dev, diff -Nru wmcoincoin-2.6.5.git+23.411d4a3/debian/manpages wmcoincoin-2.6.5.git+23.411d4a3/debian/manpages --- wmcoincoin-2.6.5.git+23.411d4a3/debian/manpages 2022-08-24 15:20:53.0 +0200 +++ wmcoincoin-2.6.5.git+23.411d4a3/debian/manpages 2023-11-13 12:28:38.0 +0100 @@ -1,3 +1,2 @@ -debian/wmccc.1 debian/wmcoincoin.1 debian/wmpanpan.1 diff -Nru wmcoincoin-2.6.5.git+23.411d4a3/debian/rules wmcoincoin-2.6.5.git+23.411d4a3/debian/rules --- wmcoincoin-2.6.5.git+23.411d4a3/debian/rules2022-08-24 15:20:53.0 +0200 +++ wmcoincoin-2.6.5.git+23.411d4a3/debian/rules2023-11-13 12:28:17.0 +0100 @@ -6,6 +6,9 @@ %: dh $@ +override_dh_auto_configure: + dh_auto_configure -- --disable-wmccc + execute_after_dh_install: mv $(INSTDIR)/bin/wmcoincoin $(INSTDIR)/bin/wmcoincoin_player \ $(INSTDIR)/libexec/wmcoincoin/
Bug#1055876: lastpass-cli: lpass login fails with "Error: SSL peer certificate or SSH remote key was not OK."
Package: lastpass-cli Version: 1.3.4-1 Severity: important Hi, On Bookworm I cannot log in to Lastpass any more, I get the following error: Error: SSL peer certificate or SSH remote key was not OK. Upstream issues: https://github.com/lastpass/lastpass-cli/issues/540 https://github.com/lastpass/lastpass-cli/issues/653 Thanks, Domenico -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 6.6.0-arm64 (SMP w/6 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) Versions of packages lastpass-cli depends on: ii binutils 2.40-2 ii ca-certificates 20230311 ii libc62.36-9+deb12u3 ii libcurl4 7.88.1-10+deb12u4 ii libssl3 3.0.11-1~deb12u2 ii libxml2 2.9.14+dfsg-1.3~deb12u1 Versions of packages lastpass-cli recommends: ii pinentry-curses 1.2.1-1 Versions of packages lastpass-cli suggests: pn xclip | xsel
Bug#925545: udhcpd: support for Runit supervision system
On Tue, 26 Mar 2019 17:25:09 + Dmitry Bogatov wrote: Package: udhcpd Version: 1:1.30.1-3 Severity: wishlist Tags: patch User: ru...@packages.debian.org Usertags: runscript Curious - Why are you filing this against udhcpd only, why not to do it for other packages too? Also, how runit handles restarts/reloads/shutdowns, aren't additional scripts needed for this? /mjt
Bug#1055875: util-linux: FTBFS on hurd-i386
Hello, Svante Signell, le lun. 13 nov. 2023 12:08:56 +0100, a ecrit: > util-linux FTBFS on hurd-i386 (built in the past, last successful build was > 2.39.1-4). In general, better discuss directly with upstream. They commited a different fix, as attached: just not include hooks.c on non-linux :) Samuel commit 1e0ad14b3ac08d855cda6de346a65f9b834e00db Author: Karel Zak Date: Mon Sep 18 13:08:57 2023 +0200 build-sys: fix libmount/src/hooks.c use Reported-by: Samuel Thibault Signed-off-by: Karel Zak diff --git a/libmount/meson.build b/libmount/meson.build index ba95acf37..a9d4d7780 100644 --- a/libmount/meson.build +++ b/libmount/meson.build @@ -17,7 +17,6 @@ configure_file( lib_mount_sources = ''' src/mountP.h src/cache.c - src/hooks.c src/fs.c src/init.c src/iter.c diff --git a/libmount/src/Makemodule.am b/libmount/src/Makemodule.am index d474aea0c..367bc4673 100644 --- a/libmount/src/Makemodule.am +++ b/libmount/src/Makemodule.am @@ -11,7 +11,6 @@ libmount_la_SOURCES = \ libmount/src/mountP.h \ libmount/src/cache.c \ libmount/src/fs.c \ - libmount/src/hooks.c \ libmount/src/init.c \ libmount/src/iter.c \ libmount/src/lock.c \ @@ -31,6 +30,7 @@ libmount_la_SOURCES += \ libmount/src/context.c \ libmount/src/context_mount.c \ libmount/src/context_umount.c \ + libmount/src/hooks.c \ libmount/src/hook_mount.c \ libmount/src/hook_mount_legacy.c \ libmount/src/hook_mkdir.c \
Bug#975405: libwabt.js => sucess but need policy and help
Hey, Am Montag, dem 13.11.2023 um 09:19 + schrieb Bastien Roucariès: [...] > Apo can I add myself to your package ? Do you care to comaintain with > javascript team ? I assume you are referring to wabt and this bug report [1] ? Do you have a solution for the circular dependency that building libwabt.js would create? In general I would be totally fine if you or the Javascript team would completely take over wabt and binaryen because both of them and emscripten are closely related. See also #1052003; emscripten FTBFS with binaryen from experimental. Personally I only need wabt and binaryen to build WebAssembly code from source for the ublock-origin Firefox/Chromium addon but I'm not really interested in becoming more involved in the Javascript ecosystem. So feel free to take over both packages and remove me as the maintainer. Regards, Markus [1] https://bugs.debian.org/975405 signature.asc Description: This is a digitally signed message part
Bug#1055759: duplicate upstream bug report
Turns out I'm not the first person to have reported this. I've closed my ticket as a duplicate. The earlier one is: https://core.tcl-lang.org/tcltls/tktview/88c0c84969 J. signature.asc Description: PGP signature
Bug#1055875: util-linux: FTBFS on hurd-i386
Source: util-linux
Version: 2.39.2-5
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org
Hi,
util-linux FTBFS on hurd-i386 (built in the past, last successful build was
2.39.1-4).
A patch enabling a successful build is attached:
libmount_src_hooks.c.diff where mnt_context_is_fake()
is defined only if USE_LIBMOUNT_MOUNTFD_SUPPORT is defined. And
USE_LIBMOUNT_MOUNTFD_SUPPORT is only defined on GNU/Linux systems.
Alternately #ifdef __linux__ instead of #ifdef USE_LIBMOUNT_MOUNTFD_SUPPORT
could be used as condition. Maybe that would be a better solution.
Configure reports:
configure: WARNING: non-linux system; not building libmount_mountfd_support,
among in total 47 warnings for not building on a non-linux system.
Thanks!
--- a/libmount/src/hooks.c 2023-08-17 09:56:12.0 +0200
+++ b/libmount/src/hooks.c 2023-11-11 19:29:01.0 +0100
@@ -315,11 +315,14 @@
{
int rc = 0;
+#ifdef USE_LIBMOUNT_MOUNTFD_SUPPORT
if (mnt_context_is_fake(cxt))
DBG(CXT, ul_debugobj(cxt, " FAKE call"));
else
rc = hook->func(cxt, hook->hookset, hook->data);
-
+#else
+ rc = hook->func(cxt, hook->hookset, hook->data);
+#endif
hook->executed = 1;
if (!rc)
rc = call_depend_hooks(cxt, hook->hookset->name, hook->stage);
@@ -364,10 +367,14 @@
DBG(CXT, ul_debugobj(cxt, "calling %s [first]", hs->name));
+#ifdef USE_LIBMOUNT_MOUNTFD_SUPPORT
if (mnt_context_is_fake(cxt))
DBG(CXT, ul_debugobj(cxt, " FAKE call"));
else
rc = hs->firstcall(cxt, hs, NULL);
+#else
+ rc = hs->firstcall(cxt, hs, NULL);
+#endif
if (!rc)
rc = call_depend_hooks(cxt, hs->name, stage);
if (rc < 0)
Bug#1055873: Acknowledgement (dcm2json is missing --convert-un for CP-1066 EVRLE)
Current work-around: % dcmconv +ti RTStruct_VRDSAsVRUN.dcm - | dcm2json - output.json
Bug#1055872: Acknowledgement (CP-2275: "NaN", "+Infinity" and "-Infinity")
Control: forwarded -1 https://support.dcmtk.org/redmine/issues/1086 Confirmed by upstream. On Mon, Nov 13, 2023 at 11:51 AM Debian Bug Tracking System wrote: > > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 1055872: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055872. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian Med Packaging Team > > If you wish to submit further information on this problem, please > send it to 1055...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 1055872: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055872 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Bug#1053565: RFS: openvpn3-client/20+dfsg-1 [ITP] -- virtual private network daemon (version 3)
06.10.2023 16:03, Marc Leeman wrote: * Package name : openvpn3-client BTW, why it is named this way? Is it client-only now, without the server part? Previous package is named just "openvpn", it acts as both client or server (actually the two roles are symmetric, it can be both). If new openvpn is like this, I suggest naming it just "openvpn3", without the -client part, since it is quite confusing. Or is there also -daemon (or -server) part? Thanks, /mjt
