Bug#1068886: RFP: rust-topgrade -- all-in-one upgrade tool which doesn't try reinventing the wheel
Package: wnpp Severity: wishlist X-Debbugs-Cc: kni9p...@anonaddy.me, debian-r...@lists.debian.org * Package name: rust-topgrade Version : 14.0.1 Upstream Contact: r-darwish * URL : https://github.com/topgrade-rs/topgrade * License : GPL-3.0 license Programming Lang: Rust Description : all-in-one upgrade tool which doesn't try reinventing the wheel Keeping your system up to date usually involves invoking multiple package managers. This results in big, non-portable shell one-liners saved in your shell. To remedy this, Topgrade detects which tools you use and runs the appropriate commands to update them. It can upgrade firmware, native packages, Flatpak, Docker containers, TLDR, vim plugins, ... and pull Git repositories on the host machine as well as on remote machines via SSH.
Bug#1067095: keepassxc: update to new upstream release 2.7.7
Package: keepassxc Version: 2.7.6+dfsg.1-1 Severity: wishlist X-Debbugs-Cc: kni9p...@anonaddy.me Dear Maintainer, please update KeePassXC to the latest upstream release 2.7.7. Thanks for your work! -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages keepassxc depends on: ii libargon2-10~20190702+dfsg-4+b1 ii libbotan-2-19 2.19.4+dfsg-1 ii libc6 2.37-15.1 ii libgcc-s1 14-20240315-1 ii libminizip11:1.3.dfsg-3+b1 ii libpcsclite1 2.0.1-1+b1 ii libqrencode4 4.1.1-1+b2 ii libqt5concurrent5 5.15.10+dfsg-7 ii libqt5core5a 5.15.10+dfsg-7 ii libqt5dbus55.15.10+dfsg-7 ii libqt5gui5 5.15.10+dfsg-7 ii libqt5network5 5.15.10+dfsg-7 ii libqt5svg5 5.15.10-2+b1 ii libqt5widgets5 5.15.10+dfsg-7 ii libqt5x11extras5 5.15.10-2+b1 ii libreadline8 8.2-3+b1 ii libstdc++6 14-20240315-1 ii libusb-1.0-0 2:1.0.27-1 ii libx11-6 2:1.8.7-1 ii libxtst6 2:1.2.3-1.1 ii libzxcvbn0 2.5+dfsg-2 ii zlib1g 1:1.3.dfsg-3.1 Versions of packages keepassxc recommends: ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1 Versions of packages keepassxc suggests: ii webext-keepassxc-browser 1.9.0.2+repack1-1 pn xclip -- no debconf information
Bug#1067003: howdoi: Please consider updating to recent upstream version v2.0.20
Package: howdoi Version: 1.1.9-1.1 Severity: wishlist X-Debbugs-Cc: kni9p...@anonaddy.me Dear Maintainer, howdoi is currently unusable as it is REALLY outdated (pls also see #1051370). A new upstream release would fix this as well as making new functionalities available. Best Regards Carl Johnson -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.13+bpo-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages howdoi depends on: ii python3 3.11.2-1+b1 ii python3-cssselect 1.2.0-2 ii python3-lxml4.9.2-1+b1 ii python3-pygments2.14.0+dfsg-1 ii python3-pyquery 1.4.3-1 ii python3-requests2.28.1+dfsg-1 ii python3-requests-cache 0.9.8-1 howdoi recommends no packages. howdoi suggests no packages. -- no debconf information
Bug#1065227: synaptic: description of packages not showing up in lower window (packages that are not already installed)
Package: synaptic Version: 0.91.3 Severity: important X-Debbugs-Cc: carlniko...@gmail.com Dear Maintainer, opened the synaptic package manager clicked on any package to read the description no description of package shown i expected the description to be visible. so i don't know what the package is supposed to be if i cannot read description. -- System Information: Debian Release: trixie/sid Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages synaptic depends on: ii hicolor-icon-theme 0.17-2 ii libapt-pkg6.02.7.12 ii libc62.37-15 ii libept1.6.0 1.2.1 ii libgcc-s114-20240201-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b1 ii libglib2.0-0 2.78.4-1 ii libgtk-3-0 3.24.41-1 ii libpango-1.0-0 1.52.0+ds-1 ii libstdc++6 14-20240201-3 ii libvte-2.91-00.75.91-2 ii libxapian30 1.4.22-1+b1 ii pkexec 124-1 ii polkitd 124-1 Versions of packages synaptic recommends: ii libgtk3-perl 0.038-3 ii xdg-utils 1.1.3-4.1 Versions of packages synaptic suggests: pn apt-xapian-index pn deborphan pn dwww pn software-properties-gtk ii tasksel 3.75 -- no debconf information
Bug#1061230: python3-fava: Incompatible with python3-flask-babel version 4
Package: python3-fava Version: 1.23.1+dfsg-1 Severity: important Tags: upstream Dear Maintainer, Fava appears to be incompatible with the version of flask-babel in Debian. Any attempt to run it results in: Traceback (most recent call last): File "/usr/bin/fava", line 5, in from fava.cli import main File "/usr/lib/python3/dist-packages/fava/cli.py", line 13, in from fava.application import app File "/usr/lib/python3/dist-packages/fava/application.py", line 152, in BABEL.localeselector(get_locale) AttributeError: 'Babel' object has no attribute 'localeselector' This appears to have been fixed upstream, with the fix appearing in version 1.24 (https://github.com/beancount/fava/issues/1549). -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.11-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-fava depends on: ii python3 3.11.6-1 ii python3-babel2.10.3-3 ii python3-beancount2.3.6-1 ii python3-cheroot 10.0.0+ds1-1 ii python3-click8.1.6-1 ii python3-flask2.2.5-1 ii python3-flask-babel 4.0.0-1 ii python3-jinja2 3.1.2-1 ii python3-markdown22.4.11-1 ii python3-ply 3.11-6 ii python3-simplejson 3.19.2-1+b1 ii python3-werkzeug 2.3.8-1 python3-fava recommends no packages. python3-fava suggests no packages. -- no debconf information
Bug#1059909: wormhole-william: please enable shell completions by default
Package: wormhole-william Version: 1.0.6-3+b2 Severity: wishlist X-Debbugs-Cc: kni9p...@anonaddy.me Dear Maintainer, upon installation, IMHO it would make sense to enable the shell completions by default for any of bash, zsh and fish present. Cheers -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.8-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wormhole-william depends on: ii libc6 2.37-13 wormhole-william recommends no packages. wormhole-william suggests no packages. -- no debconf information
Bug#1059397: extrepo: please consider fish and zsh autocompletion for subcommands like "search" and "enable"
Package: extrepo Version: 0.12 Severity: wishlist X-Debbugs-Cc: kni9p...@anonaddy.me Dear Maintainer, please consider adding fish and zsh autocompletion for subcommands like "search" and "enable" as this would greatly improve user experience. Thanks -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages extrepo depends on: ii gpgv 2.2.40-1.1 ii libcryptx-perl0.080-2 ii libdpkg-perl 1.22.2 ii libwww-perl 6.72-1 ii libyaml-libyaml-perl 0.86+ds-1 ii perl 5.36.0-10 Versions of packages extrepo recommends: ii extrepo-offline-data 1.0.3 extrepo suggests no packages. -- Configuration Files: /etc/extrepo/config.yaml changed: --- url: https://extrepo-team.pages.debian.net/extrepo-data dist: debian version: sid enabled_policies: - main - contrib - non-free -- no debconf information
Bug#1053303: Wishlist request to allow "mount --fstab /etc/fstab.d ..." as a user
Package: util-linux Version: 2.37.2-4ubuntu3 Severity: wishlist I can break the /etc/fstab into separate files in a directory, but /etc/fstab.d won't be read by default. I would have to use an explicit argument "mount -T /etc/fstab.d" but the -T (and the equivalent --fstab) are only allowed to be used by root. I like the idea of splitting the fstab into files so I can compartmentalize the information and manage the files independently in GIT. When I install a new system I'd just plop the files into /etc/fstab.d and not have to use hacks like appending or patching, which make the contents of the file look like junk. Could you please allow "-T /etc/fstab.d" to be work for users, and just exclude users from using other path-arguments? I suppose this would have to be implemented upstream of Debian, but I don't know how to file that. References: https://askubuntu.com/questions/168290/why-cant-mount-read-files-in-etc-fstab-d https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663623 https://marc.info/?l=util-linux-ng=132740311801201=2
Bug#1051541: RFP: rustic -- fast, encrypted, and deduplicated backups powered by Rust
Package: wnpp Severity: wishlist X-Debbugs-Cc: kni9p...@anonaddy.me, werdah...@riseup.net, pkg-rust-maintain...@alioth-lists.debian.net * Package name: rustic Version : 0.5.4 Upstream Contact: Alexander Weiss * URL : https://github.com/rustic-rs/rustic * License : Apache-2.0 or MIT Programming Lang: Rust Description : fast, encrypted, and deduplicated backups powered by Rust Restic (https://github.com/restic/restic/) is a great backup tool IMHO. The compatible Rust implementation rustic is a lot faster and has a lot more other features over the Golang version, for example: - `rustic repair` command allows to repair some kinds of broken repositories - `backup` command can use `.gitignore` files - `restore` uses existing files; also option `--delete` available I think that'd be a very useful utility to have in Debian.
Bug#1051082: drkonqi: Crash report wizard complete, but drkonqi then sits for hours without completing send
Package: drkonqi Version: 5.27.5-2 Severity: normal Dear Maintainer, I was trying to report a KWin crash using drkonqi. I answered all the many questions the "KWin - The KDE Crash Handler" window (which I believe is drkonqi) asked me, pressed Submit, and ... it has been sitting there spinning the little cogwheel for about 10 hours now, without actually sending. Ideally, it should actually send the error report. Or at least time out eventually, not sit there literally overnight, presumably retrying some sort of operation. (It's very opaque what is actually going on.) I mean, reportbug itself is weirdly hard to use, but at least it detects a failure to send and tells the user what is happening. -- System Information: Debian Release: 12.1 APT prefers stable-updatesVersions of packages drkonqi depends on: ii init-system-helpers 1.65.2 ii kio 5.103.0-1 ii libc6 2.36-9+deb12u1 ii libgcc-s1 12.2.0-14 ii libkf5configcore5 5.103.0-2 ii libkf5configgui5 5.103.0-2 ii libkf5coreaddons5 5.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5idletime5 5.103.0-2 ii libkf5jobwidgets5 5.103.0-1 ii libkf5kiocore5 5.103.0-1 ii libkf5kiogui5 5.103.0-1 ii libkf5notifications5 5.103.0-1 ii libkf5service-bin 5.103.0-1 ii libkf5service5 5.103.0-1 ii libkf5syntaxhighlighting5 5.103.0-3 ii libkf5wallet-bin 5.103.0-1 ii libkf5wallet5 5.103.0-1 ii libkf5widgetsaddons5 5.103.0-1 ii libkf5windowsystem5 5.103.0-1 ii libkuserfeedbackcore1 1.2.0-2 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5dbus5 5.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5network5 5.15.8+dfsg-11 ii libqt5qml5 5.15.8+dfsg-3 ii libqt5widgets5 5.15.8+dfsg-11 ii libstdc++6 12.2.0-14 ii libsystemd0 252.12-1~deb12u1 ii qml-module-org-kde-syntaxhighlighting 5.103.0-3 Versions of packages drkonqi recommends: ii systemd-coredump 252.12-1~deb12u1 drkonqi suggests no packages. -- no debconf information APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1050211: openvpn-dco-dkms: module fails to build for kernel 6.4.0: fatal error: net/gso.h: No such file or directory
Package: openvpn-dco-dkms Version: 0.0+git20230816-1 Severity: important Dear Maintainer, The module does not build in kernel 6.4.0 due to the file net/gso.h not being found. I note that this is the same file introduced by the fix for #1043116. Log follows. DKMS make.log for ovpn-dco-0.0+git20230816 for kernel 6.4.0-2-amd64 (x86_64) Tue 22 Aug 2023 14:49:19 AEST /var/lib/dkms/ovpn-dco/0.0+git20230816/build/gen-compat-autoconf.sh /var/lib/dkms/ovpn-dco/0.0+git20230816/build/compat-autoconf.h make -C /lib/modules/6.4.0-2-amd64/build M=/var/lib/dkms/ovpn-dco/0.0+git20230816/build PWD=/var/lib/dkms/ovpn-dco/0.0+git20230816/build REVISION=0.0+git20230816 CONFIG_OVPN_DCO_V2=m INSTALL_MOD_DIR=updates/ modules make[1]: Entering directory '/usr/src/linux-headers-6.4.0-2-amd64' CC [M] /var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/main.o CC [M] /var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/bind.o CC [M] /var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/crypto.o CC [M] /var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/ovpn.o /var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/ovpn.c:25:10: fatal error: net/gso.h: No such file or directory 25 | #include | ^~~ compilation terminated. make[3]: *** [/usr/src/linux-headers-6.4.0-2-common/scripts/Makefile.build:257: /var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/ovpn.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [/usr/src/linux-headers-6.4.0-2-common/scripts/Makefile.build:499: /var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco] Error 2 make[1]: *** [/usr/src/linux-headers-6.4.0-2-common/Makefile:2051: /var/lib/dkms/ovpn-dco/0.0+git20230816/build] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-6.4.0-2-amd64' make: *** [Makefile:59: all] Error 2 Carl -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openvpn-dco-dkms depends on: ii dkms 3.0.11-3 openvpn-dco-dkms recommends no packages. openvpn-dco-dkms suggests no packages. -- no debconf information
Bug#1043316: git-delta is a binary in git-extras
Source: git-delta Version: 0.16.5-2 Severity: wishlist Dear Maintainer, The package git-extras provides /usr/bin/git-delta and an associated man page. This is completely unrelated to /usr/bin/delta provided by git-delta, other than that they both work with git. I assume that most people would be looking for this git-delta, not the other one, which is a very minimal script. There's no technical issue since the binaries are named differently, but the fact that /usr/bin/git-delta and `man git-delta` are not related to git-delta makes things slightly confusing as a user. Perhaps it's worth a note in README.Debian or the package description? Feel free to close this if you disagree; just thought it was worth pointing out.
Bug#1042801: Enhancement request to "AcceptEnv TZ" in /usr/share/openssh/sshd_config file
Package: openssh-server Version: Latest By default, the /usr/share/openssh/sshd_config file contains these lines |112 # Allow client to pass locale environment variables 113 AcceptEnv LANG LC_*| ||I'd like to have the TZ variable added to the list on line 113. That way when I travel, and connect to some remote cluster from wherever I am, the dates on everything will be relative to my current timezone. Note that, unless someone uses an explicit "SendEnv TZ" in their connection, everything would behave as before. I've asked the managers of several of these clusters to add the TZ variable to the list. Most of them refuse to do it, under the assumption that it would cause a security breach. I think that the change needs to be made upstream. || //
Bug#1028258: ddcci-dkms: Module fails to build for kernel 6.1
Package: ddcci-dkms Version: 0.4.2-3 Severity: important Dear Maintainer, The ddcci module failed to build with linux-headers-6.1.0-1-common: DKMS make.log for ddcci-0.4.2 for kernel 6.1.0-1-amd64 (x86_64) Mon 09 Jan 2023 09:26:34 AEDT make: Entering directory '/var/lib/dkms/ddcci/0.4.2/build' make -C "ddcci" make[1]: Entering directory '/var/lib/dkms/ddcci/0.4.2/build/ddcci' make -C "/lib/modules/6.1.0-1-amd64/build" M="/var/lib/dkms/ddcci/0.4.2/build/ddcci" modules make[2]: Entering directory '/usr/src/linux-headers-6.1.0-1-amd64' CC [M] /var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.o /var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1813:27: error: initialization of ‘void (*)(struct i2c_client *)’ from incompatible pointer type ‘int (*)(struct i2c_client *)’ [-Werror=inc> 1813 | .remove = ddcci_remove, | ^~~~ /var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1813:27: note: (near initialization for ‘ddcci_driver.remove’) cc1: some warnings being treated as errors make[3]: *** [/usr/src/linux-headers-6.1.0-1-common/scripts/Makefile.build:255: /var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.o] Error 1 make[2]: *** [/usr/src/linux-headers-6.1.0-1-common/Makefile:2017: /var/lib/dkms/ddcci/0.4.2/build/ddcci] Error 2 make[2]: Leaving directory '/usr/src/linux-headers-6.1.0-1-amd64' make[1]: *** [Makefile:38: ddcci.ko] Error 2 make[1]: Leaving directory '/var/lib/dkms/ddcci/0.4.2/build/ddcci' make: *** [Makefile:28: ddcci] Error 2 make: Leaving directory '/var/lib/dkms/ddcci/0.4.2/build' It looks like this is not yet fixed upstream: https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux/-/issues/31 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ddcci-dkms depends on: ii dkms 3.0.9-1 ddcci-dkms recommends no packages. ddcci-dkms suggests no packages. -- no debconf information
Bug#1025278: sra-toolkit: binary sratools installed on PATH
Package: sra-toolkit Version: 3.0.0+dfsg-1 Severity: wishlist Dear Maintainer, sra-toolkit installs a binary /usr/bin/sratools, which is intended to be used via the symlinks installed by the package (since its behaviour is influenced by the name of the executable): lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/fasterq-dump -> sratools lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/fastq-dump -> sratools lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/prefetch -> sratools lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/sam-dump -> sratools lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/sra-pileup -> sratools lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/srapath -> sratools lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/vdb-dump -> sratools Invoking the executable by its original name does nothing useful: $ /usr/bin/sratools An error occured: unrecognized tool sratools If this continues to happen, please contact the SRA Toolkit at https://trace.ncbi.nlm.nih.gov/Traces/sra/ Perhaps sratools should be installed in a private directory like /usr/lib/sra-toolkit, leaving only the symlinks in /usr/bin. Given the absence of man pages for the tools, and not being familiar with them, this caused me some confusion because it appeared something was broken. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sra-toolkit depends on: ii libbz2-1.0 1.0.8-5+b1 ii libc6 2.36-6 ii libhdf5-103-1 1.10.8+repack-4 ii libmagic1 1:5.41-4 ii libncbi-vdb3 3.0.0+dfsg2-4 ii libncbi-wvdb2 2.11.2+dfsg-6 ii libncbi-wvdb3 3.0.0+dfsg2-4 ii libre2-9 20220601+dfsg-1 ii libxml22.9.14+dfsg-1.1+b2 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages sra-toolkit recommends: ii med-config 3.7.3 sra-toolkit suggests no packages. -- no debconf information
Bug#927989: RFA: terminaltables -- Python library for printing tables to the console
Hi Daniel, Please go ahead! It would make sense to also take on colorclass (https://bugs.debian.org/929658) at the same time since it's a dependency of terminaltables. I pushed updates to git for both packages to track the new upstream forks, but didn't attempt to package new upstream versions. Feel free to remove me from the Uploaders. Cheers, Carl On 16/9/22 09:17, Daniel Baumann wrote: > Hi Carl, > > I'm maintaining all of the dbi packages (mycli, pglci, etc.) in Debian, > which use terminaltables. I'm happy to also take care about > terminaltables if that's fine with you. > > Regards, > Daniel
Bug#887932: Reopen bug report
Hello Maintainer, I would like to report this bug as still relevant I have an Intel 8260AC adapter. Despite installing the driver listed here https://packages.debian.org/bookworm/firmware-iwlwifi The bluetooth does not work... under bluetoothctl it says no such adapter found... on an LSPCI output it only shows that it's a network adapter however there is nothing listed under bluetooth so...the bluetooth functionality is non-existent Can you please tell me what to do in order to help diagnose the bug? I'm running bookworm version of firmware-iwlwifi (version 20210818-) I can confirm that this bluetooth functionality works in windows 10.. Thank you Carl
Bug#1017076: qtbase6-dev: qt6-base-dev not being cached with apt-get server for bookworm
Package: qtbase6-dev Version: qt6-base-dev Severity: normal X-Debbugs-Cc: carlniko...@gmail.com Dear Maintainer, apt-get install qt6-base-dev did not work could not install version 6 from terminal. only version 5 came up in results for bookworm main on sources.list despite it supposedly being listed for bookworm on the server.. apt nor apt-get did not download files and dependencies correctly as it could not 'Locate them' expected to not have to download files manually from the debian file server for version qt6-base-dev... -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#889691: gedit-plugin-git: AttributeError calling get_repository on None
Package: gedit-plugin-git Followup-For: Bug #889691 I can no longer reproduce this issue so I assume it was fixed by an upstream updated in the meantime. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gedit-plugin-git depends on: ii gedit 42.1-1 ii gedit-plugins-common 42.1-1 ii gir1.2-ggit-1.0 1.0.0.1-2 ii gir1.2-glib-2.0 1.72.0-1+b1 ii gir1.2-gtk-3.03.24.34-1 ii gir1.2-gtksource-44.8.3-1 ii python3 3.10.4-1+b1 ii python3-gi3.42.1-1 ii python3-gi-cairo 3.42.1-1 gedit-plugin-git recommends no packages. gedit-plugin-git suggests no packages. -- no debconf information
Bug#927989: Looking for a new uploader for terminaltables and colorclass
Hi python team, I'm looking for someone to take over two python-team-maintained packages: terminaltables and colorclass. These are related packages for formatting text for output to the terminal, and both have had RFAs for a while (in CC). terminaltables has several reverse dependencies. colorclass has only 1 reverse build dependency: terminaltables. Since I last touched the packages, a new upstream maintainer has taken over both of them so the Debian packages should track the new forks and update copyright and upstream data accordingly (I filed bugs for this). Other than that, there shouldn't be much to do besides replacing me as the uploader for both packages, since the team has taken care of routine maintenance in the meantime. Thanks, Carl
Bug#1014036: colorclass: New upstream maintainer and repository
Source: colorclass Version: 2.2.0-3 Severity: normal The original upstream maintainer of colorclass has archived the repository on GitHub. Development now occurs at a new fork: https://github.com/matthewdeanmartin/colorclass The new maintainer has also been given control of the package on PyPi. The debian package should be updated to track the new upstream repository.
Bug#1014035: terminaltables: New upsteam maintainer and repository
Source: terminaltables Version: 3.1.0-4 Severity: normal The original upstream maintainer of terminaltables has archived the repository on GitHub. Development now occurs at a new fork: https://github.com/matthewdeanmartin/terminaltables The new maintainer has also been given control of the package on PyPi. The debian package should be updated to track the new upstream repository.
Bug#929658: RFA: colorclass -- ANSI color text library for Python
python3-terminaltables build-depends on python3-colorclass since it tests interoperability and provides examples of using the packages together. I cancelled the RM request. Perhaps there should also be a Suggests relationship added to reflect the interoperability.
Bug#1011593: RM: colorclass -- ROM; leaf package, no longer needed
Package: ftp.debian.org Severity: normal I packaged this Python library as a dependency for an ITP that I eventually dropped because of its large number of dependencies. I files an RFA for colorclass a long time ago (#929658) and emailed the team list but have had no takers. There are no reverse dependencies, so I think we should rm colorclass.
Bug#1011590: RM: plowshare -- ROM; effectively unmaintained upstream
Package: ftp.debian.org Severity: normal Plowshare is a tool for interacting with file sharing websites. The plowshare package itself contains only the framework (implemented in shell scripts) but separate "modules" are needed to actually implement support for specific websites. The modules need to change rapidly to keep up with developments on the file sharing websites, and as such are not a great fit for Debian packaging (I tried in the past but eventually removed them). The upstream-endorsed way to get the modules is to use a bundled script to download them, but there are security concerns with downloading a bunch of shell scripts from the internet and blindly executing them. There is also a security concern with the use of a javascript engine to interact with the sometimes sketchy file sharing sites that resulted in a Debian patch to disable this feature by default. With the JS engine disabled, many modules don't work. Upstream development on these modules has essentially stopped, and presumably many are now broken. In theory you can write your own modules, in which case the plowshare package has some value by itself. I suspect that few people would do this though, especially without any public place to share modules and the burden of maintaining them. Popcon stats show a decline in reports for plowshare since the removal of the modules. It is a leaf package with no reverse dependencies.
Bug#1010836: biosyntax-gedit: No longer works with recent versions of gedit
Package: biosyntax-gedit Version: 1.0.0b-2 Severity: important Dear Maintainer, The gedit support for biosyntax works by dropping files in: /usr/share/gtksourceview-3.0/ The README.Debian says that this should cause a theme to appear in gedit at Edit > Preferences > Font & Color > bioSyntax No such entry appears. I notice that gedit depends on libgtksourceview-4-0 and that there exist directories /usr/share/gtksourceview-4/ /usr/share/gtksourceview-5/ I tested copying the style definition to the corresponding place under gtksourceview-4/ and gedit picked it up properly, so it seems that the files should be installed at that path instead. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages biosyntax-gedit depends on: ii biosyntax-common 1.0.0b-2 ii gedit 42.0-2 biosyntax-gedit recommends no packages. biosyntax-gedit suggests no packages. -- no debconf information
Bug#1010834: biosyntax-vim: Unusable with vim-addon-manager because of outdated manifest
Package: biosyntax-vim Version: 1.0.0b-2 Severity: important Dear Maintainer, The instructions in README.Debian say that the addon should be installed with vim-addon-manager, however: $ vim-addons install biosyntax Warning: ignoring 'biosyntax' which is missing source files Helpfully, vim-addon-manager can list the files it's complaining about: $ vim-addons files biosyntax | while read -r f; do test -e "/usr/share/vim/addons/$f" || echo "$f"; done ftdetect/cwl.vim ftdetect/nexus.vim ftdetect/pml.vim syntax/cwl.vim syntax/nexus.vim syntax/pml.vim It looks like the manifest file at debian/biosyntax-vim.yaml includes extra files that are no longer included in the upstream package: https://salsa.debian.org/med-team/biosyntax/-/blob/580479a8ea5f26f67608fa38f4910180f4136b20/debian/biosyntax-vim.yaml vs https://salsa.debian.org/med-team/biosyntax/-/tree/b87d9d2c964e1c30ff82ff7c0883e82576d89043/vim -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages biosyntax-vim depends on: ii biosyntax-common 1.0.0b-2 ii vim 2:8.2.4793-1 ii vim-gtk3 [vim]2:8.2.4793-1 Versions of packages biosyntax-vim recommends: ii vim-addon-manager 0.5.10 biosyntax-vim suggests no packages. -- no debconf information
Bug#1010788: spades: Mismatch correction / --careful mode broken by Debian patch
Package: spades
Version: 3.15.4+dfsg-1
Severity: normal
Dear Maintainer,
Using spades with the --careful flag triggers the following error:
Traceback (most recent call last):
File "/usr/libexec/spades/spades.py", line 683, in
main(sys.argv)
File "/usr/libexec/spades/spades.py", line 621, in main
cfg, dataset_data, command_line = parse_args(args, log)
File "/usr/libexec/spades/spades.py", line 257, in parse_args
options, cfg, dataset_data = options_parser.parse_args(log, bin_home,
spades_home,
File "/usr/share/spades/spades_pipeline/options_parser.py", line 1157, in
parse_args
add_to_cfg(cfg, log, bin_home, spades_home, options_storage.args)
File "/usr/share/spades/spades_pipeline/options_parser.py", line 995, in
add_to_cfg
if which("bwa-spades"):
NameError: name 'which' is not defined
Reproducible with e.g.:
f="$(mktemp .fq)"
echo -e "@a\nA\n+\n!" > "$f"
spades --careful --12 "$f" -o "/tmp"
The code path related to that flag in options_parser.py has been patched in
Debian to add the call to which():
https://salsa.debian.org/med-team/spades/-/blob/d3c54b2ae8f0ee29a639fe0246d670fcad54b45b/debian/patches/0003_accept-system-bwa.patch#L82-L95
When the patch was initially created in this commit:
https://salsa.debian.org/med-team/spades/-/commit/ac1cfa145bf4066ca7f3af47db1aae6dd28ac5ab
the call and definition of which() were both in spades.py but the call was
later moved to options_parser.py while the definition was left behind unused.
Rather than adding multiple definitions of which() in the patch, the single
version in support.py could be imported wherever it needs to be used.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages spades depends on:
ii bamtools 2.5.1+dfsg-10+b1
ii bwa0.7.17-7
ii libc6 2.33-7
ii libgcc-s1 12.1.0-1
ii libgomp1 12.1.0-1
ii libnlopt0 2.7.1-4+b1
ii libssw01.1-13
ii libstdc++6 12.1.0-1
ii python33.10.4-1+b1
ii python3-distutils 3.9.12-1
ii python3-joblib 0.17.0-4
ii python3-yaml 5.4.1-1+b1
ii samtools 1.13-4
ii zlib1g 1:1.2.11.dfsg-4
spades recommends no packages.
spades suggests no packages.
-- no debconf information
Bug#732788: Processed (with 5 errors): 732788
How often should I ping you? On Thu, Jan 13, 2022 at 2:13 PM Carl Karsten wrote: > > On Mon, Jan 3, 2022 at 3:51 AM Carl Karsten wrote: > > > > https://salsa.debian.org/cloud-team/cloud-initramfs-tools/-/merge_requests/5 > > bump ^^^ > > > > > On Sat, Jan 1, 2022 at 8:28 AM Thomas Goirand wrote: > > > > > > On 12/31/21 10:14 PM, Carl Karsten wrote: > > > > What do I need to do to get overlayroot into unstable? > > > > > > Hi, > > > > > > Thanks for your explanation, now I get it. > > > > > > If you want to work on this yourself, you can simply provide a merge > > > request in the Salsa repository over here: > > > https://salsa.debian.org/cloud-team/cloud-initramfs-tools > > > > > > then ping me again in this bug. > > > > > > Cheers, > > > > > > Thomas Goirand (zigo) > > > > > > > > -- > > Carl K > > > > > -- > Carl K -- Carl K
Bug#732788: Processed (with 5 errors): 732788
On Mon, Jan 3, 2022 at 3:51 AM Carl Karsten wrote: > > https://salsa.debian.org/cloud-team/cloud-initramfs-tools/-/merge_requests/5 bump ^^^ > > On Sat, Jan 1, 2022 at 8:28 AM Thomas Goirand wrote: > > > > On 12/31/21 10:14 PM, Carl Karsten wrote: > > > What do I need to do to get overlayroot into unstable? > > > > Hi, > > > > Thanks for your explanation, now I get it. > > > > If you want to work on this yourself, you can simply provide a merge > > request in the Salsa repository over here: > > https://salsa.debian.org/cloud-team/cloud-initramfs-tools > > > > then ping me again in this bug. > > > > Cheers, > > > > Thomas Goirand (zigo) > > > > -- > Carl K > -- Carl K
Bug#732788: Processed (with 5 errors): 732788
https://salsa.debian.org/cloud-team/cloud-initramfs-tools/-/merge_requests/5 On Sat, Jan 1, 2022 at 8:28 AM Thomas Goirand wrote: > > On 12/31/21 10:14 PM, Carl Karsten wrote: > > What do I need to do to get overlayroot into unstable? > > Hi, > > Thanks for your explanation, now I get it. > > If you want to work on this yourself, you can simply provide a merge > request in the Salsa repository over here: > https://salsa.debian.org/cloud-team/cloud-initramfs-tools > > then ping me again in this bug. > > Cheers, > > Thomas Goirand (zigo) -- Carl K
Bug#998801: peruse: Missing dependency on kcm - unable to start
Package: peruse Version: 1.80+dfsg-1 Severity: grave Justification: renders package unusable Dear Maintainer, When launching peruse from a terminal, it fails to launch, printing this message: Failed to load the component from disk. Reported error was: "qrc:/qml/Main.qml:26 Type PeruseMain unavailable\nqrc:/qml/PeruseMain.qml:357 Type Settings unavailable\nqrc:/qml/Settings.qml:29 module \"org.kde.kcm\" is not installed\n" If I manually install qml-module-org-kde-kcm it works, so I assume this is a missing dependency. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages peruse depends on: ii kio5.86.0-1 ii libc6 2.32-4 ii libgcc-s1 11.2.0-10 ii libkf5archive5 5.86.0-1 ii libkf5baloo5 5.86.0-1 ii libkf5configcore5 5.86.0-1 ii libkf5coreaddons5 5.86.0-1 ii libkf5crash5 5.86.0-1 ii libkf5declarative5 5.86.0-1 ii libkf5filemetadata35.86.0-1 ii libkf5guiaddons5 5.86.0-1 ii libkf5i18n55.86.0-1 ii libkf5kiocore5 5.86.0-1 ii libkf5kiowidgets5 5.86.0-1 ii libkf5newstuffcore55.86.0-3 ii libqt5core5a 5.15.2+dfsg-12 ii libqt5gui5 5.15.2+dfsg-12 ii libqt5qml5 [qtdeclarative-abi-5-15-2] 5.15.2+dfsg-8 ii libqt5quick5 5.15.2+dfsg-8 ii libqt5sql5 5.15.2+dfsg-12 ii libqt5widgets5 5.15.2+dfsg-12 ii libstdc++6 11.2.0-10 ii peruse-common 1.80+dfsg-1 ii qml-module-org-kde-kirigami2 5.86.0-1 ii qml-module-org-kde-newstuff5.86.0-3 ii qml-module-qt-labs-folderlistmodel 5.15.2+dfsg-8 ii qml-module-qt-labs-settings5.15.2+dfsg-8 ii qml-module-qtquick-controls5.15.2-2 ii qml-module-qtquick-dialogs 5.15.2-2 ii qml-module-qtquick-layouts 5.15.2+dfsg-8 peruse recommends no packages. peruse suggests no packages. -- no debconf information
Bug#991136: fetch-crl: Install fails on update-rc.d
Hi, Thanks for replying. The measures below seems to have solved my issue. >Mattias Ellert writes: > Hi! > > The SysV init script should not be used on a system that is running > systemd. It is there to be used on non-systemd Debian installations > only (kfreebsd, hurd). If you have enabled this on a systemd based > system, please disable it. Indeed I had links to init scripts in the usual directories, /etc/rcN.d. I removed them with update-rc.d
Bug#991136: fetch-crl: Install fails on update-rc.d
Package: fetch-crl Version: 3.0.19-2 Severity: important Dear Maintainer, * I tried to uninstall and reinstall fetch-crl because of error * messages regarding a non-existing certificate. * Packet configuration fails on update-rc.d: No default runlevel. This is expected on a systemd based release as far as I can understand. init-system-helpers is installed. * I would expect fetch-crl to run from cron or a systemd timer, not * to install anything in rcN.d. Best regards, Carl-Fredrik Enell -- System Information: Debian Release: 10.10 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.bpo.7-amd64 (SMP w/64 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fetch-crl depends on: ii init-system-helpers 1.56+nmu1 ii libwww-perl 6.36-2 ii lsb-base 10.2019051400 ii openssl 1.1.1d-0+deb10u6 ii perl 5.28.1-6+deb10u1 fetch-crl recommends no packages. fetch-crl suggests no packages. -- no debconf information
Bug#969521: Browserpass icon disappears
Just to note, this is firefox bug #969174 and is not specific to browserpass.
Bug#975115: webext-dav4tbsync and webext-tbsync out of sync
Package: webext-dav4tbsync Followup-For: Bug #975115 Hi Mechtilde, I've just upgraded to tbsync 2.19-1 and now I have the opposite problem: tbsync recognises that dav4tbsync is is installed, but claims that eas4tbsync is missing. The situation for the EAS provider is now similar to what I reported above. The debug log shows: ** Wed Nov 25 2020 09:14:49 GMT+1100 (AEDT) ** [EventLog] : FAILED to load provider API version mismatch, TbSync@2.4 vs eas@Beta 2.4 ** Wed Nov 25 2020 09:14:52 GMT+1100 (AEDT) ** [Loaded provider] : dav::CalDAV & CardDAV (1.23) There's also a message in the log concerning the DAV provider, though it's perhaps unrelated: Component returned failure code: 0x8000 (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref] promisifiedHttpRequest/<@chrome://dav4tbsync/content/includes/network.js:515:64 promisifiedHttpRequest@chrome://dav4tbsync/content/includes/network.js:494:12 sendRequest@chrome://dav4tbsync/content/includes/network.js:428:33 I wonder if it's just that the providers need a stricter versioned dependency relationship with the main tbsync package to reflect whatever API version checks tbsync is doing internally? Cheers, Carl -- System Information: thunderbird1:78.5.0-1 webext-tbsync 2.19-1 webext-dav4tbsync 1.23-1 webext-eas4tbsync 1.20-1
Bug#975115: [Pkg-mozext-maintainers] Bug#975115: webext-dav4tbsync and webext-tbsync out of sync
I've just noticed this message in the debug log for tbsync about the provider failing to load: ** Mon Nov 23 2020 17:43:57 GMT+1100 (AEDT) ** [Initializing module] : ** Mon Nov 23 2020 17:43:57 GMT+1100 (AEDT) ** [TbSync init] : Done ** Mon Nov 23 2020 17:43:57 GMT+1100 (AEDT) ** [EventLog] : FAILED to load provider API version mismatch, TbSync@Beta 2.4 vs dav@2.4
Bug#975115: webext-dav4tbsync and webext-tbsync out of sync
Package: webext-dav4tbsync Version: 1.23-1 Followup-For: Bug #975115 I'm also having problems with this on sid. When I open the thunderbird addon manager, I see tbsync, dav4tbsync, and eas4tbsync all installed and enabled. All of these come from the debian packages. However, when I open the tbsync config window it claims that dav4tbsync is not installed. There is no such problem with eas4tbsync (webext-eas4tbsync 1.20-1), which works fine. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages webext-dav4tbsync depends on: ii thunderbird1:78.5.0-1 ii webext-tbsync 2.18-2 webext-dav4tbsync recommends no packages. webext-dav4tbsync suggests no packages. -- no debconf information
Bug#971689: #971689
The patch is attached. Looks like it was just that the tweener library was moved rather than removed. https://github.com/pixel-saver/pixel-saver/commit/cceefae50cf85f725385c492d756f4e3257473b7.patch >From cceefae50cf85f725385c492d756f4e3257473b7 Mon Sep 17 00:00:00 2001 From: Pellegrino Prevete Date: Thu, 1 Oct 2020 15:49:03 +0200 Subject: [PATCH] remove Tweener Shell dependency for 3.38 support --- pixel-sa...@deadalnix.me/app_menu.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pixel-sa...@deadalnix.me/app_menu.js b/pixel-sa...@deadalnix.me/app_menu.js index 51efd4c..138e29d 100644 --- a/pixel-sa...@deadalnix.me/app_menu.js +++ b/pixel-sa...@deadalnix.me/app_menu.js @@ -3,7 +3,7 @@ const Main = imports.ui.main; const Mainloop = imports.mainloop; const Shell = imports.gi.Shell; const St = imports.gi.St; -const Tweener = imports.ui.tweener; +const Tweener = imports.tweener.tweener; const ExtensionUtils = imports.misc.extensionUtils; const Me = ExtensionUtils.getCurrentExtension();
Bug#971689: gnome-shell-extension-pixelsaver: Fails with "No JS module 'tweener' found in search path"
Package: gnome-shell-extension-pixelsaver Version: 1.20-1 Severity: important Dear Maintainer, Looking in the "Extensions" app, Pixel Saver is disabled with an error message "No JS module 'tweener' found in search path". Apparently this JS library was part of Gnome Shell, but has since been removed. There is an upstream commit to fix this. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell-extension-pixelsaver depends on: ii gnome-shell 3.38.0-2 gnome-shell-extension-pixelsaver recommends no packages. gnome-shell-extension-pixelsaver suggests no packages. -- no debconf information
Bug#968586: ifupdown: No way to require IN and PD with inet6 config
Package: ifupdown Version: 0.8.35 Severity: important Tags: ipv6 Dear Maintainer, My ISP (Spectrum in the US) no longer support SLAAC for IPv6 autoconfiguration. Instead, DHCPv6 is required. However, a configuration stanza like: iface eth1 inet6 dhcp accept_ra 0 autoconf 0 request_prefix 1 Will return a Prefix Deletgation (PD) but not an Interface Address (IN). The generated dhclient command line was: /sbin/dhclient -6 -v -pf /run/dhclient6.eth1.pid -lf /var/lib/dhcp/dhclient6.eth1.leases -I -P -N -df /var/lib/dhcp/dhclient.eth1.leases eth1 Adding the -R command line flag resolves the issue, but I could not find a way to add this via the /etc/interfaces file (I tried adding `dhcp 1` but that had no effect). Running the command above with the -R flag correctly configures the prefix delegation and the WAN interface. It did not add a default route correctly, but that was probably because I did it manually. Using `rdisc6` and adding it manually via `ip -6 route add default via` worked. I think the problem can be resolved by having a flag which will add the '-R' flag to require all DHCPv6 components to get a response, as the ISP's server seems to require multiple queries to get the PD and IN responses. I can provide logs of both with and without the `-R` flag if that will help. -Carl -- Package-specific info: --- /etc/network/interfaces: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo eth1 eth2 he-ipv6 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6 vlan7 iface lo inet loopback # The primary network interface iface eth1 inet dhcp # This is an autoconfigured IPv6 interface iface eth1 inet6 dhcp accept_ra 0 autoconf 0 request_prefix 1 #post-up ip addr add 192.168.100.2/24 dev eth1 #pre-down ip addr del 192.168.100.2/24 dev eth1 iface he-ipv6 inet6 v4tunnel endpoint 184.105.253.10 address 2001:470:1f0e:296::2 netmask 64 ttl 64 post-up ip -6 route flush table he post-up ip -6 route add default via 2001:470:1f0e:296::1 table he post-up ip -6 rule add priority 15001 from 2001:470:1f0f:296::/64 to 2000::/3 table he post-up ip -6 rule add priority 15002 from 2001:470:b8b2::/48 to 2000::/3 table he # Internal network interface iface eth2 inet manual iface vlan1 inet static address 192.168.123.1 netmask 255.255.255.0 vlan-raw-device eth2 dns-nameservers 192.168.123.4 iface vlan1 inet6 manual accept_ra 0 privext 0 dhcp 0 iface vlan2 inet static address 192.168.255.1 netmask 255.255.255.0 vlan-raw-device eth2 iface vlan2 inet6 static address 2001:470:b8b2:2::1 netmask 64 accept_ra 0 privext 0 iface vlan3 inet static address 192.168.203.1 netmask 255.255.255.0 vlan-raw-device eth2 iface vlan3 inet6 static address 2001:470:b8b2:3::1 netmask 64 accept_ra 0 privext 0 iface vlan4 inet static address 192.168.204.1 netmask 255.255.255.0 vlan-raw-device eth2 iface vlan4 inet6 static address 2001:470:b8b2:4::1 netmask 64 accept_ra 0 privext 0 iface vlan5 inet static address 192.168.205.1 netmask 255.255.255.0 vlan-raw-device eth2 iface vlan5 inet6 static address 2001:470:b8b2:5::1 netmask 64 accept_ra 0 privext 0 iface vlan6 inet static address 192.168.206.1 netmask 255.255.255.0 vlan-raw-device eth2 iface vlan6 inet6 static address 2001:470:b8b2:6::1 netmask 64 accept_ra 0 privext 0 iface vlan7 inet static address 192.168.207.1 netmask 255.255.255.0 vlan-raw-device eth2 iface vlan7 inet6 static address 2001:470:b8b2:7::1 netmask 64 accept_ra 0 privext 0 --- up and down scripts installed: /etc/network/if-down.d: total 8 -rwxr-xr-x 1 root root 372 Dec 1 2014 openvpn -rwxr-xr-x 1 root root 800 May 21 2017 postfix lrwxrwxrwx 1 root root 33 Nov 3 2018 wide-dhcpv6-client -> ../../wide-dhcpv6/dhcp6c-ifupdown /etc/network/if-post-down.d: total 4 -rwxr-xr-x 1 root root 1433 Feb 4 2019 vlan /etc/network/if-pre-up.d: total 8 -rwxr-xr-x 1 root root 4224 Feb 21 2019 vlan /etc/network/if-up.d: total 20 -rwxr-xr-x 1 root root 677 Feb 4 2019 ip -rwxr-xr-x 1 root root 4948 Feb 3 2019 mountnfs -rwxr-xr-x 1 root root 385 Nov 12 2015 openvpn -rwxr-xr-x 1 root root 1117 May 21 2017 postfix lrwxrwxrwx 1 root root 33 Nov 3 2018 wide-dhcpv6-client -> ../../wide-dhcpv6/dhcp6c-ifupdown -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (1000, 'stable'), (995, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN
Bug#965212: Acknowledgement (linux-image-5.6.0-0.bpo.2-amd64: Booting HPE EPYC server with linux-image-5.6.0-0.bpo.2-amd64 reboots on startup)
After working through the dependency issues, I was able to upgrade to the 5.7 kernel from testing and all of the problems reported on this bug and many others went away. Feel free to close this issue. On 2020-07-17 17:51, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 965212: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965212. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > As you requested using X-Debbugs-CC, your message was also forwarded to > cape...@spherecube.host > (after having been given a Bug report number, if it did not have one). > > Your message has been sent to the package maintainer(s): > Debian Kernel Team > > If you wish to submit further information on this problem, please > send it to 965...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. >
Bug#966269: v4l2loopback-utils: No man page or documentation of any kind
Package: v4l2loopback-utils Version: 0.12.1-1 Severity: normal The package has no man page (which I thought was required for all Debian packages), and its folder in /usr/share/doc has a changelog and not much else. There is no information how to use it anywhere at all that I can find (within Debian). -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages v4l2loopback-utils depends on: ii gstreamer1.0-tools 1.14.4-1 ii sudo1.8.27-1+deb10u2 ii v4l-utils 1.16.3-3 Versions of packages v4l2loopback-utils recommends: ii v4l2loopback-dkms 0.12.1-1 v4l2loopback-utils suggests no packages. -- no debconf information
Bug#965212: linux-image-5.6.0-0.bpo.2-amd64: Booting HPE EPYC server with linux-image-5.6.0-0.bpo.2-amd64 reboots on startup
Package: src:linux Version: 5.6.14-2~bpo10+1 Severity: normal Dear Maintainer, Attempting to boot the 5.6 kernel series on my HPE DL325 Gen10 server does not work. The 5.4.0-0.bpo.4-rt-amd64 kernel does, which is how I am writing this report. The machine will boot, ask for my LUKS decryption key, complain about missing SVM firmware, and then power cycle without any other output. I have tried every released version of the 5.6 kernel available from Debian Buster Backports. The system works and appears to be stable with the 5.4 kernel I am running now (with the occasional ACPI error in dmesg). All of the system firmware is the latest available from HPE, and I even manually added the SVM firmware from the upstream linux-firmware repo since it is not packaged for Debian yet. The existance or abscence of said firmware file made no difference. Happy to provide additional information upon request. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: HP product_name: ProLiant DL325 Gen10 product_version: chassis_vendor: HP chassis_version: bios_vendor: HP bios_version: A41 board_vendor: HP board_name: ProLiant DL325 Gen10 board_version: ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480] Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1450] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 61) Subsystem: Hewlett Packard Enterprise FCH SMBus Controller [1590:0278] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 01:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PTDMA [1022:1498] Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PTDMA [1022:1498] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 02:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:1485] Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:1485] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 02:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PTDMA [1022:1498]
Bug#961366: /usr/bin/ncal: -b ignores locale and -s for Gregorian adoption date
Package: bsdmainutils Version: 11.1.2+b1 Severity: normal File: /usr/bin/ncal Dear Maintainer, I was interested in [n]cal's behaviour around the Gregorian adoption dates and noticed that ncal -b defaults to October 1582 regardless of locale or -s specified country code, whereas plain "cal" uses the locale correctly. There follows an example shell session. Use of the "env" command is to ensure shell aliases and functions are not responsible for the unexpected behaviour. Best Regards, Carl W. $ env cal 9 1752 September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 $ env ncal 9 1752 September 1752 Mo18 25 Tu 1 19 26 We 2 20 27 Th 14 21 28 Fr 15 22 29 Sa 16 23 30 Su 17 24 $ env ncal -b 9 1752 September 1752 Mo Tu We Th Fr Sa Su 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 $ env ncal -p AL Albania1912-11-30 IT Italy 1582-10-04 AT Austria1583-10-05 JP Japan 1918-12-18 AU Australia 1752-09-02 LI Lithuania 1918-02-01 BE Belgium1582-12-14 LN Latin -05-31 BG Bulgaria 1916-03-18 LU Luxembourg 1582-12-14 CA Canada 1752-09-02 LV Latvia 1918-02-01 CH Switzerland1655-02-28 NL Netherlands1582-12-14 CN China 1911-12-18 NO Norway 1700-02-18 CZ Czech Republic 1584-01-06 PL Poland 1582-10-04 DE Germany1700-02-18 PT Portugal 1582-10-04 DK Denmark1700-02-18 RO Romania1919-03-31 ES Spain 1582-10-04 RU Russia 1918-01-31 FI Finland1753-02-17 SI Slovenia 1919-03-04 FR France 1582-12-09 SE Sweden 1753-02-17 *GB United Kingdom 1752-09-02 TR Turkey 1926-12-18 GR Greece 1924-03-09 US United States 1752-09-02 HU Hungary1587-10-21 YU Yugoslavia 1919-03-04 IS Iceland1700-11-16 $ env ncal -s GB 9 1752 September 1752 Mo18 25 Tu 1 19 26 We 2 20 27 Th 14 21 28 Fr 15 22 29 Sa 16 23 30 Su 17 24 $ env ncal -b 9 1752 September 1752 Mo Tu We Th Fr Sa Su 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 $ env ncal -s GB -b 9 1752 September 1752 Mo Tu We Th Fr Sa Su 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 $ env ncal -b 9 1752 -s GB September 1752 Mo Tu We Th Fr Sa Su 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 $ env ncal -b 10 1582 -s GB October 1582 Mo Tu We Th Fr Sa Su 1 2 3 4 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 $ -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bsdmainutils depends on: ii bsdutils 1:2.33.1-0.1 ii debianutils 4.8.6.1 ii libbsd0 0.9.1-2 ii libc62.28-10 ii libtinfo66.1+20181013-2+deb10u2 bsdmainutils recommends no packages. Versions of packages bsdmainutils suggests: ii cpp 4:8.3.0-1 pn vacation ii wamerican [wordlist] 2018.04.16-1 ii wbritish [wordlist] 2018.04.16-1 ii whois 5.4.3 -- no debconf information
Bug#955387: Regression: flashrom programmer support reduced on non-x86
Package: flashrom Version: 1.2-5 Dear maintainers, Compared to version 1.1-1 arm64, the following programmers are missing in version 1.2-5 on arm64: ATAVIA DRKAISER GFXNVIDIA IT8212 NICINTEL NICINTEL_EEPROM NICINTEL_SPI OGP_SPI SATASII This might be related to switching the build from GNU Make to Meson. The flashrom meson build files currently do not handle arch-specific enabling of programmers. To solve this, the meson build files can be patched or the packaging can add special rules for each architecture similar to the rules introduced in 1.2-4. Caveat: Differentiating between x86 and non-x86 is not enough. Future upstream versions of flashrom will ship with more complete meson build files matching the makefile. As an alternative, building with the flashrom makefile should result in a build with the maximum functionality supported on each architecture like before.
Bug#953313: pysvn always strore password unencrypt (Security issue)
Package: pysvn Version : 1.9.9-2.1 The version 1.9.9 have a issue with gnome-keyring. That is even if svn is configure to use gnome-keyring the passowrd is store unencrypyted. rellated to issue below https://sourceforge.net/p/pysvn/tickets/2/ Manual compile of latest version 1.9.11 fix the issue. Please upgrade to 1.9.11 as it is a security issue
Bug#948192: flashrom -R does not show version number
On Sat, 04 Jan 2020 22:48:19 -0500 Antoine Beaupre wrote: > flashrom 1.0 and 1.1, as packaged in Debian, do not correctly show the > expected version number in the -R output: > > anarcat@angela:~(master)$ flashrom --version > flashrom on Linux 4.19.0-6-amd64 (x86_64) > flashrom is free software, get the source code at https://flashrom.org > > The first line shows where the version number should come up, because > there's two spaces (instead of one surrounding the version number) > between "flashrom" and "on". The flashrom 1.1 tarball in sid is incomplete. AFAICS rebuilding the package with the tarball from https://download.flashrom.org/releases/flashrom-v1.1.tar.bz2 should fix the issue. Official release tarballs contain the generated file versioninfo.inc which has the version info in case the directory containing the sources is not a git checkout.
Bug#948744: voctomix-outcasts: --audio_elements option is ignored.
released! https://github.com/CarlFK/voctomix-outcasts/releases/tag/v0.9.3 Thanks again for putting up with me. On Mon, Jan 13, 2020 at 7:12 AM Carl Karsten wrote: > oh right, I said there is a patch. hmm... let me create a release > after breakfast. > > On Mon, Jan 13, 2020 at 6:48 AM Carl F Karsten > wrote: > >> Package: voctomix-outcasts >> Severity: important >> Tags: patch >> >> Hello Holger! >> >> ingest.py --help says --audio-elements does something, but I never wrote >> the code to do anything. Opps. >> >> code added is basically: >> audio_src += args.audio_elements + " !\n" >> >> It is about to be tested in production at LCA in 2.5 hours! >> >> We coppied the file onto the box, so no need to rush getting this fix >> packaged. >> >> Thanks! >> Carl >> >> >> -- System Information: >> Debian Release: buster/sid >> APT prefers bionic-updates >> APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, >> 'bionic'), (100, 'bionic-backports') >> Architecture: amd64 (x86_64) >> Foreign Architectures: i386 >> >> Kernel: Linux 4.15.0-72-generic (SMP w/4 CPU cores) >> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), >> LANGUAGE=en_US: (charmap=UTF-8) >> Shell: /bin/sh linked to /bin/dash >> Init: systemd (via /run/systemd/system) >> LSM: AppArmor: enabled >> >> Versions of packages voctomix-outcasts depends on: >> ii gir1.2-gst-plugins-base-1.0 1.14.5-0ubuntu1~18.04.1 >> ii gstreamer1.0-plugins-good1.14.5-0ubuntu1~18.04.1 >> ii python3 3.6.7-1~18.04 >> ii python3-gi 3.26.1-2ubuntu1 >> >> Versions of packages voctomix-outcasts recommends: >> ii gstreamer1.0-x 1.14.5-0ubuntu1~18.04.1 >> >> voctomix-outcasts suggests no packages. >> > > > -- > Carl K > -- Carl K
Bug#948744: voctomix-outcasts: --audio_elements option is ignored.
oh right, I said there is a patch. hmm... let me create a release after breakfast. On Mon, Jan 13, 2020 at 6:48 AM Carl F Karsten wrote: > Package: voctomix-outcasts > Severity: important > Tags: patch > > Hello Holger! > > ingest.py --help says --audio-elements does something, but I never wrote > the code to do anything. Opps. > > code added is basically: > audio_src += args.audio_elements + " !\n" > > It is about to be tested in production at LCA in 2.5 hours! > > We coppied the file onto the box, so no need to rush getting this fix > packaged. > > Thanks! > Carl > > > -- System Information: > Debian Release: buster/sid > APT prefers bionic-updates > APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, > 'bionic'), (100, 'bionic-backports') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.15.0-72-generic (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US: (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages voctomix-outcasts depends on: > ii gir1.2-gst-plugins-base-1.0 1.14.5-0ubuntu1~18.04.1 > ii gstreamer1.0-plugins-good1.14.5-0ubuntu1~18.04.1 > ii python3 3.6.7-1~18.04 > ii python3-gi 3.26.1-2ubuntu1 > > Versions of packages voctomix-outcasts recommends: > ii gstreamer1.0-x 1.14.5-0ubuntu1~18.04.1 > > voctomix-outcasts suggests no packages. > -- Carl K
Bug#948744: voctomix-outcasts: --audio_elements option is ignored.
Package: voctomix-outcasts Severity: important Tags: patch Hello Holger! ingest.py --help says --audio-elements does something, but I never wrote the code to do anything. Opps. code added is basically: audio_src += args.audio_elements + " !\n" It is about to be tested in production at LCA in 2.5 hours! We coppied the file onto the box, so no need to rush getting this fix packaged. Thanks! Carl -- System Information: Debian Release: buster/sid APT prefers bionic-updates APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 'bionic'), (100, 'bionic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-72-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US: (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages voctomix-outcasts depends on: ii gir1.2-gst-plugins-base-1.0 1.14.5-0ubuntu1~18.04.1 ii gstreamer1.0-plugins-good1.14.5-0ubuntu1~18.04.1 ii python3 3.6.7-1~18.04 ii python3-gi 3.26.1-2ubuntu1 Versions of packages voctomix-outcasts recommends: ii gstreamer1.0-x 1.14.5-0ubuntu1~18.04.1 voctomix-outcasts suggests no packages.
Bug#944687: terminaltables: please remove config from debian/gbp.conf
Thanks for sponsoring! Sure, I'd left this config there since my first attempts at learning the gbp workflow. I understand why things like the pbuilder config don't belong in the package repo, but the branch/tag naming config is still relevant, no? Cheers, Carl
Bug#944577: RM: colorclass -- ROM; low-popcon leaf package
Package: ftp.debian.org Severity: normal This is a leaf package with few users that was added as a dependency for a now-abandoned ITP. I advertised for new uploaders and put up an RFA (#929658) but there has been no interest.
Bug#944576: RM: python-pynzb -- ROM; unmaintained
Package: ftp.debian.org Severity: normal This is a leaf package that is unmaintained upstream for >10 years. I advertised for new uploaders and put up an RFA (#929670) but there has been no interest.
Bug#934860: mate-media-pulse: Can't install on Buster because depends on wrong version of mate-media-common
Package: mate-media-pulse Severity: grave Justification: renders package unusable root@debian-NUCi5:~# apt install mate-media-pulse Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: mate-media-pulse : Depends: mate-media-common (>= 1.8.0+dfsg1-3) but it is not going to be installed Depends: mate-media-common (< 1.8.0+dfsg1-3.1) but it is not going to be installed -- System Information: Debian Release: 10.0 APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mate-media-pulse depends on: ii libatk1.0-0 2.30.0-2 ii libc6 2.28-10 ii libcairo2 1.16.0-4 pn libcanberra-gtk0 ii libcanberra0 0.30-7 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3 ii libgdk-pixbuf2.0-02.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2 ii libgtk2.0-0 2.24.32-3 ii libmate-desktop-2-17 1.20.4-2 ii libpango-1.0-01.42.4-7~deb10u1 ii libpangocairo-1.0-0 1.42.4-7~deb10u1 ii libpangoft2-1.0-0 1.42.4-7~deb10u1 ii libpulse-mainloop-glib0 12.2-4 ii libpulse0 12.2-4 ii libstartup-notification0 0.12-6 ii libunique-1.0-0 1.1.6-6 ii libx11-6 2:1.6.7-1 ii libxml2 2.9.4+dfsg1-7+b3 pn marco ii mate-desktop 1.20.4-2 ii mate-media-common 1.20.2-1 ii pulseaudio12.2-4 ii x11-utils 7.7+4 Versions of packages mate-media-pulse recommends: ii sound-theme-freedesktop 0.8-2 mate-media-pulse suggests no packages.
Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it
> Am 21.07.2019 um 21:58 schrieb Josh Triplett : > >> On July 21, 2019 11:38:03 AM PDT, James Cowgill wrote: >> Hi, >> >>> On 12/03/2019 12:44, Reinhard Tartler wrote: >>> On Tue, Mar 12, 2019 at 8:36 AM Carl Eugen Hoyos >> <mailto:ceffm...@gmail.com>> wrote: >>> >>>Please show the dependencies of (at least) libavutil and >> libavcodec >>>with your approach and maybe compare them to what sdl needs: >> While the >>>list may become smaller I wonder if it this would really solve >> the >>>described issue. >>> >>> Sure thing, please find the full build log attached to this email. >>> It details the full metadata at the end of the log. >> >> I've been on a rather long haitus from Debian stuff for a while, t I >> now >> have some time to do more so I'm going to get FFmpeg 4.1.4 uploaded >> next >> (and by the looks of things 4.2 is just around the corner...) >> >> I see a "fix" for this in the git history, but I think it's broken: >> >> * There is an obvious typo in the d/rules file which prevents the >> option >> to disable the SDL output device from taking effect. You can see from >> the build log attached to this bug report that we still have an SDL >> dependency. >> >> * Even after fixing that, the dependency remains. I think the "opengl" >> device backend has a dependency on SDL as well. Disabling that is >> probably a greater loss? >> >> * With the above two changes (disabling both sdl and opengl), I ran the >> final packages through dose and compared the dependencies. This is the >> list of transitive dependencies that no longer need installing after >> this change: >> >> libsdl2-2.0-0 >> libwayland-client0 >> libwayland-cursor0 >> libwayland-egl1 >> libxcursor1 >> libxinerama1 >> libxkbcommon0 >> libxrandr2 >> libxss1 >> xkb-data >> >> Notice that all of OpenGL, all xcb and core x11 libraries are still >> required. >> >> The total uncompressed size of these packages is around 8M, with >> libsdl2-2.0-0 and xkb-data being the only significant packages (the >> rest >> are < 100k). Note that xkb-data is installed by default so that saving >> is probably only relevant for stripped down containers. For comparison, >> if I install ffmpeg in a build chroot, apt says it will use 418M of >> extra space. >> >> In conclusion, I don't think the savings this change gives us are worth >> it, and I don't like disabling features in FFmpeg :) >> >> I think what you really want is an "ffmpeg-nox" package containing a >> build of the frontend ffmpeg tool with libavdevice completely disabled. >> I haven't run this in dose, but by dropping this dependency I would >> expect all the GL / X11 / etc dependencies to also go which would give >> much better space savings. Probably needs a little more thinking about >> the way this would be implemented though (and it's relationship with >> the >> normal ffmpeg package). > > You're right, that's much more what I'm looking for. This is primarily for > headless servers, which primarily need the command line tool and a subset of > libraries. I don’t understand: Didn’t you confirm that you tested the committed solution and that it works for you? Carl Eugen
Bug#804350: vizzini -- Kernel driver for Exar XR21V1414 USB UART
I have tested with 5.2.0, it seems to work. I have the hardware (Atlys shown here: https://hdmi2usb.tv/digilent-atlys/ and sometimes https://store.digilentinc.com/atlys-spartan-6-fpga-trainer-board-limited-time-see-nexys-video/ Are there any issues blocking this? Here is from my bash_history: mkdir shenki torvalds (cd shenki git clone https://github.com/shenki/linux.git cd linux git diff HEAD^ > ../../vizzini.patch ) cd torvalds git clone -depth 1 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux cp /boot/config-`uname -r` .config yes '' | make oldconfig make -j `getconf _NPROCESSORS_ONLN` deb-pkg LOCALVERSION=-viz-torv git apply ../../vizzini.patch make oldconfig # USB Exar XR21V141x 'Vizzini' Serial Driver (USB_SERIAL_VIZZINI) [N/m/?] (NEW) m make -j `getconf _NPROCESSORS_ONLN` deb-pkg LOCALVERSION=-viz2-torv cd .. sudo dpkg -i linux-image-5.2.0-rc1-viz2-torv_5.2.0-rc1-viz2-torv-1_amd64.deb -- Carl K
Bug#930043: voctomix-outcasts: record-timestamp uses -ilme interlacing on progressive data
fixed! https://github.com/CarlFK/voctomix-outcasts/releases/tag/v0.9.1 On Thu, Jun 6, 2019 at 11:45 AM Carl F Karsten wrote: > > Package: voctomix-outcasts > Version: 0.7.0 > Severity: normal > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > >Final encode is missing pixels because the encoder deinterlaced >progressive frames. > >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: stretch/sid > APT prefers xenial-updates > APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, > 'xenial'), (100, 'xenial-backports') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.4.0-148-generic (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) -- Carl K
Bug#930043: voctomix-outcasts: record-timestamp uses -ilme interlacing on progressive data
Package: voctomix-outcasts Version: 0.7.0 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Final encode is missing pixels because the encoder deinterlaced progressive frames. * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-148-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#855092: beets: FTBFS randomly (failing tests)
Hi,
I'm an upstream contributor to beets and I was looking into the failures
you're seeing here. I'm interested in making these tests reliable.
I tried to build the package on my (sid) laptop using sbuild and the
latest packaging repo from salsa. I'm not able to reproduce these test
failures. If I remove the Debian patches disabling tests, I'm still not
able to reproduce any of the failures that led you to add those patches
in the first case. I'm seeing three categories of tests here:
1) The test in skip-broken-test. If the failure you're seeing is the
same error on the GitHub issue you mention in that patch
('musicbrainz.host'), then my suspicion is that when running the test
beets is unable to find/read the file beets/config_default.yaml. One way
this can happen is if beets is being invoked as a zipped egg rather than
unpacked source (unsupported). Otherwise it might be that the build
environment has paths set in an unusual way that interferes with beets'
mechanism to find that YAML file relative to the invoked module.
2) There are two tests failing due to filesystem access
(test_no_write_permission and test_add_tags). Maybe we can do a better
job of mocking here so that the actual filesystem isn't being tested.
I'll take a look.
3) The two test_import_task_created* tests exercise a feature based
on a coroutine implementation (beets.util.pipeline), so I wonder if
that's related? It's the only unusual thing I can think of off-hand. I
know that the Debian build infrastructure is a little unusual, but I'm
not sure what specifically the difference could be here.
If you can help point me in the right direction to reproduce these
issues that would be appreciated.
Cheers,
Carl
Bug#929670: RFA: python-pynzb -- unified API for parsing NZB files from NNTP (Usenet) servers
Package: wnpp Severity: normal I am no longer interested in maintaining python-pynzb in Debian, and the other listed uploader doesn't currently have the time to maintain it either. The package is currently team-maintained in DPMT, however I have not yet had a response for my request for new uploaders there (https://lists.debian.org/debian-python/2019/04/msg00015.html). The package is currently in good shape and is up-to-date with upstream, which has not seen any activity in a while (10 years!). Since python3-pynzb is a leaf package with no reverse dependencies, I'll file an RM bug eventually if this RFA doesn't attract a new maintainer.
Bug#929658: RFA: colorclass -- ANSI color text library for Python
Package: wnpp Severity: normal I am no longer interested in maintaining colorclass in Debian. I initially packaged it as a dependency for a now-abandoned ITP (FlexGet). The package is currently team-maintained in DPMT, however I have not yet had a response for my request for new uploaders there (https://lists.debian.org/debian-python/2019/04/msg00015.html). The package is currently in good shape and is up-to-date with upstream, which has not seen a new release in a while. Since colorclass is a leaf package with no reverse dependencies, I'll file an RM bug eventually if this RFA doesn't attract a new maintainer.
Bug#927347: voctomix-outcasts: don't use hardcoded filenames in /tmp - even for testing
deleted one file, fixed the other. And addressed this from #dc-v (11:13:09 AM) olasd: CarlFK: why did you add a deinterlace in https://github.com/CarlFK/voctomix-outcasts/commit/174b1c9fd77f5f49f4040e0747e70ca8f39c7c39 (11:14:19 AM) olasd: it makes the loop wobblwobble fixed. tested, and made some notes about how to test https://github.com/CarlFK/voctomix-outcasts/blob/master/tests/README.md Can you package please? https://github.com/CarlFK/voctomix-outcasts/releases/tag/v0.9.0 As always, thank you for your help. On Thu, Apr 18, 2019 at 5:57 AM Holger Levsen wrote: > > package: voctomix-outcasts > severity: important > x-debbugs-cc: 927...@bugs.debian.org, c...@nextdayvideo.com > > Hi Carl, > > On Thu, Apr 18, 2019 at 10:45:00AM +, Niels Thykier wrote: > > > voctomix-outcasts (0.8.0-1) unstable; urgency=medium > > Unblocked. > > this is quite yay! (=it will make it into Buster) > > > I noted that the tests hardcodes a /tmp/test.ts file (not a regression > > though). > > eeks, this is not so yay. Please use mktemp instead. > > I see /tmp/test.ts is used by tests/server-file.sh and tests/mock-stack.sh > - do they both need to refer to the same file? If not the fix is > trivial... > > > Could you talk to upstream about avoiding hard-coding file > > names in /tmp - even in test suites? > > done :) > > > -- > tschau, > Holger > > --- >holger@(debian|reproducible-builds|layer-acht).org >PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C -- Carl K
Bug#928787: hdmi2usb-mode-switch: missing dep: python3-pkg-resources
Package: hdmi2usb-mode-switch Version: 0.0.0+git20161124-2 Severity: important Dear Maintainer, pi@oppi:~ $ hdmi2usb-mode-switch Traceback (most recent call last): File "/usr/bin/hdmi2usb-mode-switch", line 6, in from pkg_resources import load_entry_point ImportError: No module named 'pkg_resources' pi@oppi:~ $ sudo apt install python3-pkg-resources (fixed) -- System Information: Distributor ID:Raspbian Description:Raspbian GNU/Linux 9.9 (stretch) Release:9.9 Codename:stretch Architecture: armv6l Kernel: Linux 4.14.98+ Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages hdmi2usb-mode-switch depends on: ii fxload 0.0.20081013-1 ii hdmi2usb-fx2-firmware 0.0.0~git20151225-1 ii hdmi2usb-udev 0.0.0+git20161124-2 ii ixo-usb-jtag 0.0.0+git20160908-1 ii python33.5.3-1 Versions of packages hdmi2usb-mode-switch recommends: pn openocd hdmi2usb-mode-switch suggests no packages. -- no debconf information -- Carl K
Bug#927989: RFA: terminaltables
Package: wnpp Severity: normal I am no longer interested in maintaining terminaltables in Debian. I initially packaged it as a dependency for a now-abandoned ITP. In the meantime it has picked up rdeps independently. I have included the maintainers of these rdeps in CC in case they are able to help out. The package is currently team-maintained in DPMT, however I have not yet had a response for my request for new uploaders there (https://lists.debian.org/debian-python/2019/04/msg00015.html). The package is currently in good shape and is up-to-date with upstream, which has not seen a new release in a while.
Bug#927988: RM: rpyc -- ROM; RC buggy leaf package
Package: ftp.debian.org Severity: normal I initially packaged rpyc as a dependency for FlexGet. I no longer intend to package FlexGet and therefore rpyc is no longer needed. It has no rdeps, and has a FTBFS bug related to a test suite failure that I couldn't work out.
Bug#927841: plowshare: plowmod is inherently insecure
Control: severity -1 normal Thanks for your report. I have to disagree about the severity of this issue, however. To start with some history, the upstream developer moved all of the plowshare modules some time ago into a separate git repository with a name that included the word "legacy". At the time he contacted distro packagers and requested that we not package these modules at all. I decided to ignore this request and created plowshare-modules. More recently, the upstream developer has stopped maintaining the "legacy" repo hosting the modules, although there are still users from the community contributing (unanswered) pull requests there and helping each other fix compatibility issues as the file sharing websites change. Given that there are no upstream releases and not even any upstream commits that could be used as pseudo-releases for plowshare-modules, it didn't make sense to keep it as a package in Debian without also adopting its upstream development (which I have no interest in doing). A plowshare-modules package would simply break over time and would not receive security updates from upstream. If anything its existence just created a false impression of security. As I see it the threat model here involves two layers. Firstly the file sharing websites themselves could serve malicious code. This is mitigated in plowshare in Debian by disabling javascript execution unless the user explicitly opts in. There's not much more that can be done here given that we ultimately need to interact with those websites, because that's the whole point of plowshare. The second layer is in the creation and distribution of the plowshare modules. As I mentioned there is no longer an official up-to-date source for them. A user can write them from scratch or download them from various sources. Plowmod merely assists with this by making the process easier when the user chooses to use a git repo as the source for these modules. It's not necessary to use plowmod at all though, since all you need is the modules files, put in a directory where plowshare can find them. On reflection I think it's a good idea to remove the plowshare-modules-legacy URL from plowmod which is currently used as a default. This made sense at the time of the last plowshare release, but doesn't really continue to make sense. With that small change to plowmod it would be made clearer to users that the onus is on them to trust the source since none are provided by default. I agree that overall it would be nicer to have a curated and maintained set of modules in Debian, however without upstream commitment that seems like rather a lot of work for the benefit of O(100) users of the plowshare package in Debian. If you'd like to take on this work then I'd welcome it, but in its absence I don't believe that the plowshare itself needs to be removed, or that the threat model you've suggested constitutes a fatal security flaw in plowshare. Cheers, Carl
Bug#852241: beets fails to move album when modifying artist
Is this an issue you still observe in the latest version of beets? This is pretty difficult to help with without having more details. The verbose log output of beets for the relevant command, and the full configuration file would be a good start.
Bug#687849: beets: silently fails to rewrite tags
This bug is pretty much impossible to investigate without having more information, such as the actual files that exhibit the issue, verbose output from beets, the output of `beet info` for the relevant files, etc.. I think this should be closed. If it can be reproduced on a modern version of beets with more details then that can be a new bug report, but in any case it's probably better off being reported upstream.
Bug#927460: RM: plowshare-modules -- ROM; superseded by script in plowshare
Package: ftp.debian.org Severity: normal Plowshare is a tool for interacting with file sharing websites. The framework itself lives in the package plowshare, while the scripts that implement the APIs for specific websites live in plowshare-modules. These scripts are not suitable for a stable release since they evolve rapidly. The upstream source was also disowned by the maintainer and now appears to be unmaintained. The alternative is to use plowshare with scripts from some other source, and there is a tool, plowmod, bundled with it to make this process work. I have uploaded a version of plowshare to mentors that removes all reference to the plowshare-modules package, which it previously Suggested.
Bug#926829: voctomix-outcasts: usb audio needs gstreamer1.0-alsa
Package: voctomix-outcasts Version: package needs gstreamer1.0-alsa added to recommends Severity: important Dear Maintainer, A show said "oh, no audio" so I'm hooking a usb mic to the Opsis slave, which needs gstreamer1.0-alsa. this fixed it: apt install gstreamer1.0-alsa please package v0.8.0 waiting in git and add gstreamer1.0-alsa -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-142-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Carl K
Bug#926828: voctomix-outcasts: EOS errors
Package: voctomix-outcasts Version: v0.7.0 Severity: important Dear Maintainer, Hi! I wanted 5 seconds of test pattern, but limiting the stream to 5 seccodns does exit(1) and things abort. so I fixed it. go me. please package v0.8.0 waiting in git -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-142-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Carl K
Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it
2019-03-12 18:48 GMT+01:00, Josh Triplett : > On Tue, Mar 12, 2019 at 08:25:55AM -0400, Reinhard Tartler wrote: >> I think this should address the issue. Any objections to this approach? > > This would work perfectly for me, and I would then avoid installing > ffplay on my servers. I was expecting that the ffmpeg package would still pull a large number of dependencies including X11 with this change but if there is an improvement for you, all the better!
Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it
2019-03-12 13:25 GMT+01:00, Reinhard Tartler : > In a headless installation that is used for transcoding and streaming, > such dependencies, like on X11, wayland, etc. may not be desirable. Funny that you mention X11 and wayland: Both are still dependencies of FFmpeg after your patch, no?
Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it
Please show the dependencies of (at least) libavutil and libavcodec with your approach and maybe compare them to what sdl needs: While the list may become smaller I wonder if it this would really solve the described issue.
Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it
> What might work is disabling the avdevice outdev AND > moving 'ffplay' to its own binary package. Before suggesting this, I would prefer the OP to test. I still do not entirely believe that this fixes his issue. Carl Eugen
Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it
2019-03-10 23:21 GMT+01:00, Reinhard Tartler : > On Sat, Mar 9, 2019 at 2:51 PM Carl Eugen Hoyos wrote: > >> Could you test the configure option "--disable-outdev=sdl2"? >> Your report indicates it should fix your issue, I am not convinced but >> if it fixes your issue, Debian should consider using it as the device >> is mostly a (cheap) debug feature. > Wouldn't that video break playback in 'ffplay'? Can you elaborate why you think so? > at the very least, it would break the "SDL2 output device" in libavdevice. Obviously. > I'm not sure if I'd agree with that being a "cheap debug [only] feature". You don't have to. > Can you elaborate what makes you think so? Iirc, I was the only one speaking against its removal. But given that your avconv project never contained an sdl output device I wonder what your expertise is here? Carl Eugen
Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it
Hi! Could you test the configure option "--disable-outdev=sdl2"? Your report indicates it should fix your issue, I am not convinced but if it fixes your issue, Debian should consider using it as the device is mostly a (cheap) debug feature. Please report back, Carl Eugen
Bug#921603: installation-reports: Buster installer fails to detect CD when installing from flash drive (USB)
Package: installation-reports Severity: important Tags: d-i -- Package-specific info: Boot method: USB flash drive Image version: Buster Alpha3 AMD64 (downloaded 7 February 2019), also unetbootin image downloaded 8 Feb Date: Machine: Intel NUC8i5BEK Partitions: root@debian-NUCi5:~# fdisk -l /dev/sda Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Disk model: CT1000MX500SSD4 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x073bcfcf Device BootStartEndSectors Size Id Type /dev/sda1 *2048 58593279 5859123228G 83 Linux /dev/sda2 58595326 1953523711 1894928386 903.6G 5 Extended /dev/sda5 58595328 91865087 33269760 15.9G 82 Linux swap / Solaris /dev/sda6 91867136 1953523711 1861656576 887.7G 83 Linux Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E] Detect network card:[O] Configure network: [O] Detect CD: [E] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: I tried to install Debian on my Intel NUC. First I used unetbootin to create a Testing (Buster) netinstall USB drive. First of all, it's hard to get it to boot from a USB drive. You have to get into the BIOS, which on this device by default is not prompted when you power it up. You have to use Intel's secret handshake: turn off the NUC, then hold the power button down for three (but not four!) seconds, which gets you their special power-button menu, where you can turn on the BIOS prompt (and also change the BIOS directly from that menu). You also have to turn on legacy boot, of course, to boot from the USB drive. ... and when the installer got to installing kernel modules, it could not do that because the kernel version on the downloadable image doesn't match the version in the repository. I'm assuming this is a transient thing with this particular weekly image. So I downloaded the CD image, and used unetbootin to put that on the USB key. Now the installer failed with the message that it could not mount the install CD ... which was imaged onto the same USB drive I had just booted from, so ... something weird there. I flashed the Intel BIOS to the latest version. This had no effect I could see. Then I downloaded the DVD image and used K3B to burn THAT to a different Flash drive (I was wondering about a flaw in the drive I was using). Same error, could not mount the CD (despite having just read ITSELF off that same drive). Finally, rather than try to figure out the installer issue, I dug out my DVD burner (not used for over a year), burned an actual DVD image and plugged the USB optical drive into the NUC, which detected it, and the install then ran smoothly. (To clarify, I didn't reboot, the installer had run from the USB drive, and then I plugged in the optical drive which was detected as "the CD" (actually a DVD+RW). The HDMI audio didn't work, but restarting PulseAudio fixed that. Before anyone asks: yes, I'm going to submit this through reportbug. I wanted this here as well, at least partly to help anyone experiencing the same problems (since this mailing list is more likely to turn up in web searches than Debian bug reports). -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="10 (buster) - installer build 20190204-00:03:01" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux debian-NUCi5 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1 (2019-01-17) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3ed0] (rev 08) lspci -knn: Subsystem: Intel Corporation Device [8086:2074] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:3ea5] (rev 01) lspci -knn: Subsystem: Intel Corporation Device [8086:2074] lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Skylake Gaussian Mixture Model [8086:1911] lspci -knn: Subsystem: Intel Corporation Device [8086:2074] lspci -knn: 00:12.0 Signal processing controller [1180]: Intel Corporation Device [8086:9df9] (rev 30) lspci -knn: Subsystem: Intel
Bug#918657: network-manager: Problem with Wi-Fi accepting CLIENT MODE
Package: network-manager Version: 1.14.4-4 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Enabling wifi using the applet. Selecting add new network.. enter wifi password... refuses to connect. * What exactly did you do (or not do) that was effective (or ineffective)? If I go under edit network I am able to select "HOTSPOT" then.. it will recognize the network.. however it it NOT a hotspot it's a client/infrastructure network. It won't connect without using HOTSPOT * What was the outcome of this action? I was able to connect.(hotspot mode only) * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager depends on: ii adduser3.118 ii dbus 1.12.12-1 ii init-system-helpers1.56+nmu1 ii libaudit1 1:2.8.4-2 ii libbluetooth3 5.50-1 ii libc6 2.28-2 ii libcurl3-gnutls7.62.0-1 ii libglib2.0-0 2.58.1-2 ii libgnutls303.6.5-2 ii libjansson42.12-1 ii libmm-glib01.8.2-1 ii libndp01.6-1+b1 ii libnewt0.520.52.20-8 ii libnm0 1.14.4-4 ii libpam-systemd 240-2 ii libpolkit-agent-1-00.105-23 ii libpolkit-gobject-1-0 0.105-23 ii libpsl50.20.2-2 ii libreadline7 7.0-5 ii libselinux12.8-1+b1 ii libsystemd0240-2 ii libteamdctl0 1.27-1 ii libudev1 240-2 ii libuuid1 2.33-0.2 ii lsb-base 10.2018112800 ii policykit-10.105-23 ii udev 240-2 ii wpasupplicant 2:2.6-21 Versions of packages network-manager recommends: ii crda 3.18-1 ii dnsmasq-base [dnsmasq-base] 2.80-1 ii iptables 1.8.2-3 ii isc-dhcp-client 4.4.1-2 ii modemmanager 1.8.2-1 ii ppp 2.4.7-2+4 Versions of packages network-manager suggests: pn libteam-utils -- no debconf information
Bug#913523: working workaround
using files from the syslinux package and 2 from kernel.org/.../syslinux-6.04-pre1.tar target=/media/sdc sudo apt install syslinux wget -N https://mirrors.edge.kernel.org/pub/linux/utils/boot/syslinux/Testing/6.04/syslinux-6.04-pre1.tar.gz tar xf syslinux-6.04-pre1.tar.gz mkdir -p $target/EFI/syslinux $target/EFI/BOOT cp syslinux-6.04-pre1/efi64/efi/syslinux.efi $target/EFI/BOOT/BOOTX64.EFI cp syslinux-6.04-pre1/efi64/com32/elflink/ldlinux/ldlinux.e64 $target/EFI/BOOT/ cp /usr/lib/syslinux/modules/efi64/* $target/EFI/syslinux I think the fix will be something like the above (sans wget) and the cp lines be added around here: https://salsa.debian.org/installer-team/debian-installer/blob/master/build/config/x86.cfg#L113-115 mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/vesamenu.c32 ::vesamenu.c32; \ mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/libcom32.c32 ::libcom32.c32; \ mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/libutil.c32 ::libutil.c32 ; \ -- Carl K
Bug#913523: workaround/fix: add more uefi syslinux files
This works for the one box I am testing on (the same OP's turbot). There may be more files than needed, we were guessing and stopped when it booted. This suggests the existing boot.img can be fixed without breaking backwards compatibility. Get the syslinux package dd boot.img /dev/sdX, mount /dev/sdX di mkdir -p di/efi/boot mv di/syslinux.cfg di/boot cp efi64/efi/syslinux.efi di/efi/boot/bootx64.efi cp di/efi/boot/syslinux.cfg di/efi/syslinux/syslinux.cfg cp di/linux di/efi/boot/ cp di/initrd.gz di/efi/boot/ resulting files: Unsure which files are needed in efi/boot and which ones are needed in efi/syslinux di/efi/ di/efi/boot di/efi/boot/bootx64.efi di/efi/boot/libutil.c32 di/efi/boot/menu.c32 di/efi/boot/ldlinux.e64 di/efi/boot/syslinux.cfg di/efi/syslinux di/efi/syslinux/menu.c32 di/efi/syslinux/ldlinux.e64 di/efi/syslinux/libutil.c32 di/efi/syslinux/syslinux.cfg
Bug#913523: workaround: replace syslinux with grub
this isn't a fix, but a workaround that is fairly easy: dd boot.img /dev/sdX, mount it, cd it. mkdir -p efi/boot grub-mkimage -o bootx64.efi -p /efi/boot -O x86_64-efi \ fat iso9660 part_gpt part_msdos \ normal boot linux configfile loopback chain \ efifwsetup efi_gop efi_uga \ ls search search_label search_fs_uuid search_fs_file \ gfxterm gfxterm_background gfxterm_menu test all_video loadenv \ exfat ext2 ntfs btrfs hfsplus udf create grub.cfg
Bug#913523: boot.img has no partition table
hd-media/boot.img does not contain a partition table, it is just an fs: $ file boot.img boot.img: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "SYSLINUX", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, sectors 1953120 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 1904, serial number 0xdeb1, label: "Debian Inst" I tried to find support that a partition table is required. The best I could find this this: "The following list outlines the advantages of using the GPT disk layout over the legacy Master Boot Record (MBR) disk layout: ..." http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf And these comments from IRC: waldi: well, if you boot something without efi partition, it will only work with csm "In November 2017, Intel announced that it planned to phase out support for CSM by 2020." https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#CSM_booting CarlFK: is there a reason why hd-media/boot.img.gz does not have a partition table?waldi: maybe because no-one bothered to change it?
Bug#911280: smartmontools: DEVICESCAN pattern doesn't match /dev/nvme*
Package: smartmontools Version: 6.6-1 Severity: normal Dear Maintainer, I see the same systemd error status reported in #862908, however unlike that reporter my system does have an SSD disk, mounted at /dev/nvme0n1. If I manually execute smartctl --all /dev/nvme0 I get SMART data, so it's clearly a supported NVMe disk. /dev/nvm* paths don't seem to be included in the pattern searched by DEVICESCAN leading it to conclude that there are no disks. Is there any reason why the default pattern can't be extended to include NVMe paths? -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages smartmontools depends on: ii debianutils 4.8.6 ii libc62.27-6 ii libcap-ng0 0.7.9-1 ii libgcc1 1:8.2.0-7 ii libselinux1 2.8-1+b1 ii libstdc++6 8.2.0-7 ii lsb-base 9.20170808 Versions of packages smartmontools recommends: ii mailutils [mailx] 1:3.4-2 Versions of packages smartmontools suggests: pn gsmartcontrol pn smart-notifier -- no debconf information
Bug#911246: RFA: fpart -- sort file trees and pack them into bags
Package: wnpp Severity: normal I request an adopter for the fpart package (I'm not using it any more). The upstream is very responsive and would like an updated version of this package. The package description is: Fpart is a tool that helps you sort file trees and pack them into bags (called "partitions"). It is developed in C and available under the BSD license. . It splits a list of directories and file trees into a certain number of partitions, trying to produce partitions with the same size and number of files. It can also produce partitions with a given number of files or a limited size. Once generated, partitions are either printed as file lists to stdout (default) or to files. Those lists can then be used by third party programs. . Fpart also includes a live mode, which allows it to crawl very large filesystems and produce partitions in live. Hooks are available to act on those partitions (e.g. immediatly start a transfer using rsync(1)) without having to wait for the filesystem traversal job to be finished. Used this way, fpart can be seen as a powerful data migration tool.
Bug#910122: apt-listbugs: executes xdg-open as root user
Hi Francesco, Thanks for your reply, and sorry I missed the archived bugs on this topic. I'm not sure yet that I fully understand the problems, but perhaps the situation is slightly different now in that the browser is being launched with xdg-open rather than sensible-browser? I'll have a look soon and see what I can find out. A similar bug browsing menu in reportbugs's text UI works fine, including the 'b' action to launch a browser, since it's run as a normal user. Actually, the menu you were seeing (the one with "I'm bored; quit please") comes from the querybts command (part of package "reportbug"). When you enter "b1", apt-listbugs launches querybts and passes control to it. Thanks for pointing this out. Cheers, Carl
Bug#908941: rpyc FTBFS: test_registry.TestUdpRegistry failures
Control: tags -1 + help Thanks for reporting this. On Sun, 16 Sep 2018 13:36:51 +0300 Adrian Bunk wrote> Looking at the changelog, I'd suspect this might be caused by * Remove TestUdpRegistry patch rejected upstream I agree this was the cause, but I'm not able to reproduce the build failure locally. The reason that upstream rejected my patch was because they said the failure indicated a potentially misconfigured machine and so they would prefer to have the test fail in this case. I'm not really sure what's different about the build machines here that's triggering this failure. The previous FTBFS was due to a genuine upstream bug when running on a single core machine, so this could be something along those lines. Or it could just be a restriction on the build machines. I won't have the chance to look into this for a while, and in any case I'm not so familiar with the upstream code or the build machines so if anyone has any ideas that would be appreciated.
Bug#909655: plowshare: Please add libmozjs-24-bin as a suggested or recommended dependency
Control: tags -1 + pending Thanks for your suggestion - this will be done in the next upload.
Bug#910122: apt-listbugs: executes xdg-open as root user
In fact it seems that xdg-open _does_ search for firefox but has other issues when trying to open a URL as root. In its man page it explicitly advises against running as root, so I think it's really up to apt-listbugs to honour that advice here. A similar bug browsing menu in reportbugs's text UI works fine, including the 'b' action to launch a browser, since it's run as a normal user. And to clarify I was referring to the case when apt-listbugs is run as "/usr/sbin/apt-listbug apt" within the apt hook.
Bug#910122: apt-listbugs: executes xdg-open as root user
Package: apt-listbugs Version: 0.1.24 Severity: normal Dear Maintainer, When inspecting a bug presented by apt-listbugs (e.g. 'b1'), one of the possible actions is to type 'b' to open the list of bugs in the browser. When I attempt to do this it fails with an error message about xdg-open not being able to find a browser (reproduced below). It's not the fault of apt-listbugs that the 'b' function is broken; that's down to the fact that xdg-utils is not configured for the root user, and its hard-coded list of fallback browsers is missing /usr/bin/firefox. However I wonder how much sense it makes to be running xdg-open as the root user in the first place. It seems like all of the possible external actions in this menu (launching email client or web browser) are things you would expect to do as a normal user and probably wouldn't have configured for the root user. Is there any way that apt-listbugs could drop down to a normal user for the context of this menu and xdg-utils? -- Relevant output: What do you want to do now? [p|x|O|r|b|e|q|?]? ? p - Show previous message (followup). x - Provide extra information. O - (default) Show other bug reports (return to bug listing). r - Redisplay this message. b - Launch web browser to read full log. e - Launch e-mail client to read full log. q - I'm bored; quit please. ? - Display this help. What do you want to do now? [p|x|O|r|b|e|q|?]? b No protocol specified Unable to init server: Could not connect: Connection refused Error: cannot open display: :0 [28965:28965:1003/102348.181557:ERROR:zygote_host_impl_linux.cc(89)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180. No protocol specified Unable to init server: Could not connect: Connection refused Error: cannot open display: :0 /usr/bin/xdg-open: 870: /usr/bin/xdg-open: iceweasel: not found /usr/bin/xdg-open: 870: /usr/bin/xdg-open: seamonkey: not found /usr/bin/xdg-open: 870: /usr/bin/xdg-open: mozilla: not found /usr/bin/xdg-open: 870: /usr/bin/xdg-open: epiphany: not found /usr/bin/xdg-open: 870: /usr/bin/xdg-open: konqueror: not found /usr/bin/xdg-open: 870: /usr/bin/xdg-open: chromium: not found /usr/bin/xdg-open: 870: /usr/bin/xdg-open: chromium-browser: not found [28995:28995:1003/102348.230314:ERROR:zygote_host_impl_linux.cc(89)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180. /usr/bin/xdg-open: 870: /usr/bin/xdg-open: www-browser: not found /usr/bin/xdg-open: 870: /usr/bin/xdg-open: links2: not found /usr/bin/xdg-open: 870: /usr/bin/xdg-open: elinks: not found /usr/bin/xdg-open: 870: /usr/bin/xdg-open: links: not found /usr/bin/xdg-open: 870: /usr/bin/xdg-open: lynx: not found /usr/bin/xdg-open: 870: /usr/bin/xdg-open: w3m: not found xdg-open: no method available for opening 'https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909770=False=no' What do you want to do now? [p|x|O|r|b|e|q|?]? -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-listbugs depends on: ii apt 1.7.0~rc2 ii ruby1:2.5.1 ii ruby-debian 0.3.9+b8 ii ruby-gettext3.2.9-1 ii ruby-soap4r 2.0.5-4 ii ruby-unicode0.4.4-2+b9 ii ruby-xmlparser 0.7.3-3+b2 Versions of packages apt-listbugs recommends: ii ruby-httpclient 2.8.3-1 Versions of packages apt-listbugs suggests: ii firefox [www-browser] 62.0.2-1 ii google-chrome-stable [www-browser] 69.0.3497.100-1 ii reportbug 7.5.0 ii sensible-utils 0.0.12 -- no debconf information
Bug#906721: RFS: plowshare/2.1.7-2
Hi Herbert, Thanks for looking at my packages. I'm not really sure how the old changelog diff happened other than that the commit responsible must have been lost somewhere in the migration of the repository from GitHub to GitLab to salsa. I fixed the changelog in a new commit. What did you want me to update about the copyright? Whenever I do a new snapshot I go through the upstream diff to check for copyright statement changes and I didn't notice anything. I've now updated the year range for the packaging copyright in case that's what you meant. Cheers, Carl
Bug#907768: debian-installer: gfx and txt installer fail on new System76 oryx pro 17in 1080P disp w nvidia GTX1070
Greetings all, System76 support informs me they have successfully reproduced the issue on a machine with hardware identical to mine, meaning this is likely a hardware compatibility issue and not a faulty hardware issue. I would like to imagine if we can just figure out the proper boot paramaters here, the installer will just work, but I am out of my wheelhouse here and could use some help. In an attempt to unblock myself, I went ahead and set up a debian live USB planning to do a manual install with debootstrap and, surprise surprise, the live USB image also has a debian-installer style boot menu, and exhibits the exact same behavior as the installer does, so I cannot boot into a live debian system from the USB images either. I'm trying to create an ubuntu live thumb drive now so I can run debootstrap from there... Thanks! -Carl -- Carl Myers PGP Key ID 3537595B PGP Key fingerprint 9365 0FAF 721B 992A 0A20 1E0D C795 2955 3537 595B signature.asc Description: Digital signature
Bug#907821: guessit: Upstream source doesn't include copyright statement
Source: guessit Severity: normal Tags: upstream While the debian copyright file includes attribution (also historical) to upstream authors, there is no evidence for this in the actual source code upstream apart from a mention of the latest of the three entries in the doc building config. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#724718: Dependency status for flexget 2.14.19 (2018-08-26)
Here's another update on the dependency situation for FlexGet. Things are looking good because upstream FlexGet has been updating the dependency versions for several tricky packages so that shortly even guessit should point to the latest major version. On the Debian side the only thing missing now is a current version of guessit. That has some complications but once done will clear the way. FlexGet 2.14.19: PY-PACKAGE REQUIREMENT SRC PACKAGE V. STATUS - FeedParser >=5.2.1 python-feedparser 5.2.1 OK SQLAlchemy >=1.0.9, <1.999 sqlalchemy 1.2.8 OK PyYAML * [1] pyyaml 3.12OK beautifulsoup4 >=4.5 beautifulsoup4 4.6.3 OK html5lib >=0.11html5lib1.0.1 OK PyRSS2Gen* python-pyrss2gen1.1 OK pynzb* python-pynzb0.1.0 OK rpyc ==3.3.0 [1] rpyc4.2.0 OK jinja2 * jinja2 2.10OK requests ~=2.16.3 requests2.18.4 OK python-dateutil >=2.5.3 [2] python-dateutil 2.7.3 OK jsonschema >=2.0 python-jsonschema 2.6.0 OK path.py >=8.1.1 path.py 11.0.1 OK guessit <=2.1.4 [2] guessit 0.11.0 #867862 rebulk ==0.9.0 [2] python-rebulk 0.9.0 OK apscheduler >=3.2.0 apscheduler 3.5.3 OK terminaltables >=3.1.0 terminaltables 3.1.0 OK colorclass >=2.2.0 colorclass 2.2.0 OK - Web UI dependencies - feature can be disabled for now - cherrypy >=3.7.0 cherrypy3 8.9.1 OK flask>=0.7 flask 1.0.2 OK flask-restful>=0.3.3 flask-restful 0.3.6 OK flask-restplus ==0.10.1 flask-restplus -- #850089 flask-compress >=1.2.1 flask-compress 1.4.0 OK flask-login >=0.4.0 flask-login 0.4.1 OK flask-cors >=2.1.2 flask-cors -- #850091 pyparsing>=2.0.3 pyparsing 2.2.0 OK zxcvbn-python* python-zxcvbn 4.4.25 OK future >=0.15.2 python-future 0.15.2 OK + many node.js packages -- Dev requirements - maybe not all needed -- sphinx ==1.6.3 sphinx 1.7.8 OK click==6.7 python-click6.7 OK mock ==2.0.0 python-mock 2.0.0 OK vcrpy~=1.11.1 vcr.py 1.11.1 OK boto3* python-boto31.4.2 OK pytest >=3.3.0 pytest 3.6.4 OK pytest-catchlog >=1.2.2 pytest-catchlog 1.2.2 OK pytest-xdist ==1.20.0 pytest-xdist1.22.2 OK gitpython==2.1.5 python-git 2.1.11 OK twine==1.11.0 twine 1.11.0 OK subliminal >= 2.0rc1 subliminal 1.1.1 OUTDATED [1] https://github.com/Flexget/Flexget/pull/2193 [2] https://github.com/Flexget/Flexget/pull/2197
Bug#907768: debian-installer: gfx and txt installer fail on new System76 oryx pro 17in 1080P disp w nvidia GTX1070
Package: debian-installer Severity: important Tags: d-i Dear Maintainer, Booting to the installer on my new Oryx Pro is failing for both the text and graphical installer. I have produced a 5minute video showing exactly what it looks like: https://drive.google.com/file/d/1qSKTsWiLbauBi8ALDtzV1D225i7Zgrtn/view?usp=sharing When booting into the text installer, the screen is scaled so tiny it is only 1cm by 1cm, and tiled horizontally across the screen. If you zoom in you can see the screen is "really there" but it is so tiny you can't make out any of the options. When booting into the graphical installer, I just see a blank screen and the machine seems to hang forever. The machine came with ubuntu pre-installed and it boots into that system just fine. I was able to reproduce this problem with the following images: https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.5.0-amd64-xfce-CD-1.iso https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.5.0-amd64-netinst.iso https://cdimage.debian.org/cdimage/buster_di_alpha3/amd64/iso-cd/debian-buster-DI-alpha3-amd64-netinst.iso I confirmed the checksum of the ISO and the validity of the usb drive, and confirmed it worked in another machine. The machine includes both intel and nvidia graphics, which are switched by software. I have tried putting it in both NVIDIA and Intel graphics modes and see the same behavior: https://support.system76.com/articles/graphics-switch-ubuntu/ I've tried several boot parameters including "nomodeset" and "vga=", DEBIAN_FRONT_END=text, fb=false, gfxpayload=1920x1080, etc. When I boot into the ubuntu install, the native resolution appears to be 1920x1080. Because I currently have it set to Intel graphics mode, the nvidia hardware doesn't even show up in $(lspci), the intel hardware is "Intel Corporation Device 3e9b" using kernel driver i915. I can get the nvidia details if needed but system76 says it is a 8GB GTX 1070. I am filing this report from another machine, so the system information below is not relevant. I am happy to try things if you have any suggestions for a workaround, at this point I have to imagine the possibilities are a (very very weird) hardware problem, or a hardware incompatibility. Thanks! -Carl Myers -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#906721: RFS: plowshare/2.1.7-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "plowshare" and the related package "plowshare-modules". The main reason this is worth an upload is that I'm shifting the way the two packages are related in order to follow upstream recommendations. Specifically plowshare-modules should be kept out of Debian releases (but I intend to keep it in unstable hence the placeholder RC bug to prevent migration), and this requires a slight adjustment in the dependencies of plowshare itself. Package name: plowshare Version : 2.1.7-2 URL : https://salsa.debian.org/arcresu-guest/plowshare Section : web It builds these binary packages: plowshare - download and upload files from file sharing websites plowshare4 - transitional dummy package AND Package name: plowshare-modules Version : 0~git20180325.e4bd365-1 URL : https://salsa.debian.org/arcresu-guest/plowshare-modules Section : web It builds these binary packages: plowshare-modules - plowshare drivers for various file sharing websites Getting the packages: https://mentors.debian.net/package/plowshare https://mentors.debian.net/package/plowshare-modules dget -x https://mentors.debian.net/debian/pool/main/p/plowshare/plowshare_2.1.7-2.dsc dget -x https://mentors.debian.net/debian/pool/main/p/plowshare-modules/plowshare-modules_0~git20180325.e4bd365-1.dsc Changes since the last upload: plowshare (2.1.7-2) unstable; urgency=medium * Update VCS to point to Salsa. * Correct typo in patch description. * Update debhelper compat to 11 (no changes). * Update to standards version 4.2.0: - use HTTPS URL in changelog. * Set Rules-Requires-Root to no. * De-emphasise plowshare-modules in favour of plowmod: - drop from Recommends to Suggests and - promote git from Suggests to Recommends since the plowmod script that replaces the modules package requires git. -- Carl Suster Tue, 14 Aug 2018 10:54:27 +1000 plowshare-modules (0~git20180325.e4bd365-1) unstable; urgency=medium * New upstream snapshot (git e4bd365): + fixed: 1fichier, catshare, filer.net, mediafire, uptobox. * Update standards version to 4.2.0 (no changes). * Update debhelper compat to 11 (no changes). * Add upstream metadata file. * Change VCS URLs to point to Salsa. * Add watch file. -- Carl Suster Tue, 14 Aug 2018 14:21:42 +1000
Bug#906719: RFS: rpyc/4.0.2-1 [RC]
Package: sponsorship-requests Severity: important X-Debbugs-CC: debian-pyt...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "rpyc" maintained within the python modules team. Package name: rpyc Version : 4.0.2-1 URL : https://salsa.debian.org/python-team/modules/rpyc Section : python It builds these binary packages: python-rpyc-doc - transparent and symmetric Remote Python Call library -- documenta python3-rpyc - transparent and symmetric Remote Python Call library -- Python3 m Getting the package: https://mentors.debian.net/package/rpyc dget -x https://mentors.debian.net/debian/pool/main/r/rpyc/rpyc_4.0.2-1.dsc Changes since the last upload: rpyc (4.0.2-1) unstable; urgency=medium [ Ondřej Nový ] * d/control: Set Vcs-* to salsa.debian.org * d/control: Remove ancient X-Python3-Version field [ Carl Suster ] * New upstream release (Closes: #904615). * Recommend python3-gevent to support the new gevent server (however this feature is currently disabled due to crashes that are not yet understood). * Build-Depend on python3-gevent for the corresponding test (however this test is currently disabled to match upstream CI configuration). * Make the build reproducible by applying the patch provided by Chris Lamb (Closes: #893611). * Build-Depend on python3-sphinx-rtd-theme which is now used by the docs. * Stop cleaning up (in debian/rules) screencasts and CI image from docs that no longer exist upstream. * Remove GitHub "fork me" banner from documentation. * Update Standards-Version to 4.2.0 (no changes needed). * Mark the doc package as M-A: foreign as per multiarch hinter. * Add upstream metadata file. * Bump debhelper compat to 11. -- Carl Suster Tue, 14 Aug 2018 18:35:11 +1000
Bug#906003: Keep plowshare-modules out of Debian releases
It probably shouldn't have been in stretch, but as long as it does not cause trouble, you can let it rot there :-) Agreed that it shouldn't have been released in stretch; at the time I had the idea of supporting it through backports. Given the relatively low popcon statistics and activity in bts, I think I prefer to just leave the package in stretch alone for now. If anyone is caught out by the situation later I can proceed with the patching and removing as outline above. Carl
Bug#906003: Keep plowshare-modules out of Debian releases
By now the snapshot that's in stretch is ~20 months out of date. Some of the modules will work and some won't, but over time more and more will break. The version of plowshare itself in stretch includes the plowmod script, so stretch users don't need the modules. I suppose by the same logic it makes sense to remove the modules package from stretch. Plowshare currently Recommends plowshare-modules (I demote that to a Suggests in a new version on mentors for sid/testing) so I suppose the best course would be: 1) Patch the stable version of plowshare to change the dependencies (remove plowshare-modules from Recommends, add git to Recommends) and get this into stretch-proposed-updates. 2) File an RM bug against release.d.o for plowshare-modules in stable. Does that sound reasonable? The alternative is just to leave the package in stretch alone and accept that it will degrade in functionality over time. Users are already able to use the plowmod script and ignore the plowshare-modules package there if they need more recent modules. Carl
