bug#54370: network problem or intentional blocking?
Tobias Geerinckx-Rice via Bug reports for GNU Guix schreef op zo 13-03- 2022 om 20:50 [+0100]: > I wish there were a better answer than 'use Tor' for those stuck in the > cross-fire :-( For the website, publishing the website not only over HTTP/S but also over IPFS might help? The website is static and Guix has an IPFS service, so it should be feasible I think. The browser extension (https://docs.ipfs.io/install/ipfs-companion/) would need to be packaged though, and a DNS link record (https://docs.ipfs.io/concepts/dnslink/#resolve-dnslink-name) would need to be set up. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
bug#54370: network problem or intentional blocking?
Pending expertise, is it feasible to serve the copy as-is without trying to impersonate berlin? E.g. mirror.guix.gnu.org? Hm, maybe that's not worth the effort… I've asked around and short of pointing guix.gnu.org to bayfront — working around the issue & hoping that it will continue to be unaffected — or using a CDN that has points of presence in Russia — which can easily be taken down in a future wave of sanctions — the situation seems to be quite disappointing. For proper fail-over you (ironically) need one box sitting in front of the boxes you want to fail over to. Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity.
bug#54370: network problem or intentional blocking?
[Resending to the proper address, sorry; I'm mu4e-less and hence incompetent :-] Hi! On 2022-03-13 20:00, poiNt_3D wrote: Is it possible to set the firewall to allow only public services to be accessed from these IP ranges? I'm afraid we don't control the berlin firewall or have much sway in how it's managed, so there's little point in discussing such actions. can be easily interpreted as a political decision With Russia waging war, it seems likely that these Russian ISPs tolerate abusive traffic for political reasons. There are probably political consequences for those who refuse. The Internet was and still is built on ISP accountability and gives targets few other tools to effectively defend themselves, short of blocking such IP ranges. I wish there were a better answer than 'use Tor' for those stuck in the cross-fire :-( Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity.
bug#54305: disk utility fail format fat
Dear Liliana I reported it upstream as suggested. Here is the link to track the upstream issue: https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/issues/242 I intend to report here if I get a conclusive response. Thank you! Roman У чт, 2022-03-10 у 09:00 +0100, Liliana Marie Prikler пише: > Hi Roman, > > Am Mittwoch, dem 09.03.2022 um 02:27 +0200 schrieb Roman Riabenko: > > 2. GNOME Disks utility ignored the dosfstools package which I > > installed > > in my user profile. For comparison, this applies to ntfs-3g too. In > > relation to ntfs-3g with UDisks this seems to be expected behavior, > > but > > it seemed to me as a bug at first: > > https://guix.gnu.org/en/manual/devel/en/html_node/Desktop-Services.html#index-udisks_002dservice > > > > I do not know what is necessary to make GNOME Disk utility > > recognize > > the tools in the user profile and I am not sure it is necessary. It > > just seemed against the spirit of guix that the user is forced to > > reconfigure the system. > GNOME Disks inherits UDisks' limitations, as it uses it under the > hood. > With that in mind... > > > 1. The FAT option was not grayed out in the formatting dialog. For > > comparison, the NTFS option was grayed out until I added ntfs-3g to > > the system profile too. May be GNOME Disks expects mkfs.vfat to be > > present, so it does not check whether it is present like it does > > for > > other file systems. > > > > So, it would be great for GNOME Disks to check whether mkfs.vfat is > > available before proceeding like it does for other filesystems. > You should probably report this one upstream. A fix would be > relatively simple to write, see [1] for the relevant line making the > Windows button insensitive. The procedure > "gdu_utils_is_ntfs_available" spans only a few lines of code and > could > easily be adapted to check for vfat instead. > > Cheers > > [1] > https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/blob/40.2/src/disks/gducreatefilesystempage.c#L209
bug#54370: network problem or intentional blocking?
Hi!
On 2022-03-13 15:30, Ludovic Courtès wrote:
The plan we discussed during the “sysadmin hackathon” a couple
of months ago was to, for instance, have the DNS entry point to these
two machines.
Uhm, quick but:
Apparently some browsers (OK, one, and we all know which one) embraces &
extends the DNS in such a way that this provides the fall-back behaviour
you seem to expect. But this is not standard and it won't fly with most
software. I checked.
It doesn't in Firefox/IceCat. Even if it does in current Chrom{e,ium},
it might just be an unreliable side-effect.
Kind regards,
T G-R
Sent from a Web browser. Excuse or enjoy my brevity.
bug#54370: network problem or intentional blocking?
Hi, Christopher Baines skribis: > I believe bayfront was being setup to serve the website (see [1]), but > I'm not sure on how that's progressing. > > 1: > https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=8250a46b2fa178d1cdd37986028d5a07e3db65ed Indeed. The plan we discussed during the “sysadmin hackathon” a couple of months ago was to, for instance, have the DNS entry point to these two machines. The problem we keep stumbling upon and that I don’t know how yet how to solve is how to make it work for HTTPS: do we copy raw certificates to bayfront, or is there a way to have separate certificates? How about Let’s Encrypt challenges? These are the last issues to solve and I’d welcome expertise here. Any ideas? Everything else is addressed: the web site gets built on bayfront just like it is on berlin, static data such as videos and PDFs are automatically mirrored to bayfront. https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=601691e7ea07c999d60993464b27d4cba2621f05 Thanks, Ludo’.
bug#54370: network problem or intentional blocking?
Tobias Geerinckx-Rice via Bug reports for GNU Guix writes: > I didn't address guix.gnu.org beyond ci.guix.gnu.org. > > Everyone: should we ask SJTUG to mirror the Web site as well? > > I'm generally weary of that. I believe bayfront was being setup to serve the website (see [1]), but I'm not sure on how that's progressing. 1: https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=8250a46b2fa178d1cdd37986028d5a07e3db65ed signature.asc Description: PGP signature
bug#54370: network problem or intentional blocking?
Hm, I didn't address guix.gnu.org beyond ci.guix.gnu.org. Everyone: should we ask SJTUG to mirror the Web site as well? I'm generally weary of that. Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity. Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity.
bug#54370: network problem or intentional blocking?
Hi Point4d, Specifically, from the thread linked by Evgeny: "At the MDC level there’s an unrelated recent ban of some Russian IP ranges in place due to massively increased port scans and intrusion attempts since about one week. I hope you can use the Chinese mirror for the time being." That mirror is at https://mirrors.sjtug.sjtu.edu.cn/guix . Let us know if it works. Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity.
bug#54370: network problem or intentional blocking?
Hello. I would like to request a clarification on the issue of inaccessibility of guix.gnu org from the Russian Federation. Is the blocking intentional or is there some kind of networking problem? Here's my traceroute output: > 6 ge-4-0-0-10g.m320-2-vlgd.nwtelecom.ru (212.48.195.41) 15.660 ms > 13.065 ms 15.545 ms > 7 109.172.24.67 (109.172.24.67) 32.341 ms 87.226.183.61 (87.226.183.61) > 31.027 ms 28.507 ms > 8 ae53.edge4.stockholm2.level3.net (213.249.107.129) 37.298 ms 29.497 > ms 35.571 ms > 9 ae1.5.bar1.hamburg1.level3.net (4.69.142.209) 73.587 ms > s-bb1-link.ip.twelve99.net (62.115.139.180) 27.296 ms > ae1.5.bar1.hamburg1.level3.net (4.69.142.209) 74.064 ms > 10 195.122.181.62 (195.122.181.62) 64.682 ms 66.071 ms 68.254 ms > 11 ffm-b5-link.ip.twelve99.net (62.115.114.89) 51.213 ms > cr-tub2-be13.x-win.dfn.de (188.1.144.58) 67.156 ms 61.032 ms > 12 kr-mdcbln1.x-win.dfn.de (188.1.238.78) 65.546 ms > dfn-ic357399-ffm-b5.ip.twelve99-cust.net (213.248.97.41) 50.044 ms > 49.354 ms > 13 cr-erl2-be8.x-win.dfn.de (188.1.144.221) 50.629 ms * * > 14 cr-tub2-be10.x-win.dfn.de (188.1.146.210) 64.584 ms 56.154 ms * > 15 kr-mdcbln1.x-win.dfn.de (188.1.238.78) 59.972 ms * 64.541 ms16 * * > * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > Thanks.
bug#54372: SVG icons are not rendered in Qt application (qTox)
In qTox some icons inside interaface are not rendered. The log contains a lot of related warnings: --8<---cut here---start->8--- AL lib: (WW) Querying error state on null context (implicitly 0xa004) [10:09:16.339 UTC] nexus.cpp:86 : Debug: Starting up [10:09:16.539 UTC] persistence/profile.cpp:318 : Debug: Self avatar not found, will broadcast empty avatar to friends [10:09:16.577 UTC] :0 : Warning: Could not create pixmap from /home/bob/.local/share/qTox/themes/default/chatForm/callButton.svg [10:09:16.578 UTC] :0 : Warning: Could not create pixmap from /home/bob/.local/share/qTox/themes/default/chatForm/callButton.svg [10:09:16.578 UTC] :0 : Warning: Could not create pixmap from /home/bob/.local/share/qTox/themes/default/chatForm/videoButton.svg --8<---cut here---end--->8--- I copied and used a theme from qtox repository instead of built-in to make sure that files are valid SVGs, but it doesn't matter. Also, built a latest qtox release, same issue here. Reported it to qTox, but it seems the problem is related to qt or qtsvg. https://github.com/qTox/qTox/issues/6555 -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#54370: Guix in Russia
Hello! Check out this discussion: https://lists.gnu.org/archive/html/help-guix/2022-03/msg4.html
