Bug#1034595: unblock: phog/0.1.3-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: p...@packages.debian.org, Arnaud Ferraris
Control: affects -1 + src:phog
Please unblock package phog
[ Reason ]
phog in testing ships PAM files for greetd that where transitioned to
the greetd package in 0.9.0-3 and are already unblocked in #1033966.
This cleans up the phog part of it.
In addition this fixes the dependencies of phog.
[ Impact ]
same as #1033966:
PAM configuration conflicts with greetd's embedded version (in new
version).
Also phog fails to start in a minimal installation due to the missing
dependencies.
[ Tests ]
I manually tested the upgrade (as did the greetd and phog maintainers,
according to #1033966) and uninstalling.
I also tested the missing runtime dependencies.
[ Risks ]
None.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
I'm filling this on behalf of the DebianOnMobile team as I was not able
to reach Arnaud, assuming that he is fine with this and to finish #1033966.
I will also ping #1032914 to gain some time.
unblock phog/0.1.3-2
diff -Nru phog-0.1.3/debian/changelog phog-0.1.3/debian/changelog
--- phog-0.1.3/debian/changelog 2023-02-02 19:50:11.0 +0100
+++ phog-0.1.3/debian/changelog 2023-03-15 13:59:03.0 +0100
@@ -1,3 +1,19 @@
+phog (0.1.3-2) unstable; urgency=medium
+
+ [ Guido Günther ]
+ * d/control: Allow for phosh-osk-stub.
+This allows to use phosh-osk-stub instead of squeekboard
+
+ [ Arnaud Ferraris ]
+ * debian: remove PAM conffiles on upgrade
+`greetd` now ships those, so we should get rid of them. Add a versioned
+dependency on `greetd` to ensure we have the proper configs.
+(Closes: #1032914)
+ * d/control: add missing runtime dependencies.
+(Closes: #1033282)
+
+ -- Arnaud Ferraris Wed, 15 Mar 2023 13:59:03 +0100
+
phog (0.1.3-1) unstable; urgency=medium
* New upstream version 0.1.3
diff -Nru phog-0.1.3/debian/control phog-0.1.3/debian/control
--- phog-0.1.3/debian/control 2023-02-02 19:50:11.0 +0100
+++ phog-0.1.3/debian/control 2023-03-15 13:59:03.0 +0100
@@ -36,9 +36,11 @@
${misc:Depends},
${shlibs:Depends},
fonts-lato,
- greetd,
+ gnome-shell-common,
+ greetd (>= 0.9.0-3),
phoc (>= 0.21.0+ds1),
- squeekboard,
+ polkitd,
+ squeekboard | phosh-osk-stub,
Description: Greetd-compatible greeter for mobile phones
Phog is a graphical greeter speaking the `greetd` protocol and aimed at mobile
devices like smart phones and tablets using touch based inputs and small
diff -Nru phog-0.1.3/debian/phog.conffiles phog-0.1.3/debian/phog.conffiles
--- phog-0.1.3/debian/phog.conffiles1970-01-01 01:00:00.0 +0100
+++ phog-0.1.3/debian/phog.conffiles2023-03-15 13:59:03.0 +0100
@@ -0,0 +1,2 @@
+remove-on-upgrade /etc/pam.d/greetd
+remove-on-upgrade /etc/pam.d/greetd-greeter
diff -Nru phog-0.1.3/debian/phog.greetd-greeter.pam
phog-0.1.3/debian/phog.greetd-greeter.pam
--- phog-0.1.3/debian/phog.greetd-greeter.pam 2023-02-02 19:50:11.0
+0100
+++ phog-0.1.3/debian/phog.greetd-greeter.pam 1970-01-01 01:00:00.0
+0100
@@ -1,2 +0,0 @@
-#%PAM-1.0
-@include login
diff -Nru phog-0.1.3/debian/phog.greetd.pam phog-0.1.3/debian/phog.greetd.pam
--- phog-0.1.3/debian/phog.greetd.pam 2023-02-02 19:50:11.0 +0100
+++ phog-0.1.3/debian/phog.greetd.pam 1970-01-01 01:00:00.0 +0100
@@ -1,5 +0,0 @@
-#%PAM-1.0
-@include login
-
-authoptionalpam_gnome_keyring.so
-session optionalpam_gnome_keyring.so auto_start
diff -Nru phog-0.1.3/debian/rules phog-0.1.3/debian/rules
--- phog-0.1.3/debian/rules 2023-02-02 19:50:11.0 +0100
+++ phog-0.1.3/debian/rules 2023-03-15 13:59:03.0 +0100
@@ -15,7 +15,3 @@
# dh_auto_install will put files in debian/, while dh_install
# will look in debian/tmp. Make sure both use the same directory.
dh_auto_install --destdir=$(PHOG_DESTDIR)
-
-override_dh_installpam:
- dh_installpam --name=greetd
- dh_installpam --name=greetd-greeter
Bug#1032914: phog: ships /etc/pam.d/greetd
Hi, I've filled #1034595 to get phog unblocked as well. (also this hopefully delays the autoremoval of phog). Cheers Jochen * Marc Dequènes [2023-04-07 19:45]: Quack Arnaud, greetd was unblocked today. Thanks for your help :-). \_o< -- Marc Dequènes signature.asc Description: PGP signature
Bug#1034691: nmu: why3_1.5.1-1+b1 frama-c_20220511-manganese-3-10
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: w...@packages.debian.org Control: affects -1 + src:why3 src:frama-c Hi release team, can you please binNMU why3 to pick up the new ABI: nmu why3_1.5.1-1+b1 . ANY . unstable . -m "Rebuild with new OCaml ABI" And afterwards frama-c needs a rebuild against the new why3: nmu frama-c_20220511-manganese-3-10 . ANY . unstable . -m "Rebuild with new OCaml ABI (Closes: #1033701)" Thanks! Jochen
Bug#1034629: pdf-presenter-console: pdfpc terminates with symbol lookup error
* Robert Jäschke [2023-04-22 13:56]: libvmaf.so.1 => /lib/x86_64-linux-gnu/libvmaf.so.1 (0x7fa6dc39a000) I don't have this in my ldd output and I don't find the file in Debian. Can you try moving it away and see if it helps? Cheers Jochen signature.asc Description: PGP signature
Bug#1034629: pdf-presenter-console: pdfpc terminates with symbol lookup error
Hi Robert, I was not able to reproduce this in an up to date testing VM. Steps I tried: $ debvm-create --size=10G -r testing -- --include=task-gnome-desktop --aptopt='Apt::Install-Recommends "true"' --include=linux-image-amd64 --hook-dir=/usr/share/mmdebstrap/hooks/useradd $ debvm-run -g -- -m 4G in the running VM: $ sudo apt install pdf-presenter-console $ wget https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial $ pdfpc packaging-tutorial Can you check that your system is fine by running: $ sudo dpkg --verify Also send the output of $ ldd /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 In case there is an old library somewhere in the path. Cheers Jochen * Robert Jäschke [2023-04-20 09:57]: Package: pdf-presenter-console Version: 4.6.0-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: jaesc...@l3s.de Dear Maintainer, When starting pdfpc it immediately dies with the following error message: pdfpc slides.pdf pdfpc: symbol lookup error: /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37: undefined symbol: gst_transcoder_get_sync_signal_adapter -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pdf-presenter-console depends on: ii libc6 2.36-9 ii libcairo2 1.16.0-7 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgee-0.8-20.20.6-1 ii libglib2.0-02.74.6-2 ii libgstreamer-plugins-base1.0-0 1.22.0-3 ii libgstreamer1.0-0 1.22.0-2 ii libgtk-3-0 3.24.37-2 ii libjson-glib-1.0-0 1.6.6-1 ii libmarkdown22.2.7-2 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libpoppler-glib822.12.0-2+b1 ii libqrencode44.1.1-1 ii libsoup2.4-12.74.3-1 ii libwebkit2gtk-4.0-372.40.0-3 ii libx11-62:1.8.4-2 Versions of packages pdf-presenter-console recommends: ii gstreamer1.0-gtk3 1.22.0-5 pdf-presenter-console suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1034691: nmu: why3_1.5.1-1+b1 frama-c_20220511-manganese-3-10
Control: tag -1 - moreinfo Hi Sebastian, * Sebastian Ramacher [2023-04-22 11:10]: On 2023-04-21 21:35:21 +0200, Jochen Sprickerhof wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: w...@packages.debian.org Control: affects -1 + src:why3 src:frama-c Hi release team, can you please binNMU why3 to pick up the new ABI: nmu why3_1.5.1-1+b1 . ANY . unstable . -m "Rebuild with new OCaml ABI" And afterwards frama-c needs a rebuild against the new why3: nmu frama-c_20220511-manganese-3-10 . ANY . unstable . -m "Rebuild with new OCaml ABI (Closes: #1033701)" why3 installs perfectly fine in both bookworm and unstable. Why is this needed? We are past the point of doing transitions (especially uncoordinated ones). I don't know enough OCaml but rebuilding why3 and frama-c on top fixes frama-c and thus #1033701 for me. My understanding is that dh-ocaml uses some hash to track the ABI of a library and encodes into a virtual package: $ apt-cache show libwhy3-ocaml-dev | grep Provides Provides: libwhy3-ocaml-dev-mzlf3 And frama-c-base depends exactly on that: apt-cache show frama-c-base | grep -o "libwhy3-ocaml-dev[^,]*" libwhy3-ocaml-dev-mzlf3 But rebuilding the package in testing generates a different hash: $ sbuild -d testing why3 | grep Provides Provides: libwhy3-ocaml-dev-2bt20 So I assume this is not a new transition but a missing rebuild for an old transition. Cheers Jochen signature.asc Description: PGP signature
Bug#1034692: unblock: fail2ban/1.0.2-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: fail2...@packages.debian.org
Control: affects -1 + src:fail2ban
Please unblock package fail2ban
[ Reason ]
Move systemd service file to lib.
[ Impact ]
The fail2ban service will not be enabled/started upon installation.
[ Tests ]
On unstable:
# apt install fail2ban
# systemctl status fail2ban
○ fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; disabled; preset:
enabled)
# apt install ./fail2ban_1.0.2-2_all.deb
# systemctl status fail2ban
× fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; preset:
enabled)
[ Risks ]
None.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
Additionally I removed the lsb-base dependency as it is not needed.
unblock fail2ban/1.0.2-2
diff -Nru fail2ban-1.0.2/debian/changelog fail2ban-1.0.2/debian/changelog
--- fail2ban-1.0.2/debian/changelog 2022-11-09 17:42:47.0 +0100
+++ fail2ban-1.0.2/debian/changelog 2023-04-21 21:54:48.0 +0200
@@ -1,3 +1,16 @@
+fail2ban (1.0.2-2) unstable; urgency=medium
+
+ * Team upload.
+
+ [ Pirate Praveen ]
+ * Use systemd for correct /lib/systemd/system path (Closes: #1034230)
+
+ [ Jochen Sprickerhof ]
+ * Drop dependency on lsb-base. It is a transitional package to
+sysvinit-utils which is essential.
+
+ -- Jochen Sprickerhof Fri, 21 Apr 2023 21:54:48 +0200
+
fail2ban (1.0.2-1) unstable; urgency=medium
* New upstream release
diff -Nru fail2ban-1.0.2/debian/control fail2ban-1.0.2/debian/control
--- fail2ban-1.0.2/debian/control 2022-11-09 17:42:26.0 +0100
+++ fail2ban-1.0.2/debian/control 2023-04-21 21:54:48.0 +0200
@@ -13,6 +13,8 @@
, python3-pyinotify
, sqlite3
, 2to3
+ , pkg-config
+ , systemd
Homepage: https://www.fail2ban.org
Vcs-Git: https://salsa.debian.org/python-team/packages/fail2ban.git
Vcs-Browser: https://salsa.debian.org/python-team/packages/fail2ban
@@ -20,7 +22,7 @@
Package: fail2ban
Architecture: all
-Depends: ${python3:Depends}, ${misc:Depends}, lsb-base
+Depends: ${python3:Depends}, ${misc:Depends}
Recommends: nftables | iptables, whois, python3-pyinotify, python3-systemd
Suggests: mailx, system-log-daemon, monit, sqlite3
Description: ban hosts that cause multiple authentication errors
diff -Nru fail2ban-1.0.2/debian/rules fail2ban-1.0.2/debian/rules
--- fail2ban-1.0.2/debian/rules 2022-11-09 17:42:26.0 +0100
+++ fail2ban-1.0.2/debian/rules 2023-04-21 21:54:48.0 +0200
@@ -16,7 +16,7 @@
DESTDIR=$(CURDIR)/debian/fail2ban
PYVERSION=$(shell py3versions -dv)
-
+SYSTEMD_SYSTEM_UNIT_DIR = $(shell pkg-config --variable=systemdsystemunitdir
systemd)
override_dh_clean:
rm -rf fail2ban.egg-info
-rm debian/fail2ban.init
@@ -45,11 +45,11 @@
install -d $(DESTDIR)/usr/share/bash-completion/completions
install -m 644 files/bash-completion
$(DESTDIR)/usr/share/bash-completion/completions/fail2ban
: # Install systemd files
- install -d $(DESTDIR)/usr/lib/systemd/system/
+ install -d $(DESTDIR)$(SYSTEMD_SYSTEM_UNIT_DIR)
install -d $(DESTDIR)/usr/lib/tmpfiles.d
- install -m 644 build/fail2ban.service $(DESTDIR)/usr/lib/systemd/system
+ install -m 644 build/fail2ban.service
$(DESTDIR)$(SYSTEMD_SYSTEM_UNIT_DIR)
install -m 644 files/fail2ban-tmpfiles.conf
$(DESTDIR)/usr/lib/tmpfiles.d
- install -d $(DESTDIR)/usr/lib/systemd/system
+ install -d $(DESTDIR)$(SYSTEMD_SYSTEM_UNIT_DIR)
: # Install default jail enabler
install -m 644 debian/debian-files/jail.d_defaults-debian.conf
$(DESTDIR)/etc/fail2ban/jail.d/defaults-debian.conf
dh_install
Bug#1034691: nmu: why3_1.5.1-1+b1 frama-c_20220511-manganese-3-10
* Sebastian Ramacher [2023-04-22 16:06]:
Both why3 and frama-c have been rebuilt after the last ocaml ABI change.
From a quick between a build now and from the last why3, the following
packages changed (that appear to be relevant):
libcairo2-ocaml-dev (= [-0.6.2+dfsg-1+b1),-] {+0.6.4+dfsg-1),+}
ocaml (= [-4.13.1-3),-] {+4.13.1-4),+}
ocaml-base (= [-4.13.1-3),-] {+4.13.1-4),+}
ocaml-compiler-libs (= [-4.13.1-3),-] {+4.13.1-4),+}
ocaml-findlib (= [-1.9.3-1),-] {+1.9.6-1+b1),+}
ocaml-interp (= [-4.13.1-3),-] {+4.13.1-4),+}
ocaml-nox (= [-4.13.1-3),-] {+4.13.1-4),
So either the change in ocaml caused the ABI to change and we probably
need to rebuild the world of ocaml packages, or the ABI of why3 is
influenced by libcairo2-ocaml-dev but is missing the proper
dependencies.
I can recreate the old ABI hash by downgrading the src:ocaml packages,
i.e.:
ocaml (= [-4.13.1-3),-] {+4.13.1-4),+}
ocaml-base (= [-4.13.1-3),-] {+4.13.1-4),+}
ocaml-compiler-libs (= [-4.13.1-3),-] {+4.13.1-4),+}
ocaml-interp (= [-4.13.1-3),-] {+4.13.1-4),+}
ocaml-nox (= [-4.13.1-3),-] {+4.13.1-4),
I leave the decision what to do with it to you.
Cheers Jochen
signature.asc
Description: PGP signature
Bug#1035047: unblock: [pre-approval] xdg-desktop-portal-wlr/0.7.0-1
Control: tags -1 - moreinfo * Sebastian Ramacher [2023-04-29 10:25]: On 2023-04-28 11:26:00 +0200, Jochen Sprickerhof wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: xdg-desktop-portal-...@packages.debian.org, Birger Schacht Control: affects -1 + src:xdg-desktop-portal-wlr Please unblock package xdg-desktop-portal-wlr [ Reason ] Latest Chromium in testing fails to screen share with xdg-desktop-portal-wlr. This is fixed with xdg-desktop-portal-wlr 0.7.0. ACK. Please remove the moreinfo tag once the package is available in unstable. Thanks, it was just accepted into unstable. Cheers Jochen signature.asc Description: PGP signature
Bug#1035047: unblock: [pre-approval] xdg-desktop-portal-wlr/0.7.0-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: xdg-desktop-portal-...@packages.debian.org, Birger Schacht
Control: affects -1 + src:xdg-desktop-portal-wlr
Please unblock package xdg-desktop-portal-wlr
[ Reason ]
Latest Chromium in testing fails to screen share with
xdg-desktop-portal-wlr. This is fixed with xdg-desktop-portal-wlr 0.7.0.
[ Impact ]
Wayland Chromium users would not be able to share their screen.
[ Tests ]
Only manually tests that screen share works with Chromium and Firefox.
[ Risks ]
Small no package depend on xdg-desktop-portal-wlr.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
I think it is better to import the new upstream version instead of
trying to extract single patches as changes are mostly for fixing this
issue.
unblock xdg-desktop-portal-wlr/0.7.0-1
diff -Nru xdg-desktop-portal-wlr-0.6.0/debian/changelog
xdg-desktop-portal-wlr-0.7.0/debian/changelog
--- xdg-desktop-portal-wlr-0.6.0/debian/changelog 2022-07-02
10:11:20.0 +0200
+++ xdg-desktop-portal-wlr-0.7.0/debian/changelog 2023-04-28
10:59:18.0 +0200
@@ -1,3 +1,11 @@
+xdg-desktop-portal-wlr (0.7.0-1) unstable; urgency=medium
+
+ * Team upload
+ * New upstream release.
+- fixes screen sharing with latest chromium. (Closes: #1034735)
+
+ -- Jochen Sprickerhof Fri, 28 Apr 2023 10:59:18 +0200
+
xdg-desktop-portal-wlr (0.6.0-1) unstable; urgency=medium
* New upstream release
diff -Nru xdg-desktop-portal-wlr-0.6.0/include/screencast_common.h
xdg-desktop-portal-wlr-0.7.0/include/screencast_common.h
--- xdg-desktop-portal-wlr-0.6.0/include/screencast_common.h2022-06-09
11:25:25.0 +0200
+++ xdg-desktop-portal-wlr-0.7.0/include/screencast_common.h2023-04-15
10:32:26.0 +0200
@@ -11,7 +11,8 @@
// this seems to be right based on
//
https://github.com/flatpak/xdg-desktop-portal/blob/309a1fc0cf2fb32cceb91dbc666d20cf0a3202c2/src/screen-cast.c#L955
-#define XDP_CAST_PROTO_VER 2
+#define XDP_CAST_PROTO_VER 4
+#define XDP_CAST_DATA_VER 1
enum cursor_modes {
HIDDEN = 1,
@@ -24,6 +25,12 @@
WINDOW = 2,
};
+enum persist_modes {
+ PERSIST_NONE = 0,
+ PERSIST_TRANSIENT = 1,
+ PERSIST_PERMANENT = 2,
+};
+
enum buffer_type {
WL_SHM = 0,
DMABUF = 1,
@@ -60,7 +67,8 @@
bool y_invert;
uint64_t tv_sec;
uint32_t tv_nsec;
- struct xdpw_frame_damage damage;
+ struct xdpw_frame_damage damage[4];
+ uint32_t damage_count;
struct xdpw_buffer *xdpw_buffer;
struct pw_buffer *pw_buffer;
};
@@ -116,7 +124,6 @@
struct wl_list output_list;
struct wl_registry *registry;
struct zwlr_screencopy_manager_v1 *screencopy_manager;
- struct zxdg_output_manager_v1 *xdg_output_manager;
struct wl_shm *shm;
struct zwp_linux_dmabuf_v1 *linux_dmabuf;
struct zwp_linux_dmabuf_feedback_v1 *linux_dmabuf_feedback;
@@ -130,6 +137,16 @@
struct wl_list screencast_instances;
};
+struct xdpw_screencast_target {
+ struct xdpw_wlr_output *output;
+ bool with_cursor;
+};
+
+struct xdpw_screencast_restore_data {
+ uint32_t version;
+ const char *output_name;
+};
+
struct xdpw_screencast_instance {
// list
struct wl_list link;
@@ -154,11 +171,10 @@
// wlroots
struct zwlr_screencopy_frame_v1 *frame_callback;
- struct xdpw_wlr_output *target_output;
+ struct xdpw_screencast_target *target;
uint32_t max_framerate;
struct zwlr_screencopy_frame_v1 *wlr_frame;
struct xdpw_screencopy_frame_info screencopy_frame_info[2];
- bool with_cursor;
int err;
bool quit;
bool teardown;
@@ -168,17 +184,23 @@
struct fps_limit_state fps_limit;
};
+struct xdpw_screencast_session_data {
+ struct xdpw_screencast_instance *screencast_instance;
+ uint32_t cursor_mode;
+ uint32_t persist_mode;
+};
+
struct xdpw_wlr_output {
struct wl_list link;
uint32_t id;
struct wl_output *output;
- struct zxdg_output_v1 *xdg_output;
char *make;
char *model;
char *name;
int width;
int height;
float framerate;
+ enum wl_output_transform transformation;
};
void randname(char *buf);
@@ -195,4 +217,6 @@
enum xdpw_chooser_types get_chooser_type(const char *chooser_type);
const char *chooser_type_str(enum xdpw_chooser_types chooser_type);
+
+struct xdpw_frame_damage merge_damage(struct xdpw_frame_damage *damage1,
struct xdpw_frame_damage *damage2);
#endif /* SCREENCAST_COMMON_H */
diff -Nru xdg-desktop-portal-wlr-0.6.0/include/screenshot_common.h
xdg-desktop-portal-wlr-0.7.0/include/screenshot_common.h
--- xdg-desktop-portal-wlr-0.6.0/include/screenshot_common.h1970
Bug#1027439: elementpath breaks python-xmlschema autopkgtest: 'XMLSchemaContext' object has no attribute 'iter'
Hi Emmanuel, note that the new upstream version of python-xmlschema fixes this and other errors but Debian unstable is frozen and the change would be too big. On the other hand this currently keeps the new upstream version of elementpath from transition to testing which is a viable outcome at the current release state as well. So there is not really something to do for this bug till the release of bookworm and afterwards an upload of the new upstream version should fix it. Cheers Jochen * Emmanuel Arias [2023-03-27 07:35]: Hello, Applying the patch all the tests are fixed except one: == FAIL: test_xml_document_validation (xmlschema.testing._builders.TestValidator004.test_xml_document_validation) -- Traceback (most recent call last): File "/<>/.pybuild/cpython3_3.11_xmlschema/build/xmlschema/testing/_builders.py", line 623, in test_xml_document_validation self.check_data_conversion_with_lxml() File "/<>/.pybuild/cpython3_3.11_xmlschema/build/xmlschema/testing/_builders.py", line 507, in check_data_conversion_with_lxml self.assertEqual(len(lxml_errors), len(self.errors), msg=xml_file) AssertionError: 2 != 1 : tests/test_cases/examples/collection/collection3bis.xml - I will investigate a little bit today. Cheers, eamanu signature.asc Description: PGP signature
Bug#1033952: unblock: osgi-core/8.0.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: osgi-c...@packages.debian.org
Control: affects -1 + src:osgi-core
Please unblock package osgi-core
[ Reason ]
The LoggerFactory and LogEntry interface definitions where added to
osgi-core in version 8.0.0 duplication those in osgi-compendium.
osgi-compendium carries a Debian patch to adopt the APIs to be backward
compatible that was missing from osgi-core resulting in src:bnd FTBFS
(#1026606). 8.0.0-2 copies this patch so both packages provide the same
API.
[ Impact ]
src:bnd can not be build without this patch.
[ Tests ]
I did a test rebuild of src:bnd to make sure it compiles again:
https://tests.reproducible-builds.org/debian/rb-pkg/bnd.html
[ Risks ]
Given that the patch is already in osgi-compendium since 2020 and it
only provides default implementations for the added API methods I don't
see a risk.
Alternative solutions I looked into:
- Adopting src:bnd to implement the new API. I tried this but the diff
was rather large with no added value. Also I assume there are other
packages depending on the old API.
- removing LoggerFactory and LogEntry from osgi-core again which would
result in a diff to the upstream source and probably other packages
failing.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock osgi-core/8.0.0-2
diff --git a/debian/changelog b/debian/changelog
index 0f8c8cf..ee0ef4a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+osgi-core (8.0.0-2) unstable; urgency=medium
+
+ * Team upload.
+ * Preserve backward compatibility in logging interface.
+Turned the new interface methods into default methods to preserve the
+backward compatibility. Taken from osgi-compendium. (Closes: #1026606)
+
+ -- Jochen Sprickerhof Mon, 03 Apr 2023 14:57:28 +0200
+
osgi-core (8.0.0-1) unstable; urgency=medium
* Team upload.
diff --git a/debian/patches/01-backward-compatibility.patch
b/debian/patches/01-backward-compatibility.patch
new file mode 100644
index 000..a45e721
--- /dev/null
+++ b/debian/patches/01-backward-compatibility.patch
@@ -0,0 +1,95 @@
+Description: Preserves the source compatibility with older versions of the API
+Author: Emmanuel Bourg
+Forwarded: not-needed
+--- a/org/osgi/service/log/LoggerFactory.java
b/org/osgi/service/log/LoggerFactory.java
+@@ -61,7 +61,7 @@
+* parameter is equal to {@link Logger#ROOT_LOGGER_NAME}, then
the
+* root logger is returned.
+*/
+- Logger getLogger(String name);
++ default Logger getLogger(String name) { throw new
UnsupportedOperationException(); }
+
+ /**
+* Return the {@link Logger} named with the specified class.
+@@ -70,7 +70,7 @@
+*{@code null}.
+* @return The {@link Logger} named with the name of the specified
class.
+*/
+- Logger getLogger(Class< ? > clazz);
++ default Logger getLogger(Class< ? > clazz) { throw new
UnsupportedOperationException(); }
+
+ /**
+* Return the {@link Logger} of the specified type named with the
specified
+@@ -88,7 +88,7 @@
+* @throws IllegalArgumentException If the specified type is not a
supported
+* Logger type.
+*/
+- L getLogger(String name, Class loggerType);
++ default L getLogger(String name, Class
loggerType) { throw new UnsupportedOperationException(); }
+
+ /**
+* Return the {@link Logger} of the specified type named with the
specified
+@@ -104,7 +104,7 @@
+* @throws IllegalArgumentException If the specified type is not a
supported
+* Logger type.
+*/
+- L getLogger(Class< ? > clazz, Class loggerType);
++ default L getLogger(Class< ? > clazz, Class
loggerType) {throw new UnsupportedOperationException(); }
+
+ /**
+* Return the {@link Logger} of the specified type named with the
specified
+@@ -130,6 +130,6 @@
+* @throws IllegalArgumentException If the specified type is not a
supported
+* Logger type or the specified Bundle is not a resolved
bundle.
+*/
+- L getLogger(Bundle bundle, String name,
+- Class loggerType);
++ default L getLogger(Bundle bundle, String name,
++ Class loggerType) { throw new
UnsupportedOperationException(); }
+ }
+--- a/org/osgi/service/log/LogEntry.java
b/org/osgi/service/log/LogEntry.java
+@@ -111,7 +111,7 @@
+* @return The level of this {@code LogEntry} object.
+* @since 1.4
+*/
+- LogLevel getLogLevel();
++ default LogLevel getLogLevel() { throw new
UnsupportedOperationException(); }
+
+ /**
+* Returns the name of the {@link Logger} object used to creat
Bug#1027965: Fix for the RC bug in vtk
Hi Steven, * Steven Robbins [2023-02-05 10:26]: Was looking yesterday for an RC bug to fix and noticed #1027965 against VTK -- a build failure in gdcm caused by missing dependency. The fix proposed by Mathieu seems reasonable to me. I assume you mean the proposal to add a libvtk9-qt-dev dependency to libvtk9-dev? Note that libvtk9-dev already has a dependency to libvtk9-qt-dev resulting in a cyclic dependency between both. Those are known to not work well in Debian and should be avoided. The underlying problem here is that the vtk9 cmake files are not separated between libvtk9-dev and libvtk9-qt-dev so the split seems artificial to Debian and both packages should probably be merged into one or the cmake files need rewriting. Cheers Jochen signature.asc Description: PGP signature
Bug#1012890: android-platform-frameworks-base: ftbfs with GCC-12
Hi Roger, * Roger Shimizu [2023-02-04 10:47]: On Sat, Feb 4, 2023 at 12:09 AM Roger Shimizu wrote: control: reopen -1 Yes, it ftbfs on sid now. And I tried latest upstream 13.0.0_r24, result is the same. Have to fix this issue before we can migrate to sid. Error log is not originally reported, for latest error log please refer to: - https://bugs.debian.org/1012890#17 I guess the issue is caused due to upstream using clang stdc++ lib, but we're using gcc/g++ one. Those two have slight differences. I can't reproduce this. The unstable version (1:10.0.0+r36-10) builds fine in sbuild and also reproducible builds shows no ftbfs: https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/i386/android-platform-frameworks-base.html What exactly did you test? Cheers Jochen signature.asc Description: PGP signature
Bug#1012890: android-platform-frameworks-base: ftbfs with GCC-12
* Roger Shimizu [2023-02-09 13:42]:
Please try the version in experimental.
and also refer the version info of this ticket:
Found in versions android-platform-frameworks-base/1:10.0.0+r36-5,
android-platform-frameworks-base/13~beta3-1~exp1
Fixed in version android-platform-frameworks-base/1:10.0.0+r36-6
Oups, sorry. The attached patch against android-platform-tools fixes the
issue for me.
Cheers Jochen
From: Jochen Sprickerhof
Date: Fri, 10 Feb 2023 11:46:23 +0100
Subject: Implement const_iterator::operator--
Needed for
android-platform-frameworks-base/libs/androidfw/LoadedArsc.cpp
when compiling against libstdc++.
---
.../incremental_delivery/incfs/util/include/util/map_ptr.h | 12
1 file changed, 12 insertions(+)
diff --git a/system/incremental_delivery/incfs/util/include/util/map_ptr.h b/system/incremental_delivery/incfs/util/include/util/map_ptr.h
index 304540f..836b320 100644
--- a/system/incremental_delivery/incfs/util/include/util/map_ptr.h
+++ b/system/incremental_delivery/incfs/util/include/util/map_ptr.h
@@ -180,6 +180,11 @@ public:
return *this;
}
+const const_iterator& operator--() {
+safe_ptr_--;
+return *this;
+}
+
const_iterator& operator+=(int n) {
safe_ptr_ = safe_ptr_ + n;
return *this;
@@ -321,6 +326,13 @@ public:
return temp;
}
+template = 0>
+const map_ptr& operator--() {
+LIBINCFS_MAP_PTR_DEBUG_CODE(verified_ = false);
+--ptr_;
+return *this;
+}
+
template = 0>
map_ptr operator+(const S n) const {
return map_ptr(map_, ptr_ + n, verified_block_);
signature.asc
Description: PGP signature
Bug#1012890: android-platform-frameworks-base: ftbfs with GCC-12
Hi Hans, * Hans-Christoph Steiner [2023-02-13 09:17]: Roger, it is great to see your progress on android-platform-tools. Are you thinking of trying to get it into bookworm? If so, let me know how I can help. It would be really valuable to have there, but I don't know how much work it'll be. ähm, soft freeze started yesterday so no new upstream versions, please: https://release.debian.org/testing/freeze_policy.html#soft Cheers Jochen signature.asc Description: PGP signature
Bug#1030254: debvm: Please support "--variant=custom" VMs
Hi Helmut, * Helmut Grohne [2023-02-03 10:17]: Should we change --include=init to --include=systemd-sysv? Yes. Then we're into adding a skip option. I'd call it "initsystem" or "systemd" depending on the previous answer. I prefer "initsystem" in case we want to change the specific one later. Should --skip=systemd imply --skip=systemdnetwork? I assume that someone who want to skip init has a specific use case in mind and probably does not want a network either or could add just add the parameters manually. So yes. Should --skip=systemd imply --skip=autologin? Yes, same argument as above. Cheers Jochen signature.asc Description: PGP signature
Bug#1030504: RM: sdformat9 -- ROM; EOL upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: sdform...@packages.debian.org Control: affects -1 + src:sdformat9
Bug#1030500: RM: ignition-common3 -- ROM; EOL upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ignition-comm...@packages.debian.org Control: affects -1 + src:ignition-common3
Bug#1030502: RM: ignition-msgs5 -- ROM; EOL upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ignition-ms...@packages.debian.org Control: affects -1 + src:ignition-msgs5
Bug#1030503: RM: ignition-transport8 -- ROM; EOL upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ignition-transpo...@packages.debian.org Control: affects -1 + src:ignition-transport8
Bug#1030501: RM: ignition-fuel-tools4 -- ROM; EOL upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ignition-fuel-too...@packages.debian.org Control: affects -1 + src:ignition-fuel-tools4
Bug#1030498: RM: pn -- ROM; Replaced by maintained pnc fork
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: p...@packages.debian.org Control: affects -1 + src:pn
Bug#1030507: nmu: xrayutilities_1.7.4-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: xrayutilit...@packages.debian.org Control: affects -1 + src:xrayutilities nmu xrayutilities_1.7.4-1 . ANY . unstable . -m "Rebuild to pick up python3-h5py dependency (Closes: #1030220)"
Bug#1030508: RM: gazebo -- ROM; old, unmaintained, FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: gaz...@packages.debian.org Control: affects -1 + src:gazebo
Bug#1040500: routine-update: Don't create d/salsa-ci.yml file
Hi Andreas, * Andreas Tille [2023-07-07 09:20]: Am Thu, Jul 06, 2023 at 09:03:23PM +0100 schrieb Christopher Obbard: routine-update adds a file under the path "debian/salsa-ci.yml". Yes, this is intended. According to the salsa-ci-team[1], the default recommendation is to set the pipeline URL in the project settings rather than to use a standaline debian/salsa-ci.yml file. Therefore, please remove the addition of this file and instead please print a warning if this file exists for manual intervention to change the pipeline to the recommended suggestion by the Salsa CI team. I confirm routine-update is going beyond the recommendation but in those teams where I'm working (in CC) we have this de-facto standard to use this file. Before I change the behaviour of routine-update I would like to discuss this inside these teams and ask for opinions. I don't think we have a de-facto standard on that file in debian-science, at least I removed it from my packages a long time ago already and I agree with Christopher that routine-update should do the same. There is no benefit in having a file with the same content in every repo and every Debian package if we can avoid it. Cheers Jochen signature.asc Description: PGP signature
Bug#1040500: routine-update: Don't create d/salsa-ci.yml file
* Andreas Tille [2023-07-07 11:24]: Thanks for your opinion about this. What I mean with de facto standard: We have about 2000 repositories configured to check debian/salsa-ci.yml. I have not yet found a way to set the according field via gitlab API to something else. If this is scriptable I'd happily remove debian/salsa-ci.yml. For the moment I state two votes against salsa-ci.yml. ;-) echo "SALSA_TOKEN=" >> ~/.devscripts echo 'SALSA_CI_CONFIG_PATH="recipes/debian.yml@salsa-ci-team/pipeline"' >> ~/.devscripts sudo apt install devscripts salsa update_safe --group science-team --all Cheers Jochen signature.asc Description: PGP signature
Bug#1035933: linux-image-6.1.0-8-amd64-unsigned: fails to build (llvm-strip not found, missing dependency?)
Control: severity -1 minor Control: tags -1 + moreinfo Hi Claude, given your information and that the package builds fine on the buildds I downgrade this to minor and add a moreinfo tag. Cheers Jochen * Jochen Sprickerhof [2023-05-25 14:56]: Thanks for the information. I don't see why it should use llvm, on the other hand the kernel Makefile is rather clear when to use it. Can you check if you an still reproduce the problem? * Claude Heiland-Allen [2023-05-25 11:47]: Hi Jochen, I didn't set any non-standard compiler options as far as I recall. I certainly was not intending to build with LLVM. Unfortunately I have not kept the log of the failing build, but I remember seeing that gcc was used for the majority of the compilation. Regards, Claude signature.asc Description: PGP signature
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Hi Michael, * Michael Biebl [2023-05-30 13:23]: bullseye chroot upgraded to bookworm: # find /etc/systemd/system/ -name e2scrub_reap.service /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service /etc/systemd/system/default.target.wants/e2scrub_reap.service But when you use a VM: $ debvm-create -r bullseye $ debvm-run # apt install e2fsprogs # find / -name e2scrub_reap.service /var/lib/systemd/deb-systemd-helper-enabled/default.target.wants/e2scrub_reap.service /lib/systemd/system/e2scrub_reap.service /etc/systemd/system/default.target.wants/e2scrub_reap.service # cat /var/lib/systemd/deb-systemd-helper-enabled/e2scrub_reap.service.dsh-also /etc/systemd/system/default.target.wants/e2scrub_reap.service # sed -i 's/bullseye/bookworm/' /etc/apt/sources.list # apt update # apt dist-upgrade # find / -name e2scrub_reap.service /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/e2scrub_reap.service /var/lib/systemd/deb-systemd-helper-enabled/default.target.wants/e2scrub_reap.service /usr/lib/systemd/system/e2scrub_reap.service /etc/systemd/system/default.target.wants/e2scrub_reap.service # cat /var/lib/systemd/deb-systemd-helper-enabled/e2scrub_reap.service.dsh-also /etc/systemd/system/default.target.wants/e2scrub_reap.service /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service So what I would suggest is a if dpkg --compare-versions "$2" lt "$ver of your next upload"; then rm -f /etc/systemd/system/default.target.wants/e2scrub_reap.service fi in your postinst to clean up the stray enablement symlink. I think this would disable the service for users that upgraded from bullseye as shown above. Cheers Jochen signature.asc Description: PGP signature
Bug#1035933: linux-image-6.1.0-8-amd64-unsigned: fails to build (llvm-strip not found, missing dependency?)
Hi Claude, the Debian kernel is compiled with GCC: https://buildd.debian.org/status/fetch.php?pkg=linux=amd64=6.1.27-1=1683630698=0 and compiles just fine. To compile the kernel with llvm you either need to set CC or LLVM variables: https://www.kernel.org/doc/html/latest/kbuild/llvm.html Can you send the output of `export` to check what is set in your environment? Given that you don't use the default compiler and that the default toolchain is provided by the build-essential package, I don't think this is a dependency issue and I would close this bug. Cheers Jochen * Claude Heiland-Allen [2023-05-11 12:57]: Package: linux-image-6.1.0-8-amd64-unsigned Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: cla...@mathr.co.uk Dear Maintainer, * What led up to the situation? I wanted to patch the kernel source to see if it would help an issue I was having, so I followed my usual steps when changing a Debian package locally: sudo apt build-dep linux-image-6.1.0-8-amd64-unsigned mkdir linux cd linux apt source linux-image-6.1.0-8-amd64-unsigned cd linux-6.1.25 # make changes to the source code # specfically some warning prints in devices/usb/host/xhci-ring.c debuild -i -us -uc -b * What was the outcome of this action? The build failed after some time with: ... llvm-strip -g /home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool/profiler.bpf.o make[4]: llvm-strip: No such file or directory make[4]: *** [Makefile:187: /home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool/profiler.bpf.o] Error 127 make[4]: *** Waiting for unfinished jobs llvm-strip -g /home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool/pid_iter.bpf.o make[4]: llvm-strip: No such file or directory make[4]: *** [Makefile:187: /home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool/pid_iter.bpf.o] Error 127 make[4]: Leaving directory '/home/claude/linux/linux-6.1.25/tools/bpf/bpftool' make[3]: *** [/home/claude/linux/linux-6.1.25/debian/rules.d/tools/bpf/bpftool/Makefile:15: all] Error 2 make[3]: Leaving directory '/home/claude/linux/linux-6.1.25/debian/build/build-tools/tools/bpf/bpftool' make[2]: *** [debian/rules.real:538: build_bpftool] Error 2 make[2]: Leaving directory '/home/claude/linux/linux-6.1.25' make[1]: *** [debian/rules.gen:1494: build-arch_amd64_real_bpftool] Error 2 make[1]: Leaving directory '/home/claude/linux/linux-6.1.25' make: *** [debian/rules:39: build-arch] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 debuild: fatal error at line 1182: dpkg-buildpackage -us -uc -ui -i -b failed * What outcome did you expect instead? I expected apt to have fetched all the build-time dependencies of the package, and the build to have succeeded. * What exactly did you do (or not do) that was effective (or ineffective)? After sudo apt install llvm then debuild -i -us -uc -b worked as expected. Thanks for your work on this package, Claude -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (990, 'testing-security'), (990, 'testing'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-8-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-6.1.0-8-amd64-unsigned depends on: ii initramfs-tools [linux-initramfs-tool] 0.142 ii kmod30+20221128-1 ii linux-base 4.9 Versions of packages linux-image-6.1.0-8-amd64-unsigned recommends: ii apparmor 3.0.8-3 ii firmware-linux-free 20200122-1 Versions of packages linux-image-6.1.0-8-amd64-unsigned suggests: pn debian-kernel-handbook ii extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1 ii grub-efi-amd64 2.06-12 pn linux-doc-6.1 signature.asc Description: PGP signature
Bug#1036720: unblock: sxmo-utils/1.12.0-7
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: sxmo-ut...@packages.debian.org
Control: affects -1 + src:sxmo-utils
Please unblock package sxmo-utils
[ Reason ]
Removing sxmo-utils but not purging it leaves behind a
/etc/profile.d/sxmo_init.sh that fails to run cause it can't find
dependent files.
[ Impact ]
Users that removed sxmo-utils can't login any longer.
[ Tests ]
Manual tests.
[ Risks ]
None
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock sxmo-utils/1.12.0-7
diff --git a/debian/changelog b/debian/changelog
index fdc3418..ffb3f4f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+sxmo-utils (1.12.0-7) unstable; urgency=medium
+
+ * Add patch to fix login when sxmo is removed
+
+ -- Jochen Sprickerhof Wed, 24 May 2023 19:15:29 +0200
+
sxmo-utils (1.12.0-6) unstable; urgency=medium
* Replace pn by pnc
diff --git
a/debian/patches/0023-Don-t-fail-when-sxmo-utils-is-removed-but-not-purged.patch
b/debian/patches/0023-Don-t-fail-when-sxmo-utils-is-removed-but-not-purged.patch
new file mode 100644
index 000..1cfd500
--- /dev/null
+++
b/debian/patches/0023-Don-t-fail-when-sxmo-utils-is-removed-but-not-purged.patch
@@ -0,0 +1,20 @@
+From: Jochen Sprickerhof
+Date: Wed, 24 May 2023 19:12:45 +0200
+Subject: Don't fail when sxmo-utils is removed (but not purged)
+
+---
+ configs/profile.d/sxmo_init.sh | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/configs/profile.d/sxmo_init.sh b/configs/profile.d/sxmo_init.sh
+index d4792e6..3906c7f 100644
+--- a/configs/profile.d/sxmo_init.sh
b/configs/profile.d/sxmo_init.sh
+@@ -4,6 +4,7 @@
+
+ # This script is meant to be sourced on login shells
+ # shellcheck source=scripts/core/sxmo_common.sh
++test -f /usr/bin/sxmo_common.sh || return 0
+ . sxmo_common.sh
+
+ _sxmo_is_running() {
diff --git a/debian/patches/series b/debian/patches/series
index 5e3ae5a..21d7a8b 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -20,3 +20,4 @@ no_doas.patch
0020-Fix-Bluetooth-toogle.patch
0021-replace-pn-with-pnc.patch
0022-add-missing-pn-pnc.patch
+0023-Don-t-fail-when-sxmo-utils-is-removed-but-not-purged.patch
Bug#1035933: linux-image-6.1.0-8-amd64-unsigned: fails to build (llvm-strip not found, missing dependency?)
Thanks for the information. I don't see why it should use llvm, on the other hand the kernel Makefile is rather clear when to use it. Can you check if you an still reproduce the problem? * Claude Heiland-Allen [2023-05-25 11:47]: Hi Jochen, I didn't set any non-standard compiler options as far as I recall. I certainly was not intending to build with LLVM. Unfortunately I have not kept the log of the failing build, but I remember seeing that gcc was used for the majority of the compilation. Regards, Claude PS: export output as requested: $ export declare -x ANDROID_HOME="/home/claude/opt/android" declare -x ANDROID_NDK_HOME="/home/claude/opt/android/ndk/21.4.7075529" declare -x CLUTTER_IM_MODULE="ibus" declare -x COLORTERM="truecolor" declare -x DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" declare -x DESKTOP_SESSION="xfce" declare -x DISPLAY=":0.0" declare -x GDMSESSION="xfce" declare -x GNOME_TERMINAL_SCREEN="/org/gnome/Terminal/screen/0b1a867e_925f_4768_96f3_643cc3c21d91" declare -x GNOME_TERMINAL_SERVICE=":1.84" declare -x GTK_IM_MODULE="ibus" declare -x GTK_MODULES="gail:atk-bridge" declare -x HOME="/home/claude" declare -x LANG="en_GB.UTF-8" declare -x LANGUAGE="en_GB:en" declare -x LD_LIBRARY_PATH="/home/claude/opt/lib" declare -x LOGNAME="claude" declare -x LS_COLORS="rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35 :*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.swp=00;90:*.tmp=00;90:*.dpkg-dist=00;90:*.dpkg-old=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:" declare -x OLDPWD declare -x PANEL_GDK_CORE_DEVICE_EVENTS="0" declare -x PATH="/home/claude/opt/vbcc/vbcc/bin:/opt/amiga/bin:/home/claude/opt/android/ndk/21.4.7075529:/home/claude/opt/android/platform-tools:/home/claude/opt/android/tools:/home/claude/opt/bin:/home/claude/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/claude/opt/bin" declare -x PWD="/home/claude" declare -x QT_ACCESSIBILITY="1" declare -x QT_IM_MODULE="ibus" declare -x QT_QPA_PLATFORMTHEME="gtk2" declare -x SESSION_MANAGER="local/eiskaffee:@/tmp/.ICE-unix/1911,unix/eiskaffee:/tmp/.ICE-unix/1911" declare -x SHELL="/bin/bash" declare -x SHLVL="1" declare -x SSH_AGENT_PID="2048" declare -x SSH_AUTH_SOCK="/tmp/ssh-XXtd5uft/agent.1911" declare -x TERM="xterm-256color" declare -x USER="claude" declare -x VBCC="/opt/amiga/vbcc" declare -x VTE_VERSION="7003" declare -x XAUTHORITY="/home/claude/.Xauthority" declare -x XDG_CONFIG_DIRS="/etc/xdg" declare -x XDG_CURRENT_DESKTOP="XFCE" declare -x XDG_DATA_DIRS="/usr/share/xfce4:/usr/local/share/:/usr/share/:/usr/share" declare -x XDG_GREETER_DATA_DIR="/var/lib/lightdm/data/claude" declare -x XDG_MENU_PREFIX="xfce-" declare -x XDG_RUNTIME_DIR="/run/user/1000" declare -x XDG_SEAT="seat0" declare -x XDG_SEAT_PATH="/org/freedesktop/DisplayManager/Seat0" declare -x XDG_SESSION_CLASS="user" declare -x XDG_SESSION_DESKTOP="xfce" declare -x XDG_SESSION_ID="2" declare -x XDG_SESSION_PATH="/org/freedesktop/Display
Bug#1037165: vit: Python TypeError: 'str' object does not support item assignment
Control: severity -1 normal
Hi Matthew,
On Tue, 6 Jun 2023 19:43:34 +0100 Matthew Lemon wrote:
> Traceback (most recent call last):
> File "/usr/bin/vit", line 33, in
> sys.exit(load_entry_point('vit==2.2.0', 'console_scripts', 'vit')())
> ^^
> File "/usr/lib/python3/dist-packages/vit/command_line.py", line 5, in main
> Application(options, filters)
> File "/usr/lib/python3/dist-packages/vit/application.py", line 77, in
> __init__
> self.refresh(False)
> File "/usr/lib/python3/dist-packages/vit/application.py", line 920, in
> refresh
> self.bootstrap(load_early_config)
> File "/usr/lib/python3/dist-packages/vit/application.py", line 110, in
> bootstrap
> self.load_contexts()
> File "/usr/lib/python3/dist-packages/vit/application.py", line 104, in
> load_contexts
> self.contexts = self.task_config.get_contexts()
> ^^^
> File "/usr/lib/python3/dist-packages/vit/config_parser.py", line 333, in
> get_contexts
> subtree = self.subtree('context.')
>
> File "/usr/lib/python3/dist-packages/vit/config_parser.py", line 292, in
> subtree
> tree_location[part] = {} if len(parts) else value
> ~^^
> TypeError: 'str' object does not support item assignment
I can't reproduce this in a fresh system (downgrading severity accordingly). Do
you have any taskwarrior or vit config files in your home? Judging from the
trace above I guess it is a custom taskwarrior config. Can you try without that?
Cheers Jochen
Bug#1036472: unblock: ros-actionlib/1.14.0-6
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ros-action...@packages.debian.org
Control: affects -1 + src:ros-actionlib
Please unblock package ros-actionlib
[ Reason ]
libactionlib-dev was missing a depenency.
[ Impact ]
Users would need to manually install libroscpp-dev in addition.
[ Tests ]
I verified the missing dependency manually.
[ Risks ]
None.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock ros-actionlib/1.14.0-6
diff --git a/debian/changelog b/debian/changelog
index d3143ab..307e040 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ros-actionlib (1.14.0-6) unstable; urgency=medium
+
+ * Add missing dependency
+
+ -- Jochen Sprickerhof Sun, 21 May 2023 21:10:12 +0200
+
ros-actionlib (1.14.0-5) unstable; urgency=medium
* Increase timeout for test on armel
diff --git a/debian/control b/debian/control
index a9d09e5..7cebce3 100644
--- a/debian/control
+++ b/debian/control
@@ -54,7 +54,7 @@ Section: libdevel
Architecture: any
Multi-Arch: same
Depends: ${misc:Depends}, libactionlib1d ( = ${binary:Version}),
- ${python3:Depends}, python3, libboost-thread-dev,
libactionlib-msgs-dev, ros-message-generation, python3-rosunit, libstd-msgs-dev
+ ${python3:Depends}, python3, libboost-thread-dev,
libactionlib-msgs-dev, ros-message-generation, python3-rosunit,
libstd-msgs-dev, libroscpp-dev,
Description: ${source:Synopsis} - development files
${source:Extended-Description}
.
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
* James Addison [2023-06-01 12:44]: Would reverting the Install.WantedBy modification[1][2], restoring e2scrub_reap enablement using 'default.target' on relevant systems, be a sensible approach for bookworm until we can figure out the debhelper-system behaviour when that setting changes? No, bookworm is frozen and done: "In the last week prior to the freeze, testing will be completely frozen and only emergency bug fixes will be considered in this period." https://lists.debian.org/debian-devel-announce/2023/04/msg7.html Cheers Jochen signature.asc Description: PGP signature
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Hi Ted, * Theodore Ts'o [2023-05-27 19:45]: So sure, /etc/systemd.d/system/multi-user.target.wants/e2scrub_reap.service doesn't exist. *But* it still exists in .../default.target.wants/... which seems to be enough to keep the e2scrub_reap service enabled. Right? Yes, that's fine. In any case, I am still unclear (a) what is actually broken in this particular setup, since according to systemctl status the systemd unit is apparently still appropriate enabled, even if it isn't via the expected Wanted-b: multi-user.target. The point of piuparts is that an upgraded system is different to a newly installed system, i.e. that the e2scrub_reap.service symlink lies in a different directory. And secondly, (b) what is e2fsprogs's control scripts supposed to have done differently? That is, if this is indeed this is a bug in e2fsprogs --- what did I do wrong, and how do I fix it? Arguably nothing and init-system-helpers/dh_installsystemd should detect the change and move the symlink. And if the answer is you should never, ever, try to change a Wanted-by line in a systemd script, because debian's systemd unit file infrastructure is too fragile to handle this correctly, given that bookworm is about to ship with "Wanted-by: multi-user.target", what's the best path forward at this point? For now the best way is to do nothing and wait for the bookworm release. In general there are two things. One is to fix the immediate problem this issue is about and we can still do that in a point release. The other one is to have general support for changing Wanted-by: (or state that it is not supported). I would propose to ask the init-system-helpers/dh_installsystemd maintainers for a general solution and then apply that for a bookworm point release. Cheers Jochen signature.asc Description: PGP signature
Bug#1037698: j4-dmenu-desktop: ftbfs with GCC-13
Control: forwared -1 https://github.com/enkore/j4-dmenu-desktop/pull/139 Hi Peter, j4-dmenu-desktop is a dependency of sxmo-utils and so I would like to prevent it's removal from testing. The patch linked above is really simple and I would be happy if you could upload a fixed version. I can also sponsor the upload, if needed. There where also multiple new upstream versions and I would be happy to help maintain this package if you would be ok with that. In case you don't have time to do the upload, I can do an NMU. If you don't answer by end of next week I will assume that you are ok with an NMU containing the above patch and will upload. Cheers Jochen * Matthias Klose [2023-06-14 09:25]: Package: src:j4-dmenu-desktop Version: 2.16-1 Severity: normal Tags: sid trixie User: debian-...@lists.debian.org Usertags: ftbfs-gcc-13 [This bug is targeted to the upcoming trixie release] Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can be built in a follow-up test rebuild. The package fails to build in a test rebuild on at least amd64 with gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The severity of this report will be raised before the trixie release. The full build log can be found at: http://qa-logs.debian.net/2023/05/22/logs/j4-dmenu-desktop_2.16-1_unstable_gccexp.log The last lines of the build log are at the end of this report. To build with GCC 13, either set CC=gcc-13 CXX=g++-13 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t=experimental install g++ Common build failures are new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-13/porting_to.html [...] | ^~~ /<>/src/Application.hh:149:22: error: unable to find string literal operator ‘operator""_istr’ with ‘const char [11]’, ‘long unsigned int’ arguments 149 | case "OnlyShowIn"_istr: | ^ /<>/src/Application.hh:161:22: error: unable to find string literal operator ‘operator""_istr’ with ‘const char [10]’, ‘long unsigned int’ arguments 161 | case "NotShowIn"_istr: | ^~~~ /<>/src/Application.hh:173:22: error: unable to find string literal operator ‘operator""_istr’ with ‘const char [7]’, ‘long unsigned int’ arguments 173 | case "Hidden"_istr: | ^ /<>/src/Application.hh:174:22: error: unable to find string literal operator ‘operator""_istr’ with ‘const char [10]’, ‘long unsigned int’ arguments 174 | case "NoDisplay"_istr: | ^~~~ /<>/src/Application.hh:182:22: error: unable to find string literal operator ‘operator""_istr’ with ‘const char [9]’, ‘long unsigned int’ arguments 182 | case "Terminal"_istr: | ^~~ /<>/src/Application.hh:183:61: error: unable to find string literal operator ‘operator""_istr’ with ‘const char [5]’, ‘long unsigned int’ arguments 183 | this->terminal = make_istring(value) == "true"_istr; | ^~~ In file included from /<>/src/TestFormatters.cc:8: /<>/src/Application.hh: In member function ‘bool Application::read(const char*, char**, size_t*)’: /<>/src/Application.hh:94:19: warning: ignoring return value of ‘char* getcwd(char*, size_t)’ declared with attribute ‘warn_unused_result’ [-Wunused-result] 94 | getcwd(pwd, 100); | ~~^~ /<>/src/Main.hh: In member function ‘bool Main::read_args(int, char**)’: /<>/src/Main.hh:167:33: warning: this statement may fall through [-Wimplicit-fallthrough=] 167 | exclude_generic = true; | ^~ /<>/src/Main.hh:168:13: note: here 168 | case 'l': | ^~~~ /<>/src/Main.hh: In member function ‘void Main::collect_files()’: /<>/src/Main.hh:187:15: warning: ignoring return value of ‘char* getcwd(char*, size_t)’ declared with attribute ‘warn_unused_result’ [-Wunused-result] 187 | getcwd(original_wd, 384); | ~~^~ /<>/src/Main.hh:195:18: warning: ignoring return value of ‘int chdir(const char*)’ declared with attribute ‘warn_unused_result’ [-Wunused-result] 195 | chdir(path.c_str()); | ~^~ /<>/src/Main.hh:204:14: warning: ignoring return value of ‘int chdir(const char*)’ declared with attribute ‘warn_unused_result’ [-Wunused-result] 204 | chdir(original_wd); |
Bug#1037698: j4-dmenu-desktop: diff for NMU version 2.16-1.1
Control: tags 1037698 + patch Dear maintainer, I've prepared an NMU for j4-dmenu-desktop (versioned as 2.16-1.1). The diff is attached to this message. Regards. Jochen diff -Nru j4-dmenu-desktop-2.16/debian/changelog j4-dmenu-desktop-2.16/debian/changelog --- j4-dmenu-desktop-2.16/debian/changelog 2018-09-10 21:26:15.0 +0200 +++ j4-dmenu-desktop-2.16/debian/changelog 2023-07-30 16:19:24.0 +0200 @@ -1,3 +1,10 @@ +j4-dmenu-desktop (2.16-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix build with GCC 13 (Closes: #1037698) + + -- Jochen Sprickerhof Sun, 30 Jul 2023 16:19:24 +0200 + j4-dmenu-desktop (2.16-1) unstable; urgency=medium * New upstream release diff -Nru j4-dmenu-desktop-2.16/debian/patches/0003-Fix-build-with-GCC-13.patch j4-dmenu-desktop-2.16/debian/patches/0003-Fix-build-with-GCC-13.patch --- j4-dmenu-desktop-2.16/debian/patches/0003-Fix-build-with-GCC-13.patch 1970-01-01 01:00:00.0 +0100 +++ j4-dmenu-desktop-2.16/debian/patches/0003-Fix-build-with-GCC-13.patch 2023-07-30 16:18:44.0 +0200 @@ -0,0 +1,28 @@ +From: Sam James +Date: Tue, 18 Apr 2023 11:08:53 +0100 +Subject: Fix build with GCC 13 + +GCC 13 (as usual for new compiler releases) shuffles around some internal includes so some +are no longer transitively included. + +See https://gnu.org/software/gcc/gcc-13/porting_to.html. + +Bug: https://bugs.gentoo.org/895200 +--- + src/Application.hh | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/src/Application.hh b/src/Application.hh +index 355be9b..d24ff1c 100644 +--- a/src/Application.hh b/src/Application.hh +@@ -19,7 +19,8 @@ + #define APPLICATION_DEF + + #include +-#include ++#include ++#include + #include + + #include "Utilities.hh" diff -Nru j4-dmenu-desktop-2.16/debian/patches/series j4-dmenu-desktop-2.16/debian/patches/series --- j4-dmenu-desktop-2.16/debian/patches/series 2018-09-10 21:26:15.0 +0200 +++ j4-dmenu-desktop-2.16/debian/patches/series 2023-07-30 16:18:48.0 +0200 @@ -1,2 +1,3 @@ 0001-remove-catch-download.patch 0002-remove-testcase-for-desktop-systems.patch +0003-Fix-build-with-GCC-13.patch signature.asc Description: PGP signature
Bug#1040942: rosbash: Most binary tools (roscd, rosd, rosls, ....) are unavailable in this package
Hi Dima, * Dima Kogan [2023-07-12 11:37]: Hello. I'm using the package from bookworm. rosbash The "rosbash" package should provide several commandline tools, documented here: http://wiki.ros.org/rosbash But only "rosrun" is provided in the package. This is because most of the tools are not binaries, but are shell functions. These are supposed to be defined in /usr/share/rosbash/rosbash, but our rosbash package does not ship this file. This file exists in the package sources in tools/rosbash/rosbash, but it is not installed anywhere. This is the bug. Our package does reference the tools (we include all the tab completions). And the package scripts ask for it: dima@fatty:$ source /usr/share/rosbash/catkin_env_hook/15.rosbash.bash bash: /usr/share/rosbash/rosbash: No such file or directory So if we install that file, that would probably fix this bug. The file is installed as: /usr/share/bash-completion/completions/rosbash So we could adopt the path in 15.rosbash.bash. But I wonder if we should rather source that file by default. Up to 1.15.8-1 (buster) rosbash installed that file into /etc/bash_completion.d/rosbash and it was sourced automatically when bash-completion was activated. In 1.15.8-1 this was changed to /usr/share.. because the /etc patch is deprecated (afair) but bash-completion does not source those files automatically anymore. The only option I found is adding a link in /etc/profile.d/. for fish, tcsh and zsh the respective files are sourced automatically already, so we should probably remove the corresponding catkin_env_hooks. Btw. ros-noetic-rosbash contains: /opt/ros/noetic/share/rosbash/catkin_env_hook/15.rosbash.* and /opt/ros/noetic/etc/catkin/profile.d/15.rosbash.* But I'm not sure when either are used, does someone know? Cheers Jochen signature.asc Description: PGP signature
Bug#1041924: RM: gpsbabel-gui [mipsel] -- ROM; qtwebengine5-dev no longer builds on mipsel
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: gpsba...@packages.debian.org Control: affects -1 + src:gpsbabel Hi ftp-masters, please remove the mipsel gpsbabel-gui package, as proposed in #1041912 (after 1.8.0+ds-6 was build). Thanks! Jochen
Bug#1034694: gnome-core: Cannot install due to pipewire-audio dependency
Thanks for the additional information. To my understanding pipewire-alsa and pipewire-audio are put on hold on your system, not allowing it's installation. You can verify that with: apt-mark showhold But the latest gnome-core depends on pipewire-audio so apt can't find a solution. You can reset the state with: sudo apt-mark unhold pipewire-alsa pipewire-audio I can imagine apt printing a more helpful error message there but not sure what to do otherwise. I would close the bug if you agree. Cheers Jochen * Witold Baryluk [2023-05-09 21:14]: Package: gnome-core Version: 1:43+1 Followup-For: Bug #1034694 X-Debbugs-Cc: witold.bary...@gmail.com Hi Jochen. In attachment you should find debug output of apt (stdout + stderr), as well as a dpkg status file. If you want to reproduce the problem, I have a live-build iso image you can boot in qemu. wget -c http://185.108.112.63/smooth/smooth-amd64_20230421T002521Z.iso # 4.0GB sha256sums: cf8818a8989489c0314ee9cddc0650c3d33c0442fa8eb1d103879063ea41c02d smooth-amd64_20230421T002521Z.iso Run in qemu: qemu-system-x86_64 -enable-kvm -M q35 -smp 8 -m 8192 -cdrom smooth-amd64_20230421T002521Z.iso Once loaded into MATE, in terminal emulator: sudo apt update # optionally dist-upgrade sudo apt install gnome-core Hope that helps. Thanks! Witold signature.asc Description: PGP signature
Bug#1036007: unblock: opencv/4.6.0+dfsg-12
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ope...@packages.debian.org
Control: affects -1 + src:opencv
Please unblock package opencv
[ Reason ]
This upload fixes two bugs:
1. #1035886 that adds a single Breaks: against an old library version to
easy the upgrade.
2. #1035954 that adds upstream patches for two CVEs.
[ Impact ]
For 1. users could have problems upgrading.
For 2. I'm not sure about the impact of the CVEs but I guess it is
better to get them fixed before the release.
[ Tests ]
The CVEs carry a test, I did not verify the Breaks: but I assume Andreas
tested it :).
[ Risks ]
The Breaks: means users can't keep the old version, I think that is
acceptable if apt finds a upgrade solution.
For the CVEs the patch looks reasonable but I'm not sure if there is any
risk to it. Given that it applied cleanly to the version in unstable and
that upstream accepted it, I think it is fine.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
The patch carries a change to debian/gbp.conf which is not imported for
the package in the archive.
unblock opencv/4.6.0+dfsg-12
diff --git a/debian/changelog b/debian/changelog
index 35b4b87d7..6ddf7e440 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+opencv (4.6.0+dfsg-12) unstable; urgency=medium
+
+ * Team upload.
+
+ [ Andreas Beckmann ]
+ * libopencv-core406: Add Breaks: libopencv-core4.5 for smoother upgrades
from bullseye
+(Closes: #1035886)
+
+ [ Jochen Sprickerhof ]
+ * Add upstream patches for CVE-2023-2617 and CVE-2023-2618 (Closes: #1035954)
+
+ -- Jochen Sprickerhof Fri, 12 May 2023 11:40:38 +0200
+
opencv (4.6.0+dfsg-11) unstable; urgency=medium
* Update d/rules.
diff --git a/debian/control b/debian/control
index 4b6a4c095..421f0eb14 100644
--- a/debian/control
+++ b/debian/control
@@ -168,6 +168,7 @@ Section: libs
Depends: ${misc:Depends},
${shlibs:Depends}
Pre-Depends: ${misc:Pre-Depends}
+Breaks: libopencv-core4.5 (<< 4.6),
Description: computer vision core library
This package contains the OpenCV (Open Computer Vision) core runtime
libraries.
.
diff --git a/debian/gbp.conf b/debian/gbp.conf
index b5d1dad92..f2905a065 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,3 +1,5 @@
+[DEFAULT]
+component = contrib
+
[import-orig]
pristine-tar = True
-component = contrib
diff --git
a/debian/patches/0009-fix-wechat_qrcode-Init-nBytes-after-the-count-value-.patch
b/debian/patches/0009-fix-wechat_qrcode-Init-nBytes-after-the-count-value-.patch
new file mode 100644
index 0..879403e4b
--- /dev/null
+++
b/debian/patches/0009-fix-wechat_qrcode-Init-nBytes-after-the-count-value-.patch
@@ -0,0 +1,84 @@
+From: Nano
+Date: Wed, 26 Apr 2023 15:09:52 +0800
+Subject: fix(wechat_qrcode): Init nBytes after the count value is determined
+ (#3480)
+
+* fix(wechat_qrcode): Initialize nBytes after the count value is determined
+
+* fix(wechat_qrcode): Incorrect count data repair
+
+* chore: format expr
+
+* fix(wechat_qrcode): Avoid null pointer exception
+
+* fix(wechat_qrcode): return when bytes_ is empty
+
+* test(wechat_qrcode): add test case
+
+-
+
+Co-authored-by: GZTime
+---
+ .../src/zxing/qrcode/decoder/decoded_bit_stream_parser.cpp | 13 +
+ contrib/modules/wechat_qrcode/test/test_qrcode.cpp | 11 +++
+ 2 files changed, 20 insertions(+), 4 deletions(-)
+
+diff --git
a/contrib/modules/wechat_qrcode/src/zxing/qrcode/decoder/decoded_bit_stream_parser.cpp
b/contrib/modules/wechat_qrcode/src/zxing/qrcode/decoder/decoded_bit_stream_parser.cpp
+index 05de793..b3a0a69 100644
+---
a/contrib/modules/wechat_qrcode/src/zxing/qrcode/decoder/decoded_bit_stream_parser.cpp
b/contrib/modules/wechat_qrcode/src/zxing/qrcode/decoder/decoded_bit_stream_parser.cpp
+@@ -65,7 +65,8 @@ void DecodedBitStreamParser::append(std::string& result,
string const& in,
+
+ void DecodedBitStreamParser::append(std::string& result, const char* bufIn,
size_t nIn,
+ ErrorHandler& err_handler) {
+-if (err_handler.ErrCode()) return;
++// avoid null pointer exception
++if (err_handler.ErrCode() || bufIn == nullptr) return;
+ #ifndef NO_ICONV_INSIDE
+ if (nIn == 0) {
+ return;
+@@ -190,16 +191,20 @@ void
DecodedBitStreamParser::decodeByteSegment(Ref bits_, string& res
+CharacterSetECI*
currentCharacterSetECI,
+ArrayRef >&
byteSegments,
+ErrorHandler& err_handler) {
+-int nBytes = count;
+ BitSource& bits(*bits_);
+ // Don't crash trying to read more bits than we have available.
+ int available = bits.available();
+
Bug#1035987: unblock: ros-ros-comm/1.15.15+ds-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: ros-ros-c...@packages.debian.org Control: affects -1 + src:ros-ros-comm Please unblock package ros-ros-comm [ Reason ] python3-rospy extends the Python logging system with it's own API, overwriting the findCaller() function to get the filename and line number where the logging function was called. This broke with Python 3.11, resulting in a dead lock and I fixed it by importing the Python 3.11 function back then. While this worked in a simple case, it showed the wrong source code location when logging was called inside a submodule. The new version in 1.15.15+ds-2 uses the code from ros-ros-comm again, only fixing the deadlock. This is done with two changes: 1. The while hasattr(f, "f_code") looping over the stack, gains a break once there is no more f.f_back to fix the deadlock. 2. The test to find "the right frame" does no longer work with 3.11 as the stack is different. Instead it is identified by the name "_base_logger", as it is used by the code later anyhow. [ Impact ] Wrong filenames and line numbers in logs. [ Tests ] Unit test that the function does not fail, manual tests that it returns the correct value in different cases. [ Risks ] Minimal risk, the original code is part of the project for a long time and the changes are minimal and make sure that it always terminates. The only problem could be that it still prints the wrong value which would be unfortunate but not a big problem as it is used for debugging only. [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in testing [ Other info ] This was reported outside of Debian, thus no bug number. unblock ros-ros-comm/1.15.15+ds-2 diff --git a/debian/changelog b/debian/changelog index acd2cae..5193a76 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +ros-ros-comm (1.15.15+ds-2) unstable; urgency=medium + + * Properly fix rospy logging in Python 3.11 + + -- Jochen Sprickerhof Wed, 10 May 2023 12:27:48 +0200 + ros-ros-comm (1.15.15+ds-1) unstable; urgency=medium * New upstream version 1.15.15+ds diff --git a/debian/patches/0015-rosgraph-update-code-from-Python-3.11.patch b/debian/patches/0015-rosgraph-update-code-from-Python-3.11.patch index dc20fa5..975aca1 100644 --- a/debian/patches/0015-rosgraph-update-code-from-Python-3.11.patch +++ b/debian/patches/0015-rosgraph-update-code-from-Python-3.11.patch @@ -3,102 +3,27 @@ Date: Sun, 13 Nov 2022 16:39:59 +0100 Subject: rosgraph: update code from Python 3.11 --- - tools/rosgraph/src/rosgraph/roslogging.py | 72 --- - 1 file changed, 47 insertions(+), 25 deletions(-) + tools/rosgraph/src/rosgraph/roslogging.py | 7 +++ + 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/tools/rosgraph/src/rosgraph/roslogging.py b/tools/rosgraph/src/rosgraph/roslogging.py -index 9ecc121..0a94b2b 100644 +index 9ecc121..2df2f22 100644 --- a/tools/rosgraph/src/rosgraph/roslogging.py +++ b/tools/rosgraph/src/rosgraph/roslogging.py -@@ -50,32 +50,58 @@ from rospkg.environment import ROS_LOG_DIR - class LoggingException(Exception): pass - - class RospyLogger(logging.getLoggerClass()): --def findCaller(self, *args, **kwargs): -+# copied from python3.11/logging/__init__.py -+# _srcfile is only used in conjunction with sys._getframe(). -+# Setting _srcfile to None will prevent findCaller() from being called. This -+# way, you can avoid the overhead of fetching caller information. -+ -+# The following is based on warnings._is_internal_frame. It makes sure that -+# frames of the import mechanism are skipped when logging at module level and -+# using a stacklevel value greater than one. -+@staticmethod -+def _is_internal_frame(frame): -+"""Signal whether the frame is a CPython or logging module internal.""" -+filename = os.path.normcase(frame.f_code.co_filename) -+return filename == logging._srcfile or ( -+"importlib" in filename and "_bootstrap" in filename -+) -+ -+ -+def findCaller(self, stack_info=False, stacklevel=1): - """ - Find the stack frame of the caller so that we can note the source - file name, line number, and function name with class name if possible. - """ --file_name, lineno, func_name = super(RospyLogger, self).findCaller(*args, **kwargs)[:3] --file_name = os.path.normcase(file_name) -- --f = inspect.currentframe() --if f is not None: --f = f.f_back --while hasattr(f, "f_code"): +@@ -62,13 +62,12 @@ class RospyLogger(logging.getLoggerClass()): + if f is not None: + f = f.f_back
Bug#1034694: gnome-core: Cannot install due to pipewire-audio dependency
Hi Witold, can you please send the output of: sudo apt -o Debug::pkgProblemResolver=yes install gnome-core pipewire-audio should replace all of pulseaudio but there is probably a missing relation. Cheers Jochen * Witold Baryluk [2023-04-21 20:42]: Package: gnome-core Severity: grave Justification: renders package unusable X-Debbugs-Cc: witold.bary...@gmail.com Dear Maintainer, root@debian:~# sudo apt install gnome-core -V Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: gnome-core : Depends: pipewire-audio but it is not going to be installed E: Unable to correct problems, you have held broken packages. root@debian:~# -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'bookworm'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-rc7 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-core depends on: ii adwaita-icon-theme 43-1 ii at-spi2-core2.46.0-5 pn baobab pn dconf-cli ii dconf-gsettings-backend 0.40.0-4 pn eog pn evince pn evolution-data-server ii fonts-cantarell 0.303.1-1 pn gdm3 pn gkbd-capplet ii glib-networking 2.74.0-4 pn gnome-backgrounds pn gnome-bluetooth-sendto pn gnome-calculator pn gnome-characters pn gnome-contacts pn gnome-control-center pn gnome-disk-utility pn gnome-font-viewer ii gnome-keyring 42.1-1+b2 pn gnome-logs pn gnome-menus pn gnome-online-accounts pn gnome-session pn gnome-settings-daemon pn gnome-shell pn gnome-shell-extensions pn gnome-software pn gnome-sushi pn gnome-system-monitor pn gnome-terminal | gnome-console pn gnome-text-editor ii gnome-themes-extra 3.28-2 pn gnome-user-docs pn gnome-user-share ii gsettings-desktop-schemas 43.0-1 pn gstreamer1.0-packagekit ii gstreamer1.0-plugins-base 1.22.0-3 ii gstreamer1.0-plugins-good 1.22.0-5 ii gvfs-backends 1.50.3-1 ii gvfs-fuse 1.50.3-1 ii libatk-adaptor 2.46.0-5 ii libcanberra-pulse 0.30-10 ii libglib2.0-bin 2.74.6-2 ii libpam-gnome-keyring42.1-1+b2 pn libproxy1-plugin-gsettings pn libproxy1-plugin-webkit ii librsvg2-common 2.54.5+dfsg-1 pn nautilus pn pipewire-audio ii sound-theme-freedesktop 0.8-2 pn system-config-printer-common pn system-config-printer-udev pn totem pn tracker pn xdg-desktop-portal-gnome ii yelp42.2-1 ii zenity 3.44.0-1 Versions of packages gnome-core recommends: ii firefox-esr [gnome-www-browser] 102.10.0esr-1 pn libproxy1-plugin-networkmanager pn low-memory-monitor ii network-manager-gnome1.30.0-2 Versions of packages gnome-core suggests: pn gnome signature.asc Description: PGP signature
Bug#1035544: unblock: mrpt/1:2.5.8+ds-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: m...@packages.debian.org, José Luis Blanco-Claraco
Control: affects -1 + src:mrpt
Please unblock package mrpt
[ Reason ]
Wrong dependency from -dev to library package.
[ Impact ]
Broken symlink.
[ Tests ]
None.
[ Risks ]
None, d/control only change.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock mrpt/1:2.5.8+ds-2
diff -Nru mrpt-2.5.8+ds/debian/changelog mrpt-2.5.8+ds/debian/changelog
--- mrpt-2.5.8+ds/debian/changelog 2023-01-07 19:54:26.0 +0100
+++ mrpt-2.5.8+ds/debian/changelog 2023-05-04 07:27:09.0 +0200
@@ -1,3 +1,9 @@
+mrpt (1:2.5.8+ds-2) unstable; urgency=medium
+
+ * d/control: Fix wrong dependency in libmrpt-vision-lgpl (Closes: #1035446)
+
+ -- Jose Luis Blanco Claraco Thu, 04 May 2023
07:27:09 +0200
+
mrpt (1:2.5.8+ds-1) unstable; urgency=medium
* New upstream version 2.5.8+ds
diff -Nru mrpt-2.5.8+ds/debian/control mrpt-2.5.8+ds/debian/control
--- mrpt-2.5.8+ds/debian/control2023-01-07 19:54:26.0 +0100
+++ mrpt-2.5.8+ds/debian/control2023-05-04 07:27:09.0 +0200
@@ -929,7 +929,7 @@
Multi-Arch: same
Breaks: libmrpt-dev (<< 1:2)
Replaces: libmrpt-dev (<< 1:2)
-Depends: ${misc:Depends},libmrpt-vision2.5 (= ${binary:Version}),
+Depends: ${misc:Depends},libmrpt-vision-lgpl2.5 (= ${binary:Version}),
libmrpt-vision-dev
Description: ${source:Synopsis} - vision-lgpl development package
${source:Extended-Description}
Bug#1034694: gnome-core: Cannot install due to pipewire-audio dependency
Hi Witold, The friendly people in #debian-apt proposed to run: sudo apt install -o Debug::pkgProblemResolver=true -o Debug::pkgDepCache::Marker=1 -o Debug::pkgDepCache::AutoInstall=1 gnome-core And could you also send your /var/lib/dpkg/status file? More information on this: https://salsa.debian.org/apt-team/apt#debugging Thanks! Jochen * Witold Baryluk [2023-05-08 19:02]: Package: gnome-core Version: 1:43+1 Followup-For: Bug #1034694 X-Debbugs-Cc: witold.bary...@gmail.com Here: root@debian:~# sudo apt -V --simulate remove pulseaudio Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: bind9-host (1:9.18.12-1) bind9-libs (1:9.18.12-1) libfstrm0 (0.6.1-1) libjemalloc2 (5.3.0-1) libmaxminddb0 (1.7.1-1) libprotobuf-c1 (1.4.1-1+b1) libuv1 (1.44.2-1) Use 'sudo apt autoremove' to remove them. The following additional packages will be installed: liblua5.3-0 (5.3.6-2) libpipewire-0.3-modules (0.3.65-3) libwireplumber-0.4-0 (0.4.13-1) pipewire (0.3.65-3) pipewire-bin (0.3.65-3) pipewire-pulse (0.3.65-3) wireplumber (0.4.13-1) Suggested packages: libspa-0.2-bluetooth (0.3.65-3) wireplumber-doc (0.4.13-1) The following packages will be REMOVED: libcanberra-pulse (0.30-10) pulseaudio (16.1+dfsg1-2+b1) The following NEW packages will be installed: liblua5.3-0 (5.3.6-2) libpipewire-0.3-modules (0.3.65-3) libwireplumber-0.4-0 (0.4.13-1) pipewire (0.3.65-3) pipewire-bin (0.3.65-3) pipewire-pulse (0.3.65-3) wireplumber (0.4.13-1) 0 upgraded, 7 newly installed, 2 to remove and 0 not upgraded. Remv libcanberra-pulse [0.30-10] Remv pulseaudio [16.1+dfsg1-2+b1] Inst liblua5.3-0 (5.3.6-2 Debian:testing [amd64]) Inst libpipewire-0.3-modules (0.3.65-3 Debian:testing [amd64]) Inst libwireplumber-0.4-0 (0.4.13-1 Debian:testing [amd64]) Inst pipewire-bin (0.3.65-3 Debian:testing [amd64]) Inst pipewire (0.3.65-3 Debian:testing [amd64]) Inst pipewire-pulse (0.3.65-3 Debian:testing [amd64]) Inst wireplumber (0.4.13-1 Debian:testing [amd64]) Conf liblua5.3-0 (5.3.6-2 Debian:testing [amd64]) Conf libpipewire-0.3-modules (0.3.65-3 Debian:testing [amd64]) Conf libwireplumber-0.4-0 (0.4.13-1 Debian:testing [amd64]) Conf pipewire-bin (0.3.65-3 Debian:testing [amd64]) Conf pipewire (0.3.65-3 Debian:testing [amd64]) Conf pipewire-pulse (0.3.65-3 Debian:testing [amd64]) Conf wireplumber (0.4.13-1 Debian:testing [amd64]) root@debian:~# Regards, Witold signature.asc Description: PGP signature
Bug#1063516: transition: pcl
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: p...@packages.debian.org Control: affects -1 + src:pcl Hi release team, I would like to transition to the new pcl version. The auto generated ben file looks fine and the reverse build dependency builds fine. Cheers Jochen
Bug#1063677: experimental version does not sho binNMU changelogs
Package: apt-listchanges Version: 4.4 Severity: normal As title says. -- Package-specific info: ==> /etc/apt/listchanges.conf <== [apt] frontend=pager which=news email_address=root email_format=text confirm=false headers=false reverse=false save_seen=/var/lib/apt/listchanges capture_snapshots=auto snapshot_dir=/var/lib/apt/listchanges-snapshots ==> /etc/apt/listchanges.conf.d/jo-tools.conf <== [apt] which=both email_address=none headers=true reverse=true no_network=false -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-listchanges depends on: ii apt2.7.10 ii debconf [debconf-2.0] 1.5.85 ii python33.11.6-1 ii python3-apt2.7.5 ii python3-debconf1.5.85 ii sensible-utils 0.0.22 ii ucf3.0043+nmu1 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii chromium [www-browser] 121.0.6167.160-1 pn default-mta | mail-transport-agent ii firefox [www-browser] 122.0.1-1 ii lynx [www-browser] 2.9.0rel.0-2 ii python3-gi 3.46.0-3 ii w3m [www-browser] 0.5.3+git20230121-2+b2 pn x-terminal-emulator -- debconf information: * apt-listchanges/frontend: pager * apt-listchanges/confirm: false * apt-listchanges/email-format: text * apt-listchanges/headers: false * apt-listchanges/email-address: root * apt-listchanges/no-network: false * apt-listchanges/save-seen: true * apt-listchanges/reverse: false * apt-listchanges/which: news
Bug#1063777: Error: pg_wrapper: pgbench was not found in /usr/lib/postgresql/16/bin
Package: postgresql-client Version: 16+257 Severity: normal Hi Christoph, on a fresh system: # apt install postgresql-client $ pgbench Error: pg_wrapper: pgbench was not found in /usr/lib/postgresql/16/bin The executable is in postgresql-16. So I would propose to either move /usr/bin/pgbench to postgresql or /usr/lib/postgresql/16/bin/pgbench to postgresql-client-16. Cheers Jochen -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages postgresql-client depends on: ii postgresql-client-16 16.2-1 postgresql-client recommends no packages. postgresql-client suggests no packages. -- no debconf information
Bug#1063410: ros-bloom's autopkg tests fail with Python 3.12
Control: tag -1 moreinfo Hi Matthias, * Matthias Klose [2024-02-07 20:55]: Package: src:ros-bloom Version: 0.11.2-6 Severity: important Tags: sid trixie ftbfs User: debian-pyt...@lists.debian.org Usertags: python3.12 ros-bloom's autopkg tests fail with Python 3.12 [...] 578s /usr/lib/python3/dist-packages/rosdistro/distribution.py:35: in 578s from .manifest_provider.git import git_manifest_provider, git_source_manifest_provider 578s /usr/lib/python3/dist-packages/rosdistro/manifest_provider/git.py:44: in 578s from rosdistro.vcs import Git, ref_is_hash 578s /usr/lib/python3/dist-packages/rosdistro/vcs.py:39: in 578s from distutils.version import LooseVersion 578s E ModuleNotFoundError: No module named 'distutils' This looks like the same as #1061840 and was already fixed in ros-bloom and ros-rosdistro. Can you please retry with the versions in testing? I can't reproduce this and debci is also all green. Cheers Jochen signature.asc Description: PGP signature
Bug#1056866: python-pcl: ftbfs with cython 3.0.x
Hi Bas, * Sebastiaan Couwenberg [2023-12-10 12:22]: Control: tags -1 patch On Sun, 26 Nov 2023 10:06:32 + Matthias Klose wrote: If the package cannot be built with cython 3.0.5, please change the build dependency from cython3 to cython3-legacy (available now in unstable). There is no replacement for cython3-dbg. The attached patch switches to cython3-legacy as the short term workaround. Feel free to NMU (or team upload) python-pcl. Honestly I'm thinking of removing it form the archive as upstream is no longer maintained and I don't have a use anymore either (it also has a low popcon and no rdeps). Do you want to maintain it? Cheers Jochen signature.asc Description: PGP signature
Bug#1042244: Bug#1056419: [Help] Re: python-future: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
Hi Andreas, * Andreas Tille [2023-12-11 16:42]: Control: tags -1 help [Bug #1056419 in CC since the issue seems to be caused by python-future] Hi Vincent, I tried to upgrade python-future to the latest upstream version in the hope that this would solve the issue reported in bug #1042244. Unfortunately this is not the case and now with Python3.12 we also have to deal with the removal of imp (which affects bug #1056419). I'd like to ask for help on debian-python list since I'm pretty overworked with other stuff. Please also review my rude patch[1] to hack around a shinx issue. It would be great to have some better solution here. You can find a full build log of the latest upstream version in Salsa CI[2]. I think the right thing here is to package the new uncertainties version which drops the past import: https://github.com/lebigot/uncertainties/releases/tag/3.1.7 Also we should probably get rid of python-future at some point. Cheers Jochen signature.asc Description: PGP signature
Bug#1057977: RM: python-pcl -- ROM; no longer maintained upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-...@packages.debian.org Control: affects -1 + src:python-pcl ..also now rdeps, low popcon and FTBFS.
Bug#999989: poco 1.2 uses PCRE2, Mumble 1.5 depends on poco
* Chris Knadle [2024-01-02 16:53]: The way to orphan a package is to do an upload and setting the maintainer to be . Until that's done the package ends up in maintainership limbo. See the bottom of Policy 3.3, and Developer's Reference section 5.9.4. Agreed but I think that is something for the Maintainer: to do, who seems to be active in Debian, otherwise. I may be able to prepare an updated version to upload as an NMU (i.e. it would be Debian version 1.13.0-0.1), but I can't take over maintaining this package long-term because I don't use it and am not familiar with it -- I only maintain a package that has it as a required build dependency. I also haven't maintained a library yet, but I've been in this situation of needing to upload a newer version of a library before so I might be able to figure out what's required to prepare an upload. It would be interesting to upload a new version as an NMU with the maintainer marked as but strangely that seems to be what's called for here. Feel free to ask if you have questions regarding maintaining a library. Cheers Jochen signature.asc Description: PGP signature
Bug#1041275: sbuild: Using eatmydata with the unshare backend
Hi Andrea, * Andrea Pappacoda [2023-07-16 21:35]: One thing that is a bit less nice than schroot, though, is the inability of the unshare backend to use eatmydata to speed up package builds. Not only speed, but I also fear that continuous (and unnecessary) disk writes may degrade my disk's lifespan ever so slightly. Is there a way possible to use eatmydata with the unshare backend? So far I tried to start the build with `eatmydata sbuild`, but it doesn't seem to work. The eatmydata package is installed in the tarball. Given enough RAM you can use a tmpfs like this: $unshare_tmpdir_template = '/dev/shm/tmp.sbuild.XX'; According to my tests that was even faster then eatmydata (and adding eatmydata did not improve it. Cheers Jochen signature.asc Description: PGP signature
Bug#999989: poco 1.1 uses PCRE3, Mumble 1.5 depends on poco
* Chris Knadle [2024-01-07 00:29]: The main thing I'd like to understand is how to do coordinate the transition (i.e. the release) with the Release Team. I found some hints about that here: https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#lib-trans The wiki page linked there seems correct. Please ask if you have more specific questions. There is also Debian Mentors to help: https://wiki.debian.org/DebianMentors Cheers Jochen signature.asc Description: PGP signature
Bug#1057867: Acknowledgement (python-matrix-nio: New version 0.23 available)
Hi Martin, * Martin [2024-01-07 10:52]: Dears, would you mind an NMU 0.23-0.1? I prepared it for my own use anyway, so it's no extra-work for me. The new version needs jsonschema = "^4.14.0" which is only in experimental and blocked by #1055516. Did you find a work around for that? Cheers Jochen signature.asc Description: PGP signature
Bug#1057867: Acknowledgement (python-matrix-nio: New version 0.23 available)
* Martin [2024-01-08 09:05]: To me, it looks like the package builds and works with both jsonschema 4.10.3-1 and 4.19.2-1, despite the version in pyproject.toml. But maybe I'm just lucky with my use case? Looks like there was no real need to bump the version. I've uploaded a new package to unstable. Cheers Jochen signature.asc Description: PGP signature
Bug#999989: poco 1.2 uses PCRE2, Mumble 1.5 depends on poco
Hi Chris, * Chris Knadle [2024-01-02 03:06]: Can the poco library be updated? Can I help in some way? poco is basically orphaned, as I dropped myself from Uploaders in git and did not hear from the other maintainers for some time. The best way to help is to step up as a maintainer and update it ;). Unless the Poco library can be updated the only way to save Mumble will be to introduce an epoch in the package version to upload the now well outdated mumble 1.3.4 again which upstream cannot support anymore. Nit: please don't use epochs for that, also see Policy 5.6.12.1. Cheers Jochen signature.asc Description: PGP signature
Bug#1056385: in unshare mode, ischroot returns false
Hi josch, * Johannes Schauer Marin Rodrigues [2023-11-22 07:22]: steps to reproduce: --chroot-setup-commands='ischroot && echo "is chroot" || echo "is not chroot" in contrast to mmdebstrap unshare mode, the contents of /proc/1/mountinfo and /proc/self/mountinfo are the same in sbuild. See https://sources.debian.org/src/debianutils/latest/ischroot.c/ The difference is due to mmdebstrap opening a extra namespace here: https://sources.debian.org/src/mmdebstrap/1.4.0-1/mmdebstrap/#L1707 I tried to adding an unshare --mount to sbuild here but did not manage: https://sources.debian.org/src/sbuild/0.85.4/lib/Sbuild/ChrootUnshare.pm/#L324 Maybe you have an idea where to put it? While at it I also researched a bit into ischroot: # How does ischroot work: ischroot assumes that a chroot changes the mountinfo file and that the one of PID 1 is not chrooted. This is true for a chroot set up by schroot for example. sbuild+unshare instead also mounts a new proc and thus it is becoming PID 1, or rather the runuser in ChrootUnshare.pm. So one way around this would be to mount the outside proc, as in: - mount -t proc proc \"\$rootdir/proc\"; + mount -o rbind /proc \"\$rootdir/proc\"; in: https://sources.debian.org/src/sbuild/0.85.4/lib/Sbuild/ChrootUnshare.pm/#L323 But that means that the package build in sbuild can list outside processes which seems suboptimal. # How is ischroot used I looked at the results at: https://codesearch.debian.net/search?q=ischroot And it is used rather seldom (besides some testing code): https://codesearch.debian.net/search?q=ischroot+package%3A%5CQdebootstrap%5CE https://codesearch.debian.net/search?q=ischroot+package%3A%5CQglibc%5CE https://codesearch.debian.net/search?q=ischroot+package%3A%5CQsysvinit%5CE https://codesearch.debian.net/search?q=ischroot+package%3A%5CQcdist%5CE https://codesearch.debian.net/search?q=ischroot+package%3A%5CQmini-buildd%5CE mini-buildd btw. also uses systemd-detect-virt as an alternative (though not with --chroot). And there is at least one package that does the same as ischroot manually: https://codesearch.debian.net/search?q=ischroot+package%3A%5CQsalt%5CE On the other hand it considered second-class in debianutils: https://sources.debian.org/src/debianutils/5.14/CONTRIBUTING/?hl=28#L28 So maybe it should be replaced by systemd-detect-virt but that compares the inodes of /proc/1/root and / which seems even more brittle as /proc/1/root is not readable by everyone and seems to have the same issues as ischroot, otherwise. # telinit behaviour From #debian-bootstrap I understood that this is actually an issue during cross compiling something when `libc6.postinst configure` is called resulting in an endless loop of telinit. There are two implementations of telinit in Debian. The one in sysvinit-core does not seem to trigger this behaviour, whereas the one in systemd-sysv does seems to wait forever. On the other hand telinit(8) from systemd-sysv states that it should not be used anymore. So maybe libc6.postinst should use a different interface and/or do something else to check if PID 1 is actually an init? Or should sbuild run some init as PID 1? Cheers Jochen signature.asc Description: PGP signature
Bug#1056385: in unshare mode, ischroot returns false
* Johannes Schauer Marin Rodrigues [2023-11-24 20:57]: this is is only invoked for --chrooted-*-hooks but CLONE_NEWNS is also what mmdebstrap unshares by default here: Ah, I only tested with your: --chroot-setup-commands='ischroot && echo "is chroot" || echo "is not chroot" Example. This is already done here: https://sources.debian.org/src/sbuild/0.85.4/lib/Sbuild/ChrootUnshare.pm/#L279 What made you think that CLONE_NEWNS was responsible? It should be unshared for both sbuild and mmdebstrap hooks. I think it is due to mmdebstrap having extra process and maybe doing the CLONE_NEWNS in a different process? Since the problem does not happen with mmdebstrap, I think this might just be a bug in sbuild. I also suspect that your thoughts about PID 1 go into the right direction because sbuild and mmdebstrap set up the unshared processes slightly differently. Look at the complex dance of processes that mmdebstrap does: https://sources.debian.org/src/mmdebstrap/1.4.0-1/mmdebstrap/#L486 I think that is part of why it works with mmdebstrap. Compare: $ sbuild -d unstable --starting-build-commands='ps auxf' --add-depends=procps hello USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 4536 2816 ?S+ 20:17 0:00 /sbin/runuser -u root -- sh -c cd "$1" && shift && "$@" -- /build/package /bin/sh -c ps auxf root 41 0.0 0.0 2580 1408 ?S+ 20:17 0:00 sh -c cd "$1" && shift && "$@" -- /build/package /bin/sh -c ps auxf root 42 0.0 0.0 2580 1408 ?S+ 20:17 0:00 \_ /bin/sh -c ps auxf root 43 0.0 0.0 8116 4096 ?R+ 20:17 0:00 \_ ps auxf and: $ mmdebstrap --chrooted-customize-hook='ps auxf' --variant=essential --include=procps unstable /dev/null USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 1 0.5 0.1 32616 25252 ?S+ 20:15 0:00 /usr/bin/perl /usr/bin/mmdebstrap --chrooted-customize-hook=ps auxf --variant=essential --include=procps unstable /dev/null root1716 0.0 0.1 32616 23956 ?S+ 20:15 0:00 /usr/bin/perl /usr/bin/mmdebstrap --chrooted-customize-hook=ps auxf --variant=essential --include=procps unstable /dev/null root1717 0.0 0.0 2580 1536 ?S+ 20:15 0:00 \_ sh -c ps auxf root1718 0.0 0.0 8116 3968 ?R+ 20:15 0:00 \_ ps auxf And note that for mmdebstrap PID 1 has a different mountinfo as PID 1716 and below. Cheers Jochen signature.asc Description: PGP signature
Bug#1061771: Can't hear other people on meet.google.com
Package: chromium Version: 121.0.6167.85-1 Severity: normal Hi, I can't hear others on meet.google.com, though I hear the connected ping and others seem to hear me as well. Also Jitsi works. Downgrading to the version in testing makes it work again. Cheers Jochen -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common121.0.6167.85-1 ii libasound2 1.2.10-3 ii libatk-bridge2.0-0 2.50.0-1+b1 ii libatk1.0-02.50.0-1+b1 ii libatomic1 14-20240127-1 ii libatspi2.0-0 2.50.0-1+b1 ii libc6 2.37-14 ii libcairo2 1.18.0-1+b1 ii libcups2 2.4.7-1+b1 ii libdbus-1-31.14.10-4 ii libdouble-conversion3 3.3.0-1+b1 ii libdrm22.4.120-1 ii libevent-2.1-7 2.1.12-stable-8 ii libexpat1 2.5.0-2+b2 ii libflac12 1.4.3+ds-2+b1 ii libfontconfig1 2.14.2-6+b1 ii libfreetype6 2.13.2+dfsg-1+b1 ii libgbm123.3.4-1 ii libgcc-s1 14-20240127-1 ii libglib2.0-0 2.78.3-2 ii libgtk-3-0 3.24.40-2 ii libjpeg62-turbo1:2.1.5-2+b2 ii libjsoncpp25 1.9.5-6+b2 ii liblcms2-2 2.14-2 ii libminizip11:1.3.dfsg-3+b1 ii libnspr4 2:4.35-1.1 ii libnss32:3.96.1-1 ii libopenh264-7 2.4.0+dfsg-1 ii libopenjp2-7 2.5.0-2+b2 ii libopus0 1.4-1 ii libpango-1.0-0 1.51.0+ds-4 ii libpng16-161.6.40-3 ii libpulse0 16.1+dfsg1-3 ii libsnappy1v5 1.1.10-1 ii libstdc++6 14-20240127-1 ii libwebp7 1.3.2-0.3 ii libwebpdemux2 1.3.2-0.3 ii libwebpmux31.3.2-0.3 ii libwoff1 1.0.2-2 ii libx11-6 2:1.8.7-1 ii libxcb11.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage11:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxkbcommon0 1.6.0-1 ii libxml22.9.14+dfsg-1.3+b2 ii libxnvctrl0525.125.06-1 ii libxrandr2 2:1.5.2-2+b1 ii libxslt1.1 1.1.35-1 ii zlib1g 1:1.3.dfsg-3+b1 Versions of packages chromium recommends: ii chromium-sandbox 121.0.6167.85-1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii libc6 2.37-14 ii libjsoncpp25 1.9.5-6+b2 ii libstdc++614-20240127-1 ii libx11-6 2:1.8.7-1 ii libxnvctrl0 525.125.06-1 ii x11-utils 7.7+6 ii xdg-utils 1.1.3-4.1 ii zlib1g1:1.3.dfsg-3+b1 Versions of packages chromium-common recommends: ii chromium-sandbox 121.0.6167.85-1 ii fonts-liberation 1:2.1.5-3 ii libgl1-mesa-dri23.3.4-1 pn libu2f-udev pn notification-daemon pn system-config-printer pn upower Versions of packages chromium-sandbox depends on: ii libc6 2.37-14 -- no debconf information
Bug#1061365: RM: ros-python-qt-binding -- ROM; No longer used in Debian and depends on broken sip4
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ros-python-qt-bind...@packages.debian.org Control: affects -1 + src:ros-python-qt-binding
Bug#1061363: RM: ros-rosinstall -- ROM; deprecated upstream in favour of vcstool
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ros-rosinst...@packages.debian.org Control: affects -1 + src:ros-rosinstall
Bug#1061364: RM: ros-wstool -- ROM; deprecated upstream in favour of vcstool
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ros-wst...@packages.debian.org Control: affects -1 + src:ros-wstool
Bug#1056070: hibiscus: Please package new version
Hi Tony, * tony mancill [2023-11-18 12:18]: Since this is a team-maintained package, I prepared an update; no packaging changes required. I have uploaded it to DELAYED-5 out of deference to Jochen, who has performed all of the uploads prior to now. Jochen, let me know if you would like me to dcut my upload. Otherwise, I will the push the updated branches to the packaging repo. Thanks for working on it! Did you also update hbci4java to the version used by hibiscus? If yes, then feel free change the delay to 0. Otherwise I can take care of both in the next days. Cheers Jochen signature.asc Description: PGP signature
Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions
Hi Jörg, is there anything I can help with to get libhx updated? (I agree with what Tobias said below.) Cheers Jochen * Tobias Frost [2024-03-17 20:22]: Control: tags -1 moreinfo On Sun, Mar 17, 2024 at 04:57:54PM +0100, Jörg Frings-Fürst wrote: tags 1065193 - moreinfo thanks Hi Tobias, Am Sonntag, dem 17.03.2024 um 14:39 +0100 schrieb Tobias Frost: > Hi Jörg, > > "debcheckout libhx" still gives me 4.17-1 as head. > > After looking at your repo, I think I should point you to DEP-14 > as a recommended git layout for packaging. > As the branch name indicates you are using per-package-revision > branches: > IMHO It makes little sense to have one branch per debian package > version/revision; (I had a similiar discussion on vzlogger lately, > so to avoid repetiions: #1064344#28) > > Please clarify how you want to manage the package in git, as > this needs to be reflected in d/control's VCS-* fields correctly. > (this is now blocking the upload.) I have been using Vincent Driessen's branching model and the corresponding git extension gitflow-avh for at least 7 years with Debian and for a long time at work. The default branch is master and development takes place in the develop branch. The release candidates are managed in the branch release. The extension debian/debian-version is used as a tag during the transfer. The master branch always contains the last published executable version to which the git tag in debian/control points. a> The procedure is described in the README.debian. ok, won't further argue about how to organize your git repo, but I can only tell the Debian perspective: It is breaking expectations as a debcheckout libhx does today NOT give me a state that represents the package in unstable. VCS-Git specifies where the (package) development is happening [1]. [1] Policy 5.6.26 But as I am not using the git repo as base for the sponsoring, lets put that topic to rest. > > (The current fields say the package is maintained in the default branch > of your repo. I see a debian/ directory there, but that one is missing > released (it is at 4.17-1, while unstable is at 4.19-1.1) > > The review is based on the .dsc, timestamped on mentors.d.n > 2024-03-17 12:00 > > d/changelog is *STILL* changing history for the 4.19-1 changelog > block. (This issue must be fixed before upload.) > I think these were artifacts because my changes to the NMU were not adopted. Has been corrected. No it has not. I expect old changelog entries to be *identical* to the ones that have been uploaded, and they still are not, so I fear we are talking past each other. Please let me know what you think that you have fixed, so that we can spot the different expectations. For my perspective: This is the diff from debian/changelog from the current version in the archives and the dsc uploaded to mentors at 2024-03-17 14:45 You are still rewriting history (second hunk of this diff), this hunk should not exists. diff -Naur archive/libhx-4.19/debian/changelog mentors/libhx-4.23/debian/changelog --- archive/libhx-4.19/debian/changelog 2024-02-28 13:48:09.0 +0100 +++ mentors/libhx-4.23/debian/changelog 2024-03-17 15:23:31.0 +0100 @@ -1,3 +1,17 @@ +libhx (4.23-1) unstable; urgency=medium + + * New upstream release (Closes: #1064734). + * Add debian/.gitignore + * Remove not longer needed debian/libhx-dev.lintian-overrides. + * Fix debian/libhx32t64.lintian-overrides. + * debian/copyright: +- Add 2024 to myself. + * debian/control: +- Readd BD dpkg-dev (>= 1.22.5). + Thanks to Tobias Frost + + -- Jörg Frings-Fürst Sun, 17 Mar 2024 15:23:31 +0100 + libhx (4.19-1.1) unstable; urgency=medium * Non-maintainer upload. @@ -9,11 +23,8 @@ * New upstream release. - Refresh symbols files. - * Remove empty debian/libhx-dev.symbols. - * debian/rules: -- Remove build of libhx-dev.symbols. - -- Jörg Frings-Fürst Sun, 17 Dec 2023 14:44:39 +0100 + -- Jörg Frings-Fürst Tue, 21 Nov 2023 10:41:07 +0100 libhx (4.14-1) unstable; urgency=medium signature.asc Description: PGP signature
Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions
Hi Jörg, I have fixed the old debian/changelog entry and uploaded the new version to DELAYED/7. Please feel free to tell me if I should delay it longer. The patch is attached. Cheers Jochen * Jochen Sprickerhof [2024-04-10 07:25]: Hi Jörg, is there anything I can help with to get libhx updated? (I agree with what Tobias said below.) Cheers Jochen * Tobias Frost [2024-03-17 20:22]: Control: tags -1 moreinfo On Sun, Mar 17, 2024 at 04:57:54PM +0100, Jörg Frings-Fürst wrote: tags 1065193 - moreinfo thanks Hi Tobias, Am Sonntag, dem 17.03.2024 um 14:39 +0100 schrieb Tobias Frost: Hi Jörg, "debcheckout libhx" still gives me 4.17-1 as head. After looking at your repo, I think I should point you to DEP-14 as a recommended git layout for packaging. As the branch name indicates you are using per-package-revision branches: IMHO It makes little sense to have one branch per debian package version/revision; (I had a similiar discussion on vzlogger lately, so to avoid repetiions: #1064344#28) Please clarify how you want to manage the package in git, as this needs to be reflected in d/control's VCS-* fields correctly. (this is now blocking the upload.) I have been using Vincent Driessen's branching model and the corresponding git extension gitflow-avh for at least 7 years with Debian and for a long time at work. The default branch is master and development takes place in the develop branch. The release candidates are managed in the branch release. The extension debian/debian-version is used as a tag during the transfer. The master branch always contains the last published executable version to which the git tag in debian/control points. a> The procedure is described in the README.debian. ok, won't further argue about how to organize your git repo, but I can only tell the Debian perspective: It is breaking expectations as a debcheckout libhx does today NOT give me a state that represents the package in unstable. VCS-Git specifies where the (package) development is happening [1]. [1] Policy 5.6.26 But as I am not using the git repo as base for the sponsoring, lets put that topic to rest. (The current fields say the package is maintained in the default branch of your repo. I see a debian/ directory there, but that one is missing released (it is at 4.17-1, while unstable is at 4.19-1.1) The review is based on the .dsc, timestamped on mentors.d.n 2024-03-17 12:00 d/changelog is *STILL* changing history for the 4.19-1 changelog block. (This issue must be fixed before upload.) I think these were artifacts because my changes to the NMU were not adopted. Has been corrected. No it has not. I expect old changelog entries to be *identical* to the ones that have been uploaded, and they still are not, so I fear we are talking past each other. Please let me know what you think that you have fixed, so that we can spot the different expectations. For my perspective: This is the diff from debian/changelog from the current version in the archives and the dsc uploaded to mentors at 2024-03-17 14:45 You are still rewriting history (second hunk of this diff), this hunk should not exists. diff -Naur archive/libhx-4.19/debian/changelog mentors/libhx-4.23/debian/changelog --- archive/libhx-4.19/debian/changelog 2024-02-28 13:48:09.0 +0100 +++ mentors/libhx-4.23/debian/changelog 2024-03-17 15:23:31.0 +0100 @@ -1,3 +1,17 @@ +libhx (4.23-1) unstable; urgency=medium + + * New upstream release (Closes: #1064734). + * Add debian/.gitignore + * Remove not longer needed debian/libhx-dev.lintian-overrides. + * Fix debian/libhx32t64.lintian-overrides. + * debian/copyright: +- Add 2024 to myself. + * debian/control: +- Readd BD dpkg-dev (>= 1.22.5). + Thanks to Tobias Frost + + -- Jörg Frings-Fürst Sun, 17 Mar 2024 15:23:31 +0100 + libhx (4.19-1.1) unstable; urgency=medium * Non-maintainer upload. @@ -9,11 +23,8 @@ * New upstream release. - Refresh symbols files. - * Remove empty debian/libhx-dev.symbols. - * debian/rules: -- Remove build of libhx-dev.symbols. - -- Jörg Frings-Fürst Sun, 17 Dec 2023 14:44:39 +0100 + -- Jörg Frings-Fürst Tue, 21 Nov 2023 10:41:07 +0100 libhx (4.14-1) unstable; urgency=medium From e82f0d623be16aad21807a7a5089fbfdbbd8ba05 Mon Sep 17 00:00:00 2001 From: Jochen Sprickerhof Date: Sun, 21 Apr 2024 09:03:28 +0200 Subject: [PATCH] Fix old debian/changelog entry --- debian/changelog | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 5471467..e4c0c41 100644 --- a/debian/changelog +++ b/debian/changelog @@ -23,8 +23,11 @@ libhx (4.19-1) unstable; urgency=medium * New upstream release. - Refresh symbols files. + * Remove empty debian/libhx-dev.symbols. + * debian/rules: +- Remove build of libhx-dev.symbols. - -- Jörg Frings-Fürst Tue, 21 Nov 2023 10:41:07 +0100 + -- Jörg Frings-Fürst Sun, 17 Dec 2023 14:44:39 +0100 libhx (
Bug#1069803: php-codeigniter-framework tries pip install during build
Source: php-codeigniter-framework
Version: 3.1.13+dfsg1-3
Severity: serious
Tags: sid trixie ftbfs
php-codeigniter-framework accesses network resources during the build:
python3 -m venv --system-site-packages --without-pip debian/build-doc/pythonvenv
if ! debian/build-doc/pythonvenv/bin/python -m pip show pycilexer; then \
echo "Installing pycilexer" && \
cd user_guide_src/cilexer && \
../../debian/build-doc/pythonvenv/bin/python -m pip install .; \
fi
WARNING: Package(s) not found: pycilexer
Installing pycilexer
Processing /build/package/package/user_guide_src/cilexer
Installing build dependencies: started
Installing build dependencies: finished with status 'error'
error: subprocess-exited-with-error
× pip subprocess to install build dependencies did not run successfully.
│ exit code: 1
╰─> [7 lines of output]
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None,
status=None)) after connection broken by
'NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution')': /simple/setuptools/
WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None,
status=None)) after connection broken by
'NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution')': /simple/setuptools/
WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None,
status=None)) after connection broken by
'NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution')': /simple/setuptools/
WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None,
status=None)) after connection broken by
'NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution')': /simple/setuptools/
WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None,
status=None)) after connection broken by
'NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution')': /simple/setuptools/
ERROR: Could not find a version that satisfies the requirement
setuptools>=40.8.0 (from versions: none)
ERROR: No matching distribution found for setuptools>=40.8.0
[end of output]
note: This error originates from a subprocess, and is likely not a problem
with pip.
error: subprocess-exited-with-error
× pip subprocess to install build dependencies did not run successfully.
│ exit code: 1
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with
pip.
Bug#1069804: rust-mio-0.6 accesses network resources during the build
Source: rust-mio-0.6
Version: 0.6.23-3
Severity: serious
Tags: sid trixie ftbfs
rust-mio-0.6 accesses network resources during the build:
Test executable failed (exit status: 101).
stderr:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os {
code: 101, kind: NetworkUnreachable, message: "Network is unreachable" }',
src/sys/unix/ready.rs:22:16
stack backtrace:
0: rust_begin_unwind
at /usr/src/rustc-1.70.0/library/std/src/panicking.rs:578:5
1: core::panicking::panic_fmt
at /usr/src/rustc-1.70.0/library/core/src/panicking.rs:67:14
2: core::result::unwrap_failed
at /usr/src/rustc-1.70.0/library/core/src/result.rs:1687:5
3: core::result::Result::unwrap
4: rust_out::main
5: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose
backtrace.
failures:
src/poll.rs - poll::Poll (line 267)
src/poll.rs - poll::Poll::deregister (line 877)
src/poll.rs - poll::Poll::register (line 735)
src/poll.rs - poll::Poll::reregister (line 820)
src/sys/unix/ready.rs - sys::unix::ready::UnixReady (line 66)
test result: FAILED. 74 passed; 5 failed; 0 ignored; 0 measured; 0 filtered
out; finished in 4.37s
Bug#1069805: scikit-build tries pip install during build
Source: scikit-build
Version: 0.17.6-1
Severity: serious
Tags: trixie sid ftbfs
scikit-build accesses network resources during the build:
process =
stdout = None, stderr = None, retcode = 1
def run(*popenargs,
input=None, capture_output=False, timeout=None, check=False,
**kwargs):
"""Run command with arguments and return a CompletedProcess instance.
The returned instance will have attributes args, returncode, stdout and
stderr. By default, stdout and stderr are not captured, and those
attributes
will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture
them,
or pass capture_output=True to capture both.
If check is True and the exit code was non-zero, it raises a
CalledProcessError. The CalledProcessError object will have the return
code
in the returncode attribute, and output & stderr attributes if those
streams
were captured.
If timeout is given, and the process takes too long, a TimeoutExpired
exception will be raised.
There is an optional argument "input", allowing you to
pass bytes or a string to the subprocess's stdin. If you use this
argument
you may not also use the Popen constructor's "stdin" argument, as
it will be used internally.
By default, all communication is in bytes, and therefore any "input"
should
be bytes, and the stdout and stderr will be bytes. If in text mode, any
"input" should be a string, and stdout and stderr will be strings
decoded
according to locale encoding, or by "encoding" if set. Text mode is
triggered by setting any of text, encoding, errors or
universal_newlines.
The other arguments are the same as for the Popen constructor.
"""
if input is not None:
if kwargs.get('stdin') is not None:
raise ValueError('stdin and input arguments may not both be
used.')
kwargs['stdin'] = PIPE
if capture_output:
if kwargs.get('stdout') is not None or kwargs.get('stderr') is not
None:
raise ValueError('stdout and stderr arguments may not be used '
'with capture_output.')
kwargs['stdout'] = PIPE
kwargs['stderr'] = PIPE
with Popen(*popenargs, **kwargs) as process:
try:
stdout, stderr = process.communicate(input, timeout=timeout)
except TimeoutExpired as exc:
process.kill()
if _mswindows:
# Windows accumulates the output in a single blocking
# read() call run on child threads, with the timeout
# being done in a join() on those threads. communicate()
# _after_ kill() is required to collect that and add it
# to the exception.
exc.stdout, exc.stderr = process.communicate()
else:
# POSIX _communicate already populated the output so
# far into the TimeoutExpired exception.
process.wait()
raise
except: # Including KeyboardInterrupt, communicate handled that.
process.kill()
# We don't call process.wait() as .__exit__ does that for us.
raise
retcode = process.poll()
if check and retcode:
> raise CalledProcessError(retcode, process.args,
output=stdout, stderr=stderr)
E subprocess.CalledProcessError: Command '['/usr/bin/python3.12',
'-m', 'pip', 'wheel', '--wheel-dir',
'/tmp/pytest-of-jspricke/pytest-21/wheelhouse0', '/build/package/package']'
returned non-zero exit status 1.
Bug#1069809: xhtml2pdf accesses network resources during the build
Source: xhtml2pdf Version: 0.2.15+dfsg-1 Severity: serious Tags: sid trixie ftbfs xhtml2pdf accesses network resources during the build: == FAIL: test_document_cannot_identify_image (tests.test_document.DocumentTest.test_document_cannot_identify_image) Test that images which cannot be identified don't cause stack trace to be printed -- Traceback (most recent call last): File "/build/package/package/.pybuild/cpython3_3.11_xhtml2pdf/build/tests/test_document.py", line 189, in test_document_cannot_identify_image self.assertEqual( AssertionError: Lists differ: ['WAR[16 chars]ags:Could not get image data from src attribut[265 chars]>\''] != ['WAR[16 chars]ags:Cannot identify image file:\n\'\'' + ['WARNING:xhtml2pdf.tags:Cannot identify image file:\n' - ['WARNING:xhtml2pdf.tags:Could not get image data from src attribute: ' - 'https://raw.githubusercontent.com/python-pillow/Pillow/7921da54a73dd4a30c23957369b79cda176005c6/Tests/images/zero_width.gif\n' "'https://raw.githubusercontent.com/python-pillow/Pillow/7921da54a73dd4a30c23957369b79cda176005c6/Tests/images/zero_width.gif"/>\''] == FAIL: test_document_with_broken_image (tests.test_document.DocumentTest.test_document_with_broken_image) Test that broken images don't cause unhandled exception -- Traceback (most recent call last): File "/build/package/package/.pybuild/cpython3_3.11_xhtml2pdf/build/tests/test_document.py", line 169, in test_document_with_broken_image self.assertEqual( AssertionError: Lists differ: [] != ["WARNING:xhtml2pdf.xhtml2pdf_reportlab:SV[151 chars]ml'"] Second list contains 1 additional elements. First extra element 0: "WARNING:xhtml2pdf.xhtml2pdf_reportlab:SVG drawing could not be resized: 'https://raw.githubusercontent.com/xhtml2pdf/xhtml2pdf/b01b1d8f9497dedd0f2454409d03408bdeea997c/tests/samples/images.html'" - [] + ['WARNING:xhtml2pdf.xhtml2pdf_reportlab:SVG drawing could not be resized: ' + "'https://raw.githubusercontent.com/xhtml2pdf/xhtml2pdf/b01b1d8f9497dedd0f2454409d03408bdeea997c/tests/samples/images.html'"]
Bug#1068798: bookworm-pu: package fdroidserver/2.2.1-1
Package: release.debian.org Severity: normal Tags: bookworm X-Debbugs-Cc: fdroidser...@packages.debian.org, Hans-Christoph Steiner Control: affects -1 + src:fdroidserver User: release.debian@packages.debian.org Usertags: pu [ Reason ] There was a security problem reported against fdroidserver: https://www.openwall.com/lists/oss-security/2024/04/08/8 [ Impact ] Stable users of fdroidserver running their own repo could be tricked into providing wrongly signed files. [ Tests ] Manual test on F-Droid internal datasets as well as automated tests inside fdroidserver. [ Risks ] Low, the relevant code is only used to extract and verify signatures. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [ ] the issue is verified as fixed in unstable [ Changes ] The patch reorders the code as well as changes the code of the imported androguard library. [ Other info ] Upstream is still working on a long term fix that will be uploaded to unstable later. I agreed with upstream to use use the patch provided in the mail on oss-security already now.
Bug#1068798: bookworm-pu: package fdroidserver/2.2.1-1
Forgot the patch..
diff --git a/debian/changelog b/debian/changelog
index a990dc45..05aabd67 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+fdroidserver (2.2.1-1+deb12u1) bookworm; urgency=medium
+
+ * Team upload.
+ * Add patch to fix security issue in certificate checks
+
+ -- Jochen Sprickerhof Thu, 11 Apr 2024 11:20:33 +0200
+
fdroidserver (2.2.1-1) unstable; urgency=medium
* New upstream version 2.2.1
diff --git a/debian/patches/0004-Fix-signer-certificate-checks.patch b/debian/patches/0004-Fix-signer-certificate-checks.patch
new file mode 100644
index ..8830d788
--- /dev/null
+++ b/debian/patches/0004-Fix-signer-certificate-checks.patch
@@ -0,0 +1,72 @@
+From: "FC (Fay) Stegerman"
+Date: Thu, 11 Apr 2024 11:11:46 +0200
+Subject: Fix signer certificate checks
+
+This fixes the order the signatures are checked to be the same as
+Android does them and monkey patches androguard to handle duplicate
+signing blocks.
+
+This was reported as:
+
+https://www.openwall.com/lists/oss-security/2024/04/08/8
+
+Patch taken from:
+
+https://github.com/obfusk/fdroid-fakesigner-poc/blob/master/fdroidserver.patch
+---
+ fdroidserver/common.py | 33 -
+ 1 file changed, 20 insertions(+), 13 deletions(-)
+
+diff --git a/fdroidserver/common.py b/fdroidserver/common.py
+index bc4265e..bd1a4c8 100644
+--- a/fdroidserver/common.py
b/fdroidserver/common.py
+@@ -3001,28 +3001,35 @@ def signer_fingerprint(cert_encoded):
+
+ def get_first_signer_certificate(apkpath):
+ """Get the first signing certificate from the APK, DER-encoded."""
++class FDict(dict):
++def __setitem__(self, k, v):
++if k not in self:
++super().__setitem__(k, v)
++
+ certs = None
+ cert_encoded = None
+-with zipfile.ZipFile(apkpath, 'r') as apk:
+-cert_files = [n for n in apk.namelist() if SIGNATURE_BLOCK_FILE_REGEX.match(n)]
+-if len(cert_files) > 1:
+-logging.error(_("Found multiple JAR Signature Block Files in {path}").format(path=apkpath))
+-return None
+-elif len(cert_files) == 1:
+-cert_encoded = get_certificate(apk.read(cert_files[0]))
+-
+-if not cert_encoded and use_androguard():
++if use_androguard():
+ apkobject = _get_androguard_APK(apkpath)
+-certs = apkobject.get_certificates_der_v2()
++apkobject._v2_blocks = FDict()
++certs = apkobject.get_certificates_der_v3()
+ if len(certs) > 0:
+-logging.debug(_('Using APK Signature v2'))
++logging.debug(_('Using APK Signature v3'))
+ cert_encoded = certs[0]
+ if not cert_encoded:
+-certs = apkobject.get_certificates_der_v3()
++certs = apkobject.get_certificates_der_v2()
+ if len(certs) > 0:
+-logging.debug(_('Using APK Signature v3'))
++logging.debug(_('Using APK Signature v2'))
+ cert_encoded = certs[0]
+
++if not cert_encoded:
++with zipfile.ZipFile(apkpath, 'r') as apk:
++cert_files = [n for n in apk.namelist() if SIGNATURE_BLOCK_FILE_REGEX.match(n)]
++if len(cert_files) > 1:
++logging.error(_("Found multiple JAR Signature Block Files in {path}").format(path=apkpath))
++return None
++elif len(cert_files) == 1:
++cert_encoded = get_certificate(apk.read(cert_files[0]))
++
+ if not cert_encoded:
+ logging.error(_("No signing certificates found in {path}").format(path=apkpath))
+ return None
diff --git a/debian/patches/series b/debian/patches/series
index ab17e6df..8e2df116 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
debian-java-detection.patch
ignore-irrelevant-test.patch
scanner-tests-need-dexdump.patch
+0004-Fix-signer-certificate-checks.patch
signature.asc
Description: PGP signature
Bug#1070332: Wont fix
Hi Thomas, * Thomas Goirand [2024-05-06 08:21]: I already explained this: I am *NOT* interested in addressing this type of failure. Designate is "OpenStack DNS as a Service", therefore, it is expected that it's going to check/use /etc/resolv.conf. If you carefully look at what's going on, you'll see that it's not even doing DNS queries to the outside, it's simply testing itself. Removing the test would mean less Q/A, which is not desirable. "Fixing" the test would mean more work, which isn't needed in this case (the package works perfectly). Feel free to bug upstream and resolve it there if you think that's valuable, though I am of the opinion it's a loss of time. Also, note that the package builds perfectly fine in the current buildd environment (and on my laptop's sbuild setup). If that was going to change, of course, I'd review my opinion. In the mean time, I see no point in this bug. Fix your build env... Note that the buildds started switching to the unshare backend so the package will FTBFS soon. Cheers Jochen signature.asc Description: PGP signature
Bug#1070319: fails to build without a non lo IP address
Source: google-guest-agent Version: 2026.00-6 Severity: normal X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org Control: affects -1 buildd.debian.org Hi, google-guest-agent has a test that depends on having an IP address available in the build environment: https://sources.debian.org/src/google-guest-agent/2026.00-6/google_guest_agent/wsfc_test.go/#L206 This fails in sbuild with the unshare backend: === RUN TestWsfcRunAgentE2E wsfc_test.go:207: health check failed with , got = , want 1 wsfc_test.go:209: EOF --- FAIL: TestWsfcRunAgentE2E (1.00s) Cheers Jochen
Bug#1070317: fails to build without a non lo IP address
* Jochen Sprickerhof [2024-05-03 18:55]: This fails in sbuild with the chroot backend: I mean the unshare backend. signature.asc Description: PGP signature
Bug#1070317: fails to build without a non lo IP address
Source: golang-github-likexian-gokit Version: 0.25.9-3 Severity: normal X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org Control: affects -1 buildd.debian.org Hi, golang-github-likexian-gokit has a test that depends on having an IP address available in the build environment: https://sources.debian.org/src/golang-github-likexian-gokit/0.25.9-3/xip/xip_test.go/#L213 This fails in sbuild with the chroot backend: === RUN TestGetEthIPv4 assert.go:197: /<>/obj-x86_64-linux-gnu/src/github.com/likexian/gokit/xip/xip_test.go:213 assert.go:172: ! expected true, but got false --- FAIL: TestGetEthIPv4 (0.00s) Cheers Jochen
Bug#1070325: fails to build without a non local IP
Source: servefile Version: 0.5.4-3 Severity: normal Tags: patch X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org Control: affects -1 buildd.debian.org Hi, servefile fails to build when self.getIPs() does not return an IP: Traceback (most recent call last): File "", line 198, in _run_module_as_main File "", line 88, in _run_code File "/<>/.pybuild/cpython3_3.12_servefile/build/servefile/__main__.py", line 3, in servefile.main() File "/<>/.pybuild/cpython3_3.12_servefile/build/servefile/servefile.py", line 1289, in main server.serve() File "/<>/.pybuild/cpython3_3.12_servefile/build/servefile/servefile.py", line 1008, in serve self.server.append(self._createServer(self.handler)) File "/<>/.pybuild/cpython3_3.12_servefile/build/servefile/servefile.py", line 982, in _createServer self.genKeyPair() File "/<>/.pybuild/cpython3_3.12_servefile/build/servefile/servefile.py", line 927, in genKeyPair for ip in self.getIPs() + ["127.0.0.1", "::1"]: ~~^~ TypeError: unsupported operand type(s) for +: 'NoneType' and 'list' This fails in sbuild with the unshare backend. A simple fix would be: --- servefile-0.5.4.orig/servefile/servefile.py +++ servefile-0.5.4/servefile/servefile.py @@ -890,7 +890,7 @@ class ServeFile(): ips = [ip for ip in ips if ':' in ip] return ips -return None +return [] def setSSLKeys(self, cert, key): """ Set SSL cert/key. Can be either path to file or pyopenssl X509/PKey object. """ Cheers Jochen
Bug#1070324: fails to build when no local ssh server is running
Source: python-scrapli
Version: 2023.7.30-2
Severity: normal
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org
Hi,
python-scrapli has a test that tries to connect to localhost port 22:
https://sources.debian.org/src/python-scrapli/2023.7.30-2/tests/unit/transport/base/test_base_socket.py/#L6
This fails in sbuild with the unshare backend:
=== FAILURES ===
test_socket_open_close_isalive
self =
socket_address_families = {}
def _connect(self, socket_address_families: Set["socket.AddressFamily"]) ->
None:
"""
Try to open socket to host using all possible address families
It seems that very occasionally when resolving a hostname (i.e.
localhost during functional
tests against vrouter devices), a v6 address family will be the first
af the socket
getaddrinfo returns, in this case, because the qemu hostfwd is not
listening on ::1, instead
only listening on 127.0.0.1 the connection will fail. Presumably this
is something that can
happen in real life too... something gets resolved with a v6 address
but is denying
connections or just not listening on that ipv6 address. This little
connect wrapper is
intended to deal with these weird scenarios.
Args:
socket_address_families: set of address families available for the
provided host
really only should ever be v4 AND v6 if providing a hostname
that resolves with
both addresses, otherwise if you just provide a v4/v6 address
it will just be a
single address family for that type of address
Returns:
None
Raises:
ScrapliConnectionNotOpened: if socket refuses connection on all
address families
ScrapliConnectionNotOpened: if socket connection times out on all
address families
"""
for address_family_index, address_family in
enumerate(socket_address_families, start=1):
self.sock = socket.socket(address_family, socket.SOCK_STREAM)
self.sock.settimeout(self.timeout)
try:
> self.sock.connect((self.host, self.port))
E ConnectionRefusedError: [Errno 111] Connection refused
scrapli/transport/base/base_socket.py:82: ConnectionRefusedError
The above exception was the direct cause of the following exception:
socket_transport =
def test_socket_open_close_isalive(socket_transport):
"""Test socket initialization/opening"""
assert socket_transport.host == "localhost"
assert socket_transport.port == 22
assert socket_transport.timeout == 10.0
> socket_transport.open()
Please disable those tests tests:
tests/unit/transport/base/test_base_socket.py::test_socket_open_close_isalive
tests/unit/transport/base/test_base_socket.py::test_socket_bool
Cheers Jochen
Bug#1070334: libnet-frame-device-perl needs network access during build
Source: libnet-frame-device-perl Version: 1.12-1 Severity: serious Justification: Policy 4.9 X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org Control: affects -1 buildd.debian.org Hi, libnet-frame-device-perl fails to build with no network connection: 1..1 # Running under perl version 5.038002 for linux # Current time local: Sat Apr 27 12:53:04 2024 # Current time GMT: Sat Apr 27 12:53:04 2024 # Using Test.pm version 1.31 ok 1 # skip Test::Pod 1.00 required for testing ok Net::Frame::Device: updateFromDefault: unable to get dnet This can be tested with the sbuild unshare backend. Cheers Jochen
Bug#1070332: designate fails to build with no nameserver specified in /etc/resolv.conf
Source: designate
Version: 1:18.0.0-1
Severity: normal
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org
Hi,
designate fails to build with no nameserver specified in
/etc/resolv.conf:
==
FAIL: designate.tests.unit.mdns.test_handler.MdnsHandleTest.test_notify
designate.tests.unit.mdns.test_handler.MdnsHandleTest.test_notify
--
testtools.testresult.real._StringException: Traceback (most recent call last):
File "/usr/lib/python3.12/unittest/mock.py", line 1390, in patched
return func(*newargs, **newkeywargs)
^
File "/<>/designate/tests/unit/mdns/test_handler.py", line 79,
in test_notify
self.assertEqual(dns.rcode.NOERROR, tuple(response)[0].rcode())
^^^
File "/<>/designate/mdns/handler.py", line 142, in _handle_notify
resolver = dns.resolver.Resolver()
^^^
File "/usr/lib/python3/dist-packages/dns/resolver.py", line 944, in __init__
self.read_resolv_conf(filename)
File "/usr/lib/python3/dist-packages/dns/resolver.py", line 1038, in
read_resolv_conf
raise NoResolverConfiguration("no nameservers")
dns.resolver.NoResolverConfiguration: no nameservers
This fails in sbuild with the unshare backend. Please disable the
failing tests:
designate.tests.unit.mdns.test_handler.MdnsHandleTest.test_notify
designate.tests.unit.mdns.test_handler.MdnsHandleTest.test_notify_same_serial
Cheers Jochen
Bug#1070333: python-eventlet fails to build with an empty /etc/resolv.conf
Source: python-eventlet
Version: 0.35.1-1
Severity: normal
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org
Hi,
python-eventlet fails to build with no nameserver specified in
/etc/resolv.conf:
=== FAILURES ===
_ TestProxyResolver.test_clear _
self =
def test_clear(self):
rp = greendns.ResolverProxy()
assert rp._cached_resolver is None
> resolver = rp._resolver
tests/greendns_test.py:304:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
eventlet/support/greendns.py:347: in _resolver
self.clear()
eventlet/support/greendns.py:355: in clear
self._resolver = dns.resolver.Resolver(filename=self._filename)
/usr/lib/python3/dist-packages/dns/resolver.py:944: in __init__
self.read_resolv_conf(filename)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
f = <_io.TextIOWrapper name='/etc/resolv.conf' mode='r' encoding='UTF-8'>
def read_resolv_conf(self, f: Any) -> None:
"""Process *f* as a file in the /etc/resolv.conf format. If f is
a ``str``, it is used as the name of the file to open; otherwise it
is treated as the file itself.
Interprets the following items:
- nameserver - name server IP address
- domain - local domain name
- search - search list for host-name lookup
- options - supported options are rotate, timeout, edns0, and ndots
"""
nameservers = []
if isinstance(f, str):
try:
cm: contextlib.AbstractContextManager = open(f)
except OSError:
# /etc/resolv.conf doesn't exist, can't be read, etc.
raise NoResolverConfiguration(f"cannot open {f}")
else:
cm = contextlib.nullcontext(f)
with cm as f:
for l in f:
if len(l) == 0 or l[0] == "#" or l[0] == ";":
continue
tokens = l.split()
# Any line containing less than 2 tokens is malformed
if len(tokens) < 2:
continue
if tokens[0] == "nameserver":
nameservers.append(tokens[1])
elif tokens[0] == "domain":
self.domain = dns.name.from_text(tokens[1])
# domain and search are exclusive
self.search = []
elif tokens[0] == "search":
# the last search wins
self.search = []
for suffix in tokens[1:]:
self.search.append(dns.name.from_text(suffix))
# We don't set domain as it is not used if
# len(self.search) > 0
elif tokens[0] == "options":
for opt in tokens[1:]:
if opt == "rotate":
self.rotate = True
elif opt == "edns0":
self.use_edns()
elif "timeout" in opt:
try:
self.timeout = int(opt.split(":")[1])
except (ValueError, IndexError):
pass
elif "ndots" in opt:
try:
self.ndots = int(opt.split(":")[1])
except (ValueError, IndexError):
pass
if len(nameservers) == 0:
> raise NoResolverConfiguration("no nameservers")
E dns.resolver.NoResolverConfiguration: no nameservers
/usr/lib/python3/dist-packages/dns/resolver.py:1038: NoResolverConfiguration
This fails in sbuild with the unshare backend.
Cheers Jochen
Bug#1070973: Please add a include_optional to /etc/mpd.conf
Package: mpd Version: 0.23.14-2+b2 Severity: wishlist Tags: patch Hi, can you please add a include_optional to simplify local modifications? Something like this should do: echo 'include_optional "mpd_local.conf"' >> debian/mpd.conf Thanks! Jochen
Bug#1070952: ros-vcstools: FTBFS in bullseye
Hi Santiago, thanks for the report. This seems to be due to git 1:2.30.2-1+deb11u1 as it works with the version before (1:2.30.2-1). Give that it is a security fix and a testing only problem that could worked around easily, I would leave this as is. Cheers Jochen * Santiago Vila [2024-05-11 21:53]: Package: src:ros-vcstools Version: 0.1.42-3 Severity: serious Control: close -1 0.1.42-7 Tags: ftbfs bullseye Dear maintainer: During a rebuild of all packages in bullseye, your package failed to build: [...] debian/rules binary dh binary --with python3 --buildsystem=pybuild dh_update_autotools_config -O--buildsystem=pybuild dh_autoreconf -O--buildsystem=pybuild dh_auto_configure -O--buildsystem=pybuild I: pybuild base:232: python3.9 setup.py config /<>/setup.py:3: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses import imp running config dh_auto_build -O--buildsystem=pybuild I: pybuild base:232: /usr/bin/python3 setup.py build /<>/setup.py:3: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses import imp [... snipped ...] 6 files updated, 0 files merged, 0 files removed, 0 files unresolved ok test_checkout_into_subdir_without_existing_parent (test.test_hg.HGClientTest) ... updating to branch default 6 files updated, 0 files merged, 0 files removed, 0 files unresolved ok test_checkout_specific_version_and_update (test.test_hg.HGClientTest) ... updating to branch default 6 files updated, 0 files merged, 0 files removed, 0 files unresolved 0 files updated, 0 files merged, 0 files removed, 0 files unresolved pulling from /tmp/tmp18ac112f/remote searching for changes no changes found 0 files updated, 0 files merged, 2 files removed, 0 files unresolved pulling from /tmp/tmp18ac112f/remote searching for changes no changes found 2 files updated, 0 files merged, 0 files removed, 0 files unresolved pulling from /tmp/tmp18ac112f/remote searching for changes no changes found 0 files updated, 0 files merged, 2 files removed, 0 files unresolved pulling from /tmp/tmp18ac112f/remote searching for changes no changes found 2 files updated, 0 files merged, 0 files removed, 0 files unresolved ok test_get_current_version_label (test.test_hg.HGClientTest) ... updating to branch default 6 files updated, 0 files merged, 0 files removed, 0 files unresolved 0 files updated, 0 files merged, 5 files removed, 0 files unresolved pulling from /tmp/tmp18ac112f/remote searching for changes no changes found 5 files updated, 0 files merged, 0 files removed, 0 files unresolved pulling from /tmp/tmp18ac112f/remote searching for changes no changes found 1 files updated, 0 files merged, 0 files removed, 0 files unresolved ok test_get_environment_metadata (test.test_hg.HGClientTest) ... ok test_get_remote_version (test.test_hg.HGClientTest) ... updating to branch default 6 files updated, 0 files merged, 0 files removed, 0 files unresolved abort: destination '/tmp/tmp18ac112f/local' is not empty pulling from /tmp/tmp18ac112f/remote searching for changes no changes found 0 files updated, 0 files merged, 0 files removed, 0 files unresolved pulling from /tmp/tmp18ac112f/remote searching for changes no changes found 1 files updated, 0 files merged, 0 files removed, 0 files unresolved ok test_get_type_name (test.test_hg.HGClientTest) ... ok test_get_url_by_reading (test.test_hg.HGClientTest) ... updating to branch default 6 files updated, 0 files merged, 0 files removed, 0 files unresolved 0 files updated, 0 files merged, 0 files removed, 0 files unresolved ok test_get_url_nonexistant (test.test_hg.HGClientTest) ... ok marked working directory as branch test_branch (branches are permanent and global, did you want a bookmark?) updating to branch default 6 files updated, 0 files merged, 0 files removed, 0 files unresolved testStatusUntracked (test.test_hg.HGDiffStatClientTest) ... ok test_diff (test.test_hg.HGDiffStatClientTest) ... ok test_diff_relpath (test.test_hg.HGDiffStatClientTest) ... ok test_get_version_modified (test.test_hg.HGDiffStatClientTest) ... ok test_hg_diff_path_change_None (test.test_hg.HGDiffStatClientTest) ... ok test_status (test.test_hg.HGDiffStatClientTest) ... ok test_status_relpath (test.test_hg.HGDiffStatClientTest) ... ok marked working directory as branch test_branch (branches are permanent and global, did you want a bookmark?) updating to branch default 6 files updated, 0 files merged, 0 files removed, 0 files unresolved test_export_repository (test.test_hg.HGExportRepositoryClientTest) ... ok marked working directory as branch test_branch (branches are permanent and global, did you want a bookmark?) updating to branch default 6 files updated, 0 files merged, 0 files removed, 0 files unresolved test_get_branches (test.test_hg.HGGetBranchesClientTest) ... pulling from
Bug#1071190: golang-github-shirou-gopsutil fails to build with no physical disks present
Source: golang-github-shirou-gopsutil Version: 3.24.1-1 Severity: normal X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org Control: affects -1 buildd.debian.org Hi, golang-github-shirou-gopsutil fails to build when there are no physical drives mounted: === RUN TestDisk_partitions disk_test.go:38: error disk_test.go:40: [] disk_test.go:43: ret is empty --- FAIL: TestDisk_partitions (0.00s) This happens for example in the sbuild unshare backend. Cheers Jochen
Bug#1070411: containerd fails to build as a normal user due to sysctl
Source: containerd Version: 1.6.20~ds1-1 Severity: important X-Debbugs-Cc: debian-wb-t...@lists.debian.org Usertags: unshare Hi, containerd uses sysctl during the build which fails as a normal user: === RUN TestLinuxSandboxContainerSpec sandbox_run_linux_test.go:241: TestCase "spec should reflect original config" sandbox_run_linux_test.go:71: Check PodSandbox annotations sandbox_run_linux_test.go:124: Error Trace: /<>/_build/src/github.com/containerd/containerd/pkg/cri/server/sandbox_run_linux_test.go:124 /<>/_build/src/github.com/containerd/containerd/pkg/cri/server/sandbox_run_linux_test.go:259 Error: "" does not contain "0 2147483647" Test: TestLinuxSandboxContainerSpec sandbox_run_linux_test.go:241: TestCase "host namespace" sandbox_run_linux_test.go:71: Check PodSandbox annotations sandbox_run_linux_test.go:241: TestCase "should set supplemental groups correctly" sandbox_run_linux_test.go:71: Check PodSandbox annotations sandbox_run_linux_test.go:241: TestCase "should overwrite default sysctls" sandbox_run_linux_test.go:71: Check PodSandbox annotations sandbox_run_linux_test.go:241: TestCase "sandbox sizing annotations should be set if LinuxContainerResources were provided" sandbox_run_linux_test.go:71: Check PodSandbox annotations sandbox_run_linux_test.go:241: TestCase "sandbox sizing annotations should not be set if LinuxContainerResources were not provided" sandbox_run_linux_test.go:71: Check PodSandbox annotations sandbox_run_linux_test.go:241: TestCase "sandbox sizing annotations are zero if the resources are set to 0" sandbox_run_linux_test.go:71: Check PodSandbox annotations --- FAIL: TestLinuxSandboxContainerSpec (0.00s) https://salsa.debian.org/go-team/packages/containerd/-/blob/debian/sid/pkg/cri/server/sandbox_run_linux_test.go#L124 This make the build fail for example in the sbuild unshare backend. Cheers Jochen
Bug#1070413: sogo fails to build when test succeeds
Source: sogo Version: 5.10.0-2 Severity: important Hi, the sogo package contains a patch that hard coded the number of failing tests to two: https://sources.debian.org/src/sogo/5.10.0-2/debian/patches/0006-Update-unit-test-expected-failures.patch/ This makes the package FTBFS when more tests succeeds, for example in a local build or in sbuild with the unshare backend. Please drop this patch and fix or disable the failing tests instead. Cheers Jochen
Bug#1070414: fails to build when not build inside schroot
Source: kel-agent Version: 0.4.6-2 Severity: important X-Debbugs-Cc: debian-wb-t...@lists.debian.org Usertags: unshare Hi, kel-agent hard codes to skip a test when build inside schroot: https://sources.debian.org/src/kel-agent/0.4.6-2/integration/suite_test.go/#L27 But the test also fails in other environments for me, for example as a local user or in the sbuild unshare backend. Please either fix or disable the test. Cheers Jochen
Bug#1070410: golang-github-pion-webrtc.v3 accesses the internet during build
Source: golang-github-pion-webrtc.v3
Version: 3.1.56-2
Severity: serious
Justification: Policy 4.9
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org
Hi,
golang-github-pion-webrtc.v3 attempts network access during build.
This is forbidden by Policy 4.9:
For packages in the main archive, required targets must not attempt
network access, except, via the loopback interface, to services on the
build host that have been started by the build.
This can be tested with the sbuild unshare backend:
=== NAME TestDataChannelParamters_Go
util.go:41: Unexpected routines on test end:
goroutine 34 [select]:
github.com/pion/interceptor/pkg/nack.(*GeneratorInterceptor).loop(0xc240a0,
{0x9f4b80, 0xc3ec30})
/<>/_build/src/github.com/pion/interceptor/pkg/nack/generator_interceptor.go:139
+0x12d
created by
github.com/pion/interceptor/pkg/nack.(*GeneratorInterceptor).BindRTCPWriter in
goroutine 16
/<>/_build/src/github.com/pion/interceptor/pkg/nack/generator_interceptor.go:74
+0x115
goroutine 35 [select]:
github.com/pion/interceptor/pkg/report.(*ReceiverInterceptor).loop(0xc0001303c0,
{0x9f4b80, 0xc3ec30})
/<>/_build/src/github.com/pion/interceptor/pkg/report/receiver_interceptor.go:97
+0x19c
created by
github.com/pion/interceptor/pkg/report.(*ReceiverInterceptor).BindRTCPWriter in
goroutine 16
/<>/_build/src/github.com/pion/interceptor/pkg/report/receiver_interceptor.go:86
+0x115
goroutine 36 [select]:
github.com/pion/interceptor/pkg/report.(*SenderInterceptor).loop(0xc000130420,
{0x9f4b80, 0xc3ec30})
/<>/_build/src/github.com/pion/interceptor/pkg/report/sender_interceptor.go:98
+0x19c
created by
github.com/pion/interceptor/pkg/report.(*SenderInterceptor).BindRTCPWriter in
goroutine 16
/<>/_build/src/github.com/pion/interceptor/pkg/report/sender_interceptor.go:87
+0x115
[...]
Cheers Jochen
Bug#1070409: golang-github-pion-ice.v2: accesses the internet during build
Source: golang-github-pion-ice.v2 Version: 2.3.1-1 Severity: serious Justification: Policy 4.9 X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org Control: affects -1 buildd.debian.org Hi, golang-github-pion-ice.v2 attempts network access during build. This is forbidden by Policy 4.9: For packages in the main archive, required targets must not attempt network access, except, via the loopback interface, to services on the build host that have been started by the build. This can be tested with the sbuild unshare backend: === RUN TestConnectionStateCallback goroutine profile: total 16 2 @ 0x43f36e 0x40999f 0x4095d2 0x71a847 0x476061 # 0x71a846 github.com/pion/ice/v2.(*Agent).startOnConnectionStateChangeRoutine.func1+0x46 /<>/_build/src/github.com/pion/ice/v2/agent.go:424 2 @ 0x43f36e 0x438057 0x470a85 0x4a1ec7 0x4a4f0a 0x4a4ef3 0x565516 0x5a2004 0x5a568e 0x5a567c 0x5a8745 0x476061 # 0x470a84internal/poll.runtime_pollWait+0x84 /usr/lib/go-1.22/src/runtime/netpoll.go:345 # 0x4a1ec6internal/poll.(*pollDesc).wait+0x26 /usr/lib/go-1.22/src/internal/poll/fd_poll_runtime.go:84 # 0x4a4f09internal/poll.(*pollDesc).waitRead+0x129 /usr/lib/go-1.22/src/internal/poll/fd_poll_runtime.go:89 # 0x4a4ef2internal/poll.(*FD).RawRead+0x112 /usr/lib/go-1.22/src/internal/poll/fd_unix.go:708 # 0x565515net.(*rawConn).Read+0x35 /usr/lib/go-1.22/src/net/rawconn.go:44 # 0x5a2003golang.org/x/net/internal/socket.(*Conn).recvMsg+0x143 /<>/_build/src/golang.org/x/net/internal/socket/rawconn_msg.go:27 # 0x5a568dgolang.org/x/net/internal/socket.(*Conn).RecvMsg+0x4ad /<>/_build/src/golang.org/x/net/internal/socket/socket.go:247 # 0x5a567bgolang.org/x/net/ipv4.(*payloadHandler).ReadFrom+0x49b /<>/_build/src/golang.org/x/net/ipv4/payload_cmsg.go:31 # 0x5a8744github.com/pion/mdns.(*Conn).start+0xe4 /<>/_build/src/github.com/pion/mdns/conn.go:295 2 @ 0x43f36e 0x4510c5 0x4ea5b8 0x476061 # 0x4ea5b7context.(*cancelCtx).propagateCancel.func2+0x97 /usr/lib/go-1.22/src/context/context.go:510 2 @ 0x43f36e 0x4510c5 0x719098 0x476061 # 0x719097github.com/pion/ice/v2.(*Agent).taskLoop+0x137 /<>/_build/src/github.com/pion/ice/v2/agent.go:230 2 @ 0x43f36e 0x4510c5 0x71a5c5 0x476061 # 0x71a5c4 github.com/pion/ice/v2.(*Agent).startOnConnectionStateChangeRoutine.func2+0xa4 /<>/_build/src/github.com/pion/ice/v2/agent.go:433 2 @ 0x43f36e 0x4510c5 0x71b113 0x476061 # 0x71b112 github.com/pion/ice/v2.(*Agent).connectivityChecks+0x1b2 /<>/_build/src/github.com/pion/ice/v2/agent.go:550 1 @ 0x434a31 0x4706bd 0x531871 0x5316a5 0x52e4cb 0x7748bd 0x476061 # 0x4706bcruntime/pprof.runtime_goroutineProfileWithLabels+0x1c /usr/lib/go-1.22/src/runtime/mprof.go:1079 # 0x531870runtime/pprof.writeRuntimeProfile+0xb0 /usr/lib/go-1.22/src/runtime/pprof/pprof.go:774 # 0x5316a4runtime/pprof.writeGoroutine+0x44 /usr/lib/go-1.22/src/runtime/pprof/pprof.go:734 # 0x52e4caruntime/pprof.(*Profile).WriteTo+0x14a /usr/lib/go-1.22/src/runtime/pprof/pprof.go:369 # 0x7748bc github.com/pion/ice/v2.TestConnectionStateCallback.TimeOut.func2+0x3c /<>/_build/src/github.com/pion/transport/test/util.go:21 1 @ 0x43f36e 0x40999f 0x4095b2 0x4faeeb 0x4fd037 0x4fa01b 0x4fcf25 0x4fb92b 0x77c2ac 0x43ef1d 0x476061 # 0x4faeeatesting.(*T).Run+0x3aa /usr/lib/go-1.22/src/testing/testing.go:1750 # 0x4fd036testing.runTests.func1+0x36 /usr/lib/go-1.22/src/testing/testing.go:2161 # 0x4fa01atesting.tRunner+0xfa /usr/lib/go-1.22/src/testing/testing.go:1689 # 0x4fcf24testing.runTests+0x444 /usr/lib/go-1.22/src/testing/testing.go:2159 # 0x4fb92atesting.(*M).Run+0x68a /usr/lib/go-1.22/src/testing/testing.go:2027 # 0x77c2abmain.main+0x16b _testmain.go:225 # 0x43ef1cruntime.main+0x29c /usr/lib/go-1.22/src/runtime/proc.go:271 1 @ 0x43f36e 0x4510c5 0x73a965 0x766c5b 0x766c32 0x746425 0x4fa01b 0x476061 # 0x73a964github.com/pion/ice/v2.(*Agent).connect+0x124 /<>/_build/src/github.com/pion/ice/v2/transport.go:53 # 0x766c5agithub.com/pion/ice/v2.(*Agent).Dial+0xfa /<>/_build/src/github.com/pion/ice/v2/transport.go:15 # 0x766c31github.com/pion/ice/v2.connect+0xd1 /<>/_build/src/github.com/pion/ice/v2/transport_test.go:219 # 0x746424
Bug#1070412: Fails to build due to hard coded OS platform
Source: golang-github-kardianos-service Version: 1.2.0-2 Severity: important X-Debbugs-Cc: debian-wb-t...@lists.debian.org Usertags: unshare Hi, golang-github-kardianos-service fails to build when it can't detect the OS platform: === RUN TestPlatformName name_test.go:15: Platform is unix-systemv name_test.go:18: Platform() want: /^linux-.*$/, got: unix-systemv --- FAIL: TestPlatformName (0.00s) This happens for example in the sbuild unshare bachend. The problem is that in the test: https://sources.debian.org/src/golang-github-kardianos-service/1.2.1-1/name_test.go/?hl=13#L13 runtime.GOOS is hard coded to linux. Cheers Jochen
Bug#1070415: runc fails to build as a normal user due to cgroups access
Source: runc
Version: 1.1.12+ds1-2
Severity: important
X-Debbugs-Cc: debian-wb-t...@lists.debian.org
Usertags: unshare
Hi,
runc tries to write cgroups files during the build which fails as a
normal user:
=== RUN TestDevicesSetAllow
--- FAIL: TestDevicesSetAllow (0.00s)
panic: runtime error: index out of range [0] with length 0 [recovered]
panic: runtime error: index out of range [0] with length 0
goroutine 63 [running]:
testing.tRunner.func1.2({0x5e12c0, 0xc0001ed2c0})
/usr/lib/go-1.22/src/testing/testing.go:1631 +0x24a
testing.tRunner.func1()
/usr/lib/go-1.22/src/testing/testing.go:1634 +0x377
panic({0x5e12c0?, 0xc0001ed2c0?})
/usr/lib/go-1.22/src/runtime/panic.go:770 +0x132
github.com/opencontainers/runc/libcontainer/cgroups/fs.TestDevicesSetAllow(0xc0001fcd00)
/<>/_build/src/github.com/opencontainers/runc/libcontainer/cgroups/fs/devices_test.go:42
+0x45e
testing.tRunner(0xc0001fcd00, 0x607748)
/usr/lib/go-1.22/src/testing/testing.go:1689 +0xfb
created by testing.(*T).Run in goroutine 1
/usr/lib/go-1.22/src/testing/testing.go:1742 +0x390
FAILgithub.com/opencontainers/runc/libcontainer/cgroups/fs 0.044s
https://salsa.debian.org/go-team/packages/runc/-/blob/debian/1.1.5+ds1-1/libcontainer/cgroups/fs/devices_test.go?ref_type=tags#L42
This also fails with the sbuild unshare backend.
Cheers Jochen
Bug#1070436: autopkgtest-virt-schroot: error when using 'unshare --net' even though schroot allows this
Hi Richard, * Richard Lewis [2024-05-05 11:32]: If i try and run tests that use 'unshare --net' with a schroot backend they fail inside autopkgtest even though this works in the schroot being used. This works fine in a 'plain schroot' (I expect i allowed the calling user to run the schroot as root in the schroot in /etc/schroot): $ schroot --chroot chroot:unstable-amd64-sbuild --directory / --user root -- unshare --net --map-root-user ls bin boot build dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var I can't reproduce this. Testing in a fresh debvm: $ debvm-create --size=2G --release=stable -- \ --include=sbuild,schroot,debootstrap,autopkgtest \ --hook-dir=/usr/share/mmdebstrap/hooks/useradd $ debvm-run # echo "inside debvm" # sbuild-createchroot unstable /srv/chroot/unstable-amd64-sbuild \ http://deb.debian.org/debian # sbuild-adduser user # su - user $ schroot --chroot chroot:unstable-amd64-sbuild --directory / --user root -- unshare --net --map-root-user ls unshare: unshare failed: Operation not permitted Do you have any idea why it works for you? But if i have an autopkgtest with eg a debian/tests/control with Test-Command: unshare --map-root-user --net ./debian/tests/foo Depends: @ Features: test-name=foo Restrictions: needs-root This looks odd. If you only want to unshare the network, as stated in the bug title, you neither need --map-root-user nor needs-root. Indeed dropping both makes it work for me. Can you give some background what you actually want to do here? then even adding '--user root' doesnt work: $ /usr/bin/autopkgtest package.changes --user root -- schroot unstable-amd64-sbuild I guess this is due to autopkgtest-virt-schroot starts an schroot session but I can't verify without reproducing your example without a session. i get errors like unshare: unshare failed: Operation not permitted This maps to unshare(2) returning EPERM. From the manpage: | CLONE_NEWUSER was specified in flags and the caller is in a chroot | environment (i.e., the caller's root directory does not match the root | directory of the mount namespace in which it resides). I think this is what happens here. Over all I think using unshare --map-root-user in autopkgtest-virt-schroot is not supported and I don't think there is a way around that except using a different autopkgtest backend. Cheers Jochen signature.asc Description: PGP signature
Bug#1064139: Bug #1064139 ogre-1.12: FTBFS: error: ‘BuildFontAtlas’ is not a member of ‘ImGuiFreeType’
Hi Flavien, * Flavien Bridault [2024-03-07 08:07]: I just cloned the repository to open the MR but then I realized there is already a branch opened two weeks ago exactly with the fix I proposed... So I guess it is on its way ? I guess you mean: https://salsa.debian.org/games-team/ogre/-/tree/fix_imgui That was my try to fix it but it fails later on in the build (as can be seen in CI). Help appreciated. Cheers Jochen signature.asc Description: PGP signature
Bug#1067444: FileNotFoundError: [Errno 2] ... /usr/lib/python3/dist-packages/bugwarrior/docs/configuration.rst
Hi Tj,
* Tj [2024-03-21 16:08]:
Severity: grave
Justification: renders package unusable
I disagree here. Any reason why you did it?
With a fresh install and manually creating the user's configuration file
I hit this error. The path reported seems to indicate the package is not
shipping the file mentioned. I tried moving the user config directory and
saw the error caused by it being missing, put it back, and hit this package
config file issue agian.
$ bugwarrior-pull
CRITICAL:bugwarrior.command:Could not load configuration. Maybe you have not
created a configuration file.
FileNotFoundError: [Errno 2] No such file or directory:
'/home/tj/.config/bugwarrior/bugwarriorrc'
$ mv ~/.config/bugwarrior{.bak,}
$ bugwarrior-pull
CRITICAL:bugwarrior.command:Could not load configuration. Maybe you have not
created a configuration file.
FileNotFoundError: [Errno 2] No such file or directory:
'/usr/lib/python3/dist-packages/bugwarrior/docs/configuration.rst'
$ cat ~/.config/bugwarrior/bugwarriorrc
[general]
targets = debianbts my_github
Delete my_github here, as you don't have a section on it.
[debianbts]
service = bts
bts.email = deb...@iam.tj
Add bts.udd = True to get your bugs ;).
$ dpkg -S docs/configuration.rst
dpkg-query: no path found matching pattern *docs/configuration.rst*
$ apt-file search docs/configuration.rst
$
dpkg -S configuration.rst
bugwarrior: /usr/share/doc/bugwarrior/html/_sources/common_configuration.rst.txt
bugwarrior: /usr/share/doc/bugwarrior/html/_sources/configuration.rst.txt
The second one is the same file. I will push new version with a fixed
path.
Cheers Jochen
signature.asc
Description: PGP signature
Bug#1066409: Linker fails to find libraries in unstable but succeeds in testing
Hi Andreas, * Andreas Tille [2024-03-15 07:31]: Hi, thanks to the next round of Lucas' FTBFS QA rebuilds (at least) one package of the R pkg team is affected by some strange linker issue #1066409 r-cran-v8: FTBFS: ld: cannot find -lv8: No such file or directory which boils down to[1] g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o V8.so RcppExports.o bindings.o -lv8 -lv8_libplatform -L/usr/lib/R/lib -lR /usr/bin/ld: cannot find -lv8: No such file or directory /usr/bin/ld: cannot find -lv8_libplatform: No such file or directory The Build-Depends libnode-dev provides both libraries and when I try to build the package under testing all is fine. Is there any linker issue involved that might be introduced in unstable? I guess that's the same as #1066399. libnode-dev: libv8.so -> libnode.so libnode.so -> libnode.so.108t64 But libnode.so.108t64 does not exist Cheers Jochen signature.asc Description: PGP signature
Bug#1063096: python3-webview: proxy_tools dependency not found
Hi Jeremy, you uploaded python3-webview recently which seem to be broken (see below). As I currently don't use the package, are you interested in taking over maintainership? Cheers Jochen * David Purton [2024-02-05 13:18]: Package: python3-webview Version: 4.4.1+dfsg-1 Severity: important Dear Maintainer, With the upgrade to python3-webview from 3.3.5 to 4.4.1, the package is no longer usable. The package is unable to find the module proxy_tools. For example, a simple script using webview fails: --- #!/bin/python3 import webview webview.create_window(title = 'Captive Portal Login', url = 'http://network-test.debian.org/nm', width = 1024, height = 768, min_size = (1024, 768), resizable = False) webview.start() --- The error is: --- Traceback (most recent call last): File "/home/user/bin/captiveportal.py", line 3, in import webview File "/usr/lib/python3/dist-packages/webview/__init__.py", line 23, in from proxy_tools import module_property ModuleNotFoundError: No module named 'proxy_tools' --- Presumably, python3-proxy_tools needs to be packaged and added to the dependencies of python3-webview. Thanks! David -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-webview depends on: ii gir1.2-webkit2-4.1 2.42.4-1 ii python3 [python3-supported-min] 3.11.6-1 ii python3-bottle 0.12.25-1 ii python3-gi 3.46.0-3 ii python3-gi-cairo 3.46.0-3 ii python3-typing-extensions4.7.1-2 python3-webview recommends no packages. python3-webview suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1067934: jameica: Jameica cannot load plugins | service "database" not found
Control: severity -1 normal Hi Ferdinand, * Ferdinand Rau [2024-03-29 08:51]: * What led up to the situation? The plugin Hibiscus, arguably the most important plugin for jameica, was updated. Version 2.10.15 used to work fine and still does work fine with the jameica packages in Debian Bookworm and Trixie. Versions 2.10.16 and the current version 2.10.17 do not work with either Debian package, but do work fine with the latest version of jameica (2.10.4) downloaded from the upstream source willuhn.de: https://www.willuhn.de/products/hibiscus/download.php Plugin-updates/installs were performed using the integrated plugin management of jameica. That is expected, software in stable is only supported with other software in stable, i.e. with the Hibiscus plugin in stable. Staying with hibiscus 2.10.15 is not an option in the long term, because updates introduce bug fixes and, most importantly, fix access for several German banks that changed their online access to different servers and protocols. Without the update to hibiscus 2.10.17, lots of bank accounts are inaccessible for the users. This is too unspecific to call for an update in stable. From my understanding all updates are configuration changes that can be done with the stable version as well. Downgrading the bug accordingly. Note that Debian stable updates have a strict policy noted here: https://lists.debian.org/debian-devel-announce/2019/08/msg0.html * Ferdinand Rau [2024-03-29 12:41]: The upstream author suggests that the issue may be related to the "H2 Database Engine" (Debian package: jameica-h2database) in a similar, but not identical case here: https://homebanking-hilfe.de/forum/topic.php?p=170111#real170111 Upstream H2 is at version 2.2.224, whereas Debian is at 1.4.197-7, which is approx. six years old. An update of jameica-h2database will likely fix this issue? Sadly no, while upstream H2 is at 2.2.224 and the Debian package (libh2-java) is at 2.2.220, Jameica ships 1.4.199, this is why the jameica-h2database was created in the first first place. I will update it to 1.4.199 together with Jameica in unstable. Cheers Jochen signature.asc Description: PGP signature
Bug#1067444: FileNotFoundError: [Errno 2] ... /usr/lib/python3/dist-packages/bugwarrior/docs/configuration.rst
Control: severity -1 normal Hi Andreas, * Andreas Beckmann [2024-03-24 10:23]: On Thu, 21 Mar 2024 18:39:00 +0100 Jochen Sprickerhof wrote: dpkg -S configuration.rst bugwarrior: /usr/share/doc/bugwarrior/html/_sources/common_configuration.rst.txt bugwarrior: /usr/share/doc/bugwarrior/html/_sources/configuration.rst.txt The second one is the same file. I will push new version with a fixed path. Does the package work with /usr/share/doc excluded from installation? https://www.debian.org/doc/debian-policy/ch-docs.html#additional-documentation. "Packages must not require the existence of any files in /usr/share/doc/ in order to function. [6] Any files that are used or read by programs but are also useful as stand alone documentation should be installed elsewhere, such as under /usr/share/package/, and then included via symbolic links in /usr/share/doc/package." It works fine. The only missing bit is printing an example configuration if the config is wrong, which I think is not RC and fine if the documentation is not installed. Thus downgrading the bug. Cheers Jochen signature.asc Description: PGP signature
