Go to https://codesearch.debian.net/search?q=Client+sent+an+HTTP+request+to+an+HTTPS+server
select first link https://codesearch.debian.net/show?file=gcc-10_10.2.1-1%2Fgcc-10.2.0%2Flibgo%2Fgo%2Fnet%2Fhttp%2Fserver.go&line=1798
get a 404 with a list of 12 alternative source files of different
versions of gcc-XX/XX.Y.Z-W/gcc-XX.V.U/libgo/go/net/http/server.go
each returning a 404.

I have now clicked through quite a few links to source files, but
have yet to find one that won't return a 404...?

Maybe the search index would need to be purged of source files that
have disappeared (been updated) or something?

Anyway, thanks a lot for the service, very, very appreciated and useful,
*t

Hi Tomas,

Thank you very much for the detailed bug report, and apologies for the
delay in getting back to you.

After further inspection, it turns out the tarball containing the
source for gcc-10 contains embedded tarballs. See
http://deb.debian.org/debian/pool/main/g/gcc-10/gcc-10_10.2.1.orig.tar.xz
and https://sources.debian.org/src/gcc-10/10.2.0-3/

Debsources unpacked the first tarball, and the embedded ones are
technically the "source" of gcc-10. The path you obtained from
codesearch.debian.net points to a file inside the tarball inside the
tarball; this is unfortunately not supported by sources.d.o.

I didn't know codesearch supported this feature. CCing Michael, in
case you have an idea on how not to point to sources.d.o for code
results originating from unpacked archives. :)

Cheers,
--
Matthieu

Thanks for looping me in.

We introduced unpacking tarballs in https://github.com/Debian/dcs/issues/80
(from 2017!),
but apparently didn’t think it through far enough regarding sources.d.o :)

Would adding support for unpacking tarballs be something you would consider
in debsources?
I know that tarballs *technically are the source*, but humans clearly find
the contents of these tarballs more interesting.

Otherwise, we could handle these with our own /show handler by checking if
the source is present in debsources first,
but that obviously involves one additional request per /show handler, so
it’s not exactly cheap.

Hi Michael,

Thanks for your answer! And I think we can reasonably assume this edge
case doesn't happen too often. :)

Yes - clearly. The bug to implement tarballs-in-tarballs unpacking has
been open forever, so I think it's quite unlikely it's gonna be picked
up within a reasonable timeframe. I myself won't have time to take
care of this anytime soon.

That'd work indeed. Doing nothing also sounds like a reasonable
strategy, given the (assumed) low rate of this failure and the efforts
involved to implement a work-around.

But I'm glad we know where that comes from. Thanks for your thoughts!

Cheers,
--
Matthieu

I can empathize regarding not having enough time, but just want to point
out that the change itself ended up being quite simple in terms of lines of
code and mental complexity:
https://github.com/Debian/dcs/commit/2c94a341f785e2c7552a02500289b95dfe75a83d
— as you can see, we just loop over *.tar.* and call “tar xf”.

I’m not saying this to push you to implement it, just mentioning this for
your information should you eventually get around to it :)

Thank you very much! CCing the original bug for reference, might come
handy sooner or later. :)

Cheers,
--
Matthieu