bug#71113: git-fetch throws an error: gnutls_handshake() failed: An unexpected TLS packet was received.
Hello Guix! When I try to download source code of any package that use git-fetch download method I get an error if I am behind https proxy server. For example, $ guix build --no-substitutes -S eigen The following derivations will be built: /gnu/store/rsk8d4py0c5qgp7q4xzd9ci3w4l5wki5-eigen-3.4.0-checkout.drv /gnu/store/ac69jx4b08rqd07v5m5ayd5dgh3b9798-eigen-3.4.0-checkout.drv building /gnu/store/ac69jx4b08rqd07v5m5ayd5dgh3b9798-eigen-3.4.0-checkout.drv... hint: Consider installing the `glibc-locales' package and defining `GUIX_LOCPATH', along these lines: guix install glibc-locales export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" See the "Application Setup" section in the manual, for more info. Initialized empty Git repository in /gnu/store/1syd2rljr26hx9y45645lxwfh1wsya50-eigen-3.4.0-checkout/.git/ fatal: unable to access 'https://gitlab.com/libeigen/eigen.git/': gnutls_handshake() failed: An unexpected TLS packet was received. Failed to do a shallow fetch; retrying a full fetch... fatal: unable to access 'https://gitlab.com/libeigen/eigen.git/': gnutls_handshake() failed: An unexpected TLS packet was received. git-fetch: '/gnu/store/lcygm0p2d59acvwi12lwldg5c0d4czpr-git-minimal-2.41.0/bin/git fetch origin' failed with exit code 128 Trying content-addressed mirror at bordeaux.guix.gnu.org... ... But when I use 'git clone' like this: $ guix shell --preserve=https_proxy -CN git nss-certs -- \ git clone https://gitlab.com/libeigen/eigen.git/ it works. I looked into definitions of 'git' and 'git-minimal' packages. They both do not depend on 'gnutls' package (at least directly), but instead on 'openssl'. Then why is git-fetch method apparently using 'gnutls' and not 'openssl'? Is there any workaround for git-fetch (similar to package transformations) that allow to replace 'gnutls' by 'openssl' in its dependency graph? Regards, Nigko
bug#71113: git-fetch throws an error: gnutls_handshake() failed: An unexpected TLS packet was received.
It turns out that this wasn't Guix's bug at all, but only the wrong configuration of https_proxy variable in the guix-daemon environment (on foreign distro): I mistakenly set https_proxy to "https://... "address, while the proxy server understands only http protocol. Setting https_proxy to "http://.."; address fixes this. Close this bug report. Regards, Nigko Yerden
bug#64976: guix build: error: invalid character `~' in name
Hello, When running "guix build -f alps.scm" where alps.scm uses url-fetch with (uri "https://exa.phys.s.u-tokyo.ac.jp/archive/MateriApps/src/alps_20220304~r7871.orig.tar.gz";) the following error occurs guix build: error: invalid character `~' in name 'alps_20220304~r7871.orig.tar.gz.drv' Bug was noted at repository URL: https://git.savannah.gnu.org/git/guix.git commit: c173819c8e5235ce02d60b79bd88b10023a7c614 branch: master(define-module (alps) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix build-system cmake) ;;#:use-module (gnu packages cmake) #:use-module ((guix licenses) #:prefix license:) #:use-module (guix build utils) #:use-module (guix gexp) #:use-module (gnu packages boost) #:use-module (gnu packages algebra) #:use-module (gnu packages maths) ) (define-public alps (package (name "alps") (version "7871") (source (origin (method url-fetch) (uri (string-append "https://exa.phys.s.u-tokyo.ac.jp/archive/"; "MateriApps/src/alps_20220304~r7871.orig.tar.gz")) (sha256 (base32 "09klx0samxz9lap2j9q19264bdpydbrfqq1wmwwi9y01cwavkg3l" (build-system cmake-build-system) (arguments (list #:tests? #t #:configure-flags #~(list "-DALPS_BUILD_PYTHON=OFF"))) (native-inputs (list)) (inputs (list boost fftw openblas hdf5)) (propagated-inputs (list)) (synopsis "Algorithms and Libraries for Physics Simulations") (description "The ALPS project (Algorithms and Libraries for Physics Simulations) is an open source effort aiming at providing high-end simulation codes for strongly correlated quantum mechanical systems as well as C++ libraries for simplifying the development of such code. ALPS strives to increase software reuse in the physics community.") (home-page (string-append "https://web.archive.org/web/20210508050408/"; "https://alps.comp-phys.org/mediawiki/index.php/Main_Page";)) (license (license:non-copyleft "file://LICENSE" "See README in the deistribution." alps
bug#70302: Tor daemon is unable to use obfuscation
Hello Guix! I am trying to configure tor daemon to use traffic obfuscation by the following lines in my system configuration (service tor-service-type (tor-configuration (plain-file "torrc" " UseBridges 1 ClientTransportPlugin obfs4 exec /path/to/obfuscator/binary Bridge obfs4 .. Bridge obfs4 .. "))) where /path/to/obfuscator/binary corresponds to an obfs4 obfuscator. There are a few of them in the guix repo, see e.g. go-gitlab-torproject-org-tpo-anti-censorship-pluggable-transports-lyrebird or go-github-com-operatorfoundation-obfs4 packages. The obfuscator is also installed in the system profile. Bridges are gotten from the official site https://bridges.torproject.org/. This torrc configuration works perfectly on guix when tor run at user level by command '$ tor -f path/to/torrc' and '# netstat -tupan' shows obfuscator process is listening on 127.0.0.1:[some random port]. However, when tor run as system daemon, there are no obfuscator process listening and tor is unusable. Perhaps this issue is related to https://issues.guix.gnu.org/57222. I have tried to revert commit fb868cd7794f15e21298e5bdea996fbf0dad17ca on recent guix checkout and then to perform 'guix pull --url=/path/to/my/local/guix/repo --disable-authentication'. It worked fined. But when performing 'sudo guix system reconfigure /path/to/system/configuration' I got an error 'make-forkexec-constructor/container: unbound variable' Regards, Nigko Yerden
bug#70332: Tor daemon is unable to use obfuscation
I have found why it is not working! Tor process is simply not allowed to have access to the obfuscator binary because it is running inside all Linux namespaces except "net", in particular in "mnt" namespace. We need to add path/to/obfuscator/binary to the #:mappings field of the least-authority-wrapper call inside tor-shepard-service body in /gnu/service/networking.scm. I have checked, this makes obfuscation fully functional. Regards, Nigko Yerden Hello Guix! I am trying to configure tor daemon to use traffic obfuscation by the following lines in my system configuration (service tor-service-type (tor-configuration (plain-file "torrc" " UseBridges 1 ClientTransportPlugin obfs4 exec /path/to/obfuscator/binary Bridge obfs4 .. Bridge obfs4 .. "))) where /path/to/obfuscator/binary corresponds to an obfs4 obfuscator. There are a few of them in the guix repo, see e.g. go-gitlab-torproject-org-tpo-anti-censorship-pluggable-transports-lyrebird or go-github-com-operatorfoundation-obfs4 packages. The obfuscator is also installed in the system profile. Bridges are gotten from the official site https://bridges.torproject.org/. This torrc configuration works perfectly on guix when tor run at user level by command '$ tor -f path/to/torrc' and '# netstat -tupan' shows obfuscator process is listening on 127.0.0.1:[some random port]. However, when tor run as system daemon, there are no obfuscator process listening and tor is unusable. Perhaps this issue is related to https://issues.guix.gnu.org/57222. I have tried to revert commit fb868cd7794f15e21298e5bdea996fbf0dad17ca on recent guix checkout and then to perform 'guix pull --url=/path/to/my/local/guix/repo --disable-authentication'. It worked fined. But when performing 'sudo guix system reconfigure /path/to/system/configuration' I got an error 'make-forkexec-constructor/container: unbound variable' Regards, Nigko Yerden
bug#70954: No 'guix pull' substitutes for foreign distros?
Hello Florian, These are great news! Thanks a lot for investigating this! Indeed, foreign distros still run guix-daemon from Guix v1.4, which is very old now. It makes sense that old guix-daemon + recent remaining parts of Guix might have produced modified derivations. For foreign distros using systemd, the following workaround may be useful to replace old guix-daemon by guix-daemon from USER profile: ~guix-daemon.service ... [Service] ExecStart=/home/USER/.config/guix/current/bin/guix-daemon \ --build-users-group=_guixbuild --discover=no \ --substitute-urls='.' Environment='GUIX_LOCPATH=/home/USER/.guix-profile/lib/locale' ... ~ Regards, Nigko
bug#70954: No 'guix pull' substitutes for foreign distros?
Hello Florian, From testing old Guix System system generations, I believe September 2023’s new daemon feature “builtin:git-download” has caused the change in hashes As far as I remember, approximately at that time, in the late autumn, I have started to experience very long 'guix pull'. I’m closing this bug. No objections. But I would like to know, does \ work in systemd by now Yes, \ works in systemd service files. I didn't know that \ was forbidden in the past. Regards, Nigko
bug#70302: Tor daemon is unable to use obfuscation
Hi Vincent, Indeed, they are related. My message from 70332 was intended to go to 70302 and didn't get there by my mistake, thus creating new issue 70332. Regards, Nigko Vincent Legoll wrote: I think the two issues are related, and the second one may have been created by typoing the issue number https://issues.guix.gnu.org/70302 https://issues.guix.gnu.org/70332 WDYT ?
bug#70332: Tor daemon is unable to use obfuscation
Yes, the issue still need fixing. Here is my suggestion https://issues.guix.gnu.org/70341 Regards, Nigko Vincent Legoll wrote: Hello, On Thu, Jun 20, 2024 at 4:49 AM Nigko Yerden wrote: Indeed, they are related. My message from 70332 was intended to go to 70302 and didn't get there by my mistake, thus creating new issue 70332. Thanks for the explanation You said in 70332 that you found the issue, so does something still need fixing ? Regards
bug#70954: No 'guix pull' substitutes for foreign distros?
guix-module-union 2KiB 149KiB/s 00:00 ▕██▏ 100.0% applying 2 grafts for mkfontdir-1.0.7 ... guix-command 653B 436KiB/s 00:00 ▕██▏ 100.0% applying 6 grafts for texinfo-6.8 ... guix-daemon 402B105KiB/s 00:00 ▕██▏ 100.0% guix-08360a2cd 800B 94KiB/s 00:00 ▕██▏ 100.0% building CA certificate bundle... listing Emacs sub-directories... building fonts directory... building directory of Info manuals... ... Shouldn't 'guix pull' substitutes also work on foreign distros? If they should, why don't sytem B get them? Regards, Nigko
bug#70954: No 'guix pull' substitutes for foreign distros?
Hi Florian Pelz, https://guix.gnu.org/manual/en/html_node/Channels-with-Substitutes.html Yes, I'm aware about this feature. It doesn't help. it might be bad timing. I think this possibility can be excluded because of: 1) I have performed 'guix pull' on the system B for the last few months (maybe half a year) a few dozens of times and every time I observed it build all the derivations by itself. 2) I had performed the experiment. I queried [1] for the latest commit with substitutes and performed 'guix pull --commit="obtained commit"' on systems A and B (they are both x86_64). The results of this experiment are presented in my first message. 3) Today I have preformed the similar experiment. According to [1] the latest commit with substitutes was "5a624adfd". Again, the system B have built all the derivations by itself while the system A have downloaded substitutes. [1] https://ci.guix.gnu.org/api/latestbuilds?nr=1&job=guix.x86_64-linux Regards, Nigko pelzflorian (Florian Pelz) wrote: Hello Nigko Yerden. You could definitely test if substitutes are never available if you used https://guix.gnu.org/manual/en/html_node/Channels-with-Substitutes.html which should guarantee that it will use a version of Guix where guix pull has substitutes. When not using channel-with-substitutes-available, it might be bad timing. Regards, Florian
bug#70954: No 'guix pull' substitutes for foreign distros?
ectories... building fonts directory... building directory of Info manuals... building profile with 1 package... building /gnu/store/8cc301dx0j3fjki7zml115363q7v64rq-inferior-script.scm.drv... building package cache... building profile with 1 package... on my x86_64 Guix System laptop, like your machine A (that downloads substitutes), builds /gnu/store/1mwhp5crimgvqd4jmlfsj3017yk8vxsv-guix-packages-base-modules.drv whose store path is different on your machine B (that does *not* get substitutes). It looks like these 'guix pull' derivations (not only guix-packages-base-modules.drv) are almost completely different on system A and B. Regards, Nigko [1] https://guix.gnu.org/en/manual/devel/en/html_node/Getting-Started.html [2] https://guix.gnu.org/en/manual/devel/en/html_node/Substitute-Server-Authorization.html
