Thunderbird broken?

stpr commented

2023-05-09 02:39:34 +02:00

I have had some issues with thunderbird recently as the non-x86-64v3 version was breaking existing install (botan2 conflict). I noted in the package status that thunderbird build was delayed because waiting for nodejs==20.1.0-1, but seems like that nodejs build was skipped. The base arch was likely built without it as 20.1.0 is in testing and not in the main repos yet. I was wondering why this is being stalled? Is this a bug or an actual requirement for the optimised builds for thunderbird?

I have had some issues with thunderbird recently as the non-x86-64v3 version was breaking existing install (botan2 conflict). I noted in the package status that thunderbird build was delayed because `waiting for nodejs==20.1.0-1`, but seems like that nodejs build was skipped. The base arch was likely built without it as `20.1.0` is in testing and not in the main repos yet. I was wondering why this is being stalled? Is this a bug or an actual requirement for the optimised builds for thunderbird?

anonfunc commented

2023-05-09 14:00:27 +02:00

Owner

It's a bug, sort of. This happens (as it recently happened with a few dozen python packages) when Arch packagers copy the testing/staging version not only to the testing/staging, but also to their respective non-testing/non-staging folder as well. I'm not quite sure if this is a limitation of their packaging toolkit (rather unlikely) or if its just "user error".

So the situation (in the case of nodejs) is: ALHP is looking at community-x86_64 in https://github.com/archlinux/svntogit-community/tree/packages/nodejs/repos, and compares the version it finds in there with the version on the mirror, to not build packages before their respective dependencies are actually available and up-to-date on the mirror ALHP is syncing from. But, since in this case the testing version was already copied over to the non-testing community-x86_64, but hasn't actually released yet, ALHP is waiting for 20.1.0-1 to show up.

Fixing this is tricky, since ALHP needs a mechanism to determine if a package is actually released and just not on its mirror yet (and I do not want to 'hammer' archweb for it). It's fixable, but as infrequently as it happens I just ignored it.

EDIT: Btw, ALHP is not the only project that is affected by this. I have also seen this exact same problem happening on ALARM, when they release testing versions of packages wrongly copied into the non-testing one (like what is happening with nodejs here) into their normal core/extra/community.

It's a bug, sort of. This happens (as it recently happened with a few dozen python packages) when Arch packagers copy the testing/staging version not only to the testing/staging, but also to their respective non-testing/non-staging folder as well. I'm not quite sure if this is a limitation of their packaging toolkit (rather unlikely) or if its just "user error". So the situation (in the case of `nodejs`) is: ALHP is looking at `community-x86_64` in https://github.com/archlinux/svntogit-community/tree/packages/nodejs/repos, and compares the version it finds in there with the version on the mirror, to not build packages before their respective dependencies are actually available and up-to-date on the mirror ALHP is syncing from. But, since in this case the testing version was already copied over to the non-testing `community-x86_64`, but hasn't actually released yet, ALHP is waiting for `20.1.0-1` to show up. Fixing this is tricky, since ALHP needs a mechanism to determine if a package is actually released and just not on its mirror yet (and I do not want to 'hammer' archweb for it). It's fixable, but as infrequently as it happens I just ignored it. *EDIT*: Btw, ALHP is not the only project that is affected by this. I have also seen this exact same problem happening on ALARM, when they release testing versions of packages wrongly copied into the non-testing one (like what is happening with nodejs here) into their normal core/extra/community.

👍 1