Bug#1058083: Before I try to tackle this bug - can we move the package to DPT
Hi Agustin and Ulises, I noticed there were several NMUs not commited to the Git repository of this package. I'd volunteer to bring the repository in sync with latest uploads and move it to Debian Python Team before I try to tacke bug #1058083. Kind regards Andreas. -- http://fam-tille.de
Bug#1052838: [debian-mysql] Bug#1052838: mariadb: FTBFS: make[1]: *** [debian/rules:161: override_dh_auto_test] Error 1
Hi, On Thu, 26 Oct 2023 10:59:50 +0200 Lucas Nussbaum wrote: Hi, On 02/10/23 at 21:59 -0700, Otto Kekäläinen wrote: > Hi! > > The relevant lines from log seems to be: > > > main.bind_address_resolution w4 [ fail ] > ... > > 2023-09-26 6:31:03 0 [ERROR] Can't start server: Bind on TCP/IP port. Got error: 98: Address already in use > > 2023-09-26 6:31:03 0 [ERROR] Do you already have another server running on port: 16020 ? > > 2023-09-26 6:31:03 0 [ERROR] Aborting > > What might have been holding port 16020 during the test run? I could reproduce the issue again, and I was not running anything else on the node. The ci.debian.net results for mariadb seem to be very flaky lately (on amd64 they fail roughly 9/10) since version 1:10.11.6-1. Might be related (although the failure is different). i386 and arm64 seem to be exceptions. https://ci.debian.net/packages/m/mariadb/testing/amd64/ Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055192: RFS: golang-github-apenella-go-ansible
On Sun, Dec 24, 2023 at 01:41:39PM +0530, Ananthu C V wrote: > It looks that this has been a clear oversight from my side. *I do find this a > very useful library* > but as you mentioned, since go team convention does not include packaging > libaries that are not > needed by any binaries, there is probably no real value in getting this in. It is not a go-team convention as such. In principle library packages can be packaged as well. However there is no utility in doing so. At the end of the day, a user only wants the necessary tools. The situation is quite different from python or javascript (where you work). In those teams, once you install python lib or a js lib, you can use it for your development w/o any extra hurdles. All imports/functionalities would work just fine. However, in go packages, you need to change the GOPATH/GOROOT to actually import and use those packages. This makes close to no sense for anyone to do, and simply using a go get is the most simple way. Adding in lib packages that effectively won't be used also calls for extra maintenance burden on the team so at least I find it sensible to add lib packages only when there's a use for them. > As such, please prune the corresponding repositories for the following: > - golang-github-apenella-go-ansible > - golang-github-apenella-go-common-utils > - golang-github-sosedoff-ansible-vault-go Pruned! > I feel sincerely sorry that an oversight from my side has ended up taking > some of your busy schedule > and I apologize for making you spend your time needlessly. I'll try my best > to make sure such mishapas > does not occur in the future, since it is not beneficial to anyone. And > regardless of the outcome of > this, thanks a lot for taking a look at the RFS. Don't worry about it, thanks for working on these regardless! Best, Nilesh signature.asc Description: PGP signature
Bug#1059421: Say " (which is also called dhclient)"
Package: isc-dhcp-client Version: 4.4.3-P1-4 Severity: minor File: /usr/share/doc/isc-dhcp-client/NEWS.Debian.gz We read > isc-dhcp-client (4.4.3-1) unstable; urgency=medium > > ISC has decided to stop maintaining the client and relay parts of isc-dhcp, > and they will be removed after the 4.4.3 release, keeping only the server > component. Please, consider using an alternative for isc-dhcp-client > (dhclient). Say instead: > ... component. Please, consider using an alternative for isc-dhcp-client > (which is also called dhclient). Otherwise we think the alternative we want is called dhclient.
Bug#1059418: nemo stops attempting to mount SMB servers or shares if an incorrect password is "remembered"
Package: nemo Version: 5.6.4-1 Severity: important X-Debbugs-Cc: debian-b...@ericswpark.com Dear Maintainer, nemo (or some underlying system that nemo uses) has a bug where SMB share/server mounting will lock up, if an incorrect password was entered previously and the password was set to be remembered (for a session or forever). It is possible that the password remember option is not necessary to lock up nemo, however I have not tested this. During this "lock up" state, nemo will appear to be mounting the server/share, with the dialog "Opening (File Sharing)" and the message "You can stop this operation by clicking cancel". However, this dialog will never go away and the server or share will never mount. Steps to reproduce: 1. Click on a server/share entry in the "Network" tab 2. Input incorrect credentials 3. Click on one of the remember credentials options (although this may not be necessary for bug repro) 4. Retry connecting to the server/share again In this bugged state, the incorrect credentials cannot be removed from memory, as it does not show up under seahorse. I am assuming that the previous operation with the incorrect credentials did not succeed, so it didn't save to the keystore yet, but nemo is still waiting on that previous operation to finish, creating some sort of deadlock. Eric -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-16-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nemo depends on: ii cinnamon-desktop-data 5.6.1-1 ii desktop-file-utils 0.26-1 ii gsettings-desktop-schemas 43.0-1 ii gvfs 1.50.3-1 ii libatk1.0-02.46.0-5 ii libc6 2.36-9+deb12u3 ii libcairo-gobject2 1.16.0-7 ii libcairo2 1.16.0-7 ii libcinnamon-desktop4 5.6.1-1 ii libexempi8 2.6.3-1 ii libexif12 0.6.24-1+b1 ii libgail-3-03.24.38-2~deb12u1 ii libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libglib2.0-data2.74.6-2 ii libgsf-1-114 1.14.50-1 ii libgtk-3-0 3.24.38-2~deb12u1 ii libnemo-extension1 5.6.4-1 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-01.50.12+ds-1 ii libselinux13.4-1+b6 ii libx11-6 2:1.8.4-2+deb12u2 ii libxapp1 2.4.2-3 ii libxml22.9.14+dfsg-1.3~deb12u1 ii nemo-data 5.6.4-1 ii shared-mime-info 2.2-1 Versions of packages nemo recommends: ii catdoc 1:0.95-5 ii cinnamon-l10n 5.6.1-2 ii exif0.6.22-3 ii gnome-disk-utility 43.0-1 ii gvfs-backends 1.50.3-1 ii gvfs-fuse 1.50.3-1 ii html2text 1.3.2a-28 ii id3 1.1.2-3 ii librsvg2-common 2.54.7+dfsg-1~deb12u1 ii nemo-fileroller 5.6.1-1 ii odt2txt 0.5-7 ii poppler-utils 22.12.0-2+b1 ii python3 3.11.2-1+b1 ii python3-xlrd1.2.0-3 ii untex 1:1.2-7 Versions of packages nemo suggests: ii eog 43.2-1 ii evince [pdf-viewer] 43.1-2+b1 ii totem43.0-2 ii xdg-user-dirs0.18-1 -- no debconf information
Bug#1058932: RFP: forgejo -- a self-hosted lightweight software forge
Hi, On Mon, 18 Dec 2023 14:24:35 + Wim Bertels wrote: > It would be nice to have it in Debian, > as apart from Redmine there no "easy" to setup project management > software available. There's already an RFP for gitea (#935834), which forgejo is based on. > Some work has already been done? > https://codeberg.org/forgejo-contrib/forgejo-deb Unfortunately, their work isn't compliant with Debian Policy at all. I'll look into the missing dependencies needed for packaging this. Kind regards, Maytham signature.asc Description: This is a digitally signed message part
Bug#1059350: debian-keyring: missing update since 2023.09.24
On Sat, 23 Dec 2023 07:23:12 + Jonathan McDowell wrote: > The debian-keyring package is a convenience package and we only make > efforts to ensure it is up to date around release time. The actual > keyring used by the Debian infrastructure is served via rsync and > matches the version that is currently available via salsa. For further > details on the workflow you might find > https://keyring.debian.org/keyring-workflow.html useful. > > J. I hadn't understood the actual workflow. It's useful information. Thanks!
Bug#1043131: Solution for kernel 6.5 with openafs 1.8.10-1 in debian
Hi Gergely, On Wed, Dec 20, 2023 at 04:26:55PM +0100, Gergely Riskó wrote: > Hey all, > > Yes, OpenAFS is always a pain to work with both on the server and the > client side. :( > > This time I think the client installation is harder than usual, we > have to apply 5 patches. Yes, there's a lot this time. Thanks for putting together your stack -- I would have missed DirEntryFlex in my first pass and thus panic'd my machine during testing. -Ben
Bug#1019751: openafs-client: Instructions to setup a new cell is out of date on Debian 9 and possibly on newer versions
On Wed, Sep 14, 2022 at 05:36:00PM +0100, Jose M Calhariz wrote: > Hi > > I am creating a new OpenAFS cell for testing purposes and found the > the file README.server.gz with some instructions a bit out of date. > This makes the new cell setup dificult to a inexperienced OpenAFS > sysadmin. > > As I found a similar problem with OpenAFS in Debian 11. I think this > bug is still relevant. Yes, it is still relevant, thank you for reporting it. > To setup the new cell I used this commands: > > On krb server: > > kadmin.local > addprinc -randkey -e aes256-cts-hmac-sha1-96 afs > ktadd -k /root/rxkad.keytab afs > getprinc afs > quit > > On afs server: > > mv rxkad.keytab /etc/openafs/server/rxkad.keytab > touch /etc/openafs/server/KeyFile > > > The touch KeyFile is to workaround a small bug in afs-newcell command, > that still search for a old KeyFile with DES material. I'm preparing an upload that attempts to update the documentation to use afs/cell.name and the Kerberos interactions for rxkad-k5. The documentation will include using `akeyconvert` (or `asetkey`) after creating /etc/openafs/server/rxkad.keytab -- the postinst currently runs akeyconvert but I had intended that to only be an aid for the rxkad-k5 transition rather than a permanent feature. -Ben
Bug#1059417: ed: install (r)ed into /usr/bin
Chris Hofstaedtler writes ("Bug#1059417: ed: install (r)ed into /usr/bin"):
> Your package installs ed and red into /bin. For the ongoing Debian
> UsrMerge effort [1] these should move to /usr/bin in the trixie
> cycle.
Hi. FTR, I am not the maintainer.
> I'm attaching a trivial patch to implement such a move.
> As explained in debian/changelog, the update-alternatives calls are
> intentionally kept unchanged, to preserve existing user
> configuration.
I assume that you are following a plan developed by Helmut et al, as
part of the overall Debian usrmerge mitigation plan.
I don't think I agree with this change, as provided, because it will
cause ed to move to /usr/bin on downstreams that don't do usrmerge.
And then, without changing the diversion, the package is actually
broken.
I think there could be an affordance in dh_auto_configure that allows
this all to work properly.
I assume there is some reason why we aren't, in Debian, changing
dh_auto_configure to interpret --bindir=/bin as --bindir=/usr/bin.
> If during the trixie cycle your package will undergo structural
> changes or any other file moves, please also see the wiki and upload
> to experimental first when these changes are done.
I don't believe this is planned, but, once again, I am not the
maintainer.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1059296: hamster-time-tracker: CVE-2023-36250
forwarded 1059296 https://github.com/projecthamster/hamster/issues/750 thanks Hi Moritz, Thanks for bringing this to attention, this was not reported upstream yet. > https://github.com/BrunoTeixeira1996/CVE-2023-36250/blob/main/README.md > sounds a little bogus, I don't see how this crosses any security boundary? AFAICS it does not cross any boundary, but if it allows arbitrary commands to be executed when just importing a CSV file, that would still be unexpected and a security issue. I haven't looked at the code yet, but hope to do so in the common days. Let's keep further discussion about this upstream for now. Gr. Matthijs signature.asc Description: PGP signature
Bug#1058451: ntpsec: FTBFS [Hurd] change Build-Depends: systemd to [linux-any]
On 2023-12-12 04:52, Martin-Éric Racine wrote: Build-Depends: systemd must be changed to systemd [linux-any], since systemd has not been powerted to non-Linux platforms. I suspect that change would be necessary, but not sufficient. In commit 7f969a0ecab4ef3ab50defd4fe9d7e7a47817dbe, I wrote: Build-Depend on systemd This is required for the pkg-config file, so that waf will detect systemd and install the systemd units. If past me was correct, without systemd at build-time, waf will not install the systemd units. Then we will end up with other failures in debian/rules or from the .install files. HURD is the only non-Linux platform that Debian supports these days, right? kFreeBSD is gone, IIRC. The ntpsec package (like ntp before it, IIRC) does not build on HURD anyway. From debian/rules: ifeq (hurd, $(DEB_HOST_ARCH_OS)) # hurd does not provided the system calls needed for ntpd to work. exit 1 endif I see a couple of ways forward here: A) I properly indicate this package does not support HURD. I think I would just replace the "Architecture: any" with "Architecture: linux-any" on binary packages in debian/control, but I would love confirmation on that. B) Someone who cares about HURD figures out how much of this package can reasonably be expected to work and submits a patch. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057228: dolphin-emu: Installs file into /lib/udev/rules.d
Control: tags -1 + patch On Fri, Dec 01, 2023 at 10:48:23PM +0100, Chris Hofstaedtler wrote: > For the ongoing UsrMerge effort [1], /lib needs to become "empty", IOW no > package should install a file there. Instead, files should be installed > into /usr/lib. Here is a trivial patch. Chris diff -Nru dolphin-emu-5.0-19870+dfsg/debian/changelog dolphin-emu-5.0-19870+dfsg/debian/changelog --- dolphin-emu-5.0-19870+dfsg/debian/changelog 2023-09-06 19:42:46.0 +0200 +++ dolphin-emu-5.0-19870+dfsg/debian/changelog 2023-12-24 22:40:43.0 +0100 @@ -1,3 +1,10 @@ +dolphin-emu (5.0-19870+dfsg-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install udev rules file into /usr/lib. (Closes: #1057228) + + -- Chris Hofstaedtler Sun, 24 Dec 2023 22:40:43 +0100 + dolphin-emu (5.0-19870+dfsg-1) unstable; urgency=medium * New upstream beta release. diff -Nru dolphin-emu-5.0-19870+dfsg/debian/dolphin-emu.install dolphin-emu-5.0-19870+dfsg/debian/dolphin-emu.install --- dolphin-emu-5.0-19870+dfsg/debian/dolphin-emu.install 2023-09-06 14:13:20.0 +0200 +++ dolphin-emu-5.0-19870+dfsg/debian/dolphin-emu.install 2023-12-24 22:40:39.0 +0100 @@ -1,4 +1,4 @@ -Data/51-usb-device.rules /lib/udev/rules.d +Data/51-usb-device.rules /usr/lib/udev/rules.d usr/games/dolphin-emu usr/games/dolphin-emu-nogui usr/games/dolphin-tool
Bug#1058511: ntpsec: FTBFS: mv: cannot stat 'debian/tmp/lib/systemd/system/ntpd.service': No such file or directory
Control: fixed 1.2.2+dfsg1-3 This looks to be the same as #1052664. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059076: duplicity: --version returns $version, instead of an actual version
On Thu, 21 Dec 2023 08:18:38 +1000 Alexander Zangerl wrote: > On Wed, 20 Dec 2023 15:57:54 -0600, Kenneth Loafman writes: > >Duplicity has been this way for a long time. Where do you get your sources > >from? > > launchpad, as long as duplicity lived there. > not duplicity.gitlab.io, as that send you nowhere. > gitlab, since. > > anyway, code modified, case closed. I find this logic hard to accept. If you are actually using gitlab, then surely you should see the clear statement of intent on gitlab: upstream uses sourceforge as a source tarball hosting site and clearly expects this to be used. The sourceforge tarball contains a replaced $version. -- Eli Schwartz
Bug#1059417: ed: install (r)ed into /usr/bin
Source: ed Version: 1.19-1 Severity: normal Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi! Your package installs ed and red into /bin. For the ongoing Debian UsrMerge effort [1] these should move to /usr/bin in the trixie cycle. I'm attaching a trivial patch to implement such a move. As explained in debian/changelog, the update-alternatives calls are intentionally kept unchanged, to preserve existing user configuration. However, please still read the wiki page on moving files, especially if you intend to backport to bookworm or earlier. The patch has already been checked by a local dumat copy. If during the trixie cycle your package will undergo structural changes or any other file moves, please also see the wiki and upload to experimental first when these changes are done. Chris [1] https://wiki.debian.org/UsrMerge diff -Nru ed-1.19/debian/changelog ed-1.19/debian/changelog --- ed-1.19/debian/changelog 2023-01-16 08:11:57.0 +0100 +++ ed-1.19/debian/changelog 2023-12-24 22:45:06.0 +0100 @@ -1,3 +1,12 @@ +ed (1.19-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install ed, red into /usr/bin. (Closes: #-1) +Keep update-alternatives calls unchanged, to preserve existing +user configuration. + + -- Chris Hofstaedtler Sun, 24 Dec 2023 22:45:06 +0100 + ed (1.19-1) unstable; urgency=medium * New upstream version 1.19 diff -Nru ed-1.19/debian/rules ed-1.19/debian/rules --- ed-1.19/debian/rules 2023-01-16 08:11:57.0 +0100 +++ ed-1.19/debian/rules 2023-12-24 22:44:57.0 +0100 @@ -13,5 +13,5 @@ .PHONY: override_dh_auto_configure override_dh_auto_configure: - dh_auto_configure -- --bindir=/bin $(CROSS) \ + dh_auto_configure -- $(CROSS) \ $(foreach v,CPPFLAGS CFLAGS LDFLAGS,'$(v)=$($(v))')
Bug#1058961: ntpsec: postinst should check for user:group before adding them
Richard Laager wrote: > Bob Proulx wrote: > > if ! getent passwd ntpsec > /dev/null; then > > addgroup --system --quiet ntpsec > > fi > > if ! getent group ntpsec > /dev/null; then > > adduser --system --quiet --ingroup ntpsec \ > > --no-create-home --home /nonexistent ntpsec > > fi > > Those getent checks have passwd & group swapped, Oop! Drat! I hate it when I do that! And of course it works by accident if one either has neither or both. My bad! > but otherwise, yes, that's what we want. I'll upload a fix > shortly. Thanks! Awesome! :-) Bob
Bug#1056467: python-djangosaml2's autopkg tests fail with Python 3.12
Dear Maintainer, This issue was fixed in the new upload of python3-xmlschema and autopkg tests pass now. Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058194 Kind Regards
Bug#1059416: osspd: install files into /usr (instead of /)
Source: osspd
Version: 1.3.2-13.1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2
Hi!
Your package installs files into /lib/{udev,modules-load.d}.
For the ongoing Debian UsrMerge effort [1] these files should move
to /usr in the trixie cycle.
I'm attaching a patch to implement such a move.
However, please still read the wiki page on moving files, especially
if you intend to backport to bookworm or earlier. The patch has
already been checked by a local dumat copy.
If during the trixie cycle your package will undergo structural
changes or any other file moves, please also see the wiki and upload
to experimental first when these changes are done.
Chris
[1] https://wiki.debian.org/UsrMerge
diff -Nru osspd-1.3.2/debian/changelog osspd-1.3.2/debian/changelog
--- osspd-1.3.2/debian/changelog 2023-02-04 19:49:50.0 +0100
+++ osspd-1.3.2/debian/changelog 2023-12-24 22:18:57.0 +0100
@@ -1,3 +1,12 @@
+osspd (1.3.2-13.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Install all files below /usr. (Closes: #-1)
+For udev rules, use udev.pc to find correct install location.
+For the rest, just hardcode /usr.
+
+ -- Chris Hofstaedtler Sun, 24 Dec 2023 22:18:57 +0100
+
osspd (1.3.2-13.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru osspd-1.3.2/debian/control osspd-1.3.2/debian/control
--- osspd-1.3.2/debian/control 2023-02-04 19:49:50.0 +0100
+++ osspd-1.3.2/debian/control 2023-12-24 22:18:57.0 +0100
@@ -6,7 +6,9 @@
Build-Depends: debhelper-compat (= 13),
libasound2-dev,
libfuse-dev,
- libpulse-dev
+ libpulse-dev,
+ pkgconf,
+ systemd-dev
Standards-Version: 4.3.0
Homepage: https://sourceforge.net/projects/osspd/
Vcs-Browser: https://salsa.debian.org/debian/osspd
diff -Nru osspd-1.3.2/debian/osspd.install osspd-1.3.2/debian/osspd.install
--- osspd-1.3.2/debian/osspd.install 2023-02-04 19:49:50.0 +0100
+++ osspd-1.3.2/debian/osspd.install 2023-12-24 22:17:44.0 +0100
@@ -1,2 +1,2 @@
-lib/udev/rules.d/98-osscuse.rules
+${env:deb_udevdir}/rules.d/98-osscuse.rules
usr/sbin/osspd
diff -Nru osspd-1.3.2/debian/rules osspd-1.3.2/debian/rules
--- osspd-1.3.2/debian/rules 2023-02-04 19:49:50.0 +0100
+++ osspd-1.3.2/debian/rules 2023-12-24 22:18:10.0 +0100
@@ -1,7 +1,8 @@
#!/usr/bin/make -f
+export deb_udevdir = $(shell pkg-config --variable=udevdir udev | sed s,^/,,)
SLAVESDIR=/usr/lib/osspd
-UDEVDIR=/lib/udev/rules.d
+UDEVDIR=/${deb_udevdir}/rules.d
%:
dh $@
@@ -18,7 +19,7 @@
override_dh_install:
dh_install
# adding kmod integration
- install -D -m 0644 debian/osspd.kmod debian/osspd/lib/modules-load.d/osspd.conf
+ install -D -m 0644 debian/osspd.kmod debian/osspd/usr/lib/modules-load.d/osspd.conf
# Disable tests, they require running the osspd
override_dh_auto_test:
Bug#1058194: python-djangosaml2: FTBFS: AttributeError: type object '_PurePosixPath' has no attribute '_from_parts'. Did you mean: '_load_parts'?
Dear Maintainer,
> File "/usr/lib/python3/dist-packages/xmlschema/__init__.py", line 20, in
>
> from .dataobjects import DataElement, DataElementConverter,
>DataBindingConverter
> File "/usr/lib/python3/dist-packages/xmlschema/dataobjects.py", line 27, in
>
> from . import validators
> File "/usr/lib/python3/dist-packages/xmlschema/validators/__init__.py",
>line 38, in
> from .schemas import XMLSchemaMeta, XMLSchemaBase, XMLSchema,
>XMLSchema10, XMLSchema11
> File "/usr/lib/python3/dist-packages/xmlschema/validators/schemas.py", line
>2137, in
> class XMLSchema10(XMLSchemaBase):
> File "/usr/lib/python3/dist-packages/xmlschema/validators/schemas.py", line
>148, in __new__
> meta_schema = meta_schema_class.create_meta_schema(meta_schema_file)
> ^^
> File "/usr/lib/python3/dist-packages/xmlschema/validators/schemas.py", line
>763, in create_meta_schema
> meta_schema = meta_schema_class(source, XSD_NAMESPACE,
>global_maps=global_maps,
>
>^
> File "/usr/lib/python3/dist-packages/xmlschema/validators/schemas.py", line
>357, in __init__
> self.source = XMLResource(source, base_url, allow, defuse, timeout)
> ^
> File "/usr/lib/python3/dist-packages/xmlschema/resources.py", line 511, in
>__init__
> self.parse(source, lazy)
> File "/usr/lib/python3/dist-packages/xmlschema/resources.py", line 746, in
>parse
> url = normalize_url(source, self._base_url)
> ^
> File "/usr/lib/python3/dist-packages/xmlschema/resources.py", line 188, in
>normalize_url
> path = _PurePath.from_uri(url)
> ^^^
> File "/usr/lib/python3/dist-packages/xmlschema/resources.py", line 109, in
>from_uri
> return cls(uri)
>
> File "/usr/lib/python3/dist-packages/xmlschema/resources.py", line 98, in
>__new__
> return cast('_PurePath', cls._from_parts(args))
This issue has been fixed in python3-xmlschema/1.10.0-7 [1] and your package
does build
fine now.
Kind Regards
[1]
https://tracker.debian.org/news/1485130/accepted-python-xmlschema-1100-7-source-into-unstable/
Bug#1058961: ntpsec: postinst should check for user:group before adding them
On 2023-12-18 16:15, Bob Proulx wrote: Package: ntpsec Version: 1.2.2+dfsg1-3 Severity: normal Tags: patch Every time the ntpsec package upgrades it attempts to unconditionally add the ntpsec user and group as per the following postinst snippet. addgroup --system --quiet ntpsec adduser --system --quiet --ingroup ntpsec \ --no-create-home --home /nonexistent ntpsec This logs errors because the user and group already exists. For the record, the "logs" here is critical. These errors show up in the logs, not on stdout. This is why I have never noticed this behavior until now (whether in ntpsec or just generally, having used adduser for years). Please test for the existence of those groups before creating them as other packages such as apt and others do. Adding the following "if" and "getent" checking fixes this using the same method the apt package and others do. if ! getent passwd ntpsec > /dev/null; then addgroup --system --quiet ntpsec fi if ! getent group ntpsec > /dev/null; then adduser --system --quiet --ingroup ntpsec \ --no-create-home --home /nonexistent ntpsec fi Those getent checks have passwd & group swapped, but otherwise, yes, that's what we want. I'll upload a fix shortly. Thanks! -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059415: ntfs-3g: install files into /usr (instead of /)
Source: ntfs-3g
Version: 1:2022.10.3-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2
Hi!
Your package installs files into /. For the ongoing Debian UsrMerge
effort [1] these files should move to /usr in the trixie cycle.
I'm attaching a patch to implement such a move. It is quite
involved, but mostly undoes the move /usr -> /. The upstream
Makefiles ignore --exec-prefix/rootsbindir for the mount.* symlinks,
so I've chosen to re-create them using dh_link instead.
However, please still read the wiki page on moving files, especially
if you intend to backport to bookworm or earlier. The patch has
already been checked by a local dumat copy.
If during the trixie cycle your package will undergo structural
changes or any other file moves, please also see the wiki and upload
to experimental first when these changes are done.
Chris
[1] https://wiki.debian.org/UsrMerge
diff -Nru ntfs-3g-2022.10.3/debian/changelog ntfs-3g-2022.10.3/debian/changelog
--- ntfs-3g-2022.10.3/debian/changelog 2022-10-31 15:14:06.0 +0100
+++ ntfs-3g-2022.10.3/debian/changelog 2023-12-24 21:16:13.0 +0100
@@ -1,3 +1,10 @@
+ntfs-3g (1:2022.10.3-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Install files into /usr instead of /. (Closes: #-1)
+
+ -- Chris Hofstaedtler Sun, 24 Dec 2023 21:16:13 +0100
+
ntfs-3g (1:2022.10.3-1) unstable; urgency=high
* New upstream release:
diff -Nru ntfs-3g-2022.10.3/debian/libntfs-3g89.install ntfs-3g-2022.10.3/debian/libntfs-3g89.install
--- ntfs-3g-2022.10.3/debian/libntfs-3g89.install 2015-10-24 09:41:03.0 +0200
+++ ntfs-3g-2022.10.3/debian/libntfs-3g89.install 2023-12-24 21:16:13.0 +0100
@@ -1 +1 @@
-lib/*/*.so.*
+usr/lib/*/*.so.*
diff -Nru ntfs-3g-2022.10.3/debian/local/ntfs-3g.hook ntfs-3g-2022.10.3/debian/local/ntfs-3g.hook
--- ntfs-3g-2022.10.3/debian/local/ntfs-3g.hook 2014-04-25 20:44:28.0 +0200
+++ ntfs-3g-2022.10.3/debian/local/ntfs-3g.hook 2023-12-24 21:16:13.0 +0100
@@ -17,9 +17,9 @@
. /usr/share/initramfs-tools/hook-functions
-copy_exec /bin/ntfs-3g /bin
+copy_exec /usr/bin/ntfs-3g /usr/bin
-ln -s /bin/ntfs-3g "${DESTDIR}/sbin/mount.ntfs-3g"
-ln -s /bin/ntfs-3g "${DESTDIR}/sbin/mount.ntfs"
+ln -s /usr/bin/ntfs-3g "${DESTDIR}/usr/sbin/mount.ntfs-3g"
+ln -s /usr/bin/ntfs-3g "${DESTDIR}/usr/sbin/mount.ntfs"
exit 0
diff -Nru ntfs-3g-2022.10.3/debian/ntfs-3g.install ntfs-3g-2022.10.3/debian/ntfs-3g.install
--- ntfs-3g-2022.10.3/debian/ntfs-3g.install 2015-10-24 09:40:42.0 +0200
+++ ntfs-3g-2022.10.3/debian/ntfs-3g.install 2023-12-24 21:16:13.0 +0100
@@ -1,4 +1,3 @@
-bin
-sbin
usr/bin
+usr/sbin
usr/share
diff -Nru ntfs-3g-2022.10.3/debian/ntfs-3g.links ntfs-3g-2022.10.3/debian/ntfs-3g.links
--- ntfs-3g-2022.10.3/debian/ntfs-3g.links 2014-04-25 20:44:28.0 +0200
+++ ntfs-3g-2022.10.3/debian/ntfs-3g.links 2023-12-24 21:16:13.0 +0100
@@ -1,4 +1,6 @@
-/sbin/mount.ntfs-3g /sbin/mount.ntfs
+/usr/sbin/mount.ntfs-3g /usr/sbin/mount.ntfs
+/usr/bin/ntfs-3g /usr/sbin/mount.ntfs-3g
+/usr/bin/lowntfs-3g /usr/sbin/mount.lowntfs-3g
/usr/share/man/man8/ntfs-3g.8.gz /usr/share/man/man8/mount.ntfs.8.gz
/usr/share/man/man8/ntfs-3g.8.gz /usr/share/man/man8/lowntfs-3g.8.gz
diff -Nru ntfs-3g-2022.10.3/debian/ntfs-3g-udeb.install ntfs-3g-2022.10.3/debian/ntfs-3g-udeb.install
--- ntfs-3g-2022.10.3/debian/ntfs-3g-udeb.install 2015-10-24 09:42:19.0 +0200
+++ ntfs-3g-2022.10.3/debian/ntfs-3g-udeb.install 2023-12-24 21:16:13.0 +0100
@@ -1,4 +1,3 @@
-bin/ntfs-3g
-lib/*/*.so.*
-sbin/mount.*
-sbin/ntfsresize
+usr/bin/ntfs-3g
+usr/lib/*/*.so.*
+usr/sbin/ntfsresize
diff -Nru ntfs-3g-2022.10.3/debian/ntfs-3g-udeb.links ntfs-3g-2022.10.3/debian/ntfs-3g-udeb.links
--- ntfs-3g-2022.10.3/debian/ntfs-3g-udeb.links 2014-04-25 20:44:28.0 +0200
+++ ntfs-3g-2022.10.3/debian/ntfs-3g-udeb.links 2023-12-24 21:16:13.0 +0100
@@ -1 +1,2 @@
-/sbin/mount.ntfs-3g /sbin/mount.ntfs
+/usr/sbin/mount.ntfs-3g /usr/sbin/mount.ntfs
+/usr/bin/ntfs-3g /usr/sbin/mount.ntfs-3g
diff -Nru ntfs-3g-2022.10.3/debian/rules ntfs-3g-2022.10.3/debian/rules
--- ntfs-3g-2022.10.3/debian/rules 2022-10-31 15:14:06.0 +0100
+++ ntfs-3g-2022.10.3/debian/rules 2023-12-24 21:16:13.0 +0100
@@ -11,7 +11,7 @@
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
-SONAME = $(shell objdump -p debian/tmp/lib/*/libntfs-3g.so.*.* | awk -Fso. '/SONAME/ { print $$2 }')
+SONAME = $(shell objdump -p debian/tmp/usr/lib/*/libntfs-3g.so.*.* | awk -Fso. '/SONAME/ { print $$2 }')
ifeq ($(DEB_HOST_ARCH_OS), linux)
CONFIGURE_FLAGS = --enable-posix-acls
@@ -24,7 +24,7 @@
dh ${@}
override_dh_auto_configure:
- dh_auto_configure -- --exec-prefix=/ --enable-crypto \
+ dh_auto_configure -- --exec-prefix=/usr --enable-crypto \
--enable-extras --enable-xattr-mappings \
--enable-quarantined --disable-ldconfig \
--enable-mount-helper --with-fuse=internal \
@@ -33,13 +33,10 @@
Bug#1059273: missing path /var/lib/ntp/drift-tmp in apparmor.d/usr.sbin.ntpd
On 2023-12-22 05:32, Stefan Bauer wrote: Apparmor denies creation of /var/lib/ntp/drift-tmp. Where are you getting /var/lib/ntp/drift from? The ntpsec package in Debian has (from when both ntp and ntpsec existed in Debian) everything namespaced under "ntpsec". It uses /var/lib/ntpsec/ntp.drift in the default config file. Maybe you have something different set. What does "grep driftfile /etc/ntpsec/ntp.conf" say? -- Richard
Bug#1057570: libgnt: FTBFS: error: invalid use of incomplete typedef ‘PANEL’ {aka ‘struct panel’}
On 2023-12-20 09:57, Sven Joachim wrote: I have not tested it myself, but these errors should be fixed in libgnt 2.14.4 which has been released upstream the other day. See https://keep.imfreedom.org/libgnt/libgnt/rev/2da723f790d6, which explicitly mentions this bug. Thanks for letting me know! -- Richard
Bug#1059414: open-ath9k-htc-firmware: install files into /usr (instead of /)
Source: open-ath9k-htc-firmware Version: 1.4.0-108-gd856466+dfsg1-1.4 Severity: normal Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi! Your package installs firmware files into /lib/firmware. For the ongoing Debian UsrMerge effort [1] these files should move to /usr/lib/firmware in the trixie cycle. I'm attaching a very trivial patch to implement such a move. However, please still read the wiki page on moving files, especially if you intend to backport to bookworm or earlier. The patch has already been checked by a local dumat copy. If during the trixie cycle your package will undergo structural changes or any other file moves, please also see the wiki and upload to experimental first when these changes are done. Chris [1] https://wiki.debian.org/UsrMerge diff -Nru open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/changelog open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/changelog --- open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/changelog 2023-07-26 21:09:48.0 +0200 +++ open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/changelog 2023-12-24 21:24:56.0 +0100 @@ -1,3 +1,10 @@ +open-ath9k-htc-firmware (1.4.0-108-gd856466+dfsg1-1.5) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install all files below /usr. (Closes: #-1) + + -- Chris Hofstaedtler Sun, 24 Dec 2023 21:24:56 +0100 + open-ath9k-htc-firmware (1.4.0-108-gd856466+dfsg1-1.4) unstable; urgency=medium * Non-maintainer upload. diff -Nru open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/firmware-ath9k-htc.install open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/firmware-ath9k-htc.install --- open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/firmware-ath9k-htc.install 2023-07-26 21:09:18.0 +0200 +++ open-ath9k-htc-firmware-1.4.0-108-gd856466+dfsg1/debian/firmware-ath9k-htc.install 2023-12-24 21:24:52.0 +0100 @@ -1,2 +1,2 @@ -target_firmware/htc_*.fw lib/firmware/ath9k_htc/ +target_firmware/htc_*.fw usr/lib/firmware/ath9k_htc/ debian/firmware-ath9k-htc.metainfo.xml usr/share/metainfo
Bug#1059413: h2o: CVE-2023-41337
Source: h2o Version: 2.2.5+dfsg2-8 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for h2o. CVE-2023-41337[0]: | h2o is an HTTP server with support for HTTP/1.x, HTTP/2 and HTTP/3. | In version 2.3.0-beta2 and prior, when h2o is configured to listen | to multiple addresses or ports with each of them using different | backend servers managed by multiple entities, a malicious backend | entity that also has the opportunity to observe or inject packets | exchanged between the client and h2o may misdirect HTTPS requests | going to other backends and observe the contents of that HTTPS | request being sent. The attack involves a victim client trying to | resume a TLS connection and an attacker redirecting the packets to a | different address or port than that intended by the client. The | attacker must already have been configured by the administrator of | h2o to act as a backend to one of the addresses or ports that the | h2o instance listens to. Session IDs and tickets generated by h2o | are not bound to information specific to the server address, port, | or the X.509 certificate, and therefore it is possible for an | attacker to force the victim connection to wrongfully resume against | a different server address or port on which the same h2o instance is | listening. Once a TLS session is misdirected to resume to a server | address / port that is configured to use an attacker-controlled | server as the backend, depending on the configuration, HTTPS | requests from the victim client may be forwarded to the attacker's | server. An H2O instance is vulnerable to this attack only if the | instance is configured to listen to different addresses or ports | using the listen directive at the host level and the instance is | configured to connect to backend servers managed by multiple | entities. A patch is available at commit | 35760540337a47e5150da0f4a66a609fad2ef0ab. As a workaround, one may | stop using using host-level listen directives in favor of global- | level ones. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-41337 https://www.cve.org/CVERecord?id=CVE-2023-41337 [1] https://github.com/h2o/h2o/security/advisories/GHSA-5v5r-rghf-rm6q [2] https://github.com/h2o/h2o/commit/35760540337a47e5150da0f4a66a609fad2ef0ab Please adjust the affected versions in the BTS as needed. If I followed the code correctly then this one is as well present in the older versions ad present in unstable and older, but please double check. Regards, Salvatore
Bug#1058828: thunderbolt-tools: diff for NMU version 0.9.3-6.1
Control: tags 1058828 + pending Dear maintainer, I've prepared an NMU for thunderbolt-tools (versioned as 0.9.3-6.1) and uploaded it to DELAYED/7. Please feel free to upload yourself in the meantime. Chris diff -Nru thunderbolt-tools-0.9.3/debian/changelog thunderbolt-tools-0.9.3/debian/changelog --- thunderbolt-tools-0.9.3/debian/changelog 2022-12-14 13:42:55.0 +0100 +++ thunderbolt-tools-0.9.3/debian/changelog 2023-12-24 14:13:22.0 +0100 @@ -1,3 +1,10 @@ +thunderbolt-tools (0.9.3-6.1) unstable; urgency=medium + + * Non-maintainer upload. + * Skip duplicate installation of tbtacl-write. (Closes: #1058828) + + -- Chris Hofstaedtler Sun, 24 Dec 2023 14:13:22 +0100 + thunderbolt-tools (0.9.3-6) unstable; urgency=medium * Roll in all fixes since 0.9.3, project is now in maintainence diff -Nru thunderbolt-tools-0.9.3/debian/install thunderbolt-tools-0.9.3/debian/install --- thunderbolt-tools-0.9.3/debian/install 2018-04-08 16:43:12.0 +0200 +++ thunderbolt-tools-0.9.3/debian/install 2023-12-24 14:13:14.0 +0100 @@ -1,2 +1 @@ -build_userspace/tbtacl/tbtacl-write lib/udev/ build_userspace/tbtadm/tbtadm usr/bin
Bug#1059344: bookworm-pu: package libdatetime-timezone-perl/1:2.60-1+2023d
On Sun, Dec 24, 2023 at 08:57:22PM +0100, gregor herrmann wrote: > On Sun, 24 Dec 2023 16:19:07 +, Jonathan Wiltshire wrote: > > > On Sat, Dec 23, 2023 at 01:36:11AM +0100, gregor herrmann wrote: > > > I've uploaded libdatetime-timezone-perl/1:2.60-1+2023d to bookworm. > > > As usual, it contains the tzdata data 2023d as a quilt patch. > > Thanks. Should it and the bullseye one be released to stable-updates as > > usual? Text along the lines of the previous SUA? > > Thanks for asking! > I didn't include this request this time, as the changes probably > don't affect too many people and I thought that you might be busy with > other things at this time of the year :) > > But if it's not too much hassle (and without any time pressure > whatsoever), having them in *-updates before the next point releases > would be nice. And basing the wording of the announcements on the > previous examples would be perfect. Ok; the window for today has just closed so I'll sort it out in the next couple of days and by then hopefully tzdata will also be ready. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1059412: netcat-openbsd: install into /usr/bin
Source: netcat-openbsd Version: 1.226-1 Severity: normal Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi! Your package installs nc.openbsd into /bin. For the ongoing Debian UsrMerge effort [1] it should move to /usr/bin in the trixie cycle. I'm attaching a patch to implement such a move. As noted in debian/changelog, the update-alternatives calls are intentionally kept unchanged, to preserve existing user configuration. However, please still read the wiki page on moving files, especially if you intend to backport to bookworm or earlier. The patch has already been checked by a local dumat copy. If during the trixie cycle your package will undergo structural changes or any other file moves, please also see the wiki and upload to experimental first when these changes are done. Chris [1] https://wiki.debian.org/UsrMerge diff -Nru netcat-openbsd-1.226/debian/changelog netcat-openbsd-1.226/debian/changelog --- netcat-openbsd-1.226/debian/changelog 2023-10-16 19:31:08.0 +0200 +++ netcat-openbsd-1.226/debian/changelog 2023-12-24 20:41:47.0 +0100 @@ -1,3 +1,12 @@ +netcat-openbsd (1.226-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install nc.openbsd into /usr/bin. (Closes: #-1) +Keep update-alternatives calls unchanged to preserve user +configuration. + + -- Chris Hofstaedtler Sun, 24 Dec 2023 20:41:47 +0100 + netcat-openbsd (1.226-1) unstable; urgency=medium [ Guilhem Moulin ] diff -Nru netcat-openbsd-1.226/debian/netcat-openbsd.install netcat-openbsd-1.226/debian/netcat-openbsd.install --- netcat-openbsd-1.226/debian/netcat-openbsd.install 2023-10-16 19:31:08.0 +0200 +++ netcat-openbsd-1.226/debian/netcat-openbsd.install 2023-12-24 20:41:19.0 +0100 @@ -1 +1 @@ -nc bin/ +nc usr/bin/ diff -Nru netcat-openbsd-1.226/debian/rules netcat-openbsd-1.226/debian/rules --- netcat-openbsd-1.226/debian/rules 2023-10-16 19:31:08.0 +0200 +++ netcat-openbsd-1.226/debian/rules 2023-12-24 20:41:33.0 +0100 @@ -39,7 +39,7 @@ endif execute_after_dh_install: - mv -T $(prefix)/bin/nc $(prefix)/bin/nc.openbsd + mv -T $(prefix)/usr/bin/nc $(prefix)/usr/bin/nc.openbsd execute_after_dh_installman: mv -T $(man1dir)/nc.1 $(man1dir)/nc_openbsd.1
Bug#1059410: sddm: DisplayServer=wayland caused a complete lockout
Package: sddm Version: 0.20.0-2 Severity: important Dear Maintainer, Thank you for packaging SDDM. After creating a file named /etc/sddm.conf.d/use_wayland.conf with the following content: [General] DisplayServer=wayland SDDM showed a black screen and captured keyboard inputs preventing me from switching to the tty consoles, locking me out of the system. Rebooting multiple times did not help. (I had to resort to booting with systemd.unit=emergency.target) -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sddm depends on: ii adduser 3.137 ii debconf [debconf-2.0] 1.5.82 ii libc6 2.37-13 ii libgcc-s1 13.2.0-8 ii libpam0g1.5.2-9.1 ii libqt5core5a5.15.10+dfsg-5 ii libqt5dbus5 5.15.10+dfsg-5 ii libqt5gui5 5.15.10+dfsg-5 ii libqt5network5 5.15.10+dfsg-5 ii libqt5qml5 5.15.10+dfsg-2 ii libqt5quick55.15.10+dfsg-2 ii libstdc++6 13.2.0-8 ii libsystemd0 255-1 ii libxau6 1:1.0.9-1 ii libxcb-xkb1 1.15-1 ii libxcb1 1.15-1 ii qml-module-qtquick2 5.15.10+dfsg-2 ii x11-common 1:7.7+23 ii xauth 1:1.1.2-1 ii xkb-data2.38-2 ii xserver-xorg [xserver] 1:7.7+23 Versions of packages sddm recommends: ii libpam-systemd 255-1 ii sddm-theme-debian-elarun [sddm-theme] 0.20.0-2 ii sddm-theme-maldives [sddm-theme] 0.20.0-2 ii sddm-theme-maui [sddm-theme] 0.20.0-2 ii sddm-theme-maya [sddm-theme] 0.20.0-2 Versions of packages sddm suggests: ii libpam-kwallet5 5.27.9-1 pn qtvirtualkeyboard-plugin -- debconf information: * shared/default-x-display-manager: sddm sddm/daemon_name: /usr/bin/sddm
Bug#1059411: nano: install files into /usr/bin
Source: nano Version: 7.2-1 Severity: normal Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi! Your package installs files directly into /bin. For the ongoing Debian UsrMerge effort [1] these files should move to /usr/bin in the trixie cycle. I'm attaching a patch to implement such a move. As noted in d/changelog, the update-alternatives calls are intentionally kept unchanged to preserve existing user configuration. However, please still read the wiki page on moving files, especially if you intend to backport to bookworm or earlier. The patch has already been checked by a local dumat copy. If during the trixie cycle your package will undergo structural changes or any other file moves, please also see the wiki and upload to experimental first when these changes are done. Chris [1] https://wiki.debian.org/UsrMerge diff -Nru nano-7.2/debian/changelog nano-7.2/debian/changelog --- nano-7.2/debian/changelog 2023-01-18 16:31:52.0 +0100 +++ nano-7.2/debian/changelog 2023-12-24 20:22:21.0 +0100 @@ -1,3 +1,12 @@ +nano (7.2-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install all files below /usr. (Closes: #-1) +Keep update-alternatives calls unchanged to preserve user +configuration. + + -- Chris Hofstaedtler Sun, 24 Dec 2023 20:22:21 +0100 + nano (7.2-1) unstable; urgency=medium * The "Blue checkmark" release. diff -Nru nano-7.2/debian/rules nano-7.2/debian/rules --- nano-7.2/debian/rules 2022-12-07 23:10:44.0 +0100 +++ nano-7.2/debian/rules 2023-12-24 20:22:21.0 +0100 @@ -13,8 +13,7 @@ tinybuild=$(CURDIR)/build-tiny udebbuild=$(CURDIR)/build-udeb -CONFFLAGS = \ - --bindir=/bin +CONFFLAGS = CONFFLAGS_nano = @@ -54,18 +53,18 @@ dh_auto_install --builddirectory=$(tinybuild) \ --destdir=$(CURDIR)/debian/nano-tiny - mv debian/nano-tiny/bin/nano debian/nano-tiny/bin/nano-tiny + mv debian/nano-tiny/usr/bin/nano debian/nano-tiny/usr/bin/nano-tiny rm -rf $(CURDIR)/debian/nano-tiny/usr/share/man rm -rf $(CURDIR)/debian/nano-tiny/usr/share/info rm -rf $(CURDIR)/debian/nano-tiny/usr/share/nano rm -rf $(CURDIR)/debian/nano-tiny/usr/share/doc/nano - rm -f $(CURDIR)/debian/nano-tiny/bin/rnano + rm -f $(CURDIR)/debian/nano-tiny/usr/bin/rnano ifeq (,$(filter noudeb,$(DEB_BUILD_PROFILES))) dh_auto_install --builddirectory=$(udebbuild) \ --destdir=$(CURDIR)/debian/nano-udeb - rm -rf $(CURDIR)/debian/nano-udeb/usr - rm -f $(CURDIR)/debian/nano-udeb/bin/rnano + rm -rf $(CURDIR)/debian/nano-udeb/usr/share + rm -f $(CURDIR)/debian/nano-udeb/usr/bin/rnano endif override_dh_auto_clean:
Bug#1059344: bookworm-pu: package libdatetime-timezone-perl/1:2.60-1+2023d
On Sun, 24 Dec 2023 16:19:07 +, Jonathan Wiltshire wrote: > On Sat, Dec 23, 2023 at 01:36:11AM +0100, gregor herrmann wrote: > > I've uploaded libdatetime-timezone-perl/1:2.60-1+2023d to bookworm. > > As usual, it contains the tzdata data 2023d as a quilt patch. > Thanks. Should it and the bullseye one be released to stable-updates as > usual? Text along the lines of the previous SUA? Thanks for asking! I didn't include this request this time, as the changes probably don't affect too many people and I thought that you might be busy with other things at this time of the year :) But if it's not too much hassle (and without any time pressure whatsoever), having them in *-updates before the next point releases would be nice. And basing the wording of the announcements on the previous examples would be perfect. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#1058938: bookworm-pu: package onionprobe/1.0.0+ds-2.1+deb12u1
On Sun, Dec 24, 2023 at 05:20:54PM +, Georg Faerber wrote: > On 23-12-24 16:31:37, Jonathan Wiltshire wrote: > > Something has gone wrong with your upload (a rebase maybe?): > > The missing part of the changelog, as per the diff you sent, is > currently not part of the git history, which is problematic, I guess. > > So if my above assumption is correct, I'll ensure that's recorded in git > accordingly, rebuild and upload again. > > Jonathan, does the above make sense? Yes. Just make sure you have the rejection email before you upload again with the same version. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1059409: net-tools: please apply usr-merged layout in unstable
Source: net-tools Version: 2.10-0.1 User: helm...@debian.org Usertags: dep17m2 Control: tags -1 + fixed-in-experimental Hi! net-tools in experimental already applied the usr-merged layout. Please make sure this reaches unstable. (This bug is also helpful for keeping track of the in-progress work.) Thanks, Chris
Bug#1059333: mirage: Please disable LTO
Control: close -1 -- Real issue has been found. There is no need to disable LTO. https://gitlab.com/thomasross/mirage/-/merge_requests/7 -- Regards Sudip
Bug#1059408: mt-st: install files into /usr (instead of /)
Source: mt-st Version: 1.7-1 Severity: normal Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi! Your package installs files into /. For the ongoing Debian UsrMerge effort [1] these files should move to /usr in the trixie cycle. I'm attaching a patch to implement such a move. However, please still read the wiki page on moving files, especially if you intend to backport to bookworm or earlier. The patch has already been checked by a local dumat copy. If during the trixie cycle your package will undergo structural changes or any other file moves, please also see the wiki and upload to experimental first when these changes are done. Chris [1] https://wiki.debian.org/UsrMerge diff -Nru mt-st-1.7/debian/changelog mt-st-1.7/debian/changelog --- mt-st-1.7/debian/changelog 2023-04-20 23:30:00.0 +0200 +++ mt-st-1.7/debian/changelog 2023-12-24 20:14:47.0 +0100 @@ -1,3 +1,11 @@ +mt-st (1.7-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install all files below /usr, and update references to these files. +(Closes: #-1) + + -- Chris Hofstaedtler Sun, 24 Dec 2023 20:14:47 +0100 + mt-st (1.7-1) unstable; urgency=medium * New upstream release fixing a bug triggered by the test suite on diff -Nru mt-st-1.7/debian/mt-st.dirs mt-st-1.7/debian/mt-st.dirs --- mt-st-1.7/debian/mt-st.dirs 2023-04-20 23:30:00.0 +0200 +++ mt-st-1.7/debian/mt-st.dirs 1970-01-01 01:00:00.0 +0100 @@ -1,3 +0,0 @@ -sbin -bin -etc diff -Nru mt-st-1.7/debian/mt-st.files mt-st-1.7/debian/mt-st.files --- mt-st-1.7/debian/mt-st.files 2023-04-20 23:30:00.0 +0200 +++ mt-st-1.7/debian/mt-st.files 1970-01-01 01:00:00.0 +0100 @@ -1,4 +0,0 @@ -sbin/stinit -bin/mt-st -usr/share/man/man?/* -etc/stinit.def diff -Nru mt-st-1.7/debian/mt-st.udev mt-st-1.7/debian/mt-st.udev --- mt-st-1.7/debian/mt-st.udev 2023-04-20 23:30:00.0 +0200 +++ mt-st-1.7/debian/mt-st.udev 2023-12-24 20:13:53.0 +0100 @@ -1,3 +1,3 @@ # Use stinit to set default parameters on st device creation -KERNEL=="st[0-9]", RUN+="/sbin/stinit %n" -KERNEL=="st[0-9]*[0-9]", RUN+="/sbin/stinit %n" +KERNEL=="st[0-9]", RUN+="/usr/sbin/stinit %n" +KERNEL=="st[0-9]*[0-9]", RUN+="/usr/sbin/stinit %n" diff -Nru mt-st-1.7/debian/rules mt-st-1.7/debian/rules --- mt-st-1.7/debian/rules 2023-04-20 23:30:00.0 +0200 +++ mt-st-1.7/debian/rules 2023-12-24 20:14:47.0 +0100 @@ -9,9 +9,9 @@ dh $@ --with bash-completion override_dh_auto_install: - install -m 644 debian/stinit.def $(DESTDIR)/etc/ - install mt $(DESTDIR)/bin/mt-st - install stinit $(DESTDIR)/sbin/ + install -D -m 644 debian/stinit.def $(DESTDIR)/etc/stinit.def + install -D mt $(DESTDIR)/usr/bin/mt-st + install -D stinit $(DESTDIR)/usr/sbin/stinit override_dh_installman: cp mt.1 debian/mt-st.1 diff -Nru mt-st-1.7/debian/tests/simple mt-st-1.7/debian/tests/simple --- mt-st-1.7/debian/tests/simple 2023-04-20 23:30:00.0 +0200 +++ mt-st-1.7/debian/tests/simple 2023-12-24 20:14:07.0 +0100 @@ -11,8 +11,8 @@ # Symlink the installed binaries echo Symlinking the package binaries -ln -s /bin/mt-st "$AUTOPKGTEST_TMP/mt" -ln -s /sbin/stinit "$AUTOPKGTEST_TMP/stinit" +ln -s /usr/bin/mt-st "$AUTOPKGTEST_TMP/mt" +ln -s /usr/sbin/stinit "$AUTOPKGTEST_TMP/stinit" # And then run tests echo Running tests
Bug#1059407: mobile-tweaks: install udev, systemd files below /usr
Source: mobile-tweaks Version: 5 Severity: normal Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi! Your package installs files into /lib. For the ongoing Debian UsrMerge effort [1] these files should move to /usr/lib in the trixie cycle. I'm attaching a patch to implement such a move. However, please still read the wiki page on moving files, especially if you intend to backport to bookworm or earlier. The patch has already been checked by a local dumat copy. If during the trixie cycle your package will undergo structural changes or any other file moves, please also see the wiki and upload to experimental first when these changes are done. Chris [1] https://wiki.debian.org/UsrMerge diff -Nru mobile-tweaks-5/debian/changelog mobile-tweaks-5+nmu1/debian/changelog --- mobile-tweaks-5/debian/changelog 2023-07-18 14:59:15.0 +0200 +++ mobile-tweaks-5+nmu1/debian/changelog 2023-12-24 20:07:52.0 +0100 @@ -1,3 +1,10 @@ +mobile-tweaks (5+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install udev, systemd files below /usr. (Closes: #-1) + + -- Chris Hofstaedtler Sun, 24 Dec 2023 20:07:52 +0100 + mobile-tweaks (5) unstable; urgency=medium [ undef ] diff -Nru mobile-tweaks-5/debian/control mobile-tweaks-5+nmu1/debian/control --- mobile-tweaks-5/debian/control 2022-02-03 07:43:11.0 +0100 +++ mobile-tweaks-5+nmu1/debian/control 2023-12-24 20:07:52.0 +0100 @@ -6,7 +6,8 @@ Arnaud Ferraris , Guido Günther , Henry-Nicolas Tourneur , -Build-Depends: debhelper-compat (= 13), +Build-Depends: debhelper (>= 13.11.6), + debhelper-compat (= 13), dh-exec Standards-Version: 4.5.0 Rules-Requires-Root: no diff -Nru mobile-tweaks-5/debian/librem5-tweaks.install mobile-tweaks-5+nmu1/debian/librem5-tweaks.install --- mobile-tweaks-5/debian/librem5-tweaks.install 2023-07-18 14:59:15.0 +0200 +++ mobile-tweaks-5+nmu1/debian/librem5-tweaks.install 2023-12-24 20:07:30.0 +0100 @@ -1,6 +1,6 @@ # GPSD -librem5/gpsd/99-gnss.rules lib/udev/rules.d/ -librem5/gpsd/gpsd.service.d lib/systemd/system/ +librem5/gpsd/99-gnss.rules usr/lib/udev/rules.d/ +librem5/gpsd/gpsd.service.d usr/lib/systemd/system/ librem5/gpsd/librem5-gpsd etc/default # Device specific gsettings for power management
Bug#1059406: ITP: invidtui -- TUI based Invidious client
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: invidtui Version : 0.3.7 Upstream Authors: darkhz URL : https://github.com/darkhz/invidtui * License : MIT Description : TUI based Invidious client This is an invidious client, which fetches data from invidious instances and displays a user interface in the terminal(TUI), and allows for selecting and playing Youtube audio and video. . Features - Play audio or video - Control the video resolution - Ability to open, view, edit and save m3u8 playlists - Automatically queries the invidious API and selects the best instance - Search for and browse videos, playlists and channels, with history support = Authentication with invidious and management of user feed, playlists and subscriptions - Download video and/or audio
Bug#1059405: lm-sensors: install fancontrol-systemd-sleep into /usr
Source: lm-sensors Version: 1:3.6.0-8 Severity: normal Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi! Your package installs fancontrol-systemd-sleep into /lib/systemd/system-sleep. For the ongoing Debian UsrMerge effort [1] this should move below /usr during the trixie cycle. I'm attaching a patch to implement such a move, using systemd.pc to determine the correct location. However, please still read the wiki page on moving files, especially if you intend to backport to bookworm or earlier. The patch has already been checked by a local dumat copy. If during the trixie cycle your package will undergo structural changes or any other file moves, please also see the wiki and upload to experimental first when these changes are done. Chris [1] https://wiki.debian.org/UsrMerge diff -Nru lm-sensors-3.6.0/debian/changelog lm-sensors-3.6.0/debian/changelog --- lm-sensors-3.6.0/debian/changelog 2023-08-25 21:39:18.0 +0200 +++ lm-sensors-3.6.0/debian/changelog 2023-12-24 19:39:49.0 +0100 @@ -1,3 +1,10 @@ +lm-sensors (1:3.6.0-8.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Use systemd.pc to place systemd sleep files. (Closes: #-1) + + -- Chris Hofstaedtler Sun, 24 Dec 2023 19:39:49 +0100 + lm-sensors (1:3.6.0-8) unstable; urgency=medium * Drop versioned depends on obsolete lsb-base package. diff -Nru lm-sensors-3.6.0/debian/control lm-sensors-3.6.0/debian/control --- lm-sensors-3.6.0/debian/control 2023-08-22 13:30:06.0 +0200 +++ lm-sensors-3.6.0/debian/control 2023-12-24 19:39:49.0 +0100 @@ -1,7 +1,7 @@ Source: lm-sensors Section: utils Priority: optional -Build-Depends: debhelper-compat (= 13), bison, flex +Build-Depends: debhelper-compat (= 13), bison, flex, pkgconf, systemd-dev Rules-Requires-Root: no Standards-Version: 4.6.2 Maintainer: Aurelien Jarno diff -Nru lm-sensors-3.6.0/debian/rules lm-sensors-3.6.0/debian/rules --- lm-sensors-3.6.0/debian/rules 2021-01-25 01:02:46.0 +0100 +++ lm-sensors-3.6.0/debian/rules 2023-12-24 19:39:49.0 +0100 @@ -1,5 +1,7 @@ #!/usr/bin/make -f +export deb_systemdsleepdir = $(shell pkg-config --variable=systemdsleepdir systemd) + %: dh $@ @@ -31,8 +33,7 @@ override_dh_auto_install-indep: $(MAKE) install-etc install-prog-pwm $(MAKEARGS_INDP) - mkdir -p $(CURDIR)/debian/fancontrol/lib/systemd/system-sleep/ - install -m 755 $(CURDIR)/debian/fancontrol-systemd-sleep $(CURDIR)/debian/fancontrol/lib/systemd/system-sleep/fancontrol + install -m 755 -D $(CURDIR)/debian/fancontrol-systemd-sleep $(CURDIR)/debian/fancontrol$(deb_systemdsleepdir)/fancontrol # Make sure /etc/sensors.d/ is not removed touch $(CURDIR)/debian/tmp/etc/sensors.d/.placeholder
Bug#981185: nheko: Similar problem with nheko 0.11.3-2 on bookworm
Package: nheko Version: 0.11.3-2 Followup-For: Bug #981185 X-Debbugs-Cc: n...@protonmail.com Dear Maintainer, I appear to be running into the same/similar problem. When using nheko with: * i3 window manager on X * pipewire with wireplumber session manager As soon as I attempt to place a video call, I get a segfault. However, text chat and voice chat work perfectly. I have attached a stack trace to this report. Sincerely, Nathan -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 6.1.0-16-686-pae (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nheko depends on: ii gstreamer1.0-nice 0.1.21-1 ii gstreamer1.0-qt51.22.0-5+deb12u1 ii libc6 2.36-9+deb12u3 ii libcmark0.30.2 0.30.2-6 ii libcpp-httplib0.11 0.11.4+ds-1+deb12u1 ii libcurl47.88.1-10+deb12u5 ii libevent-core-2.1-7 2.1.12-stable-8 ii libevent-pthreads-2.1-7 2.1.12-stable-8 ii libfmt9 9.1.0+ds1-2 ii libgcc-s1 12.2.0-14 ii libglib2.0-02.74.6-2 ii libgstreamer-plugins-bad1.0-0 1.22.0-4+deb12u4 ii libgstreamer-plugins-base1.0-0 1.22.0-3+deb12u1 ii libgstreamer1.0-0 1.22.0-2 ii liblmdb00.9.24-1 ii libolm3 3.2.13~dfsg-1 ii libqt5core5a5.15.8+dfsg-11 ii libqt5dbus5 5.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5keychain1 0.13.2-5 ii libqt5multimedia5 5.15.8-2 ii libqt5multimedia5-plugins 5.15.8-2 ii libqt5network5 5.15.8+dfsg-11 ii libqt5qml5 5.15.8+dfsg-3 ii libqt5quick55.15.8+dfsg-3 ii libqt5svg5 5.15.8-3 ii libqt5widgets5 5.15.8+dfsg-11 ii libre2-920220601+dfsg-1+b1 ii libspdlog1.10 [libspdlog1.10-fmt9] 1:1.10.0+ds-0.4 ii libssl3 3.0.11-1~deb12u2 ii libstdc++6 12.2.0-14 ii libxcb-ewmh20.4.1-1.1 ii libxcb1 1.15-1 ii qml-module-qt-labs-animation5.15.8+dfsg-3 ii qml-module-qt-labs-platform 5.15.8+dfsg-2 ii qml-module-qt-labs-settings 5.15.8+dfsg-3 ii qml-module-qtgraphicaleffects 5.15.8-2 ii qml-module-qtmultimedia 5.15.8-2 ii qml-module-qtquick-controls25.15.8+dfsg-2 ii qml-module-qtquick-layouts 5.15.8+dfsg-3 ii qml-module-qtquick-particles2 5.15.8+dfsg-3 ii qml-module-qtquick-window2 5.15.8+dfsg-3 ii qml-module-qtquick2 5.15.8+dfsg-3 Versions of packages nheko recommends: ii ca-certificates20230311 ii fonts-noto-color-emoji 2.042-0+deb12u1 ii kimageformat-plugins 5.103.0-2 ii qt5-image-formats-plugins 5.15.8-2 Versions of packages nheko suggests: ii gstreamer1.0-vaapi 1.22.0-2 -- no debconf information Error: signal 11: nheko(_Z17stacktraceHandleri+0x41)[0xffa411] linux-gate.so.1(__kernel_sigreturn+0x0)[0xb7fc6564] /lib/i386-linux-gnu/libgobject-2.0.so.0(+0x1c63b)[0xb6f0c63b] /lib/i386-linux-gnu/libglib-2.0.so.0(g_hash_table_lookup+0x28)[0xb4f6eb08] /lib/i386-linux-gnu/libgobject-2.0.so.0(g_param_spec_pool_lookup+0x99)[0xb6f0e3c9] /lib/i386-linux-gnu/libgobject-2.0.so.0(g_object_set_valist+0x2ee)[0xb6f0984e] /lib/i386-linux-gnu/libgobject-2.0.so.0(g_object_set+0x62)[0xb6f0a0d2] nheko(_ZN13WebRTCSession16addVideoPipelineEi+0x14b)[0xe58d1b] nheko(_ZN13WebRTCSession14createPipelineEii+0x224)[0xe59f84] nheko(_ZN13WebRTCSession13startPipelineEii+0x6c)[0xe5a05c] nheko(_ZN13WebRTCSession11createOfferEN6webrtc8CallTypeEj+0x39)[0xe5a589] nheko(_ZN11CallManager10sendInviteERK7QStringN6webrtc8CallTypeEj+0x6bd)[0xe4c6ed] nheko(+0x7b3ee8)[0xc61ee8] nheko(_ZN11CallManager11qt_metacallEN11QMetaObject4CallEiPPv+0x9e)[0xc7258e] /lib/i386-linux-gnu/libQt5Qml.so.5(+0x29b2a3)[0xb6c9b2a3] /lib/i386-linux-gnu/libQt5Qml.so.5(+0x178cf2)[0xb6b78cf2] /lib/i386-linux-gnu/libQt5Qml.so.5(_ZNK3QV413QObjectMethod12callInternalEPKNS_5ValueES3_i+0x663)[0xb6b7af13] /lib/i386-linux-gnu/libQt5Qml.so.5(_ZN3QV413QObjectMethod11virtualCallEPKNS_14FunctionObjectEPKNS_5ValueES6_i+0x24)[0xb6b7b664] /lib/i386-linux-gnu/libQt5Qml.so.5(+0x19a733)[0xb6b9a733] /lib/i386-linux-gnu/libQt5Qml.so.5(+0x19ddf5)[0xb6b9ddf5]
Bug#1059404: lldpad: install systemd service into /usr
Source: lldpad Version: 1.1+git20221028.aa18720-1 Severity: normal Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi! Your package installs systemd service files into /lib. For the ongoing Debian UsrMerge effort [1] these files should move to /usr/lib in the trixie cycle. I'm attaching a trivial patch to implement this move, mostly undoing the previous move to /lib. However, please still read the wiki page on moving files, especially if you intend to backport to bookworm or earlier. The patch has already been checked by a local dumat copy. If during the trixie cycle your package will undergo structural changes or any other file moves, please also see the wiki and upload to experimental first when these changes are done. Chris [1] https://wiki.debian.org/UsrMerge diff -Nru lldpad-1.1+git20221028.aa18720/debian/changelog lldpad-1.1+git20221028.aa18720/debian/changelog --- lldpad-1.1+git20221028.aa18720/debian/changelog 2023-02-19 22:47:00.0 +0100 +++ lldpad-1.1+git20221028.aa18720/debian/changelog 2023-12-24 19:32:18.0 +0100 @@ -1,3 +1,10 @@ +lldpad (1.1+git20221028.aa18720-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install systemd units into /usr (Closes: #-1) + + -- Chris Hofstaedtler Sun, 24 Dec 2023 19:32:18 +0100 + lldpad (1.1+git20221028.aa18720-1) unstable; urgency=medium * New upstream version 1.1+git20221028.aa18720 diff -Nru lldpad-1.1+git20221028.aa18720/debian/control lldpad-1.1+git20221028.aa18720/debian/control --- lldpad-1.1+git20221028.aa18720/debian/control 2023-02-19 22:28:23.0 +0100 +++ lldpad-1.1+git20221028.aa18720/debian/control 2023-12-24 19:31:45.0 +0100 @@ -7,6 +7,7 @@ Valentin Vidic , tony mancill Build-Depends: + debhelper (>= 13.11.6), debhelper-compat (= 13), pkg-config, libconfig-dev (>= 1.3.2~), diff -Nru lldpad-1.1+git20221028.aa18720/debian/lldpad.install lldpad-1.1+git20221028.aa18720/debian/lldpad.install --- lldpad-1.1+git20221028.aa18720/debian/lldpad.install 2020-02-17 19:37:25.0 +0100 +++ lldpad-1.1+git20221028.aa18720/debian/lldpad.install 2023-12-24 19:28:46.0 +0100 @@ -2,5 +2,5 @@ usr/sbin/* usr/lib/*/liblldp_clif.so.* etc/init.d/lldpad -lib/systemd/system/* +usr/lib/systemd/system/* usr/share/bash-completion/completions/* diff -Nru lldpad-1.1+git20221028.aa18720/debian/rules lldpad-1.1+git20221028.aa18720/debian/rules --- lldpad-1.1+git20221028.aa18720/debian/rules 2020-05-09 19:56:10.0 +0200 +++ lldpad-1.1+git20221028.aa18720/debian/rules 2023-12-24 19:28:39.0 +0100 @@ -17,8 +17,6 @@ override_dh_auto_install: dh_auto_install install -D lldpad.init debian/tmp/etc/init.d/lldpad - mkdir -p debian/tmp/lib/systemd - mv debian/tmp/usr/lib/systemd/system debian/tmp/lib/systemd override_dh_installinit: dh_installinit -plldpad --only-scripts
Bug#1059344: libdatetime-timezone-perl 2.60-1+2023d flagged for acceptance
package release.debian.org tags 1059344 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: libdatetime-timezone-perl Version: 2.60-1+2023d Explanation: update data to Olson database version 2023d (changes for Antarctica and Greenland)
Bug#1059235: fish 3.6.0-3.1+deb12u1 flagged for acceptance
package release.debian.org tags 1059235 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: fish Version: 3.6.0-3.1+deb12u1 Explanation: handle Unicode non-printing characters safely when given as command substitution [CVE-2023-49284]
Bug#1056969: swupdate 2022.12+dfsg-4+deb12u1 flagged for acceptance
package release.debian.org tags 1056969 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: swupdate Version: 2022.12+dfsg-4+deb12u1 Explanation: prevent acquiring root privileges through inappropriate socket mode
Bug#1054466: localslackirc 1.17-1.1+deb12u1 flagged for acceptance
package release.debian.org tags 1054466 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: localslackirc Version: 1.17-1.1+deb12u1 Explanation: send authorization and cookie headers to the websocket
Bug#1059403: collectd hugepages plugin reports spurious warnings trying to open demote
Package: collectd Version: 5.12.0-14 Severity: normal Tags: upstream patch Dear Maintainer, Thanks for packaging collectd! After upgrading one of my servers to bookworm, I noticed that collectd started emitting warnings about being unable to read demote files. It seems this was reported upstream at https://github.com/collectd/collectd/issues/3993 and a commit was merged into main: https://github.com/collectd/collectd/commit/4cebbfc1ed4b44644d981df996a8ca941e38e8a1 It would be great if this patch could be incorporated into the next stable point release for bookworm. If you agree but are short on time, I'm happy (and motivated) to do the work. Thanks, --Joe -- System Information: Debian Release: 12.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'stable-debug') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-15-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages collectd depends on: ii collectd-core 5.12.0-14 ii libc6 2.36-9+deb12u3 ii librrd81.7.2-4+b8
Bug#1059402: bookworm-pu: package postfix/3.7.6-0+deb12u2
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
(Please provide enough information to help the release team
to judge the request efficiently. E.g. by filling in the
sections below.)
[ Reason ]
This is another of the regular postfix maintenance updates. It
encompasses three upstream updates (3.7.7, 3.7.8, and 3.7.9) because
life intervened and I got behind. This one is of particular importance/
urgency since it includes a new setting to address CVE-2023-51764.
[ Impact ]
Bugs remain unfixed, CVE-2023-51764 can be partially mitigated, but not
fully resolved.
[ Tests ]
There is a high level autopkgtest.
[ Risks ]
Risks are low. These have all been released as part of upstream
maintenance and no regressions have been reported. There are no changes
in Debian packaging.
[ 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
[X] the issue is verified as fixed in unstable
[ Changes ]
* 3.7.7
- Bugfix (bug introduced: 20140218): when opportunistic TLS fails
during or after the handshake, don't require that a probe
message spent a minimum time-in-queue before falling back to
plaintext. Problem reported by Serg. File: smtp/smtp.h.
- Bugfix (defect introduced: 19980207): the valid_hostname()
check in the Postfix DNS client library was blocking unusual
but legitimate wildcard names (*.name) in some DNS lookup
results and lookup requests. Examples:
name class/type value
*.one.example IN CNAME *.other.example
*.other.example IN A 10.0.0.1
*.other.example IN TLSA ..certificate info...
Such syntax is blesed in RFC 1034 section 4.3.3.
This problem was reported first in the context of TLSA
record lookups. Files: util/valid_hostname.[hc],
* 3.7.8
- Bugfix (defect introduced Postfix 2.5, 20080104): the Postfix
SMTP server was waiting for a client command instead of
replying immediately, after a client certificate verification
error in TLS wrappermode. Reported by Andreas Kinzler. File:
smtpd/smtpd.c.
- Usability: the Postfix SMTP server now attempts to log the
SASL username after authentication failure. In Postfix
logging, this appends ", sasl_username=xxx" after the reason
for SASL authentication failure. The logging replaces an
unavailable reason with "(reason unavailable)", and replaces
an unavailable sasl_username with "(unavailable)". Based
on code by Jozsef Kadlecsik. Files: xsasl/xsasl_server.c,
xsasl/xsasl_cyrus_server.c, smtpd/smtpd_sasl_glue.c.
- Bugfix (defect introduced: Postfix 2.11): in forward_path,
the expression ${recipient_delimiter} would expand to an
empty string when a recipient address had no recipient
delimiter. Fixed by restoring Postfix 2.10 behavior to use
a configured recipient delimiter value. Reported by Tod
A. Sandman. Files: proto/postconf.proto, local/local_expand.c.
* 3.7.9 (Closes: #1059230)
- Addresses CVE-2023-51764, requires configuration change
- Security: with "smtpd_forbid_bare_newline = yes" (default
"no" for Postfix < 3.9), reply with "Error: bare
received" and disconnect when an SMTP client sends a line
ending in , violating the RFC 5321 requirement that
lines must end in . This prevents SMTP smuggling
attacks that target a recipient at a Postfix server. For
backwards compatibility, local clients are excluded by
default with "smtpd_forbid_bare_newline_exclusions =
$mynetworks". Files: mantools/postlink, proto/postconf.proto,
global/mail_params.h, global/smtp_stream.c, global/smtp_stream.h
[ Other info ]
The CVE fix requires a configuration change, which is not set be default
as it would likely break some configuratins. We should be sure to
mention that in the SUA.
Scott K
diff -Nru postfix-3.7.6/debian/changelog postfix-3.7.9/debian/changelog
--- postfix-3.7.6/debian/changelog 2023-07-05 17:18:24.0 -0400
+++ postfix-3.7.9/debian/changelog 2023-12-24 12:33:24.0 -0500
@@ -1,3 +1,58 @@
+postfix (3.7.9-0+deb12u1) bookworm; urgency=medium
+
+ [Wietse Venema]
+
+ * 3.7.7
+- Bugfix (bug introduced: 20140218): when opportunistic TLS fails
+ during or after the handshake, don't require that a probe
+ message spent a minimum time-in-queue before falling back to
+ plaintext. Problem reported by Serg. File: smtp/smtp.h.
+- Bugfix (defect introduced: 19980207): the valid_hostname()
+ check in the Postfix DNS client library was blocking unusual
+ but legitimate wildcard names (*.name) in some DNS lookup
+ results and lookup requests. Examples:
+ name class/type value
+*.one.example IN CNAME *.other.example
+
Bug#1059401: [INTL:ro] Romanian debconf templates translation of "x2gobroker"
Package: x2gobroker Version: 0.0.4.3-4 Severity: wishlist Tags: l10n, patch Dear Maintainer, Please find attached the Romanian translation of the «x2gobroker_debconf» file. A draft has been posted to the debian-l10n-romanian mailing list allowing for review. Please add it to your next package revision. - Thanks, Remus-Gabriel# Mesajele în limba românÄ pentru pachetul x2gobroker (debconf). # Romanian translation of x2gobroker (debconf). # Copyright © 2023 THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the x2gobroker package. # # Remus-Gabriel Chelu , 2023 # msgid "" msgstr "" "Project-Id-Version: x2gobroker\n" "Report-Msgid-Bugs-To: x2gobro...@packages.debian.org\n" "POT-Creation-Date: 2019-02-03 11:44+0100\n" "PO-Revision-Date: 2023-12-17 00:13+0100\n" "Last-Translator: Remus-Gabriel Chelu \n" "Language-Team: Romanian \n" "Language: ro\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n==0 || (n!=1 && n%100>=1 && " "n%100<=19) ? 1 : 2);\n" "X-Generator: Poedit 3.2.2\n" #. Type: boolean #. Description #: ../x2gobroker-ssh.templates:2001 msgid "Create group for X2Go Broker SSH access now?" msgstr "" "DoriÈi sÄ creaÈi acum un grup pentru accesul SSH la brokerul de sesiune X2Go?" #. Type: boolean #. Description #: ../x2gobroker-ssh.templates:2001 msgid "" "In X2Go Session Broker, SSH-based broker access is controlled via the broker " "users' membership in a dedicated group (default: x2gobroker-users)." msgstr "" "Ãn brokerul de sesiune X2Go, accesul la brokerul bazat pe SSH este controlat " "prin apartenenÈa utilizatorilor brokerului la un grup dedicat (implicit: " "x2gobroker-users)." #. Type: boolean #. Description #: ../x2gobroker-ssh.templates:2001 msgid "" "If this group is not created now, you will be asked to assign this privilege " "to an existing group instead." msgstr "" "DacÄ acest grup nu este creat acum, vi se va cere sÄ atribuiÈi acest " "privilegiu unui grup existent." #. Type: boolean #. Description #: ../x2gobroker-ssh.templates:3001 msgid "Use an already existing group for X2Go Session Broker SSH access?" msgstr "" "UtilizaÈi un grup deja existent pentru accesul SSH la brokerul de sesiune " "X2Go?" #. Type: boolean #. Description #: ../x2gobroker-ssh.templates:3001 msgid "" "If there already exists a group (e.g. in an LDAP database) that you would " "like to use for controlling X2Go Session Broker SSH access with, then you " "can specify this group name with the next step." msgstr "" "DacÄ existÄ deja un grup (de exemplu, într-o bazÄ de date LDAP) pe care " "doriÈi sÄ Ã®l utilizaÈi pentru a controla accesul SSH la brokerul de sesiune " "X2Go, atunci puteÈi specifica acest nume de grup în pasul urmÄtor." #. Type: boolean #. Description #: ../x2gobroker-ssh.templates:4001 msgid "Set up X2Go Session Broker SSH access later?" msgstr "ConfiguraÈi mai târziu accesul SSH la brokerul de sesiune X2Go?" #. Type: boolean #. Description #: ../x2gobroker-ssh.templates:4001 msgid "" "Without an existing group for X2Go Session Broker SSH access, the SSH broker " "will not be usable by users. You have to set up things later, either " "manually or via this configuration helper." msgstr "" "FÄrÄ un grup existent pentru accesul SSH la brokerul de sesiune X2Go, " "brokerul SSH nu va putea fi utilizat de cÄtre utilizatori. Trebuie sÄ " "configuraÈi lucrurile mai târziu, fie manual, fie prin intermediul acestui " "ajutor de configurare." #. Type: boolean #. Description #: ../x2gobroker-ssh.templates:4001 msgid "" "A manual setup is only recommended, if you really know what have to do for " "this." msgstr "" "O configurare manualÄ este recomandatÄ doar dacÄ ÈtiÈi cu adevÄrat ce " "trebuie sÄ faceÈi pentru aceasta." #. Type: boolean #. Description #: ../x2gobroker-ssh.templates:4001 msgid "Alternatively, the setup questions can be asked once more..." msgstr "Alternativ, întrebÄrile de configurare pot fi puse încÄ o datÄ..." #. Type: string #. Description #: ../x2gobroker-ssh.templates:5001 msgid "X2Go Session Broker SSH access group:" msgstr "Grupul de acces SSH la brokerul de sesiune X2Go:" #. Type: string #. Description #: ../x2gobroker-ssh.templates:5001 msgid "" "Please specify the group name for users with full X2Go Session Broker access " "via SSH now." msgstr "" "VÄ rugÄm sÄ specificaÈi acum numele grupului pentru utilizatorii cu acces " "complet la brokerul de sesiune X2Go prin SSH." #. Type: boolean #. Description #: ../x2gobroker-ssh.templates:6001 msgid "" "Delete the group that was formerly used for X2Go Session Broker SSH access?" msgstr "" "ÈtergeÈi grupul care a fost utilizat anterior pentru accesul SSH la brokerul " "de sesiune X2Go?" #. Type: boolean #. Description #: ../x2gobroker-ssh.templates:6001 msgid "The group for X2Go Session Broker SSH access has been modified." msgstr "" "Grupul
Bug#1059400: kubetail: Broken on Debian Bookworm ("syntax error near unexpected token") due to Bash 5.2 incompatibility
Package: kubetail Version: 1.6.5-2 Severity: important Tags: upstream Dear Maintainer, Unfortunately, attempting to use kubetail fails on Debian Bookworm. In particular, any trivial use reports a "syntax error", as follows: ``` $ kubetail nginx Will tail 2 logs... nginx-deployment-7c79c4bf97-jdmkg nginx-deployment-7c79c4bf97-p7bxr /usr/bin/kubetail: eval: line 326: syntax error near unexpected token `kubectl' /usr/bin/kubetail: eval: line 326: `kubectl logs nginx-deployment-7c79c4bf97-jdmkg nginx -f=true --since=10s --tail=-1| while read -r; do echo "[nginx-deployment-7c79c4bf97-jdmkg] $REPLY " | tail -n +1; done kubectl logs nginx-deployment-7c79c4bf97-p7bxr nginx -f=true --since=10s --tail=-1| while read -r; do echo "[nginx-deployment-7c79c4bf97-p7bxr] $REPLY " | tail -n +1; done' ``` This error has been reported and fixed upstream, with the root cause being a breaking change in Bash 5.2, the version used in Bookworm. Upstream issue: https://github.com/johanhaleby/kubetail/issues/133 A fix for this issue has been merged in Kubetail 1.6.17: https://github.com/johanhaleby/kubetail/pull/134 I'd be grateful if the version in Debian Bookworm can be updated or include the fix above, as otherwise the package can not be used unless one resolts to any of the workarounds published in the upstream issue. Regards. -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.0-rc6-1001-mainline-git-00303-g3f82f1c3a036 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect -- no debconf information
Bug#1059395: libacl1, debhelper: changelog handling with --no-trim seems to be not binNMU-safe
Control: reassign -1 debhelper Control: found -1 debhelper/13.11.4 On Sun, 2023-12-24 at 14:27:22 +, Simon McVittie wrote: > Package: libacl1,debhelper > Control: found -1 libacl1/2.3.1-3 > Control: found -1 debhelper/13.11.9 > Severity: important > X-Debbugs-Cc: debian-rele...@lists.debian.org > I notice that libacl1 uses dh_installchangelogs --no-trim in its > debian/rules to suppress the default exclusion of older changelog > entries. It appears that using that option also suppresses the separation > of binNMU changelog entries into a separate file? I think it probably > should not, because the trimming of old changelog entries is merely > a nice-to-have to save some disk space, but the separation of binNMU > changelog entries is functionally necessary if we want packages to remain > multiarch co-installable across binNMUs. Yes, I don't see why the old behavior, when requested explicitly, would no longer behave as previously. This would seem like a regression in debhelper due to the trimming handling. > A sourceful upload of libacl1 would temporarily address this (until the > next binNMU) by not being a binNMU, but would not be a long-term solution, > unless we stop using binNMUs entirely and replace them with "no-changes" > machine-assisted sourceful uploads like Ubuntu has done. I've uploaded acl now with some minor pending changes I had queued as a temporary workaround. But the obvious and correct way forward to me is to fix debhelper (instead of having to change all affected packages, or having to stop using binNMUs due to this…). And I've just tested this and it also affects the current debhelper version in Debian (stable) bookworm. :/ Thanks, Guillem
Bug#1058938: bookworm-pu: package onionprobe/1.0.0+ds-2.1+deb12u1
Hi, Sorry for the additional work: On 23-12-24 16:31:37, Jonathan Wiltshire wrote: > Something has gone wrong with your upload (a rebase maybe?): The missing part of the changelog, as per the diff you sent, is currently not part of the git history, which is problematic, I guess. So if my above assumption is correct, I'll ensure that's recorded in git accordingly, rebuild and upload again. Jonathan, does the above make sense? Thanks, Georg
Bug#1059158: libreoffice-core-nogui: Can't open a spreadsheet from python uno because libforuilo.so is missing.
retitle 1059158 libreoffice-core-nogui: Can't open a spreadsheet from python uno on 32bits because libforuilo.so is missing. thanks Hi, Am 20.12.23 um 18:42 schrieb Gerard Henri Pille: * What exactly did you do (or not do) that was effective (or ineffective)? So this is even 32bit specific since on 64bit libforuilo.so is subsumed by libvmergedlo.so. (Which cannot be done on 32bit since libmergedlo.so is probably too big for 32bit to actually link it). Using arm64 (yes, even on rpi) would have rules this exact bug out ;) But given libforuilo.so is inside libmergedlo.so in 64bit archs anyway we can just include it here since as said i's included in 64bits packages nevertheless. Already in git (you got the mails). No idea when this actually will end up in stable, though :) Regards, Rene
Bug#1059388: git-debrebase: found two-parent merge, how to cope?
Hi.
I'm going to reply off the cuff in the hope of getting you unstuck.
If this email doesn't nsuffice I'll take a look at your git
branch. So please let me know how you get on.
Philipp Kern writes ("Bug#1059388: git-debrebase: found two-parent merge, how
to cope?"):
> In the absence of a better venue of asking this question (there seems to
> be no mailing list): I have an upstream repository that contains a
> two-parent merge for some reason (https://github.com/twosigma/nsncd, of
> all the things merging a CLA into the repository). dgit bails out with
> this:
In git-debrebase, the upstream branches are supposed to be able to
contain any arbitrary stuff.
gdr is supposed to stop looking in detail at the commit structure as
soon as it finds the anchor, ie the last merge from into Debian.
These must all be done with gdr new-upstream.
> | Format `3.0 (quilt)', need to check/update patch stack
> | examining quilt state (multiple patches, linear mode)
..
> | git-debrebase: error: found unprocessable commit, cannot cope: general
> two-parent merge (e3de17c274315bab561664ac57e46472670545cf)
I suspect that the upstream branch has been merged directly into your
packaging branch, rather than using git-debrebase --new-upstream ?
> I have so far forced an --anchor manually upon git-debrebase, which
> worked, but is also very tedious to pass everywhere. Is this something
> that will auto-fix itself on the next upstream release because dgit will
> properly discard the history pre the current upstream release? I was at
> least hoping that it would disappear with the first regular upload - but
> this did not happen.
..
> Is there something I can do for dgit to accept the current state of the
> repository as canonical up to the point where the Debian packaging was
> modified/forked off. The snags are upstream's prior packaging as found
> in the upstream repository, which does not seem to be uncommon to me
> either.
I'm not sure using --anchor is wise. Certainly not routinely.
new-upstream would generate a new anchor, so you could use --anchor
once, assuming you're sure about which commit it is.
But if you merged from upstream *on top* of commits represending the
delta, that won't do the right thing. It will abolish the delta and
start to try to treat them as part of the upstream, and then your next
attempt to make a source package will fail.
One thing you could try would be an invocation of
git-debrebase --experimental-merge-resolution new-upstream
Or indeed
git-debrebase --status
I think if my hypothesis about what has happened to your branch is
correct, my suggested remedy would be to make a new branch starting
just before the mistake, redo all subsequent work "properly" - without
introduce any merges other than via git-debrebase new-upstream.
Then when you have done that the result should be tressame to your
"messed up" branch, but have correct gdr history.
Then "git merge -s ours broken-branch" will make your fixed version ff
from the broken one and from then I hope everything will be fine?
(Maybe I should look up which branch of a completely tree-identical
merge gdr looks at, but I'm hoping that it's the one that is implied
by following the non-contributing parent of git merge -s ours.)
Don't spend too long on wrestling with this. I can probably fix it up
in an hour or so.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1059345: libdatetime-timezone-perl 2.47-1+2023d flagged for acceptance
package release.debian.org tags 1059345 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: libdatetime-timezone-perl Version: 2.47-1+2023d Explanation: update data to Olson database version 2023d (changes for Antarctica and Greenland)
Bug#1027779: ITP: receptor -- Link controllers with executors across a mesh of nodes
Package: wnpp Followup-For: Bug #1027779 ITP for golang-github-songgao-water: #1059399
Bug#1059399: ITP: golang-github-songgao-water -- A simple TUN/TAP library written in native Go.
Package: wnpp Severity: wishlist Owner: Jérémy Lal * Package name: golang-github-songgao-water Version : 0.0~git20200317.2b4b6d7-1 Upstream Author : Song Gao * URL : https://github.com/songgao/water * License : BSD-3-clause Programming Lang: Go Description : Simple TUN/TAP library for Go language This library is designed to be simple and efficient. It . * wraps almost only syscalls and uses only Go standard types; * exposes standard interfaces; plays well with standard packages like io, bufio, etc.. * does not handle memory management (allocating/destructing slice). It's up to user to decide whether/how to reuse buffers. * has partial support for MacOS or Windows This package will be go-team maintained, and seems to be pretty popular. This is a build-dependency for receptor, a meshed network daemon needed by awx.
Bug#1058938: bookworm-pu: package onionprobe/1.0.0+ds-2.1+deb12u1
On Fri, Dec 22, 2023 at 12:08:41PM +, Georg Faerber wrote: > On 23-12-21 21:52:08, Jonathan Wiltshire wrote: > > Please go ahead. > > Thanks, uploaded. Something has gone wrong with your upload (a rebase maybe?): | 1.0.0+ds/debian/changelog onionprobe-1.0.0+ds/debian/changelog | --- onionprobe-1.0.0+ds/debian/changelog 2022-10-15 10:32:07.0 + | +++ onionprobe-1.0.0+ds/debian/changelog 2023-12-18 14:30:56.0 + | @@ -1,9 +1,10 @@ | -onionprobe (1.0.0+ds-2.1) unstable; urgency=medium | +onionprobe (1.0.0+ds-2.1+deb12u1) bookworm; urgency=medium | | - * Non-maintainer upload. | - * No source change upload to rebuild with debhelper 13.10. | + * debian/patches: | +- Pull in upstream fix to silence Tor if generating hashed passwords. | + (Closes: #1053204) | | - -- Michael Biebl Sat, 15 Oct 2022 12:32:07 +0200 | + -- Georg Faerber Mon, 18 Dec 2023 14:30:56 + | | onionprobe (1.0.0+ds-2) unstable; urgency=medium I will reject so that you can upload again with the same version. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1027779: ITP: receptor -- Link controllers with executors across a mesh of nodes
Package: wnpp Followup-For: Bug #1027779 Missing dependencies that I might bundle in a multiple upstream tarball, because they look so specific: - golang-github-prep-socketpair-dev - golang-github-jupp0r-go-priority-queue-dev Missing, needs to be packaged, some are already being worked on: - golang-github-songgao-water (#inprocess) - golang-github-k8s-io-api-dev - golang-github-k8s-io-apimachinery-dev (#1012720) - golang-github-k8s-io-client-go-dev The k8s ones are missing golang-github-google-gnostic-models-dev, which is in NEW, #1053000.
Bug#1059344: bookworm-pu: package libdatetime-timezone-perl/1:2.60-1+2023d
On Sat, Dec 23, 2023 at 01:36:11AM +0100, gregor herrmann wrote: > > I've uploaded libdatetime-timezone-perl/1:2.60-1+2023d to bookworm. > As usual, it contains the tzdata data 2023d as a quilt patch. Thanks. Should it and the bullseye one be released to stable-updates as usual? Text along the lines of the previous SUA? Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#983584: paraview: reproducible builds: Embeds running kernel in header files and binaries
Source: paraview Followup-For: Bug #983584 X-Debbugs-Cc: vagr...@reproducible-builds.org, reproducible-b...@lists.alioth.debian.org Control: fixed -1 paraview/5.11.0~rc1+dfsg-1 Control: close -1 The patch provided has been included into the Debian package; however note also that the third party library (catalyst) that it patched has been removed from the upstream codebase, so the patch is commented-out in the patch series file.
Bug#1026381: python-django-health-check: please make the build reproducible
Source: python-django-health-check
Followup-For: Bug #1026381
X-Debbugs-Cc: la...@debian.org, reproducible-b...@lists.alioth.debian.org
I believe that this bug should disappear on build hosts that are using
dh-python version 6.20231204 or greater, where a fix for bug #1057432 means
that files with a dot ('.') prefix are excluded from binary packages.
Bug#1010279: python-iso8601: please make the build reproducible
Source: python-iso8601 Followup-For: Bug #1010279 X-Debbugs-Cc: la...@debian.org, reproducible-b...@lists.alioth.debian.org >From some recent build results, it seems there is a '.hypothesis' directory that is also created within the project's directory at build-time, so it would also be worth filtering that directory in addition to the '.pytest_cache' dir. After searching around on sources.debian.org to find out how other packages handle extraneous files like these, I learned of the 'debian/clean' file; that might be a slightly neater (fewer scripted statements) exclusion approach. Either way: I think that when building with dh-python/6.20231204 onwards, these directories are automatically excluded from the binary package thanks to the fix for #1056291 (an obscure filesystem os.walk bug in dh-python).
Bug#1059398: httping: New Upstream Version
Hello Olaf. On 24/12/23 03:39 PM, Olaf van der Spek wrote: > Hi, > > A new version has been released upstream: > https://github.com/folkertvanheusden/HTTPing/releases Yes, I started looking to it. I am in contact with the upstream developer as well. Thank you
Bug#1059398: httping: New Upstream Version
Package: httping Version: 2.5-5.2+b1 Severity: wishlist X-Debbugs-Cc: olafvds...@gmail.com Hi, A new version has been released upstream: https://github.com/folkertvanheusden/HTTPing/releases Olaf -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.8-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages httping depends on: ii libc6 2.37-13 ii libfftw3-double3 3.3.10-1 ii libncursesw6 6.4+20231209-1 ii libssl3 3.1.4-2 ii libtinfo6 6.4+20231209-1 ii openssl 3.1.4-2 httping recommends no packages. httping suggests no packages. -- no debconf information
Bug#1059397: extrepo: please consider fish and zsh autocompletion for subcommands like "search" and "enable"
Package: extrepo Version: 0.12 Severity: wishlist X-Debbugs-Cc: kni9p...@anonaddy.me Dear Maintainer, please consider adding fish and zsh autocompletion for subcommands like "search" and "enable" as this would greatly improve user experience. Thanks -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages extrepo depends on: ii gpgv 2.2.40-1.1 ii libcryptx-perl0.080-2 ii libdpkg-perl 1.22.2 ii libwww-perl 6.72-1 ii libyaml-libyaml-perl 0.86+ds-1 ii perl 5.36.0-10 Versions of packages extrepo recommends: ii extrepo-offline-data 1.0.3 extrepo suggests no packages. -- Configuration Files: /etc/extrepo/config.yaml changed: --- url: https://extrepo-team.pages.debian.net/extrepo-data dist: debian version: sid enabled_policies: - main - contrib - non-free -- no debconf information
Bug#1059382: kitty: Text rendering change
Hi Nilesh On 12/24/23 03:19, Nilesh Patra wrote: Thanks for reporting it and taking the time to bisect it as well! The issue is that on a dark background with light text everything is made bold, whereas previously this was not bold. I think it is wise to inform users that `text_composition_strategy legacy` restores the old defaults (similar to the version in stable) and/or refer to the manual page: https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.text_composition_strategy If kitty can read a system-wide config it might be set there. It can, but honestly I don't want to diverge from upstream here. Everyone may not like the said change and enforcing a system wide config for a composition change isn't something that I'm willing to do. If you could, please consider opening up an upstream issue to see if we can reach a common ground. If not, I'll just add a d/NEWS entry informing users/sysadmin about this change. I'm fine with adding a d/NEWS entry, that is mainly the reason why I reported the bug. I think it's worth a mention because it confused me quite a bit :) Cheers, Wesley -- Wesley Schwengle E: wes...@schwengle.net
Bug#1059396: PGP/GPG handling wrong
Package: evolution Version: 3.50.2-1 Severity: critical I send all my e-mails with a PGP signature. If the recipient replies including my signature, the email is displayed as "partially signed with GPG" and the reply is hidden. This is incorrect, as it suggests that the reply is partially signed correctly, but this is fundamentally wrong, as the signature does not originate from the sender. In addition, despite the incorrect signature, only the incorrectly signed text is displayed and not the reply. CU Jörg -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-2-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 evolution depends on: ii dbus [default-dbus-system-bus] 1.14.10-3 ii evolution-common3.50.2-1 ii evolution-data-server 3.50.2-1 ii libc6 2.37-12 ii libcamel-1.2-64 3.50.2-1 ii libclutter-gtk-1.0-01.8.4-4+b1 ii libecal-2.0-2 3.50.2-1 ii libedataserver-1.2-27 3.50.2-1 ii libevolution3.50.2-1 ii libglib2.0-02.78.3-1 ii libgtk-3-0 3.24.38-6 ii libical33.0.17-1 ii libnotify4 0.8.3-1 ii libwebkit2gtk-4.1-0 2.42.4-1 ii libxml2 2.9.14+dfsg-1.3+b1 ii psmisc 23.6-1 Versions of packages evolution recommends: ii evolution-plugin-bogofilter 3.50.2-1 ii evolution-plugin-pstimport 3.50.2-1 ii evolution-plugins3.50.2-1 ii yelp 42.2-1 Versions of packages evolution suggests: pn evolution-ews ii evolution-plugins-experimental 3.50.2-1 ii gnupg 2.2.40-1.1 ii network-manager 1.44.2-6 -- no debconf information
Bug#1059395: libacl1, debhelper: changelog handling with --no-trim seems to be not binNMU-safe
Package: libacl1,debhelper
Control: found -1 libacl1/2.3.1-3
Control: found -1 debhelper/13.11.9
Severity: important
X-Debbugs-Cc: debian-rele...@lists.debian.org
libacl1 was recently binNMU'd on all architectures to address version skew.
Unfortunately, the binNMU'd version is no longer multiarch co-installable
because its changelog differs between architectures:
│ │ ├── ./usr/share/doc/libacl1/changelog.Debian.gz
│ │ │ ├── changelog.Debian
│ │ │ │ @@ -1,13 +1,13 @@
│ │ │ │ acl (2.3.1-3+b1) sid; urgency=low, binary-only=yes
│ │ │ │
│ │ │ │ - * Binary-only non-maintainer upload for amd64; no source changes.
│ │ │ │ + * Binary-only non-maintainer upload for i386; no source changes.
│ │ │ │* Rebuild to sync binNMU versions
│ │ │ │
│ │ │ │ - -- all / amd64 / i386 Build Daemon (x86-conova-01) ...
│ │ │ │ + -- i386 Build Daemon (x86-grnet-01) ...
This binNMU changelog entry would normally be separated into
changelog.Debian.${DEB_HOST_ARCH}.gz, as can be seen in
/usr/share/doc/libxext6/ at the time of writing. However, that mechanism
doesn't seem to have been effective for libacl1.
I notice that libacl1 uses dh_installchangelogs --no-trim in its
debian/rules to suppress the default exclusion of older changelog
entries. It appears that using that option also suppresses the separation
of binNMU changelog entries into a separate file? I think it probably
should not, because the trimming of old changelog entries is merely
a nice-to-have to save some disk space, but the separation of binNMU
changelog entries is functionally necessary if we want packages to remain
multiarch co-installable across binNMUs.
A sourceful upload of libacl1 would temporarily address this (until the
next binNMU) by not being a binNMU, but would not be a long-term solution,
unless we stop using binNMUs entirely and replace them with "no-changes"
machine-assisted sourceful uploads like Ubuntu has done.
Not using --no-trim could address this from the libacl1 side, but
presumably the libacl1 maintainer has used that option intentionally and
for a reason. (Is that reason more important than having co-installable
binNMUs?)
Making --no-trim only disable the trimming of old changelog entries, but
retain the separation of binNMU changelog entries (and then binNMU'ing
libacl1 again) could address this from the debhelper side.
I don't know which of these ways forward is the right one. Please reassign
or clone as appropriate, and in the meantime please consider doing a
sourceful upload of libacl1 to unblock multi-arch co-installability.
Thanks,
smcv
Bug#896016: strace: please make the build reproducible
Source: strace Followup-For: Bug #896016 X-Debbugs-Cc: la...@debian.org, reproducible-b...@lists.alioth.debian.org Control: fixed -1 strace/4.26-0.1 Control: close -1
Bug#1021207: lintian: Please reconsider the type and size of field-too-long
On Mon, Oct 03, 2022 at 07:57:36PM +0200, Mathias Behrle wrote: > E: tryton-modules-all: field-too-long Depends (5604 chars > 5000) > > > > Looking at #942943 and #942487 it looks as if the issue with reprepro > should be mitigated with > https://salsa.debian.org/debian/reprepro/-/commit/7cb8fcf53c077467c4f38b5a48f706e7b5f75f4c > > So I am asking for re-evaluation and/or advice > > - if this limitation still stands? > - if the former is true this shouldn't be rather a warning than an > error? > - if the former is true the only way out is to split the Depends into > sub-packages? For what it's worth, we're seeing this error trigger in podman, for the Built-Using field (it's golang) Lintian already has exceptions for "package-list" and "description" (per #942493), and while we could also add "Built-Using" to the list, I kinda wonder if this is a game of a whack-a-mole and this heuristic should be revisited, especially in the light of the reprepro fix mentioned by Mathias above. Thanks, Faidon
Bug#1058887: issue persists with kernel 6.6.8
After today's upgrade bringing linux-image-6.6.8 to sid, issue persists. Switching off my iwlwifi device makes nmcli unusable. It also blocks firefox. And "sudo any-command" hangs, impossible to break it. Powering off/rebooting the system is also impossible. -- Jean-Marc
Bug#1059394: bridge-utils: install files into /usr (instead of /)
Source: bridge-utils
Version: 1.7.1-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2
Hi!
Your package installs files directly into /. For the ongoing Debian
UsrMerge effort [1] these files should move to /usr in the trixie
cycle.
I'm attaching a patch to implement such a move.
However, please still read the wiki page on moving files, especially
if you intend to backport to bookworm or earlier. The patch has
already been checked by a local dumat copy.
If during the trixie cycle your package will undergo structural
changes or any other file moves, please also see the wiki and upload
to experimental first when these changes are done.
Chris
[1] https://wiki.debian.org/UsrMerge
diff -Nru bridge-utils-1.7.1/debian/bridge-network-interface.sh bridge-utils-1.7.1/debian/bridge-network-interface.sh
--- bridge-utils-1.7.1/debian/bridge-network-interface.sh 2023-01-25 22:11:52.0 +0100
+++ bridge-utils-1.7.1/debian/bridge-network-interface.sh 2023-12-23 21:31:44.0 +0100
@@ -19,7 +19,7 @@
[ "$BRIDGE_HOTPLUG" = "no" ] && exit 0
-. /lib/bridge-utils/bridge-utils.sh
+. /usr/lib/bridge-utils/bridge-utils.sh
if [ -d /run/network ]; then
for i in $(ifquery --list --allow auto); do
diff -Nru bridge-utils-1.7.1/debian/changelog bridge-utils-1.7.1/debian/changelog
--- bridge-utils-1.7.1/debian/changelog 2023-01-25 22:11:52.0 +0100
+++ bridge-utils-1.7.1/debian/changelog 2023-12-23 21:31:44.0 +0100
@@ -1,3 +1,10 @@
+bridge-utils (1.7.1-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Install files into /usr instead of /. (Closes: #-1)
+
+ -- Chris Hofstaedtler Sat, 23 Dec 2023 21:31:44 +0100
+
bridge-utils (1.7.1-1) unstable; urgency=low
* New upstream version.
diff -Nru bridge-utils-1.7.1/debian/dirs bridge-utils-1.7.1/debian/dirs
--- bridge-utils-1.7.1/debian/dirs 2023-01-25 22:11:52.0 +0100
+++ bridge-utils-1.7.1/debian/dirs 2023-12-23 21:31:44.0 +0100
@@ -1,6 +1,6 @@
etc/network/if-pre-up.d
etc/network/if-down.d
etc/network/if-post-down.d
-sbin
-lib/bridge-utils
-lib/udev
+usr/sbin
+usr/lib/bridge-utils
+usr/lib/udev
diff -Nru bridge-utils-1.7.1/debian/examples/hibernate bridge-utils-1.7.1/debian/examples/hibernate
--- bridge-utils-1.7.1/debian/examples/hibernate 2023-01-25 22:11:52.0 +0100
+++ bridge-utils-1.7.1/debian/examples/hibernate 2023-12-23 21:31:44.0 +0100
@@ -6,7 +6,7 @@
AddConfigHandler BridgeOptions
BridgeSuspend() {
-for i in `/sbin/brctl show|sed -n "s/^[^ ]*\t\([^\t]*\)/\1/p"`
+for i in `/usr/sbin/brctl show|sed -n "s/^[^ ]*\t\([^\t]*\)/\1/p"`
do
ip link set dev $i down
done
@@ -14,7 +14,7 @@
}
BridgeResume() {
-for i in `/sbin/brctl show|sed -n "s/^[^ ]*\t\([^\t]*\)/\1/p"`
+for i in `/usr/sbin/brctl show|sed -n "s/^[^ ]*\t\([^\t]*\)/\1/p"`
do
ip link set dev $i up
done
diff -Nru bridge-utils-1.7.1/debian/examples/pm-utils bridge-utils-1.7.1/debian/examples/pm-utils
--- bridge-utils-1.7.1/debian/examples/pm-utils 2023-01-25 22:11:52.0 +0100
+++ bridge-utils-1.7.1/debian/examples/pm-utils 2023-12-23 21:31:44.0 +0100
@@ -4,7 +4,7 @@
# as /etc/pm/sleep.d/bridge
BridgeSuspend() {
-for i in `/sbin/brctl show|sed -n "s/^[^ ]*\t\([^\t]*\)/\1/p"`
+for i in `/usr/sbin/brctl show|sed -n "s/^[^ ]*\t\([^\t]*\)/\1/p"`
do
ip link set dev $i down
done
@@ -12,7 +12,7 @@
}
BridgeResume() {
-for i in `/sbin/brctl show|sed -n "s/^[^ ]*\t\([^\t]*\)/\1/p"`
+for i in `/usr/sbin/brctl show|sed -n "s/^[^ ]*\t\([^\t]*\)/\1/p"`
do
ip link set dev $i up
done
diff -Nru bridge-utils-1.7.1/debian/ifupdown.sh bridge-utils-1.7.1/debian/ifupdown.sh
--- bridge-utils-1.7.1/debian/ifupdown.sh 2023-01-25 22:11:52.0 +0100
+++ bridge-utils-1.7.1/debian/ifupdown.sh 2023-12-23 21:31:44.0 +0100
@@ -6,7 +6,7 @@
# Have a look at /usr/share/doc/bridge-utils/README.Debian if you want
# more info about the way on wich a bridge is set up on Debian.
-if [ ! -x /sbin/brctl ]
+if [ ! -x /usr/sbin/brctl ]
then
exit 0
fi
@@ -14,7 +14,7 @@
#default configuration
[ -f /etc/default/bridge-utils ] && . /etc/default/bridge-utils
-. /lib/bridge-utils/bridge-utils.sh
+. /usr/lib/bridge-utils/bridge-utils.sh
case "$IF_BRIDGE_PORTS" in
"")
diff -Nru bridge-utils-1.7.1/debian/rules bridge-utils-1.7.1/debian/rules
--- bridge-utils-1.7.1/debian/rules 2023-01-25 22:11:52.0 +0100
+++ bridge-utils-1.7.1/debian/rules 2023-12-23 21:31:44.0 +0100
@@ -64,13 +64,13 @@
# Add here commands to install the package into debian/tmp.
#$(MAKE) install prefix=$(CURDIR)/debian/bridge-utils/usr
- $(INSTALL_PROGRAM) -m 755 brctl/brctl $(IDIR)/sbin
- $(INSTALL_SCRIPT) -m 755 debian/ifupdown.sh $(IDIR)/lib/bridge-utils/
- ln -s /lib/bridge-utils/ifupdown.sh $(IDIR)/etc/network/if-pre-up.d/bridge
- ln -s /lib/bridge-utils/ifupdown.sh $(IDIR)/etc/network/if-down.d/bridge
-
Bug#1000044: ccze: depends on obsolete pcre3 library
Axel Beckert wrote:
> sorry for the late reply, but I only managed to continue on this now
> as I'm on holidays now.
No problem at all, we are all busy. And it's not late according to my
standards. :)
> I though got another crash on this line:
>
> Dec 24 06:43:16 c6 kernel: net_ratelimit: 1 callbacks suppressed
Good catch! This is a case when process is allocated by
pcre2_substring_get_bynumber but since there are no square brackets
around, the strdup call at line 68 doesn't happen.
> I think I managed to fix it and will also upload, but I'd be happy for
> a short review of yours:
Removing the free call avoids the abort but leads to a memory leak.
Attached is a better fix, I think (tested with your line above and my
syslog, and of course with valgrind).
diff --git a/debian/patches/pcre2.patch b/debian/patches/pcre2.patch
index a5ee6b3..334d4e3 100644
--- a/debian/patches/pcre2.patch
+++ b/debian/patches/pcre2.patch
@@ -2473,7 +2473,7 @@ Last-Update: 2023-12-24
{
char *date = NULL, *host = NULL, *send = NULL, *process = NULL;
char *msg = NULL, *pid = NULL, *tmp = NULL, *toret;
-+ int use_free = 0;
++ int msg_use_free = 0, process_use_free = 0;
+ size_t l;
- pcre_get_substring (str, offsets, match, 1, (const char **));
@@ -2488,7 +2488,7 @@ Last-Update: 2023-12-24
-msg = strdup (send);
+{
+ msg = strdup (send);
-+ use_free = 1;
++ msg_use_free = 1;
+}
else
{
@@ -2499,7 +2499,7 @@ Last-Update: 2023-12-24
}
if (process)
-@@ -60,8 +64,8 @@
+@@ -60,8 +64,9 @@
pid = strndup ([1], (size_t)(t2 - t - 1));
tmp = strndup (process, (size_t)(t - process));
@@ -2507,10 +2507,11 @@ Last-Update: 2023-12-24
-process = tmp;
+pcre2_substring_free (process);
+process = strdup (tmp);
++process_use_free = 1;
}
}
-@@ -87,12 +91,17 @@
+@@ -87,12 +92,20 @@
else
toret = strdup (send);
@@ -2522,18 +2523,21 @@ Last-Update: 2023-12-24
+ pcre2_substring_free (date);
+ pcre2_substring_free (host);
+ pcre2_substring_free (send);
-+ /* free (process); */
free (pid);
+ free (tmp);
+
-+ if (use_free)
++ if (process_use_free)
++free (process);
++ else
++pcre2_substring_free (process);
++ if (msg_use_free)
+free (msg);
+ else
+pcre2_substring_free (msg);
return toret;
}
-@@ -100,33 +109,34 @@
+@@ -100,33 +113,34 @@
static void
ccze_syslog_setup (void)
{
Bug#1059393: openssh: CVE-2023-51767
Source: openssh Version: 1:9.6p1-2 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi Colin, The following vulnerability was published for openssh. This is for now just to track the issue as pointed out by a current paper. Apparently openssh and sudo got CVEs assigned for their respective issues. CVE-2023-51767[0]: | OpenSSH through 9.6, when common types of DRAM are used, might allow | row hammer attacks (for authentication bypass) because the integer | value of authenticated in mm_answer_authpassword does not resist | flips of a single bit. NOTE: this is applicable to a certain threat | model of attacker-victim co-location in which the attacker has user | privileges. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-51767 https://www.cve.org/CVERecord?id=CVE-2023-51767 [1] https://arxiv.org/abs/2309.02545 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1057240: alsa-utils: diff for NMU version 1.2.10-1.1
Control: tags 1057240 + patch
Control: tags 1057240 + pending
Dear maintainer,
I've prepared an NMU for alsa-utils (versioned as 1.2.10-1.1) and
uploaded it to DELAYED/7.
The NMU/patch also fixes the install path for systemd units and
moves the d-i script.
Chris
diff -Nru alsa-utils-1.2.10/debian/alsa-utils-udeb.install alsa-utils-1.2.10/debian/alsa-utils-udeb.install
--- alsa-utils-1.2.10/debian/alsa-utils-udeb.install 2019-10-30 11:35:09.0 +0100
+++ alsa-utils-1.2.10/debian/alsa-utils-udeb.install 2023-12-24 12:42:40.0 +0100
@@ -1,4 +1,4 @@
-debian/S37alsa-utils-udeb lib/debian-installer-startup.d
+debian/S37alsa-utils-udeb usr/lib/debian-installer-startup.d
debian/utils.sh /usr/share/alsa
usr/bin/amixer
usr/sbin/alsactl
diff -Nru alsa-utils-1.2.10/debian/changelog alsa-utils-1.2.10/debian/changelog
--- alsa-utils-1.2.10/debian/changelog 2023-09-13 15:45:59.0 +0200
+++ alsa-utils-1.2.10/debian/changelog 2023-12-24 12:42:40.0 +0100
@@ -1,3 +1,14 @@
+alsa-utils (1.2.10-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Use udevdir from udev.pc to determine udev rules install path.
+(Closes: #1057240)
+ * Use systemdsystemunitdir from systemd.pc to determine systemd unit install
+path.
+ * udeb: move debian-installer-startup.d/S37alsa-utils-udeb into /usr/lib.
+
+ -- Chris Hofstaedtler Sun, 24 Dec 2023 12:42:40 +0100
+
alsa-utils (1.2.10-1) unstable; urgency=medium
* New upstream release.
diff -Nru alsa-utils-1.2.10/debian/control alsa-utils-1.2.10/debian/control
--- alsa-utils-1.2.10/debian/control 2023-06-13 13:42:46.0 +0200
+++ alsa-utils-1.2.10/debian/control 2023-12-24 12:40:58.0 +0100
@@ -14,6 +14,7 @@
pkg-config,
python3-docutils,
systemd,
+ systemd-dev,
xmlto
Standards-Version: 4.6.2
Homepage: https://www.alsa-project.org/
diff -Nru alsa-utils-1.2.10/debian/install alsa-utils-1.2.10/debian/install
--- alsa-utils-1.2.10/debian/install 2022-07-06 03:17:35.0 +0200
+++ alsa-utils-1.2.10/debian/install 2023-12-24 12:42:40.0 +0100
@@ -1,6 +1,6 @@
debian/utils.sh /usr/share/alsa
-lib/systemd
-lib/udev
+${env:deb_systemdsystemunitdir}
+${env:deb_udevdir}/rules.d
usr/bin
usr/lib/*/alsa-topology/*.so
usr/sbin
diff -Nru alsa-utils-1.2.10/debian/links alsa-utils-1.2.10/debian/links
--- alsa-utils-1.2.10/debian/links 2019-10-30 11:35:09.0 +0100
+++ alsa-utils-1.2.10/debian/links 2023-12-24 12:42:40.0 +0100
@@ -1,3 +1,3 @@
-dev/null lib/systemd/system/alsa-utils.service
+dev/null ${env:deb_systemdsystemunitdir}/alsa-utils.service
usr/bin/aplay usr/bin/arecord
usr/share/man/man1/aplay.1.gz usr/share/man/man1/arecord.1.gz
diff -Nru alsa-utils-1.2.10/debian/rules alsa-utils-1.2.10/debian/rules
--- alsa-utils-1.2.10/debian/rules 2023-09-13 15:45:07.0 +0200
+++ alsa-utils-1.2.10/debian/rules 2023-12-24 12:41:31.0 +0100
@@ -1,6 +1,8 @@
#!/usr/bin/make -f
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export deb_udevdir = $(shell pkg-config --variable=udevdir udev | sed s,^/,,)
+export deb_systemdsystemunitdir = $(shell pkg-config --variable=systemdsystemunitdir systemd | sed s,^/,,)
%:
dh $@
@@ -10,7 +12,7 @@
--with-asound-state-dir=/var/lib/alsa \
--with-alsactl-home-dir=/run/alsa \
--with-alsactl-runtime-dir=/run/alsa/runtime \
- --with-systemdsystemunitdir=/lib/systemd/system \
+ --with-systemdsystemunitdir=/$(deb_systemdsystemunitdir) \
--disable-alsaconf
override_dh_auto_test:
Bug#1059187: samba: installs files into /lib/...
On Sun, Dec 24, 2023 at 12:54:09PM +0300, Michael Tokarev wrote: > Control: tag -1 + confirmed moreinfo > > 21.12.2023 03:09, Chris Hofstaedtler : > > For the correct place of the systemd system units, you can ask: > > pkg-config --variable=systemdsystemunitdir systemd > > Provided you add systemd-dev to Build-Depends. > > /lib/systemd is currently hard-coded in samba's d/rules (and repeated > in multiple places). It's easy to fix, but. > > The same samba package is being built on multiple distributions and > releases, including ubuntu focal and jammy, debian bullseye and buster, - > I provide sort of backports for these releases and this service has > become quite popular. The suggested > > pkg-config --variable=systemdsystemunitdir systemd > > does not work on bullseye already. This should work on bullseye, provided you Build-Depend: systemd. > What's an alternative way to determine if we should use /lib or /usr/lib > which works in older releases too - for systemd and for system libs like > libnss*? For systemd, please use systemd.pc. For everything else, it is harder: One option is to use dh_movetousr if available in debhelper, and otherwise skip it (= on old suites). For PAM, I'm guessing you can query libdir from pam.pc. Note that there is no coordinated plan for PAM yet, so while I hope pam.pc will, in the future, have a /usr/lib/... libdir, you cannot exactly rely on it. However, because the paths are aliased, if you move today it will still work. For nsswitch, I have no useful answer. Maybe piggyback on something else (pam?) even if that is technically wrong, or hardcode old suite names? Chris
Bug#1058034: webkit2gtk: 2.43 fails to build on riscv64
On Thu, Dec 21, 2023 at 8:26 AM Alberto Garcia wrote: > Ok, I wanted to upload 2.43.3 to experimental today and I decided to > include that patch. Debian's riscv64 build succeeded. https://buildd.debian.org/status/package.php?p=webkit2gtk=experimental Thank you, Jeremy Bícha
Bug#1058767: netplug: unmaintained
On Wednesday 20 December 2023 22:32:38 Chris Hofstaedtler wrote: > Hi, > > * Pali Rohár [231216 11:35]: > > On Friday 15 December 2023 21:56:01 Chris Hofstaedtler wrote: > > Hello, I talked with the author of the netplug (Bryan O'Sullivan) and I > > got permission to continue working on this project. I can continue > > maintaining this package on Debian, so please let me know what is needed > > to fix for preventing its removal. Thanks. > > Well, the immediate thing to do is: close this bug. Ok, I have closed it. > But the more important thing: actually maintain the package, > including ongoing quality work in the packaging, responding > to/fixing bugs, etc. > > If I were in your shoes, I'd make sure to know if/where the users of > this package are. If all users are using vyos, then maybe its better > maintained as part of vyos, and removed from Debian. > Debian has a number of other things that can react to network > events, some of those have active upstreams ... > > Best, > Chris I'm going to ask vyos what they think about it and decide next steps then. Thanks.
Bug#1059266: error: cannot verify inline signature
Hi On 2023-12-22 23:30, Guillem Jover wrote: > I'll prepare an upload right away and force the code to use gpg for > now (as it was used before the recent upload, instead of trying gpgv, > sqop, pgpainless-cli, or sq), until I've devised a better migration > plan, or implemented enough configuration options for people to switch > or use other OpenPGP backends when desired. Thanks, I confirm it fixes the issue. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1000044: ccze: depends on obsolete pcre3 library
Control: tag -1 + pending Hi Yavor, sorry for the late reply, but I only managed to continue on this now as I'm on holidays now. Yavor Doganov wrote: > Here it is -- no memory leaks and I could not obtain crash or abort > with the logs I've tested. Note that while my original patch > introduced some leaks, it also fixes some in the original code. Thanks again for these patches! They indeed work much better than before this set of patches. I though got another crash on this line: Dec 24 06:43:16 c6 kernel: net_ratelimit: 1 callbacks suppressed I think I managed to fix it and will also upload, but I'd be happy for a short review of yours: Backtrace is as follows: Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `ccze -A'. Program terminated with signal SIGABRT, Aborted. #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) bt #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x7fe6a065715f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 0x7fe6a0609472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x7fe6a05f34b2 in __GI_abort () at ./stdlib/abort.c:79 #4 0x7fe6a05f41ed in __libc_message (fmt=fmt@entry=0x7fe6a076678c "%s\n") at ../sysdeps/posix/libc_fatal.c:150 #5 0x7fe6a0660a75 in malloc_printerr (str=str@entry=0x7fe6a076422c "free(): invalid pointer") at ./malloc/malloc.c:5658 #6 0x7fe6a06627f4 in _int_free (av=, p=, have_lock=have_lock@entry=0) at ./malloc/malloc.c:4432 #7 0x7fe6a066516f in __GI___libc_free (mem=) at ./malloc/malloc.c:3367 #8 0x7fe6a05b6467 in ccze_syslog_process (offsets=0x558834ff3170) at ./src/mod_syslog.c:97 #9 ccze_syslog_handle (str=, length=, rest=0x7fffc99b28c8) at ./src/mod_syslog.c:134 #10 0x558833642a2f in ccze_plugin_run (pluginset=pluginset@entry=0x558834fefd30, subject=subject@entry=0x558834fe59c0 "Dec 24 06:43:16 c6 kernel: net_ratelimit: 1 callbacks suppressed", subjlen=64, rest=rest@entry=0x7fffc99b28c8, type=type@entry=CCZE_PLUGIN_TYPE_FULL, handled=handled@entry=0x7fffc99b28a4, status=0x7fffc99b28a8) at ./src/ccze-plugin.c:327 #11 0x558833640616 in ccze_main () at ./src/ccze.c:706 #12 main (argc=, argv=) at ./src/ccze.c:756 Commenting out the "free (process);" in line 97 of src/mod_syslog.c via the pcre2.patch seems to have fixed that: https://salsa.debian.org/debian/ccze/-/commit/11b90155a6559e2121836483c2acacf35d8fca3b Do you think that change would have any other impact? At least no more crashes, so I'll upload anyway. But if you find some drawbacks, please tell me. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#896016: strace: please make the build reproducible
James Addison wrote: > Unfortunately there are plenty of FTBFS failures -- mostly test timeouts on > some architectures, alongside libfaketime errors that seem to affect i386 -- > but those seem like separate problems. Perhaps we could close this bug? Sure thing: as in, I agree that the FTBFS's are a separate problem and also that this bug can be closed. Can you go ahead and do so, presumably with the correct versioning? Many thanks. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1059376: [Pkg-pascal-devel] Bug#1059376: lcl is wrongly marked Multi-Arch: foreign
Hi, On Sun, Dec 24, 2023 at 08:51:54AM +0100, Abou Al Montacir wrote: > Just like lcl, lcl-2.2 is also a virtual package. This is technically wrong. The term "virtual package" refers to a binary package name that is provided by some package but doesn't exist as a .deb. Both lcl and lcl-2.2 exist as .deb files and thus are called "concrete packages". > If I look to all other virtual packages, they are Arch: all, and I tend to > agree > with that. Since virtual packages do not exist as concrete packages, they do not have an Architecture field and inherit their architecture from the providing concrete packages. I sense that your use of "virtual packages" does not match the definitions in Debian policy section 7.5. I guess that what you mean here is more commonly called "meta package" or "dependency package". Does that make sense to you? > However, I'm not very familiar with multi-arch subtleties. I am, but I am very much unfamiliar with Pascal, so we will only make a dent on this if we manage to combine our knowledge. > So if you want to fix this, please provide a proposal for then entire set of > packages. > > I would glad then to fix it. I fear that my knowledge of Pascal is too limited here, but let me try anway: lazarus-2.2 and lazarus look like a metapackages. They presently are A:all and implicitly M-A:no. That much seems fine to me. Due to depending on lcl-2.2, they must not become M-A:foreign. lazarus-src-2.2 and lazarus-src are A:all M-A:foreign and binary packages containing source code only are commonly that way. lazarus-ide-2.2, lazarus-ide-gtk2-2.2, lazarus-ide-qt5-2.2, lcl-utils-2.2, lcl-units-2.2, lcl-nogui-2.2, lcl-gtk2-2.2 and lcl-qt5-2.2 are A:any and implicitly M-A:no. I'd leave it that way unless there is a need for change. lcl-2.2 is A:any M-A:same. This is a metapackage for libraries and A:any M-A:same is commonly correct for libraries. lazarus-doc-2.2 and lazarus-doc are A:all M-A:foreign and binary packages containing documentation only are commonly that way. lazarus-ide, lazarus-ide-gtk2, lazarus-ide-qt5, lcl-utils, lcl-units, lcl-nogui, lcl-gtk2 and lcl-qt5 are A:all and implicitly M-A:no. These are metapackages and those typically have their Architecture field match the one they forward to, but this is not the case here. It's not clear whether this needs to change. As long as we only need it for the native architecture, this can be fine. They must not become M-A:foreign though. lcl is much like lazarus-ide and friends except that it is M-A:foreign and this is what this bug report is about. When I say "need to change" I mean an actual unresolvable dependency that happens in some practical setting such as cross building (which is what motivated this bug report). It seems very likely that we'll have to work on #845498 before there is any need for lazarus, so keeping these A:all metapackages for now makes sense to me. Just try to remember that when someone comes a long and says "lcl-units should be M-A:foreign, because this dependency is not resolvable" that it must not be M-A:foreign and instead that'd be the time to convert it from A:all to A:any. Until that happens, I think you're fine. On the flip side, lcl presently being M-A:foreign is promising that interfacing with lcl is independent of the architecture and this is a lie. We should not be making this promise and thus remove M-A:foreign there as it misleads a dependency resolver in finding a solution that totally does not work at all in practice and causes me to file annoying bug reports about your package. :) So this really is only about removing that one M-A:foreign line from d/control. And then once we moved forward on #845498, then revisit the other metapackages in a distant future. Helmut
Bug#1059392: eboard FTCBFS: builds for the build architecture
Source: eboard Version: 1.1.3-2 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs eboard fails to cross build from source, because it uses the build architecture compiler as a make default. Consider applying the attached patch to let dpkg's buildtools.mk initialize CC correctly for cross compilation. Helmut diff --minimal -Nru eboard-1.1.3/debian/changelog eboard-1.1.3/debian/changelog --- eboard-1.1.3/debian/changelog 2023-09-04 20:21:10.0 +0200 +++ eboard-1.1.3/debian/changelog 2023-12-22 11:19:12.0 +0100 @@ -1,3 +1,9 @@ +eboard (1.1.3-3) UNRELEASED; urgency=medium + + * Fix FTCBFS: Let dpkg's buildtools.mk initialize CC. (Closes: #-1) + + -- Helmut Grohne Fri, 22 Dec 2023 11:19:12 +0100 + eboard (1.1.3-2) unstable; urgency=medium * QA upload. diff --minimal -Nru eboard-1.1.3/debian/rules eboard-1.1.3/debian/rules --- eboard-1.1.3/debian/rules 2023-09-04 20:21:10.0 +0200 +++ eboard-1.1.3/debian/rules 2023-12-22 11:19:12.0 +0100 @@ -2,6 +2,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all +-include /usr/share/dpkg/buildtools.mk include /usr/share/dpkg/buildflags.mk %:
Bug#1059391: tgt FTCBFS: debian/rules hard codes the build architecture pkg-config
Source: tgt Version: 1:1.0.85-1.1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs tgt fails to cross build from source, because debian/rules hard codes the build architecture pkg-config causing a misdetection and subsequent failure in dh_install. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru tgt-1.0.85/debian/changelog tgt-1.0.85/debian/changelog --- tgt-1.0.85/debian/changelog 2023-11-17 22:35:38.0 +0100 +++ tgt-1.0.85/debian/changelog 2023-12-24 10:35:35.0 +0100 @@ -1,3 +1,10 @@ +tgt (1:1.0.85-1.2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Use the host architecture pkg-config. (Closes: #-1) + + -- Helmut Grohne Sun, 24 Dec 2023 10:35:35 +0100 + tgt (1:1.0.85-1.1) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru tgt-1.0.85/debian/rules tgt-1.0.85/debian/rules --- tgt-1.0.85/debian/rules 2023-11-17 22:35:38.0 +0100 +++ tgt-1.0.85/debian/rules 2023-12-24 10:35:34.0 +0100 @@ -1,9 +1,11 @@ #!/usr/bin/make -f #export DH_VERBOSE=1 +include /usr/share/dpkg/buildtools.mk + FEATURES = ISCSI_RDMA=1 CEPH_RBD=1 SD_NOTIFY=1 -glfs_libs = $(shell pkg-config --libs glusterfs-api 2>/dev/null) +glfs_libs = $(shell $(PKG_CONFIG) --libs glusterfs-api 2>/dev/null) ifneq ($(glfs_libs),) FEATURES += GLFS_BD=1 endif
Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)
reopen 1058876 block 1058944 by 1058876 thanks Alas, the fix in openmpi 4.1.6-3 for the include path to the openmpi fortran modules has hardcoded x86_64-linux-gnu This is preventing builds and tests on other architectures, e.g. rebuilding sundials for the petsc transition. I think openmpi's debian/tests will also need Depends: pkg-config for the new compile_run_cc_pkgconfig test.
Bug#1057755: Qt WebEngine Security Support In Stable
On Sat, Dec 23, 2023 at 03:55:15PM -0700, Soren Stoutner wrote: >... > In a hypothetical world where Qt 6.2 LTS had shipped with bookworm, we could > build any Qt WebEngine from 6.2, 6.3, or 6.4 against it without problem. > Initially it might seem best to build the highest possible, but because 6.4 > updates end a full year before 6.2 LTS updates, it would be best for stable > support if we stuck with 6.2 as long as possible. >... When Qt WebEngine from 6.5 is officially backportable to 6.2, then backporting it to versions between 6.2 and 6.5 is unlikely to be a problem. Backporting even more recent versions to 6.4 would be expected to be easier than backporting to 6.2, since 6.4 is closer to what gets backported and backporting problems tend to increase when the backporting distance increases since the code differences increase. >... > If it ends up not being feasible to backport the entire Qt WebEngine from > the next LTS release, then we could look at cherry-picking all of the > security commits. This would be, by far, the most time-intensive solution. > But, as your point out, the security fixes on the Chromium side are well > marked. And, generally, they are small commits that only modify a few lines. > For example: >... Your "generally" is not true, it misses the biggest problem. Out of 20 CVEs there might be 19 easy ones, plus one that is a quite invasive patch requiring a lot of backporting work. Who has both the required skills and a reliable commitment today for doing in the year 2027 an urgent backport of a complex fix for a zero-day vulnerability that is already being exploited in the wild? > Soren Stoutner cu Adrian
Bug#1059390: linux-image-6.5.0-5-amd64: Large number of missed packets reported by "e1000e" driver
Package: src:linux Version: 6.5.13-1 Severity: normal Tags: upstream Dear Maintainer, I'm using a Shuttle DS20UV2 as my broadband router and firewall. After updating it from Debian 12.4 to Trixie yesterday one of its network interfaces started reporting a large and ever increasing number of missed packets: > ip -s link show eno1 3: eno1: mtu 1508 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 80:ee:73:XX:XX:XX brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 991043595 846955 0 03691 0 TX: bytes packets errors dropped carrier collsns 890811461 793387 0 0 0 0 altname enp0s31f6 The number was much larger before I rebooted the machine to test out some kernel parameter changes. I originally had similar problems with Debian 12.x. But increasing the RX ring size from 256 to 1024 fixed the problem. Under Trixie neither this nor increasing the RX ring size to the maximum of 4096 helps. I also tried to restrict the maximum C-state to 3 (down from 9) which again didn't help. The interface in question is using an MTU of 1508 bytes to allow an MTU of 1500 bytes on PPPoE session running over it. The broadband link's maximum speed is 1 Gbit/sec. As such the incoming packet rate can be high at times. There is another ehternet interface in this machine which is driven by the "igc" driver. It reports zero missed packets but it also not using mini jumbo frames. -- Package-specific info: ** Version: Linux version 6.5.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 13.2.0-7) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC Debian 6.5.13-1 (2023-11-29) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.5.0-5-amd64 root=UUID=3f51e9a7-af14-4c6d-a6f3-da33d730389d ro pcie_aspm=off intel_idle.max_cstate=3 quiet ** Not tainted ** Kernel log: 2023-12-24T09:34:02.980398+00:00 [REDACTED] kernel: Linux version 6.5.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 13.2.0-7) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC Debian 6.5.13-1 (2023-11-29) 2023-12-24T09:34:02.980403+00:00 [REDACTED] kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.5.0-5-amd64 root=UUID=3f51e9a7-af14-4c6d-a6f3-da33d730389d ro pcie_aspm=off intel_idle.max_cstate=3 quiet 2023-12-24T09:34:02.980404+00:00 [REDACTED] kernel: BIOS-provided physical RAM map: 2023-12-24T09:34:02.980405+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x-0x0005dfff] usable 2023-12-24T09:34:02.980406+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x0005e000-0x0005efff] reserved 2023-12-24T09:34:02.980407+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x0005f000-0x0009] usable 2023-12-24T09:34:02.980407+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x000a-0x000f] reserved 2023-12-24T09:34:02.980410+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x0010-0x8dbcafff] usable 2023-12-24T09:34:02.980411+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x8dbcb000-0x8eefafff] reserved 2023-12-24T09:34:02.980411+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x8eefb000-0x8f02afff] ACPI data 2023-12-24T09:34:02.980412+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x8f02b000-0x8f460fff] ACPI NVS 2023-12-24T09:34:02.980413+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x8f461000-0x8f993fff] reserved 2023-12-24T09:34:02.980413+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x8f994000-0x8fc4dfff] type 20 2023-12-24T09:34:02.980414+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x8fc4e000-0x8fc4efff] usable 2023-12-24T09:34:02.980416+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x8fc4f000-0x9b7f] reserved 2023-12-24T09:34:02.980417+00:00 [REDACTED] kernel: BIOS-e820: [mem 0xe000-0xefff] reserved 2023-12-24T09:34:02.980418+00:00 [REDACTED] kernel: BIOS-e820: [mem 0xfe00-0xfe010fff] reserved 2023-12-24T09:34:02.980418+00:00 [REDACTED] kernel: BIOS-e820: [mem 0xfec0-0xfec00fff] reserved 2023-12-24T09:34:02.980419+00:00 [REDACTED] kernel: BIOS-e820: [mem 0xfed0-0xfed03fff] reserved 2023-12-24T09:34:02.980420+00:00 [REDACTED] kernel: BIOS-e820: [mem 0xfee0-0xfee00fff] reserved 2023-12-24T09:34:02.980422+00:00 [REDACTED] kernel: BIOS-e820: [mem 0xff00-0x] reserved 2023-12-24T09:34:02.980422+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x0001-0x0004627f] usable 2023-12-24T09:34:02.980423+00:00 [REDACTED] kernel: NX (Execute Disable) protection: active 2023-12-24T09:34:02.980424+00:00 [REDACTED] kernel: efi: EFI v2.7 by American Megatrends 2023-12-24T09:34:02.980424+00:00 [REDACTED] kernel: efi: ACPI=0x8f419000 ACPI 2.0=0x8f419014 TPMFinalLog=0x8f41f000 SMBIOS=0x8f802000 SMBIOS 3.0=0x8f801000
Bug#1052740: graphite2: FTBFS: graph_legend.dot:1: error: Problems running dot: exit code=1, command='dot', arguments='"/<>/build/doc/doxygen/html/graph_legend.dot" -Tpng -o "/<
Hi, Am 23.12.23 um 11:43 schrieb Rene Engelhard: Hi, Am 23.12.23 um 02:40 schrieb Bastian Germann: graph_legend.dot should have quotes around the font name references. Ah, thanks. Unfortunately this is a generated file... And yes, I also noticed that the FreeSans.ttf is at fault. Indeed I actually played around with it but that didn't give anything. Thinking abit it this value set already is default anyway, so we can just remove it and it still works (and passes the problem), now running into the (unrelated) LaTeX issue. Regards, Rene
Bug#1059389: r-cran-ggeffects: autopkgtest regression
Source: r-cran-ggeffects
Version: 1.3.2+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of r-cran-emmeans 1.9.0+dfsg-1, the autopkgtest of
r-cran-ggeffects is failing [1]. I've copied what I hope is the
relevant part of the log below.
Regards
Graham
[1] https://ci.debian.net/packages/r/r-cran-ggeffects/testing/amd64/
199s ══ Failed tests
199s ── Failure ('test-rq.R:23:5'): ggemmeans, rq
───
199s ggemmeans(m1, "Air.Flow", verbose = FALSE) is not NULL
199s
199s `actual` is an S3 object of class , a list
199s `expected` is NULL
199s
199s [ FAIL 1 | WARN 0 | SKIP 19 | PASS 385 ]
199s Error: Test failures
199s Execution halted
199s autopkgtest [21:26:42]: test run-unit-test: ---]
Bug#1059388: git-debrebase: found two-parent merge, how to cope?
Package: dgit Version: 11.5 Severity: wishlist X-Debbugs-Cc: pk...@debian.org Hey, In the absence of a better venue of asking this question (there seems to be no mailing list): I have an upstream repository that contains a two-parent merge for some reason (https://github.com/twosigma/nsncd, of all the things merging a CLA into the repository). dgit bails out with this: | Format `3.0 (quilt)', need to check/update patch stack | examining quilt state (multiple patches, linear mode) | git-debrebase: snag ignored (-funclean-ordering): packaging change (6228b52f9f4e1c847907651dcfa27a4003280538) follows upstream change (eg 2a5ff9d32c70a818044d26b007ec407a875d2374) | git-debrebase: snag ignored (-funclean-ordering): packaging change (b977d9b16db9bd6dcfc7f9f1e1831ea254d2df1d) follows upstream change (eg 44c81340420d2e993e7506f3144720862c56d77a) | git-debrebase: snag ignored (-funclean-mixed): found mixed upstream/packaging commit (ef3e287879586088e795a518977de87e65c6c2fd) | | git-debrebase: error: found unprocessable commit, cannot cope: general two-parent merge (e3de17c274315bab561664ac57e46472670545cf) | git-debrebase: Branch does not seem to be meant to be a git-debrebase branch? | git-debrebase: Wrong branch, or maybe you needed git-debrebase convert-from-*. | git-debrebase: | dgit: failed command: git-debrebase --noop-ok -funclean-mixed -funclean-ordering make-patches --quiet-would-amend | | dgit: error: subprocess failed with error exit status 255 I have so far forced an --anchor manually upon git-debrebase, which worked, but is also very tedious to pass everywhere. Is this something that will auto-fix itself on the next upstream release because dgit will properly discard the history pre the current upstream release? I was at least hoping that it would disappear with the first regular upload - but this did not happen. Is there something I can do for dgit to accept the current state of the repository as canonical up to the point where the Debian packaging was modified/forked off. The snags are upstream's prior packaging as found in the upstream repository, which does not seem to be uncommon to me either. The repo can be found on dgit as well as on [1]. Kind regards and thanks Philipp Kern [1] https://salsa.debian.org/Debian/nsncd
Bug#1059187: samba: installs files into /lib/...
Control: tag -1 + confirmed moreinfo 21.12.2023 03:09, Chris Hofstaedtler : Source: samba Version: 2:4.19.3+dfsg-2 User: helm...@debian.org Usertags: dep17m2 Hi! The samba binary packages installs a number of files below /lib. For the ongoing Debian UsrMerge effort [1], these should be moved below /usr/lib. Currently the files installed are: - lib/systemd/system/ctdb.service - lib/systemd/system/nmb.service -> nmbd.service - lib/systemd/system/nmbd.service - lib/systemd/system/samba-ad-dc.service - lib/systemd/system/samba.service -> samba-ad-dc.service - lib/systemd/system/smb.service -> smbd.service - lib/systemd/system/smbd.service - lib/systemd/system/winbind.service - lib/x86_64-linux-gnu/libnss_winbind.so.2 - lib/x86_64-linux-gnu/libnss_wins.so.2 - lib/x86_64-linux-gnu/security/pam_winbind.so Please investigate moving these below /usr/lib. When doing so, make sure your packages do not install empty directories inside /lib (or /lib itself). For the correct place of the systemd system units, you can ask: pkg-config --variable=systemdsystemunitdir systemd Provided you add systemd-dev to Build-Depends. /lib/systemd is currently hard-coded in samba's d/rules (and repeated in multiple places). It's easy to fix, but. The same samba package is being built on multiple distributions and releases, including ubuntu focal and jammy, debian bullseye and buster, - I provide sort of backports for these releases and this service has become quite popular. The suggested pkg-config --variable=systemdsystemunitdir systemd does not work on bullseye already. What's an alternative way to determine if we should use /lib or /usr/lib which works in older releases too - for systemd and for system libs like libnss*? Thanks, /mjt
Bug#1059387: exim4: CVE-2023-51766
Source: exim4 Version: 4.97-2 Severity: important Tags: security upstream Forwarded: https://bugs.exim.org/show_bug.cgi?id=3063 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for exim4. CVE-2023-51766[0]: | Exim through 4.97 allows SMTP smuggling in certain configurations. | Remote attackers can use a published exploitation technique to | inject e-mail messages that appear to originate from the Exim | server, allowing bypass of an SPF protection mechanism. This occurs | because Exim supports . but some other popular e-mail | servers do not. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-51766 https://www.cve.org/CVERecord?id=CVE-2023-51766 [1] https://bugs.exim.org/show_bug.cgi?id=3063 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1059386: sendmail: CVE-2023-51765
Source: sendmail Version: 8.17.2-1 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for sendmail. CVE-2023-51765[0]: | sendmail through at least 8.14.7 allows SMTP smuggling in certain | configurations. Remote attackers can use a published exploitation | technique to inject e-mail messages that appear to originate from | the sendmail server, allowing bypass of an SPF protection mechanism. | This occurs because sendmail supports . but some other | popular e-mail servers do not. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-51765 https://www.cve.org/CVERecord?id=CVE-2023-51765 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1059230: postfix: SMTP Smuggling attack
Control: retitle -1 postfix: CVE-2023-51764: SMTP Smuggling attack Hi On Thu, Dec 21, 2023 at 01:03:20PM -0500, Scott Kitterman wrote: > On Thursday, December 21, 2023 11:57:21 AM EST Salvatore Bonaccorso wrote: > > Source: postfix > > Version: 3.8.2-1 > > Severity: important > > Tags: security upstream > > Forwarded: > > https://www.mail-archive.com/postfix-users@postfix.org/msg100901.html > > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > Control: found -1 3.7.6-0+deb12u2 > > Control: found -1 3.5.18-0+deb11u1 > > Control: found -1 3.4.23-0+deb10u1 > > > > Hi > > > > There was a SMTP smuggling vulerability reported, for which in some > > Postfix versions at least already exists short term mitiations in form > > of "smtpd_forbid_unauth_pipelining = yes". > > > > Details via: > > > > https://www.mail-archive.com/postfix-users@postfix.org/msg100901.html > > https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwid > > e/ > > See https://www.postfix.org/smtp-smuggling.html for the most recent > information. > > The mitigation is available for stable, but not yet oldstable. Right, that was the better reference to following the status. A CVE has been assigned in meanwhile for the issue in postfix: CVE-2023-51764. Regards, Salvatore
Bug#1055192: RFS: golang-github-apenella-go-ansible
On Sat, Dec 23, 2023 at 10:35:08PM +0530, Nilesh Patra wrote: > I finally got some time to look at this. From what I see, this is just a > library > package (and no binary) and this seems to be the final package you want to > get uploaded. > > Generally, all go library packages 'are'/'should be' present in Debian > because they are needed > for a target (binary) package which a user is interested in using. No-one > would be keen > on apt installing golang libraries and fiddling with GOPATH/GOROOT > rather than a simpler `go get -u` if they want to use them to write code. > > Hence, unless you have any target packages for which these libs are needed, I > do not see > a lot of use of getting this in. Let me know what you'd think. I *do* expect > your reponse on this. It looks that this has been a clear oversight from my side. *I do find this a very useful library* but as you mentioned, since go team convention does not include packaging libaries that are not needed by any binaries, there is probably no real value in getting this in. As such, please prune the corresponding repositories for the following: - golang-github-apenella-go-ansible - golang-github-apenella-go-common-utils - golang-github-sosedoff-ansible-vault-go > Thanks! > > Best, > Nilesh I feel sincerely sorry that an oversight from my side has ended up taking some of your busy schedule and I apologize for making you spend your time needlessly. I'll try my best to make sure such mishapas does not occur in the future, since it is not beneficial to anyone. And regardless of the outcome of this, thanks a lot for taking a look at the RFS. Best, Ananthu
Bug#1059376: [Pkg-pascal-devel] Bug#1059376: lcl is wrongly marked Multi-Arch: foreign
Hi Helmut, Just like lcl, lcl-2.2 is also a virtual package. If I look to all other virtual packages, they are Arch: all, and I tend to agree with that. However, I'm not very familiar with multi-arch subtleties. So if you want to fix this, please provide a proposal for then entire set of packages. I would glad then to fix it. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
