Bug#1069357: Fwd: Re: Bug#1069357: cpp-httplib: FTBFS on arm64: dh_auto_test: error: cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test --timeout-m

[Andrea Pappacoda]

 Messaggio originale 
Da: Andrea Pappacoda 
Inviato il: 3 maggio 2024 07:39:59 CEST
A: Stuart Prescott 
Oggetto: Re: Bug#1069357: cpp-httplib: FTBFS on arm64: dh_auto_test: error: cd 
obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 
MESON_TESTTHREADS=4 meson test --timeout-multiplier=3 
--test-args=--gtest_filter=-\*_Online returned exit code 1

Hi Stuart, thanks for the ping.

I've been aware of these test failures for a while, but haven't been able to 
determine the cause of them. They actually ran successfully when I first 
uploaded the package, but broke after some package upload which I haven't yet 
identified.

It is possible that this is indeed a bug in cpp-httplib, but it has only showed 
up after an unknown package has been updated in unstable.

Citing a previous mail of mine, sent to Bastian Germann the 7th of April:

> When I uploaded the package to mentors the tests ran fine in an unstable 
> chroot, and still do when running them on my local machine (which runs 
> Testing). I haven't yet tried running them in a chroot which pulls things 
> from experimental, but if I run them now in an unstable chroot I get a 
> failure in the SSLClientServerTest.ClientCertPresent test, and a timeout 
> afterwards.

The issue shows up in cpp-httplib's Server::listen() function.

Do you have any suggestions regarding how I can "bisect" such an issue?

Thanks!

P.S. this mail may look broken - I've sent it from my phone.

Bug#1070274: bibledit: The current version currently has partially broken javascript

[Teus Benschop]

Source: bibledit
Version: 5.1.002-1
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: teusbensc...@debian.org

Dear Maintainer,

The version of upstream code, included in this package,
has broken javascript.
This cripples some parts of the program, in particular the verse editor.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1070273: bibledit-cloud: The current version currently has partially broken javascript

[Teus Benschop]

Source: bibledit-cloud
Version: 5.1.005-1
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: teusbensc...@debian.org

Dear Maintainer,

The uptream version, included in this package,
has partially broken javascript.
This cripples some parts of the Bible editors.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1070266: nmu: chromium_124.0.6367.118-1

[GCS]

Control: tags -1 +moreinfo

