Re: gdb and ancient GNU autotools

Hi,

On Sun, Feb 25, 2024 at 03:05:54AM -0500, Eli Schwartz wrote:
> On 2/24/24 7:22 PM, Tomasz Kłoczko wrote:
> Although really you should not be repeating this work. Why does every
> other distro not have the problem you are having? Most likely because
> they have spent the last few decades trying to figure out how to make it
> NOT be a problem, and eventually came up with an intriguing technology
> called:
> 
> downloading it once.
> 
> And saving it.
> 
> - Alongside the build recipe (Arch, Debian, Fedora, Gentoo, Void)
> - in a "lookaside cache" / distro mirror site (Fedora, Gentoo, Void)
> - in /var/cache/PM-source-distfiles (Arch, Gentoo, Void)
> 
> You should consider doing the same. It's not that complicated, there is
> already rpm tooling to do it! Provably so since Fedora does it.

I think it should in theory work, if it really doesn't, then we should
figure out why. I assume it is because the original poster is using
the gitweb interface over https at https://sourcware.org/git/ to
download individual files or diffs, which is known to not be the most
efficient way of fetching the sources. Instead of using the git https
interface. If so, it should be solved by using actually using the git
https backends or switching to the cgit interface at
https://sourceware.org/cgit/

But yes, having a cache certainly helps.

Note that all of sourceware repos are also in the
https://www.softwareheritage.org/ project. And that if you like a
forge like interface you can also use the sourcehut mirrors at
https://sr.ht/~sourceware/ It might be another good fallback if you do
have issues with the main sourceware git servers.

> > Above technique glued with some one line generator which generates those
> > Patch: lines allows me to save TONS of time to keep updated packages
> > downloading all of what is needed in *seconds* ..
> > Some packages only to test them in advance are using gitlab/github email
> > notifications processed over procmail to test build after EACH commit made
> > by maintainers (+ batch of tests to check that produced packages are still
> > OK and warn me over zabbix that something is wrong).
> > Above gives the best possible VISIBILITY of what has been changed in all
> > those commits as well (you can use for that for example mc to manually
> > check what has been changed in each commit .. offline).
> > Instead of chasing bugs using git bisect it is easier to have an instant
> > signal that after commit <hash> something went wrong.
> 
> ... so you've invented a new Linux distro called DDoS Linux?
> 
> Are we supposed to clap now?

Please don't be sarcastic. We do the exact same thing with our CI at
https://builder.sourceware.org/ which gets new commits all the time
sometimes fetching code for 20 builders at a time in parallel from
different machines. So it is known to work. We aren't DDoSing
ourselves. So we just have to figure out why it doesn't seem to work
for Tomasz.

Cheers,

Mark