Bug#1068999: FTBFS due to plantuml
reassign 1069353 plantuml severity 1068999 serious forcemerge 1068999 1069353 thanks Hello, In #1069353, the bug in #1068999 caused nncp to FTBFS in sid due to this same issue. nncp uses plantuml to build documentation as part of its build. The full build log is at http://qa-logs.debian.net/2024/04/20/nncp_8.10.0-8_unstable-arm64.log Thanks, John
Bug#1066780: Checking in on this bug
Hello, It would probably be good to update our package to 0.42.0, since it contains a fix for CVE-2024-22189. Perhaps that would also contain a fix for this? I don't know how hard this issue is to track down, but it will be leading to several packages being unpatched and removed from testing otherwise. Thanks! - John
Bug#1069104: maildir-utils: Version 1.12.4 is available upstream
Package: maildir-utils Version: 1.12.3-3~bpo12+1 Severity: wishlist Hello, and thanks for maintaining maildir-utils! Upstream has released 1.12.4 which fixes some bugs I have encountered. Thanks! - John -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages maildir-utils depends on: ii guile-3.0-libs 3.0.8-2 ii libc6 2.36-9+deb12u4 ii libcld2-0 0.0.0-git20150806-9 ii libgcc-s1 12.2.0-14 ii libglib2.0-02.74.6-2 ii libgmime-3.0-0 3.2.13+dfsg-2 ii libstdc++6 12.2.0-14 ii libxapian30 1.4.22-1 maildir-utils recommends no packages. maildir-utils suggests no packages. -- no debconf information
Bug#1067809: maildir-utils: New upstream version 1.12.2 is available
Package: maildir-utils Severity: wishlist Hi, A new upstream version is available. It would be nice to have it in Debian. Thanks! -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages maildir-utils depends on: ii guile-3.0-libs 3.0.8-2 ii libc6 2.36-9+deb12u4 ii libgcc-s1 12.2.0-14 ii libglib2.0-02.74.6-2 ii libgmime-3.0-0 3.2.13+dfsg-2 ii libstdc++6 12.2.0-14 ii libxapian30 1.4.22-1 maildir-utils recommends no packages. maildir-utils suggests no packages. -- no debconf information
Bug#1067717: emacs-common: Security issues with emacs; remote code execution in Gnus
Package: emacs-common Version: 1:28.2+1-15 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: Debian Security Team Hello, https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-29 describes some security issues addressed in emacs 29.3. Among them: ** Gnus now treats inline MIME contents as untrusted. To get back previous insecure behavior, 'untrusted-content' should be reset to nil in the buffer. ** LaTeX preview is now by default disabled for email attachments. To get back previous insecure behavior, set the variable 'org--latex-preview-when-risky' to a non-nil value. I don't see anything that would explicitly indicate if the version in stable, 1.28.2, is vulnerable but the nature of this leads me to think that it is. Thanks, John -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs-common depends on: ii emacs-el 1:28.2+1-15 ii emacsen-common 3.0.5 ii init-system-helpers 1.65.2 ii install-info 6.8-6+b1 emacs-common recommends no packages. Versions of packages emacs-common suggests: pn emacs-common-non-dfsg ii ncurses-term 6.4-4 -- no debconf information
Bug#1064945: grub-efi-amd64: Sudden boot failures on ZFS systems
Package: grub-efi-amd64 Version: 2.06-13+deb12u1 Severity: critical Tags: upstream patch Justification: breaks the whole system My system suddenly refused to start up grub. An error message flashed by, but too quickly for me to be able to see. Then I got the grub emergency prompt. Upon booting from a Debian live image to attempt to fix this, after chrooting into an appropriately-configured filesystem from the target (with bind-mount /proc, /sys, /dev, /boot/efi, etc), grub-install failed with: error: compression algorithm inherit not supported I'll note that "inherit" is not really a compression algorithm for ZFS. (root, and also boot, are part of ZFS on this system.) Upon researching this, I see that https://github.com/openzfs/zfs/issues/15261 discusses the problem. https://github.com/openzfs/zfs/issues/13873 does as well. https://github.com/openzfs/zfs/issues/13873#issuecomment-1905182760 suggests that it is the ZFS feature extensible_dataset that is responsible for this. That feature can get auto-enabled by other features at runtime. Both of these bugs indicate that grub 2.12 contains patches to fix the issue. Indeed, the four patches listed at https://git.savannah.gnu.org/cgit/grub.git/log/grub-core/fs/zfs/zfs.c pertaining to ZFS are thought to fix it. I have built a bookworm-backports version of grub 2.12 and it does indeed solve the problem. I think this issue justifies backporting those ZFS patches into the version in bookworm for stable-proposed-updates. Thanks! - John -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages grub-efi-amd64 depends on: ii debconf [debconf-2.0] 1.5.82 ii grub-common2.06-13+deb12u1 ii grub-efi-amd64-bin 2.06-13+deb12u1 ii grub2-common 2.06-13+deb12u1 ii ucf3.0043+nmu1 grub-efi-amd64 recommends no packages. grub-efi-amd64 suggests no packages. -- debconf information excluded
Bug#1062097: gensio: NMU diff for 64-bit time_t transition
On Fri, Feb 23 2024, Steve Langasek wrote: > [[PGP Signed Part:Undecided]] > Please find attached an updated patch for the latest gensio in unstable. Hi Steve, Thanks for your work on this! There was no attachment there, however. A question on this. Since the initial bug was filed on gensio, I updated the Debian package to a newer upstream. This changed the Debian library from libgensio4 to libgensio6. libgensio6 is in testing but has never been in stable. Is it still worth renaming libgensio6 given that it's never been in a stable release? Just thought I'd check on that. Thanks, John
Bug#1063497: zfs-dkms: Data loss bug in version in bookworm
Package: zfs-dkms Version: 2.1.11-1 Severity: critical Tags: patch upstream Justification: causes serious data loss Hello ZFS maintainers! Thank you for maintaining this for Debian. In the release notes for ZFS 2.1.14 at https://github.com/openzfs/zfs/releases/tag/zfs-2.1.14, it states: "This release contains an important fix for a data corruption bug. Full details are in the issue (#15526) and bug fix (#15571). There's also a developer's bug summary that gives a good overview... This bug is very hard to hit, and really only came to light due to changes in cp in coreutils 9.x. It's extremely unlikely that the bug was ever hit on EL7 or EL8 when running cp since they all use coreutils 8.x which performs file copies differently." I'll note that bookworm contains coreutils 9.x. Two options would exist to get this into stable-proposed-updates: 1) Backport the patch (linked to from the release notes) onto 2.1.14 (likely easy), or 2) Upgrade stable to 2.1.14. If you would like my assistance with either of these steps, I'm available to help. John -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zfs-dkms depends on: ii debconf [debconf-2.0] 1.5.82 ii dkms 3.0.10-8+deb12u1 ii file 1:5.44-3 ii libc6-dev [libc-dev] 2.36-9+deb12u4 ii libpython3-stdlib 3.11.2-1+b1 ii lsb-release12.0-1 ii perl 5.36.0-7+deb12u1 ii python3-distutils 3.11.2-3 Versions of packages zfs-dkms recommends: ii linux-libc-dev 6.5.10-1~bpo12+1 ii zfs-zed 2.2.2-4~bpo12+1 ii zfsutils-linux 2.2.2-4~bpo12+1 Versions of packages zfs-dkms suggests: ii debhelper 13.11.4 -- debconf information excluded
Bug#1062097: closed by Debian FTP Masters (reply to John Goerzen ) (Bug#1062097: fixed in gensio 2.8.2-4)
Hi Lukas and Michael, Thank you for your work on this large transition. I am confused. The gensio bug was reported with severity serious, against the version of gensio in unstable, which prevents transition to testing. I don't understand what action is being requested. If the bug cannot be fixed, it should not be filed (or not filed as serious). Additionally, there are other bugs impacting these packages and their symbol files, which I have addressed. They will create a conflict with the proposed NMU, so the NMU will need to be refreshed before being applied. Now the bug is reopened asking me to roll back the same patch that the bug was opened for. I could of course do that -- disentangling the conflicts -- and close the bug with the upload. But that would leave gensio without the t64 libraries -- the same state it was in when you reported the serious bug. So which is it: is there a serious bug with gensio in unstable with the t64 libraries, or without? It cannot be both. I don't think I've ever received a bug report, severity serious, tagged patch, found in the version in unstable, where applying the patch is somehow the wrong thing to do. Please clarify what action I could take that would close this bug. I may not be the only one confused here, and would be happy to have this conversation on debian-devel if that would be more broadly useful. - John On Mon, Feb 05 2024, Lukas Märdian wrote: > [[PGP Signed Part:Undecided]] > reopen 1062097 > > Dear John, > > please revert your latest upload to unstable. > The time_t NMU was targeted at experimental. > The dpkg in unstable does not yet set the compiler defaults to provide 64-bit > time_t; so packages built as part of this upload will now have the wrong ABI > in the reverse direction. > > -- Lukas > > On Mon, Feb 05, 2024 at 06:39:05AM +, Debian Bug Tracking System wrote: >> This is an automatic notification regarding your Bug report >> which was filed against the src:gensio package: >> >> #1062097: gensio: NMU diff for 64-bit time_t transition >> >> It has been closed by Debian FTP Masters >> (reply to John Goerzen ). >> >> Their explanation is attached below along with your original report. >> If this explanation is unsatisfactory and you have not received a >> better one in a separate message then please contact Debian FTP Masters >> (reply to John Goerzen >> ) by >> replying to this email. >> >> >> -- >> 1062097: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062097 >> Debian Bug Tracking System >> Contact ow...@bugs.debian.org with problems > >> Date: Mon, 05 Feb 2024 06:35:44 + >> From: Debian FTP Masters >> To: 1062097-cl...@bugs.debian.org >> Subject: Bug#1062097: fixed in gensio 2.8.2-4 >> >> Source: gensio >> Source-Version: 2.8.2-4 >> Done: John Goerzen >> >> We believe that the bug you reported is fixed in the latest version of >> gensio, which is due to be installed in the Debian FTP archive. >> >> A summary of the changes between this version and the previous one is >> attached. >> >> Thank you for reporting the bug, which will now be closed. If you >> have further comments please address them to 1062...@bugs.debian.org, >> and the maintainer will reopen the bug report if appropriate. >> >> Debian distribution maintenance software >> pp. >> John Goerzen (supplier of updated gensio package) >> >> (This message was generated automatically at their request; if you >> believe that there is a problem with it please contact the archive >> administrators by mailing ftpmas...@ftp-master.debian.org) >> >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> Format: 1.8 >> Date: Mon, 05 Feb 2024 00:18:56 -0600 >> Source: gensio >> Architecture: source >> Version: 2.8.2-4 >> Distribution: unstable >> Urgency: medium >> Maintainer: Marc Haber >> Changed-By: John Goerzen >> Closes: 1061614 1062097 >> Changes: >> gensio (2.8.2-4) unstable; urgency=medium >> . >>* Apply patch from Lukas Märdian to rename libraries for 64-bit time_t >> transition. Closes: #1062097. >>* Apply patch from Matthias Klose to mark symbols not seen building >> with -O3 as optional. Closes: #1061614. >> Checksums-Sha1: >> be5b49300127e98911ce9c48ada186f4261590a4 2251 gensio_2.8.2-4.dsc >> b074438a4c893499ad22bbaf08b8f5e325f74d5b 11868 gensio_2.8.2-4.debian.tar.xz >> 21b223330fb4412e2433fd579cd8efbd142b1ce9 8915 >> gensio_2.8.2-4_source.buildinfo >> Checksums-Sha256: >> a7c3214f8d71c44b8de526aa1ee93393468ac2e79b481a
Bug#1060418: ser2net 4.6.0 now available
Source: ser2net Version: 4.3.11-1 Severity: wishlist Dear Maintainer, Hi, ser2net 4.6.0 is now available at https://github.com/cminyard/ser2net/releases . It contains some bugfixes for things I've worked with upstream on, so it would be great to have it packaged. Thanks! -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-16-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1055314: RM: golang-github-bits-and-blooms-bloom -- ROM; Duplicates golang-github-willf-bloom
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Hello, I learned at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055134 that golang-github-bits-and-blooms-bloom duplicates functionality in an existing package. Please remove golang-github-bits-and-blooms-bloom. Thanks, John
Bug#1055134: ITP: golang-github-bits-and-blooms-bloom -- Go package implementing Bloom filters, used by Milvus and Beego.
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: golang-github-bits-and-blooms-bloom Version : 3.6.0-1 Upstream Author : Will Fitzgerald * URL : https://github.com/bits-and-blooms/bloom * License : BSD-2-clause Programming Lang: Go Description : Go package implementing Bloom filters, used by Milvus and Beego. Bloom filters . A Bloom filter is a concise/compressed representation of a set, where the main requirement is to make membership queries; *i.e.*, whether an item is a member of a set. A Bloom filter will always correctly report the presence of an element in the set when the element is indeed present. A Bloom filter can use much less storage than the original set, but it allows for some 'false positives': it may sometimes report that an element is in the set whereas it is not. . This is a Go library for a bloom filter. It is required by the latest Yggdrasil.
Bug#1053216: firefox-esr: changelog.Debian.gz missing important entries
Package: firefox-esr Version: 115.3.0esr-1~deb12u1 Severity: important Hello, After today's dist-upgrade on a bookworm machine, I had one update: firefox-esr. apt's output showed: Unpacking firefox-esr (115.3.0esr-1~deb12u1) over (102.15.1esr-1~deb12u1) ... Given the recent number of security issues present in various browsers, I wanted to see what vulnerabilities had already been addressed in 102.15.1esr-1~deb12u1, and which were new. However, there is no entry for any 102.15 version in debian/changelog at all. The bottom of the file references running apt changelog firefox-esr; even though the oldest entries in the changelog.Debian.gz were far older than 102.15, I tried it, but this resulted in an error. In short, the changelog.Debian.gz is missing entries for the firefox-esr version journey that most users of Debian stable will experience. Thanks! -- Addons package information -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox-esr depends on: ii debianutils 5.7-0.4 ii fontconfig 2.14.1-4 ii libasound2 1.2.8-1+b1 ii libatk1.0-0 2.46.0-5 ii libc62.36-9+deb12u1 ii libcairo-gobject21.16.0-7 ii libcairo21.16.0-7 ii libdbus-1-3 1.14.8-2~deb12u1 ii libdbus-glib-1-2 0.112-3 ii libevent-2.1-7 2.1.12-stable-8 ii libffi8 3.4.4-1 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgcc-s112.2.0-14 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libgtk-3-0 3.24.37-2 ii libnspr4 2:4.35-1 ii libnss3 2:3.87.1-1 ii libpango-1.0-0 1.50.12+ds-1 ii libstdc++6 12.2.0-14 ii libvpx7 1.12.0-1 ii libx11-6 2:1.8.4-2+deb12u1 ii libx11-xcb1 2:1.8.4-2+deb12u1 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxrandr2 2:1.5.2-2+b1 ii libxtst6 2:1.2.3-1.1 ii procps 2:4.0.2-3 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages firefox-esr recommends: ii libavcodec59 7:5.1.3-1 Versions of packages firefox-esr suggests: ii fonts-lmodern 2.005-1 pn fonts-stix | otf-stix ii libcanberra0 0.30-10 ii libgssapi-krb5-2 1.20.1-2 pn pulseaudio -- no debconf information
Bug#1051239: bookworm-pu: package dar/2.7.8-2
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@packages.debian.org
Control: affects -1 + src:dar
[ Reason ]
A bug was recently reported to Debian as #1050663, and subsequently to upstream.
This bug causes dar to create isolated catalog files that cannot be read by a
future dar invocation. The catalog files are used as the basis for backups, so
this breaks users' backup flows.
Upstream has not yet pinned down the cause for the issue; however, reports are
that it looks tied to gcc versions 12 or above. This version does exist in
bookworm.
A workaround patch has been developed that mitigates the problems on all tested
systems. I have already applied that patch to 2.7.12-1, which is uploaded to
unstable. The same patch applies to 2.7.8.
We are not yet certain of the trigger of the issue. It is possible that some
binary builds on some archs in bookworm are not impacted. However, for maximum
safety, this patch should be included.
[ Impact ]
While the initial full backup will be created fine, attempts to create future
incremental or differential backups could fail with a dar crash due to this
issue.
Reducing the impact of the issue: the issue only arises when --on-fly-isolate is
used. That is not the only way to create an isolated catalog, and isolated
catalogs are not used in every workflow. Also, the backups that dar does create
are fully intact. However, a script that doesn't check the exit status of dar
may believe a backup was successfully created when it was not.
[ Tests ]
There is no automated test suite over this part of the code. However, the patch
has been tested on the dar mailing list, including on Debian.
[ Risks ]
The patch is trivial. Detection of corrupted catalogs should be fairly
immediate as well.
[ 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 ]
This includes just the small patch to address the issue.
[ Other info ]
Please advise whether or not the upload to bookworm should be source-only.
diff -Nru dar-2.7.8/debian/changelog dar-2.7.8/debian/changelog
--- dar-2.7.8/debian/changelog 2022-12-04 08:57:33.0 -0600
+++ dar-2.7.8/debian/changelog 2023-09-04 15:07:26.0 -0500
@@ -1,3 +1,10 @@
+dar (2.7.8-2) bookworm; urgency=high
+
+ * Include a patch that can prevent issues with creating isolated catalogs
+with dar built using gcc 12 or newer. Closes: #1050663.
+
+ -- John Goerzen Mon, 04 Sep 2023 15:07:26 -0500
+
dar (2.7.8-1) unstable; urgency=medium
* New upstream release.
diff -Nru dar-2.7.8/debian/patches/series dar-2.7.8/debian/patches/series
--- dar-2.7.8/debian/patches/series 2022-12-04 08:57:33.0 -0600
+++ dar-2.7.8/debian/patches/series 2023-09-04 15:07:12.0 -0500
@@ -2,3 +2,4 @@
fix_dcf_path.patch
fix_Hurd_FTBFS.patch
link_with_assuan.patch
+slice_layout.cpp-remove_ternary_operator.patch
diff -Nru
dar-2.7.8/debian/patches/slice_layout.cpp-remove_ternary_operator.patch
dar-2.7.8/debian/patches/slice_layout.cpp-remove_ternary_operator.patch
--- dar-2.7.8/debian/patches/slice_layout.cpp-remove_ternary_operator.patch
1969-12-31 18:00:00.0 -0600
+++ dar-2.7.8/debian/patches/slice_layout.cpp-remove_ternary_operator.patch
2023-09-04 15:07:02.0 -0500
@@ -0,0 +1,21 @@
+Description: Fix on-fly-isolate with recent GCC #1050663
+Author: Thomas
+Last-Update: 2023-08-30
+
+---
+
+--- DAR_a/src/libdar/slice_layout.cpp 2023-09-02 09:08:49.657051708 +0200
DAR_b/src/libdar/slice_layout.cpp 2023-09-02 09:11:39.240669572 +0200
+@@ -54,7 +54,11 @@ namespace libdar
+
+ void slice_layout::write(generic_file & f) const
+ {
+- char tmp = older_sar_than_v8 ? OLDER_THAN_V8 : V8;
++ char tmp = V8;
++ if(older_sar_than_v8)
++ {
++ tmp = OLDER_THAN_V8;
++ }
+ first_size.dump(f);
+ other_size.dump(f);
+ first_slice_header.dump(f);
Bug#1050663: Fwd: Re: [Dar-support] Fwd: Bug#1050663: dar option --on-fly-isolate creates catalogue with broken slice_layout
>From the thread on the dar support mailing list:
https://sourceforge.net/p/dar/mailman/message/37890758/
On Sat, Sep 02 2023, Thomas wrote:
> On Wed, Aug 30, 2023 at 03:24:12PM -0500, John Goerzen wrote:
>> On Wed, Aug 30 2023, Denis Corbin wrote:
>>
>> >> Summary
>> >> ===
>> >> g++ 10 works fine with optimization.
>> >> g++ 11 or newer work only without optimization.
>> >> Hope this helps.
>> >
>> > Thanks for confirming this is a gcc issue. I don't know what should be the
>> > next
>> > step, if someone fills a bug report to gcc Debian maintainer?
>>
>> Well, to be sure, we have a couple of possibilities:
>>
>> 1) This is a gcc bug,
>>
>> or 2) There is something in dar (or, for that matter, bzip2 or some
>> other library) that is relying on some sort of C/C++ undefined behavior
>> (UB) that the optimizer is taking in a different direction. Other
>> possibilities could include race conditions, etc.
>
> To find the root cause why the optimizer does something harmfull in our
> case is way over my head.
>
> But...
> I have found a workaround for dar. The appended patch works for me with
> dar v2.7.11 and g++ v13.2.0, v12.3.0 and v11.4.0. Means, files generated
> with OnFlyIsolation are readable again with default optimizations
> activated.
> It seems the optimizer does not like the used ternary operator.
>
> I tested the patch with g++ v10.4.0 and 9.3.0, too without problems but
> these versions are working with or without this patch anyway.
>
> Hope this helps.
>
> Tom
>
> [2. text/x-diff; slice_layout.cpp-remove_ternary_operator.patch]...
diff -rupN DAR_a/src/libdar/slice_layout.cpp DAR_b/src/libdar/slice_layout.cpp
--- DAR_a/src/libdar/slice_layout.cpp 2023-09-02 09:08:49.657051708 +0200
+++ DAR_b/src/libdar/slice_layout.cpp 2023-09-02 09:11:39.240669572 +0200
@@ -54,7 +54,11 @@ namespace libdar
void slice_layout::write(generic_file & f) const
{
- char tmp = older_sar_than_v8 ? OLDER_THAN_V8 : V8;
+ char tmp = V8;
+ if(older_sar_than_v8)
+ {
+ tmp = OLDER_THAN_V8;
+ }
first_size.dump(f);
other_size.dump(f);
first_slice_header.dump(f);
Bug#1050865: kwin-bismuth: Please patch for Wayland compatibility
Package: kwin-bismuth Version: 3.1.4-4 Severity: important Tags: patch Hi, Bismuth doesn't work well with Wayland (and, in some cases, X11) in current KDE. A one-character patch here fixes it: https://github.com/Bismuth-Forge/bismuth/pull/490 -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kwin-bismuth depends on: ii libc6 2.36-9+deb12u1 ii libgcc-s1 12.2.0-14 ii libkdecorations2-5v5 4:5.27.5-2 ii libkf5configcore5 5.103.0-2 ii libkf5configgui5 5.103.0-2 ii libkf5coreaddons5 5.103.0-1 ii libkf5globalaccel-bin 5.103.0-1 ii libkf5globalaccel55.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5quickaddons55.103.0-1 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5dbus5 5.15.8+dfsg-11 ii libqt5gui55.15.8+dfsg-11 ii libqt5qml55.15.8+dfsg-3 ii libqt5quick5 5.15.8+dfsg-3 ii libqt5widgets55.15.8+dfsg-11 ii libstdc++612.2.0-14 ii plasma-workspace 4:5.27.5-2 ii qml-module-org-kde-kcm5.103.0-1 ii qml-module-org-kde-kirigami2 5.103.0-1 ii qml-module-qtquick-controls 5.15.8-2 ii qml-module-qtquick-layouts5.15.8+dfsg-3 ii qml-module-qtquick2 5.15.8+dfsg-3 kwin-bismuth recommends no packages. kwin-bismuth suggests no packages. -- no debconf information
Bug#1050663: dar option --on‐fly‐isolate creates catalogue with broken slice_layout
tags 1050663 upstream
thanks
Hi Thomas,
Thank you for this clear and well-documented report. This looks like a
bug in upstream dar. Would you please report it to Denis (upstream
author) on the mailing list at
https://sourceforge.net/projects/dar/lists/dar-support ?
I do also monitor that list and will chime in if there is anything
Debian-specific to add. Denis is very responsive and is going to be
making a new release soon, so maybe this could get into the release he
is preparing.
Thanks,
John
On Sun, Aug 27 2023, Thomas wrote:
> Package: dar
> Version: 2.7.10-2+b2
> Severity: normal
> X-Debbugs-Cc: debianbts-20230827181...@racbu.de
>
> Dear Maintainer,
>
> I try to do a differential backup with an earlier on-fly-isolated
> catalogue. It seems dar can't read the isolated catalogues anymore.
>
> , [ Error ]
> | Final memory cleanup...
> | exception type = [BUG] --
> | [source]
> | File ../../../src/libdar/slice_layout.cpp line 48 : it seems to be
> a bug here
> | stack dump :
> |
> /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar4EbugC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi+0x140)
> | [0x7f4ff3f79d50]
> | stack dump : /lib/x86_64-linux-gnu/libdar64.so.6000(+0xf83bb)
> [0x7f4ff3ef83bb]
> | stack dump :
> |
> /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar14header_version4readERNS_12generic_fileERNS_16user_interactionEb+0x264)
> | [0x7f4ff3fbc944]
> | stack dump :
> |
> /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar24macro_tools_open_archiveERKSt10shared_ptrINS_16user_interactionEERKS0_INS_8entrepotEERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_8limitintImEESG_NS_11crypto_algoERKNS_11secu_stringEjRNS_4pileERNS_14header_versionESG_SG_SG_RSI_RNS9_4listINS_8signatorESaISV_EEERNS_12slice_layoutEmmb+0x3aa)
> | [0x7f4ff3fe526a]
> | stack dump :
> |
> /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar7archive9i_archiveC1ERKSt10shared_ptrINS_16user_interactionEERKNS_4pathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESH_RKNS_20archive_options_readE+0x44f)
> | [0x7f4ff3fc1d6f]
> | stack dump :
> |
> /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar7archiveC2ERKSt10shared_ptrINS_16user_interactionEERKNS_4pathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESG_RKNS_20archive_options_readE+0xd6)
> | [0x7f4ff3f248c6]
> | stack dump : dar(+0x49306) [0x560a2c6b1306]
> | stack dump : dar(+0x5158c) [0x560a2c6b958c]
> | stack dump : dar(+0x247d1) [0x560a2c68c7d1]
> | stack dump : /lib/x86_64-linux-gnu/libc.so.6(+0x276ca)
> [0x7f4ff38456ca]
> | stack dump :
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7f4ff3845785]
> | stack dump : dar(+0x24821) [0x560a2c68c821]
> | [most outside call]
> | ---
> `
>
> Reproduce the error
>
> This is a minimal example to reproduce the error.
>
> ### Create som structure to backup
> $ export BASE=/tmp/dar_debug
> $ mkdir -p ${BASE}/bak ${BASE}/cat ${BASE}/files
> $ touch ${BASE}/files/file1
>
> ### Create the backup and the on-fly-isolation
> $ dar --create ${BASE}/bak/full --fs-root ${BASE}/files/ --aux
> ${BASE}/cat/full_onthefly
>
> ### Do a manual isolation after the backup is done
> $ dar --ref ${BASE}/bak/full --isolate ${BASE}/cat/full_isolate
>
> ### As described in the man page on-fly-isolation is always compressed so
> ### lets do this manually, too
> $ dar --ref ${BASE}/bak/full --compression=bzip2 --isolate
> ${BASE}/cat/full_isolate_compressed
>
> ### checking the results
> # the backup itself and the after backup-catalogues are working:
> $ dar --list ${BASE}/bak/full
> [Data ][D][ EA ][FSA][Compr][S]| Permission | User | Group | Size|
> Date |filename
> ++---+---+-+---+
> [Saved][ ] [-L-][ ][ ] -rw-r--r-- thomas thomas 0 Sun Aug
> 27 18:45:31 2023file1
>
> $ dar --list ${BASE}/cat/full_isolate
> [Data ][D][ EA ][FSA][Compr][S]| Permission | User | Group | Size|
> Date |filename
> ++---+---+-+---+
> [InRef][ ] [-L-][-][ ] -rw-r--r-- thomas thomas 0 Sun Aug
> 27 18:45:31 2023file1
>
> $ dar --list ${BASE}/cat/full_isolate_compressed
> [Data ][D][ EA ][FSA][Compr][S]| Permission | User | Group | Size|
> Date |filename
> ++---+---+-+---+
> [InRef][ ] [-L-][-][ ] -rw-r--r-- thomas thomas 0 Sun Aug
> 27 18:45:31 2023file1
>
>
> # dar can't read the on-fly-catalogue and reports the error above:
> $ dar --list ${BASE}/cat/full_onthefly
>
Bug#1043217: netmaze: please consider upgrading to 3.0 source format
On Thu, Aug 17 2023, Bastian Germann wrote: > Hi John, > > Am 17.08.23 um 02:54 schrieb John Goerzen: >> Is there a way to remove from delayed? > > Yes. I will do so. If you don't mind, I will add an explicit 1.0 format. Sure, that is fine. Incidentally, I got this: DELAYED/2-day/netmaze_0.81+jpg0.82-16.2_source.changes is already present on target host: 10-day/netmaze_0.81+jpg0.82-16.2_source.buildinfo Either you already uploaded it, or someone else came first. Job netmaze_0.81+jpg0.82-16.2_source.changes removed. Maybe the upload for the explicit 1.0 format tried to go in to 2-day but got rejected? Not quite sure. - John
Bug#1043217: netmaze: please consider upgrading to 3.0 source format
Hello Bastian, Thank you for the contribution and your work to improve Debian. I appreciate NMUs! However, I would prefer not to do this to Netmaze. I have people that send me patches on Github from time to time, and this makes it significantly more difficult for non-Debian contributors to participate. Personal opinion: Source format is duplicitive of features already in git for packages that are maintained in git, and makes collaboration with others more challenging, especially in a case like this. Is there a way to remove from delayed? - John On Thu, Aug 17 2023, Bastian Germann wrote: > I am uploading a NMU to DELAYED/10 to fix this. The debdiff is attached. > > [2. text/plain; netmaze_0.81+jpg0.82-16.2.debdiff]...
Bug#1042938: Additional information
I can add to this: 1) Adding the "ftp" user lets the anonymous and ftp accounts work as expected. 2) The long delay appears to be due to attempting a reverse lookup with avahi. I could find no way to disable reverse lookups in iksd. Most services these days don't do reverse lookups because of the expense of them, and waiting so long for a response seems to be breaking the incoming processes. Probably the postinst script should adduser the ftp account, or, given that iksd is less-used than kermit as a whole, README.Debian should mention it. I am still unable to get the syslog feature to work. - John
Bug#1042969: vsftpd: Deletes the ftp user on remove, breaking other packages
Package: vsftpd Version: 3.0.3-13+b2 Severity: critical Justification: breaks unrelated software On removing this package, it indiscriminately removes the ftp user. Unfortunately, that user was required for iksd in package ckermit to work, so this broke the unrelated ckermit package. It is likely that there are other packages and users that would also use the ftp user. It should not be removed on package removal. -- Package-specific info: -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vsftpd depends on: ii adduser3.134 ii debconf [debconf-2.0] 1.5.82 ii libc6 2.36-9+deb12u1 ii libcap21:2.66-4 ii libpam-modules 1.5.2-6 ii libpam0g 1.5.2-6 ii libssl33.0.9-1 ii libwrap0 7.6.q-32 ii lsb-base 11.6 ii netbase6.4 ii procps 2:4.0.2-3 ii sysvinit-utils [lsb-base] 3.06-4 Versions of packages vsftpd recommends: ii logrotate 3.21.0-1 ii ssl-cert 1.1.2 vsftpd suggests no packages. -- debconf information: vsftpd/directory: /srv/ftp vsftpd/username: ftp # Example config file /etc/vsftpd.conf # # The default compiled in settings are fairly paranoid. This sample file # loosens things up a bit, to make the ftp daemon more usable. # Please see vsftpd.conf.5 for all compiled in defaults. # # READ THIS: This example file is NOT an exhaustive list of vsftpd options. # Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's # capabilities. # # # Run standalone? vsftpd can run either from an inetd or as a standalone # daemon started from an initscript. listen=NO # # This directive enables listening on IPv6 sockets. By default, listening # on the IPv6 "any" address (::) will accept connections from both IPv6 # and IPv4 clients. It is not necessary to listen on *both* IPv4 and IPv6 # sockets. If you want that (perhaps because you want to listen on specific # addresses) then you must run two copies of vsftpd with two configuration # files. listen_ipv6=YES # # Allow anonymous FTP? (Disabled by default). anonymous_enable=NO # # Uncomment this to allow local users to log in. local_enable=YES # # Uncomment this to enable any form of FTP write command. #write_enable=YES # # Default umask for local users is 077. You may wish to change this to 022, # if your users expect that (022 is used by most other ftpd's) #local_umask=022 # # Uncomment this to allow the anonymous FTP user to upload files. This only # has an effect if the above global write enable is activated. Also, you will # obviously need to create a directory writable by the FTP user. #anon_upload_enable=YES # # Uncomment this if you want the anonymous FTP user to be able to create # new directories. #anon_mkdir_write_enable=YES # # Activate directory messages - messages given to remote users when they # go into a certain directory. dirmessage_enable=YES # # If enabled, vsftpd will display directory listings with the time # in your local time zone. The default is to display GMT. The # times returned by the MDTM FTP command are also affected by this # option. use_localtime=YES # # Activate logging of uploads/downloads. xferlog_enable=YES # # Make sure PORT transfer connections originate from port 20 (ftp-data). connect_from_port_20=YES # # If you want, you can arrange for uploaded anonymous files to be owned by # a different user. Note! Using "root" for uploaded files is not # recommended! #chown_uploads=YES #chown_username=whoever # # You may override where the log file goes if you like. The default is shown # below. #xferlog_file=/var/log/vsftpd.log # # If you want, you can have your log file in standard ftpd xferlog format. # Note that the default log file location is /var/log/xferlog in this case. #xferlog_std_format=YES # # You may change the default value for timing out an idle session. #idle_session_timeout=600 # # You may change the default value for timing out a data connection. #data_connection_timeout=120 # # It is recommended that you define on your system a unique user which the # ftp server can use as a totally isolated and unprivileged user. #nopriv_user=ftpsecure # # Enable this and the server will recognise asynchronous ABOR requests. Not # recommended for security (the code is non-trivial). Not enabling it, # however, may confuse older FTP clients. #async_abor_enable=YES # # By default the server will
Bug#1042938: ckermit: Several issues with iksd
Package: ckermit Version: 402~beta08-1 Severity: normal Hello, I have enabled iksd in my configuration, and /srv/ftp exists. I want to use anonymous mode. Initially it added this to /etc/inetd.conf: kermit stream tcp nowait root/usr/sbin/tcpd /usr/sbin/iksd -A --initfile:/etc/kermit/iksd-anon.conf --dbfile:/var/run/iksd.db --syslog:5 --root:/srv/ftp --anonymous:on However, after connecting, I'd immediately get a "Connection terminated by foreign host." Hmm. I determined this line allows it to run and even give a login prompt: kermit stream tcp nowait root/usr/sbin/tcpd /usr/sbin/iksd -A --dbfile:/var/run/iksd.db --root:/srv/ftp --anonymous:on Now, "telnet localhost kermit" will connect, and after about a 10-second delay, display the banner and a username prompt. However, both "anonymous" and "ftp" usernames produce "access denied". Within kermit, "iksd localhost" doesn't work at all. I also tried "iksd /encrypt:none localhost", and that was no better. Thanks! -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ckermit depends on: ii debconf [debconf-2.0] 1.5.82 ii libc6 2.36-9+deb12u1 ii libncurses66.4-4 ii libpam0g 1.5.2-6 ii libssl33.0.9-1 ii libtinfo6 6.4-4 Versions of packages ckermit recommends: ii openssh-client [ssh-client] 1:9.2p1-2 Versions of packages ckermit suggests: ii openbsd-inetd [inet-superserver] 0.20221205-1 -- debconf information: * ckermit/iksd-anondir: /srv/ftp * ckermit/iksd: true ckermit/iksd-no-inetd: * ckermit/iksd-anon: true
Bug#1038389: devscripts: dch --bpo should reference bpo12 and bookworm-backports, not bullseye
Package: devscripts Version: 2.23.4 Severity: normal dch --bpo in bookworm references bullseye-backports. -- Package-specific info: --- /etc/devscripts.conf --- Empty. --- ~/.devscripts --- DEBCOMMIT_STRIP_MESSAGE=yes DEBSIGN_KEYID=0x276D7B77B69B756C7CB68669DD29F88442839ED3 -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages devscripts depends on: ii dpkg-dev 1.21.22 ii fakeroot 1.31-1.2 ii file 1:5.44-3 ii gnupg 2.2.40-1.1 ii gnupg22.2.40-1.1 ii gpgv 2.2.40-1.1 ii libc6 2.36-9 ii libfile-dirlist-perl 0.05-3 ii libfile-homedir-perl 1.006-2 ii libfile-touch-perl0.12-2 ii libfile-which-perl1.27-2 ii libipc-run-perl 20220807.0-1 ii libmoo-perl 2.005005-1 ii libwww-perl 6.68-1 ii patchutils0.4.2-1 ii perl 5.36.0-7 ii python3 3.11.2-1+b1 ii sensible-utils0.0.17+nmu1 ii wdiff 1.2.2-5 Versions of packages devscripts recommends: ii apt 2.6.1 ii curl7.88.1-10 ii dctrl-tools 2.24-3+b1 ii debian-keyring 2022.12.24 ii dput1.1.3 ii dupload 2.9.12 ii equivs 2.3.1 pn libdistro-info-perl ii libdpkg-perl1.21.22 ii libencode-locale-perl 1.05-3 pn libgit-wrapper-perl pn libgitlab-api-v4-perl ii liblist-compare-perl0.55-2 ii liblwp-protocol-https-perl 6.10-1 ii libsoap-lite-perl 1.27-3 ii libstring-shellquote-perl 1.04-3 ii libtry-tiny-perl0.31-2 ii liburi-perl 5.17-1 ii licensecheck3.3.5-1 ii lintian 2.116.3 ii man-db 2.11.2-2 ii patch 2.7.6-7 ii pristine-tar1.50 ii python3-apt 2.6.0 ii python3-debian 0.1.49 ii python3-magic 2:0.4.26-3 ii python3-requests2.28.1+dfsg-1 ii python3-unidiff 0.7.3-1 ii python3-xdg 0.28-2 ii strace 6.1-0.1 ii unzip 6.0-28 ii wget1.21.3-1+b2 ii xz-utils5.4.1-0.2 Versions of packages devscripts suggests: pn adequate ii at3.2.5-1+b1 ii autopkgtest 5.28 pn bls-standalone ii bsd-mailx [mailx] 8.1.2-0.20220412cvs-1 ii build-essential 12.9 pn check-all-the-things pn cvs-buildpackage ii debhelper 13.11.4 pn diffoscope pn disorderfs ii dose-extra7.0.0-1+b2 pn duck pn elpa-devscripts pn faketime ii gnuplot 5.4.4+dfsg1-2 ii gnuplot-nox [gnuplot] 5.4.4+dfsg1-2+b2 pn how-can-i-help ii libauthen-sasl-perl 2.1600-3 pn libdbd-pg-perl ii libfile-desktopentry-perl 0.22-3 ii libterm-size-perl 0.211-1+b2 ii libtimedate-perl 2.3300-2 ii libyaml-syck-perl 1.34-2+b1 ii mailutils [mailx] 1:3.15-4 pn mmdebstrap pn mozilla-devscripts ii mutt 2.2.9-1+b1 ii openssh-client [ssh-client] 1:9.2p1-2 pn piuparts ii postgresql-client 15+248 ii postgresql-client-13 [postgresql-client] 13.11-0+deb11u1 ii postgresql-client-15 [postgresql-client] 15.3-0+deb12u1 pn pristine-lfs ii quilt 0.67+really0.66-1 pn ratt pn reprotest pn svn-buildpackage ii w3m 0.5.3+git20230121-2 -- no debconf information
Bug#1038129: libcurl4-openssl-dev: Static library shouldn't use krb5
Package: libcurl4-openssl-dev Version: 7.88.1-10 Severity: normal Hi, I am attempting to enable curl support in dar. dar provides a standard binary and dar_static, which is to be used for emergency system rescues. Curl provides a static version (.a). Unfortunately, curl uses gssapi_krb5, which is not available in a static version. The result is an inability to link a static program (due to being unable to find the krb5 symbols referenced in libcurl.a). The static version of libcurl.a should, therefore, be built without krb5 support. Thanks, John -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libcurl4-openssl-dev depends on: ii libcurl4 7.88.1-10 libcurl4-openssl-dev recommends no packages. Versions of packages libcurl4-openssl-dev suggests: pn libcurl4-doc pn libidn-dev ii libkrb5-dev 1.20.1-2 ii libldap-dev [libldap2-dev] 2.5.13+dfsg-5 ii libldap2-dev2.5.13+dfsg-5 pn librtmp-dev pn libssh2-1-dev ii libssl-dev 3.0.9-1 ii pkg-config 1.8.1-1 ii pkgconf [pkg-config]1.8.1-1 ii zlib1g-dev 1:1.2.13.dfsg-1 -- no debconf information
Bug#1038128: libkrb5-dev: Please provide static libraries (.a)
Package: libkrb5-dev Version: 1.20.1-2 Severity: normal I am attempting to enable curl support in dar. dar provides a standard binary and dar_static, which is to be used for emergency system rescues. Curl provides a static version (.a). Unfortunately, curl uses gssapi_krb5, which is not available in a static version.The result is an inability to link a static program. configure supports --enable-static. I see in the changelog that it was enabled in Debian in version 1.4.3-5, though that was dropped since for an unknown reason. It looks like enable-shared and enable-static may now conflict, so it may be necessary to build twice (as with the kmod package) to achieve this. Thanks, John -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libkrb5-dev depends on: ii krb5-multidev 1.20.1-2 libkrb5-dev recommends no packages. Versions of packages libkrb5-dev suggests: pn krb5-doc -- no debconf information
Bug#918075: Some patches for dar
Hi Laszlo, I have uploaded dar 2.7.9 with the change to Maintainer. libthreadar is also in NEW, and once it is accepted, I will be able to enable curl to provide FTP/SFTP support and close the bug entirely. Thank you for your work maintaining dar all this time! - John On Mon, Jun 05 2023, László Böszörményi (GCS) wrote: > Hi John, > > On Mon, Jun 5, 2023 at 10:12 PM John Goerzen wrote: >> If you are open to me taking over dar at this time, I would go ahead and >> upload 2.7.9 (with my updates above) with the maintainer changed to me. > I just ask for one thing. Please wait until Bookworm is released - > probably this or next week. Then go ahead and take over dar. > > Regards, > Laszlo/GCS
Bug#519558: Please retry with a newer dar
tags 519558 moreinfo thanks Hello, This bug is more than 10 years old. Please retry with a newer Dar; ideally 2.7.9 in sid. Failing that, at least the version in bookworm. It would be very helpful to have a reproducible test case if indeed the problem can be reproduced. Thanks, John
Bug#918075: Some patches for dar
On Mon, Jun 05 2023, László Böszörményi (GCS) wrote: > Hi John, > > On Mon, Jun 5, 2023 at 10:12 PM John Goerzen wrote: >> If you are open to me taking over dar at this time, I would go ahead and >> upload 2.7.9 (with my updates above) with the maintainer changed to me. > I just ask for one thing. Please wait until Bookworm is released - > probably this or next week. Then go ahead and take over dar. OK, will do. Thanks László! - John > > Regards, > Laszlo/GCS
Bug#918075: Some patches for dar
Hi László, With bookworm almost released, I figured I'd check back in. In addition to the uses I've been using dar for already, I'm beginning work on a long-term data archiving project with it, which is expanding my use case set. I blogged about that at https://changelog.complete.org/archives/10500-recommendations-for-tools-for-backing-up-and-archiving-to-removable-media if you are interested. Anyhow, additional comments inline below: On Wed, Mar 08 2023, László Böszörményi wrote: > Hi John, > > On Wed, Mar 8, 2023 at 2:47 PM John Goerzen wrote: >> I had thought that I'd be able to get by without the delta-diff >> features, but due to some changes over here, they would save me multiple >> GBs per day. So I am happy to dive in to work on dar. > Sounds good. > >> I have submitted an ITP for libthreadar, which will allow multithreaded >> compression/encryption as well as enable remote repository support. I >> have also uploaded a backport of librsync to bullseye-backports to >> enable a future dar backport to bullseye with binary delta support. > Where can I check the libthreadar packaging? This is now in NEW and available at https://salsa.debian.org/debian/libthreadar >> Would you like me to take over maintaining dar? Or would you like to >> apply the patch (with appropriate changelog updates) and upload it? Or >> I could upload it and leave the maintainers line alone? > It's a release freeze for Bookworm. I'm asking for approval and will > do it once it is allowed. > I am open to giving the package to you during the Trixie release cycle. I saw that the request to include a patched version in bookworm was denied; that's unfortunate, but I will prepare a backport for it anyway. My local patchset (not uploaded) carries this changelog: * Support delta changes via librsync. * Update dep on e2fslibs-dev to new name libext2fs-dev * Add dep on libcap-dev to eneable proper capability handling. * Add build-dependency on dot to ensure figures for docs are always built. Some of the dar frontends use the Python bindings, so I may also look into getting those built in the future. If you are open to me taking over dar at this time, I would go ahead and upload 2.7.9 (with my updates above) with the maintainer changed to me. Thanks, John
Bug#1035514: unblock: nncp/8.8.2-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package nncp
[ Reason ]
This unblock request is to support a small three-line diff that
corrects a data handling bug in NNCP.
[ Impact ]
At
http://lists.cypherpunks.ru/archive/nncp-devel/CAACH8H_3XugxyUQkgbOMNK=H_WAw-XNPR5ZH4Si29OR2fef=m...@mail.gmail.com/T/
, a bug was reported relating to the NNCP chunked (split) file transfer mode.
When chunked mode is used, large files are split into smaller chunks to make
transport possible over small media (eg, a 1TB file across a 128GB USB drive).
The bug resulted in reassembly being impossible with certain combinations of
chunk size and file size.
A fix already in my tree was also applied to postinst, which prevents it exiting
in error if a user had manually created the nncp user prior to installing nncp.
[ Tests ]
Sergey Matveev, author of NNCP, fixed the bug upstream. The original reporter
confirmed it was fixed.
[ Risks ]
The fix itself is trivial as seen in the attached debdiff. It is limited in
scope to the chunked transfer mode. The chunked transfer mode isn't used all
that often, but for those that do wish to use it, this prevents possible data
loss.
In the release announcement for NNCP 8.8.3 at
https://nncp.mirrors.quux.org/Release-8_005f8_005f3.html , you can see it
includes this fix, as well as a bunch of updated Go dependencies. The updated
Go dependencies would not be suitable for the transition at this point.
Therefore, I applied just the fix for this bug from the 8.8.3 branch and
uploaded 8.8.2-3 with it to unstable. To say I "backported" it would, I
suppose, be technically accurate but overstating things; it applied directly to
the 8.8.2 tree since that it what it was targeted to upstream anyhow. "Cherry
picked" would be a more accurate term.
[ 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 testing
[ Other info ]
unblock nncp/8.8.2-3
diff -Nru nncp-8.8.2/debian/changelog nncp-8.8.2/debian/changelog
--- nncp-8.8.2/debian/changelog 2023-01-01 15:32:04.0 -0600
+++ nncp-8.8.2/debian/changelog 2023-04-29 10:25:52.0 -0500
@@ -1,3 +1,11 @@
+nncp (8.8.2-3) unstable; urgency=medium
+
+ * Apply upstream bugfix to chunk reassembly.
+ * Tweak postinst to not generate an error if the nncp user was
+previously created by the user.
+
+ -- John Goerzen Sat, 29 Apr 2023 10:25:52 -0500
+
nncp (8.8.2-2) unstable; urgency=medium
* Team upload
diff -Nru nncp-8.8.2/debian/nncp.postinst nncp-8.8.2/debian/nncp.postinst
--- nncp-8.8.2/debian/nncp.postinst 2021-09-21 07:29:18.0 -0500
+++ nncp-8.8.2/debian/nncp.postinst 2023-01-07 08:25:29.0 -0600
@@ -25,7 +25,7 @@
mkdir /var/spool/nncp
CREATED=1
fi
- adduser --no-create-home --home /var/spool/nncp --system --group
nncp
+ adduser --no-create-home --home /var/spool/nncp --system --group
nncp || true
if [ "$CREATED" = "1" ]; then
chown nncp:nncp /var/spool/nncp
fi
diff -Nru nncp-8.8.2/debian/patches/reass-backport.diff
nncp-8.8.2/debian/patches/reass-backport.diff
--- nncp-8.8.2/debian/patches/reass-backport.diff 1969-12-31
18:00:00.0 -0600
+++ nncp-8.8.2/debian/patches/reass-backport.diff 2023-04-29
10:24:50.0 -0500
@@ -0,0 +1,29 @@
+Description: Fix bug in reassembly of certain chunked files
+ On April 28 2023, a bug was reported describing that reassembly of chunked
+ files could fail when the file size is an integer multiple of the chunk size.
+
http://lists.cypherpunks.ru/archive/nncp-devel/zez6w5vhuvzr2...@stargrave.org/T/#t
+ .
+ NNCP author Sergey Matveev released NNCP 8.8.3, which also contained updates
+ to the Go dependencies, including to Go 1.20. This makes it unsuitable for
+ upload to unstable or transition to testing at this time.
+ .
+ This patch isolates just the bugfix from NNCP 8.8.3, backporting it to NNCP
+ 8.8.2.
+Author: Sergey Matveev
+Origin: upstream
+Applied-Upstream: 523ac7e7dd5a2f97711fa369f7a73e43ff7b49bc
+Last-Update: 2023-04-29
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/cmd/nncp-reass/main.go
b/src/cmd/nncp-reass/main.go
+@@ -124,7 +124,8 @@
+ }
+ var badSize bool
+ if chunkNum+1 == len(chunksPaths) {
+- badSize = uint64(fi.Size()) !=
metaPkt.FileSize%metaPkt.ChunkSize
++ left := metaPkt.FileSize % metaPkt.ChunkSize
++ badSize = left != 0 && uint64(fi.Size()) != left
+ } else {
+ badSize = uint64(fi.Size()) != metaPkt.ChunkSize
+ }
diff -Nru nncp-8.8.2/debian/patches/series nncp-8.8.2/debian/pat
Bug#1034737: yggdrasil: yggdrasilctl getSelf doesn't report version number
Thank you! Nice detective work there. - John On Sat, Apr 22 2023, Andres Salomon wrote: > Control: tags -1 patch > > On Sat, Apr 22 2023 at 11:16:26 PM -04:00:00, Andres Salomon > wrote: >> >> However, I can't for the life of me figure out how to tell dh-golang >> to actually pass that to the Go compiler. *shrug* >> > > Here we go. This patch allows both `yggdrasil --version` and > `yggdrasilctl getself` to report the current version.
Bug#918075: Some patches for dar
Hi László,
I had thought that I'd be able to get by without the delta-diff
features, but due to some changes over here, they would save me multiple
GBs per day. So I am happy to dive in to work on dar.
I have submitted an ITP for libthreadar, which will allow multithreaded
compression/encryption as well as enable remote repository support. I
have also uploaded a backport of librsync to bullseye-backports to
enable a future dar backport to bullseye with binary delta support.
The attached patch adds binary delta support, as well as cleaning up
some other things (documentation images and capability support depending
on what was installed in the build environment, for instance). I was
also able to backport the result to bullseye.
Would you like me to take over maintaining dar? Or would you like to
apply the patch (with appropriate changelog updates) and upload it? Or
I could upload it and leave the maintainers line alone?
Thanks!
- John
diff --git a/debian/changelog b/debian/changelog
index f037041..2cb2738 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+dar (2.7.8-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Support delta changes via librsync.
+ * Update dep on e2fslibs-dev to new name libext2fs-dev
+ * Add dep on libcap-dev to eneable proper capability handling.
+ * Add build-dependency on dot to ensure figures for docs are always
+built.
+
+ -- John Goerzen Mon, 06 Mar 2023 18:19:22 -0600
+
dar (2.7.8-1) unstable; urgency=medium
* New upstream release.
diff --git a/debian/control b/debian/control
index 5698278..43bcb2c 100644
--- a/debian/control
+++ b/debian/control
@@ -3,9 +3,11 @@ Section: utils
Priority: optional
Maintainer: Laszlo Boszormenyi (GCS)
Build-Depends: debhelper-compat (= 13), pkg-config, zlib1g-dev, libbz2-dev,
- libzstd-dev, liblzo2-dev, liblzma-dev, liblz4-dev, e2fslibs-dev,
- libgcrypt20-dev, libgpgme-dev, libassuan-dev, libargon2-dev, doxygen, groff
-Build-Conflicts: libcurl4-gnutls-dev, libcurl4-openssl-dev, librsync-dev
+ libzstd-dev, liblzo2-dev, liblzma-dev, liblz4-dev, libext2fs-dev,
+ libgcrypt20-dev, libgpgme-dev, libassuan-dev, libargon2-dev,
+ librsync-dev, libcap-dev,
+ doxygen, groff, graphviz
+Build-Conflicts: libcurl4-gnutls-dev, libcurl4-openssl-dev
Standards-Version: 4.6.1
Rules-Requires-Root: no
Homepage: http://dar.linux.free.fr/
diff --git a/debian/rules b/debian/rules
index de23882..0e60393 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,7 +10,7 @@ DEB_CONFIGURE_EXTRA_FLAGS := --disable-upx --disable-python-binding \
--enable-mode=64
DEB_CONFIGURE_EXTRA_FLAGS += --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
-BUILT_USING_PACKAGES = libc-dev-bin libattr1-dev libbz2-dev libgcrypt20-dev libgpgme-dev liblzo2-dev zlib1g-dev libzstd-dev liblz4-dev libargon2-dev libassuan-dev
+BUILT_USING_PACKAGES = libc-dev-bin libbz2-dev libgcrypt20-dev libgpgme-dev liblzo2-dev zlib1g-dev libzstd-dev liblz4-dev libargon2-dev libassuan-dev librsync-dev libext2fs-dev libcap-dev
BUILT_USING=$(shell dpkg-query -f '$${source:Package} (= $${source:Version}), ' -W $(BUILT_USING_PACKAGES))
Bug#1032520: ITP: libthreadar -- C++ classes for manipulating threads
Package: wnpp Severity: wishlist Owner: John Goerzen X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libthreadar Version : 2.4.0 Upstream Author : Denis Corbin * URL : https://sourceforge.net/projects/libthreadar/ * License : LGPL v3+ Programming Lang: C++ Description : C++ classes for manipulating threads Libthreadar is a C++ library providing an abstracted set of C++ *classes* to manipulate threads in a very simple and efficient way from your C++ code. . It also handles exceptions thrown from a thread and propagated to another one, when the later is calling the thread::join() method. This let one manage exceptions as simply as it is in C++ single threaded context. . Additionally, all the related objects around multi-threading (mutex, semaphore, ...) are provided, under easy to use and independent C++ classes. Other more advanced classes ease the information exchange between threads like scattering and gathering a collection of objects between many threads, or asynchonous buffered information exchanges between two threads. . libthreadar allows the dar package to provide multithreaded encryption, compression, and remote repository access.
Bug#1024818: ITP: pygopherd -- Modular Multiprotocol Gopher/HTTP/WAP Server in Python
Package: wnpp Severity: wishlist Owner: John Goerzen X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pygopherd Version : 3.0.0b2 Upstream Author : John Goerzen , Michael Lazar * URL : https://github.com/michael-lazar/pygopherd * License : GPL Programming Lang: Python Description : Modular Multiprotocol Gopher/HTTP/WAP Server in Python This is a modern Gopher server. It can serve documents with Gopher+, standard Gopher (RFC1436), HTTP, and WAP -- all on the same port. Pygopherd features a modular extension system as well as loadable scripts and much more. It contains full support for UMN gopherd systems -- including .Links, .names, .cap, searches, etc. Pygopherd also supports Bucktooth features such as gophermap files and executables. In addition to all this, there are Pygopherd's own extra features. All features are fully customizable and can be enabled or disabled by editing /etc/pygopherd/pygopherd.conf. Note: pygopherd initially written and maintained in Debian by me. It was removed previously due to the Python 2 removal. Michael Lazar introduced Python 3 support, so I will be re-introducing it.
Bug#1024053: Ordering
My guess is that you want a Wants= and After= in your sshd.service override. You might try that and see. - John
Bug#1023265: Test failures blocking migration of rust-libc and several deps to testing
Package: rust-libc Version: 0.2.137-1 Severity: serious X-Debbugs-CC: plugw...@debian.org, wolfg...@silbermayr.at, infini...@debian.org Migration of several other packages is blocked due to the issues listed over at: https://tracker.debian.org/pkg/rust-libc In particular, it has caused failures in rust-capston on s390x and rust-netlink-sys in multiple platforms. Thanks, John
Bug#1022198: rust-rustyline: please upgrade to v9
On Sat, Oct 22 2022, Jonas Smedegaard wrote: > In Debian we use ITP bugreports to reduce the risk of such "race > conditions". Not for packages that are already in unstable as this one was. Or, for Rust libraries, per: https://salsa.debian.org/rust-team/debcargo-conf#itps - John
Bug#1022198: rust-rustyline: please upgrade to v9
On Sat, Oct 22 2022, Jonas Smedegaard wrote: >> rust-fd-lock has no reverse dependencies, but it's first (and only) upload >> was >> only 7 months ago. So I would like to give dkg a heads-up in case a major >> version bump interferes with his plans. >> >> I also notice that jgorzen has been working on fd-lock 3 packaging in >> debcargo-conf, however he has packaged 3.0.6 which depends on rustix which is >> not yet in Debian (currently waiting in new). >> >> So my plan would be >> >> upload fd-lock 3.0.2 and rustyline 9.1.2 now >> >> upload fd-lock 3.0.6 if/when rustix passes NEW >> >> jgorzen, dkg do you have any objections to this plan? > > Seems you can jump straight to second phase, as librust-rustix-dev has > just now entered unstable. :-) > > - Jonas Race condition here! I had visited with dkg about this and just uploaded fd-lock 3.0.6 (which is needed by filespooler, which I'm also about to upload) - John
Bug#1019702: RM: golang-golang.zx2c4-go118-netip -- RoQA; superseded by stdlib in Go1.18
On Tue, Sep 13 2022, Shengjing Zhu wrote: > I have updated wireguard-go last month. > > Currently dak doesn't complain about the removal. Oh excellent! No concerns from me then. - John
Bug#1019702: RM: golang-golang.zx2c4-go118-netip -- RoQA; superseded by stdlib in Go1.18
Hello, Yggdrasil depends on wireguard-go, which (in the version Yggdrasil wants), depends on netip. A newer version of wireguard-go does drop that dep. I guess we could see about packaging that and see if it works with Yggdrasil? Yggdrasil still supports 1.17 upstream which may be why they haven't updated the dep yet. John On Tue, Sep 13 2022, Shengjing Zhu wrote: > Package: ftp.debian.org > Severity: normal > X-Debbugs-Cc: z...@debian.org, jgoer...@complete.org > > This library is a temporary copy of golang 1.18 stdlib for old go versions. > Now golang 1.18 is the default version in unstable/testing for a while, so > this > library is no longer useful.
Bug#1019459: ITP: gvisor -- Application Kernel for Containers
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: gvisor Version : 20220905.0-1 Upstream Author : Google * URL : https://github.com/google/gvisor * License : Apache-2.0 and MIT Programming Lang: Go Description : Application Kernel for Containers gVisor is an application kernel, written in Go, that implements a substantial portion of the Linux system surface. This package includes the subset of gVisor necessary for applications that use its TCP/IP stack, which was formerly split out into inet.af/netstack. inet.af/netstack is deprecated thanks to the new support in Go for partial module compilation. NNCP now uses gVisor.
Bug#1013452: gensio-bin: Please include gensio.5 in gensio-bin
Package: gensio-bin Version: 2.2.4-1 Severity: normal Dear Maintainer, Please include the gensio.5(.gz) manpage in gensio-bin. It's in the -dev package but has helpful examples for running the binary. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-14-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gensio-bin depends on: ii libc6 2.31-13+deb11u3 ii libgensio0 2.2.4-1 ii libpam0g1.4.0-9+deb11u1 ii libssl1.1 1.1.1n-0+deb11u2 gensio-bin recommends no packages. gensio-bin suggests no packages. -- no debconf information
Bug#1013290: ITP: filespooler -- Sequential, Distributed, POSIX-Style Job Queues
Package: wnpp Severity: wishlist Owner: John Goerzen X-Debbugs-Cc: debian-de...@lists.debian.org, debian-r...@lists.debian.org * Package name: filespooler Version : 1.2.1 Upstream Author : John Goerzen * URL : https://www.complete.org/filespooler/ * License : GPL Programming Lang: Rust Description : Sequential, Distributed, POSIX-Style Job Queues Filespooler is a Unix-style tool that facilitates local or remote command execution, complete with stdin capture, with easy integration with various tools. Filespooler's capabilities: . It can easily use tools such as S3, Dropbox, Syncthing, NNCP, ssh, UUCP, USB drives, CDs, etc., or pipes as transport. Basically anything that's a filesystem or a pipe can be a transport. . It can use arbitrary decoder command pipelines (eg, zcat, stdcat, gpg, age, etc) to pre-process stored packets. . Its storage format is simple on-disk files with locking. . It supports one-to-one and one-to-many configurations. . Locking is unnecessary when writing new jobs to the queue, and many arbitrary tools (eg, Syncthing, Dropbox, etc) can safely write directly to the queue without any assistance. . Queue processing is (by default) strictly ordered based on the order on the creation machine, even if job files are delivered out of order to the destination. . stdin can be piped into the job creation tool, and piped to a later executor at process time on a remote machine. . The file format is lightweight; less than 100 bytes overhead unless large extra parameters are given. . The queue format is lightweight; having 1000 different queues on a Raspberry Pi would be easy. . Processing is stream-based throughout; arbitrarily-large packets are fine and sizes in the TB range are no problem. . The Filespooler command, fspl, is extremely lightweight, consuming less than 10MB of RAM on x86_64. . Filespooler has extensive documentation. . This package contains the command-line tool (fspl) for interacting with queues.
Bug#1010385: task-spooler: Please update to newer upstream
Package: task-spooler Version: 1.0.1+dfsg1-1 Severity: wishlist https://github.com/justanhduc/task-spooler seems to be the new home, and it up to 1.3.x. Thanks! -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-13-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages task-spooler depends on: ii libc6 2.31-13+deb11u3 task-spooler recommends no packages. task-spooler suggests no packages. -- no debconf information
Bug#1008286: Should nglister be removed?
severity 1008286 normal reassign 1008286 ftp.debian.org retitle 1008286 RM: nglister -- RoM; unmaintained thx On Fri, Mar 25 2022, Moritz Muehlenhoff wrote: > Source: nglister > Version: 1.0.2 > Severity: serious > > Your package came up as a candidate for removal from Debian: > > - Last upload in 2016 > - Removed from testing since 2019 > - Multiple RC bugs > > If you disagree and want to continue to maintain this package, > please just close this bug (and fix the open issues). > > If you agree with the removal, please reassign to ftp.debian.org > by sending the following commands to cont...@bugs.debian.org: > > -- > severity $BUGNUM normal > reassign $BUGNUM ftp.debian.org > retitle $BUGNUM RM: -- RoM; > thx > -- > > Otherwise I'll move forward and request it's removal in a month. > > Cheers, > Moritz
Bug#945396: Another theme should solve this
Installing a different sddm theme package and switching to it should resolve this. John
Bug#1004367: ITP: golang-inet-netstack -- Pure Go network stack
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: golang-inet-netstack Version : 0.0~git20211120.8aa80cf2-1 Upstream Author : inet.af * URL : https://github.com/inetaf/netstack * License : Apache-2.0 Programming Lang: Go Description : A pure Go network stack This is a "fork" of gvisor, extracting out just the "netstack" networking bits, which previously were self-contained at https://github.com/google/netstack. Why? Because gVisor's go.mod is gigantic and causes problems to people trying to use it as a library. Required by newer NNCP versions
Bug#1004028: ITP: golang-github-kardianos-minwinsvc -- Stub for portability to Windows
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: golang-github-kardianos-minwinsvc Version : 1.0.0-1 Upstream Author : Daniel Theophanes * URL : https://github.com/kardianos/minwinsvc * License : BSD-3 Programming Lang: Go Description : Stub for portability to Windows Minimal windows service stub . Programs designed to run from most *nix style operating systems can import this package to enable running programs as services without modifying them. On Debian platforms, it is simply a no-op, but is a dependency of certain cross-platform Go code.
Bug#1004025: ITP: golang-github-arceliar-ironwood -- Routing library with public keys as addresses
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: golang-github-arceliar-ironwood Version : 0.0~git20210619.6ad55ca-1 Upstream Author : Arceliar * URL : https://github.com/Arceliar/ironwood * License : MPL-2.0 Programming Lang: Go Description : Ironwood is a routing library with a net.PacketConn-compatible interface using ed25519.PublicKeys as addresses. Basically, you use it when you want to communicate with some other nodes in a network, but you can't guarantee that you can directly connect to every node in that network. It was written to test improvements to / replace the routing logic in Yggdrasil (https://github.com/yggdrasil-network/yggdrasil-go), but it may be useful for other network applications. Required by Yggdrasil, which is required by NNCP
Bug#1004021: ITP: wireguard-go -- Implementation of WireGuard in Go
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: wireguard-go Version : 0.0.20220117-1 Upstream Author : Jason A. Donenfeld * URL : https://git.zx2c4.com/wireguard-go/about/ * License : MIT Programming Lang: Go Description : Implementation of WireGuard in Go This is a userspace implementation of WireGuard in Go. . It also provides a library that is used by other programs for working with the kernel tun interface and related tasks. This is a dependency of Yggdrasil, which uses it for its tun support. NNCP also requires Yggdrasil now.
Bug#1004020: ITP: golang-golang.zx2c4-go118-netip -- netip from Go 1.18 for use in Go 1.17
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: golang-golang.zx2c4-go118-netip Version : 0.0~git2021.a4a02ee-1 Upstream Author : The Go Authors * URL : TODO * License : BSD 3-clause Programming Lang: Go Description : An extraction of netip from Go 1.18 for use in Go 1.17 Required by wireguard-go
Bug#1003988: ITP: golang-github-arceliar-phony -- A ponylang-inspired actor model library for Go
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: golang-github-arceliar-phony Version : 0.0~git20210209.dde1a8d-1 Upstream Author : Arceliar * URL : https://github.com/Arceliar/phony * License : MPL-2.0 Programming Lang: Go Description : A ponylang-inspired actor model library for Go Phony is a Pony-inspired proof-of-concept implementation of shared-memory actor-model concurrency in the Go programming language. Actors automatically manage goroutines and use asynchronous causal messaging (with backpressure) for communcation. This makes it easy to write programs that are free from deadlocks, goroutine leaks, and many of the for loops over select statements that show up in boilerplate code. The down side is that the code needs to be written in an asynchronous style, which is not idiomatic to Go, so it can take some getting used to.
Bug#1003985: ITP: yggdrasil-go -- foo
Package: wnpp Severity: wishlist Owner: John Goerzen X-Debbugs-Cc: debian-de...@lists.debian.org Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: yggdrasil-go Version : 0.4.2-1 Upstream Author : Yggdrasil Network * URL : https://github.com/yggdrasil-network/yggdrasil-go * License : LGPL Programming Lang: Go Description : Scalable, distributed, encrypted IPv6 overlay network Yggdrasil is a fully end-to-end encrypted IPv6 network. It is lightweight, self-arranging, supported on multiple platforms and allows pretty much any IPv6-capable application to communicate securely with other Yggdrasil nodes. Yggdrasil does not require you to have IPv6 Internet connectivity - it also works over IPv4.
Bug#918075: Enabling new 2.6/2.7 dar features
Hi again Laszlo, I thought I would revisit the conversation in 918075. Since then, I think we have had additional features in 2.7.x. At the moment, I believe this is a list of things we could support in dar on Debian but aren't: zstd compression lz4 compression multithreading delta compression (librsync) remote repository (libcurl) argon2 hashing (libargon) Python library Necessary libraries for all of these except multithreading are in Debian already. If I might summarize the situation: - There is concern that some of these libraries are not available in static versions in Debian, and thus dar_static can't be built with them. - On the other hand, we are now at a point where Debian's dar is incapable of extracting quite a few archives made by dar on other platforms (or locally-compiled dar). dar_static is of little use if it can't unpack the archive anyhow. zstd and delta compression, in particular, are two quite compelling features that we are lacking. I propose: 1) Packaging up threadar 2) Pick one of: 2a) Enabling all libraries in the dynamic version, and as many as possible in the static version, and document the situation; 2b) Take an approach like exim4-daemon-heavy vs. exim4-daemon-light, and provide a dar-light and a dar-heavy binary package, which differ in what libraries are linked in. 2c) Enable all libraries in the dynamic version, and drop dar-static entirely. I volunteer to do the work. I would be happy to package up and maintain threadar, and to send you patches for dar, be a co-maintainer for dar, or take over maintaining dar, whatever you may prefer. As for which option 2 we choose, my preference is 2c, followed by 2a. I think that a light vs. heavy package is overkill in this situation (exim did this because the "heavy" package really did bring in significant heavy libraries like SQL and such). Comparing with other similar packages on the system: - GNU tar, at /bin/tar, is dynamically linked but calls external archivers as a separate process and therefore doesn't link them in. - bsdtar, at /usr/bin/bsdtar, is dynamically linked and has a very similar set of libraries it would use compared to dar. bsdtar's own libarchive is linked in, as well as liblz4, libzstd, libbz2, liblzma, libacl, etc. bsdtar is a multi-archive program, supporting multiple flavors of tar, pax, cpio, shar, iso9660, zip, ar, mtree, 7z, cab, lha, rar, warc, and xar, so it is quite capable of creating formats that can't be extraced by standard Debian base system tools. - fsarchiver has its own format, and its linking approach is like bsdtar. dynamically-linked only, links libbz2, liblzo2, liblz4, libzstd, liblzma, libgcrypt, etc. - p7zip uses a linking approach similar to GNU tar, dynamic only - unrar is dynamic only - cpio is dynamic only - afio is dynamic only - borgbackup is Python-only and also depends on libzstd1 - rdiff-backup is Python-only and also depends on librsync2 - duplicity is Python-only and also depends on librsync2 So what I'm trying to say here is that I can't find any other backup/archiving tool on Debian that limits itself to what is possible in a static binary, or even ships a static binary in the first place. Given the existence of Debian Live images, it should be easy enough for someone wanting to be able to extract a dar archive to make that happen even with a completely wiped system. All of these other tools make that assumption as well. Ultimately, I don't want Debian's dar to be unable to unpack dar archives because we are restricting the feature set so tightly to what we can put in dar-static. Thanks, John
Bug#994727: reportbug: Hang at boot (pre-X) with [drm] CPU Pipe A FIFO underrun [workaround included]
Package: src:linux
Version: 5.10.46-4
Severity: critical
Hello,
After upgrading this laptop from buster to bullseye, I started to have
issues. The laptop uses a LUKS root, so it pauses before loading X to
prompt for a password. Therefore I know this problem is not just X.
Immediately after putting in my password, I would observe screen corruption
(random garbage on the top few rows of pixels) followed by a complete
system hang. Occasionally I was able to see a message on the console
first:
[drm] CPU Pipe A FIFO underrun
I tried booting the Debian bullseye live image, and it too would hang a few
minutes into the session (which was X-based) with no message at all.
Quite a bit of searching brought me to #884116 and this thread
https://lists.debian.org/debian-kernel/2017/12/msg00350.html.
Unfortunately, it didn't immediately help.
I tried iommu=soft and other iommu options, but they only resolved the
corruption but not the crash.
Eventually, I found
https://askubuntu.com/questions/895329/flickering-screen-cpu-pipe-b-fifo-underrun-when-i-use-the-termnal
which recommended these kernel options:
i915.enable_psr=0 i915.edp_vswing=2
This resolved the issue and the system booted normally. That report also
mentions screen flickering; I also have been experiencing that in the
console (but not X) and the flickering persisted, but that is not a big
deal to me since most of the time is spent in X.
The askubuntu page also referenced disabling C-states in BIOS, though that
was not necessary for me.
This system is a Dell Latitude 7480 with a Core i7-7600U and Intel HD
Graphics 620.
-- Package-specific info:
** Version:
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP
Debian 5.10.46-4 (2021-08-03)
** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-8-amd64 root=ZFS=rpool/ROOT/debian-1 ro
i915.enable_psr=0 i915.edp_vswing=2
** Tainted: PUOE (12353)
* proprietary module was loaded
* taint requested by userspace application
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
[9.961833] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD (1bcf:2b96)
[9.966740] dell_laptop: Using i8042 filter function for receiving events
[9.982813] input: Integrated_Webcam_HD: Integrate as
/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input11
[9.987357] Console: switching to colour dummy device 80x25
[9.987385] i915 :00:02.0: vgaarb: deactivate vga console
[9.991762] usbcore: registered new interface driver uvcvideo
[9.991766] USB Video Class driver (1.1.1)
[ 10.010681] i915 :00:02.0: vgaarb: changed VGA decodes:
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 10.013323] i915 :00:02.0: firmware: direct-loading firmware
i915/kbl_dmc_ver1_04.bin
[ 10.013611] i915 :00:02.0: [drm] Finished loading DMC firmware
i915/kbl_dmc_ver1_04.bin (v1.4)
[ 10.033304] i915 :00:02.0: [drm] Panel advertises DPCD backlight
support, but VBT disagrees. If your backlight controls don't work try booting
with i915.enable_dpcd_backlight=1. If your machine needs this, please file a
_new_ bug report on drm/i915, see
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for
details.
[ 10.042820] mei_hdcp :00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04:
bound :00:02.0 (ops i915_hdcp_component_ops [i915])
[ 10.043946] Intel(R) Wireless WiFi driver for Linux
[ 10.044259] iwlwifi :02:00.0: enabling device ( -> 0002)
[ 10.078776] iwlwifi :02:00.0: firmware: direct-loading firmware
iwlwifi-8265-36.ucode
[ 10.079252] iwlwifi :02:00.0: loaded firmware version 36.ad812ee0.0
8265-36.ucode op_mode iwlmvm
[ 10.079281] iwlwifi :02:00.0: firmware: failed to load
iwl-debug-yoyo.bin (-2)
[ 10.079283] firmware_class: See https://wiki.debian.org/Firmware for
information about missing firmware
[ 10.153860] Bluetooth: Core ver 2.22
[ 10.153883] NET: Registered protocol family 31
[ 10.153886] Bluetooth: HCI device and connection manager initialized
[ 10.153890] Bluetooth: HCI socket layer initialized
[ 10.153892] Bluetoo
th: L2CAP socket layer initialized
[ 10.153896] Bluetooth: SCO socket layer initialized
[ 10.170927] usbcore: registered new interface driver btusb
[ 10.185285] Bluetooth: hci0: Bootloader revision 0.0 build 26 week 38 2015
[ 10.186286] Bluetooth: hci0: Device revision is 16
[ 10.186289] Bluetooth: hci0: Secure boot is enabled
[ 10.186290] Bluetooth: hci0: OTP lock is enabled
[ 10.186291] Bluetooth: hci0: API lock is enabled
[ 10.186292] Bluetooth: hci0: Debug lock is disabled
[ 10.186293] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[ 10.189271] bluetooth hci0: firmware: direct-loading firmware
intel/ibt-12-16.sfi
[ 10.189278] Bluetooth: hci0: Found device firmware: intel/ibt-12-16.sfi
[ 10.281773] EXT4-fs (sda2): mounting ext2 file
Bug#993211: inn2: ovdb_monitor/server can't start due to missing /run/news
On Sun, Sep 05 2021, Russ Allbery wrote:
We could, but it does indicate an actual problem, so I'd love to
understand more about why this is happening. If ZFS does change
the
inodes on every reboot, another possible solution may be to
ensure that
expireover fixes the inode references (I'm not sure that it does
right now
in cases where it didn't need to change anything during
expiration), which
means the messages will only happen once after each reboot.
This has been nagging at me, and after giving it some more
thought, I am remembering something now -- the exact timing is
lost, and I apologize for not thinking of it before.
This was running inside a Docker container. Initially I installed
some things, then tar'd up /var/{lib,spool}/news in preparation
for making them into Docker volumes. I did make the volumes, and
unpacked the tarball over them. Was this coinciding with the log
messages? That I don't know, but it's the most plausible
explanation I have right now. The volumes were on a different ZFS
dataset so that would certainly have different inode numbers.
Again, I apologize for not thinking of this before.
I assume ZFS can't be changing them constantly without a reboot
or a
remounting of the file system, since presumably that would break
lots of
other software.
I'm sure this is right. I will note that people may like to be
able to mount a ZFS snapshot -- which would certainly have a
different st_dev or st_ino -- without 50,000 errors. But it may
well be that I had forgotten this.
- John
Bug#993703: dh-make-golang: make crashes with certain unknown publishers
Package: dh-make-golang
Version: 0.5.0-1
Severity: important
I am attempting to package up NNCP, and for that I need a
go.cypherpunks.ru/balloon .
Running dh-make-golang make -type library -allow_unknown_hoster
go.cypherpunks.ru/balloon , I see:
2021/09/05 01:16:27 Running "git fetch go.cypherpunks"
remote: Enumerating objects: 95, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 95 (delta 0), reused 3 (delta 0), pack-reused 92
Unpacking objects: 100% (95/95), 27.75 KiB | 163.00 KiB/s, done.
>From https://git.cypherpunks.ru/balloon
* [new branch] master -> go.cypherpunks/master
* [new tag] v1.0.0 -> v1.0.0
* [new tag] v1.1.0 -> v1.1.0
* [new tag] v1.1.1 -> v1.1.1
tar: This does not look like a tar archive
gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now
gbp:error: Couldn't unpack
'/home/jgoerzen/work/nncp-debian/golang-lukechampine-blake3/golang-go.cypherpunks-balloon_1.1.1.orig.tar.gz':
it exited with 2
2021/09/05 01:16:28 Could not create git repository: import-orig: exit status 1
And indeed, there's a reason it couldn't unpack that:
-rw-r--r-- 1 jgoerzen jgoerzen 0 Sep 5 01:16
golang-go.cypherpunks-balloon_1.1.1.orig.tar.gz
Looking in the code, the hoster isn't going to have a tarball. But in make.go,
there's this:
if u.isRelease {
if !u.hasGodeps { // No need to repack; fetch pristine tarball
u.compression = "gz"
if err := u.tarballFromHoster(); err != nil {
if err.Error() == "unsupported hoster" {
log.Printf("INFO: Hoster does not
provide release tarball\n")
} else {
return fmt.Errorf("tarball from hoster:
%w", err)
}
}
return nil
Basically it returns in the same way whether or not tarballFromHoster worked.
If I remove that "return nil", it works for this case (though of course may be
broken for others).
If you wish to test with this package, you will need the CA certificate from
http://www.ca.cypherpunks.ru/ installed per the instructions in
/usr/share/doc/ca-certificates.
Thanks,
John
-- System Information:
Debian Release: 11.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dh-make-golang depends on:
ii git 1:2.30.2-1
ii git-buildpackage 0.9.22
ii golang-any2:1.15~1
ii libc6 2.31-13
ii pristine-tar 1.49
Versions of packages dh-make-golang recommends:
ii exim4-daemon-light [mail-transport-agent] 4.94.2-7
ii golang-golang-x-tools 1:0.1.0+ds-1+b5
dh-make-golang suggests no packages.
-- no debconf information
Bug#993695: ITP: golang-lukechampine-blake3 -- A pure-Go implementation of the BLAKE3 cryptographic hash function
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: golang-lukechampine-blake3 Version : 1.1.5-1 Upstream Author : Luke Champine * URL : https://github.com/lukechampine/blake3 * License : Expat Programming Lang: Go Description : Pure-Go implementation of BLAKE3 cryptographic hash blake3 implements the BLAKE3 cryptographic hash function (https://github.com/BLAKE3-team/BLAKE3). This implementation aims to be performant without sacrificing (too much) readability, in the hopes of eventually landing in x/crypto. . In addition to the pure-Go implementation, this package also contains AVX-512 and AVX2 routines (generated by avo (https://github.com/mmcloughlin/avo)) that greatly increase performance for large inputs and outputs. Required for packaging NNCP
Bug#993672: ITP: hjson-go -- Hjson for Go
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: hjson-go Version : 3.1.0-1 Upstream Author : Hjson * URL : https://github.com/hjson/hjson-go * License : Expat Programming Lang: Go Description : Hjson for Go This package includes the hjson-cli command-line tool as well as the Go library for working with HJSON. HJSON is a derivative of JSON designed to be more easily editable by humans. This package is needed for the packaging of NNCP.
Bug#993666: ITP: golang-github-davecgh-go-xdr -- Implements the XDR standard as specified in RFC 4506 in pure Go (Golang)
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: golang-github-davecgh-go-xdr Version : 0.0~git20161123.e6a2ba0-1 Upstream Author : Dave Collins * URL : https://github.com/davecgh/go-xdr * License : ISC Programming Lang: Go Description : Implements the XDR standard as specified in RFC 4506 in pure Go (Golang) go-xdr Build Status (https://travis-ci.org/davecgh/go-xdr) Coverage Status (https://coveralls.io/r/davecgh/go-xdr?branch=master) . Go-xdr implements the data representation portion of the External Data Representation (XDR) standard protocol as specified in RFC 4506 (obsoletes RFC 1832 and RFC 1014) in Pure Go (Golang). A comprehensive suite of tests are provided to ensure proper functionality. It is licensed under the liberal ISC license, so it may be used in open source or commercial projects. . NOTE: Version 1 of this package is still available via the github.com/davecgh/go-xdr/xdr import path to avoid breaking existing clients. However, it is highly recommended that all old clients upgrade to version 2 and all new clients use version 2. In addition to some speed optimizations, version 2 has been been updated to work with standard the io.Reader and io.Writer interfaces instead of raw byte slices. This allows it to be much more flexible and work directly with files, network connections, etc. Documentation GoDoc (http://godoc.org/github.com/davecgh/go-xdr/xdr2) . Full go doc style documentation for the project can be viewed online without installing this package by using the excellent GoDoc site here: http://godoc.org/github.com/davecgh/go-xdr/xdr2 . You can also view the documentation locally once the package is installed with the godoc tool by running godoc -http=":6060" and pointing your browser to http://localhost:6060/pkg/github.com/davecgh/go-xdr/xdr2/ Installation bash $ go get github.com/davecgh/go-xdr/xdr2 . Required for packaging NNCP
Bug#993211: inn2: ovdb_monitor/server can't start due to missing /run/news
On Sat, Aug 28 2021, Russ Allbery wrote: John Goerzen writes: Hi Russ! It is good to visit with you again. Thanks for what you do with inn. I run an INN site for an ISP waaay back and am now getting back into it. Given your good point about makehistory, I suspect the right answer here is to create /run/news via /etc/tmpfiles.d. That should handle all I hadn't known about /etc/tmpfiles.d. TIL - thanks. Yes, that makes perfect sense. systemd systems, and the init script should handle non-systemd systems (with the edge case of not handling makehistory when the init script hasn't run since the last reboot, but I'm not sure if that's worth worrying about). Agreed. That's pretty obscure. BTW, I am a little uncertain about the long-term future of ovdb. We don't have an active maintainer of it upstream and BerkeleyDB itself is kind of a mess for various reasons and on shaky ground inside Debian. The next major release of INN will have a SQLite backend, which is probably the most equivalent replacement, although tradindexed does fine for most people. Ah, interesting. Sqlite makes sense for the future for sure. So I should mention why I switched. I was getting lines like this in the news.daily report: innd: tradindexed: index inode mismatch for local.test ... expireover: tradindexed: index inode mismatch for control expireover: tradindexed: index inode mismatch for control.cancel expireover: tradindexed: index inode mismatch for control.checkgroups ... I am running inn2 inside a Docker container atop zfs. I believe inodes should be internally consistent (eg, tar can properly detect hardlinkes) but due to the bind mount (and possibility of running atop a zfs clone or whatnot), I suspect -- but have not verified -- that at least st_dev if not st_ino also (from stat(2)) are not guaranteed to be consistent across restarts. I'd guess the most common reason for that would be st_dev changes due to the bind mount that Docker does. However, looking at the code, I don't think it uses st_dev, so perhaps st_ino is also not stable across restarts. (conjecture at this point) I read a few comments in the code and thought "you know, the easiest way out of this is to just use ovdb". - John
Bug#993211: inn2: ovdb_monitor/server can't start due to missing /run/news
Package: inn2 Version: 2.6.4-2 Severity: normal Hello, I was tracking down an odd problem with trying to get ovdb going: news@news:/var/lib/news$ /usr/lib/news/bin/ovdb_init ovdb_init: OVDB: can not open database unless ovdb_monitor is running ovdb_init: database is active ovdb_init: OVDB: can not open database unless ovdb_monitor is running ovdb_init: starting ovdb monitor ovdb_init: starting ovdb server But this leaves off with no ovdb processes actually running. Moreover, makehistory -O complained that it couldn't open overview due to "No such file or directory." Upon investigating things further, I noticed that /etc/news/inn.conf listed pathrun as /run/news, which doesn't exist. I did: mkdir /run/news chown news /run/news and then the ovdb processes started up fine. However, as run is often ephemeral, that isn't really a proper solution. I suspect that one or more of these should happen: 1) pathrun should be something different in the default config 2) README.Debian should document this issue 3) /run/news somehow gets created. I notice that the debian/inn2.init file does do this. However, on systemd systems, the debian/inn2.service file doesn't appear to. Also in situations of needing to run makehistory and such, often innd will have not been running. I wonder if the code to handle this got dropped on the way to systemd? -- John -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages inn2 depends on: ii cron [cron-daemon] 3.0pl1-137 ii exim4-daemon-light [mail-transport-agent] 4.94.2-7 pn inn2-inews ii libc6 2.31-13 ii libcrypt1 1:4.4.18-4 ii libdb5.3 5.3.28+dfsg1-0.8 ii libmime-tools-perl 5.509-1 ii libpam0g 1.4.0-9 ii libperl5.325.32.1-4+deb11u1 ii libpython3.9 3.9.2-1 ii libsasl2-2 2.1.27+dfsg-2.1 ii libssl1.1 1.1.1k-1+deb11u1 ii libsystemd0247.3-6 ii lsb-base 11.1.0 ii perl 5.32.1-4+deb11u1 ii perl-base [perlapi-5.32.1] 5.32.1-4+deb11u1 ii procps 2:3.3.17-5 ii time 1.9-0.1 ii zlib1g 1:1.2.11.dfsg-2 inn2 recommends no packages. Versions of packages inn2 suggests: pn gnupg1 pn libgd-perl ii libkrb5-3 1.18.3-6 ii wget1.21-1+b1
Bug#918075: Newer librsync now available
On Sun, Jan 17 2021, László Böszörményi (GCS) wrote: Hi, On Sun, Jan 17, 2021 at 7:03 AM John Goerzen wrote: Sid and bullseye now have a newer librsync; perhaps this can be done yet before freeze, at least for binary deltas? Indeed, librsync is newer than the needed minimum version. However it still does not include the static library needed for dar-static. Meaning I still can't include this functionality for dar. :( Hi Laszlo, I filed wishlist bug #980333 asking for this. The maintainer sounds receptive and might get it going soon, so perhaps this can be done in time for bullseye! John
Bug#980333: librsync-dev: Please also build static library
On Sun, Jan 17 2021, Andrey Rahmatullin wrote: Could you build a .a to include in librsync-dev, so that dar can take advantage of librsync features in both its dynamically-linked and statically-linked versions? Do you want this in bullseye? Yes, it would be fantastic if that could happen! Thanks, John
Bug#980333: librsync-dev: Please also build static library
Package: librsync-dev Version: 2.3.1-1 Severity: wishlist Hi, In #918075, binary delta support for dar is discussed. dar can optionally support it with librsync. However, from the dar source package, dar-static is also built. The dar maintainer doesn't want to enable binary deltas for only the dynamically-linked package. Could you build a .a to include in librsync-dev, so that dar can take advantage of librsync features in both its dynamically-linked and statically-linked versions? Thanks! - John -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-0.bpo.5-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages librsync-dev depends on: ii libbz2-dev 1.0.6-9.2~deb10u1 ii libpopt-dev 1.16-12 ii librsync10.9.7-10+b1 ii zlib1g-dev 1:1.2.11.dfsg-1 librsync-dev recommends no packages. librsync-dev suggests no packages.
Bug#980278: dar: par2 support doesn't work
On Sun, Jan 17 2021, László Böszörményi (GCS) wrote: Hi, On Sun, Jan 17, 2021 at 7:09 AM John Goerzen wrote: According to the manpage, I should be able to add "par2" and just have that work. However, I had several issues: 1) First, it said it was an unrecognized target. par2 was listed in /etc/darrc, but I had to add -B /etc/darrc for par2 to be recognized. Could be because of the wrong paths. Maybe you have ~/.darrc and that takes precedence. I did check, and no, I didn't have that file. 2) /usr/share/doc/dar/examples/dar_par.dcf has the wrong path to dar_par_create.duc and dar_par_test.duc (they are in /usr/share/doc/dar/examples, not /usr/share/dar/samples). Going to fix the paths soon, please try with the new package version. Thanks! - John
Bug#980278: dar: par2 support doesn't work
Package: dar Version: 2.6.2-1+b10 Severity: normal Hi, According to the manpage, I should be able to add "par2" and just have that work. However, I had several issues: 1) First, it said it was an unrecognized target. par2 was listed in /etc/darrc, but I had to add -B /etc/darrc for par2 to be recognized. 2) /usr/share/doc/dar/examples/dar_par.dcf has the wrong path to dar_par_create.duc and dar_par_test.duc (they are in /usr/share/doc/dar/examples, not /usr/share/dar/samples). I'm not entirely sure that /usr/share/doc/dar/examples is a good place for something that gets invoked in this manner, but that is a more minor and perhaps separate question. -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-0.bpo.5-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dar depends on: ii libassuan0 2.5.2-1 ii libattr1 1:2.4.48-4 ii libbz2-1.0 1.0.6-9.2~deb10u1 ii libc6 2.28-10 ii libdar64-6000 2.6.2-1+b10 ii libgcc11:8.3.0-6 ii libgcrypt201.8.4-5 ii libgpg-error0 1.35-1 ii libgpgme11 1.12.0-6 ii liblzma5 5.2.4-1 ii liblzo2-2 2.10-0.1 ii libstdc++6 8.3.0-6 ii zlib1g 1:1.2.11.dfsg-1 dar recommends no packages. Versions of packages dar suggests: ii dar-docs 2.6.2-1 ii par2 0.8.0-1 -- no debconf information -- debsums errors found: debsums: changed file /usr/share/doc/dar/examples/dar_par.dcf (from dar package)
Bug#918075: Newer librsync now available
Hi, Sid and bullseye now have a newer librsync; perhaps this can be done yet before freeze, at least for binary deltas? Thanks! John
Bug#977169: weechat-scripts: Python TabError on queue.py
Package: weechat-scripts Version: 20200815-1 Severity: normal When loading a script that requires /usr/share/weechat/python/queue.py, a TabError for inconsistent use of tabs and spaces is raised. Indeed, this is correct; using sed to convert every tab to 8 spaces causes the file to load without issue. The previous edition of this file did not appear to manifest this problem. Thanks, John
Bug#972132: [Pkg-zfsonlinux-devel] Bug#972132: zfs-initramfs: Fails to boot when / is on zfs encryption=on dataset
On Mon, Oct 12 2020, Richard Laager wrote: On 10/12/20 9:29 PM, John Goerzen wrote: I have set up this system to use ZFS crypto rather than my more conventional zfs-atop-LUKS. Can you explain a little bit more about how you setup your system? This (root-on-ZFS with native encryption) already works for me on Buster (with ZFS from buster-backports) using the upstream HOWTO (that I maintain): https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html Hi Richard, That HOWTO is fantastic and I wish that it would have turned up when I did my search! I have pretty much done similar things with my setup. The main thing that occurs to me is I hadn't figured out the -O encryption=on for the zpool create, so I have a top-level rpool that is unencrypted, and under that rpool/crypt that is encrypted, and everything on the system is under rpool/crypt. /boot is not on ZFS. # zfs list -o name,mountpoint NAME MOUNTPOINT rpool/rpool rpool/crypt /rpool/crypt rpool/crypt/debian-1 / rpool/crypt/debian-1/home/home and so forth. I don't have a separate bpool due to /boot being ext2 so there's not that issue for me. I made no modification to systemd unit files, or the zfs-list.cache. Thanks, John
Bug#972132: zfs-initramfs: Fails to boot when / is on zfs encryption=on dataset
Package: zfs-initramfs Version: 0.8.4-2~bpo10+1 Severity: important Dear Maintainer, I have set up this system to use ZFS crypto rather than my more conventional zfs-atop-LUKS. I have a passphrase that needs a prompt. All that should be necessary here would be adding -l to zfs mount, or to zpool import. Without it, the system fails to boot. To workaround this, I have added a file in /etc/initramfs-tools/scripts/local-premount that basically does a zpool import, then a zpool load-key, which is enough to get the system going. -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-0.bpo.2-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zfs-initramfs depends on: ii busybox 1:1.30.1-4 ii initramfs-tools 0.133+deb10u1 ii zfs-dkms [zfs-modules] 0.8.4-2~bpo10+1 ii zfsutils-linux 0.8.4-2~bpo10+1 zfs-initramfs recommends no packages. zfs-initramfs suggests no packages. -- no debconf information
Bug#960452: mount: Editing fstab in a valid way causes silent failure to mount
On Tue, Jun 23 2020, Chris Hofstaedtler wrote: > Okay, that would match the suggestion. In this case I'd think this > is more a systemd issue than a mount issue - mount passes your mount > request to the kernel, and the kernel mounts it. Then something else > (probably systemd) unmounts it immediately. I think that is absolutely plausible. I'm not sure if it would help, since I can no longer reproduce this, but a guess a reassignment to systemd might be relevant. But I agree that adding content to fstab(5) would be helpful in any case (and perhaps also mount(8)). Thanks Chris! - John
Bug#960452: mount: Editing fstab in a valid way causes silent failure to mount
On Tue, May 12 2020, Chris Hofstaedtler wrote: Hi Chris, > I must say this is a very generic report. To your points 1) and 2) > I could ask "What did the kernel say at this time, esp. did it claim > success?", to 3) and 4) I could say "There is also no documentation > on interactions with other tools changing global system state, like > reboot(1)". > Now, none of these replies would be very helpful. Sorry about that, Chris. I have tried just now and, rather to my surprise, have been unable to duplicate this in order to gather more information. I had assumed it would be fairly readily reproducible; that is my mistake. I can report to you that the kernel messages looked as if it had been mounted; for instance: May 11 20:48:46 tinwhistle kernel: [10011.916687] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) May 11 20:50:19 tinwhistle kernel: [10104.961413] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: errors=remount-ro May 11 21:06:21 tinwhistle kernel: [11067.149192] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: errors=remount-ro May 11 21:06:30 tinwhistle kernel: [11076.165431] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: errors=remount-ro May 11 21:06:47 tinwhistle kernel: [11093.047456] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) May 11 21:07:14 tinwhistle kernel: [9.680451] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) May 11 21:07:30 tinwhistle kernel: [11135.623084] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: errors=remount-ro May 11 21:07:56 tinwhistle kernel: [11161.524673] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) May 11 21:08:22 tinwhistle kernel: [11187.655296] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) May 11 21:09:05 tinwhistle kernel: [11231.262182] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: errors=remount-ro I believed at the time that it was being -- at least to the kernel -- mounted briefly and then immediately unmounted again. > - What exactly do you want to see changed, and what are your wording > suggestions? Ideally it would just work. Failing that, it would give a helpful error message. Failing that, a warning in the manpages. Thanks, and sorry for the lack of detail. John
Bug#960452: mount: Editing fstab in a valid way causes silent failure to mount
Package: mount Version: 2.33.1-0.1 Severity: important There are multiple issues reflected in this report: 1) That mount failed to properly mount a filesystem; 2) That it incorrectly said it had mounted it; 3) That running systemctl daemon-reload fixed the issue; 4) That neither the mount nor the fstab manpages mentioned this interaction I was recently migrating a server from LVM to md-raid. In the process, I made a new filesystem on /dev/md0, mounted it on /mnt, and copied /boot over to it on /mnt. I then unmounted /mnt and /boot, edited fstab to reflect the new location, and tried to mount it on /boot. mount -v /boot responded: mount: /dev/md0 mounted on /boot. However, /boot was still empty. df didn't show that it was mounted there, neither did /proc/mounts. These commands all produced similar results: mount -v /dev/md0 /boot mount -t ext4 /dev/md0 /boot However, this worked fine: mount -v /dev/md0 /mnt In other words, I could mount /dev/md0 at any location on the system EXCEPT /boot. Any attempt to mount something at /boot would indicate success but fail. Eventually, on a lark, I tried systemctl daemon-reload. After that, it mounted fine. Related information: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907536 requests documentation of the systemctl daemon-reload in fstab, but does not address the incorrect behavior of mount. https://github.com/systemd/systemd/issues/7291 states that the "raw util-linux commands still honour /etc/fstab directly", but that does not appear to be the case. Thanks, John -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mount depends on: ii libblkid1 2.33.1-0.1 ii libc6 2.28-10 ii libmount1 2.33.1-0.1 ii libselinux12.8-1+b1 ii libsmartcols1 2.33.1-0.1 ii util-linux 2.33.1-0.1 mount recommends no packages. Versions of packages mount suggests: ii nfs-common 1:1.3.4-2.5 -- no debconf information
Bug#959763: shadowsocks-libev: Security vulnerabilities in buster
Package: shadowsocks-libev Version: 3.2.5+ds-1 Severity: normal Tags: security Per https://github.com/shadowsocks/shadowsocks-libev/blob/master/debian/changelog : shadowsocks-libev (3.3.4-1) unstable; urgency=medium * Minor bug fixes. (#2539, #2565, #2566, #2577) * Security bug fixes. (CVE-2019-5163, CVE-2019-5164) It would be good to get this version, or at least these patches, into buster security updates. -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages shadowsocks-libev depends on: ii libbloom1 1.5-5 ii libc-ares2 1.14.0-1 ii libc6 2.28-10 ii libcap2-bin 1:2.25-2 ii libcork16 0.15.0+ds-12 ii libcorkipset1 1.1.1+20150311-8 ii libev4 1:4.25-1 ii libmbedcrypto3 2.16.0-1 ii libpcre32:8.39-12 ii libsodium23 1.0.17-1 ii lsb-base10.2019051400 shadowsocks-libev recommends no packages. Versions of packages shadowsocks-libev suggests: pn haveged pn kcptun pn simple-obfs -- no debconf information
Bug#950492: ITP: notcurses -- Character-mode graphics and TUI library
Very cool! (and apologies for missing it in the readme)
I have been rather annoyed at the increasing number of curses-like
libraries that only work with ANSI terminals. It is refreshing to see a
new one that properly supports terminfo!
I own a number of actual serial terminals from the 80s and 90s and
actively use them in various projects. They of course know nothing of
Unicode (another challenge) or color, but otherwise are still quite
functional.
Best,
John
On Mon, Feb 03 2020, Nick Black wrote:
> Your questions are answered in the README.md, I believe:
>
> https://github.com/dankamongmen/notcurses
>
> Yes, it is powered by (and requires) Terminfo. It ought work, more or less,
> with all terminals capable of cursor-based addressing ("cup" Terminfo
> capability). It quantizes color down at the moment in the absence of 24bit
> RGB support, but I plan to issue perfect palettes for terminals with the
> "ccc" capability Real Soon Now.
>
> On Mon, Feb 3, 2020, 19:47 John Goerzen wrote:
>
>> Hi Nick,
>>
>> This is interesting. Out of curiosity, does notcurses still support
>> terminfo and provide a functional implementation on non-ANSI terminals?
>> (eg, IBM3151, etc)
>>
>>
>> On Sun, Feb 02 2020, Nick Black wrote:
>>
>> > Package: wnpp
>> > Severity: wishlist
>> > Owner: Nick Black
>> >
>> > * Package name: notcurses
>> > Version : 1.1.4
>> > Upstream Author : Nick Black
>> > * URL : https://nick-black.com/dankwiki/index.php/notcurses
>> > * License : Apache-2.0
>> > Programming Lang: C, C++, Python
>> > Description : Character-mode graphics and TUI library
>> >
>> > notcurses facilitates the creation of modern TUI programs,
>> > making full use of Unicode and 24-bit direct color. It presents
>> > an API similar to that of Curses, and rides atop libtinfo.
>> >
>> > Work on notcurses began in November of 2019, and it has had
>> Debian-compatible
>> > infrastructure (debhelper compat level 12) from the beginning. As of
>> February
>> > 2020, it is rapidly stabilizing, and being used in several tools. I've
>> > rewritten my "growlight" disk management tool using notcurses instead of
>> > ncurses, cutting out several thousand lines of UI code along the way.
>> Nestopia
>> > is about to merge notcurses support (coming out of maintenance mode to
>> do so).
>> > I'm working on a console SDR visualization tool that will make working
>> with
>> > remote SDRs much more pleasant, and expect to release it soon.
>> >
>> > Sid/unstable debs are available (and have been available for weeks) in
>> my repo
>> > at https://www.dsscaw.com/apt (this repo is available in Wouter
>> Verhelst's
>> > extrepo tool). The Debian packaging that I currently have can be seen
>> here:
>> > https://github.com/dankamongmen/notcurses/tree/master/debian
>> >
>> > Notcurses can be regarded as a successor to ncurses. It provides much of
>> the
>> > functionality of that package, with major improvements IMHO regarding
>> Unicode,
>> > multithreading, and color support. 24-bit RGB with two bits of
>> transparency is
>> > the fundamental color space, and input/output are entirely based off
>> UTF8 and
>> > Unicode's Extended Grapheme Clusters. I've written many thousand lines of
>> > ncurses code in my life, and expect to write no more--notcurses will
>> entirely
>> > supplant it in my projects. ncurses is a venerable, robust library, with
>> a
>> > fantastic maintainer in Thomas E. Dickey, but it's fundamentally bound to
>> > X/OSI. It's time to move past 90s-era TUI APIs.
>> >
>> > As for maintaining the package, I've written 90%+ of the code in
>> notcurses, and
>> > intend to maintain it for the long haul. I'm actively committed to
>> maintaining
>> > the Debian/Ubuntu packaging, and indeed hope to use it as a springboard
>> towards
>> > Debian Developer status.
>> >
>> > notcurses has been included in Arch's AUR since its 0.4.0 release in
>> November
>> > 2019.
>>
>>
Bug#950492: ITP: notcurses -- Character-mode graphics and TUI library
Hi Nick, This is interesting. Out of curiosity, does notcurses still support terminfo and provide a functional implementation on non-ANSI terminals? (eg, IBM3151, etc) On Sun, Feb 02 2020, Nick Black wrote: > Package: wnpp > Severity: wishlist > Owner: Nick Black > > * Package name: notcurses > Version : 1.1.4 > Upstream Author : Nick Black > * URL : https://nick-black.com/dankwiki/index.php/notcurses > * License : Apache-2.0 > Programming Lang: C, C++, Python > Description : Character-mode graphics and TUI library > > notcurses facilitates the creation of modern TUI programs, > making full use of Unicode and 24-bit direct color. It presents > an API similar to that of Curses, and rides atop libtinfo. > > Work on notcurses began in November of 2019, and it has had Debian-compatible > infrastructure (debhelper compat level 12) from the beginning. As of February > 2020, it is rapidly stabilizing, and being used in several tools. I've > rewritten my "growlight" disk management tool using notcurses instead of > ncurses, cutting out several thousand lines of UI code along the way. Nestopia > is about to merge notcurses support (coming out of maintenance mode to do so). > I'm working on a console SDR visualization tool that will make working with > remote SDRs much more pleasant, and expect to release it soon. > > Sid/unstable debs are available (and have been available for weeks) in my repo > at https://www.dsscaw.com/apt (this repo is available in Wouter Verhelst's > extrepo tool). The Debian packaging that I currently have can be seen here: > https://github.com/dankamongmen/notcurses/tree/master/debian > > Notcurses can be regarded as a successor to ncurses. It provides much of the > functionality of that package, with major improvements IMHO regarding Unicode, > multithreading, and color support. 24-bit RGB with two bits of transparency is > the fundamental color space, and input/output are entirely based off UTF8 and > Unicode's Extended Grapheme Clusters. I've written many thousand lines of > ncurses code in my life, and expect to write no more--notcurses will entirely > supplant it in my projects. ncurses is a venerable, robust library, with a > fantastic maintainer in Thomas E. Dickey, but it's fundamentally bound to > X/OSI. It's time to move past 90s-era TUI APIs. > > As for maintaining the package, I've written 90%+ of the code in notcurses, > and > intend to maintain it for the long haul. I'm actively committed to maintaining > the Debian/Ubuntu packaging, and indeed hope to use it as a springboard > towards > Debian Developer status. > > notcurses has been included in Arch's AUR since its 0.4.0 release in November > 2019.
Bug#937449: Bug#947303: pygopherd: Python2 removal in sid/bullseye
Hello, I am actively working on a port to Python 3 for pygopherd. I expect to have it done in January. Please do not remove from sid. John On Mon, Dec 23 2019, Sandro Tosi wrote: > Source: pygopherd > Version: 2.0.18.5 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests, in details: > > (source:pygopherd)Build-Depends-Indep->python > (binary:pygopherd)Depends->python > (binary:pygopherd)Depends->python-simpletal > (binary:pygopherd)Depends->python:any > (binary:pygopherd)Depends->python:any > (binary:pygfarm)Depends->python-dictclient > > Please stop using Python2, and fix this issue by one of the following > actions. > > - Convert your Package to Python3. This is the preferred option. In > case you are providing a Python module foo, please consider dropping > the python-foo package, and only build a python3-foo package. Please > don't drop Python2 modules, which still have reverse dependencies, > just document them. > > This is the preferred option. > > - If the package is dead upstream, cannot be converted or maintained > in Debian, it should be removed from the distribution. If the > package still has reverse dependencies, raise the severity to > "serious" and document the reverse dependencies with the BTS affects > command. If the package has no reverse dependencies, confirm that > the package can be removed, reassign this issue to ftp.debian.org, > make sure that the bug priority is set to normal and retitle the > issue to "RM: PKG -- removal triggered by the Python2 removal". > > - If the package has still many users (popcon >= 300), or is needed to > build another package which cannot be removed, document that by > adding the "py2keep" user tag (not replacing the py2remove tag), > using the debian-pyt...@lists.debian.org user. Also any > dependencies on an unversioned python package (python, python-dev) > must not be used, same with the python shebang. These have to be > replaced by python2/python2.7 dependencies and shebang. > > This is the least preferred option. > > If there are questions, please refer to the wiki page for the removal: > https://wiki.debian.org/Python/2Removal, or ask for help on IRC > #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#942859: uucp: Very slow to start due to closing 1 million FDs
Package: uucp Version: 1.07-24 Severity: normal In an environment where ulimit -n is 1048576 (as is, for instance, the case for Docker and most likely other environments that don't have ulimit/rlimits set by something like systemd-system), most UUCP programs (including even uulog) try to close nearly all 1048576 possible fds. The culprit code appears to be in unix/init.c: /* Close everything but stdin, stdout and stderr. */ #if HAVE_GETDTABLESIZE cdescs = getdtablesize (); #else #if HAVE_SYSCONF cdescs = sysconf (_SC_OPEN_MAX); #else It's pretty gratuituous to try to do such a thing these days, especially since we have things like CLOEXEC and such now. I would suggest a sanity check, such that if cdescs is > 1024, to just set it down to 1024, for instance. I'm having a hard time coming up with a scenario in which this would represent a security issue. -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages uucp depends on: ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-1 ii cron 3.0pl1-134 ii cu1.07-24 ii libc6 2.28-10 ii libpam-runtime1.3.1-5 ii libpam0g 1.3.1-5 ii mailutils [mailx] 1:3.5-3 ii netbase 5.6 ii openbsd-inetd [inet-superserver] 0.20160825-4 Versions of packages uucp recommends: ii exim4 4.92-8+deb10u3 ii logrotate 3.14.0-4 uucp suggests no packages. -- Configuration Files: /etc/uucp/call [Errno 13] Permission denied: '/etc/uucp/call' /etc/uucp/passwd [Errno 13] Permission denied: '/etc/uucp/passwd' -- no debconf information
Bug#942818: uucp: Default configuration has incorrect short-packets definition
Package: uucp Version: 1.07-24 Severity: normal Hi, In the default /etc/uucp/sys, there is this line: protocol-parameter G short-packets This triggers errors like: uucico uucp1 - (2019-10-21 19:45:09.88 1305) ERROR: Error in G protocol parameters uucico uucp1 - (2019-10-21 19:45:09.88 1305) ERROR: syntax error Because short-packets requires a boolean parameter. Perhaps this should just be removed from the default file. -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages uucp depends on: ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-1 ii cron 3.0pl1-134 ii cu1.07-24 ii libc6 2.28-10 ii libpam-runtime1.3.1-5 ii libpam0g 1.3.1-5 ii mailutils [mailx] 1:3.5-3 ii netbase 5.6 ii openbsd-inetd [inet-superserver] 0.20160825-4 Versions of packages uucp recommends: ii exim4 4.92-8+deb10u3 ii logrotate 3.14.0-4 uucp suggests no packages. -- Configuration Files: /etc/uucp/call [Errno 13] Permission denied: '/etc/uucp/call' /etc/uucp/passwd [Errno 13] Permission denied: '/etc/uucp/passwd' -- no debconf information
Bug#942819: uucp: inetd should run uucp as user:group uucp:uucp
Package: uucp Version: 1.07-24 Severity: normal Hi, The default inetd.conf entry had uucpd running as root. It should be running as uucp:uucp instead. This is particularly important if, as documented, one replaces it with uucico -l, which needs to be in the uucp group to access /etc/uucp/passwd. -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages uucp depends on: ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-1 ii cron 3.0pl1-134 ii cu1.07-24 ii libc6 2.28-10 ii libpam-runtime1.3.1-5 ii libpam0g 1.3.1-5 ii mailutils [mailx] 1:3.5-3 ii netbase 5.6 ii openbsd-inetd [inet-superserver] 0.20160825-4 Versions of packages uucp recommends: ii exim4 4.92-8+deb10u3 ii logrotate 3.14.0-4 uucp suggests no packages. -- Configuration Files: /etc/uucp/call [Errno 13] Permission denied: '/etc/uucp/call' /etc/uucp/passwd [Errno 13] Permission denied: '/etc/uucp/passwd' -- no debconf information
Bug#942689: ITP: nncp -- Node to Node Copy for secure store-and-forward online and offline file and mail exchange
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: nncp Version : 4.1 Upstream Author : Sergey Matveev * URL : http://www.nncpgo.org/ * License : GPL Programming Lang: Go Description : Node to Node Copy for secure store-and-forward online and offline file and mail exchange NNCP is a package facilitating secure store-and-forward file and mail exchange. It can be thought of as a modern UUCP with Internet smarts. NNCP supports direct online communication over a LAN or Internet, scheduled communication, offline copies, streaming communication (pipes), and more. It can therefore be used for air-gapped computers that might be communicated with by CD-ROM, tape, or USB stick. It can also be used for intermittent or on-demand links, very slow or high latency links, etc. Like UUCP, NNCP supports routing messages via intermediate systems. With NNCP, however, all packets are end-to-end encrypted and authenticated, making this more proper onion routing -- the intermediate systems have no visibility to the content of the data being passed. NNCP also has robust tools for interrupted transfer resumption, handling of very large files, and verifying integrity of data copied off.
Bug#942240: ITP: glktermw -- Curses-based interface library for interactive fiction programs
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: glktermw Version : 1.0.4 Upstream Author : Andrew Plotkin * URL : https://www.eblong.com/zarf/glk/index.html * License : Custom permissive (DFSG-free) Programming Lang: C Description : Curses-based interface library for interactive fiction programs Glk is a device-independent interface specification intended primarily for interactive fiction implementations. This library provides an ncurses-based glk interface and includes Unicode support. It is used by packages such as glulxe.
Bug#942239: ITP: glulxe -- Interpreter for glulx interactive fiction
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: glulxe Version : 0.5.4 Upstream Author : Andrew Plotkin * URL : https://eblong.com/zarf/glulx/ * License : MIT Programming Lang: C Description : Interpreter for glulx interactive fiction glulxe is the authoritative interpreter for the Glulx interactive fiction VM, which is a 32-bit update of the older Z-Machine standard. This program can play games ending with .ulx, .gblorb, .glb, .blorb, and .blb. glulxe can work with only a terminal; the optional graphics in some Glulx games can be shown by using the package gargoyle-free instead.
Bug#941829: inform-mode: Can't type right bracket; complains about last-command-char
Package: inform-mode Version: 1.5.8-4 Severity: grave Justification: renders package unusable Whenever I attempt to type a right bracket -- a rather important operation in inform, as it ends a function -- I get: Symbol's value as variable is void: last-command-char According to https://stackoverflow.com/questions/18336117/void-variable-last-command-char-error-when-i-use-semantic-to-locate-symbol, in Emacs 24.3, it was removed and renamed to last-command-event. I suspect this is also addressed in the newer releases of inform-mode, as mentioned in #673376. - John -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages inform-mode depends on: ii emacsen-common 3.0.4 inform-mode recommends no packages. inform-mode suggests no packages. -- no debconf information
Bug#941443: openssh-client: Causes terminal corruption by disabling XON/XOFF unconditionally
On Mon, Sep 30 2019, Colin Watson wrote: > I think this needs to be forwarded upstream. I'm often happy to do that > on people's behalf when I understand a bug well and/or can reproduce it, > but in this case neither of those things is true. I also suspect that > working out the best fix is going to involve some back-and-forth between > you and upstream, and I'm going to add very little to that process other > than being a rather slow proxy. > > Would you consider filing this directly upstream > (https://bugzilla.mindrot.org/)? I know it's another account to create, > but I think it would work better. Hi Colin, That makes sense. I created the report here: https://bugzilla.mindrot.org/show_bug.cgi?id=3075 - John
Bug#941443: openssh-client: Causes terminal corruption by disabling XON/XOFF unconditionally
Package: openssh-client Version: 1:7.9p1-10 Severity: important Hello, I am using an original DEC vt420 serial terminal connected to a Debian box. As with many such terminals, it: 1) Is incapable of consistently processing incoming data, particularly if it contains escape sequences, at line rate if the line rate is above 4800bps (though it supports line rates up to 38400bps); 2) Supports only XON/XOFF flow control. I observed issues that were clearly related to flow control with sshing from it to other systems, although it was working fine locally. I narrowed it down to this code in sshtty.c:enter_raw_mode(): tio.c_iflag &= ~(ISTRIP | INLCR | IGNCR | ICRNL | IXON | IXANY | IXOFF); in other words, it unconditionally disables XON/XOFF handling on the local machine. You might be asking at this point: well, couldn't the remote handle it? And the answer is no, for several reasons: 1) The internal buffer on this terminal is tiny, far less than even the TCP packet size. It is quite possible -- likely, even -- that a large screen update already caused a packet to be transmitted from the remote end that will overflow the local buffer. 2) The latency in processing could mean that the remote sends enough text to overflow the terminal's buffer after the terminal sends XOFF. Other people from around the internet also report this issue. For instance: https://superuser.com/questions/1096862/ssh-and-xon-xoff-software-flow-control I recognize that there may be reasons to drop IXON and IXOFF by default, but they are not appropriate for situations in which IXON and IXOFF are legitimately needed. Perhaps a configuration option here? Thanks, John -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssh-client depends on: ii adduser 3.118 ii dpkg 1.19.7 ii libc6 2.28-10 ii libedit2 3.1-20181209-1 ii libgssapi-krb5-2 1.17-3 ii libselinux1 2.8-1+b1 ii libssl1.1 1.1.1c-1 ii passwd1:4.5-1.1 ii zlib1g1:1.2.11.dfsg-1 Versions of packages openssh-client recommends: ii xauth 1:1.0.10-1 Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere ii ssh-askpass 1:1.2.4.1-10 -- no debconf information
Bug#929834: Also seeing it with gdm3
Hi Folks, On a Dell Latitude with Intel graphics, running gnome flashback, I also saw this behavior after upgrading from stretch to buster. This laptop, however, is running gdm3, not lightdm. I am seeing the exact same symptoms, with VT switching generally working around the issue post-lock. So far, the workaround at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929834#66 has resolved this for me. I will update this bug if I see any further issues. John
Bug#934160: nfs-common: Umask ignored, all files created world-writable on NFS
Package: nfs-common Version: 1:1.3.4-2.5 Severity: grave Tags: security Justification: user security hole I have an NFS client and server both running Debian. I recently upgraded them both to buster. I discovered today that the regular process umask has been ignored on my nfs mounts since the upgrade, and all files and directories are being created a+rw. On the client, the fstab fstype is nfs4 and the mount options are hard,intr,bg,noatime. The relevant datasets are exported rw,no_root_squash,no_subtree_check from the server. In researching this, I stumbled across https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1779736 and https://bugzilla.redhat.com/show_bug.cgi?id=1667761 which indicate the problem is present elsewhere as well. Adding vers=4.1 to my client's mount options completely resolved the problem. (Though now I have a couple weeks' worth of files with unintentionally open permissions to wade through.) I tagged this as security and grave because it opens up quite a few scenarios for users to receive privileges they shouldn't, and for other potential mischief (placing malicious executables in world-writable directories, etc). The server is indeed running zfs with its default acltype setting (off). As the Ubuntu bug report shows, mounting with noacl doesn't resolve the behavior either. The RedHat bug occurred with an OpenWRT server, unlikely to be running zfs. I do not believe this bug should be pinned down to ZFS; a filesystem not supporting ACLs should not result in umask 0 for all clients in any scenario. -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper -- /etc/default/nfs-common -- NEED_STATD= STATDOPTS= NEED_IDMAPD= NEED_GSSD= -- /etc/idmapd.conf -- [General] Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs [Mapping] Nobody-User = nobody Nobody-Group = nogroup -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nfs-common depends on: ii adduser 3.118 ii keyutils1.6-6 ii libc6 2.28-10 ii libcap2 1:2.25-2 ii libcom-err2 1.44.5-1 ii libdevmapper1.02.1 2:1.02.155-3 ii libevent-2.1-6 2.1.8-stable-4 ii libgssapi-krb5-21.17-3 ii libk5crypto31.17-3 ii libkeyutils11.6-6 ii libkrb5-3 1.17-3 ii libmount1 2.33.1-0.1 ii libnfsidmap20.25-5.1 ii libtirpc3 1.1.4-0.4 ii libwrap07.6.q-28 ii lsb-base10.2019051400 ii rpcbind 1.2.5-0.3 ii ucf 3.0038+nmu1 Versions of packages nfs-common recommends: ii python 2.7.16-1 Versions of packages nfs-common suggests: pn open-iscsi pn watchdog -- no debconf information
Bug#927725: Please build with --enable-mmdblookup
On Tue, Apr 23 2019, Michael Biebl wrote: > Am 23.04.19 um 11:12 schrieb Michael Biebl: > >> But splitting each tiny module into a separate package adds significant >> overhead packaging-wise. > > (not to forget NEW round trips) What about an approach like exim4-daemon-light vs. exim4-daemon-heavy? Maybe have two rsyslogs, one of which has all the deps enabled and the other doesn't. John
Bug#914568: emacs25: Please build with xwidget support
Package: emacs25 Version: 25.1+1-4+deb9u1 Severity: normal Hi, Over at https://www.gnu.org/software/emacs/manual/html_node/emacs/Embedded-WebKit-Widgets.html , the xwidget-webkit-browse-url function is documented. C-h a also lists it, and it is apparently defined in xwidget.el. However, when I run M-x xwidget-webkit-browse-url, I get: "Your Emacs was not compiled with xwidgets support" Thanks, John -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages emacs25 depends on: ii emacs25-bin-common 25.1+1-4+deb9u1 ii gconf-service 3.2.6-4+b1 ii libacl12.2.52-3+b1 ii libasound2 1.1.3-5 ii libatk1.0-02.22.0-1 ii libc6 2.24-11+deb9u3 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libdbus-1-31.10.26-0+deb9u1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgconf-2-4 3.2.6-4+b1 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libgif75.1.4-0.4 ii libglib2.0-0 2.50.3-2 ii libgnutls303.5.8-5+deb9u3 ii libgomp1 6.3.0-18+deb9u1 ii libgpm21.20.4-6.2+b1 ii libgtk-3-0 3.22.11-1 ii libice62:1.0.9-2 ii libjpeg62-turbo1:1.5.1-2 ii libm17n-0 1.7.0-3+b1 ii libmagickcore-6.q16-3 8:6.9.7.4+dfsg-11+deb9u5 ii libmagickwand-6.q16-3 8:6.9.7.4+dfsg-11+deb9u5 ii libotf00.9.13-3+b1 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-01.40.5-1 ii libpng16-161.6.28-1 ii librsvg2-2 2.40.16-1+b1 ii libselinux12.6-3+b3 ii libsm6 2:1.2.2-1+b3 ii libtiff5 4.0.8-2+deb9u2 ii libtinfo5 6.0+20161126-1+deb9u2 ii libx11-6 2:1.6.4-3 ii libx11-xcb12:1.6.4-3 ii libxcb11.12-1 ii libxfixes3 1:5.0.3-1 ii libxft22.3.2-1+b2 ii libxinerama1 2:1.1.3-1+b3 ii libxml22.9.4+dfsg1-2.2+deb9u2 ii libxpm41:3.5.12-1 ii libxrandr2 2:1.5.1-1 ii libxrender11:0.9.10-1 ii zlib1g 1:1.2.8.dfsg-5 emacs25 recommends no packages. Versions of packages emacs25 suggests: ii emacs25-common-non-dfsg 25.1+1-1 -- no debconf information
Bug#570623: Submitted MR on Salsa
One additional comment - it would probably be good to default Limit: 1 to mimic prior behavior, wouldn't it? - John
Bug#570623: Submitted MR on Salsa
Hi folks, In case it makes things easier, I submitted https://salsa.debian.org/brlink/reprepro/merge_requests/1 which represents Benjamin's 5.2.0 patchset, unmodified, with his original commits from github. I'm just resubmitting it there in case it makes it easier to apply. Thanks, John
Bug#570623: Prognosis for integrating multiple version support into reprepro?
Hi folks, First of all, thanks to all of you for your work on reprepro. I am looking at a use case for which reprepro plus the profitbricks multiple version support looks ideal. However, as I want to set this up for long-term success without a lot of fiddling, I'm wondering what the prognosis is for getting this patch set integrated into reprepro itself. I don't see any comments in the bug log after either the 2017 or the 2018 patches, and am just wondering where things are? Is there something I could do to help move it along/ Thanks, John
Bug#910252: ITP: libnbcompat -- NetBSD compatibility library
On Sat, Oct 06 2018, Guillem Jover wrote: > I see the packages have already gone through NEW, so I've taken a > look. And I've almost got mtree-netbsd building using just libmd and > libbsd. I'll be releasing new upstream versions fixing or adding the > missing stuff: > > - libmd had bogus compat macros for SHA512, and missing ones for > SHA384. Hah - I was wondering about SHA512_File. Looked odd to me, but I figured something else must have that interface. > - libbsd is missing the pwcache modules from the BSDs, which I'll > be adding. > - libbsd is missing a that implicitly includes > , I'll be adding that. > > Then I've got some minimal patches for mtree-netbsd, which fix or improve > things there, that I'll be sending your way once I've finished with the > above. At which point I think it would be nice to drop libnbcompat > completely? That would be great, especially if the mtree patches really are minimal. > I really think libnbcompat should be completely unnecessary. :) And if > there'd be new features required my mtree-netbsd in the future I'm > always happy to consider new additions to these libraries if they make > sense! Sounds great. Appreciate it! - John > > Thanks, > Guillem
Bug#910252: ITP: libnbcompat -- NetBSD compatibility library
On Thu, Oct 04 2018, Guillem Jover wrote: > Hmm, what does this library provide that is required by mtree-netbsd not > available in glibc, libbsd and libmd? Perhaps even freebsd-glue? > > I've skimmed over the functionality and it seems most of it is already > covered by those. If there's still stuff needed I'm always happy to add > it to libbsd or libmd as required! Hi Guillem and Andrej, Thanks for your interest in this! You are correct that the functionality is generally available. The problem is that the interfaces are different. nbconfig.h, for instance, defines a number of HAVE_* macros that are used while building mtree. nbconfig.h includes a number of system header files (stdio.h, etc.) that cause *numerous* build errors if missing. There are also functions for things like hashing files that take different numbers of parameters, etc. I also considered, for a bit, whether to even make libnbcompat be a separate package. I concluded yes, because: 1) It has its own standalone configure, 2) It must be configured and built before mtree can be configured, 3) Even on NetBSD, mtree requires libnbcompat to build (the #include is not wrapped inside any conditional macro) Because of #1 and #2, just including it in mtree itself would cause the build system to somewhat violate the usual principles of how to build. It may also be of interest that FreeBSD recently imported NetBSD's mtree into their contrib tree, and switched their default mtree to NetBSD's. They still have the FreeBSD mtree (named fmtree, dovetailing nicely with freebsd-buildutils). I examined it for packaging instead of the one from the NetBSD tree. They don't use nbcompat, and ripped all of the things from nbcompat.h out (adding many #includes to their .c files, making FreeBSD-specific assumptions, etc.) They pulled out autoconf entirely. Basically, theirs is less portable, won't trivially track the NetBSD source, and will likely require more work to maintain over the long term. -- John
Bug#910253: ITP: nmtree -- Validates modes, ownership, and contents of directory tree against specification
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: mtree-netbsd Version : 20180822 Upstream Author : Joerg Sonnenberger and NetBSD contributors * URL : http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/pkgtools/mtree/README.html * License : BSD Programming Lang: C Description : Validates modes, ownership, and contents of directory tree against specification The mtree utility compares a file hierarchy against a specification, creates a specification for a file hierarchy, or modifies a specification. This specification can be controlled by the user, but typically includes file/directory/symlink names, ownership information, permission bits, and so forth. It may optionally also include various hashes, such as SHA-256 or MD5. . This mtree utility can understand its own files, as well as those generated by the FreeBSD mtree (in Debian as fmtree in freebsd-buildutils and freebsd-glue) and bsdtar/libarchive.
Bug#910252: ITP: libnbcompat -- NetBSD compatibility library
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: libnbcompat Version : 20180822 Upstream Author : Joerg Sonnenberger and the NetBSD PRoject * URL : http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/pkgtools/libnbcompat/README.html * License : BSD Programming Lang: C Description : NetBSD compatibility library libnbcompat is designed to let non-NetBSD operating systems execute code that is part of the NetBSD pkgsrc repository. It is, in particular, required for building the NetBSD mtree, which has some distinct advantages over the FreeBSD mtree already in the Debian repos and is being adopted by FreeBSD.
Bug#909451: pristine-tar: Be resilient in the face of hard links - simple patch?
Package: pristine-tar Version: 1.38 Severity: normal I have a use case that occurs on a filesystem where jdupes is used periodically to hardlink together duplicate files. The tree which tarballs will be used from contains such duplicates that may be hardlinked either before or after the delta is generated. GNU tar, by default, inserts special "link to" records for a the second and subsequent occurence of a reference to the same inode number. That such files may be hardlinked post-delta generation would cause the generated tarball to be unpredictable and therefore quite possibly broken. I believe the very simple fix would be to add --hard-dereference to the list of tar options in recreatetarball_helper. In the case that hard links were present in the tarball, xdelta ought to simply remove the extra data and no harm would be done. Thanks, John -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pristine-tar depends on: ii libbz2-1.0 1.0.6-8.1 ii libc6 2.24-11+deb9u3 ii perl5.24.1-3+deb9u4 ii tar 1.29b-1.1 ii xdelta 1.1.3-9.1+b1 ii xdelta3 3.0.11-dfsg-1+b1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages pristine-tar recommends: ii bzip2 1.0.6-8.1 ii pbzip21.1.9-1+b1 ii xz-utils 5.2.2-1.2+b1 pristine-tar suggests no packages. -- no debconf information
Bug#909403: freebsd-buildutils: Please use new FreeBSD mtree
Package: freebsd-buildutils Version: 10.3~svn296373-7 Severity: normal Hello, While working on an issue, I discovered that our fmtree can't deal with the output from our bsdtar. This turns out to be a known bug at https://github.com/archiecobbs/mtree-port/issues/5 which was corrected by FreeBSD switching to NetBSD's mtree at https://github.com/archiecobbs/mtree-port/issues/11 (https://lists.freebsd.org/pipermail/freebsd-current/2012-December/038697.html ). Thanks, John -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages freebsd-buildutils depends on: ii bsdmainutils 9.0.12+nmu1 ii freebsd-glue 0.2.22 ii freebsd-mk10.3~svn296373-6 ii libbsd0 0.8.3-1 ii libc6 2.24-11+deb9u3 ii libdb5.3 5.3.28-12+deb9u1 ii libmd00.0.0-2 ii libsbuf6 10.3~svn296373-9 ii m41.4.18-1 ii patchutils0.3.4-2 ii unzip 6.0-21 freebsd-buildutils recommends no packages. freebsd-buildutils suggests no packages. -- no debconf information
