Re: gdb and ancient GNU autotools

[Mark Wielaard <mark@klomp.org>]

Hi Tomasz,

On Sun, Feb 25, 2024 at 12:22:49AM +0000, 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.

But they use different backends, the gitweb interface is very
inefficient, the cgit one is much more efficient.

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

I don't believe it is. If you believe you are seeing throttling when
using the cgit interface could you please report, so we can
investigate what is going on?

> 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

Right. Do you have an example that uses sourceware.org?

If you have seen any issues using the gitweb interface at
https://sourceware.org/git/project.git... you might simply want to
replace them with https://sourceware.org/cgit/project/tree/... If you
have trouble with the transformation we can show you a perl script
that does it automatically.

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

I am not aware of such throttling, except for server load. And as said
above, using the cgit interface would avoid any such server load
issues.

BTW. Please try to be civil, the admins are not fascists. They simply
try to help the community and users make most efficient use of the
resources.

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

Please show some that use sourceware.org, so we can investigate and
see if changing from /git/ to /cgit/ helps your use case.

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

So does sourceware of course. Although not many projects are using
that yet.

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

gitweb sits at https://sourceware.org/git/ (and the plain git https
backend). cgit sits at https://sourceware.org/cgit/ git signing is
independent from the backend used.

An explanation of different ways to sign your git commits (on
sourceware) can be found here:
https://inbox.sourceware.org/overseers/ZJ3Tihvu6GbOb8%2FR@elastic.org/

Cheers,

Mark