Bug#1071443: unable to login as root at tty
Source: selinux-policy-default Version: 2:2.20221101-9 Severity: normal X-Debbugs-Cc: aeru...@aerusso.net Dear Maintainer, On a fresh bookworm installation, I have enabled selinux following [1]. I enabled enforcing mode, and tried to log in at the console tty (tty1, tty2, and tty6). journalctl -f shows an authentication error. Moreover, audit2why -al indicated that agetty was being denied when trying to use checkpoint_restore. I used audit2allow -m local to create a policy and then compile and load it. This eliminated the selinux denial audit event, but did not change the overall behavior: I cannot login as root at any ttys. I can, however, log in as regular user, and use su to elevate to root privileges, though. Creating a /etc/securetty file with tty0-tty6 and console does not change the situation. I've tried relabeling the filesystem several times. The remaining audit2why -al all seem innocuous: NetworkManager, run-parts, utmp, apcupds, ModemManager, wall The only possibly suspect one is comm="(spawn)" accessing files under /proc (scontext=system_u:system_r:udev_t:s0), thought I would think that's not a problem. I'm at a loss for what could be different between enforcing and permissive mode, and I'm not even sure what logs to look at. Best, Antonio [1] https://wiki.debian.org/SELinux/Setup OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071201: systemd 256~rc2-1
I can confirm this version of systemd breaks my system's boot as well. I don't have any modified journald.conf settings. I'm running dracut, and the image that is built fails to start systemd-modules-load.service Running systemd-modules-load (rd.shell=1 rd.break=cmdline) at the (dracut) shell gave Failed to initialize libkmod context: Operation not supported I (too) was able to roll back to systemd 255.5-1 (dpkg -i /var/cache/apt/archives/*255.5-1*deb) fully restoring the system. Best, Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071034: unversioned libuv1 Provides: is inadequate
Source: libuv1
Version: 1.48.0-3
Severity: serious
X-Debbugs-Cc: aeru...@aerusso.net
Dear Maintainer,
libuv1 version 1.48.0-3 has an unversioned Provides: libuv1 line, but packages
(such as cmake) have
versioned dependencies on libuv1. This is breaking cmake in unstable right now.
It appears that dpkg-dev version 1.22.5 (or later) allows you to use
Provides: ${t64:Provides}
to automatically generate the versioned Provides: line.
Best,
Antonio Russo
OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
Dear maintainer, This bug is (apparently?) currently preventing the amd64 build of 1.20.1-6. I apologize if this is already understood (by the way, is there somewhere on [1] or elsewhere to see if the build is being retried?). I'm also assuming I am not authorized to "give back" and trigger another build attempt. So, I'm asking for someone to please "give back" the build to the buildds, so that we can spin the roulette wheel and hopefully get a buildd with an ipv4 address. Best, Antonio Russo [1] https://tracker.debian.org/pkg/krb5 OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057688: aptitude: Stray input on window click when running under tmux
On 2023-12-08 09:01, Sven Joachim wrote: > > , > | @@ -8550,7 +8556,7 @@ tmux|tmux terminal multiplexer, > | use=ecma+italics, use=ecma+strikeout, use=xterm+edit, > | use=xterm+pcfkeys, use=xterm+sl, use=xterm+tmux, > | use=screen, use=bracketed+paste, use=report+version, > | - use=xterm+focus, > | + use=xterm+focus, use=xterm+sm+1006, > | > | tmux-256color|tmux with 256 colors, > | use=xterm+256setaf, use=tmux, > ` > > That seems to be not really intended and should likely be reverted, > given the issue at hand. I can confirm this change resolves the aptitude issue for me. I'll continue testing it. > >> (a change to the terminal description to help vim turned out to expose one >> of the VTE bugs - fixed by making it less likely for other applications >> to trigger the bug) > > There is no VTE involved in this case, I reproduced the problem in > xterm. > > Cheers, >Sven Thanks! Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057688: aptitude: Stray input on window click when running under tmux
Package: aptitude Version: 0.8.13-5 Severity: normal X-Debbugs-Cc: aeru...@aerusso.net Dear maintainer, If I run aptitude inside xterm, and click on an aptitude TUI element (say, a particular package), that package will be selected. If, instead, I am running aptitude inside tmux, and I click on said element, it appears many garbage characters are sent to aptitude, including probably m and M, (the symptom is the automatic install state of packages changes). If I manually set TERM=xterm inside the tmux window, everything works. Alternatively, outside of tmux, if I set TERM=tmux-256color I get the same bad behavior in aptitude. If I downgrade all ncurses packages to 6.4+20231016, I don't get this behavior. Maybe this bug should instead be assigned to ncurses? Best, Antonio Russo OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1053910: zfs: use zpool user properties instead of zfs user properties for scrub and trim cron scripts
What semantics are you thinking for handling upgrades? This does not appear to be a new zpool "feature", so we may want to support loading such a pool on an earlier version of our zfs packaging. How does this sound? - migrate the property if it exists (but do not remove the old, root filesystem one) - use the pool-level property if there's a conflict, but throw a warning if there's a discrepancy between the two - suggest people remove the old property if they don't need backwards compatibility in NEWS - in several version, start warning if the filesystem one is still around - several versions after that, stop even checking for the old property Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1053296: RFS: kcollectd/0.12.1-1 -- simple collectd graphing front-end for KDE
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "kcollectd": * Package name : kcollectd Version : 0.12.1-1 Upstream contact : Antonio Russo * URL : https://www.antonioerusso.com/projects/kcollectd * License : GFDL-1.3+, PUBLIC-DOMAIN, GPL-3+ * Vcs : https://salsa.debian.org/qt-kde-team/extras/kcollectd Section : utils The source builds the following binary packages: kcollectd - simple collectd graphing front-end for KDE To access further information about this package, please visit the following URL: https://mentors.debian.net/package/kcollectd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/k/kcollectd/kcollectd_0.12.1-1.dsc Changes since the last upload: kcollectd (0.12.1-1) unstable; urgency=medium . * New upstream release 0.12.1. - Align translations with source code (Closes: #1048793) * Bump Standards-Version to 4.6.2, no changes required. Best, Antonio Russo OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1051994: RFS: inkscape-textext/1.9.0-1 -- Re-editable LaTeX graphics for Inkscape
On 2023-09-22 07:29, Boyuan Yang wrote: > > You claimed that you are trying to validate upstream signatures, yet your > .dsc file as presented > on mentors.debian.net does not include tarball signature at all. Lintian is > also complaining > orig-tarball-missing-upstream-signature inkscape-textext_1.9.0.orig.tar.xz. > Do you want to try > to fix this problem, or let us upload the current version as-is first? > > Thanks, > Boyuan Yang Hello, Thanks for looking at this! Upstream does not release signed tarballs as far as I can tell. They sign git tags. I am using pgpmode=git for uscan. Is this the correct way to handle this? I have confirmed that uscan fails if I change upstream/signing-key.asc to another key : > gpgv: Signature made Wed Jul 26 03:24:55 2023 MDT > gpgv:using RSA key 32746E27876C1E5418BBBF7F7A9964831E98EED5 > gpgv: Can't check signature: No public key > uscan die: OpenPGP signature did not verify. at > /usr/share/perl5/Devscripts/Uscan/Output.pm line 77. I assume that means it is actually verifying the signature. Should I add a lintian override to capture this situation? Best, Antonio Russo OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1041742: RFS: keepassxc-proxy-client/0.1.7-1 [ITP] -- Library to access a running KeepassXC instance
Dear mentors, I am looking for a sponsor for my package "keepassxc-proxy-client": * Package name : keepassxc-proxy-client Version : 0.1.7-1 Upstream contact : Henrik Böving * URL : https://github.com/hargoniX/keepassxc-proxy-client * License : ISC * Vcs : https://salsa.debian.org/aerusso-guest/keepassxc-proxy-client Section : python Description : Library to access a running KeepassXC instance KeepassXC is a password manager which exposes a interface to allow access-conntroled retrieval of passwords from its secure storage. keepassxc-proxy-client is a Python library that can speak this protocol, allowing programmatic access to passwords in the database. This packages also includes a simple CLI client build using the library. I am re-posting this RFS for this very small library in the hopes that I can get some feedback on the packaging. The source builds the following binary packages: keepassxc-proxy-client - Library to access a running KeepassXC instance To access further information about this package, please visit the following URL: https://mentors.debian.net/package/keepassxc-proxy-client/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/k/keepassxc-proxy-client/keepassxc-proxy-client_0.1.6-1.dsc Changes for the initial release: keepassxc-proxy-client (0.1.7-1) unstable; urgency=medium . * Initial release (Closes: #1041718) Best, Antonio Russo OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1051994: RFS: inkscape-textext/1.9.0-1 -- Re-editable LaTeX graphics for Inkscape
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: aeru...@aerusso.net Dear mentors, I am looking for a sponsor for my package "inkscape-textext" * Package name: inkscape-textext Version : 1.9.0-1 Upstream Author : Jan Winkler * URL : https://textext.github.io/textext * License : BSD-3-clause * Vcs : https://salsa.debian.org/aerusso-guest/textext Section : graphics Description : Re-editable LaTeX graphics for Inkscape TexText is a Python plugin for the vector graphics editor Inkscape providing the possibility to add and re-edit LaTeX generated SVG elements to your drawing. Key features . Windows/Linux/MacOS support . LaTeX generated SVG elements can be re-edited later . Multi-line editor with syntax highlighting . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex . Interoperable scaling in TexText and Inkscape . Font size match with Inkscape text . Customizable TeX preamble (additional packages, parskip, parindent, etc.) . Colorization via TeX commands/Inkscape is kept after re-editing . Alignment anchor of the produced output . Preview images It builds the binary packages: inkscape-textext - Re-editable LaTeX graphics for Inkscape inkscape-textext-doc - Re-editable LaTeX graphics for Inkscape (documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/inkscape-textext/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/inkscape-textext/inkscape-textext_1.9.0-1.dsc Changes since the last upload: inkscape-textext (1.9.0-1) experimental; urgency=medium . * New upstream release * Refresh patches * Update debian/copyright * Bump standards version (no changes required) * Drop support for inkscape <1.3, matching upstream * Simplify build scripts * Validate upstream signatures * Relax architecture dependencies This upload is primarily to track upstream releases. Most notably, upstream has dropped support for inkscape <1.3, and I am tracking that change here. Best, Antonio Russo OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1041742: RFS: keepassxc-proxy-client/0.1.6-1 [ITP] -- Library to access a running KeepassXC instance
Hello all, Upstream has released another version incorporating a typo lintian found, and now pushes version tags (but does not yet have a gpg key to sign them). I've updated the packaging and pushed another release to mentors: https://mentors.debian.net/package/keepassxc-proxy-client/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/k/keepassxc-proxy-client/keepassxc-proxy-client_0.1.7-1.dsc All changes are squashed into the initial release: keepassxc-proxy-client (0.1.7-1) unstable; urgency=medium . * Initial release (Closes: #1041718) Best, Antonio Russo OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1041742: RFS: keepassxc-proxy-client/0.1.6-1 [ITP] -- Library to access a running KeepassXC instance
Package: sponsorship-requests Severity: wishlist Control: block 1041718 by -1 Dear mentors, I am looking for a sponsor for my package "keepassxc-proxy-client": * Package name : keepassxc-proxy-client Version : 0.1.6-1 Upstream contact : Henrik Böving * URL : https://github.com/hargoniX/keepassxc-proxy-client * License : ISC * Vcs : https://salsa.debian.org/aerusso-guest/keepassxc-proxy-client Section : python The source builds the following binary packages: keepassxc-proxy-client - Library to access a running KeepassXC instance To access further information about this package, please visit the following URL: https://mentors.debian.net/package/keepassxc-proxy-client/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/k/keepassxc-proxy-client/keepassxc-proxy-client_0.1.6-1.dsc Changes for the initial release: keepassxc-proxy-client (0.1.6-1) unstable; urgency=medium . * Initial release (Closes: #1041718) Best, Antonio Russo OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1041718: ITP: keepassxc-proxy-client -- Library to access a running KeepassXC instance
Package: wnpp Severity: wishlist Owner: Antonio Russo X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: keepassxc-proxy-client Version : 0.1.6 Upstream Contact: Henrik Böving * URL : https://github.com/hargoniX/keepassxc-proxy-client * License : ISC Programming Lang: Python Description : Library to access a running KeepassXC instance KeepassXC is a password manager which exposes an interface to allow access-controlled retrieval of passwords from its secure storage. keepassxc-proxy-client is a Python library that can speak this protocol, allowing programmatic access to passwords in the database. This packages also includes a simple CLI client built using the library. Best, Antonio Russo
Bug#1034395: libkf5kcmutils-dev: need fix incorrect symlink
control: tag -1 patch This breaks builds of many things including, e.g., kwin. I'm attaching couc...@debian.org 's patch, which fixed 5.103.0-3, but apparently never got into the git repository. Best, Antonio Russo (hello other Antonio!) --- ../kcmutils/debian/libkf5kcmutils-bin.install 2023-06-19 16:10:51.039117308 -0600 +++ kcmutils-5.103.0/debian/libkf5kcmutils-bin.install 2023-02-28 04:48:46.0 -0700 @@ -1 +1 @@ -usr/lib/*/libexec/kf5/kcmdesktopfilegenerator usr/libexec/kf5/kcmdesktopfilegenerator +usr/lib/*/libexec/kf5/kcmdesktopfilegenerator usr/libexec/kf5 OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1034022: zfs filesystems are mounted before local filesystems
Hello, This is the use case for the zfs-mount-generator(8). The man page EXAMPLES section has a quick start guide. Best, Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1032950: usrmerge: Can't rename /lib during aptitude upgrade from bullseye under WSL
retitle -1 dpkg continues to perform setup after usrmerge directory fails thanks This was a WSL1 install of Debian, which is buggy [1] (but I do no want to be the focus of this bug report). (The /lib directory genuinely cannot be renamed, or something. Who knows what/how exactly WSL1 butchered things.) I still think this bug report represents a defect in usrmerge: the install process should have halted after that warning. It at least appeared that dpkg continued setting things up after that warning. Especially since dpkg/apt/aptitude tried a second time to do the usrmerge setup (which is normally a good idea for regular packages, IMO.) Antonio [1] https://github.com/microsoft/WSL/issues/4279
Bug#1032950: usrmerge: Can't rename /lib during aptitude upgrade from bullseye under WSL
Package: usrmerge Version: 35 Severity: important X-Debbugs-Cc: aeru...@aerusso.net Dear Maintainer, Under WSL, I installed Debian bullseye (months? a year? ago), and have now decided to upgrade it to bookworm. My process was: 1. s/bullseye/bookworm/g for /etc/apt/sources.list 2. apt update 3. apt install aptitude 4. Using the aptitude TUI, upgraded everything. (in retrospect, I understand that installing aptitude might seem weird, and may in fact be what precipitated this bug) During the install process, I got "FATAL ERROR: Can't rename /lib" permission denied error in convert-usrmerge. dpkg/aptitude continued to try to set things up (despite the "do not install or update" anything else bold warning). Some other packages "successfully" installed. Then, usrmerge tried again (and failed) to install. It looks like at a minimum, a better mechanism to stop dpkg from doing anything while usrmerge has failed is in order. I cannot play around on this system, unfortunately, so I will be untangling the /lib mess, installing either usrmerge or usr-is-merged (after doing it by hand), and finishing the upgrade. Best, Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1028284: [Pkg-zfsonlinux-devel] Bug#1028284: zfs-dkms: build fails for linux-headers-6.1.0-1-amd64
On 1/9/23 01:48, Achim Schaefer wrote: > Package: zfs-dkms > Version: 2.1.7-1 > Severity: important > X-Debbugs-Cc: bts.debian@schaefer-home.eu > > > When installing the new 6.1 kernel headers, dkms starts to build the zfs > module, but fails: > configure: creating ./config.status > config.status: creating Makefile > config.status: creating include/Makefile > config.status: creating include/os/Makefile > config.status: creating include/os/linux/Makefile > config.status: creating include/os/linux/kernel/Makefile > config.status: creating include/os/linux/kernel/linux/Makefile > config.status: creating include/os/linux/spl/Makefile > config.status: creating include/os/linux/spl/rpc/Makefile > config.status: error: cannot find input file: > `include/os/linux/spl/sys/Makefile.in' Hello, Can you please check that /usr/src/zfs-2.1.7/include/os/linux/spl/sys/Makefile.in actually exists on your installation? I.e., run ls -l /usr/src/zfs-2.1.7/include/os/linux/spl/sys/Makefile.in If that does not exist, please reinstall zfs-dkms; the file was somehow deleted. On an unrelated note: BTS 1028242 means that some temporary files on ZFS with Linux 6.1 will not work. (This should not be related to your compiling issue at all, though). Best, Antonio Russo
Bug#1028242: zfs-linux: open with O_TMPFILE flag fails on Linux 6.1
Package: src:zfs-linux Version: 2.1.7-1 X-Debbugs-Cc: aeru...@aerusso.net Severity: important Tags: patch Dear Maintainer, This bug is reported upstream at [1], resolved in [2], and backported to 2.1.7 in (the last patch of) [3] ([3] has not yet been accepted or reviewed). I've put this at important severity since it is a regression and could conceivable lead to difficult to debug problems. Briefly, the interface to tmpfile() interface in the kernel was adjusted to use a struct file rather than a struct dentry. The adjustment is relatively straightforward. Best, Antonio Russo [1] https://github.com/openzfs/zfs/issues/14301 [2] https://github.com/openzfs/zfs/commit/d27c81847b43584483b5509ff352e7e727b0ce87 [3] https://github.com/openzfs/zfs/pull/14357
Bug#1026848: apt-cacher-ng: Two fixes for erroneous tagging
On 1/8/23 09:22, Eduard Bloch wrote:
>
> Thanks. Regarding the second patch, I am not sure. Looks like my C++
> also has become rusty in the last months. It would be good to have an
> explicit description of the problem cases, since I don't know exactly
> what you mean with "streaming". I.e. it seems like you want the generic
> parser implementation to be changed to a specialized local one but how
> am I supposed to write a unit test for this?
>
> To be checked in the next days, stay tuned.
>
> Best regards,
> Eduard.
Sorry, I was in a bit of a hurry when I wrote that email.
The purpose of the second patch is to properly parse the list of packages
sources, e.g. [1]. Those files are concatenations of RFC822 blocks,
separated by blank lines. The previous implementation did not work,
because it did not account for the fact that all of these separate blocks
are of importance to us.
In particular, ParseDebianRfc822Index, line 1995 of src/cacheman.cc:
// we don't merge
justifies the next statement:
pLastVal->clear();
That serves to remove the last block's information (rather than merge it
with the last package). The symptom of this error in parsing is that
all Sources blocks (except the last one, which is not clobbered by any
subsequent blocks) are not identified as referencing data in the cache.
Therefore most of the, e.g., .tar{,.gz,.xz,.bzip2} and .dsc files are
marked for expiration from the cache.
I have added a new implementation in the same spirit as the one used for
Packages parsing, (see src/cacheman.cc:1707). In that branch of the
switch statement (EIDX_PACKAGES), each RFC822 block is parsed. I used
the word "streaming" to indicate that the whole index does not need to
be loaded into memory before the first call to ret(info) begins returning
data to the rest of the service.
While good for the overall performance of apt-cacher-ng, this streaming
behavior is not the primary purpose of the patch (and I apologize for
overemphasizing that in the title). Indeed, it is the correctness of
the result that is my main objective here.
As for writing a unit test, I would suggest grabbing some subset of [1],
and ensuring that all of the entries are properly accounted for. Without
this patch, such a unit test would fail.
Best,
Antonio
[1] http://ftp.us.debian.org/debian/dists/bookworm/main/source/Sources.gz
OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1028174: zfs-linux FTBFS due to python3-packaging
Package: src:zfs-linux Version: 2.1.7-1 X-Debbugs-Cc: aeru...@aerusso.net Severity: grave Tags: patch The recent upgrade of python3-packaging from 21.3-1.1 to 22.0-2 breaks packaging.version.LegacyVersion (specifically, it removed it). The configure script will fail because it tries to use the unavailable class. Matthew Ahrens has fixed this with upstream commit b72efb751 [1]. Best, Antonio Russo [1] https://github.com/openzfs/zfs/commit/b72efb751147ab57afd1588a15910f547cb22600
Bug#1027167: apt-cacher-ng: unix domain sockets don't work
Package: apt-cacher-ng
Version: 3.6.4-1
X-Debbugs-Cc: aeru...@aerusso.net
Severity: normal
Tags: patch upstream
Dear maintainer,
This is a composite of three bug reports, all closely related to the use of
unix domain sockets instead of tcp.
1. The tcp listener cannot be disabled, due to an erroneous reapplication of the
default port. The attached patch should fix this (previously, this variable was
a string describing the port, rather than the actual integer value).
2. When a unix domain socket connection is created, szClientName may be null.
The current behavior is to set that string to "", which prevents it from being
handled correctly by the rest of the infrastructure. The attached patch sets
the string to the sentinel value "0", which should never be a valid hostname or
ip address. This may not be ideal, but it does illustrate problem and one
solution.
3. acngtool cannot properly connect to a unix domain socket. Unix domain socket
connections cannot be reused, as alluded to in the empty
TUdsFactory::RecycleIdleConnection.
However, the udsconnection::tcpconnect function (which does in fact create a
unix
domain socket connection), passes a request to get / from the acng server.
This dooms that connection to uselessness, and results in acngtool falling back
to
the tcp connection code path. If that is also disabled, the tool hangs for a
very long time. The attached patch avoids this first / lookup, making the tool
work with unix domain sockets.
Best,
Antonio Russocommit 3c8d91146b9acfa5ab42e4c2496038185b86f95d
Author: Antonio Russo
Date: Mon Dec 26 12:31:48 2022 -0700
Do not override disabled tcp listener
diff --git a/src/acfg.cc b/src/acfg.cc
index a137ac2..2a64348 100644
--- a/src/acfg.cc
+++ b/src/acfg.cc
@@ -702,9 +702,6 @@ void PostProcConfig()
{
remotedb::GetInstance().PostConfig();
- if(!port) // heh?
- port=ACNG_DEF_PORT;
-
if(connectPermPattern == "~~~")
connectPermPattern="^(bugs\\.debian\\.org|changelogs\\.ubuntu\\.com):443$";
diff --git a/src/conserver.cc b/src/conserver.cc
index 6ca6639..afa7d26 100644
--- a/src/conserver.cc
+++ b/src/conserver.cc
@@ -207,6 +207,8 @@ std::string scratchBuf;
unsigned setup_tcp_listeners(LPCSTR addi, uint16_t port)
{
LOGSTARTFUNCxs(addi, port);
+ if(!port)
+ return 0;
USRDBG("Binding on host: " << addi << ", port: " << port);
auto hints = addrinfo();
commit 080a5aecd9fbc9161e677ffcdbc600580fee5540
Author: Antonio Russo
Date: Sat Dec 24 08:32:14 2022 -0700
Send sentinel client name for unix domain sockets
diff --git a/src/conserver.cc b/src/conserver.cc
index b47a548..6ca6639 100644
--- a/src/conserver.cc
+++ b/src/conserver.cc
@@ -53,7 +53,8 @@ SHARED_PTR g_tpool;
void SetupConAndGo(unique_fd&& man_fd, const char *szClientName, const char *portName)
{
LOGSTARTFUNCs;
- string sClient(szClientName ? szClientName : "");
+ // szClientName is null exactly when this is a unix domain socket
+ string sClient(szClientName ? szClientName : "0");
USRDBG("Client name: " << sClient << ":" << portName);
try
{
commit 4e71a6542351e688855bc05349c17d2633c5d36c
Author: Antonio Russo
Date: Wed Dec 28 11:06:15 2022 -0700
UDS connections cannot be reused
diff --git a/src/acngtool.cc b/src/acngtool.cc
index 19373ff..14e330f 100644
--- a/src/acngtool.cc
+++ b/src/acngtool.cc
@@ -533,14 +533,6 @@ struct TUdsFactory : public ::acng::IDlConFactory
failed = true;
return;
}
-// basic identification needed
-tSS ids;
-ids << "GET / HTTP/1.0\r\nX-Original-Source: localhost\r\n\r\n";
-if (!ids.send(m_conFd))
-{
- failed = true;
- return;
-}
}
};
auto ret = make_shared();
Bug#1026848: apt-cacher-ng: Two fixes for erroneous tagging
Package: apt-cacher-ng
X-Debbugs-Cc: aeru...@aerusso.net
Severity: important
Tags: patch upstream
Dear maintainer,
In bug 1026395, I identified behavior where apt-cacher-ng was tagging many
valid, referenced files for deletion. One cause is mentioned there. However,
I failed to notice another source of erroneous tagging: SHA256 sums in
the Packages/Sources/etc. files are not being detected.
For examples, debrep/dists/bullseye-backports/main/binary-amd64/Packages,
contains "^SHA256: " lines that are not being used.
The first of the two patches fixes that behavior for Packages.
During this process, a third source showed up: the lists of files in Sources
was getting clobbered because of the behavior of
cacheman.cc:ParseGenericRfc822File
("we don't merge").
The second patch implements streaming handling of Sources a la Packages. That
patch parses possibly untrusted data, so please give it a close read (also I
haven't done a lot of C++ coding recently, so I apologize in advance).
I'm tagging this important because most files for bookworm (and later) will
be automatically purged after a few days, since they are found to never be
referenced. This has significant impact on many use cases for this package.
Best,
Antonio Russodiff --git a/src/cacheman.cc b/src/cacheman.cc
index 43d8f12..940be40 100644
--- a/src/cacheman.cc
+++ b/src/cacheman.cc
@@ -1700,7 +1700,7 @@ bool cacheman::ParseAndProcessMetaFile(std::functioncommit 5d03dc3da84531a3902536b2e9fed01d5eb54e23
Author: Antonio Russo
Date: Thu Dec 22 04:41:14 2022 -0700
Streaming support for Sources
Signed-off-by: Antonio Russo
diff --git a/src/cacheman.cc b/src/cacheman.cc
index 940be40..52f3a38 100644
--- a/src/cacheman.cc
+++ b/src/cacheman.cc
@@ -1695,6 +1695,7 @@ bool cacheman::ParseAndProcessMetaFile(std::function=STEP) SendChunk("\n");});
+ CSTYPES current_cstype = CSTYPES::CSTYPE_INVALID;
switch(idxType)
{
@@ -1911,8 +1912,55 @@ bool cacheman::ParseAndProcessMetaFile(std::function.");
+
+ if (sLine.empty())
+ {
+current_cstype = CSTYPES::CSTYPE_INVALID;
+continue;
+ }
+
+ if (isspace((unsigned) (sLine[0])))
+ {
+if(current_cstype == CSTYPES::CSTYPE_INVALID)
+ continue;
+
+trimBoth(sLine);
+info.fpr.csType = current_cstype;
+if(ParseDebianIndexLine(info, sLine)) {
+ info.sDirectory=sPkgBaseDir;
+ ret(info);
+}
+info.SetInvalid();
+continue;
+ }
+
+ current_cstype = CSTYPES::CSTYPE_INVALID;
+
+ if (ParseKeyValLine(sLine, key, val))
+ {
+if(key==sSrcMD5)
+ current_cstype = CSTYPE_MD5;
+else if(key==sSrcSHA256)
+ current_cstype = CSTYPE_SHA256;
+else
+ continue;
+ }
+ }
+ break;
case EIDX_TRANSIDX:
return ParseDebianRfc822Index(reader, ret, sBaseDir, sPkgBaseDir,
EIDX_TRANSIDX, CSTYPES::CSTYPE_SHA1, "SHA1", byHashMode);
Bug#1026395: [apt-cacher-ng] All files tagged for removal
I must have somehow managed to run an expiration task while there weren't package files. This presumably caused the files to be tagged for deletion. When they became referenced again, apt-cacher-ng still wants to delete them. I'm leaving this bug open as a wishlist because it's trivial to work around (just delete _expending_dat), but it might be nice for this to be automated for people. Thanks for the great software! Antonio
Bug#1026395: [apt-cacher-ng] All files tagged for removal
Package: apt-cacher-ng X-Debbugs-Cc: aeru...@aerusso.net Version: 3.7.4-1~bpo11+1 Severity: normal Dear Maintainer, During a manual run of acng expiration scan, I'm finding acng wants to remove basically all the cached files. As a specific example, it's parsing bullseye/main/binary-amd64: Parsing metadata in debrep/dists/bullseye/main/binary-amd64/Packages.xz which contains Package: wireshark-qt Source: wireshark Version: 3.4.10-0+deb11u1 but yet, apt-cacher-ng decides to tag that deb for deletion: Tagging debrep/pool/main/w/wireshark/wireshark-qt_3.4.10-0+deb11u1_amd64.deb There are no other copies of that file. However, that file is also referenced by: secdeb/dists/bullseye-security/main/binary-amd64/Packages.xz As a possible cause of this, I will add that I was getting some 404 errors that were blocking tagging for removal, so I removed debrep/dists and secrep/dists, and then re-downloaded the index files (by removing /var/lib/apt/lists on a client and running an apt-get update). Is it possible this broke something? Best, Antonio
Bug#1021855: RFS: inkscape-textext/1.8.2-1 -- Re-editable LaTeX graphics for Inkscape
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: aeru...@aerusso.net Dear mentors, I am looking for a sponsor for my package "inkscape-textext" * Package name: inkscape-textext Version : 1.8.2-1 Upstream Author : Jan Winkler * URL : https://textext.github.io/textext * License : BSD-3-clause * Vcs : https://salsa.debian.org/aerusso-guest/textext Section : graphics Description : Re-editable LaTeX graphics for Inkscape TexText is a Python plugin for the vector graphics editor Inkscape providing the possibility to add and re-edit LaTeX generated SVG elements to your drawing. Key features . Windows/Linux/MacOS support . LaTeX generated SVG elements can be re-edited later . Multi-line editor with syntax highlighting . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex . Interoperable scaling in TexText and Inkscape . Font size match with Inkscape text . Customizable TeX preamble (additional packages, parskip, parindent, etc.) . Colorization via TeX commands/Inkscape is kept after re-editing . Alignment anchor of the produced output . Preview images It builds the binary packages: inkscape-textext - Re-editable LaTeX graphics for Inkscape inkscape-textext-doc - Re-editable LaTeX graphics for Inkscape (documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/inkscape-textext/ Alternatively, one can download the package with dget using this command: dget -x hhttps://mentors.debian.net/debian/pool/main/i/inkscape-textext/inkscape-textext_1.8.2-1.dsc Changes since the last upload: inkscape-textext (1.8.2-1) unstable; urgency=medium . * New upstream release * Refresh patches * Do not compress changelog in -doc package * Update debian/copyright * Bump standards version (no changes required) * Debian Janitor: clean up metadata This upload is primarily to track upstream releases. A few minor packaging issues were addressed, none, however, should be end-user visible. Best, Antonio Russo
Bug#1017419: inkscape-textext: Please package new upstream version (1.8.1)
I've pushed packaging for 1.8.2 to salsa [1]. I don't presently have a testing/unstable system to test this with, (and I wasn't able to trivially backport 1.2.1), so I can only confirm it works on 1.0.2-4 and 1.1.2-3~bpo11+1. If anyone confirms this works on unstable, I'll push it out. Otherwise it may be a while before I migrate any machines to testing. Antonio [1] https://salsa.debian.org/aerusso-guest/textext OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#992219: [Pkg-zfsonlinux-devel] Bug#992219: zfs-dkms: Error! Bad return status for module build on kernel: 5.13.0-trunk-amd64 (x86_64)
Control: severity -1 wishlist Control: retitle -1 Please backport support for 5.13 Hello, ZFS 2.0.3 doesn't support 5.13. Neither does 2.0.5, (which is a matter of some friction). You'll have to switch to 2.1 if you can't wait -- and I haven't gotten around to packaging it yet. - Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#992208: firefox-esr: Advertises for proprietary services
Hello, Those instructions don't quite work. It did, however, lead me how to figure it out (thank you). If you want to do this, you have to: 1. Open ANOTHER tab (try it if you don't believe me, you have to do this) 2. On that tab, a section called "top sites" will appear. Tab to the site you would like to get ride of, and then hit tab one more time. A HIDDEN ... menu appears. Alternatively, hover over the top right of the icon of the site to see the ... menu. 3. Click it, and then select dismiss. This doesn't address my other points about non-freedom respecting sites being advertised by Debian, nor about the ability to remove this for deployed systems. Should I open another bug, or are you indicating that is some kind "won't fix"? I can provide the patches to fix this. - Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#992208: firefox-esr: Advertises for proprietary services
Package: firefox-esr X-Debbugs-Cc: aeru...@aerusso.net Version: 78.13.0esr-1~deb11u1 Severity: normal Dear Maintainer, * What led up to the situation? Install firefox-esr, remove any old profiles, start the program, and click in the URL bar. Advertisements for several non-free online platforms are displayed. These cannot (apparently) be removed by accessing settings, at least easily (see below). * What exactly did you do (or not do) that was effective (or ineffective)? Pressing the arrow keys to select any of the advertised sites, and pressing delete and/or shift-delete do nothing. Disabling Amazon in the search engines also failed to remove its advertisement (though it did indeed remove it as an enabled search engine). * What was the outcome of this action? Debian is advertising non-free and non-freedom respecting services. * What outcome did you expect instead? No such advertisements. At a minimum, the ability to remove/preset these sites, in particular in an automated fashion when deploying to many machines. If desired, I can provide the patch to remove these advertisements, or, if we can agree on such a list, a replacement set of websites to show. - Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#991896: New upstream version 2.1.0 available
With the release coming up, I don't think anyone has made getting new versions of software into Debian a major priority. (So that's the excuse this time!) (Post-release) As for 2.1, I'd like to get this into experimental -- and I'd like to keep unstable/bookworm on 2.0, since my understanding is that it is long-term stable, while 2.1 is short- term stable. If it turns out that 2.1 gets kernel compatibility updates faster/ more reliably than 2.0, I think that's a good argument to jumping to 2.1. But, some of the features in 2.1 look like they might be high-risk. I'm personally not moving to 2.1 for a while, for this reason. (This is just me musing right now, I'm certainly not able to give an official answer). Best, Antonio
Bug#989373: zfs-linux: Extra iov_iter_advance may lead to memory corruption
Source: zfs-linux Version: 2.0.1-1 Severity: grave Tags: upstream Justification: causes data loss X-Debbugs-Cc: aeru...@aerusso.net See Brian Behlendof's comment at [1], in the merge request for commit 3f81aba76, referencing the analysis of the bug report [2]. In summary: a kernel buffer iterator can be advanced beyond its end. On kernels 5.12 and later, a safety mechanism has been created that detects this error, but as of 5.10, this mechanism is not present (AFAICT). The aforementioned commit addresses the issue, and has also been applied to 2.0.5-staging (as 3e0bc63e1). As of now, no released version of ZFS addresses this issue. There is a suggestion that this could lead to memory corruption, which seems plausible. The lack of widespread data loss under ZFS 2.0 to date suggests that any corruption is relatively minor. [1] https://github.com/openzfs/zfs/pull/12155#issuecomment-850935748 [2] https://github.com/openzfs/zfs/issues/12041 OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#985142: chromium: CVE-2021-21193 (RCE) in Blink
Package: chromium Version: 89.0.4389.82-1 Severity: grave Tags: upstream security Justification: user security hole X-Debbugs-Cc: aeru...@aerusso.net, Debian Security Team Per [1] (or [2], and allegedly [3] which I cannot access): > A use after free security issue was found in the Blink component of the > Chromium browser before version 89.0.4389.90. Google is aware of reports > that an exploit for this issue exists in the wild. Does this also affect libqt5webengine5? I know that its upstream derives in part from the Chromium source tree. Antonio [1] https://chromereleases.googleblog.com/2021/03/stable-channel-update-for-desktop_12.html [2] https://security.archlinux.org/CVE-2021-21193 [3] https://crbug.com/1186287 OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#983179: zfs-dkms: fails to build with backports kernel 5.10.0-0.bpo.3-amd64
Control: fixed -1 2.0.2-1 Hello, Unfortunately, it took a while to get 2.0 into backports. This should now be resolved. That said, if you look at the bug reports for ZFS, there's a recurring theme---people often upgrade their kernel and find that ZFS is not compatible. You point out: > btw: Is there any way I can tell the kernel installer or the initramfs > creation to fail if the the ZFS module has not been compiled? I think that we should consider - Warning the user if the ZFS does not explicitly support an installed version of Linux - Warning the user more loudly if the DKMS build fails The second of these is a DKMS feature, I think. Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#983331: zfs-linux: zfs_zrele_async can cause txg sync deadlocks
Control: found -1 0.8.6-1 Control: fixed -1 2.0.2-1 Thank you for reporting this. Are you running stable (0.7.12) and affected by this? Backports and bullseye should now have the fix you mention. Best, Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#983401: [Pkg-zfsonlinux-devel] Bug#983401: zfs-zed: Update of zfs-zed from buster-backports fails.
Control: tag -1 patch Hello Andreas, Deleting these old symlinks from (presumably) another ZFS packaging is indeed the correct fix. I do think we could handle this case slightly more nicely, and I've opened an MR on salsa [1] that should fix this. Best, Antonio [1] https://salsa.debian.org/zfsonlinux-team/zfs/-/merge_requests/38
Bug#983086: zfsutils-linux: TRIM crashes SSD drives
Hello, On 2/19/21 1:35 AM, Xavier wrote: > > The recently added cron "TRIM the first Sunday of every month" makes some SSD > drives crash. > > The problem appears on reasonnably busy and otherwise stable servers: >* with about 100 containers, >* each on a separate zvol, ext4 mounted with discard option, >* on a 6 identical drives raidz2. > > The issue has been observed on these drives: >* Micron_5100_MTFDDAK960TCB >* Samsung_SSD_850_EVO_1TB >* Samsung_SSD_860_EVO_1TB > > When affected (it not always the case), the systems could not complete the > cancelling of the trim with: > # zpool trim -c pool > Testing trim on one drive only, and reducing the rate to as low as 50, > did not help. I am trying to understand the symptom---what exactly do you mean the "SSD drives crash"? Is it just that you cannot cancel the trim? Or is there some other symptom? > > A reset seems the only solution, followed by a zpool trim -c after reboot. > > It would be wise to deactivate that cron by default, or at least to provide > some kind of convenient way to do so, like an option in /etc/default/zfs. > > Thank you. > > -- System Information: > Debian Release: 10.8 > APT prefers stable > APT policy: (900, 'stable'), (500, 'stable-updates'), (400, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.4.19 (SMP w/8 CPU cores) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), > LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages zfsutils-linux depends on: > ii libblkid12.33.1-0.1 > ii libc62.31-9 > ii libnvpair1linux 0.8.6-1~bpo10+1 > ii libudev1 241-7~deb10u6 > ii libuuid1 2.33.1-0.1 > ii libuutil1linux 0.8.6-1~bpo10+1 > ii libzfs2linux 0.8.6-1~bpo10+1 > ii libzpool2linux 0.8.6-1~bpo10+1 > ii python3 3.9.1-1 > ii zlib1g 1:1.2.11.dfsg-1 > > Versions of packages zfsutils-linux recommends: > ii lsb-base10.2019051400 > ii zfs-dkms [zfs-modules] 2.0.2-1 > ii zfs-zed 0.8.6-1~bpo10+1 > > Versions of packages zfsutils-linux suggests: > pn nfs-kernel-server > pn samba-common-bin > pn zfs-initramfs | zfs-dracut > > -- Configuration Files: > /etc/default/zfs changed [not included] > /etc/zfs/zfs-functions changed [not included] > > -- no debconf information You do not have a consistent set of zfs packages installed---please fully upgrade to 2.0.3 (or at least 2.0.2). You have zfs-dkms from unstable, and the rest of zfs from backports. I don't know exactly what you've done to get this setup, but it is not a supported configuration, and may be dangerous to your data. Best, Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#983146: sponsorship-requests: Backup next generation (bung)
Hello, > Please change the email address on this bug report from > send_only.aurin...@auroville.org.in to b...@charlesmatkinson.org See controlling the Debian BTS [1]. > I tried hard to make a source .deb but did not manage to do so. > Would you like me to share the system I use to create the .deb? Please see the new maintainers guide [2]. The long and short of it is: Debian manages thousands of software packages and provides a huge amount of freedom to maintainers in how they do so. However, your package MUST build from a single call to debian/rules (see [3], /FTBFSIASW/). This baseline level of uniformity allows Debian to support many architectures and provide support for the full duration of a Debian release. > bung was not a Debian package so I thought the appropriate place > to install it was under /opt. If it becomes a Debian package > then it should be installed in the conventional places. Since you are submitting a package to be included in Debian, it will not be accepted unless it is packaged in a way that is suitable for Debian---all the files should be placed in accordance with the Debian FHS (see [4] and [5]). Once you do this, be sure to use lintian---I suggest at least looking at the "pedantic" results: lintian --verbose -L ">=pedantic" $changes_file Sponsors are more likely to look at a lintian-clean package. Best, Antonio [1] https://www.debian.org/Bugs/server-control#submitter [2] https://www.debian.org/doc/manuals/maint-guide/ [3] https://ftp-master.debian.org/REJECT-FAQ.html [4] https://wiki.debian.org/FilesystemHierarchyStandard [5] https://www.debian.org/doc/debian-policy/ch-opersys.html
Bug#956822: Bug#981715: RFS: xpra/3.0.9+dfsg1-1.1 [NMU] [RC] -- tool to detach/reattach running X programs
control: tag -1 patch
On 2/5/21 3:22 AM, Gianfranco Costamagna wrote:
> control: reopen -1
> control: notfixed -1 3.0.9+dfsg1-1.1
>
> Hello, I reuse this bug, to point out that now the package has an autopkgtest
> failure on armhf, probably due to an incomplete patch or a missing xvfb
> dependency on debian/tests/control
Thanks---digging into this more, I think I understand what's going on:
xpra/scripts/config.py:detect_xvfb_command specifically wants Xvfb
In particular:
if platform.uname()[4].startswith("arm"):
#arm struggles to launch Xdummy, so use Xvfb:
(But, why this _is_ working on arm64, I do _not_ understand---presumably,
some other case-handling causes xpra to change its mind elsewhere.)
It would, then, seem that all we need is to depend on Xvfb on the failure
architecture:
diff --git a/debian/control b/debian/control
index 6befbb9..77ef63c 100644
--- a/debian/control
+++ b/debian/control
@@ -42,6 +42,7 @@ Depends: ${misc:Depends}, ${python3:Depends},
${shlibs:Depends}
,python3-gi-cairo
,x11-xserver-utils
,xserver-xorg-video-dummy
+,xvfb [armhf]
# Packet Encoding (http://xpra.org/trac/wiki/PacketEncoding):
,python3-rencode
Recommends: ${misc:Recommends}
OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
Bug#981715: RFS: xpra/3.0.9+dfsg1-1.1 [NMU] [RC] -- tool to detach/reattach running X programs
Hello Wookey, On 2/3/21 6:44 AM, Wookey wrote: > On 2021-02-02 23:42 -0700, Antonio Russo wrote: > > I've tested the builds on arm64 and armhf. I'm short of non-headless > boxes here to test the X functionality on. > > So I've uploaded to get the migration going and allow others to test. I > should be able to contrive a non-headless armhf machine too, given a > bit of time (not today) > > Wookey > Thanks for the upload! I've since heard back from Dmitry, and it looks like I'll be able to help out packaging xpra more directly moving forwards. Best, Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#981715: RFS: xpra/3.0.9+dfsg1-1.1 [NMU] [RC] -- tool to detach/reattach running X programs
Package: sponsorship-requests Severity: important Dear mentors, I am look for a sponsor for my NMU of the "xpra" package, which is blocked migrating to testing for the last ~6 months [1] due to a FTBS on armel and armhf [2]. * Package name: xpra Version : 3.0.9+dfsg1-1.1 Upstream Author : Antoine Martin * URL : http://xpra.org/ * License : GPL-2+, LGPL-3+, Expat * Vcs : https://salsa.debian.org/debian/xpra.git Section : x11 It builds those binary packages: xpra - tool to detach/reattach running X programs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/xpra/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/x/xpra/xpra_3.0.9+dfsg1-1.1.dsc Changes since the last upload: xpra (3.0.9+dfsg1-1.1) unstable; urgency=medium . * Non-maintainer upload. * Tweak fix-xvfb-patch.patch (Closes: #921700, #956822). I am moving with a bit of urgency, since this software will otherwise not make it into bullseye. Also, I do not have access to arm* hardware to test this on, so, while I can confirm that this builds (and works) on amd64, it would be nice if someone could check that it works correctly on arm. Best, Antonio Russo [1] https://tracker.debian.org/pkg/xpra [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956822
Bug#956822: xpra: Xpra errors when attempting to attach client
The patch I submitted builds and runs fine on amd64. It should
also trivially get past the assertion failure in the referenced
buildd log.
I can prepare an NMU---but I'd feel better if someone with an
actual arm* machine could test it.
Also, maybe
-if not platform.uname()[4].startswith("arm"):
+if not platform.uname().machine.startswith("arm"):
on top of the earlier patch.
Best,
Antonio
OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
Bug#923500: snapd: non-classic snap not confined
Control: severity -1 grave Dear Maintainer, Does this root-level access bug still affect the current version of snapd in testing? I do not think it befits Debian to ship a package in this state---users expect security isolated snaps to not give trivial root level access to their systems. I apologize if this bug is stale---I personally observed it a year ago, and have stayed away from snapd eversince, partially because this bug has remained unresolved. Best, Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#956822: xpra: Xpra errors when attempting to attach client
Dear maintainer,
The existing xvfb path checking code is very brittle. The attached,
revised patch is more robust. I don't have an arm system to test on,
but I suspect this will help the situation.
Best,
Antonio
Description: Fix path to Xorg binary in /etc/xpra/conf.d/55_server_x11.conf
We need the (absolute) path to the non-setuid binary and not to a possibly
installed setuid-wrapper (which requires root or login on a tty).
Auto-dection fails as Xorg is not installed in the build environment.
.
As the Xorg setuid wrapper is Debian specific (and might be removed in the
future) there's no need to upstream this change.
Author: Simon Ruderich
Author: Antonio Russo
Bug-Debian: https://bugs.debian.org/863891
Forwarded: not-needed
Last-Update: 2020-12-18
Index: xpra-2.4.3+dfsg1/setup.py
===
--- xpra-2.4.3+dfsg1.orig/setup.py
+++ xpra-2.4.3+dfsg1/setup.py
@@ -785,6 +785,12 @@
def build_xpra_conf(install_dir):
#generates an actual config file from the template
xvfb_command = detect_xorg_setup(install_dir)
+xorg_unwrapped = '/usr/lib/xorg/Xorg'
+import platform
+if not platform.uname()[4].startswith("arm"):
+if xvfb_command[0] != xorg_unwrapped:
+assert xvfb_command[0] == 'Xorg'
+xvfb_command[0] = xorg_unwrapped
fake_xinerama = "no"
if POSIX and not OSX and not (is_Debian() or is_Ubuntu()):
from xpra.x11.fakeXinerama import find_libfakeXinerama
OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
Bug#950442: radicale: missing-systemd-service-for-init.d-script
Hello Andreas, I lifted the systemd service file out of DOCUMENTATION.md. Now that you point it out, it would make sense for us to hard-code the Debian path to python3 in there. However, I didn't really try to change it, since I'd like to stay as close to upstream as possible. As for upstreaming the changes: I assume that they had some good reason not to put it in a file by itself. I do not have any preexisting relationship with them, so I don't feel like rocking the boat to change things up. Best, Antonio Russo OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#981179: nmu: dovecot-antispam_2.0+20171229-1+b6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: aeru...@aerusso.net Hello, I'm watching dovecot's progress through unstable [1] and it's blocked by dovecot-antispam [2]. If I understand correctly, it's because dovecot-antispam depends on dovecot-abi-2.3.abiv11, which is not provided by the new version of dovecot-core (which instead provides a new abi virtual package dovecot-abi-2.3.abiv13). That dependency, however, is determined at dovecot-antispam build time, so it should naturally resolve itself if it is rebuilt. Per a conversation I've had on debian-devel [3], it appears I should request a binNMU (as I believe I am, here). Please let me know if I am doing anything incorrectly (e.g., should I be cc-ing the dovecot* developers involved?) Thank you, Antonio Russo [1] https://tracker.debian.org/pkg/dovecot [2] https://tracker.debian.org/pkg/dovecot-antispam [3] https://lists.debian.org/debian-devel/2021/01/msg00395.html nmu dovecot-antispam_2.0+20171229-1+b6 . ANY . unstable . -m "Rebuild for dovecot-abi-2.3.abiv13" OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#980464: [Pkg-zfsonlinux-devel] Bug#980464: Bug#980464: zfs-dracut: dracut+ZFS-on-root systems rendered unbootable
Yes, and this is partly my fault. I've prepared a version of this patch [1] and forwarding it to upstream [2]. [1] Also includes some other fixes that should get in, but weren't worth delaying the upload for. (But this certainly is!) /sbin is the correct place for this, right? Antonio [1] https://salsa.debian.org/zfsonlinux-team/zfs/-/merge_requests/35 [2] https://github.com/openzfs/zfs/pull/11485
Bug#980273: util-linux: overzealous canonicalization breaks zfs mounts
Package: util-linux Version: 2.36.1-4 Severity: important Tags: patch Dear maintainer, Recent version of util-linux include a new feature to canonicalize paths related to mounting. Unfortunately, this mangles non-path descriptions used by some filesystems (in this case, zfs), because the string being passed to libmount happens to correspond to an actual path, causing libmount to add a / character at the beginning---see [1] and discussions referenced in [2]. Upstream has addressed this (at least for zfs) in [2], which is not yet included in the Debian version. Would it be possible to cherry-pick that commit? Thanks, Antonio Russo [1] https://github.com/openzfs/zfs/issues/11448 [2] https://github.com/karelzak/util-linux/commit/372ce5b74e79470b1bda1fc284c19a313a422361 OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#963867: [dma] 0.13 Packaging
On 1/13/21 10:30 AM, Laurent Bigonville wrote: > > I already have a package here that I can upload, but I didn't really had the > time to test it. > > Can you confirm me that 0.13 is working fine for you? It's been working excellently for me for the last few months on a half dozen machines. > > Kind regards, > > Laurent Bigonville Thanks for getting back so quickly, Antonio Russo OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#963867: [dma] 0.13 Packaging
Hello, I am interested in getting dma 0.13 into bullseye. I've been running it on a fleet of machines after packaging it [1]. Would the dma packaging team be willing to sponsor an upload if I prepared it? Best, Antonio Russo [1] https://salsa.debian.org/debian/dma/-/merge_requests/2 OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#979709: [Pkg-zfsonlinux-devel] Bug#979709: ZFS crash on update!
Control: forcemerge 977656 -1 Hello, 0.8.6 does not support Linux 5.10---hence the failures. Right now, the only released version of ZFS that supports Linux 5.10 is 2.0.1, and that is currently packaged in experimental. The Debian ZFS team is still deciding between 0.8.x and 2.0.x for bullseye, but 2.0.x will exist in backports. Best, Antonio
Bug#977656: zfs-dkms: Fail to build with 5.10 kernel
tag -1 upstream thanks Giving an update here, since many people may be interested in a status report on this: - There is *no released version* of ZoL/OpenZFS that supports 5.10. - 5.10 appears to have been slightly more work for OpenZFS to adjust to. - As of e1d9228b0 (on their 2.0.1-staging branch), upstream has expressed confidence that they have kernel compatibility. (yay!) - Upstream will *not* be back porting their 5.10 compatibility patches to 0.8, but *does* welcome patches doing so. - 2.0.0 is currently in the NEW queue, targeting experimental. Once this is accepted, expect a relatively speedy delivery of 2.0.1 (or cherry picked patches for 5.10 compatibility)---to experimental. - The Debian ZoL team has not yet decided on 0.8.6 vs. 2.0.? for bullseye. References: [1] https://github.com/openzfs/zfs/issues/11314 OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#978948: RFS: kcollectd/0.12.0-1 -- simple collectd graphing front-end for KDE
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: aeru...@aerusso.net Dear mentors, I am looking for a sponsor for my package "kcollectd" * Package name: kcollectd Version : 0.12.0-1 Upstream Author : Antonio Russo * URL : https://www.antonioerusso.com/projects/kcollectd/ * License : GPLv3+ * Vcs : https://salsa.debian.org/qt-kde-team/extras/kcollectd Section : utils Description : simple collectd graphing front-end for KDE This package provides a basic KDE application for viewing RRD files created by collectd, the system statistics storage daemon. It allows easy mouse-driven navigation through data collections and can be used as a virtual chart recorder. It builds the binary packages: kcollectd - simple collectd graphing front-end for KDE To access further information about this package, please visit the following URL: https://mentors.debian.net/package/kcollectd/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/k/kcollectd/kcollectd_0.12.0-1.dsc I am also upstream for this project, and have incorporated a few minor UI improvements since my last release, in addition to some under the hood build simplifications. The upstream update also subsumes a fix for a build failure that was addressed by an NMU upload earlier this month. It also updates my email address. On the Debian side, this upload tracks the changes upstream, also updating my email address. Best, Antonio Russo OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#977997: radicale: Please package 3.0.6
Package: radicale Severity: wishlist Tags: patch X-Debbugs-Cc: aeru...@aerusso.net Dear maintainer, It would be nice to have the newer version of Radicale packaged in time for the freeze. I've done some preliminary work packaging 3.0.6 [1], and it "works for me", by which I mean the package builds, and after some customization behaves as I'd like. However, I'm not upgrading from a previous version, but I suspect there may be significant friction for upgrades. I cannot be fully aware of how much trouble this may cause for existing users. Best, Antonio Russo [1] https://salsa.debian.org/debian/radicale/-/merge_requests/2 OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#977506: ckb-next: resolved in 0.4.3
Control: tag -1 patch Dear maintainer, Upstream 0.4.3 resolves this bug for me. It's unclear to me what package is "at fault", but I've built and installed ckb-next/0.4.3 (see [1]), and the problem goes away. Best, Antonio Russo [1] https://salsa.debian.org/debian/ckb-next/-/merge_requests/1 OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#977338: konsole: unable to select intensive color using ANSI \e[1m sequence
Package: konsole Version: 4:20.12.0-1 Severity: normal Tags: upstream X-Debbugs-Cc: aeru...@aerusso.net Dear maintainer, Konsole 20.12.0 contains a regression which breaks the ability to select an "intensive" color in the standard way, which I've reported upstream [1]. The commit in question is 82806a2. I would encourage you to revert that commit---I currently have a comprehensive fix [2] that begins with the reversion of that commit, and addresses the feature request that motivated 82806a2 originally. Since that represents a significant change, I would understand if you decided not to include the rest of that MR as a patch even after it is merged. Best, Antonio Russo [1] https://bugs.kde.org/show_bug.cgi?id=430311 [2] https://invent.kde.org/utilities/konsole/-/merge_requests/299 OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#977119: okular: Please package 20.12.0
Package: src:okular Severity: wishlist Tags: patch X-Debbugs-Cc: aeru...@aerusso.net Dear Maintainer, I've taken a stab at updating the packaging for okular [1]. I'd very much like to get okular 20.12.0 ASAP, since it fixes some painful regressions for me. Best, Antonio Russo [1] https://salsa.debian.org/qt-kde-team/kde/okular/-/merge_requests/6 OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#977008: RFS: inkscape-textext/1.3.0-2 -- Re-editable LaTeX graphics for Inkscape
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: aeru...@aerusso.net Dear mentors, I am looking for a sponsor for my package "inkscape-textext" * Package name: inkscape-textext Version : 1.3.0-2 Upstream Author : Jan Winkler * URL : https://textext.github.io/textext * License : BSD-3-clause * Vcs : https://salsa.debian.org/aerusso-guest/textext Section : graphics Description : Re-editable LaTeX graphics for Inkscape TexText is a Python plugin for the vector graphics editor Inkscape providing the possibility to add and re-edit LaTeX generated SVG elements to your drawing. Key features . Windows/Linux/MacOS support . LaTeX generated SVG elements can be re-edited later . Multi-line editor with syntax highlighting . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex . Interoperable scaling in TexText and Inkscape . Font size match with Inkscape text . Customizable TeX preamble (additional packages, parskip, parindent, etc.) . Colorization via TeX commands/Inkscape is kept after re-editing . Alignment anchor of the produced output . Preview images It builds the binary packages: inkscape-textext - Re-editable LaTeX graphics for Inkscape inkscape-textext-doc - Re-editable LaTeX graphics for Inkscape (documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/inkscape-textext/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/inkscape-textext/inkscape-textext_1.3.0-2.dsc Since my last upload, I have addressed comments regarding debian/copyright raised by the ftp team, as well as performing some minor package cleanup (bumped to the new standards version 4.5.1 and aligning gbp.conf with my salsa layout). Best, Antonio Russo OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#975999: RFS: inkscape-textext/1.3.0-1 -- Re-editable LaTeX graphics for Inkscape
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: aeru...@aerusso.net Dear mentors, I am looking for a sponsor for my package "inkscape-textext" * Package name: inkscape-textext Version : 1.3.0-1 Upstream Author : Jan Winkler * URL : https://textext.github.io/textext * License : BSD-3-clause * Vcs : https://salsa.debian.org/aerusso-guest/textext Section : graphics Description : Re-editable LaTeX graphics for Inkscape TexText is a Python plugin for the vector graphics editor Inkscape providing the possibility to add and re-edit LaTeX generated SVG elements to your drawing. Key features . Windows/Linux/MacOS support . LaTeX generated SVG elements can be re-edited later . Multi-line editor with syntax highlighting . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex . Interoperable scaling in TexText and Inkscape . Font size match with Inkscape text . Customizable TeX preamble (additional packages, parskip, parindent, etc.) . Colorization via TeX commands/Inkscape is kept after re-editing . Alignment anchor of the produced output . Preview images It builds the binary packages: inkscape-textext - Re-editable LaTeX graphics for Inkscape inkscape-textext-doc - Re-editable LaTeX graphics for Inkscape (documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/inkscape-textext/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/inkscape-textext/inkscape-textext_1.3.0-1.dsc Since my last upload, upstream has released 1.3, requiring only trivial adjustments. The package is lintian clean, with the exception of the warning about upstream tarball signing and missing tests. I am still interacting with upstream to get signed releases [1]. **My last upload is still in the NEW queue.** Should I wait for it to clear before uploading my next revision? Best, Antonio Russo [1] https://github.com/textext/textext/issues/231 OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#942249: RFS: inkscape-textext/1.2.0-1 [ITP] -- Re-editable LaTeX graphics for Inkscape
Dear mentors, I am looking for a sponsor for my package "inkscape-textext" * Package name: inkscape-textext Version : 1.2.0-1 Upstream Author : Jan Winkler * URL : https://textext.github.io/textext * License : BSD-3-clause * Vcs : https://salsa.debian.org/aerusso-guest/textext Section : graphics Description : Re-editable LaTeX graphics for Inkscape TexText is a Python plugin for the vector graphics editor Inkscape providing the possibility to add and re-edit LaTeX generated SVG elements to your drawing. Key features . Windows/Linux/MacOS support . LaTeX generated SVG elements can be re-edited later . Multi-line editor with syntax highlighting . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex . Interoperable scaling in TexText and Inkscape . Font size match with Inkscape text . Customizable TeX preamble (additional packages, parskip, parindent, etc.) . Colorization via TeX commands/Inkscape is kept after re-editing . Alignment anchor of the produced output . Preview images It builds the binary packages: inkscape-textext - Re-editable LaTeX graphics for Inkscape inkscape-textext-doc - Re-editable LaTeX graphics for Inkscape (documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/inkscape-textext/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/inkscape-textext/inkscape-textext_1.2.0-1.dsc Since my last upload, upstream has released 1.2. This required only trivial adjustments, but I took this upload as an opportunity to sharpen the dependencies and update by email address. The package is lintian clean, with the exception of the warning about upstream tarball signing and missing tests. I am still interacting with upstream to get signed releases [1]. Best, Antonio Russo [1] https://github.com/textext/textext/issues/231
Bug#973542: RFS: inkscape-textext/1.2.0-1 [ITP] -- Re-editable LaTeX graphics for Inkscape
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: aeru...@aerusso.net Dear mentors, I am looking for a sponsor for my package "inkscape-textext" * Package name: inkscape-textext Version : 1.2.0-1 Upstream Author : Jan Winkler * URL : https://textext.github.io/textext * License : BSD-3-clause * Vcs : https://salsa.debian.org/aerusso-guest/textext Section : graphics Description : Re-editable LaTeX graphics for Inkscape TexText is a Python plugin for the vector graphics editor Inkscape providing the possibility to add and re-edit LaTeX generated SVG elements to your drawing. Key features . Windows/Linux/MacOS support . LaTeX generated SVG elements can be re-edited later . Multi-line editor with syntax highlighting . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex . Interoperable scaling in TexText and Inkscape . Font size match with Inkscape text . Customizable TeX preamble (additional packages, parskip, parindent, etc.) . Colorization via TeX commands/Inkscape is kept after re-editing . Alignment anchor of the produced output . Preview images It builds the binary packages: inkscape-textext - Re-editable LaTeX graphics for Inkscape inkscape-textext-doc - Re-editable LaTeX graphics for Inkscape (documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/inkscape-textext/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/inkscape-textext/inkscape-textext_1.2.0-1.dsc Since my last upload, upstream has released 1.2. This required only trivial adjustments, but I took this upload as an opportunity to sharpen the dependencies and update by email address. The package is lintian clean, with the exception of the warning about upstream tarball signing and missing tests. I am still interacting with upstream to get signed releases [1]. Best, Antonio Russo [1] https://github.com/textext/textext/issues/231 OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#969477: zfs-dkms fails to compile with 5.7.0-3 kernel blocking kernel upgrade
Control: tag -1 normal In an off-list discussion, the reporter has said that the issue has spontaneously resolved for kernel 5.9 on Debian sid. I am therefore reducing the severity to normal. If this problem reoccurs for anyone, please also show your exact kernel header version, i.e., # apt-cache policy linux-headers-$(uname -r) for the affected kernel version. Antonio Russo OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#972809: dracut-core: Acts on /boot/initramfs-... instead of /boot/initrd... by default
Hello, On 10/25/20 4:03 AM, Thomas Lange wrote: Thanks for the patch. But when I tried to apply it on my local machine it failed. Can you please check this [snip] Hmm... it looks like 050+65-1 isn't on salsa, only 050+35-4 (and that's what the patch is based on). If you push 050+65-1 to salsa and ping me, I'll rebase on that. Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#972809: dracut-core: Acts on /boot/initramfs-... instead of /boot/initrd... by default
Package: dracut-core Version: 050+65-1 Severity: normal Tags: patch X-Debbugs-Cc: aeru...@aerusso.net By default, dracut --force acts on /boot/initramfs-$(uname -r).img, instead of the debian default initramfs file, /boot/initrd.img-$(uname -r). The patch in salsa [1] addresses this. Best, Antonio https://salsa.debian.org/debian/dracut/-/merge_requests/2 -- System Information: Debian Release: bullseye/sid APT prefers testing Versions of packages dracut-core depends on: ii bash5.1~rc1-2 ii cpio2.13+dfsg-4 ii e2fsprogs 1.45.6-1 ii kmod27+20200310-2 ii kpartx 0.8.4-4 ii libc6 2.31-4 ii libkmod227+20200310-2 ii pkg-config 0.29.2-1 ii udev246.6-2 ii util-linux 2.36-3+b1 Versions of packages dracut-core recommends: ii binutils 2.35.1-2 ii console-setup 1.197 ii cryptsetup 2:2.3.4-1 ii dmraid 1.0.0.rc16-8+b1 ii dmsetup2:1.02.171-3 ii lvm2 2.03.09-3 ii mdadm 4.1-8 ii pigz 2.4-1+b1 ii systemd246.6-2 dracut-core suggests no packages. -- no debconf information OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#972327: zfsutils-linux: No NMU binary compliant
Control: tag -1 patch I have opened an MR on salsa [1] that addresses this by relaxing the version constraints. I'd appreciate feedback if this is an appropriate way to solve the problem. Antonio [1] https://salsa.debian.org/zfsonlinux-team/zfs/-/merge_requests/28 OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#969477: zfs-dkms fails to compile with 5.7.0-3 kernel blocking kernel upgrade
Hello Jordan, Do you have the architecture-specific Linux headers installed? I.e., please call # uname -r that should give you something like 5.8.0-2-amd64 Is the package linux-headers-5.8.0-2-amd64 installed (replaced for your specific kernel version)? Or, just run # apt-cache policy linux-headers-$(uname -r) And send the output. Best, Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#963867: new upstream
Control: tag -1 patch I've gone ahead and taken a shot at the packaging [1]. I'm running it locally on several machines (the new FINGERPRINT option is great). If there's any more legwork to run on this, let me know. I'd love to help out. Antonio [1] https://salsa.debian.org/debian/dma/-/merge_requests/2
Bug#966698: rasdaemon: fails to start by default under systemd due to EnvironmentFile=/etc/sysconfig/rasdaemon
Control: tag -1 patch I've created an MR on salsa that should address this https://salsa.debian.org/ahs3/rasdaemon/-/merge_requests/2 Best, Antonio
Bug#966565: [zfsutils-linux] zfs-mount-generator broken by git_fix_dependency_loop_encryption1.patch
Ugh, sorry. This is of course correct. On 2020-07-30 17:50, Richard Laager wrote: > On 7/30/20 1:58 PM, Antonio Russo wrote: >> Changing this line to >> >> pools=$(zpool list -H -o name | true) > > This should be || true (two pipes, not one). >
Bug#966565: [zfsutils-linux] zfs-mount-generator broken by git_fix_dependency_loop_encryption1.patch
Package: zfsutils-linux Version: 0.8.4-2 Severity: important X-Debbugs-CC: rlaa...@wiktel.com Tags: patch The addition of the command pools=$(zpool list -H -o name) to /lib/systemd/system-generators/zfs-mount-generator means that zpool must succeed at very early in the boot. This may not be the case on many systems. Indeed, great effort is taken in zfs-mount-generator infrastructure to avoid any dependency on zpool and zfs. Changing this line to pools=$(zpool list -H -o name | true) allows the command to fail, and fall-back to the original behavior if zpool is unavailable or the command is unable to get a list of pools. This can easily break a users boot, so it may make sense to raise the severity of this bug. Antonio
Bug#963742: spl-dkms: missing makefile
Hello, Could you confirm that you have linux-headers-5.6.0-0.bpo.2-amd64 installed, and its exact version? Additionally, to debug this we will need to > Consult /var/lib/dkms/spl/0.7.12/build/make.log for more information. Could you please attach that (and any other suspicious files in that directory)? Best, Antonio
Bug#961179: RFS: inkscape-textext/1.0.1-1 [ITP] -- Re-editable LaTeX graphics for Inkscape
control: retitle -1 RFS: inkscape-textext/1.1.0-1 [ITP] -- Re-editable LaTeX graphics for Inkscape thanks Dear mentors, I am looking for a sponsor for my package "inkscape-textext" * Package name: inkscape-textext Version : 1.1.0-1 Upstream Author : Jan Winkler * URL : https://textext.github.io/textext * License : AGPL * Vcs : https://github.com/textext/textext Section : graphics Description : Re-editable LaTeX graphics for Inkscape TexText is a Python plugin for the vector graphics editor Inkscape providing the possibility to add and re-edit LaTeX generated SVG elements to your drawing. Key features . Windows/Linux/MacOS support . LaTeX generated SVG elements can be re-edited later . Multi-line editor with syntax highlighting . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex . Interoperable scaling in TexText and Inkscape . Font size match with Inkscape text . Customizable TeX preamble (additional packages, parskip, parindent, etc.) . Colorization via TeX commands/Inkscape is kept after re-editing . Alignment anchor of the produced output . Preview images It builds these binary packages: inkscape-textex inkscape-textex-doc To access further information about this package, please visit the following URL: https://mentors.debian.net/package/inkscape-textext Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/inkscape-textext/inkscape-textext_1.1.0-1.dsc Changes since the last upload: * Merge upstream 1.1.0. The package is (mostly) lintian-clean. Upstream does not sign releases, so I cannot help the two signing warnings (should I set them to be ignored?). The embedded-javascript-library warning appears to be an issue with dh_sphinxdoc (see [1], the last email dated Jul 13 from Alexis Murzeau). I have not set up autopkgtests. The packaging is maintained in Debian salsa [2], and builds in pbuilder. Best, Antonio Russo [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964013 [2] https://salsa.debian.org/aerusso-guest/textext
Bug#965244: RFS: collectd/5.11.0-4 [RC NMU] -- statistics collection and monitoring daemon
Package: sponsorship-requests Severity: important X-Debbugs-CC: team+colle...@tracker.debian.org Dear mentors, I am looking for a sponsor for a NMU of the collectd package to save it from autoremoval tomorrow. I have filed an MR on salsa [1] that addresses these issues. I also emailed at the beginning of the week offering my assistance. I have furthermore BCC-ed all uploaders listed on the package on this bug report. I'm not sure of the etiquette of any of this, and I apologize for almost certainly doing the wrong thing. It's currently scheduled for autoremoval because of several FTBFS issues I think this is a really fantastic package, and I would hate to see it removed. You can consider this an offer of support for the packaging effort of collectd going forward as well, if anyone so desires. The RFS template (and more) follows: * Package name: collectd Version : 5.11.0-4 Upstream Author : Florian Forster et al * URL : collectd.org * License : GPL-2 * Vcs : https://salsa.debian.org/debian/pkg-collectd (this upload is MR 5, plus a changelog entry) Section : utils It builds these binary packages: collectd To access further information about this package, please visit the following URL: https://mentors.debian.net/package/collectd Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/collectd/collectd_5.11.0-4.dsc Changes since the last upload: * Fix FTBS: disable gRPC * Fix FTBFS: disable gmond (ganglia) * Fix FTBS: MHD_start_daemon strict type (Closes: #964593) Please note: this is the second upload with this exact version (5.11.0-4) to mentors. The first one did not close #964593 in the changelog, but should otherwise be identical. The mentors page often has trouble identifying a new version, but does appear to be showing up correctly now. Please be wary of this when downloading the package. Best, Antonio Russo [1] https://salsa.debian.org/debian/pkg-collectd/-/merge_requests/5
Bug#964995: RFS: kcollectd/0.11.99.0-1 -- simple collectd graphing front-end for KDE
Package: sponsorship-requests Severity: normal X-Debbugs-CC: pkg-kde-t...@alioth-lists.debian.net Dear mentors, I am looking for a sponsor for my package "kcollectd": * Package name: kcollectd Version : 0.11.99.0-1 Upstream Author : Antonio Russo (myself) * URL : www.antonioerusso.com/projects/kcollectd * License : GPLv3 * Vcs : https://salsa.debian.org/qt-kde-team/extras/kcollectd.git Section : utils It builds these binary packages: kcollectd To access further information about this package, please visit the following URL: https://mentors.debian.net/package/kcollectd Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/k/kcollectd/kcollectd_0.11.99.0-1.dsc Changes since the last upload: * New upstream release 0.11.99.0. - Includes --basedir CLI option to select directory containing RRDs. * Do not depend on collectd at build or runtime. * Bump debhelper-compat to 13 (no changes). Most critically of the above is that it avoids a build dependency on collectd, which is currently due to be autoremoved in 4 days. Though this program may be most useful on a machine that has collectd installed, it is still useful for viewing RRD files that are remote (via, say, sshfs). This is actually a recent, specific feature request [1]. Best, Antonio Russo [1] https://gitlab.com/aerusso/kcollectd/-/issues/4
Bug#961179: RFS: inkscape-textext/1.0.1-1 [ITP] -- Re-editable LaTeX graphics for Inkscape
Hello again, Is there anything I can do to help move this process along? Are you still willing to sponsor an upload for this package? Thank you, Antonio Russo
Bug#962424: zfsutils-linux: systemd zfs-mount-generator breaks boot if multiple datasets have the same mountpoint
Control: severity -1 wishlist Control: tag -1 -moreinfo On 2020-07-03 09:49, Wxcafé wrote: > My problem is that canmount=noauto datasets should not be mounted > automatically (I mean it’s in the name, isn’t it?) and right now they are > being mounted automatically (through systemd) systemd mounts parent datasets it understands whenever child datasets are mounted. I will re-iterate: if you do not want systemd doing systemd things on a subset of your datsets, do zfs set org.openzfs.systemd:ignore=on $dataset I agree that it is different behavior, but I suspect upstream will not reverse course on this. Feel free to weigh in on that discussion, but I'm recommending closing this bug report as a "feature not a bug" because it is upstream's explicit intention. Antonio
Bug#962424: zfsutils-linux: systemd zfs-mount-generator breaks boot if multiple datasets have the same mountpoint
Can you confirm that zfs set org.openzfs.systemd:ignore=on rpool/backups resolves your issue? Right now, you've got backup datasets that are canmount=noauto, but presumably should never be mounted at those mountpoints. Other options are - change your mountpoint on your backup root, and have everything inherit from that. (my recommendation) - set canmount=off for all the datasets that you cannot actually mount right now. We're having an upstream discussion [1]. [1] https://github.com/openzfs/zfs/issues/10530
Bug#962382: kcollectd: no information printing
Control: severity -1 wishlist Control: tag -1 upstream I haven't heard anything back about this, so I'm going to treat the bugreport as exact fact. > kcollectd starts, shows the inputs tree correctly but clicking any > source shows only: "Drop sensors from list here" and the rest of the > main area is grey. This is intended behavior. You must drag and drop sensors from the list to display them. > Also there are three buttons in the bottom right > corners which don't have any description and are not doing anything. This makes sense if you have not dragged any items from the list. The problem is that the instructions on how to use the tool are apparently unclear. I've therefore changed this severity to wishlist. I've also "forwarding this to upstream" a.k.a. myself. Best, Antonio
Bug#962424: zfsutils-linux: systemd zfs-mount-generator breaks boot if multiple datasets have the same mountpoint
Control: tags -1 +moreinfo Hello! Is that attached file literally what is in /etc/zfs/zfs-list.cache ? How was it generated, and how did it get there? Because it's wrong---it's space separated, and must be tab separated. Use -H, per man zfs-mount-generator, if it must be done by hand. Best, Antonio
Bug#961179: RFS: inkscape-textext/1.0.1-1 [ITP] -- Re-editable LaTeX graphics for Inkscape
Just wanted to do a quick follow up: Is there anything else you would like me to do to prepare this package for submission? Thanks, Antonio On 2020-06-10 18:30, Antonio Russo wrote: > On 2020-06-10 08:53, Boyuan Yang wrote: >> Signed tags/tarballs don't matter; they are totally optional. Your >> debian/watch file is using mode=git, which is totally fine; however, >> you may also opt to monitor the github releases page like other Debian >> packages. > > Understood. I've left it untouched, in the hope that upstream will > sign their git tags. > >> Just one last issue: you did not document the license information of >> textext/texoutparse.py; this file is licensed under the MIT License >> (seems to be the Expat variant), not BSD-3-Clause. Please update this >> information accordingly. After that, I think I can help to upload this >> package. > > Whoops. I've fixed that, and uploaded the changes to mentors and salsa. > > Thanks for your time, > Antonio >
Bug#962382: kcollectd: no information printing
Control: tags -1 +moreinfo Hello Eduard, You say that the tree of sensors appears for you. Just to confirm: what happens when you drag an item from that list into the right-hand region, where it says "Drop sensors from list here"? Antonio
Bug#961179: RFS: inkscape-textext/1.0.1-1 [ITP] -- Re-editable LaTeX graphics for Inkscape
On 2020-06-10 08:53, Boyuan Yang wrote: > Signed tags/tarballs don't matter; they are totally optional. Your > debian/watch file is using mode=git, which is totally fine; however, > you may also opt to monitor the github releases page like other Debian > packages. Understood. I've left it untouched, in the hope that upstream will sign their git tags. > Just one last issue: you did not document the license information of > textext/texoutparse.py; this file is licensed under the MIT License > (seems to be the Expat variant), not BSD-3-Clause. Please update this > information accordingly. After that, I think I can help to upload this > package. Whoops. I've fixed that, and uploaded the changes to mentors and salsa. Thanks for your time, Antonio
Bug#961179: RFS: inkscape-textext/1.0.1-1 [ITP] -- Re-editable LaTeX graphics for Inkscape
This essentially the same as [1] BTS 961741, and I've pushed the fix to debian-mentors [2] and salsa [3]. I apologize for this, I did not push these changes out earlier because I (apparently incorrectly) assumed no one was going to look at my package. I still have not heard back from upstream regarding signed git tags [4]. Thank you very much for looking at this, Antonio Russo [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961741 [2] https://mentors.debian.net/package/inkscape-textext [3] https://salsa.debian.org/aerusso-guest/textext [4] https://github.com/textext/textext/issues/231 On 2020-06-09 21:04, Boyuan Yang wrote: > Control: tags -1 +moreinfo > X-Debbugs-CC: antonio.e.ru...@gmail.com > > Hi Antonio, > > On Wed, 20 May 2020 20:00:30 -0600 Antonio Russo < > antonio.e.ru...@gmail.com> wrote: >> Package: sponsorship-requests >> Severity: wishlist >> X-Debbugs-CC: 942...@bugs.debian.org >> >> Dear mentors, >> >> I am looking for a sponsor for my package "inkscape-textext" >> >> * Package name: inkscape-textext >>Version : 1.0.1-1 > > Unfortunately your package fails to build from source. The full > buildlog has been attached with this email. Please review your > packaging and make sure that it builds sucessfully in a clean > environment. >
Bug#942249: FWD: RFS: inkscape-textext/1.0.1-1 [ITP] -- Re-editable LaTeX graphics for Inkscape
Hello TeX maintainers, I'm forwarding my RFS advertisement for this package, which may be of interest to some of you. Thank you for your consideration, Antonio Dear mentors, I am looking for a sponsor for my package "inkscape-textext" * Package name: inkscape-textext Version : 1.0.1-1 Upstream Author : Jan Winkler * URL : https://textext.github.io/textext * License : AGPL * Vcs : https://github.com/textext/textext Section : graphics Description : Re-editable LaTeX graphics for Inkscape TexText is a Python plugin for the vector graphics editor Inkscape providing the possibility to add and re-edit LaTeX generated SVG elements to your drawing. Key features . Windows/Linux/MacOS support . LaTeX generated SVG elements can be re-edited later . Multi-line editor with syntax highlighting . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex . Interoperable scaling in TexText and Inkscape . Font size match with Inkscape text . Customizable TeX preamble (additional packages, parskip, parindent, etc.) . Colorization via TeX commands/Inkscape is kept after re-editing . Alignment anchor of the produced output . Preview images Since my last upload, upstream has released 1.0 (and 1.0.1). Now that there is an upstream release, the package is suitable for unstable, rather than experimental. I've renamed the package to inkscape-textext, aligning with the naming of other inkscape extensions I have found. The package is lintian clean, with the exception of the warning about upstream tarball signing (and tests) [1]. I'm currently interacting with upstream to get signed releases [2]. The packaging is maintained in Debian salsa [3], and builds in pbuilder. Best, Antonio Russo [1] https://mentors.debian.net/package/inkscape-textext [2] https://github.com/textext/textext/issues/231 [3] https://salsa.debian.org/aerusso-guest/textext
Bug#961179: RFS: inkscape-textext/1.0.1-1 [ITP] -- Re-editable LaTeX graphics for Inkscape
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: 942...@bugs.debian.org Dear mentors, I am looking for a sponsor for my package "inkscape-textext" * Package name: inkscape-textext Version : 1.0.1-1 Upstream Author : Jan Winkler * URL : https://textext.github.io/textext * License : AGPL * Vcs : https://github.com/textext/textext Section : graphics Description : Re-editable LaTeX graphics for Inkscape TexText is a Python plugin for the vector graphics editor Inkscape providing the possibility to add and re-edit LaTeX generated SVG elements to your drawing. Key features . Windows/Linux/MacOS support . LaTeX generated SVG elements can be re-edited later . Multi-line editor with syntax highlighting . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex . Interoperable scaling in TexText and Inkscape . Font size match with Inkscape text . Customizable TeX preamble (additional packages, parskip, parindent, etc.) . Colorization via TeX commands/Inkscape is kept after re-editing . Alignment anchor of the produced output . Preview images Since my last upload, upstream has released 1.0 (and 1.0.1). Now that there is an upstream release, the package is suitable for unstable, rather than experimental. I've renamed the package to inkscape-textext, aligning with the naming of other inkscape extensions I have found. The package is lintian clean, with the exception of the warning about upstream tarball signing (and tests) [1]. I'm currently interacting with upstream to get signed releases [2]. The packaging is maintained in Debian salsa [3], and builds in pbuilder. Best, Antonio Russo [1] https://mentors.debian.net/package/inkscape-textext [2] https://github.com/textext/textext/issues/231 [3] https://salsa.debian.org/aerusso-guest/textext
Bug#942249: RFS: inkscape-textext/1.0.1-1 [ITP] -- Re-editable LaTeX graphics for Inkscape
Dear mentors, I am looking for a sponsor for my package "inkscape-textext" * Package name: inkscape-textext Version : 1.0.1-1 Upstream Author : Jan Winkler * URL : https://textext.github.io/textext * License : AGPL * Vcs : https://github.com/textext/textext Section : graphics Description : Re-editable LaTeX graphics for Inkscape TexText is a Python plugin for the vector graphics editor Inkscape providing the possibility to add and re-edit LaTeX generated SVG elements to your drawing. Key features . Windows/Linux/MacOS support . LaTeX generated SVG elements can be re-edited later . Multi-line editor with syntax highlighting . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex . Interoperable scaling in TexText and Inkscape . Font size match with Inkscape text . Customizable TeX preamble (additional packages, parskip, parindent, etc.) . Colorization via TeX commands/Inkscape is kept after re-editing . Alignment anchor of the produced output . Preview images Since my last upload, upstream has released 1.0 (and 1.0.1). Now that there is an upstream release, the package is suitable for unstable, rather than experimental. I've renamed the package to inkscape-textext, aligning with the naming of other inkscape extensions I have found. The package is lintian clean, with the exception of the warning about upstream tarball signing (and tests) [1]. I'm currently interacting with upstream to get signed releases [2]. The packaging is maintained in Debian salsa [3], and builds in pbuilder. Best, Antonio Russo [1] https://mentors.debian.net/package/inkscape-textext [2] https://github.com/textext/textext/issues/231 [3] https://salsa.debian.org/aerusso-guest/textext
Bug#942249: ITP: inkscape-ext-textext -- Re-editable LaTeX graphics for Inkscape
Hello! I'm glad someone is finding use for this. I updated the packaging in [1]. Notice the change in package name to inkscape-textext, which more closely matches other inkscape extension packages. It "works" in the sense that it compiles, installs, and creates basic objects in inkscape, but I haven't tested the packaging (or the actual extension) beyond that. I'd appreciate any feedback you have while testing and using it. I'll try to get around to uploading to debian-mentors again and asking for a sponsor in the near-ish future. Best, Antonio [1] https://salsa.debian.org/aerusso-guest/textext On 5/20/20 3:59 AM, Adrien Grellier wrote: > Hi, > > Thank your for your package of TexText. I successfully compile your package > for Buster, for a user of our laboratory, but failed to use it. > > Upstream developpers released a new version recently (1.0.1), do you intend > to package it ? It can solve the bugs I encountered. > > Kind regards, > > Adrien > > *-- > > Adrien Grellier (02 40 37 15 55) > Administrateur système du LHEEA > CNRS – École Centrale de Nantes*
Bug#960468: Please package 0.8.4
Source: zfs-linux Severity: wishlist Tags: patch --- Please enter the report below this line. --- Upstream has release 0.8.4 [1]. It adds official support for 5.5 and 5.6---a dire need for Debian unstable and testing users, since 5.4 is no longer supported. Some packaging changes are required to build and install 0.8.4. I've addressed them in an MR on salsa [2]. There may be some test failures on Linux 5.6 [3]---I am in the process of reproducing on Debian's kernel. [1] https://github.com/openzfs/zfs/releases/tag/zfs-0.8.4 [2] https://salsa.debian.org/zfsonlinux-team/zfs/-/merge_requests/23 [3] https://github.com/openzfs/zfs/pull/10209#issuecomment-626211848
Bug#958191: patch
Control: tag -1 patch I've opened a merge request [1] addressing this. [1] https://salsa.debian.org/debian/dracut/-/merge_requests/1
Bug#958191: processor microcode is not loaded (not dracut: early cpio is not produced)
Package: dracut Version: 050+35-2 Severity: serious This newest version of dracut is not loading Intel microcode updates, and reverting to 048+80-2 resolves the issue. lsinitrd in 048 shows an early cpio archive with the microcode. that cpio is missing in 050, so maybe that is related? I've marked this serious because it can re-expose a system to spectre/meltdown bugs. Please adjust as you see fit.
Bug#956531: closing bugreport
Control: notfound -1 1.23.90-1 This was caused by the router's DHCP6 server (but not the dhcp4 server) misbehaving. While network manager could have more robustly handled the failure, it's at most a wishlist bug, and I've described mitigations in the upstream bugreport. There's no reason to leave this Debian bug open.
Bug#956531: router firmware is not an issue
The router firmware mentioned above is a red herring. A macbook on the same network is perfectly able to maintain ipv6 connectivity. Conversely, both wired and wireless connections are exhibiting this misbehavior on 3 separate Debian testing/unstable machines. Antonio
Bug#956531: network-manager: ipv6 dhcp leases are not renewed
Package: network-manager
Version: 1.23.90-1
Severity: important
Tags: ipv6
Symptom:
inet6 leases are acquired without (apparent) issue at connection start time,
but expire
without any attempt to renew (no log entry in journalctl containing "dhcp6").
inet4
addresses are properly acquired and renewed (with log entries including the
text dhcp4
in them).
Setup:
I am running behind a router with a dual ip4/ip6 setup. I get a long (9sec)
lease
for ipv4, and a short (600sec) ipv6 lease.
This affects both ip6-privacy unset (which I believe means "on") and
ip6-privacy=0, as
set in the nm connection file:
# cat /proc/sys/net/ipv6/conf/default/use_tempaddr
2
This also happens 1.22.10-1.
Workaround:
Periodically call nmcli con up "${connection_name}"
Additional notes:
1. The inet6 address I get works: ping6 can get out.
2. This problem appeared after an upgrade to the router firmware. But, even if
there is an
issue with that firmware, why is no attempt made to renew the expiring inet6
address(es)?
Am I misunderstanding some detail about ipv6 address assignment?
3. Even before the router firmware upgrade, dhcp6 consistently connected with
some timeout issue:
Apr 07 06:36:46 hostname NetworkManager[2644]: [1586263006.8448] dhcp6
(eth0): activation: beginning transaction (timeout in 45 seconds)
Apr 07 06:36:46 hostname NetworkManager[2644]: [1586263006.8456]
policy: set 'eth0-dynamic' (eth0) as default for IPv6 routing and DNS
Apr 07 06:37:32 hostname NetworkManager[2644]: [1586263052.0247] dhcp6
(eth0): request timed out
Apr 07 06:37:32 hostname NetworkManager[2644]: [1586263052.0247] dhcp6
(eth0): state changed unknown -> timeout
Apr 07 06:37:32 hostname NetworkManager[2644]: [1586263052.0248] dhcp6
(eth0): canceled DHCP transaction
Apr 07 06:37:32 hostname NetworkManager[2644]: [1586263052.0248] dhcp6
(eth0): state changed timeout -> done
This, however, did not cause trouble getting the inet6 address (I have other
records that indicate the address was
assigned).
Antonio
Bug#946152: iptables-dev vs libiptc-dev dependency in collectd
On 3/6/20 4:50 PM, Bernd Zeimetz wrote:
>
> I fail to understand the reason behind this: libiptc-dev still exists
> and collectd needs it to build successfully. Please convince me why
> there is a reason for this change.
>
My apologies: I for some reason thought I saw "pkg-config --exists libip4tc"
and "pkg-config --exists libip4tc" in the configure.ac file in the collectd
5.10 release---but my eyes must have been misled, because that is not the
case.
Because that is not the case, the pkg-config calls to get the path to
libip4tc{.h,.so} libip6tc{.h,.so} and libiptc.h fail. You can get around
that with the trivial patch I've attached.
As for the question "Why can't we just use libiptc-dev's version of the
pkg-config file that just works?" I don't know. But, if it becomes a
problem, this should work (it builds on my machine without libiptc-dev).
Best,
Antonio
Description: Fix path to Xorg binary in /etc/xpra/conf.d/55_server_x11.conf
We need the (absolute) path to the non-setuid binary and not to a possibly
installed setuid-wrapper (which requires root or login on a tty).
Auto-dection fails as Xorg is not installed in the build environment.
.
As the Xorg setuid wrapper is Debian specific (and might be removed in the
future) there's no need to upstream this change.
Author: Simon Ruderich
Bug-Debian: https://bugs.debian.org/863891
Forwarded: not-needed
Last-Update: 2019-02-07
Index: xpra-2.4.3+dfsg1/setup.py
===
--- xpra-2.4.3+dfsg1.orig/setup.py
+++ xpra-2.4.3+dfsg1/setup.py
@@ -819,6 +819,12 @@ def detect_xorg_setup(install_dir=None):
def build_xpra_conf(install_dir):
#generates an actual config file from the template
xvfb_command = detect_xorg_setup(install_dir)
+xorg_call = '/usr/lib/xorg/Xorg'
+if xvfb_command[0] != xorg_call:
+assert xvfb_command[0] == 'Xorg'
+xvfb_command[0] = xorg_call
+
+xvfb_command[0] = '/usr/lib/xorg/Xorg'
from xpra.platform.features import DEFAULT_ENV
def bstr(b):
if b is None:
Bug#946152: iptables-dev vs libiptc-dev dependency in collectd
Sorry for the noise here. I understand that these are two separate issues, and I believe that upstream has addressed the libiptc -> libip4tc name change in their 5.10.0 release. My MR has been updated to only pull in libip4tc-dev and libip6tc-dev, and not libiptc-dev in a third patch, so there is still a patch pending to fix this. Antonio
Bug#946152: iptables-dev vs libiptc-dev dependency in collectd
I'm trying to address the changes in the iptables package for collectd. I can avoid the dependency on the transitional iptables-dev package (see [1]), but I'm confused by the statement: > The src:iptables debian package (v1.8.4-1) dropped the libiptc-dev and > libiptc0 binary packages. I see that libiptc0 is a transitional dummy package, but libiptc-dev is not indicated to be obsolete, and in fact contains the pkg-config file /usr/lib/x86_64-linux-gnu/pkgconfig/libiptc.pc Is there another package that collectd should build-depend on for this file? (I.e., have I incorrectly merged 946152 and 951088?) Or is the removal of the dependency on libiptc0 (by rebuilding) sufficient to address your original bug report? Thanks, Antonio Russo [1] https://salsa.debian.org/debian/pkg-collectd/-/merge_requests/2
Bug#951088: Merge request 2
Control: forcemerge -1 946152 Control: tag -1 patch Please see my MR on salsa [1]. With that patch, collectd builds locally without the obsolete build-dep. Antonio [1] https://salsa.debian.org/debian/pkg-collectd/-/merge_requests/2
Bug#952822: /etc/zfs/zed.d configuration is clobbered on upgrade
Package: zfs-zed Version: 0.8.3-1 Severity: serious Tags: patch Justification: Policy 10.7.3 Please see my MR on salsa [1], which should address this policy violation. In short: the symlinks shipped by zfs-zed in /etc/zfs/zed.d are not tracked as conffiles by dpkg, so they re-appear even after being deleted. Antonio [1] https://salsa.debian.org/zfsonlinux-team/zfs/-/merge_requests/21
Bug#952494: unable to reproduce
Hi! I merged your two bug reports, because it seems that they're about the same issue. In the future, you can indicate that the problem still exists in another version by using the "Control: found -1" command (see [1] for details to manage the Debian BTS). I too am running network manager, and using it to manage a wired connection. However, my upgrade went smoothly. Could you go into more detail about your configuration? In which prior version of network manager was this working? Did anything else change? What is the output of "nmcli connection"? Can you also please include your NetworkManager.conf file? (Make sure there are no secrets in it!) Best, Antonio Russo [1] https://www.debian.org/Bugs/server-control#found
