Bug#1057744: nmap: bring back zenmap
Package: nmap Version: 7.93+dfsg1-1 Severity: wishlist Some time ago, zenmap was removed due to being stuck back on python 2, but as of nmap 0.94 [1] it has been brought up to date to use python 3 and gobject, so hopefully it can now be brought back to Debian? [1] https://github.com/nmap/nmap/blob/e47b742669e6aadcab8aaa16d123d8fa4832fe5d/CHANGELOG#L13
Bug#1049392: golang-1.21: FTBFS if dh-golang is installed
On Tue, 15 Aug 2023, Shengjing Zhu wrote: So why would you install dh-golang? It's not listed in golang-1.21's Build-Depends. To build other packages. Building Go and building packages that use Go on the same system doesn't seem weird to me. Is your view that source packages only need to be buildable in isolated chroots/containers that have just essential and their build-deps installed? While the policy manual doesn't seem to be explicit on this, the existence of the Build-Conflicts field seems to imply that the expectation is any breakage is explicitly declared there, and would provide a reasonable solution to this IMO. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824495 has a long discussion on the merits of different possible policy stances on this. https://lists.debian.org/debian-devel/2019/02/msg00204.html continues that discussion, though some of the mesages were also CC'd to the bug. -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#1049392: golang-1.21: FTBFS if dh-golang is installed
Source: golang-1.21 Version: 1.21.0-1 Severity: important Tags: ftbfs Context: trying to build local golang-1.21 packages against stable (bookworm) If dh-golang is installed, building the golang toolchain itself fails tests, specifically TestCgoLib in src/cmd/nm/nm_cgo_test.go: --- FAIL: TestCgoLib (2.19s) nm_test.go:264: go tool nm: exit status 1 open /tmp/TestGoLib2084668406/gopath/src/mylib/mylib.a: unrecognized object file After much digging and adding printf-y debugging output to the go toolchain, I eventually tracked this down to dh-golang copying CFLAGS (and related) env vars to CGO_CFLAGS (etc.). This notably includes the `-ffile-prefix-map` flag, which the go toolchain doesn't like, which causes it to put a "preferlinkext" sigil file in the `.a` file the test generates, which then makes the `go tool nm` program under test barf, because it doesn't know what that flag file is. I've reported the issue with `go tool nm` upstream: https://github.com/golang/go/issues/62036 However, I don't think `dh-golang` should be getting pulled in when building the Go toolchain itself, should it, at least not for setting CGO flags since I don't think the toolchain uses CGO, so this is only messing with tests? This also affects golang-1.20, and based on my analysis of the root cause in the upstream issue, I believe will affect golang-1.19 too, but I have not directly confirmed that. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-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#1030290: python3-gtts: Outdated, no longer works
Package: python3-gtts Version: 2.0.3-4 Severity: important The current version of this package no longer works: gtts.tts - WARNING - Unable to get language list: 'NoneType' object is not subscriptable Usage: gtts-cli [OPTIONS] Try 'gtts-cli -h' for help. Error: Unable to find token seed! Did https://translate.google.com change? Searching upstream finds e.g. https://github.com/pndurette/gTTS/issues/354 suggesting that this is fixed upstream and the package just needs an update. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-2-amd64 (SMP w/8 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 Versions of packages python3-gtts depends on: ii python33.11.1-2 ii python3-bs44.11.1-3 ii python3-click 8.1.3-2 ii python3-gtts-token 1.1.3-3 ii python3-pkg-resources 65.6.3-1 ii python3-requests 2.28.1+dfsg-1 ii python3-six1.16.0-4 python3-gtts recommends no packages. python3-gtts suggests no packages. -- no debconf information
Bug#1027841: desktop-base: Please provide UHD images for Debian 12 (emerald theme)
Package: desktop-base Version: 12.0.2 Severity: wishlist Updating some systems to Bookworm to try things out, I noticed the new desktop theme is blurry on many systems compared to Bullseye, becaues the Bullseye default "Homeworld" theme came with images (esp. SVGs) targeting several resolutions above 1080p-ish, while Emerald tops out at 1920x1080/1200. It feels especially sad to have _vector_ images do blurry pixel-oriented upscaling -- GNOME at least seems to render the SVG at its target resolution and then do a raster scaling to the screen resolution. That's not this package's fault, but it can certainly provide copies of the SVGs that target the higher res with very minimal editing. For example, this tiny edit is enough to make the 1920x1080 render crisply at 3840x2160, when combined with corresponding changes to the metadata file(s): --- /usr/share/desktop-base/emerald-theme/wallpaper/contents/images/1920x1080.svg 2022-12-23 12:31:20.0 -0500 +++ /usr/share/desktop-base/emerald-theme/wallpaper/contents/images/3840x2160.svg 2023-01-03 17:18:55.791977381 -0500 @@ -1,6 +1,7 @@ http://www.w3.org/2000/svg; xmlns:xlink="http://www.w3.org/1999/xlink; x="0px" y="0px" + scale-x="0.5" width="3840" height="2160" viewBox="0 0 1920 1080" style="enable-background:new 0 0 1920 1080;" xml:space="preserve">
Bug#1023661: libc6-dev: 2.36 incompatible with binutils 2.35 from stable
Package: libc6-dev
Version: 2.36-4
Severity: normal
On my partial testing system, after libc6{,-dev} upgraded from 2.35-4 to
2.36-4, ld (from binutils 2.35-2 from stable) could no longer link binaries
due to errors like this:
/usr/bin/ld: /lib/x86_64-linux-gnu/libc.so.6: unknown type [0x13] section
`.relr.dyn'
/usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libc.so.6 when
searching for /lib/x86_64-linux-gnu/libc.so.6
/usr/bin/ld: cannot find /lib/x86_64-linux-gnu/libc.so.6
Upgrading binutils to 2.39-8 from testing fixed the problem, so I infer it
needs a Breaks somewhere in that version range?
-- System Information:
Debian Release: 11.5
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
'oldstable-updates'), (500, 'oldoldstable'), (500, 'testing'), (500,
'oldstable'), (490, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-2-amd64 (SMP w/8 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libc6-dev depends on:
ii libc-dev-bin2.36-4
ii libc6 2.36-4
ii libcrypt-dev1:4.4.18-4
ii libnsl-dev 1.3.0-2
ii linux-libc-dev 5.10.140-1
ii rpcsvc-proto1.4.2-4
libc6-dev recommends no packages.
Versions of packages libc6-dev suggests:
ii glibc-doc 2.31-13+deb11u4
ii manpages-dev 5.10-1
-- no debconf information
Bug#1006276: wireguard-go: Please rename bin/wireguard to bin/wireguard-go
Package: wireguard-go Version: 0.0.20220117-2+b1 Followup-For: Bug #1006276 This probably merits Severity: grave, as the main use for this would be to work with wg-quick on systems that don't have the kernel module available, such as ChromeOS Crostini containers, and this package is unusable for that in its current state & default configuration. The wg-quick script expects the binary to be called wireguard-go, and produces confusing errors if neither that binary nor the kernel module is available. It _is_ possible to work around this by setting WG_QUICK_USERSPACE_IMPLEMENTATION=wireguard (in the environment), but that requires quite a bit of spelunking to find.
Bug#1008127: Acknowledgement (fprintd: Can't re-enroll after re-install with goodix (framework laptop))
notfound 1008127 fprintd/1.94.2-1 reassign 1008127 libfprint-2-2 found 1008127 libfprint-2-2/1:1.94.2-1 thanks Oops, missed that fprintd and libfprint are different source packages
Bug#1008127: fprintd: Can't re-enroll after re-install with goodix (framework laptop)
Package: fprintd Version: 1.94.2-1 Severity: normal Tags: upstream Due to https://gitlab.freedesktop.org/libfprint/libfprint/-/issues/444, goodix hardware can't re-enroll a finger if the user-space state is lost, such as on a reinstall or other issue. This is fixed upstream in v1.94.3: https://gitlab.freedesktop.org/libfprint/libfprint/-/releases#v1.94.3 -- System Information: Debian Release: 11.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-4-amd64 (SMP w/8 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fprintd depends on: ii dbus 1.12.20-2 ii libc6 2.33-7 ii libfprint-2-2 1:1.94.2-1 ii libglib2.0-0 2.66.8-1 ii libpolkit-gobject-1-0 0.105-31 ii policykit-10.105-31 fprintd recommends no packages. fprintd suggests no packages. -- no debconf information
Bug#1004714: iotop: Falsely reports CONFIG_TASK_DELAY_ACCT not enabled in kernel
Package: iotop Version: 0.6-24-g733f3f8-1.1 Severity: normal With recent bookwork kernel builds, iotop incorrectly reports `CONFIG_TASK_DELAY_ACCT not enabled in kernel`. This seems to have been fixed upstream: https://repo.or.cz/iotop.git/commit/ab35334d374e588bec12d201fb8869c536f0545d Workaround: sudo sysctl -w kernel.task_delayacct=1 Other workaround: uninstall this package and install iotop-c instead -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable-updates'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages iotop depends on: ii python3 3.9.2-3 iotop recommends no packages. iotop suggests no packages. -- no debconf information
Bug#1001302: nut-client: drop sysvinit support so apcupsd conflict can be dropped
Package: nut-client Version: 2.7.4-13 Severity: wishlist Dear Maintainer, Trying to work out support for a new UPS I acquired, I found this upstream github issue about supporting the protocol needed to get full information out of my new hardware: https://github.com/networkupstools/nut/issues/139 (I am fastcat in that discussion). One item that came out of it: being able to install apcupsd side-by-side would help work around this issue, but is not currently possible due to conflicts between the packages. AFAICT, this conflict centers _solely_ on the sysvinit script for nut-client, or more precisely the /etc/init.d/ups-monitor symlink. This is no longer provided by upstream, but rather by the debian package. If this symlink was removed, the conflict on apcupsd could be dropped, and the two packages installed side-by-side. Since this is just a symlink, I think it may be safe to remove it. I think it should be simple enough to write some post-upgrade logic to rewrite any /etc/rcN.d links to the proper name, if they even exist? -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'testing'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nut-client depends on: ii adduser 3.118 ii init-system-helpers 1.60 ii libc62.32-4 ii libupsclient42.7.4-13 ii lsb-base 11.1.0 Versions of packages nut-client recommends: ii bash-completion 1:2.11-2 Versions of packages nut-client suggests: pn nut-monitor -- Configuration Files: /etc/nut/nut.conf changed [not included] /etc/nut/upsmon.conf [Errno 13] Permission denied: '/etc/nut/upsmon.conf' /etc/nut/upssched.conf [Errno 13] Permission denied: '/etc/nut/upssched.conf' -- no debconf information
Bug#994249: postgresql-client-common: vacuumlo erroneously complains about missing client package
Package: postgresql-client-common Version: 225 Severity: minor When only postgresql client package(s) are installed, the vacuumlo wrapper erroneously reports: Error: You must install at least one postgresql-client- package Even though the client package(s) _are_ installed. This seems to be because the underlying binaries are provided by the postgresql _server_ package(s). Which may also be a bug? The upstream documentation for the vacuumlo package implies that it can be run as a client, it doesn't seem to need to be run directly on/from the server system. -- System Information: Debian Release: 11.0 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages postgresql-client-common depends on: ii netbase 6.3 Versions of packages postgresql-client-common recommends: ii libreadline8 8.1-1 postgresql-client-common suggests no packages. -- no debconf information
Bug#993450: golang-1.17-go: Can't compile golang.org/x/tools/imports, undefined defaultGOARCH in internal/buildcfg
Package: golang-1.17-go
Version: 1.17-2
Severity: important
It seems like the binary packages for 1.17-2 were somehow built wrong. Some
build-time generated code that would have defined defaultGOARCH and other
constants doesn't seem to have been generated & built, resulting in some
built-in packages being un-compilable.
This manifested for me with some build tooling, but I've narrowed it down to
this minimal reproducer:
package main
import _ "golang.org/x/tools/imports"
func main() {}
Trying to compile this results in errors:
# internal/buildcfg
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:25:29: undefined: defaultGOARCH
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:26:27: undefined: defaultGOOS
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:27:28: undefined: defaultGO386
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:33:13: undefined: defaultGO_LDSO
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:34:13: undefined: version
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:56:9: undefined: defaultGOARM
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:74:30: undefined: defaultGOMIPS
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:79:9: undefined: defaultGOMIPS
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:83:32: undefined: defaultGOMIPS64
/usr/lib/go-1.17/src/internal/buildcfg/exp.go:32:29: undefined:
defaultGOEXPERIMENT
/usr/lib/go-1.17/src/internal/buildcfg/cfg.go:83:32: too many errors
Pulling 1.17-1 from snapshot.debian.org, it does not reproduce this. There's
only one meaningful commit on salsa between the two, though it's not clear
to me how it would produce this issue.
I tried building 1.17-2 locally from salsa commit 9a929cf2, and my locally
built packages also do not reproduce this issue, so it seems that there was
somehow simply an error in the build process for the official packages.
-- System Information:
Debian Release: 11.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-security'), (500,
'oldstable-updates'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages golang-1.17-go depends on:
ii golang-1.17-src 1.17-2
ii libc62.31-13
Versions of packages golang-1.17-go recommends:
ii g++ 4:10.2.1-1
ii gcc 4:10.2.1-1
ii libc6-dev 2.31-13
ii pkg-config 0.29.2-1
Versions of packages golang-1.17-go suggests:
pn bzr | brz
ii ca-certificates 20210119
ii git 1:2.33.0-1
pn mercurial
pn subversion
-- no debconf information
Bug#836324: tightvncserver: Typing gives wrong keys in some apps
On Sat, 7 Aug 2021, Sven Geuer wrote:
I tried to reproduce your observation using tightvncserver 1:1.3.10-3
but didn't encounter any key mapping issues.
Can you provide me with instuctions how to verify this bugs still
persists?
I've been continuing with TigerVNC for the nearly 5 years since this
bug, so it's quite possible ... something ... changed and it's not
broken any more :)
FWIW, my setup hasn't really changed much, however. The vnc server runs
my ~/.xsession which:
1. xscreensver &
2. xset s off
3. osdsh
4. echo "Xft.dpi: $(xdpyinfo | sed -nre
'/^[[:space:]]*resolution:[[:space:]]*([0-9]+)x([0-9]+) dots per inch.*/{s/^.*x([0-9]+)
dots .*/\1/;p}')" | xrdb -
(I've no idea why this is in there ... parts of this .xsession script
are literally 20 years old. I think this is maybe a workaround for
some issues with weird font sizes under VNC)
5. exec wmaker
--
-- Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.
Package: fwupd
Version: 1.5.7-2
Followup-For: Bug #943343
This started out as what I thought may be the same essential data as Ross
Vandergrift reported above, but I think I've figured out the problem.
I'm seeing this same issue on a bullseye system. Interestingly, not on
_all_ of my bullseye systems, even though I thought they were all configured
equivalently as far as this package would be concerned.
On the failing system, if I use `systemctl edit fwupd-refresh.service` to
change `StandardError` from `null` to `inherit`, I see this error when it
fails:
Jun 21 12:15:26 myhostname systemd[1]: Starting Refresh fwupd metadata and
update motd...
Jun 21 12:15:26 myhostname fwupdmgr[3874480]: Failed to connect to daemon:
Exhausted all available authentication mechanisms (tried: EXTERNAL) (available:
EXTERNAL)
Jun 21 12:15:26 myhostname systemd[1]: fwupd-refresh.service: Main process
exited, code=exited, status=1/FAILURE
Jun 21 12:15:26 myhostname systemd[1]: fwupd-refresh.service: Failed with
result 'exit-code'.
Jun 21 12:15:26 myhostname systemd[1]: Failed to start Refresh fwupd metadata
and update motd.
If I apply a fixed version of Ross' "strace" change to the refresh service
(need to clear ExecStart first), I see the "AUTH EXTERNAL" handshake is
_exactly_ the same ... which I guess isn't the same because the dynamic
user id is chosen from hashing the same username, and so isn't actually all
that "dynamic".
Looking for other differences between the working and non-working systems, I
notice the working system has a
/etc/dbus-1/system.d/org.freedesktop.fwupd.conf file that is an exact copy
of its /usr/share/ counterpart. But replicating that on the working system
and doing `systemctl reload dbus` doesn't fix things, and removing it on the
working system doesn't break things.
I resorted to rummaging in the dbus code itself to see why `AUTH EXTERNAL`
might fail, and most of it was pretty basic stuff like not providing a user,
or malloc failures or things like that, which I was pretty sure were not the
problem. About the only thing left was this block of code:
https://github.com/freedesktop/dbus/blob/ef55a3db0d8f17848f8a579092fb05900cc076f5/dbus/dbus-auth.c#L1152
if (!_dbus_credentials_add_from_user (auth->desired_identity,
>identity,
DBUS_CREDENTIALS_ADD_FLAGS_NONE,
))
{
// ...
_dbus_verbose ("%s: could not get credentials from uid string: %s\n",
DBUS_AUTH_NAME (auth), error.message);
// ...
return send_rejected (auth);
}
}
And thought "OK, so it wants to look up user info from a uid" and thought
"how the heck does that work with dynamic users?" On a lark I went looking
at /etc/nsswitch.conf on the working vs. non-working systems, and noticed
that the working system has "systemd" listed under "passwd" and "group", and
has `libnss-systemd` installed. The non-working system has neither!
So I installed that package and did `sudo systemctl restart dbus` and ...
Voila! Broken system now works.
So, libnss-systemd is only a Recommends in various places. This package
seems to _Depend_ on it being installed & configured for its default
installation to work properly.
-- System Information:
Debian Release: 11.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable'), (500, 'oldstable'), (490,
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-6-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages fwupd depends on:
ii libc6 2.31-12
ii libcurl3-gnutls7.74.0-1.2
ii libefiboot137-6
ii libelf10.183-1
ii libflashrom1 1.2-5
ii libfwupd2 1.5.7-2
ii libfwupdplugin11.5.7-2
ii libglib2.0-0 2.66.8-1
ii libgnutls303.7.1-5
ii libgudev-1.0-0 234-1
ii libgusb2 0.3.5-1
ii libjcat1 0.1.3-2
ii libjson-glib-1.0-0 1.6.2-1
ii libpolkit-gobject-1-0 0.105-31
ii libsmbios-c2 2.4.3-1
ii libsqlite3-0 3.34.1-3
ii libsystemd0247.3-5
ii libtss2-esys-3.0.2-0 3.0.3-2
ii libxmlb1 0.1.15-2
ii shared-mime-info 2.0-1
Versions of packages fwupd recommends:
pn bolt
ii dbus 1.12.20-2
ii fwupd-amd64-signed [fwupd-signed] 1.5.7+2
ii python33.9.2-3
pn secureboot-db
ii udisks22.9.2-2
Versions of packages fwupd suggests:
pn gir1.2-fwupd-2.0
-- Configuration Files:
/etc/fwupd/uefi_capsule.conf changed [not included]
-- no debconf information
Bug#987231: [debian-mysql] Bug#987231: mariadb-server-10.5: Generated /etc/logrotate.d/mariadb has wrong paths
On Tue, 4 May 2021, Faustin Lammler wrote: Hi Matthew! Thanks for your detailed report. Appreciate the followup :) Indeed, the generated log rotate seems wrong (and I am able to reproduce the problem with 10.5 on sid). Could you maybe help on this directly upstream https://github.com/MariaDB/server/pull/1556? I have just created a comment based on this bug report https://github.com/MariaDB/server/pull/1556#discussion_r625630838. Aah, I think I see the issue given that context. The Debian package is missing these critical-looking lines to set `logdir`: https://github.com/MariaDB/server/pull/1556/files#diff-4bfceb03afa373d0cf49ad955b3a1801decfc9048f43b4731ecf1fab38afb6c0R34-R36 -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#987231: mariadb-server-10.5: Generated /etc/logrotate.d/mariadb has wrong paths
Package: mariadb-server-10.5 Version: 1:10.5.9-1 Severity: normal debian/patches/1556.patch contains an update to try to generate a logrotate config file for mariadb, but it malfunctions almost completely. The template used is: @localstatedir@/mysqld.log @logdir@/mysql.log @localstatedir@/mariadb.log @logdir@/mysql-slow.log @logdir@/mariadb-slow.log @logdir@/error.log Which results in this: /var/lib/mysql/mysqld.log /mysql.log /var/lib/mysql/mariadb.log /mysql-slow.log /mariadb-slow.log /error.log The list of log files, according to commented out defaults in /etc/mysql/mariadb.conf.d/50-server.cnf, is: /var/log/mysql/mysql.log /var/log/mysql/mariadb-slow.log /var/log/mysql/error.log Of course, on a default system, none of these are written any more either, but they might still exist. MariaDB definitely isn't going to log to /, and it seems unlikely for it to log to /var/lib/mysql/. Why does it matter? This is causing the logrotate service to fail to start for me. It logs what looks like a warning claiming it's skipping the non-existent files, but then exits. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/16 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mariadb-server-10.5 depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.75 ii galera-4 26.4.7-3 ii gawk 1:5.1.0-1 ii iproute2 5.10.0-4 ii libc6 2.31-11 ii libdbi-perl 1.643-3+b1 ii libpam0g 1.4.0-7 ii libssl1.1 1.1.1k-1 ii libstdc++610.2.1-6 ii lsb-base 11.1.0 ii lsof 4.93.2+dfsg-1.1 ii mariadb-client-10.5 1:10.5.9-1 ii mariadb-common1:10.5.9-1 ii mariadb-server-core-10.5 1:10.5.9-1 ii passwd1:4.8.1-1 ii perl 5.32.1-3 ii procps2:3.3.17-5 ii psmisc23.4-2 ii rsync 3.2.3-4 ii socat 1.7.4.1-3 ii zlib1g1:1.2.11.dfsg-2 Versions of packages mariadb-server-10.5 recommends: ii libhtml-template-perl 2.97-1.1 Versions of packages mariadb-server-10.5 suggests: ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-2 pn mariadb-test ii netcat-openbsd 1.217-3 -- debconf information excluded
Bug#986476: orpie: man page does not render correctly
Package: orpie Version: 1.6.1-1 Severity: important Something changed in a recent verison of orpie, causing large sections of its man page, describing the default key bindings and related important information to no longer render. For example, the section `EXECUTING BASIC FUNCTION OPERATIONS` currently begins thus: EXECUTING BASIC FUNCTION OPERATIONS Once some data has been entered on the stack, you can apply operations to that data. For example, '+' will add the last two elements on the stack. By default, the following keys have been bound to such opera‐ tions: As a shortcut, function operators will automatically enter any data that you were in the process of entering. So instead of the sequence 22+, you could type simply 22+ and the second num‐ ber would be entered before the addition operation is applied. As you might infer from the ":" ending the first paragraph, there is supposed to be a table there describing the default key bindings. This table is visible in the web rendering here: https://manpages.debian.org/buster/orpie/orpie.1.en.html#EXECUTING_BASIC_FUNCTION_OPERATIONS Also the table data is clearly visible in the orpie.1.gz file shipped, it's just that it doesn't actually render in the `man` program. Without this information, it's very hard to use orpie for anything other than basic arithmetic. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'stable-updates'), (500, 'stable'), (490, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages orpie depends on: ii libc6 2.31-11 ii libgsl25 2.6+dfsg-2 ii libncursesw6 6.2+20201114-2 ii libtinfo6 6.2+20201114-2 Versions of packages orpie recommends: ii sensible-utils 0.0.14 orpie suggests no packages. -- no debconf information
Bug#981284: [Pkg-libvirt-maintainers] Bug#981284: libvirt-daemon-driver-storage-iscsi-direct: Should recommend qemu-block-extra
On Thu, 28 Jan 2021, Guido Günther wrote: Hi, On Thu, Jan 28, 2021 at 11:52:41AM -0500, Matthew Gabeler-Lee wrote: Package: libvirt-daemon-driver-storage-iscsi-direct Version: 6.9.0-4 Severity: normal If using qemu, the libvirt iscsi-direct backend won't work without installing the qemu-block-extra package. So, like libvirt-daemon recommends qemu, I think this package should recommend the qemu iscsi support package. Care enough to send an MR here https://salsa.debian.org/libvirt-team/libvirt Sure thing, filed https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/95 Note: I don't have a bullseye builder environment setup yet, so I've not actually verified lack of typos there yet. But it looks like a CI pipeline should help out there :) -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#981284: libvirt-daemon-driver-storage-iscsi-direct: Should recommend qemu-block-extra
Package: libvirt-daemon-driver-storage-iscsi-direct Version: 6.9.0-4 Severity: normal If using qemu, the libvirt iscsi-direct backend won't work without installing the qemu-block-extra package. So, like libvirt-daemon recommends qemu, I think this package should recommend the qemu iscsi support package. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/16 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libvirt-daemon-driver-storage-iscsi-direct depends on: ii libc6 2.31-9 ii libgcc-s1 10.2.1-6 ii libglib2.0-02.66.4-1 ii libiscsi7 1.19.0-3 ii libvirt-daemon 6.9.0-4 ii libvirt06.9.0-4 libvirt-daemon-driver-storage-iscsi-direct recommends no packages. libvirt-daemon-driver-storage-iscsi-direct suggests no packages. -- no debconf information
Bug#975997: pcp: Upgrade failure due to unversioned libpcp3 dependency
Package: pcp Version: 5.2.2-1.1 Severity: important Attempting an `apt upgrade` on my bullseye system failed, due to improper dependency info in the pcp package. The libpcp3 dependency has no version constraints, and the new version of libpcp3 requires pulling in a new version of perl, so `apt upgrade` left it out. This then resulted in the attempt to restart the pcp service failing due to a missing symbol: Nov 27 16:10:02 cheetah.fastcat.org systemd[1]: Starting LSB: Control pmcd (the collection daemon for PCP)... Nov 27 16:10:02 cheetah.fastcat.org pmcd[3683911]: Rebuilding PMNS ... Nov 27 16:10:02 cheetah.fastcat.org pmcd[3684067]: Starting pmcd ... Nov 27 16:10:02 cheetah.fastcat.org pmcd[3684072]: /usr/lib/pcp/bin/pmcd: /usr/lib/libpcp.so.3: version `PCP_3.30' not found (required by /usr/lib/pcp/bin/pmcd) Nov 27 16:10:02 cheetah.fastcat.org pmcd[3683845]: /etc/init.d/pmcd: pmcd --verify failed, cannot start pmcd. Nov 27 16:10:02 cheetah.fastcat.org systemd[1]: pmcd.service: Control process exited, code=exited, status=1/FAILURE Nov 27 16:10:02 cheetah.fastcat.org systemd[1]: pmcd.service: Failed with result 'exit-code'. Nov 27 16:10:02 cheetah.fastcat.org systemd[1]: Failed to start LSB: Control pmcd (the collection daemon for PCP). dpkg: error processing package pcp (--configure): installed pcp package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: pcp needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) Since libpcp3 is coming into the deps via shlibs:Depends AFAICT, I'm guessing this is then due to a symbol/versioning issue with libpcp3? In this case the upgrade is from 5.2.0 to 5.2.2, FWIW. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/16 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pcp depends on: ii gawk1:5.0.1+dfsg-1 ii libc6 2.31-4 ii libncurses6 6.2+20200918-1 ii libpcp-gui2 5.2.0-1 ii libpcp-import1 5.2.0-1 ii libpcp-mmv1 5.2.0-1 ii libpcp-pmda35.2.0-1 ii libpcp-trace2 5.2.2-1.1 ii libpcp-web1 5.2.2-1.1 ii libpcp3 5.2.0-1 ii libpfm4 4.11.1+git4-gfa84c27-1 ii libreadline88.1~rc2-2 ii libssl1.1 1.1.1h-1 ii libsystemd0 246.6-4 ii libtinfo6 6.2+20200918-1 ii libuv1 1.40.0-1 ii procps 2:3.3.16-5 ii python3 3.8.6-1 ii python3-pcp 5.2.0-1 Versions of packages pcp recommends: ii libpcp-pmda-perl 5.2.0-1 Versions of packages pcp suggests: pn bpftrace pn libpcp-import-perl ii pcp-gui 5.2.2-1.1 pn redis-server -- no debconf information
Bug#974113: greylistd: Please re-upload in testing-migratable form
Package: greylistd Version: 0.9.0 Severity: normal Dear Maintainer, The 0.9.9 version is being rejected from testing migrations due to being a binary upload instead of a source one. I hope if an 0.9.0-1 is re-uploaded as source it will be accepted for testing migration? -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/16 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages greylistd depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.74 ii init-system-helpers1.58 ii lsb-base 11.1.0 ii python33.8.6-1 Versions of packages greylistd recommends: ii exim4 4.94-8 greylistd suggests no packages. -- debconf information excluded
Bug#972348: closed by Craig Small (Re: Bug#972348: procps: [sysctl] /etc/sysctl.d should supersede /lib and /usr/lib)
On Mon, 19 Oct 2020, Craig Small wrote: On Mon, 19 Oct 2020 at 15:51, Matthew Gabeler-Lee wrote: Aah, no, I can't, that's my point. Because /etc/sysctl.d/ is read before package-shipped files, then it doesn't matter what file I put it in, it will still be overridden by package-shipped files in (/usr)/lib. Did you test this? I thought I did, and the results I thought I got seemed to match up with the documentation: /usr/lib overrides /etc. But it seems that my "test" was faulty and the documentation is confusing. The documentation states the order the directories are read in, but the files do not seem to be applied in that order at all. Instead the files seem to be applied in order of their base name, and the directory order is only used to de-duplicate files with the same base name. I would have never figured that out from reading this paragraph in the documentation: Files are read from directories in the following list in given order from top to bottom. Once a file of a given filename is loaded, any file of the same name in subsequent directories is ignored. That says to me that it processes everything from the first directory, and then everything that doesn't have an overlapping name from the second directory, and so on, but that is _not_ what it does at all, as your example demonstrates. The "test" then got confused because some pacakges (tracker-miner-fs is the one that tripped me up) run selective sysctl updates in their postinst, leaving the system in an inconstent state after an apt upgrade. -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#972598: pgcli: Broken dependencies render package unusable
Package: pgcli Version: 3.0.0-1 Followup-For: Bug #972598 Quick addenda: 1) Verified that downgrading python3-humanize indeed works around this issue. 2) Upstream looks like they've worked around this by no longer using humanize: https://github.com/dbcli/pgcli/commit/8f7e31450835bca5d9a8bb4de252efba6f4b7b10 Unfortunately it looks like the replacement for it they're using is not available in Debian :(
Bug#972598: pgcli: Broken dependencies render package unusable
Package: pgcli
Version: 3.0.0-1
Severity: important
Since the update of python3-humanize to 3.0.0, pgcli is now completely
broken. Even trying to run `pgcli --help` reports a runtime error about
missing dependencies:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 567, in
_build_master
ws.require(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 884, in
require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 775, in
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (humanize 0.0.0
(/usr/lib/python3/dist-packages), Requirement.parse('humanize>=0.5.1'),
{'pgcli'})
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/pgcli", line 6, in
from pkg_resources import load_entry_point
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3239,
in
def _initialize_master_working_set():
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3222,
in _call_aside
f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3251,
in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 569, in
_build_master
return cls._build_from_requirements(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 582, in
_build_from_requirements
dists = ws.resolve(reqs, Environment())
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 770, in
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'humanize>=0.5.1' distribution was not
found and is required by pgcli
Since python3-humanize _is_ installed, and was updated much more recently on
my system than pgcli itself, I'm guessing that the major version jump from
what pgcli expects to what's now in Debian is likely the problem (pgcli
wants 0.5.1-ish, Debian went from 2.6.0 to 3.0.0), but I'm not at all sure
of that.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (490,
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pgcli depends on:
ii python3 3.8.2-3
ii python3-click 7.1.2-1
ii python3-configobj 5.0.6-4
ii python3-humanize3.0.1-1
ii python3-pgspecial 1.11.10+dfsg1-1
ii python3-pkg-resources 50.3.0-1
ii python3-prompt-toolkit 3.0.8-1
ii python3-psycopg22.8.5-1+b1
ii python3-pygments2.3.1+dfsg-4
ii python3-setproctitle1.1.10-3
ii python3-sqlparse0.3.1-1
ii python3-tabulate0.8.2-1.1
ii python3-terminaltables 3.1.0-3
pgcli recommends no packages.
pgcli suggests no packages.
-- no debconf information
Bug#972348: closed by Craig Small (Re: Bug#972348: procps: [sysctl] /etc/sysctl.d should supersede /lib and /usr/lib)
You can either: 1) Make your file appear "later" in the listing. So something like 999-must-happen.conf; or Aah, no, I can't, that's my point. Because /etc/sysctl.d/ is read before package-shipped files, then it doesn't matter what file I put it in, it will still be overridden by package-shipped files in (/usr)/lib. Only the /etc/sysctl.conf file overrides the package files. And while yes, the package does behave as documented, my point was that this package behaves contrary to how most other packages in Debian (and Linux/Unix) behave. -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#972348: procps: [sysctl] /etc/sysctl.d should supersede /lib and /usr/lib
Package: procps Version: 2:3.3.16-5 Severity: normal My normal expectation with most things unix/linux is that administrator-controlled files in /etc supersede package-shipped files in /lib and /usr/lib. However, the documented (and AFAICT actual) order of loading sysctl .conf files is: /run/sysctl.d/*.conf /etc/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf This makes it super annoying/frustrating to ensure proper configuration as the settings in the files in /etc/sysctl.d/ can be overridden by almost everything else. It seems from the documentation that the intent is to allow the /etc/sysctl.d/ _files_ to override files of the same name in later directories, but this is rather confusing and frustrating. If I want to ensure some limit-style setting is raised to a high enough level, I have to make sure I know every package-provided file that might adjust that setting, and manually maintain a copy of every other setting that package provides, except the limit I want to raise. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages procps depends on: ii init-system-helpers 1.58 ii libc62.31-3 ii libncurses6 6.2+20200918-1 ii libncursesw6 6.2+20200918-1 ii libprocps8 2:3.3.16-5 ii libtinfo66.2+20200918-1 ii lsb-base 11.1.0 Versions of packages procps recommends: ii psmisc 23.3-1 procps suggests no packages. -- no debconf information
Bug#970525: docker.io: Unable to start minikube/kubernetes containers: unable to find user 0: invalid argument
Package: docker.io Version: 19.03.12+dfsg1-4 Severity: important Something in the change(s) for 19.03.12+dfsg1-4 has broken using the docker.io package with some minikube configurations (particularly the "none" driver which runs the kubernetes containers directly in the host docker instance). All of minikube/kubelet's attempts to start the pods result in docker logging errors like so: Sep 17 20:28:35 nigripes dockerd[2793900]: time="2020-09-17T20:28:35.211635346-04:00" level=error msg="Handler for POST /v1.40/containers/e847bf6564589a04ca7a9a54f77d09a1cf6300fbaebce0224d7e86fc9f900754/start returned error: unable to find user 0: invalid argument" Downgrading just one release to 19.03.12+dfsg1-3 and it works again, so there's a pretty narrow window for what could have broken this. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-3-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages docker.io depends on: ii adduser 3.118 ii init-system-helpers 1.58 ii iptables 1.8.5-3 ii libc62.31-3 ii libdevmapper1.02.1 2:1.02.171-3 ii libltdl7 2.4.6-14 ii libnspr4 2:4.28-1 ii libnss3 2:3.56-1 ii libseccomp2 2.4.3-1+b1 ii libsystemd0 246.5-1 ii lsb-base 11.1.0 ii runc 1.0.0~rc92+dfsg1-5 ii tini 0.18.0-1+b1 Versions of packages docker.io recommends: ii ca-certificates 20200601 ii cgroupfs-mount 1.4 ii git 1:2.28.0-1 ii needrestart 3.5-1 ii xz-utils 5.2.4-1+b1 Versions of packages docker.io suggests: ii aufs-tools 1:4.14+20190211-1 ii btrfs-progs 5.7-1 ii debootstrap 1.0.123 pn docker-doc ii e2fsprogs1.45.6-1 pn rinse ii xfsprogs 5.6.0-1+b2 pn zfs-fuse | zfsutils -- no debconf information
Bug#969543: solaar: Solaar should autostart with --window=hide
repoen 969543 thanks Package: solaar Version: 1.0.3+dfsg-2 Followup-For: Bug #969543 Unfortunately 1.0.3+dfsg-2 didn't actually fix this, I suspect due to some issue with the rules around debconf and replacing symlinks with files. When upgrading from 1.0.3+dfsg-1 to the new version, what happened is I ended up with /etc/xdg/autostart/solaar.desktop.dpkg-new, but the old symlink to the other file still in place unmodified. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-3-amd64 (SMP w/12 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages solaar depends on: ii adduser 3.118 ii debconf [debconf-2.0]1.5.74 ii gir1.2-ayatanaappindicator3-0.1 0.5.5-2 ii gir1.2-gtk-3.0 3.24.22-1 ii gir1.2-notify-0.70.7.9-1 ii passwd 1:4.8.1-1 ii python3 3.8.2-3 ii python3-gi 3.36.1-1 ii python3-pyudev 0.21.0-3 ii udev 246.4-1 Versions of packages solaar recommends: ii python3-dbus 1.2.16-3 ii upower0.99.11-2 solaar suggests no packages. -- debconf information excluded
Bug#949637: hub: New upstream release
On 2020-07-28 07:19, Simon Frei wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 22 Jan 2020 21:24:10 -0500 (EST) Matthew Gabeler-Lee wrote: A quick followup: I was able to use gpb and a bit of editing to get a package built locally that seems to work. I have a guest account on salsa, and I'd be happy to submit that work there, but given that work touches 3 branches (master, upstream, pristine-tar), I'm not quite sure on the mechanics of that. According to "Team Maintenance" in https://go-team.pages.debian.net/packaging.html and the team being listed as the maintainer of hub, it's fine for you to directly commit to it. You'd have to request access to the go team. I'd be great if you could do that. Otherwise I might want to try it myself, for which it would be great to build on your work. However I wasn't able to find your fork either from the hub repo nor your salsa profile. Would you mind making your work available somehow? I've pushed my work up to a fork on salsa: https://salsa.debian.org/cheetah-guest/hub/-/compare/master...update-2.14.2 https://salsa.debian.org/cheetah-guest/hub/-/compare/upstream...upstream-update-2.14.2 https://salsa.debian.org/cheetah-guest/hub/-/compare/pristine-tar...pristine-tar-update-2.14.2 Feel free to use this as you wish. I've largely moved over from the hub tool to the newer gh tool (https://github.com/cli/cli) so I'm not likely to dig into this more any time soon.
Bug#965932: libc6: breaks openssh-server/buster
Package: libc6 Version: 2.31-1 Followup-For: Bug #965932 Having the same issue, found an additional tidbit that may be of use: When the failure happens, kernel logs a line like this: Jul 20 20:04:38 hostname kernel: [ 373.963787] audit: type=1326 audit(1595289878.694:7): auid=4294967295 uid=100 gid=65534 ses=4294967295 subj==unconfined pid=11667 comm="sshd" exe="/usr/sbin/sshd" sig=31 arch=c03e syscall=230 compat=0 ip=0x7f6a9798fbea code=0x0 Also, Andreas notes: > I haven't tried sshd/bullseye. I did, and it works fine with the new libc6. Sounds like libc6 needs a Breaks for openssh-server less than something (exactly where it breaks I guess is TBD, but less than the 1:8.3p1-1 current in bullseye seems safe). -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/16 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) Versions of packages libc6 depends on: ii libcrypt1 1:4.4.16-1 ii libgcc-s1 10.1.0-6 Versions of packages libc6 recommends: ii libidn2-0 2.0.5-1+deb10u1 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.71 ii glibc-doc 2.28-10 ii libc-l10n 2.31-1 ii locales2.31-1 -- debconf information: glibc/restart-failed: * glibc/disable-screensaver: * glibc/upgrade: true * libraries/restart-without-asking: true glibc/kernel-not-supported: * glibc/restart-services: spamassassin samba dovecot exim4 cups cron atd apache2 glibc/kernel-too-old:
Bug#962960: kdiff3: Choose X Everywhere / For All Unsolved menu items missing
forwarded 962960 https://bugs.kde.org/show_bug.cgi?id=407745 tags 962960 + upstream fixed-upstream thanks Looks like this was fixed upstream and has been released in 1.8.02, by commit https://invent.kde.org/sdk/kdiff3/-/commit/1c86432a9a72c9fbf193d97035255e3a1b6cac09 -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#962960: kdiff3: Choose X Everywhere / For All Unsolved menu items missing
Package: kdiff3 Version: 1.8.01-1+b1 Severity: normal The Merge menu items to Choose A/B/C Everywhere or For All Unsolved (Whitespace) Conflicts are not showing up in the kdiff3 build in bullseye. Downgrading to the version in buster and they show up again. I also tried 1.8.01-1 from snapshot.debian.org and it has the same issue. The changelog shows this entry: Don't enable "Choose C for Everthing" on two way merge but this is also seeming to happen on 3 way merge (via git mergetool) -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.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) LSM: AppArmor: enabled Versions of packages kdiff3 depends on: ii kio 5.70.1-1 ii libc6 2.30-8 ii libkf5configcore5 5.70.0-1 ii libkf5configwidgets5 5.70.0-1 ii libkf5coreaddons5 5.70.0-1 ii libkf5crash5 5.70.0-1 ii libkf5i18n5 5.70.0-1 ii libkf5iconthemes5 5.70.0-1 ii libkf5kiocore55.70.1-1 ii libkf5kiowidgets5 5.70.1-1 ii libkf5parts5 5.70.0-1 ii libkf5textwidgets55.70.0-1 ii libkf5widgetsaddons5 5.70.0-1 ii libkf5xmlgui5 5.70.0-1 ii libqt5core5a 5.12.5+dfsg-10+b1 ii libqt5gui55.12.5+dfsg-10+b1 ii libqt5printsupport5 5.12.5+dfsg-10+b1 ii libqt5widgets55.12.5+dfsg-10+b1 ii libstdc++610.1.0-3 Versions of packages kdiff3 recommends: ii kdiff3-doc 1.8.01-1 kdiff3 suggests no packages. -- no debconf information
Bug#918116: intel-gpu-tools: Unable to read its own config files due to use-after-free
Package: intel-gpu-tools Followup-For: Bug #918116 This has been fixed by 1.25-2, verified empirically, and can see the offending use-after-free has been fixed in the source. -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages intel-gpu-tools depends on: ii libc6 2.30-8 ii libcairo2 1.16.0-4 ii libdrm-intel1 2.4.97-1 ii libdrm22.4.97-1 ii libdw1 0.176-1.1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libkmod2 26-1 ii libpciaccess0 0.14-1 ii libpixman-1-0 0.36.0-1 ii libprocps8 2:3.3.16-5 ii libudev1 241-7~deb10u4 ii libunwind8 1.2.1-9 ii libx11-6 2:1.6.7-1 ii libxext6 2:1.3.3-1+b2 ii libxv1 2:1.0.11-1 ii zlib1g 1:1.2.11.dfsg-1 intel-gpu-tools recommends no packages. intel-gpu-tools suggests no packages. -- no debconf information
Bug#960932: gnome-shell: Screen does not lock if active VT switched
Package: gnome-shell Version: 3.36.2-1 Severity: normal While the screen lock works normally if I leave my user session as the active VT, if I switch to another VT (e.g. the login one with Ctrl-Alt-1, or another logged in user session with Ctrl-Alt-3), the screen lock never activates. I can return to my user session (e.g. Ctrl-Alt-2) _days_ later and have the screen be fully unlocked and the session available. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/12 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 gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii evolution-data-server3.36.2-1 ii gir1.2-accountsservice-1.0 0.6.55-2 ii gir1.2-atspi-2.0 2.36.0-2 ii gir1.2-freedesktop 1.64.1-1 ii gir1.2-gcr-3 3.36.0-2 ii gir1.2-gdesktopenums-3.0 3.36.1-1 ii gir1.2-gdm-1.0 3.34.1-3 ii gir1.2-geoclue-2.0 2.5.6-1 ii gir1.2-glib-2.0 1.64.1-1 ii gir1.2-gnomebluetooth-1.03.34.1-1 ii gir1.2-gnomedesktop-3.0 3.36.2-1 ii gir1.2-gtk-3.0 3.24.20-1 ii gir1.2-gweather-3.0 3.36.0-1 ii gir1.2-ibus-1.0 1.5.22-5 ii gir1.2-mutter-6 3.36.2-1 ii gir1.2-nm-1.01.24.0-1 ii gir1.2-nma-1.0 1.8.28-2 ii gir1.2-pango-1.0 1.44.7-4 ii gir1.2-polkit-1.00.105-26 ii gir1.2-rsvg-2.0 2.48.4+dfsg-1 ii gir1.2-soup-2.4 2.70.0-1 ii gir1.2-upowerglib-1.00.99.11-1 ii gjs 1.64.2-1 ii gnome-backgrounds3.36.0-1 ii gnome-settings-daemon3.36.1-1 ii gnome-shell-common 3.36.2-1 ii gsettings-desktop-schemas3.36.1-1 ii libatk-bridge2.0-0 2.34.1-3 ii libatk1.0-0 2.36.0-2 ii libc62.30-8 ii libcairo21.16.0-4 ii libecal-2.0-13.36.2-1 ii libedataserver-1.2-243.36.2-1 ii libgcr-base-3-1 3.36.0-2 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-4 ii libgirepository-1.0-11.64.1-1 ii libgjs0g 1.64.2-1 ii libgles2 1.3.1-1 ii libglib2.0-0 2.64.2-1 ii libglib2.0-bin 2.64.2-1 ii libgnome-autoar-0-0 0.2.4-2 ii libgnome-desktop-3-193.36.2-1 ii libgraphene-1.0-01.10.0-1 ii libgstreamer1.0-01.16.2-2 ii libgtk-3-0 3.24.20-1 ii libical3 3.0.8-1 ii libjson-glib-1.0-0 1.4.4-2 ii libmutter-6-03.36.2-1 ii libnm0 1.24.0-1 ii libpango-1.0-0 1.44.7-4 ii libpangocairo-1.0-0 1.44.7-4 ii libpolkit-agent-1-0 0.105-26 ii libpolkit-gobject-1-00.105-26 ii libpulse-mainloop-glib0 13.0-5 ii libpulse013.0-5 ii libsecret-1-00.20.3-1 ii libsystemd0 245.5-2 ii libwayland-server0 1.18.0-1 ii libx11-6 2:1.6.9-2+b1 ii libxfixes3 1:5.0.3-2 ii mutter 3.36.2-1 ii python3 3.8.2-3 Versions of packages gnome-shell recommends: ii bolt 0.8-4 ii chrome-gnome-shell10.1-5 ii gdm3 3.34.1-3 ii gkbd-capplet 3.26.1-1 ii gnome-control-center 1:3.36.2-1 ii gnome-menus 3.36.0-1 ii gnome-user-docs 3.36.2-1 ii ibus 1.5.22-5 ii iio-sensor-proxy 3.0-1 ii switcheroo-control2.1-1 ii unzip
Bug#918728: libvirt-daemon should provide iscsi-direct storage backend
Package: libvirt-daemon Version: 6.0.0-4 Followup-For: Bug #918728 Any chance this can get addressed for bullseye? FWIW, if I build the package from source with libiscsi-dev (and corresponding libiscsi7) installed, it auto-detects that it should build this backend. Presumably then all that's needed to address this is to update the build deps, possibly the configure invocation in rules, and the .install file to include the generated library file? -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/12 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 libvirt-daemon depends on: ii libblkid1 2.34-0.1 ii libc6 2.30-2 ii libcap-ng0 0.7.9-2.1+b2 ii libdbus-1-3 1.12.16-2 ii libdevmapper1.02.1 2:1.02.167-1+b1 ii libfuse22.9.9-2 ii libgcc-s1 10-20200324-1 ii libglib2.0-02.64.1-1 ii libnetcf1 1:0.2.8-1+b3 ii libparted2 3.3-4 ii libpcap0.8 1.9.1-2 ii libpciaccess0 0.14-1 ii libselinux1 3.0-1+b1 ii libudev1244.3-1 ii libvirt-daemon-driver-qemu 6.0.0-4 ii libvirt06.0.0-4 ii libxml2 2.9.10+dfsg-4 Versions of packages libvirt-daemon recommends: ii libvirt-daemon-driver-lxc 6.0.0-4 ii libvirt-daemon-driver-vbox 6.0.0-4 ii libvirt-daemon-driver-xen 6.0.0-4 ii libxml2-utils 2.9.10+dfsg-4 ii netcat-openbsd 1.206-1 ii qemu-kvm1:4.2-3 Versions of packages libvirt-daemon suggests: pn libvirt-daemon-driver-storage-gluster pn libvirt-daemon-driver-storage-rbd pn libvirt-daemon-driver-storage-zfs ii libvirt-daemon-system 6.0.0-4 pn numad -- no debconf information
Bug#953134: sensible-utils: 0.0.12+nmu1 broke recursion protection
Package: sensible-utils Version: 0.0.12+nmu1 Severity: normal The diff applied for sensible-editor in 0.0.12+nmu1 broke the logic to protect against recursive loops due to a copy paste error: [ -n "$EDITOR" ] && [ "$(which $EDITOR || true)" = "$p" ] && EDITOR= [ -n "$EDITOR" ] && [ "$(which $VISUAL || true)" = "$p" ] && VISUAL= [ -n "$EDITOR" ] && [ "$(which $SELECTED_EDITOR || true)" = "$p" ] && SELECTED_EDITOR= Should be: [ -n "$EDITOR" ] && [ "$(which $EDITOR || true)" = "$p" ] && EDITOR= [ -n "$VISUAL" ] && [ "$(which $VISUAL || true)" = "$p" ] && VISUAL= [ -n "$SELECTED_EDITOR" ] && [ "$(which $SELECTED_EDITOR || true)" = "$p" ] && SELECTED_EDITOR= -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/12 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 -- no debconf information
Bug#949637: hub: New upstream release
A quick followup: I was able to use gpb and a bit of editing to get a package built locally that seems to work. I have a guest account on salsa, and I'd be happy to submit that work there, but given that work touches 3 branches (master, upstream, pristine-tar), I'm not quite sure on the mechanics of that. -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#949637: hub: New upstream release
Package: hub Version: 2.7.0~ds1-1+b10 Severity: wishlist The upstream package now has released up to 2.14.0. Of particular note is the new `hub api` command, which is very useful for scripting, introduced in version 2.8.3. -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing'), (490, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-2-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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hub depends on: ii git1:2.20.1-2+deb10u1 ii libc6 2.29-9 Versions of packages hub recommends: ii xclip 0.13-1 ii xsel 1.2.0+git9bfc13d.20180109-1 hub suggests no packages. -- no debconf information
Bug#947941: alpine: New Upstream
retitle 947941 Bugs fixed in upstream 2.21.99* dev releases severity 947941 wishlist thanks On Wed, 8 Jan 2020, Unit 193 wrote: There seems to be a few bugs that will be fixed, SNI support for one. If you have a list of bugs matched to the associated upstream changelog entries, I wouldn't mind having those though. :) Based on looking at commit logs, I think ... #882424 fixed by 0ef0caf #706279 may be fixed already based on Eduardo's post in that bug #934439 fixed by c83adef (and probably others) #450411 ... #450412 ... #503931 ... these three _might_ be fixed, or at least improved/mitigated #886370 fixed by 6413ad3 (deb bug specifically noted in the commit msg) #813615 fixed by 46320c8 (I think?) There's quite a few TLS fixes in general, might be good to ask folks to re-test if e.g. one of the dev tags were uploaded to experimental. There may be more that aren't obvious from comparing bug titles to commit logs, of course. -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#948469: geoipupdate: NEWS/README should point user at how to get an account
Package: geoipupdate Version: 4.0.6-2 Severity: minor With upstream no longer permitting download of the databases without signing up for an account, this package is no longer usable out of the box, and doesn't contain pointers to what needs to be done to make it work. Suggest including in at least the README, if not a NEWS item, a link to MaxMind's instructions on how to get a (free) account to use with this tool so that the databases can be downloaded: https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/ Also, since the /etc/GeoIP.conf file will now generally include an account ID and token, it probably should no longer be auto-included in bug reports, unless those values can be automatically scrubbed out. -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/16 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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages geoipupdate depends on: ii libc6 2.29-7 geoipupdate recommends no packages. Versions of packages geoipupdate suggests: ii geoip-bin 1.6.12-5~bpo10+1 pn mmdb-bin -- Configuration Files: /etc/GeoIP.conf changed [not included] -- no debconf information
Bug#947941: alpine: New Upstream
On 2020-01-08 01:11, Unit 193 wrote: Howdy, It seems upstream has moved again, now to https://repo.or.cz/alpine.git That's not a new home, that's just where the git repository lives. The current home is still http://alpine.x10host.com/alpine/ Oops, I got confused by the bit the watchfile looks at being broken/gone, sorry! From a cursory examination of the log, I see several commits that look like they would fix open bugs in Debian. There seems to be a few bugs that will be fixed, SNI support for one. If you have a list of bugs matched to the associated upstream changelog entries, I wouldn't mind having those though. :) I'll follow up with that :)
Bug#947941: alpine: New Upstream
Package: alpine Version: 2.21+dfsg1-1.1 Severity: normal It seems upstream has moved again, now to https://repo.or.cz/alpine.git There is active development there from Eduadro, including two tagged releases since what's in Debian currently (though from the numbering and the contents of the pine.hlp file in the repo, these may be intended as rc/pre-releases). >From a cursory examination of the log, I see several commits that look like they would fix open bugs in Debian. -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/16 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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages alpine depends on: ii libc6 2.29-3 ii libgssapi-krb5-2 1.17-3 ii libkrb5-3 1.17-3 ii libldap-2.4-2 2.4.47+dfsg-3+deb10u1 ii libpam0g 1.3.1-5 ii libssl1.1 1.1.1d-0+deb10u2 ii libtinfo6 6.1+20181013-2+deb10u2 ii mlock 8:2007f~dfsg-6 Versions of packages alpine recommends: ii alpine-doc 2.21+dfsg1-1.1 Versions of packages alpine suggests: ii aspell 0.60.7~20110707-6 ii exim4 4.92-8+deb10u3 ii exim4-daemon-light [mail-transport-agent] 4.92-8+deb10u3 -- no debconf information
Bug#880531: libvncclient1: Can't connect to VMware
On 2019-12-03 03:30, Mike Gabriel wrote: Hi Matthew, thanks for reporting this bug. Thank you for following up :) If you don't have time for testing this, I'd appreciate a quick feedback anyway. I have the time, but unfortunately I no longer have the systems. I encountered this in a work environment, and have since switched jobs and don't have any VMware systems against which to test at the new job.
Bug#785441: Support maintainer name and email address
Package: checkinstall Version: 1.6.2+git20170426.d24a630-1~bpo10+1 Followup-For: Bug #785441 I think the patch _was_ the original bug report, specifically this: MAINTAINER="`eval "echo '$1'"`" As compared to what the checkinstall code does now: MAINTAINER=`eval echo $1` The suggested extra layer of quoting will help with many issues around the standard maintainer name format, I think. If you have single quotes in the argument values it will still have problems, but it's at least better than the current state of affairs. It's unclear to me why this extra layer of indirection is happening at all, though, and why it can't just do: MAINTAINER="$1" I can only imagine that there's some desire to let you indirectly reference variables set by earlier arguments, but I have also seen anti-patterns like this before from folks that just have a brain fart and forget how bash works. // extra frustration: whomever wrote this clearly knew this was an issue, // because the manpage says: "Be careful to correctly quote/escape the name, // to prevent shell expansion", but fails to note that "correct" is not well // defined and barely achievable here. -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/16 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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages checkinstall depends on: ii dpkg-dev1.19.7 ii file1:5.35-4 ii libc6 2.28-10 ii sensible-utils 0.0.12 Versions of packages checkinstall recommends: ii make 4.2.1-1.2 Versions of packages checkinstall suggests: ii gettext 0.19.8.1-9 -- no debconf information
Bug#939845: modprobe: ERROR: could not insert 'wireguard': Exec format error
On Wed, 11 Sep 2019, Daniel Kahn Gillmor wrote: But hm, maybe the 4.19.0-5 ABI wasn't actually stable? Thinking about this a bit more ... the issue wasn't a symvers mismatch, which is what I'd have expected if the ABI was not actually stable, and in my case the module headers exactly matched the running kernel anyways. The error was about a bad relocation. IIRC, the bad relocation would imply that the module's own compilation said "edit _in the module_ with ", but the place it was supposed to edit wasn't all zeros. Which sounds to me like the compiled module binary being inconsistent with itself, not with the running kernel? My understanding of relocations and how they work with kernel modules as opposed to normal userspace binaries is ... not strong, so I may be barking up the wrong tree here. -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#939845: modprobe: ERROR: could not insert 'wireguard': Exec format error
On Wed, 11 Sep 2019, Daniel Kahn Gillmor wrote: IIUC, dkms should build different modules for different kernel ABIs. it won't try to install the 4.19.0-6 module into the 4.19.0-5 kernel. Right, but it looks like the Makefile(s) for wireguard might have been buggy. Of course, I dont know if dkms even makes use of that Makefile. Not particularly relevant to this issue, regardless, though. It sounds to me like you and David are saying this report is specific to an interaction with 4.19.0-5 and wireguard 0.0.20190905-1, not that the problem has to do with a generic upgrade path. But hm, maybe the 4.19.0-5 ABI wasn't actually stable? do either of you (Matthew or David) know what version of 4.19.0-5 was actually running on your system, vs. what version of linux-headers-4.19.0-5 you had installed when it was built? That would be a useful datapoint. The machine in question for me has (unchanged since the issue): linux-headers-4.19.0-5-amd64/stable,now 4.19.37-5+deb10u2 And /var/log/kern.log says it was running: Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#939845: modprobe: ERROR: could not insert 'wireguard': Exec format error
Package: wireguard-dkms Version: 0.0.20190905-1 Followup-For: Bug #939845 Same problem here. Seems pretty normal to install updates before activating a new kernel I notice that systems that have hand-configured wireguard intefaces, the upgrade scripts won't reload the module, but systems just using wg-quick@.service do. Having a system update disable a network interface and fail to restore it is ... bad. Luckily I wasn't accessing the systems in question over that vpn! This item from /var/log/kern.log looks like it might be useful in tracing down the issue: module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1, loc fdbe1c28, val c14f00a6 This item from the git log for the new releae also seems like it might be related, though unlikely: https://git.zx2c4.com/WireGuard/commit/?id=dcca03f27879701d7377109517176a3aae86619f > Makefile: allow specifying kernel release > This makes depmod work when building/installing the module for a kernel > other than the currently running one. Not sure if the common dkms scripts might be passing the KERNELRELEASE var in a way that is messing up the build? In fairness, that seems ... unlikely to be the cause of an invalid relocation, and more likely to _fix_ having built the module for the new kernel before booting it :) -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wireguard-dkms depends on: ii dkms 2.6.1-4 ii perl 5.28.1-6 Versions of packages wireguard-dkms recommends: ii wireguard-tools 0.0.20190905-1 wireguard-dkms suggests no packages. -- no debconf information
Bug#939845: modprobe: ERROR: could not insert 'wireguard': Exec format error
On Wed, 11 Sep 2019, Matthew Gabeler-Lee wrote: Not sure if the common dkms scripts might be passing the KERNELRELEASE var in a way that is messing up the build? In fairness, that seems ... unlikely to be the cause of an invalid relocation, and more likely to _fix_ having built the module for the new kernel before booting it :) Small addendum: indeed the module built for the new kernel while running the old kernel indeed loaded correctly after booting into 4.19.0-6 -- I did not need to rebuild the dkms module after rebooting. It was, ironically, only the module built for the _running_ kernel that was bad. -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#933311: bitcoin-qt: symbol lookup error: bitcoin-qt: undefined symbol: _ZN7leveldb4port5Mutex6UnlockEv
On Mon, 26 Aug 2019, Jonas Smedegaard wrote: Quoting Matthew Gabeler-Lee (2019-08-26 15:42:32) Given its a symbols related issue, arguably that package needs its soversion bumped? If you mean bumping SOVERSION of bitcoin-qt, then I disagree, and ask you to please elaborate why you think that should be done. If you mean bumping SOVERSION of libleveldb1d then I agree. Yes, bumping soname/soversion of libleveldb is what I meant, sorry if wording was unclear there. Indeed, this package needs its dependency on libleveldb1d bumped. This problem happened while there was no change to bitcoin-qt and while libleveldb1d was upgraded to a newer upstream version. The cause of this problem is therefore likely that libleveldb1d failed to bump its soname. Only if bitcoin-qt is linking beyond the public API of libleveldb1d is bitcoin-qt to blame for this failure. I see no need for bumping any dependencies: A simple rebuild made the package work again, which to me indicates that this is a bug in libleveldb1d. Again, unclear wording on my part, sorry. I didn't mean bumping source dependency versions, just the binary version, which rebuilding does. Given this makes the daemon not launch, it probably merits a severity bump. Raising severity beyond "important" practically means "if this issue isn't fixed then better to remove the package from the arcive" which arguably doesn't make sense for bitcoin-qt (it works when only the right library is available) but certainly makes sense if reassigned to libleveldb1d (it is suspected that this issue affects other applications too). I have not had time to investigate closer if relevant to reassign, and prefer for now to leave this open but at non-fatal severity, as it is does not affect the 0.18.1~dfsg-1 release. I suspect that, whatever is done to libleveldb, a rebuild of the bitcoin package will be required. Help investigating closer would be much appreciated. apt-rdepends --reverse libleveldb1d gives: Reverse Depends: bitcoin-qt (0.18.1~dfsg-1) Reverse Depends: bitcoind (0.18.1~dfsg-1) Reverse Depends: caffe-tools-cpu (1.0.0+git20180821.99bd997-2+b1) Reverse Depends: caffe-tools-cuda (1.0.0+git20180821.99bd997-4) Reverse Depends: ceph-base (12.2.11+dfsg1-2.1) Reverse Depends: ceph-mon (12.2.11+dfsg1-2.1) Reverse Depends: ceph-osd (12.2.11+dfsg1-2.1) Reverse Depends: ceph-test (12.2.11+dfsg1-2.1) Reverse Depends: groestlcoin-qt (2.17.2~dfsg-1) Reverse Depends: groestlcoind (2.17.2~dfsg-1) Reverse Depends: libcaffe-cpu1 (1.0.0+git20180821.99bd997-2+b1) Reverse Depends: libcaffe-cuda1 (1.0.0+git20180821.99bd997-4) Reverse Depends: libleveldb-dev (= 1.22-3) Reverse Depends: libleveldb1.2-cil (1.9.1-1.2) Reverse Depends: libleveldb1d-dbgsym (= 1.20-2.1) Reverse Depends: librime1 (1.4.0+dfsg1-2+b1) Reverse Depends: litecoin-qt (0.17.1-1) Reverse Depends: litecoind (0.17.1-1) Reverse Depends: minetest (5.0.1+repack-2) Reverse Depends: minetest-server (5.0.1+repack-2) Reverse Depends: node-leveldown (1.5.0+dfsg-3+b1) Reverse Depends: python-leveldb (0~svn68-3+b3) Reverse Depends: python3-leveldb (0~svn68-3+b3) Reverse Depends: stenographer (0.0~git20190528.0.6415e2b-1) Presumably this bug needs to be reassigned to libleveldb, and once fixed there, bitcoin (and many other packages) will need to be rebuilt to depend on the new binary package that generates (liblevedb1e?). Digging into the leveldb source and its differences between 1.20 and 1.22, the "port" section of the library looks to have been completely rewritten, so I think the first step here is to reassign this to leveldb with a need for a soname bump since breaking changes were made to the ABI there. -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#933311: bitcoin-qt: symbol lookup error: bitcoin-qt: undefined symbol: _ZN7leveldb4port5Mutex6UnlockEv
Package: bitcoin-qt Version: 0.18.1~dfsg-1 Followup-For: Bug #933311 Indeed, this package needs its dependency on libleveldb1d bumped. Updating that package to the version in bullseye/sid fixes this issue. Given its a symbols related issue, arguably that package needs its soversion bumped? #933908 is a dupe of this for the bitcoind binary package. Given this makes the daemon not launch, it probably merits a severity bump. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/16 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) Versions of packages bitcoin-qt depends on: ii libboost-chrono1.67.0 1.67.0-13 ii libboost-filesystem1.67.0 1.67.0-13 ii libboost-system1.67.0 1.67.0-13 ii libboost-thread1.67.0 1.67.0-13 ii libc6 2.28-10 ii libdb5.3++ 5.3.28+dfsg1-0.5 ii libevent-2.1-6 2.1.8-stable-4 ii libevent-pthreads-2.1-62.1.8-stable-4 ii libgcc11:8.3.0-6 ii libleveldb1d 1.22-3 ii libminiupnpc17 2.1-1+b1 ii libprotobuf17 3.6.1.3-2 ii libqrencode4 4.0.2-1 ii libqt5core5a 5.11.3+dfsg1-1 ii libqt5dbus55.11.3+dfsg1-1 ii libqt5gui5 5.11.3+dfsg1-1 ii libqt5network5 5.11.3+dfsg1-1 ii libqt5widgets5 5.11.3+dfsg1-1 ii libsecp256k1-0 0.1~20170810-2 ii libssl1.1 1.1.1c-1 ii libstdc++6 9.2.1-1 ii libunivalue0 1.0.4-2 ii libzmq54.3.1-4+deb10u1 bitcoin-qt recommends no packages. bitcoin-qt suggests no packages. -- no debconf information
Bug#928672: firmware-misc-nonfree: please include GV100 signed firmware
Package: firmware-misc-nonfree Version: 20190717-1 Followup-For: Bug #928672 Still broken due to the one missing file -- m712 & Sven Joachim's messages above -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing'), (490, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-misc-nonfree depends on no packages. firmware-misc-nonfree recommends no packages. Versions of packages firmware-misc-nonfree suggests: ii initramfs-tools 0.133 -- no debconf information
Bug#934286: (no subject)
Subject: linux-image-5.2.0-2-amd64: More led trigger modules Package: src:linux Version: 5.2.7-1 Severity: wishlist It would be nice if some more LEDS options were enabled in Debian's configuration, e.g.: # CONFIG_LEDS_TRIGGER_ACTIVITY is not set # CONFIG_LEDS_TRIGGER_NETDEV is not set # CONFIG_LEDS_TRIGGER_PATTERN is not set -- Package-specific info: ** Kernel log: boot messages should be attached -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.1.0-trunk-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-5.2.0-2-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.133 ii kmod26-1 ii linux-base 4.6 Versions of packages linux-image-5.2.0-2-amd64 recommends: pn apparmor ii firmware-linux-free 3.4 Versions of packages linux-image-5.2.0-2-amd64 suggests: pn debian-kernel-handbook ii grub-efi-amd64 2.02+dfsg1-20 pn linux-doc-5.2 Versions of packages linux-image-5.2.0-2-amd64 is related to: ii firmware-amd-graphics 20190114-1 ii firmware-atheros 20190114-1 pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium ii firmware-intel-sound 20190114-1 pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv ii firmware-iwlwifi 20190114-1 pn firmware-libertas ii firmware-linux-nonfree20190114-1 ii firmware-misc-nonfree 20190114-1 pn firmware-myricom pn firmware-netxen pn firmware-qlogic ii firmware-realtek 20190114-1 pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#896184: conserver-server fails to restart on systemd reliably
Package: conserver-server Followup-For: Bug #896184 This problem has gotten even worse. Now the stop script has become completely ineffectual -- it will never stop the server at all, systemd or not. From the start-stop-daemon manpage, on --pidfile: Warning: using this match option with a world-writable pidfile or using it alone with a daemon that writes the pidfile as an unprivileged (non-root) user will be refused with an error (since version 1.19.3) as this is a security risk Thus, the stop script fails 100% of the time with: Stopping conserver: start-stop-daemon: matching only on non-root pidfile /var/run/conserver.pid is insecure On the upside, Bernhard's patch fixes this problem too :) -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.1.0-trunk-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages conserver-server depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii libpam0g 1.3.1-5 ii libssl1.1 1.1.1c-1 ii libwrap0 7.6.q-28 ii lsb-base 10.2019051400 conserver-server recommends no packages. conserver-server suggests no packages. -- Configuration Files: /etc/conserver/conserver.cf changed [not included] -- debconf information excluded
Bug#930401: mutter: Crashes on restart if Static Workspaces are enabled (gnome-shell)
Package: mutter Version: 3.30.2-7 Severity: normal Tags: upstream If you enable static instead of dynamic workspaces, then gnome-shell segfaults if you restart it. This has been reported and fixed upstream in 3.32.x, it would be nice if this fix could be backported to Debian's 3.30.x release. https://gitlab.gnome.org/GNOME/mutter/issues/479 https://gitlab.gnome.org/GNOME/mutter/merge_requests/466 https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1796607 Note: I've put "gnome-shell" in the title in the hopes of making it discoverable by web search, since the user perception is that this happens when restarting gnome-shell, even though the upstream bug/fix is in mutter. -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 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) Versions of packages mutter depends on: ii gnome-settings-daemon-common 3.30.2-3 ii gsettings-desktop-schemas 3.28.1-1 ii libc6 2.28-10 ii libglib2.0-0 2.58.3-2 ii libmutter-3-0 3.30.2-7 ii libx11-6 2:1.6.7-1 ii libxcomposite11:0.4.4-2 ii mutter-common 3.30.2-7 ii zenity3.30.0-2 mutter recommends no packages. Versions of packages mutter suggests: ii gnome-control-center 1:3.30.3-1 ii xdg-user-dirs 0.17-2 -- no debconf information
Bug#924035: libvirt-daemon: Unable to complete lxc guest shutdown: Failed to delete veth device
Package: libvirt-daemon Followup-For: Bug #924035 The LXC update sin the 5.0.0-3 appear to have resolved this bug :) -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.0.0-trunk-amd64 (SMP w/16 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) Versions of packages libvirt-daemon depends on: ii libacl1 2.2.53-4 ii libapparmor12.13.2-10 ii libaudit1 1:2.8.4-3 ii libavahi-client30.7-4+b1 ii libavahi-common30.7-4+b1 ii libblkid1 2.33.1-0.1 ii libc6 2.28-10 ii libcap-ng0 0.7.9-2 ii libcurl3-gnutls 7.64.0-3 ii libdbus-1-3 1.12.12-1 ii libdevmapper1.02.1 2:1.02.155-2 ii libfuse22.9.9-1 ii libgcc1 1:8.3.0-6 ii libgnutls30 3.6.6-2 ii libnetcf1 1:0.2.8-1+b2 ii libnl-3-200 3.4.0-1 ii libnl-route-3-200 3.4.0-1 ii libnuma12.0.12-1 ii libparted2 3.2-25 ii libpcap0.8 1.8.1-6 ii libpciaccess0 0.14-1 ii libsasl2-2 2.1.27+dfsg-1 ii libselinux1 2.8-1+b1 ii libssh2-1 1.8.0-2.1 ii libudev1241-3 ii libvirt05.0.0-3 ii libxenmisc4.11 4.11.1+26-g87f51bf366-3 ii libxenstore3.0 4.11.1+26-g87f51bf366-3 ii libxentoollog1 4.11.1+26-g87f51bf366-3 ii libxml2 2.9.4+dfsg1-7+b3 ii libyajl22.1.0-3 Versions of packages libvirt-daemon recommends: ii libxml2-utils 2.9.4+dfsg1-7+b3 ii netcat-openbsd 1.195-2 ii qemu1:3.1+dfsg-7 ii qemu-kvm1:3.1+dfsg-7 Versions of packages libvirt-daemon suggests: pn libvirt-daemon-driver-storage-gluster pn libvirt-daemon-driver-storage-rbd pn libvirt-daemon-driver-storage-zfs ii libvirt-daemon-system 5.0.0-3 pn numad -- no debconf information
Bug#929414: dbconfig-common: Assumes pgsql ident means dbuser must exist as a local user
Package: dbconfig-common
Version: 2.0.11
Severity: normal
dbconfig-common assumes that, if "ident" auth is used with postgresql, then
the database user must also exist as a local user.
This is ... not true.
The "peer" auth in postgresql just means that the identity of the connecting
user authenticates for the database user. There is no requirement that the
two must be the same.
Given a setup like this, upgrades fail in strange ways:
runuser: options --{shell,fast,command,session-command,login} and --user
are mutually exclusive
Running with `dbc_debug` shows a more useful sequence (long command lines
trimmed because it's only the start that is important):
creating database backup in /var/cache/dbconfig-common/backups/...
runuser --user -- /bin/sh -c "...
unable to connect to postgresql server.
dumping database as user failed, retrying with administrator credentials.
dbc_get_admin_pass() .
runuser --user postgres -- /bin/sh -c "...
runuser --user postgres -- /bin/sh -c "...
_dbc_apply_upgrades() 19.2.
applying upgrade sql for 18.12+dfsg-1 -> 19.2.
runuser --user -- /bin/sh -c "...
error encountered processing /usr/share/dbconfig-common/data/...
runuser: options --{shell,fast,command,session-command,login} and --user
are mutually exclusive
It doesn't help that `runuser` is giving a wildly misleading error here, but
the root cause is the `_dbc_psql_local_username` function having this logic:
if [ "${dbc_dbuser:-}" ] && id $dbc_dbuser >/dev/null 2>&1; then
echo $dbc_dbuser
return 0
else
dbc_error="ident method specified but local account doesn't
exist. mapping isn't supported"
return 1
fi
This is exacerbated by the call sites for this function not checking for
errors, and blithely passing the empty username string to `runuser`.
Ironically, in this configuration (system user is providing the real
authentication for connection over a unix socket), it seems that selecting
password auth and giving a bogus password may work, since pgsql won't be
looking at the password at all.
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable'), (500,
'oldstable'), (490, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.0.0-trunk-amd64 (SMP w/16 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)
Versions of packages dbconfig-common depends on:
ii debconf [debconf-2.0] 1.5.71
ii ucf3.0038+nmu1
dbconfig-common recommends no packages.
Versions of packages dbconfig-common suggests:
ii dbconfig-mysql2.0.11
ii dbconfig-pgsql2.0.11
ii dbconfig-sqlite3 2.0.11
-- debconf information excluded
Bug#929273: deborphan: Can't add first keep entry: invalid seek
Package: deborphan
Version: 1.7.31
Severity: normal
Trying to use `deborphan --add-keep` with an empty or absent keep file fails:
deborphan: fseek on /var/lib/deborphan/keep: Invalid argument
strace says the failing seek is:
openat(AT_FDCWD, "/var/lib/deborphan/keep", O_RDWR|O_CREAT|O_APPEND, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lseek(3, -4096, SEEK_SET) = -1 EINVAL (Invalid argument)
Checking the source, this code in keep.c looks suspect:
// ... check if the final newline is missing ...
if (fseek(fp, -1L, SEEK_END) < 0) {
error(EXIT_FAILURE, errno, "fseek on %s", kfile);
}
That's not going to work on an empty file.
Editing the keep file by hand to put an entry, or just a blank line, in it
makes it work, but the default installation state of the package is
non-functional.
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (490,
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-4-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)
LSM: AppArmor: enabled
Versions of packages deborphan depends on:
ii libc6 2.28-10
Versions of packages deborphan recommends:
ii apt 1.8.1
ii dialog1.3-20190211-1
ii gettext-base 0.19.8.1-9
deborphan suggests no packages.
-- no debconf information
Bug#699392: xscreensaver requires xfonts-100dpi or xfonts-75dpi
On Wed, 1 May 2019, Jamie Zawinski wrote: -arabic-newspaper-medium-r-normal--19-140-100-100-p-0-iso10646-1 I'm gonna guess that this font, despite claiming to be 10646 (Unicode) does not actually contain Latin characters... So that's not ideal if your locale is set to one that requires those. That sounds likely... It looks like you've got a smattering of Arabic and Japanese fonts, but all of your Latin fonts are fixed-width! Is that intentional? By which I mean is, did you do this on purpose or is your distro doing this by default for some reason? Maybe you manually deleted some package that you shouldn't have? It's certainly not intentinoal in the sense of uninstalling things. But the system in question _is_ an intentionally fairly minimal vm/container setup for a specific build environment. In particular, this container was setup with APT::Install-Recommends (and Suggests) disabled. Are any of your apps capable of displaying Latin letters in variable width? If so, my next question will be, what font are those apps finding and how? Yep ... Chrome, VS Code, all the basic LXDE apps, kdiff3, pgAdmin III, LXTerminal's preferences screen, all render just fine. but I think those are all using TrueType fonts via fontconfig/etc, not "traditional" X11 fonts. My list of installed packages providing files under /usr/share/fonts (i.e. dpkg -S /usr/share/fonts passed through some cleanup) is: fonts-cantarell fonts-dejavu-core fonts-dejavu-extra fonts-droid-fallback: fonts-freefont-ttf fonts-hack fonts-liberation fonts-noto-cjk fonts-noto-core fonts-noto-mono fonts-noto-ui-core fonts-noto-unhinted fonts-opensymbol fonts-quicksand fonts-roboto-unhinted fonts-symbola xfonts-base xfonts-encodings xfonts-scalable xfonts-utils The following patch might help: this will remove the wildcard font-family fallback, which should result in the xscreensaver dialogs being in "fixed" instead of that Arabic font. But I'd still like to understand how your machine got into this state, and how likely it is that others will also be dealing with similar configurations. The patch works with precisely the expected effect, yes. PS: Thanks for all your help following up on this :) -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#699392: xscreensaver requires xfonts-100dpi or xfonts-75dpi
On Tue, 30 Apr 2019, Jamie Zawinski wrote: Ok, I'm not really sure what's going on here. This makes me feel better ;) Possibly the problem is that your font cache needs to be regenerated with fc-cache? Tried that, didn't impact things. There's definitely a sign something is wonky in that area, however, given: $ grep -r helvetica /usr/share/fonts/X11 /usr/share/fonts/X11/misc/fonts.alias:variable -*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-1 (and no other matches) This didn't make sense with my first round at the diagnostics you asked for below, so I tried restarting the X session after removing the xfonts-100dpi and doing things over again. What do you get with: xlsfonts -fn '-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1' Before the X restart, I got 3 answers for '-adobe-helvetica-...'. After the restart, I get: xlsfonts: pattern "-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1" unmatched xlsfonts -fn '-adobe-helvetica-bold-r-normal--0-0-100-100-p-0-iso8859-1' Before the restart, I got one answer. After I get: xlsfonts: pattern "-adobe-helvetica-bold-r-normal--0-0-100-100-p-0-iso8859-1" unmatched Does text show if you do: xterm -fn '-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1' I get text, looks like the standard "fixed" font ... but presumably that's related to this error: xterm: cannot load font "-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1" This one didn't change before/after restarting X. I've re-collected the debug output from the prior round of this from the clean restart of the X server in the hopes that might help provide less confusing diagnostics. Notably now helvetica doesn't appear at all in the output of xlsfonts. The two variants of medium listed as "substituted ..." in the xscreensaver debug output produce "interesting" results in xterm: -*-*-medium-r-*-*-*-180-*-*-p-*-iso10646-1 => giant xterm with huge square characters (as judged by the size of the cursor block), but all the characters are blank -*-*-medium-r-*-*-*-140-*-*-p-*-iso10646-1 => same idea, just slightly less huge. Huge here being approximately 3x the height & 4x the width of the characters in xterm's default font. xlsfonts on each of these patterns produces this output (substituting the 140 point size as appropriate for that case): -arabic-newspaper-medium-r-normal--19-140-100-100-p-0-iso10646-1 -mutt-clearlyu alternate glyphs-medium-r-normal--19-140-100-100-p-0-iso10646-1 -mutt-clearlyu arabic-medium-r-normal--19-140-100-100-p-0-iso10646-1 -mutt-clearlyu pua-medium-r-normal--19-140-100-100-p-0-iso10646-1 -mutt-clearlyu-medium-r-normal--19-140-100-100-p-0-iso10646-1 I can't select the first one in xfontsel for whatever reason, which seems odd. In fact, if I get xfontsel to -*-*-medium-r-*-*-*-*-*-*-p-*-iso10646-1, there are _no_ fonts at ptSz 180 or 140. If I select one of the ptSz values that exists for the "arabic" one, I don't get any text. Same happens with "mutt-clearlyu alternate glyphs", and mostly so with "... arabic" (there's a couple funky characaters rendered, but nothing in the latin alphanumerics). "mutt-clearlyu pua" renders mostly as tofu (as opposed to totally blank space). "mutt-clearlyu" renders as an ugly but legible font with the expected characters all there. , hope this helps! -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9 fonts.2.txt.gz Description: fonts.2.txt.gz xscreensaver.debug.2.log.gz Description: xscreensaver.debug.2.log.gz
Bug#699392: xscreensaver requires xfonts-100dpi or xfonts-75dpi
On Mon, 22 Apr 2019, Jamie Zawinski wrote: Xscreensaver 5.42 tries really hard to do something sensible with whatever set of garbage fonts you happen to have installed, so it would be helpful if you send me the output of xlsfonts on your system where it's doing something terrible. Attached fonts.txt.gz with that output. In experimenting with this, I noticed that if I launch xfontsel and tell it to use the same font spec xscreensaver defaults to, it comes up ... bit with all the text blank. Just like xscreensaver. But if I launch it normally, I can't find any font that matches that font spec, oddly. If you're feeling adventurous, rebuilding with DEBUG defined in utils/font-retry.c and sending me the output of a run with that version would also be helpful. Did that ... also had to increase the size of stderr_buffer by 100x in order to get all the output without truncation. Attached xscreensaver.debug.log.gz with the output of that. That log shows launching "xscreensaver -verbose", then from another terminal I ran "xscreensaver-command -lock", unlocked it interactively, and then ran "xscreensaver-command -exit" to terminate it cleanly. All the font related output starts when I began the unlock process, unsurprisingly. If I read the logs correctly, it looks like the determined font it's choosing is: xscreensaver: substituted "-*-*-medium-r-*-*-*-170-*-*-p-*-iso10646-1" for "-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1" I'm not sure what font that is ... I can't find it in xlsfonts. I can get close, if I ignore the 170, but the font that picks doesn't render any characters in xfontsel, which is ... suspicious. Poking around most of the options in xfontsel under iso10646 fail to render characters, or at least any letters or numbers. For comparison, when xfonts-100dpi is installed, the font debug output, in its entirety, is: xscreensaver: loaded -*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1 xscreensaver: loaded -*-helvetica-bold-r-*-*-*-140-*-*-*-*-iso8859-1 xscreensaver: loaded -*-helvetica-bold-r-*-*-*-140-*-*-*-*-iso8859-1 xscreensaver: loaded -*-helvetica-bold-r-*-*-*-140-*-*-*-*-iso8859-1 xscreensaver: loaded -*-courier-medium-r-*-*-*-140-*-*-*-iso8859-1 xscreensaver: loaded -*-helvetica-medium-r-*-*-*-80-*-*-*-*-iso8859-1 xscreensaver: loaded -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-1 Hope all this helps, let me know if there's more info I can collect that would be useful. -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9 fonts.txt.gz Description: fonts.txt.gz xscreensaver.debug.log.gz Description: xscreensaver.debug.log.gz
Bug#928212: tt-rss: Update to 19.2
Package: tt-rss Version: 18.12+dfsg-1 Severity: wishlist Please consider updating tt-rss to upstream 19.2 release. The 18.12 release removed some major features, major enough that the outcry caused upstream to bring them back just a couple days after (combined mode). It looks like buster already has the dependencies needed for the 19.2 release (new versions of dojo/dijit).
Bug#699392: xscreensaver requires xfonts-100dpi or xfonts-75dpi
Package: xscreensaver Version: 5.42+dfsg1-1 Followup-For: Bug #699392 It's now actually worse. The core xscreensaver package does not work without xfonts-(100|75)dpi installed, because the font it uses to render the unlock widget is unavailable without one of those packages installed. The result then, is that you get the unlock widget, and it works ... if you know what it is supposed to look like. The only text on it that renders is the username and password asterisks. Everything else is a sea of blankness. As to Tormod's question of 6+ years ago, this can happen if you have a headless box using a vnc server to provide X sessions. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.0.0-trunk-amd64 (SMP w/16 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#924035: libvirt-daemon: Unable to complete lxc guest shutdown: Failed to delete veth device
Package: libvirt-daemon Version: 5.0.0-1 Severity: normal Dear Maintainer, Since a recent upgrade (I _think_ this showed up when libvirt 5.0 migrated to buster, but I'm not entirely sure of that. It could also be related to the 4.20 kernel, which is the minimum version needed to support the onboard graphics in my coffee lake system), I can no longer fully shut down lxc guests. I can't trigger a guest shutdown externally, but that is not the bug I'm reporting here. If I trigger the guest shutdown from within the guest, the guests shuts down, and the parent libvirt_lxc process exits, but the libvirt daemon then hits an error, which is logged thus: 2019-03-08 16:14:00.548+: 17612: error : virNetDevVethDelete:210 : internal error: Failed to delete veth device vnet3 (the vnet device number of course changes over time / guest) At this point I can neither force shut down the guest, nor can I restart it. My ownly recourse is to restart the libvirt daemon (reload is insufficient). A restart _does_ work, but it disconnects all clients, and I've had bad experiences in the past with such actions putting libvirt / guests into a bad state, e.g. having two copies of every lxc guest running, one of which has become completely dissociated from the libvirt daemon, with chaotic and deleterious effect. Note: this does _not_ affect qemu guests. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.20.0-trunk-amd64 (SMP w/16 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) Versions of packages libvirt-daemon depends on: ii libacl1 2.2.52-5 ii libapparmor12.13.2-7 ii libaudit1 1:2.8.4-2 ii libavahi-client30.7-4+b1 ii libavahi-common30.7-4+b1 ii libblkid1 2.33.1-0.1 ii libc6 2.28-7 ii libcap-ng0 0.7.9-2 ii libcurl3-gnutls 7.64.0-1 ii libdbus-1-3 1.12.12-1 ii libdevmapper1.02.1 2:1.02.155-2 ii libfuse22.9.9-1 ii libgcc1 1:8.2.0-21 ii libgnutls30 3.6.6-2 ii libnetcf1 1:0.2.8-1+b2 ii libnl-3-200 3.4.0-1 ii libnl-route-3-200 3.4.0-1 ii libnuma12.0.12-1 ii libparted2 3.2-24 ii libpcap0.8 1.8.1-6 ii libpciaccess0 0.14-1 ii libsasl2-2 2.1.27+dfsg-1 ii libselinux1 2.8-1+b1 ii libssh2-1 1.8.0-2 ii libudev1240-6 ii libvirt05.0.0-1 ii libxenmisc4.11 4.11.1-1 ii libxenstore3.0 4.11.1-1 ii libxentoollog1 4.11.1-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libyajl22.1.0-3 Versions of packages libvirt-daemon recommends: ii libxml2-utils 2.9.4+dfsg1-7+b3 ii netcat-openbsd 1.195-2 ii qemu1:3.1+dfsg-4 ii qemu-kvm1:3.1+dfsg-4 Versions of packages libvirt-daemon suggests: pn libvirt-daemon-driver-storage-gluster pn libvirt-daemon-driver-storage-rbd pn libvirt-daemon-driver-storage-zfs ii libvirt-daemon-system 5.0.0-1 pn numad -- no debconf information
Bug#923254: watchdog: service restart always fails
Package: watchdog
Version: 5.15-2
Severity: normal
I've noticed it due to needrestart, but even on manual invocations
restarting the watchdog service (systemctl restart watchdog.service)
_always_ fails. The service status after a failed restart looks like this:
● watchdog.service - watchdog daemon
Loaded: loaded (/lib/systemd/system/watchdog.service; enabled; vendor
preset: enabled)
Active: inactive (dead) since Mon 2019-02-25 09:32:15 EST; 3s ago
Process: 30341 ExecStartPre=/bin/sh -c [ -z "${watchdog_module}" ] || [
"${watchdog_module}" = "none" ] || /sbin/modprobe $watchdog_module
(code=exited, status=0/SUCCESS)
Process: 30342 ExecStart=/bin/sh -c [ $run_watchdog != 1 ] || exec
/usr/sbin/watchdog $watchdog_options (code=exited, status=0/SUCCESS)
Process: 30348 ExecStopPost=/bin/sh -c [ $run_wd_keepalive != 1 ] || false
(code=exited, status=1/FAILURE)
Main PID: 30344 (code=exited, status=0/SUCCESS)
This is reproducible on multiple machines for me.
The shell snippet under ExecStopPost is suspicious to me, as the construct
it uses will _always_ fail. It looks like it's meant to make the service
stop fail so as to trigger the wd_keepalive service. The wd_keepalive
service settings have an ExecStartPre that looks like it's supposed to clear
this failed state, but it doesn't seem to work properly. Either way the
"always fail on stop" nature makes restarting the watchdog service normally
impossible, which is not good.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable'), (500,
'oldstable'), (490, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.20.0-trunk-amd64 (SMP w/16 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)
Versions of packages watchdog depends on:
ii debconf [debconf-2.0] 1.5.70
ii init-system-helpers1.56+nmu1
ii libc6 2.28-7
ii lsb-base 10.2018112800
ii makedev2.3.1-94
ii udev 240-6
watchdog recommends no packages.
watchdog suggests no packages.
-- Configuration Files:
/etc/default/watchdog changed:
run_watchdog=1
run_wd_keepalive=1
watchdog_module="iTCO_wdt"
watchdog_options=""
/etc/watchdog.conf changed:
realtime= yes
priority= 1
file = /var/log/total
change = 600
-- debconf information:
* watchdog/run: true
* watchdog/run_keepalive: true
* watchdog/restart: true
* watchdog/module: iTCO_wdt
Bug#920205: gimp: Hangs at startup trying to show toolbox window
Package: gimp Version: 2.10.8-2 Severity: important After updating from stretch->buster, gimp no longer starts for me. I took a look at #903514, but it does _not_ appear to be the issue I'm having: for one, when I first encountered this, I had neither gimp-python nor any openblas packages installed. Second, I took a backtrace in GDB, and it does not look at all like the ones posted to that bug. I also took a look at #672894, but that is for a much much older version, and also does not look like my issue. I tried moving away my gimp config directory, and while that changes the backtrace, it does not change the behavior. Here is the last few lines of output (ran with --verbose) and then the main thread backtrace for the hang when running with a ~/.config/GIMP/... directory: Starting extension: 'extension-script-fu' [Detaching after vfork from child process 16833] INIT: gui_restore_after_callback Parsing '/home/cheetah/.config/GIMP/2.10/menurc' Parsing '/home/cheetah/.config/GIMP/2.10/action-history' Parsing '/home/cheetah/.config/GIMP/2.10/devicerc' Parsing '/home/cheetah/.config/GIMP/2.10/controllerrc' loading menu '/usr/share/gimp/2.0/menus/image-menu.xml' for /image-menubar ^C/usr/lib/gimp/2.0/plug-ins/script-fu/script-fu terminated: Interrupt Thread 1 "gimp" received signal SIGINT, Interrupt. 0x769d6b39 in __GI___poll (fds=0x560ccb60, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. (gdb) bt #0 0x769d6b39 in __GI___poll (fds=0x560ccb60, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x76ca2016 in g_main_context_poll (priority=, n_fds=3, fds=0x560ccb60, timeout=, context=0x55d7b190) at ../../../glib/gmain.c:4221 #2 g_main_context_iterate (context=context@entry=0x55d7b190, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:3915 #3 0x76ca213c in g_main_context_iteration (context=0x55d7b190, may_block=1) at ../../../glib/gmain.c:3981 #4 0x77c06b01 in gtk_main_iteration () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #5 0x77d256c5 in gtk_widget_show_now () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #6 0x55799ad1 in gimp_dialog_factory_dialog_new_internal (factory=factory@entry=0x5607c6d0, screen=screen@entry=0x55da69d0, monitor=monitor@entry=0, context=, ui_manager=ui_manager@entry=0x0, identifier=identifier@entry=0x58180ba0 "gimp-toolbox-window", view_size=0, return_existing=0, present=1, create_containers=0) at gimpdialogfactory.c:666 #7 0x55799f14 in gimp_dialog_factory_dialog_new (factory=factory@entry=0x5607c6d0, screen=screen@entry=0x55da69d0, monitor=monitor@entry=0, ui_manager=ui_manager@entry=0x0, identifier=0x58180ba0 "gimp-toolbox-window", view_size=view_size@entry=0, present=1) at gimpdialogfactory.c:702 #8 0x5565fbb2 in dialogs_restore_dialog (factory=0x5607c6d0, screen=0x55da69d0, monitor=0, info=) at dialogs.c:473 #9 0x557ec187 in gimp_session_info_restore (info=0x562a4a60, factory=0x5607c6d0, screen=0x55da69d0, monitor=0) at gimpsessioninfo.c:573 #10 0x5579b202 in gimp_dialog_factory_restore (factory=0x5607c6d0, screen=screen@entry=0x55da69d0, monitor=monitor@entry=0) at gimpdialogfactory.c:1455 #11 0x5562b005 in session_restore (gimp=gimp@entry=0x55dd2090, screen=0x55da69d0, monitor=0) at session.c:340 #12 0x55627b05 in gui_restore_after_callback (gimp=0x55dd2090, status_callback=) at gui.c:714 #13 0x76d83c7d in g_closure_invoke (closure=0x560f8420, return_value=0x0, n_param_values=2, param_values=0x7fffdd80, invocation_hint=0x7fffdd00) at ../../../gobject/gclosure.c:810 #14 0x76d96e2e in signal_emit_unlocked_R (node=node@entry=0x55dcb2c0, detail=detail@entry=0, instance=instance@entry=0x55dd2090, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffdd80) at ../../../gobject/gsignal.c:3705 #15 0x76da02c2 in g_signal_emit_valist (instance=, signal_id=, detail=, var_args=var_args@entry=0x7fffdf50) at ../../../gobject/gsignal.c:3391 #16 0x76da090f in g_signal_emit (instance=instance@entry=0x55dd2090, signal_id=, detail=detail@entry=0) at ../../../gobject/gsignal.c:3447 #17 0x558e13fd in gimp_restore (gimp=gimp@entry=0x55dd2090, status_callback=status_callback@entry=0x5562c710 , error=error@entry=0x7fffe098) at gimp.c:797 #18 0x55624e03 in app_run (full_prog_name=, filenames=, alternate_system_gimprc=, alternate_gimprc=0x0, session_name=, batch_interpreter=0x0, batch_commands=0x0, as_new=0, no_interface=0, no_data=0, no_fonts=0, no_splash=0, be_verbose=1, use_shm=1, use_cpu_accel=1, console_messages=0, use_debug_handler=0, show_playground=0,
Bug#839843: /usr/bin/lxc-create: Ran rm -rf on an entire filesystem after failing to create a container
reassign 839843 lxc-templates 3.0.3-1
thanks
On 2019-01-10 18:12, Pierre-Elliott Bécue wrote:
Matthew, I'm really sorry about the bad experience you've met in 2016.
I
guess you don't have the reply to Christian question three years after.
I'll let the bug open, but I guess it'll never find a solution.
Well, as you surmised I don't have much direct info at this stage, esp.
since this happened on a work machine at a job I have since left.
However looking back at Christian's questions, and comparing that to the
current LXC code and the basics of what I know I was trying to do at the
time, I think I now understand what went wrong.
As you can guess from the directory names, I was working on
instantiating a CentOS container.
Looking at the lxc-centos template in current Buster, I see this code:
##
revert()
{
echo "Interrupted, so cleaning up"
lxc-destroy -n $name
# maybe was interrupted before copy config
rm -rf $path
echo "exiting..."
exit 1
}
trap revert SIGHUP SIGINT SIGTERM
##
And now the horror show makes a little more sense. I suspect, in trying
to work out how to change where it created the original rootfs from
being under /var to the destination I wanted (a container-named folder
in that /scratch filesystem), I had used --path /scratch. I probably
then realized it was creating the rootfs as /scratch/rootfs not
/scratch/container-name, and hit Ctrl-C. And that triggered the revert
code above, which ran the rm -rf /scratch.
I note that only some of the templates have this pattern -- archlinux,
centos, fedora, fedora-legacy, pld, and void-linux. The lxc-debian
template does not, though it does have a SIGINT handler, that cleans up
something different and which looks guaranteed to be "safe".
So, I guess this bug needs to be reassigned to lxc-templates. I've
tried to do that above, hopefully I didn't fat finger it :)
Bug#787555: lvm2: Unmount of invalid (full) snapshot unmounts main device too
So, this bit me again, years later. This time I have a better
understanding of what is going on.
When a snapshot is mounted, /proc/mounts gets weird. Here's an example
having created two LVs, bind mounting the first onto a new directory,
and then mounting a snapshot of the second lv into the subdir of that
new directory.
+ grep /mnt/snaptest /proc/mounts
/dev/mapper/ssd1-test1 /mnt/snaptest/a ext4 rw,relatime 0 0
/dev/mapper/ssd1-test2 /mnt/snaptest/a/2 ext4 rw,relatime 0 0
/dev/mapper/ssd1-test1 /mnt/snaptest/b ext4 rw,relatime 0 0
/dev/mapper/ssd1-test2--snap /mnt/snaptest/b/2 ext4 rw,relatime 0 0
/dev/mapper/ssd1-test2--snap /mnt/snaptest/a/2 ext4 rw,relatime 0 0
Note that /proc/mounts is LYING. I have no idea why. But the last line
there claiming that the snapshot is mounted on the "a" directory (the
"original" one) is utterly untrue. My guess is that this has something
to do with how bind mounts work?
It's acting as if I used "mount --rbind" or such, but I did not, I used
"mount --bind".
In the example above, I'm using an LV for the "root" FS ("test1"), but
in the real world that is not an LV so I can't create a snapshot from it
and avoid the bind mounting. For context, the real world thing I'm
doing here is setting up a separate set of mounts, using snapshot LVs
wherever I can, that is a copy of the system layout, to then run a
backup tool against that "snapshot" setup.
This weirdness with /proc/mounts is also, I think, causing heinous
confusion to systemd even without the snapshot LV getting full, causing
systemd to try to unmount the original directory when the snapshot
device is removed. This is super-fun on a production server when the
snapshot is of /var or /usr and thus stopping local-fs.target and
bringing down almost everything for no good reason.
--
-- Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#918758: iftop: Doesn't support multi-gigabit interfaces
Package: iftop Version: 1.0~pre4-5 Severity: normal Tags: upstream iftop doesn't properly handle interface speeds (e.g. -m option) above 1Gbps. Upstream has fixed this in git: https://code.blinkace.com/pdw/iftop/commit/77901c8c53e01359d83b8090aacfe62214658183 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.0-trunk-amd64 (SMP w/16 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) Versions of packages iftop depends on: ii libc62.28-2 ii libncurses6 6.1+20181013-1 ii libpcap0.8 1.8.1-6 ii libtinfo66.1+20181013-1 iftop recommends no packages. iftop suggests no packages. -- no debconf information
Bug#918757: i965-va-driver: Please update to 2.3.0 for fuller Coffee Lake support
Package: i965-va-driver Version: 2.2.0+dfsg1-2 Severity: normal While the description of this package claims it contains support for Coffee Lake, that support is incomplete in v2.2.0. Upstream 2.3.0 release has support for newer Coffee Lake (and Kaby Lake) PCI IDs that the 2.2 driver is lacking. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.0-trunk-amd64 (SMP w/16 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) Versions of packages i965-va-driver depends on: ii libc6 2.28-2 ii libdrm-intel1 2.4.95-1 ii libdrm22.4.95-1 ii libva2 [libva-driver-abi-1.2] 2.3.0-2 i965-va-driver recommends no packages. Versions of packages i965-va-driver suggests: pn i965-va-driver-shaders -- no debconf information
Bug#918755: deborphan: guess-python suggests removing python3-cffi-backend despite being needed by certbot
Package: deborphan Version: 1.7.30 Severity: normal I have certbot explicitly installed, which depends on python3-certbot, on python3-cryptography, which depends on (virtual?) packages python3-cffi-backend-api-min (<= 9729), python3-cffi-backend-api-max (>= 9729). Runing deborpha --guess-python suggests uninstalling python3-cffi-backend, which would force certbot to be removed, which is clearly not desirable. I'm guessing from context that this is a problem with virtual packages like this? -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.0-trunk-amd64 (SMP w/16 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) Versions of packages deborphan depends on: ii libc6 2.28-2 Versions of packages deborphan recommends: ii apt 1.8.0~alpha3 ii dialog1.3-20181022-1 ii gettext-base 0.19.8.1-9 deborphan suggests no packages. -- no debconf information
Bug#918753: xscreensaver: xdg desktop files miss many items from debian menu file
Package: xscreensaver Version: 5.40-1 Severity: normal I noticed on an upgrade that I lost (in wmaker) many menu items related to xscreensaver. On investigation this is because these menu items are only provided in xscreensaver in the legacy Debian menu system and not in the modern xdg / freedesktop .desktop files, which is all that many things support these days. Of particular note to me personally was the menu item to lock the screen immediately, which was very useful. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.0-trunk-amd64 (SMP w/16 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) Versions of packages xscreensaver depends on: ii libatk1.0-0 2.30.0-2 ii libc62.28-2 ii libcairo21.16.0-2 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-7 ii libglade2-0 1:2.6.4-2+b1 ii libglib2.0-0 2.58.2-3 ii libgtk2.0-0 2.24.32-3 ii libice6 2:1.0.9-2 ii libpam0g 1.1.8-3.8 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpangoft2-1.0-01.42.4-6 ii libsm6 2:1.2.2-1+b3 ii libx11-6 2:1.6.7-1 ii libxext6 2:1.3.3-1+b2 ii libxi6 2:1.7.9-1 ii libxinerama1 2:1.1.4-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxmu6 2:1.1.2-2 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxt6 1:1.1.5-1 ii libxxf86vm1 1:1.1.4-1+b2 ii xscreensaver-data5.40-1 Versions of packages xscreensaver recommends: ii libjpeg-turbo-progs 1:1.5.2-2+b1 ii perl5.28.1-3 ii wamerican [wordlist]2018.04.16-1 ii wamerican-large [wordlist] 2018.04.16-1 Versions of packages xscreensaver suggests: ii elinks [www-browser]0.12~pre6-14 ii firefox [www-browser] 64.0-1 pn fortune pn gdm3 | kdm-gdmcompat ii google-chrome-stable [www-browser] 71.0.3578.98-1 ii links [www-browser] 2.17-1 ii lynx [www-browser] 2.8.9rel.1-2 pn qcam | streamer ii w3m [www-browser] 0.5.3-36+b1 pn xdaliclock pn xfishtank pn xscreensaver-data-extra ii xscreensaver-gl 5.40-1 pn xscreensaver-gl-extra -- no debconf information
Bug#918728: libvirt-daemon should provide iscsi-direct storage backend
Package: libvirt-daemon Version: 4.10.0-2 Severity: normal Upstream now has an "iscsi-direct" storage backend which has several advantages over the iscsiadm-based "iscsi" storage backend, including performance and not having the iscsi devices visible to the rest of the system. Debian's libvirt-daemon package should build with this enabled, or provide a libvirt-daemon-driver-storage-iscsi-direct package. -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.0-trunk-amd64 (SMP w/16 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) Versions of packages libvirt-daemon depends on: ii libacl1 2.2.52-3+b1 ii libapparmor12.11.0-3+deb9u2 ii libaudit1 1:2.6.7-2 ii libavahi-client30.6.32-2 ii libavahi-common30.6.32-2 ii libblkid1 2.33-0.2 ii libc6 2.28-2 ii libcap-ng0 0.7.9-1+b1 ii libcurl3-gnutls 7.62.0-1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdevmapper1.02.1 2:1.02.155-1 ii libfuse22.9.8-2 ii libgcc1 1:8.2.0-13 ii libgnutls30 3.6.5-2 ii libnetcf1 1:0.2.8-1+b2 ii libnl-3-200 3.2.27-2 ii libnl-route-3-200 3.2.27-2 ii libnuma12.0.11-2.1 ii libparted2 3.2-23 ii libpcap0.8 1.8.1-3 ii libpciaccess0 0.13.4-1+b2 ii libsasl2-2 2.1.27~101-g0780600+dfsg-3 ii libselinux1 2.6-3+b3 ii libssh2-1 1.7.0-1 ii libudev1232-25+deb9u6 ii libvirt04.10.0-2 ii libxenmisc4.11 4.11.1~pre.20180911.5acdd26fdc+dfsg-5 ii libxenstore3.0 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10 ii libxentoollog1 4.11.1~pre.20180911.5acdd26fdc+dfsg-5 ii libxml2 2.9.4+dfsg1-2.2+deb9u2 ii libyajl22.1.0-2+b3 Versions of packages libvirt-daemon recommends: ii libxml2-utils 2.9.4+dfsg1-2.2+deb9u2 ii netcat-openbsd 1.195-1 ii qemu1:3.1+dfsg-2 ii qemu-kvm1:3.1+dfsg-2 Versions of packages libvirt-daemon suggests: pn libvirt-daemon-driver-storage-gluster pn libvirt-daemon-driver-storage-rbd pn libvirt-daemon-driver-storage-sheepdog pn libvirt-daemon-driver-storage-zfs ii libvirt-daemon-system 4.10.0-2 pn numad -- no debconf information
Bug#918116: intel-gpu-tools: Unable to read its own config files due to use-after-free
Package: intel-gpu-tools
Version: 1.22-1
Severity: normal
With a recent libc update, the register access tools all fail like this:
Error: /usr/share/intel-gpu-tools/registers/common_display.txt:1:
('CPU_VGACNTRL', '0x00041000', '')
Error: /usr/share/intel-gpu-tools/registers/haswell:1: common_display.txt
Warning: reading '/usr/share/intel-gpu-tools/registers/haswell' failed. Using
builtin register spec.
Some gdb work tracked this down to a use-after free in the parsing code
(tools/intel_reg_spec.c)
} else if (i == 2) {
reg->addr = strtoul(p, , 16);
free(p);
if (*e)
ret = -1;
It seems that it "got away" with this with older libc versions, but
something changed between the libc in stretch and that in buster and now
this use-after-free reliably fails every time for me.
-- System Information:
Debian Release: 9.6
APT prefers stable
APT policy: (990, 'stable'), (500, 'testing'), (490, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-8-amd64 (SMP w/4 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)
Versions of packages intel-gpu-tools depends on:
ii libc6 2.28-2
ii libcairo2 1.16.0-2
ii libdrm-intel1 2.4.74-1
ii libdrm22.4.95-1
ii libkmod2 23-2
ii libpciaccess0 0.13.4-1+b2
ii libprocps6 2:3.3.12-3+deb9u1
ii libudev1 232-25+deb9u6
ii libunwind8 1.1-4.1
ii libx11-6 2:1.6.4-3+deb9u1
ii libxext6 2:1.3.3-1+b2
ii libxrandr2 2:1.5.1-1
ii libxv1 2:1.0.11-1
ii zlib1g 1:1.2.11.dfsg-1
intel-gpu-tools recommends no packages.
intel-gpu-tools suggests no packages.
-- no debconf information
Bug#916249: luksipc: Should depend on cryptsetup-bin, not cryptsetup
Package: luksipc Version: 0.04-2+b1 Severity: normal luksipc just needs the binaries (/sbin/cryptsetup) from cryptsetup-bin, it doesn't need the boot process integration from cryptsetup. As such it should depend just on the bin package. This is useful if one is using it with disk images or the like and don't want update-initramfs to constantly produce scary warnings about not being able to find your boot device if it isn't encrypted. -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/12 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) Versions of packages luksipc depends on: ii cryptsetup 2:1.7.3-4 ii dmsetup 2:1.02.137-2 ii libc6 2.27-8 luksipc recommends no packages. luksipc suggests no packages. -- no debconf information
Bug#909776: aria2: Missing SFTP support
Package: aria2 Version: 1.30.0-2 Severity: normal While all the aria2c documentation says you can use it with SFTP, trying to do so with the Debian package fails to work, presumably because the Debian package is failing to build it with libssh2 support. I suspect that simply adding libssh2-1-dev to the Build-Depends list would resolve this. -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/12 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) Versions of packages aria2 depends on: ii libc-ares21.12.0-1+deb9u1 ii libc6 2.27-6 ii libgcc1 1:6.3.0-18+deb9u1 ii libgmp10 2:6.1.2+dfsg-1 ii libgnutls30 3.5.8-5+deb9u3 ii libnettle63.3-1+b2 ii libsqlite3-0 3.25.0-1 ii libstdc++68.2.0-7 ii libxml2 2.9.4+dfsg1-2.2+deb9u2 ii zlib1g1:1.2.11.dfsg-1 Versions of packages aria2 recommends: ii ca-certificates 20161130+nmu1+deb9u1 aria2 suggests no packages. -- no debconf information
Bug#905608: wmaker: Should build with Magick support
Package: wmaker Version: 0.95.7-8 Severity: normal wmaker ought to be built with support for imagemagick via libmagickwand, to support more image types. Notably, this would permit wmaker to, for example, use the default debian theme images, which are only distributed in SVG form normally, which wmaker can't read without libmagickwand. -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-7-amd64 (SMP w/12 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) Versions of packages wmaker depends on: ii libc62.27-5 ii libfontconfig1 2.13.0-5 ii libfreetype6 2.6.3-3.2 ii libgif7 5.1.4-0.4 ii libjpeg62-turbo 1:1.5.1-2 ii libpng16-16 1.6.28-1 ii libtiff5 4.0.8-2+deb9u2 ii libwings30.95.7-8 ii libwraster5 0.95.7-8 ii libwutil50.95.7-8 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxinerama1 2:1.1.3-1+b3 ii libxpm4 1:3.5.12-1 ii wmaker-common0.95.7-8 wmaker recommends no packages. Versions of packages wmaker suggests: ii desktop-base9.0.2+deb9u1 ii lxterminal [x-terminal-emulator]0.3.0-2 ii menu2.1.47+b1 ii rxvt-unicode [x-terminal-emulator] 9.22-1+b1 ii wmaker-data 0.9~3-4 pn wmaker-utils ii x11-apps7.7+6+b1 ii xterm [x-terminal-emulator] 327-2 -- no debconf information
Bug#900375: hg-fast-export: Incompatible with mercurial 4.6
Package: hg-fast-export Version: 20140308-1 Severity: important The (old) version of hg-fast-export currently packaged is incompatible with mercurial 4.6. Support for this looks to be available upstream (https://github.com/frej/fast-export) on the hg-4.6-compat branch. There are also many other fixes & enhancements available upstream on the master branch. -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'testing'), (490, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-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) Versions of packages hg-fast-export depends on: ii git1:2.11.0-3+deb9u2 ii mercurial 4.6-2 ii python 2.7.13-2 hg-fast-export recommends no packages. hg-fast-export suggests no packages. -- no debconf information
Bug#895966: libvirt-daemon: Should suggest/recommend/depend systemd-container (redo #822581)
Package: libvirt-daemon Version: 3.0.0-4+deb9u3 Severity: normal This is a followup to #822581, which has been archived and thus I can't seem to reopen it, and direct mail to the maintainer also bounced (bad ipv6 config somewhere in the path it seems). After a long time of not being able to make sense of why I was having problems, and the maintainer not, I think I was able to track down the issue via some thinking and some UTSL. I think another detail of the issue is that the problem may only manifest on package upgrades, and that removing but not *purging* systemd-container might mask the issue as well. The mail I tried to send as a followup to #822581 follows: On Thu, 14 Sep 2017, Guido Günther wrote: > On Sun, Jul 31, 2016 at 08:21:22PM +0200, Guido Günther wrote: >> I just tried to reproduce with 2.1.0-rc1 and I can't reproduce this. Are >> you still seeing this with recent versions? If so please provide logs >> (the containers log and libvirtds log would be a start). > > Closing since things work here and there was no submitter feedback for > over a year. I'm not having exactly the same problem as before, but I am still seeing that systemd-container is needed for proper operation of libvirt for lxc guests. Without it I'm having problems with it tracking running guests across restarts. I'm finding that there end up with two copies of the guest running, but only one of them does libvirt know about. This causes all kinds of hyper-bizarro confusion within the guest -- there's two copies of systemd, of rsyslog, cron, etc., all working from the same system image. But the one systemd doesn't know about has lost its network connectivity, so I generally can't do much other than just kill it. I think a bit of UTSL has allowed me to track down the root of this problem and its connection to the systemd-container package. When the lxc driver starts up, it tries to reconnect to the running guests -- check the Reconnect methods in lxc_process.c, called initially from the lxcStateInitialize method in lxc_driver.c The Reconnect methods /seem/ to be at least partly dependent upon virSystemdGetMachineNameByPID (also in lxc_process.c), at least when running under systemd (which of course is the norm in Debian). That method is in turn dependent on the org.freedesktop.machine1 DBus service. And that service is only available if systemd-container is installed. Extra fun: the dbus service file is a conf file, so a normal apt remove systemd-container won't remove it, which seems like it could confuse testing this issue. -- -Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9 -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/12 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) Versions of packages libvirt-daemon depends on: ii libapparmor12.11.0-3+deb9u2 ii libaudit1 1:2.6.7-2 ii libavahi-client30.6.32-2 ii libavahi-common30.6.32-2 ii libblkid1 2.29.2-1+deb9u1 ii libc6 2.27-3 ii libcap-ng0 0.7.7-3+b1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdevmapper1.02.1 2:1.02.137-2 ii libfuse22.9.7-1 ii libgnutls30 3.5.8-5+deb9u3 ii libnetcf1 1:0.2.8-1+b2 ii libnl-3-200 3.2.27-2 ii libnl-route-3-200 3.2.27-2 ii libnuma12.0.11-2.1 ii libparted2 3.2-17 ii libpcap0.8 1.8.1-3 ii libpciaccess0 0.13.4-1+b2 ii librados2 10.2.5-7.2 ii librbd1 10.2.5-7.2 ii libsasl2-2 2.1.27~101-g0780600+dfsg-3 ii libselinux1 2.6-3+b3 ii libssh2-1 1.7.0-1 ii libudev1232-25+deb9u2 ii libvirt03.0.0-4+deb9u3 ii libxen-4.8 4.8.3+comet2+shim4.10.0+comet3-1+deb9u5 ii libxenstore3.0 4.8.3+comet2+shim4.10.0+comet3-1+deb9u5 ii libxml2 2.9.4+dfsg1-2.2+deb9u2 ii libyajl22.1.0-2+b3 Versions of packages libvirt-daemon recommends: ii libxml2-utils 2.9.4+dfsg1-2.2+deb9u2 ii netcat-openbsd 1.130-3 ii qemu1:2.8+dfsg-6+deb9u3 ii qemu-kvm1:2.8+dfsg-6+deb9u3 Versions of packages libvirt-daemon suggests: ii libvirt-daemon-system 3.0.0-4+deb9u3 pn numad -- no debconf information
Bug#881725: apache2: reload fails inside (libvirt) lxc container
On Sat, 14 Apr 2018, Stefan Fritsch wrote: This seems to be a systemd bug. Changing PrivateTmp from true to false in apache2.service fixes the issue. But even with PrivateTmp it works for some time. It would be interesting what is the trigger to make it fail later on. Hmm ... I was having a problem on some systems where tmpreaper, in its default configuration, will eventually delete all the directories systemd creates to support PrivateTmp, which might explain this... -- -Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#894308: tftpd-hpa: Init script kills daemons in lxc containers too
Package: tftpd-hpa Version: 5.2+20150808-1+b1 Severity: normal The init script for tftpd-hpa kills any instances running in lxc containers when stopping the service on the host machine. Example: Host: sudo service tftpd-hpa start Guest: sudo service tftpd-hpa start ## all running now Host: sudo service tftpd-hpa stop Guest: sudo service tftpd-hpa status ## no longer running in the guest, host init script killed it! -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-5-amd64 (SMP w/12 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) Versions of packages tftpd-hpa depends on: ii adduser3.115 ii debconf [debconf-2.0] 1.5.61 ii libc6 2.24-11+deb9u3 ii libwrap0 7.6.q-26 tftpd-hpa recommends no packages. Versions of packages tftpd-hpa suggests: ii pxelinux 3:6.03+dfsg-14.1+deb9u1 -- debconf information excluded
Bug#892302: libpam-systemd: Does not recgonize serial consoles as part of a seat
Thanks for the very fast reply :) On Thu, 8 Mar 2018, Michael Biebl wrote: Are you logging in via serial console as unprivileged user? Yes. If I'm root, that grants all access and the session/tty/etc. become irrelevant. But I want to run something as not-root under systemd-inhibit. Yes, I could sudo systemd-inhibit sudo -u ... but blech :) /etc/securetty (pam_securetty) is not really a good idea. Any thoughts why, other than that the default version of that file seems to have everything under the sun listed in it? That all said, you should really take this up with upstream at https://github.com/systemd/systemd/issues ACK, though systemd's official policy is basically "go away if you aren't running the bleeding edge". I can verify the problem code is in the git master of systemd, but their policy is to not accept bug reports from such "old" versions as Debian runs, and explicitly to redirect back to the linux distro for support. Nevertheless, filed https://github.com/systemd/systemd/issues/8582 -- -Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#891599: gdm3: Greeter doesn't allow control of network-manager connections even when member of netdev group
On Fri, 23 Mar 2018, Simon McVittie wrote: it would be unexpected for someone finding a machine with a locked GNOME session, logged in as a user with netdev privileges, to be able to reconfigure the network without first unlocking the session! I could make the same argument that it is unexpected that explicitly granting the greeter permission to activate network connections being ignored is unexpected :) Other display managers don't let you perform unauthenticated privileged actions from their greeter-equivalent either, and that isn't generally considered to be a bug. Actually I came to attempting to do this specifically because *they do*. Ubuntu's configuration of LightDM explicitly allows controlling existing network configurations. If you need to be connected to a VPN to be able to authenticate logins, configuring it to be saved as a system-wide connection that can be connected non-interactively might help. (I would not recommend this configuration, because inability to log in without first connecting to a VPN seems extremely fragile, but it's your system.) This scenario (network auth) is exactly why I want to be able to bring up a pre-defined network connection from the greeter. I don't think that LDAP-based login (or the winbind variant of it) is really that weird a thing... Saving the VPN password is not a viable option here, both for technical and policy reasons, nor is having it always auto-connect (that for technical reasons). For business/enterprise-y environments, the ability to configure connections to be avaible pre-login has been a long-standing feature for a lng time. This was old hat even back in the mid 90s. But history and such aside, it seems like the proper thing here would be to actually obey the policy kit restrictions. AFAICT policy kit supports the cases here -- don't want locked session of a user to have network control? Require the session to be active to grant permissions. Do want the greeter or a locked session to at least be able to turn network connections on or off, can do that too. -- -Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#891599: gdm3: Greeter doesn't allow control of network-manager connections even when member of netdev group
Package: gdm3
Version: 3.22.3-3+deb9u1
Followup-For: Bug #891599
This actually looks like it might be a bug in gnome-shell, and still present
in 3.28. This silly-looking(?) bit of logic is present there in
js/ui/status/network.js:
_sessionUpdated() {
let sensitive = !Main.sessionMode.isLocked &&
!Main.sessionMode.isGreeter;
this.menu.setSensitive(sensitive);
},
I.e. it looks like it's hard coding things to not allow interaction from the
greeter, no matter what permissions you might or might not have set.
Bug#892302: libpam-systemd: Does not recgonize serial consoles as part of a seat
Package: libpam-systemd Version: 232-25+deb9u1 Severity: normal Various policykit actions that flag as for "active" or even "inactive", but not "any", do not work from serial console sessions. After much pain, I'm fairly sure I've traced this down to libpam-systemd not marking serial logins as part of a seat. This causes policykit to decide that the session is not local, and thus its activity state is irrelevant for the allow_inactive / allow_active policykit grants. This seems to boil down, finally, to the get_seat_from_display function in pam_systemd.c. Granted, serial console sessions are not _always_ local, given that I guess modems still technically exist and you might have dialup sessions, but this basically means that policykit is half-broken on headless systems, and that breaks significant bits of systemd, such as systemd-inhibit, which is where I began this adventure. For headless systems, being able to identify serial consoles that _are_ local and thus should have a "seat" would be helpful. The contents of /etc/securetty seem like they would be a useful starting place here. -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'testing'), (490, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-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) Versions of packages libpam-systemd depends on: ii dbus1.10.24-0+deb9u1 ii libc6 2.26-6 ii libpam-runtime 1.1.8-3.6 ii libpam0g1.1.8-3.6 ii libselinux1 2.6-3+b3 ii systemd 232-25+deb9u1 ii systemd-sysv232-25+deb9u1 libpam-systemd recommends no packages. libpam-systemd suggests no packages. -- no debconf information
Bug#891599: gdm3: Greeter doesn't allow control of network-manager connections even when member of netdev group
Package: gdm3 Version: 3.22.3-3+deb9u1 Severity: normal Based on the policy-kit settings, I would expect that adding the Debian-gdm user to the netdev group (and restarting gdm3 or rebooting) to allow me to control network connections from the greeter (AKA login screen). For example, if a VPN needs to be connected first to authenticate logins (LDAP/AD). But this doesn't work. The greeter seems to always show the network connection information as read-only. -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'testing'), (490, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-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) Versions of packages gdm3 depends on: ii accountsservice 0.6.43-1 ii adduser 3.115 ii dconf-cli 0.26.0-2+b1 ii dconf-gsettings-backend 0.26.0-2+b1 ii debconf [debconf-2.0] 1.5.61 ii gir1.2-gdm-1.03.22.3-3+deb9u1 ii gnome-session [x-session-manager] 3.22.3-1 ii gnome-session-bin 3.22.3-1 ii gnome-settings-daemon 3.22.2-2+deb9u2 ii gnome-shell 3.22.3-3 ii gnome-terminal [x-terminal-emulator] 3.22.2-1 ii gsettings-desktop-schemas 3.22.0-1 ii libaccountsservice0 0.6.43-1 ii libaudit1 1:2.6.7-2 ii libc6 2.26-6 ii libcanberra-gtk3-00.30-3 ii libcanberra0 0.30-3 ii libgdk-pixbuf2.0-02.36.5-2+deb9u2 ii libgdm1 3.22.3-3+deb9u1 ii libglib2.0-0 2.50.3-2 ii libglib2.0-bin2.50.3-2 ii libgtk-3-03.22.11-1 ii libkeyutils1 1.5.9-9 ii libpam-modules1.1.8-3.6 ii libpam-runtime1.1.8-3.6 ii libpam-systemd232-25+deb9u1 ii libpam0g 1.1.8-3.6 ii librsvg2-common 2.40.16-1+b1 ii libselinux1 2.6-3+b3 ii libsystemd0 232-25+deb9u1 ii libwrap0 7.6.q-26 ii libx11-6 2:1.6.4-3 ii libxau6 1:1.0.8-1 ii libxcb1 1.12-1 ii libxdmcp6 1:1.1.2-3 ii lsb-base 9.20161125 ii lxterminal [x-terminal-emulator] 0.3.0-2 ii metacity [x-window-manager] 1:3.22.1-1 ii mutter [x-window-manager] 3.22.3-2 ii policykit-1 0.105-18 ii terminator [x-terminal-emulator] 1.90+bzr-1705-1 ii tilix [x-terminal-emulator] 1.7.1-2 ii ucf 3.0036 ii wmaker [x-window-manager] 0.95.7-8 ii x11-common1:7.7+19 ii x11-xserver-utils 7.7+7+b1 ii xfce4-terminal [x-terminal-emulator] 0.8.3-1 ii xterm [x-terminal-emulator] 327-2 Versions of packages gdm3 recommends: ii at-spi2-core2.22.0-6+deb9u1 ii desktop-base9.0.2+deb9u1 ii x11-xkb-utils 7.7+3+b1 pn xserver-xephyr ii xserver-xorg1:7.7+19 ii zenity 3.22.0-1+b1 Versions of packages gdm3 suggests: pn gnome-orca ii libpam-gnome-keyring 3.20.0-3 -- Configuration Files: /etc/gdm3/Init/Default changed [not included] -- debconf information: * shared/default-x-display-manager: gdm3 gdm3/daemon_name: /usr/sbin/gdm3
Bug#809415: checkinstall logic to identify conffiles is broken
Package: checkinstall Version: 1.6.2-4 Followup-For: Bug #809415 whitespace problems from the original reporter not-withstanding, this bug is still present and annoying and trivial to fix. It also might be better titled "checkinstall logic to identify conffiles is broken" In this: === # Tag files in /etc to be conffiles find -L $BUILD_DIR/etc -type f 2> /dev/null | sed -e "s,$BUILD_DIR,," | \ > $BUILD_DIR/DEBIAN/conffiles === Remove the trailing "|" pipe from the middle line. The syntax as present currently will /always/ cause the conffile list to be empty, no matter /what/ the output of the find... bit is. Also this is a dupe of #781169 -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'testing'), (490, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-5-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) Versions of packages checkinstall depends on: ii dpkg-dev 1.18.24 ii file 1:5.30-1+deb9u1 ii libc6 2.26-6 Versions of packages checkinstall recommends: ii make 4.1-9.1 Versions of packages checkinstall suggests: ii gettext 0.19.8.1-2 -- no debconf information
Bug#826717: Fixed recently
fixed 826717 58.0-1 thanks In one of the recent (compared to the age of this bug) Firefox updates, this bug went away and native notifications in Gnome now work properly for me. -- -Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#888396: firefox: Shouldn't suggest mozplugger any more
Package: firefox Version: 58.0-1 Severity: minor I don't think Firefox should be suggesting mozplugger any more -- AFAICT mozplugger provides an NPAPI plugin, and since non-ESR builds of Firefox 52, and 53 generally, such plugins are no longer supported. So, while mozplugger is still available, installing it won't do anything useful in Firefox. -- Package-specific info: -- Addons package information -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'testing'), (490, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-5-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) Versions of packages firefox depends on: ii debianutils 4.8.1.1 ii fontconfig2.11.0-6.7+b1 ii libatk1.0-0 2.22.0-1 ii libc6 2.26-4 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.24-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-6 ii libfontconfig12.12.6-0.1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18 ii libgdk-pixbuf2.0-02.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-03.22.11-1 ii libgtk2.0-0 2.24.31-2 ii libhunspell-1.6-0 1.6.2-1 ii libjsoncpp1 1.7.4-3 ii libnspr4 2:4.12-6 ii libnss3 2:3.34.1-1 ii libpango-1.0-01.40.5-1 ii libsqlite3-0 3.16.2-5+deb9u1 ii libstartup-notification0 0.12-4+b2 ii libstdc++66.3.0-18 ii libvpx4 1.6.1-3 ii libx11-6 2:1.6.4-3 ii libx11-xcb1 2:1.6.4-3 ii libxcb-shm0 1.12-1 ii libxcb1 1.12-1 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-2+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii procps2:3.3.12-3 ii zlib1g1:1.2.8.dfsg-5 firefox recommends no packages. Versions of packages firefox suggests: ii fonts-lmodern 2.004.5-3 ii fonts-stix [otf-stix] 1.1.1-4 ii libcanberra0 0.30-3 ii libgssapi-krb5-2 1.15-1+deb9u1 pn mozplugger -- no debconf information
Bug#881725: apache2: reload fails inside (libvirt) lxc container
On Mon, 25 Dec 2017, Stefan Fritsch wrote: Hi Matthew, I don't know libvirt lxc containers at all, but ... On Tue, 14 Nov 2017, Matthew Gabeler-Lee wrote: Nov 14 14:38:33 hostname systemd[1]: Reloading The Apache HTTP Server. Nov 14 14:38:33 hostname systemd[11798]: apache2.service: Failed at step NAMESPACE spawning /usr/sbin/apachectl: No such file or directory this seems to say that /usr/sbin/apachectl is missing in your container. I guess this is a configuration problem in your container config. I don't think there is anything that can be done from the apache side. I'm pretty sure that's actually _not_ what it's saying, or at least it's an overly literal interpretation. For one, the container is a full debian OS container. If apachectl wasn't there, apache would never _start_, much less fail to _restart_. Second, when looking into the code, the "Failed at step NAMESPACE" is, I think, the crux of the issue. It's failing at a step related to setting up the namespaces to run apachectl, not finding the binary. Either way, apachectl is very definitely in the container. -- -Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#884719: mdadm-grow-continue service doesn't work if --backup-file is specified
Package: mdadm Version: 3.4-4+b1 Severity: normal Trying to use mdadm to grow a raid5 array from 2 to 4 devices, I started it with the --backup-file argument to ensure integrity. This seems to have caused mdadm-grow-continue@...service to have failed: ● mdadm-grow-continue@md123.service - Manage MD Reshape on /dev/md123 Loaded: loaded (/lib/systemd/system/mdadm-grow-continue@.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Sun 2017-12-17 16:20:11 EST; 19h ago Main PID: 10875 (code=exited, status=2) Dec 17 16:20:10 hostname.fqdn systemd[1]: Started Manage MD Reshape on /dev/md123. Dec 17 16:20:11 hostname.fqdn systemd[1]: mdadm-grow-continue@md123.service: Main process exited, code=exited, status=2/INVALIDARGUMENT Dec 17 16:20:11 hostname.fqdn systemd[1]: mdadm-grow-continue@md123.service: Unit entered failed state. Dec 17 16:20:11 hostname.fqdn systemd[1]: mdadm-grow-continue@md123.service: Failed with result 'exit-code'. And the grow seemed to freeze at having reshaped a single block. Manually running mdadm --grow --continue /dev/md123 --backup-file ... got things running again. -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-amd64 (SMP w/12 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) Versions of packages mdadm depends on: ii debconf [debconf-2.0] 1.5.61 ii libc6 2.24-11+deb9u1 ii lsb-base 9.20161125 ii udev 232-25+deb9u1 Versions of packages mdadm recommends: ii exim4-daemon-light [mail-transport-agent] 4.89-2+deb9u2 ii kmod 23-2 mdadm suggests no packages. -- Configuration Files: /etc/cron.daily/mdadm changed [not included] -- debconf information excluded -- debsums errors found: debsums: changed file /lib/systemd/system/mdmonitor.service (from mdadm package)
Bug#884367: [pkg-gnupg-maint] Bug#884367: gnupg2: Please bring skel files back as documentation/examples
On Thu, 14 Dec 2017, Daniel Kahn Gillmor wrote: iirc, upstream has completely dropped the skeleton files completely from their source The current debian package in stable still has the patch to remove the files so they are there in that version. But I just checked the package in /testing and indeed upstream has removed those files there. I guess that renders most of my wishlist item here moot :/ I'm not convinced that adding our own example skeleton file to usr/share/doc/gpg/examples is worth deviating from upstream. Agreed, given upstream has removed the examples, having Debian ship its doesn't make sense. can you give me an example of what you'd like to see in such a skeleton file? My ideal config file is the empty file :) My case was looking for essentially documentation on the recommendations for some parameters that I think default to empty. In particular I was having trouble with keys.gnupg.net and was wondering if there was a newer recommended server to use, hoping to find that in an updated copy of that sample file. -- -Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#884367: gnupg2: Please bring skel files back as documentation/examples
Package: gnupg2 Version: 2.1.18-8~deb9u1 Severity: wishlist While the rationale listed in 0077-g10-remove-skeleton-options-files.patch for not having gnupg write the default config files to the user home directory is sound, removing the sample files from the distribution entirely is not so good. This seems to be what /usr/share/doc/_package_/examples/ is for. It would be nice/helpful to have these skel files available there for reference, and that would avoid the "documentation that's always out of date" problem, as now they would be properly placed as documentation, and be kept up to date. -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'testing'), (490, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-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) Versions of packages gnupg2 depends on: ii gnupg 2.1.18-8~deb9u1 gnupg2 recommends no packages. gnupg2 suggests no packages. -- no debconf information
Bug#884114: nvidia-support: rmmod instructions are out of date
Package: nvidia-support Version: 20151021+4 Severity: minor The instructions for how to correct a mismatched nvidia kernel module are out of date. Running "rmmod nvidia" is no longer sufficient, it seems that you need to now do "rmmod nvidia_drm nvidia_modeset nvidia". -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-amd64 (SMP w/12 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) Versions of packages nvidia-support depends on: ii debconf [debconf-2.0] 1.5.61 nvidia-support recommends no packages. nvidia-support suggests no packages. -- debconf information excluded
Bug#861262: sphinxsearch needs systemd unit file
Looking at http://sphinxsearch.com/bugs/view.php?id=2321 and the 2.2.11 vs. 2.2.10 upstream source releases, or the upstream git repo, I can't find any signs that a systemd unit file was actually added to the tree at all. Nor does upstream ticket 2321 appear in the changelog for 2.2.11. Seems someone upstream maybe forgot to actually commit/push the fix? And for that matter, the sysvinit script debian ships is not really related to upstream's one in contrib.
Bug#881725: apache2: reload fails inside (libvirt) lxc container
Package: apache2 Version: 2.4.25-3+deb9u3 Severity: normal When running inside a libvirt-managed lxc os container, the reload command on the systemd unit fails always: Nov 14 14:38:33 hostname systemd[1]: Reloading The Apache HTTP Server. Nov 14 14:38:33 hostname systemd[11798]: apache2.service: Failed at step NAMESPACE spawning /usr/sbin/apachectl: No such file or directory Nov 14 14:38:33 hostname systemd[1]: apache2.service: Control process exited, code=exited status=226 Nov 14 14:38:33 hostname systemd[1]: Reload failed for The Apache HTTP Server. Restart works normally. This mostly crops up for me via the logrotate script. -- Package-specific info: -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/12 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) Versions of packages apache2 depends on: ii apache2-bin 2.4.25-3+deb9u3 ii apache2-data 2.4.25-3+deb9u3 ii apache2-utils2.4.25-3+deb9u3 ii dpkg 1.18.24 ii init-system-helpers 1.48 ii lsb-base 9.20161125 ii mime-support 3.60 ii perl 5.24.1-3+deb9u2 ii procps 2:3.3.12-3 Versions of packages apache2 recommends: ii ssl-cert 1.0.39 Versions of packages apache2 suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom pn www-browser Versions of packages apache2-bin depends on: ii libapr1 1.5.2-5 ii libaprutil1 1.5.4-3 ii libaprutil1-dbd-sqlite3 1.5.4-3 ii libaprutil1-ldap 1.5.4-3 ii libc62.24-11+deb9u1 ii libldap-2.4-22.4.44+dfsg-5+deb9u1 ii liblua5.2-0 5.2.4-1.1+b2 ii libnghttp2-141.18.1-1 ii libpcre3 2:8.39-3 ii libssl1.0.2 1.0.2l-2+deb9u1 ii libxml2 2.9.4+dfsg1-2.2+deb9u1 ii perl 5.24.1-3+deb9u2 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages apache2-bin suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom pn www-browser Versions of packages apache2 is related to: ii apache2 2.4.25-3+deb9u3 ii apache2-bin 2.4.25-3+deb9u3 -- no debconf information
Bug#881100: [Pkg-samba-maint] Bug#881100: libnss-winbind is not multiarch safe
On Fri, 10 Nov 2017, Mathieu Parent wrote: This looks similar to #647430 which was solved in 2:4.6.5+dfsg-6. Can you test from sid? While that is likely a necessary component to fixing this, it is not sufficient. That fixes a script error, this ticket is about package dependency errors between the various binary packages from the Samba source package. Trying to install both "PC" architectures of libnss-winbind produces this error when targeting sid (which is basically the same as when targeting stable or buster, just different package versions referenced): The following packages have unmet dependencies: libnss-winbind : Depends: samba-libs (= 2:4.7.1+dfsg-1) but it is not going to be installed Depends: winbind (= 2:4.7.1+dfsg-1) but it is not going to be installed libnss-winbind:i386 : Depends: samba-libs:i386 (= 2:4.7.1+dfsg-1) but it is not going to be installed Depends: winbind:i386 (= 2:4.7.1+dfsg-1) but it is not going to be installed You can't co-install multiple architectures of the winbind daemon, of course. I'm not an expert on Debian packaging, but I believe that could be solved by changing the dependency there to be "arch any", since it just needs to have the daemon be installed to communicate with it, not necessarily have the daemon of the same architecture be running. Though I don't know if the local socket/pipe protocol it uses is maybe architecture-specific (e.g. binary packed stuff that is dependent on the cpu arch), so there might still be problems there. The samba-libs problem seems to be related to samba-libs depending on python-talloc, which is #862338. As I noted before I'm not sure libnss-winbind actually needs to depend on samba-libs at all, though I'm not really sure of that. Running strings on the shared libs shipped in libnss-winbind doesn't find anything that looks like it's trying to dlopen libraries from samba-libs, nor does it link against them directly. -- -Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#881100: libnss-winbind is not multiarch safe
Package: libnss-winbind Version: 2:4.5.12+dfsg-2 Severity: normal Background: I use libnss-winbind, and a mulitiarch amd64/i386 system because I need to run some third party i386 binaries. At least one of those binaries needs to be able to do nss lookups for some basic account information. Trying to install libnss-winbind:i386 fails because: 1) It depends on the i386 version of the main winbind package. This seems wrong-ish? It just needs _some_ version of winbind installed so it can talk to it over the socket. 2) It depends on samba-libs, which fails multiarch because of at least #862338, though it's not immediately obvious to me _why_ it depends on samba-libs if the nss lib is just a thin shim to talk to other daemons? If it's dlopening stuff from that, though, it'd make sense. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'testing'), (490, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-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) Versions of packages libnss-winbind depends on: ii dpkg 1.18.24 ii libbsd0 0.8.3-1 ii libc6 2.24-11+deb9u1 ii libwbclient0 2:4.5.12+dfsg-2 ii samba-common 2:4.5.12+dfsg-2 ii samba-libs2:4.5.12+dfsg-2 ii winbind 2:4.5.12+dfsg-2 libnss-winbind recommends no packages. Versions of packages libnss-winbind suggests: ii libpam-winbind 2:4.5.12+dfsg-2 -- no debconf information
Bug#881098: moreutils: pee should have an unbuffered or line-buffered mode
Package: moreutils Version: 0.60-1 Severity: wishlist Using pee to work with something generating output but also going through more processing before heading to a logfile gets icky, because pee always has the pipes it uses to talk to the child processes buffered. e.g. output-generating-thing | pee "cat" "ts >logfile" results in the terminal output being batched due to the output buffer in pee for the pipe to cat, no matter how many places one adds stdbuf invocations. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'testing'), (490, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-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) Versions of packages moreutils depends on: ii libc62.24-11+deb9u1 ii libipc-run-perl 0.94-1 ii perl 5.24.1-3+deb9u2 moreutils recommends no packages. Versions of packages moreutils suggests: pn libtime-duration-perl ii libtimedate-perl 2.3000-2 -- no debconf information
Bug#880531: libvncclient1: Can't connect to VMware
Package: libvncclient1 Version: 0.9.11+dfsg-1 Severity: normal Tags: upstream libvncclient has a bug with how it expresses the truecolor pixel format which causes an error talking to VMware servers. This looks to have been fixed upstream, so just need to import this fix or package a new upstream version: https://github.com/LibVNC/libvncserver/pull/170 https://github.com/LibVNC/libvncserver/issues/141 -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'testing'), (490, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-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) Versions of packages libvncclient1 depends on: ii libc62.24-11+deb9u1 ii libgcrypt20 1.7.6-2+deb9u2 ii libgnutls30 3.5.8-5+deb9u3 ii libjpeg62-turbo 1:1.5.1-2 ii zlib1g 1:1.2.8.dfsg-5 libvncclient1 recommends no packages. libvncclient1 suggests no packages. -- no debconf information
