Our automated repository checks [1] have detected that the 'megacoffee' repository can not be synced. The following URIs are listed for the repository: [mercurial] https://rhodecode.megacoffee.net/gentoo-overlay/main [mercurial] http://rhodecode.megacoffee.net/gentoo-overlay/main Please verify that the server hosting the repository is working correctly. If the repository has been moved to a new location or removed altogether, please let us know to update the record appropriately. We reserve the right to remove the repository if we do not receive any reply within 2 weeks. [1]:https://wiki.gentoo.org/wiki/Project:Repository_mirror_and_CI
I can clone our repository just fine and don't see any errors in our log. Your log indicates an issue with SSL verification and there have been multiple other bug reports created at about the same time. We are using a certificate from CACert which was supposed to be trusted by default in Gentoo. Has this changed?
Okay, so it seems like cacert USE flag has indeed been unset by default. What's bad about that move (which is tracked as 580722) is that it breaks systems which used and relied on CACert before. I'll add that comment on 580722 as well... For the moment we will be adding a note to our website as we just got emailed by one of our users complaining about not being able to access our repo for 2-3 weeks. We will (sadly) make a switch to Let's Encrypt but that will take at least a few days as I don't want to reissue certificates manually every 90 days, that's just to frequent... So please bare with us and keep us in the overlay list, even if it should take longer than 2 weeks for us to resolve the issue. Can you please confirm? We will update this bug report as soon as we have changed the CA.
Sure. As a side note, I think your http:// is redirecting to https://, so you may want to remove the redundant address.
Besides, I suggest you try to obtain at least a temporary certificate ASAP because -- as you have noticed -- multiple users will lose access to the repo when upgrading. I can't say I like the way it's done, I could've just re-enabled cacert on the server but I've decided it's better to warn people about this.
Don't worry, I won't shoot the messenger. In fact, thanks for notifying us about that issue. :) Concerning the redirect: That's still from when we first enabled HTTPS for our overlay and tried to smoothly "migrate" previous setups. I don't remember if that method ever worked reliably, so the HTTP URL could as well be removed now. By the way, we were also discussing to move the repo to GitHub recently to ease collaborations with external users. AFAIK there is no mechanism to instruct layman to delete the old local overlay copy and instead clone from a new URL? So maybe we will add a GitHub URL later on and keep running our own (Mercurial-based) clone for legacy installations. What's especially bad is that not only the primary URL would change but also the VCS. Not entirely thought through yet... Issuing a temporary LE certificate via "get HTTPS for free" would be an option (I did that before) but I'm not entirely sure if and how we can re-use the LE account authorization with an ACME client - whatever client we will choose...
(In reply to Daniel Neugebauer from comment #5) > By the way, we were also discussing to move the repo to GitHub recently to > ease collaborations with external users. AFAIK there is no mechanism to > instruct layman to delete the old local overlay copy and instead clone from > a new URL? So maybe we will add a GitHub URL later on and keep running our > own (Mercurial-based) clone for legacy installations. What's especially bad > is that not only the primary URL would change but also the VCS. Not entirely > thought through yet... I think that's not a major problem. As long as the name is the same, layman can detect the change and warn user somehow. If it's not doing that yet, it shouldn't be hard to change it.
I've sacrificed my afternoon and we now have an ACME client managing its first LE certificate on our server - the connectivity issue should now be resolved; could you please check again if it works from your test system as well?
The bug seems to be fixed in the repository. Closing.
