Re: gdb and ancient GNU autotools

[Eli Schwartz via Gdb <gdb@sourceware.org>]

[-- Attachment #1.1.1: Type: text/plain, Size: 9298 bytes --]

On 2/24/24 7:22 PM, Tomasz Kłoczko wrote:
> 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


Can we not, please? The GNU project is not being fascist, regardless of
any throttling settings.


> which is b*dy easy to exceed.


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.



> 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?


> 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.


Okay, now this I am genuinely fascinated by and would like to hear more
about.

- This is not about github or gitlab, it's just a native git feature.
  gitweb and cgit support it too.

- Verifying a signature on a patch file should be impossible, since:
  a) the original signature is not signing a patch file
  b) patch files frequently change their bytes as a reaction to:
    - git version running on the server to produce the patch
    - size of git repo changing the hash abbrev minimum

- git signed commits, even if verified, contain a cryptographic strength
  of: sha1. In general, distros have been moving to the use of sha256 or
  blake2 due to well publicized weaknesses in sha1 that indicate that
  even if there is no known attack that affects git specifically, the
  time is coming and we won't necessarily know when it is here.


> 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?🤔


The main topic is a rant about how GDB but actually the several projects
sharing the same build system, do NOT have the resources right at this
second to update the Autoconf in use, from:
- autoconf 2.69 (the latest version as of December 2020)

to:
- autoconf 2.72 (the latest version as of February 2024)


Given that it is apparently challenging to find the resources to perform
a relatively minor facelift to an existing build system, I am quite
shocked that you think there are resources to throw out the entire build
system and rewrite it from ground zero in meson.

However, GDB is Free / Libre and Open Source Software, and in the finest
spirit of FLOSS, I would like to remind you, that:

patches

are welcome

to rewrite binutils, gcc, and gdb in meson.

Aside: the Meson WrapDB would also welcome contribution of such a
rewrite, even a partial one, as it provides a useful functionality to
people that need to depend on binutils libraries. Might be a good place
to test a work-in-progress port, even. ;)


Thank you! And have a very nice day. :)


-- 
Eli Schwartz

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 18399 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]