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 Tuesday, 15 October 2024 22:56:24 CEST Timo Paulssen wrote:
> 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.

ok, then we'll have to decide the best course on a case by case basis.

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

ok.

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

Yes. One hurdle to cleat is that I made the mistake of trying to use prove6 to 
run non-regression tests during build. This leads to circular dependencies 
when building, which is a problem.

Some package were switched to use Perl's prove, like raku-tap-harness. Could 
you check that all other modules are not depending on prove6 ?

> > There's an issue with raku-json-class: the upstream changes should be
> > brought
> > by merging upstream branch. 
> > 
> > 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.

ok. The git history looks good now. I've tried to build it., but the build 
fails on precompilation issues with rakudo 2022 and missing dependencies with 
rakudo 2024. I guess that can be fixed by uploading rakudo 2024 to unstable. 
But I do not know if all raku modules will be built correctly.

> I have a small merge request for dh-make-raku in salsa BTW if you'd like
> to have a look at that :)

Merged via git and uploaded. Thanks for the patch.

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

The first way is to compile your package locally with the same dependencies as 
the build server using package installed from Debian repository. Do not use 
package that you built yourself because you might not see compiler Id issue.

If that does not work, the other tricks depend on the FTBS error.

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

That would be preferable...

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

Right. I will push that button when needed.

> 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 :)

- remove prove6 dependencies from all raku modules
- upload modified packages (me)
- trigger rakudo transition (me)

Then we'll see the next steps.

All the best