Bug#992081: RFP: elpa-persistent-scratch -- preserve scratch buffers across Emacs sessions
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-emac...@lists.debian.org * Package name: elpa-persistent-scratch Version : 0.3.5 Upstream Author : Fanael Linithien * URL or Web page : https://github.com/Fanael/persistent-scratch * License : BSD 2-clause "Simplified" License Description : preserve the state of scratch buffers across Emacs sessions
Bug#992073: shim-signed: restore arm64 support
Hi, On 10-08-2021 19:02, Antonio Terceiro wrote: > As a data point, the Huawei cloud infra where ci.debian.net runs arm64 > workers (for arm*) does use Secure Boot on arm64, and applying security > updates broke our machines there. Just a proper follow-up. It seems we were hit by the inappropriate 1.36~1+deb10u1+15.4-5~deb10u1. This was possible because we used APT::Default-Release "buster" ; which *doesn't* include buster-updates, so the fixed package was prioritized *below* the broken one by APT. Upgrading a fresh VM with a fixed APT::Default-Release pulled in the fixed package from buster-updates and enabled the VM to reboot afterwards. So, Huawei doesn't seem to force Secure Boot on armd64 after all. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#992075: gitlab: download button for 2fa recovery codes does not work (coping works)
Upstream issue: https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/2271 Can be fixed with this commit: https://gitlab.com/gitlab-org/gitlab-ui/-/commit/3a4de98fecfe8e7808e3e83cd84a0639c1e6f33b
Bug#991104: antlr: reproducible-builds: Example Makefiles embed build paths and binary paths
Hi Vagrant! On Wed, Jul 14, 2021 at 07:37:58AM -0700, Vagrant Cascadian wrote: > Source: antlr > Severity: normal > Tags: patch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: buildpath usrmerge > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > The build path and several binary paths are embedded in example Makefiles > shipped in the package: Right... I can't imagine why a user would want to have these in installed as examples. They seem more like build artifacts. Thanks for the patch. I will prepare a new upload of antlr real soon now. > If removing the Makefiles is somehow not an option, an alternate option > would be to sanitize the Makefiles stripping the build path, and > possibly passing various variables to configure (e.g. GREP=/bin/grep, > SHELL=/bin/sh, ...). Sanitization sounds like a good plan, if there ends up being a use case. Cheers, tony signature.asc Description: PGP signature
Bug#992052: [Debian-med-packaging] Bug#992052: cd-hit: autopkgtest fails on very powerful CI workers
Hi Paul, Paul Gevers, on 2021-08-10: > I copied some of the output at the bottom of this report. It's ironical > that cd-hit complains about not enough memory when the worker this test > runs on has the biggest amount of memory we have in the ci.d.n worker > park: 250GB. If I read the output correctly, you assign the amount of > memory cd-hit is allowed to use and the required amount of memory also > depends on the amount of cores. This machine has 160 cores. I wonder if > the value for -M needs to be calculated instead of hard coded or that > you should limit the maximum amount of cores used or... But I leave it > up to you to find the appropriate solution. Looking up the cd-hit(1) manual, it seems possible to disable the memory limit by specifying -M 0. At least it seems to do the expected thing on my end. I will adjust the autopkgtest accordingly, and maybe upload at some point after the bullseye release. Thank you for your analysis! Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
Bug#992067: ITP: powder-toy -- A free physics sandbox game
On Tue, Aug 10, 2021 at 3:27 PM clay stan wrote: > * Package name: powder-toy Some earlier related bugs: https://bugs.debian.org/673087 https://bugs.debian.org/671595 Some prior packaging: https://alioth-archive.debian.org/git/pkg-games/powder.git.tar.xz -- bye, pabs https://wiki.debian.org/PaulWise
Bug#992080: (no subject)
It may be obvious, but I forgot to mention that this is on Bullseye, up to date as of today (Aug 10th). This bug is likely related to #991552.
Bug#757882: pkgsel: [text frontend] No feedback right after selecting the software tasks
Control: reassign -1 cdebconf Control: done -1 0.255 Samuel Thibault, le lun. 11 août 2014 23:53:02 +0200, a ecrit: > Right after answering the "Software selection" tasksel question, one > does not get any feedback, so the user is wondering whether it's > installing anything. I fixed this within cdebconf, forcing progress feedback after questions. Samuel
Bug#992080: udiskie: "udiskie --appindicator" fails to start due to missing Typelib
Package: udiskie Version: 2.3.2-2 Severity: important Dear Maintainer, udiskie fails in sway (or any other situation that only supports SNI tray icons) due to missing Typelib: $ udiskie --appindicator Typelib for 'AppIndicator3 0.1' is not available. Possible causes include: - libappindicator is not installed - the typelib is provided by a separate package - it was built with introspection disabled Starting udiskie without appindicator icon. I suspect the solution is to move udiskie to ayatanaappindicator, and make it depend on gir1.2-ayatanaappindicator3-0.1. I haven't tried installing gir1.2-appindicator3-0.1 from sid, which I suspect might work. I will report back when I try that out. -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 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 Versions of packages udiskie depends on: ii python33.9.2-3 ii python3-distutils 3.9.2-1 ii python3-docopt 0.6.2-3 ii python3-gi 3.38.0-2 ii python3-pkg-resources 52.0.0-4 ii python3-yaml 5.3.1-5 ii udisks22.9.2-2 Versions of packages udiskie recommends: ii dunst [notification-daemon] 1.5.0-1 ii gir1.2-gtk-3.0 3.24.24-4 ii gir1.2-notify-0.70.7.9-3 ii gobject-introspection1.66.1-1+b1 ii notification-daemon 3.20.0-4 ii python3-keyutils 0.6-2+b4 udiskie suggests no packages. -- no debconf information
Bug#992079: salt-master should have write access to /etc/salt
Package: salt-master Version: 3002.6+dfsg1-4 Severity: Normal While the official packages run salt-master as root, the Debian packages run salt-master under the user "salt". I have written a plug-in for Salt that provides dynamically generated pillars for encryption keys, passwords, and other useful features (shameless plug: https://github.com/jdelic/dynamicsecrets). However, dynamicsecrets needs to save data to a permanent location in the form of a sqlite database. The default path for that is /etc/salt/dynamicsecrets.sqlite. Of the folders owned by the salt-master package, this is the logical choice since /var/cache/salt and /var/run/salt are ephemeral locations. Unfortunately on the Debian packages the "salt" user has no write access to /etc/salt. Salt's own documentation (https://docs.saltproject.io/en/latest/ref/configuration/nonroot.html) under "Running the Salt Master/Minion as an Unprivileged User" states """ In order to allow Salt to successfully run as a non-root user, ownership, and permissions need to be set such that the desired user can read from and write to the following directories (and their subdirectories, where applicable): /etc/salt /var/cache/salt /var/log/salt /var/run/salt """ Unfortunately there is no way to fix this from within dynamicsecrets as the "salt" user doesn't have write access to any location amenable to long-term storage. So I would ask the package to be updated to change the owner of /etc/salt to be owned by the "salt" user.
Bug#627653: Please don't use obsolete libsysfs-dev any more
Hi! On Mon, 2011-05-23 at 09:44:04 +0200, Martin Pitt wrote: > Package: edac-utils > Version: 0.16-1 > User: mp...@debian.org > Usertags: libsysfs-deprecation > Some years ago libsysfs (source package: sysfsutils) was written as an > abstraction layer for accessing /sys/. However, this turned out to be > a historical error and evolutionary dead end: It does not actually > abstract anything (it's just as specific to the Linux kernel and a > particular version thereof as /sys itself), and just adds unnecessary > complexity, RAM overhead, and bugs. Thus its development has ceased > years ago, in favor of programs just using /sys as it is. I have to disagree with the above. It abstracts the access to /sys in a more natural form than directly having to do so. Development is also still going, and upstream has recently released a new version merging all Debian patches plus other cleanup and fixes sent by me and others. > In fact, most applications probably don't want to access /sys at all, > but use libudev [1] or gudev [2] instead. These provide a better API > for device enumeration, properties, and callbacks for hardware > changes. If this project would be better suited with some other library, then sure go ahead, but please take into account that as the current sysfsutils maintainer in Debian, I consider the library supported and definitely not obsolete, so if you'd like you keep using it, please feel free to do so (and to close this report :). > This package is one of the few which still use the old libsysfs. Can > you please check with upstream to prepare a migration away from > libsysfs to using plain /sys or libudev? I hope that we can drop the > old libsysfs entirely for wheezy. I have no plans for this. On Tue, 2012-05-22 at 08:57:36 -0700, Mark A. Grondona wrote: > It is on the TODO list to remove the dependency on libsysfs going > forward. It is just a matter of time. Edac-utils has gotten very little > development time over the past few years. > > Going forward there is a push to rearchitect edac core[1] and so I think > when that makes it upstream, there should be a complete rewrite of > edac-utils or a replacement of something providing similar functionality > (command line tool and library for monitoring tools) > > So does it still make sense to do the work of removing libsysfs from > edac-utils, or should we work on a new utility? See above, if you think another library would suit the project better, then sure, otherwise please feel free to keep relying on the libsysfs library. Thanks, Guillem
Bug#627649: Please don't use obsolete libsysfs-dev any more
Hi! On Mon, 2011-05-23 at 09:44:21 +0200, Martin Pitt wrote: > Package: cpufreqd > Version: 2.4.2-1 > User: mp...@debian.org > Usertags: libsysfs-deprecation > Some years ago libsysfs (source package: sysfsutils) was written as an > abstraction layer for accessing /sys/. However, this turned out to be > a historical error and evolutionary dead end: It does not actually > abstract anything (it's just as specific to the Linux kernel and a > particular version thereof as /sys itself), and just adds unnecessary > complexity, RAM overhead, and bugs. Thus its development has ceased > years ago, in favor of programs just using /sys as it is. I have to disagree with the above. It abstracts the access to /sys in a more natural form than directly having to do so. Development is also still going, and upstream has recently released a new version merging all Debian patches plus other cleanup and fixes sent by me and others. > In fact, most applications probably don't want to access /sys at all, > but use libudev [1] or gudev [2] instead. These provide a better API > for device enumeration, properties, and callbacks for hardware > changes. If this project would be better suited with some other library, then sure go ahead, but please take into account that as the current sysfsutils maintainer in Debian, I consider the library supported and definitely not obsolete, so if you'd like you keep using it, please feel free to do so (and to close this report :). > This package is one of the few which still use the old libsysfs. Can > you please check with upstream to prepare a migration away from > libsysfs to using plain /sys or libudev? I hope that we can drop the > old libsysfs entirely for wheezy. I have no plans for this. Thanks, Guillem
Bug#627647: Please don't use obsolete libsysfs-dev any more
Hi! On Mon, 2011-05-23 at 09:43:23 +0200, Martin Pitt wrote: > Package: openhpi > Version: 2.14.1-1 > User: mp...@debian.org > Usertags: libsysfs-deprecation > Some years ago libsysfs (source package: sysfsutils) was written as an > abstraction layer for accessing /sys/. However, this turned out to be > a historical error and evolutionary dead end: It does not actually > abstract anything (it's just as specific to the Linux kernel and a > particular version thereof as /sys itself), and just adds unnecessary > complexity, RAM overhead, and bugs. Thus its development has ceased > years ago, in favor of programs just using /sys as it is. I have to disagree with the above. It abstracts the access to /sys in a more natural form than directly having to do so. Development is also still going, and upstream has recently released a new version merging all Debian patches plus other cleanup and fixes sent by me and others. > In fact, most applications probably don't want to access /sys at all, > but use libudev [1] or gudev [2] instead. These provide a better API > for device enumeration, properties, and callbacks for hardware > changes. If this project would be better suited with some other library, then sure go ahead, but please take into account that as the current sysfsutils maintainer in Debian, I consider the library supported and definitely not obsolete, so if you'd like you keep using it, please feel free to do so (and to close this report :). > This package is one of the few which still use the old libsysfs. Can > you please check with upstream to prepare a migration away from > libsysfs to using plain /sys or libudev? I hope that we can drop the > old libsysfs entirely for wheezy. I have no plans for this. Thanks, Guillem
Bug#992078: bullseye-pu: package libbluray/1:1.2.1-4+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: sramac...@debian.org [ Reason ] The BDJ features of libbluray are currently broken due to an incompatibility with libasm-java from bullseye. This issue was reported as #991991 and is easily fixed by reverting to using the embedded copy of libasm. [ Impact ] Users will be unable to play Blurays with BDJ. [ Tests ] None, as I don't own a Bluray with BDJ. [ Risks ] None, as far as I can tell. libbluray-bdj is known to work with the embedded copy of libasm. [ 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 bullseye [ ] the issue is verified as fixed in unstable The issue is currently fixed in experimental and the fix will be available in unstable once bullseye is released. [ Changes ] Besides changing gbp's branch, the new version unapplies a Debian-specific patch and removes libasm-java from Build-Depends. Depends is automatically handled by javahelper. Cheers -- Sebastian Ramacher diff --git a/debian/changelog b/debian/changelog index 6ea2b74..40e3021 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +libbluray (1:1.2.1-4+deb11u1) bullseye; urgency=medium + + * debian/gbp.conf: Switch to bullseye branch + * debian/: Switch to embedded libasm. The version from libasm-java is too +new. (Closes: #991991) + + -- Sebastian Ramacher Sun, 08 Aug 2021 23:27:53 +0200 + libbluray (1:1.2.1-4) unstable; urgency=medium * debian/patches: diff --git a/debian/control b/debian/control index 11142ed..1a885ba 100644 --- a/debian/control +++ b/debian/control @@ -18,8 +18,7 @@ Build-Depends-Indep: ant, doxygen, graphviz, - javahelper, - libasm-java + javahelper Standards-Version: 4.5.1 Homepage: http://www.videolan.org/developers/libbluray.html Vcs-Git: https://salsa.debian.org/multimedia-team/libbluray.git diff --git a/debian/gbp.conf b/debian/gbp.conf index 4f24002..e0f993f 100644 --- a/debian/gbp.conf +++ b/debian/gbp.conf @@ -1,3 +1,4 @@ [DEFAULT] pristine-tar = True compression = bzip2 +debian-branch = bullseye diff --git a/debian/patches/0002-Use-system-asm-instead-of-embedded-copy.patch b/debian/patches/0002-Use-system-asm-instead-of-embedded-copy.patch deleted file mode 100644 index 54ad932..000 --- a/debian/patches/0002-Use-system-asm-instead-of-embedded-copy.patch +++ /dev/null @@ -1,45 +0,0 @@ -From: Sebastian Ramacher -Date: Wed, 14 Jun 2017 20:22:27 +0200 -Subject: Use system asm instead of embedded copy - - src/libbluray/bdj/build.xml | 14 -- - 1 file changed, 8 insertions(+), 6 deletions(-) - -diff --git a/src/libbluray/bdj/build.xml b/src/libbluray/bdj/build.xml -index 1753779..19163d1 100644 a/src/libbluray/bdj/build.xml -+++ b/src/libbluray/bdj/build.xml -@@ -21,17 +21,15 @@ - - -- -- -- -- - - - -+ -+ -+ -+ - - - - - -+ -+ -+ -+ - - - diff --git a/debian/patches/series b/debian/patches/series index 89954be..16342b0 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,3 +1,2 @@ 0001-Do-not-download-image-from-the-web.patch -0002-Use-system-asm-instead-of-embedded-copy.patch 0003-Update-check-for-new-libudfread-pkg-config-file-name.patch signature.asc Description: PGP signature
Bug#992027: ITP: openqa-client -- Python API to access openQA server
Sudip Mukherjee writes: > Package: wnpp > Severity: wishlist > Owner: Sudip Mukherjee > X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com, > Philip Hands > > * Package name: openqa-client > Version : 4.1.2 > * URL : https://github.com/os-autoinst/openQA-python-client > * License : GPL-2.0 > Programming Lang: Python > Description : Python API to access openQA server > > This is a client for the openQA API, based on requests. > The API always returns JSON responses; this client's > request functions parse the response before returning it. > > There is already another RFP for openqa server and the client, > #840253 and I think Philip Hands is already working on that and > has made a great job at openqa.debian.net. This package is only > the python api to communicate with the openqa server. I do use > it as part of my role in https://openqa.qa.codethink.co.uk/. > > Added Cc to Philip Hands also and if he is planning to add Python API > as part of his implementation then I can close this and wait for him. At present my packaging of openqa (which I hope to get into a state fit to upload very soon -- a few lintian warnings need addressing) already produces a package called openqa-client, which includes the scripts such as openqa-cli and openqa-client. BTW You can see the current state of play here: https://salsa.debian.org/philh/openqa The openqa-client script is obsolescent, so renaming that package to be openqa-cli would make sense anyway, since that is the script to use these days, but I think calling what seems to be a python library simply 'openqa-client' would be a bit confusing. Wouldn't it make sense to put a 'python' in the package name? I'm not really a python programmer, so probably not the person to package this, but would be pleased to see it available in Debian, and am very happy help where I can. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#856060: Please don't use obsolete libsysfs-dev any more
Hi! On Sun, 2017-04-09 at 10:17:41 +0200, Philipp Kern wrote: > On 02/24/2017 11:05 PM, Michael Biebl wrote: > > Some years ago libsysfs (source package: sysfsutils) was written as an > > abstraction layer for accessing /sys/. However, this turned out to be > > a historical error and evolutionary dead end: It does not actually > > abstract anything (it's just as specific to the Linux kernel and a > > particular version thereof as /sys itself), and just adds unnecessary > > complexity, RAM overhead, and bugs. Thus its development has ceased > > years ago, in favor of programs just using /sys as it is. Upstream development for sysfsutils is still going, they have f.ex. merged all patches Debian was carrying, plus several cleanup patch series I've sent, and have done new upstream releases. As the current maintainer in Debian I do not consider it obsolete, and would encourage anyone to use it, in preference of having to manually parse stuff from /sys. > > In fact, most applications probably don't want to access /sys at all, > > but use libudev [1] or gudev [2] instead. These provide a better API > > for device enumeration, properties, and callbacks for hardware > > changes. > > I can see how we ended up here, but it still does abstract something > away: access to sysfs, avoiding bugs in accessing it from C in the process. Indeed. So from my side, if you'd like to switch to something else, for whatever reason, that's fine, but if you'd rather keep using libsysfs, then that should also be fine. Thanks, Guillem
Bug#905793:
Please check your email and reply to my previous email thanks.
Bug#970836: kino: diff for NMU version 1.3.4+dfsg0-1.1
Control: tags 970836 + pending Dear maintainer, I've prepared an NMU for kino (versioned as 1.3.4+dfsg0-1.1) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. Cheers -- Sebastian Ramacher diff -Nru kino-1.3.4+dfsg0/debian/changelog kino-1.3.4+dfsg0/debian/changelog --- kino-1.3.4+dfsg0/debian/changelog 2018-09-03 23:26:57.0 +0200 +++ kino-1.3.4+dfsg0/debian/changelog 2021-08-10 22:44:49.0 +0200 @@ -1,3 +1,10 @@ +kino (1.3.4+dfsg0-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/control: Switch to libdc1394-dev (Closes: #970836) + + -- Sebastian Ramacher Tue, 10 Aug 2021 22:44:49 +0200 + kino (1.3.4+dfsg0-1) unstable; urgency=medium * Acknowledge non-maintainer uploads, thanks to Reinhard Tartler, Andreas diff -Nru kino-1.3.4+dfsg0/debian/control kino-1.3.4+dfsg0/debian/control --- kino-1.3.4+dfsg0/debian/control 2018-09-03 23:26:57.0 +0200 +++ kino-1.3.4+dfsg0/debian/control 2021-08-10 22:44:05.0 +0200 @@ -29,7 +29,7 @@ libgsm1-dev, intltool, libiec61883-dev, - libdc1394-22-dev, + libdc1394-dev, libvorbis-dev, libgl1-mesa-dev | libgl-dev, libswscale-dev, signature.asc Description: PGP signature
Bug#990340: glances: contains prebuilt javascript without source
Control: tag -1 + patch On Tue, 29 Jun 2021 01:44:06 +0530 Pirate Praveen wrote: > It uses webpack to build. > > https://github.com/nicolargo/glances/blob/develop/glances/outputs/static/package.json#L28 > > cd glances/outputs/static && webpack > > in debian/rules with required build dependencies added should work. Most > build dependencies are already packaged. > -- > Sent from my p≡p for Android. Most (non-dev) dependencies are not in Debian [0] (like angular) so I've made a MR [1] that simply remove pre-built files. This makes the remote web interface probably useless, but the package can still be used for most usages (I guess, in standalone mode for example, which is the only mode I use). [1] npm2deb output on package.json (modified to add required "name" key): Dependencies: NPM Debian glances-web-ui (FIX_ME version) None ├─ angular (^1.7.9) None ├─ angular-hotkeys (^1.7.0) None ├─ bootstrap (^3.4.1) None ├─ favico.js (^0.3.10)None └─ lodash (^4.17.15) node-lodash (4.17.21+dfsg+~cs8.31.189.20210220-1) Build dependencies: NPM Debian clean-webpack-plugin (^0.1.19)None copy-webpack-plugin (^4.6.0) node-copy-webpack-plugin (5.1.2+~cs9.0.2-4) css-loader (^0.28.11) node-css-loader (5.0.1+~cs14.0.5-2) del (^2.2.1) node-del (5.1.0-2) exports-loader (^0.7.0) node-exports-loader (1.1.1-2) file-loader (^1.1.11) node-file-loader (6.2.0-2) html-loader (^0.5.5) None less (^3.10.3)less.js (3.13.0+dfsg-5) less-loader (^4.1.0) node-less-loader (5.0.1-2) ngtemplate-loader (^2.0.1)None node-sass (^4.14.0) node-node-sass (4.14.1+git20200512.e1fc158+dfsg-4) sass-loader (^6.0.7) None style-loader (^0.20.3)node-style-loader (2.0.0-2) url-loader (^0.6.2) node-url-loader (4.1.1-3) webpack (^3.12.0) node-webpack (5.6.0+~cs6.4.0-1~exp2) [0] https://salsa.debian.org/debian/glances/-/merge_requests/2 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F| signature.asc Description: OpenPGP digital signature
Bug#992077: [INTL:sv] Swedish strings for iperf3 debconf
package: iperf3 severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother http://sis.bthstudent.se # Translation of iperf3 debconf template to Swedish # Copyright (C) 2021 Martin Bagge # This file is distributed under the same license as the iperf3 package. # # Martin Bagge , 2021 msgid "" msgstr "" "Project-Id-Version: iperf3\n" "Report-Msgid-Bugs-To: ipe...@packages.debian.org\n" "POT-Creation-Date: 2021-06-27 19:24+0200\n" "PO-Revision-Date: 2021-08-10 21:13+0200\n" "Last-Translator: Martin Bagge \n" "Language-Team: Swedish \n" "Language: sv\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../templates:1001 msgid "Start Iperf3 as a daemon automatically?" msgstr "Ska Iperf3 starta som en tjänst automatiskt?" #. Type: boolean #. Description #: ../templates:1001 msgid "" "Choose this option if Iperf3 should start automatically as a daemon, now and " "at boot time." msgstr "" "Ange detta alternativ om tjänsten iperf3 ska starta automatiskt vid " "systemets start."
Bug#984397: caused by DWARF5
Control: block -1 by 984397 This is caused by gcc-11 emitting DWARF5 debug info by default, and valgrind not understanding it yet. I can hack this away, but it's much better to fix the cause not a symptom. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Bug#992075: gitlab: download button for 2fa recovery codes does not work (coping works)
Package: gitlab Version: 13.12.9+ds1-2 Severity: important The same feature works fine on gitlab.com so this looks something specific to the native package.
Bug#992074: libvpd: FTBFS with GCC 11
source: libvpd Version: 2.2.7-1 Severity: normal Tags: sid bookworm User: debian-...@lists.debian.org Usertags: ftbfs-gcc-11 Forwarded: https://github.com/power-ras/libvpd/pull/5 [This bug is not targeted to the upcoming bullseye release] Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can be built in a follow-up test rebuild. The package fails to build in a test rebuild on at least amd64 with gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The severity of this report will be raised before the bookworm release, so nothing has to be done for the bullseye release. To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t=experimental install g++ Common build failures are new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-11/porting_to.html GCC 11 defaults to the GNU++17 standard. If your package installs header files in /usr/include, please don't work around C++17 issues by choosing a lower C++ standard for the package build, but fix these issues to build with the C++17 standard. I've copied what I hope is the relevant part of the log below: libtool: compile: g++ -DHAVE_CONFIG_H -I. -I./config -I./src/ -Wall -fstack-protector-all -Wstack-protector -Wdate-time -D_FORTIFY_SOURCE=2 -DDEST_DIR=\"/usr\" -g -O3 -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -c src/logger.cpp -fPIE -o src/logger.o >/dev/null 2>&1 In file included from src/vpdretriever.cpp:25: ./src/libvpd-2/vpdretriever.hpp:62:33: error: ISO C++17 does not allow dynamic exception specifications 62 | throw( VpdException& ); | ^ ./src/libvpd-2/vpdretriever.hpp:74:33: error: ISO C++17 does not allow dynamic exception specifications 74 | throw( VpdException& ); | ^ src/vpdretriever.cpp:50:37: error: ISO C++17 does not allow dynamic exception specifications 50 | string dbFileName ) throw( VpdException& ) | ^ src/vpdretriever.cpp:62:39: error: ISO C++17 does not allow dynamic exception specifications 62 | VpdRetriever::VpdRetriever( ) throw( VpdException& ) | ^ make[1]: *** [Makefile:671: src/vpdretriever.lo] Error 1 make[1]: *** Waiting for unfinished jobs
Bug#991478: [shim-signed] RFE: do not brick users' systems in the stable distribution
Hi, On Sun, 25 Jul 2021 16:52:27 +0100 Steve McIntyre wrote: > When we found that problem, as an immediate workaround I released a > newer shim-signed package into the buster-updates repo which solves > it: version 1.36~1+deb10u2+15.4-5~deb10u1 (note the > deb10u1->deb10u2). I can see that your system is showing > buster-updates in its list of package sources, so I'm very confused as > to what's happened there and why your system did not pick up the later > version. Argh! I learned yesterday that people that use APT pinning or APT::Default-Release may be missing out -updates if they pin to buster only. See the latest entry to the release notes [1, last paragraph] to cover the issue for bullseye-security. I'm obviously not sure if that happened here, but if the issue is the same on ci.d.n infrastructure, it would explain the failure there (the logs from yesterday there mention "Setting up shim-signed:arm64 (1.36~1+deb10u1+15.4-5~deb10u1)". Paul [1] https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive OpenPGP_signature Description: OpenPGP digital signature
Bug#984363: therion: ftbfs with GCC-11
On Wed, 03 Mar 2021 16:17:55 + Matthias Klose wrote: > Package: src:therion > Version: 5.5.7ds1-1 > Severity: normal > Tags: sid bookworm > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-11 > The package fails to build in a test rebuild on at least amd64 with > gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The > severity of this report will be raised before the bookworm release, > so nothing has to be done for the bullseye release. > > The full build log can be found at: > http://people.debian.org/~doko/logs/20210228/filtered/gcc11/therion_5.5.7ds1-1_unstable_gcc11.log This is actually an issue caused by libvtk9-dev, as noted here: https://gitlab.kitware.com/vtk/vtk/-/issues/18194 Martin
Bug#992073: shim-signed: restore arm64 support
Package: shim-signed Version: 1.38+15.4-7 Severity: normal X-Debbugs-CC: debian...@lists.debian.org Hi, Thanks for you work on shim-signed. I have read both the package changelog and the NEWS file, and I understand the reason for dropping the signed shim support for arm64. I'm opening this bug to have a user-visible tracking of this issue. Quoting NEWS for the benefit of others find this bug: shim-signed (1.34) unstable; urgency=medium Debian no longer supports UEFI Secure Boot on arm64 systems Shim and other EFI programs have always been difficult to build on arm64, compared to x86 platforms. Binutils for amd64 and i386 includes explicit support for creating programs in the PE/COFF binary format that EFI uses, but this has never been added for arm64. In the past, shim developers added some local hacks into the shim package to generate a *mostly*-compliant PE/COFF EFI binary without this toolchain support, and that seemed to be sufficient for use. Everything seemed to work. *However*, during the development and testing phase of shim 15.3 and 15.4, we found significant issues with this approach. New security features needed in shim (SBAT) showed up severe problems with the lack of proper toolchain support. See https://github.com/rhboot/shim/issues/366 for more details. The old hacks around binutils are no longer sustainable. Statistics tell us that very few people have attempted to use arm64 Secure Boot with Debian so far. In the interests of releasing needed updates in a timely manner, we have decided *for the time being* to disable signed shim support for Debian arm64. We hope to re-introduce arm64 Secure Boot support as soon as possible in the future. As a data point, the Huawei cloud infra where ci.debian.net runs arm64 workers (for arm*) does use Secure Boot on arm64, and applying security updates broke our machines there. signature.asc Description: PGP signature
Bug#992072: ITP: click-help-colors -- color messages in click
Package: wnpp Severity: wishlist Owner: Sakirnth Nagarasa * Package name: click-help-colors Upstream Author : None * URL : https://github.com/r-m-n/click-help-colors * License : MIT Description : color help messages in click Colorization of help messages in Click. To improve the readability of the help messages. Greetings Sakirnth
Bug#992071: ITP: click-completion -- fish bash zsh and powershell completion for click
Package: wnpp Severity: wishlist Owner: Sakirnth Nagarasa * Package name: click-completion Upstream Author : Gaëtan Lehmann * URL : https://github.com/click-contrib/click-completion * License : MIT Description : fish bash zsh and powershell completion for click Automatic completion support for different type of shells for Click. All the supported shells are able to complete all the command line arguments and options defined with click. Greetings Sakirnth
Bug#992070: keystone: CVE-2021-38155: Account name and UUID oracles in account locking
Source: keystone Version: 2:18.0.0-3 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for keystone. CVE-2021-38155[0]: | OpenStack Keystone 10.x through 16.x before 16.0.2, 17.x before | 17.0.1, 18.x before 18.0.1, and 19.x before 19.0.1 allows information | disclosure during account locking (related to PCI DSS features). By | guessing the name of an account and failing to authenticate multiple | times, any unauthenticated actor could both confirm the account exists | and obtain that account's corresponding UUID, which might be leveraged | for other unrelated attacks. All deployments enabling | security_compliance.lockout_failure_attempts are affected. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-38155 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38155 [1] https://www.openwall.com/lists/oss-security/2021/08/10/5 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#992034: init choice in Debian installation instructions
Hi, as the content for the release notes was suggested to be put into the Wiki (instead?) anyway, how about, to lower translator burden, there *will* be put a section about this into the installation guide, but one that is mostly comprised of a link to the Wiki, with a short intro. @Matthew: that’s most certainly an em dash there; normally, you render an em dash as U+2014 surrounded by U+200A (hair space) on both sides (some US-american publishers seem to omit the hair spaces; in Tₑχ/LᴬTᴇΧ I personally realise them as ⅙em which may be slightly wider than the hair spaces of some publishers but find this makes it easier to read). Now I have no idea how this is best done in the sources for the Debian installation guide… bye, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
Bug#992069: libvkd3d-doc is not installable besides libvkd3d-dev
Package: libvkd3d-doc Version: 1.2-5 Severity: important Dear Maintainer, sudo apt install libvkd3d-doc Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: libvkd3d-doc 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/788 kB of archives. After this operation, 2154 kB of additional disk space will be used. (Reading database ... 365748 files and directories currently installed.) Preparing to unpack .../libvkd3d-doc_1.2-5_all.deb ... Unpacking libvkd3d-doc (1.2-5) ... dpkg: error processing archive /var/cache/apt/archives/libvkd3d-doc_1.2-5_all.deb (--unpack): trying to overwrite '/usr/share/doc/libvkd3d-dev/ANNOUNCE.gz', which is also in package libvkd3d-dev:i386 1.2-5 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libvkd3d-doc_1.2-5_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#992068: libhdf5-mpich-dev: please bump libmpich-dev dependency to (>= 3.3-3~)
Package: libhdf5-mpich-dev
Version: 1.10.6+repack-4
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts
During an piuparts upgrade test of libhdf5-mpich-dev on the upgrade path
squeeze -> wheezy -> jessie -> stretch -> buster -> bullseye
I observed this failure:
Setting up libhdf5-mpich-dev (1.10.6+repack-4) ...
update-alternatives: priority must be an integer
Use 'update-alternatives --help' for program usage information.
dpkg: error processing package libhdf5-mpich-dev (--configure):
installed libhdf5-mpich-dev package post-installation script subprocess
returned error exit status 2
At the time of the failure the libmpich1.0-dev package which
Provides: libmpich-dev
was still installed, but that uses an ancient mpi alternative scheme
the postinst cannot parse.
Making the libmpich-dev versioned (buster shipped with 3.3-3 which uses
the new alternatives scheme) ensures that libmpich-dev gets upgraded
(or rather installed, kicking out the ancient libmpich1.0-dev from
squeeze).
This fix needs to get backported to bullseye-pu.
This needs an update of mpich as well, since there is an unhandled
file conflict between libmpich1.0-dev and mpich, #992065.
I've verified that using the two updated packages fixes the problematic
upgrade path.
Andreas
PS: it took me quite some time to understand what was going on here
so the fix wasn't ready before the bullseye deadline.
diff -Nru hdf5-1.10.6+repack/debian/changelog
hdf5-1.10.6+repack/debian/changelog
--- hdf5-1.10.6+repack/debian/changelog 2021-06-16 23:57:23.0 +0200
+++ hdf5-1.10.6+repack/debian/changelog 2021-08-10 16:54:23.0 +0200
@@ -1,3 +1,10 @@
+hdf5 (1.10.6+repack-5) UNRELEASED; urgency=medium
+
+ * libhdf5-mpich-dev: Bump libmpich-dev dependency to (>= 3.3-3~) to ensure
+the postinst is able to parse the mpi alternative. (Closes: #-1)
+
+ -- Andreas Beckmann Tue, 10 Aug 2021 16:54:23 +0200
+
hdf5 (1.10.6+repack-4) unstable; urgency=medium
* Revert support for read-only S3 virtual file driver, as it introduced
diff -Nru hdf5-1.10.6+repack/debian/control hdf5-1.10.6+repack/debian/control
--- hdf5-1.10.6+repack/debian/control 2021-06-16 23:57:23.0 +0200
+++ hdf5-1.10.6+repack/debian/control 2021-08-10 16:54:23.0 +0200
@@ -480,7 +480,7 @@
zlib1g-dev,
libaec-dev,
libjpeg-dev,
- libmpich-dev,
+ libmpich-dev (>= 3.3-3~),
${misc:Depends}
Suggests: libhdf5-doc
Breaks: libhdf5-mpi-dev (= 1.10.6+repack-1~exp4)
diff -Nru hdf5-1.10.6+repack/debian/control.in
hdf5-1.10.6+repack/debian/control.in
--- hdf5-1.10.6+repack/debian/control.in2021-06-16 23:57:23.0
+0200
+++ hdf5-1.10.6+repack/debian/control.in2021-08-10 16:54:23.0
+0200
@@ -480,7 +480,7 @@
zlib1g-dev,
libaec-dev,
libjpeg-dev,
- libmpich-dev,
+ libmpich-dev (>= 3.3-3~),
${misc:Depends}
Suggests: libhdf5-doc
Breaks: libhdf5-mpi-dev (= 1.10.6+repack-1~exp4)
libhdf5-mpich-dev_1.10.6+repack-4.log.gz
Description: application/gzip
Bug#992067: ITP: powder-toy -- A free physics sandbox game
Package: wnpp Severity: wishlist Owner: clay stan X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: powder-toy Version : 96.1.349 Upstream Author : The-Powder-Toy * URL : https://github.com/The-Powder-Toy/The-Powder-Toy License : GPL-3.0
Bug#992066: libvkd3d-headers: Package doesn't contain header files
Package: libvkd3d-headers Version: 1.2-5 Severity: important Dear Maintainer, The libvkd3d-headers package does not contain any header files (for example, vkd3d.h). $ apt policy libvkd3d-headers libvkd3d-headers: Installed: 1.2-5 Candidate: 1.2-5 Version table: *** 1.2-5 100 1 http://ftp.nl.debian.org/debian experimental/main amd64 Packages 1 http://ftp.nl.debian.org/debian experimental/main i386 Packages 100 /var/lib/dpkg/status $ dpkg-query -L libvkd3d-headers /. /usr /usr/share /usr/share/doc /usr/share/doc/libvkd3d-headers /usr/share/doc/libvkd3d-headers/ANNOUNCE.gz /usr/share/doc/libvkd3d-headers/AUTHORS /usr/share/doc/libvkd3d-headers/README /usr/share/doc/libvkd3d-headers/changelog.Debian.gz /usr/share/doc/libvkd3d-headers/copyright -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled libvkd3d-headers depends on no packages. Versions of packages libvkd3d-headers recommends: ii libvkd3d-dev 1.2-5 libvkd3d-headers suggests no packages.
Bug#837093: edk2: Please build an EFI shell package
Source: edk2 Followup-For: Bug #837093 Control: tags -1 + patch Dear Maintainer, Please find a patch here https://salsa.debian.org/qemu-team/edk2/-/merge_requests/3 Note that I have just posted a mail to debian-devel requesting an arch triplet. BTW I think we should compile the dynamic command initrd. Documentation is left in your side shell-basic is pretty basic and does not include network neither dump/write disk shell is the full package Please apply Bastien
Bug#983960: abiword: ftbfs with GCC-11
Package: abiword
Version: 3.0.4~dfsg-3
Followup-For: Bug #983960
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com
Control: tags -1 patch
Hi Jonas,
C++17 does not allow dynamic exception specifications anymore, therefore we need
to remove/replace the relevant throw() statements, as done upstream in 2017:
https://github.com/AbiWord/abiword/commit/ef29fc9
I'm not sure why this commit isn't part of the 3.0.4 release – from 2019 –
already...
In Ubuntu, the attached (upstream) patch was applied cleanly to make it build
again.
Thanks for considering the patch.
-- System Information:
Debian Release: bullseye/sid
APT prefers hirsute-updates
APT policy: (500, 'hirsute-updates'), (500, 'hirsute-security'), (500,
'hirsute'), (100, 'hirsute-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.11.0-25-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru
abiword-3.0.4~dfsg/debian/patches/0014-Remove-deprecated-throw-specifiers.patch
abiword-3.0.4~dfsg/debian/patches/0014-Remove-deprecated-throw-specifiers.patch
---
abiword-3.0.4~dfsg/debian/patches/0014-Remove-deprecated-throw-specifiers.patch
1970-01-01 01:00:00.0 +0100
+++
abiword-3.0.4~dfsg/debian/patches/0014-Remove-deprecated-throw-specifiers.patch
2021-08-10 16:25:27.0 +0200
@@ -0,0 +1,849 @@
+From: Hubert Figuiere
+Date: Wed, 22 Nov 2017 06:01:56 +
+Subject: Remove deprecated throw specifiers
+
+git-svn-id: svn+ssh://svn.abisource.com/svnroot/abiword/trunk@35445
bcba8976-2d24-0410-9c9c-aab3bd5fdfd6
+---
+ plugins/aiksaurus/aiksaurusgtk3/AiksaurusGTK.cpp | 34 ++---
+ plugins/aiksaurus/aiksaurusgtk3/DialogMediator.h | 8 ++---
+ plugins/aiksaurus/aiksaurusgtk3/Display.cpp | 28 -
+ plugins/aiksaurus/aiksaurusgtk3/Display.h| 28 -
+ plugins/aiksaurus/aiksaurusgtk3/Meaning.cpp | 12
+ plugins/aiksaurus/aiksaurusgtk3/Meaning.h| 10 +++
+ plugins/aiksaurus/aiksaurusgtk3/Toolbar.cpp | 32 ++--
+ plugins/aiksaurus/aiksaurusgtk3/Toolbar.h| 34 ++---
+ plugins/sdw/xp/docinfo.cpp | 4 +--
+ plugins/sdw/xp/docinfo.h | 2 +-
+ plugins/sdw/xp/ie_imp_StarOffice.cpp | 12
+ plugins/sdw/xp/ie_imp_StarOffice.h | 38
+ src/af/util/xp/ut_iconv.cpp | 2 +-
+ src/af/util/xp/ut_iconv.h| 3 +-
+ 14 files changed, 123 insertions(+), 124 deletions(-)
+
+diff --git a/plugins/aiksaurus/aiksaurusgtk3/AiksaurusGTK.cpp
b/plugins/aiksaurus/aiksaurusgtk3/AiksaurusGTK.cpp
+index 61cd640..15f2721 100644
+--- a/plugins/aiksaurus/aiksaurusgtk3/AiksaurusGTK.cpp
b/plugins/aiksaurus/aiksaurusgtk3/AiksaurusGTK.cpp
+@@ -51,15 +51,15 @@ namespace AiksaurusGTK_impl
+ DialogImpl();
+ virtual ~DialogImpl();
+
+-const char* runThesaurus(const char* word) throw();
+-void setTitle(const char* title) throw();
+-void setReplacebar(bool replacebar) throw();
+-void setInitialMessage(const char* message) throw(std::bad_alloc);
+-
+-void eventCancel() throw();
+-void eventReplace(const char* replacement) throw();
+-void eventSelectWord(const char* word) throw();
+-void eventSearch(const char* word) throw();
++const char* runThesaurus(const char* word) noexcept(false);
++void setTitle(const char* title) noexcept(false);
++void setReplacebar(bool replacebar) noexcept(false);
++void setInitialMessage(const char* message) noexcept(false);
++
++void eventCancel() noexcept(false);
++void eventReplace(const char* replacement) noexcept(false);
++void eventSelectWord(const char* word) noexcept(false);
++void eventSearch(const char* word) noexcept(false);
+ };
+
+
+@@ -78,13 +78,13 @@ namespace AiksaurusGTK_impl
+ }
+
+
+-void DialogImpl::setReplacebar(bool replacebar) throw()
++void DialogImpl::setReplacebar(bool replacebar) noexcept(false)
+ {
+ d_showreplacebar = replacebar;
+ }
+
+
+-void DialogImpl::setInitialMessage(const char* message)
throw(std::bad_alloc)
++void DialogImpl::setInitialMessage(const char* message) noexcept(false)
+ {
+ d_initialMessage = message;
+ }
+@@ -149,7 +149,7 @@ namespace AiksaurusGTK_impl
+ }
+
+
+-const char* DialogImpl::runThesaurus(const char* word) throw()
++const char* DialogImpl::runThesaurus(const char* word) noexcept(false)
+ {
Bug#992065: mpich: libhdf5-mpich-dev upgrade problems if libmpich1.0-dev is still installed
Package: mpich Version: 3.4.1-4 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: affects -1 + libhdf5-mpich-dev During an piuparts upgrade test of libhdf5-mpich-dev on the upgrade path squeeze -> wheezy -> jessie -> stretch -> buster -> bullseye I observed this failure: Setting up libhdf5-mpich-dev (1.10.6+repack-4) ... update-alternatives: priority must be an integer Use 'update-alternatives --help' for program usage information. dpkg: error processing package libhdf5-mpich-dev (--configure): installed libhdf5-mpich-dev package post-installation script subprocess returned error exit status 2 mpi alternative setting after the failure (after upgrade squeeze...bullseye): # update-alternatives --query mpi Name: mpi Link: /usr/include/mpi Slaves: libmpi++.a /usr/lib/libmpi++.a libmpi++.so /usr/lib/libmpi++.so libmpi.a /usr/lib/libmpi.a libmpi.so /usr/lib/libmpi.so mpiCC /usr/bin/mpiCC mpiCC.1.gz /usr/share/man/man1/mpiCC.1.gz mpicc /usr/bin/mpicc mpicc.1.gz /usr/share/man/man1/mpicc.1.gz mpicxx /usr/bin/mpicxx mpicxx.1.gz /usr/share/man/man1/mpicxx.1.gz mpif77 /usr/bin/mpif77 mpif77.1.gz /usr/share/man/man1/mpif77.1.gz mpif90 /usr/bin/mpif90 mpif90.1.gz /usr/share/man/man1/mpif90.1.gz mpireconfig /usr/bin/mpireconfig mpireconfig.1.gz /usr/share/man/man1/mpireconfig.1.gz Status: auto Best: /usr/lib/mpich/include Value: /usr/lib/mpich/include Alternative: /usr/lib/mpich/include Priority: 10 Slaves: libmpi++.a /usr/lib/mpich/lib/libpmpich++.a libmpi++.so /usr/lib/mpich/lib/shared/libpmpich++.so libmpi.a /usr/lib/mpich/lib/libmpich.a libmpi.so /usr/lib/mpich/lib/shared/libmpich.so mpiCC /usr/bin/mpiCC.mpich mpiCC.1.gz /usr/share/man/man1/mpiCC.mpich.1.gz mpicc /usr/bin/mpicc.mpich mpicc.1.gz /usr/share/man/man1/mpicc.mpich.1.gz mpicxx /usr/bin/mpicxx.mpich mpicxx.1.gz /usr/share/man/man1/mpicxx.mpich.1.gz mpif77 /usr/bin/mpif77.mpich mpif77.1.gz /usr/share/man/man1/mpif77.mpich.1.gz mpif90 /usr/bin/mpif90.mpich mpif90.1.gz /usr/share/man/man1/mpif90.mpich.1.gz mpireconfig /usr/bin/mpireconfig.mpich mpireconfig.1.gz /usr/share/man/man1/mpireconfig.mpich.1.gz and after fresh installation in bullseye: # update-alternatives --query mpi Name: mpi Link: /usr/bin/mpicc Slaves: hdf5-mpi.pc /usr/lib/x86_64-linux-gnu/pkgconfig/hdf5-mpi.pc mpiCC /usr/bin/mpiCC mpic++ /usr/bin/mpic++ mpicxx /usr/bin/mpicxx mpif77 /usr/bin/mpif77 mpif90 /usr/bin/mpif90 mpifort /usr/bin/mpifort Status: auto Best: /usr/bin/mpicc.mpich Value: /usr/bin/mpicc.mpich Alternative: /usr/bin/mpicc.mpich Priority: 40 Slaves: hdf5-mpi.pc /usr/lib/x86_64-linux-gnu/pkgconfig/hdf5-mpich.pc mpiCC /usr/bin/mpicxx.mpich mpic++ /usr/bin/mpicxx.mpich mpicxx /usr/bin/mpicxx.mpich mpif77 /usr/bin/mpifort.mpich mpif90 /usr/bin/mpifort.mpich mpifort /usr/bin/mpifort.mpich OK, that is still an ancient mpi alternative at the time libhdf5-mpich-dev.postinst runs ... Probably caused by libmpich1.0-dev providing libmpich-dev and therefore no newer libmpich-dev getting installed. Trying to add some Breaks/Replaces ... tests running ... BTW, installing libmpich-dev in the failure state causes Selecting previously unselected package mpich. Preparing to unpack .../31-mpich_3.4.1-4_amd64.deb ... Unpacking mpich (3.4.1-4) ... dpkg: error processing archive /tmp/apt-dpkg-install-S2t7dN/31-mpich_3.4.1-4_amd64.deb (--unpack): trying to overwrite '/usr/bin/mpicc.mpich', which is also in package libmpich1.0-dev 1.2.7-9.1 Andreas libhdf5-mpich-dev_1.10.6+repack-4.log.gz Description: application/gzip
Bug#992064: greylistd should not recommend installation of exim4
Package: greylistd Version: 0.9.0 Severity: Normal The greylistd package currently recommends exim4. I wrote a filter for OpenSMTPD that uses greylistd for providing greylisting services (shameless plug: https://github.com/jdelic/opensmtpd-filter-greylistd/). With the current package, if the user tries to install greylistd without --no-install-recommends, apt will happily uninstall OpenSMTPD to install exim4. This is not ideal from a user-experience point of view. I think the best solution is for greylistd to merely _suggest_ exim4. If we want to keep the recommendation, an alternative solution would be to recommend the "mail-transport-agent" meta package. This way OpenSMTPD would also fulfill the recommendation. What do y'all think?
Bug#992063: bullseye-pu: package fetchmail/6.4.16-4+deb11u1
Package: release.debian.org
User: release.debian@packages.debian.org
Tags: bullseye
Severity: normal
Hi RMs,
Asking for a fetchmail package update, fixing a regression in its last
security fix. This is a one liner, moving down an 'endif'.
The reason is, partial_message_size_used was double incremented and
messages got truncated (the size limit reached much sooner). Updated
package is already in Sid, I would like to get it for Bullseye too.
Debdiff is attached.
Thanks for consideration,
Laszlo/GCS
diff -Nru fetchmail-6.4.16/debian/changelog fetchmail-6.4.16/debian/changelog
--- fetchmail-6.4.16/debian/changelog 2021-07-29 00:18:56.0 +0200
+++ fetchmail-6.4.16/debian/changelog 2021-08-09 20:06:48.0 +0200
@@ -1,3 +1,10 @@
+fetchmail (6.4.16-4+deb11u1) bullseye; urgency=medium
+
+ * Backport upstream regression fix for 6.4.20's security (CVE-2021-36386)
+fix.
+
+ -- Laszlo Boszormenyi (GCS) Mon, 09 Aug 2021 20:06:48 +0200
+
fetchmail (6.4.16-4) unstable; urgency=high
* Backport upstream security fix for CVE-2021-36386: denial of service or
diff -Nru fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch
--- fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch 1970-01-01 01:00:00.0 +0100
+++ fetchmail-6.4.16/debian/patches/12_fix_logfile_and_message_truncation_issue.patch 2021-08-09 20:06:48.0 +0200
@@ -0,0 +1,76 @@
+From d3db2da1d13bd2419370ad96defb92eecb17064c Mon Sep 17 00:00:00 2001
+From: Matthias Andree
+Date: Mon, 9 Aug 2021 17:42:29 +0200
+Subject: [PATCH] Fix --logfile and message truncation issue.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Regression in 6.4.20's security fix (Git commit c546c829).
+
+We doubly incremented partial_message_size_used on modern systems
+(stdard.h/vsnprintf), once in report_vbuild() and then again in
+report_build(), so the 2nd and subsequent report_build() fragments
+landed too late in the buffer. This will not cause overruns due to the
+reallocation prior to the vsnprintf/sprintf, but it write starts behind
+the '\0' byte, instead of right over it, so the string also gets
+truncated to the first fragment written with report_vbuild().
+
+Fix by moving the increment back into the #else...#endif part that does
+not use report_vbuild().
+
+Reported by: Jürgen Edner, Erik Christiansen
+---
+ NEWS | 18 ++
+ report.c | 3 ++-
+ 2 files changed, 20 insertions(+), 1 deletion(-)
+
+diff --git a/NEWS b/NEWS
+index 0cd3f968..b98f15d2 100644
+--- a/NEWS
b/NEWS
+@@ -64,6 +64,24 @@ removed from a 6.5.0 or newer release.)
+ for end-of-life OpenSSL versions may be removed even from patchlevel releases.
+
+
++fetchmail-6.4.21 (released 2021-08-09, 30042 LoC):
++
++# REGRESSION FIX:
++* The new security fix in 6.4.20 for CVE-2021-36386 caused truncation of
++ messages logged to buffered outputs, predominantly --logfile.
++
++ This also caused lines in the logfile to run into one another because
++ the fragment containing the '\n' line-end character was usually lost.
++
++ Reason is that on all modern systems (with header and vsnprintf()
++ interface), the length of log message fragments was added up twice, so
++ that these ended too deep into a freshly allocated buffer, after the '\0'
++ byte. Unbuffered outputs flushed the fragments right away, which masked the
++ bug.
++
++ Reported by: Jürgen Edner, Erik Christiansen.
++
++
+ fetchmail-6.4.20 (not yet released):
+
+ # SECURITY FIX:
+diff --git a/report.c b/report.c
+index aea6b3ea..2db7d0a9 100644
+--- a/report.c
b/report.c
+@@ -286,10 +286,11 @@ report_build (FILE *errfp, message, va_alist)
+ n = snprintf (partial_message + partial_message_size_used,
+ partial_message_size - partial_message_size_used,
+ message, a1, a2, a3, a4, a5, a6, a7, a8);
+-#endif
+
+ if (n > 0) partial_message_size_used += n;
+
++#endif
++
+ if (unbuffered && partial_message_size_used != 0)
+ {
+ partial_message_size_used = 0;
+--
+GitLab
+
diff -Nru fetchmail-6.4.16/debian/patches/series fetchmail-6.4.16/debian/patches/series
--- fetchmail-6.4.16/debian/patches/series 2021-07-29 00:18:56.0 +0200
+++ fetchmail-6.4.16/debian/patches/series 2021-08-09 20:06:48.0 +0200
@@ -5,3 +5,4 @@
09_fix_memory_leak_in_timeout_situation.patch
10_update_manpage.patch
11_fix_CVE-2021-38386.patch
+12_fix_logfile_and_message_truncation_issue.patch
Bug#992002: [PATCH][Debian#992002] tbl: allow two-character fonts and format fonts in -Thtml
Hi Nab,
Nab wrote on Tue, Aug 10, 2021 at 01:08:31AM +0200:
> On Mon, Aug 09, 2021 at 10:58:19AM +0200, Ingo Schwarze wrote:
>> Nab wrote on Sun, Aug 08, 2021 at 03:24:53PM +0200:
>>> tbl's -Thtml ignores font requests;
>> Not in CVS HEAD; see https://cvsweb.bsd.lv/mandoc/tbl_html.c revision 1.34,
>> committed on May 16 earlier this year.
> Oh, indeed. I tested and based my patch on 1.14.5 from Debian,
> didn't realise that's almost two years old by now.
> Will use the CVS next time.
Note that so far, everybody who contributed code to mandoc provided
their first and last names. I'm not sure it is strictly required in
the legal sense, but i do consider it beneficial both for authors
and for users. The benefit for authors is that it makes it easier
for them to exercise their rights under the Berne Convention, in
particular their moral rights under that Convention, for example
to protect themselves if somebody abuses their contribution for
slander. The benefit for users of knowing who the Copyright holders
are is also obvious, even if the code is BSD or ISC licensed:
It makes Copyright and license audits easier and reduces the risk
of suddenly being sued by parties the users didn't even know existed.
In this case, it isn't needed because by mere chance, even though
several of your ideas remained in the committed patch, none of your
code did, because i switched from TBL_CELL_BOLD and TBL_CELL_ITALIC
to ESCAPE_FONT*. Ideas aren't subject to Copyright, only text is,
and for crediting a person who provided bug reports, feature requests,
and ideas, a pseudonym is sufficient.
>>> text
>>> text
>>> text
>> These become:
>> text
>> text
> This is great news! A bunch of my pages use C[BI] and the HTML renders
> look much better, thanks!
Note that i don't recommend using these fonts in manual pages.
Even with groff, typical installations don't prodide CB and CI
fonts for terminal output, which typically results in warnings
being thrown. The details may vary among operating systems and
package managers even for the same version of groff. Portability
to other formatters (like Heirloom, Plan 9, DWB, Solaris, neatroff)
is even more doubtful, but i don't know any details about that.
But as a rule, mandoc(1) even supports features if using them is
unwise, as long as that doesn't cause an undue burden. One reason
to do so is making existing pages look better, no matter how good
or bad the style is that they are using. Not supporting a feature
hurts end users - who aren't responsible for author's choices which
features to use. But that a feature is supported by mandoc(1)
should not be misinterpreted by authors as a free pass to go on a
rampage and employ the most arcane and brittle features they manage
to find.
>> * GNU tbl(1) appears to ignore space characters between the f
>>modifier and the font name, so "lf B" is the same as "lfB".
> Huh, so it does! That's not explicitly mentioned by the manual and so
> I didn't think to test it.
No, i'm not even convinced it is intentional, and relying on it in
any document would be a thoroughly bad idea. But mandoc(1) aims to
be bug-compatible with groff unless there is a good reason to differ.
> Now, tbl(1) says
> Key characters can be separated by spaces or tabs.
> so consider the following document:
> -- >8 --
> .TS
> lfBI lf BI lf BI .
> a b c
> .TE
> -- >8 --
> (In order, none, space, tab follow 'f';
> base64: LlRTCmxmQkkJbGYgQkkJbGYJQkkJLgphCWIJYwouVEUK)
>
> groff renders it with a, b, and c as BI,
> but mandoc with your patch with a+b as BI and c as R, with -Tlint:
> mandoc: ./q.1:2:14: WARNING: unknown font, \
> skipping request: TS f BI .
>
> If you change tbl_layout.c L171 to match L75:
> -- >8 --
> - while (p[*pos] == ' ')
> + while (p[*pos] == ' ' || p[*pos] == '\t')
> -- >8 --
> and L187:
> -- >8 --
> - if (strchr(" .", p[*pos + isz]) == NULL)
> + if (strchr(" \t.", p[*pos + isz]) == NULL)
> -- >8 --
> The document renders correctly.
Done in the commit cited below, thanks for pointing out that quirk.
>> Could you please check out from CVS (instead of the last release),
>> apply the following patch, and tell me whether it looks reasonable
>> and works for you?
> Yeah, save for the tab thing above, I haven't managed to fault it,
> in tests or real pages.
Thank you very much for testing. That patch ended up growing
tentacles into quite a number of files, so the additional testing
is highly appreciated.
Here is the committed patch:
https://inbox.vuxu.org/mandoc-source/c2aa6365c21bf...@mandoc.bsd.lv/
Yours,
Ingo
Bug#992051: security archive layout change needs more configuration changes
Paul Gevers wrote: > Do you agree with the attached patch? Yes, looks good to me! -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#608121: Helo
Pershendetje Ju lutemi kontrolloni mesazhin tim të hershëm dhe kthehuni tek unë, ju lutem. Faleminderit. të fala. Elimond Emeh Greeting Kindly check my early message and get back to me please. Thanks. regards. Elimond Eme
Bug#992051: security archive layout change needs more configuration changes
Hi Justin, all, On 10-08-2021 14:29, Justin B Rye wrote: > (I'm assuming APT::Default-Release users will be aware they're doing > it, presumably because they've got sources defined for more than one > release and need to specify which one is "primary") I'm assuming the same. > Do we need to mention fnmatch patterns (AKA globs) when the example > doesn't use them? I guess not. We don't need to write APT's documentation here. Do you agree with the attached patch? Paul From ff677aa0be71b9a27d4d6d343f9ed1b14bcc086f Mon Sep 17 00:00:00 2001 From: Paul Gevers Date: Tue, 10 Aug 2021 13:03:30 +0200 Subject: [PATCH] issues.dbk: security archive requires update to pinning and Default-Release Closes: #992051 --- en/issues.dbk | 11 +++ 1 file changed, 11 insertions(+) diff --git a/en/issues.dbk b/en/issues.dbk index 1fbba7a3..d3321953 100644 --- a/en/issues.dbk +++ b/en/issues.dbk @@ -81,6 +81,17 @@ The security line in your APT configuration may look like: deb https://deb.debian.org/debian-security bullseye-security main contrib + +If your APT configuration also involves pinning or +APT::Default-Release, it is likely to +require adjustments as the codename of the security archive no +longer matches that of the regular archive. An example of a +working APT::Default-Release line for +bullseye looks like: +APT::Default-Release "/^bullseye(|-security|-upgrades)$/"; +which takes advantage of the undocumented feature of APT that +it supports regular expressions (inside /). + -- 2.30.2 OpenPGP_signature Description: OpenPGP digital signature
Bug#991982: nano does not work with TERM unset
Le mardi 10 août 2021, 08:05:00 UTC Benno Schulenberg a écrit : > Op 09-08-2021 om 15:08 schreef Bastien Roucariès: > > nano work with TERM=dumb (but is strange but it work), > > For me, 'TERM=dumb nano somefile' does not work, not on a console, not > on an xterm, not on Xfce Terminal -- it shows something, but is totally > unusable: the user cannot see what he or she is doing. What terminal > are you using? Yes but it run, it is unusable but it run. The problem is the behvior is not consistant. You have only two sane choice: 1 allow to run in every terminal. It is user choice and it could shot it own foot 2 filter the bad terminal and return with an unambigous error code because I could not initialize(like 156 faking could not execute due to library not here or even 155 is it is documented) You do not implement a consistant behavior. > > > so safer will be to > > consider as best effort TERM="" , TERM not set, equivalent to dumb. > > May I ask what the scenario is? How can it happen that TERM is unset? > What disaster can leave TERM unset? When the user starts a shell with > 'env -i' and does not know how to get out? > > I think it is okay when nano works around an unset TERM, simply because > nano /needs/ a terminal. But if TERM is set to anything that is invalid > (even the empty string), then the user is responsible and they should get > what they asked for -- that is: a non-functioning nano. No posix said about vi that the behavior for empty term should be consistant and documented. If nano want to be a vi replacement it should be consistant. You could implement 2 (fine) but please be consistant refuse dumb, vt52 and other impossible terminal with error code that say nano could not initialize (thus allowing to test if they are an error during reading/writting a file and nano could not run, please try another editor) Bastien > > Benno signature.asc Description: This is a digitally signed message part.
Bug#992008: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require
2021, ഓഗസ്റ്റ് 10 5:44:35 PM IST, Pirate Praveen ൽ എഴുതി > > >2021, ഓഗസ്റ്റ് 10 12:44:39 PM IST, "László Böszörményi (GCS)" >ൽ എഴുതി >>Control: tags -1 +pending >> >>Hi Pirate, >> >>On Mon, Aug 9, 2021 at 8:51 PM Pirate Praveen >>wrote: >>> Can you upload this change? Or if you are okay with this change, I can >>> upload it as well. Once this is fixed, I can switch back to the >>> packaged version (currently using gem install google-protobuf as work >>> around). >> Sure, I can. Will do it soon. Thanks. >>> I had seen this bug earlier >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989774 but I thought >>> it was something similar/related to >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966653 (between, this >>> bug also seems to be fixed with newer protobuf/grpc versions in >>> experimental). >> You know, my question is, how and why it was and still working for >>3.12.4 but nor for 3.17.3? One change that I can think of is adding noruby build profile between these two versions. >>Regards, >>Laszlo/GCS -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#992051: security archive layout change needs more configuration changes
Paul Gevers wrote: > The security line in your APT configuration may look like: > deb https://deb.debian.org/debian-security > bullseye-security main contrib > > + > + If APT is configured using APT pinning or > + APT::Default-Release, "Configured using" is a bit unclear; I think you mean If your APT configuration also involves pinning or APT::Default-Release, (I'm assuming APT::Default-Release users will be aware they're doing it, presumably because they've got sources defined for more than one release and need to specify which one is "primary") >the configuration > + most likely need updating as the codename of the security "is likely to need updating", or: it is likely to require adjustments as the codename of the security > + archive no longer matches that of the regular archive. An > + example of a working APT::Default-Release > + line for bullseye looks: line for bullseye looks like: > + APT::Default-Release > "/^bullseye(|-security|-upgrades)$/"; > + which takes advantage of the undocumented feature of APT that > + it supports POSIX fnmatch patterns and regular expressions > + (inside /). > + Do we need to mention fnmatch patterns (AKA globs) when the example doesn't use them? Even if we do, we should make it clearer that "inside /" only means regexps: it supports regular expressions (inside /) as well as glob patterns. (Or should "glob" be in quotes, or s?) -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#991811: unblock: libapache2-mod-auth-openidc/2.4.9-1
Dear Security Team, the fixed version is now in bullseye. Thanks for that. What is the plan for buster and stretch? Do you prepare fixes? Greetings Christoph Am 06.08.21 um 11:46 schrieb Christoph Martin: > Hi Paul, > hi Salvatore, > > Am 06.08.21 um 09:32 schrieb Salvatore Bonaccorso: >>> >>> It's *very* late in the freeze so I need an answer *real soon*. You >>> didn't tell us how you tested the package, how upstream tested the >>> changes and how you *judge* the changes between bullseye and sid. I >>> can't estimate the risk by myself. >> >> From security team perspective, we could tend to confirm to be good >> option to actually go to 2.4.9 based version, if Christoph can confirm >> the above questions on testing. Was it tested in production >> environment as well? >> > > I have tested it in a production environment. > The package installs correctly on a bullseye system. > Upgrade of the package also works. > Login via our idp ist working as expected. > All expected env variables in phpinfo have the expected values. > > Regards > > Christoph > OpenPGP_signature Description: OpenPGP digital signature
Bug#992053: c-ares: diff for NMU version 1.17.1-1.1
Hello, Thank you for handling this issue so quickly. I'm travelling for the next week and won't be able to work on anything Debian related. If you feel comfortable, you could also upload the fixed package without any delay. Thanks, Gregor
Bug#991997: new upstream (0.31)
Hi, On 2021-08-08 10:32, Daniel Baumann wrote: Package: nwipe Hi Martijn, thank you so much for nwipe. Given the isaac issue, it would be nice if you could upload nwipe 0.31 anytime soon to Debian (experimental) and consider a bugfix for bullseye. Thanks! Will try too upload a new version soon and consider what else would be possible. Kind regards, Martijn
Bug#992051: security archive layout change needs more configuration changes
Control: tags -1 patch Hi all, On 10-08-2021 07:55, Paul Gevers wrote: > Yesterday I noticed that the layout change of the security impacts more > than just the apt *sources* as my system wasn't updating perl, > libencode-perl and exiv2. I already enabled the new security archive > layout a long time ago (and apt will complain when the sources are not > found). I discussed the issue on IRC on #d-release with juliank (apt > upstream). What users *need* to be aware of is that apt pinning (pabs > told me) and APT::Default-Release (found myself) may need adjustments > too, otherwise security updates are not installed. > > I'm working on text for the release notes, but I fear a lot of users > will not be reading those and when they upgrade their secure buster > systems and only fix their apt sources, depending on how they configure > their system to follow bullseye, they may easily miss out on security > updates. Please find attached my proposal, ready to push. Paul From 3e106d7ef0412530a0a9643032edb7bd4b453d74 Mon Sep 17 00:00:00 2001 From: Paul Gevers Date: Tue, 10 Aug 2021 13:03:30 +0200 Subject: [PATCH] issues.dbk: security archive requires update to pinning and Default-Release Closes: #992051 --- en/issues.dbk | 12 1 file changed, 12 insertions(+) diff --git a/en/issues.dbk b/en/issues.dbk index 1fbba7a3..e0d5fb11 100644 --- a/en/issues.dbk +++ b/en/issues.dbk @@ -81,6 +81,18 @@ The security line in your APT configuration may look like: deb https://deb.debian.org/debian-security bullseye-security main contrib + + If APT is configured using APT pinning or + APT::Default-Release, the configuration + most likely need updating as the codename of the security + archive no longer matches that of the regular archive. An + example of a working APT::Default-Release + line for bullseye looks: + APT::Default-Release "/^bullseye(|-security|-upgrades)$/"; + which takes advantage of the undocumented feature of APT that + it supports POSIX fnmatch patterns and regular expressions + (inside /). + -- 2.30.2 OpenPGP_signature Description: OpenPGP digital signature
Bug#992062: ITP: libxcvt -- VESA CVT standard timing modelines generator
Package: wnpp Severity: wishlist Owner: Timo Aaltonen X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libxcvt Version : 0.1.0 Upstream Author : X.Org * URL : https://gitlab.freedesktop.org/xorg/lib/libxcvt * License : MIT, NTP Programming Lang: C Description : libxcvt libxcvt is a library providing a standalone version of the X server implementation of the VESA CVT standard timing modelines generator. This used to be part of xorg-server, and got split off as a shared library so that other projects can use it.
Bug#992060: pytsk: please make the build reproducible
forwarded 992060 https://github.com/py4n6/pytsk/pull/81 thanks I've forwarded this upstream here: https://github.com/py4n6/pytsk/pull/81 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#992061: surgescript: please make the build reproducible
Source: surgescript Version: 0.5.4.4-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0] we noticed that surgescript could not be built reproducibly. This is because CMake's RPATH is not stripped, needing us to avoid it being set with -DCMAKE_SKIP_RPATH=ON. Patch attached. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2021-08-10 11:44:23.417015261 +0100 --- b/debian/rules 2021-08-10 11:47:44.882173416 +0100 @@ -15,7 +15,8 @@ override_dh_auto_configure: dh_auto_configure -- \ - -DLIB_SUFFIX=/$(DEB_HOST_MULTIARCH) + -DLIB_SUFFIX=/$(DEB_HOST_MULTIARCH) \ + -DCMAKE_SKIP_RPATH=ON override_dh_compress: dh_compress -X.ss
Bug#992060: pytsk: please make the build reproducible
Source: pytsk
Version: 20200117-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0] we noticed that
pytsk could not be built reproducibly.
This is because it generated a pytsk3.c file in a nondeterministic
manner, specifically by naively iterating over a Python set()
structure.
Patch attached.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/0002-Reproducible-build.patch 1970-01-01
01:00:00.0 +0100
--- b/debian/patches/0002-Reproducible-build.patch 2021-08-10
11:33:28.947652513 +0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2021-08-10
+
+--- pytsk-20200117.orig/class_parser.py
pytsk-20200117/class_parser.py
+@@ -914,7 +914,7 @@ uint64_t integer_object_copy_to_uint64(P
+ self.initialise_class(class_name, out, done)
+
+ # Add the constants in here
+-for constant, type in self.constants:
++for constant, type in sorted(self.constants):
+ if type == "integer":
+ out.write(
+ "tmp = PyLong_FromUnsignedLongLong((uint64_t)
{0:s});\n".format(constant))
--- a/debian/patches/series 2021-08-10 11:29:42.852085888 +0100
--- b/debian/patches/series 2021-08-10 11:33:28.139656520 +0100
@@ -1,2 +1,3 @@
0001-Link-system-tsk-statically-talloc-dynamically-instea.patch
change-lexer.patch
+0002-Reproducible-build.patch
Bug#992059: spatialindex: please make the build reproducible
Control: tags -1 pending Hi Chris, Thanks for the patch, it's applied in git and will be included in the next upload. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#992059: spatialindex: please make the build reproducible
Source: spatialindex Version: 1.9.3-2 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0] we noticed that spatialindex could not be built reproducibly. This is because CMake's RPATH is not stripped, needing us to avoid it being set with -DCMAKE_SKIP_RPATH=ON. Patch attached. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2021-08-10 10:48:25.404043494 +0100 --- b/debian/rules 2021-08-10 10:51:29.773864458 +0100 @@ -20,7 +20,7 @@ dh $@ --with pkgkde_symbolshelper override_dh_auto_configure: - dh_auto_configure -- -DSIDX_LIB_SUBDIR=lib/$(DEB_HOST_MULTIARCH) + dh_auto_configure -- -DSIDX_LIB_SUBDIR=lib/$(DEB_HOST_MULTIARCH) -DCMAKE_SKIP_RPATH=ON override_dh_install: $(RM) $(CURDIR)/debian/tmp/usr/lib/*/*.la
Bug#891083: remmina: Fails to save connection details
I Think this is not relevant anymore and can be closed
Bug#959395: remmina: Grab all keyboard events not working after upgrade
Do you still have the same problem with Remmina v1.4.20?
Bug#981153: cargo: Please package new upstream
On Wed, Jan 27, 2021 at 10:52:17AM +0900, Mike Hommey wrote: > Source: cargo > Version: 0.47.0-3 > Severity: wishlist > > Firefox now requires version 0.48, latest upstream is 0.50, and unstable > is on 0.47. Fwiw; with Cargo 0.51 the new resolver feature has been stablelized [0]. I'm starting to hit issues when building with various crates from the ecosystem as that's starting to be adopted now. 0: https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html#cargos-new-feature-resolver
Bug#970665: Doesn't save any preferences (not even within the session)
Hi Daniel, Do you still have the same problem with Remmina v1.4.20?
Bug#985353:
And again: Mon 2021-08-09 12:03:34 EEST 675300 1000 1000 11 present /usr/bin/evolution
Bug#992058: opensysusers: uses `eval` on data that is not supposed to be safe to eval
Package: opensysusers Version: 0.6-2 Severity: serious Tags: security upstream X-Debbugs-Cc: Debian Security Team opensysusers uses the shell's `eval` on everything in sysusers.d like there is no tomorrow. These files can contain shell meta-characters that should not result in code execution, e.g., in the GECOS field. +--- | # mkdir /etc/sysusers.d | # echo 'u test-user - "Do not $(rm /etc/bash.bashrc)" /var/lib/test-users /bin/sh' > /etc/sysusers.d/test.conf | # ls -l /etc/bash.bashrc | -rw-r--r-- 1 root root 1994 Jun 22 02:26 /etc/bash.bashrc | # systemd-sysusers # this is opensysusers | # ls -l /etc/bash* | ls: cannot access '/etc/bash*': No such file or directory +---[ opensysusers 0.6-2 ] systemd's systemd-sysuser behaves differently: +--- | # mkdir /etc/sysusers.d | # echo 'u test-user - "Do not $(rm /etc/bash.bashrc)" /var/lib/test-users /bin/sh' > /etc/sysusers.d/test.conf | # ls -l /etc/bash.bashrc | -rw-r--r-- 1 root root 1994 Jun 22 02:26 /etc/bash.bashrc | # systemd-sysusers | Creating group systemd-coredump with gid 999. | Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. | Creating group test-user with gid 998. | Creating user test-user (Do not $(rm /etc/bash.bashrc)) with uid 998 and gid 998. | # ls -l /etc/bash.bashrc | -rw-r--r-- 1 root root 1994 Jun 22 02:26 /etc/bash.bashrc | # getent passwd test-user | test-user:x:998:998:Do not $(rm /etc/bash.bashrc):/var/lib/test-users:/bin/sh +---[ systemd 247.3-6 ] As opensysusers is supposed to be a drop-in requirement for systemd-sysusers it *must* behave as systemd does and not execute data. Ansgar
Bug#991136: fetch-crl: Install fails on update-rc.d
Hi! The SysV init script should not be used on a system that is running systemd. It is there to be used on non-systemd Debian installations only (kfreebsd, hurd). If you have enabled this on a systemd based system, please disable it. On systemd based systems the proper way is to use the fetch-crl systemd timer unit. This is activated using: systemctl enable fetch-crl.timer systemctl start fetch-crl.timer There is also a fetch-crl systemd service unit. This is only intended to be run when the timer unit is triggered, and can not be enabled on its own - the unit files does not have an install section by design. The issue with missing certificates would better be addressed by updating the igtf-policy packages (if you are using them). Unfortunately, due to the freeze for the upcoming release, this package is not up to date in Debian and still contains references to an old discontinued CA that was removed from later upstream releases. If the discontinued CA (INFN-CA-2015) causes issued for you, you can reconfigure igtf-policy-classic to exclude it. See /usr/share/doc/igtf-policy-classic/README.Debian Let me know if this addresses your issues. Mattias Ellert tor 2021-07-15 klockan 13:22 +0200 skrev Carl-Fredrik Enell: > Package: fetch-crl > Version: 3.0.19-2 > Severity: important > > Dear Maintainer, > > > * I tried to uninstall and reinstall fetch-crl because of error > * messages regarding a non-existing certificate. > > * Packet configuration fails on update-rc.d: No default runlevel. > This is expected on a systemd based release as far as I can > understand. > init-system-helpers is installed. > > * I would expect fetch-crl to run from cron or a systemd timer, not > * to install anything in rcN.d. > > Best regards, > Carl-Fredrik Enell > > > -- System Information: > Debian Release: 10.10 > APT prefers stable > APT policy: (990, 'stable'), (500, 'stable-updates'), (500, > 'proposed-updates') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-0.bpo.7-amd64 (SMP w/64 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages fetch-crl depends on: > ii init-system-helpers 1.56+nmu1 > ii libwww-perl 6.36-2 > ii lsb-base 10.2019051400 > ii openssl 1.1.1d-0+deb10u6 > ii perl 5.28.1-6+deb10u1 > > fetch-crl recommends no packages. > > fetch-crl suggests no packages. > > -- no debconf information smime.p7s Description: S/MIME cryptographic signature
Bug#992038: systemd: regression with systemd-networkd + dropbear initramfs and kernel ip autoconfig(?)
Control: tags -1 + moreinfo Am 09.08.21 um 19:12 schrieb Michael Biebl: Am 09.08.21 um 18:03 schrieb Axel Scheepers: Package: systemd Version: 247.3-6 Severity: normal Dear Maintainer, * What led up to the situation? Testing bullseye rc-3 install on remote server. * What exactly did you do (or not do) that was effective (or ineffective)? I used encrypted root and dropbear initramfs to remote unlock, also setup systemd-networkd for both wireless and wired interfaces: How exactly do you configure your network in the initramfs? systemd-networkd does not ship any hooks for that. Aside from that: Could you also try with v249 from experimental if the problem is reproducible with this version. If it's not fixed there, it would be best to take it upstream and file a bug report at https://github.com/systemd/systemd/issues If it's fixed with v249, you could try git bisect to find the commit which fixes the issue. If it's not too invasive we might then consider backporting this for the first bullseye stable release. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#992056: htpdate: systemd service won't start because htpdate writes the wrong PID to the PID file
Package: htpdate Version: 1.2.2-4 Severity: normal X-Debbugs-Cc: deb-b...@larsluthman.net The systemd service that comes with this package won't start because htpdate writes the wrong PID to the PID file. The service is stuck 'activating' until it times out and kills the htpdate process. When I run the following command: systemctl start htpdate I get the following in the log: Aug 10 09:47:10 sirion systemd[1]: Starting HTTP based time synchronization tool... Aug 10 09:47:10 sirion htpdate[143803]: htpdate version 1.2.2 started Aug 10 09:47:10 sirion systemd[1]: htpdate.service: New main PID 12732 does not exist or is a zombie. Aug 10 09:48:40 sirion systemd[1]: htpdate.service: start operation timed out. Terminating. Aug 10 09:48:40 sirion systemd[1]: htpdate.service: Failed with result 'timeout'. Aug 10 09:48:40 sirion systemd[1]: Failed to start HTTP based time synchronization tool. To confirm that the wrong PID is written, I run the following commands in another terminal after 'systemctl start htpdate' and before it times out: $ cat /run/htpdate.pid 12732 $ systemctl status htpdate ● htpdate.service - HTTP based time synchronization tool Loaded: loaded (/lib/systemd/system/htpdate.service; enabled; vendor preset: enabled) Active: activating (start) since Tue 2021-08-10 09:47:10 CEST; 29s ago Docs: man:htpdate Process: 143799 ExecStart=/usr/sbin/htpdate $HTP_OPTIONS $HTP_PROXY -i /run/htpdate.pid $HTP_SERVERS Tasks: 1 (limit: 16609) Memory: 216.0K CPU: 21ms CGroup: /system.slice/htpdate.service └─143804 /usr/sbin/htpdate -D -s -i /run/htpdate.pid www.pool.ntp.org www.ntp.br www.wikipedia.org Aug 10 09:47:10 sirion systemd[1]: Starting HTTP based time synchronization tool... Aug 10 09:47:10 sirion htpdate[143803]: htpdate version 1.2.2 started Aug 10 09:47:10 sirion systemd[1]: htpdate.service: New main PID 12732 does not exist or is a zombie. This shows that a htpdate process is running, but it has PID 143804 rather than 12732 as reported in the PID file. Once the activation times out that process is killed and the PID file deleted. I can work around this by editing the service file and changing Type=forking PIDFile=/run/htpdate.pid to Type=oneshot RemainAfterExit=yes ExecStopPost=/usr/bin/rm -f /run/htpdate.pid This tells systemd to not track the PID, but just assume that htpdate is always running successfully until the service is stopped, and then delete the PID file so that htpdate won't object when it's started next time. This is obviously not ideal since any problems will be unreported. -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages htpdate depends on: ii init-system-helpers 1.60 ii libc62.31-13 ii lsb-base 11.1.0 htpdate recommends no packages. htpdate suggests no packages. -- no debconf information
Bug#991982: nano does not work with TERM unset
Op 09-08-2021 om 15:08 schreef Bastien Roucariès: > nano work with TERM=dumb (but is strange but it work), For me, 'TERM=dumb nano somefile' does not work, not on a console, not on an xterm, not on Xfce Terminal -- it shows something, but is totally unusable: the user cannot see what he or she is doing. What terminal are you using? > so safer will be to > consider as best effort TERM="" , TERM not set, equivalent to dumb. May I ask what the scenario is? How can it happen that TERM is unset? What disaster can leave TERM unset? When the user starts a shell with 'env -i' and does not know how to get out? I think it is okay when nano works around an unset TERM, simply because nano /needs/ a terminal. But if TERM is set to anything that is invalid (even the empty string), then the user is responsible and they should get what they asked for -- that is: a non-functioning nano. Benno OpenPGP_signature Description: OpenPGP digital signature
Bug#992055: edk2: Better naming of package
Source: edk2 Severity: minor Tags: patch Dear Maintainer, Please use consistant naming of your package and canonical arch name I have made a proposal using version provides to achieve this, but may be it should be a plain rename with version provides of the old name https://salsa.debian.org/qemu-team/edk2/-/merge_requests/2
Bug#992053: c-ares: diff for NMU version 1.17.1-1.1
Hi Gregor, On Tue, Aug 10, 2021 at 09:38:07AM +0200, Gregor Jasny wrote: > Hello, > > Thank you for handling this issue so quickly. I'm travelling for the next > week and won't be able to work on anything Debian related. > > If you feel comfortable, you could also upload the fixed package without > any delay. Thanks for your quick response. For DSA 4954-1 I pushed both buster-security (and the already operational bullseye-security packages, in preparation of next weekends release), so yes could do then as well the NMU for unstable directly! Thanks for acknowleging it. Regards, Salvatore
Bug#992008: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require
Control: tags -1 +pending Hi Pirate, On Mon, Aug 9, 2021 at 8:51 PM Pirate Praveen wrote: > Can you upload this change? Or if you are okay with this change, I can > upload it as well. Once this is fixed, I can switch back to the > packaged version (currently using gem install google-protobuf as work > around). Sure, I can. Will do it soon. > I had seen this bug earlier > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989774 but I thought > it was something similar/related to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966653 (between, this > bug also seems to be fixed with newer protobuf/grpc versions in > experimental). You know, my question is, how and why it was and still working for 3.12.4 but nor for 3.17.3? Regards, Laszlo/GCS