On Fri, May 3, 2024 at 12:57 AM Andres Salomon  wrote:
> Snappy 1.2.0-1 was uploaded with broken symbols (see
> https://bugs.debian.org/1070217). This is fixed in snappy 1.2.0-2, but
> chromium in sid had already built against the broken version of snappy.
 Nope, the symbols were _not_ broken, some were missing as of the
1.1.10-1 version. I have added those back in the 1.2.0-2 package
version.

> Please rebuild chromium against snappy 1.2.0-2 to fix its broken symbol
> dependencies. Because this chromium release has CVE fixes (and there's
> 20-something pending CVEs in trixie already that would be fixed by
> chromium migration), I'm filing this with a higher severity than usual.
 It is _not_ needed. the ABI of 1.2.0-1 is not changed in 1.2.0-2,
I've even installed the new snappy library version and can still use
chromium without problems. Do you experience any odd behaviour?

Regards,
Laszlo/GCS

Bug#1068629: testng7 backport for bullseye needed for latest Java LTS releases

[tony mancill]

Please excuse the top-post and the slow response-time.  I am fully in
agreement with the vendoring approach for jtreg7.

If there aren't any concerns from the team, I will review the MR and
prepare an upload in the next few days.

Cheers,
tony

On Tue, Apr 09, 2024 at 02:02:13PM +1200, Vladimir Petko wrote:
> Hi,
> 
> I have realized that I have not submitted the bug report for this
> issue, so the decision to try vendoring dependencies for JTREG is not
> visible anywhere.
> 
> Starting from the April OpenJDK release, JTREG 7.3 will be used for
> openjdk-11 and up, which will require having it in Buster and up.
> 
> In Ubuntu, the January OpenJDK update used the vendored version, and
> we have not found any test regression issues caused by it.
> 
> I have an MR open[1] that does not update the source tree and a
> branch[2] with imported sources.
> 
> Best Regards,
>  Vladimir.
> 
> [1] https://salsa.debian.org/java-team/jtreg7/-/merge_requests/1
> [2] 
> https://salsa.debian.org/vpa1977/jtreg7/-/tree/jtreg_with_sources?ref_type=heads
> 
> On Sun, Oct 22, 2023 at 10:01 AM Emmanuel Bourg  wrote:
> >
> > Le 21/10/2023 à 20:55, tony mancill a écrit :
> >
> > > My secondary concern is how we would respond to CVEs in the vendored
> > > components.  We can debate whether the attack surface area in a tool
> > > like jtreg warrants patching the vendored components, but as a general
> > > principle, that's why we avoid vendoring in the first place.
> > >
> > > But if vendoring is acceptable in some circumstances,  I can imagine
> > > cases where it helps with bootstrapping too, but that's probably a topic
> > > for a different thread.
> > >
> > > In any event, I'm glad that we're having the discussion and that the
> > > Security Team has taken a look.  Let's see how it goes with jtreg7.
> >
> > jtreg is only used to run the openjdk tests, that's not a security
> > sensitive package, so embedding the package isn't a concern.
> >
> > Emmanuel Bourg
> >


signature.asc
Description: PGP signature

Bug#1069357: cpp-httplib: FTBFS on arm64: dh_auto_test: error: cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test --timeout-multiplier=3 --test-arg

[Stuart Prescott]

Hi Andrea

Gentle ping on this bug - there are a few packages lined up for 
autoremoval and/or can't migrate due to this bug.


Looking at the test suite, there seems to be three tests (all within 
SSLClientServerTest) that now hang on multiple architectures. I don't 
think this is simply a matter of increasing the timeout on the test as 
these seem to sit for 15 minutes with no CPU activity.


The tests fail not only on arm64 as reported in this bug but also on 
amd64 and i386, both on salsa-ci and tested locally by me.


Skipping these tests by extending the test filter in d/rules is enough 
to get the package to build; I have not investigated what is leading to 
these tests failing.


--gtest_filter=-*_Online:*ClientCertPresent*:*TrustDirOptional*:*CustomizeServerSSLCtx*

Of course skipping failing tests may well build a broken package — I 
don't know this package well enough to make a judgement call on that, 
hence I have not NMUd to skip the tests. Please let me know if you think 
it is indeed appropriate and would like me to NMU the above change.


cheers
Stuart

--
Stuart Prescott   http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer  http://www.debian.org/   stu...@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1070163: socat: support duplicating data to multiple clients of listening socket?

[Paul Wise]

On Wed, 2024-05-01 at 11:48 +0200, Gerhard Rieger wrote:

> Socat is not able to do this, and there is currently no plan to 
> implement this feature.
> 
> However, due to the repeated requests, a script socat-mux.sh has been
> written and released with Socat 1.8.0.0 that is able to provide 
> many-to-one, one-to-all communications. Internally it utilizes two Socat 
> (parent) processes that use UDP broadcast on loopback interface for data 
> multiplication. Please note that this has a security risk because local 
> users are able to join the communications.

Thanks for the info!

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386

[Shmerl]

On Thu, 2 May 2024 19:05:22 +0300 Jussi Pakkanen  wrote:
>
> Along the way I found other bugs, such as bindgen not working at all
> out of the box. I filed
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070241 for that.
>
> All in all this is getting into very deep Debian toolchain magic, of
> which I have little knowledge. :(
>

If real solution for this requires upstream involvement, may be it's worth
disabling
these tests, until upstream is actually not broken? That would at least
move things
forward, otherwise it might be stuck for who knows how long?

I don't know what's the usual recommended approach for handling such cases.

Regards,
Shmerl.

Bug#1070272: rust-sequoia-octopus-librnp: FTBFS on armel/armhf: tv_usec: duration.subsec_micros() as libc::suseconds_t, expected `i64`, found `i32`

[Andreas Beckmann]

Source: rust-sequoia-octopus-librnp
Version: 1.8.1-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: time-t

rust-sequoia-octopus-librnp FTBFS on armel/armhf due to the t64
transition:

https://buildd.debian.org/status/fetch.php?pkg=rust-sequoia-octopus-librnp=armel=1.8.1-4=1713865768=0

   Compiling socket2 v0.5.5
 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=socket2 
CARGO_MANIFEST_DIR=/<>/registry/socket2-0.5.5 
CARGO_PKG_AUTHORS='Alex Crichton :Thomas de Zeeuw 
' CARGO_PKG_DESCRIPTION='Utilities for handling 
networking sockets with a maximal amount of configuration
possible intended.
' CARGO_PKG_HOMEPAGE='https://github.com/rust-lang/socket2' 
CARGO_PKG_LICENSE='MIT OR Apache-2.0' CARGO_PKG_LICENSE_FILE='' 
CARGO_PKG_NAME=socket2 
CARGO_PKG_REPOSITORY='https://github.com/rust-lang/socket2' 
CARGO_PKG_RUST_VERSION=1.63 CARGO_PKG_VERSION=0.5.5 CARGO_PKG_VERSION_MAJOR=0 
CARGO_PKG_VERSION_MINOR=5 CARGO_PKG_VERSION_PATCH=5 CARGO_PKG_VERSION_PRE='' 
LD_LIBRARY_PATH='/<>/target/release/deps:/usr/lib' rustc 
--crate-name socket2 --edition=2021 
/<>/registry/socket2-0.5.5/src/lib.rs --error-format=json 
--json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib 
--emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg 
'feature="all"' -C metadata=2c09183bf02940c5 -C 
extra-filename=-2c09183bf02940c5 --out-dir 
/<>/target/armv5te-unknown-linux-gnueabi/release/deps --target 
armv5te-unknown-linux-gnueabi -L 
dependency=/<>/target/armv5te-unknown-linux-gnueabi/release/deps 
-L dependency=/<>/target/release/deps --extern 
libc=/<>/target/armv5te-unknown-linux-gnueabi/release/deps/liblibc-da839ea29c615453.rmeta
 --cap-lints warn -C debuginfo=2 --cap-lints warn -C 
linker=arm-linux-gnueabi-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix 
/<>=/usr/share/cargo/registry/sequoia-octopus-librnp-1.8.1 
--remap-path-prefix /<>/registry=/usr/share/cargo/registry`
error[E0308]: mismatched types
--> /usr/share/cargo/registry/socket2-0.5.5/src/sys/unix.rs:1137:22
 |
1137 | tv_usec: duration.subsec_micros() as libc::suseconds_t,
 |  ^ 
expected `i64`, found `i32`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `socket2` due to previous error

Caused by:
  process didn't exit successfully: `CARGO=/usr/bin/cargo 
CARGO_CRATE_NAME=socket2 
CARGO_MANIFEST_DIR=/<>/registry/socket2-0.5.5 
CARGO_PKG_AUTHORS='Alex Crichton :Thomas de Zeeuw 
' CARGO_PKG_DESCRIPTION='Utilities for handling 
networking sockets with a maximal amount of configuration
  possible intended.
  ' CARGO_PKG_HOMEPAGE='https://github.com/rust-lang/socket2' 
CARGO_PKG_LICENSE='MIT OR Apache-2.0' CARGO_PKG_LICENSE_FILE='' 
CARGO_PKG_NAME=socket2 
CARGO_PKG_REPOSITORY='https://github.com/rust-lang/socket2' 
CARGO_PKG_RUST_VERSION=1.63 CARGO_PKG_VERSION=0.5.5 CARGO_PKG_VERSION_MAJOR=0 
CARGO_PKG_VERSION_MINOR=5 CARGO_PKG_VERSION_PATCH=5 CARGO_PKG_VERSION_PRE='' 
LD_LIBRARY_PATH='/<>/target/release/deps:/usr/lib' rustc 
--crate-name socket2 --edition=2021 
/<>/registry/socket2-0.5.5/src/lib.rs --error-format=json 
--json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib 
--emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg 
'feature="all"' -C metadata=2c09183bf02940c5 -C 
extra-filename=-2c09183bf02940c5 --out-dir 
/<>/target/armv5te-unknown-linux-gnueabi/release/deps --target 
armv5te-unknown-linux-gnueabi -L 
dependency=/<>/target/armv5te-unknown-linux-gnueabi/release/deps 
-L dependency=/<>/target/release/deps --extern 
libc=/<>/target/armv5te-unknown-linux-gnueabi/release/deps/liblibc-da839ea29c615453.rmeta
 --cap-lints warn -C debuginfo=2 --cap-lints warn -C 
linker=arm-linux-gnueabi-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix 
/<>=/usr/share/cargo/registry/sequoia-octopus-librnp-1.8.1 
--remap-path-prefix /<>/registry=/usr/share/cargo/registry` (exit 
status: 1)


Andreas

Bug#1070271: nmu: 64-bit time_t rebuilds for experimental

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

The package in sid had a renaming t64 transition, but experimental
already has a different SOVERSION, so only a binNMU is needed.

nmu openmm_8.1.0+dfsg-2 . ANY . experimental . -m "Rebuild for time_t"
nmu opensubdiv_3.6.0-1 . ANY . experimental . -m "Rebuild for time_t"
nmu protobuf_3.25.2-1 . ANY . experimental . -m "Rebuild for time_t"
nmu opencascade_7.7.1+dfsg1-1~exp2 . ANY . experimental . -m "Rebuild for 
time_t"


Andreas

Bug#1070270: riseup-vpn: client no longer works due to cert verification problem

[Matt Taggart]

Package: riseup-vpn
Version: 0.21.11+ds1-5+b1
Severity: grave

When attempting to run the bookworm riseup-vpn package, it fails to 
connect to riseup's servers and gives the following output:


2024/05/01 18:21:23 Error fetching eip v3 
json:https://api.black.riseup.net/3/config/eip-service.json


My understanding is that this is due to the package failing to be able 
to verify the current LetsEncrypt cert that host is using. More details at


https://0xacab.org/leap/bitmask-vpn/-/issues/768

(supposedly the current upstream snap has this fixed, but I haven't 
tried it)


As this breaks what the package is supposed to do (at least when using 
riseup as provider, maybe there is a way to point it elsewhere?) I think 
this is grave. Also I think it might be a good candidate for being fixed 
in a stable release update.


Thanks,

--
Matt Taggart
m...@lackof.org

Bug#1068390: src:translate-toolkit: unsatisfied build dependency in testing: python3-levenshtein

[Stuart Prescott]

Update:

- python3-levenshtein is now fixed in unstable
- python-levenshtein can't migrate because of a long chain that gets
  back to #1069357 (cpp-httplib: FTBFS on arm64).



--
Stuart Prescott   http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer  http://www.debian.org/   stu...@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1070269: bluez: Please update to 5.75

[Jeremy Bícha]

Source: bluez
Version: 5.73-1
Severity: wishlist

bluez 5.75 is available. Please update to it. Perhaps it helps
https://bugs.debian.org/1069012 ?

Also I submitted several merge requests for the Debian package at
https://salsa.debian.org/bluetooth-team/bluez/-/merge_requests

Thank you,
Jeremy Bícha

Bug#1070268: RFA: recutils -- text-based databases called recfiles

[Sven Wick]

Package: wnpp
Severity: normal
Version: 1.9

Bug#1070267: mirror listing update for mirrors.jcut.edu.cn

[stack zhao]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: mirrors.jcut.edu.cn
Archive-architecture: amd64 arm64 armel armhf i386 mips64el ppc64el
Archive-http: /debian/
Maintainer: stack zhao 
Country: CN China
Location: Jingmen, Hubei
Sponsor: JCUT https://www.jcut.edu.cn




Trace Url: http://mirrors.jcut.edu.cn/debian/project/trace/
Trace Url: http://mirrors.jcut.edu.cn/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.jcut.edu.cn/debian/project/trace/mirrors.jcut.edu.cn

Bug#1070266: nmu: chromium_124.0.6367.118-1

[Andres Salomon]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: serious

Hello,

Snappy 1.2.0-1 was uploaded with broken symbols (see 
https://bugs.debian.org/1070217). This is fixed in snappy 1.2.0-2, but 
chromium in sid had already built against the broken version of snappy.


Please rebuild chromium against snappy 1.2.0-2 to fix its broken symbol 
dependencies. Because this chromium release has CVE fixes (and there's 
20-something pending CVEs in trixie already that would be fixed by 
chromium migration), I'm filing this with a higher severity than usual.


  nmu chromium_124.0.6367.118-1 . ANY . -m 'Rebuild against 
libsnappy1v5 to fix broken symbols (#1070217)'




OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#576591: mplayer - gmplayer fails by default

[Lorenzo]

Control: severity -1 normal
Control: forwarded -1 https://trac.mplayerhq.hu/ticket/1044
Control: tags -1 upstream

On Mon, 5 Apr 2010 23:17:21 +0200 Bastian Blank 
wrote:
> Package: mplayer
> Version: 1.0~rc3+svn20090405-1+b1
> Severity: grave
> 
> gmplayer fails by default with the following error:
> | Error: opening/initializing the selected video_out (-vo) device.
> 
> It only tries the mga output instead of the generic Xv.

This seems to be still relevant: I have no vo= defined in
/etc/mplayer/mplayer.conf and the gui creates ~/.mplayer/gui.conf with
vo_driver=vdpau and in my case fails to play with

[vdpau] Error when calling vdp_device_create_x11: 1
Error opening/initializing the selected video_out (-vo) device.
Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared
object file: No such file or directory  

if I change to
vo_driver=vdpau,xv

it plays the video with no errors.

Ingo, is it possible to patch the gui so that the default value is
changed to xv or to a list that includes xv?

Thanks,
Lorenzo

> 
> Bastian
> 
> -- 
> I've already got a female to worry about.  Her name is the Enterprise.
>   -- Kirk, "The Corbomite Maneuver", stardate 1514.0
> 
> 
> 

Bug#1070265: RM: osmo-hlr/experimental -- RoQA; NVIU; t64 transition has been reverted

[Andreas Beckmann]

Package: ftp.debian.org

After restricting osmo-hlr to 64-bit architectures, the t64 renaming
transition is no longer needed and the prepared package can go from
experimental.

osmo-hlr| 1.5.0+dfsg1-3.1~exp1 | experimental | source, amd64, 
arm64, armel, armhf, i386, mips64el, ppc64el, riscv64
osmo-hlr| 1.5.0+dfsg1-4| testing  | source
osmo-hlr| 1.5.0+dfsg1-4| unstable | source


Andreas

Bug#1070264: RM: osmo-iuh/experimental -- RoQA; NVIU; t64 transition has been reverted

[Andreas Beckmann]

Package: ftp.debian.org

After restricting osmo-iuh to 64-bit architectures, the t64 renaming
transition is no longer needed and the prepared package can go from
experimental.

osmo-iuh  | 1.3.0+dfsg1-5.1~exp1 | experimental | source
osmo-iuh  | 1.3.0+dfsg1-7| testing  | source
osmo-iuh  | 1.3.0+dfsg1-7| unstable | source


Andreas

Bug#1070263: uuu: Add Appstream metainfo XML with hardware mapping

[Petter Reinholdtsen]

Package: uuu
Version: 1.5.141-1
Tags:patch

Here is a patch for mfgtools to add Appstream metainfo XML announcing
the hardware handled by this package.

Including this information in the package will ensure programs mapping
hardware to packages using Appstream information, like the isenkram
package, will know that this package is useful on machines where the USB
IDs are discovered.

diff --git a/debian/copyright b/debian/copyright
index 5911c26..8003583 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -14,6 +14,29 @@ Files: debian/*
 Copyright: 2020 Henry-Nicolas Tourneur 
 License: BSD-3-clause
 
+Files: debian/uuu.metainfo.xml
+Copyright: 2024 Petter Reinholdtsen
+License: MIT
+ Permission is hereby granted, free of charge, to any person obtaining
+ a copy of this software and associated documentation files (the
+ "Software"), to deal in the Software without restriction, including
+ without limitation the rights to use, copy, modify, merge, publish,
+ distribute, sublicense, and/or sell copies of the Software, and to
+ permit persons to whom the Software is furnished to do so, subject to
+ the following conditions:
+ .
+ The above copyright notice and this permission notice shall be
+ included in all copies or substantial portions of the Software.
+ .
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ SOFTWARE.
+
 License: BSD-3-clause
  Redistribution and use in source and binary forms, with or without 
modification,
  are permitted provided that the following conditions are met:
diff --git a/debian/uuu.install b/debian/uuu.install
new file mode 100644
index 000..c4e0bfd
--- /dev/null
+++ b/debian/uuu.install
@@ -0,0 +1 @@
+debian/uuu.metainfo.xml usr/share/metainfo
diff --git a/debian/uuu.metainfo.xml b/debian/uuu.metainfo.xml
new file mode 100644
index 000..5da0baf
--- /dev/null
+++ b/debian/uuu.metainfo.xml
@@ -0,0 +1,49 @@
+
+
+  com.github.NXPmicro.mfgtools
+  MIT
+  mfgtools
+  Freescale/NXP I.MX Chip image deploy tools
+  
+Universal update utility for I.MX CPUs. It can be used to
+e.g. burn uboot or a rootfs into the emmc.
+  
+  
+usb:v1FC9p012Fd*
+usb:v1FC9p0129d*
+usb:v1FC9p0147d*
+usb:v15A2p004Fd*
+usb:v1FC9p013Ed*
+usb:v1FC9p0146d*
+usb:v1FC9p014Ad*
+usb:v1FC9p014Bd*
+usb:v1FC9p014Ed*
+usb:v1FC9p015Dd*
+usb:v15A2p0076d*
+usb:v15A2p0054d*
+usb:v15A2p0061d*
+usb:v15A2p0063d*
+usb:v15A2p0071d*
+usb:v15A2p007Dd*
+usb:v15A2p0080d*
+usb:v1FC9p0128d*
+usb:v1FC9p0126d*
+usb:v1FC9p0135d*
+usb:v1FC9p0134d*
+usb:v1FC9p012Bd*
+usb:v0525pB4A4d*
+usb:v0525pB4A4d*
+usb:v1FC9p0151d*
+usb:v0525pB4A4d*
+usb:v3016p1001d*
+usb:v3016p1001d*
+usb:v066Fp9AFEd*
+usb:v066Fp9BFFd*
+usb:v1FC9p0153d*
+usb:v0525pA4A5d*
+usb:v18D1p0D02d*
+usb:v3016p0001d*
+usb:v1FC9p0152d*
+usb:v0483p0AFBd*
+  
+

-- 
Happy hacking
Petter Reinholdtsen

Bug#1070262: msi-keyboard: Adjust udev access rights from 'everyone' to 'console user'

[Petter Reinholdtsen]

Package: msi-keyboard
Version: 1.1-2
Tags: patch

The current udev role grant access to the device for everyone when the
hardware is inserted.  I believe a better approach is to only grant
access to the console user using the 'uaccess' tag.  Here is a patch to
adjust the access role.

diff --git a/99-msi.rules b/99-msi.rules
index 81d21ba..1946dca 100644
--- a/99-msi.rules
+++ b/99-msi.rules
@@ -1 +1 @@
-SUBSYSTEM=="usb", ATTRS{idVendor}=="1770", ATTRS{idProduct}=="ff00", 
MODE="0666"
+SUBSYSTEM=="usb", ATTRS{idVendor}=="1770", ATTRS{idProduct}=="ff00", 
TAG+="uaccess"

-- 
Happy hacking
Petter Reinholdtsen

Bug#1070261: msi-keyboard: Add Appstream metainfo XML with hardware mapping

[Petter Reinholdtsen]

Package: msi-keyboard
Version: 1.1-2
Tags: patch

Here is a patch for msi-keyboard to add Appstream metainfo XML
announcing the hardware handled by this package.

Including this information in the package will ensure programs mapping
hardware to packages using Appstream information, like the isenkram
package, will know that this package is useful on machines where the USB
IDs are discovered.

diff --git a/debian/copyright b/debian/copyright
index 69828c7..7402d29 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -13,6 +13,29 @@ Files: debian/*
 Copyright: 2015 Giulio Paci 
 License: BSD-3-clause
 
+Files: debian/msi-keyboard.metainfo.xml
+Copyright: 2024 Petter Reinholdtsen
+License: MIT
+ Permission is hereby granted, free of charge, to any person obtaining
+ a copy of this software and associated documentation files (the
+ "Software"), to deal in the Software without restriction, including
+ without limitation the rights to use, copy, modify, merge, publish,
+ distribute, sublicense, and/or sell copies of the Software, and to
+ permit persons to whom the Software is furnished to do so, subject to
+ the following conditions:
+ .
+ The above copyright notice and this permission notice shall be
+ included in all copies or substantial portions of the Software.
+ .
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ SOFTWARE.
+
 License: BSD-3-clause
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions
diff --git a/debian/msi-keyboard.install b/debian/msi-keyboard.install
index 7061c7e..6d6e917 100644
--- a/debian/msi-keyboard.install
+++ b/debian/msi-keyboard.install
@@ -1 +1,2 @@
 msi-keyboard /usr/bin
+debian/msi-keyboard.metainfo.xml usr/share/metainfo
diff --git a/debian/msi-keyboard.metainfo.xml b/debian/msi-keyboard.metainfo.xml
new file mode 100644
index 000..8e6845f
--- /dev/null
+++ b/debian/msi-keyboard.metainfo.xml
@@ -0,0 +1,17 @@
+
+
+  com.github.bparker06.msi-keyboard
+  MIT
+  msi-keyboard
+  command line tool to change MSI steelseries keyboards color 
setup
+  
+This command line tool allows one to change the color setup of
+MSI steelseries keyboards, found on some MSI laptop.  The tool
+supports changing operational mode of keyboard backlight and
+changing color and intensity of specific areas.
+
+  
+  
+usb:v1770pFF00d*
+  
+

-- 
Happy hacking
Petter Reinholdtsen

Bug#1070235: Guix fails to pull channel with SSL error

[Tomas Volf]

On 2024-05-02 13:16:08 -0700, Vagrant Cascadian wrote:
> On 2024-05-02, Tomas Volf wrote:
> > Package: guix
> > Version: 1.4.0-3
> >
> > When I invoke `guix pull' against my channel, it fails with a SSL error:
> >
> > # /usr/bin/guix pull --url=https://git.wolfsden.cz/.git/guix
> > Updating channel 'guix' from Git repository at 
> > 'https://git.wolfsden.cz/.git/guix'...
> > guix pull: error: Git error: SSL error: 0x8880 - SSL - A fatal 
> > alert message was received from our peer
> >
> > No special configuration is needed, just booting the system and installing 
> > guix
> > via apt-get.
>
> Does guix pull with the default channels work?

Yes, that is a workaround I use for now.  Guix pull the default channel, and
after that pull mine using the new Guix.  However since guix pull is slow and
resource intensive, that is wasteful and I would like to be able to skip that
step, hence this report.

>
> What certificate authority does your https server for your channel use?

Let's Encrypt.

>
>
> > This seems to be a problem specific to Guix from the debian package.  When 
> > I try
> > to access the channel by other means (from the same system as above), it 
> > works
> > fine.  `git clone' works just fine, and even Guix installed in non-debian 
> > way
> > works fine, for example via time-machine:
> >
> > guix time-machine -q --commit=v1.4.0 -- pull 
> > --url=https://git.wolfsden.cz/.git/guix
> >
> > I am using Debian 12 on 6.7.4 kernel and 2.36-9 libc, running on physical 
> > server
> > machine.
>
> You seem to also be lacking the recent security update for guix
> (e.g. 1.4.0-3+deb12u1), please test that version also, just in case
> there is some weird hidden versioned dependency conflict (e.g. if
> guile-gnutls was built against a different version of gnutls than when
> guix was initially built).

Sorry for bad bug report, I did use that version:

# apt list -a guix
Listing... Done
guix/stable-security,stable-security,now 1.4.0-3+deb12u1 amd64 [installed]
guix/stable,stable 1.4.0-3 amd64

The example bug report on the website does not have the +deb... suffix, so I
assumed I should exclude it, sorry (I do not know much about debian packaging).

>
>
> live well,
>   vagrant



--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

Bug#1070203: python3-pip: app silently lost in upgrade to Bookworm + pip3 lost track of the status (4 bugs)

[Stefano Rivera]

Hi Manny (2024.05.02_19:34:03_+)
> I’m a bit confused because “pip3 list” shows a list of 146 packages,
> but not argostranslation. Why did all those other packages survive the
> upgrade?  I wonder if some of them are somehow managed by apt.

Yes, probably.

> > So, I'm afraid you're well out of the supported area of pip.
> > Sorry.
> 
> Is it necessary for aptitude full-upgrade to withhold information from
> the user about package destruction or removal?  Ideally users would
> get a loud warning when actions are taken that are expected to impact
> an installed package. If it’s a mission critical tool, users need to
> be able to back out of the upgrade and assess the consequences.

Anything you install without apt, in /usr/local, /opt, etc. is outside
of apt's area of responsibility. It's up to you to manage these
yourself.

> I would also like to mention a fifth defect I just discovered:
> 
> ⑤ argostranslate was only /partially/ removed.
> 
> There are some big language files that were originally installed by
> argostranslate. The argostranslate executable survived the upgrade but
> not some of the modules it relies on, leaving it in a broken partially
> existent state with no information given to the user. The language
> packs remained in tact. I don’t know where on the filesystem they
> live, but when I installed argostranslate again the previous language
> packs were found and automatically available for use.

They're probably there, just not importable in your new python. Have a
look around in /usr/local.

> The pip package manager has an uninstall procedure and since pip is
> the manager of the argostranslate package, users rely on it to keep
> track of the objects associated to the application.

Pip is a far less expansive package manager than apt. It's only
responsible for installing libraries and applications *within* a
particular Python install. It doesn't try to do anything beyond that.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/

Bug#1070260: msi-keyboard: Please make git repository available on salsa?

[Petter Reinholdtsen]

Package: msi-keyboard
Version: 1.1-2

At the moment, the package metadata point to 
https://anonscm.debian.org/cgit/collab-maint/msi-keyboard.git >,
which no longer work.  Please move it to salsa.debian.org.

I can help with the conversion, if you want me to.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1070259: tuiwidgets: Should experimental t64 version be uploaded to unstable?

[textshell]

On Thu, May 02, 2024 at 11:25:12PM +0200, Bastian Germann wrote:
> Source: tuiwidgets
> Version: 0.2.1-1.1~exp1
> Severity: important
> X-Debbugs-Cc: vor...@debian.org
> 
> tuiwidget was targeted to be part of the t64 transition but has not been
> uploaded to unstable after renaming the experimental library. Should this be
> done?
> 

tuiwidget was targeted in error (because some glitch while analysing made
it fail to analyse).

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063006#12 (also that
message seems to have a copy and paste error for the package name).

(if needed i can dig out more details from irc on the analysis)

I think the proper course of action will be drop the experimental version
(and the auto transition tracker it created). But i was going to wait until
things have calmed down a bit, because this cleanup seems to be non urgent.

 - Martin

Bug#1070259: tuiwidgets: Should experimental t64 version be uploaded to unstable?

[Bastian Germann]

Source: tuiwidgets
Version: 0.2.1-1.1~exp1
Severity: important
X-Debbugs-Cc: vor...@debian.org

tuiwidget was targeted to be part of the t64 transition but has not been uploaded to unstable after renaming the 
experimental library. Should this be done?

Bug#1070150: Loading of expl3.ltx **extremely** slow on emulated runs

[Karl Berry]

it looks like the LuaTeX binaries were compiled with "-g -O2", but
running "readelf" and "objdump" shows that they're stripped, so I
don't think that that's the issue here.

FWIW, it's my understanding that what matters for execution speed is not
the presence or absence of debug symbols (-g), but whether optimization
was enabled (-O2 or similar).

   Debian Sidarm64  LuaTeX: 0m15.392s
   Debian Sidarm64  pdfTeX: 0m7.914s
   TeX Live 2023 arm64  LuaTeX: 0m0.737s
   TeX Live 2023 x86_64 pdfTeX: 0m0.156s
   TeX Live 2023 x86_64 LuaTeX: 0m0.156s

Not sure whether to conclude it's arm-specific or sid-specific or both
from those numbers, but I suppose a few more runs would show.

LuaTeX 2024 could be getting slowed down a bit by the additional access
checking, I suppose, but there were no significant changes in pdfteX in
2024, so that can't be the whole explanation.

FWIW, building lualatex.fmt on my x86_64-linux (Rocky Linux 9.3) home
machine, with the TL luahbtex binary, took about six seconds.
Rebuilding all the formats took about 80 seconds, last time it happened.

Best,
Karl

Bug#1070236: [Pkg-samba-maint] Bug#1070236: python3-samba: SyntaxError during configuration phase of package on upgrade

[Michael Tokarev]

02.05.2024 23:36, Michael Biebl wrote:

Control: reopen -1
Control: found -1 2:4.19.6+dfsg-3

On Thu, 2 May 2024 11:58:59 -0700 "Leo L. Schwab"  wrote:

Did you fix this one, too?

---
Performing actions...
Setting up python3-samba (2:4.19.6+dfsg-2) ...
  File "/usr/lib/python3/dist-packages/samba/ms_schema_markdown.py", line 25
    try
   ^
SyntaxError: expected ':'



I also get
   File "/usr/lib/python3/dist-packages/samba/ms_schema_markdown.py", line 27
     except ImportError e:
    ^
SyntaxError: invalid syntax


All this is fixed in -3.

/mjt

--
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 
ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 
8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt

Bug#1061645: poco: NMU diff for 64-bit time_t transition

[Bastian Germann]

This has essentially happened because I have accidentally uploaded to unstable.
The only reverse dependency that still depends on the old SONAME is clickhouse, 
which FTBFS due to unrelated issues.
I think this can be closed.

Bug#1070236: python3-samba: SyntaxError during configuration phase of package on upgrade

[Michael Biebl]

Control: reopen -1
Control: found -1 2:4.19.6+dfsg-3

On Thu, 2 May 2024 11:58:59 -0700 "Leo L. Schwab"  wrote:

Did you fix this one, too?

---
Performing actions...
Setting up python3-samba (2:4.19.6+dfsg-2) ...
  File "/usr/lib/python3/dist-packages/samba/ms_schema_markdown.py", line 25
try
   ^
SyntaxError: expected ':'
  File "/usr/lib/python3/dist-packages/samba/ms_schema_markdown.py", line 25
try
   ^
SyntaxError: expected ':'
dpkg: error processing package python3-samba (--configure):
---

Schwab




I also get
  File "/usr/lib/python3/dist-packages/samba/ms_schema_markdown.py", 
line 27

except ImportError e:
   ^
SyntaxError: invalid syntax


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070258: release-notes: Approach to managing other package managers when upgrading needs documentation

[Manny]

Package: release-notes
Severity: normal
X-Debbugs-Cc: debbug.release-no...@sideload.33mail.com

One of the ways I got burnt in the Bullseye → Bookworm full-upgrade is
documented here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070203

There was no signal given before, during, or after the upgrade warning
that the non-debian python app “argostranslate” would be ruined. It
was just a surprise the next time the app was needed that it no longer
functioned.

I’m not sure if the release notes could give any detailed guidance,
but users should probably be instructed to minimally become aware of
packages that are at risk. These existing sections are probably
relevant:

  4.2.6. Remove non-Debian packages
  4.2.13. Check package status

Perhaps users should probably be instructed to run:

  $ pip list
  $ pip3 list
  $ pipx list

to at least become aware of non-Debian packages that might be impacted
so they can be reminded to give some thought to it. IMO it’s sensible
to save the lists from that output to a file and then refer to it
post-upgrade to test these fragile apps so the nasty surprise of lost
functionality does not manifest at the time that they need to use it,
which is about the worst time to discover the loss.

Rust also has its own package manager (cargo), as does emacs. I have
no idea if they have the same special needs that pip does. I don’t
think cargo gives a listing mechanism so perhaps nothing can be done
there.

Bug#1070257: cryptsetup: cryptroot-unlock re licensed

[Walter Lozano]

Package: cryptsetup
Severity: wishlist

Dear Maintainer,

I noticed that cryptroot-unlock was re licensed as GPL-3 in
https://salsa.debian.org/cryptsetup-
team/cryptsetup/-/commit/c350f3afc95048eb793f82ee10b02782b8129659 but from the
commit message it seems that there is no strong opinion about the license.

This change can affect the usability of this tool in some scenarios, specially
for projects with strong license policies like Apertis [1]. Also, since the
package is L/GPL-2, probably it is better to keep the main license as default,
unless there is some particular reason against that.

For these reasons I felt it could be useful to re-license back to it original
license. Similar comments apply to the cryptsetup-suspend, but since that is a
new tool it is a bit different.

Thanks in advance,

Walter

[1] https://www.apertis.org/policies/license-expectations/


-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.5.0-28-generic 
root=UUID=b7f43638-7a6b-4524-8486-6b422b4a42d9 ro 
cryptdevice=UUID=be594949-8a07-41d8-8368-81df6b982eb8 
root=/dev/mapper/nvme0n1p3_crypt ro quiet splash vt.handoff=7

-- /etc/crypttab
# 
nvme0n1p3_crypt UUID=be594949-8a07-41d8-8368-81df6b982eb8   noneluks

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
# / was on /dev/nvme0n1p2 during installation
/dev/mapper/nvme0n1p3_crypt /   ext4errors=remount-ro 0   1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=09A4-7167  /boot/efi   vfatumask=0077  0   1
/swapfile noneswapsw
  0   0

-- lsmod
Module  Size  Used by
cdc_acm45056  0
nhpoly1305_avx212288  0
nhpoly1305_sse212288  0
nhpoly1305 16384  2 nhpoly1305_avx2,nhpoly1305_sse2
adiantum   12288  0
libpoly130512288  2 adiantum,nhpoly1305
camellia_generic   45056  0
camellia_aesni_avx228672  0
camellia_aesni_avx_x86_6428672  1 camellia_aesni_avx2
camellia_x86_6461440  2 camellia_aesni_avx_x86_64,camellia_aesni_avx2
cast5_avx_x86_64   53248  0
cast5_generic  24576  1 cast5_avx_x86_64
cast_common12288  2 cast5_generic,cast5_avx_x86_64
des_generic12288  0
des3_ede_x86_6449152  0
libdes 36864  2 des_generic,des3_ede_x86_64
blowfish_generic   12288  0
blowfish_x86_6424576  0
blowfish_common16384  2 blowfish_generic,blowfish_x86_64
serpent_avx2   45056  0
serpent_avx_x86_64 49152  1 serpent_avx2
serpent_sse2_x86_6449152  0
serpent_generic24576  3 
serpent_avx2,serpent_sse2_x86_64,serpent_avx_x86_64
twofish_generic20480  0
twofish_avx_x86_64 49152  0
twofish_x86_64_3way32768  1 twofish_avx_x86_64
twofish_x86_64 16384  2 twofish_x86_64_3way,twofish_avx_x86_64
twofish_common 94208  4 
twofish_x86_64,twofish_generic,twofish_x86_64_3way,twofish_avx_x86_64
lrw12288  0
wireguard 114688  0
curve25519_x86_64  36864  1 wireguard
libchacha20poly130516384  1 wireguard
chacha_x86_64  32768  1 libchacha20poly1305
poly1305_x86_6428672  1 libchacha20poly1305
libcurve25519_generic49152  2 curve25519_x86_64,wireguard
libchacha  12288  1 chacha_x86_64
ip6_udp_tunnel 12288  1 wireguard
udp_tunnel 28672  1 wireguard
vboxnetadp 28672  0
vboxnetflt 36864  0
nft_masq   12288  1
vboxdrv   741376  2 vboxnetadp,vboxnetflt
ccm20480  3
vhost_vsock24576  0
vmw_vsock_virtio_transport_common57344  1 vhost_vsock
vhost  65536  1 vhost_vsock
vhost_iotlb16384  1 vhost
vsock  61440  2 vmw_vsock_virtio_transport_common,vhost_vsock
r8153_ecm  12288  0
cdc_ether  24576  1 r8153_ecm
usbnet 61440  2 r8153_ecm,cdc_ether
rfcomm 98304  4
snd_seq_dummy  12288  0
snd_hrtimer12288  1
r8152 143360  1 r8153_ecm
mii20480  2 usbnet,r8152
snd_usb_audio 450560  2
snd_usbmidi_lib53248  1 snd_usb_audio
snd_ump45056  1 snd_usb_audio
xt_CHECKSUM12288  1
xt_MASQUERADE  16384  3
xt_conntrack   12288  1
ipt_REJECT 12288  2
nf_reject_ipv4 16384  1 ipt_REJECT
xt_tcpudp  16384  0
nft_compat 20480  7
nft_chain_nat  12288  3
nf_nat 61440  3 nft_masq,nft_chain_nat,xt_MASQUERADE
nf_conntrack  208896  4 xt_conntrack,nf_nat,nft_masq,xt_MASQUERADE
nf_defrag_ipv6 24576  1 

Bug#1064552: mdevctl - upcoming rust-nix update.

[Athos Ribeiro]

On Thu, May 02, 2024 at 08:20:53PM +0100, Peter Green wrote:

I have now uploaded a NMU to delayed/5, final debdiff
is attatched.


Thanks, Peter.

--
Athos Ribeiro

Bug#1070235: Guix fails to pull channel with SSL error

[Vagrant Cascadian]

On 2024-05-02, Tomas Volf wrote:
> Package: guix
> Version: 1.4.0-3
>
> When I invoke `guix pull' against my channel, it fails with a SSL error:
>
> # /usr/bin/guix pull --url=https://git.wolfsden.cz/.git/guix
> Updating channel 'guix' from Git repository at 
> 'https://git.wolfsden.cz/.git/guix'...
> guix pull: error: Git error: SSL error: 0x8880 - SSL - A fatal alert 
> message was received from our peer
>
> No special configuration is needed, just booting the system and installing 
> guix
> via apt-get.

Does guix pull with the default channels work?

What certificate authority does your https server for your channel use?


> This seems to be a problem specific to Guix from the debian package.  When I 
> try
> to access the channel by other means (from the same system as above), it works
> fine.  `git clone' works just fine, and even Guix installed in non-debian way
> works fine, for example via time-machine:
>
> guix time-machine -q --commit=v1.4.0 -- pull 
> --url=https://git.wolfsden.cz/.git/guix
>
> I am using Debian 12 on 6.7.4 kernel and 2.36-9 libc, running on physical 
> server
> machine.

You seem to also be lacking the recent security update for guix
(e.g. 1.4.0-3+deb12u1), please test that version also, just in case
there is some weird hidden versioned dependency conflict (e.g. if
guile-gnutls was built against a different version of gnutls than when
guix was initially built).


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1067661: condor: unable to install condor on armhf in Ubuntu

[Tim Theisen]

My apologies. I cut and pasted the wrong bug number. However, thank you 
for the patch. I have included it in the upcoming 23.6.2 release in 
Debian. I have also incorporated this patch upstream.


--
Tim Theisen (he, him, his)
Release Manager
HTCondor & Open Science Grid
Center for High Throughput Computing
Department of Computer Sciences
University of Wisconsin - Madison
4261 Computer Sciences and Statistics
1210 W Dayton St
Madison, WI 53706-1685
+1 608 265 5736

Bug#1064516: ruby-rack: diff for NMU version 2.2.7-1.1

[Adrian Bunk]

Control: tags 1064516 + patch
Control: tags 1064516 + pending

Dear maintainer,

I've prepared an NMU for ruby-rack (versioned as 2.2.7-1.1) and uploaded 
it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian
diffstat for ruby-rack-2.2.7 ruby-rack-2.2.7

 changelog  |   10 +
 patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch |   51 ++
 patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch |   46 +
 patches/0003-Fixing-ReDoS-in-header-parsing.patch  |   30 +
 patches/series |3 
 5 files changed, 140 insertions(+)

diff -Nru ruby-rack-2.2.7/debian/changelog ruby-rack-2.2.7/debian/changelog
--- ruby-rack-2.2.7/debian/changelog	2023-07-10 17:32:41.0 +0300
+++ ruby-rack-2.2.7/debian/changelog	2024-05-02 22:55:26.0 +0300
@@ -1,3 +1,13 @@
+ruby-rack (2.2.7-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * CVE-2024-25126: ReDoS in Content Type header parsing
+  * CVE-2024-26141: Reject Range headers which are too large
+  * CVE-2024-26146: ReDoS in Accept header parsing
+  * Closes: #1064516
+
+ -- Adrian Bunk   Thu, 02 May 2024 22:55:26 +0300
+
 ruby-rack (2.2.7-1) unstable; urgency=medium
 
   * Team Upload
diff -Nru ruby-rack-2.2.7/debian/patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch ruby-rack-2.2.7/debian/patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch
--- ruby-rack-2.2.7/debian/patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch	1970-01-01 02:00:00.0 +0200
+++ ruby-rack-2.2.7/debian/patches/0001-Avoid-2nd-degree-polynomial-regexp-in-MediaType.patch	2024-05-02 22:55:26.0 +0300
@@ -0,0 +1,51 @@
+From e5c0e03f70624433d7132a5eb039f5f04787d20c Mon Sep 17 00:00:00 2001
+From: Jean Boussier 
+Date: Wed, 6 Dec 2023 18:32:19 +0100
+Subject: Avoid 2nd degree polynomial regexp in MediaType
+
+---
+ lib/rack/media_type.rb | 13 +
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+diff --git a/lib/rack/media_type.rb b/lib/rack/media_type.rb
+index 41937c99..7fc1e39d 100644
+--- a/lib/rack/media_type.rb
 b/lib/rack/media_type.rb
+@@ -4,7 +4,7 @@ module Rack
+   # Rack::MediaType parse media type and parameters out of content_type string
+ 
+   class MediaType
+-SPLIT_PATTERN = %r{\s*[;,]\s*}
++SPLIT_PATTERN = /[;,]/
+ 
+ class << self
+   # The media type (type/subtype) portion of the CONTENT_TYPE header
+@@ -15,7 +15,11 @@ module Rack
+   # http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7
+   def type(content_type)
+ return nil unless content_type
+-content_type.split(SPLIT_PATTERN, 2).first.tap &:downcase!
++if type = content_type.split(SPLIT_PATTERN, 2).first
++  type.rstrip!
++  type.downcase!
++  type
++end
+   end
+ 
+   # The media type parameters provided in CONTENT_TYPE as a Hash, or
+@@ -27,9 +31,10 @@ module Rack
+ return {} if content_type.nil?
+ 
+ content_type.split(SPLIT_PATTERN)[1..-1].each_with_object({}) do |s, hsh|
++  s.strip!
+   k, v = s.split('=', 2)
+-
+-  hsh[k.tap(&:downcase!)] = strip_doublequotes(v)
++  k.downcase!
++  hsh[k] = strip_doublequotes(v)
+ end
+   end
+ 
+-- 
+2.30.2
+
diff -Nru ruby-rack-2.2.7/debian/patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch ruby-rack-2.2.7/debian/patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch
--- ruby-rack-2.2.7/debian/patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch	1970-01-01 02:00:00.0 +0200
+++ ruby-rack-2.2.7/debian/patches/0002-Return-an-empty-array-when-ranges-are-too-large.patch	2024-05-02 22:55:26.0 +0300
@@ -0,0 +1,46 @@
+From e4a334bba45d1f66499973d65ba4db2679129153 Mon Sep 17 00:00:00 2001
+From: Aaron Patterson 
+Date: Tue, 13 Feb 2024 13:34:34 -0800
+Subject: Return an empty array when ranges are too large
+
+If the sum of the requested ranges is larger than the file itself,
+return an empty array. In other words, refuse to respond with any bytes.
+
+[CVE-2024-26141]
+---
+ lib/rack/utils.rb  | 3 +++
+ test/spec_utils.rb | 4 
+ 2 files changed, 7 insertions(+)
+
+diff --git a/lib/rack/utils.rb b/lib/rack/utils.rb
+index c8e61ea1..72700503 100644
+--- a/lib/rack/utils.rb
 b/lib/rack/utils.rb
+@@ -380,6 +380,9 @@ module Rack
+ end
+ ranges << (r0..r1)  if r0 <= r1
+   end
++
++  return [] if ranges.map(&:size).sum > size
++
+   ranges
+ end
+ 
+diff --git a/test/spec_utils.rb b/test/spec_utils.rb
+index 90676258..6b069914 100644
+--- a/test/spec_utils.rb
 b/test/spec_utils.rb
+@@ -590,6 +590,10 @@ describe Rack::Utils, "cookies" do
+ end
+ 
+ describe Rack::Utils, "byte_range" do
++  it "returns an empty list if the sum of the ranges is too large" do
++ 

Bug#968415: susv4: Patch

[Matthew A. Lukowicz]

Package: susv4
Version: 7.20180621
Followup-For: Bug #968415
X-Debbugs-Cc: mlukow...@sdf.org

--- debian/susv4.postinst.orig  2024-05-02 15:56:25.243665232 -0400
+++ debian/susv4.postinst   2024-05-02 15:56:34.133076612 -0400
@@ -8,7 +8,7 @@
 wget -P $TEMPDIR 
http://pubs.opengroup.org/onlinepubs/9699919799/download/susv4-2018.tar.bz2
 
 echo Verifying SHA512 checksum...
-SHA512SUM="c356d8b9b311201bef8900add7aab18b822af0e6e1a0c63b141c7c5f5e401bf25f39dcf9976577e934b7bfc939574c965ebefd63fef7a57ad6feb875e237fd7d"
+SHA512SUM="2484d24d19b9731808c61219b61d63cdf4d8dff6498fb4655478b76808a583064a5cfbcfcf18f1d27c56e03a6b47cc6833f94483784ec29059bef063724c2567"
 [ x"$(sha512sum $TEMPDIR/susv4-2018.tar.bz2 | cut -f1 -d\ )" = x"$SHA512SUM" ] 
|| (rm -rf $TEMPDIR; exit 1)
 
 echo Untarring...

-- 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.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages susv4 depends on:
ii  bzip2  1.0.8-5.1
ii  wget   1.24.5-1

susv4 recommends no packages.

susv4 suggests no packages.

-- no debconf information

Bug#1070243: dicomnifti 2.33.1-5: ROM; Obsolete

[Andreas Beckmann]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: dicomnifti -- ROM; Obsolete

On Thu, 2 May 2024 12:15:48 -0400 Valerio Luccio 
 wrote:

Package: dicomnifti 2.33.1-5

Software not compatible with most recent DICOM image version and will 
not be updated.


I assume you wanted to file a RM request for ftpmaster. I've reassigned 
and retitled the bug accordingly.


Hint: using reportbug to file such requests helps getting bug metadata 
(title formatting, tags, ...) in the right format.


Andreas

Bug#968415: susv4: Patch with new sha512sum

[Matthew A. Lukowicz]

Package: susv4
Version: 7.20180621
Followup-For: Bug #968415
X-Debbugs-Cc: mlukow...@sdf.org

Dear Maintainer,

--- debian/susv4/DEBIAN/postinst.orig   2024-05-02 15:49:52.972725058 -0400
+++ debian/susv4/DEBIAN/postinst2024-05-02 15:50:01.506839488 -0400
@@ -8,7 +8,7 @@
 wget -P $TEMPDIR 
http://pubs.opengroup.org/onlinepubs/9699919799/download/susv4-2018.tar.bz2
 
 echo Verifying SHA512 checksum...
-SHA512SUM="c356d8b9b311201bef8900add7aab18b822af0e6e1a0c63b141c7c5f5e401bf25f39dcf9976577e934b7bfc939574c965ebefd63fef7a57ad6feb875e237fd7d"
+SHA512SUM="2484d24d19b9731808c61219b61d63cdf4d8dff6498fb4655478b76808a583064a5cfbcfcf18f1d27c56e03a6b47cc6833f94483784ec29059bef063724c2567"
 [ x"$(sha512sum $TEMPDIR/susv4-2018.tar.bz2 | cut -f1 -d\ )" = x"$SHA512SUM" ] 
|| (rm -rf $TEMPDIR; exit 1)
 
 echo Untarring...

-- 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.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages susv4 depends on:
ii  bzip2  1.0.8-5.1
ii  wget   1.24.5-1

susv4 recommends no packages.

susv4 suggests no packages.

-- no debconf information

Bug#1070254: ktp-text-ui FTBFS: undefined reference to `snappy::RawCompress(char const*, unsigned long, char*, unsigned long*)'

[Patrick Franz]

Hej,

Am Donnerstag, 2. Mai 2024, 15:24:07 CEST schrieb Helmut Grohne:
> Source: ktp-text-ui
> Version: 22.12.3-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in
> the past)
> 
> ktp-text-ui fails to build from source in unstable on amd64. The

[...] 

> | /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.10 /usr/bin/ld:
> | /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5.15.15: undefined
> | reference to `snappy::RawCompress(char const*, unsigned long,
> | char*, unsigned long*)' collect2: error: ld returned 1 exit status

That looks like it's https://bugs.debian.org/cgi-bin/bugreport.cgi?
bug=1070254 for which a fix has been uploaded.

I guess trying to rebuild it tomorrow will fix this build error.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1070203: python3-pip: app silently lost in upgrade to Bookworm + pip3 lost track of the status (4 bugs)

[Manny]

> If you upgrade from bullseye to bookworm, your python3 is upgraded from
> 3.9 to 3.11. These are incompatible versions, and install libraries to
> different paths (when you use pip3).
> Anything installed with pip on 3.9 will not be importable in 3.11.

Thanks for the explanation. That explains bug ① (“an app module was
dropped/lost”). Apparently that bug cannot realistically be remedied,
although perhaps the release notes should cover this topic.

I’m a bit confused because “pip3 list” shows a list of 146 packages,
but not argostranslation. Why did all those other packages survive the
upgrade?  I wonder if some of them are somehow managed by apt.

There are still 3 other bugs.

> So, I'm afraid you're well out of the supported area of pip.
> Sorry.

Is it necessary for aptitude full-upgrade to withhold information from
the user about package destruction or removal?  Ideally users would
get a loud warning when actions are taken that are expected to impact
an installed package. If it’s a mission critical tool, users need to
be able to back out of the upgrade and assess the consequences.

I would also like to mention a fifth defect I just discovered:

⑤ argostranslate was only /partially/ removed.

There are some big language files that were originally installed by
argostranslate. The argostranslate executable survived the upgrade but
not some of the modules it relies on, leaving it in a broken partially
existent state with no information given to the user. The language
packs remained in tact. I don’t know where on the filesystem they
live, but when I installed argostranslate again the previous language
packs were found and automatically available for use.

In my case, this happened to be a benefit as it saved me from the
effort of refetching the language files. But it’s probably not an
favorable general behavior for packages to be partially
removed. Ideally the user should receive a warning about pending
removal and an option for a clean removal or a partial removal.

The pip package manager has an uninstall procedure and since pip is
the manager of the argostranslate package, users rely on it to keep
track of the objects associated to the application.

> Can I suggest using pipx for installing applications instead? It
> actually understands this problem and has a "reinstall-all" feature to
> help you recover from Python minor-version upgrades.

I really appreciate the suggestion. I gave it a try. It had several
issues, but it could very well turn out to be the lesser of
evils. After several hurdles pipx was able to install argostranslate
in the end.

Bug#1065459: rust-smol - upcoming rust-nix update.

[Peter Green]

On 04/03/2024 23:24, Peter Green wrote:

Package: rust-smol

I am currently preparing to update the rust-nix pacakge to version 0.27.

The smol crate has a dev-dependency on the nix crate, which the Debian
packaging translates to build and autopkgtest dependencies. After
relaxing the dependencies to allow the new version.

The new rust-nix package is available in experimental. A debdiff
is attached.

I have now uploaded the new version of nix to unstable and uploaded
this as a NMU, final debdiff is attached.

diff -Nru rust-smol-1.3.0/debian/changelog rust-smol-1.3.0/debian/changelog
--- rust-smol-1.3.0/debian/changelog2024-02-01 19:28:09.0 +
+++ rust-smol-1.3.0/debian/changelog2024-05-02 17:16:46.0 +
@@ -1,3 +1,10 @@
+rust-smol (1.3.0-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Allow building with nix 0.27 (Closes: #1065459).
+
+ -- Peter Michael Green   Thu, 02 May 2024 17:16:46 +
+
 rust-smol (1.3.0-5) unstable; urgency=medium
 
   * add patches 2001_async_* to accept older crates;
diff -Nru rust-smol-1.3.0/debian/control rust-smol-1.3.0/debian/control
--- rust-smol-1.3.0/debian/control  2024-02-01 19:14:29.0 +
+++ rust-smol-1.3.0/debian/control  2024-05-02 17:16:01.0 +
@@ -24,7 +24,7 @@
  librust-hyper-0.14+stream-dev ,
  librust-inotify-0-dev (<< 0.11) ,
  librust-native-tls-0.2+default-dev ,
- librust-nix-0+default-dev (<< 0.27) ,
+ librust-nix-0+default-dev (<< 0.28) ,
  librust-nix-0+default-dev (>= 0.23) ,
  librust-signal-hook-0.3+default-dev ,
  librust-tempfile-3+default-dev ,
diff -Nru rust-smol-1.3.0/debian/patches/1001_nix.patch 
rust-smol-1.3.0/debian/patches/1001_nix.patch
--- rust-smol-1.3.0/debian/patches/1001_nix.patch   2023-08-20 
08:25:51.0 +
+++ rust-smol-1.3.0/debian/patches/1001_nix.patch   2024-05-02 
17:16:01.0 +
@@ -10,7 +10,7 @@
  [target.'cfg(target_os = "linux")'.dev-dependencies]
  inotify = { version = "0.10", default-features = false }
 -nix = "0.24"
-+nix = ">= 0.24, < 0.27"
++nix = ">= 0.24, < 0.28"
  timerfd = "1"
  
  [target.'cfg(windows)'.dev-dependencies]
diff -Nru rust-smol-1.3.0/debian/patches/2001_inotify.patch 
rust-smol-1.3.0/debian/patches/2001_inotify.patch
--- rust-smol-1.3.0/debian/patches/2001_inotify.patch   2023-08-20 
08:25:51.0 +
+++ rust-smol-1.3.0/debian/patches/2001_inotify.patch   2024-05-02 
17:16:01.0 +
@@ -13,5 +13,5 @@
  [target.'cfg(target_os = "linux")'.dev-dependencies]
 -inotify = { version = "0.10", default-features = false }
 +inotify = { version = ">= 0.9, < 0.11", default-features = false }
- nix = ">= 0.24, < 0.27"
+ nix = ">= 0.24, < 0.28"
  timerfd = "1"
diff -Nru rust-smol-1.3.0/debian/patches/2001_windows.patch 
rust-smol-1.3.0/debian/patches/2001_windows.patch
--- rust-smol-1.3.0/debian/patches/2001_windows.patch   2023-08-20 
08:25:51.0 +
+++ rust-smol-1.3.0/debian/patches/2001_windows.patch   2024-05-02 
17:16:01.0 +
@@ -8,7 +8,7 @@
 +++ b/Cargo.toml
 @@ -50,6 +50,3 @@
  inotify = { version = "0.10", default-features = false }
- nix = ">= 0.24, < 0.27"
+ nix = ">= 0.24, < 0.28"
  timerfd = "1"
 -
 -[target.'cfg(windows)'.dev-dependencies]

Bug#1070236: python3-samba: SyntaxError during configuration phase of package on upgrade

[Leo L. Schwab]

Did you fix this one, too?

---
Performing actions...
Setting up python3-samba (2:4.19.6+dfsg-2) ...
  File "/usr/lib/python3/dist-packages/samba/ms_schema_markdown.py", line 25
try
   ^
SyntaxError: expected ':'
  File "/usr/lib/python3/dist-packages/samba/ms_schema_markdown.py", line 25
try
   ^
SyntaxError: expected ':'
dpkg: error processing package python3-samba (--configure):
---

Schwab

Bug#1070256: libcxx-serial FTBFS with the nocheck build profile

[Helmut Grohne]

Source: libcxx-serial
Version: 1.2.1-5
Severity: serious
Justification: nocheck ftbfs is rc since trixie
Tags: ftbfs trixie sid

libcxx-serial fails to build from source when enabling the nocheck build
profile. I think the relevant part is:

| -- catkin 0.8.10
| -- BUILD_SHARED_LIBS is on
| CMake Error at /usr/share/catkin/cmake/test/tests.cmake:21 (message):
|   () is not available when tests are not enabled.  The CMake code should only
|   use it inside a conditional block which checks that testing is enabled:
| 
|   if(CATKIN_ENABLE_TESTING)
| 
| (...)
| 
|   endif()
| 
| Call Stack (most recent call first):
|   tests/CMakeLists.txt:20 (catkin_add_gtest)
| 
| 
| -- Configuring incomplete, errors occurred!
| cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt
| ==> CMakeCache.txt <==

Helmut

Bug#1070255: midish FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: midish
Version: 1.0.4-1.2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

midish fails to cross build from source, because it builds for the build
architecture. It's configure script doesn't take architecture into
account and mostly configures paths. Cross tools need to be passed to
make just as is done in a traditional make-only project. I'm attaching a
patch for your convenience.

Helmut
diff --minimal -Nru midish-1.0.4/debian/changelog midish-1.0.4/debian/changelog
--- midish-1.0.4/debian/changelog   2022-11-03 22:49:04.0 +0100
+++ midish-1.0.4/debian/changelog   2024-05-02 07:37:47.0 +0200
@@ -1,3 +1,10 @@
+midish (1.0.4-1.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 02 May 2024 07:37:47 +0200
+
 midish (1.0.4-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru midish-1.0.4/debian/rules midish-1.0.4/debian/rules
--- midish-1.0.4/debian/rules   2022-11-03 22:49:04.0 +0100
+++ midish-1.0.4/debian/rules   2024-05-02 07:37:47.0 +0200
@@ -12,7 +12,7 @@
 build: build-stamp
 build-stamp: configure-stamp
dh_testdir
-   $(MAKE)
+   dh_auto_build --buildsystem=makefile
touch build-stamp
 
 clean:

Bug#1070254: ktp-text-ui FTBFS: undefined reference to `snappy::RawCompress(char const*, unsigned long, char*, unsigned long*)'

[Helmut Grohne]

Source: ktp-text-ui
Version: 22.12.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

ktp-text-ui fails to build from source in unstable on amd64. The
relevant log probably is:

| [ 76%] Linking CXX executable ktp-text-ui
| cd /<>/obj-x86_64-linux-gnu/app && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/ktp-text-ui.dir/link.txt --verbose=1
| /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 
-fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align 
-Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef 
-Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Werror=init-self 
-Wvla -Wdate-time -Wsuggest-override -Wlogical-op -Wl,--enable-new-dtags 
-Wl,-z,relro 
"CMakeFiles/ktp-text-ui.dir/ktp-text-ui_autogen/mocs_compilation.cpp.o" 
"CMakeFiles/ktp-text-ui.dir/main.cpp.o" 
"CMakeFiles/ktp-text-ui.dir/telepathy-chat-ui.cpp.o" 
"CMakeFiles/ktp-text-ui.dir/chat-window.cpp.o" 
"CMakeFiles/ktp-text-ui.dir/chat-tab.cpp.o" 
"CMakeFiles/ktp-text-ui.dir/emoticon-text-edit-action.cpp.o" 
"CMakeFiles/ktp-text-ui.dir/emoticon-text-edit-selector.cpp.o" 
"CMakeFiles/ktp-text-ui.dir/invite-contact-dialog.cpp.o" -o ktp-text-ui  
-Wl,-rpath,/<>/obj-x86_64-linux-gnu/lib:/<>/obj-x86_64-linux-gnu/image-sharer:
 /usr/lib/x86_64-linux-gnu/libQt5WebEngine.so.5.15.15 ../lib/libktpchat.so 
/usr/lib/x86_64-linux-gnu/libKF5PeopleWidgets.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Emoticons.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKTpWidgets.so.22.12.3 
/usr/lib/x86_64-linux-gnu/libKTpModels.so.22.12.3.abi1 
/usr/lib/x86_64-linux-gnu/libKF5NotifyConfig.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5KCMUtils.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5TextWidgets.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5SonnetUi.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5SonnetCore.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKTpLogger.so.22.12.3.abi1 
/usr/lib/x86_64-linux-gnu/libKTpCommonInternals.so.22.12.3.abi1 
/usr/lib/x86_64-linux-gnu/libKF5Wallet.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Notifications.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libtelepathy-logger-qt.so.0.9.80.0 
/usr/lib/x86_64-linux-gnu/libtelepathy-qt5.so.0.0.9.8 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so.5.15.15 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5.15.15 
/usr/lib/x86_64-linux-gnu/libQt5WebChannel.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5Positioning.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5QmlModels.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5PrintSupport.so.5.15.10 
../image-sharer/libktpimagesharer.so 
/usr/lib/x86_64-linux-gnu/libKF5KIOWidgets.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5KIOGui.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5JobWidgets.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Service.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Solid.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Completion.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5IconThemes.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5ConfigWidgets.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5ConfigGui.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5ConfigCore.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Codecs.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Auth.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5AuthCore.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5Archive.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5WindowSystem.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libX11.so 
/usr/lib/x86_64-linux-gnu/libQt5Concurrent.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libKTpOTR.so.22.12.3 
/usr/lib/x86_64-linux-gnu/libtelepathy-qt5.so.0.0.9.8 
/usr/lib/x86_64-linux-gnu/libQt5Network.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5Xml.so.5.15.10 -fPIC 
/usr/lib/x86_64-linux-gnu/libKF5WidgetsAddons.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5People.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5CoreAddons.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libKF5I18n.so.5.107.0 
/usr/lib/x86_64-linux-gnu/libQt5DBus.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.10 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.10
| /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5.15.15: 
undefined reference to `snappy::RawCompress(char const*, unsigned long, char*, 
unsigned long*)'
| collect2: error: ld returned 1 exit status
| make[3]: *** [app/CMakeFiles/ktp-text-ui.dir/build.make:220: app/ktp-text-ui] 
Error 1
| make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[2]: *** [CMakeFiles/Makefile2:1633: app/CMakeFiles/ktp-text-ui.dir/all] 
Error 2
| make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[1]: *** [Makefile:149: all] Error 2
| 

Bug#1070253: ddnet FTCBFS: upstream has rather un-Debiann-ish ideas about how cross compilation should work

[Helmut Grohne]

Source: ddnet
Version: 16.4-1.3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Hi,

ddnet fails to cross build from source. Digging into this I found that
ddnet upstream has a very different idea about cross building from
Debian. For instance, ddnet stops using any kind of system libraries and
expects that you vendor them all into the ddnet source code. Also they
immediately opt out of using pkgconf for cross compilation. This is very
much not what we do in Debian. I managed to make it cross buildable, but
given how ddnet upstream has chosen to implement cross building, I
expect that they very much won't like this patch. Possibly, there could
be some kind of global switch between that vendoring-world that they
want and that "like native" world that Debian's cross build environment
is? Do you mind maintaining this patch in the source package?

Helmut
--- ddnet-16.4.orig/CMakeLists.txt
+++ ddnet-16.4/CMakeLists.txt
@@ -493,7 +493,7 @@
 # be more aggressive with android toolchain
 set(CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH NO_CMAKE_SYSTEM_PATH NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
   else()
-set(CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH NO_CMAKE_SYSTEM_PATH)
+set(CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH)
   endif()
 else()
   set(CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH)
@@ -512,11 +512,9 @@
   endif()
 endfunction()
 
-if(NOT CMAKE_CROSSCOMPILING)
-  # Check for PkgConfig once so all the other `find_package` calls can do it
-  # quietly.
-  find_package(PkgConfig)
-endif()
+# Check for PkgConfig once so all the other `find_package` calls can do it
+# quietly.
+find_package(PkgConfig)
 if(TARGET_OS STREQUAL "android")
   find_package(Android)
 endif()
--- ddnet-16.4.orig/cmake/FindMySQL.cmake
+++ ddnet-16.4/cmake/FindMySQL.cmake
@@ -1,3 +1,7 @@
+find_package(PkgConfig QUIET)
+pkg_check_modules(MYSQLCLIENT mysqlclient)
+pkg_check_modules(LIBMARIADB libmariadb)
+
 if(NOT CMAKE_CROSSCOMPILING)
   find_program(MYSQL_CONFIG
 NAMES mysql_config mariadb_config
@@ -39,13 +43,13 @@
 set_extra_dirs_lib(MYSQL mysql)
 find_library(MYSQL_LIBRARY
   NAMES "mysqlclient" "mysqlclient_r" "mariadbclient"
-  HINTS ${MYSQL_CONFIG_LIBRARY_PATH}
+  HINTS ${MYSQL_CONFIG_LIBRARY_PATH} ${MYSQLCLIENT_LIBRARY_DIRS} ${LIBMARIADB_LIBRARY_DIRS}
   ${CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH}
 )
 set_extra_dirs_include(MYSQL mysql "${MYSQL_LIBRARY}")
 find_path(MYSQL_INCLUDEDIR
   NAMES "mysql.h"
-  HINTS ${MYSQL_CONFIG_INCLUDE_DIR}
+  HINTS ${MYSQL_CONFIG_INCLUDE_DIR} ${MYSQLCLIENT_INCLUDE_DIRS} ${LIBMARIADB_INCLUDE_DIRS}
   ${CROSSCOMPILING_NO_CMAKE_SYSTEM_PATH}
 )
 

Bug#1064580: netavark - diff for NMU 1.4.0-4.1

[Peter Green]

A debdiff is attatched, if I get no response I will likely NMU this when the
new rust-nix is uploaded to unstable.


As promised I have uploaded this.



During a rebuild of all packages in sid, your package failed to build
on arm64.


This fit the zero-day NMU guidelines, and my NMU would have FTBFS if I
didn't fix it. So I added a fix for is to the NMU.

Final debdiff is attatched.diff -Nru netavark-1.4.0/debian/changelog netavark-1.4.0/debian/changelog
--- netavark-1.4.0/debian/changelog 2023-09-06 22:46:22.0 +
+++ netavark-1.4.0/debian/changelog 2024-05-02 17:08:20.0 +
@@ -1,3 +1,11 @@
+netavark (1.4.0-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patch for new version of rust-nix (Closes: #1064580)
+  * Relax cargo dependency on sysctl crate (Closes: #1069350)
+
+ -- Peter Michael Green   Thu, 02 May 2024 17:08:20 +
+
 netavark (1.4.0-4) unstable; urgency=medium
 
   [ Peter Michael Green ]
diff -Nru netavark-1.4.0/debian/control netavark-1.4.0/debian/control
--- netavark-1.4.0/debian/control   2023-09-06 22:46:22.0 +
+++ netavark-1.4.0/debian/control   2024-05-02 16:54:53.0 +
@@ -18,7 +18,7 @@
  librust-libc-dev,
  librust-log-dev,
  librust-netlink-packet-route-0.17-dev,
- librust-nix-dev,
+ librust-nix-0.27-dev,
  librust-rand-dev,
  librust-rtnetlink-dev,
  librust-serde+derive-dev,
diff -Nru netavark-1.4.0/debian/patches/nix-0.27.patch 
netavark-1.4.0/debian/patches/nix-0.27.patch
--- netavark-1.4.0/debian/patches/nix-0.27.patch1970-01-01 
00:00:00.0 +
+++ netavark-1.4.0/debian/patches/nix-0.27.patch2024-05-02 
17:02:52.0 +
@@ -0,0 +1,42 @@
+This patch is based on the upstream commit described below, adapted for use
+in the Debian package by Peter Michael Green.
+
+commit 61b8e62f4205b1b2609054bb0d07771b56a5ef9c
+Author: Paul Holzinger 
+Date:   Mon Sep 11 18:13:13 2023 +0200
+
+bump nix to 0.27.1
+
+The nix crate removes all features by default so we need to explicitly
+list what we use.
+Second, the io API's changed and all use the AsFd trait now. This is
+great for IO safety but will require larger changes to migrate from
+RawFd. Thus I went the easy way and use unsafe (not really unsafe here)
+and construct and a new BorrowedFd object (which impl AsFd) for the
+setns call.
+
+Signed-off-by: Paul Holzinger 
+
+Index: netavark-1.4.0/Cargo.toml
+===
+--- netavark-1.4.0.orig/Cargo.toml
 netavark-1.4.0/Cargo.toml
+@@ -34,1 +34,1 @@ serde_json = "1"
+-nix = "0.26.1"
++nix = { version = "0.27.1", features = ["sched", "signal", "user", "fs"] }
+Index: netavark-1.4.0/src/network/core_utils.rs
+===
+--- netavark-1.4.0.orig/src/network/core_utils.rs
 netavark-1.4.0/src/network/core_utils.rs
+@@ -260,7 +260,10 @@ impl CoreUtils {
+ }
+ 
+ pub fn join_netns(fd: RawFd) -> NetavarkResult<()> {
+-match sched::setns(fd, sched::CloneFlags::CLONE_NEWNET) {
++match sched::setns(
++unsafe { BorrowedFd::borrow_raw(fd) },
++sched::CloneFlags::CLONE_NEWNET,
++) {
+ Ok(_) => Ok(()),
+ Err(e) => Err(NetavarkError::wrap(
+ "setns",
diff -Nru netavark-1.4.0/debian/patches/relax-deps.patch 
netavark-1.4.0/debian/patches/relax-deps.patch
--- netavark-1.4.0/debian/patches/relax-deps.patch  2023-09-06 
22:46:22.0 +
+++ netavark-1.4.0/debian/patches/relax-deps.patch  2024-05-02 
16:59:29.0 +
@@ -19,7 +19,7 @@
 +serde = { version = "1", features = ["derive"], optional = true }
 +serde-value = "0.7"
 +serde_json = "1"
-+sysctl = "0.4"
++sysctl = ">= 0.4"
  url = "2.3.1"
  zbus = { version = "3.6.1" }
  nix = "0.26.1"
diff -Nru netavark-1.4.0/debian/patches/series 
netavark-1.4.0/debian/patches/series
--- netavark-1.4.0/debian/patches/series2023-09-06 22:46:22.0 
+
+++ netavark-1.4.0/debian/patches/series2024-05-02 16:54:53.0 
+
@@ -3,3 +3,4 @@
 debian-paths.patch
 netlink-0.5.patch
 netlink-0.7.patch
+nix-0.27.patch

Bug#1064480: aardvark-dns - upcoming rust-nix update.

[Peter Green]

On 29/02/2024 12:22, Marc Dequènes (duck) wrote:


I do not have a proper Internet connexion in my new Pond yet so I'd gladly let you upload it :-). 

Done

Final debdiff is attatched.diff -Nru greetd-0.9.0/debian/changelog greetd-0.9.0/debian/changelog
--- greetd-0.9.0/debian/changelog   2023-12-21 14:17:58.0 +
+++ greetd-0.9.0/debian/changelog   2024-05-02 16:30:23.0 +
@@ -1,3 +1,11 @@
+greetd (0.9.0-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patch for nix 0.27 (Closes: #1064480)
+  * Tighten build-dependency on nix.
+
+ -- Peter Michael Green   Thu, 02 May 2024 16:30:23 +
+
 greetd (0.9.0-6) unstable; urgency=medium
 
   * Relax dependency on rpassword (Closes: #1057931).
diff -Nru greetd-0.9.0/debian/control greetd-0.9.0/debian/control
--- greetd-0.9.0/debian/control 2023-12-21 14:17:58.0 +
+++ greetd-0.9.0/debian/control 2024-05-02 16:26:04.0 +
@@ -6,7 +6,7 @@
  debhelper-compat (= 13),
  dh-cargo,
 # greetd & greetd_ipc
- librust-nix-dev (>= 0.25),
+ librust-nix-0.27-dev,
  librust-pam-sys-dev (>= 0.5.6),
  librust-users-dev (>= 0.11.0),
  librust-serde-derive-dev (>= 1.0),
diff -Nru greetd-0.9.0/debian/patches/nix-0.27.patch 
greetd-0.9.0/debian/patches/nix-0.27.patch
--- greetd-0.9.0/debian/patches/nix-0.27.patch  1970-01-01 00:00:00.0 
+
+++ greetd-0.9.0/debian/patches/nix-0.27.patch  2024-05-02 16:26:04.0 
+
@@ -0,0 +1,43 @@
+This patch is based on the upstream commit described below, adapted for use
+in the Debian package by Peter Michael Green.
+
+commit 161218164d366482ab7fab9dcc59cbd40623ac2c
+Author: Kenny Levinsen 
+Date:   Wed Feb 7 15:14:24 2024 +0100
+
+Update dependencies
+
+diff --git a/greetd/Cargo.toml b/greetd/Cargo.toml
+index c206ac1..3b1446f 100644
+--- a/greetd/Cargo.toml
 b/greetd/Cargo.toml
+@@ -14,1 +14,1 @@ repository = "https://git.sr.ht/~kennylevinsen/greetd/;
+-nix = "0.26"
++nix = { version = "0.27", features = ["ioctl", "signal", "user", "fs", 
"mman"] }
+diff --git a/greetd/src/main.rs b/greetd/src/main.rs
+index b88c6dc..92a53d4 100644
+--- a/greetd/src/main.rs
 b/greetd/src/main.rs
+@@ -22,7 +22,7 @@ use crate::{error::Error, session::worker};
+ 
+ async fn session_worker_main(config: config::Config) -> Result<(), Error> {
+ let raw_fd = config.internal.session_worker as RawFd;
+-let mut cur_flags = unsafe { FdFlag::from_bits_unchecked(fcntl(raw_fd, 
FcntlArg::F_GETFD)?) };
++let mut cur_flags = FdFlag::from_bits_retain(fcntl(raw_fd, 
FcntlArg::F_GETFD)?);
+ cur_flags.insert(FdFlag::FD_CLOEXEC);
+ fcntl(raw_fd, FcntlArg::F_SETFD(cur_flags))?;
+ let sock = unsafe { UnixDatagram::from_raw_fd(raw_fd) };
+diff --git a/greetd/src/session/interface.rs b/greetd/src/session/interface.rs
+index f1d3f04..b31f47f 100644
+--- a/greetd/src/session/interface.rs
 b/greetd/src/session/interface.rs
+@@ -99,8 +99,7 @@ impl Session {
+ UnixDatagram::pair().map_err(|e| format!("could not create pipe: 
{}", e))?;
+ 
+ let raw_child = childfd.as_raw_fd();
+-let mut cur_flags =
+-unsafe { FdFlag::from_bits_unchecked(fcntl(raw_child, 
FcntlArg::F_GETFD)?) };
++let mut cur_flags = FdFlag::from_bits_retain(fcntl(raw_child, 
FcntlArg::F_GETFD)?);
+ cur_flags.remove(FdFlag::FD_CLOEXEC);
+ fcntl(raw_child, FcntlArg::F_SETFD(cur_flags))?;
+ 
diff -Nru greetd-0.9.0/debian/patches/relax_deps.patch 
greetd-0.9.0/debian/patches/relax_deps.patch
--- greetd-0.9.0/debian/patches/relax_deps.patch2023-12-21 
14:17:58.0 +
+++ greetd-0.9.0/debian/patches/relax_deps.patch2024-05-02 
16:26:04.0 +
@@ -15,15 +15,4 @@
  getopts = "0.2"
  enquote = "1.1"
 -nix = "0.26"
-+nix = ">=0.26"
 a/greetd/Cargo.toml
-+++ b/greetd/Cargo.toml
-@@ -11,7 +11,7 @@
- debug = []
- 
- [dependencies]
--nix = "0.26"
-+nix = ">=0.26"
- pam-sys = "0.5.6"
- users = "0.11.0"
- serde = { version = "1.0", features = ["derive"] }
++nix = ">= 0.26"
diff -Nru greetd-0.9.0/debian/patches/series greetd-0.9.0/debian/patches/series
--- greetd-0.9.0/debian/patches/series  2023-12-21 14:17:58.0 +
+++ greetd-0.9.0/debian/patches/series  2024-05-02 16:26:04.0 +
@@ -2,3 +2,4 @@
 config_tweaks.patch
 relax_deps.patch
 rpassword_6.0_adaptation.patch
+nix-0.27.patch

Bug#1064479: aardvark-dns - upcoming rust-nix update.

[Peter Green]

if I get no response I will likely NMU this when the
new rust-nix is uploaded to unstable.


I have now uploaded rust-nix to unstable and uploaded
the nmu for this package.

Final debdiff is attatched (really this time)
diff -Nru aardvark-dns-1.4.0/debian/changelog 
aardvark-dns-1.4.0/debian/changelog
--- aardvark-dns-1.4.0/debian/changelog 2023-09-07 00:45:48.0 +
+++ aardvark-dns-1.4.0/debian/changelog 2024-05-02 16:14:54.0 +
@@ -1,3 +1,12 @@
+aardvark-dns (1.4.0-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax cargo dependency on nix to support 0.27 and explicitly enable
+required features, since nix no longer enables any features by default.
+(Closes: #1064479)
+
+ -- Peter Michael Green   Thu, 02 May 2024 16:14:54 +
+
 aardvark-dns (1.4.0-5) unstable; urgency=medium
 
   * Build against clap version 4, Closes: #1040876, #1040877
diff -Nru aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 
aardvark-dns-1.4.0/debian/patches/update-dependencies.patch
--- aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 2023-09-07 
00:45:48.0 +
+++ aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 2024-05-02 
16:14:43.0 +
@@ -25,7 +25,7 @@
 +async-broadcast = ">= 0.4.1"
  resolv-conf = "0.7.0"
 -nix = "0.25.0"
-+nix = "0.26"
++nix = { version = ">= 0.25.0", features = ["fs", "signal"] }
  libc = "0.2"
  
  [build-dependencies]

Bug#1064479: aardvark-dns - upcoming rust-nix update.

[Peter Green]

if I get no response I will likely NMU this when the
new rust-nix is uploaded to unstable.


I have now uploaded rust-nix to unstable and uploaded
the nmu for this package.

Final debdiff is attatched.

Bug#998627: linux: please enable the new NTFS3 driver in 5.15

[Christoph Anton Mitterer]

Hey.

Seems there were at least a series of commits from upstream last
November and few again this January.
And there even seem to be some more in their dev branch.


The number of CVEs mentioned by Salvatore is worrying, but it looks
even much worse over the years for ntfs-3g:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ntfs-3g

Plus it seems ntfs-3g upstream is even less active than ntfs3's:
https://github.com/tuxera/ntfs-3g/
Last commit June 2023.


Of course this could also just mean that ntfs-3g is simply more mature
and less issues are found - dunno.
Security-wise the same, could mean that they've no ironed out all
issues, or simply no-one looks at it anymore.


What I did notice in this bug is that quite some people pushed for
enabling it, with email addresses that look in style similar to those
that where used in the XZ social engineering or like throw away
addresses.



Cheers,
Chris.

Bug#1069681: less does not escape special characters when outputting the filename

[Salvatore Bonaccorso]

Hi Milan,

On Thu, May 02, 2024 at 12:54:10PM -0400, Milan Kupcevic wrote:
> Hi Salvatore,
> 
> On 5/2/24 10:45, Salvatore Bonaccorso wrote:
> [...]
> > 
> > I did ponder about it and trying to add this fix as well for the
> > upcoming less DSA, but it won't go apply for the older releases and
> > the issue is compared minor enough.
> > 
> > I think I will go ahead with the two CVE fixes only.
> > 
> Take a look at the attached patch. It applies and fixes the bookworm and
> bullseye versions. It seems the buster version is not vulnerable to this
> particular issue.

Ah right that's the same you applied in unstable AFAICS and
backported. I will have a look, so that could make it as well into the
DSA released version.

Thanks a lot!

Regards,
Salvatore

Bug#1070252: sublime-music: playback broken by libmpv 0.38

[Louis-Philippe Véronneau]

Package: sublime-music
Version: 0.12.0-1
Severity: critical
Forwarded: https://github.com/sublime-music/sublime-music/issues/462

Using libmpv2 0.38, the playback is broken an results in the following trace:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sublime_music/dbus/manager.py", line 24, 
in wrapper
function(*args)
  File "/usr/lib/python3/dist-packages/sublime_music/app.py", line 629, in 
on_play_pause
self.play_song(self.app_config.state.current_song_index)
  File "/usr/lib/python3/dist-packages/sublime_music/app.py", line 1415, in 
play_song
song_details_future.add_done_callback(
  File "/usr/lib/python3/dist-packages/sublime_music/adapters/manager.py", line 
140, in add_done_callback
fn(self, *args)
  File "/usr/lib/python3/dist-packages/sublime_music/app.py", line 1416, in 

lambda f: do_play_song(self.song_playing_order_token, f.result())
  ^^^
  File "/usr/lib/python3/dist-packages/sublime_music/dbus/manager.py", line 24, 
in wrapper
function(*args)
  File "/usr/lib/python3/dist-packages/sublime_music/app.py", line 1166, in 
do_play_song
self.player_manager.play_media(
  File "/usr/lib/python3/dist-packages/sublime_music/players/manager.py", line 
188, in play_media
current_player.play_media(uri, progress, song)
  File "/usr/lib/python3/dist-packages/sublime_music/players/mpv.py", line 137, 
in play_media
self.mpv.command(
  File "/usr/lib/python3/dist-packages/mpv.py", line 1233, in command
_mpv_command_node(self.handle, ppointer, out)
  File "/usr/lib/python3/dist-packages/mpv.py", line 148, in raise_for_ec
raise ex
ValueError: ('Invalid value for mpv parameter', -4, (, 
, ))

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1070251: tt-rss: LibXML error 4 at line 1 (column 1): Start tag expected, '<' not found

[Tiger!P]

Package: tt-rss
Version: 21~git20210204.b4cbc79+dfsg-1.2
Severity: important

Dear Maintainer,

At the moment I have a few RSS-feeds that have an error and more feeds are
getting the same error.

"LibXML error 4 at line 1 (column 1): Start tag expected, '<' not found"

This is shown at least for the following feeds:
https://gohugo.io/news/index.xml
http://www.blender.org/feed/
https://blog.gitea.io/index.xml

When I look at the feeds themselves, I do not see an issue with them, so I
would expect that tt-rss would be able to handle them.

It might have to do with a libxml2 package update I did recently.
2024-05-01 22:22:55 upgrade libxml2:amd64 2.9.14+dfsg-1.3+b2 2.9.14+dfsg-1.3+b3

I already restarted tt-rss, but this does not solve the issue.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-2-amd64 (SMP w/4 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 tt-rss depends on:
ii  dbconfig-common   2.0.24
ii  dbconfig-mysql2.0.24
ii  debconf [debconf-2.0] 1.5.86
ii  fonts-material-design-icons-iconfont  6.7.0+dfsg-1
ii  init-system-helpers   1.66
ii  libapache2-mod-php8.2 [php-json]  8.2.12-1+b1
ii  libjs-dojo-core   1.17.2+dfsg1-2.1
ii  libjs-dojo-dijit  1.17.2+dfsg1-2.1
ii  libjs-scriptaculous   1.9.0-3
ii  lsb-base  11.6
ii  php   2:8.2+93
ii  php-cli   2:8.2+93
ii  php-intl  2:8.2+93
ii  php-json  2:8.2+93
ii  php-mbstring  2:8.2+93
ii  php-mysql 2:8.2+93
ii  php-pgsql 2:8.2+93
ii  php-php-gettext   1.0.12-6
ii  php-psr-log   1.1.4-2
ii  php-xml   2:8.2+93
ii  php8.2 [php]  8.2.12-1
ii  php8.2-cli [php-json] 8.2.12-1+b1
ii  php8.2-fpm [php-json] 8.2.12-1+b1
ii  php8.2-intl [php-intl]8.2.12-1+b1
ii  php8.2-mbstring [php-mbstring]8.2.12-1+b1
ii  php8.2-pgsql [php-pgsql]  8.2.12-1+b1
ii  php8.2-phpdbg [php-json]  8.2.12-1+b1
ii  php8.2-xml [php-xml]  8.2.12-1+b1
ii  phpqrcode 1.1.4-3.1
ii  sysvinit-utils [lsb-base] 3.09-1

Versions of packages tt-rss recommends:
ii  apache2 [httpd] 2.4.58-1+b1
ii  ca-certificates 20240203
ii  nginx [httpd]   1.24.0-2+b1
ii  php-curl2:8.2+93
ii  php-gd  2:8.2+93
pn  php-mcrypt  
ii  php8.2-curl [php-curl]  8.2.12-1+b1
ii  php8.2-gd [php-gd]  8.2.12-1+b1

Versions of packages tt-rss suggests:
pn  php-apc   
pn  sphinxsearch  

-- Configuration Files:
/etc/tt-rss/config.php changed [not included]

-- debconf information:
  tt-rss/passwords-do-not-match:
* tt-rss/database-type: pgsql
  tt-rss/mysql/method: Unix socket
  tt-rss/pgsql/authmethod-admin: ident
  tt-rss/install-error: abort
  tt-rss/mysql/admin-user:
  tt-rss/dbconfig-reinstall: false
  tt-rss/pgsql/manualconf:
  tt-rss/internal/skip-preseed: false
  tt-rss/dbconfig-remove: true
* tt-rss/self_url_path: http://localhost/
  tt-rss/db/basepath:
  tt-rss/mysql/authplugin: default
  tt-rss/missing-db-package-error: abort
* tt-rss/dbconfig-install: true
  tt-rss/internal/reconfiguring: false
  tt-rss/remove-error: abort
* tt-rss/reconfigure-webserver:
  tt-rss/pgsql/changeconf: false
  tt-rss/dbconfig-upgrade: true
* tt-rss/remote/host: localhost
  tt-rss/pgsql/method: TCP/IP
  tt-rss/db/app-user: ttrss@localhost
  tt-rss/purge: false
  tt-rss/upgrade-backup: true
  tt-rss/db/dbname: ttrss
  tt-rss/upgrade-error: abort
  tt-rss/remote/port:
  tt-rss/pgsql/no-empty-passwords:
  tt-rss/pgsql/admin-user: postgres
  tt-rss/pgsql/authmethod-user: password
  tt-rss/remote/newhost: localhost

Bug#1070250: telepathy-glib: Fails to build with glib 2.80

[Jeremy Bícha]

Source: telepathy-glib
Severity: serious
Version: 0.24.2-0.3
Tags: ftbfs upstream
X-Debbugs-CC: bi...@debian.org

Please cherry-pick the glib commit from
https://gitlab.freedesktop.org/telepathy/telepathy-glib/-/commits/master
to fix the build with glib 2.80 (currently in experimental but will be
uploaded to Unstable as soon as the t64 transitions clear out).

There is also a commit there to port examples from Python 2 to 3.

Thank you,
Jeremy Bícha

Bug#1070227: Fails to start with undefined symbol

[Andres Salomon]

Thanks. This is a duplicate (https://bugs.debian.org/1070217), but I'm 
leaving it open to ensure that chromium doesn't accidentally migrate to 
trixie while built against a broken libsnappy. And as a reminder that 
we'll probably need a binNMU once snappy is fixed, unless upstream has a 
new release



On Thu, 2 May 2024 10:57:25 +0200 Yuri D'Elia  wrote:

Package: chromium
Version: 124.0.6367.78-1
Severity: grave

The current package in debian unstable fails to start with the following
missing symbol:

$ chromium
grep: warning: stray \ before -
/usr/lib/chromium/chromium: symbol lookup error: /usr/lib/chromium/chromium: 
undefined symbol: _ZN6snappy11RawCompressEPKcmPcPm


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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 chromium depends on:
ii  chromium-common124.0.6367.78-1
ii  libasound2t64  1.2.11-1+b1
ii  libatk-bridge2.0-0t64  2.52.0-1
ii  libatk1.0-0t64 2.52.0-1
ii  libatomic1 14-20240429-1
ii  libatspi2.0-0t64   2.52.0-1
ii  libc6  2.38-6
ii  libcairo2  1.18.0-3+b1
ii  libcups2t642.4.7-1.2+b1
ii  libdbus-1-31.14.10-4+b1
ii  libdouble-conversion3  3.3.0-1+b1
ii  libdrm22.4.120-2
ii  libevent-2.1-7t64  2.1.12-stable-8.1+b3
ii  libexpat1  2.6.2-1
ii  libflac12t64   1.4.3+ds-2.1
ii  libfontconfig1 2.15.0-1.1
ii  libfreetype6   2.13.2+dfsg-1+b4
ii  libgbm124.1.0~rc1-1
ii  libgcc-s1  14-20240429-1
ii  libglib2.0-0t642.78.4-7
ii  libgtk-3-0t64  3.24.41-4
ii  libjpeg62-turbo1:2.1.5-3
ii  libjsoncpp25   1.9.5-6+b2
ii  liblcms2-2 2.14-2+b1
ii  libminizip1t64 1:1.3.dfsg-3.1
ii  libnspr4   2:4.35-1.1+b1
ii  libnss32:3.99-1
ii  libopenh264-7  2.4.1+dfsg-1
ii  libopenjp2-7   2.5.0-2+b3
ii  libopus0   1.4-1+b1
ii  libpango-1.0-0 1.52.1+ds-1
ii  libpng16-16t64 1.6.43-5
ii  libpulse0  16.1+dfsg1-5


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070202: RM: rust-atk-sys/experimental -- ROM; RoM; unmaintained library

[Adam D. Barratt]

On Wed, 2024-05-01 at 21:15 +0200, Matthias Geiger wrote:
> I uploaded an experimental version some time ago that wasn't picked
> up by dak apperantly when it was removing it from unstable.

For reference, that's expected - the removal command operates on a
single suite, so removals from more than one suite need a bug for each.

Regards,

Adam

Bug#1070249: bookworm-pu: package python-jwcrypto/1.1.0-1+deb12u1

[Steve McIntyre]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: steve.mcint...@pexip.com, Timo Aaltonen 

Hi,

[ Reason ]
I've backported the upstream fix for CVE-2024-28102 (#1065688) to
bookworm. It's not considered critical as a security fix by the
security team, but would still be good to have in bookworm.

Ready to upload if you're happy.

Timo is happy for me to upload this - see the conversation in
#1065688.

[ Impact ]
Minor security issue.

[ Tests ]
The patch comes from upstream, and includes a unit test.

[ Risks ]
The changes are straightforward, cherry-picked from current upstream
and just massaged to fit the older version in bookworm.

[ 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 ]

The debdiff here just contains trivial metadata changes from my
initial debdiff in #1065688

python-jwcrypto (1.1.0-1+deb12u1) bookworm; urgency=medium

  * Apply and tweak upstream security fix for CVE-2024-28102
Address potential DoS with high compression ratio
diff -Nru python-jwcrypto-1.1.0/debian/changelog 
python-jwcrypto-1.1.0/debian/changelog
--- python-jwcrypto-1.1.0/debian/changelog  2022-03-29 08:33:50.0 
+0100
+++ python-jwcrypto-1.1.0/debian/changelog  2024-04-26 17:18:31.0 
+0100
@@ -1,3 +1,10 @@
+python-jwcrypto (1.1.0-1+deb12u1) bookworm; urgency=medium
+
+  * Apply and tweak upstream security fix for CVE-2024-28102
+Address potential DoS with high compression ratio
+
+ -- Steve McIntyre <93...@debian.org>  Fri, 26 Apr 2024 17:18:31 +0100
+
 python-jwcrypto (1.1.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch 
python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch
--- python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch   1970-01-01 
01:00:00.0 +0100
+++ python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch   2024-04-26 
17:18:31.0 +0100
@@ -0,0 +1,72 @@
+commit 90477a3b6e73da69740e00b8161f53fea19b831f
+Author: Simo Sorce 
+Date:   Tue Mar 5 16:57:17 2024 -0500
+
+Address potential DoS with high compression ratio
+
+Fixes CVE-2024-28102
+
+Signed-off-by: Simo Sorce 
+
+Index: os-python-jwcrypto/jwcrypto/jwe.py
+===
+--- os-python-jwcrypto.orig/jwcrypto/jwe.py
 os-python-jwcrypto/jwcrypto/jwe.py
+@@ -9,6 +9,9 @@ from jwcrypto.common import base64url_de
+ from jwcrypto.common import json_decode, json_encode
+ from jwcrypto.jwa import JWA
+ 
++# Limit the amount of data we are willing to decompress by default.
++default_max_compressed_size = 256 * 1024
++
+ 
+ # RFC 7516 - 4.1
+ # name: (description, supported?)
+@@ -387,6 +390,10 @@ class JWE:
+ 
+ compress = jh.get('zip', None)
+ if compress == 'DEF':
++if len(data) > default_max_compressed_size:
++raise InvalidJWEData(
++'Compressed data exceeds maximum allowed'
++'size' + f' ({default_max_compressed_size})')
+ self.plaintext = zlib.decompress(data, -zlib.MAX_WBITS)
+ elif compress is None:
+ self.plaintext = data
+Index: os-python-jwcrypto/jwcrypto/tests.py
+===
+--- os-python-jwcrypto.orig/jwcrypto/tests.py
 os-python-jwcrypto/jwcrypto/tests.py
+@@ -1716,6 +1716,32 @@ class ConformanceTests(unittest.TestCase
+ check.decrypt(key)
+ self.assertEqual(check.payload, b'plain')
+ 
++def test_jwe_decompression_max(self):
++key = jwk.JWK(kty='oct', k=base64url_encode(b'A' * (128 // 8)))
++payload = '{"u": "' + "u" * 4 + '", "uu":"' \
+++ "u" * 4 + '"}'
++protected_header = {
++"alg": "A128KW",
++"enc": "A128GCM",
++"typ": "JWE",
++"zip": "DEF",
++}
++enc = jwe.JWE(payload.encode('utf-8'),
++  recipient=key,
++  protected=protected_header).serialize(compact=True)
++with self.assertRaises(jwe.InvalidJWEData):
++check = jwe.JWE()
++check.deserialize(enc)
++check.decrypt(key)
++
++defmax = jwe.default_max_compressed_size
++jwe.default_max_compressed_size = 10
++# ensure we can eraise the limit and decrypt
++check = jwe.JWE()
++check.deserialize(enc)
++check.decrypt(key)
++jwe.default_max_compressed_size = defmax
++
+ 
+ class JWATests(unittest.TestCase):
+ def test_jwa_create(self):
diff -Nru python-jwcrypto-1.1.0/debian/patches/series 
python-jwcrypto-1.1.0/debian/patches/series
--- 

Bug#1070248: pingus: update its homepage (patch attached)

[Patrice Duroux]

Source: pingus
Version: 0.7.6-6
Severity: minor

Dear Maintainer,

Here is a patch for.

Thanks,
Patrice


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.12-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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
diff --git a/debian/control b/debian/control
index d0dcf5b..e0ce339 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,7 @@ Build-Depends:
 Standards-Version: 4.4.1
 Vcs-Browser: https://salsa.debian.org/games-team/pingus
 Vcs-Git: https://salsa.debian.org/games-team/pingus.git
-Homepage: https://pingus.gitlab.io/
+Homepage: https://pingus.github.io/
 Rules-Requires-Root: no
 
 Package: pingus

Bug#1070247: telepathy-glib: Fails to build with glib 2.80

[Jeremy Bícha]

Source: telepathy-glib
Severity: serious
Version: 0.24.2-0.3
Tags: ftbfs upstream
X-Debbugs-CC: bi...@debian.org

Please cherry-pick the glib commit from
https://gitlab.freedesktop.org/telepathy/telepathy-glib/-/commits/master
to fix the build with glib 2.80 (currently in experimental but will be
uploaded to Unstable as soon as the t64 transitions clear out). There
is also a commit there to port examples from Python 2 to 3.

Thank you,
Jeremy Bícha

Bug#1070246: libayatana-appindicator version of Debian package does not match the upstream version

[Carlos Alberto Lopez Perez]

Source: libayatana-appindicator
Severity: serious
Version: 0.5.92-1
Version: 0.5.93-1


The package of libayatana-appindicator on Debian is not building from the
right orig tarball as indicated on the package version.

Both package versions on Debian 12 and testing (versions 0.5.92-1 and 0.5.93-1)
are actually version 0.5.90 of upstream.

$ apt-cache policy libayatana-appindicator3-1
libayatana-appindicator3-1:
  Installed: 0.5.92-1
  Candidate: 0.5.92-1
  Version table:
 *** 0.5.92-1 500
500 http://deb.debian.org/debian bookworm/main amd64 Packages
100 /var/lib/dpkg/status

$ zcat /usr/share/doc/libayatana-appindicator3-1/changelog.gz|head
Overview of changes in libayatana-appindicator 0.5.90

  - Mono bindings: Change namespace from ayatana-appindicator-sharp3
to ayatana-appindicator3-sharp (and similar).
  - Port to CMake.
  - Default to GTK+-3.0 as default build flavour.
  - Add Travis CI configuration.
  - Add --keep-env option to dbus-test-runner calls. Allows propagating
e.g. a build HOME into the DBus test environment.


See how on the upstream changelog file it says version "0.5.90"

I have triple checked this by comparing the orig.tar.gz tarball from the Debian
packages VS the ones at 
https://github.com/AyatanaIndicators/libayatana-appindicator/tags

And the version shipped on Debian (both for 0.5.92-1 and 0.5.93-1) is actually 
the upstream 0.5.90 version

Please fix this

Thanks

Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using

[Fabian Grünbichler]

On Sat, Apr 27, 2024 at 05:40:49PM +0800, Maytham Alsudany wrote:
> Hi everyone,
> 
> Thanks for your input and suggestions. I've attached an updated patch with
> several changes, including improving making the description of the field more
> specific, adding another example that is not Go/Rust related, and improving 
> the
> Rust example to show the simultaneous use of Static-Built-Using and 
> Built-Using.
> 
> I would greatly appreciate any more feedback for this new patch. If you 
> believe
> that it is complete (and you are a DD), it would be very helpful if you could
> second this consensus and proposal.
> 
> The relevant part of the new patch has been included at the bottom of this
> email.
> 

[..]

> 
> Below is the relevant part of the updated patch, to save you from downloading
> the attachment:
> 
> ``Static-Built-Using``
> ~~
> 
> This ``Static-Built-Using`` field must list source packages who's
> contents (like source code or data) were incorporated into the binary
> package during the build, including an "exactly equal" ("=") version
> relation on the version that was used to build that version of the
> incorporating binary package.
> 
> Cases where this field may be used include (but are not limited to)
> linking against static libraries in other packages, builds for
> source-centered languages such as Go and Rust, usage of header-only
> C/C++ libraries and injecting data blobs into code.
> 
> This is useful to track whether the package might need to be rebuilt
> when source packages listed here have been updated. This is important
> to stay ahead of the package failing to build from source (FTBFS) with
> the updated versions of the listed source packages, or security
> updates in the listed source packages.
> 
> Unlike Built-Using, the Debian archive will **not** retain the
> versions of the source packages listed in the Static-Built-Using
> field. This means that any package listed in Static-Built-Using who's
> license requires its source code to be available must also
> simultaneously be listed in the Built-Using field.
> 
> A package that needs domain name suffix data from the publicsuffix
> binary package would list it in the ``Static-Built-Using`` field like
> so:
> 
> ::
> 
> Static-Built-Using: publicsuffix (= 20231001.0357-0.1)
> 
> A package statically linked with a library from the
> golang-github-mattn-go-xmpp-dev binary package would have this field
> in its control file:
> 
> ::
> 
> Static-Built-Using: golang-github-mattn-go-xmpp (= 0.2.0-1)
> 
> A package statically linked with the libraries contained in the
> librust-gtk4-dev and librust-pulsectl-rs-dev binary packages, where
> the latter is licensed under GPL-3+ (a license that requires full
> source code to be available), would have these fields in its control
> file:
> 
> ::
> 
> Built-Using: rust-pulsectl-rs (= 0.3.2-1+b1)
> Static-Built-Using: rust-gtk4 (= 0.7.3-3), rust-pulsectl-rs (= 0.3.2-1+b1)
> 

LGTM, consider this Seconded :) (even though it is not currently tagged as
"Wording Proposed ;))

Fabian


signature.asc
Description: PGP signature

Bug#1070245: dicomnifti 2.33.1-5: ROM; Obsolete

[Valerio Luccio]

Package: dicomnifti
Version: 2.33.1-5

Software not compatible with most recent DICOM image version and will 
not be updated.


--
Valerio Luccio  
High Performance Computing  10 Astor Place, 4th Floor
New York University New York, NY 10003

   "In an open world, who needs windows or gates ?"

Bug#1068951: new upstream (6.x)

[Jakub Ružička]

Yo Santiago (CC'd), could you please drop your opinion on this for extra 
reference?


On 4/30/24 18:34, Daniel Baumann wrote:

Hi,

On 4/30/24 18:12, Jakub Ružička wrote:
Secondary reason for that was that there is no upgrade path from 5.x 
to 6.x so it's unwanted for knot-resolver 5 packages to auto-update 
to 6.


For that, the package probably needs a different name (like 
knot-resolver6)


imho this should be handled in the package (e.g. by showing a debconf 
note or so) and be included in the trixie release notes. renaming the 
binary package doesn't really solve much and is more suited for 
(library) transitions, i.e. if there were several 
knot-resolver-module-* packages or so.
We currently have v5 and v6 packages in a single knot-resolver repo on 
pkg.labs.nic.cz and v5 users are safe to `apt update` from the repo 
without breaking their setup or they can `apt install knot-resolver6` to 
upgrade. This would apply to Bookworm -> Trixie transition as well.


If there was no distinction between v5 and v6 packages, unwanted updates 
leading into broken setups are bound to happen, that's not very user 
friendly. I could split the upstream repos (knot-resolver5, 
knot-resolver6), but that won't solve Bookworm -> Trixie case.


OTOH knot-resolver6 fork is extra maintenance (new source package & 
Salsa repo...) and an unwanted irregularity although it gets the job 
done. This was the case for bird2 and upcoming bird3 for example, which 
also isn't a library.


also (I haven't looked at it), is it worthwile to (with users consent) 
to "try" to guess with (some parts of) the old config to generate the 
new config from?

I don't think that's worthwhile, that's why it's not officially supported.




So what do you suggest?


generally, the amount of binary packages should be limited to a 
minimum - oiow there needs to be a reason why an additional binary 
package is added. some of them are:


  * saving relative excessive amount of diskspace (e.g. large
    documentation can be split into a -doc package)

  * different parts have different dependencies and/or particulary
    long dependency chains (e.g. gtk parts of a cli tool)

therefore, imho the following binary packages make sense here:

  * knot-resolver
  * knot-resolver-doc
  * knot-resolver-module-dnstap
  * knot-resolver-module-http
Consulting with upstream, there doesn't seem to be a strong reason not 
to merge like that. Separating the python module(s) in a sub-package 
could be useful in some (official unsupported edge) cases like 
containers where pulling the extra python deps might increase the image 
size significantly.


I believe vast majority of users will use the manager so it's desirable 
to install it by default, which would be 100 % ensured by having it a 
part of knot-resolver package, so that's a plus.


Those who want to use kresd without manager can simply disable manager 
and do what they want at the cost of some unused python deps. I don't 
think that's too bad of a compromise.


So I'm generally in favor of merging the -manager package, I'm just 
worried about unwanted upgrades if we don't change the name 
(knot-resolver6) as there isn't really an upgrade path. Such is the 
price of progress.


Note that Fedora policies/customs are strongly in favor of not forking 
per-version - in line of what you suggest.




Note that -dbg packages are generated automatically and don't need to 
be specified in control (I'll provide a commit for that).

Oh, right :)


Cheers,
Jakub

Bug#1070244: ITP: snap7 -- Siemens S7 PLCs communications library

[Gijs Molenaar]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: gijsmolen...@gmail.com

Subject: ITP: snap7 -- Siemens S7 PLCs communications library
Package: wnpp
Owner: Gijs Molenaar 
Severity: wishlist

* Package name : snap7
Version : 1.4.1
Upstream Author : Davide Nardella 
* URL : http://snap7.sourceforge.net/
* License : LGPL-3.0+
Programming Lang: C
Description : Siemens S7 PLCs communications library -- dev files
The new CPUs 1200/1500 and SINAMICS Drives are also partially supported.
Although it has been designed to overcome the limitations of OPC servers
when
transferring large amounts of high speed data in industrial facilities, it
scales well down to small Linux based arm boards such as Raspberry PI,
BeagleBone Black, pcDuino and CubieBoard.
.
Three specialized components, Client, Server and Partner, allow you to
definitively integrate your PC based systems into a PLC automation chain.\
.
Main features:
* Native multi-architecture design (32/64 bit).
* Platform independent, currently are supported Windows (from NT 4.0 up
to Windows 8), Linux, BSD, Oracle Solaris 11.
* Fully scalable, starting from blade servers down to Raspberry PI board.
* No dependence on any third-party libraries, no installation needed, zero
configuration.
* Three Different native thread models for performance optimization: Win32
threads/ Posix threads / Solaris 11 threads.
* Two data transfer models: classic synchronous and asynchronous.
* Two data flow models: polling and unsolicited (PLC transfers data when it
wants to).
.
This package contains the development files.

Remark: This package is maintained by Gijs Molenaar with sponsorship by
Michael Crusoe at
https://salsa.debian.org/debian/snap7

Bug#1069681: less does not escape special characters when outputting the filename

[Milan Kupcevic]

Hi Salvatore,

On 5/2/24 10:45, Salvatore Bonaccorso wrote:
[...]


I did ponder about it and trying to add this fix as well for the
upcoming less DSA, but it won't go apply for the older releases and
the issue is compared minor enough.

I think I will go ahead with the two CVE fixes only.

Take a look at the attached patch. It applies and fixes the bookworm and 
bullseye versions. It seems the buster version is not vulnerable to this 
particular issue.



MilanDate:   Tue Apr 23 10:54:50 2024 -0700
Author: Mark Nudelman 
Author: Milan Kupcevic 
Origin: upstream, https://github.com/gwsw/less/commit/2a642a07d86f7f9484db18cd748bc521e71c997f
Bug-Debian: https://bugs.debian.org/1069681
Applied-Upstream: 654
Subject: Fix incorrect display when filename contains control chars.

---
 output.c | 12 ++--
 prompt.c | 17 -
 2 files changed, 22 insertions(+), 7 deletions(-)

--- a/output.c
+++ b/output.c
@@ -31,6 +31,7 @@
 extern int screen_trashed;
 extern int is_tty;
 extern int oldbot;
+extern int utf_mode;
 
 #if MSDOS_COMPILER==WIN32C || MSDOS_COMPILER==BORLANDC || MSDOS_COMPILER==DJGPPC
 extern int ctldisp;
@@ -562,6 +563,7 @@
 	PARG *parg;
 {
 	char *s;
+	char *es;
 	int col;
 
 	col = 0;
@@ -578,11 +580,17 @@
 			{
 			case 's':
 s = parg->p_string;
+es = s + strlen(s);
 parg++;
 while (*s != '\0')
 {
-	putchr(*s++);
-	col++;
+	LWCHAR ch = step_char(, +1, es);
+	constant char *ps = utf_mode ? prutfchar(ch) : prchar(ch);
+	while (*ps != '\0')
+	{
+		putchr(*ps++);
+		col++;
+	}
 }
 break;
 			case 'd':
--- a/prompt.c
+++ b/prompt.c
@@ -29,6 +29,7 @@
 extern int sc_height;
 extern int jump_sline;
 extern int less_is_more;
+extern int utf_mode;
 extern IFILE curr_ifile;
 #if EDITOR
 extern char *editor;
@@ -83,13 +84,17 @@
 ap_str(s)
 	char *s;
 {
-	int len;
-
-	len = (int) strlen(s);
-	if (mp + len >= message + PROMPT_SIZE)
-		len = (int) (message + PROMPT_SIZE - mp - 1);
-	strncpy(mp, s, len);
-	mp += len;
+	char *es = s + strlen(s);
+	while (*s != '\0')
+	{
+	LWCHAR ch = step_char(, +1, es);
+	constant char *ps = utf_mode ? prutfchar(ch) : prchar(ch);
+	size_t plen = strlen(ps);
+	if (mp + plen >= message + PROMPT_SIZE)
+	break;
+	strcpy(mp, ps);
+	mp += plen;
+	}
 	*mp = '\0';
 }
 

Bug#1070243: dicomnifti 2.33.1-5: ROM; Obsolete

[Valerio Luccio]

Package: dicomnifti 2.33.1-5

Software not compatible with most recent DICOM image version and will 
not be updated.


--
Valerio Luccio  
High Performance Computing  10 Astor Place, 4th Floor
New York University New York, NY 10003

   "In an open world, who needs windows or gates ?"

Bug#1070242: tracker.debian.org: Removal information not useful

[Helge Kreutzmann]

Package: tracker.debian.org
Severity: normal

how-can-i-help informs me regularly about packages needing help. Often
(which is not part of this bug report) this information is outdated,
i.e. the package to be removed is no longer removed.

Today, I got informed that several games are removed from Testing, e.g.
pingus. So I followed the link and went to
https://tracker.debian.org/pkg/pingus

Ok, there I get the information:
 The package has not entered testing even though the 5-day delay is over. Check 
why.

Which links me to
https://qa.debian.org/excuses.php?package=pingus

However, this page does *not* give any reason:
Migration status for pingus (- to 0.7.6-6): BLOCKED: Rejected/violates 
migration policy/introduces a regression

Here nothing tells me what policy entry is violated or which
regeression is about to occur.

Then
Issues preventing migration:

Nothing here, execpt that piuparts tested ok, which I don't think is a
problem.

The last line is
Remove hint for (transitive) dependency: sdl-mixer1.2

Now I go (manually) to 
https://tracker.debian.org/pkg/sdl-mixer1.2

Here I see that a removal is scheduled (but has not happened!), again
"Check why" / https://qa.debian.org/excuses.php?package=sdl-mixer1.2 
only tells me that a removal is about to happen (Removal request
by auto-removals), but not why. It even tells me that the most recent
upload is closing a bug.

This is very frustrating.

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#852429: devscripts: [uscan] support 7z in uscan repack stuff

[Michael R. Crusoe]

On Sat, 28 Jan 2017 12:14:14 +0900 Osamu Aoki  wrote:
> Hi,
>
> On Tue, Jan 24, 2017 at 12:19:16PM +0100, Félix Sipma wrote:
> > Package: devscripts
> > Version: 2.17.0
> > Severity: wishlist
> >
> > It would be nice to have .7z support in uscan repack stuff.
>
> 7zip archiver is in main so this is a possible feature but before adding
> any feature, we need to verify its raison d'être.
>
> Please cite 3 typical actual upstram archive site cases where this is
> the only option to get their upstream source.

https://sourceforge.net/projects/snap7/files/1.4.2/

> From 1.4.2 only 7z will be released




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386

[Jussi Pakkanen]

On Thu, 2 May 2024 at 01:48, Shmerl  wrote:

> > Ubuntu fixed it with this patch:
> > https://launchpadlibrarian.net/715235929/meson_1.3.2-1_1.3.2-1ubuntu1.diff.gz
> >
>
> Can this fix be added to Debian? Meson has been stuck without
> moving to testing for a very long time and now it seems to be
> stalling Mesa in result too.

I looked into this and the answer is sadly no. That patch explicitly
adds -lc to every link which breaks other tests that depend on it not
being there. These tests have been added after Ubuntu made that
change, so they won't show up there. They will once they update Meson
to a newer version.

Along the way I found other bugs, such as bindgen not working at all
out of the box. I filed
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070241 for that.

All in all this is getting into very deep Debian toolchain magic, of
which I have little knowledge. :(

Bug#1015201: logcheck: Update patterns, here: rsyslogd

[Helge Kreutzmann]

Hello Michael,
Am Thu, May 02, 2024 at 12:28:30PM +0200 schrieb Michael Biebl:
> Am 02.05.24 um 09:39 schrieb Richard Lewis:
> > lOn Mon, 29 Apr 2024, 14:19 Helge Kreutzmann,  > > wrote:
> > i think that practice and theory have diverged here! or possibly this
> > is/was produced when logs are rotated.
> 
> The latest autopkgtest test for logcheck passed successfully [1], so I'm
> inclined to close this bug report.

I haven't yet switched over to testing, so maybe the report is
outdated.

> If the log check rules do need an update, they should be accompanied with a
> corresponding autopkgtest.

I can provide patterns, when necessary.

> As I don't use logcheck, I will have to rely on someone to contribute those
> changes. Ideally in the form of a MR on salsa at
> https://salsa.debian.org/debian/rsyslog

I'm happy to send patterns in bug reports, when applicable, using
reportbug(1). I use logcheck a lot, and tweak the rulse regularly. But
I'm not fluent at all in autopkgtest or creating merge requests.

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1070241: Bindgen missing dependency on Clang

[Jussi Pakkanen]

Package: bindgen
Version: 0.66.1-4

If you do `apt install bindgen` and try to use it, it will fail with
an error message like this:

/usr/include/zconf.h: 254 fatal error 'stddef.h' not found

Running `apt install clang` makes it work. As bindgen can't be run
without it, the bindgen package should have a dependency on clang (or
whatever other package actually provides the necessary functionality).

Thanks,

Bug#1070240: r-cran-tmb: Please rebuild under updated Matrix package

[Dirk Eddelbuettel]

Package: r-cran-tmb
Version: 1.9.11-1
Severity: important

CRAN package Matrix had a new release 1.7.0 bringing in a new
SuiteSparse API which requires a rebuild if (and only if) the
Matrix headers are used. Your package is one of those that do,
and therefore needs a rebuild.

This was reasonably well circulated earlier (by upstream in [1],
and I followed up on debian-devel) but it was then decided to tie 
this 1.7-0 release to the R 4.4.0 release last week.

To recap we can look at the total dependencies of Matrix at CRAN (1300+)
and the ones using the headers via LinkingTo (15) in R via 

  > db <- tools::CRAN_package_db()
  > matrixrevdep <- tools::package_dependencies("Matrix", reverse=TRUE, 
db=db)[[1]]
  > length(matrixrevdep)# the vector 'matrixrevdep' list all
  [1] 1349
  > tools::package_dependencies("Matrix", which = "LinkingTo", reverse = 
TRUE)[[1L]]
   [1] "ahMLE"   "bayesWatch"  "cplm"
"GeneralizedWendland"
   [5] "geostatsp"   "hibayes" "irlba"   "lme4" 
  
   [9] "mcmcsae" "OpenMx"  "PRIMME"  
"PUlasso"
  [13] "robustlmm"   "spGARCH" "TMB"
  > 

But among these 15 affected only five are in Debian:
 
   irlbar-cran-irlba
   lme4 r-cran-lme4
   OpenMx   r-cran-openmx
   TMB  r-cran-tmb
   bcSeqr-bioc-bcseq

and lme4 is my package, and I already rebuilt it.

You should see a message about 'Matrix API 1, needs 2' in case of
a mismatch, if you rebuild then the `library(...)` call in R will 
be quiet as usual.

All it takes is a rebuild: for r-cran-lme4 I just adjusted (Build-)
Depends for r-cran-matrix to r-cran-matrix (>= 1.7-0) (and I also 
adjusted r-base-dev to depend on 4.4.0 or greater, but that is both
optional, and implied via Matrix).

It would be terrific if you could update the package in the next
few days. If you are unable I could do a binary-only NMU -- just
let me know.

Many thanks,  Dirk

[1] https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010463.html

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1070239: r-cran-openmx: Please rebuild under updated Matrix package

[Dirk Eddelbuettel]

Package: r-cran-openmx
Version: 2.21.11+dfsg-3
Severity: important

CRAN package Matrix had a new release 1.7.0 bringing in a new
SuiteSparse API which requires a rebuild if (and only if) the
Matrix headers are used. Your package is one of those that do,
and therefore needs a rebuild.

This was reasonably well circulated earlier (by upstream in [1],
and I followed up on debian-devel) but it was then decided to tie 
this 1.7-0 release to the R 4.4.0 release last week.

To recap we can look at the total dependencies of Matrix at CRAN (1300+)
and the ones using the headers via LinkingTo (15) in R via 

  > db <- tools::CRAN_package_db()
  > matrixrevdep <- tools::package_dependencies("Matrix", reverse=TRUE, 
db=db)[[1]]
  > length(matrixrevdep)# the vector 'matrixrevdep' list all
  [1] 1349
  > tools::package_dependencies("Matrix", which = "LinkingTo", reverse = 
TRUE)[[1L]]
   [1] "ahMLE"   "bayesWatch"  "cplm"
"GeneralizedWendland"
   [5] "geostatsp"   "hibayes" "irlba"   "lme4" 
  
   [9] "mcmcsae" "OpenMx"  "PRIMME"  
"PUlasso"
  [13] "robustlmm"   "spGARCH" "TMB"
  > 

But among these 15 affected only five are in Debian:
 
   irlbar-cran-irlba
   lme4 r-cran-lme4
   OpenMx   r-cran-openmx
   TMP  r-cran-tmp
   bcSeqr-bioc-bcseq

and lme4 is my package, and I already rebuilt it.

You should see a message about 'Matrix API 1, needs 2' in case of
a mismatch, if you rebuild then the `library(...)` call in R will 
be quiet as usual.

All it takes is a rebuild: for r-cran-lme4 I just adjusted (Build-)
Depends for r-cran-matrix to r-cran-matrix (>= 1.7-0) (and I also 
adjusted r-base-dev to depend on 4.4.0 or greater, but that is both
optional, and implied via Matrix).

It would be terrific if you could update the package in the next
few days. If you are unable I could do a binary-only NMU -- just
let me know.

Many thanks,  Dirk

[1] https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010463.html

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1055711: Bug#1057469: gcc-13: Please build gcc with -mbranch-protection=standard to fix PAC/BTI support on arm64

[Emanuele Rocca]

On 2023-12-31 10:32, Matthias Klose wrote:
> please also check
> 
>  - that a cross compiler with this patch has these enabled
> 
>  - that a cross build of gcc-13 targeting arm64 with this
>patch has these enabled

There have been a few gcc-12 and gcc-13 updates since I initially sent my patch
so I now verified that it still works as expected.

The BTI patch looks like this, both for gcc-12 and -13:

diff -Nru gcc-12-12.3.0/debian/rules2 gcc-12-12.3.0/debian/rules2
--- gcc-12-12.3.0/debian/rules2 2023-12-03 18:45:19.0 +0100
+++ gcc-12-12.3.0/debian/rules2 2024-05-02 14:25:19.0 +0200
@@ -195,6 +195,22 @@
   STAGE1_LDFLAGS   =
 endif
 
+ifeq ($(DEB_TARGET_ARCH),arm64)
+  ifeq ($(DEB_CROSS),yes)
+# Building cross compilers
+CFLAGS_FOR_TARGET += -mbranch-protection=standard
+CXXFLAGS_FOR_TARGET += -mbranch-protection=standard
+  else ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
+# Cross build of the native compiler
+CFLAGS_FOR_TARGET += -mbranch-protection=standard
+CXXFLAGS_FOR_TARGET += -mbranch-protection=standard
+  else
+# Native build
+CFLAGS += -mbranch-protection=standard
+CXXFLAGS += -mbranch-protection=standard
+  endif
+endif
+
 # set CFLAGS/LDFLAGS for the configure step only, maybe be modifed for some 
target
 # all other flags are passed to the make step.
 pass_vars = $(foreach v,$(1),$(if $($(v)),$(v)="$($(v))"))


These are the checks I performed:

(1) Native aarch64 compiler built on aarch64

On aarch64, I applied the BTI patch to gcc-12's debian/rules2 and built the
package with sbuild. Then I checked that crtbeginS.o and crtendS.o from
libgcc-12-dev had BTI on.

  dpkg --extract libgcc-12-dev_12.3.0-18_arm64.deb /tmp/libgcc-12-dev
  readelf -n 
/tmp/libgcc-12-dev/usr/lib/gcc/aarch64-linux-gnu/12/crt{begin,end}S.o | grep BTI

Same procedure and outcome when it comes to gcc-13.

(2) Cross compiler (aarch64) built on x86_64

On x86_64, I did the following in a clean sid chroot:

 apt build-dep gcc-12-cross
 Apply the BTI patch to /usr/src/gcc-12/debian/rules2
 
Then, inside the source directory of gcc-12-cross:

 export CROSS_ARCHS="amd64 arm64"
 debian/rules control
 dpkg-buildpackage

At the end of the build process, I checked that crtbeginS.o and crtendS.o as
shipped by libgcc-12-dev-arm64-cross had BTI on.

 dpkg --extract libgcc-12-dev-arm64-cross_12.3.0-17_all.deb /tmp/libgcc-cross
 readelf -n 
/tmp/libgcc-cross/usr/lib/gcc-cross/aarch64-linux-gnu/12/crt{begin,end}S.o | 
grep BTI

Same procedure and outcome when it comes to gcc-13.

(3) Cross build of the native compiler

There are various issues that make cross builds of the native compiler fail.
They are unrelated to the patch proposed here, but I'm mentioning them because
I had to work around them in order to test if a cross build of the native
compiler would carry the BTI property as expected.

The first problem is due to the m2 language, which fails to cross build. I
believe this to be a long standing, known issue (at least Helmut mentioned
being aware of it in the past). Languages can be disabled by passing the
'nolang' build option to DEB_BUILD_OPTIONS, so that's what I have done.

The second issue affects gcc-12 only. Cross building gcc-12 for arm64 on a
amd64 machine fails with an undefined reference error (fprintf_unlocked). Full
logs at https://people.debian.org/~ema/gcc-12_12.3.0-17_arm64.build. Because of
this second problem, I tested a cross-build of the native gcc-13 only, not of
gcc-12.

The third issue affects gcc-13: nvptx does not cross build properly (see
#1060075) but it is enabled in gcc-13 for arm64. To work around this problem
when it comes to gcc-13 I have removed arm64 from the list of nvptx_archs in
debian/rules.defs.

Then, I cross built with m2 disabled:

 DEB_BUILD_OPTIONS='nolang=m2' sbuild --host=arm64

At the end of the build process, I verified that crtbeginS.o and crtendS.o from
libgcc-13-dev had BTI on.

  dpkg --extract libgcc-13-dev_13.2.0-24.1_arm64.deb /tmp/xxx
  readelf -n /tmp/xxx/usr/lib/gcc/aarch64-linux-gnu/13/crt{begin,end}S.o | grep 
BTI

Bug#1070238: r-cran-irlba: Please rebuild under updated Matrix package

[Dirk Eddelbuettel]

Package: r-cran-irlba
Version: 2.3.5.1-3
Severity: important

CRAN package Matrix had a new release 1.7.0 bringing in a new
SuiteSparse API which requires a rebuild if (and only if) the
Matrix headers are used. Your package is one of those that do,
and therefore needs a rebuild.

This was reasonably well circulated earlier (by upstream in [1],
and I followed up on debian-devel) but it was then decided to tie 
this 1.7-0 release to the R 4.4.0 release last week.

To recap we can look at the total dependencies of Matrix at CRAN (1300+)
and the ones using the headers via LinkingTo (15) in R via 

  > db <- tools::CRAN_package_db()
  > matrixrevdep <- tools::package_dependencies("Matrix", reverse=TRUE, 
db=db)[[1]]
  > length(matrixrevdep)# the vector 'matrixrevdep' list all
  [1] 1349
  > tools::package_dependencies("Matrix", which = "LinkingTo", reverse = 
TRUE)[[1L]]
   [1] "ahMLE"   "bayesWatch"  "cplm"
"GeneralizedWendland"
   [5] "geostatsp"   "hibayes" "irlba"   "lme4" 
  
   [9] "mcmcsae" "OpenMx"  "PRIMME"  
"PUlasso"
  [13] "robustlmm"   "spGARCH" "TMB"
  > 

But among these 15 affected only five are in Debian:
 
   irlbar-cran-irlba
   lme4 r-cran-lme4
   OpenMx   r-cran-openmx
   TMP  r-cran-tmp
   bcSeqr-bioc-bcseq

and lme4 is my package, and I already rebuilt it.

You should see a message about 'Matrix API 1, needs 2' in case of
a mismatch, if you rebuild then the `library(...)` call in R will 
be quiet as usual.

All it takes is a rebuild: for r-cran-lme4 I just adjusted (Build-)
Depends for r-cran-matrix to r-cran-matrix (>= 1.7-0) (and I also 
adjusted r-base-dev to depend on 4.4.0 or greater, but that is both
optional, and implied via Matrix).

It would be terrific if you could update the package in the next
few days. If you are unable I could do a binary-only NMU -- just
let me know.

Many thanks,  Dirk

[1] https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010463.html

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1069349: live-build: Regression in d14306a7 leading to build failures

[Daniel Reichelt]

On 02.05.24 17:30, Roland Clobus wrote:

I'll prepare a proper fix that detects whether the directory is present.


Perfect, thanks!

Bug#1069349: live-build: Regression in d14306a7 leading to build failures

[Roland Clobus]

On 02/05/2024 12:14, Daniel Reichelt wrote:

Hi Roland,
 > On 20/04/2024 13:32, Daniel Reichelt wrote:
 > What are you doing that makes the directory 'config/includes.binary'
 > disappear?
 > If I use 'lb config --distribution sid', the directory is created (but
 > empty) and there will be no error message.

I'm keeping my (final, i.e. `lb config`ured) config-trees in git which 
has been

working for over a decade so far.


Ah, that's a known feature of git: it does not store empty directories 
(therefore often a hidden file .gitkeep or .gitignore is used [1])



 > the directory is created (but empty) and there will be no error
 > message.

It is not a good practise to depend on the existence of empty
directories, IMHO.

Your commit message says nothing abaout the patch in
scripts/build/binary_includes. Why did you move those lines in the first
place?


I placed a hidden directory in it (.disk), and that could not be found 
by 'Find_files', so I shifted things around. All my test scenarios are a 
combination of 'lb config' and 'lb build', so I couldn't see an issue 
with the missing directory in my local tests.


I'll prepare a proper fix that detects whether the directory is present.

With kind regards,
Roland

[1] 
https://stackoverflow.com/questions/7229885/what-are-the-differences-between-gitignore-and-gitkeep


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070237: wsclean: error while loading shared libraries: libradler.so: cannot open shared object file

[André Offringa]

Package: wsclean
Version: 3.4-1+b2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: offri...@gmail.com

Dear Maintainer,

There is something wrong with the packaging of WSClean; running WSClean fails
with the following error:

wsclean: error while loading shared libraries: libradler.so: cannot open shared
object file: No such file or directory

Radler is a component of wsclean that is normally compiled along wsclean,
linked into a static library and subsequently linked into the wsclean binary. I
think that Debian's WSClean package builds radler as a shared object, but does
not ship the library.

Thanks,
André


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_NL.UTF-8, LC_CTYPE=en_NL.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wsclean depends on:
ii  libboost-filesystem1.83.0   1.83.0-2+b2
ii  libc6   2.37-18
ii  libcasa-casa7   3.5.0-2+b3
ii  libcasa-fits7   3.5.0-2+b3
ii  libcasa-measures7   3.5.0-2+b3
ii  libcasa-ms7 3.5.0-2+b3
ii  libcasa-tables7 3.5.0-2+b3
ii  libcfitsio10t64 [libcfitsio10]  4.3.1-1.1+b1
ii  libfftw3-double33.3.10-1+b1
ii  libfftw3-single33.3.10-1+b1
ii  libgcc-s1   14-20240330-1
ii  libgsl272.7.1+dfsg-6+b1
ii  libhdf5-103-1   1.10.10+repack-3+b1
ii  libhdf5-cpp-103-1   1.10.10+repack-3+b1
ii  libstdc++6  14-20240330-1

wsclean recommends no packages.

Versions of packages wsclean suggests:
pn  wsclean-dev  

-- no debconf information

Bug#1070236: [Pkg-samba-maint] Bug#1070236: python3-samba: SyntaxError during configuration phase of package on upgrade

[Michael Tokarev]

02.05.2024 18:11, Dennis Boone wrote:

Package: python3-samba
Version: 2:4.19.6+dfsg-2
Severity: normal
X-Debbugs-Cc: d...@msu.edu

Dear Maintainer,

During an `apt-get upgrade` this morning, the configuration phase of
python3-samba emitted this error due to a missing colon:

==
Configurando python3-samba (2:4.19.6+dfsg-2) ...
   File "/usr/lib/python3/dist-packages/samba/ms_forest_updates_markdown.py", 
line 27
 try
^


https://salsa.debian.org/samba-team/samba/-/commit/d1e04012eec6fcc111584590f8416991eddab0e3
 FWIW.

/mjt

Bug#1070236: python3-samba: SyntaxError during configuration phase of package on upgrade

[Dennis Boone]

Package: python3-samba
Version: 2:4.19.6+dfsg-2
Severity: normal
X-Debbugs-Cc: d...@msu.edu

Dear Maintainer,

During an `apt-get upgrade` this morning, the configuration phase of
python3-samba emitted this error due to a missing colon:

==
Configurando python3-samba (2:4.19.6+dfsg-2) ...
  File "/usr/lib/python3/dist-packages/samba/ms_forest_updates_markdown.py", 
line 27
try
   ^
SyntaxError: expected ':'
  File "/usr/lib/python3/dist-packages/samba/ms_forest_updates_markdown.py", 
line 27
try
   ^
SyntaxError: expected ':'
dpkg: error al procesar el paquete python3-samba (--configure):
 el subproceso instalado paquete python3-samba script post-installation 
devolvió el código de salida de error 1
dpkg: problemas de dependencias impiden la configuración de samba-common-bin:
 samba-common-bin depende de python3-samba; sin embargo:
 El paquete `python3-samba' no está configurado todavía.

dpkg: error al procesar el paquete samba-common-bin (--configure):
 problemas de dependencias - se deja sin configurar
==

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 6.7.9-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-samba depends on:
ii  libbsd0   0.12.2-1
ii  libc6 2.37-19
ii  libgnutls30t643.8.5-2
ii  libldb2   2:2.8.0+samba4.19.6+dfsg-2
ii  libpython3.11t64  3.11.9-1
ii  libtalloc22.4.2-1+b1
ii  libtevent0t64 0.16.1-2
ii  python3   3.11.8-1
ii  python3-ldb   2:2.8.0+samba4.19.6+dfsg-2
ii  python3-talloc2.4.2-1+b1
ii  python3-tdb   1.4.10-1
ii  samba-libs [libndr3]  2:4.19.6+dfsg-2

Versions of packages python3-samba recommends:
ii  python3-gpg  1.18.0-4.1+b1

python3-samba suggests no packages.

-- no debconf information

Bug#1068082: bullseye-pu: package intel-microcode/3.20240312.1~deb11u1

[Henrique de Moraes Holschuh]

On Mon, Apr 22, 2024, at 13:58, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
>
> On Sat, Mar 30, 2024 at 07:50:45AM -0300, Henrique de Moraes Holschuh wrote:
>> As requested by the security team, I would like to bring the microcode
>> update level for Intel processors in Bullseye and Bookworm to match what
>> we have in Sid and Trixie.  This is the bug report for Bullseye, a
>> separate one will be filled for Bookmorm.
>
> Please go ahead.

Uploaded!

Thank you!

-- 
  Henrique de Moraes Holschuh 

Bug#1070217: chromium: Symbol lookup error with libsnappy1v5>=1.2.0

[Martin Steigerwald]

Work-around for affected users:

Download and install

libsnappy1v5_1.1.10-1+b1_amd64.deb

from

https://snapshot.debian.org/archive/debian/20240210T223313Z/pool/main/s/snappy/


Temporary protection:

% cat /etc/apt/preferences.d/libsnappy 
Explanation: Debian#1070217: chromium: Symbol lookup error with 
libsnappy1v5>=1.2.0
Explanation: https://bugs.debian.org/1070217
Package: libsnappy1v5
Pin: version *
Pin-Priority: -3

Please remove once bug is fixed.

Thanks,
-- 
Martin

Bug#1069681: less does not escape special characters when outputting the filename

[Salvatore Bonaccorso]

Hi Milan,

On Tue, Apr 23, 2024 at 09:08:55AM +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Mon, Apr 22, 2024 at 12:25:45PM -0400, Milan Kupcevic wrote:
> > forwarded 1069681 https://github.com/gwsw/less/issues/503
> > thanks
> 
> Thanks. For now I will hold-back the prepared security update to see
> if there is something else which needs to be done here.

I did ponder about it and trying to add this fix as well for the
upcoming less DSA, but it won't go apply for the older releases and
the issue is compared minor enough.

I think I will go ahead with the two CVE fixes only.

Let me know if you think otherwise.

Regards,
Salvatore

Bug#1070235: Guix fails to pull channel with SSL error

[Tomas Volf]

Package: guix
Version: 1.4.0-3

When I invoke `guix pull' against my channel, it fails with a SSL error:

# /usr/bin/guix pull --url=https://git.wolfsden.cz/.git/guix
Updating channel 'guix' from Git repository at 
'https://git.wolfsden.cz/.git/guix'...
guix pull: error: Git error: SSL error: 0x8880 - SSL - A fatal alert 
message was received from our peer

No special configuration is needed, just booting the system and installing guix
via apt-get.

This seems to be a problem specific to Guix from the debian package.  When I try
to access the channel by other means (from the same system as above), it works
fine.  `git clone' works just fine, and even Guix installed in non-debian way
works fine, for example via time-machine:

guix time-machine -q --commit=v1.4.0 -- pull 
--url=https://git.wolfsden.cz/.git/guix

I am using Debian 12 on 6.7.4 kernel and 2.36-9 libc, running on physical server
machine.

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Bug#1069895: [debian-mysql] Bug#1069895: mariadb-server: InnoDB to hang on systems with very intensive write loads when running out of I/O slots. This problem is fixed with MariaDB Server 10.11.7. Can

[Salvatore Bonaccorso]

Hi,

On Fri, Apr 26, 2024 at 02:27:12PM -0700, Otto Kekäläinen wrote:
> We can put 10.11.7 in Stable until it yas been accepted in Testing first.
> It is on the way though.

I guess it won't migrate very soon yet to testing (due to tim64
transition?). In such case it would still be good to ask SRM for
accepting it for the next point release (given it is fixed in unstable
and this version *is* aimed to go to trixie).

Regards,
Salvatore

Bug#1070079: nghttp3: Update to 1.1.0 or newer

[Sakirnth Nagarasa]

Hello Samuel

I am good and I hope you too.

On 4/29/24 22:24, Samuel Henrique wrote:
> So maybe it even makes sense to get the latest releases for the transition.

I agree. I normaly do both nghttp3 and ngtcp2 the same time, therefore I
didn't want to block the t64 transition. Since ngtcp2 was a reverse
dependency of affected packages. I will try to upload the latest version
this weekend to experimental.

> Would you be interested in any kind of help for this?

Thanks, I will let you know this weekend. Probably in testing the
rebuild of Wireshark with the new version of nghttp3.

> If you would like, we could also put the package under the curl team. We are
> not a "real team" in the sense that we don't gate contributions, that's just 
> to
> make it more easy and clear that people should feel free to do team-uploads.

Yes, that would be good. Given that I can put ngtcp2 also under the curl
team.

Cheers
Saki

Bug#1070172: Exception when invoked without options

[Guido Günther]

Hi,
On Thu, May 02, 2024 at 03:55:53PM +0200, Guido Günther wrote:
> Hi,
> On Wed, May 01, 2024 at 12:27:41PM +0200, Guido Günther wrote:
> > Package: gcovr
> > Version: 7.2-1
> > Severity: grave
> > 
> > Hi,
> > invoking gcovr 7.2 in an empty directory fails like
> > 
> > $ gcovr 
> > --
> >GCC Code Coverage Report
> > Traceback (most recent call last):
> >   File "/usr/bin/gcovr", line 1972, in 
> > print_text_report(covdata)
> >   File "/usr/bin/gcovr", line 822, in print_text_report
> > OUTPUT.write("Directory: "+options.root+"\n")
> >  ~^
> > TypeError: can only concatenate str (not "NoneType") to str
> > 
> > 
> > This makes meson think gcovr is not available, e.g.:
> > 
> >   
> > https://gitlab.gnome.org/World/Phosh/phosh-mobile-settings/-/jobs/3839480#L3265
> > 
> > I've marked this as grave as it breaks CI pipelines.
> 
> Just had a closer look. It seems verson 3.2 instead of 7.2 got
> imported. I'll propose a fix.

