Fwd: Incoming Debian freeze

[Timo Paulssen]

Hey Dominique, Hi List,

On 1/13/25 10:30, Dominique Dumont wrote:
> Hi
>
> On Sunday 12 January 2025 17:04:34 CET you wrote:
>> I received a message that mailly.debian.org couldn't send this mail to
>> your free.fr account.
> This is weird. Moreover, your mail was not sent to pkg-rakudo-devel list. So
> there may be an issue between your mail server and Debian's mail server.

I think that's only in the mail I forwarded to you. I can see my mail on 
the mailing list archive.


>> Is it an option at all to skip the arches where we get freezes?

I have good news! I have a patch that uses memory fencing when writing, 
and atomic loads when reading, and I've run it for around 16 hours 
without triggering the issue. The issue makes sense when interpreted 
from a "you didn't make sure the changes arrive on other cores in the 
right order" standpoint, and the solution should be correct, too.

Is it better to apply it to 2024.09 and concentrate on getting that all 
through, or would it be wiser to try packaging 2024.12? Right now I'm at 
the start of a little respiratory viral infection (apparently not the 
big one) so I have to assume this week, maybe next week, I won't be able 
to do anything that requires much concentration. In that case, 2024.09 
with a little patch may be better.


>> I have also not yet had the time to check what exactly the current
>> problem with FTBFS from the "outdated or wrong version of dependency"
>> issue is.
>>
>> My last status was that after the transition, everything should have
>> been fixed.
>> Did we perhaps forget to kick off rebuild attempts?
> AFAIR, everything was rebuilt during the transition. Then the problem with
> build hang showed up and was reported as a serious bug. This triggered a
> removal or rakudo and its dependencies from testing.

I do see a couple of packages blocked by the FTBFS bug, so I think I 
need to go through these bugs and send a mail to mark them as resolved. 
I am not exactly sure how, though. Can I mark them as "fixed by the 
transition we did"? Does it require a "fixed in version XYZ"? Because 
there's not really "a version that is broken" vs "a version where it's 
fixed" for these packages.

>> Or did I need to mark all the relevant FTBFS bugs as "resolved"?
> Difficult to say it that's a problem due to the build hang issue.
>
> Let's first restrict rakudo to build on architectures known to work. What are
> they ?
>
> Then we will be able to check what's going on with module builds.

Glad to say I believe the build hang issue is resolvable through just a 
patch to moarvm, it shouldn't even require an upgrade to nqp and rakudo, 
except if it's required to increase the dependency in nqp to require the 
new moarvm, and the dependency in rakudo to require that new nqp.

It would be enough to only do these for the arches arm64 and armhf.

I am not sure what the options are for "only new versions on some 
arches", or if it doesn't matter and we just submit a new source package 
with a patch applied and the rest happens by itself?

Thanks!
   - Timo