dev-python/dtfabric-20220219 fails to fetch

[asarubbo]

https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/

Issue: dev-python/dtfabric-20220219 fails to fetch.
Discovered on: amd64 (internal ref: pentoo_tinderbox)
System: GCC-14-SYSTEM (https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#GCC-14)

Info about the issue:
https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#CF0017

At the time of writing, github-cli does not support attachments. I'm using gists but they can be deleted at a certain point. If you want to save them, please create attachments on your own.

build log: https://gist.github.com/asarubbo/1fab18dba28905bb83e1e361c3d677e7
Context of error(s): https://gist.github.com/asarubbo/fb4d83d7cfd64755807b840b2f411cc3

[thinrope]

That is an old issue, ebuild version is no longer in tree and thus should be closed as resolved/invalid or resolved/fixed.

There is new package in my pkalin overlay as well.

[rick-gnous]

The package is still in the tree and can have the issue. No need to close it, even if the version does not match with the current one

[thinrope]

The reason, IMHO, that fetch failed is because the git tag the the ebuild relies upon was removed by upstream while @joachimmetz who maintains lots of DFIR libraries tags them as experimental and only tags them with dates as versions; however every now and then he cleans old tags and for us the upstream seems to disappear.
Adding an extra step: manually coding the commit hash of the tag when it is released may help prevent some of this, assuming no force pushes, but may not be worth it. Mirroring all the sources is another costly/complex solution.

So, when an ebuild fails to fetch, but is no longer in the tree (dtfabric-20220219 was removed via commit 422b848 >1y ago), IMHO, the issue is resolved. <-- this was my reasoning, since this is automated issue by tinderbox

Now that I look closer, under https://github.com/libyal/dtfabric/tags currently there are only two tags: 20260506 and 20251118, yet pentoo-overlay has dev-python/dtfabric-2024021.ebuild that still fails to fetch since the 2024021 tag was removed ...

We can update the subject for that version, or file another issue, something along the lines of "ebuilds based on git tags sometimes fail to fetch when upstream removers the tags", or more generally "ebuilds fail to fetch when upstream withdraws the release" which... is way to broad to be useful.

There are currently 104 packages (some with more than one ebuild version) in pentoo-overlay and 971 packages in gentoo that rely on such versioning, see this command for a list (adjust the cd path maybe):

$ (cd /var/db/repos/pentoo/; find * -type f -name '*.ebuild' |xargs grep -F "SRC_URI" |grep -F archive/refs/tags) |cut -d/ -f1-2 |sort -u

Now, I don't know how often upstream cleans their tags, but I am sure there are more packages affected by this. So the tinderbox found a real problem, instance of a class of problems and now we know the potentially affected ebuilds, what shall we do next?

[rick-gnous]

Now that I look closer, under https://github.com/libyal/dtfabric/tags currently there are only two tags: 20260506 and 20251118, yet pentoo-overlay has dev-python/dtfabric-2024021.ebuild that still fails to fetch since the 2024021 tag was removed ...

as you say, the issue is still here, no need to closed it. However, I can't rename the issue; but the error is the same so that's fine for me

what shall we do next?

follow the updates on repology (the best imho to watch which package is completly outdated), get new maintainers who follow the updates (that's what i try to do but i can't check every package daily), set up a new tinderbox, etc. etc. however, we don't always have time for that (sadly). I don't know what zc or bl want to setup / have time to do too.

I've prepared a PR to close this issue, but it takes time as I check the dependencies AND the packages that depend on it, to check that it doesn't broke anything.