Bug#1071456: autopkgtest-virt-qemu: autopkgtest [15:14:50]: ERROR: testbed failure: sent `auxverb_debug_fail', got `timeout', expected `ok...'
Package: autopkgtest Version: 5.35 Severity: normal I ran > sudo autopkgtest-build-qemu --architecture amd64 sid > /opt/chroots/autopkgtest-qemu.img followed by > autopkgtest . --test-name=initrd-boot -- qemu > /opt/chroots/autopkgtest-qemu.img in a directory that is a checkout of https://salsa.debian.org/wouter/nbd.git It installed the test dependencies, and then failed on: > autopkgtest [16:55:00]: Setting up user "user" to sudo without password... > qemu-system-x86_64: terminating on signal 15 from pid 150414 > (/usr/bin/python3) > autopkgtest [17:00:02]: ERROR: testbed failure: sent `auxverb_debug_fail', > got `timeout', expected `ok...' which I did not expect... -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages autopkgtest depends on: ii apt-utils 2.9.3 ii libdpkg-perl1.22.6 ii mawk1.3.4.20240123-1 ii procps 2:4.0.4-4 ii python3 3.11.8-1 ii python3-debian 0.1.49 Versions of packages autopkgtest recommends: ii autodep8 0.28 ii fakeroot 1.34-1 Versions of packages autopkgtest suggests: ii docker.io20.10.25+dfsg1-3 pn fakemachine ii genisoimage 9:1.1.11-3.5 pn incus ii lxc 1:6.0.0a-1 pn lxd ii ovmf 2024.02-2 pn ovmf-ia32 pn podman ii python3-distro-info 1.7 ii qemu-efi-aarch64 2024.02-2 ii qemu-efi-arm 2024.02-2 pn qemu-efi-riscv64 ii qemu-system 1:8.2.3+ds-2+b1 ii qemu-utils 1:8.2.3+ds-2+b1 ii schroot 1.6.13-3+b3 ii util-linux 2.40.1-1 ii vmdb20.40-1 ii zerofree 1.1.1-1+b1 -- no debconf information
Bug#1067491: time_t transition upgrade: failed systemctl call in preinst due to missing pre-dependencies
Package: mariadb-server Version: 1:10.11.7-3 Severity: serious I did a 2G "apt dist-upgrade" to get my way through the time_t transition. This failed halfway through with the following messages: Uitpakken van .../10-mariadb-server_1%3a10.11.7-3_amd64.deb wordt voorbereid... systemctl: error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory dpkg: waarschuwing: subproces van het verouderd pakket mariadb-server het script pre-removal gaf de foutwaarde 127 terug dpkg: script uit het nieuwe pakket wordt geprobeerd als alternatief... systemctl: error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory dpkg: fout bij verwerken van archief /tmp/apt-dpkg-install-IuQoIO/10-mariadb-server_1%3a10.11.7-3_amd64.deb (--unpack): subproces van het nieuwe pakket mariadb-server het script pre-removal gaf de foutwaarde 127 terug Here, the Dutch terms translate (approximately) to: "Unpacking .../10-mariadb-..." dpkg: warning: subproces of the old package mariadb-server pre-removal script return error value 127 dpkg: trying script from the new package as alternative... i.e., the prerm script tries to call systemctl, which fails because libcrypto.so.3 is not on the filesystem. The new package's prerm script tries the same, which fails for the same reason. Checking dpkg.log, I see: 2024-03-22 12:12:24 remove libssl3:i386 3.1.5-1 2024-03-22 12:12:24 status half-configured libssl3:i386 3.1.5-1 2024-03-22 12:12:24 status half-installed libssl3:i386 3.1.5-1 2024-03-22 12:12:24 status config-files libssl3:i386 3.1.5-1 2024-03-22 12:12:24 status not-installed libssl3:i386 2024-03-22 12:12:24 remove libssl3:amd64 3.1.5-1 2024-03-22 12:12:24 status half-configured libssl3:amd64 3.1.5-1 2024-03-22 12:12:24 status half-installed libssl3:amd64 3.1.5-1 2024-03-22 12:12:24 status config-files libssl3:amd64 3.1.5-1 2024-03-22 12:12:24 status not-installed libssl3:amd64 2024-03-22 12:12:24 startup archives unpack 2024-03-22 12:12:25 install libssl3t64:i386 3.1.5-1.1 2024-03-22 12:12:25 status half-installed libssl3t64:i386 3.1.5-1.1 2024-03-22 12:12:25 status unpacked libssl3t64:i386 3.1.5-1.1 [...] 2024-03-22 12:18:20 upgrade mariadb-server:amd64 1:10.11.7-1 1:10.11.7-3 2024-03-22 12:18:20 status half-configured mariadb-server:amd64 1:10.11.7-1 2024-03-22 12:18:20 status installed mariadb-server:amd64 1:10.11.7-1 2024-03-22 12:18:20 upgrade mariadb-server-core:amd64 1:10.11.7-1 1:10.11.7-3 2024-03-22 12:18:20 status half-configured mariadb-server-core:amd64 1:10.11.7-1 2024-03-22 12:18:20 status unpacked mariadb-server-core:amd64 1:10.11.7-1 2024-03-22 12:18:20 status half-installed mariadb-server-core:amd64 1:10.11.7-1 2024-03-22 12:18:21 status unpacked mariadb-server-core:amd64 1:10.11.7-3 Full dpkg.log of this run attached. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mariadb-server depends on: ii adduser3.137 ii debconf [debconf-2.0] 1.5.86 ii galera-4 26.4.16-2+b1 ii gawk 1:5.2.1-2 ii init-system-helpers1.66 ii iproute2 6.8.0-1 ii libc6 2.37-15.1 ii libdbi-perl1.643-4+b1 ii libpam0g 1.5.3-6 ii libssl3t64 3.1.5-1.1 ii libstdc++6 14-20240315-1 ii lsof 4.95.0-1 ii mariadb-client 1:10.11.7-3 ii mariadb-common 1:10.11.7-3 ii mariadb-server-core1:10.11.7-3 ii passwd 1:4.13+dfsg1-4 ii perl 5.38.2-3.2 ii procps 2:4.0.4-4 ii psmisc 23.7-1 ii rsync 3.2.7-1+b1 ii socat 1.8.0.0-4 ii zlib1g 1:1.3.dfsg-3.1 Versions of packages mariadb-server recommends: ii libhtml-template-perl 2.97-2 ii mariadb-plugin-provider-bzip2 1:10.11.7-3 ii mariadb-plugin-provider-lz4 1:10.11.7-3 ii mariadb-plugin-provider-lzma1:10.11.7-3 ii mariadb-plugin-provider-lzo 1:10.11.7-3 ii mariadb-plugin-provider-snappy 1:10.11.7-3 ii pv 1.8.5-2 Versions of packages mariadb-server suggests: ii bsd-mailx [mailx] 8.1.2-0.20220412cvs-1 ii mailutils [mailx] 1:3.17-1.1+b1 pn mariadb-test ii netcat-openbsd 1.226-1 -- debconf information excluded dpkg.log.gz Description: application/gzip
Bug#1066842: Updating extrepo-offline-data in Debian Stable
Package: release.debian.org
Control: affects -1 + src:extrepo-data
User: release.debian@packages.debian.org
Usertags: pu
Tags: bookworm
Severity: normal
Subject: bookworm-pu: package extrepo-data/1.0.5
thanks
[making this an official stable update request; for the full backstory,
please see the thread starting at
https://lists.debian.org/debian-release/2024/03/msg00076.html]]
On Thu, Mar 07, 2024 at 07:10:28PM +0100, Thomas Goirand wrote:
> On 3/7/24 06:57, Paul Gevers wrote:
> > Having said that and not knowing if it doesn't already do that, if
> > extrepro would update a cache when online, it's offline option could
> > also be refreshed at a convenience moment without the need for an
> > up-to-date package in stable. I hope it's needless to say that I don't
> > mean that this mechanisme should replace the data package, merely
> > complement it.
>
> It's actually a very good idea to have such cache. Though as you wrote, it
> doesn't replace the data package, especially when one wants to use local
> mirror, with something like this:
>
> apt-get install extrepo extrepo-offline-data
> extrepo enable --offlinedata --mirror http://mirror.example.com/haproxy
To give a bit more background here:
extrepo was originally designed to use an online, GPG-signed, metadata
repository. When you run an extrepo command and it needs to, extrepo
will download the metadata index and the signature on that, and then
verify that the signature is correct. All further information that it
needs is hashed with a cryptographically secure hash, and so can be
assumed to be safe.
extrepo provides two things: a (checked and vetted) URI for a repository
of external packages, and a (checked and vetted) GPG key that can sign
packages in that repository.
Accessing the metadata repository in the way described above however
requires direct access to that metadata repository, which is complicated
for air-gapped systems. While the location of that repository is
configurable, and in theory it is possible to write a tool which will
download the metadata plus all signatures plus all external files that
exist, that seems like quite a bit of work, and Thomas therefore
suggested an alternate solution whereby the extrepo metadata is also
packaged in Debian. Doing so only requires a person to mirror the
repository that they want to enable, and to override the mirror URL by
way of the --mirror option passed to extrepo. This way, extrepo will
enable the repository on the given mirror, and will ensure that the
relevant GPG key for the repository in question is provided to apt,
which can still save the user some work of having to manually download
and verify the GPG key.
The downside here however, is that most repositories are updated to add
support for a particular Debian release only after that Debian release
has been promoted to stable. This unfortunately reduces the usability of
the extrepo-offline-data package, which could be remedied by updating
the package in stable.
The extrepo-offline-data package, as the name implies, is a data-only
package. Apart from the changelog and copyright in /usr/share/doc, it
only contains metadata files under /usr/share/extrepo/offline-data.
Thanks for your consideration,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1020648: extrepo-data: reproducible builds: "testing" suite resolves differently depending on build date
Hi Vagrant,
On Sat, 08 Apr 2023 20:23:29 -0700, Vagrant Cascadian wrote:
> On 2023-04-08, Wouter Verhelst wrote:
> > This behavior is on purpose. The build system is used for the one on
> > salsa too, and there we *want* the name "testing" (as well as the name
> > "stable") to resolve to "whatever is current".
> >
> > The build is reused for the package, because we want to make 100% sure
> > that the contents of the package (at the time of the package build, at
> > least) is the same as what would be served on the website.
>
> This is probably because I am not understanding something, but how would
> you perform a security update or update for a stable point release?
The package contains metadata for external repositories. If the package
is updated, it is a good thing that the metadata is made more recent; it
makes no sense to provide metadata for repositories that are no longer
accessible.
I have not yet considered whether we want to provide common updates to
stable. Perhaps I should talk to the SRMs about that...
At any rate, the purpose of this package is to provide an alternative to
the online version of the same data that can be downloaded through a
pages.debian.net URL. Thus it should be as similar as possible to that
one.
> The package ends up shipping entirely different repository information
> based on when you happen to build the package.
Which in the context of extrepo-data is a feature, not a bug.
> In the case of the tests.reproducible-builds.org, we are building a
> little over a year in the future, and I guess DistroInfo is
> hard-coding when it expects future distributions to become testing?
Possibly, I don't know what the reasoning behind all that is :)
> > Looking at the source of Debian::DistroInfo, there does not currently
> > appear to be a way to ask for information at a given date, but that
> > sounds like a reasonable wishlist for Debian::DistroInfo to provide.
> >
> > Once that's available, updating extrpo-offline-data to use that to build
> > on a source epoch in the past seems like a reasonable course of action
> > to fix this bug.
>
> Yes, this sounds like that a better way to fix the issue overall!
Indeed.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1062821: ola: NMU diff for 64-bit time_t transition
On Wed, Feb 07, 2024 at 09:47:10AM +0200, Wouter Verhelst wrote:
> Hi Lucas,
>
> On Sat, Feb 03, 2024 at 02:39:49PM -0300, Lucas Kanashiro wrote:
> > Source: ola
> > Version: 0.10.9.nojsmin-4
> > Severity: serious
> > Tags: patch pending sid trixie
> > Justification: library ABI skew on upgrade
> > User: debian-...@lists.debian.org
> > Usertags: time-t
> >
> > NOTICE: these changes must not be uploaded to unstable yet!
> >
> > Dear maintainer,
> >
> > As part of the 64-bit time_t transition required to support 32-bit
> > architectures in 2038 and beyond
> > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> > ola as a source package shipping runtime libraries whose ABI
> > either is affected by the change in size of time_t, or could not be
> > analyzed via abi-compliance-checker (and therefore to be on the safe
> > side we assume is affected).
>
> Would it make sense for me to contact upstream and ask if they do
> certain things? They're quite knowledgeable and might know.
>
> If not, then no worries, but I thought I'd ask.
nvm, just read the d-d-a mail :-)
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1062821: ola: NMU diff for 64-bit time_t transition
Hi Lucas,
On Sat, Feb 03, 2024 at 02:39:49PM -0300, Lucas Kanashiro wrote:
> Source: ola
> Version: 0.10.9.nojsmin-4
> Severity: serious
> Tags: patch pending sid trixie
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
>
> NOTICE: these changes must not be uploaded to unstable yet!
>
> Dear maintainer,
>
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> ola as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
Would it make sense for me to contact upstream and ask if they do
certain things? They're quite knowledgeable and might know.
If not, then no worries, but I thought I'd ask.
Thanks,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1014616: extrepo update fails with "uninitialized value" error
Version: 0.11
Hi Adam,
Thanks for your report.
The run function in Update.pm has been removed and merged into Enable.pm
since extrepo 0.10, which means that this bug should be resolved now.
However, I forgot to close the bug report at the time.
Doing so now.
Thanks,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1011558: Not going to do this
Control: severity -1 wishlist Control: tags -1 wontfix Thanks The problem with this is that the config file ships statically, and detecting which distribution you're running is actually quite complicated due to the fact that people may have multiple distributions enabled but then use various intricate apt pinning configurations to decide which distribution to prefer, if any. The current situation is that we default to the code name of whatever distribution the extrepo package is in (except in unstable, because the package does not change when migrating to testing), which seems like the best possibility here, given the existing constraints. I did want to give this some thought, but I don't see a way to make this work, and if you're using unstable and would prefer that, then having to edit a config file is not too hard. -- Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.
Bug#1060149: src:extrepo: fails to migrate to testing for too long: autopkgtest regression
On Sun, Jan 07, 2024 at 08:19:40AM +0100, Paul Gevers wrote:
> Hi Wouter,
>
> On 06-01-2024 20:51, Wouter Verhelst wrote:
> > > The Release Team considers packages that are out-of-sync between testing
> > > and
> > > unstable for more than 30 days as having a Release Critical bug in testing
> > > [1]. Your package src:extrepo has been trying to migrate for 33 days [2].
> >
> > This should have been fixed with the recent upload of extrepo-offline-data?
>
> Doesn't that mean that there is a versioned relation or a Breaks needed
> somewhere?
Not really. The issue is that the old version of extrepo-offline-data
did not have the "debian_official" repository for trixie yet, and the
test tries to use that; and as of extrepo 0.12, the default is to enable
trixie, not bookworm.
Things work as expected, even with extrepo-offline-data, it's just that
the test suite expects a repository to be there which is not there
(yet).
I don't think that's worthy of a Breaks relationship, but it is an
oversight on my side.
To muddle the waters a bit more, I also uploaded extrepo 0.13 now, which
adds a few features, but the test is now failing because it got
entangled in the perl migration... I guess things will have to wait.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1060149: src:extrepo: fails to migrate to testing for too long: autopkgtest regression
Hi Paul,
On Sat, Jan 06, 2024 at 01:58:53PM +0100, Paul Gevers wrote:
> Source: extrepo
> Version: 0.11
> Severity: serious
> Control: close -1 0.12
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
>
> Dear maintainer(s),
>
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:extrepo has been trying to migrate for 33 days [2].
This should have been fixed with the recent upload of extrepo-offline-data?
If that didn't happen yet, can you try to trigger another autopkgtest run?
Thanks,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1059397: extrepo: please consider fish and zsh autocompletion for subcommands like "search" and "enable"
Hi Carl,
On Sun, Dec 24, 2023 at 03:35:26PM +0100, Carl Johnson wrote:
> Package: extrepo
> Version: 0.12
> Severity: wishlist
> X-Debbugs-Cc: kni9p...@anonaddy.me
>
> Dear Maintainer,
>
> please consider adding fish and zsh autocompletion for subcommands like
> "search" and "enable" as this would greatly improve user experience.
I'm happy to ship something like that, but do not have the necessary
experience in writing any of that. Patches welcome! ;-)
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1053106: ACK
Yes please, would be great to make this happen.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1050214: network-manager-openconnect-gnome: Hangs after upgrade to 1.2.10-1
Package: network-manager-openconnect-gnome Version: 1.2.10-1 Severity: important Hi, I don't use gnome; I use awesome with a freedesktop.org-compatible system tray in which I run nm-applet. This seems to work fine. When I use network-manager-openconnect and -gnome from stable, I can connect to the VPN at $DAYJOB (a Cisco AnyConnect VPN). However, after upgrading to the version in unstable, I can't. When I try using the version in unstable, the Openconnect dialog appears and seems to do its thing. The VPN is set up to request a second factor out of band (through my cell phone), and that happens. Once I approve the log in, however, the nm-applet hangs; the UI freezes and clicking on it does not make the menu appear. At this point, the following lines appear on the stdout of nm-applet: ** (nm-openconnect-auth-dialog:9269): CRITICAL **: 09:24:25.757: process_stdin: assertion 'status == G_IO_STATUS_NORMAL' failed ** (nm-openconnect-auth-dialog:9274): CRITICAL **: 09:24:25.896: process_stdin: assertion 'status == G_IO_STATUS_NORMAL' failed Downloading: cscan rm: kan '/home/wouter/.cisco/hostscan/bin/cscan.tmp' niet verwijderen: Bestand of map bestaat niet Failure on cscan, trying gz Downloading: libcsd.so rm: kan '/home/wouter/.cisco/hostscan/lib/libcsd.so.tmp' niet verwijderen: Bestand of map bestaat niet Failure on libcsd.so, trying gz Downloading: libhostscan.so rm: kan '/home/wouter/.cisco/hostscan/lib/libhostscan.so.tmp' niet verwijderen: Bestand of map bestaat niet Failure on libhostscan.so, trying gz Downloading: libwaapi.so rm: kan '/home/wouter/.cisco/hostscan/lib/libwaapi.so.tmp' niet verwijderen: Bestand of map bestaat niet Failure on libwaapi.so, trying gz Launching: /home/wouter/.cisco/hostscan/bin/cstub -log error -ticket "491663C95A2787D05D0C2B93" -stub "0" -group "" -host "https://217.111.249.109/CACHE; -certhash "C888C20D189D2799C6EF227330448FC0:" whereas the NetworkManager journal gets the following log entries: aug 22 09:24:25 pc220518 NetworkManager[8855]: [1692689065.6091] vpn[0x559caf3b7820,fb276fb6-f660-4a5f-99f8-f7173bb1fe33,""]: starting openconnect aug 22 09:24:25 pc220518 NetworkManager[8855]: [1692689065.6097] audit: op="connection-activate" uuid="fb276fb6-f660-4a5f-99f8-f7173bb1fe33" name="" pid=9115 uid=1000 result="success" at which point everything hangs. Restarting the NetworkManager systemd unit additionally adds this to the journal: aug 22 09:26:24 pc220518 NetworkManager[8855]: [1692689184.9734] vpn[0x559caf3b7820,fb276fb6-f660-4a5f-99f8-f7173bb1fe33,"Zetes PASS AnyConnect"]: secrets: failed to request VPN secrets #3: No agents were available for this request. aug 22 09:26:27 pc220518 NetworkManager[8855]: [1692689187.7615] agent-manager: agent[1659a8c6bdb6724e,:1.115/org.freedesktop.nm-applet/1000]: agent registered aug 22 09:27:13 pc220518 NetworkManager[8855]: [1692689233.7565] agent-manager: agent[0efbfa6130ae5284,:1.122/org.freedesktop.nm-applet/1000]: agent registered (it may be that the latter two only appeared after restarting nm-applet; I'm not sure now) If any further information is necessary to help me debug this, please let me know. Thanks, -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.4.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager-openconnect-gnome depends on: ii libc62.37-7 ii libgcr-base-3-1 3.41.1-3 ii libgcr-ui-3-13.41.1-3 ii libglib2.0-0 2.77.2-1 ii libgtk-3-0 3.24.38-4 ii libgtk-4-1 4.10.5+ds-3 ii libnm0 1.44.0-1 ii libnma-gtk4-01.10.6-1 ii libnma0 1.10.6-1 ii libopenconnect5 9.12-1 ii libsecret-1-00.21.0-1 ii libsoup2.4-1 2.74.3-1 ii libwebkit2gtk-4.0-37 2.40.5-1 ii libxml2 2.9.14+dfsg-1.3 ii network-manager-openconnect 1.2.10-1 network-manager-openconnect-gnome recommends no packages. network-manager-openconnect-gnome suggests no packages. -- no debconf information
Bug#1037254: extrepo apt-transport-tor and onion support
On Tue, Jul 18, 2023 at 08:52:00AM +, Patrick Schleizer wrote:
> One thing to consider: A few onions are tor+https but most are tor+http. But
> I guess that's not an issue because http vs https is declared in the
> repository configuration files.
Yeah, we'll just prepend 'tor+' if that was asked, and leave everything
else as is.
> > I think this would be a nice feature to have, indeed.
>
> Thank you for your interest in this feature!
>
> > However, given that I have zero experience with tor, I would need some help
> > with the design of such a feature.
>
> Sure thing!
I've given this some more thought, and I think a better design would be this:
--tor=onion: use .onion URLs, fail if no such setting exists for the
requested repository.
--tor=tunnel: use tor+http(s), ignore .onion URLs.
--tor=auto: use .onion, fall back on tor+http(s).
--tor=if-onion: use .onion if available, fall back on regular URLs.
All these values would be settable using a "tor:" line in
/etc/extrepo/config.yaml, too.
> > In order to make sure that the data is correct and complete, we would need
> > to be able to validate .onion URLs in the CI jobs, which involves
> > downloading repository metadata and making sure it looks sensible. Do you
> > know if it is possible to reach the tor network from a container?
>
> If you want to test onion availability without use of apt-get? In that case,
> the torsocks package will help. Use of torsocks is very simple. Simply
> prepend it in front of the command you intent to use and the connection will
> be torified. Example usage: torsocks curl oniondomain.onion
I tried this, in the "onion" branch of
https://salsa.debian.org/extrepo-team/extrepo-data, but it failed for
reasons I don't understand. Would you care to take a look?
Thanks,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1042424: src:ola: fails to migrate to testing for too long: uploader built arch:all binaries
Hi Paul,
On Fri, Jul 28, 2023 at 08:18:56AM +0200, Paul Gevers wrote:
> Your package is only blocked because the arch:all binary package(s) aren't
> built on a buildd. Unfortunately the Debian infrastructure doesn't allow
> arch:all packages to be properly binNMU'ed. Hence, I will shortly do a
> no-changes source-only upload to DELAYED/15, closing this bug. Please let me
> know if I should delay or cancel that upload.
Thanks. I forgot about this one, and yes, a no-changes source-only
upload was still required. The delay is unnecessary; I've just uploaded
-4 which is essentially the same, directly to the upload queue.
Thanks for nudging me.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1042431: libmedia-convert-perl: autopkgtest regression with ffmpeg 6.0
Control: retitle -1 libmedia-convert-perl: autopkgtest fails
On Fri, Jul 28, 2023 at 09:51:06AM +0200, Sebastian Ramacher wrote:
> Source: libmedia-convert-perl
> Version: 1.0.4-3
> Severity: serious
> Tags: sid trixie
> X-Debbugs-Cc: sramac...@debian.org
>
> libmedia-convert-perl's autopkgtest fail with ffmpeg 6.0:
Actually, it just fails ;-) I've got a fix upcoming.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1041541: ffmpeg: libsvtav1 encoding broken
Package: ffmpeg Version: 7:5.1.3-1 Severity: normal Dear Maintainer, I ran the following on a bookworm machine: ffmpeg -i foo.mp4 -c:a libopus -c:v libsvtav1 -crf 35 -preset 8 -y foo.webm This proceeded to encode the video in AV1. However, when I tried the same on unstable, I received the following output: wouter@pc220518:~$ ffmpeg -i foo.mp4 -c:a libopus -c:v libsvtav1 -preset 8 -crf 35 -y foo.webm ffmpeg version 5.1.3-1 Copyright (c) 2000-2022 the FFmpeg developers built with gcc 12 (Debian 12.2.0-14) configuration: --prefix=/usr --extra-version=1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libglslang --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq --enable-librist --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --disable-sndio --enable-libjxl --enable-pocketsphinx --enable-librsvg --enable-libmfx --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-libplacebo --enable-librav1e --enable-shared libavutil 57. 28.100 / 57. 28.100 libavcodec 59. 37.100 / 59. 37.100 libavformat59. 27.100 / 59. 27.100 libavdevice59. 7.100 / 59. 7.100 libavfilter 8. 44.100 / 8. 44.100 libswscale 6. 7.100 / 6. 7.100 libswresample 4. 7.100 / 4. 7.100 libpostproc56. 6.100 / 56. 6.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'foo.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 title : Make the code work for you: Flutter Code Generation date: 2022-02-05 encoder : Lavf58.45.100 Duration: 00:38:59.68, start: 0.00, bitrate: 564 kb/s Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 430 kb/s, 24.98 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name: VideoHandler vendor_id : [0][0][0][0] Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 96000 Hz, mono, fltp, 125 kb/s (default) Metadata: handler_name: SoundHandler vendor_id : [0][0][0][0] Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> av1 (libsvtav1)) Stream #0:1 -> #0:1 (aac (native) -> opus (libopus)) Press [q] to stop, [?] for help [libopus @ 0x564c58b50d80] No bit rate set. Defaulting to 64000 bps. Svt[info]: --- Svt[info]: SVT [version]: SVT-AV1 Encoder Lib v1.6.0 Svt[info]: SVT [build] : GCC 12.3.0 64 bit Svt[info]: --- Svt[error]: Instance 1: MinQpAllowed must be smaller than MaxQpAllowed Svt[error]: Instance 1 : Invalid use_qp_file. use_qp_file must be [0 - 1] [libsvtav1 @ 0x564c58b51d80] Error setting encoder parameters: bad parameter (0x80001005) Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [libopus @ 0x564c58b50d80] 1 frames left in the queue on closing Conversion failed! If any further information is required, please do not hesitate to let me know. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.3.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ffmpeg depends on: ii libavcodec597:5.1.3-1 ii libavdevice59 7:5.1.3-1 ii libavfilter87:5.1.3-1 ii libavformat59 7:5.1.3-1 ii libavutil57 7:5.1.3-1 ii libc6 2.37-6 ii libpostproc56 7:5.1.3-1 ii libsdl2-2.0-0 2.28.1+dfsg-1 ii libswresample4 7:5.1.3-1 ii libswscale6 7:5.1.3-1 ffmpeg recommends no packages. Versions of packages ffmpeg suggests: pn ffmpeg-doc -- no debconf information
Bug#1037254: extrepo apt-transport-tor and onion support
Hi Patrick, I think this would be a nice feature to have, indeed. However, given that I have zero experience with tor, I would need some help with the design of such a feature. I'm thinking something like this might work: - If you pass --onion on the command line, or set onion: true in the configuration file: require a preconfigured .onion URL in the repository configuration. - If you pass --tor-tunnel on the command line, or set tor-tunnel: true in the configuration file: enable the use of the tor+https configuration, don't use a .onion URL even if it is known. - if you pass --tor on the command line, or set tor: true in the configuration file: use a .onion URL if it exists, but fall back to using tor+https if not. What do you think of this suggestion? Does it make sense? Are the proposed option names sensible? In order to make sure that the data is correct and complete, we would need to be able to validate .onion URLs in the CI jobs, which involves downloading repository metadata and making sure it looks sensible. Do you know if it is possible to reach the tor network from a container? If so, would you be willing to help me work that out? If not, can you make another suggestion as to how to do that? Thanks, -- Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.
Bug#1036918: debvm: manual mounting of root image
Hi Helmut,
On Thu, Jun 01, 2023 at 07:53:00AM +0200, Helmut Grohne wrote:
> Hi Wouter,
>
> On Wed, May 31, 2023 at 12:18:00PM +0200, Wouter Verhelst wrote:
> > I don't think it is. All packages that do things at early boot have
> > complicatd requirements; nbd isn't the only one. It's just the first one
> > you hear about.
>
> Thank you for not giving up here.
>
> > > and that debvm may not be the right hammer for your job? While debvm
> > > gives you a complete rootfs, you seem to be satisfied with a kernel an
> > > an initrd.
> >
> > No, that is not accurate; I do need a root filesystem too.
>
> Now that - to me - is a compelling argument. Arguably, that should have
> been obvious. Thanks for spelling it out.
>
> > Yes, I could run debvm-create and then do the extraction of the kernel
> > and initrd myself, but that shouldn't be necessary -- debvm-run would be
> > a perfectly good abstraction, if only it allowed me to tell it not to
> > try to mount the hard drive automatically and/or let me override the
> > root= parameter.
>
> I believe I now understand your use case and I follow your reasoning
> that debvm could reasonably do better at supporting it.
>
> Both mmdebstrap and debvm-create have a --skip mechanism. Doing
> something similar to debvm-run seems sensible initially. The precise way
> of doing it less so. Would you be interested in helping sort the
> details?
>
> For one thing, I think your use of -append does not work well with
> debvm-run. While it sounds like it was appending, it actually is
> replacing the kernel cmdline. debvm-run has its own ideas and passes the
> rootfs, console and terminal emulation type there. By overriding
> -append, you miss all of that. I suspect, we need a more clever
> management of cmdline here and am unsure what that should be exactly.
Ah, yes. I did indeed assume it was keeping the arguments, but it not
doing so seems consistent with what I saw. I assumed that things went
wrong because there were multiple versions of hte same filesystem; but
come to think of it, I would then still have had some output, at least,
which I did not. Losing the whole command line would lose the console,
which would mean there was no output.
I do think debvm-run needs to have a way to actually add to the kernel
command line. Some use cases would need this without having to basically
reimplement what it is already doing. Combined with a skip mechanism, I
think that would cover a lot of use cases.
Since ordering of the kernel command line rarely matters, adding a
simple option for additional command line bits (which then get added at
the end of the command line) should be sufficient, I would think.
> For passing the actual rootfs, I guess a --skip=rootdev would address
> your need. I imagine it as skipping both the root= cmdline argument and
> passing of the blockdev.
I think it may make more sense to treat the two as separate. You mount
the root filesystem by label, currently; so it does not matter how the
block device is set up, as long as it is there. I think some use cases
would benefit from being able to fine-tune the way the block device is
set up without having to add the root filesystem again.
On the other hand, adding a root= parameter to the command line after it
has been removed should be fairly trivial, provided there is a way to
add to the kernel command line without having to redo it. So I don't
think this is really crucial.
> Other things that users might want to skip include the network setup
> (not in your case ;) and the random device setup.
>
> So at this point, the addition of a --skip option seems fairly likely to
> me, but I'd like to consult with other users some more and won't upload
> debvm before bookworm has been released anyway. Still your (and other's)
> input on what kind of features should be skippable and how we could
> better deal with the cmdline is welcome.
>
> Thanks for insisting.
>
> Helmut
>
>
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1036919: debvm: singleshot mode
On Mon, May 29, 2023 at 08:12:54PM +0200, Helmut Grohne wrote:
> Control: clone -1 -2
> Control: retitle -2 debvm's autopkgtests should be marked as flaky
> Control: submitter -2 !
> Control: severity -2 important
>
> Hi Wouter,
>
> On Mon, May 29, 2023 at 02:28:08PM +0200, Wouter Verhelst wrote:
> > I would like to use debvm to run autopkgtests for nbd-client. In order
> > to do that, I would need to run the vm noninteractively, do some in-vm
> > tests, and then shut it down again, with the result of the test
> > affecting the exit state.
>
> Thanks for caring about debvm! Before we delve into your problem, let me
> point out that I had a rather longer talk with Paul Gevers about my
> autopkgtests. In effect, these tests - when executed in testing - still
> test unstable packages. As such, a problem in unstable may make the test
> in stable or testing fail. This is bad. I am at fault here. Please avoid
> repeating my mistake.
I will try :-)
> That being said, would you spend a moment on my autopkgtests anyway? The
> usual interaction happens on stdin/stdout via serial by default, but you
> can also background it and interact with it via ssh, which is what my
> tests do. I think this is the easiest way to script it. Does that suit
> your needs? If not, can you add more detail to how you see this
> happening?
Yeah, that could definitely work. I'll have a look at your autopkgtest
> I also note that autopkgtest has a qemu backend. While this backend is
> not available in the Debian infrastructure, it is being asked for
> repeatedly. Maybe Paul knows more here, but it seems to me that a test
> restriction asking for a VM is more useful for your use case in
> principle.
No, my test needs to communicate with a service outside the VM, so using
the qemu backend for autopkgtest won't help.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1036918: debvm: manual mounting of root image
On Mon, May 29, 2023 at 08:22:06PM +0200, Helmut Grohne wrote:
> Hi Wouter,
>
> On Mon, May 29, 2023 at 02:20:09PM +0200, Wouter Verhelst wrote:
> > I am exploring the possibility to write an autopkgtest for the initramfs
> > stuff that I wrote for nbd-client.
>
> Please see my other mail regarding the use of debvm in autopkgtests.
> Let's not duplicate that topic here. I note that this fully applies in
> the exact way to the projected use of mmdebstrap below.
Sure, but as there were two feature requests, I opened two wishlist bugs ;-)
> > In order to do so, I want to run a client VM that has no root hard disk
> > configured, but is configured to attempt to mount the VM image over the
> > network, using NBD. This is accomplished by way of a few kernel command
> > line parameters.
> >
> > I tried running
> >
> > debvm-run -- -append 'nbdroot=192.168.88.103,root_export,nbd0'
>
> May I suggest that this is a quite unusual use case
Sigh.
Everyone who I talk to about nbd autopkgtest tells me it's an "unusual"
use case.
I don't think it is. All packages that do things at early boot have
complicatd requirements; nbd isn't the only one. It's just the first one
you hear about.
> and that debvm may not be the right hammer for your job? While debvm
> gives you a complete rootfs, you seem to be satisfied with a kernel an
> an initrd.
No, that is not accurate; I do need a root filesystem too.
For reference, nbd is not nfs; it is a network BLOCK device, which means
you need to layer a filesystem on top. So in order to be able to boot
from nbd, you need to create an image that you export. While I could do
this myself, it's what debvm-create does, and I don't think it makes
much sense to replicate that.
In short, the plan is to do something along these lines:
1. Create a filesystem image
2. Configure nbd-server to export that image over NBD, and restart nbd-server
3. boot a VM with the root filesystem on NBD, pointed to the nbd-server that we
just configured
4. Verify that we reach a shell in the VM
5. shut down the VM again
6. Verify that the shutdown worked correctly
7. Boot the VM again, make configuration changes, update the initramfs
8. Reboot the VM, repeat steps 4 through 6.
(I might also want to try some of the other nbdroot= argument formats
that are documented in nbd-client's README.Debian, which all would
require their own reboot, but these are details)
I was looking at guestfish and other similar things, but really, debvm
already does all of this, so there's no point. The only thing is that it
insists on passing root and hard disk arguments to qemu, which break for
my use case.
Yes, I could run debvm-create and then do the extraction of the kernel
and initrd myself, but that shouldn't be necessary -- debvm-run would be
a perfectly good abstraction, if only it allowed me to tell it not to
try to mount the hard drive automatically and/or let me override the
root= parameter.
Thanks for considering,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1036539: nbd-client: not working inside initrd due to unresolved library dependencies
Control: tags -1 unreproducible
thanks
Hi Tomasz,
On Mon, May 22, 2023 at 09:03:12AM +0200, Tomasz Wolak wrote:
> Package: nbd-client
> Version: 1:3.21-1+deb11u1
> Severity: important
> Tags: d-i
> X-Debbugs-Cc: tomas.wo...@gmail.com
>
>
> The nbd-client binary (/sbin/nbd-client), while working fine on the regular
> system,
> is not working inside initrd images (which have very limited set of
> libraries).
> During system startup, it is failing with:
> /sbin/nbd-client: error while loading shared libraries: libgnutls.so.30:
> cannot
> open shared object file: No such file or directory
>
> Currently the nbd-client used for building initrd images is copied the
> initramfs hook
> /usr/share/initramfs-tools/hooks/nbd
> which uses the regular /sbin/nbd-client, which has the following dependencies
> (the example is for i386, but, of course, similar for others):
>
> # ldd /sbin/nbd-client
> linux-gate.so.1 (0xb7f3f000)
> libgnutls.so.30 => /lib/i386-linux-gnu/libgnutls.so.30 (0xb7cf5000)
> libnl-genl-3.so.200 => /lib/i386-linux-gnu/libnl-genl-3.so.200
> (0xb7cec000)
> libnl-3.so.200 => /lib/i386-linux-gnu/libnl-3.so.200 (0xb7cc7000)
> libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7adf000)
> libp11-kit.so.0 => /lib/i386-linux-gnu/libp11-kit.so.0 (0xb798a000)
> libidn2.so.0 => /lib/i386-linux-gnu/libidn2.so.0 (0xb7968000)
> libunistring.so.2 => /lib/i386-linux-gnu/libunistring.so.2
> (0xb77e6000)
> libtasn1.so.6 => /lib/i386-linux-gnu/libtasn1.so.6 (0xb77cf000)
> libnettle.so.8 => /lib/i386-linux-gnu/libnettle.so.8 (0xb7784000)
> libhogweed.so.6 => /lib/i386-linux-gnu/libhogweed.so.6 (0xb773b000)
> libgmp.so.10 => /lib/i386-linux-gnu/libgmp.so.10 (0xb76ab000)
> libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7689000)
> /lib/ld-linux.so.2 (0xb7f41000)
> libffi.so.7 => /lib/i386-linux-gnu/libffi.so.7 (0xb767f000)
> libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7679000)
>
> which, as one can expect, are not met inside an initrd...
So, actually, this bit is not true.
/usr/share/initramfs-tools/hooks/nbd looks like this:
-8<-
#!/bin/sh
# We don't have any prerequirements
case $1 in
prereqs)
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
manual_add_modules nbd
auto_add_modules net
copy_exec /sbin/nbd-client /sbin
->8-
The "copy_exec" in there is a shell function, defined in the
/usr/share/initramfs-tools/hook-functions library, which copies a
program *and all the libraries it requires* into the initramfs.
I checked, and on my system the initramfs does in fact contain all the
necessary libraries. You can check yourself; for instance, to check
libnettle you would do:
wouter@pc220518:~/scratch$ lsinitramfs /boot/initrd.img-$(uname -r)|grep
libnettle
usr/lib/x86_64-linux-gnu/libnettle.so.8
usr/lib/x86_64-linux-gnu/libnettle.so.8.6
or for gnutls:
wouter@pc220518:~/scratch$ lsinitramfs /boot/initrd.img-$(uname -r)|grep gnutls
usr/lib/x86_64-linux-gnu/libgnutls.so.30
usr/lib/x86_64-linux-gnu/libgnutls.so.30.34.3
If this doesn't work for you for some reason, then either you have
misconfigured initramfs-tools or something else is going on -- but at
any rate it is not a problem in nbd-client.
I'm leaving this open for the time being in case I missed something; but
unless you can show me that something is going wrong in the nbd-client
package, I'm going to close this bug a few weeks from now.
Thanks,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1036919: debvm: singleshot mode
Package: debvm Version: 0.2.10 Severity: wishlist Hi, I would like to use debvm to run autopkgtests for nbd-client. In order to do that, I would need to run the vm noninteractively, do some in-vm tests, and then shut it down again, with the result of the test affecting the exit state. Perhaps I missed it, but I didn't see a way to do this. Please make something like this easier :) -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debvm depends on: ii e2fsprogs 1.47.0-2 ii genext2fs 1.5.0-3 ii ipxe-qemu 1.0.0+git-20190125.36a4c85-5.1 ii mmdebstrap 1.3.5-7 ii passwd 1:4.13+dfsg1-1+b1 ii qemu-system-arm 1:7.2+dfsg-7 ii qemu-system-mips1:7.2+dfsg-7 ii qemu-system-misc1:7.2+dfsg-7 ii qemu-system-ppc 1:7.2+dfsg-7 ii qemu-system-sparc 1:7.2+dfsg-7 ii qemu-system-x86 [qemu-kvm] 1:7.2+dfsg-7 Versions of packages debvm recommends: ii arch-test 0.20-1 ii binfmt-support2.2.2-2 ii fakechroot2.20.1+ds-15 ii fakeroot 1.31-1.2 ii file 1:5.44-3 ii openssh-client1:9.2p1-2 ii qemu-system 1:7.2+dfsg-7 ii qemu-user-static 1:7.2+dfsg-7 ii seabios 1.16.2-1 ii systemd 252.6-1 ii uidmap1:4.13+dfsg1-1+b1 Versions of packages debvm suggests: ii qemu-system-gui 1:7.2+dfsg-7 -- no debconf information
Bug#1036918: debvm: manual mounting of root image
Package: debvm Version: 0.2.10 Severity: wishlist Hi, I am exploring the possibility to write an autopkgtest for the initramfs stuff that I wrote for nbd-client. In order to do so, I want to run a client VM that has no root hard disk configured, but is configured to attempt to mount the VM image over the network, using NBD. This is accomplished by way of a few kernel command line parameters. I tried running debvm-run -- -append 'nbdroot=192.168.88.103,root_export,nbd0' however, since debvm-run had by this point already mounted the hard drive, the kernel sees the same root device twice, and let's just say that this didn't go very well. I would like to see an option to tell debvm-run not to mount the filesystem image but to let the user handle that. However, the extracting of the kernel and initramfs which debvm-run does would still be necessary; it's just that I want to fiddle with how we get to the filesystem. Thanks, -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debvm depends on: ii e2fsprogs 1.47.0-2 ii genext2fs 1.5.0-3 ii ipxe-qemu 1.0.0+git-20190125.36a4c85-5.1 ii mmdebstrap 1.3.5-7 ii passwd 1:4.13+dfsg1-1+b1 ii qemu-system-arm 1:7.2+dfsg-7 ii qemu-system-mips1:7.2+dfsg-7 ii qemu-system-misc1:7.2+dfsg-7 ii qemu-system-ppc 1:7.2+dfsg-7 ii qemu-system-sparc 1:7.2+dfsg-7 ii qemu-system-x86 [qemu-kvm] 1:7.2+dfsg-7 Versions of packages debvm recommends: ii arch-test 0.20-1 ii binfmt-support2.2.2-2 ii fakechroot2.20.1+ds-15 ii fakeroot 1.31-1.2 ii file 1:5.44-3 ii openssh-client1:9.2p1-2 ii qemu-system 1:7.2+dfsg-7 ii qemu-user-static 1:7.2+dfsg-7 ii seabios 1.16.2-1 ii systemd 252.6-1 ii uidmap1:4.13+dfsg1-1+b1 Versions of packages debvm suggests: ii qemu-system-gui 1:7.2+dfsg-7 -- no debconf information
Bug#1035348: nbd: new upstream release
Source: nbd Severity: wishlist I just released an upstream version of NBD. I won't upload it to unstable until bookworm is released, and I'm not liable to forget, but experience tells me that in situations like that I tend to get useless wishlist bug reports against nbd, so here's me just telling people not to bother ;-)
Bug#1016447: reportbug: olad includes Angular 1.3.14, but Debian replaces this with a dependency on 1.8.2 (which isn't compatible)
Version: 0.10.9.nojsmin-1
This was fixed with the 0.10.9 upload (but I forgot to mention that in
the changelog, sorry)
Kind regards,
On Sun, Jul 31, 2022 at 12:35:38PM -0700, Ken Harris wrote:
> Package: ola
> Version: 0.10.8.nojsmin-2
> Severity: normal
>
> Dear Maintainer,
>
> When visiting the "New" local OLA server at
> <http://localhost:9090/new/>, clicking on the page for any Universe
> only shows the first tab. Clicking any other tab (Faders, Keypad,
> etc) sends you back to the home page.
>
> OLA includes a copy of Angular 1.3.14 at ola/olad/www/new/libs/, but
> Debian's package removes this and replaces it with a dependency on
> package "libjs-angularjs", which is currently at version 1.8.2, and
> incompatible with OLA's Angular 1.3.14 interface.
>
> Replacing the "angular.min.js" and "angular-route.min.js" symlinks in
> this package with the original files (from ola's upstream repo) fixes
> the problem completely.
>
>
>
> -- System Information:
> Debian Release: 11.3
> APT prefers stable
> APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
> 'stable-security'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.10.0-14-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 ola depends on:
> ii adduser 3.118
> ii libc62.33-7
> ii libgcc-s110.2.1-6
> ii libjs-angularjs 1.8.2-2
> ii libjs-bootstrap 3.4.1+dfsg-2
> ii libjs-jquery 3.5.1+dfsg+~3.5.5-7
> ii libncurses6 6.2+20201114-2
> ii libola1 0.10.8.nojsmin-2
> ii libprotobuf233.12.4-1
> ii libstdc++6 10.2.1-6
> ii libtinfo66.2+20201114-2
> ii lsb-base 11.1.0
>
> ola recommends no packages.
>
> Versions of packages ola suggests:
> ii bash-completion 1:2.11-2
>
> -- no debconf information
>
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1032065: ola: request RT acknowledgement for update to upstream version 0.10.9
Hi Paul,
On Tue, Feb 28, 2023 at 09:06:25PM +0100, Paul Gevers wrote:
> Hi Wouter,
>
> On 27-02-2023 23:37, Wouter Verhelst wrote:
> > To be clear: this would require a pass through NEW, for the RDM tester
> > package ("ola-rdm-tester"). That's okay then? If so, can you add the
> > unblock? If not, I'll leave the rdm-tester for after the release.
>
> No, adding new binaries is not OK.
Thanks. I had assumed that, but my email was a bit muddled and so I just
wanted to be clear.
I've uploaded 0.10.9 without the RDM tester (so no NEW cycle is needed).
That will wait until after the release.
Kind regards,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1032065: ola: request RT acknowledgement for update to upstream version 0.10.9
Package: release.debian.org Severity: normal Hi release team! Since the current state of the freeze, I thought I'd check with you guys before uploading ola 0.10.9. A bit of background: there were a few compatibility bugs in ola 0.10.8 (currently in stable) which meant that it was kicked out of testing a while back for FTBFS reasons. In coordination with upstream, I uploaded a prerelease snapshot to Debian in December that solves some, but not all, of the existing issues. Upstream has since worked on fixing more issues and getting 0.10.9 out, and given that the difference between the current snapshot in Debian and 0.10.9 is mostly bugs fixed, I would like to update to 0.10.9 -- but seen as how there are quite a number of things, and seen as how it is a new upstream release (which technically isn't allowed anymore, AIUI), I would like your go-ahead before I upload. The full list of changes can be found at https://github.com/OpenLightingProject/ola/compare/1b28e794...0.10.9 but it starts off with a number of changelogs and upstream CI things (which we don't use), so you can ignore those and start at https://github.com/OpenLightingProject/ola/compare/1b28e794...0.10.9#diff-d20d9f18d302fd0e8d90fc0b3f880090767ea56fd65f565a1dbb2dcf41c12135 Most of the changes are small bug fixes, spelling fixes, and a bunch of reformatting in the python code. What's not: - olad/www/new/*: this is precompiled in the upstream tarball from olad/www/new-src, removed before upload to Debian (hence the ".nojsmin" bit in the version -- I refuse to call this a ".dfsg" version because I don't agree it's a DFSG issue, but think of it as that) - A number of tests were added (so there's better test coverage) - Ola was in the midst of a reworking of some code that was still Python2-specific; the code that hadn't been ported has been (temporarily) disabled in the version that is currently in the archive. There are some new python files that are necessary to finish the Python3 transition for ola. This is mostly the RDM tester code; the package for that is currently disabled in testing and unstable, but that is a regression from stable -- it works there. There are a few new files to support that better (mostly some string handling utilities) and some extra tests, but nothing earth shattering. Do I have the go ahead? If so I'll upload ASAP.
Bug#801065: Documenting how to not fail postinst on service fails to start
On Wed, Feb 15, 2023 at 02:38:10PM -0500, Marvin Renich wrote:
> > > > - the service fails to start in the postinst.
>
> This implies that "the service is running" is part of "the service is
> configured", which is where I disagree.
What Steve said is that if
- The service fails to start, *AND*
- The service was previously running (or this is a new install)
*THEN*
this is something that should make postinst fail.
The two preconditions are linked, and should not be looked at
separately.
If the service was *not* previously running, then that is a different
situation.
But if the service was previously running and now a restart fails, then
obviously[1] this is a problem with the upgrade that should be looked at
by the admin, which means it must be flagged to the admin somehow.
As I mentioned in the TC discussion, one can reasonably debate what the
best way is to flag such problems, but I think it's not reasonable to
say "let's just push it under the mat, it doesn't matter".
We currently only have one sure way of telling the admin that there is a
problem, and that is "fail postinst".
As such, I think any suggestion that we ignore a restart failure of a
service that was running before the dpkg run should be accompanied by a
plan on *how* to flag this failure to the admin in a way that the admin
will know that things failed. In the absence of that, the status quo of
"postinst should fail on a restart of a service" should probably be
retained.
[1] barring extreme corner cases of the style "the admin made broken
changes but forgot to try a restart"
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1029763: pipewire: does not seem to work unless xdg-desktop-portal is running
On Sat, Jan 28, 2023 at 12:19:17PM +0200, Wouter Verhelst wrote:
> If my analysis above is correct, I would suggest you tighten
> dependencies so that you can't install pipewire-pulse without a working
> pipewire audio setup.
... and for what it's worth, installing "pipewire-audio" on top of what
I had makes audio work.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1029763: pipewire: does not seem to work unless xdg-desktop-portal is running
Hi Dylan, On Fri, Jan 27, 2023 at 12:14:40PM +0100, Dylan Aïssi wrote: > Hello Wouter, > > Le ven. 27 janv. 2023 à 11:00, Wouter Verhelst a écrit : > > > > The pipewire upstream troubleshooting guide suggests I look at > > journalctl output as a first step in troubleshooting things. That > > reveals: > > > > wouter@pc220518:~$ journalctl -xe | grep pipewire > > jan 27 11:04:01 pc220518 pipewire[2111]: mod.rt: Can't find > > org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? > > jan 27 11:04:01 pc220518 pipewire[2111]: mod.rt: found session bus but no > > portal > > jan 27 11:04:01 pc220518 pipewire-media-session[2113]: mod.rt: Can't find > > org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? > > jan 27 11:04:01 pc220518 pipewire-media-session[2113]: mod.rt: found > > session bus but no portal > > jan 27 11:04:01 pc220518 dbus-daemon[1042]: [system] Activating via > > systemd: service name='org.freedesktop.RealtimeKit1' > > unit='rtkit-daemon.service' requested by ':1.33' (uid=127 pid=2113 > > comm="/usr/bin/pipewire-media-session") > > jan 27 11:04:01 pc220518 pipewire-pulse[2114]: mod.rt: Can't find > > org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? > > jan 27 11:04:01 pc220518 pipewire-pulse[2114]: mod.rt: found session bus > > but no portal > > jan 27 11:04:53 pc220518 pipewire[2729]: mod.rt: Can't find > > org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? > > jan 27 11:04:53 pc220518 pipewire[2729]: mod.rt: found session bus but no > > portal > > jan 27 11:04:53 pc220518 pipewire-media-session[2730]: mod.rt: Can't find > > org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? > > jan 27 11:04:53 pc220518 pipewire-media-session[2730]: mod.rt: found > > session bus but no portal > > jan 27 11:04:53 pc220518 pipewire-pulse[2731]: mod.rt: Can't find > > org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? > > jan 27 11:04:53 pc220518 pipewire-pulse[2731]: mod.rt: found session bus > > but no portal > > wouter@pc220518:~$ journalctl -xe | grep wireplumber > > wouter@pc220518:~$ journalctl --user-unit=pipewire --user-unit=wireplumber > > --user-unit=pipewire-pulse -f > > jan 27 11:04:52 pc220518 systemd[2708]: Started PipeWire Multimedia Service. > > jan 27 11:04:53 pc220518 systemd[2708]: Started PipeWire PulseAudio. > > jan 27 11:04:53 pc220518 pipewire[2729]: mod.rt: Can't find > > org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? > > jan 27 11:04:53 pc220518 pipewire[2729]: mod.rt: found session bus but no > > portal > > jan 27 11:04:53 pc220518 pipewire-pulse[2731]: mod.rt: Can't find > > org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? > > jan 27 11:04:53 pc220518 pipewire-pulse[2731]: mod.rt: found session bus > > but no portal > > > > I use awesomewm, which probably doesn't require xdg-desktop-portal and > > therefore doesn't start it. > > xdg-desktop-portal is only used by pipewire for screen-sharing. If you don't > have it, then pipewire will just not be able to do screen-sharing, but will > work > correctly for the audio part. Okay, that's not related then. > What do you mean by it doesn't start it? That sentence referred to "awesome doesn't start xdg-desktop-portal". But if that's unrelated to the problem, then disregard it. > Do you mean you don't have sound at all? Yes. I did not install pipewire manually; it was installed through dependencies. In the mean time I removed pipewire as a workaround, but looking through dpkg.log told me how to reproduce it. If I have these installed, there is no audio: wouter@pc220518:~$ dpkg -l |grep pipewire ii libpipewire-0.3-0:amd64 0.3.65-1 amd64libraries for the PipeWire multimedia server ii libpipewire-0.3-modules:amd64 0.3.65-1 amd64libraries for the PipeWire multimedia server - modules ii pipewire:amd640.3.65-1 amd64audio and video processing engine multimedia server ii pipewire-bin 0.3.65-1 amd64PipeWire multimedia server - programs ii pipewire-media-session0.4.2-1 amd64example session manager for PipeWire ii pipewire-pulse0.3.65-1 amd64PipeWire PulseAudio daemon I'm guessing the problem is that "pipewire-pulse" is installed (which redirect
Bug#958872: Intent to NMU nbd to fix longstanding l10n bugs
Hi Helge,
On Fri, Jan 27, 2023 at 05:32:28PM +0100, Helge Kreutzmann wrote:
> Hello Eduard,
ITYM "Wouter" ;-)
> I intend to NMU ndb around 2023-02-14 to fix longstanding l10n
> bugs[1]. The changelog would be something like the following:
>
> nbd (1:3.24-1.1) unstable; urgency=medium
> .
>* Non-maintainer upload.
>* Update debconf template translation
> - Spanish translation.
>Thanks to Camaleón (Closes: #958872,#1003386)
>
> During rebuild, I also noticed quite a few lintian errors and
> warnings, which I might fix as well (if they are not too hard to
> resolve).
>
> Please tell me if you are currently preparing a new release yourself
> and would like me to skip the NMU.
I have no plans at the moment; please go ahead.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1029763: pipewire: does not seem to work unless xdg-desktop-portal is running
Package: pipewire Version: 0.3.64-4 Severity: important Dear Maintainer, The pipewire upstream troubleshooting guide suggests I look at journalctl output as a first step in troubleshooting things. That reveals: wouter@pc220518:~$ journalctl -xe | grep pipewire jan 27 11:04:01 pc220518 pipewire[2111]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? jan 27 11:04:01 pc220518 pipewire[2111]: mod.rt: found session bus but no portal jan 27 11:04:01 pc220518 pipewire-media-session[2113]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? jan 27 11:04:01 pc220518 pipewire-media-session[2113]: mod.rt: found session bus but no portal jan 27 11:04:01 pc220518 dbus-daemon[1042]: [system] Activating via systemd: service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' requested by ':1.33' (uid=127 pid=2113 comm="/usr/bin/pipewire-media-session") jan 27 11:04:01 pc220518 pipewire-pulse[2114]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? jan 27 11:04:01 pc220518 pipewire-pulse[2114]: mod.rt: found session bus but no portal jan 27 11:04:53 pc220518 pipewire[2729]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? jan 27 11:04:53 pc220518 pipewire[2729]: mod.rt: found session bus but no portal jan 27 11:04:53 pc220518 pipewire-media-session[2730]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? jan 27 11:04:53 pc220518 pipewire-media-session[2730]: mod.rt: found session bus but no portal jan 27 11:04:53 pc220518 pipewire-pulse[2731]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? jan 27 11:04:53 pc220518 pipewire-pulse[2731]: mod.rt: found session bus but no portal wouter@pc220518:~$ journalctl -xe | grep wireplumber wouter@pc220518:~$ journalctl --user-unit=pipewire --user-unit=wireplumber --user-unit=pipewire-pulse -f jan 27 11:04:52 pc220518 systemd[2708]: Started PipeWire Multimedia Service. jan 27 11:04:53 pc220518 systemd[2708]: Started PipeWire PulseAudio. jan 27 11:04:53 pc220518 pipewire[2729]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? jan 27 11:04:53 pc220518 pipewire[2729]: mod.rt: found session bus but no portal jan 27 11:04:53 pc220518 pipewire-pulse[2731]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running? jan 27 11:04:53 pc220518 pipewire-pulse[2731]: mod.rt: found session bus but no portal I use awesomewm, which probably doesn't require xdg-desktop-portal and therefore doesn't start it. I think if pipewire is to be the default, it should either be able to work without xdg-desktop-portal, or it should be able to start it itself if it cannot do so. There are plenty of (supported!) graphical environments in Debian that don't do that much xdg stuff. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pipewire depends on: ii adduser 3.130 ii init-system-helpers 1.65.2 ii libpipewire-0.3-modules 0.3.64-4 ii pipewire-bin 0.3.64-4 pipewire recommends no packages. pipewire suggests no packages. -- no debconf information
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Fri, Jan 20, 2023 at 05:16:43PM +, Simon McVittie wrote:
> On Fri, 20 Jan 2023 at 09:54:21 -0700, Anthony Fok wrote:
> > supposedly some older Chinese websites are still using "GBK" as
> > encoding, probably something like:
> >
> >
> >
> > which has less than 30,000 characters and thus a very limited subset
> > of Unicode. And, presumably not everyone has the know how to convert
> > to UTF-8, the Chinese government wants those unable to at least change
> > that meta tag to:
> >
> >
>
> Sure, but neither of those actually require us to support GBK or GB
> 18030 as a system locale, only as something that iconv() (or whatever
> browsers actually use, which is probably their own thing) can convert
> into their preferred internal representation (which is almost certainly
> UTF-8, UTF-16 or UCS-4).
Those files need to be edited *somewhere*. If that somewhere is a Debian
desktop, then you also need editors that know how to write such files,
etc.
Sometimes it's just easier if the whole thing uses the same encoding.
> Analogously, we've never supported using Windows-1252 (Microsoft's
> legacy Latin-1 variant) as a system locale encoding in some hypothetical
> locale like en_US.windows-1252, but HTML documents with
> text/html;charset=windows-1252 still work fine.
Windows-* encodings were native on Windows, and we only needed to
be able to read files that were generated on such systems.
We're talking here instead about a government-mandated encoding that
systems are expected to support; not only to consume data, but also to
*produce* data.
Windows-* encodings never had that attached to them.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Thu, Jan 19, 2023 at 11:47:42AM +, Simon McVittie wrote:
> Preferring to use Unicode does seem to be the direction that all of
> computing is going in, as a simplifying assumption - for example W3C
> advice for HTML is "You should always use the UTF-8 character encoding"[1]
> - and as we know, things that aren't tested usually don't work. So I
> think the level of functionality for non-UTF-8 locales and encodings in
> the software we package is going to decline over time, whether Debian
> wants it to or not.
If the world's most populous country uses something that is not UTF-8, I
think it's safe to say it's being tested, if only by people who will
file bugs when things go awry.
If the PRC government *requires* a non-UTF-8 encoding for things sold to
them, we would be doing our users who want to sell a product containing
Debian to the PRC government a disservice by dropping support for it
altogether.
We don't have to ensure it works perfectly out of the box; just that
support is achievable with a reasonable amount of work.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#908274: Multi-host networking software, autopkgtests
Hi Ian,
On Fri, Jan 06, 2023 at 04:59:58PM +, Ian Jackson wrote:
> Paul Gevers writes ("Re: Multi-host networking software, autopkgtests"):
> > I guess this is best discussed in https://bugs.debian.org/908274 (added
> > in the To)? Maybe with Wouter and other interested parties?
>
> Hmmm. Well, a way of doing this "officially" in autopkgtest would be
> nice. But:
>
> Think such an "official" thing ought to allow the specification of
> different dependencies for the different hosts in the test. And I
> don't much like the mini-DSL suggestion. Maybe it would be better to
> offer the test script an adt virt server interface to control the
> "other" hosts.
>
> This all seems very complex. I definitely want to have something
> working before something like that could exist. Also, I think it
> would be a good idea to do something ad-hoc, ideally in a number of
> packages, to gain experience so we know what shape the "official"
> thing ought to be.
>
> I think therefore that I need to pursue some kind of within-testbed
> nesting, as an interim approach at the very least. I was hoping that
> someone else had solved (part of) this problem already...
Unfortunately not.
We also had a discussion during the "autopkgtest office hours" session
during debconf21[1], where an alternate method (that would be slightly
easier to implement) was proposed: to have an autopkgtest helper command
that allows you to easily create and run a Debian VM for the host
architecture, and run stuff on it. This might be a bit easier to
implement than the dsl in the proposal.
[1]
https://debconf-video-team.pages.debian.net/videoplayer/#/event/2021/debconf21?video=debconf21-82-autopkgtest-office-hours.webm=2028
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1026108: vue.min.js contains incorrect contents
Package: libjs-vue Version: 2.6.14+dfsg-4 Severity: important Hi, wouter@pc220518:~$ cat /usr/share/javascript/vue/vue.min.js; echo /*! * Vue.js v2.6.14 * (c) 2014-2022 Evan You * Released under the MIT License. */ undefined wouter@pc220518:~$ Something went horribly wrong with the minimization here... -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled libjs-vue depends on no packages. Versions of packages libjs-vue recommends: ii javascript-common 11+nmu1 libjs-vue suggests no packages. -- no debconf information
Bug#1022870: libsvtav1enc1: Fails to allocate memory on 32-bit arm architectures
Package: libsvtav1enc1 Version: 1.2.1+dfsg-1 Severity: normal Dear Maintainer, I uploaded my package libmedia-convert-perl, with an autopkgtest. As part of the autopkgtest, it calls ffmpeg to encode a very short media file to av1 using the svt-av1 encoder. This works fine on my own laptop (amd64), but it fails when run on the armhf and armel workers for ci.debian.net. At this point, more architectures are pending, so more failures may occur later. Relevant logs: https://ci.debian.net/data/autopkgtest/testing/armhf/libm/libmedia-convert-perl/27553000/log.gz https://ci.debian.net/data/autopkgtest/testing/armel/libm/libmedia-convert-perl/27552345/log.gz It shows the following output: Running: 'ffmpeg' '-loglevel' 'warning' '-y' '-i' 't/testvids/bbb.mp4' '-threads' '1' '-c:v' 'libsvtav1' '-b:v' '1116.207k' '-minrate' '558.1035k' '-maxrate' '1618.50015k' '-r:v' '24/1' '-crf' '25' '-speed' '4' '-c:a' 'libvorbis' '-b:a' '133431' '-ar' '44100' '-t' '0.1' '-pix_fmt' 'yuv420p' './1sec.webm' Svt[info]: --- Svt[info]: SVT [version]: SVT-AV1 Encoder Lib v1.2.0 Svt[info]: SVT [build] : GCC 12.2.0 32 bit Svt[info]: --- Svt[info]: Number of logical cores available: 16 Svt[info]: Number of PPCS 71 Svt[info]: [asm level on system : up to c] Svt[info]: [asm level selected : up to c] Svt[info]: --- Svt[info]: SVT [config]: main profile tier (auto) level (auto) Svt[info]: SVT [config]: width / height / fps numerator / fps denominator : 856 / 480 / 24 / 1 Svt[info]: SVT [config]: bit-depth / color format / compressed 10-bit format : 8 / YUV420 / 0 Svt[info]: SVT [config]: preset / tune / pred struct : 10 / PSNR / random access Svt[info]: SVT [config]: gop size / mini-gop size / key-frame type : 161 / 16 / key frame Svt[info]: SVT [config]: BRC mode / rate factor / max bitrate (kbps) : capped CRF / 25 / 1618 Svt[info]: --- Svt[error]: Failed to create thread: Cannot allocate memory SvtMalloc[fatal]: allocate memory failed, at ./Source/Lib/Encoder/Globals/EbEncHandle.c:2285 [libsvtav1 @ 0x13366c0] Error initializing encoder: insufficient resources (0x80001000) Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [libvorbis @ 0x13053a0] 41 frames left in the queue on closing (this is from the armel build, in case it matters, though the armhf one is very similar) The debian-ci maintainers tell me that the armel worker has 32G of memory available, which is more than most 64-bit architectures (and in fact, also more than my own laptop has, on which it works perfectly), leading me to suspect it is rather a bug in svt-av1 rather than a memory issue. Thanks,
Bug#968226: Move documentation of Build-Depends alternative selection out of footnote
On Thu, Sep 22, 2022 at 07:11:38PM -0700, Russ Allbery wrote:
> Wouter Verhelst writes:
> > On Tue, Sep 20, 2022 at 07:17:17PM -0700, Russ Allbery wrote:
> >> Wouter Verhelst writes:
>
> >>> Thanks, yeah, I missed that. I'll have a stab at a patch some time soon
> >>> (probably after debconf though)
>
> >> Here, a couple of years later, is a patch that does this, and which I
> >> think is ready for seconds.
>
> > Whoops, sorry; this completely slipped my mind.
>
> Apologies, that probably sounded like I was complaining about you not
> sending a patch. I only meant to mention that this was a thread from a
> long time back, which is why it might seem out of the blue. I have
> dropped so many Policy balls that I'm certainly not going to complain
> about a bug slipping someone else's mind. :)
Oh no, trust me, it wasn't; but I still feel bad for having dropped the
ball, as I always do :-)
> > I think this could be expanded a bit?
>
> > "This is done to reduce the risk of inconsistencies between repeated
> > builds, in case a package is temporarily not available to be installed
> > on a given architecture (which due to the nature of the unstable
> > distribution might happen for any number of reasons) at the time of the
> > (re-)build of a package."
>
> > or something along those lines. The point is to make it clear how these
> > inconsistencies are caused, which I think will help with understanding.
>
> > (I realize your text is what the footnote originally said, but I think
> > this suggestion would improve matters)
>
> Here's an updated patch that expands that and also is more explicit, since
> I found my own wording a bit hard to read. I also added an example. It
> may be a bit verbose now, but this feels like an important topic to be
> clear about given how often it comes up.
>
> I also reworded the paragraph about backports to hopefully address
> Holger's reading. It's just trying to say that backports uses aptitude in
> the normal way and doesn't do anything special to transform the
> alternative.
I think that text is miles better, yes. Seconded.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
signature.asc
Description: PGP signature
Bug#968226: Move documentation of Build-Depends alternative selection out of footnote
On Sat, Sep 24, 2022 at 10:16:12AM +, Holger Levsen wrote:
> On Fri, Sep 23, 2022 at 04:17:04PM +0100, Simon McVittie wrote:
> > On Thu, 22 Sep 2022 at 19:11:38 -0700, Russ Allbery wrote:
> > > I also reworded the paragraph about backports to hopefully address
> > > Holger's reading. It's just trying to say that backports uses aptitude in
> > > the normal way and doesn't do anything special to transform the
> > > alternative.
>
> yup, it's better, thanks.
>
> > It's perhaps worth mentioning that experimental does something similar
> > (it has used the aptitude and aspcud resolvers at various times, but
> > I'm not sure which one is currently in use).
>
> I see.
>
> I think my biggest concern is actually not how it's described but rather
> why/that it is different at all (and then wondering whether it will stay
> that way...)
Experimental is different because it is an incomplete distribution,
which needs to default to using packages from unstable except if
build-depends explicitly lists versions that are only available in
experimental.
When I set up the first experimental autobuilder back in the day, I
hacked the sbuild resolver (it had its own resolver at the time) to
explicitly tell apt which packages to pull from experimental, rather
than doing something like "-t experimental" or some such.
I wrote
https://lists.debian.org/debian-devel-announce/2006/04/msg7.html to
-devel-announce at the time; but since I haven't been involved with
buildd work in a while, I can't really say whether it's still accurate
or relevant today.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#968226: Move documentation of Build-Depends alternative selection out of footnote
On Tue, Sep 20, 2022 at 07:17:17PM -0700, Russ Allbery wrote: > Wouter Verhelst writes: > > On Tue, Aug 11, 2020 at 10:05:42AM -0700, Russ Allbery wrote: > >> Wouter Verhelst writes: > > >>> -policy: this is a question that has come up before > >>> (https://lists.debian.org/debian-devel/2016/12/msg00470.html is > >>> another example that springs to mind, but I'm pretty sure there are > >>> more), so I think we should document in Policy that a) buildd only > >>> looks at the first dependency in alternative build-dependencies, and > >>> b) why this is the case. > > >> Policy already says: > > >> While Build-Depends, Build-Depends-Indep and Build-Depends-Arch > >> permit the use of alternative dependencies, these are not normally > >> used by the Debian autobuilders. To avoid inconsistency between > >> repeated builds of a package, the autobuilders will default to > >> selecting the first alternative, after reducing any > >> architecture-specific restrictions for the build architecture in > >> question. While this may limit the usefulness of alternatives in a > >> single release, they can still be used to provide flexibility in > >> building the same package across multiple distributions or > >> releases, where a particular dependency is met by differently named > >> packages. > > >> in 7.1. However, it's hidden in a footnote. Perhaps we should make it > >> more prominant (and make it clear that it's normative), and tweak the > >> wording. > > > Thanks, yeah, I missed that. I'll have a stab at a patch some time soon > > (probably after debconf though) > > Here, a couple of years later, is a patch that does this, and which I > think is ready for seconds. Whoops, sorry; this completely slipped my mind. > -- > Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> > > From dd30c5455f13086dd0ef90bf6890c20729a1ac0b Mon Sep 17 00:00:00 2001 > From: Russ Allbery > Date: Tue, 20 Sep 2022 19:11:54 -0700 > Subject: [PATCH] Improve alternative build dependency discussion > > Alternatives in build dependencies are normally (except for > backports) handled specially by autobuilders to try to maintain > consistent builds. This was documented in Policy, but in a > footnote that people often didn't see. > > Move this text into the main body of the discussion of build > dependencies and reword it for additional clarity. Add a pointer > to this discussion where alternative dependencies are introduced. > --- > policy/ch-relationships.rst | 41 ++--- > 1 file changed, 25 insertions(+), 16 deletions(-) > > diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst > index 5074428..f177885 100644 > --- a/policy/ch-relationships.rst > +++ b/policy/ch-relationships.rst > @@ -15,7 +15,10 @@ control fields of the package, which declare dependencies > on other > packages, the package names listed may also include lists of alternative > package names, separated by vertical bar (pipe) symbols ``|``. In such a > case, that part of the dependency can be satisfied by any one of the > -alternative packages. [#]_ > +alternative packages. (Alternative dependencies in ``Build-Depends``, > +``Build-Depends-Indep``, and ``Build-Depends-Arch`` are normally used in a > +restricted way. See :ref:`Relationships between source and binary packages > +` for more details.) > > All of the fields may restrict their applicability to particular versions > of each named package. This is done in parentheses after each individual > @@ -620,6 +623,27 @@ earlier for binary packages) in order to invoke the > targets in > ``Build-Conflicts-Arch`` fields must be satisfied when these targets > are invoked. > > +Alternative dependencies are allowed in the ``Build-Depends``, > +``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields, but Debian's > +autobuilders normally interpret them in a restricted way. After > +dependencies that do not apply to the current architecture are removed, > +all alternatives specifying different package names than the first > +alternative are dropped. (Alternatives specifying the same package name > +are kept to permit relationships such as ``foo (<= x) | foo (>= y)``.) > +The effect, therefore, is to use only the first alternative that is valid > +on the relevant architecture. This is done to reduce the risk of > +inconsistencies between repeated builds. I think this could be expanded a bit? "This is done to reduce the risk of inconsistencies betw
Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes
On Sun, Sep 18, 2022 at 06:01:38PM -0700, Russ Allbery wrote:
> Guillem Jover writes:
>
> > Oh! I've completely missed this all this time, I think because that
> > feels very weird given that it has no synopsis and the text is added
> > already on the first line on the spec. :/
>
> Other formatted fields with the same semantics are Source, Disclaimer, and
> Comment. I don't think there are any fields in debian control files with
> those semantics (Description is the only formatted field and it has a
> synopsis), but there are several of them in copyright files.
>
> Source is another ongoing minor problem, since it's *usually* a URL but is
> not required to be one, and sometimes a textual description of the source
> is needed. Here too, a structured format would have been nicer, so that
> you could have something like:
>
> source:
> urls:
> - https://example.com/foo
> - https://example.org/foo
> comment: >-
> The foo-rewrite script was originally posted to comp.unix.sources in
> 1992 but otherwise has no source other than the Debian package.
>
> Ah well.
>
> > Right, the problem I see is that applying this formatting to a field
> > that has no special treatment for the first line just after the field
> > name seems very unintuitive, because the first line does not contain an
> > additional prefixing space, or if it does no one is adding it!
>
> > It feels very weird to me that all these would be equivalent:
>
> > Copyright: Something long that might trigger some wrapping behavior
> > Other thing very long that might not be clear behaves as the above
> > More
>
> > and
>
> > Copyright: Something long that might trigger some wrapping behavior
> > Other thing very long that might not be clear behaves as the above
> > More
>
> > and
>
> > Copyright:
> > Something long that might trigger some wrapping behavior
> > Other thing very long that might not be clear behaves as the above
> > More
>
> I think my brain just assumes that all whitespace after the colon of a
> field name and before the first non-whitespace character is ignored, so
> doesn't have a problem with that, but I can see why it would be confusing.
>
> > Otherwise, if the current semantics are retained, at least for me, the
> > first line behavior really needs to be clarified.
>
> Yes, we should distinguish between formatted text with synopsis and
> formatted text without synopsis more clearly. Or, you know, just propose
> a new YAML format which would make it trivial to clean up all of these
> problems *and* would provide first-class editor support and easy parsing
> in every major programming language. :) But that's WAY bigger than this
> bug.
If we're going to do that, it might make sense to explicitly allow JSON
and/or TOML as alternative representations, because there are some
really weird edge cases in YAML.
> > If we end up switching the field semantics, that seems it might cause
> > unnecessary modification churn, given that I (not sure whether other
> > people have done this before than me as well) at least have "instigated"
> > unintentionally this type of change in several places (packages I
> > maintain, golang/prometheus team), including tooling (AFAIR dh-make and
> > dh-make-golang), and other people might have also picked this up too. :/
>
> I think making the field a line-based list is the obviously correct thing
> to do. It's just not backward-compatible, so we will have to face the
> question of how we handle a version bump in the copyright file (and of
> course figure out if we're going to deal with all of the other requests
> that would require a version bump).
I think semantic versioning would require you make this a major version
bump, since like you say it's not backwards compatible.
> And I have packages where individual copyright lines are longer than 80
> columns, so we either have to require unwrapped lines greater than 80
> columns (which I'd rather not do), or we have to define line wrapping
> semantics for line-based lists, which adds yet more irritating ugliness to
> the deb822 format. Probably just "if the line is indented by more than
> one space, it's a continuation for the previous line" I guess.
Ah yes, but then if you do that, the old examples in policy that were
being patched away here (usage of which might exist in the wild) would
now have different semantics...
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#917541: Whoops, I packaged this
Hi,
I uploaded a version of python-xxhash to NEW the other day:
https://ftp-master.debian.org/new/python-xxhash_3.0.0-1.html
I had somehow missed this ITP bug, and so completely ignored the
packaging work that had already been done.
I have no particular interest in this package, other than "mycroft
requires it", and I am working on getting that into Debian (see
#893788); so if someone who had been working on the package wants to
take it off my hands, just go ahead. I won't be upset, promise!
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#1009752: Segfaults a while into the game
Package: singularity Version: 1.0.0-1 Severity: important Singularity crashes after playing it for a while, with the following output: Singularity 1.00 (commit: 2ebc2f3f2059b96885416167363bde2e27ece106) Running under Python 3.9.12 (main, Mar 24 2022, 13:02:21) [GCC 11.2.0] pygame 2.1.2 (SDL 2.0.20, Python 3.9.12) Hello from the pygame community. https://www.pygame.org/contribute.html The error-log configured as /home/wouter/.local/share/singularity/log/error.log (lazily created when something is logged) Fatal Python error: pygame_parachute: (pygame parachute) Segmentation Fault Python runtime state: initialized Current thread 0x7f75cd2ea640 (most recent call first): Thread 0x7f75d21ee740 (most recent call first): File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 272 in handle File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 231 in show File "/usr/lib/python3/dist-packages/singularity/code/screens/message.py", line 119 in show File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 125 in call_dialog File "/usr/lib/python3/dist-packages/singularity/code/screens/message.py", line 44 in show_list File "/usr/lib/python3/dist-packages/singularity/code/screens/map.py", line 639 in on_tick File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 405 in call_handlers File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 390 in handle File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 231 in show File "/usr/lib/python3/dist-packages/singularity/code/safety.py", line 64 in safe_call File "/usr/lib/python3/dist-packages/singularity/code/screens/map.py", line 580 in show File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 125 in call_dialog File "/usr/lib/python3/dist-packages/singularity/code/screens/main_menu.py", line 104 in new_game File "/usr/lib/python3/dist-packages/singularity/code/graphics/button.py", line 247 in activated File "/usr/lib/python3/dist-packages/singularity/code/graphics/button.py", line 213 in activate_with_sound File "/usr/lib/python3/dist-packages/singularity/code/graphics/button.py", line 112 in handle_hotkey File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 405 in call_handlers File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 390 in handle File "/usr/lib/python3/dist-packages/singularity/code/graphics/dialog.py", line 231 in show File "/usr/lib/python3/dist-packages/singularity/__init__.py", line 382 in main File "/usr/games/singularity", line 11 in Afgebroken The file error.log that is referred to in the output exists, but is empty. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, riscv64, armhf Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages singularity depends on: ii fonts-dejavu-core 2.37-2 ii python33.9.8-1 ii python3-numpy 1:1.21.5-1 ii python3-polib 1.1.1-1 ii python3-pygame 2.1.2+dfsg-3 Versions of packages singularity recommends: ii singularity-music 007-2 Versions of packages singularity suggests: ii timidity 2.14.0-8+b1 -- no debconf information
Bug#994388: dpkg currently warning about merged-usr systems
On Fri, Apr 08, 2022 at 12:07:25PM -0700, Sean Whitton wrote:
> Hello Wouter,
>
> On Fri 08 Apr 2022 at 09:36AM +02, Wouter Verhelst wrote:
>
> > Given that, in case the dpkg maintainer chooses to remain silent
> > again, I believe the only way forward is for the TC to recommend a GR
> > under §4.2.1 of the consitution.
>
> Perhaps there is some appropriate GR that at some point it will be
> appropriate for the ctte to propose, but not one with the same text as
> one of our merged-/usr decisions already issued -- that doesn't make
> much constitutional sense, I think.
Well, I think it would -- the TC can always say "we want to get wider
input", and a GR is a proper way to do so, even if the GR is about the
exact thing the TC previously decided on (though that of course doesn't
need to be the case). Perhaps if there is a clearer project-wide
consensus about this, the dpkg maintainer might be convinced?
But that was just a thought, feel free to ignore it :-)
On a side note, the dpkg maintainer replied to my message, dropping the
-ctte Cc, wherein he claims that the warning has been removed:
https://lists.debian.org/debian-dpkg/2022/04/msg7.html
I didn't check any of the claims in his message, but it seems relevant
information.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#994388: dpkg currently warning about merged-usr systems
On Fri, Apr 08, 2022 at 02:31:27PM +0100, Wookey wrote:
> On 2022-04-08 09:36 +0200, Wouter Verhelst wrote:
> >
> > The dpkg maintainer has chosen not to engage with the TC in #994388, and
> > now seems to be actively subverting a validly-made TC decision.
> >
> > I do believe it reasonable to assume the dpkg maintainer has a point if
> > he believes that the currently-chosen way of moving forward is harmful.
> > However, the right way for him to make that point would have been to
> > engage with the TC, the body constitutionally placed to resolve
> > conflicts of this manner, not ignoring them and then doing whatever he
> > wants when the decision inevitably doesn't go his way.
>
> > I encourage the dpkg maintainer (Cc'd) to engage with the TC in this
> > matter. It is not yet too late;
>
> That all sounds reasonable, but there is the long-standing issue that
> Guillem has never accepted that the TC has authority over the
> project. I forget the details, but given that he does not see it as
> valid it's not surprising that he is not engaging with it.
Why does that matter? I honestly don't care.
Debian has a set of rules. It's called our "constitution". We all follow
those rules when we engage with the project, for instance when we are
voting.
wouter@pc181009:~/debian/webwml/english/vote$ grep 'guillem' */*voters.txt|wc -l
42
You don't get to exercise your rights in our constitution in one
instance but ignore your duties in another. The constitution exists, and
it is not an optional document. Either you agree by it (and then you get
to vote, etc), or you don't (and then what are you doing here). If one
party can get their way simply by ignoring the rules, then we might as
well pack up and forget this whole Debian thing even happened in the
first place.
There have been cases in the past where Debian has made decisions that I
disagreed with. There have been cases where I seriously considered
leaving the project. In the end, I chose not to do so, in part because
the rules we follow made the decision a fair one, even if I did not
agree with it.
For clarity, and again, I am inclined to agree with the dpkg maintainer
on the matter of how the /usr merge should be implemented; but I am
seriously offended by how he is acting in this manner. This is not how
things should be done.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#994388: dpkg currently warning about merged-usr systems
On Fri, Apr 08, 2022 at 03:41:25AM -0700, Felix Lechner wrote:
> Hi,
>
> On Fri, Apr 8, 2022 at 1:48 AM Wouter Verhelst wrote:
> >
> > The nuclear option here is obviously to take maintenance of dpkg away
> > from the dpkg maintainer unless and until he decides to follow the
> > rules.
>
> This song is for Guillem:
>
> https://www.youtube.com/watch?v=cnoX81TC6jk
(Stereo MC's - Connected)
I'm not sure what this is supposed to contribute to the discussion? I
think the current situation (where one person in a position of power
decides the rules don't apply to them) is extremely problematic.
Regardless of whether I think the dpkg maintainer is right in this
dispute (and I am inclined towards that position), I think the way he
has chosen to prove his point is not acceptable.
It fails §3 of the code of conduct ("Be collaborative"). Ignoring a
ruling of the TC and just doing your own damn thing is not conducive to
solving the problem. This, to me, is not acceptable.
It fails the "Our Users" bit of the "Our priorities" in the social
contract. Using user pressure to override a technical committee decision
that was taken, even if I may disagree with the merit of that decision,
is not acceptable to me.
Telling users to do one thing when the rest of the project has decided
to do another thing is *not acceptable*. Regardless of who you are.
You may think that the decision is wrong. That's fair. You are given the
option to express that opinion before this committee. If you don't
immediately have time to express that opinion, then you may request more
time. If you think there are other options possible but you need time to
write code to express those other options, then that's fine too and you
can say so.
But remaining silent and then just dropping a bomb like this is not
acceptable, in my opinion, and silly songs don't change that.
But hey, who am I...
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#994388: dpkg currently warning about merged-usr systems
On Fri, Apr 08, 2022 at 01:28:16PM +0500, Andrey Rahmatullin wrote:
> On Fri, Apr 08, 2022 at 09:36:21AM +0200, Wouter Verhelst wrote:
> > FWIW, I think the TC should punt this bug to a GR.
> >
> > The dpkg maintainer has chosen not to engage with the TC in #994388, and
> > now seems to be actively subverting a validly-made TC decision.
> >
> > I do believe it reasonable to assume the dpkg maintainer has a point if
> > he believes that the currently-chosen way of moving forward is harmful.
> > However, the right way for him to make that point would have been to
> > engage with the TC, the body constitutionally placed to resolve
> > conflicts of this manner, not ignoring them and then doing whatever he
> > wants when the decision inevitably doesn't go his way.
> >
> > I encourage the dpkg maintainer (Cc'd) to engage with the TC in this
> > matter. It is not yet too late; the TC can always roll back decisions it
> > made earlier if it believes, in light of new arguments, those decisions
> > to be wrong. However, if this does not happen, then that does not
> > inspire me with confidence that whatever the TC decides after weighing
> > all the arguments available to them, the dpkg maintainer will follow
> > that ruling. Given that, in case the dpkg maintainer chooses to remain
> > silent again, I believe the only way forward is for the TC to recommend
> > a GR under §4.2.1 of the consitution.
> This effectively means "TC cannot enforce its own decisions and everybody
> can ignore them". Also, who would enforce the GR results and how?
I suppose it does. Do you see a better way forward?
> Note that §2.1.1, at least in my opinion, forbids working against a TC
> decision, but doesn't say who would enforce that and how.
Exactly.
The nuclear option here is obviously to take maintenance of dpkg away
from the dpkg maintainer unless and until he decides to follow the
rules. I didn't want to suggest that (I don't think we're quite at that
level yet), but I'm pretty sure someone will put that option on the
ballot should this get to a GR.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#994388: dpkg currently warning about merged-usr systems
Hi,
On Tue, Mar 15, 2022 at 03:14:36PM -0700, Josh Triplett wrote:
> It would appear that the situation has deteriorated further. dpkg 1.21.2
> now issues a warning on all merged-usr systems:
>
> Setting up dpkg (1.21.2) ...
> dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
> dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.
>
> This escalation seems in direct contradiction to the tech-ctte decision
> in 994388. Moreover, this seems to effectively use package maintainer
> scripts as a means of directing a complaint at Debian users that has not
> gotten traction in other forums, and then directing such users at a wiki
> page that contradicts a prior project decision.
>
> This does not even seem to be calling for help in any meaningful way.
> For instance, soliciting help updating dpkg to handle such
> configurations might have been more productive; that still wouldn't be
> appropriate in a maintainer script, but it might have been productive in
> a mail to -devel. But this isn't soliciting help, it's just incorrectly
> declaring the user's system broken.
>
> This seems counterproductive and harmful.
FWIW, I think the TC should punt this bug to a GR.
The dpkg maintainer has chosen not to engage with the TC in #994388, and
now seems to be actively subverting a validly-made TC decision.
I do believe it reasonable to assume the dpkg maintainer has a point if
he believes that the currently-chosen way of moving forward is harmful.
However, the right way for him to make that point would have been to
engage with the TC, the body constitutionally placed to resolve
conflicts of this manner, not ignoring them and then doing whatever he
wants when the decision inevitably doesn't go his way.
I encourage the dpkg maintainer (Cc'd) to engage with the TC in this
matter. It is not yet too late; the TC can always roll back decisions it
made earlier if it believes, in light of new arguments, those decisions
to be wrong. However, if this does not happen, then that does not
inspire me with confidence that whatever the TC decides after weighing
all the arguments available to them, the dpkg maintainer will follow
that ruling. Given that, in case the dpkg maintainer chooses to remain
silent again, I believe the only way forward is for the TC to recommend
a GR under §4.2.1 of the consitution.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#1008663: NEWS.Debian file contains UNRELEASED as the release name
Package: gdm3 Version: 42.0-1 Severity: minor Hi, The 41.3-2 NEWS.Debian entry for gdm3 starts off like: gdm3 (41.3-2) UNRELEASED; urgency=medium this should probably contain "unstable" or some such?
Bug#1007702: Acknowledgement (fdpowermon: "Not charging" state not supported)
On Wed, Mar 16, 2022 at 06:30:55PM +0100, Roland Rosenfeld wrote:
> Hi Wouter!
>
> It seems, that my patch isn't complete, since with the following
> output of acpi -bi:
>
> Battery 0: Discharging, 87%, 03:13:16 remaining
> Battery 0: design capacity 1958 mAh, last full capacity 1506 mAh = 76%
> Battery 1: Not charging, 5%
> Battery 1: design capacity 4609 mAh, last full capacity 4239 mAh = 91%
>
> I now see the charging symbol (flash next to the battery).
>
> So the attached additional patch seems to be necessary.
>
> Greetings
> Roland
> diff --git a/fdpowermon b/fdpowermon
> index d7b8b6f..ee20dda 100755
> --- a/fdpowermon
> +++ b/fdpowermon
> @@ -447,6 +447,9 @@ sub checklevels {
> if($state =~ /Discharging/) {
> $step = $themes{$theme}->{discharging};
> $charging = 0;
> + } elsif($state =~ /Not charging/) {
> + $step = $themes{$theme}->{discharging};
> + $charging = 0;
This assumes that "Not charging" is always equal to "Discharging",
which is not necessarily true (you gave examples where one battery is
charging, and the other one is "Not charging").
I've instead made it so that $state is assigned to if the state is
"Charging" or "Discharging", but not if $state already has a value and
the state is neither of those two.
This will make a state of "Discharging" for one battery and "Not
charging" for the other use discharging theme, and a state of "Not
charging" for one battery and "Charging" for the other to use the
charging theme.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#1006915: 2 security issues in nbd-server
Source: nbd Version: 1:3.23-3 Severity: serious Tags: security X-Debbugs-Cc: Debian Security Team Two security issues exist in NBD: CVE-2022-26495 and CVE-2022-26496. The former exists since a very long time; the latter only exists since the introduction of NBD_OPT_INFO and NBD_OPT_GO in NBD 3.16. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, riscv64, armhf Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#1004938: Invalid encoding of spam mail causes offlineimap to crash
Package: offlineimap
Version: 7.3.3+dfsg1-1+0.0~git20211018.e64c254+dfsg-1
Severity: normal
An email in my spam folder has started causing the following crash:
Folder spam [acc: Test]:
Syncing spam: IMAP -> Maildir
Copy message UID 1353368115 (1/88) Folk:spam -> Local:spam
Copy message UID 1353368116 (2/88) Folk:spam -> Local:spam
Copy message from Folk:spam:
ERROR: Copying message 1353368115 [acc: Test]
'ascii' codec can't encode characters in position 1541-1579: ordinal not in
range(128)
Thread 'Copy message from Folk:spam' terminated with exception:
Traceback (most recent call last):
File "/usr/share/offlineimap3/offlineimap/threadutil.py", line 146, in run
Thread.run(self)
File "/usr/lib/python3.9/threading.py", line 910, in run
self._target(*self._args, **self._kwargs)
File "/usr/share/offlineimap3/offlineimap/folder/Base.py", line 815, in
copymessageto
new_uid = dstfolder.savemessage(uid, message, flags, rtime)
File "/usr/share/offlineimap3/offlineimap/folder/Maildir.py", line 409, in
savemessage
tmpname = self.save_to_tmp_file(messagename, msg)
File "/usr/share/offlineimap3/offlineimap/folder/Maildir.py", line 359, in
save_to_tmp_file
fd.write(msg.as_bytes(policy=output_policy))
File "/usr/lib/python3.9/email/message.py", line 178, in as_bytes
g.flatten(self, unixfrom=unixfrom)
File "/usr/lib/python3.9/email/generator.py", line 116, in flatten
self._write(msg)
File "/usr/lib/python3.9/email/generator.py", line 181, in _write
self._dispatch(msg)
File "/usr/lib/python3.9/email/generator.py", line 218, in _dispatch
meth(msg)
File "/usr/lib/python3.9/email/generator.py", line 276, in _handle_multipart
g.flatten(part, unixfrom=False, linesep=self._NL)
File "/usr/lib/python3.9/email/generator.py", line 116, in flatten
self._write(msg)
File "/usr/lib/python3.9/email/generator.py", line 181, in _write
self._dispatch(msg)
File "/usr/lib/python3.9/email/generator.py", line 218, in _dispatch
meth(msg)
File "/usr/lib/python3.9/email/generator.py", line 362, in _handle_message
g.flatten(msg.get_payload(0), unixfrom=False, linesep=self._NL)
File "/usr/lib/python3.9/email/generator.py", line 116, in flatten
self._write(msg)
File "/usr/lib/python3.9/email/generator.py", line 181, in _write
self._dispatch(msg)
File "/usr/lib/python3.9/email/generator.py", line 218, in _dispatch
meth(msg)
File "/usr/lib/python3.9/email/generator.py", line 268, in _handle_multipart
self.write(subparts)
File "/usr/lib/python3.9/email/generator.py", line 410, in write
self._fp.write(s.encode('ascii', 'surrogateescape'))
UnicodeEncodeError: 'ascii' codec can't encode characters in position
1541-1579: ordinal not in range(128)
I'm not entirely sure what the message is that causes the exact error,
but I can look that up if you need me to.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-debug'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'unstable'), (500, 'stable'),
(500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, riscv64, armhf
Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages offlineimap depends on:
ii offlineimap3 0.0~git20211018.e64c254+dfsg-1
offlineimap recommends no packages.
offlineimap suggests no packages.
-- no debconf information
Bug#1002210: adapt: diff for NMU version 1.0.0-1.1
Thanks! The delay is absolutely not necessary; feel free to redirect to a direct upload. -- Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.
Bug#1004156: src:adapt: fails to migrate to testing for too long: FTBFS
Hi Paul,
On Fri, Jan 21, 2022 at 10:22:43PM +0100, Paul Gevers wrote:
> If you believe your package is unable to migrate to testing due to issues
> beyond your control, don't hesitate to contact the Release Team.
No, that's not it; I've just not been able to look at the problem, due
to being too busy with other things[1].
I'll get around that early next month, hopefully.
Thanks for caring,
[1] e.g., https://fosdem.org/2022/, which I help organizing.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#1004017: qemu-system-x86_64: assertion failure in parsing code of SLIC ACPI table
Package: qemu-system-x86
Version: 1:6.2+dfsg-1
Severity: important
Justification: qemu always crashes at startup in one (fairly common) use case
Forwarded: https://gitlab.com/qemu-project/qemu/-/issues/786
When called with the necessary parameters to loop through the Windows
license key that is embedded in my laptop (through libvirt), qemu fails
with an assertion:
internal error: qemu unexpectedly closed the monitor: qxl_send_events:
spice-server bug: guest stopped, ignoring
**
ERROR:../../hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed:
(len <= maxlen)
Bail out! ERROR:../../hw/acpi/aml-build.c:61:build_append_padded_str: assertion
failed: (len <= maxlen)
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57,
in newfn
ret = fn(self, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in
startup
self._backend.create()
File "/usr/lib/python3/dist-packages/libvirt.py", line 1353, in create
raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor:
qxl_send_events: spice-server bug: guest stopped, ignoring
**
ERROR:../../hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed:
(len <= maxlen)
Bail out! ERROR:../../hw/acpi/aml-build.c:61:build_append_padded_str: assertion
failed: (len <= maxlen)
Resulting in a failure to start the Windows VM.
This is tracked upstream at
https://gitlab.com/qemu-project/qemu/-/issues/786, and a patch is
already available; please consider including it in the Debian package.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-debug'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'unstable'), (500, 'stable'),
(500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, riscv64, armhf
Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages qemu-system-x86 depends on:
ii ipxe-qemu 1.0.0+git-20190125.36a4c85-5.1
ii libaio1 0.3.112-13
ii libc6 2.33-2
ii libcapstone4 4.0.2-5
ii libfdt1 1.6.1-1
ii libfuse3-33.10.5-1
ii libgcc-s1 11.2.0-13
ii libglib2.0-0 2.70.2-1
ii libgnutls30 3.7.2-5
ii libibverbs1 38.0-1
ii libjpeg62-turbo 1:2.1.2-1
ii libnettle83.7.3-1
ii libnuma1 2.0.14-3
ii libpixman-1-0 0.40.0-1
ii libpmem1 1.11.1-3
ii libpng16-16 1.6.37-3
ii librdmacm138.0-1
ii libsasl2-22.1.27+dfsg2-3
ii libseccomp2 2.5.3-2
ii libslirp0 4.6.1-1
ii libudev1 250.2-3
ii liburing2 2.1-2
ii libvdeplug2 4.0.1-3
ii libxendevicemodel14.14.3+32-g9de3671772-1
ii libxenevtchn1 4.14.3+32-g9de3671772-1
ii libxenforeignmemory1 4.14.3+32-g9de3671772-1
ii libxengnttab1 4.14.3+32-g9de3671772-1
ii libxenmisc4.144.14.3+32-g9de3671772-1
ii libxenstore3.04.14.3+32-g9de3671772-1
ii libxentoolcore1 4.14.3+32-g9de3671772-1
ii libzstd1 1.4.8+dfsg-3
ii qemu-system-common1:6.2+dfsg-1
ii qemu-system-data 1:6.2+dfsg-1
ii seabios 1.15.0-1
ii zlib1g1:1.2.11.dfsg-2
Versions of packages qemu-system-x86 recommends:
ii ovmf 2021.11-1
ii qemu-block-extra 1:6.2+dfsg-1
ii qemu-system-gui 1:6.2+dfsg-1
ii qemu-utils1:6.2+dfsg-1
Versions of packages qemu-system-x86 suggests:
pn samba
pn vde2
-- no debconf information
Bug#1000239: Rescue system won't find root partition, but insists on /usr
On Fri, Dec 03, 2021 at 04:08:24PM -0500, Nicholas D Steeves wrote:
> Control: severity -1 serious
> Control: tags = confirmed
>
> CCing the release team, and CTTE because I don't know who else is
> tracking issues related to the usrmerge effort. I've consciously chosen
> not to pour gasoline on the flame war by CCing anyone else (nor will I
> contact anyone else about the existence of this bug).
>
> Steps I used to try to reproduce:
>
> 1. Downloaded debian-testing-amd64-netinst.iso2021-12-03 16:21 408M
> 2. Installed to EFI-enabled qemu eg:
>kvm -bios /usr/share/ovmf/bios.bin -m 2G \
>-hda debian-separate-usr-sda.raw \
>-cdrom debian-testing-amd64-netinst.iso
> 3. Guided partitioning with separate /home, then changed the mount point
>to /usr. Partition layout is:
> sda1: ESP fat32
> sda2: /ext4
> sda3: swap swap
> sda4: /usr ext4
> 4. Selected only "Standard System Utilities"
> 5. Rebooted
>
> Result: SUCCESS
>
> Then, to test the rescue functionality:
>
> 1. I discovered qemu+OVMF boot order is broken without changing the
>command to: kvm -L /usr/share/ovmf/ -m 2G -boot menu=on \
>-hda /scratch/debian-separate-usr-sda.raw \
>-cdrom /scratch/debian-testing-amd64-netinst.iso
> 2. Selected sda2
> 3. Yes, mount /boot/efi
> 4. Execute a shell in /dev/sda2
> 5. No usable shell was found on your root file system (/dev/sda2)
> 6. Changed virtual terminal
> 7. cd /target && ls bin
>ls: bin: No such file or directory
>
> Result: FAILED
> Conclusion: This is a usrmerged system, and the rescue system does not
> support usermerged systems.
>
> The options are, as I see them, ranked from least to most work-hours:
>
> 1. Debian isn't yet ready for usrmerge. Revert to normal system installation.
> 2. Reassign to src:rescue, and fix the rescue system.
>a) before chrooting, test for the presence of /target/bin/sh
>b) if /bin/sh is not found, either emit error to the user and present a
> dialogue for selecting /usr partition, or
>c) parse /target/etc/fstab, and attempt to mount other partitions
>d) b & c will be difficult to implement when attempting to accommodate
> the heterogeneity of possible MD, LUKS, and LVM layouts, not to mention
> the complications introduced by the possibility of a user-configured
> btrfs subvolume name "@usr" on any valid device. Fstab parsing might
> make the btrfs case easier with:
> i) Display a dialogue selector if a btrfs partition is detected
> The dialogue will list all detected subvolumes
> ii) If the user cannot find a subvolume for "@usr", then
> iii) Allow the user to escape to the partition selection screen, and
> iv) Unmount the partition
> 3. Disallow configuring of a mount for "/usr", and *Prominently* declare that
>Debian no longer supports separating /usr from /, declare this in *many
>places*, and reply to bugs on this topic for many years. I put this one
>last because I believe the cost to work-hours is unbounded, and
>because I believe there may be a negative social cost associated with
>this action. Also, if Fedora/RHEL/SUSE/Ubuntu support a separate /usr
>partition, then this action could make Debian look inferior.
FWIW, Debian was the last holdout in still supporting a separate /usr
partition amongst major distributions, so that bit is irrelevant...
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#1000503: nbd FTBFS: configure.ac:371: error: required file 'man/nbd-client.8.sh.in' not found
Version: 1:3.23-3
On Wed, Nov 24, 2021 at 01:20:21PM +0200, Adrian Bunk wrote:
> Source: nbd
> Version: 1:3.23-2
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/logs.php?pkg=nbd=1%3A3.23-2
>
>
> configure.ac:371: error: required file 'man/nbd-client.8.sh.in' not found
> configure.ac:371: error: required file 'man/nbd-server.5.sh.in' not found
> configure.ac:371: error: required file 'man/nbd-server.1.sh.in' not found
> configure.ac:371: error: required file 'man/nbd-trdump.1.sh.in' not found
> configure.ac:371: error: required file 'man/nbdtab.5.sh.in' not found
> autoreconf: error: automake failed with exit status: 1
> dh_autoreconf: error: autoreconf -f -i returned exit code 1
>
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#996487: nbd-client: connects to localhost instead of the requested server
This is fixed in dc00a45a068f6520d554bcaf9bb61f52d7044e74
Don't look it up. Please don't look it up.
On Thu, Oct 14, 2021 at 07:59:27PM +0200, Adam Borowski wrote:
> Package: nbd-client
> Version: 1:3.22-1
> Severity: important
>
> Hi!
> Since a few days ago (ie, since 1:3.22-1 upload), nbd-client stopped working
> for me. stracing it shows:
>
> [pid 4166] socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
> [pid 4166] connect(3, {sa_family=AF_INET6, sin6_port=htons(10809),
> sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", _addr),
> sin6_scope_id=0}, 28) = 0
> [pid 4166] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(53150),
> sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", _addr),
> sin6_scope_id=0}, [28]) = 0
> [pid 4166] connect(3, {sa_family=AF_UNSPEC,
> sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
> [pid 4166] connect(3, {sa_family=AF_INET, sin_port=htons(10809),
> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> [pid 4166] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(50006),
> sin6_flowinfo=htonl(0), inet_pton(AF_INET6, ":::127.0.0.1", _addr),
> sin6_scope_id=0}, [28]) = 0
> [pid 4166] close(3)= 0
> [pid 4166] socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 3
> [pid 4166] connect(3, {sa_family=AF_INET6, sin6_port=htons(10809),
> sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", _addr),
> sin6_scope_id=0}, 28) = -1 ECONNREFUSED (Connection refused)
> [pid 4166] close(3)= 0
> [pid 4166] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
> [pid 4166] connect(3, {sa_family=AF_INET, sin_port=htons(10809),
> sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)
>
> ie, it tries to connect to the localhost via various means, instead of the
> server specified in /etc/nbdtab (2001:470:64f4::90).
>
> And indeed, if I set up a tunnel from localhost:10809 to the server, the
> connection succeeds.
>
> Downgrading to 1:3.21-1 fixes the issue.
>
>
> Meow!
> -- System Information:
> Debian Release: bookworm/sid
> APT prefers unstable
> APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
> Architecture: arm64 (aarch64)
>
> Kernel: Linux 5.14.0-2-arm64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_CRAP
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: OpenRC (via /run/openrc), PID 1: init
> LSM: AppArmor: enabled
>
> Versions of packages nbd-client depends on:
> ii debconf [debconf-2.0] 1.5.77
> ii libc6 2.32-4
> ii libgnutls303.7.2-2
> ii libnl-3-2003.4.0-1+b1
> ii libnl-genl-3-200 3.4.0-1+b1
>
> nbd-client recommends no packages.
>
> nbd-client suggests no packages.
>
> -- Configuration Files:
> /etc/nbdtab changed:
> nbd0 2001:470:64f4::90 cacodemon persist,timeout=3600
> nbd1 2001:470:64f4::90 mancubus swap,persist,timeout=3600
>
>
> -- debconf information:
> nbd-client/no-auto-config:
> nbd-client/killall_set:
>
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#994768: Homepage: field in control file outdated
Source: openstack-meta-packages Version: 0.31 Severity: minor The "homepage:" field in openstack-meta-packages points to openstack.alioth.debian.org, which no longer exists. This should probably be updated or removed. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, riscv64, armhf Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#992785: Please allow blacklisting a particular card reader
Package: pcscd Version: 1.9.1-1 Severity: wishlist Hi, My laptop has a builtin (i.e., impossible to remove or disable) smart card reader. It connects through USB. Unfortunately, it is broken: it continuously reports that a card is in the device (even when that is not the case). When something tries to read from the card, the only way for me to discover that things failed is in the fact that the read times out. Unfortunately my laptop's firmware does not allow me to disable it, which means I'd have to tell pcscd to ignore the reader; but I can't find any setting to do so. Please add an option to blacklist a particular card reader. Thanks, -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, riscv64, armhf Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pcscd depends on: ii init-system-helpers 1.60 ii libacsccid1 [pcsc-ifd-handler] 1.1.8-1 ii libc6 2.31-13 ii libccid [pcsc-ifd-handler] 1.4.34-1 ii libpcsclite11.9.1-1 ii libsystemd0 247.9-1 ii libudev1247.9-1 ii lsb-base11.1.0 pcscd recommends no packages. Versions of packages pcscd suggests: ii systemd 247.9-1 -- Configuration Files: /etc/init.d/pcscd [Errno 2] Bestand of map bestaat niet: '/etc/init.d/pcscd' -- no debconf information
Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages
On Fri, Aug 13, 2021 at 09:43:32AM -0700, Felix Lechner wrote:
> Hi,
>
> On Fri, Aug 13, 2021 at 9:12 AM Bill Allombert wrote:
> >
> > Then I would suggest that a new lintian category is designed to catter
> > for such usage, so that tools might chose not to display such warnings
> > as they do with 'P: pedantic' currently.
>
> I am not sure that helps. The tag 'outdated-standards-version' does
> not offer solutions to an obscure but undisputed deficiency. It
> states: "You are too slow."
I disagree with this assessment.
I think it rather says "things have changed since you last looked at
this package, there might be more things that are relevant for you now".
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#991204: exim4-daemon-heavy: Please add SPF support
Package: exim4-daemon-heavy Version: 4.94.2-6 Followup-For: Bug #528344 Perhaps important to note is that both DMARC and (currently still experimental, but...) ARC both depend on the builtin SPF support. While the SPF "support" by calling an external binary may work for SPF checks at a cost of a fork per ACL test (i.e., some performance penalty), this is not the case for the extra functionality that depends on the builtin SPF support, such as sending out DMARC validation reports, and adding ARC headers (to mitigate the issues with forwarding emails). Please seriously consider this wishlist item for bookworm already...
Bug#990026: Aaargh!
Whoever wrote that patch should be slapped around the head with a copy
of RFC3696.
Go read it. Now, please. Understand it. Internalize it. Then update your
data verification code so that all valid email addresses will be
accepted.
But first remove the "save_p" function from the cron implementation. It
is broken, and the fix may otherwise take too long, I suppose.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#983448: unblock: gridengine/8.1.9+dfsg-9.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package gridengine
[ Reason ]
gridengine was blocked on a gcc-10 FTBFS bug. I didn't notice this until
someone pointed it out to me in late January, and then I immediately set
out to create an NMU that fixes the issue, which I uploaded to the
DELAYED queue.
When I found out that my timing was off, I uploaded it again to the
regular queue, and did not think about it any more. Only later did I
notice that an upload of a package of the same version to the regular
upload queue does not override the pending upload in the DELAYED queue,
which meant the package entered unstable too late to still enter
testing before the freeze.
[ Impact ]
Since it's out of testing due only to a few missing "extern"
declarations (that caused FTBFS with gcc-10), users depending on
gridengine in buster won't be able to upgrade to bullseye.
[ Tests ]
I installed the gridengine packages on my laptop and confirmed basic
functionality.
[ Risks ]
Patches are very trivial; I only added this patch (plus changelog etc):
Description: Fix FTBFS with g++ 10
Author: Pierre Gruet
Bug-Debian: https://bugs.debian.org/957310
Forwarded: no
Last-Update: 2020-11-26
--- a/source/libs/japi/drmaa2_list_dict.h
+++ b/source/libs/japi/drmaa2_list_dict.h
@@ -10,7 +10,7 @@
struct _drmaa2_node *next;
} _drmaa2_Node;
-/* static */ struct drmaa2_list_s
+/* static */ extern struct drmaa2_list_s
{
_drmaa2_Node *head;
_drmaa2_Node *tail;
@@ -33,7 +33,7 @@
struct _drmaa2_dictentry_t* next;
} _drmaa2_dictentry_t;
-/* static */ struct drmaa2_dict_s
+/* static */ extern struct drmaa2_dict_s
{
_drmaa2_dictentry_t*head;
_drmaa2_dictentry_t*tail;
diff --git a/source/3rdparty/qmake/make.h b/source/3rdparty/qmake/make.h
index 46d523a4c..87e871bc6 100644
--- a/source/3rdparty/qmake/make.h
+++ b/source/3rdparty/qmake/make.h
@@ -348,7 +348,7 @@ extern int unixy_shell;
#endif
#ifdef SET_STACK_SIZE
# include
-struct rlimit stack_limit;
+extern struct rlimit stack_limit;
#endif
struct floc
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[ ] attach debdiff against the package in testing
(no debdiff against testing, because the package is not currently in
testing)
[ Other info ]
(Anything else the release team should know.)
unblock gridengine/8.1.9+dfsg-9.1
Bug#981677: offlineimap3: broken handling of self-signed certificates after upgrade to offlineimap3
Package: offlineimap3 Version: 0.0~git20210105.00d395b+dfsg-2 Severity: normal Hi, I have the following in my .offlineimaprc: remotehost = ... cert_fingerprint = ... ssl = yes Which used to work fine with offlineimap when it was running on python2. However, after the upgrade to the python3 version, I get: OfflineIMAP 7.3.0 Licensed under the GNU GPL v2 or any later version (with an OpenSSL exception) imaplib2 v3.05, Python v3.9.1+, OpenSSL 1.1.1i 8 Dec 2020 Account sync Test: *** Processing account Test Establishing connection to imap.grep.be:993 (Folk) ERROR: Unknown SSL protocol connecting to host 'imap.grep.be' for repository 'Folk'. OpenSSL responded: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate (_ssl.c:1123) *** Finished account 'Test' in 0:00 ... which is obviously not very useful. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, riscv64, armhf Kernel: Linux 5.10.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages offlineimap3 depends on: ii python3 3.9.1-1 ii python3-distro1.5.0-1 ii python3-imaplib2 2.57-5.2 offlineimap3 recommends no packages. offlineimap3 suggests no packages. -- no debconf information
Bug#981520: Adressing the concerns
Hi Alex Beckert, Thanks for the report and the suggestions. I'm developer for Minigalaxy and your concerns make sense. To address the suggested solutions. Using an external browser for authentication is unfortunately not possible with Minigalaxy, because after the login Minigalaxy takes the page URL to get the code which is used to authenticate with the API. With an external browser retrieving this would not be possible. Showing the URL of the browser window could be implemented. Some additional information about how the systems works at the moment: - It uses the girl1.2-webkit2-4.0 package for the webkit engine. - It uses HTTPS for all API calls and for the login screens. In the code you can see HTTPS is used here: https://github.com/sharkwouter/minigalaxy/blob/1.0.1/minigalaxy/api.py Having said all that, this does not seem like a security issue to me. Authentication happens using the same page the official GOG client for Windows does. The user could be concerned, but there does not seem to be an actual security risk. Hopefully this helps understand how Minigalaxy does authentication a bit better and makes you feel less worried. An issue has been created in our issue tracker to address the visibility of the URL in the browser window. Kind regards, Wouter Wijsman
Bug#978636: move to merged-usr-only?
On Tue, Jan 26, 2021 at 12:28:45AM +0100, Marco d'Itri wrote: > Also, as is has been discussed, if the /usr/doc/ transition was > representative then this would probably take many years. You keep using that as an argument. I think it's very disinginuous to point to a problem Debian had over 20 years ago[1] and say "look, we don't know how to do this quickly". It's not like things haven't changed since. We can (and should, IMO) declare *today* that for bookworm, shipping files in / (as opposed to /usr) that are not compatibility symlinks will be RC. You can start writing a lintian check today for the same. If we take both these steps, this will only take us one release cycle, and the dpkg maintainers can come up with a plan to remove /bin and friends and replace them by symlinks in ways that will not confuse dpkg. [1] the /usr/doc transition was in progress when I first joined Debian, 20 years ago. I don't remember the start of it, but I do remember it ending. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#980849: apt fails to reject repositories with invalid InRelease file
Hi David, On Sun, Jan 24, 2021 at 05:17:14PM +0100, David Kalnischkies wrote: > On Sat, Jan 23, 2021 at 09:35:12AM +0200, Wouter Verhelst wrote: > > Currently, there are two merge requests open[3] for repositories on > > which my script fails while trying to verify the InRelease file. > > > > It turns out that these repositories return data for the InRelease file > > -- i.e., a file that has checksums and is signed by some tool -- but the > > signature is invalid. The repository also has a Release/Release.gpg > > pair, where the signature *is* valid. > > Merge request 66 repository results in this 'apt update' output for me: > | […] > | Err:3 https://adoptopenjdk.jfrog.io/adoptopenjdk/deb buster InRelease > | The following signatures were invalid: ERRSIG 8AC3B29174885C03 > | Reading package lists... > | W: GPG error: https://adoptopenjdk.jfrog.io/adoptopenjdk/deb buster > InRelease: The following signatures were invalid: ERRSIG 8AC3B29174885C03 > | E: The repository 'https://adoptopenjdk.jfrog.io/adoptopenjdk/deb buster > InRelease' is not signed. > | N: Updating from such a repository can't be done securely, and is therefore > disabled by default. > | N: See apt-secure(8) manpage for repository creation and user configuration > details. > > So please give us the actual configuration and output apt produces for > you if you suspect a bug (reportbug should help you with that). Since I didn't actually enable that repository on my laptop, that wouldn't work :) But yeah, I suppose I should indeed have tried things out first. Sorry about that. Also, it looks like the repository has changed since; when I tried it before filing this bug, it would validate correctly if I skipped the InRelease file and only checked the Release/Release.gpg files. Can't help it if people break their stuff, of course ;-) (but then perhaps that might have been another case of the same issue as MR 66) > Merge request 65 repository is a fun one as apt actually accepts > the InRelease as valid, even though throwing it directly at gpg does > indeed indicate a bad signature – gpg is not telling what is bad about > this signature through: The class of this signature. The signature is > of the binary class, which clearsigned text is not by definition. > > apt doesn't feed the InRelease file to gpg directly though: It first > splits the file in two – creating files akin to Release and Release.gpg > – and passes those to gpg. A signature for a binary file is valid in > that context – and successfully passes verification by gpg. Oh, I wasn't aware of that. Thanks for informing me. I guess that means I need to update my validation tool then :) > We do this as we work with the Release internally and we want to be sure > that the data we see is what was signed as we run the risk of either us > or gpg being tricked into parsing the InRelease differently and hence > seeing and acting on [unsigned] different data (it happened before). Makes sense. [...] > > Apt should probably produce a warning (if not an error) on such > > repositories; it currently does not seem to do that. > > We could implement a check for that I presume, but I am not particular > keen on parsing the different signature packet formats out of the base64 > encoding just so we can complain about something that is technically no > problem for us even if that is of course not a supported interface but > a reliance on an implementation detail which could change any minute > (in theory at least) and is likely a problem for clients with > a different implementation. That seems more like the job of a linter… > > There are btw reasons a seemingly invalid InRelease file is ignored and > we continue on to use a Release + Release.gpg pair without producing an > error or a warning (except an Ign line in update output): Some servers > e.g. send file not found pages with "200 OK". In that case, gpgv will report gpgv: no valid OpenPGP data found gpgv: the signature could not be verified which is different from [GNUPG:] NEWSIG [GNUPG:] KEY_CONSIDERED ... [GNUPG:] BADSIG ... For clarity, what I mean to say is that if the signature exists but is invalid on the InRelease file (while the Release.gpg file contains a valid signature) then you have a repository that is signed both correctly and incorrectly. This is not the same thing as a repository that is signed correctly and that returns junk instead of some other possible signature. If the repository is signed both correctly and incorrectly, then which of the two is correct? You may have had an attacker who replaced software in your repository with an older, vulnerable, version of the same software, but was thrown out before they could complete their attack (or they messed up). I'm not saying that apt should always check t
Bug#980849: apt fails to reject repositories with invalid InRelease file
Package: apt Version: 2.1.18 Severity: important Hi, I maintain the extrepo package[1], a tool to manage external (i.e., third-party, non-Debian) repositories. As part of that, the extrepo-data repository on salsa[2] manages metadata for repositories. In a GitLab CI job, I validate that the repositories do not contain anything that is not valid before accepting them to the metadata repository. One of the checks is to validate the InRelease file. Currently, there are two merge requests open[3] for repositories on which my script fails while trying to verify the InRelease file. It turns out that these repositories return data for the InRelease file -- i.e., a file that has checksums and is signed by some tool -- but the signature is invalid. The repository also has a Release/Release.gpg pair, where the signature *is* valid. Apt should probably produce a warning (if not an error) on such repositories; it currently does not seem to do that. [1] https://packages.debian.org/extrepo [2] https://salsa.debian.org/extrepo-team/extrepo-data [3] https://salsa.debian.org/extrepo-team/extrepo-data/-/merge_requests/65 and .../66
Bug#980739: gnome-terminal: Maximizing a window and restoring results in a smaller window
Package: gnome-terminal Version: 3.38.1-2 Severity: normal When starting a gnome-terminal window, the terminal defaults to a 80 columns by 24 lines terminal window. Maximizing that on my FullHD monitor results in whatever fits in the display. Restoring that back to the "regular" size then results in a 79x23, rather than a 80x24, terminal window. This can be repeated, until the window has 47 columns and 3 lines, at which point the window no longer resizes smaller. In case it is relevant, I changed my profile so that I have a 9pt monospace font. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, riscv64, armhf Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-terminal depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.20-1 ii dbus-x11 [dbus-session-bus] 1.12.20-1 ii dconf-gsettings-backend [gsettings-backend] 0.38.0-1 ii gnome-terminal-data 3.38.1-2 ii gsettings-desktop-schemas 3.38.0-2 ii libatk1.0-0 2.36.0-2 ii libc6 2.31-9 ii libdconf1 0.38.0-1 ii libglib2.0-0 2.66.4-1 ii libgtk-3-03.24.24-1 ii libpango-1.0-01.46.2-3 ii libuuid1 2.36.1-5 ii libvte-2.91-0 0.62.1-1 ii libx11-6 2:1.7.0-2 Versions of packages gnome-terminal recommends: ii gvfs 1.46.1-2 ii nautilus-extension-gnome-terminal 3.38.1-2 ii yelp 3.38.2-1 gnome-terminal suggests no packages. -- no debconf information
Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages
On Mon, Jan 11, 2021 at 09:07:03PM +, Matthew Vernon wrote: > [0] to that end, orphan-sysvinit-scripts is in NEW, Glad you're taking that route. I had been thinking of other things to suggest that would make your life easier while allowing maintainers to drop init scripts if they so desire, but I couldn't really come up with anything better than that (except for a few very convoluted things that don't really improve the situation). > and while I hope your ruling will not result in a bonfire of perfectly > good init scripts, I hope that maintainers who decide to ditch them > will let us know so we can add them there Maybe talk to debian-policy to come up with some wording to be added to either the developer's reference or policy that discourages dropping init scripts, but encourages talking to the maintainers of orphan-sysvinit-scripts if for whatever reason it ends up being necessary? -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hi Sam, On Sun, Dec 27, 2020 at 10:05:37AM -0500, Sam Hartman wrote: > >>>>> "Wouter" == Wouter Verhelst writes: > Wouter> On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote: > >> I think that we should either decide that > >> > >> 1) NetworkManager should support elogind > >> > >> or > >> > >> 2) That we haven't seen enough development of alternatives to > >> systemd and the project consensus on the GR has changed. > > Wouter> Personally, I think both of these options are terrible and > Wouter> will fail to fix the situation long term. > > You then go on to talk about init scripts. If that is what you took away from my email, then I should probably have written it differently so my message was clearer. Apologies about that. I don't think that either elogind or init scripts are really the heart of the matter here. What matters is that there are two opposing visions about what Debian should become, that both these visions have valid technical needs, and that deciding that we have to go with one or the other isn't going to solve the issue; people will continue talking about wanting to do what they want to do. Debian isn't Fedora. Fedora has a "steering committee" (FESCo) which decides on what to use in the future, and their word is final. If you want to do something in Fedora that FESCo decided against, you're out of luck. It means far less arguments, and there is something to be said for doing things that way, but historically, it's not what Debian has done. In my opinion, this diversity is one of our strengths, and making a decision either way like you suggest is not going to help anyone. > I found that really frustrating because I was talking about elogind, > not init scripts. Honestly, I don't think you can realistically do that. The no-systemd people don't actually care about elogind; they only want it because there is software out there which requires an interface provided by logind, and elogind provides the same interface outside of systemd, and so you can theoretically run NetworkManager without systemd if you install elogind, or something along those lines. So while making a decision about elogind may solve the bug at hand, it doesn't really address the bigger issue, and then if we do that we'll be back here in six months. Perhaps that's all we can do, but I do think it's worth pointing out that it will happen. As far as "developing alternatives" go: as I understand it, the end goal for no-systemd people is not "something that doesn't exist yet". Instead, the end goal is "we want to use what we have been using a long time and what we thinks works just fine and we don't want this newfangled mess, thank you very much". By allowing them to use elogind but not init scripts, and then telling them that they have to write something not-initscripts and also not-systemd if they want to move forward within Debian, you're not saying something they want to hear. That is, unless your end goal is to tell them to go do their thing somewhere outside of Debian (which would be a valid position if it happens to be how you feel about the issue, but it's not one I share). In other words, I think the two are entangled, and I don't think you can decide to only handle one of the two if you want to solve the issue at hand. (however, it is certainly possible to provide different solutions for the two; e.g., you can say that the maintainer should add elogind as an alternative dependency, but that init scripts should be elsewhere, in a package maintained by no-systemd people) > My reasoning doesn't apply to init scripts, I never said it did, and I > even gave entirely different reasoning about init scripts because I > don't think the text you quoted is a good place to think about init > scripts. My reasoning is that init scripts are the end goal, and that elogind is just a symptom of that end goal, and that therefore talking about elogind in isolation serves no purpose. > The GR, policy, and our discussions treat elogind and init scripts > differently. I support the consensus of debian-policy, the and the > majority of project members who voted in the GR in treating these issues > differently. I don't think that's actually the case; but the vote was rather muddled because some options on the ballot were written by people who didn't actually support the position they were writing, so I can't say for sure. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote: > I think that we should either decide that > > 1) NetworkManager should support elogind > > or > > 2) That we haven't seen enough development of alternatives to systemd > and the project consensus on the GR has changed. Personally, I think both of these options are terrible and will fail to fix the situation long term. There are people in Debian who would rather not see that they have to carry init scripts in their packages. For better or for worse, these init scripts are a relic of the past for such people, and they do not want to have to work on them. And while Debian does have some ways of collaborating across package boundaries, it's not really something we are very good at, culturally. Given that the GR has given init scripts lower priority nowadays, dropping the init script is not an RC bug anymore, and therefore people in this group feel that it's just fine to drop their init scripts and let people who care about alternatives deal with the fallout of that. At the same time, there are people in Debian who would rather not run systemd on their systems, and who want to put in the work to make sure that some alternative (of whatever form they prefer) is usable and available in Debian. These developers seem willing to fix bugs when they appear, but for reasons they've explained elsewhere in the thread are unwilling to group all the sysvinit-specific stuff in a single package and deal with it that way. It feels to me that any solution that prescribes that people in the first group need to do something which means they can't actually drop the init scripts, or alternatively any solution which does not provide a clear way forward for people in the second group on how they will be able to do what they would like to achieve, is doomed to failure. People in the first group are not going to magically change their mind and want to put in the work. Any solution that prescribes that they have to will fail the constitutional requirement that nobody can be forced to do anything they do not want. People in the second group are not going to magically change their mind and want to stop using something not systemd. Any solution that prescribes that they have to will fail the very same constitutional requirement. I think whatever the TC comes up with will need to incorporate the valid needs and wants of both groups if it is going to succeed in settling the argument. Both the solutions which you suggest fail to meet this bar, from where I'm standing. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#964496: libjson-validator-perl: URL is gone, this is now RC
Control: tags -1 + pending thanks Hi Andrius, On Wed, Dec 09, 2020 at 09:29:01AM +0200, Andrius Merkys wrote: > Hi Wouter, > > I have uploaded libjson-validator-perl with cache links for OpenAPI > schemas. Please upload sreview-web 0.6.1-2 without the obstructing cache > files. Yeah. That was meant as a temporary local hack so I could test my package. I never intended to upload it... *blush*. I've actually already fixed it (https://salsa.debian.org/debconf-video-team/sreview/-/commit/a0f09046da82cd5319f71708343b8db0fc3192c8), but there's still a few unrelated issues that I need to try and get resolved before I can upload. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#964496: libjson-validator-perl: URL is gone, this is now RC
Hi Andrius, On Mon, Nov 30, 2020 at 01:00:46PM +0200, Andrius Merkys wrote: > Hello, > > On 2020-11-29 18:59, Wouter Verhelst wrote: > > This bug is still present. Additionally, the URL for the OpenAPI JSON > > scheme now returns a 404 error, which means that any software using > > OpenAPI on Debian with this bug present will fail to function correctly.> > > Please fix this bug before the release of bullseye. > > While I agree that this is an important issue, I do not think severity > "serious" is appropriate here. It is true that the upstream provides > caching mechanism, but any URL may become offline, and a general > approach to prevent failures in such cases is to use Debian-packaged > files. ... which is exactly what this bug report is talking about, so I don't understand? > With OpenAPI schemas provided in openapi-specification binary > package, this is as simple as replacing OpenAPI URLs with > /usr/share/openapi-specification/schemas/$VERSION/schema.json in the > using code. Unfortunately, that doesn't work very if the code in question is also packaged (because upgrades would blow those changes away, yada yada). > The upstream caching mechanism could indeed be employed, but as said > before [1], preferable way to use it needs transparency of cache hashes. > > By the way, could you please provide OpenAPI URL that returns 404 now? That would be https://spec.openapis.org/oas/3.0/schema/2019-04-02 -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#964496: libjson-validator-perl: URL is gone, this is now RC
Package: libjson-validator-perl Version: 4.10+dfsg-1 Followup-For: Bug #964496 Control: severity -1 serious This bug is still present. Additionally, the URL for the OpenAPI JSON scheme now returns a 404 error, which means that any software using OpenAPI on Debian with this bug present will fail to function correctly. Please fix this bug before the release of bullseye.
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Thu, Nov 19, 2020 at 09:04:07AM +, Matthew Vernon wrote: > [I don't need a CC, thanks] > Hi, > > > I know it was mentioned back in the day, but trying to re-ask it now: > > Wouldn't it be possible to ship init scripts for compatibility purposes > > from a sysvinit (or maybe a sysvinit-support) package? This would be the > > inverse of what happened back when systemd was introduced, which was > > about shipping service files that superseded existing init scripts. > > I have thought about this, and it seems like a bad idea for a number of > reasons, including: > > 1) poor user experience - a package of initscripts would clutter > /etc/init.d/ with a huge number of files (most of which would be no use to > the user) This could be fairly easily fixed. Option one: - Don't install the init scripts in /etc/init.d, but install them in /usr/share somewhere. - Install a dpkg trigger that uses ucf to copy the relevant init scripts /etc/init.d (and goes through the rest of the dance to enable them) when the relevant package(s) is/are installed. Option two: split up the initscripts package into multiple smaller packages. I don't think either of these are necessary, but if it's a concern, there are ways. > 2) init scripts to need to change sometimes, typically that change will > accompany a version change in the associated daemon (e.g. the CLI changes) - > the most natural way to have this work seamlessly is for the init script to > come with the daemon This puts the burden of maintaining said init script on the maintainer. In my reading of the GR, that's not expected of maintainers anymore. I think it's fair for a maintainer to be expected to file a bug on an "init scripts" package if their CLI changes. The rest should then be the job of the maintainers of that init scripts package. > 3) many upstreams (esp. those who support BSD) ship a sysvinit file, again > making the daemon (source at least) package the natural place to keep it. Yes, but does this also apply to network manager? > 4) difficulty reliably achieving seamless handoff from daemon package to a > putative sysvinit-scripts package (e.g. packages that actively remove the > init.d file from the installed system; keeping a users' modifications to the > file) This might need some dependency trickery that I don't immediately have a good answer for, but that I don't see as insurmountable. Furthermore, it is my belief that if you are not running the default init system, that then *some* level of ugliness is to be expected. At the very least, you'd see systemd units on the file system that you're not ever going to be using. I think it's unreasonable to expect the same level of cleanliness and technical excellence as when your preferred init system was still the Debian default. > > I understand that you might not want that maintenance burden, however it > > seems like the network-manager maintainers might not want that > > maintenance burden either. > > I think the burden concern is over-made here. This is not a case of "this > init script has bugs that have been causing problems and no-one has fixed > it", nor a bug report of the form "please write an init script". There is an > extant, working init script. Software changes. Environments change. Sometimes an init script stops working due to changes outside the maintainer's area of responsibility. This has happened to the nbd-client init script at one point, for example (no bug, because I found it out myself and fixed it, but it did happen). Thus, maintaining an init script that the maintainer themselves doesn't want to use or think is useful, imposes a burden of *at least* testing it on the maintainer, for which they need a separate system (or, at least, a VM) in order to do proper testing of the package with all that implies. That's actually quite a bit of work, and it's not unfair that the maintainer wouldn't want to do it. If the init script is in the network-manager package, then the maintainer is at the very least *expected* to make sure it keeps working. If it stops working, where is the maintainer going to ask for help? There is no guaranteed answer for the maintainer, and nothing they can do other than accept bugs against their package that they then have to set up a wholly separate system for just so they can fix a bug they don't want to deal with in the first place. If the init script is in a separate package, then the maintainer can certainly give a heads-up to the maintainers of the separate package when something changes in network-manager. It would not be unreasonable to expect the network-manager maintainer to maintain a level of communication with the maintainers of said initscripts package, and I think you would have a *much* stronger case for complaining about maintainers not wanting to support your pet project. > There are people more than happy to provide assistance should it need > updating. I concede that collaborating with those people is non-zero > effort,
Bug#947847: Fwd: Bug#946456: systemd: Provide systemd-sysusers as an independent package
On Wed, Oct 07, 2020 at 09:53:06PM +0200, Michael Biebl wrote:
> Forwarding this to the CTTE, just in case they have some input on this
> proposed plan.
>
>
> Weitergeleitete Nachricht
> Betreff: Re: Bug#946456: systemd: Provide systemd-sysusers as an
> independent package
> Datum: Wed, 7 Oct 2020 18:21:39 +0200
> Von: Michael Biebl
> An: 946...@bugs.debian.org, Felipe Sateler , Ansgar
> , Niels Thykier
>
> A small update here:
> v246 provides a build switch -Dstandalone-binaries=true:
> `
> option('standalone-binaries', type : 'boolean', value : 'false',
>description : 'also build standalone versions of supported binaries')
> `
>
> Atm, those supported binaries are systemd-tmpfiles and systemd-sysusers.
> Those binaries do not link against libsystemd-shared and have minimal
> dependencies.
>
> Fedora decided to ship those binaries in separate binary packages named
> systemd-standalone-sysusers and systemd-standalone-tmpfiles, which
> conflict with the main systemd package, i.e. the main systemd package
> will continue to ship systemd-tmpfiles and systemd-sysusers linking
> against libsystemd-shared.
>
> I like this approach and think we should do the same in Debian.
> Users, which have the full systemd package installed don't have any
> negative side effects, which could result from splitting out
> systemd-tmpfiles/systemd-sysusers and libsystemd-shared.
>
> Restricted/non-systemd environments, like containers, can use
> systemd-standalone-sysusers and systemd-standalone-tmpfiles with minimal
> dependencies.
>
> We could debate whether systemd-standalone-tmpfiles and
> systemd-standalone-sysusers should be provided by a single binary
> package, but since Fedora has already done this split this way, I would
> simply follow here and use the same binary package names.
> The relevant Fedora PR is
> https://src.fedoraproject.org/rpms/systemd/pull-request/27 fwiw.
>
> Thankfully, -Dstandalone-binaries=true doesn't require a separate, third
> build variant (as with the udeb flavour), so build times shouldn't go up.
>
> If there are no objections to this approach I would proceed and
> implement it like this:
> - Build systemd with -Dstandalone-binaries=true
> - Install the standalone binaries in binary packages named
> systemd-standalone-sysusers and systemd-standalone-tmpfiles
> - Those binaries packages would only ship /bin/systemd-sysusers resp.
> /bin/systemd-tmpfiles and have a Conflicts/Replaces: systemd
Probably stating the obvious here, but just in case:
Both systemd and the proposed new packages should also have a
"Provides:" header with something common so that packages that try to
use systemd-tmpfiles and/or systemd-sysusers can depend on that
something without requiring a 'Depends: systemd |
systemd-standalone-tmpfiles'?
--
To the thief who stole my anti-depressants: I hope you're happy
-- seen somewhere on the Internet on a photo of a billboard
Bug#969084: Added that
FYI: I added a "policy-rcd-declarative-deny-all" package that contains an alternative default policy denying all service startup requests. As soon as it passes my tests, I'll upload that to unstable. You might want to update the script then to install policy-rcd-declarative-deny-all (which depends on policy-rcd-declarative) and drop the manual policy config file. If wanted, I could also upload this to backports? Regards, -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#968226: Build-Depends-If-Available
On Tue, Aug 11, 2020 at 10:05:42AM -0700, Russ Allbery wrote: > Wouter Verhelst writes: > > > -policy: this is a question that has come up before > > (https://lists.debian.org/debian-devel/2016/12/msg00470.html is another > > example that springs to mind, but I'm pretty sure there are more), so I > > think we should document in Policy that a) buildd only looks at the > > first dependency in alternative build-dependencies, and b) why this is > > the case. > > Policy already says: > > While Build-Depends, Build-Depends-Indep and Build-Depends-Arch permit > the use of alternative dependencies, these are not normally used by > the Debian autobuilders. To avoid inconsistency between repeated > builds of a package, the autobuilders will default to selecting the > first alternative, after reducing any architecture-specific > restrictions for the build architecture in question. While this may > limit the usefulness of alternatives in a single release, they can > still be used to provide flexibility in building the same package > across multiple distributions or releases, where a particular > dependency is met by differently named packages. > > in 7.1. However, it's hidden in a footnote. Perhaps we should make it > more prominant (and make it clear that it's normative), and tweak the > wording. Thanks, yeah, I missed that. I'll have a stab at a patch some time soon (probably after debconf though) -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#968219: ITP: openpbs -- An HPC workload manager and job scheduler for desktops, clusters, and clouds.
On Tue, Aug 11, 2020 at 03:28:30AM +, Mo Zhou wrote: > Package: wnpp > Severity: wishlist > Owner: Mo Zhou > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: openpbs > Version : 20.0.1 > Upstream Author : Name > * URL : http://www.example.org/ > * License : AGPL-3 > Programming Lang: C, python, shell > Description : An HPC workload manager and job scheduler for desktops, > clusters, and clouds. > > I'm wondering why it is absent in debian. My guess: slurm and gridengine exist in Debian and are "good enough", whereas PBS has been going through some upstream switches/forks a few times over the past few years? Could be my misunderstanding though. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#968226: Build-Depends-If-Available
Package: debian-policy On Sun, Aug 09, 2020 at 06:28:50PM +0100, Barak A. Pearlmutter wrote: > I understand what you're saying, and indeed trying to encode > "Build-Depends-If-Available: foo" as "Build-Depends: foo | something" > is a bad idea from the get-go. After all, foo can have three states on > an architecture: installable, unavailable, or > available-but-uninstallable-for-some-reason. And we want different > behaviour in the three cases: build with it, build without it, or > delay-building-until-installable. And we can't shoehorn those three > things into the binary logic of "foo | something". Exactly, and therein lies the problem. Buildd used to consider alternative build-dependencies, and it caused a never-ending stream of package transition entanglements, because the delay-building-until-installable thing never happened, which meant that every rebuild of something to solve a problem would have to either be timed very well, or would be likely to be playing a roulette game of "will the rebuild solve all problems or create yet even more". -policy: this is a question that has come up before (https://lists.debian.org/debian-devel/2016/12/msg00470.html is another example that springs to mind, but I'm pretty sure there are more), so I think we should document in Policy that a) buildd only looks at the first dependency in alternative build-dependencies, and b) why this is the case. Suggestion: ---8<--- Note that sbuild, the program which builds packages on each of Debian's architectures, only considers the first alternative for any declared element in the Build-Depends: header, after removing alternatives with architecture restrictions that don't apply to the architecture on which the package is building. All other alternatives are ignored by sbuild. This is done so that package dependencies are predictable; previously, sbuild would consider alternative dependencies, but it made binary package dependencies change based on whether a particular package happened to be installable on unstable at the time of a package rebuild. These changes were unpredictable, and made handling transitions harder than they needed to be. --->8--- Not sure in which section to place this though. Thoughts? -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#967949: ITP: ipqalc -- graphical utility for IPv4 subnet calculation
On Wed, Aug 05, 2020 at 12:03:12PM -0300, Fabio Augusto De Muzio Tobich wrote: > Package: wnpp > Severity: wishlist > Owner: Fabio Augusto De Muzio Tobich > X-Debbugs-Cc: debian-de...@lists.debian.org, ftob...@gmail.com > > * Package name: ipqalc > Version : 1.5.3 > Upstream Author : Alexander Danilov > * URL : https://bitbucket.org/admsasha/ipqalc > * License : GPL-3+ > Programming Lang: C++ > Description : graphical utility for IPv4 subnet calculation > > Small utility for IP address calculations including broadcast and network > addresses as well as Cisco wildcard mask. > > >From a given IPv4 address calculates broadcast, network, Cisco wildcard mask, > and host range. It can also be used as a teaching tool and presents the > results in binary, and hex, values. How does it differ from sipcalc? (not that I want to say you shouldn't upload this, just interested) -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#955999: openmsx: Issues with pressing multiple keys
Hi, You can diagnose the issue like this: - open the openMSX console (F10) - execute the command: set kbd_trace_key_presses true - close the openMSX console (F10 again) Each key press/release now generates a log line on stderr. Those should appear in the terminal from which you started openMSX. These log lines are pretty close to the events we receive from SDL. So if it's already wrong in the log the issue is likely located in SDL itself. if the log looks fine, then we might be able to fix it in openMSX. Wouter On Mon, Apr 6, 2020 at 9:15 PM Manuel Bilderbeek < manuel.bilderb...@gmail.com> wrote: > Hi, > > On 06-04-2020 13:54, Jesús Barrado Varela wrote: > > > Can you confirm the problem doesn't occur by compiling a previous > > > version and trying that? > > I've tried the following today: > > * On Debian 10 Buster the bug is present on version 0.15.0-2. > > * On Debian 10 Buster the bug is present on version 0.13.0-1 (the > > version found in Stretch repos). > > * On Debian 9 Stretch the bug is *not* present on version 0.13.0-1. > > * On Ubuntu 18.04 the bug is *not* present on version 0.14.0-2. > > On all these cases, did you try with full screen, consistently? > > > I've also noticed today that the bug is only present under Buster when > > playing fullscreen (pressing the F12 key). Maybe it's an SDL bug? > > Does it make a difference to go to fullscreen by typing in the console > (open with F10): > set fullscreen on > ? > > I still can't reproduce the issue on 0.15.0-2+b1. > > If you reproduced consistently in the same way, and in one 0.13.0-1 it > occurs and in the ther 0.13.0-1 it does not occur, then I doubt it's a > bug in openMSX. > > -- > Kind regards, > > Manuel > >
Bug#955551: openmsx ftbfs on ppc64el and s390x
Hi,
I think the problem occurred on big-endian systems. Are ppc64el and s390x
indeed big-endian? (IOW does the openMSX build system correctly detects
this?)
I pushed a fix upstream:
https://github.com/openMSX/openMSX/commit/0c259566e5f7a9597369b66c03d957ba7d37e5d1
This patch makes the big- and little-endian code paths more similar (it
only keeps the essential differences).
I think this will fix the problem. But I have not been able to test-compile
this myself.
Thanks for reporting.
Wouter
On Thu, Apr 2, 2020 at 3:09 PM Matthias Klose wrote:
> Package: src:openmsx
> Version:
> Severity: serious
> Tags: sid bullseye
>
> openmsx ftbfs at least on ppc64el and s390x with
>
> src/utils/small_compare.hh: In instantiation of ‘struct ScValBe int,
> '\357', '\273', '\277'>’:
> src/utils/small_compare.hh:88:41: required from ‘struct ScVal int,
> '\357', '\273', '\277'>’
> src/utils/small_compare.hh:100:37: required from ‘const type
> SmallCompare<'\357', '\273', '\277'>::mask’
> src/utils/small_compare.hh:110:20: required from ‘bool
> small_compare(const
> char*) [with char ...Ns = {'\357', '\273', '\277'}]’
> src/utils/rapidsax.hh:208:34: required from ‘bool
> rapidsax::internal::next(const char*) [with char C0 = '\357'; char C1 =
> '\273';
> char C2 = '\277']’
> src/utils/rapidsax.hh:353:51: required from here
> src/utils/small_compare.hh:84:41: error: narrowing conversion of ‘-1’ from
> ‘int’
> to ‘unsigned int’ [-Wnarrowing]
>84 | template struct ScValBe : ScValBeImpl 0, -1,
> Ns...> {};
> | ^~~
> src/utils/small_compare.hh: In instantiation of ‘const type
> SmallCompare<'\357',
> '\273', '\277'>::mask’:
>
> and
>
> src/utils/small_compare.hh: In instantiation of ‘const type
> SmallCompare<'t',
> ';'>::value’:
> src/utils/small_compare.hh:110:32: required from ‘bool
> small_compare(const
> char*) [with char ...Ns = {'t', ';'}]’
> src/utils/rapidsax.hh:204:30: required from ‘bool
> rapidsax::internal::next(const char*) [with char C0 = 't'; char C1 = ';']’
> src/utils/rapidsax.hh:281:22: required from ‘char*
> rapidsax::internal::skipAndExpand(char*&) [with StopPred =
> rapidsax::internal::AttPred1; StopPredPure =
> rapidsax::internal::AttPurePred1;
> int FLAGS = 2]’
> src/utils/rapidsax.hh:704:52: required from ‘void
> rapidsax::internal::Parser::parseAttributes(char*&, bool)
> [with
> int FLAGS = 2; HANDLER = openmsx::XMLLoader::XMLElementParser]’
> src/utils/rapidsax.hh:387:3: required from ‘void
> rapidsax::internal::Parser::parseDeclaration(char*&) [with
> int
> FLAGS = 2; HANDLER = openmsx::XMLLoader::XMLElementParser]’
> src/utils/rapidsax.hh:575:5: required from ‘void
> rapidsax::internal::Parser::parseNode(char*&) [with int
> FLAGS =
> 2; HANDLER = openmsx::XMLLoader::XMLElementParser]’
> src/utils/rapidsax.hh:377:4: required from
> ‘rapidsax::internal::Parser HANDLER>::Parser(HANDLER&, char*) [with int FLAGS = 2; HANDLER =
> openmsx::XMLLoader::XMLElementParser]’
> src/utils/rapidsax.hh:731:35: required from ‘void
> rapidsax::parse(HANDLER&,
> char*) [with int FLAGS = 2; HANDLER =
> openmsx::XMLLoader::XMLElementParser]’
> src/config/XMLLoader.cc:46:64: required from here
> src/utils/small_compare.hh:99:37: error: ‘value’ is not a member of
> ‘SmallCompare<'t', ';'>::C’ {aka ‘ScVal’}
>99 | static const typename Loader::type value = C::value;
> | ^
> make[2]: *** [build/main.mk:531:
> derived/s390-linux-debian/obj/config/XMLLoader.o] Error 1
>
>
Bug#955472: xnee: Please build the GUI components
Package: xnee Version: 3.19-3 Severity: wishlist Hi, xnee comes with two GUI components: gnee, a GUI version of cnee, and pnee, a Gnome applet. At least gnee seems to compile just fine on my buster system. However, neither of these two are shipped as part of the Debian package. Please fix that ;-) -- System Information: Debian Release: 10.3 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, riscv64, armhf Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xnee depends on: ii cnee 3.19-3 xnee recommends no packages. xnee suggests no packages. -- no debconf information
Bug#954138: Should not download indexes for architectures that are not enabled
On Tue, Mar 17, 2020 at 04:39:58PM +0100, David Kalnischkies wrote: > It is possible that I completely misunderstood you though as I basically > ignored your first example (and bugtitle) as it makes no sense to me and Yes, sorry; I guess my mind got a better handle on what I was trying to say as I was writing the message, and then forgot to update the earlier messages. > focused on the later examples… Why should someone configure a list of > architectures in sources.list they do not want to be downloaded? That is > like the freaking point of configuring the list in sources.list compared > to just letting apt decide which architectures to download (based on > what dpkg could process by default). The problem is that apt will produce warning messages if the list of architecture indexes it tries to download from a repository is not a strict subset of the list of available architectures at that repository. If I say "dpkg --add-architecture riscv64", then apt will try to download riscv64 indexes from *all* my configured repositories, including those that do not carry riscv64, and produce a warning message for those that do not carry it. The only way to stop apt from issuing those warnings (that I can see) is to add explicit configuration for those repositories to list the architectures that it does support. I try to do that with extrepo[1], as I think it is bad form to write configuration files that will produce warning messages. However, the result is now that I create configuration files which may say things like "Architectures: i386 amd64 ppc64el" even on systems which do not have one or more of those architectures enabled as foreign architectures. While this will not produce warning messages, it does result in a waste of bandwidth. I guess what I want is for a way to avoid the warning messages? "Yes, apt, these architectures are not expected to be there, leave that as is now, kthxbye". [1] https://packages.debian.org/extrepo -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Bug#954138: Should not download indexes for architectures that are not enabled
Package: apt Version: 1.8.2 Severity: wishlist Control: block 947244 by -1 thanks Hi, (filing against the version in stable because I can reproduce it there and my unstable machine is broken at the moment so I can't verify that it still exists in unstable, but presumably this should not be fixed in stable...) The "Architectures:" key in a .sources file (or the "arch=" in a .list file) defaults to the value of APT::Architectures, which defaults to the architectures enabled on the system. However, when an explicit list of architectures is configured for a repository, then this overrides the default value, regardless of whether the extra architectures are enabled for the system. It is possible to modify the default by way of Architectures-Add and Architectures-Remove, but that requires knowledge of which architectures are enabled on the system. It would be useful to have a configuration value that says "this repository has these architectures available" (let's say we call that "Architectures-Available:"), so that if, say, APT::Architecture contains "i386 amd64 riscv64", and "Architectures-Available" contains "i386 amd64", the result would be as though "Architectures-Remove: riscv64" were specified; but if "Architectures-Available" instead contains "i386 amd64 riscv64 armhf", then the result would be as though no Architectures-* keys were specified at all, and indexes files for i386, amd64, and riscv64 (but not armhf) will be downloaded. The alternatives currently are to either produce a warning message that a particular architecture is not enabled for a repository, to download more than is needed, or to create a configuration file that depends on state outside of the configuration file itself, which for a tool like extrepo is suboptimal. Thanks for considering, -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Bug#937186: Being worked on upstream
control: forwarded 937186 https://github.com/OpenLightingProject/ola/issues/1506 thanks ola currently doesn't have Python3 support yet. This is being worked on upstream. Once the python3 support is available, I will upload a new package which drops python2 and replaces it with the python3 equivalents. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Bug#950994: Discourage package in contrib to install the real program via another package manager
On Mon, Feb 10, 2020 at 05:48:42AM -0500, Sam Hartman wrote: > I'm not really sure that policy is the best place for this sort of > discouragement though. Why not? Policy discourages loads of things. If we agree that it's not the right thing to do (I'm inclined to agree with that), then we should totally document that in policy. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#950318: RFP: swagger-codegen -- OpenAPI-based code generator
Package: wnpp Severity: wishlist * Package name: swagger-codegen * URL : https://github.com/swagger-api/swagger-codegen * License : Apache 2.0 Programming Lang: Java Description : OpenAPI-based code generator Swagger Codegen allows generation of API client libraries (SDK generation), server stubs, and documentation automatically from an OpenAPI Specification. It can produce stubs and client libraries in a variety of languages.
Bug#949857: extrepo: need dependency on libhash-case-perl
Hi Nick, On Sat, Jan 25, 2020 at 08:59:20PM -0500, Nick Black wrote: > Package: extrepo > Version: 0.6 > Severity: normal > > Dear Maintainer, > > The `tools/validate-repo` script fails without libhash-case-perl being > installed: While that would obviously be an issue, validate-repo is not part of the extrepo package (it's in an entirely different repository), so that's not a bug in extrepo :) Hence, closing. I've updated the README.md file in extrepo-data to mention the required packages, though. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#947244: shouldn't include Architectures in sources file by default
So. On Mon, Dec 23, 2019 at 02:00:18PM +0100, Christoph Berg wrote: > Hi, > > I just enabled the postgresql repo here: > > Holen:10 http://apt.postgresql.org/pub/repos/apt bullseye-pgdg/main Sources > [42,7 kB] > Holen:11 http://apt.postgresql.org/pub/repos/apt bullseye-pgdg/main amd64 > Packages [147 kB] > Holen:12 http://apt.postgresql.org/pub/repos/apt bullseye-pgdg/main ppc64el > Packages [146 kB] > > I am on amd64, the ppc64el Packages file isn't useful. Oh, damn; I was under the impression that other architectures would only be downloaded if you've run 'dpkg --add-architecture '. That's not the case apparently, then. > $ cat /etc/apt/sources.list.d/extrepo_postgresql.sources > Components: main > Types: deb deb-src > Suites: bullseye-pgdg > Uris: http://apt.postgresql.org/pub/repos/apt > Architectures: amd64 ppc64el > Signed-By: /var/lib/extrepo/keys/postgresql.asc > > Please don't include the Architectures line here, it should only be > added by the user if they want to *exclude* some architectures > otherwise enabled via dpkg `--add-architecture`. Perhaps adding the > list as a comment makes sense. > > (On a similar ticket, should "deb-src" be include by default? At least > a switch to configure that at "enable" time would be nice.) I think it should. It doesn't hurt? -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#948117: extrepo: fails to start on fresh installation
Control: forcemerge 947067 -1 thanks Hi Raju, On Sat, Jan 04, 2020 at 01:48:06PM +0530, Raju Devidas wrote: > Package: extrepo > Version: 0.6 > Severity: important > > Dear Maintainer, > > I did a fresh installation of extrepo on Debian Unstable machine. > When I tried starting it for the first time, it gave be the output as > given in the paste here https://paste.debian.net/1124442/ For future reference: please don't pastebin information that you link to from a bug report; pastebins don't usually store the information for a very long time, making the bug report unusable when the data is removed after a week or so. Instead, just copy-and-paste the output into the email that you send to the bts initially. In this particular case, your pastebin contains: $ extrepo --help syntax error at (eval 16) line 1, near "Debian::ExtRepo::Commands::--" ...propagated at /usr/bin/extrepo line 102. $ aptitude search extrepo i extrepo - External repository manager $ extrepo Use of uninitialized value $cmdlower in ucfirst at /usr/bin/extrepo line 98. Undefined subroutine ::ExtRepo::Commandsrun called at (eval 16) line 1. ...propagated at /usr/bin/extrepo line 102. ...which was also mentioned in #947067 as well. Note that it doesn't actually fail to start; it starts just fine. However, the --help argument is not supported, is attempted to be interpreted as a command, and that fails, which produces that error message. That's indeed not very helpful, but it works just fine. Until this bug is fixed, for help on how to use it, please read the output of "man extrepo". Regards, -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#911794: bluetooth: Baseus B11: Poor audio quality HSP/HFP, terrible with a2dp sink
Package: bluetooth Version: 5.50-1 Followup-For: Bug #911794 Hi, I had this too, with my laptop and bluetooth headset. Then I found https://unix.stackexchange.com/questions/407447/how-to-force-a2dp-sink-when-wireless-bluetooth-headset-is-connected The solution suggested there seems to work; adding "AutoConnect=true" (to connect to all profiles, not just "the first one available", which if it happens to be HFP/HSP is terrible) and "MultiProfile = multiple" (to enable the Multi Profile Specification, which defaults to "off") allows me to select A2DP (and in fact defaults to that for me). It's probably a good idea to change the defaults in the bluetooth package to do so by default...? -- System Information: Debian Release: 10.2 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, riscv64, armhf Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bluetooth depends on: ii bluez 5.50-1 bluetooth recommends no packages. Versions of packages bluetooth suggests: pn bluez-cups ii bluez-obexd 5.50-1 -- no debconf information
Bug#946630: openstack-cluster-installer-agent: syntax error
Source: openstack-cluster-installer
Version: 21
Severity: grave
Justification: makes the package unusable
The agent contains the following on line 29:
ETH_SPEED=$(( $(lshw -class network 2>/dev/null -json | jq '.[] |
select(.serial|test("'${MAC_ADDR}'")) | .capacity') / 100))
The shell redirect ("2>/dev/null") means the shell stops passing
command-line arguments from there on, which means the "-json" is never
seen by lshw, which in turn means the "jq" command doesn't get any JSON
data.
This results in an error message of the type
bash: / 100 : syntax error: operand expected (error token is "/ 100")
upon which the agent stops working, and nothing is added to oci's
database.
(this may be fixed in later versions, didn't check, but this is what's in
stable...)
Bug#943525: Namespaces for Lintian Tags
On Wed, Nov 20, 2019 at 09:55:04AM -0800, Felix Lechner wrote: [...] > For example, the tag > 'debian-copyright-file-uses-obsolete-national-encoding' might become > 'national-encoding@debian/copyright'. > > There are many motivations: > > 1. Shortens tag names. I do not see how that is a good thing. "debian-copyright-file-uses-obsolete-national-encoding" is a sentence, which inherently makes it extremely human-readable. For a tool that is primarily meant to validate the output of a human, this is an immensely useful feature. "national-encoding@debian/copyright" is not very useful in that respect, and is a huge step backwards IMO. > 2. Points to the code that issued the tag. While I can see how that might be useful from a lintian maintainer's point of view, this is not really of benefit to the majority of users of lintian. > 3. Frees up name space (good tags are rare). This of course *does* make sense. > 4. Multiple checks can use the same tag in different contexts (i.e. > 'spelling'). Don't see that as a benefit, tbh. > 5. Preempts name conflicts in case some check-writing is delegated to > expert teams. > 6. Quicker to split large checks when components reuse tag names. > 7. Brings consistency between Lintian and custom profile users, such > pkg-perl-tools and pkg-js-tools, who already have private namespaces. These make sense, I guess. I guess namespacing things might have some limited benefit, I suppose. But I like that a plain "lintian" run provides enough context for most people to understand what's going on, without having to use lintian-info. Same for lintian overrides. Please don't break that. HTH, [...] -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#945127: extrepo: YAML_PARSE_ERR_INCONSISTENT_INDENTATION error on extrepo update
Version: 0.4 thanks Hi Leandro, This is due to a mismatch between the YAML and YAML::XS perl modules. A fixed package is available in incoming already, should be on a Debian Mirror Near You(TM) soon. On Wed, Nov 20, 2019 at 09:30:15AM +, Leandro Lisboa Penz wrote: > Package: extrepo > Version: 0.3 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > Running "extrepo update" produced the following output: > > $ extrepo update > gpgv: Signature made Tue 19 Nov 2019 12:09:16 PM GMT > gpgv:using RSA key 7A8502E9FF4765B162A964171283BEE904FB0E04 > gpgv: Good signature from "Debian external repositories signing key > (experimental)" > > > YAML Error: Inconsistent indentation level >Code: YAML_PARSE_ERR_INCONSISTENT_INDENTATION >Line: 9 >Document: 1 > at /usr/share/perl5/YAML/Loader.pm line 804. > ...propagated at /usr/bin/extrepo line 101. > > This is the first time I'm running it. > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (520, 'testing'), (510, 'stable'), (150, 'unstable'), (120, > 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to en_US.UTF-8), LANGUAGE=en (charmap=UTF-8) (ignored: LC_ALL set > to en_US.UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages extrepo depends on: > ii gpgv2.2.17-3 > ii libcryptx-perl 0.066-1 > ii libwww-perl 6.41-1 > ii libyaml-perl1.29-1 > ii perl5.30.0-9 > > extrepo recommends no packages. > > extrepo suggests no packages. > > -- no debconf information > -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#939765: fdpowermon dies every now and then
On Sun, Sep 08, 2019 at 04:58:20PM +0200, Christoph Berg wrote:
> Package: fdpowermon
> Version: 1.18
> Severity: normal
>
> Hi,
>
> I have fdpowermon running with awesome (and no "modern" desktop
> environment).
Yeah, me too :-)
> Things work fine, except that after some time, when I'm
> not looking, fdpowermon just disappears. I can't say what's happening,
> the icon and the process are then just gone.
>
> Any suggestion on how to debug that? Start from gdb?
gdb wouldn't help. "perl -d" might, though. But don't start there.
Instead, I would suggest you capture fdpowermon's stdout and stderr.
They might reveal what's happening. If not, the perl debugger ("perl
-d") might help.
Note that if you run fdpowermon or awesome in a session, the output may
be part of your ~/.xsession-errors file or some such.
--
To the thief who stole my anti-depressants: I hope you're happy
-- seen somewhere on the Internet on a photo of a billboard
