--- Begin Message ---
Package: www.debian.org
Severity: normal
Search on https://search.debian.org/ page for words or any strings
present only in files later than the 6 October 2017 return no results,
for example "Spectre" or "3.22.3-1+deb9u1".
To reproduce:
- use the search box for the term "Spectre" in English (or any other
language) or for "3.22.3-1+deb9u1" (stable fixed version number for
nautilus in DSA-3994-1 released on 7 October 2017). There are no
results.
It's not an issue with the web browser: I tried with firefox and
chromium. Furthermore the command line request "grep -r Spectre" in
webwml directory returns a lot of results, and likewise, "grep -r
3.22.3-1+deb9u1" returns 5 results.
-- System Information:
Debian Release: stretch
APT prefers stable
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On Sun, Oct 07, 2018 at 11:24:12AM +0200, Jean-Pierre Giraud wrote:
> Search on https://search.debian.org/ page for words or any strings
> present only in files later than the 6 October 2017 return no results,
> for example "Spectre" or "3.22.3-1+deb9u1".
>
> To reproduce:
> - use the search box for the term "Spectre" in English (or any other
> language) or for "3.22.3-1+deb9u1" (stable fixed version number for
> nautilus in DSA-3994-1 released on 7 October 2017). There are no
> results.
Thanks for reporting.
This is due to a bug in the search database replication. It wasn't
actually affecting all languages, but rather those after a certain point
in the list of languages.
The replication script iterates over the list of languages, each of
which has its own database, and tries to replicate each database in
turn. However when there are no changes for a language the replication
command seems to get killed by SIGPIPE (possibly due to the ssh tunnel
wrapper - I recall weasel hit a SIGPIPE issue trying to use stunnel when
we set this up at Debconf in Heidelberg, and he decided to use an ssh
wrapper instead of fighting it).
I've modified the replication script to continue when a database
replication fails, since that seems more robust anyway.
I'll try to debug what the SIGPIPE issue is, but the issue reported
here should be fixed and shouldn't recur so closing the bug.
Cheers,
Olly
--- End Message ---