rust-event-listener's --no-default-features autopkgtest is failing:

https://ci.debian.net/packages/r/rust-event-listener/unstable/amd64/

This issue will block the rust-event-listener transition. I suggest
marking the autopkgtest as flaky and reporting the issue upstream.

Thank you,
Jeremy Bícha

Simple patch attached.

Thank you,
Jeremy Bícha

Quoting Jeremy Bícha (2024-04-21 19:47:08)
the upstream bugs recently tracked upstream, which might in Debian be
affected by relaxed dependencies e.g. on concurrent-queue.

 - Jonas

On Mon, 10 Jun 2024 11:17:04 +0200 Jonas Smedegaard <jonas@jones.dk> 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

Quoting Matthias Geiger (2024-06-18 15:18:17)

Not sure what you mean.

This bug affects only event-listener in experimental, which will never
transition anywhere. So the concern raised is only for the situation when
event-listener gets released to unstable - which requires all involved
packages to be in sync and buildable at all, and only then does it make
sense to me to check if this instability persists.

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

* async-channel
* async-process (awaits new crate async-signal)
* async-std (awaits async-process)
* blocking
* criterion (awaits smol)
* criterion-0.3 (awaits smol)
* fs4 (awaits smol)
* if-watch (awaits smol)
* isahc
* sluice
* smol
* zbus

 - Jonas

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

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
    <https://bugs.debian.org/1074107>
* async-global-executor
  * needs to accept async-channel v2 at least in experimental
    <https://bugs.debian.org/1074067>
    <https://bugs.debian.org/1074114>
  * 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
    <https://bugs.debian.org/1074107>
  * 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.

Kind regards,

 - Jonas

23.06.2024 17:11:51 Jonas Smedegaard <js@debian.org>:
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 yet. Thanks for the
bugreports, I expect to stage everything tomorrow (to exp). In case I
don't run into any issues I'd gladly start the transition after this.

Kind regards,

werdahias

Quoting Matthias Geiger (2024-06-23 20:20:59)

I didn't mean that maintenance work was sloppy, but that the packaging
*style* is sloppy, requiring you to do autopkgtesting.

When did you test?  Because the related packages have changed until I
posted that email.

Sounds good.

 - Jonas

done.
done.
done.
done.
does not build with async-channel 2.x easily. will look into getting it
patched.

done, thanks to plugwash.

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


best,


werdahias

Quoting Matthias Geiger (2024-06-25 23:15:58)

Great!

I am still fighting with async-std and if-watch but am optimistic (and I
have given up on isahc for different reasons).

Please post here when you consider sluice ready, then I will do the same
for async-std and if-watch - and when all 3 are ready I suggest that we
simply begin the re-release to unstable as much parallel as possible.

Thanks for the help!

 - Jonas

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

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:

* 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
* event-listener
  * involves branch transition: v2 -> v5
  * v5.3.1 succeeds build-time testsuite in experimental
* if-watch
  * v3.2.0 accepts smol v1+2 in unstable
  * v3.2.0 succeeds build-time testsuite and autopkgtests in unstable
* 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
  * v2.0.0 succeeds build-time testsuite in experimental

DONE but awaits testing:

* async-std
  * v1.12.0 accepts async-channel v1+2 in unstable
  * v1.12.0 accepts async-lock v2+3 in unstable
  * v1.12.0 accepts async-process v1+2 in unstable
  * needs to succeed build-time testsuite and autopkgtests in unstable

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-global-executor
  * needs to accept async-channel v2 at least in experimental
    <https://bugs.debian.org/1074067>
    <https://bugs.debian.org/1074114>
  * 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
* 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
* sluice
  * needs to accept async-channel v2 at least in experimental
  * needs custom testing: package lacks build-time testing
* sqlx-core
  * v0.7.3 accepts event-listener v5 in experimental
  * needs custom testing: package lacks build-time testing
* zbus
  * needs to accept event-listener v5 at least in experimental
  * needs custom testing: package lacks build-time testing

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,

 - Jonas

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

Thanks :)

best,

werdahias

Quoting Matthias Geiger (2024-07-06 18:49:23)

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?!?

Kind regards,

 - Jonas

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.

best,

werdahias

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

Makes great sense.

 - Jonas

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

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

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

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*?

 - Jonas

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

Quoting Matthias Geiger (2024-07-13 17:52:09)
when that action is done (not at some timeslot).

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

 - Jonas

If you weren't aware, https://github.com/containers/netavark/pull/1025 may help
you speed up a bit.

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


best,


werdahias

Quoting Matthias Geiger (2024-07-14 14:23:31)

Great. Going ahead now!

 - Jonas

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
    <https://bugs.debian.org/1074067>
    <https://bugs.debian.org/1074114>
  * 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

BROKEN for different reasons

* isahc
  * needs to accept async-channel v2
  * needs to accept event-listener v5
  * broken

 - Jonas

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

By the way, rust-event-listener's autopkgtest is failing in Unstable
now, which is why I originally filed this bug.

https://tracker.debian.org/pkg/rust-event-listener

Jeremy

Quoting Jeremy Bícha (2024-07-15 01:03:27)

In future, it would be helpful if you could please elaborate a bit:
Reporting "it fails" and then a month later "it fails again" make it
sound like "ahaaaa, there's a pattern there" when really there is too
little to correlate.

The cause for the old bug is likely gone by now, so I will close this
bugreport now.

If you suspect that the same bug which caused the original issue has
re-emerged, then please provide more detail about what happened back
then and now.

For treating this as a new independent issue, feel free to file a new
bugreport - but I suggest to wait a day before doing so, as I am on it
already, but that's your call.

Kind regards,

 - Jonas