Bug#1070836: rust-apple-nvram: Switch from rust-nix 0.26 to 0.27
Hello Jeremy Bicha,
Thanks for explicitly CCing me on this. See below. There's no urgency to
fix this as the relevant rdeps are still stuck in NEW (for 6+ months).
On Fri, May 10, 2024 at 05:31:54AM -0400, Jeremy Bícha wrote:
> Source: rust-apple-nvram
> Version: 0.2.0-1
> Severity: serious
> Tags: ftbfs upstream sid
> X-Debbugs-CC: andr...@fatal.se
>
> rust-apple-nvram Depends and Build-Depends: rust-nix 0.26 but Unstable
> has rust-nix 0.27 instead. I tried doing a simple version bump from
> 0.26 to 0.27 in the package but dh_auto_test failed.
>
> Thank you,
> Jeremy Bícha
I got the following error when trying the same thing.
I have no idea why, since the ioctl_write_ptr and ioctl_read macros are
still supposed to be around. I can't spot any relevant change in nix
that would cause this to happen. Help would be appreciated.
```
error[E0433]: failed to resolve: could not find `ioctl_write_ptr` in `nix`
--> src/mtd.rs:50:6
|
50 | nix::ioctl_write_ptr!(mtd_mem_erase, b'M', 2, EraseInfoUser);
| ^^^ could not find `ioctl_write_ptr` in `nix`
error[E0433]: failed to resolve: could not find `ioctl_read` in `nix`
--> src/mtd.rs:51:6
|
51 | nix::ioctl_read!(mtd_mem_get_info, b'M', 1, MtdInfoUser);
| ^^ could not find `ioctl_read` in `nix`
error[E0425]: cannot find function `mtd_mem_get_info` in this scope
--> src/mtd.rs:54:17
|
54 | if unsafe { mtd_mem_get_info(file.as_raw_fd(),
MtdInfoUser::default()) }.is_err() {
| not found in this scope
error[E0425]: cannot find function `mtd_mem_erase` in this scope
--> src/mtd.rs:62:9
|
62 | mtd_mem_erase(file.as_raw_fd(), _info).unwrap();
| ^ not found in this scope
Some errors have detailed explanations: E0425, E0433.
For more information about an error, try `rustc --explain E0425`.
error: could not compile `apple-nvram` (lib test) due to 4 previous errors
```
Regards,
Andreas Henriksson
Bug#1056177: librust-tikv-jemalloc-ctl-dev: depends on missing packages
Hello Jonas, On Sat, Nov 18, 2023 at 10:31:56AM +0100, Jonas Smedegaard wrote: > Package: librust-tikv-jemalloc-ctl-dev > Version: 0.5.4-1 > Severity: grave > Justification: renders package unusable > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Depends on packages librust-tikv-jemalloc-sys-0.5+default-dev and > librust-tikv-jemalloc-sys-0.5+disable-initial-exec-tls-dev that are > missing in Debian. tikv-jemalloc-sys is currently stuck in NEW (since a month, wonder if there's a reason for it taking so long?). Looks like this problem should resolve itself once it's accepted. Regards, Andreas Henriksson
Bug#1034213: arno-iptables-firewall: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: arno-iptables-firewall > Version: 2.1.1-7 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package arno-iptables-firewall is shipping files > (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] It seems the package has manually written maintainer scripts (instead of letting debhelper generating the proper code): ``` arno-iptables-firewall-2.1.1> grep -R deb-systemd-helper debian/ debian/postrm: # Remove deb-systemd-helper's state file debian/postrm: deb-systemd-helper purge arno-iptables-firewall.service debian/postinst:deb-systemd-helper enable arno-iptables-firewall.service ``` So while I think manually written maintscript code should be frowned upon (since it's a very common source of bugs), I guess this means this bug is not RC severity?! Regards, Andreas Henriksson
Bug#1034214: tcmu-runner: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: tcmu-runner > Version: 1.5.4-4 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package tcmu-runner is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] tcmu-1.5.4> grep -R systemd.system . ./debian/tcmu-runner.install:debian/tmp/usr/lib/systemd/system/tcmu-runner.service ./README.md:1. If using systemd, copy `org.kernel.TCMUService1.service` to `/usr/share/dbus-1/system-services/` and `tcmu-runner.service` to `/lib/systemd/system`. ./CMakeLists.txt: install(FILES tcmu-runner.service DESTINATION /usr/lib/systemd/system/) These paths are wrong and the culprit of this bug report. You could change them to use the currently correct path, but then you would have to revert that again after bookworm is released when the paths will change again. A better solution would derive the path from systemd.pc, eg. pkg-config --variable=systemdsystemunitdir systemd (Note: this needs pkg-config and systemd in build-deps) Since the upstream build system is CMake, there are plenty of others to look at of how to implement using pkg-config and querying the variable in CMake. This should give you atleast a few hits that could be possible examples to follow: https://codesearch.debian.net/search?q=systemdsystemunitdir+path%3ACMake=0 https://codesearch.debian.net/search?q=systemdsystemunitdir+path%3AFindSystemd=0 Regards, Andreas Henriksson
Bug#1034215: drkonqi: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hello again,
On Wed, Apr 12, 2023 at 01:19:52PM +0200, Andreas Henriksson wrote:
> On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> > Package: drkonqi
> > Version: 5.27.2-1
> > Severity: serious
> > Tags: sid bookworm
> > User: debhel...@packages.debian.org
> > Usertags: systemd-files-in-usr-bookworm
> >
> > Dear Maintainer,
> >
> > It seems that your package drkonqi is shipping files (.service, .socket or
> > .timer) in /usr/lib/systemd/system.
> [...]
>
> ```
> $ apt-file show drkonqi | grep systemd/system
> drkonqi: /usr/lib/systemd/system/drkonqi-coredump-processor@.service
> ```
I forgot to mention that since this is a template unit (@.service)
maybe the severity should not be RC.
As far as I know debhelper will not enable any instance of a template
unit by default anyway, so the consequences that bigon warned about
probably doesn't apply here?
>
> From ./src/coredump/processor/CMakeLists.txt :
>
> ```
> configure_file(
> drkonqi-coredump-processor@.service.cmake
> ${CMAKE_CURRENT_BINARY_DIR}/drkonqi-coredump-processor@.service
> )
> install(
> FILES ${CMAKE_CURRENT_BINARY_DIR}/drkonqi-coredump-processor@.service
> DESTINATION ${KDE_INSTALL_SYSTEMDUNITDIR}/system
> )
> ```
>
> So apparently KDE_INSTALL_SYSTEMDUNITDIR is not set correctly.
>
> I'm not sure where this variable comes from. The above line is the
> only hit on
> https://codesearch.debian.net/search?q=KDE_INSTALL_SYSTEMDUNITDIR=1
>
> Maybe someone with better understanding of KDE and CMake can help figure this
> out.
>
> If not, I guess you can always add a hack that appends to dh_install to move
> the file into the correct directory as returned by
> `pkg-config --variable=systemdsystemunitdir systemd`.
> (Note: make sure to have systemd.pc available by build-dep on systemd)
Regards,
Andreas Henriksson
Bug#1034215: drkonqi: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> Package: drkonqi
> Version: 5.27.2-1
> Severity: serious
> Tags: sid bookworm
> User: debhel...@packages.debian.org
> Usertags: systemd-files-in-usr-bookworm
>
> Dear Maintainer,
>
> It seems that your package drkonqi is shipping files (.service, .socket or
> .timer) in /usr/lib/systemd/system.
[...]
```
$ apt-file show drkonqi | grep systemd/system
drkonqi: /usr/lib/systemd/system/drkonqi-coredump-processor@.service
```
>From ./src/coredump/processor/CMakeLists.txt :
```
configure_file(
drkonqi-coredump-processor@.service.cmake
${CMAKE_CURRENT_BINARY_DIR}/drkonqi-coredump-processor@.service
)
install(
FILES ${CMAKE_CURRENT_BINARY_DIR}/drkonqi-coredump-processor@.service
DESTINATION ${KDE_INSTALL_SYSTEMDUNITDIR}/system
)
```
So apparently KDE_INSTALL_SYSTEMDUNITDIR is not set correctly.
I'm not sure where this variable comes from. The above line is the
only hit on
https://codesearch.debian.net/search?q=KDE_INSTALL_SYSTEMDUNITDIR=1
Maybe someone with better understanding of KDE and CMake can help figure this
out.
If not, I guess you can always add a hack that appends to dh_install to move
the file into the correct directory as returned by
`pkg-config --variable=systemdsystemunitdir systemd`.
(Note: make sure to have systemd.pc available by build-dep on systemd)
Regards,
Andreas Henriksson
Bug#1034216: boinc-client: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: boinc-client > Version: 7.20.5+dfsg-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package boinc-client is shipping files (.service, .socket > or > .timer) in /usr/lib/systemd/system. [...] So the package already contains this patch: ./debian/patches/systemd-directory.patch where the (currently) wrong path is used. Simply updating the patch would work, but then would have to be reverted again once it's changed in the future (after bookworm release). A better solution would be to use pkg-config and query systemd.pc for the correct path, eg. pkg-config --variable=systemdsystemunitdir systemd Note: that this needs systemd.pc to be available, thus you'll need to build-depend on the systemd package (as you already list pkg-config in build-deps). Regards, Andreas Henriksson
Bug#1034217: qbittorrent-nox: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> Package: qbittorrent-nox
> Version: 4.5.2-1
> Severity: serious
> Tags: sid bookworm
> User: debhel...@packages.debian.org
> Usertags: systemd-files-in-usr-bookworm
>
> Dear Maintainer,
>
> It seems that your package qbittorrent-nox is shipping files (.service,
> .socket or
> .timer) in /usr/lib/systemd/system.
[...]
This package seems to install a template unit (as well as a user unit).
Might be wrong, but as far as I know there's no debhelper code that
automatically enables an instance of a template unit, so maybe this
bug report does not qualify as RC severity.
The CMake build system seems to do things correctly by querying
systemd.pc for the systemdsystemunitdir variable already
(see ./cmake/Modules/FindSystemd.cmake and the use of it in
./dist/unix/CMakeLists.txt )
There's however this in unixconf.pri (which is wrong):
```
# Systemd Service file
nogui:systemd {
systemdService.files = $$DIST_PATH/systemd/qbittorrent-nox@.service
systemdService.path = $$PREFIX/lib/systemd/system
INSTALLS += systemdService
}
```
Regards,
Andreas Henriksson
Bug#1034218: cfengine3: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: cfengine3 > Version: 3.21.0-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package cfengine3 is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] So configure.ac contains this: ``` AC_ARG_WITH(systemd-service, AS_HELP_STRING([--with-systemd-service=PATH], [Install systemd service file in given path. The default is no, but if specified, the default path is /usr/lib/systemd/system.]), ``` So it hard-codes a default path, rather than check with systemd.pc. I think that could be fixed to actually use the path from systemd.pc instead. Alternatively you could ofcourse use the existing mechanism and extend the --with-systemd-service you're already passing in debian/rules to actually include the correct path as an argument. eg. ``` SYSTEMDSYSTEMUNITDIR=$(shell pkg-config --variable=systemdsystemunitdir systemd) [...] --with-systemd-service=$(SYSTEMDSYSTEMUNITDIR) \ [...] ``` Note: do not forget to add pkg-config and systemd (for systemd.pc) to build-deps. Regards, Andreas Henriksson
Bug#1034219: debomatic: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: debomatic > Version: 0.26-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package debomatic is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] debomatic is the second package using the pybuild build system that I look at which has subdirectories `usr/lib/systemd/system/` containing the service file and then no obvious code to install it so I guess all the magic to handle it is in pybuild or some upstream build system not included in the actual source package itself. I'm not sure exactly what the best option is to adress this for pybuild using packages, but my guess would be to have some debian/rules hack that moves the file (if it's not already located in the same path as returned by `pkg-config --variable=systemdsystemunitdir systemd`) after dh_install has run probably. Regards, Andreas Henriksson
Bug#1034220: shadowsocks-libev: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: shadowsocks-libev > Version: 3.3.5+ds-9 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package shadowsocks-libev is shipping files (.service, > .socket or > .timer) in /usr/lib/systemd/system. [...] The incorrect path is in: ./debian/shadowsocks-libev.install (also in ./debian/README.Debian ) Changing it to lib/systemd/system and then in trixie back to usr/lib/systemd/system again seems suboptimal. Rather than duplicating the path everywhere, the best thing would be to simply query systemd.pc for it, eg: pkg-config --variable=systemdsystemunitdir systemd This needs pkg-config and systemd to be in build-depends. To use this command in ./debian/shadowsocks-libev.install you would have to make the file executable and integrate dh-exec. I'll leave it up to you to decide if you think integrating dh-exec is worth it or not (Another option is to make the upstream build system install the file in the correct path.) Regards, Andreas Henriksson
Bug#1034236: mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hello Max Kellermann,
On Tue, Apr 11, 2023 at 04:13:28PM +0200, Max Kellermann wrote:
> On 2023/04/11 15:11, Andreas Henriksson wrote:
> > The culprit seems to be that mpd falls back on hard-coded path (instead
> > of failing) when systemd.pc is not found!
>
> What does this have to do with systemd.pc? It isn't used anywhere.
Right, I overlooked this which is indeed a problem.
Currently there's only a meson_option.txt you can set which means:
1. implement `pkg-config --variable=systemdsystemunitdir systemd`
in debian/rules and pass it in via the existing option.
2. implement checking systemdsystemunitdir from systemd.pc in meson
and have the build system do the right thing without any options.
I think 2 is better myself and I'm attaching a proof of concept
debdiff to implement it. (You might want to make a cleaner version.)
Regards,
Andreas Henriksson
diff -Nru mpd-0.23.12/debian/changelog mpd-0.23.12/debian/changelog
--- mpd-0.23.12/debian/changelog2023-01-21 21:32:37.0 +0100
+++ mpd-0.23.12/debian/changelog2023-04-11 17:30:42.0 +0200
@@ -1,3 +1,11 @@
+mpd (0.23.12-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add debian/patches/systemdsystemunitdir.patch
+ * Add systemd build-dep for systemd.pc
+
+ -- Andreas Henriksson Tue, 11 Apr 2023 17:30:42 +0200
+
mpd (0.23.12-1) unstable; urgency=medium
* New upstream version 0.23.12
diff -Nru mpd-0.23.12/debian/control mpd-0.23.12/debian/control
--- mpd-0.23.12/debian/control 2023-01-21 21:32:37.0 +0100
+++ mpd-0.23.12/debian/control 2023-04-11 17:30:42.0 +0200
@@ -55,6 +55,7 @@
libsoxr-dev,
libsqlite3-dev,
libsystemd-dev [linux-any],
+ systemd [linux-any],
libupnp-dev (>= 1.8~),
liburing-dev [linux-any],
libvorbis-dev [!armel],
diff -Nru mpd-0.23.12/debian/patches/series mpd-0.23.12/debian/patches/series
--- mpd-0.23.12/debian/patches/series 2021-11-11 15:58:40.0 +0100
+++ mpd-0.23.12/debian/patches/series 2023-04-11 17:25:58.0 +0200
@@ -1,3 +1,4 @@
# Debian-specific
systemd_honor_MPDCONF.patch
mpd.service.documentation.user.patch
+systemdsystemunitdir.patch
diff -Nru mpd-0.23.12/debian/patches/systemdsystemunitdir.patch
mpd-0.23.12/debian/patches/systemdsystemunitdir.patch
--- mpd-0.23.12/debian/patches/systemdsystemunitdir.patch 1970-01-01
01:00:00.0 +0100
+++ mpd-0.23.12/debian/patches/systemdsystemunitdir.patch 2023-04-11
17:30:33.0 +0200
@@ -0,0 +1,16 @@
+Index: mpd-0.23.12/systemd/system/meson.build
+===
+--- mpd-0.23.12.orig/systemd/system/meson.build
mpd-0.23.12/systemd/system/meson.build
+@@ -1,5 +1,11 @@
+ systemd_system_unit_dir = get_option('systemd_system_unit_dir')
+ if systemd_system_unit_dir == ''
++ systemd = dependency('systemd', required: false)
++ if systemd.found()
++ systemd_system_unit_dir =
systemd.get_pkgconfig_variable('systemdsystemunitdir')
++ endif
++endif
++if systemd_system_unit_dir == ''
+ systemd_system_unit_dir = join_paths(get_option('prefix'), 'lib',
'systemd', 'system')
+ endif
+
Bug#1034223: powerman: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hello Laurent Bigonville, On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: powerman > Version: 2.3.27-2 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package powerman is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. > > This is not supported by the version of dh_installsystemd/debhelper currently > in unstable and bookworm (See: #1031695). That means that currently your > service might not be enabled at boot and/or started as expected. [...] Note that debian/rules has: ``` override_dh_installinit: dh_installinit --no-start --no-enable override_dh_installsystemd: dh_installsystemd --no-start --no-enable ``` So do you agree that the severity of this bug report should be downgraded (maybe even closed)? Regards, Andreas Henriksson
Bug#1034226: cloudflare-ddns: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> Package: cloudflare-ddns
> Version: 2.0.0-3
> Severity: serious
> Tags: sid bookworm
> User: debhel...@packages.debian.org
> Usertags: systemd-files-in-usr-bookworm
>
> Dear Maintainer,
>
> It seems that your package cloudflare-ddns is shipping files (.service,
> .socket or
> .timer) in /usr/lib/systemd/system.
[...]
The culprit seems to be hard-coded paths in the upstream build system
at:
https://sources.debian.org/src/cloudflare-ddns/2.0.0-3/exe/meson.build/#L70
Since I wasn't sure about how configure_file directive in meson works
and the documentation at
https://mesonbuild.com/Reference-manual_functions.html#configure_file
says install_dir takes a subdirectory I had to try it out.
The attached debdiff should solve the problem.
While at it I also adressed the hardcoded sysuser directory at:
https://sources.debian.org/src/cloudflare-ddns/2.0.0-3/exe/meson.build/#L90
See attached file which you might want to improve (for example you could
make systemd a build-option even on linux if you care).
Regards,
Andreas Henriksson
diff -Nru cloudflare-ddns-2.0.0/debian/changelog
cloudflare-ddns-2.0.0/debian/changelog
--- cloudflare-ddns-2.0.0/debian/changelog 2023-01-16 22:16:37.0
+0100
+++ cloudflare-ddns-2.0.0/debian/changelog 2023-04-11 16:17:38.0
+0200
@@ -1,3 +1,12 @@
+cloudflare-ddns (2.0.0-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * add debian/patches/systemdsystemunitdir.patch
+ * debian/cloudflare-ddns.install: install lib/systemd/system
+ * Add systemd build-dep, for systemd.pc
+
+ -- Andreas Henriksson Tue, 11 Apr 2023 16:17:38 +0200
+
cloudflare-ddns (2.0.0-3) unstable; urgency=medium
* d/.install: fix build on non-Linux with dh-exec
diff -Nru cloudflare-ddns-2.0.0/debian/cloudflare-ddns.install
cloudflare-ddns-2.0.0/debian/cloudflare-ddns.install
--- cloudflare-ddns-2.0.0/debian/cloudflare-ddns.install2023-01-16
22:10:06.0 +0100
+++ cloudflare-ddns-2.0.0/debian/cloudflare-ddns.install2023-04-11
16:17:38.0 +0200
@@ -1,5 +1,5 @@
#!/usr/bin/dh-exec
-[linux-any] usr/lib/systemd/
+[linux-any] lib/systemd/system
[linux-any] usr/lib/sysusers.d/
etc/
usr/bin/
diff -Nru cloudflare-ddns-2.0.0/debian/control
cloudflare-ddns-2.0.0/debian/control
--- cloudflare-ddns-2.0.0/debian/control2023-01-16 22:10:06.0
+0100
+++ cloudflare-ddns-2.0.0/debian/control2023-04-11 16:17:38.0
+0200
@@ -11,6 +11,7 @@
libsimdjson-dev (>= 0.9.0),
meson (>= 0.53.0),
pkg-config,
+ systemd,
ronn
Standards-Version: 4.6.2
Homepage: https://github.com/Tachi107/cloudflare-ddns
diff -Nru cloudflare-ddns-2.0.0/debian/patches/series
cloudflare-ddns-2.0.0/debian/patches/series
--- cloudflare-ddns-2.0.0/debian/patches/series 1970-01-01 01:00:00.0
+0100
+++ cloudflare-ddns-2.0.0/debian/patches/series 2023-04-11 16:13:19.0
+0200
@@ -0,0 +1 @@
+systemdsystemunitdir.patch
diff -Nru cloudflare-ddns-2.0.0/debian/patches/systemdsystemunitdir.patch
cloudflare-ddns-2.0.0/debian/patches/systemdsystemunitdir.patch
--- cloudflare-ddns-2.0.0/debian/patches/systemdsystemunitdir.patch
1970-01-01 01:00:00.0 +0100
+++ cloudflare-ddns-2.0.0/debian/patches/systemdsystemunitdir.patch
2023-04-11 16:17:38.0 +0200
@@ -0,0 +1,37 @@
+Index: cloudflare-ddns-2.0.0/exe/meson.build
+===
+--- cloudflare-ddns-2.0.0.orig/exe/meson.build
cloudflare-ddns-2.0.0/exe/meson.build
+@@ -66,8 +66,10 @@ if ronn.found()
+ )
+ endif
+
+-if host_machine.system() == 'linux'
+- systemddir = 'lib'/'systemd'/'system'
++systemd = dependency('systemd', required: host_machine.system() == 'linux')
++if systemd.found()
++ systemdsystemunitdir =
systemd.get_pkgconfig_variable('systemdsystemunitdir')
++systemdsysusersdir = systemd.get_pkgconfig_variable('sysusersdir')
+
+ configure_file(
+ input: 'systemd'/'cloudflare-ddns.service.in',
+@@ -77,16 +79,16 @@ if host_machine.system() == 'linux'
+ 'libdir': get_option('prefix')/get_option('libdir')
+ },
+ install: true,
+- install_dir: systemddir
++ install_dir: systemdsystemunitdir
+ )
+
+ install_data(
+ 'systemd'/'cloudflare-ddns.timer',
+- install_dir: systemddir
++ install_dir: systemdsystemunitdir
+ )
+
+ install_data(
+ 'sysusers.d'/'cloudflare-ddns.conf',
+- install_dir: 'lib'/'sysusers.d'
++ install_dir: systemdsysusersdir
+ )
+ endif
Bug#1034227: mpdscribble: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: mpdscribble > Version: 0.24-2 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package mpdscribble is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The problem seems to be basically the same as in https://bugs.debian.org/1034236 When systemd.pc is not found, it falls back on hard-coded path in: https://sources.debian.org/src/mpdscribble/0.24-2/systemd/system/meson.build/#L1-L4 As pkg-config is already part of build-deps, simply adding systemd (for systemd.pc) should be enough to fix the problem. Regards, Andreas Henriksson
Bug#1034228: zcfan: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: zcfan > Version: 1.2.1-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package zcfan is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The culprit seems to be the wrong path hardcoded at: https://sources.debian.org/src/zcfan/1.2.1-1/Makefile/#L44 Preferably you would find out this path by querying systemd.pc for it, ie. pkg-config --variable=systemdsystemunitdir systemd (Note: You'll also need to build-dep on pkg-config and systemd, for systemd.pc) Regards, Andreas Henriksson
Bug#1034221: caddy: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: caddy > Version: 2.6.2-4 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package caddy is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The culprit seems to be wrong path at: https://sources.debian.org/src/caddy/2.6.2-4/debian/caddy.install/#L2-L3 Please note that if you change it to /lib/systemd/system now, you'll likely need to reverse that change again in the future. Preferably the correct path is derived from the value given by pkg-config --variable=systemdsystemunitdir systemd You could use this via making your debian/caddy.install executable and integrating dh-exec. You'll have to decide if you think it's worth it or not. Regards, Andreas Henriksson
Bug#1034229: wsdd2: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: wsdd2 > Version: 1.8.7+dfsg-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package wsdd2 is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The culprit seems to be the hard-coded path at: https://sources.debian.org/src/wsdd2/1.8.7%2Bdfsg-1/Makefile/#L31 As this path will change again in the future, please consider finding out the path from the proper source via: pkg-config --variable=systemdsystemunitdir systemd (Note: you'll need to build-dep on pkg-config and systemd, for systemd.pc) Regards, Andreas Henriksson
Bug#1034230: fail2ban: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: fail2ban > Version: 1.0.2-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package fail2ban is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] Wrong path is used at: https://sources.debian.org/src/fail2ban/1.0.2-1/debian/rules/#L50 Note that the path will likely change again in the future, so rather than hard-coding a path please consider finding the path via: pkg-config --variable=systemdsystemunitdir systemd (Note: you'll need to build-dep on pkg-config and systemd, for systemd.pc) Regards, Andreas Henriksson
Bug#1034232: nvme-cli: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: nvme-cli > Version: 2.3-2 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package nvme-cli is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The culprit seems to be here: https://sources.debian.org/src/nvme-cli/2.4%2Breally2.3-2/meson.build/#L27 (making the systemddir build option unusable.) The proper solution would involve pkg-config and systemd.pc which should be queried for the systemdsystemunitdir variable. (Note: do not forget to build-dep on pkg-config and systemd.) This should give you a bunch of packages to choose from as examples of how to implement that using meson: https://codesearch.debian.net/search?q=get_option.*systemdsystemunitdir=0=1 Regards, Andreas Henriksson
Bug#1034233: tlp: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: tlp > Version: 1.5.0-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package tlp is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The problem seems to originate from: https://sources.debian.org/src/tlp/1.5.0-1/debian/rules/#L9 The upstream default value is actually correct for Debian (at the moment): https://sources.debian.org/src/tlp/1.5.0-1/Makefile/#L17 However, this will change in the future... so I think a better solution would be to actually retrieve the value from systemd.pc. You should be able to do this by: * build-dep on pkg-config and systemd (for systemd.pc) * Modify debian/rules `export TLP_SYSD=/usr/lib/systemd/system` to: export TLP_SYSD=$(shell pkg-config --variable=systemdsystemunitdir systemd) * Update https://sources.debian.org/src/tlp/1.5.0-1/debian/tlp.install/#L5 Regards, Andreas Henriksson
Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: libpam-modules-bin > Version: 1.5.2-6 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package libpam-modules-bin is shipping files (.service, > .socket or > .timer) in /usr/lib/systemd/system. [...] wrong variable name (systemdsystemunitdir): https://sources.debian.org/src/pam/1.5.2-6/configure.ac/?hl=646#L646 overridden by wrong path: https://sources.debian.org/src/pam/1.5.2-6/debian/rules/#L33 Regards, Andreas Henriksson
Bug#1034236: mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: mpd > Version: 0.23.12-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package mpd is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The culprit seems to be that mpd falls back on hard-coded path (instead of failing) when systemd.pc is not found! https://sources.debian.org/src/mpd/0.23.12-1/systemd/system/meson.build/#L1-L4 Fixing the problem should be as easy as adding a build-dep on the package that contains systemd.pc (systemd). Regards, Andreas Henriksson
Bug#1034237: gammu-smsd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: gammu-smsd > Version: 1.42.0-7 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package gammu-smsd is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The culprit seems to be here: https://sources.debian.org/src/gammu/1.42.0-7/debian/rules/#L32 ``` -DSYSTEMD_SERVICES_INSTALL_DIR=/usr/lib/systemd/system \ ``` By removing this line you'll let cmake auto-detect the correct path via ./cmake/FindSystemD.cmake which uses pkg-config. Make sure you also build-dep on the package containing systemd.pc (you already seem to have pkg-config itself in build-deps). Also note that you need to adjust: https://sources.debian.org/src/gammu/1.42.0-7/debian/gammu-smsd.install/#L5 Regards, Andreas Henriksson
Bug#1034240: pass-extension-tomb: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 10:00:16AM +0200, bi...@debian.org wrote: > Package: pass-extension-tomb > Version: 1.3-2 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package pass-extension-tomb is shipping files (.service, > .socket or > .timer) in /usr/lib/systemd/system. [...] The culprit seems to be here: https://sources.debian.org/src/pass-tomb/1.3-2/Makefile/#L21 (and also line 36) ``` @install -Dm0644 pass-close@.service "$(DESTDIR)$(LIBDIR)/systemd/system/pass-close@.service" ``` To get the correct path you could use: ``` pkg-config --variable=systemdsystemunitdir systemd ``` (Note: do not forget to also build-dep on the package containing systemd.pc as well as pkg-config itself.) Regards, Andreas Henriksson
Bug#1034238: fapolicyd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 02:23:32PM +0200, Andreas Henriksson wrote:
> On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> > Package: fapolicyd
> > Version: 1.1.7-3
> > Severity: serious
> > Tags: sid bookworm
> > User: debhel...@packages.debian.org
> > Usertags: systemd-files-in-usr-bookworm
> >
> > Dear Maintainer,
> >
> > It seems that your package fapolicyd is shipping files (.service, .socket or
> > .timer) in /usr/lib/systemd/system.
> [...]
>
> The problem seems to come from the more or less hardcoded path in
> configure.at at:
> https://sources.debian.org/src/fapolicyd/1.1.7-3/configure.ac/#L74
>
> ```
> dnl FIXME some day pass this on the command line
> def_systemdsystemunitdir=${prefix}/lib/systemd/system
> AC_SUBST([systemdsystemunitdir], [$def_systemdsystemunitdir])
> ```
>
> For example how to use value from systemd.pc, see a random example:
> https://sources.debian.org/src/pam/1.5.2-6/configure.ac/?hl=646#L641-L649
> (Note: you'll also need a build-dep on package containing systemd.pc)
Actually this example might be broken ... should probably use
variable=systemdsystemunitdir rather than variable=systemdunitdir
>
> Regards,
> Andreas Henriksson
Bug#1034238: fapolicyd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> Package: fapolicyd
> Version: 1.1.7-3
> Severity: serious
> Tags: sid bookworm
> User: debhel...@packages.debian.org
> Usertags: systemd-files-in-usr-bookworm
>
> Dear Maintainer,
>
> It seems that your package fapolicyd is shipping files (.service, .socket or
> .timer) in /usr/lib/systemd/system.
[...]
The problem seems to come from the more or less hardcoded path in
configure.at at:
https://sources.debian.org/src/fapolicyd/1.1.7-3/configure.ac/#L74
```
dnl FIXME some day pass this on the command line
def_systemdsystemunitdir=${prefix}/lib/systemd/system
AC_SUBST([systemdsystemunitdir], [$def_systemdsystemunitdir])
```
For example how to use value from systemd.pc, see a random example:
https://sources.debian.org/src/pam/1.5.2-6/configure.ac/?hl=646#L641-L649
(Note: you'll also need a build-dep on package containing systemd.pc)
Regards,
Andreas Henriksson
Bug#1031572: librt-extension-commandbymail-perl: Please add a Homepage field in debian/control
Hello Adrian Bunk, On Sat, Feb 18, 2023 at 10:58:33PM +0200, Adrian Bunk wrote: > Source: librt-extension-commandbymail-perl > Version: 3.00-1.1 > Severity: serious > > Homepage: https://metacpan.org/pod/RT::Extension::CommandByMail > would be an option. Could you please provide some additional information here that I'm obviously failing to understand. The Homepage field is an optional field: https://www.debian.org/doc/debian-policy/ch-controlfields.html#binary-package-control-files-debian-control I personally often leave it out even when a homepage exists but contains very little useful information (probably all already available in the package itself). If this is even a bug then it would be at most Severity: wishlist as I see it. What am I missing here that makes Homepage so important for this package to warrant a release-critical severity? Regards, Andreas Henriksson
Bug#1031436: ubuntu-dev-tools: FTBFS: make[1]: *** [debian/rules:10: override_dh_auto_test] Error 1
Control: retitle -1 ubuntu-dev-tools: FTBFS because of ./run-linters during build Hello, On Fri, Feb 17, 2023 at 07:55:22AM +0100, Lucas Nussbaum wrote: > Source: ubuntu-dev-tools > Version: 0.192 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230216 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > ./run-linters [...] Running linters during build seems like an equally bad idea as using -Werror in release builds! When ever a linter changes opinion of something the package will start to FTBFS (just like when gcc gains a new warning and code with -Werror starts to FTBFS). I hope removing `./run-linters` from debian/rules is a simple fix for this issue (and future ones). Run the linters *before* release, not on every (re)build after release. (Or possibly catch this via an autopkgtest that would trigger when a new version of a dependency is uploaded. But I don't think linter package maintainers would appreciate you blocking their package from testing migration until you've uploaded a relinted version of your package.) Regards, Andreas Henriksson
Bug#1031473: freebayes: FTBFS: Variant.h:36:10: fatal error: wavefront/wfa.hpp: No such file or directory
Control: reassign -1 libvcflib-dev 1.0.7+dfsg-1 Control: retitle -1 libvcflib-dev lacks dependency on libwfa2-dev Control: affects -1 freebayes Hello, On Fri, Feb 17, 2023 at 08:01:41AM +0100, Lucas Nussbaum wrote: > Source: freebayes > Version: 1.3.6-2 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230216 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > c++ -Ilibfreebayes_common.a.p -I. -I.. -I../src -I../ttmath > > -I/usr/include/vcflib -I/usr/include/smithwaterman -I/usr/include/fastahack > > -I/usr/include/SeqLib -I/usr/include/jsoncpp -fdiagnostics-color=always > > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++14 -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread > > -fpermissive -Wno-reorder -Wno-sign-compare -Wno-unused-variable > > -Wno-unused-but-set-variable -MD -MQ > > libfreebayes_common.a.p/src_DataLikelihood.cpp.o -MF > > libfreebayes_common.a.p/src_DataLikelihood.cpp.o.d -o > > libfreebayes_common.a.p/src_DataLikelihood.cpp.o -c > > ../src/DataLikelihood.cpp > > In file included from ../src/AlleleParser.h:32, > > from ../src/DataLikelihood.h:20, > > from ../src/DataLikelihood.cpp:1: > > /usr/include/vcflib/Variant.h:36:10: fatal error: wavefront/wfa.hpp: No > > such file or directory > >36 | #include "wavefront/wfa.hpp" > > | ^~~ > > compilation terminated. [...] Note than it's not freebayes that includes "wavefront/wfa.hpp", but vcflib. Given that vcflib has had a recent new upload to unstable that makes me think this is actually a problem in vcflib. The new vcflib version has not yet migrated to testing, so reassigning this to add a(n additional) blocker for that to happen and prevent the problem from affecting testing. I notiled that libvcflib-dev does *not* have a dependency on libwfa2-dev (which has wavefront/wfa.hpp). Maybe this is the bug itself. There could possibly be additional problems like cflags (and libs) not propagating properly up the chain. There seems to be no .pc (pkgconfig) file included in libwfa2-dev. Not sure how the needed "-I/usr/include/wfa2lib/" are supposed to be propagated up, but lets first fix the dependency issue and then I'll leave potential additional problems as an excercise for the maintainer(s) to figure out while testing their new package. Please consider adding a simple compile test as an autopkgtest, which would help you catch missing dependencies in the -dev packages. For example see: https://sources.debian.org/src/util-linux/2.38.1-5/debian/tests/libmount-dev/ Regards, Andreas Henriksson
Bug#1031453: sane-frontends: FTBFS: dh_install: error: missing files, aborting
Control: retitle -1 sane-frontends: FTBFS: Couldn't find SANE libraries (sane-backends) Hello, This seems to be a regression caused by the newly uploaded sane-backends. Maybe that should get an RC bug to prevent it from going into testing! Would probably make sense to atleast add a Breaks: sane-fronteds (<< fixed-version) to the new version of sane-backends. Anyway, more about sane-frontends FTBFS below. On Fri, Feb 17, 2023 at 08:04:01AM +0100, Lucas Nussbaum wrote: > Source: sane-frontends > Version: 1.0.14-16 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230216 ftbfs-bookworm [...] > > checking for sane-backends >= 1.0.0... yes > > ** > > ERROR: Couldn't find SANE libraries (sane-backends). Possible reasons: > > - sane-backends isn't installed (install sane-backends before > >sane-frontends) > > - the SANE header files aren't installed (if you installed > >SANE as RPM make sure you also included the sane-devel RPM) > > - the SANE libraries can't be found because /usr/local/lib/ isn't > >searched by the dynamic linker (see INSTALL for details) > > ** ^^ this is the actual error. Unfontunately when this occurs the configure script exits with code 0. https://sources.debian.org/src/sane-frontends/1.0.14-16/configure.in/#L131 It would be much better if it exited with an error code (and printed the error messages to stderr instead of stdout while at it). Then we wouldn't have to proceed to end up with this: > > > >create-stamp debian/debhelper-build-stamp > >dh_prep > >dh_installdirs > >dh_auto_install --destdir=debian/sane/ > >dh_install > > dh_install: warning: Cannot find (any matches for) > > "debian/sane/usr/bin/xscanimage" (tried in ., debian/tmp) [...] The fix would probably be to replace ldflags with libs here (and bump version of libsane-dev build-dep as this would not work with older versions than the one currently in unstable): https://sources.debian.org/src/sane-frontends/1.0.14-16/configure.in/#L117 The sane-backends.pc from unstable (1.2.1-1) has: # grep -e ldflags= -e libs= /usr/lib/x86_64-linux-gnu/pkgconfig/sane-backends.pc libs= -ldl -lm -ltiff -ljpeg -lgphoto2 -lgphoto2_port -lm -lavahi-common -lavahi-client -lusb-1.0 While the sane-backends.pc currently in testing (1.1.1-6) has: # grep -e ldflags= -e libs= usr/lib/x86_64-linux-gnu/pkgconfig/sane-backends.pc ldflags=-Wl,-z,relro -Wl,-z,now libs= Regards, Andreas Henriksson
Bug#1031448: fwupd: FTBFS: ./obj-x86_64-linux-gnu/meson-private/tmp7p7957mh/./obj-x86_64-linux-gnu/meson-private/tmp7p7957mh/testfile.c:17: undefined reference to `gcab_cabinet_add_allowed_compression
Control: reassign -1 libflashrom-dev 1.3.0-2 Control: affects -1 fwupd Control: retitle -1 libfrashrom-dev missing dependency on pkg-config required libraries On Fri, Feb 17, 2023 at 06:34:17AM +0100, Lucas Nussbaum wrote: > Source: fwupd > Version: 1.8.10-2 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230216 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): [...] I believe this is the actual relevant part: Called `/usr/bin/pkg-config --cflags flashrom` -> 1 pkg-config error with 'flashrom': Could not generate cargs for flashrom: Package libjaylink was not found in the pkg-config search path. Perhaps you should add the directory containing `libjaylink.pc' to the PKG_CONFIG_PATH environment variable Package 'libjaylink', required by 'flashrom', not found > The full build log is available from: > http://qa-logs.debian.net/2023/02/16/fwupd_1.8.10-2_unstable.log [...] grep Requires usr/lib/*-linux-gnu/pkgconfig/flashrom.pc Requires.private: libpci, libusb-1.0, libftdi1, libjaylink The packages containing these .pc needs to be listed in Depends of libflashrom-dev. I'd suggest adding a trivial compile test as an autopkgtest using pkgconfig which I find is the easiest way to spot if the -dev package is missing dependencies listed in the pkg-config file. For example see: https://sources.debian.org/src/util-linux/2.38.1-5/debian/tests/libmount-dev/ Regards, Andreas Henriksson
Bug#1029944: neon27 FTBFS on IPV6-only buildds
Hello again,
On Sat, Feb 11, 2023 at 06:55:13PM +0100, Andreas Henriksson wrote:
> On Sun, Jan 29, 2023 at 02:29:23PM +0100, László Böszörményi (GCS) wrote:
> > Control: tags -1 +confirmed
> >
> > On Sun, Jan 29, 2023 at 12:33 PM Adrian Bunk wrote:
> > > https://buildd.debian.org/status/logs.php?pkg=neon27=amd64
> > >
> > > ...
> > > auth.. 3/20 FAIL - retries (line 311: HTTP error:
> > > Could not resolve hostname `127.0.0.1': Address family for hostname not
> > > supported)
> > Is there a way to detect such buildds as a maintainer? What can I do
> > except notifying upstream and / or disable such tests?
If replacing "127.0.0.1" with "localhost" does not work the attached
(completely untested) patch might be an option instead (simply skip the
test on EAFNOSUPPORT).
(Sorry if the patch is completely broken, but I hope you get the
idea...)
Regards,
Andreas Henriksson
--- test/utils.h.orig 2023-02-11 19:38:52.122713689 +0100
+++ test/utils.h 2023-02-11 19:40:25.601514834 +0100
@@ -25,7 +25,7 @@
#include "child.h"
-#define ONREQ(x) do { int _ret = (x); if (_ret) { t_context("line %d: HTTP error:\n%s", __LINE__, ne_get_error(sess)); return FAIL; } } while (0);
+#define ONREQ(x) do { int _ret = (x); if (_ret) { t_context("line %d: HTTP error:\n%s", __LINE__, ne_get_error(sess)); if (strcmp(ne_get_error(sess), "Could not resolve hostname `127.0.0.1': Address family for hostname not supported") == 0) { return SKIP; } else { return FAIL; } } } while (0);
int single_serve_string(ne_socket *s, void *userdata);
Bug#1030175: libgetdata: FTBFS: dh_install: error: missing files, aborting
On Sun, Feb 05, 2023 at 02:52:49PM +0100, s3v wrote: > Dear Maintainer, > > > dh_install: warning: Cannot find (any matches for) > > "usr/local/lib/python3.10/dist-packages/*" (tried in ., debian/tmp) > > > > dh_install: warning: python3-pygetdata missing files: > > usr/local/lib/python3.10/dist-packages/* > > dh_install: error: missing files, aborting > > make: *** [debian/rules:28: binary-arch] Error 25 > > this is caused by a reference to python 3.10 in this file [1] > > Kind Regards > > [1] > https://sources.debian.org/src/libgetdata/0.11.0-5/debian/python3-pygetdata.install/ I think this is only half the truth. The file explicitly list both 3.10 and 3.11. The second half is that python3-all-dev no longer brings in both 3.10 and 3.11 since (see last bullet): python3-defaults (3.11.1-2) unstable; urgency=medium * Provide python3-supported-min and python3-supported-max versioned virtual packages, to allow modules to easily declare dependencies for all supported versions. * Bump Depends to 3.11.1-1. * Drop support for Python 3.10. -- Stefano Rivera Sat, 28 Jan 2023 09:46:57 -0400 It would however probably be a good idea if libgetdata / python3-pygetdata.install did not hardcode which python versions it expects python3-all-dev to bring in at all?! Is there any specific reason why it explicitly lists both the 3.10 and 3.11 paths rather than just use a wildcard in the path? If it's only to move files from /usr/local/lib to /usr/lib then maybe that would be better to do in debian/rules exectute_after_dh_auto_install target?! (Unless there's a better way to get the upstream install to use prefix /usr instead of /usr/local ofcourse) Oh well... now that I've written all this I see there's already: https://salsa.debian.org/science-team/libgetdata/-/commit/f698db0b309351d8dc66fad194f9462fb5c531ea Might still be worth considering not hardcoding any versions as discussed above though (to avoid repeating this problem once python 3.11 goes out of fashion)... Regards, Andreas Henriksson
Bug#1030186: enigmail: FTBFS (Error: Cannot find module 'chalk')
On Wed, Feb 01, 2023 at 12:32:44AM +0100, Santiago Vila wrote: > Package: src:enigmail > Version: 2:2.2.4-0.3 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > I've just noticed that enigmail currently fails to build in bookworm: > > make[1]: Leaving directory '/<>' >dh_auto_test -i > make -j1 test "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 > make[1]: Entering directory '/<>' > static_analysis/eslint package > There was a problem loading formatter: > /usr/share/nodejs/eslint/lib/cli-engine/formatters/stylish > Error: Cannot find module 'chalk' [...] /usr/share/nodejs/eslint/lib/cli-engine/formatters/stylish is part of eslint package. The eslint package (build-depends and) *recommends* node-chalk. This changelog entry seems relevant: eslint (1.3.1~dfsg-3) experimental; urgency=medium * Fix install executable. * Add patch cherry-picked upstream to lazy-load rules. Relax to recommend (not depend on) node-chalk node-inquirer node-strip-ansi node-text-table. Fix explicitly depend on node-escape-string-regexp (previously pulled in by node-chalk). -- Jonas Smedegaard Sat, 12 Oct 2019 15:19:55 +0200 I'm not able to determine if either enigmail should dep on node-chalk itself because it uses supposedly optional components of eslint or if there's a mistake in eslint which should have node-chalk as a depends rather than recommends Hope someone else can figure this out. Regards, Andreas Henriksson
Bug#1029944: neon27 FTBFS on IPV6-only buildds
On Sun, Jan 29, 2023 at 02:29:23PM +0100, László Böszörményi (GCS) wrote: > Control: tags -1 +confirmed > > On Sun, Jan 29, 2023 at 12:33 PM Adrian Bunk wrote: > > https://buildd.debian.org/status/logs.php?pkg=neon27=amd64 > > > > ... > > auth.. 3/20 FAIL - retries (line 311: HTTP error: > > Could not resolve hostname `127.0.0.1': Address family for hostname not > > supported) > Is there a way to detect such buildds as a maintainer? What can I do > except notifying upstream and / or disable such tests? FWIW "127.0.0.1" is hardcoded here: https://sources.debian.org/src/neon27/0.32.5-1/test/utils.c/#L207 Possibly that could be replaced with "localhost" instead, but I'm not sure if using 127.0.0.1 is an attempt at hiding that the code is ipv4-only rather than protocol independent (maybe)... I tried quickly looking at upstream git history if it could confirm my suspicion, but the closest I could find was: https://github.com/notroj/neon/commit/eff6521be537c74511593743bf8665d898e26567 Seems like localhost -> 127.0.0.1 switch was intentional (and done during SVN days?). Maybe someone digging deeper can find "r1910". Regards, Andreas Henriksson
Bug#916596: iptables.postinst failure on link creation
Control: tags -1 + moreinfo On Sun, Feb 05, 2023 at 12:08:32PM +0200, Adrian Bunk wrote: > Control: tags -1 - moreinfo > Control: severity -1 serious > > On Fri, Dec 28, 2018 at 02:59:26PM +0100, Arturo Borrero Gonzalez wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Control: tag -1 moreinfo > > > > On Sun, 16 Dec 2018 13:14:19 +0100 Olivier wrote: > > > Package: iptables Version: 1.8.2-2+b1 Severity: important > > > > > > Dear Maintainer, > > > > > > Issue occure during iptables:i386 1.8.2-2 -> 1.8.2-2+b1 upgrade. > > > > > > /var/lib/dpkg/info/iptables.postinst fail with message: > > > > > > ln: failed to create symbolic link ''$'\t'' > > > /sbin/iptables-save': No such file or directory > > > > > > > I can't reproduce the issue: > >... > > I didn't try in i386 because I don't have any machine (virtual or > > physical) with that arch, maybe is a architecture specific bug in the > > shell? Hard to believe to say the least. > >... > > I can reproduce the problem in a current amd64 unstable chroot. Great, can you provide some information regarding how? Could you for example modify iptables.prerm to check what the content of $IFS is when you reproduce this? Did any other packages maintainer script (which does things with IFS) error out while you reproduce the problem with iptables? I can only speculate about this issue. I don't doubt the original reportes error message actually happened and is real, but I don't see how. The only possibility I see is that IFS was modified to a non-default value which made it no longer include tab- and space-characters. The iptables.prerm script doesn't set IFS itself, so I have to assume it somehow inherited a dirty environment from somewhere. Is it possible that some other packages maintainerscript code messed with IFS without resetting it and then that environment got inherited by iptables.prerm? If so then I think the package needs to be identified and this bug reassigned to it I don't think every package that has maintainerscripts should expect a dirty environment and guard against for example a non-default IFS, but that's kind of the only solution inside iptables that I can see have it explicitly (un)set IFS. I however don't think that's the correct solution, just a solution. > > #1007829 was a similar problem in arptables, > I haven't checked how these are related. I don't see how these two are related at all. #1007829 seems to be a simple logic error. Regards, Andreas Henriksson
Bug#1030240: wayfire: FTBFS with wlroots 0.16.1
On Wed, Feb 01, 2023 at 04:46:14PM +0100, Guido Günther wrote: > Hi, > On Wed, Feb 01, 2023 at 04:37:37PM +0100, Andreas Henriksson wrote: [...] > > FWIW here are some examples of autopkgtest for checking if pkg-config > > works for your own -dev packages: > > https://sources.debian.org/src/util-linux/2.38.1-4/debian/tests/ > > We have tests for that like ages: > > > https://salsa.debian.org/swaywm-team/wlroots/-/blob/debian/latest/debian/tests/ > > It just won't trigger if you don't need the vulkan renderer. Feel free > to submit a patch that exercises that as well. Not sure why your tests doesn't catch this then. You can reproduce this as simple as this: 1. start with a clean sid chroot (eg. `pbuilder login`) 2. add experimental to /etc/apt/sources.list 3. apt update 4. apt install libwlroots-dev/experimental 5. pkg-config --cflags wlroots Package vulkan was not found in the pkg-config search path. Perhaps you should add the directory containing `vulkan.pc' to the PKG_CONFIG_PATH environment variable Package 'vulkan', required by 'wlroots', not found There's nothing vulkan specific about my clean chroot. Anyone trying to use `pkg-config --cflags wlroots` should see it exit with 1 (error). FWIW here's what I get when I launch your tests in my chroot: ``` # ls -l total 8 -rwxr-xr-x 1 root root 248 Feb 1 16:30 build-test -rw-r--r-- 1 root root 300 Feb 1 16:30 test.c # ./build-test Package vulkan was not found in the pkg-config search path. Perhaps you should add the directory containing `vulkan.pc' to the PKG_CONFIG_PATH environment variable Package 'vulkan', required by 'wlroots', not found gcc test.c -lwlroots -lwayland-server Build test of test.c succeeded WLR_BACKENDS=headless ./a.out 00:00:00.000 [backend/backend.c:297] Loading user-specified backends due to WLR_BACKENDS: headless 00:00:00.000 [backend/headless/backend.c:68] Creating headless backend ``` So it doesn't seem like your test-case actually catches the pkg-config exit code (and apparently the build still succeeds without cflags). Regards, Andreas Henriksson
Bug#1030240: wayfire: FTBFS with wlroots 0.16.1
On Wed, Feb 01, 2023 at 04:23:00PM +0100, Andreas Henriksson wrote: > On Wed, Feb 01, 2023 at 04:03:47PM +0100, Guido Günther wrote: > > Hi, > > [..snip..] > > > This seems to be caused by wlroots/experimental missing a > > > build-dependency on libvulkan-dev and indeed after installing > > > that package the build works again. > > > > There is a build-dependency on libvulkan-dev. I think what you mean is > > the lack of a dependency in the libwlroots-dev package? > > Exactly... I've already retitled the bug report (again) to remove > my incorrect use of build-dep, when what I mean was -dev package > depending on another -dev package. FWIW here are some examples of autopkgtest for checking if pkg-config works for your own -dev packages: https://sources.debian.org/src/util-linux/2.38.1-4/debian/tests/ Regards, Andreas Henriksson
Bug#1030240: wayfire: FTBFS with wlroots 0.16.1
On Wed, Feb 01, 2023 at 04:03:47PM +0100, Guido Günther wrote: > Hi, > [..snip..] > > This seems to be caused by wlroots/experimental missing a > > build-dependency on libvulkan-dev and indeed after installing > > that package the build works again. > > There is a build-dependency on libvulkan-dev. I think what you mean is > the lack of a dependency in the libwlroots-dev package? Exactly... I've already retitled the bug report (again) to remove my incorrect use of build-dep, when what I mean was -dev package depending on another -dev package. Regards, Andreas Henriksson
Bug#1030240: wayfire: FTBFS with wlroots 0.16.1
Control: reassign -1 wlroots 0.16.1-1 Control: retitle -1 wlroots/exp: missing build-dep on libvulkan-dev (breaks pkg-config) Control: affects -1 wayfire On Wed, Feb 01, 2023 at 02:15:37PM +0100, Andreas Beckmann wrote: > Source: wayfire > Version: 0.7.5-1~exp1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > > Hi, > > wayfire/experimental recently started to FTBFS: [...] > Run-time dependency wlroots found: NO (tried pkgconfig and cmake) [...] > This seems to be related to the wlroots upgrade from 0.16.0 to 0.16.1 in > experimental. Did a build of my own and got some more useful information: Determining dependency 'wlroots' with pkg-config executable '/usr/bin/pkg-config' env[PKG_CONFIG_PATH]: Called `/usr/bin/pkg-config --modversion wlroots` -> 0 0.16.1 env[PKG_CONFIG_PATH]: Called `/usr/bin/pkg-config --cflags wlroots` -> 1 pkg-config error with 'wlroots': Could not generate cargs for wlroots: Package vulkan was not found in the pkg-config search path. Perhaps you should add the directory containing `vulkan.pc' to the PKG_CONFIG_PATH environment variable Package 'vulkan', required by 'wlroots', not found This seems to be caused by wlroots/experimental missing a build-dependency on libvulkan-dev and indeed after installing that package the build works again. Every package listed in pkg-config .pc files Requires* must be available and thus the package holding the .pc file referenced must be a build-dependency... otherwise pkg-config will not work. Adding autopkgtest to run pkg-config --cflags --libs etc. and maybe build a trivial example application is a great way to make sure pkg-config is working as expected (because it's easy to forget to check every .pc file changes and cross-check which package provides that and if it's listed in build-depends on every update). Regards, Andreas Henriksson
Bug#1030000: fontconfig: after upgrade from 2.13.1-4.5 to 2.14.1-3 subpixel is enabled
Hello Thorsten Glaser, Thanks for your bug report. On Mon, Jan 30, 2023 at 03:32:02AM +0100, Thorsten Glaser wrote: > Package: fontconfig > Version: 2.14.1-3 > Severity: serious > Justification: Policy 10.7.3 > X-Debbugs-Cc: t...@mirbsd.de > > > * local changes must be preserved during a package upgrade, and > > After an upgrade, etckeeper reports that > /etc/fonts/conf.d/10-sub-pixel-rgb.conf > shows up again, despite the local admin > choice to not have blurry fonts. Ouch, no relevant changes to maintainer scripts has been done. Have you experienced this problem in previous upgrades? Can you reproduce the problem at all? > > Running dpkg-reconfigure -plow fontconfig-config > shows that the debconf database correctly remembers > the admin-provided setting (subpixel disabled was > pre-selected), By 'disabled' I assume you mean 'Never', right? > and just pressing Enter on every > question makes it remove that file, Did it also create 10-no-sub-pixel.conf ? (Which would be consistent with 'Never'. If neither file exists, that's the 'Automatic' option which is also the default.) > so I believe that some maintainer script errorneously forcibly > creates that file overriding local configuration. Is there any chance you can try to find some additional information on what happened on your system? It sounds weird that you would end up with 'Always' option somehow when default is 'Automatic' and you supposedly selected 'Never'. The relevant code is here: https://sources.debian.org/src/fontconfig/2.14.1-3/debian/fontconfig-config.postinst/#L93-L116 Note that this is protected by: https://sources.debian.org/src/fontconfig/2.14.1-3/debian/fontconfig-config.postinst/#L32 https://sources.debian.org/src/fontconfig/2.14.1-3/debian/fontconfig-config.postinst/#L13-L23 (Thus it should not have run at all on upgrade.) See also: https://sources.debian.org/src/fontconfig/2.14.1-3/debian/fontconfig-config.config/#L49-L64 Possibly 'Always' option could have come from here: https://sources.debian.org/src/fontconfig/2.14.1-3/debian/fontconfig-config.config/#L56 But then again, the initial/re-configure should not have been run at all because of https://sources.debian.org/src/fontconfig/2.14.1-3/debian/fontconfig-config.postinst/#L32 as mentioned earlier. Regards, Andreas Henriksson
Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64
Hello, On Tue, Jan 31, 2023 at 02:26:50AM +0100, Helge Deller wrote: > Hi David & Andreas, > > On 1/28/23 12:10, David Prévot wrote: > > Le Wed, Jan 18, 2023 at 01:24:37AM +0100, Helge Deller a écrit : > > > On Sat, 14 Jan 2023 20:38:38 +0100 Andreas Henriksson > > > wrote: > > > > Here's a slightly different patch to implement basically the same thing > > > > > > Unfortunately, even if both patches allow me to build tar on i386, they > > also both lead to an FTBFS on amd64. > > That's right. glibc headers used by configure complains then that > _TIME_BITS=64 can only be > used if FILE_OFFSET_BITS=64 is defined too (which isn't the case on amd64 > as it's not needed there). > > So, please use this hunk instead. It compiles for me on amd64 and 32-bit hppa. In my attempt at https://salsa.debian.org/debian/tar/-/commits/wip/bug1026204 I tried to avoid hardcoding assumptions about flags (and rely on gnulib DTRT), but I agree what I came up with is just to convoluted and it's probably a better idea to just use Helges suggestion below. > > export DEB_BUILD_MAINT_OPTIONS = future=+lfs > export DEB_CFLAGS_MAINT_APPEND = -Wall -Wno-analyzer-null-argument Might be useful to add a comment here saying: # Workaround gnulib issue: The below three lines can be dropped once tar >= 1.35 is used. > ifneq ($(shell dpkg-architecture -qDEB_TARGET_ARCH_BITS),64) > export DEB_CPPFLAGS_MAINT_APPEND = -D_TIME_BITS=64 > endif > > DPKG_EXPORT_BUILDFLAGS = 1 > include /usr/share/dpkg/buildflags.mk > --- > Helge I assume you also have no idea how to use src:gnulib when building tar (or maybe it's just too complicated change)? (The problem should already be fixed in the version of src:gnulib we have in debian...) Will you go ahead and upload this Helge? Regards, Andreas Henriksson
Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64
Hello taffit, On Sat, Jan 28, 2023 at 12:10:53PM +0100, David Prévot wrote: > Hi, > > Le Wed, Jan 18, 2023 at 01:24:37AM +0100, Helge Deller a écrit : > > On Sat, 14 Jan 2023 20:38:38 +0100 Andreas Henriksson > > wrote: > > > Here's a slightly different patch to implement basically the same thing > > > > Yes, I like this patch better too. > > Unfortunately, even if both patches allow me to build tar on i386, they > also both lead to an FTBFS on amd64. Thanks for the feedback. I ran short on time when looking at this and tried to cheap out on just setting `-D_TIME_BITS=64` directly which causes problems. I generally have no clue when it comes to gnulib but I've now made an attempt at backporting the `year2038` gnulib module that upstream has enabled. I've pushed this here: https://salsa.debian.org/debian/tar/-/commits/wip/bug1026204 This time I've build-tested both on a sid amd64 chroot and a sid i386 chroot (on top of amd64). Maybe there's a better/cleaner way of doing this backport. I also have no idea if this impacts the output format of tar in any incompatible way, but hopefully it doesn't since upstream seems to now have it enabled by default in git atleast. Hopefully someone finds this useful... I'm not confident enough to actually upload this myself. Reviews welcome. Also note that the debian gnulib package seems to have the year2038 stuff in largefile.m4 already, so maybe it would be better to try to use that instead of the bundled m4 files in tar?!... (That should hopefully also sort out anyones worry about shipping generated (diff) files without source.) Regards, Andreas Henriksson
Bug#997274: NMU strace 6.1 for unstable?
Hello Steve McIntyre, As you might have noticed I've taken the liberty to NMU strace into *experimental*. I've done so based on my past experience that strace can have many architecture specific problems, to give me a picture of what the situation is for the latest upstream 6.1 release. (And since it's experimental we have the posisibily to just RM it and act like it never happened.) It seems like mips* has test failures (as usual?!). I've filed https://github.com/strace/strace/issues/235 with my limited conclusions about the issues. Given that strace has not been updated for the entire release cycle and that it's currently RC-buggy, I think it would be useful to try to update it before the 12 Feb freeze. The time window is however very small. Additionally ppc64el seems to have a huge build backlog, so if we want to make it during the limited time window before the freeze we can't wait for the results. (I could possibly build on a ppc64el porterbox to see if I can spot any problems there.) I would like to know what you think about a potential NMU of strace 6.1 to unstable at this point. Probably with mips* tests set to not fail the build (`|| true`). Possibly the same for ppc64el just to make sure it doesn't give any surprises once it finally builds (and the upload is old enough to migrate to testing). If I'm going to do the NMU I'll need to proceed very soon so your input on this would be very appreciated if you could give it ASAP! What do you think? Regards, Andreas Henriksson
Bug#999322: Intent to NMU
Hello, I intend to NMU changes to fix the outstanding RC bugs as well as some related changes for bonnie++ in Debian. The changes was made against the git repo and are available as a salsa MR at: https://salsa.debian.org/etbe/bonnie/-/merge_requests/2 Since these bugs seems to have been around for a long time (some including patches) and that we're getting really close to freeze I'm uploading directly into unstable without any delay to have a chance for bonnie++ to make it back into testing. Please feel free to do a maintainer upload to override my upload if there's anything in here that is controversial or wrong, but hopefully there isn't. Regards, Andreas Henriksson
Bug#1027383: xen-tools: FTBFS in bullseye (missing build-depends on mount)
Hello Santiago Vila, While I do consider this a valid (wishlist) bug report, ... On Fri, Dec 30, 2022 at 07:04:32PM +0100, Santiago Vila wrote: > Package: src:xen-tools > Version: 4.9-1 > Severity: serious > Tags: ftbfs patch [...] > CPUs, using a reduced chroot with only build-essential packages (plus > debhelper). [...] This IMHO means you're using an *unsupported* system setup! None of the debootstrap variants lacks `Priority: required` packages and I don't think this warrants a release-critical severity. (You might argue about the exact wording of policy, but I think you should better do that in a policy bug report or their mailing list. This is not a practical problem until you use an unsupported setup, which means you get to keep all the pieces. The name of the priority level should be pretty self-explanatory - *required*, not recommended.) As already mentioned, I think wishlist is the proper severity. (And as said, I don't mind this being considered a bug or fixing it which is simple... however with a relevant severity.) Regards, Andreas Henriksson
Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64
Hello, On Fri, Dec 16, 2022 at 09:13:44AM +0100, Helge Deller wrote: > Package: tar > Version: 1.34+dfsg-1.1 > Tags: hppa, patch, ftbfs, lfs [...] > I've found, that changing the line 12 in debian/rules from > CPPFLAGS = `dpkg-buildflags --get CPPFLAGS` > to: > CPPFLAGS = `dpkg-buildflags --get CPPFLAGS` -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64 -D__USE_TIME_BITS64 > does solve the issue. [...] Thanks for identifying the solution already. Here's a slightly different patch to implement basically the same thing (and I can confirm it builds in an i386 chroot which previously failed). (Note: The initial two lines in debian/rules could also be replaced by `include /usr/share/dpkg/architecture.mk` for further slight modernization.) Regards, Andreas Henriksson --- a/debian/rules 2023-01-14 19:20:32.572449385 + +++ b/debian/rules 2023-01-14 19:19:02.745766528 + @@ -6,10 +6,12 @@ CONFARGS = --host=$(DEB_HOST_GNU_TYPE) endif -CFLAGS = `dpkg-buildflags --get CFLAGS` -CFLAGS += -Wall -Wno-analyzer-null-argument -LDFLAGS += `dpkg-buildflags --get LDFLAGS` -CPPFLAGS = `dpkg-buildflags --get CPPFLAGS` +export DEB_BUILD_MAINT_OPTIONS = future=+lfs +export DEB_CFLAGS_MAINT_APPEND = -Wall -Wno-analyzer-null-argument +export DEB_CPPFLAGS_MAINT_APPEND = -D_TIME_BITS=64 + +DPKG_EXPORT_BUILDFLAGS = 1 +include /usr/share/dpkg/buildflags.mk export BUILD_DATE = $(shell dpkg-parsechangelog | sed -n -e 's/^Date: //p')
Bug#1027619: gh: FTBFS: tests fail
Hello Lucas Nussbaum, Could you please provide some additional input? See below. On Sun, Jan 01, 2023 at 03:33:44PM +0100, Lucas Nussbaum wrote: > Source: gh > Version: 2.18.1+dfsg1-1 > Severity: serious > Justification: FTBFS [...] > > === RUN TestStartJupyterServerFailure > > client_test.go:70: error connecting to internal server: failed to share > > remote port 16634: dial tcp 127.0.0.1:50051: connect: connection refused > > --- FAIL: TestStartJupyterServerFailure (0.00s) > > FAIL > > FAILgithub.com/cli/cli/v2/internal/codespaces/grpc 0.039s > > ? github.com/cli/cli/v2/internal/codespaces/grpc/jupyter [no > > test files] > > ? github.com/cli/cli/v2/internal/codespaces/grpc/test [no > > test files] > > ? github.com/cli/cli/v2/internal/config [no test files] [...] Port 16634 is hardcoded at: ./internal/codespaces/grpc/client.go: codespacesInternalPort= 16634 If this port is not available I presume things will just fail. I've rebuilt the package locally and it succeeds for me. It also succeded on the official buildds. If you are able to reproduce the problem it would be great if you could check what is using the port to identify if it's some external program using this port and thus making the test fail or if it possibly is the test-suite racing against itself somehow. As far as I can tell right now, this issue doesn't seem release-critical to me so consider if maybe the severity should be downgraded. Regards, Andreas Henriksson
Bug#1027803: src:fakeroot: fails to migrate to testing for too long: ftbfs on mipsel
Hello, So the mipsel FTBFS is because of a failing test-case that was added in the 1.30-1 version of fakeroot. For more information on this issue see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023286#48 Regards, Andreas Henriksson
Bug#1028278: dh-cmake FTBFS with Python 3.11 as default version
On Mon, Jan 09, 2023 at 08:02:05AM +0200, Adrian Bunk wrote: > Source: dh-cmake > Version: 0.6.1 > Severity: serious > Tags: ftbfs bookworm sid > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dh-cmake.html [...] > > File "/build/1st/dh-cmake-0.6.1/dhcmake/tests/source_check.py", line 25, in > > self.foreach_py(lambda a, r, c: self.assertEqual(autopep8.fix_code(c), c, > ^ > AssertionError: '# Th[204 chars]\n\n# from unittest import skip\n\nimport > os\n[9838 chars]e)\n' != '# Th[204 chars]\n\n#from unittest import > skip\n\nimport os\nf[9837 chars]e)\n' > Diff is 10430 characters long. Set self.maxDiff to None to see it. : File > dhcmake/tests/common.py is incorrectly formatted [...] So same as above, but in my own words: It seems autopep8.fix_code() has changed it's opinion on formatting and now thinks dhcmake/tests/common.py line 5 should have a space after the hash (#) character (before `from unittest import skip`). The new style looks better IMHO and this might be a bugfix in autopep8.fix_code(), but at the same time changes like these might cause alot of breakage (atleast if used in tests like in this case). Regards, Andreas Henriksson
Bug#1025884: src:ddnet: fails to migrate to testing for too long: FTBFS on s390x
Hello, The upstream PR fixing big endian builds that Adrian Bunk previously set in the forwarded control message is now merged upstream. It would be great if this commit could be cherry-picked as a patch into the ddnet package to fix build os s390x (big endian): https://github.com/ddnet/ddnet/commit/abb1979d20d9a3290442d5d0ed304ce24c0a710e Regards, Andreas Henriksson
Bug#1028146: collectd FTBFS with Python 3.11 as default version
Control: tags -1 + fixed-upstream Control: forwarded -1 https://salsa.debian.org/debian/pkg-collectd/-/merge_requests/11 Hello, The python 3.11 issue is fixed upstream in this commit: https://github.com/collectd/collectd/commit/623e95394e0e62e7f9ced2104b786d21e9c0bf53 A merge-request against the debian collectd packaging git repo has been opened, albeit with a different patch than upstreams: https://salsa.debian.org/debian/pkg-collectd/-/merge_requests/11 Regards, Andreas Henriksson
Bug#1016963: Please test u-boot for rpi_4 rpi_4_32b
On Tue, Jan 03, 2023 at 11:56:51PM +0100, Andreas Henriksson wrote: > On Tue, Jan 03, 2023 at 11:46:31PM +0100, Andreas Henriksson wrote: > > On Wed, Dec 28, 2022 at 04:11:04PM -0800, Vagrant Cascadian wrote: > > > rpi_4 > > > rpi_4_32b [...] Hello again, While I only have the earliest rpi 4B rev A0 (1.1) it has come to my attention that apparently there's a revision C0 (1.4) that has problems booting with u-boot. Apparently in 1.4 revision they changed the hardware in an incompatible way and then cover this up by having the proprietary firmware modify the dtb in ram to change nodes as needed. The issue has been discussed on the rpi forums: https://forums.raspberrypi.com/viewtopic.php?t=315662 There has been seemingly two indenpendent attempts at submitting (very similar) patches upstream to adress this in u-boot: https://lists.denx.de/pipermail/u-boot/2021-November/468322.html https://lists.denx.de/pipermail/u-boot/2021-September/462020.html ... but apparently they've never been merged. NixOS are carrying patches: https://github.com/NixOS/nixpkgs/tree/master/pkgs/misc/uboot which includes some revision of Sjoerds patch. Some info on board revisions can be found at: https://www.raspberrypi-spy.co.uk/2012/09/checking-your-raspberry-pi-board-version/ This issue probably deserves it's own separate bug report, but since I don't have the hardware in question I'm leaving that to who ever else cares and just share the info I have. It might be useful to consider just include NixOS/Sjoerds patch or documenting that RPi 4B hw rev 1.4 will not work. (Hardware revision is visible in /proc/cpuinfo under the Revision: field.) However it maybe best trying to find someone who has the affected hardware revision that can confirm the problem exists and that the patch actually resolves it. Regards, Andreas Henriksson
Bug#909750: RFC: fontconfig 2.14.1-1 experimental branch on salsa.debian.org
Hello all, As per my previous call for review and testing. New upstream release of fontconfig is now in experimental. (The big endian FTBFS should be fixed in git.) If people who experienced #909750 could help confirm if the problem is fixed or now that feedback would be very welcome! Also general feedback if it's suitable to upload the experimental package to unstable this close to the freeze (which I feel will need to happen ASAP or wait until after the release). If I don't get any feedback, I will likely not upload to unstable. Regards, Andreas Henriksson
Bug#1016963: Please test u-boot for rpi_4 rpi_4_32b
On Tue, Jan 03, 2023 at 11:46:31PM +0100, Andreas Henriksson wrote: > On Wed, Dec 28, 2022 at 04:11:04PM -0800, Vagrant Cascadian wrote: > > rpi_4 > > rpi_4_32b > > I dug up my old dusty rpi4 which I probably haven't touched > since last time we spoke about u-boot on it. > > > I've tested only the 64bit (arm64) version so far. [...] > I upgraded only u-boot.bin from bookworm/sid/experimental [...] > The unstable and experimental versions both caused a reset > after run bootcmd and before "Starting Linux...". [...] After upgrading rpi firmware files to latest release/tag also the unstable and experimental u-boot seemed to boot fine (no reset, garbage on console after linux started). ### unstable u-boot with rpi firmware-1.20221104.tar.gz U-Boot 2022.10+dfsg-2 (Dec 23 2022 - 23:18:44 +) DRAM: 3.9 GiB RPI 4 Model B (0xc03111) Core: 209 devices, 16 uclasses, devicetree: board MMC: mmcnr@7e30: 1, mmc@7e34: 0 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In:serial Out: serial Err: serial Net: eth0: ethernet@7d58 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 U-Boot> U-Boot> U-Boot> U-Boot> U-Boot> U-Boot> U-Boot> U-Boot> run bootcmd switch to partitions #0, OK mmc0 is current device Scanning mmc 0:2... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf U-Boot menu 1: Debian GNU/Linux 5.7.0-1-arm64 2: Debian GNU/Linux 5.7.0-1-arm64 (rescue target) Enter choice: 1:Debian GNU/Linux 5.7.0-1-arm64 Retrieving file: /boot/initrd.img-5.7.0-1-arm64 Retrieving file: /boot/vmlinuz-5.7.0-1-arm64 append: root=LABEL=root ro rootwait console=ttyS1,115200 Retrieving file: /usr/lib/linux-image-5.7.0-1-arm64/broadcom/bcm2711-rpi-4-b.dtb ## Flattened Device Tree blob at 0260 Booting using the fdt blob at 0x260 Using Device Tree in place at 0260, end 0260896e Starting kernel ... [... garbage characters...] ### experimental u-boot with rpi firmware-1.20221104.tar.gz U-Boot 2023.01-rc4+dfsg-1 (Dec 24 2022 - 03:13:23 +) DRAM: 948 MiB (effective 3.9 GiB) RPI 4 Model B (0xc03111) Core: 209 devices, 16 uclasses, devicetree: board MMC: mmcnr@7e30: 1, mmc@7e34: 0 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In:serial Out: serial Err: serial Net: eth0: ethernet@7d58 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 U-Boot> U-Boot> U-Boot> U-Boot> run bootcmd switch to partitions #0, OK mmc0 is current device Scanning mmc 0:2... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf U-Boot menu 1: Debian GNU/Linux 5.7.0-1-arm64 2: Debian GNU/Linux 5.7.0-1-arm64 (rescue target) Enter choice: 1:Debian GNU/Linux 5.7.0-1-arm64 Retrieving file: /boot/initrd.img-5.7.0-1-arm64 Retrieving file: /boot/vmlinuz-5.7.0-1-arm64 append: root=LABEL=root ro rootwait console=ttyS1,115200 Retrieving file: /usr/lib/linux-image-5.7.0-1-arm64/broadcom/bcm2711-rpi-4-b.dtb ## Flattened Device Tree blob at 0260 Booting using the fdt blob at 0x260 Working FDT set to 260 Using Device Tree in place at 0260, end 00000260896e Working FDT set to 260 Starting kernel ... [...garbage characters...] Regards, Andreas Henriksson
Bug#1016963: Please test u-boot for rpi_4 rpi_4_32b
On Wed, Dec 28, 2022 at 04:11:04PM -0800, Vagrant Cascadian wrote: > rpi_4 > rpi_4_32b I dug up my old dusty rpi4 which I probably haven't touched since last time we spoke about u-boot on it. I've tested only the 64bit (arm64) version so far. The version that was on the sd-card since last time: U-Boot> ver U-Boot 2020.07+dfsg-1 (Jul 08 2020 - 23:29:02 +) gcc (Debian 9.3.0-14) 9.3.0 GNU ld (GNU Binutils for Debian) 2.34.90.20200706 U-Boot> I upgraded only u-boot.bin from bookworm/sid/experimental on the firmware partition (nothing else touched, and I'm not really sure what state it was in since last time but probably a bootable system atleast). Testing/bookworm u-boot.bin seems to boot fine (although serial console became garbage after Linux started, but it seemed to run but I didn't investigate much). The unstable and experimental versions both caused a reset after run bootcmd and before "Starting Linux...". U-Boot itself seemed to run fine though, it was running bootcmd that caused the reset. Maybe I need to upgrade the rpi firmware, or maybe it's related to what else is on the old sd-card that was in the box. # testing u-boot U-Boot> ver U-Boot 2022.04+dfsg-2+b1 (May 14 2022 - 19:14:13 +) gcc (Debian 11.3.0-1) 11.3.0 GNU ld (GNU Binutils for Debian) 2.38 U-Boot> # unstable u-boot U-Boot> ver U-Boot 2022.10+dfsg-2 (Dec 23 2022 - 23:18:44 +) gcc (Debian 12.2.0-10) 12.2.0 GNU ld (GNU Binutils for Debian) 2.39.50.20221208 U-Boot> U-Boot 2022.10+dfsg-2 (Dec 23 2022 - 23:18:44 +) DRAM: 3.9 GiB RPI 4 Model B (0xc03111) Core: 135 devices, 14 uclasses, devicetree: board MMC: mmcnr@7e30: 1, emmc2@7e34: 0 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In:serial Out: serial Err: serial Net: eth0: genet@7d58 PCIe BRCM: link up, 5.0 Gbps x1 (!SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller Port not available. Hit any key to stop autoboot: 0 "Synchronous Abort" handler, esr 0x9644 elr: 0009f3a8 lr : 0009572c (reloc) elr: 3b36c3a8 lr : 3b36272c x0 : 3af52610 x1 : 3af52680 x2 : 0051 x3 : 6964003b6963765f x4 : 3b3d0890 x5 : 3b3d0890 x6 : 005b x7 : 3b3d0e30 x8 : 3b3d0820 x9 : 0008 x10: fff0 x11: 0006 x12: 0001869f x13: 3af3e708 x14: 3af3e810 x15: x16: 3b36d548 x17: 596fcb0297bbddff x18: 3af48d70 x19: 0071 x20: 3b3d0880 x21: x22: 0005 x23: 000a x24: 0001 x25: 3b3e4cd8 x26: x27: 3b3c4851 x28: 006d x29: 3af3d9e0 Code: a9410803 8b130001 b2400273 f9000413 (f9000c62) Resetting CPU ... resetting ... # experimental u-boot U-Boot> ver U-Boot 2023.01-rc4+dfsg-1 (Dec 24 2022 - 03:13:23 +) gcc (Debian 12.2.0-10) 12.2.0 GNU ld (GNU Binutils for Debian) 2.39.50.20221208 U-Boot> U-Boot> run bootcmd "Synchronous Abort" handler, esr 0x9644 elr: 0009f7e0 lr : 00095e0c (reloc) elr: 3b36c7e0 lr : 3b362e0c x0 : 3af59470 x1 : 3af59490 x2 : 30636d6d x3 : 5f646d63746f6f00 x4 : 0070 x5 : 3b3d0e08 x6 : 005b x7 : 3b3d13a8 x8 : 0050 x9 : 0008 x10: fff0 x11: 0006 x12: 0001869f x13: 3af3e708 x14: 3af3e810 x15: x16: 3b36d994 x17: d9ff4b22fffbdcff x18: 3af48d70 x19: 0021 x20: 3b3d0df8 x21: 3af59d80 x22: 3af59b20 x23: 0010 x24: 0008 x25: 3b3e5258 x26: 0002 x27: 3b3c4e54 x28: 0073 x29: 3af3da10 Code: a9410803 8b130001 b2400273 f9000413 (f9000c62) Resetting CPU ... resetting ... U-Boot 2023.01-rc4+dfsg-1 (Dec 24 2022 - 03:13:23 +) [...]
Bug#1020707: popa3d: postinst should use policy-mandated helpers
Package: popa3d Version: 1.0.3-1 Severity: serious Tags: patch Dear Maintainer, The postinst script currently directly calls into the init script, while Debian Policy mandate that all interactions from maintainer scripts should happen via the policy helpers invoke-rc.d, et.al. https://www.debian.org/doc/debian-policy/ch-opersys.html#running-init-scripts For your convenience I've attached a patch that should fix this, however notice that I have *not* tested it! Bonus list of things you might want to consider looking at "while you're in there" (some of these might be policy violations of their own, some not): * update_defaults is always called, should likely only be called when package is reconfigured or initially configured. Sysadms can make changes to the configuration, doesn't need to use dpkg-reconfigure / debconf, and loosing their config on package upgrades is critical severity because of data loss. https://www.debian.org/doc/debian-policy/ap-flowcharts.html https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-configuration https://www.debian.org/doc/debian-policy/ch-files.html#behavior https://www.debian.org/Bugs/Developer#severities * update_defaults modifies conffiles in a non-policy compliant way. consider using the ucf tool for installing changed /etc/default/popa3d Using ucf will both prompt on changes and save a backup of the old file, as required. * tempfile command has no cleanup (see trap example in man tempfile). * Attempt to catch $? and conditionally exit on error, but the script already uses `set -e` so any command returning error will abort the script immediately. Was this ever tested? * "WARNING: tempfile is deprecated; consider using mktemp instead." * "# /var/lib/popa3d should be created by package" well it's /var so don't trust it to be unchanged. Should probably wrap the chmod/chown commands in an `if test -d /var/lib/popa3d ; then`. Regards, Andreas Henriksson diff --git a/debian/postinst b/debian/postinst index 75e32aa..4b27350 100644 --- a/debian/postinst +++ b/debian/postinst @@ -17,7 +17,9 @@ update_defaults() update-inetd --pattern "popa3d" --remove pop3 else RUN_STANDALONE="no" - pidof popa3d && /etc/init.d/popa3d stop + if invoke-rc.d --quiet popa3d status > /dev/null 2>&1 ; then + invoke-rc.d popa3d stop + fi # Add service to /etc/inetd.conf update-inetd --group MAIL --add 'pop3\t\tstream\ttcp\tnowait\troot\t/usr/sbin/tcpd\t/usr/sbin/popa3d' fi
Bug#1013447: gupnp-tools: gupnp-av-cp fails to detect upnp av serveur that kodi or vlc detects correctly
Control: severity -1 normal Control: tags -1 moreinfo Hello Eric Valette, On Thu, Jun 23, 2022 at 10:54:10PM +0200, Eric Valette wrote: > Package: gupnp-tools > Version: 0.10.3-1 > Severity: grave > Justification: renders package unusable > The gupnp-tools package consists of multiple tools. You're stating the bug you report are making the package unusable, thus all tools are supposedly completely unusable. Since you only actually briefly mention gupnp-av-cp I'm going to downgrade severity right off the bat. > starting gupnp-av-cp does not detect any DLNA (minidlnad, smartv TV, > ...) content server on local network. Could you please give details on how these devices exposes themselves on the network? The gupnp-av-cp tool will only list Media Renderer and Media Servers. That is devices exposing themselves as Type urn:schemas-upnp-org:device:MediaRenderer:1 or urn:schemas-upnp-org:device:MediaServer:1 See: https://sources.debian.org/src/gupnp-tools/0.10.3-1/src/av-cp/main.c/#L112-L113 https://sources.debian.org/src/gupnp-tools/0.10.3-1/src/av-cp/main.c/#L40-L41 My Smart TV's for example exposes themselves as Type urn:dial-multiscreen-org:device:dial:1 according to gupnp-universal-cp (also part of gupnp-tools package!). They will thus be filtered out from being displayed in gupnp-av-cp. If you want to test something which will expose itself as something that will show up in gupnp-av-cp that could for example be gmediarender. Things seems to work as expected to me, although DLNA/UPnP-AV itself and proprietary vendors implementations of it are indeed quite confusing. > > VLC and Kodi do detect them. Regards, Andreas Henriksson
Bug#1008395: marked as pending in golang-github-bmatsuo-lmdb-go
Control: tag -1 pending Hello, Bug #1008395 in golang-github-bmatsuo-lmdb-go reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-github-bmatsuo-lmdb-go/-/commit/c2642ddc97761a0386969407d4d7f7f70f86c9c4 Add patch to fix FTBFS with go 1.18 https://github.com/bmatsuo/lmdb-go/issues/143 Closes: #1008395 (this message was generated automatically) -- Greetings https://bugs.debian.org/1008395
Bug#998586: marked as pending in libgxps
Control: tag -1 pending Hello, Bug #998586 in libgxps reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/gnome-team/libgxps/-/commit/d59208d95950ea4726f4e8fea6d827b902971db4 Fix config option typo (libgjpeg->libjpeg) The option together with the typo was introduced in: commit a45acc67a02f374e05710a517aca527d111e2146 "add more configure flags, to be explicit" Closes: #998586 (this message was generated automatically) -- Greetings https://bugs.debian.org/998586
Bug#1004615: marked as pending in gnome-sound-recorder
Control: tag -1 pending Hello, Bug #1004615 in gnome-sound-recorder reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/gnome-team/gnome-sound-recorder/-/commit/259d39c5c4233d4ecdc1f9c5ceb3d540e9f6f670 Cherry-pick patch from upstream to fix FTBFS "Ignored in Meson < 0.60.0, deprecated since 0.60.1 and fatal since 0.61.0." Closes: #1004615 (this message was generated automatically) -- Greetings https://bugs.debian.org/1004615
Bug#998528: marked as pending in file-roller
Control: tag -1 pending Hello, Bug #998528 in file-roller reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/gnome-team/file-roller/-/commit/30206544c02e1e62318696e3c9d6446e27a502b0 Remove use of libmagic (upstream dropped support) The magic configure option no longer exists and now causes a failure to build from source. Relevant upstream commits: commit 067036301b0a0bdadacc24823faff4d7001cf4c6 Author: Jasper Lievisse Adriaanse Date: Sun Jan 6 14:06:04 2019 +0100 Remove libmagic leftovers from ab34e3f7 commit ab34e3f765183136c3e548f180751ffe5efd3860 Author: Paolo Bacchilega Date: Mon Aug 20 12:26:52 2018 +0200 removed use of magic to detect the mime type from content magic doesn't detect zip files from content, which is very important to us. Closes: #998528 (this message was generated automatically) -- Greetings https://bugs.debian.org/998528
Bug#991082: gir1.2-gtd-1.0 has empty Depends
Hello Adrian Bunk,
On Tue, Jul 13, 2021 at 09:35:24PM +0300, Adrian Bunk wrote:
> Package: gir1.2-gtd-1.0
> Version: 3.28.1-2
> Severity: serious
>
> ${gir:Depends} needs "dh --with gir" in debian/rules.
Sure, why not it looks like a possible oversight and could be added
to the packaging at some point.
>
> Something might still go wrong after that,
> when trying it did not generate dependencies
> on any library:
> Depends: gir1.2-glib-2.0, gir1.2-gtk-3.0 (>= 3.19.5)
There is no traditional shared object to depend on
The files that are being introspected (a) are part of the main program
executable (b) as can be seen in src/meson.build.
(a):
https://sources.debian.org/src/gnome-todo/3.28.1-6/src/meson.build/#L211
(b):
https://sources.debian.org/src/gnome-todo/3.28.1-6/src/meson.build/#L43
The easiest way to "solve" this would likely be to just set the
introspection build option (c) to false and drop the gir1.2-gtd-1.0
package as it has no reverse dependencies.
(c):
https://sources.debian.org/src/gnome-todo/3.28.1-6/meson_options.txt/#L11
I'm not sure which actual problem that solves though. Do you have
a particular use-case that's affected by this?
If this is only a theoretical correctness discussion, then I don't think
it deserves any attention before the release (or even future point
releases). I fear that if pushing through the suggested "solution",
next you'll find out that libgnome-todo-dev doesn't depend on
any shared object package either... then start filing bug reports
about libnome-todo lacking a sover in the name, not containing
a shared object, etc Is there anything that's actually breaking
in the real world caused by anything discussed in this bug report?
(Note libgnome-todo-dev has no rdeps either, and the content of
libgnome-todo could likely just be folded into the gnome-todo
binary package... and then why not merge gnome-todo-common as well
to really simplify the packaging making this a simple single-
binary package. OTOH changes like that are likely better done
during the next development cycle... and by someone who knows
what the future direction of gnome-todo might be, but feel free
to send a merge-request!)
Regards,
Andreas Henriksson
Bug#985948: libubootenv-tool: Debug lines from fw_printenv break RAUC, mender-client, etc.
Hello again, On Wed, Apr 07, 2021 at 11:36:30AM +0200, Andreas Henriksson wrote: [...] > I've submitted a merge-request that fixes the imminent problems for > review at: > https://salsa.debian.org/debian/libubootenv/-/merge_requests/3 [...] I've studied things a bit more and updated the merge-request with more of a cleanup approach that simply drops unused settings and then just adds defining NDEBUG via debhelper variables. (More detailed info in each commit message.) Please speak up ASAP if you're interested in reviewing this and doing a maintainer upload, otherwise I might not wait very long before I make use the 0-day NMU policy. I'd really like to see this be fixed in bullseye very soon. Please also speak up if you don't have time and want me to proceed with the NMU and dealing with the unblock request so I know! Regards, Andreas Henriksson
Bug#985948: libubootenv-tool: Debug lines from fw_printenv break RAUC
Control: affects -1 mender-client Hi, On Sat, Apr 03, 2021 at 02:52:34PM +0200, Bastian Germann wrote: > Control: tags -1 patch > > A patch is enclosed. [...] > CMAKE_FLAGS = \ > -DCMAKE_VERBOSE_MAKEFILE=ON \ > - -DCMAKE_C_FLAGS_RELEASE="$(CFLAGS)" \ > + -DCMAKE_C_FLAGS_RELEASE="$(CFLAGS) NDEBUG=" \ > -DCMAKE_EXE_LINKER_FLAGS_RELEASE="$(LDFLAGS)" \ > -DBUILD_DOCS=ON \ > -DCMAKE_INSTALL_INCLUDEDIR="include/$(DEB_HOST_MULTIARCH)" Your patch seems to have been applied in the last upload and this bug report was closed. I've reopened the bug report, as the bug seems to still exist: $ dpkg -l libubootenv0.1 | grep ^ii libubootenv0.1:armhf 0.3-2armhfLibrary to access U-Boot environment - runtime $ strings /usr/lib/arm-linux-gnueabihf/libubootenv.so.0.3 | grep Environment Environment %s, copy %d Environment FLAGS %s $ sudo fw_printenv | head -n1i Environment OK, copy 1 FYI This extra debug output also breaks mender-client. Could we please just add a patch that either just rips out the NDEBUG lines (or inverts the login to #ifdef DEBUG ) ?! Such a patch could/should be forwarded upstream as well.... A library should not print to stdout like this! Regards, Andreas Henriksson
Bug#984983: python3-networkmanager: crashes on unknown device types (eg. wifi p2p) in >=bullseye
Package: python3-networkmanager
Version: 2.1-2
Severity: serious
Justification: Incompatibility with bullseye NM causes crashes enumerating
devices etc.
Dear Maintainer,
I'm experiencing python3-networkmanager crashing with a simple test
program like this:
$ cat /tmp/test.py
#!/usr/bin/python3
import NetworkManager
for dev in NetworkManager.NetworkManager.Devices:
if dev.DeviceType == NetworkManager.NM_DEVICE_TYPE_WIFI:
print(dev)
print("Program finished")
$ python3 /tmp/test.py
Traceback (most recent call last):
File "/tmp/test.py", line 6, in
for dev in NetworkManager.NetworkManager.Devices:
File "/usr/lib/python3/dist-packages/NetworkManager.py", line 174, in get_func
return fixups.to_python(klass, 'Get', name, data, attrib['type'])
File "/usr/lib/python3/dist-packages/NetworkManager.py", line 555, in
to_python
val = fixups.base_to_python(val)
File "/usr/lib/python3/dist-packages/NetworkManager.py", line 612, in
base_to_python
return [fixups.base_to_python(x) for x in val]
File "/usr/lib/python3/dist-packages/NetworkManager.py", line 612, in
return [fixups.base_to_python(x) for x in val]
File "/usr/lib/python3/dist-packages/NetworkManager.py", line 625, in
base_to_python
return globals()[classname](val)
File "/usr/lib/python3/dist-packages/NetworkManager.py", line 353, in __new__
klass = device_class(obj.Get('org.freedesktop.NetworkManager.Device',
'DeviceType', dbus_interface='org.freedesktop.DBus.Properties'))
File "/usr/lib/python3/dist-packages/NetworkManager.py", line 373, in
device_class
return {
KeyError: dbus.UInt32(30, variant_level=1)
The reason appears to be that NM in bullseye supports and returns a
(disconnected=30) wifi p2p interface on my device.
Here's some info from the affected system:
$ nmcli d
DEVICE TYPE STATE CONNECTION
wlan0 wifi connected FOOBAR
p2p-dev-wlan0 wifi-p2p disconnected --
lo loopback unmanaged --
The mere existance of p2p-dev-wlan0 causes the crash and the needed constant
values in python3-networkmanager was added in new upstream release 2.2.
FWIW the problem is also reproducible on a buster system with a partial
update to NM (and deps) from bullseye. The p2p feature is thus not a new
kernel feature or similar, simply new info exposed by NM.
As mentioned, this is fixed in upstream release 2.2.
I've also filed a pre-approval request to update to 2.2 during freeze,
see Bug#984925
Regards,
Andreas Henriksson
Bug#983917: marked as pending in libgweather
Control: tag -1 pending Hello, Bug #983917 in libgweather reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/gnome-team/libgweather/-/commit/bacbf97c838abb33c18aceff09bb06d6df396329 Add patches from upstream for yr.no->met.no API These patches has been cherry-picked from upstream and modified to apply directly to the yrno backend (without renaming it to metno and breaking the API). Closes: #983917 (this message was generated automatically) -- Greetings https://bugs.debian.org/983917
Bug#983917: gnome-weather: Fails to get forecast data
Control: reassign -1 libgweather-3-16 3.36.1-1 Thanks for your bug report, more info below. On Wed, Mar 03, 2021 at 11:58:38AM +0100, Pelle wrote: > Package: gnome-weather > Version: 3.36.1-1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > Gnome Weather fails to get forecast data. After entering a location the app > shows the message: "Forecast data not available" [...] Apparently yr.no has discontinued it's old API and a new one is available from met.no. The changes needed are in libgweather and has been done for libgweather 40.x releases upstream. The changes includes atleast one API change which possibly makes it not possible to simply update libgweather. Here are a bunch of commits to look closer at: https://gitlab.gnome.org/GNOME/libgweather/-/commit/3f8f622e9a7d532b9041133bfcc42b67f0cdd9da https://gitlab.gnome.org/GNOME/libgweather/-/commit/c0c39a54b67849efe17367fa9b6f1ca7ad58349b https://gitlab.gnome.org/GNOME/libgweather/-/commit/44d042336f9439ca3b341b5bcb44c55a3384fa66 https://gitlab.gnome.org/GNOME/libgweather/-/commit/6b3c33980a56f6c8ffa1cb516560c495bec88fc8 https://gitlab.gnome.org/GNOME/libgweather/-/commit/924671fe2022f1d3bd7179a04dfb6c9f0780a77a https://gitlab.gnome.org/GNOME/libgweather/-/commit/d49f7f90dc8af135260009e313e718704b284257 https://gitlab.gnome.org/GNOME/libgweather/-/commit/827631c054cda713e89a36862a54a4c88632cac3 And finally the API breaking fixup commit in gnome-weather is: https://gitlab.gnome.org/GNOME/gnome-weather/-/commit/6763f7dc9cb25eac4aa13e94e07ea932a42c8e4d Regards, Andreas Henriksson
Bug#941624: Recommending ibus breaks fcitx
Hello Shengjing Zhu, (FYI I've not been part of pkg-gnome maintenance for the better part of bullseye development cycle and don't speak for pkg-gnome team, but I feel this is not a new issue and hopefully my input can hopefully help shed some light on the situation at hand...) First let me be clear that IBus is *THE* input method supported by GNOME. This is not a decision made by or influenced in any way by pkg-gnome maintainers. The pkg-gnome maintainers simply makes a judgement call on how to best describe the situation in the form of package relations. It is also my previous experience that pkg-gnome team has little to no influence over how tasksel describes things (and I doubt anything has changed). You might find it that a third party actually has higher chance of getting tasksel maintainers to make changes to tasksel if they discuss it with tasksel maintainers, rather than trying to go via pkg-gnome team. My personal best recommendation is to simply not use tasksel! (And I wish I could have all the time back that I've wasted on supporting confused users who ended up with problems from using tasksel over simply using gnome meta-packages. Tasksel simply isn't helpful.) All the problems you describe to me just sounds like you're describing tasksel issues. Some specific comments for things you raised below. On Mon, Mar 01, 2021 at 11:06:53PM +0800, Shengjing Zhu wrote: [...] > + Users are now possible to install two input engines. It troubles than > benefits. Bring this up with input engine maintainers. If it's true that having more than one installed at any time isn't useful, then the solution is that they all provide a common (virtual) package which they all also conflict against. Then pulling in one will push out all the others. This is not related to gnome-shell! > + And the tasksel won't install corresponding language library for ibus. > + And for the im-config, it's not possible to decide which engine is preferred > by the tasksel data. Please bring up tasksel issues with tasksel maintainers. This is not related to gnome-shell! > Yes you can say that users change it by hand, but it's not > what we want to achieve. We want a working desktop for different users by > default. > > If GNOME maintainer want to change the default input method, it's better to > do it in tasksel package. I don't understand why you think tasksel has any influence over what GNOME does Likely many/most GNOME developers aren't even aware of tasksel existance. It's an arcane Debian-only program after all. > > Please downgrade ibus to Suggests for bullseye. It is my personal general reflection that issues like this exists because debian maintainers tries too hard to be accomodating towards tweakers which just causes problems and confusion. As ripping out IBus from under GNOME already requires hacks, I think it would simply be a better idea to bump to Depends (and tell tweakers to use equivs). That would hopefully make the situtation less confusing for people and more obvious that tweakers are on their own with whatever hack they come up with. Some info already available at: https://wiki.debian.org/InputMethodBuster Possibly we could also consider adding (versioned?) Conflicts against tasksel packages, since there's a long standing disconnect between GNOME and tasksel meta-package descriptions. To be able to do versioned conflicts tasksel would first need to have a fixed version though, so please bring it up with them and then feedback which packages and versions are relevant to conflict against. As of right now, this is something I simply consider "wontfix" from gnome-shells point of view. No matter how the package relationship is described, the situation that GNOME relies on IBus won't change! Please also feel free to follow up you severity bump with a justification pointing out which specific policy paragraph you're refering to. Hope this helps. Please also remember that my views are mine and might not neccessarily reflect the official pkg-gnome standpoint. Regards, Andreas Henriksson
Bug#983092: xapps-common:all is not properly arch-independent
Hello, On Fri, Feb 19, 2021 at 10:45:41AM +0100, Sven Mueller wrote: > Package: xapp > Version: 2.0.6-1 > Severity: serious > > xapps-common is tagged as architecture:all, but the generated > xapp-sn-watcher.desktop included in it depends on the architecture it was > built on. [...] > 1) Move the autostart file into the respective libxapp1 packages (with the > binary) [...] Seems like Fabio Fantoni went with this solution and while I agree that desktop files should be shipped in the same package as the binary they launch in general, I also think it's very wrong to ship non-SO-verioned files in a libfooN package! (You'll most likely cause a file conflict bug when you later move to libxapp2 in the future the entire reason we put the SO version in the package name is to make the different versions co-installable, but if you put non-versioned files in the package then you're breaking that) The executable and desktop file should really be in a different (possibly newly added) package! Given we're in freeze it might be too late to introduce a new binary package (if that's needed), but fixing one bug by doing something wrong doesn't feel like debian style either. Wouldn't it be better to just ask the release team which solution they prefer and possibly get an exception for introducing a new binary package if needed? Regards, Andreas Henriksson
Bug#982253: netkit telnetd: ship with bullseye with open security problems?
Control: severity -1 important Hi again, FYI I just uploaded netkit-telnet with two changes: - orphan package - include patch to fix crash on nessus scan On Mon, Feb 15, 2021 at 02:21:04AM +0100, Chris Hofstaedtler wrote: > I was hoping someone would jump in here and say "I'm using a telnet > server in 2021, and want to maintain it". But... not happening > apparently. Still hoping for Christoph Biedl to take it, but the package is now orphaned since he did not respond (yet) to my previous mail. > > Personally I would favor keeping netkit-telnet, but turning off > telnetd. As Salvatore said, this might have to wait for bookworm. IMO netcat is a better telnet client. We could possibly have a telnet package that just symlinks telnet to netcat for easier discoverability by users who hear telnet and are not familiar with netcat. (That could possibly also help my problem which is remembering which netcat implementation is the saner one.) If the telnet daemon is removed, I think you could just as well RM src:netkit-telnet entirely I'm personally also aware of people writing new telnet client/server code right now (even in 2021!). Their code is likely not less buggy, but what do I know. I'd rather see them use existing implementation and improve on those if needed, but my argumentation gets harder if those are removed from the archives. (I don't have a problem with people using telnet technology if used/contained on trusted premises or accessible only via some transport layer security like a VPN.) Right now we offer several implementations and to me they all seem equally bad and un(der)maintained from a quick glance, but maybe we should just find one implementation that we promote usage of and get rid of the others. I noticed that busybox also has a telnetd applet that is currently disabled. Maybe it would be something to investigate if that's a better option to enable as hopefully busybox is a good active upstream (but I don't know how they view or care about their own telnet implementation). > > Maybe upload the patch now (closing both bugs), and I'll see if I > remember to remove telnetd for bookworm? :-) I think reopening this discussion early in bookworm is much better. In general if we remove stuff early, we have a good chance to see if people miss it and alot of time to try to convince people to try other solutions and if that fails still have time to re-introduce things before freeze happens For now I'm lowering the severity below RC (maybe we should just close this bug report. Feel free to do so as far as I'm concerned atleast). And as said, if you go for removal please just remove the entire source. Regards, Andreas Henriksson
Bug#982757: firmware-brcm80211: [REGRESSION] brcm/brcmfmac43340-sdio.bin missing in sid (20210208-1)
On Tue, Feb 16, 2021 at 11:46:26PM +0100, maximilian attems wrote: > > Actually I think the problem is this commit: > > https://salsa.debian.org/kernel-team/firmware-nonfree/-/commit/9c597cb850e77c2bff39378503849a92ff522353 > > this commit is just fine, the debian package just needs to have the > corresponding symlinks to the newer version. FYI I've now tested reverting that commit and the symlinks are back: Here's the sid vs sid+revert binary package content (files) diff: --- fbr-sid-files.txt 2021-02-17 09:39:13.679336856 +0100 +++ fbr-sid-rev9c597cb850e7-files.txt 2021-02-17 10:00:12.730055901 +0100 @@ -63,4 +63,13 @@ ./usr/share/doc/firmware-brcm80211/copyright ./usr/share/metainfo/ ./usr/share/metainfo/firmware-brcm80211.metainfo.xml +./lib/firmware/brcm/brcmfmac43340-sdio.bin +./lib/firmware/brcm/brcmfmac43362-sdio.bin +./lib/firmware/brcm/brcmfmac4339-sdio.bin +./lib/firmware/brcm/brcmfmac43430-sdio.bin +./lib/firmware/brcm/brcmfmac43455-sdio.bin +./lib/firmware/brcm/brcmfmac4354-sdio.bin +./lib/firmware/brcm/brcmfmac4356-pcie.bin ./lib/firmware/brcm/brcmfmac4356-sdio.bin +./lib/firmware/brcm/brcmfmac43570-pcie.bin +./lib/firmware/brcm/brcmfmac4373-sdio.bin And yes, they are all symlinks... eg from the patched/rebuilt package: $ dpkg -c patched/firmware-brcm80211_20210208-1_all.deb | grep brcmfmac43340-sdio lrwxrwxrwx root/root 0 2021-02-17 09:58 ./lib/firmware/brcm/brcmfmac43340-sdio.bin -> ../cypress/cyfmac43340-sdio.bin Note also that this is definitely not a general problem with symlinks as even the existing package in sid has atleast one symlink in it still: $ dpkg -c sid/firmware-brcm80211_20210208-1_all.deb | grep -- '->' lrwxrwxrwx root/root 0 2021-02-09 11:15 ./lib/firmware/brcm/brcmfmac4356-sdio.bin -> ../cypress/cyfmac4356-sdio.bin The problem is simply that the symlinks are being installed into debian/build/install/ but then they are not moved over to the debian/firmware-brcm80211 directory to be included in the binary package. It might be helpful to improve the packaging logic so files are /moved/ from debian/build/install/ into the respective binary package directory and then fail the build if debian/build/install/ still contains anything (ie. similar to --fail-missing in generic dh packages). Regards, Andreas Henriksson
Bug#982757: firmware-brcm80211: [REGRESSION] brcm/brcmfmac43340-sdio.bin missing in sid (20210208-1)
On Tue, Feb 16, 2021 at 10:35:53PM +0100, Andreas Henriksson wrote: > Control: notfound -1 20201218-3 > Control: found -1 20210208-1 > > On Tue, Feb 16, 2021 at 08:20:47AM +0100, maximilian attems wrote: > [...] > > right it was replaced by newer cypress version and there should be > > a symlink of that guy from the older name: > > > > Link: brcm/brcmfmac43340-sdio.bin -> ../cypress/cyfmac43340-sdio.bin > > > > Could you please test latest 2021 upstream package with this symlink? > > It seems the bug report was filed against the (working) testing version > when (as said in subject) the problem is really in the 2021 unstable > version. Adjusted bug metadata accordingly. (I've confirmed by checking > the content of both versions myself.) > > It seems the reason that brcm/brcmfmac43340-sdio.bin symlink is missing > is this: > > The symlink first gets installed in debian/build/install ... then ... the rest on my analysis was completly wrong. Actually I think the problem is this commit: https://salsa.debian.org/kernel-team/firmware-nonfree/-/commit/9c597cb850e77c2bff39378503849a92ff522353 Regards, Andreas Henriksson
Bug#982757: firmware-brcm80211: [REGRESSION] brcm/brcmfmac43340-sdio.bin missing in sid (20210208-1)
Control: notfound -1 20201218-3 Control: found -1 20210208-1 On Tue, Feb 16, 2021 at 08:20:47AM +0100, maximilian attems wrote: [...] > right it was replaced by newer cypress version and there should be > a symlink of that guy from the older name: > > Link: brcm/brcmfmac43340-sdio.bin -> ../cypress/cyfmac43340-sdio.bin > > Could you please test latest 2021 upstream package with this symlink? It seems the bug report was filed against the (working) testing version when (as said in subject) the problem is really in the 2021 unstable version. Adjusted bug metadata accordingly. (I've confirmed by checking the content of both versions myself.) It seems the reason that brcm/brcmfmac43340-sdio.bin symlink is missing is this: The symlink first gets installed in debian/build/install ... then debian/rules.gen (generated by debian/bin/gencontrol.py) does *not* install it into debian/firmware-brcm80211 . The reason seems to be that the filename is not listed in debian/firmware-brcm80211.metainfo.xml (The cypress filename the symlink points to is however listed and that gets installed as expected.) HTH Regards, Andreas Henriksson
Bug#982705: openssh: FTBFS: sha2.h:57:16: error: redefinition of ‘struct _SHA2_CTX’
On Mon, Feb 15, 2021 at 09:41:30AM +, Colin Watson wrote: [...] > FWIW, I think your patch in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982705#25 is correct > (even if I prefer to take a different approach as a workaround for the > packaging) and could be forwarded upstream. Would you mind doing that? > I normally prefer people to forward their own patches where possible so > that there's no doubt about copyright/licensing intent or whatever. Agreed. The patch is fixing stuff in the non-portable version though and I couldn't figure out how to contribute to that. The only contribution info I could find lead to donating money to openbsd. I did however send a mail yesterday with the patch attached directly to https://github.com/djmdjm who's seems to have been the one touching the relevant code according to https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sk-usbhid.c (and seems also being active in https://github.com/openssh/openssh-portable ). YOLO and I'm moving on. Regards, Andreas Henriksson
Bug#982705: openssh: FTBFS: sha2.h:57:16: error: redefinition of ‘struct _SHA2_CTX’
Hello Colin Watson, On Sun, Feb 14, 2021 at 01:05:11PM +, Colin Watson wrote: > Thanks for digging into this. > > How about this approach instead? Given the choice between a > packaging-only change and one that requires another patch against > upstream, I have a slight preference for the packaging-only change as > long as it's basically reasonable, which I think this is. It just > overrides configure's automatic detection and tells it that sha2.h isn't > available. Builds cleanly and doesn't seem to incur any new direct > dependencies. Whatever works and feel free to choose the way you as maintainer prefers as far as I'm concerned! :) FWIW I make similar choices myself, but my definition of preferred solution is a bit more complicated. Nothing is ever as permanent as something temporary. It's not uncommon to see a temporary hack be forgotten about and then not be dropped when it's no longer needed, just to come back later and bite you in the ass. So while I agree with your rule in general, I go for patches when there's a big chance that the patch will stop apply when upstream fixes this. Then it's hard to miss that it should be dropped when the package is updated the next time However there's no guarantee that will happen with my patch, so it's really up to you to go with your gut feeling. And apart from that, my autotools knowledge simply isn't as good as yours to come up with your solution (even though I definitely have seen similar things used in the past now that you point it out). > > diff --git a/debian/rules b/debian/rules > index 73a53c309..44bac00f1 100755 > --- a/debian/rules > +++ b/debian/rules > @@ -65,6 +65,10 @@ ifeq ($(DEB_HOST_ARCH_OS),hurd) > confflags += --with-libs=-lcrypt > endif > > +# Avoid using libmd even if it's installed; see > +# https://bugs.debian.org/982705. > +confflags += ac_cv_header_sha2_h=false > + > # Everything above here is common to the deb and udeb builds. > confflags_udeb := $(confflags) > > > Thanks, > > -- > Colin Watson (he/him) [cjwat...@debian.org] Regards, Andreas Henriksson
Bug#982253: netkit telnetd: ship with bullseye with open security problems?
Hello, On Sun, Feb 07, 2021 at 09:06:28PM +0100, Salvatore Bonaccorso wrote: [...] > > 2) possibly unpatched exploit here: > > https://www.exploit-db.com/exploits/48170 > > JFTR, this one was CVE-2020-10188 and in Debian was fixed in earlier > times. > > Replacing telnetd package with an empy package and depending on > inetutils-telnetd: is it possible to basically interchangably replace > those two? If so this might be an option but I'm not sure if at this > stage of the preparations for bullseye it might be too late. It's not like inetutils is a shining example of perfectness either. #945861 inetutils: CVE-2019-0053 The inetutils also doesn't ship all tools and recommends using existing ones including netkit (eg. in #672295). It also seems to lack features compared to netkit alternatives (eg. SSL). ... "pest eller kolera" ... It seems like Christoph Biedl who did the last NMU has considered adopting the package. Hopefully if that happened the situation around netkit could improve. > > > 1) open bug #974428, causes telnetd to crash, remotely triggerable > > The first issue, if there a verified patch might be good to fix in > time for bullseye. I've pondered uploading the posted patch and since the last maintainer upload was in 2016 I'd orphan the package while doing so but I'll consider hijacking it on Christoph Biedl's behalf if he's interested in maintaining it still. Unless there's a conclusion about this bug report I don't really see much point in proceeding though. Regards, Andreas Henriksson
Bug#982705: openssh: FTBFS: sha2.h:57:16: error: redefinition of ‘struct _SHA2_CTX’
Control: tags -1 + patch Hi again, Attached is a possibly upstreamable patch that solves our problem (but the base problem still exists in the code for anyone wishing to build with openssl disabled). See description in patch itself. Regards, Andreas Henriksson Description: sk-usbhid.c: Only include sha2.h if building without openssl Author: Andreas Henriksson Bug-Debian: https://bugs.debian.org/982705 There are many sha2.h and including both the openbsd-compat/sha2.h and the (libmd) /usr/include/sha2.h causes build problems. Other files like hash.c etc only includes the sha2.h if building without openssl. It seems like the code in sk-usbhid.c also doesn't really need to include it since it prefers using openssl already, so just reorder the includes similar to hash.c and others to avoid hitting this problem. (The underlying problem likely still needs to be resolved for anyone who wishes to actually build without openssl though.) Forwarded: TODO Last-Update: 2021-02-14 --- openssh-8.4p1.orig/sk-usbhid.c +++ openssh-8.4p1/sk-usbhid.c @@ -26,9 +26,6 @@ #include #include #include -#ifdef HAVE_SHA2_H -#include -#endif #ifdef WITH_OPENSSL #include @@ -37,6 +34,10 @@ #include #include #include +#else +# ifdef HAVE_SHA2_H +# include +# endif #endif /* WITH_OPENSSL */ #include
Bug#982705: openssh: FTBFS: sha2.h:57:16: error: redefinition of ‘struct _SHA2_CTX’
Hi,
On Sun, Feb 14, 2021 at 09:18:25AM +0100, Andreas Henriksson wrote:
> On Sun, Feb 14, 2021 at 08:32:58AM +0100, Andreas Henriksson wrote:
> > Hello,
> >
> > On Sat, Feb 13, 2021 at 06:04:32PM +0100, Lucas Nussbaum wrote:
> > > Source: openssh
> > > Version: 1:8.4p1-3
> > > Severity: serious
> > > Justification: FTBFS on amd64
[...]
I'm attaching a patch (which can be droppen in debian/patches and
appended to series) that adds libmd checking to configure.ac and sets
the required defines to make the build pass.
It likely needs additional work, see FIXMEs. Consider this a PoC. Only
compile-tested (so might not actually work at runtime).
Someone who knows what the intended purpose of the existing code was and
has motivation to untangle the mess called autotools should work out a
real patch.
Also, the SHA*Update etc. implemented by openbsd-compat/sha2.* doesn't
seem to even be called anywhere, so maybe it can just be removed
instead?
If we want a debian-only patch it might be easier to just do:
AC_DEFINE([_SSHSHA2_H_], [1], [Disable openbsd-compat/sha2.h])
Someone should really discuss with whoever does the openbsd-compat stuff
how they see the situation and what they think is the best way to handle
this.
Regards,
Andreas Henriksson
Index: openssh-8.4p1/configure.ac
===
--- openssh-8.4p1.orig/configure.ac
+++ openssh-8.4p1/configure.ac
@@ -1973,6 +1973,20 @@ AC_CHECK_FUNCS([ \
warn \
])
+# FIXME: Possible redefinition of HAVE_SHA* if they where already found
+# in AC_CHECK_FUNCS above?
+# FIXME: This should add -lmd to LDFLAGS instead of relying on something
+# else to pull it in (or even better use pkg-config --{cflags,libs} libmd).
+AC_CHECK_LIB([md], [SHA256Update], [
+ AC_DEFINE([HAVE_SHA256UPDATE], [1], [libmd has SHA256Update])
+ ], [])
+AC_CHECK_LIB([md], [SHA384Update], [
+ AC_DEFINE([HAVE_SHA384UPDATE], [1], [libmd has SHA384Update])
+ ], [])
+AC_CHECK_LIB([md], [SHA512Update], [
+ AC_DEFINE([HAVE_SHA512UPDATE], [1], [libmd has SHA512Update])
+ ], [])
+
AC_CHECK_DECLS([bzero, memmem])
dnl Wide character support.
Bug#982705: openssh: FTBFS: sha2.h:57:16: error: redefinition of ‘struct _SHA2_CTX’
On Sun, Feb 14, 2021 at 08:32:58AM +0100, Andreas Henriksson wrote: > Hello, > > On Sat, Feb 13, 2021 at 06:04:32PM +0100, Lucas Nussbaum wrote: > > Source: openssh > > Version: 1:8.4p1-3 > > Severity: serious > > Justification: FTBFS on amd64 [...] > (Which in turn makes me wonder if something changed on the libmd side?) So looked around a bit more here Apparently this is the reason libmd-dev is installed: openssh b-d libedit-dev libedit-dev dep libbsd-dev libbsd-dev dep libmd-dev Both libmd-dev and libbsd-dev seems to have had recent changes. >From libbsd (0.11.1-1) changelog: ``` - Switch from embedded hashing function implementations to use libmd. Add libmd-dev to Build-Depends and libbsd-dev Depends. ``` I have not yet looked up what the configure results where for the last successful openssh build, but I suspect that the situation back then was that SHA256Update et.al. where not found and the openssh compat sha2.h was used, but this was not a problem because libmd-dev (which provides /usr/lib/sha2.h) was not pulled in back then either... Simply introducing an opennsh `Build-Conflicts: libmd-dev` will not work now that we have a dependency chain which will pull it in via libedit-dev. I suspect the way out of this is to simply improve the openssh configure now... Regards, Andreas Henriksson
Bug#982705: openssh: FTBFS: sha2.h:57:16: error: redefinition of ‘struct _SHA2_CTX’
Hello,
On Sat, Feb 13, 2021 at 06:04:32PM +0100, Lucas Nussbaum wrote:
> Source: openssh
> Version: 1:8.4p1-3
> Severity: serious
> Justification: FTBFS on amd64
[...]
> > In file included from ../../sk-usbhid.c:30:
> > /usr/include/sha2.h:57:16: error: redefinition of ‘struct _SHA2_CTX’
[...]
> > ../../openbsd-compat/sha2.h:66:16: note: originally defined here
[...]
This problem seems to be caused by configure not finding the
SHA{256,384,512}Update functions and thus not defining HAVE_*
for them to make openbsd-compat/sha2.h ifndef's bail out.
The build log says:
```
checking for SHA256Update... no
checking for SHA384Update... no
checking for SHA512Update... no
```
More info on why is in config.log :
```
configure:11580: checking for SHA256Update
configure:11580: cc -o conftest -g -O2 -ffile-prefix-map=/tmp/openssh-8.4p1=.
-fstack-protector-strong -Wformat -Werror=format-security -pipe
-Wno-error=format-truncation -Wall -Wextra -Wpointer-arith -Wuninitialized
-Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign
-Wno-unused-parameter -Wno-unused-result -Wimplicit-fallthrough
-fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset
-fstack-protector-strong -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-ffile-prefix-map=/tmp/openssh-8.4p1=. -fstack-protector-strong -Wformat
-Werror=format-security -DSSH_EXTRAVERSION=\"Debian-3\" -Wdate-time
-D_FORTIFY_SOURCE=2 -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE
-I/usr/include/editline -Wl,-z,relro -Wl,-z,now -Wl,-z,relro -Wl,-z,now
-Wl,-z,noexecstack -fstack-protector-strong -Wl,--as-needed -Wl,-z,relro
-Wl,-z,now conftest.c -lutil -lz >&5
: warning: missing terminating " character
/usr/bin/ld: /tmp/cc7rTcJW.o: in function `main':
./debian/build-deb/conftest.c:153: undefined reference to `SHA256Update'
collect2: error: ld returned 1 exit status
```
Seems like some linker flag (-lmd) is missing to make the test program
succeed. OpenSSH uses AC_CHECK_FUNCS to check for SHA256Update, etc.
This macro doesn't have any way to pass in -lmd as far as I can tell
(Which in turn makes me wonder if something changed on the libmd side?)
Regards,
Andreas Henriksson
Bug#982275: debianutils: add-shell depends on non-essential package
Hello Michael Gilbert, Sorry for butting in here, but I have some questions and would be happy if you could enlighten me. On Sun, Feb 07, 2021 at 09:51:28PM -0500, Michael Gilbert wrote: > package: src:debianutils > severity: serious > version: 4.11.2 > tag: patch > > debianutil's add-shell script uses awk, but awk is not an > Essential:yes package. True (because awk is not a package but a /virtual/ package), but awk is a "pseudo-essential" package since base-files (which is Essential: yes) Pre-Depends on awk. So you can't really not have (any implementation of) awk even if you only have essential packages available. > For systems where awk is not yet installed (chroots), installation of > dash will currently fail since it's postinst calls add-shell from > debianutils. Please share details about how to reproduce this situation! You say you don't have awk when dash postinst runs, but that would also mean you don't have base-files (since it pre-depends on awk), which means you're lacking essential packages while you're configuring dash! Sounds to me like you're doing something very peculiar and likely completely unsupported to be able to trigger this issue. Atleast I can't think of any obvious way how to trigger it. FWIW Essential packages have the special requirement that they have to provide their functionality before being configured (only unpacked), and no packages /configuration/ should start before all packages finished being unpacked. However you're claiming awk's not even been unpacked before you move on to configure some packages (dash in this case). For anyone interested in the subject this might also be useful to look at for the different possible states during a package installation: https://www.debian.org/doc/debian-policy/ap-flowcharts.html > > A simple fix seems possible, just change add-shell to use cat, which > is in coreutils (Essential:yes). Proposed update attached. Replacing using awk with cat whenever possible sounds like a good thing to do, so for the record I'm not against that. My skepticism is more at why this is not a wishlist bug report (that would be much better to adress early in a development cycle, rather than when we're already in the bullseye freeze). Regards, Andreas Henriksson PS. The reason for the weird awk Pre-Depends is to avoid making a particular implementation of awk Essential: yes, to avoid making it unneccesarily hard to switch to a different awk implementation. (eg. mawk -> gawk). Also AFAIK it's not possible to make a virtual package Essential: yes (because I've never seen that, but someone might say it's possible)...
Bug#976518: marked as pending in gsound
Control: tag -1 pending Hello, Bug #976518 in gsound reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/gnome-team/gsound/-/commit/8bc79f25bd01f5a3ac035d40bef40ac73b926f34 Add patch to fix autoreconf problem Closes: #976518 (this message was generated automatically) -- Greetings https://bugs.debian.org/976518
Bug#975228: xdg-utils: FTBFS: tests failed
Control: tags -1 + patch upstream
Hello,
On Thu, Nov 19, 2020 at 10:56:51AM +0100, Lucas Nussbaum wrote:
> Source: xdg-utils
> Version: 1.1.3-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201119 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > make[3]: Entering directory '/<>/autotests'
[...]
> > * Testing that xdg-open
> > - opens a URL with gio open in recent GNOME 3, and Cinnamon
> > ASSERTION FAILED: expected command to be run: gio open
> > http://www.freedesktop.org/
> > ASSERTION FAILED: expected command to be run: gio open
> > http://www.freedesktop.org/
[...]
The problem is using the command "gio open" (containing space) and
a/ not properly handling its expansion b/ mocking it as an executable
including the space.
The attached patch fixes the problem, but I have no idea why this
problem appeared now
Regards,
Andreas Henriksson
diff -uriNp xdg-utils-1.1.3.orig/autotests/t-xdg-open.sh xdg-utils-1.1.3/autotests/t-xdg-open.sh
--- xdg-utils-1.1.3.orig/autotests/t-xdg-open.sh 2021-01-04 21:59:11.0 +
+++ xdg-utils-1.1.3/autotests/t-xdg-open.sh 2021-01-04 22:00:09.919276956 +
@@ -7,7 +7,7 @@ test_open_url() {
shift
local cmd=$1
-mock $cmd
+mock "$cmd"
run $de xdg-open http://www.freedesktop.org/
assert_run "$@" http://www.freedesktop.org/
unmock $cmd
diff -uriNp xdg-utils-1.1.3.orig/autotests/test-lib.sh xdg-utils-1.1.3/autotests/test-lib.sh
--- xdg-utils-1.1.3.orig/autotests/test-lib.sh 2018-05-10 15:02:31.0 +
+++ xdg-utils-1.1.3/autotests/test-lib.sh 2021-01-04 21:59:52.927289723 +
@@ -95,7 +95,7 @@ set_de_() {
}
mock() {
-local command="$1" script="$2"
+local command="$(echo $1 | cut -d' ' -f1)" script="$2"
local executable="$BINDIR/$command"
cat >"$executable" <
Bug#976050: mailutils: FTBFS on amd64 with current unstable
Control: tags -1 - unreproducible moreinfo Control: retitle -1 mailutils: FTBFS with emacs installed in build environment Hello again, On Sat, Jan 02, 2021 at 03:12:07PM -0600, Rob Browning wrote: [...] > dh_missing > dh_missing: warning: usr/share/emacs/site-lisp/mailutils-mh.el exists in > debian/tmp but is not installed to anywhere (related file: > "debian/tmp/usr/share/mailutils/mh/mailutils-mh.el") > dh_missing: warning: usr/share/emacs/site-lisp/mailutils-mh.elc exists in > debian/tmp but is not installed to anywhere [...] > dh_missing: error: missing files, aborting > make: *** [debian/rules:4: binary] Error 255 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit > status 2 [...] Thanks for this info, it made it much easier to know where to look for the problem which is caused by having emacs installed in the build environment (which it isn't in a clean buildd chroot). The AM_PATH_LISPDIR macro will check for emacs xemacs and set the EMACS variable (which defaults to 'no' if not found). This in turn will cause the mailutils-mh.el to (also) be installed in the `lispdir` (in addition to the `mhlibdir`). I see these potential theoretical solutions: 1. Declare Build-Conflicts against any package that has emacs or xemacs. (... which seems like a really bad idea to me.) 2. just `rm -rf debian/tmp/usr/share/emacs` before dh_missing is ran. 3. Build-depend on (some variant of) emacs and install the emacs/site-lisp files. 4. Try to convince configure to enable emacs/lispdir without having emacs necessarily installed (possibly by passing --with-lispdir) and install the emacs/site-lisp files. (Probably a better idea than 3 if possible.) I'm don't know emacs stuff well enough to know if and why installing the same file in both paths would be a useful thing to do, maybe someone else can help shine some light on that? Doing 2/ is easy, fixes the problem, and gets the same content in the built package as the currently existing package in the archive, however it might be useful to understand what purpose having it in the emacs/site-lisp path serves and if that's actually preferred over just maintaining the status quo. Regards, Andreas Henriksson
Bug#978172: evolution-data-server: FTBFS: CheckFunctionExists.c:17: undefined reference to `res_query'
Hello, Seems like intentional(?) changes in libphonennumber caused this. Adding recipient Matthias Klose, who uploaded the latest libphonenumber version, to hopefully get a comment on if this is something than should get fixed in libphonenumber or in e-d-s. Please note that the libphonenumber Vcs-Git repo seems outdated so it's not possible to track down exact commit which changed debian/control and get more details! On Sat, Dec 26, 2020 at 10:12:40PM +0100, Lucas Nussbaum wrote: > Source: evolution-data-server > Version: 3.38.2-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201226 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > /usr/bin/ld: CMakeFiles/cmTC_9ba60.dir/CheckFunctionExists.c.o: in function > > `main': > > /usr/share/cmake-3.18/Modules/CheckFunctionExists.c:17: undefined reference > > to `res_query' > > collect2: error: ld returned 1 exit status Nope, this is a wild goose > > The full build log is available from: > > http://qa-logs.debian.net/2020/12/26/evolution-data-server_3.38.2-2_unstable.log [...] Hopefully actually relevant part (because I have to say finding the actual error from CMake builds is horrible!): ``` gmake[3]: Entering directory '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' Building CXX object CMakeFiles/cmTC_24d88.dir/src.cxx.o /usr/bin/c++ -DI18N_PHONENUMBERS_USE_BOOST -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Dphone_number_with_boost_thread-mt -fPIE -o CMakeFiles/cmTC_24d88.dir/src.cxx.o -c /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.cxx : warning: ISO C++11 requires whitespace after the macro name In file included from /usr/include/phonenumbers/phonenumberutil.h:32, from /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:1: /usr/include/phonenumbers/base/memory/scoped_ptr.h:10:10: fatal error: boost/scoped_ptr.hpp: No such file or directory 10 | #include | ^~ compilation terminated. gmake[3]: *** [CMakeFiles/cmTC_24d88.dir/build.make:85: CMakeFiles/cmTC_24d88.dir/src.cxx.o] Error 1 gmake[3]: Leaving directory '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' gmake[2]: *** [Makefile:140: cmTC_24d88/fast] Error 2 ``` So this looks like a bug in libphonenumber to me Interestingly this is part of libphonenumber 7.1.0-7 changelog: * Don't build using boost, not required on recent Linux versions. ... and in /usr/include/phonenumbers/base/memory/scoped_ptr.h we can see that the boost header is conditionally included based on `#if defined(I18N_PHONENUMBERS_USE_BOOST)`. That define in turn is apparently set by evolution-data-server: ./cmake/modules/FindPhonenumber.cmake:set(PHONENUMBER_DEFINITIONS -DI18N_PHONENUMBERS_USE_BOOST CACHE STRING "libphonenumber compile definitions, default is -DI18N_PHONENUMBERS_USE_BOOST") Does that mean evolution-data-server is supposed to open-code the dependencies needed by libphonenumber on boost ? I think it would be better if the libphonenumber-dev pulled in everything needed in every supported configuration (or alternatively provided 2 separate -dev packages, eg. libphonenumber-boost-dev which deps on libphonennumber-dev plus required boost parts but that seems too complex for little gain - not to mention needing to go through NEW). Regards, Andreas Henriksson
Bug#976050: mailutils: FTBFS on amd64 with current unstable
Control: tags -1 + unreproducible moreinfo Hello, I'm unable to reproduce your build problems. I've built mailutils in a loop for a while now and every build succeeds for me. On Sat, Nov 28, 2020 at 03:11:11PM -0600, Rob Browning wrote: > > Package: mailutils > Version: 1:3.10-3 > Severity: serious > > After an "apt-get source mailutils/sid" with current unstable, > "debian/rules binary" fails here like this: > > Creating popauth.1... > /home/vagrant/mailutils/mailutils-3.10/debian/tmp/usr/bin/popauth: error > while loading shared libraries: libmu_dbm.so.7: cannot open shared object > file: No such file or directory [...] Could you please try using `dpkg-buildpackage -uc -us`, rather than directly invoking debian/rules, and see if it helps you detect any misconfigurations in your build environment? Could you please provide a full build log? Can you think of anything that might be relevant why the build would fail for you but not me? Regards, Andreas Henriksson
Bug#978176: gimp: FTBFS: dh_install: error: missing files, aborting
Control: reassign -1 libheif-dev 1.10.0-1 Control: retitle -1 libheif-dev missing dependencies on pkg-config Requires.private listed components Control: affects -1 gimp Hello, It seems like the recently uploaded libheif 1.10 is broken causing problems for gimp (and all other reverse dependencies using libheif.pc ?!). Thus reassigning, more details below. On Sat, Dec 26, 2020 at 10:13:50PM +0100, Lucas Nussbaum wrote: > Source: gimp > Version: 2.10.22-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201226 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' [...] > > dh_install: warning: Cannot find (any matches for) > > "usr/lib/gimp/2.0/plug-ins/file-heif" (tried in ., debian/tmp) > > > > dh_install: warning: gimp missing files: usr/lib/gimp/2.0/plug-ins/file-heif > > dh_install: error: missing files, aborting > > make[1]: *** [debian/rules:44: override_dh_install] Error 25 > > The full build log is available from: >http://qa-logs.debian.net/2020/12/26/gimp_2.10.22-2_unstable.log [...] In the full build log it can be seen that no version of libheif is detected by configure despite the libheif-dev being installed as part of build-dependencies. This can be seen in config.log: ``` configure:29056: checking for libheif > 1.5.1 configure:29063: $PKG_CONFIG --exists --print-errors "libheif > 1.5.1" Package aom was not found in the pkg-config search path. Perhaps you should add the directory containing `aom.pc' to the PKG_CONFIG_PATH environment variable Package 'aom', required by 'libheif', not found configure:29066: $? = 1 configure:29080: $PKG_CONFIG --exists --print-errors "libheif > 1.5.1" Package aom was not found in the pkg-config search path. Perhaps you should add the directory containing `aom.pc' to the PKG_CONFIG_PATH environment variable Package 'aom', required by 'libheif', not found configure:29083: $? = 1 configure:29097: result: no Package 'aom', required by 'libheif', not found configure:29116: checking for libheif = 1.4.0 configure:29123: $PKG_CONFIG --exists --print-errors "libheif = 1.4.0" Package aom was not found in the pkg-config search path. Perhaps you should add the directory containing `aom.pc' to the PKG_CONFIG_PATH environment variable Package 'aom', required by 'libheif', not found configure:29126: $? = 1 configure:29140: $PKG_CONFIG --exists --print-errors "libheif = 1.4.0" ``` New in libheif 1.10 (currently in unstable) is that the libheif.pc pkg-config file has: ``` > grep Requires usr/lib/*/pkgconfig/libheif.pc Requires: Requires.private: aom libde265 x265 ``` This was not the case in libheif 1.9 (currently in testing). The pkg-config file is thus broken when installing libheif-dev in a clean system where the pkg-config files of aom, etc are not installed. As far as I can tell the fix is: a/ Add libaom-dev, libde265-dev and libx265-dev to Depends of libheif-dev b/ preferably also write a simple autopkgtest that checks if libheif.pc works as expected eg. `pkg-config --exists --print-errors "libheif > 1.5.1"` should not error out when libheif-dev is installed. Regards, Andreas Henriksson
Bug#957912: marked as pending in vinagre
Control: tag -1 pending Hello, Bug #957912 in vinagre reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/gnome-team/vinagre/-/commit/62a378f51dc54aa25d8484214bf85e5984b6755a Add upstream !8 as d/p/gcc-10.patch Closes: #957912 (this message was generated automatically) -- Greetings https://bugs.debian.org/957912
Bug#978357: marked as pending in gnome-todo
Control: tag -1 pending Hello, Bug #978357 in gnome-todo reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/gnome-team/gnome-todo/-/commit/e56c1f7ad205341e8b6f23dbe80640bf667f6716 Explicitly build-dep on librest-dev rest-0.7 is referenced in meson.build but apparently was not mentioned in build-dependencies as it should (but probably worked before because some other build-dep would pull it in, and now stopped doing so). Since we directly reference it we should have a direct build-depedency as well Closes: #978357 (this message was generated automatically) -- Greetings https://bugs.debian.org/978357
Bug#976926: golang-github-coreos-bbolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short go.etcd.io/bbolt returned exit
Hello! On Wed, Dec 09, 2020 at 10:03:39AM +0100, Lucas Nussbaum wrote: > Source: golang-github-coreos-bbolt > Version: 1.3.5-1 > Severity: serious > Justification: FTBFS on ppc64el > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on ppc64el. At the same time, it did not fail on amd64. [...] > > === RUN TestBucket_Stats > > bucket_test.go:1222: unexpected BranchPageN: 0 > > --- FAIL: TestBucket_Stats (9.56s) [...] Apparently bbolt is a fork of boltdb, so please see my comments on the equivalent bug report againt boltdb: https://bugs.debian.org/976907 Relevant part: It seems the test-suite makes assumptions related to calculations that involve os.Getpagesize() (which gives 4096 on amd64 and 65536 on ppc64el, which is 16 times larger). Changing the 500 number to 8000 (16 times larger) in TestBucket_Stats(...) (in bucket_test.go:1143) gives the expected BranchPageN == 1 (however after that it then says "unexpected LeafPageN: 6" with this modification). In my opinion it's pretty clear that these are test-suite only issues and not issues in the actual product. I would thus personally just disable the test-suite on !amd64 if no porter is interested in fixing the testsuite (unless we agree this issue simply can be downgraded to non-RC). Regards, Andreas Henriksson
Bug#976907: golang-github-boltdb-bolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short github.com/boltdb/bolt github.co
Hello again, So after wasting my time here I finally realized that apparently boltdb is archived upstream. It will not receive any fixes. Apparently golang-github-coreos-bbolt is a maintained feature-extended fork. We should likely encurage moving to that and get boltdb removed from debian. The timeout waiting for db.mmaplock that occurred in boltdb is apparently already fixed in bbolt, see: https://github.com/etcd-io/bbolt/commit/e06ec0a754bc30c2e17ad871962e71635bf94d45 The pagesize issue seems to plague them both still though. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976926 for the bug report against bbolt. Regards, Andreas Henriksson
Bug#976907: golang-github-boltdb-bolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short github.com/boltdb/bolt github.co
Hello again, On Sat, Dec 12, 2020 at 05:59:37PM +0100, Andreas Henriksson wrote: > Hello all, > > 1 down, 1 to go info below. > > On Wed, Dec 09, 2020 at 10:03:31AM +0100, Lucas Nussbaum wrote: > [...] > > > === RUN TestBucket_Stats > > > bucket_test.go:1172: unexpected BranchPageN: 0 > > > --- FAIL: TestBucket_Stats (6.41s) [...] Now also quickly looked into this one. It seems the test-suite makes assumptions related to calculations that involve os.Getpagesize() (which gives 4096 on amd64 and 65536 on ppc64el, which is 16 times larger). Changing the 500 number to 8000 (16 times larger) in TestBucket_Stats(...) (in bucket_test.go:1143) gives the expected BranchPageN == 1 (however after that it then says "unexpected LeafPageN: 6" with this modification). Anyway, this makes me loose interest in pursuing this further. In my opinion it's pretty clear that these are test-suite only issues and not issues in the actual product. Unless someone else wants to pursue fixing up the test-suite for ppc64le needs, my offer to "fix" this will be to simply disable it on !amd64 architectures (unless we agree on simply downgrading this issue to non-RC). Regards, Andreas Henriksson
Bug#976907: golang-github-boltdb-bolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short github.com/boltdb/bolt github.co
Hello all, 1 down, 1 to go info below. On Wed, Dec 09, 2020 at 10:03:31AM +0100, Lucas Nussbaum wrote: > Source: golang-github-boltdb-bolt > Version: 1.3.1-7 > Severity: serious > Justification: FTBFS on ppc64el > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on ppc64el. At the same time, it did not fail on amd64. [...] > > === RUN TestBucket_Stats > > bucket_test.go:1172: unexpected BranchPageN: 0 > > --- FAIL: TestBucket_Stats (6.41s) ^--- I've not looked into this one yet. [...] > > === RUN TestTx_Commit_ErrTxNotWritable > > panic: test timed out after 10m0s [...] ^-- this one is solved by adding `tx.Rollback()` last in TestTx_Commit_ErrTxNotWritable function (in tx_test.go:65). In other words, this is a test-suite bug (not a bug in the actual product code). The reasoning goes that tx.Commit() is expected to return error bolt.ErrTxNotWritable, which it does -- but this means it's holding a reader lock on db.mmaplock. After the test function finishes the deferred function db.MustClose() runs and calls into things that tries to take a read-write lock of db.mmaplock which times out. The added tx.Rollback() on a read-only tx basically only removes the transaction and releases the db.mmaplock. I have no idea why this would not also trigger on any other arch. Regards, Andreas Henriksson
Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/
On Sat, Dec 12, 2020 at 10:32:15AM +0100, Lucas Nussbaum wrote: > Hi Andreas, > > Is the above problem going to be a problem at runtime as well? It depends on which part of /proc you use and how it deviates on your architecture, but yes... eventually you'll hit something that errors out in parsing or worse returns an answer that's just wildly wrong/unexpected. > If so, I wonder if you should make this package "Architecture: amd64" > instead of "Architecture: all". [...] In theory, the right question is probably what anyone is willing to support. Debian usually takes the naive approach of assuming porters will fix up any issues once they're found, but that's not really how things turn out in practise. (Also if we limit the archs, what is the correct subset? The ones where the testsuite succeeds? The ones where it actually works? The ones which someone is actually promising to support?) The practical problem is that if the arch field is changed what happens to the entire reverse dependency tree that has accumulated? Getting one thing removed from the archive is hard and painful enough Regards, Andreas Henriksson
Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/
Hello Lucas Nussbaum,
On Sat, Dec 05, 2020 at 02:23:54PM +0100, Lucas Nussbaum wrote:
> Source: golang-github-shirou-gopsutil
> Version: 2.19.11-3
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on arm64 (I don't know if it also fails on amd64).
[...]
> > === RUN TestCpuInfo
> > cpu_test.go:90: could not get CPU Info:
> > {"cpu":0,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"0","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > cpu_test.go:90: could not get CPU Info:
> > {"cpu":1,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"1","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > cpu_test.go:90: could not get CPU Info:
> > {"cpu":2,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"2","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > cpu_test.go:90: could not get CPU Info:
> > {"cpu":3,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"3","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > --- FAIL: TestCpuInfo (0.00s)
[...]
> > FAIL
> > FAILgithub.com/shirou/gopsutil/cpu 0.047s
[...]
> > FAIL
> > dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4
> > github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu
> > github.com/shirou/gopsutil/disk github.com/shirou/gopsutil/docker
> > github.com/shirou/gopsutil/host github.com/shirou/gopsutil/internal/common
> > github.com/shirou/gopsutil/load github.com/shirou/gopsutil/mem
> > github.com/shirou/gopsutil/net github.com/shirou/gopsutil/process returned
> > exit code 1
>
> The full build log is available from:
>
> http://qa-logs.debian.net/2020/12/05/golang-github-shirou-gopsutil_2.19.11-3_unstable.log
[...]
With the above log I will, without ever looking deeper at the problem,
claim that gopsutil parsing of /proc/cpuinfo does not work on your
architecture of choice.
I've briefly dug into this package in the past[1] and unless my memory
serves me wrong my conclusion was that gopsutil's assumptions about
/proc is not intended to be portable between architectures at all.
On the other hand /proc looking wildly different between architectures
on linux is kind of a problem that each architecture that is not the
most popular one is setting themselves up for problems with. Not even
using the same syntax in /proc/cpuinfo (or even using same keywords
as used on mainstream archs, but give them a different meaning!).
I would personally expect that porters steps up if they want a
particular piece of software ported to their arch, but I doubt that will
happen. I also very much doubt anyone else will port to a wide range of
architectures, or even a single one - plus maintain it.
I can thus suggest one "solution":
Disable the testsuite on !amd64 and just let it build without actually
ever having a chance of working except possibly by chance.
(We all did this for so many years while kfreebsd was still a testing
migration blocker, so it's not like my suggestion is a new idea.)
HTH.
Regards,
Andreas Henriksson
[1]: https://github.com/shirou/gopsutil/pull/269
Bug#969965: [Pkg-kbd-devel] Bug#969965: text installer: unable to switch keyboard layouts - libkeymap.so.1 missing
Hello Holger, On Tue, Oct 06, 2020 at 11:25:06PM +, Holger Wansing wrote: > Hi, > > Am Dienstag, 6. Oktober 2020 schrieb Andreas Henriksson: > > Could you please test rebuilding kbd with --enable-libkeymap to > > --disable-libkeymap in debian/rules? > > sbuild fails when I try it like that. > A build log is attached. > Debugging this is somewhat out of my skills, sorry. I've uploaded a new version that implements the above suggestion and would very much appreciate if you could test and give feedback on where we ended up when you have chance to do so. Regards, Andreas Henriksson
Bug#969965: [Pkg-kbd-devel] Bug#969965: text installer: unable to switch keyboard layouts - libkeymap.so.1 missing
Hello Holger Wansing, On Tue, Oct 06, 2020 at 04:49:14PM +0200, Holger Wansing wrote: > Control: reopen -1 > > Switching keyboard in the text installer still fails! [...] Thanks for testing and giving useful feedback on the kbd udebs. > loadkeys: error while loading shared libraries: libkeymap.so.1: cannot open > shared object file. No such file or directory > > Thus keymap is not set. Please fix loadkeys in udeb. [...] (... and once libkeymap.so.1 is available, libkbdfile.so.1 will be needed next I presume.) Could you please test rebuilding kbd with --enable-libkeymap to --disable-libkeymap in debian/rules? That should as I understand it make sure everything is linked statically and the shared libraries are not shipped at all (which if we want to should really happen in a separare properly named binary package anyway). (Another future TODO would also be to refactor debian/rules to do two separate flavoured builds with complete configure/build/install passes for each flavour, to replace the current brittle hack that duplicates the upstream build system as manual steps in debian/rules udeb build. Help welcome here as well ofcourse.) Regards, Andreas Henriksson
Bug#967139: marked as pending in gimp-help
Control: tag -1 pending Hello, Bug #967139 in gimp-help reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/gnome-team/gimp-help/-/commit/2cbd892e4913e5cbaaf079326ac4ce810d0d798a Switch python build-deps to python3 equivalent See patch added in previous commit changing the xml2po code to python3. Closes: #951823, #967139 (this message was generated automatically) -- Greetings https://bugs.debian.org/967139
