From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id jAyjCrfy2mVZ5ysAWB0awg (envelope-from ) for ; Sun, 25 Feb 2024 02:56:39 -0500 Received: by simark.ca (Postfix, from userid 112) id 0F9C01E0D2; Sun, 25 Feb 2024 02:56:39 -0500 (EST) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id E948C1E092 for ; Sun, 25 Feb 2024 02:56:36 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4835E38582A1 for ; Sun, 25 Feb 2024 07:56:36 +0000 (GMT) Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id B42D038582A4 for ; Sun, 25 Feb 2024 07:56:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B42D038582A4 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B42D038582A4 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=45.83.234.184 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708847767; cv=none; b=YsaBVuVgmwmfgy9+t2rfcpuNh646Rqu/Vdyvp0X2Gpb33u4nVzId3CwDC+iw+9l1mOG29JHKtZRMMDrgRgqy2xHGgzpMEJbzc5R4fGFXd3lqQ/lgAvcGvRM5naZnqNex7DNksE8NmLk8KyiwBQrFugQSKWfhjuplZMb1zFLiBXY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708847767; c=relaxed/simple; bh=qJdUvbUEWfTK3ynphAvwVp/F8aoQketCJ2/36xvwq2g=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=iHmprTGY2nb2ZphSZFgSQa57NNCEwxHOHMFX2JZ8PEay7vxbzVNqz+BkOkmaGlH+wL7IAvmSpdzwxiVMQghl/2BeZYJGI0YOLj1RUK5d/OeDQAqkmONKjNhm/E1QQrPbXYtnJPEFQvAdTA4o4GN2+GaryHjoGcgURjfBcT86Qk4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by gnu.wildebeest.org (Postfix, from userid 1000) id C83A83000400; Sun, 25 Feb 2024 08:56:04 +0100 (CET) Date: Sun, 25 Feb 2024 08:56:04 +0100 From: Mark Wielaard To: Tomasz =?utf-8?Q?K=C5=82oczko?= Cc: Sam James , gdb@sourceware.org Subject: Re: gdb and ancient GNU autotools Message-ID: <20240225075604.GB8121@gnu.wildebeest.org> References: <87v86d6byg.fsf@gentoo.org> <87o7c56ale.fsf@gentoo.org> <20240224193114.GF1353@gnu.wildebeest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" 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 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