XPost: linux.debian.devel.qa

Hi!

On Wed, 2024-03-06 at 14:15:03 +0000, Debian Bug Tracking System wrote:

------------------------------------------------------------------------ vcswatch: Use --filter blob:none

Required blobs (changelog, control, upstream metadata) are fetched by
git on demand. Thanks to Gábor Németh for the suggestion!

Closes: #1032623 ------------------------------------------------------------------------

It looks like this broke for remotes that do not support filtering
(yet?). The attached completely untested patch might make this work
again. Affecting at least git.hadrons.org and git.dpkg.org, but there
might be others too.

Thanks,
Guillem

From d78a41fad53de64eb50f72692bf057c82d41fc85 Mon Sep 17 00:00:00 2001
From: Guillem Jover <guillem@debian.org>
Date: Thu, 7 Mar 2024 13:30:41 +0100
Subject: [PATCH] vcswatch: Ignore warning when the server does not know about
filtering

The command succeeded, but emitted a warning. Instead of failing the
fetching, ignore the warning.
---
data/vcswatch/vcswatch | 2 ++
1 file changed, 2 insertions(+)

diff --git a/data/vcswatch/vcswatch b/data/vcswatch/vcswatch
index be72cc35..611d5372 100755
--- a/data/vcswatch/vcswatch
+++ b/data/vcswatch/vcswatch
@@ -243,6 +243,8 @@ sub process_package ($) {
# try a full clone instead
runcmd ('git', 'clone', '--quiet', '--bare', '--mirror', '--template', '', $url, $pkgdir);
$dbh->do("UPDATE vcs SET dumb_http = true WHERE package = ?", undef, $pkg->{package});
+ } elsif ($err =~ /warning: filtering not recognized by server, ignoring/) {
+ # ignore the warning
} else {
error ($err);
}
--
2.43.0

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.qa

It looks like this broke for remotes that do not support filtering
(yet?). The attached completely untested patch might make this work
again. Affecting at least git.hadrons.org and git.dpkg.org, but there
might be others too.

Thanks for spotting that, the patch seems to work.

Re-running the scan on the dpkg repo still takes around 3 minutes -
not sure what the client or the server are doing during that time, it
doesn't re-fetch the repo.

On acl and attr the scan is done in 2 or 3s.

Christoph

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.qa

Hi!

On Thu, 2024-03-07 at 14:34:39 +0100, Christoph Berg wrote:

It looks like this broke for remotes that do not support filtering
(yet?). The attached completely untested patch might make this work
again. Affecting at least git.hadrons.org and git.dpkg.org, but there
might be others too.

Thanks for spotting that, the patch seems to work.

Great! :)

Re-running the scan on the dpkg repo still takes around 3 minutes -
not sure what the client or the server are doing during that time, it
doesn't re-fetch the repo.

I've now done a «git gc --aggressive» on the repo on the server,
hoping that might help with that.

On acl and attr the scan is done in 2 or 3s.

These only contain the debian/ directory, so I'd expect them to be
fast no matter what.

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)