Follow-up Comment #18, bug #66342 (group groff):

At 2026-02-03T08:03:54-0500, Deri James wrote:
> Follow-up Comment #17, bug #66342 (group groff):
> I have had continual timeout connections to https://savannah.gnu.org
> since the weekend.

Ugh.  That really sucks.  :(

> Is it just me! :-)

I'm not having that exact problem, but I've had others like it.

https://savannah.nongnu.org/support/?111374

If you can't get there, you can't see it, but it's a ticket from Benno
Schulenberg complaining of stale cgit.git.savannah.gnu.org mirrors.

Load-balancing gone wrong, perhaps.

Benno wrote:

>>> Looking at https://cgit.git. ... rg/cgit/nano.git/ it shows "copyright:
>>> update the years for the FSF" from two weeks ago as the last commit.
>>> But yesterday it showed "docs: add an Exit Status section to the man
>>> page and the manual" from yesterday as the last commit.
>>>
>>> When I now do `git push` on that last commit, it says: Everything
>>> up-to-date.  But the cgit still shows the state from two weeks ago.

I added:

>>> Concur.  One of the cgit mirror sites was stale for groff by about
>>> two whole weeks!
>>>
>>> I tried sniffing out the culprit by running "nslookup" on
>>> "cgit.git.savannah.org" and putting the IP address directly in the
>>> URLs, but this didn't work due to HTTPS default and inappropriate or
>>> missing SSL certificate matches.  (I'm not au fait with modern web
>>> security.)
>>>
>>> What made this worse was that mirror selection seems to be arbited
>>> on source-IP basis, so restarting my browser did no good--if my
>>> browser picks the stale mirror, that is the one I see from that host
>>> for an indefinitely long period (several days).
>>>
>>> I got multiple IP addresses from "nslookup" on
>>> "cgit.git.savannah.org", as I pretty much expected.
>>>
>>> I'm no load-balancing expert, but that was the technique I was
>>> expecting.

> But from what I remember of your sensible comment #8 I was in
> agreement and stuck it on my todo list after 1.24.0 is out the door.

Here's Dave's comment #8 in its entirety:

>>> Deri,
>>>
>>> Would it make sense to make embedding the default behavior, continue
>>> to accept "-e" as a no-op (as Branden did), and introduce a new flag
>>> to specify not embedding the base 14 fonts, for those users who do
>>> need smaller PDFs?  This would change existing behavior for users
>>> who do not specify -e, but in a way more in line with best
>>> practices, and would not affect users who do specify -e.  Is that an
>>> acceptable change?

My amendment would be to give that "new flag" an identity of `-E`.

But I would also like to see the meaning of bit 3 of `--opt` inverted.

I'd like to see this done _before_ 1.24.0 is out, to avoid the necessity
of changing the meaning of bit 3 of gropdf's `--opt`.

Unless of course you disagree with that proposal, in which case further
discussion is warranted.

If you agree, I'm happy to help develop the changes.

> If you have access to savannah please can you confirm this message
> (via the email route to savannah) has arrived.

Confirmed; I see it on the Savannah website as comment #17 to bug
#66342.

> I have a hankering

You twigged it, rather.  ;-)

A hankering is a feeling of desire.

"Hmm, I guess Bart's not to blame.  He's lucky too, because it's
spankin' season and I've got a hankerin' for some spankerin'!"

> I may have triggered an anti ddos rule and got myself blacklisted, I
> believe the last time I successfully accessed the site at the weekend,
> firefox was mis-behaving, I left it to have my lunch and when I came
> back it was still using a lot of cpu and I killed it, but I wonder if
> during that high cpu it was hammering POST messages at savannah, which
> put me on "the naughty step".

Maybe, but I've also fallen victim to (what I suspect to be) anti-DDoS
measures simply by clicking through GNU mailing list archives "too
fast".  "Too fast" is, I guess, on the order of under 1 second per
HTTP(S) request.

> I have recently (my xmas present to myself) upgraded my internet
> connection to 500Mbs, so firefox misbehaving would be serious.

Yes.  A disadvantage of a high data rate as a consumer is that we become
more confusable with deep-pocketed crawler bots who are trying to
masquerade as ordinary consumers.

> Do you have an email address I can use to contact savannah admins who
> can help me get access again. Of course, it could be savannah is under
> a real ddos attack and I've just been unlucky not to get a connection
> slot.

Yes, you can contact (and I recommend subscribing to)
<[email protected]>.

There's also this resource:

https://hostux.social/@fsfstatus

...but in my experience neither of these is updated as frequently as
outages occur in practice.  I've more than once had to mail that -public
list to solicit information.  On the upside, that usually works, but I
don't usually get a response super-fast.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66342>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature

Reply via email to