What's the right approach to the autoremove we currently have? Plus: json-class and json-meta6 ready for review / upload

[Dominique Dumont]

Hi

On Monday, 14 October 2024 18:09:01 CEST Timo Paulssen wrote:
> The rakudo package has seen an upload of version 2022.12-1.1, which I
> think is what introduced the new precompiled versions of built-ins (like
> the v6c.bootstrap that's mentioned in the error message).

From my point of view, rakudo's compiler id should not change when rakudo 
packaging is updated. Even if we patch rakudo.  This requires to have a 
reproducible build.

> I think we said we don't want to cause rebuilds of all the packages
> "just" to fix their builds, but when the packages are going to be
> removed from debian if we don't get their FTBFS bugs fixed, I think it
> should be treated a little bit more urgently?

Well, the real deadline is next Debian freeze which should happen next spring.

> If I understand correctly, we were just waiting for a fix to the problem
> meta6 had, which was legit and not just precompilation problems. The
> upstream fixed it in the newer version, which requires a newer version
> of JSON::Class as well.

ok, then we should release a new version of this package. There's no need to 
go through experimental branch to update a module.

> I have pushed commits to the debian/sid branch of both raku-json-class
> and raku-meta6 that should be ready-to-go for releasing packages.

There's an issue with raku-json-class: the upstream changes should be brought 
by merging upstream branch. In the repo we see that upstream change are 
directly applied to debian/sid branch, but I cannot see the merge commit from 
upstream. This should be done by dh-make-raku, but it looks like something 
went wrong.

Can you fix that ?

> I would have gone through a proper merge request workflow, but salsa is
> currently experiencing high load on its background workers, so merge
> requests hang for an extended period of time after creation.

No problem, we can progress with only git.

> I think once these two packages are uploaded to experimental, we should
> be in a good position to upload everything to unstable.

more or less. We can release new or updated raku modules in debian/unstable.

> I hope once we do that, the unstable upload, we can soon move on towards
> testing. We can then mark all the FTBFS bugs "fixed in this version".

This can be done automatically if debian/changelog mentions "(Closes: 
#bugnumber).

> Actually, I'm now thinking that perhaps all the FTBFS bugs should be
> moved to become bugs of the rakudo package? 

Yes. I'm a little fuzzy on the details to avoid getting new bug reports on the 
modules until the FTBS is actually fixed.

> The cause for it is kind of
> "ethereal" or "environmental". 

That does not fill me with confidence 😆

> It will not be a new version of any one
> package that causes it to become fixed, but a new build being uploaded
> for (essentially) the same version - at least the same version of the
> source package.

Yes. I believe the root cause of most FTBS issues is the unexpected changes of 
compiler id. Once this is fixed, we'll have to trigger a build of all raku 
modules. Either manually (with a giveback command or something like), by a 
module update or through a rakudo update (and a transition).

All the best