Re: gdb and ancient GNU autotools

["Tomasz Kłoczko via Gdb" <gdb@sourceware.org>]

On Sat, 24 Feb 2024 at 19:31, Mark Wielaard <mark@klomp.org> wrote:
[..]

> How exactly are you downloading the patches? You really should not
> download them through the gitweb interface. Please just use git,
> either over https or git.


In both cases content is served by http server.

Or if you really want to use a web interface
> please use the cgit interface at https://sourceware.org/cgit/ which is
> much faster than the gitweb interface. If you do have trouble doing
> checkouts for your automated builds and are worried that your
> connection is trapped in a fail2ban jail please reach out so we can
> investigate. https://sourceware.org/mission.html#organization


That cgit interface content is served by the same web server which is
throttling the rate of the requests.

OK I'll give you the full picture ..to show how deep that rabbit hole is.
FYI: I'm doin that because in rpm spec file is possible to specify
something like below:

Name:           mate-utils
Version:        1.28.0
Release:        2%{?dist}
License:        GPL-3.0-or-later (
https://spdx.org/licenses/GPL-3.0-or-later.htm), LGPL-2.0-or-later (
https://spdx.org/licenses/LGPL-2.0-or-later.html)
URL:            https://mate-desktop.org/
VCS:            https://github.com/mate-desktop/mate-utils/
Source:         https://pub.mate-desktop.org/releases/%(v=%{version}; echo
${v%.*})/%{name}-%{version}.tar.xz
Patch:
 %{VCS}/pull/363.patch#/%{name}-build-mate-dictionary-loadable-module-as-not-versioned-DSO.patch

Or other example:

Name:           gsettings-desktop-schemas
Version:        46.beta
Release:        3%{?dist}
License:        LGPL-2.1-or-later (
https://spdx.org/licenses/LGPL-2.1-or-later.html)
URL:            https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/
VCS:            https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/
Source:
https://download.gnome.org/sources/gsettings-desktop-schemas/%(v=%{version};
echo ${v/.*/})/%{name}-%{version}.tar.xz
Patch:
 %{VCS}/commit/3537f5ab.patch#/%{name}-Update-Georgian-translation.patch
Patch:
 %{VCS}/commit/ea06d947.patch#/%{name}-Update-Turkish-translation.patch
Patch:
 %{VCS}/commit/b3ebfbc4.patch#/%{name}-Update-Ukrainian-translation.patch
Patch:
 %{VCS}/commit/9c7a53ed.patch#/%{name}-Update-Czech-translation.patch
Patch:
 %{VCS}/commit/cb370919.patch#/%{name}-Update-Hebrew-translation.patch
Patch:
 %{VCS}/commit/7c7a2136.patch#/%{name}-Update-Norwegian-Bokm-l-translation.patch
Patch:
 %{VCS}/commit/63869de8.patch#/%{name}-Update-Turkish-translation-1.patch
Patch:
 %{VCS}/commit/7e238e6c.patch#/%{name}-Update-Slovenian-translation.patch
Patch:
 %{VCS}/commit/aa2d88f0.patch#/%{name}-Change-default-clock-format-back-to-24h-for-non-US-l.patch
Patch:
 %{VCS}/commit/9c9d4c89.patch#/%{name}-Update-Persian-translation.patch
Patch:
 %{VCS}/commit/5e674865.patch#/%{name}-Update-Persian-translation-1.patch
Patch:
 %{VCS}/commit/10aa69e8.patch#/%{name}-Update-Ukrainian-translation-1.patch
Patch:
 %{VCS}/commit/57282960.patch#/%{name}-Update-Hebrew-translation=1.patch
Patch:
 %{VCS}/commit/dd6b6341.patch#/%{name}-Update-Indonesian-translation-1.patch
Patch:
 %{VCS}/commit/63264176.patch#/%{name}-Update-Slovenian-translation-1.patch
Patch:
 %{VCS}/commit/f36769de.patch#/%{name}-Update-Turkish-translation-2.patch
Patch:
 %{VCS}/commit/0ddb6985.patch#/%{name}-Update-Galician-translation.patch
Patch:
 %{VCS}/commit/4d67a8a5.patch#/%{name}-Update-Basque-translation.patch
Patch:
 %{VCS}/commit/04ffad13.patch#/%{name}-Update-Occitan-translation.patch

Which allows me easy integrate patches taken from commits added after
release %{version} directly over VCS REST interface.

For example elfutils or dwz quite often after release in some commits are
fixing some important issues and maintainers are not willing to release new
version ASP.

Simple 'rpmbuild -bs -D "_disable_source_fetch 0"
gsettings-desktop-schemas.spec --clean --rmsource --rmspec --nodeps' allows
quickly form src.rpm on the system which has access to the public network
which in next step is sent to the prod build env spawned only to build
single package which is cut off from access to the public network.
If that list of patches downloaded over VCS URLs is long enough it exceeds
the throttled rate and .. some patches are not downloaded.

Web server serving web content of the https://sourceware.org/git/ is ONLY
known to me such a server which has such throttling.
Literally NONE of other places with VCS REST interfaces are using such
fascist settings .. IIRC that throttling is something like 25-30 per MINUTE
which is b*dy easy to exceed.

Some samples of use such technique from my packages:

[tkloczko@pers-jacek SPECS]$ grep Patch:.*VCS *spec -c | sort -t: -nk 2 |
tail -n 5
mdadm.spec:125
groff.spec:129
qt5-qtbase.spec:148
libiscsi.spec:187
libimobiledevice.spec:190

And yet another stat ..

[tkloczko@pers-jacek SPECS]$ ls -1 *spec | wc -l; grep Patch:.*VCS *spec|
wc -l
4829
5829

In other words: avg it is more than one VCS based patch taken out of some
commits *per package* in that +4.8k packages population.

As you see I'm using that on a massive scale. With any other VCS REST
interfaces there is no ANY problem .. except with
https://sourceware.org/git/ and I'm using different VCSess in case of +90%
of all my packages

[tkloczko@pers-jacek SPECS]$ grep ^VCS: *spec| wc -l
4444

.. and that VCS: field sits in each of those specs files to be instantly
used if it is needed.
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.

If you may be thinking about security aspects of downloading all those
patches in the batch mode .. github and gitlab allow you to sign commits or
git tags.
On downloading patches out of commits it is possible to verify
those signatures (it takes one line of POSIX sh script to do that).
Percentage of projects especially on github in recent months which
are using signet commits started going up.

Do I need to mention that cgit from https://sourceware.org/git/ do not
offer such additional functionality and will probably never be able to do
that?🤔

---
Any comments about the main topic?🤔

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH