<lfam>If not, that will be very annoying. We would need to change our approach to sourceforge packages. Maybe have the Guix downloader check some content addressed storage like tarballs.nixos.org before the sourceforge URLs?
<lfam>Or, tarballs.guixsd.org or tarballs.hydra.gnu.org ;)
<ng0>the new owners? sf got a management replacement?
<ng0>when is it okay to bump an issues on github or ask for reaction? 3 weeks? It's just 9 days without reply now, but meanwhile others got opened and replied to.
<lfam>In that case, it's possible the upstream maintainers are finding something difficult about your report. I would bump it, but make an effort to clarify the nature of the problem and the possible solution, if a solution is known.
<civodul>lfam: i was thinking that our download code should indeed check the hash of what it got
<ng0>guile 2.0.12 was released? I just saw a version bump of the gentoo bug I'm taking part in
<civodul>lfam: this would be redundant with what guix-daemon does, but it would allow us to try another URL when the hash is invalid
<ng0>lfam: maybe i split the 2nd issue. the first is rather clear, but I can clarify it
<lfam>civodul: I should try reading guix/download.scm to see how much I can understand. My knowledge of Guix internals is still not great.
<lfam>Having to remove the binary diffs and their associated changes from the security patches drastically increases the knowledge required to apply security patches. In general, security updates and patches should be easy to apply.
<ng0>i think gnupg-2.1.14 was released.. at least that's what my gentoo hardened-musl is failing on now^^
<ng0>I have no energy to test this today on guix.. but i will this weekend
<alezost>lfam: np, btw it's better to use "sourceforge" regexp instead of "mirror://sourceforge": I've noticed there are 10 sourceforge packages that don't use mirror form. Look at output of this script: http://paste.debian.net/781793
<lfam>alezost: What is this called? "~a@~a:~/~a~%" I'd like to read about it in the Guile manual