Bug#1083195: ITP: rust-ulid -- ULID implementation
On 10/2/24 15:25, Jonas Smedegaard wrote: Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: rust-ulid Version : 0.1.3 Upstream Contact: Dylan Hart * URL : https://github.com/dylanhart/ulid-rs * License : Expat Programming Lang: Rust Description : ULID implementation ulid is a Rust implementation of Universally Unique Lexicographically Sortable Identifiers (ULID). . This package contains the source for the Rust ulid crate, for use with cargo. This package is needed for recent releases of matrix-synapse, fractal (bug#900928), atomic-server (bug#996464) and iamb (bug#1061425). It will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/rust-ulid>. I packaged this is in [1]. I'm not sure what the status of rust-team actually getting the package out is. Feel free to salvage as much or as little of that MR as you'd like! Best, Antonio Russo https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/657
Bug#1082164: cargo and rust dependencies could be relaxed
Package: python3-setuptools-rust Version: 1.5.2-2 Severity: wishlist X-Debbugs-Cc: aeru...@aerusso.net Dear Maintainer, I'm trying to backport matrix-synapse, which build-depends on this package. I am unable to use it for this purpose because python3-setuptools-rust requires cargo, and does not allow for cargo-web to satisfy that requirement. I've attached a trivial patch that simplifies the build-dependency. If this is acceptable, I'd like to also get this updated version into backports. I'll add that I've applies this patch onto 1.5.2-2 and can confirm that cargo-web indeed interacts well enough with python3-setuptools-rust as packaged to actually build something. Best, Antonio Russo From 0acc174812eb3020e57ed05e4c7e5d5efd6d18c9 Mon Sep 17 00:00:00 2001 From: Antonio Enrico Russo Date: Wed, 18 Sep 2024 18:39:10 -0600 Subject: [PATCH] Relax rust dependency The cargo dependency automatically pulls in a compatible version of rust, so remove that redundant requirement. Additionally, cargo-web is allowed to satisfy the cargo dependency. Signed-off-by: Antonio Enrico Russo --- debian/control | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index dd0b005..b48120d 100644 --- a/debian/control +++ b/debian/control @@ -22,7 +22,7 @@ Vcs-Git: https://salsa.debian.org/python-team/packages/python-setuptools-rust.gi Vcs-Browser: https://salsa.debian.org/python-team/packages/python-setuptools-rust Package: python3-setuptools-rust -Depends: python3-setuptools, ${misc:Depends}, ${python3:Depends}, rustc, cargo +Depends: python3-setuptools, ${misc:Depends}, ${python3:Depends}, cargo | cargo-web Architecture: all Description: Setuptools Rust extension plugin setuptools-rust is a plugin for setuptools to build Rust Python -- 2.45.1
Bug#1078791: Missing permissions for screen capture
Hello Jessie, On 2024-08-16 10:42, Jesse Rhodes wrote: > Can you clarify exactly what functionality is missing without this > interface, and how to reproduce the issue? Is there an upstream bug? I'm not able to reproduce this any more (i.e., I rolled back the change I made to /usr/share/applications/org.kde.spectacle.desktop, and I can still take screenshots of the whole desktop). Moreover, I can reproduce the original buggy behavior by removing the line > X-KDE-DBUS-Restricted-Interfaces=org.kde.KWin.ScreenShot2 from the .desktop file for spectacle. At the time, spectacle was only able to take screen shots using the "Window Under Cursor" option. I modified the desktop file as I described in the original bug report, and the issue was resolved (I guessed the name from some error output from spectacle, about permission being denied to acces). I now no longer believe that patch has any merit, and that it was there mere act of changing the file that triggered it to be (re)loaded that resolved the issue. At the time, I was also experiencing another unexpected behavior: none of the desktop files seemed to be getting picked up. For instance, the "Application Menu" widget had no items in it. Additionally, the "default applications" section of systemsettings had no programs to select, despite, for example, Thunderbird being installed. I had upgraded bits and pieces of KDE since that time, and the desktop files are now apparently being parsed: the menu is now fully populated and the Default Application section shows, e.g., Firefox and Thunderbird as options for default web browser and email client. I will say that I had rebooted the machine before trying to take the screenshot. This bug report should probably be closed: my best guess as to what happened is that some third package was blocking desktop files from being parsed, but that issue now appears resolved. > > Also, do you have a link to where these options are documented? I'd > like to make sure we didn't miss anything else. I was reasoning entirely based off the fact that adding that line fixed the behavior. I doubt that alleged interface even exists. > sney Best, Antonio OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1078791: Missing permissions for screen capture
Package: kde-spectacle Version: 24.05.2-1 Severity: normal Dear Maintainer, For wayland screen capture, the appropriate "restricted interfaces" must be authorized for use. This is done in /usr/share/applications/org.kde.spectacle.desktop with the X-KDE-DBUS-Restricted-Interfaces option. The "org.kde.KWin.CaptureScreen" interface is used by spectacle to capture the entire screen (ScreenShot2 is only used to capture a single window). Please change the line 204 from X-KDE-DBUS-Restricted-Interfaces=org.kde.KWin.ScreenShot2 to X-KDE-DBUS-Restricted-Interfaces=org.kde.KWin.ScreenShot2,org.kde.KWin.CaptureScreen Best, Antonio Russo OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1075803: failure piping "large" output to virtual machine
Package: autopkgtest Version: 5.28 Severity: normal X-Debbugs-Cc: aeru...@aerusso.net Dear Maintainer, I'm not sure if this bug belongs to sbuild, sbuild-qemu, or autopkgtest. The problem I am experiencing is that passing --extra-package with a large enough package (93 MB is the example I am running into). The copy to vm fails (hangs apparently indefinitely, and breaks further interaction with the VM). The stdin file on the 9p shared filesystem winds up the same size as stdin_eof flag-file. Is this limitation known and/or am I doing something wrong with the VM? Best, Antonio Russo OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
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: