Bug#1077327: rust-async-channel: test failures on armel

[Matthias Geiger]

Source: rust-async-channel
Severity: serious
X-Debbugs-Cc: werdah...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

rust-async-channel currently fails a single test on armel for the -2:
feature.

Log:

==

205s running 20 tests
205s test capacity ... ok
205s test len_empty_full ... ok
205s test receiver_count ... ok
205s test recv_after_close ... ok
205s test smoke ... ok
205s test sender_count ... ok
205s test send_after_close ... ok
206s error: test failed, to rerun pass `--test bounded`
206s
206s Caused by:
206s   process didn't exit successfully: `CARGO=/usr/bin/cargo 
CARGO_MANIFEST_DIR=/usr/share/cargo/registry/async-channel-2.3.1 
CARGO_PKG_AUTHORS='Stjepan Glavina ' 
CARGO_PKG_DESCRIPTION='Async multi-producer multi-consumer channel' 
CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='Apache-2.0 OR MIT' 
CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=async-channel 
CARGO_PKG_README=README.md 
CARGO_PKG_REPOSITORY='https://github.com/smol-rs/async-channel' 
CARGO_PKG_RUST_VERSION=1.60 CARGO_PKG_VERSION=2.3.1 CARGO_PKG_VERSION_MAJOR=2 
CARGO_PKG_VERSION_MINOR=3 CARGO_PKG_VERSION_PATCH=1 CARGO_PKG_VERSION_PRE='' 
LD_LIBRARY_PATH='/tmp/tmp.zaAfdUX5Ty/target/armv5te-unknown-linux-gnueabi/debug/deps:/tmp/tmp.zaAfdUX5Ty/target/armv5te-unknown-linux-gnueabi/debug:/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib'
 
/tmp/tmp.zaAfdUX5Ty/target/armv5te-unknown-linux-gnueabi/debug/deps/bounded-565f4ac522be8163`
 (signal: 11, SIGSEGV: invalid memory reference)
206s autopkgtest [23:13:09]: test rust-async-channel-2:: 
---]
206s rust-async-channel-2: FAIL non-zero exit status 101
==

It segfaults with an invalid memory reference. A fix would be much
appreciated since this is the last blocker for testing migration of the
async- / zbus stack.

best,

werdahias


- -- 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.9.10-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iIsEARYIADMWIQQUWTv/Sl6/b+DpcW7svtu2B7myvgUCZqZDpRUcd2VyZGFoaWFz
QGRlYmlhbi5vcmcACgkQ7L7btge5sr7CdwD/S0f0BgSOLD6urlMjH6t4YpoFt3NI
qw9Gru+y6bujto8BAO3VuOpNAKvnPvozkNJVia/AycyZlLidWim9ldt7D1wE
=OOWC
-END PGP SIGNATURE-

Bug#1069621: rust-event-listener: no-default-features autopkgtest fails

[Matthias Geiger]

On 14.07.24 15:47, Jonas Smedegaard wrote:

event-listener v5 should now be available at http://incoming.debian.org/
which should be adequate for releasing event-listener-strategy.

I cannot do more until that is done:

DONE in unstable, but awaits testing:

* event-listener v5
   * involves branch transition: v2 -> v5
   * needs to succeed build-time testsuite and autopkgtest

READY for unstable, but awaits event-listener-strategy

* async-channel v2
   * involves branch transition: v1 -> v2
   * accepts event-listener v5
 (via event-listener-strategy)
   * succeeds build-time testsuite in experimental
   * awaits event-listener v5
   * awaits event-listener-strategy
* async-lock v3
   * involves branch transition: v2 -> v3
   * accepts event-listener v5
   * succeeds build-time testsuite in experimental
   * awaits event-listener-strategy

READY for unstable, but awaits async-channel

* async-process v2
   * involves branch transition: v1 -> v2
   * accepts async-channel v2
   * accepts async-lock v2+3
   * accepts event-listener v5
   * succeeds build-time testsuite in experimental
   * awaits async-channel v2
   * awaits event-listener v5

READY for unstable, but awaits async-process

* smol v2
   * involves branch transition: v1 -> v2
   * accepts async-channel v1+2
   * accepts async-fs v1+2
   * accepts async-lock v3
   * succeeds build-time testsuite in experimental
   * awaits async-lock v3
   * awaits async-process v2

UNKNOWN (needs custom testing):

* async-broadcast
   * involves branch transition: v0.5 -> v0.7
   * accepts event-listener v5 in experimental
* async-global-executor
   * needs to accept async-channel v2
 
 
   * needs to accept async-lock v3
* async-io
   * v2.3.3 accepts async-lock v3 in experimental
* async-mutex
   * v1.4.0 accepts event-listener v5 in experimental
* crosstermion
   * v0.14.0 accepts async-channel v2 in experimental, sloppily
* event-listener-strategy
   * v0.5.2 accepts event-listener v5 in experimental
* fs4
   * needs to accept smol v2 at least in experimental
* gst-plugin-gtk4
   * needs to accept async-channel v2 at least in experimental
* sluice
   * needs to accept async-channel v2 at least in experimental
* sqlx-core
   * v0.7.3 accepts event-listener v5 in experimental
* zbus
   * needs to accept event-listener v5


I just uploaded everything (including event-listener-strategy) to 
unstable with nocheck, including zbus and rdeps.


I should have got all relevant packages. Most already have been accepted 
and will be built once their respective deps are available.


best,


werdahias

Bug#1069621: rust-event-listener: no-default-features autopkgtest fails

[Matthias Geiger]

On 13.07.24 18:25, Jonas Smedegaard wrote:


If we are waiting for a specific action (not a timeslot), then lets move
when that action is done (not at some timeslot).

Or whatever: I am ready, just tell you are ready as well.


netavark has been patched; this means we can go ahead from my end.


best,


werdahias

Bug#1069621: rust-event-listener: no-default-features autopkgtest fails

[Matthias Geiger]

On 13.07.24 17:48, Jonas Smedegaard wrote:

Quoting Matthias Geiger (2024-07-13 17:25:06)

On 09.07.24 08:14, Blair Noctis wrote:

The errors came from the fact that os_pipe is sync, while isahc is async. I've
implemented a simple wrapper for the pipe reader & writer; rather long, thus put
in a fork: https://salsa.debian.org/ncts/rust-isahc/-/commits/replace-sluice.

Note that os_pipe can fail, thus two `todo!()`s. OTOH, sluice returns directly
the pipe, without wrapping in Result, so I think there is space for improvement.


Blair,


thanks for this. Jonas, with this patch at hand, are you ok if I file a
RM request for sluice then ?

isahc is RC-buggy anyway and would need an additional aptch for polling 2.x.

I updated all relevant crates for the Rust team (including zbus and all
rdeps). Once sluice is removed I'd suggest we flip the switch then.

Fine with me to then flip the switch *now*, as we can fix isahc/sluic in
parallel the the pile of involved packages entering unstable.

Are you ok with flipping the switch *now*?

I need to build netavark with zbus 4.0 and ask siretart if it's ok; then 
we can do this. I will look into netavark today; maybe we can upload 
everything Sunday morning then ?


best,

werdahias

Bug#1069621: rust-event-listener: no-default-features autopkgtest fails

[Matthias Geiger]

On 09.07.24 08:14, Blair Noctis wrote:


The errors came from the fact that os_pipe is sync, while isahc is async. I've
implemented a simple wrapper for the pipe reader & writer; rather long, thus put
in a fork: https://salsa.debian.org/ncts/rust-isahc/-/commits/replace-sluice.

Note that os_pipe can fail, thus two `todo!()`s. OTOH, sluice returns directly
the pipe, without wrapping in Result, so I think there is space for improvement.


Blair,


thanks for this. Jonas, with this patch at hand, are you ok if I file a 
RM request for sluice then ?


isahc is RC-buggy anyway and would need an additional aptch for polling 2.x.

I updated all relevant crates for the Rust team (including zbus and all 
rdeps). Once sluice is removed I'd suggest we flip the switch then.



best,

werdahias

Bug#1069621: rust-event-listener: no-default-features autopkgtest fails

[Matthias Geiger]

On 08.07.24 18:45, Jonas Smedegaard wrote:

Quoting Matthias Geiger (2024-07-07 11:21:07)

On 07.07.24 10:10, Jonas Smedegaard wrote:
[...]

[...]

isahc requires sluice only for some pipe functionality in two files.
Since patching sluice proves to be hard I'd

opt to patch isahc to use something like stdio::piped() rather than
sluice::pipe. Then I can file a RM request for sluice since it's not
used elsewhere and we can finish this transition.

Makes great sense.


I attached my wip for using os_pipe instead of sluice. Still has four 
errors atm; I'd appreciate some knowledgable people looking into it 
(CC'd ncts). I do not have any more time atm to sink into this; will 
pick it up later unless someone beats me to it.


best,

werdahias
diff --git a/Cargo.toml b/Cargo.toml
index e1ab8ef..351fbc1 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -35,6 +35,7 @@ unstable-interceptors = []
 async-channel = "1.4.2"
 castaway = "0.1.1"
 crossbeam-utils = ">=0.7.0, <0.9.0"
+os_pipe = "*"
 curl = "0.4.36"
 curl-sys = "0.4.55"
 event-listener = "2.3.3"
@@ -44,7 +45,6 @@ log = "0.4"
 once_cell = "1"
 polling = "2"
 slab = "0.4"
-sluice = "0.5.4"
 url = "2.1"
 waker-fn = "1"
 
diff --git a/src/body/sync.rs b/src/body/sync.rs
index e035dee..fe6d380 100644
--- a/src/body/sync.rs
+++ b/src/body/sync.rs
@@ -1,11 +1,11 @@
 use super::AsyncBody;
 use futures_lite::{future::yield_now, io::AsyncWriteExt};
-use sluice::pipe::{pipe, PipeWriter};
+use os_pipe::{PipeWriter, pipe};
 use std::{
 borrow::Cow,
 fmt,
 fs::File,
-io::{Cursor, ErrorKind, Read, Result},
+io::{Cursor, ErrorKind, Read, Result, Write},
 };
 
 /// Contains the body of a synchronous HTTP request or response.
@@ -158,7 +158,8 @@ impl Body {
 Inner::Empty => (AsyncBody::empty(), None),
 Inner::Buffer(cursor) => (AsyncBody::from_bytes_static(cursor.into_inner()), None),
 Inner::Reader(reader, len) => {
-let (pipe_reader, writer) = pipe();
+
+let Ok((pipe_reader, writer)) = pipe();
 
 (
 if let Some(len) = len {
@@ -275,7 +276,7 @@ impl Writer {
 Err(e) => return Err(e),
 };
 
-self.writer.write_all([..len]).await?;
+self.writer.write_all([..len]);
 }
 }
 }
diff --git a/src/handler.rs b/src/handler.rs
index 92445f6..05c9fc9 100644
--- a/src/handler.rs
+++ b/src/handler.rs
@@ -14,7 +14,7 @@ use curl_sys::CURL;
 use futures_lite::io::{AsyncRead, AsyncWrite};
 use http::Response;
 use once_cell::sync::OnceCell;
-use sluice::pipe;
+use os_pipe::{pipe, PipeReader};
 use std::{
 ascii,
 ffi::CStr,
@@ -79,7 +79,7 @@ pub(crate) struct RequestHandler {
 response_headers: http::HeaderMap,
 
 /// Writing end of the pipe where the response body is written.
-response_body_writer: pipe::PipeWriter,
+response_body_writer: os_pipe::PipeWriter,
 
 /// A waker used with writing the response body asynchronously. Populated by
 /// an agent when the request is initialized.
@@ -126,7 +126,7 @@ impl RequestHandler {
 ) {
 let (sender, receiver) = async_channel::bounded(1);
 let shared = Arc::new(Shared::default());
-let (response_body_reader, response_body_writer) = pipe::pipe();
+let Ok((response_body_reader, response_body_writer)) = os_pipe::pipe() else { todo!() };
 
 let handler = Self {
 span: tracing::debug_span!("handler", id = tracing::field::Empty),
@@ -672,7 +672,8 @@ impl fmt::Debug for RequestHandler {
 /// Wrapper around a pipe reader that returns an error that tracks transfer
 /// cancellation.
 pub(crate) struct ResponseBodyReader {
-inner: pipe::PipeReader,
+inner: os_pipe::PipeReader,
+
 shared: Arc,
 }
 

Bug#1069621: rust-event-listener: no-default-features autopkgtest fails

[Matthias Geiger]

On 07.07.24 10:10, Jonas Smedegaard wrote:
[...]

Patching sluice seems not trivial. Given that it's sole rdep is isahc,
would you be ok with me filing a RM request for it if I patch isahc to
use standard rust pipes ? imo this is the easiest option going forward.
The code changes look more doable than patching sluice.
  
I would ertainly be happy getting help with isahc, but I don't quite

understand what you are proposing concretely - how will patching isahc
also require an RM request?!?
isahc requires sluice only for some pipe functionality in two files. 
Since patching sluice proves to be hard I'd


opt to patch isahc to use something like stdio::piped() rather than 
sluice::pipe. Then I can file a RM request for sluice since it's not 
used elsewhere and we can finish this transition.


best,

werdahias

Bug#1069621: rust-event-listener: no-default-features autopkgtest fails

[Matthias Geiger]

On 04.07.24 03:24, Jonas Smedegaard wrote:

Quoting Jonas Smedegaard (2024-06-18 22:58:59)

It seems these packages still need to be updated as well:

Here is the current status:

DONE in unstable:

* async-fs
   * v2.1.2 accepts async-lock v2+3 in unstable
   * v2.1.2 succeeds build-time testsuite and autopkgtests in unstable
* blocking
   * v1.6.1 accepts async-channel v1+2 in unstable
   * v1.6.1 succeeds build-time testsuite and autopkgtests in unstable
* criterion
   * v0.5.1 accepts smol v1+2 in unstable
   * v0.5.1 succeeds build-time testsuite and autopkgtests in unstable
* criterion-0.3
   * v0.3.6 accepts smol v1+2 in unstable
   * v0.3.6 succeeds build-time testsuite and autopkgtests in unstable

DONE in experimental, just need re-release for unstable:

[...]

* sluice
   * needs to accept async-channel v2 at least in experimental
   * needs custom testing: package lacks build-time testing
Patching sluice seems not trivial. Given that it's sole rdep is isahc, 
would you be ok with me filing a RM request for it if I patch isahc to 
use standard rust pipes ? imo this is the easiest option going forward. 
The code changes look more doable than patching sluice.

BROKEN for different reasons

* isahc
   * needs to accept async-channel v2 at least in experimental
   * needs to accept event-listener v5 at least in experimental
   * broken

If, as expected, testing of async-std turns succesfull, I am ready to
re-release to unstable all of the packages listed above that is
currently lingering in experimental.

Please tell when you are ready as well, for the packages above listed as
needing custom testing.  Only say so when they are *all* ready.

Kind regards, and thanks for all your help and patience,


Thanks :)

best,

werdahias

Bug#1074396: librust-ashpd-dev: impossible to install

[Matthias Geiger]

Control: block -1 by 1069621

On Thu, 27 Jun 2024 23:48:44 +0200 Jonas Smedegaard  wrote:

Package: librust-ashpd-dev  > Version: 0.6.7-1+b1 > Severity: grave > Justification: renders 

package unusable >

Package is impossible to install: Depends on missing packages, including
librust-gdk4-wayland-0.7+default-dev.

I know; this was a somewhat deliberate choice as I wanted to push gtk4 
into unstable when event-listener and affected packages were not ready. 
Once those are resolved I need to update zbus to 4.0 fixing this.


best,


werdahias

Bug#1069621: rust-event-listener: no-default-features autopkgtest fails

[Matthias Geiger]

On 23.06.24 17:11, Jonas Smedegaard wrote:

TODO:

* async-global-executor

done.

* crosstermion
   * v0.14.0 accepts async-channel v2 in experimental, sloppily
   * needs custom testing: package lacks build-time testing

done.

* fs4

done.

* gst-plugin-gtk4

done.


* sluice
   * needs to accept async-channel v2 at least in experimental
   * needs custom testing: package lacks build-time testing
does not build with async-channel 2.x easily. will look into getting it 
patched.

* zbus


done, thanks to plugwash.

Bar sluice everything has been uploaded; once that has landed we can 
make the switch imo.



best,


werdahias

Bug#1069575: FTBFS in experimental

[Matthias Geiger]

On Wed, 19 Jun 2024 20:04:26 +0200 Jonas Smedegaard  wrote:
> > >
> > I packaged async-signal; it's awaiting a NEW trip.
>
> Great!
>
async-signal migrated to testing; I'd appreciate it if you could test if 
re-enabling async-signal fixes this bug.

best,

werdahias

Bug#1069621: rust-event-listener: no-default-features autopkgtest fails

[Matthias Geiger]

23.06.2024 17:11:51 Jonas Smedegaard :


Quoting Jonas Smedegaard (2024-06-18 22:58:59)

It seems these packages still need to be updated as well:


Here is a more complete list of branch transisioning entanglements for
async-broadcast, async-channel, async-lock, async-process, event-listener
and smol.

DONE for unstable:

* blocking
  * v1.4.1 accepts async-channel v1+2 in unstable
  * v1.4.1 accepts async-lock v2+3 in unstable

DONE for experimental, just need re-release for unstable:

* async-channel
  * involves branch transition: v1 -> v2
  * v2.3.1 accepts event-listener v5 in experimental
    (via event-listener-strategy)
  * v2.3.1 succeeds build-time testsuite in experimental
* async-executor
  * v1.12.0 stops needing async-lock v2 in experimental
  * v1.12.0 succeeds build-time testsuite in experimental
* async-lock
  * involves branch transition: v2 -> v3
  * v3.4.0 accepts event-listener v5 in experimental
  * v3.4.0 succeeds build-time testsuite in experimental
* async-process
  * involves branch transition: v1 -> v2
  * v2.2.3 accepts async-channel v2 in experimental
  * v2.2.3 accepts async-lock v2+3 in experimental
  * v2.2.3 accepts event-listener v5 in experimental
  * v2.2.3 succeeds build-time testsuite in experimental
* async-std
  * needs to accept async-channel v2 at least in experimental
  * needs to accept async-lock v3 at least in experimental
  * needs to accept async-process v2 at least in experimental
  * awaits librust-async-global-executor-dev
* event-listener
  * involves branch transition: v2 -> v5
  * v5.3.1 succeeds build-time testsuite in experimental

TODO:

* async-broadcast
  * involves branch transition: v0.5 -> v0.7
  * v0.7.0 accepts event-listener v5 in experimental
  * needs custom testing: package lacks build-time testing
* async-fs
  * v2.1.2 accepts async-lock v2+3 in unstable
  * v2.1.2 succeeds build-time testsuite in unstable
  * awaits possible revert if unstable zbus cannot fit new branch
    
* async-global-executor
  * needs to accept async-channel v2 at least in experimental
    
    
  * needs to accept async-lock v3 at least in experimental
  * needs custom testing: package lacks build-time testing
* async-io
  * v2.3.3 accepts async-lock v3 in experimental
  * needs custom testing: package lacks build-time testing
* async-mutex
  * v1.4.0 accepts event-listener v5 in experimental
  * needs custom testing: package lacks build-time testing
* blocking
  * v1.6.1 accepts async-channel v2 in experimental
* criterion
  * needs to accept smol v2 at least in experimental
* criterion-0.3
  * needs to accept smol v2 at least in experimental
    (or obsoletion: https://bugs.debian.org/1074104)
* crosstermion
  * v0.14.0 accepts async-channel v2 in experimental, sloppily
  * needs custom testing: package lacks build-time testing
* event-listener-strategy
  * v0.5.2 accepts event-listener v5 in experimental
  * needs custom testing: package lacks build-time testing
* fs4
  * needs to accept smol v2 at least in experimental
  * needs custom testing: package lacks build-time testing
* gst-plugin-gtk4
  * needs to accept async-channel v2 at least in experimental
  * needs custom testing: package lacks build-time testing
* if-watch
  * needs to accept smol v2 at least in experimental
* isahc
  * needs to accept async-channel v2 at least in experimental
  * needs to accept event-listener v5 at least in experimental
* sluice
  * needs to accept async-channel v2 at least in experimental
  * needs custom testing: package lacks build-time testing
* smol
  * involves branch transition: v1 -> v2
  * v2.0.0 accepts async-channel v1+2 in experimental
  * v2.0.0 accepts async-fs v1+2 in experimental
  * v2.0.0 accepts async-lock v3 in experimental
  * awaits blocking
* sqlx-core
  * v0.7.3 accepts event-listener v5 in experimental
  * needs custom testing: package lacks build-time testing
* zbus
  * needs to accept async-fs in unstable
    
  * needs to accept event-listener v5 at least in experimental
  * needs custom testing: package lacks build-time testing

My next tasks is to get smol working in experimental, and then the
packages depending on smol as well.

After that, I am ready to "flip the switch" and re-release all packages
now in experimental for unstable.  But I would be quite frustrated if it
turns out that the sloppy packaging style by the Rust team has caused
some breakage goes undetected, so I will wait for your guys from the Rust
team to state explicitly here in this bugreport, that you believe that
all the packages listed above as "needs custom testing" are good to go.


Jonas,

thanks for the thorough analysis. For the packages I staged in 
experimental all tests passed (build + autopkgtest), so certainly no 
sloppy work ! I will upload a patched zbus, gst-plugin-gtk4 and the few 
remaining crates which haven't been patched 

Bug#1072807: rust-instant: crate is abandoned - recommended replacement is web_time

[Matthias Geiger]

On 20.06.24 17:29, Jonas Smedegaard wrote:

Quoting Matthias Geiger (2024-06-20 17:14:08)

On Sat, 08 Jun 2024 08:12:48 +0200 Jonas Smedegaard  wrote:

Source: rust-instant  > Version: 0.1.12-3 > Severity: serious > Tags: upstream >
The crate is buggy and unmaintained, according to this:
https://github.com/sebcrozet/instant/issues/52

The recommended (seemingly drop-in) replacement is web_time.

Raising severity as this crate seems unsuitable for long-term stable
distribution.

- Jonas


Tracking at https://salsa.debian.org/rust-team/debcargo-conf/-/issues/66

Debian uses debbugs as bugtracker, so I expect that anything at that
local-to-Rust-team tracker relevant to Debian will be echoed here.


We opted to patch out instant / replace it with std::time::Instant 
rather than packaging web-time since instant is a wasm crate anyway.


All affected crates (indicatif, backoff, rhai) have working / tested 
patches and are awaiting upload. Then I will file a RM request for instant.


best,

werdahias

Bug#1072807: rust-instant: crate is abandoned - recommended replacement is web_time

[Matthias Geiger]

On Sat, 08 Jun 2024 08:12:48 +0200 Jonas Smedegaard  wrote:

Source: rust-instant  > Version: 0.1.12-3 > Severity: serious > Tags: upstream >
The crate is buggy and unmaintained, according to this:
https://github.com/sebcrozet/instant/issues/52

The recommended (seemingly drop-in) replacement is web_time.

Raising severity as this crate seems unsuitable for long-term stable
distribution.

- Jonas


Tracking at https://salsa.debian.org/rust-team/debcargo-conf/-/issues/66

best,


werdahias

Bug#1069575: FTBFS in experimental

[Matthias Geiger]

On 18.06.24 22:16, Jonas Smedegaard wrote:

Quoting Jonas Smedegaard (2024-06-18 22:06:09)

Quoting Matthias Geiger (2024-06-18 15:19:23)

anything blocking an upload of async-process 2.3.0 to exp ?

That it doesn't exist?

Newest upstream release of async-process is v2.2.3.

Not sure why you need it - there is zero functional changes for for
non-android systems since v2.2.1 currently in experimental.

I'll do the update now, regardless.

Ah, now I remember why I didn't update: recent releases of async-process
needs crate async-signal which is not in Debian.

I have not found time yet to pacakge async-signal - you or anyone else,
feel free to package async-signal.

There is no point in updating async-process, as that won't make the FTBFS
disappear.


I packaged async-signal; it's awaiting a NEW trip.

best,

werdahias

Bug#1069621: rust-event-listener: no-default-features autopkgtest fails

[Matthias Geiger]

On Mon, 10 Jun 2024 11:17:04 +0200 Jonas Smedegaard  wrote:
> Quoting Jeremy Bícha (2024-04-21 19:47:08)
> > Simple patch attached.
>
> I am not convinced that this issue should be ignored: Might be revealing
> the upstream bugs recently tracked upstream, which might in Debian be
> affected by relaxed dependencies e.g. on concurrent-queue.
>

Any news on this ? event-listener is currently blocking zbus 4.0 which 
in turn prevents me from fixing the remaining GTK4 rust packages.



best, werdahias

Bug#1069575: FTBFS in experimental

[Matthias Geiger]

On Tue, 11 Jun 2024 22:57:35 +0200 Matthias Geiger 
 wrote:
> On Mon, 10 Jun 2024 11:02:23 +0200 Jonas Smedegaard  
wrote:

>
> > >
> > > I will look into updating concurrent-queue to 2.5.0 then.
> >
> > Any news on updating concurrent-queue to 2.5.0?
> >
>
> > - Jonas
>
> Just uploaded to exp along with async-io 2.3.3.
>
>

 Hi Jonas,

anything blocking an upload of async-process 2.3.0 to exp ?


best,


werdahias

Bug#1069575: FTBFS in experimental

[Matthias Geiger]

On Mon, 10 Jun 2024 11:02:23 +0200 Jonas Smedegaard  wrote:

> >
> > I will look into updating concurrent-queue to 2.5.0 then.
>
> Any news on updating concurrent-queue to 2.5.0?
>

> - Jonas

Just uploaded to exp along with async-io 2.3.3.


best,


werdahias

Bug#1069575: FTBFS in experimental

[Matthias Geiger]

On Sat, 25 May 2024 20:27:28 +0200 Jonas Smedegaard  wrote:
> Control: block -1 by 1071900
>
> Quoting Jonas Smedegaard (2024-05-25 20:13:12)
> > Ahh, you are talking about *async-channel* v2.3.0. Please consider in
> > future to mention crate name, both in email subject and in content, to
> > help disambiguate.
> >
> > I'll have a go at updating async-channel, and tighten dependency on 
that

> > from async-process to see if that solves the FTBFS of async-process.
> >
> > Thanks for nudging,
>
> ...and now I remember what held me back last I had a look at this:
> async-channel v2.3.0 is broken. Bugfix released with v2.3.1 was to
> tighten dependency on concurrent-queue, to a version newer than what is
> in Debian.
>
>
> - Jonas
>

> --

Ack,

I will look into updating concurrent-queue to 2.5.0 then.

--

Matthias Geiger 

Bug#1069575: FTBFS in experimental

[Matthias Geiger]

On Wed, 15 May 2024 22:18:38 +0200 Matthias Geiger 
 wrote:

> On Mon, 22 Apr 2024 19:45:07 +0200 Matthias Geiger
>  wrote:
> > On Sat, 20 Apr 2024 20:36:11 +0200 Matthias Geiger
> >  wrote:
> > > Source: rust-async-process
> > > Version: 1.7.0-4
> > > Severity: important
> > > Tags: ftbfs
> > > X-Debbugs-Cc: jbi...@debian.org, werdah...@riseup.net
> > >
> > >
> > > I didn't have time to investigate this yet. I'd appreciate it if you
> > > coud take a look at this as it is blocking the
> > > event-listener-transition.
> >
> > >
> >
> > 2.2.1 (the latest upstream release) should fix this. Please consider
> > uploading this version so we can proceed with the event-listener
> transition.
> >
>
> 2.3 depends on event-listener-strategy 0.5; this release should fix
> this. I will create a debdiff later and send it over.


Hi Jonas,

is there anything blocking this ? Having 2.3  in exp would resolve the 
FTBFS and pave the way to switch to event-listener 5 (and zbus 4.0 later 
on).


thanks,

--
Matthias Geiger 
Debian Maintainer

Bug#1069575: FTBFS in experimental

[Matthias Geiger]

On Mon, 22 Apr 2024 19:45:07 +0200 Matthias Geiger 
 wrote:

> On Sat, 20 Apr 2024 20:36:11 +0200 Matthias Geiger
>  wrote:
> > Source: rust-async-process
> > Version: 1.7.0-4
> > Severity: important
> > Tags: ftbfs
> > X-Debbugs-Cc: jbi...@debian.org, werdah...@riseup.net
> >
> >
> > I didn't have time to investigate this yet. I'd appreciate it if you
> > coud take a look at this as it is blocking the
> > event-listener-transition.
>
> >
>
> 2.2.1 (the latest upstream release) should fix this. Please consider
> uploading this version so we can proceed with the event-listener 
transition.

>

2.3 depends on event-listener-strategy 0.5; this release should fix 
this. I will create a debdiff later and send it over.



--
Matthias Geiger 
Debian Maintainer

Bug#1014539: squirrel3: CVE-2022-30292

[Matthias Geiger]

On Thu, 18 Apr 2024 14:40:58 +0200 Matthias Geiger 
 wrote:


>
> //I have prepared a fix; however this needs the FTBFS in #997441
> adressed first.
>
> Will attach a debdiff once that has happened.
>

See attachement.

best,

--
Matthias Geiger 
Debian Maintainer
diff -Nru squirrel3-3.1/debian/changelog squirrel3-3.1/debian/changelog
--- squirrel3-3.1/debian/changelog  2024-02-16 17:46:43.0 +0100
+++ squirrel3-3.1/debian/changelog  2024-05-06 23:54:53.0 +0200
@@ -1,3 +1,11 @@
+squirrel3 (3.1-8.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-pick upstream commit as 03-fix-buffer-overflow.diff (Closes: 
#1014539)
+(CVE-2022-30292) 
+
+ -- Matthias Geiger   Mon, 06 May 2024 23:54:53 +0200
+
 squirrel3 (3.1-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff 
squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff
--- squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff1970-01-01 
01:00:00.0 +0100
+++ squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff2024-05-06 
23:52:27.0 +0200
@@ -0,0 +1,22 @@
+From a6413aa690e0bdfef648c68693349a7b878fe60d Mon Sep 17 00:00:00 2001
+From: Alberto Demichelis 
+Date: Mon, 2 May 2022 12:04:58 +0200
+Subject: [PATCH] fix in thread.call
+
+---
+ squirrel/sqbaselib.cpp | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/squirrel/sqbaselib.cpp b/squirrel/sqbaselib.cpp
+index 662aeac..e283900 100644
+--- a/squirrel/sqbaselib.cpp
 b/squirrel/sqbaselib.cpp
+@@ -1012,6 +1012,7 @@ static SQInteger thread_call(HSQUIRRELVM v)
+ SQObjectPtr o = stack_get(v,1);
+ if(type(o) == OT_THREAD) {
+ SQInteger nparams = sq_gettop(v);
++sq_reservestack(_thread(o), nparams + 3);
+ _thread(o)->Push(_thread(o)->_roottable);
+ for(SQInteger i = 2; i<(nparams+1); i++)
+ sq_move(_thread(o),v,i);
+
diff -Nru squirrel3-3.1/debian/patches/series 
squirrel3-3.1/debian/patches/series
--- squirrel3-3.1/debian/patches/series 2024-02-16 17:46:43.0 +0100
+++ squirrel3-3.1/debian/patches/series 2024-05-06 23:52:45.0 +0200
@@ -1,2 +1,3 @@
 01-fix-spelling-errors.patch
 02-sphinx-ext.patch
+03-fix-buffer-overflow.diff

Bug#1069687: librust-bitflags-1-dev: fails to co-install

[Matthias Geiger]

On Mon, 22 Apr 2024 21:01:22 +0200 Helmut Grohne  wrote:
> Package: librust-bitflags-1-dev
> Version: 1.3.2-5+b1
> Severity: serious
> Justification: causes an installation failure
>
> Hi,
>
> Attempting to install librust-bitflags-1-dev for multiple architectures
> fails, because apt and dpkg disagree about how breaks and provides work.
> apt thinks that self-breaks can be ignored, but dpkg thinks that since
> librust-bitflags-1-dev breaks+provides librust-bitflags-1.3.2-dev it
> cannot be coinstalled and gives up. You cannot combine such
> breaks+provides with m-a:same. The simplest workaround here is dropping
> m-a:same as it cannot be exercised anyway.
>
> Helmut


This is the same situation as in #1040477. This is an issue wrt how we 
generate the semvers. I image rust-proc-macro-crate-1 would pose the 
same problem. Quoting you from 1040477:



A very simple workaround from my pov would be temporarily removing
Multi-Arch: same. Of course that would make the package unavailable to
cross compilation, but on the flip side, it already is. After dropping
Multi-Arch: same, dose would no longer consider solutions involving
coinstallations of it and archive testing could continue.

Failing that, the only way I see is blacklisting the package in crossqa,
but then I'd probably forget about it and it would also be surprising in
the diagnostics as crossqa would always tell that this package does not
exist. I prefer having you work around the issue. A simple upload
dropping M-A:same removes the worst of pain and gives us time to work on
a generic solution. Do you agree?


Is the only workaround dropping Ma:same here ?

Unfortunately we need the semvers (but try to keep them to a minimum).

CC'd Fabian since he is a bit more knowledgable than me here.

best,


--
Matthias Geiger 
Debian Maintainer

Bug#1067251: librust-isahc-dev: impossible to install

[Matthias Geiger]

On Wed, 20 Mar 2024 21:29:24 +0100 Matthias Geiger 
 wrote:

> Package: librust-isahc-dev
> Severity: grave
> Justification: not installable
> X-Debbugs-Cc: werdah...@riseup.net
>

Unfortunately polling 2.x to 3.x had breaking changes. This is my 
attempt at a


(non-working) patch bumping polling (see attachment). Maybe you can 
figure out the missing bits; this is too difficult for me.


best,

werdahias
diff --git a/Cargo.toml b/Cargo.toml
index d797d20..62ca8cd 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -43,7 +43,7 @@ futures-io = "0.3.24" # futures-io ecosystem compatibility
 http = "0.2.1" # http ecosystem compatibility, part of API
 log = "0.4" # log ecosystem compatibility
 once_cell = "1" # used for a few singletons
-polling = "2" # async I/O driver
+polling = "3" # async I/O driver
 sluice = "0.5.4" # byte buffers between curl and Isahc
 url = "2.1" # URL parsing
 waker-fn = "1" # async primitive
diff --git a/src/agent/selector.rs b/src/agent/selector.rs
index 813e708..836dd39 100644
--- a/src/agent/selector.rs
+++ b/src/agent/selector.rs
@@ -1,5 +1,5 @@
 use curl::multi::Socket;
-use polling::{Event, Poller};
+use polling::{Event, Poller, Events};
 use std::{
 collections::{HashMap, HashSet},
 io,
@@ -30,7 +30,7 @@ pub(crate) struct Selector {
 
 /// Socket events that have occurred. We re-use this vec every call for
 /// efficiency.
-events: Vec,
+events: Events,
 
 /// Incrementing counter used to deduplicate registration operations.
 tick: usize,
@@ -50,7 +50,7 @@ impl Selector {
 poller: Arc::new(Poller::new()?),
 sockets: HashMap::with_hasher(Default::default()),
 bad_sockets: HashSet::with_hasher(Default::default()),
-events: Vec::new(),
+events: Events::new(),
 tick: 0,
 })
 }
@@ -144,7 +144,7 @@ impl Selector {
 // We don't do this immediately after polling because the caller may
 // choose to de-register a socket before the next call. That's why we
 // wait until the last minute.
-for event in self.events.drain(..) {
+for event in self.events.iter() {
 let socket = event.key as Socket;
 if let Some(registration) = self.sockets.get_mut() {
 // If the socket was already re-registered this tick, then we
@@ -211,21 +211,17 @@ fn poller_add(poller: , socket: Socket, readable: bool, writable: bool) -
 // operation as a modification is sufficient to handle this.
 //
 // This is especially common with the epoll backend.
-if let Err(e) = poller.add(socket, Event {
-key: socket as usize,
-readable,
-writable,
-}) {
+if let Err(e) = poller.add(socket, 
+Event::readable(socket.try_into().unwrap()),
+) {
 tracing::debug!(
 "failed to add interest for socket {}, retrying as a modify: {}",
 socket,
 e
 );
-poller.modify(socket, Event {
-key: socket as usize,
-readable,
-writable,
-})?;
+poller.modify(socket, 
+Event::readable(socket.try_into().unwrap()),
+)?;
 }
 
 Ok(())
@@ -239,21 +235,17 @@ fn poller_modify(
 ) -> io::Result<()> {
 // If this errors, we retry the operation as an add instead. This is done
 // because epoll is weird.
-if let Err(e) = poller.modify(socket, Event {
-key: socket as usize,
-readable,
-writable,
-}) {
+if let Err(e) = poller.modify(socket, 
+Event::readable(socket.try_into().unwrap()),
+) {
 tracing::debug!(
 "failed to modify interest for socket {}, retrying as an add: {}",
 socket,
 e
 );
-poller.add(socket, Event {
-key: socket as usize,
-readable,
-writable,
-})?;
+poller.add(socket,
+Event::readable(socket.try_into().unwrap()),
+)?;
 }
 
 Ok(())

Bug#1014539: squirrel3: CVE-2022-30292

[Matthias Geiger]

On Thu, 7 Jul 2022 17:55:11 +0200 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= 
 wrote:

> Source: squirrel3
> X-Debbugs-CC: t...@security.debian.org
> Severity: grave
> Tags: security
>
> Hi,
>
> The following vulnerability was published for squirrel3.
>
> CVE-2022-30292[0]:
> | Heap-based buffer overflow in sqbaselib.cpp in SQUIRREL 3.2 due to
> | lack of a certain sq_reservestack call.
>
> 
https://github.com/albertodemichelis/squirrel/commit/a6413aa690e0bdfef648c68693349a7b878fe60d

> https://github.com/sprushed/CVE-2022-30292
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2022-30292
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30292
>
> Please adjust the affected versions in the BTS as needed.
>

>

//I have prepared a fix; however this needs the FTBFS in #997441 
adressed first.


Will attach a debdiff once that has happened.

best,

--
Matthias Geiger 
Debian Maintainer

Bug#1068721: Depends on nonexistant librust-parking-2+std-dev

[Matthias Geiger]

Package: librust-event-listener-dev
Severity: serious
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Jonas,

thanks for updating event-listener.
However, the package is unistallable for me:

sudo apt install librust-event-listener-dev -t experimental  -s
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 librust-event-listener-dev : Depends: librust-parking-2+std-dev but it is not 
installable
E: Unable to correct problems, you have held broken packages.

parking does not have a +std feature enabled:

[...]

Provides:
  librust-parking+default-dev
  librust-parking-2+default-dev
  librust-parking-2-dev
  librust-parking-2.0+default-dev
  librust-parking-2.0-dev
  librust-parking-2.0.0+default-dev
  librust-parking-2.0.0-dev
Replaces: librust-parking-dev
[...]

best,

werdahias

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages librust-event-listener-dev depends on:
pn  librust-concurrent-queue-2+std-dev
pn  librust-parking-2+std-dev 
pn  librust-pin-project-lite-0.2+default-dev  

librust-event-listener-dev recommends no packages.

librust-event-listener-dev suggests no packages.

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmYVhPkVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR11vMQAMBgRGPBHxDTy7893h2ovmTguPBs
1hqSiZFgZVaySLtMd0RY2MT3YlaCfUQGVMmyHMBVjHc0FLj0YZxSrSI7760bBNL7
O7binQZEl0VIGUb1TKSHNTiapo9l8xKwuwt3nG5ObttQV3cFk0vxIHgUjjpHffYE
sZOD2cLZYx5zLU29TGSDP/WIqMCaBhUwDHNqQGihpuVniRzKO9b0YTBvsNSrKy9+
+vh8CiK2sQzNcpcFgPH3nlhIDUj+XEfo4rEWBIuO7MDbuFCPehmoBGQnM7nnmB9e
3XGamSigg8+ZUJhKa5AbTppZbugLCfXW2htqaX6bVuseFmfKtGxfnXK01Xvsgi+x
7tucQpUcVEpXGh7pA2VmKNOVSvFUWH+m/QI5XN2gtnaVICe1pHpPPaIGHIdSQhyA
Ua0tSSM0MDsjJ0KUU3y+ZPW7zAfdTenSwkqCWbEyGQ0+A9xLXWhsm7zEbTyfSK+g
3SwueCajbKNFFCG71Hot/VgMyfTPQwbJcy6bQmDVWTipDGymEmwpce83tO9Ec3IW
t52ShOPUjWiKWtIeI2ScSIsesS/2XZmqAEx2LJTB5oObpJe4XIfTeG5Sm9mZrhpN
ODowu6du/WJ6vz1sM+OhawysJbM3jZFFBKEfzD+LwglN70mAfZ7f7gZfkcByc+BD
gBpcQKl3ZqfaDoPn
=ppql
-END PGP SIGNATURE-

Bug#1067251: librust-isahc-dev: impossible to install

[Matthias Geiger]

Package: librust-isahc-dev
Severity: grave
Justification: not installable
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

librust-isahc-dev is uninstallable because of the polling update:

 sudo apt install librust-isahc-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 librust-isahc-dev : Depends: librust-curl-0.4+default-dev (>= 0.4.36)
 Depends: librust-curl-0.4+static-ssl-dev (>= 0.4.36)
 Depends: librust-curl-sys-0.4+default-dev (>= 0.4.55)
 Depends: librust-polling-2+default-dev but it is not 
installable
E: Unable to correct problems, you have held broken packages.

best,

werdahias



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

Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages librust-isahc-dev depends on:
pn  librust-async-channel-1+default-dev 
pn  librust-castaway-0.2+default-dev
pn  librust-crossbeam-utils-0+default-dev   
pn  librust-curl-0.4+default-dev
pn  librust-curl-0.4+http2-dev  
pn  librust-curl-0.4+static-curl-dev
pn  librust-curl-0.4+static-ssl-dev 
pn  librust-curl-sys-0.4+default-dev
pn  librust-curl-sys-0.4+spnego-dev 
pn  librust-encoding-rs-0.8+default-dev 
pn  librust-event-listener-2+default-dev
pn  librust-futures-lite-1+default-dev  
pn  librust-http-0.2+default-dev
pn  librust-httpdate-1+default-dev  
pn  librust-log-0.4+default-dev 
pn  librust-mime-0.3+default-dev
pn  librust-once-cell-1+default-dev 
pn  librust-parking-lot-0.12+default-dev
pn  librust-polling-2+default-dev   
pn  librust-publicsuffix-2+default-dev  
pn  librust-publicsuffix-2+std-dev  
pn  librust-serde-1+default-dev 
pn  librust-serde-json-1+default-dev
pn  librust-slab-0.4+default-dev
pn  librust-sluice-0.5+default-dev  
pn  librust-tracing-0.1+default-dev 
pn  librust-tracing-0.1+log-dev 
pn  librust-tracing-futures-0.2+std-dev 
pn  librust-tracing-futures-0.2+std-future-dev  
pn  librust-url-2+default-dev   
pn  librust-waker-fn-1+default-dev  
ii  publicsuffix20231001.0357-0.1

librust-isahc-dev recommends no packages.

librust-isahc-dev suggests no packages.

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmX7RyAVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1xvAP/AkjiKceqcLqadETCbOs1zSB2o3U
E3FMOEnHm9hY5C4/ClYhqJ1/X+jutEVxVVdziOYI6F0XfCLw+clI4tv5XNAu7XIV
MVokWdnk7sI6aF/F6R246/22gN6lSDzIR/MK2aXM0b2YeGgCmrQZsECQipWz3QmE
UKRW3rpccrdct73Hl0qS/P/dl7tAP/qcDvRPfB6tWX6FcMoc2TSsx+2HRdjgxn+D
Wiy769D3sc31C+o05RpxEyY0/QMV6q/qI+hzKZk7dC0tG6yANAI59fjYoj5RgpYK
Cdyd1KqYVR0ltb1VIR5PfHBl4PpOfCdu3XbgRo70GfaDBKpC+IsdOPp61QE4nohx
YKVmBWzdEui2JFV+NNLAZH74m+HqOoLZxulym1k2fPY1QAgy0zuGgVlJB5D7SCNW
PbIktFB53CWoUkJPu87yiLF7mqrbMYQk1R4HrHDzjlevd80zq9/Ae5WBMZJK1X82
pOElejk0LI6sNeRZbHEtR2HzWCD/Mez26oNdwLApWNPIK1W+JT8LeuKmKa7osEgr
A4oWdPB5/Qzk4nZ+ryfY7chCy0zqEX8hrUQSZ0t0z7KW7jfNyXJzxyXo/EmwQvg3
f7+g4j71tIbB2qfjKBJKF9sGyiAj0BU+7xpS2Sg8ZcLsFm4uUvvy54HAkVffz2Qx
OehVdADb2j32am09
=Zmbl
-END PGP SIGNATURE-

Bug#1064375: Raising severity of rust-gtk bugs

[Matthias Geiger]

On Sun, 3 Mar 2024 10:01:21 -0500 =?UTF-8?Q?Jeremy_B=C3=ADcha?= 
 wrote:

> Control: severity -1 serious
>
> at-spi2-core is part of the 64-bit time_t transition. The new version
> of at-spi2-core is causing rust-atk-sys' autopkgtest to fail.
> rust-atk-sys and the rest of the Rust GTK3 stack is no longer
> maintained upstream. One way to handle this is to ignore failures of
> the overly sensitive autopkgtest. But it also makes the GNOME 46 Rust
> transition easier if we don't need to tweak or fix all the Rust GTK3
> stuff ourselves.
>
> Therefore, I am raising the severity of this bug and we will probably
> ask the Debian Release Team to remove these packages from Testing even
> faster than the automatic removal process.
>
> Thank you,
> Jeremy Bícha
>

>

It is now EOL/deprecated officialy upstream: 
https://github.com/gtk-rs/gtk3-rs.


I managed to vendor in the crates for squeekboard but I couldn't get it 
to build, will look into it more but would appreciate a second opinion. 
For gtklayershell / swayosd we can do the same; building


a mix of vendored and packaged crates works.

best,

--
Matthias Geiger 
Debian Maintainer



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064374: rust-gtk-layer-shell-sys: Depends on obsolete rust-gtk

[Matthias Geiger]

On Tue, 20 Feb 2024 17:22:36 -0500 =?UTF-8?Q?Jeremy_B=C3=ADcha?= 
 wrote:

> Source: rust-gtk-layer-shell-sys
> Version: 0.7.0-1
> Severity: serious
> X-Debbugs-CC: maytha8the...@gmail.com, sylves...@debian.org
>
> rust-gtk-layer-shell-sys (and rust-gtk-layer-shell) depends on
> rust-gtk which is the old GTK3 library that is no longer maintained.
> rust-gtk is only in Debian because of squeekboard.
>
> Please instead package https://crates.io/crates/gtk4-layer-shell and
> encourage apps using the old rust-gtk-layer-shell to switch to the
> gtk4 version.
>
> Please let me know if there is a reason we should not file a removal
> bug for rust-gtk-layer-shell-sys (which only appeared in Debian this
> month).
>
> On behalf of the Debian Rust Maintainers,
> Jeremy Bícha
>

>

Since this was packaged in preparation for swayosd (which I would like 
to see packaged in debian) I think the best way forward here is to 
vendor gtk-layershell(-sys) and its gtk3-rs related deps in (for 
swayosd) and remove it from debian.


GTK3-rs is eol upstream and building "mixed" is a good compromise imho 
until upstream switches to gtk4-layershell.


I will  try to prepare a MR for Maythams WIP packaging which does that.

best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#997441: squirrel3: FTBFS: '! LaTeX Error: File `tgtermes.sty' not found.'

