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

[Timo Paulssen]

Hi List, hi Dominique,

On 10/15/24 18:14, Dominique Dumont wrote:
> 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.

Especially if we patch rakudo, the compiler id definitely has to change. 
The way precompilation works forces us to invalidate precompiled files 
relatively aggressively. The reason the compiler ID changes "too much" 
is to give an earlier exit from a bad situation instead of object 
indices into the serialized blobs becoming misaligned.

MoarVM precompilation is a lot more in-depth than for example python, 
where the result of precompilation is not much more than the result of 
the parsing stage serialized. This is among other things necessary to 
properly support things like "augment".

Unfortunately, we currently don't generate the same results from 
compiling the same source twice in a row in the context of rakudo 
itself. I think it's more than just a different compiler ID being put 
in, but a real difference that needs a change somewhere inside rakudo's 
internals.

I have a prototype for a "dump everything, categorized" flag for moarvm, 
plus a corresponding patch that adds dumping of moarvm files to 
diffoscope, and I will look into this topic more.

>> 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.
OK, I was not sure if the "autorm" going through would put us in a 
situation where we would have to go through a more elaborate process if 
we want the packages to get back in.
>> 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.
Cool, so it's correct to have it in debian/sid like I'm already doing, 
and we're already well on the way to reaching this goal?
>> 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 ?

OK, I'm not sure how exactly I messed that up, but it's correct now. I 
did have some trouble with dh-make-raku initially, but I think I've got 
the hang of it now.

I have a small merge request for dh-make-raku in salsa BTW if you'd like 
to have a look at 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).
I'm not 100% confident that uploading will fix the bugs 
properly. Can you guide me through figuring out how exactly to reproduce 
the FTBFS bugs for the individual packages and how to make sure what we 
do actually fixes the bugs.
>> 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.
I should probably contact Santiago Vila about this. I'm not sure if it's 
fine to push all the burden of figuring out what the best solution 
should be away from myself onto a DD who is surely already busy enough ...
>> The cause for it is kind of
>> "ethereal" or "environmental".
> That does not fill me with confidence 😆
That's what I'm referring to when I say I'm not certain about the bugs 
getting fixed :)It depends on more than just the version of one package. 
Or something like that.
>> 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

I've seen a giveback link somewhere, I think the buildd interface, but 
with just a salsa account I can't request them myself. I would need a 
Debian SSO Client Certificate, which are no longer given out AIUI.

So you will have to do that part, or I pester the good people of 
#debian-mentors on IRC :)

If I'm not mistaken, I have nothing else to do right now for at least 
this situation. I will wait for you to tell me what I should do next :)

Thanks!
   - Timo