Uploaded to delayed/3. MR is at 
https://salsa.debian.org/debian/gcovr/-/merge_requests/5
Cheers,
 -- Guido
> 
> Cheers,
>  -- Guido
> 
> > 
> > Cheers,
> >  -- Guido
> > 
> > 
> > -- System Information:
> > Debian Release: trixie/sid
> >   APT prefers testing
> >   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
> > 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
> > 'experimental')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: arm64
> > 
> > Kernel: Linux 6.6.15-amd64 (SMP w/12 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 gcovr depends on:
> > ii  python33.11.6-1
> > ii  python3-pkg-resources  68.1.2-2
> > 
> > gcovr recommends no packages.
> > 
> > gcovr suggests no packages.
> > 
> > -- no debconf information

Bug#1070133: Patches for these two bugs

[Steve McIntyre]

On Thu, May 02, 2024 at 08:09:46AM -0400, Stefano Rivera wrote:
>Control: tag 1070133 +pending
>Control: tag 1070135 +pending
>
>Hi Steve (2024.05.01_06:07:10_-0400)
>
>Thanks for the patches, backported some more security patches and filed
>a bookworm-pu request (#1070232).

Lovely. :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Bug#1070172: Exception when invoked without options

[Guido Günther]

Hi,
On Wed, May 01, 2024 at 12:27:41PM +0200, Guido Günther wrote:
> Package: gcovr
> Version: 7.2-1
> Severity: grave
> 
> Hi,
> invoking gcovr 7.2 in an empty directory fails like
> 
> $ gcovr 
> --
>GCC Code Coverage Report
> Traceback (most recent call last):
>   File "/usr/bin/gcovr", line 1972, in 
> print_text_report(covdata)
>   File "/usr/bin/gcovr", line 822, in print_text_report
> OUTPUT.write("Directory: "+options.root+"\n")
>  ~^
> TypeError: can only concatenate str (not "NoneType") to str
> 
> 
> This makes meson think gcovr is not available, e.g.:
> 
>   
> https://gitlab.gnome.org/World/Phosh/phosh-mobile-settings/-/jobs/3839480#L3265
> 
> I've marked this as grave as it breaks CI pipelines.

Just had a closer look. It seems verson 3.2 instead of 7.2 got
imported. I'll propose a fix.

Cheers,
 -- Guido

> 
> Cheers,
>  -- Guido
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
> 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: arm64
> 
> Kernel: Linux 6.6.15-amd64 (SMP w/12 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 gcovr depends on:
> ii  python33.11.6-1
> ii  python3-pkg-resources  68.1.2-2
> 
> gcovr recommends no packages.
> 
> gcovr suggests no packages.
> 
> -- no debconf information

Bug#1068925: 1068925: macromoleculebuilder should be limited to 64bit

[Andrius Merkys]

Control: owner -1 !

Hello,

Upstream has confirmed that macromoleculebuilder should be limited to 
64bit. I am going to limit the architectures and file for RM on armhf soon.


Andrius

Bug#1068953: new upstream (10.0)

[Daniel Baumann]

On 5/2/24 10:30, David Lamparter wrote:

I've managed to get sbuild crosscompile to work for hppa and found the
problem (it's a missing "XREF_SETUP()" line, not that the error message
would give any hint to that...)


yay!


I'll put a -2 together later today.


nice, feel free to ping me when done to sponsor it.

Regards,
Daniel

Bug#1068633: bookworm-pu: package cjson/1.7.15-1+deb12u1

[Maytham Alsudany]

Ping! Could someone please have a look at and approve the bookworm-pu for cjson?
The debdiff was changed a while back, and it is attached in this mail.

Kind regards,
Maytham

On Mon, 2024-04-08 at 12:27 +0300, Maytham Alsudany wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: cj...@packages.debian.org
> Control: affects -1 + src:cjson
> 
> [ Reason ]
> CVE-2023-50472, CVE-2023-50471
> 
> [ Impact ]
> Segmentation violation via the function cJSON_InsertItemInArray at cJSON.c
> 
> [ Tests ]
> Upstream's test continue to pass, and they have also added new tests to
> cover this security issue.
> 
> [ Risks ]
> Minimal, no change to API. Only minimal changes were made to fix this
> security issue.
> 
> [ 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 ]
> - Set myself as Maintainer (I am adopting the package, #1067510)
> - Bump Standards-Version to 4.6.2
> - Add Build-Depends-Package to symbools
> - Backport upstream's patch to 'add NULL checkings'.
>   Upstream adds a few more if statements to avoid the segmentation
>   fault, and thus resolve the security vulnerability.
> 
> [ Other info ]
> If you can spare the time, could you please upload this for me? (I need
> a sponsor, #1068624.) I'm also still waiting for someone to give me
> access to the Salsa repo.
> 
> Thanks,
> Maytham

diff -Nru cjson-1.7.15/debian/changelog cjson-1.7.15/debian/changelog
--- cjson-1.7.15/debian/changelog	2021-08-29 23:30:06.0 +0300
+++ cjson-1.7.15/debian/changelog	2024-04-09 04:30:29.0 +0300
@@ -1,3 +1,11 @@
+cjson (1.7.15-1+deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport patch to add NULL checkings (CVE-2023-50472, CVE-2023-50471)
+(Closes: #1059287)
+
+ -- Maytham Alsudany   Tue, 09 Apr 2024 04:30:29 +0300
+
 cjson (1.7.15-1) unstable; urgency=medium
 
   * New upstream release 1.7.15.
diff -Nru cjson-1.7.15/debian/gbp.conf cjson-1.7.15/debian/gbp.conf
--- cjson-1.7.15/debian/gbp.conf	1970-01-01 03:00:00.0 +0300
+++ cjson-1.7.15/debian/gbp.conf	2024-04-09 04:29:47.0 +0300
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch = debian/bookworm
diff -Nru cjson-1.7.15/debian/patches/0001-add-null-checkings.patch cjson-1.7.15/debian/patches/0001-add-null-checkings.patch
--- cjson-1.7.15/debian/patches/0001-add-null-checkings.patch	1970-01-01 03:00:00.0 +0300
+++ cjson-1.7.15/debian/patches/0001-add-null-checkings.patch	2024-04-09 04:29:47.0 +0300
@@ -0,0 +1,101 @@
+Origin: backport, https://github.com/DaveGamble/cJSON/commit/60ff122ef5862d04b39b150541459e7f5e35add8
+From: Peter Alfred Lee 
+Bug: https://github.com/DaveGamble/cJSON/issues/803
+Bug: https://github.com/DaveGamble/cJSON/issues/802
+Bug-Debian: https://bugs.debian.org/1059287
+Acked-by: Maytham Alsudany 
+Subject: [PATCH] add NULL checkings (#809)
+ * add NULL checks in cJSON_SetValuestring
+ Fixes #803(CVE-2023-50472)
+ .
+ * add NULL check in cJSON_InsertItemInArray
+ Fixes #802(CVE-2023-50471)
+ .
+ * add tests for NULL checks
+ add tests for NULL checks in cJSON_InsertItemInArray and cJSON_SetValuestring
+
+--- a/cJSON.c
 b/cJSON.c
+@@ -401,7 +401,12 @@
+ {
+ char *copy = NULL;
+ /* if object's type is not cJSON_String or is cJSON_IsReference, it should not set valuestring */
+-if (!(object->type & cJSON_String) || (object->type & cJSON_IsReference))
++if ((object == NULL) || !(object->type & cJSON_String) || (object->type & cJSON_IsReference))
++{
++return NULL;
++}
++/* return NULL if the object is corrupted */
++if (object->valuestring == NULL)
+ {
+ return NULL;
+ }
+@@ -2260,7 +2265,7 @@
+ {
+ cJSON *after_inserted = NULL;
+ 
+-if (which < 0)
++if (which < 0 || newitem == NULL)
+ {
+ return false;
+ }
+@@ -2271,6 +2276,11 @@
+ return add_item_to_array(array, newitem);
+ }
+ 
++if (after_inserted != array->child && newitem->prev == NULL) {
++/* return false if after_inserted is a corrupted array item */
++return false;
++}
++
+ newitem->next = after_inserted;
+ newitem->prev = after_inserted->prev;
+ after_inserted->prev = newitem;
+--- a/tests/misc_tests.c
 b/tests/misc_tests.c
+@@ -353,6 +353,19 @@
+ {
+ char buffer[10];
+ cJSON *item = cJSON_CreateString("item");
++cJSON *array = cJSON_CreateArray();
++cJSON *item1 = cJSON_CreateString("item1");
++cJSON *item2 = cJSON_CreateString("corrupted array item3");
++cJSON *corruptedString = cJSON_CreateString("corrupted");
++struct cJSON *originalPrev;
++
++add_item_to_array(array, item1);
++add_item_to_array(array, item2);
++
++originalPrev = item2->prev;
++item2->prev = 

Bug#1070150: texlive-latex-extra: performance regression under emulation with 2023.20240207-1

[Preuße]

Control: reassign -1 texlive-binaries
Control: severity -1 important

On 01.05.2024 00:19, Steev Klimaszewski wrote:

Hi all,


Since the 2023.20240207-1 release, there is a major performance
regression when running the tex-common postinst hook in an arm64
chroot on amd64 host.



I assume this is important, further the package needs to be corrected.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070234: udisks2: version 2.10.1-7 and possible issue with Calamares

[Jeremy Hendricks]

Package: udisks2
Version: 2.10.1-7

Hello! For my own odd reasons, I made a Debian SID installable ISO
with Calamares. I created it a few days ago (4/28) and it worked great
to install. I updated the ISO yesterday (5/1) and I now get this
message when I start the installer "There are no partitions to install
on". I reverted back to the backup chroot I used to create the ISO and
installed all updates except for udisks2 and libudisks2-0


udisks2 and libdisks2-0 were updated to 2.10.1-7 on 4/30 and I
confirmed I was using 2.10.1-6 previously.

I am digging deeper but I wanted to get this in to prevent it from
migrating to Trixie if I am correct.

Bug#1067925: RFS: fastfetch/2.8.10 [ITP] -- Fastfetch is a neofetch-like tool for fetching system information and displaying them in a pretty way.

[Maytham Alsudany]

Hi Carter,

It looks like the debian/ directory you have submitted is straight from upstream
(which you have also written), and as such seems to be very lacklustre and aimed
at Ubuntu.

Currently, the packaging does not comply with Debian Policy whatsoever; I
recommend that you look at https://wiki.debian.org/Packaging for some basic
understanding in (compliant) packaging.

I also recommend maintaining packaging for Debian in a separate repo; ideally on
Salsa (Debian's GitLab instance) under the "debian" group.

If you would like, I am happy to provide a full list of problems with the
current package.

I'm also interested in getting fastfetch into Debian, so if you don't want to
try to fix the packaging, prefer if someone else maintained it in Debian, or
want a co-maintainer, I am available :)

Kind regards,
Maytham

On Fri, 29 Mar 2024 01:33:31 + Li Carter  wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "fastfetch":
> 
> * Package name : fastfetch
> Version : 2.8.10
> Upstream contact : [fill in name and email of upstream]
> * URL : https://github.com/fastfetch-cli/fastfetch
> * License : Expat
> * Vcs : [fill in URL of packaging vcs]
> Section : universe/utils
> 
> The source builds the following binary packages:
> 
> fastfetch - Fastfetch is a neofetch-like tool for fetching system information
and displaying them in a pretty way.
> 
> To access further information about this package, please visit the following
URL:
> 
> https://mentors.debian.net/package/fastfetch/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
> dget -x
https://mentors.debian.net/debian/pool/main/f/fastfetch/fastfetch_2.8.10.dsc
> 
> Changes for the initial release:
> 
> fastfetch (2.8.10) unstable; urgency=medium
> .
> * Init debian support
> 
> Regards,
> -- 
> Carter Li
> 
> 



signature.asc
Description: This is a digitally signed message part

Bug#1070233: ITP: telepathy-ofono -- telepathy oFono connection manager

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: telepathy-ofono
  Version : 0.3.1
  Upstream Contact: UBports developers 
* URL : https://gitlab.com/ubports/development/core/telepathy-ofono
* License : LGPL-3
  Programming Lang: C++ / C
  Description : telepathy oFono connection manager

 telepathy-ofono is a Telepathy connection manager that makes it possible for
 Telepathy clients to communicate using oFono modems, enabling features like
 real phone calls and send and receive SMSs.
 .
 This package will be maintained by the Debian UBports Packaging Team and is
 part of Lomiri's phone stack.

Bug#1070217: chromium: Symbol lookup error with libsnappy1v5>=1.2.0

[di dit]

Same issue with nextcloud (package nextcloud-desktop):

$  nextcloud
nextcloud: symbol lookup error:
/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5: undefined symbol:
_ZN6snappy11RawCompressEPKcmPcPm