[Matthias Geiger]

On Sat, 23 Oct 2021 22:26:14 +0200 Lucas Nussbaum  wrote:
> Source: squirrel3
> Version: 3.1-8
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20211023 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[2]: Entering directory '/<>/debian/tmp/doc'
> > latexmk -pdf -dvi- -ps- 'reference.tex'
> > Rc files read:
> > /etc/LatexMk
> > latexmkrc
> > Latexmk: This is Latexmk, John Collins, 21 September 2021, version: 
4.75.

> > Rule 'pdflatex': File changes, etc:
> > Changed files, or newly in use since previous run(s):
> > 'reference.tex'
> > 
> > Run number 1 of rule 'pdflatex'
> > 
> > 
> > Running 'pdflatex -recorder "reference.tex"'
> > 
> > Latexmk: applying rule 'pdflatex'...
> > This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 
2022/dev/Debian) (preloaded format=pdflatex)

> > restricted \write18 enabled.
> > entering extended mode
> > (./reference.tex
> > LaTeX2e <2021-06-01> patch level 1
> > L3 programming layer <2021-08-27> (./sphinxmanual.cls
> > Document Class: sphinxmanual 2019/12/01 v2.3.0 Document class 
(Sphinx manual)

> > (/usr/share/texlive/texmf-dist/tex/latex/base/report.cls
> > Document Class: report 2021/02/12 v1.4n Standard LaTeX document class
> > (/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)))
> > (/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty)
> > (/usr/share/texlive/texmf-dist/tex/latex/cmap/cmap.sty)
> > (/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty<>)
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
> > For additional information on amsmath, use the `?' option.
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty))
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty)
> > (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty))
> > (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amssymb.sty
> > (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amsfonts.sty))
> > (/usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
> > (/usr/share/texlive/texmf-dist/tex/generic/babel/babel.def
> > (/usr/share/texlive/texmf-dist/tex/generic/babel/txtbabel.def))
> > (/usr/share/texlive/texmf-dist/tex/generic/babel-english/english.ldf))
> >
> > ! LaTeX Error: File `tgtermes.sty' not found.
> >

> > Type X to quit or  to proceed,

tags -1 patch

thanks


debdiff fixing this bug attached.


best,


werdahias

diff -Nru squirrel3-3.1/debian/changelog squirrel3-3.1/debian/changelog
--- squirrel3-3.1/debian/changelog  2019-08-01 15:01:06.0 +0200
+++ squirrel3-3.1/debian/changelog  2024-02-16 17:46:43.0 +0100
@@ -1,3 +1,11 @@
+squirrel3 (3.1-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix watch file to look for Github tags instead of releases 
+  * Build-depend on tex-gyre (Closes: #997441)
+
+ -- Matthias Geiger   Fri, 16 Feb 2024 17:46:43 +0100
+
 squirrel3 (3.1-8) unstable; urgency=medium
 
   * Change build dependency from texlive-generic-extra to
diff -Nru squirrel3-3.1/debian/control squirrel3-3.1/debian/control
--- squirrel3-3.1/debian/control2019-08-01 15:01:06.0 +0200
+++ squirrel3-3.1/debian/control2024-02-16 17:46:43.0 +0100
@@ -8,7 +8,8 @@
texlive,
texlive-latex-extra,
texlive-plain-generic,
-   latexmk
+   latexmk,
+   tex-gyre,
 Standards-Version: 4.4.0
 Homepage: http://squirrel-lang.org/
 Vcs-Git: https://salsa.debian.org/wolff-guest/squirrel3.git/
diff -Nru squirrel3-3.1/debian/watch squirrel3-3.1/debian/watch
--- squirrel3-3.1/debian/watch  2019-08-01 15:01:06.0 +0200
+++ squirrel3-3.1/debian/watch  2024-02-16 17:46:11.0 +0100
@@ -1,4 +1,4 @@
 version=4
 opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%squirrel-$1.tar.gz%" \
- https://github.com/albertodemichelis/squirrel/releases \
+ https://github.com/albertodemichelis/squirrel/tags \
  (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate

Bug#1063498: rust-glib-sys FTBFS with the nocheck build profile: cp: cannot stat '/usr/share/gir-1.0/GLib-2.0.gir': No such file or directory

[Matthias Geiger]

On Thu, 8 Feb 2024 15:20:53 +0100 Helmut Grohne  wrote:
> Source: rust-glib-sys
> Version: 0.18.1-2
> Severity: serious
> Tags: ftbfs trixie sid
>
> rust-glib-sys fails to build from source in unstable when built with the
> nocheck build profile. Since trixie, a nocheck failure is considered
> release-critical. A build ends with:
>
> | debian/rules execute_before_dh_auto_build
> | make[1]: Entering directory '/<>'
> | cp /usr/share/gir-1.0/GLib-2.0.gir /<>
> | cp: cannot stat '/usr/share/gir-1.0/GLib-2.0.gir': No such file or 
directory

> | make[1]: *** [debian/rules:9: execute_before_dh_auto_build] Error 1
> | make[1]: Leaving directory '/<>'
> | make: *** [debian/rules:4: binary] Error 2
> | dpkg-buildpackage: error: debian/rules binary subprocess returned 
exit status 2

>

> Helmut

Control: tags +1 patch

Hi Helmut,

the version in experimental already contains the fix for this. I hope to 
subsequently upload all of gtk-rs to experimental this weekend and then 
to unstable soon after.


Actually some other gtk-rs packages are also affected; this will be 
remedied.


best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060848: (no subject)

[Matthias Geiger]

reopen 1060848

thanks


still present in the latest upload.


--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060848: rust-isahc: Autopkgtest failures

[Matthias Geiger]

Source: rust-isahc
Version: 1.7.2+ds-24
Severity: serious
Justification: fails to migrate to testing
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

See
https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-isahc/40410753/log.gz.

snip:

842s error: cannot determine resolution for the macro `mock`
842s--> tests/redirects.rs:268:9
842s |
842s 268 | mock! {
842s | 
842s |
842s = note: import resolution is stuck, try simplifying macro imports
842s 
842s error: cannot determine resolution for the macro `mock`
842s--> tests/redirects.rs:292:14
842s |
842s 292 | let m2 = mock! {
842s |  
842s |
842s = note: import resolution is stuck, try simplifying macro imports
842s 
842s error: cannot determine resolution for the macro `mock`
842s--> tests/redirects.rs:300:14
842s |
842s 300 | let m1 = mock! {
842s |  
842s |
842s = note: import resolution is stuck, try simplifying macro imports
842s 
842s error: could not compile `isahc` due to 3 previous errors
==

This blocks testing migration for rust-transmission-client, please fix
isahc accordingly.

best,

werdahias


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

Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmWlU6EVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1/BAQAK4PodKtnigscZNZi9NpEEDs56rT
qsheNo3a6AzaN/3uwpjfcN7otzMxarKmS+oPgNoEDId9q4zlS0zRAAL95jT2XrSq
VayXKyGJuiU0dw6V6J4wdjjBGDAs/NgSxNSaGnrKPOjDyLUgyJunp7iW/6Oiec6p
UnfTMx8RtuJbVICtpocvLr5RsDFfusRAlncnKZ5m3sILqPAQizTyohoy3/BJRSfh
aLmefKNvLikVSUYiwIeccG+Fyclp+O+LfNroMfHNbbEJHy0UMXZaYWZmfn/nD7F5
Id6wkBxYnckV5JXZ4xRMCBHq8cPHQMQOfLe0HOZEvFkAxBEICGs8nkbLb+HWup/1
ZczOX4thxoTqSypVI3ZuFFN3c3LWUFEzeOuWjcJsy+1vIa8Kp+Ivk0P3wzMp/DNj
AVMfsUE5pB5QjQ5lU4uCK43nPXSuElmhNAyMsow3+dxSpA/hwig+pmq9DMLbLVYf
75suhPWYx4UeVbrLEmY82dDT4kPOa8FdzmOxvN/z9JDD6MOPerynU+CqAlgzQvdm
lQNfPdbBLF2ZB73UP5YL+3GxfmSM0o15xR19REfs2aZf81GzBL2+OSW2s7efMo2t
p3xGjz2j9Osf8qMz7FuiAyidKRBhGstpZx6B3erPHm5pSKijrM+l/rKNW3jBh20i
NYzu/ciejRBoGBjf
=ccy6
-END PGP SIGNATURE-

Bug#993849: RE. authenticator

[Matthias Geiger]

On 13.01.24 14:19, Bastian Germann wrote:

Hi Matthias,

On Fri, 14 Jul 2023 00:59:43 +0200 Matthias Geiger 
 wrote:
If my tracking spreadsheet is correct (rust) authenticator is still 
missing five crates:


scrypt, search-provider, libadwaita, gst-plugin-gtk4 and aes-gcm.


They are all available (gst-plugin-gtk4 in experimental) now.
Are you going to upload the new version soon?
The git repo should be moved over to the GNOME Team. Is there anybody 
with sufficient rights?




Hi Bastian,

gst-plugin-gtk4 still needed the rest of the gstreamer-gl* packages 
which were just accepted today from NEW. Another issue is Authenticator 
depending on aperture. While it is available on crates.io it does not 
include a copy of its license in the source which I believe won't fly 
with ftpmasters. It's upstream just links to it (see issue [0] ).


I would rather someone else would take over Authenticator as I already 
maintain a lot; the options I see are a) getting upstream to include the 
license (might be unlikely since they aren't distro-friendly ) or use an 
old version of Authenticator which does not use aperture yet.


I don't have a lot of time until February anyway but save the aperture 
situation this should be straightforward to package now.


[0] https://gitlab.gnome.org/GNOME/snapshot/-/issues/114

best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059495: src:corectrl: unsatisfied build dependency in testing: libtrompeloeil-cpp-dev

[Matthias Geiger]

On Tue, 26 Dec 2023 19:29:35 +0100 Paul Gevers  wrote:
> Source: corectrl
> Version: 1.3.8+ds-1
> Severity: serious
> Tags: sid trixie
> User: debian...@lists.debian.org
> Usertags: edos-uninstallable
>
> Dear maintainer(s),
>
> Dose [1] is reporting a build issue with your package, it's missing a
> build dependency. Obviously your build dependencies shouldn't be
> removed from testing, but unfortunately there are multiple scenarios
> where that can happen nevertheless. To uphold our social contract,
> Debian requires that packages can be rebuild from source in the suite
> we are shipping them, so currently this is a serious issue with your
> package in testing.
>
> Can you please investigate the situation and figure out how to resolve
> it? Regularly, if the build dependency is available in unstable,
> helping the maintainer of your Build-Depends to enable migration to
> testing is a great way to solve the issue. If your build dependency is
> gone from unstable and testing, you'll have to fix the build process
> in some other way.
>
> Paul
>
> Note: this bug report was sent after some quick manual checks using a
> template. Please reach out to me if you believe I made a mistake in my
> process.
>
> [1] 
https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html


>

Hi Paul,

yeah, you're right. I intend to fix trompeloeil soon since its bug can 
be worked around by not running the tests for now.


This will unblock corectrl and resolve this bug, too.

best,


--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051281: oregano: Segfault on initial startup (intermittent)

[Matthias Geiger]

On Tue, 05 Sep 2023 13:39:03 -0400 Calum McConnell 
 wrote:

> Package: oregano
> Version: 0.84.41+dfsg.1-1.1
> Severity: grave
> Justification: renders package unusable
>
> Its a segfault on startup, after the splash screen shows but before 
anything happens.
> I have it running right now, for no reason that I can tell, but it 
occured both when
> launched through a terminal or through GNOME. A few coredumps are 
attached of crashing

> runs; i'm not sure how lucky I got to get it running now.
>
> Coredumps are zstd-compressed, extracted straight from coredumpctl

I have the same issue. The crash happens only under Wayland; forcing 
GDK_BACKEND_x11 oregano opens the program and it works as intended.


While this is a legit workaround it shouldn't segfault on startup either 
way. I resorted to using KiCad for drawing circuits.


best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054714: trompeloeil-cpp: FTBFS: compiling_tests.cpp:22:10: fatal error: catch2/catch.hpp: No such file or directory

[Matthias Geiger]

On 28.10.23 01:45, Matthias Geiger wrote:



This was caused by the recent upload of catch2 to the 3.x release 
track. The header name changed so naturally the build fails now.


Looking at https://qa.debian.org/excuses.php?package=catch2 this broke 
quite a few other packages.


best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054714: trompeloeil-cpp: FTBFS: compiling_tests.cpp:22:10: fatal error: catch2/catch.hpp: No such file or directory

[Matthias Geiger]

On Fri, 27 Oct 2023 21:16:46 +0200 Lucas Nussbaum  wrote:
> Source: trompeloeil-cpp
> Version: 44-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20231027 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > cd /<>/obj-x86_64-linux-gnu/test && /usr/bin/c++ 
-I/<>/include -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 
-Wall -Wextra -pedantic -Wshadow -Wconversion -Wnonnull -Werror -g 
-std=c++14 -MD -MT test/CMakeFiles/self_test.dir/compiling_tests.cpp.o 
-MF CMakeFiles/self_test.dir/compiling_tests.cpp.o.d -o 
CMakeFiles/self_test.dir/compiling_tests.cpp.o -c 
/<>/test/compiling_tests.cpp
> > /<>/test/compiling_tests.cpp:22:10: fatal error: 
catch2/catch.hpp: No such file or directory

> > 22 | #include 
> > | ^~
> > compilation terminated.
> > gmake[5]: *** [test/CMakeFiles/self_test.dir/build.make:79: 
test/CMakeFiles/self_test.dir/compiling_tests.cpp.o] Error 1

> > gmake[5]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> > gmake[4]: *** [CMakeFiles/Makefile2:103: 
test/CMakeFiles/self_test.dir/all] Error 2

> > gmake[4]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> > gmake[3]: *** [CMakeFiles/Makefile2:110: 
test/CMakeFiles/self_test.dir/rule] Error 2

> > gmake[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> > gmake[2]: *** [Makefile:172: self_test] Error 2
> > gmake[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> >
> > make[1]: *** [debian/rules:16: execute_after_dh_auto_build] Error 2
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2023/10/27/trompeloeil-cpp_44-1_unstable.log
>
> All bugs filed during this archive rebuild are listed at:
> 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20231027;users=lu...@debian.org

> or:
> 
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20231027=lu...@debian.org=1=1=1=1#results

>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to 
contribute!

>
> If you reassign this bug to another package, please mark it as 
'affects'-ing

> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it 
with mine

> so that we can identify if something relevant changed in the meantime.
>

>


Control: forwarded -1 https://github.com/rollbear/trompeloeil/issues/321

Control: tags -1 confirmed

Hi Lucas,

This was caused by the recent upload of catch2 to the 3.x release track. 
The header name changed so naturally the build fails now.


Patching in catch2_all.hpp compiles but does fail to run to the tests. I 
asked upstream to support catch 3.x (see issue).



best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050185: (no subject)

[Matthias Geiger]

Version: 0.12.0-1

Closing since this got fixed by the darling 0.14 semver packages.

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050185: rust-derive-builder-core - depends on old version of darling

[Matthias Geiger]

I take it this can be closed now that the semver packages were uploaded ?

Bug#1036076: rust-mysqlclient-sys appears to be unsound when used with mariadb.

[Matthias Geiger]

On Mon, 15 May 2023 05:47:10 +0100 Peter Green  wrote:
> Package: rust-mysqlclient-sys
> Severity: serious
>
> I was looking at why rust-diesel was not migrating to testing
> (other than the freeze obviously) and noticed that rust-mysqlclient-sys
> was not built on 32-bit architectures. As with a bunch of other
> packages I correctly suspected this was mostly a case of unportable
> bindgen-generated tests and started preparing fixes for them.
>
> However while doing so, I rapidly came to the conclusion that something
> else was wrong. Specifically I noticed significant discrepancies
> between the "mysql" (actually mariadb) C headers on my system and the
> rust bindings in rust-mysqlclient-sys.
>
> The tests in the crate only test that the size/alignment of the
> structures defined in the crate are consistent with what they were
> when the bindings were generated. They do not check in any way that
> they are consistent with the structures defined by the C headers on
> the user's system. There are no functional tests either.
>
> My conclusion is that attempting to use this crate with mariadb
> is highly unsound, though I don't know enough about how the mysql
> client library is used to determine in what way exactly it will break
> and whether the breakage is likely to be immediately apparent or more
> subtle.
>
>

>

Control: severity -1 important

lowering severity so it and rdeps can migrate. I skipped the failing 
tests for now.


--
Matthias Geiger (werdahias)
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036076: rust-mysqlclient-sys appears to be unsound when used with mariadb.

[Matthias Geiger]

On Mon, 15 May 2023 05:47:10 +0100 Peter Green  wrote:
> Package: rust-mysqlclient-sys
> Severity: serious
>
> I was looking at why rust-diesel was not migrating to testing
> (other than the freeze obviously) and noticed that rust-mysqlclient-sys
> was not built on 32-bit architectures. As with a bunch of other
> packages I correctly suspected this was mostly a case of unportable
> bindgen-generated tests and started preparing fixes for them.
>
> However while doing so, I rapidly came to the conclusion that something
> else was wrong. Specifically I noticed significant discrepancies
> between the "mysql" (actually mariadb) C headers on my system and the
> rust bindings in rust-mysqlclient-sys.
>
> The tests in the crate only test that the size/alignment of the
> structures defined in the crate are consistent with what they were
> when the bindings were generated. They do not check in any way that
> they are consistent with the structures defined by the C headers on
> the user's system. There are no functional tests either.
>
> My conclusion is that attempting to use this crate with mariadb
> is highly unsound, though I don't know enough about how the mysql
> client library is used to determine in what way exactly it will break
> and whether the breakage is likely to be immediately apparent or more
> subtle.
>

fwiw, I reported an issue upstream about the failing tests and uploaded 
a version skipping those unblocking diesel and rdeps.


best,

--
Matthias Geiger (werdahias)
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038135: rust-diesel: librust-diesel-dev uninstallable on 32-bit archs

[Matthias Geiger]

On Thu, 15 Jun 2023 13:32:41 -0700 Steve Langasek 
 wrote:

> Package: rust-diesel
> Version: 2.0.3-1
> Severity: serious
> Tags: patch
> Justification: uninstallable
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu mantic ubuntu-patch
>
> Dear maintainers,
>
> rust-diesel is not migrating to Debian testing because it depends on
> librust-pq-sys-dev and librust-mysqlclient-sys-dev, neither of which is
> buildable on 32-bit archs; but it does not build-depend on these 
packages,

> so librust-diesel-dev builds uninstallable binary packages.
>
> Either rust-diesel should build-depend on these packages so that binaries
> are not built on architectures where they're unavailable, or the
> dependencies should be relaxed so that the packages are installable.
>
> For the moment, I've opted for the first of these in Ubuntu. See attached
> patch.
>


I just uploaded a proper version of mysqlclient-sys where the failing 
bindgen tests are skipped for now.


I'll do the same for pq-sys; that should make it and dependent packages 
build/installable.


best,

werdahias

Bug#1050299: [Pkg-rust-maintainers] Bug#1050299: rust-webpki: RUSTSEC-2023-0052

[Matthias Geiger]

On Sat, 9 Sep 2023 09:16:55 +0300 Michael Tokarev  wrote:
> 09.09.2023 03:07, Peter Green:
>
> > async-tls has not switched upstream. On the other hand I don't
> > see any packages in Debian using it yet. ccing mjt to see what
> > the reason for packaging it was.
>
> async-tls isn't my baby, count_omega (=werdahias, Cc'd) asked to 
sponsor it

> on Jun-28 and I uploaded it, that's all.
>
> Thanks,
>
> /mjt
>
>

A pull request was opened upstream:https://github.com/async-rs/async-tls/pull/54
I packaged async-tls as it's a dependecy of magic-wormhole-rs  (which is needed 
for warp which I ITP'd).

best,

--
Matthias Geiger (werdahias)
Debian Maintainer



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1042921: glib log feature

[Matthias Geiger]

Hi Jonas.

Sorry, I patched out the log dependency (and subsequent features) 
absentminded.


A fixed version is uploaded and should hit the buildds / archive soon.


regards

Matthias



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1042916: Unsatisfiable build-dependency on gtk4 0.16

[Matthias Geiger]

Package: helvum
Severity: grave
Justification: renders package installable
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Jonas.

Yesterday I uploaded the new gtk-rs release which makes helvum uninstallable
as it depends on the no longer present 0.16 versions of the gtk-rs
libraries. The fix is simple, just dropping 2001_gtk.patch should
suffice. Please look into this as it blocks testing migration for gtk-rs
otherwise. 

Thanks,

Matthias

- -- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.2-surface (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
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 helvum depends on:
ii  libc62.36-9
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.76.3-1
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-4-1   4.10.3+ds-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpipewire-0.3-00.3.65-3

helvum recommends no packages.

helvum suggests no packages.

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmTKqk0VHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1yMsP9jRViLwDlXoyVxq5wSvWpVB1honZ
TqyTaPVWhjYsEZsWftKjeGWEv1Mf5cHy5A6d9rhXlIj7QIcGRKv9ss3SevQLplL8
7LwPBdQ/TIsPvNBhaHt8tOnTJlqWXT2uyVwHidjcE+UcIYN/QGW51UY2dpPPq4WS
0Qp3UTL8EvyYF0omjQ8/Gdaj7ufNKdcLsCPOMijRkGq2zcU9mIbY4a3lD/xiY4X4
NMD1GtqbFcZF1ND/FrzTQqD0Q8je0NBJzo9TJR2M1mF6ozkZjuM2ZgoVZEGwUWhl
o9kp5+69JxwAhOubPMi29TDpILHiKJfWKDph2S7I1APcjyvLBlCifDhpXVuEu6QA
rH10KWChI6j1nQ6PlcXjfD1fAnfqPLckACm2lkyLejDT3LzTjjQM1dmETepRN7h+
5Ibjxwj5+yIf0gsckru5Lj4VkMi9HRCh86TEvcG1BaS9oz0oir0CcNdw8Ytrnqrn
6+n8p257OBVCfwvLh4dQm0cJ7GyjIF6ojrM7ju0a54jASpA052PCxMM29wgC6riW
jj6weVhryZhdRlk9CJVE0GGMWhy7NjggUL7dQvoF18hevms5om0HHdMIU2uy49zg
dthnaYMLOESW9UlHV564KM/Tz1A7t0vDBdDEvHRjDBVsalu7j09CW/P1urYz3lO9
BU6yB9Q8g+5cMek=
=1f89
-END PGP SIGNATURE-

Bug#1041260: wike ftbfs

[Matthias Geiger]

Hi Sebastian,

this happened due to an untimely upload of mine. The required libadwaita 
(1.3) is already in experimental; according to the GNOME team they won't 
upload it until after the bookworm 12.1


update. For now all we can do is wait.

cheers

--
Matthias Geiger (werdahias)


OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#993849: authenticator

[Matthias Geiger]

> If someone wants to help, feel contribute in the debian-rust team.

I meant feel free :)

---

Matthias Geiger



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#993849: RE. authenticator

[Matthias Geiger]

I uploaded the rust-gtk stack into debian which was the major missing 
chunk. If my tracking spreadsheet is correct (rust) authenticator is 
still missing five crates:


scrypt, search-provider, libadwaita, gst-plugin-gtk4 and aes-gcm. Some 
of them have more reverse dependencies. I haven't looked into it further 
and I'm a bit busy atm.


If bug #1017905 gets resolved libadwaita can enter debian; this is being 
worked on by myself and jbicha. The rest of the dependencies look 
straightforward to tackle.



If someone wants to help, feel contribute in the debian-rust team. The 
"new" application should go under the gnome teams' umbrella imho.



regards,


Matthias Geiger





OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038242: Does not build against gtk 0.5

[Matthias Geiger]

Package: rust-ashpd
Severity: serious
Tags: trixie sid
X-Debbugs-Cc: jbi...@debian.org, matthias.geiger1...@tutanota.de

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

ashpd in its current version in unstable and testing does not build against the 
newer gtk-rs prepared in experimental.
The newer upstream does also not build against that; it needs gtk 0.6 which 
will be uploaded after 0.5.
This is a blocking bug so the gtk-rs stack can migrate once I upload them to 
unstable.

regards, 

werdahias


- -- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.3-surface (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
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

-BEGIN PGP SIGNATURE-

iQJUBAEBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmSMqCIgHG1hdHRoaWFz
LmdlaWdlcjEwMjRAdHV0YW5vdGEuZGUACgkQGL0QaztsVHXedg/+N+y7MZp1sOhT
bc5iWIs644CxE8QWviRXzaD8O4SEOF/9utzd+z6R8M6j2Ph8WjMUo3K8PgsfJtX0
/pCcd1SENF2GIFoHz9dH1hKA6oiiWTe0r+MrdN/PBGGIFjjU9nTO6gfRVsPI9s9r
mOrOvab1+fQSuamVclPhnmw5M+RFQRYpKULMzu+KMPFlCQuoQ3RFuXfoYT4PIHdo
8cSjjzw0edBF5jpgGKlLw1bn9itS8keyFd8LQ8bv0dVLuryveuBwIBDCyXz7WieD
7pjYS5oW0SNu9HGYn9yUO9tuh9URtgWyoghcyo/q/Z1GwIEWOKDV2eIHLFrY3ste
8GgTD4wirY4BOKjWo1E+qpJt5nSIjq3Y+0SM/iHVFOG+O9ZJdOk29VVWX0PRsT/R
OM3KeMBmPmhDxlCHGliio8l92WES7WOfXGYY3hCHZ4k5wEyV4NfqWmgEicmY4bON
V02zaz/hXSXlv4SPV1dUDvG43i9sWhmapy9h3CjL20plTZDnmZrXjWIuuSZc2PaE
X8R023x3MRGzxDiN6LyFWVUAzhzAxu8aWnnriABlqZ76pO8N9zATnK8oE9QALo49
AmkjsNCghsgCf+1JWU4ztEn94TlMFW+Oqeaa7/aVWgA6pSiaoiePmcDiGoPaYXDW
77WCaZ8IcHGkkRy9iyNr+lXEQqiP610=
=hiH5
-END PGP SIGNATURE-