IRC channel logs
2023-05-10.log
back to list of logs
<zacchae[m]>I have packaged a program that is built with cmake using the cmake-build-system. Normally, the next step would be to 'pip install' one of the directories in the source tree (desired output is a python package). Should I try to add python commands to a new build phase in cmake, or try to incorporate the existing python-build-system somehow? <Kabouik>Can I pause a long-running guix process? I would need the cpu now, but do not want to waste what guix has started (but not finished) to compile. <Kabouik>^z does not seem to free any CPU load. <zacchae[m]>The former sounds easier: I can create a directory lib/python3.10/site-packages and use that as an installation prefix, but how do I ensure that this directory is included in the output? <ulfvonbe`>mmm, it might stop it eventually if the build output fills up the daemon pipe's buffer after the daemon fills up the client socket's buffer <Kabouik>.You are right ulfvonbe`, I just needed to wait longer, thanks. <lemos[m]><lemos[m]> "still on the update saga" <- but, why does guix show -L does not show the package i changed? <lemos[m]>i add the dir guix/gnu/packages from the clone <lemos[m]>btw, still kinda confused on where should i read, i passed some time updating another packages from the project meanwhile <zacchae[m]>Not sure about -L flag. Should work with the ./pre-inst-env in your clone <lemos[m]>this ./pre-inst-env should be used for anything done under the clone? <zacchae[m]>yeah. Then you would use only the clone, and not your install version <zacchae[m]>^ make sure you read the page before it (building from git) in detail or it won't work <zacchae[m]><zacchae[m]> "The former sounds easier: I..." <- I suppose my question is more general: Many things from the build environment (e.g. the source code) are not included in the final output. Where do I put things for them to be included? Is it absolute paths? Would I install to /lib/python3.10/site-packages inside the build daemon for them to end up in /gnu/store/.../lib/python3.10/site-packages outside the build daemon? <podiki[m]>I think depends on the build-system, but usually something like a lib/.... paths will be installed yes <podiki[m]>bin, share, that sort of thing I've never had to manually "install" unless it is something like copy-build-system or a more manual one like that <podiki[m]>and you can do something like (mkdir-p (string-append #$output "/lib/blahblah")) in a new phase if you need to <zacchae[m]>podiki: Thanks. cmake-build-system puts you in build/, so I guess I could place things in ../lib? I'll try that if my current attempt fails. Currently, I am trying to use (assoc-ref outputs "out") similarly to the method used in guix/build/python-build-system.scm <podiki[m]>yes, you can look at packages with multiple outputs to see what they do <podiki[m]>I haven't done any cmake ones recently so you can try a few things or search through cmake built packages to see examples of what you may need <apteryx>rekado: did you manage to access to node 129? <zacchae[m]>podiki: I tried looking at the opencv package (similarly compiles with cmake and has python bindings to install), but I couldn't figure out how it was installing the python portion (must have been wrapped up in (c)make) <zacchae[m]>I'm not trying to have multiple outputs, but that probably is the "right" way to do what I want. <podiki[m]>well in that same module, look at paraview, it has an install-license-files phase to manually copy over files that might be what you want <zacchae[m]>ValueError: ZIP does not support timestamps before 1980 <zacchae[m]>^ I had this error once, and someone told me to add a (setenv ...) that magically fixed it <zacchae[m]>Anyone know how to fix this? It's only a problem inside the build daemon <apteryx>if like me your a poor soul without a static IP and stuck with a frequently-changing IPv4 <apteryx>perhaps I can finally stop micro-managing exposing remote ports with reverse SSH connections <zacchae[m]>Maybe (setenv "SOURCE_DATE_EPOCH" "1683681503") will do the trick. <podiki[m]>zacchae: try looking at ensure-no-mtimes-pre-1980 from python-build-system maybe <zacchae[m]>podiki: Thanks. That seems better than setting SOURCE_DATE_EPOCH <ulfvonbe`>tests/builders.scm seems to fail with a bunch of "building of `/gnu/store/jwgl5fgdkh8gfq64jvqz272mrzn63lvk-gcc-11.3.0.drv' timed out after 600 seconds". Did someone really change the timeout to 10 minutes? <ulfvonbe`>seems tests/gremlin.scm is failing - apparently a lib/libgcc_s.so.1 is being found by file-needed/recursive that isn't being found by LD_TRACE_LOADED_OBJECTS <ulfvonbe`>;; Make sure we don't end up rebuilding the world for those tests. <ulfvonbe`> (set-build-options store #:timeout (* 10 60))) <ulfvonbe`>if building python and its dependencies in advance is a requirement for the tests passing, that should probably be documented somewhere <zacchae[m]>neither (setenv "SOURCE_DATE_EPOCH" "315619200") nor 'ensure-no-mtimes-pre-1980 seemed to work :( <chomwitt>Goodmorning. During installation and since my guix profile is in my home folder doest that change a partition scheme of a seperate system and home partition ? <zamfofex>Your home directory only has a symlink to the profile on the store. <chomwitt>i see. But even then what if in a new installation i keep that home partition ? <zamfofex>I’d assume so. Though it should then override these symlinks on system installation or e.g. `guix pull` <chomwitt>ok. i guess i'll test it. Maybe rm all my guix-store before a new install ? <zamfofex>You can just choose to format the partition. In any case, depending on how you test it, it might “just work” because the store directories would have the exact same names. <chomwitt>in my use case i want to keep home partition intact <rekado>apteryx: I don’t have my SSH keys on berlin, but I can connect to it by proxying through ci.guix.gnu.org <jpoiret>chomwitt: you can export a manifest of your profiles and rebuild them reproducibly with guix <jpoiret>no need to keep the actual links, guix can just make them again <carmenshea[m]>jpoiret: Are you referring to the manifest file locate in $HOME/.guix-home/profile/ ? <jpoiret>no, this is unfortunate but there are two kinds of manifests in guix, the internal format and the user-facing format. That's the internal one, not meant for consumption by guix commands directly <jpoiret>you want `guix package -p /some/profile --export-manifest` iirc <jpoiret>that manifest will be useable by `guix package -m /some/manifest.scm` <jpoiret>for guix home though you don't need to export the manifest, the guix home config replaces it <rekado>apteryx: the problem was with the default route <rekado>apteryx: node 129 had a default route through the internal network <rekado>so incoming external communications were responded to over the internal network, and then filtered by the firewall <rekado>this fixed it: ip route replace default via 141.80.181.1 <rekado>now I can reach node 129 from the outside as 141.80.181.41 <ennoausberlin>Hello. When doing guix pull - the phase building package cache takes more and more longer (since a few weeks). Is this normal behaviour? <ennoausberlin>And the process guix repl -t machine eats more than 21 GB of RAM <rekado>ennoausberlin: is this with just the guix channel? Or do you have other channels enabled? <rekado>and without that channel does guix pull exhibit the same behavior? <ennoausberlin>I will have to test it. Right now I am checking for cyclic dependencies. <rekado>is someone looking into this? Or should I restart cuirass? <cbaines>civodul has been making code changes at least, I think to fix things <cbaines>although I'm not sure if they were berlin specific problems <rekado>I wonder if the problem reported by ennoausberlin is just a different side of the same problem <ennoausberlin>rekado: Without my channel included guix pull runs just fine. My channel has around 60 packages. Mostly python. My first suspicion was pytest, but it is not, because I use the original one now <rekado>maybe you can take a look at the derivations that are giving you trouble and look at the code <rekado>see if you can reproduce this manually <ennoausberlin>rekado: I might split the channel into halfs to find the problematic one. I hope it is only one package <jpoiret>we don't provide a regulatory db for our users, and so they might be breaking their local laws <jpoiret>ah, apologies, seems that it is loaded later by a udev helper, my kernel was spewing out an error on boot and never anything else so I just assumed it wasn't doing it at all <RavenJoad>I am having some trouble making a development environment for some Erlang testing. I want just erlang and erlang-proper (along with rebar3) available inside the shell, but rebar cannot pick up the erlang-proper library. ERL_LIBS is not set when the shell is made? Can I add that somehow? <RavenJoad>By add, I mean have it stored in the package or manifest used to build this shell. <RavenJoad>jpoiret: So I can just drop that scheme snippet in the manifest? <jpoiret>RavenJoad: no, the thread mentions that there's no good solution for now unfortunately <RavenJoad>That's what I was thinking when I read the thread. Ok. At least I can set ERL_LIBS manually for now. When doing that though, I get a rebar error. Though that might be from my misuse of rebar too. <Parnikkapore_m>I guess the header files are not large enough for a dev output to be a thing <apoorv569[m]>I can't seem to find a lot of other deps.. like libasound lilv-utils sordi libcurl-gnutls mesa-common... <civodul>apteryx & whoever might be concerned: i'm reconfiguring berlin so we get a working Cuirass <civodul>then i'll be ready to extinguish the next fire! <civodul>efraim: howdy! what was the story with rust-bootstrap on aarch64? :-) <civodul>hmm on berlin "herd status nginx" says it's stopped but nginx is running <bdju>does pip work on guix? I'd normally not even try, but I'd like to get a certain program working asap <bdju>it's needed to use a piece of hardware I bought recently <bdju>I just chucked it on the guix wishlist as well but things on there tend to not get packaged all that quickly <bdju>(I realize I could help with that issue if I learned packaging, but that probably won't be happening in the near future) <jpoiret>should be very easy to package, only needs python bindings to qt6 apparently <jpoiret>ah, and around 5 libraries that we probably already have packaged <ennoausberlin>bdju: The pypi version seems uptodate. I will add it to my channel to see if it build and let you know <bdju>thanks, both of you, for looking into it <cbaines>dammit, looks like the i586-gnu derivations have gexp's in them again :( <chomwitt_>guix describe displays commit: xxx.... How can i found that commit in git.savannah ? <efraim>civodul: It builds, it just takes a while. I built the entire chain myself <ennoausberlin>bdju: I just build the console version of flashgbx and trying the qt version now. I will put the package definition to pastebin <bdju>ennoausberlin: awesome! thank you very much for your effort on this <ennoausberlin>bdju: The qt version pulls in a lot of packages. It might take some time to build. <bdju>okay, that's understandable <bdju>it's still early in the day for me so I will be around a while <ennoausberlin>This is the qt version. For the console version just remove python-pyside-6 from the inputs <bdju>I added guix packages and guix download but it needs more <bdju>flashgbx.scm:9:18: error: pypi-uri: unbound variable <bdju>how would I find the use-module needed for pypi-uri? <bdju>added gnu packages python. now the hint recommends guix build-system python. getting there... <chomwitt_>why in a fresh install /gnu/store has a many package's files and conf files and $HOME/.guix-profile doesnt exist ? <bdju>> flashgbx.scm:26:11: error: license:gpl3+: unbound variable <rekado>chomwitt_: /gnu/store is a big cache <rekado>chomwitt_: $HOME/.guix-profile only exists after “guix install” or “guix package -m” is run. <ennoausberlin>bdju: I have all the modules in my channel file. I will paste the relevant parts <rekado>bdju: you probably don’t import (guix licenses) with the license: prefix. <rekado>bdju: in that case just use “gpl3+” <rekado>civodul, apteryx, efraim: kreuzberg is back in the data centre and ready to build stuff for aarch64. Cuirass, however, doesn’t have any tasks for them. <bdju> http://ix.io/4vAo this is what I'm trying now and my current error is: guix package: error: cannot install non-package object: #<unspecified> <bdju>I looked at another local file package I had to figure out the license thing and then rewrote the use-module part in a different format but I must have done something wrong <bdju>oh, thanks. I'll try this <ennoausberlin>These are all modules my channel uses. You probably dont need all of them, but I can not sort them out now <rekado>oops, I spoke too soon: reboot: HARDWARE PROTECTION shutdown (Temperature too high) <rekado>ACTION moves the machine closer to the cold aisle… <bdju>ennoausberlin: hm I'm getting the same error <apteryx>civodul: awesome; you could pinpoint the new Cuirass issue? <bdju>guix package: error: (#:prefix license:): source expression failed to match any pattern <chomwitt_>rekado, as a decade old debian user i am disoriented. As i get it gnus/store it's a system-wide available packages and each user could on that base install packages that only she/he will see ? <apteryx>rekado: I don't have my SSH keys on berlin either but you can use "ForwardAgent yes" in your .ssh/config <apteryx>node 129 seems to now be reachable from the Internet :-) <bdju>ennoausberlin: is something mistyped in the modules section? <bdju>I don't really know guile so I don't have the eyes for this <ennoausberlin>bdju: Then just use (guix licenses) as module and (license gpl3+) in the package definition <apteryx>rekado: that's very good news, thanks for fixing the access <bdju>but I notice if I jump from the first paren to the one that should match it, it puts me at the endof the license line instead of the whole modules block <apteryx>rekado: was it a cable, or you needed to change something in the configuration of the machine? <ennoausberlin>bdju: Yes the leading paren was missing in the modules line. Copy and paste error. But just use the way I mentioned above <cbaines>sounds like it was reachable, but couldn't talk back due to a configuration issue <bdju>ughhhhhhhhhhhhhhhhhhhhhhhhhhhhh <bdju>flashgbx.scm:56:0: error: flashgbx: unbound variable <bdju>I think I have to rewrite the whole top section <bdju>to be inside some other defined module <ennoausberlin>bdju: I have a very rocky connection to my guix machine due to some companys proxy settings. So I can not easily copy paste using webvnc <apteryx>cbaines: ah, I had missed that message, thanks <bdju>hm I added the (define-module (gnu packages flashgbx) line and then put #:use-module before all the use-module lines but the error didn't change <bdju>updated places I wrote flashgbx to say python-flashgbx <bdju>now I have conflicting entries in my profile for python-dateutil. I'll see if I can figure that out <ennoausberlin>bdju: The first package is always the hardest:) And the syntax to is slightly different for packages defined in a channel and local-file-packages <ennoausberlin>bdju: Just update to conflicting package - guix package -u package-name or try the new one with guix shell <apteryx>rekado: I'll add the default route config to deploy-node-129.scm, thanks <bdju>gajim has a build failure and now I'm getting a million conflicts as I try to skip more and more packages during upgrades. this sort of things happened a few days ago as well. very frustrating. <bdju>I'll try just upgrading the one package I guess <bdju>upgrading python-matplotlib has a conflict and recommends also upgrading... gajim. yep I'm stuck. <attila_lendvai_>i get slow dl rates from the subsitute servers in the last few days. is it my connection, or is it something with the servers? <ennoausberlin>bdju: You can have more than one version of a piece of software on your system, but not in the same profile. They are conflicting now. <bdju>well the fact that gajim doesn't build is a bug and the fact that I get conflicts trying to skip upgrading it is my current problem <bdju>I reported a gajim build failure <bdju>it just so happens that is preventing me from doing other things <cbaines>attila_lendvai_, I'm mostly interested in bordeaux.guix.gnu.org, but if you could share some output from wget downloading the things that you find slow, that might be helpful to understand what's going on <rekado>oof, kreuzberg keeps dying a heat death <apteryx>civodul: re nginx on berlin 'reload' also hangs... <bdju>wait I reported this on the 22nd. I wonder if it's the same problem or a new one <ennoausberlin>bdju: As soon as qt is build I will try gajm. Never used it before <bdju>I can't tell if my mail sent. it's in my sent dir but I can't find it on the web ui and I didn't get a confirmation email. I had issues reporting a dolphin-emu build failure the other day as well, but that at least was visible on the web ui <bdju>trying tor efine by date in the web ui seems to just not do anything at all <attila_lendvai>cbaines, how can i get a http url that i can use for testing? all i see is the package name (as output by guix system reconfigure). and https://bordeaux.guix.gnu.org doesn't provide a search either. (the page opened rather slow, too) <cbaines>are you sure you're not building things? <cbaines>if you have a store path though, I can give you the corresponding download URL <attila_lendvai>cbaines, yes. what i see is: guix-1.4.0-6.dc5430c 45.9MiB 133KiB/s 03:20 ▕██████████▏ ▏ 56.8% <cbaines>attila_lendvai, further up though, do you see the full URL? <attila_lendvai>cbaines, i tried the url you gave above with wget, and it's around 50 KB/sec. <cbaines>attila_lendvai, I think my internet connection is pretty bad, and I get 2.01MB/s for that file <attila_lendvai>cbaines, no. maybe you have some extra verbosity enabled? i see "1,449.7 MB will be downloaded", and then lines like the one above. <cbaines>bordeaux.guix.gnu.org is in Bordeaux, France. Roughly where are you downloading from? <attila_lendvai>cbaines, i'm in hungary, central europe. probably it's my connection then, not the servers. <ennoausberlin>bdju: If you can not wait until gajim is fixed, you can run guix edit gajim and add the 2 missing inputs python-wheel and python-idna. And probably disable the test phase if there are other problems popping up <rekado>kreuzberg is shutting down again <rekado>I get a lot of these: failed to read out thermal zone (-61) <bdju>ennoausberlin: I thought that guix edit opened things read-only <ennoausberlin>bdju: I am not an expert as well, but I like the idea of reproducible software and step by step I change my projects the guix way. But the start is hard. Don't give up :) <apteryx>civodul: are you reconfigured with custom fixes or current master? <bdju>I have actually been using guix for over 4 years, I just never learn and the pains continue <ennoausberlin>bdju: Yes but you can save it to a file, if I remember correctly <apteryx>ACTION catches up with guix-sysadmin list <civodul>apteryx: see "guix system describe": it's current master of Guix and maintenance.git <apteryx>and thanks for fixing that high impact bug! <bdju>I'm not sure what I'd do after saving to another file. I don't know how to use guix shell with the .scm I was working on. it really is tempting to just use another computer/OS at this point <civodul>apteryx: yw! apparently we have a couple of successful evaluations already, just not in the 'master' jobset yet <cbaines>attila_lendvai, ok, are you able to download more quickly from other servers? <ennoausberlin>bdju: You can still do the normal python3 -m pip install FlashGBX. You can run it from /home/user/.local/bin then <bdju>>ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts. <bdju>I have never had good luck with pip <bdju>buku requires some dependencies I don't have it seems <bdju>not sure if I pip install those or guix install htem <bdju>more errors trying to pip install them <ennoausberlin>bdju: A lot of python projects are packaged in a strange way. Over the years Python had at least 3 variants to do this and it is a mess <rekado>turns out some weirdo pushed a SATA cable so far into the enclosure that it touched and blocked the CPU fan… <efraim>I guess now you have to stand there forever and blow air on the CPU. or pull it back a bit <rekado>the dangers of switching to NVMe! Dangling SATA cables. <macrocreation>Wow! After over 42 different builds and 3 days. I finally got freeswitch to compile in guix! What a journey <apteryx>macrocreation: that sounds interesting :-) <macrocreation>Are there any core guix people here who could meet in london so I can fix the 'bypasses' I made. <macrocreation>Learning guix I have realized is like going from copying files to a backup directory for version control, and moving to git. It's serious effort - but it is so worth it. <bdju>ennoausberlin: thank you for all your efforts to help, it seems I'm having bad luck lately. hopefully gajim can be fixed for everyone soon and then I can just guix pull and get this going <ennoausberlin>bdju: I am quite sure, flashgbx is running in guix. It was working without qt6, the qt6 version still builds on my machine. Don't know why there are no substitutes. <ennoausberlin>bdju: I will see if I can create a .scm file for you extracting the relevant parts from my channel. But I will do it from home. The companies proxy is hell <apteryx>macrocreation: freeswitch service for a self-hosted phone system when? <apteryx>well, we already have jami-service-type for video conferences, but connecting to the plain old telephony system via a self-hosted freeswitch is appealing to me <apteryx>Currently I use Jami with a SIP <-> POTS gateway service (voip.ms) for that purpose <apteryx>we may need a telephony-team soon ;-) <apteryx>strange, 'guix deploy -L modules deploy-node-129.scm' from berlin (having forwarded my SSH keys with "ForwardAgent yes") gets stuck on "guix deploy: sending 86 store items (37 MiB) to '141.80.167.186'..." <apteryx>ah, I'm guessing I need '--no-substitutes' to avoid it hanging up somewhere <andreas-e>That sounds like the offloading bug that civodul fixed, hanging on sending things via ssh. <apteryx>now everything seems to have been sent, but it's still hanging up: guix deploy: sending 0 store items (0 MiB) to '141.80.167.186'... <apteryx>inetd style sshd makes debugging hard, I find <apteryx>by the time I found the right PID the important syscall chatter is already finished <apteryx>not sure what "goal destroyed" means or if it's a problem <andreas-e>It comes from nix/libstore/build.cc. It simply means that the destructor of an object of type Goal was called. But I also do not know whether this is a problem :) <andreas-e>I would assume not, and that it simply reflects that something has been built, see the "...drv: done" before it. <evilsetg[m]>Does anybody else get an error when trying to run icedove? I get a symbol lookup error for glibc with `undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE` <evilsetg[m]>Pulling and updating did not fix this unfortunately. <apteryx>try updating your system, your profile, then rebooting <apteryx>sudo guix system reconfigure your-config.scm && guix upgrade && sudo reboot <apteryx>the new guile-gnutls doesn't build for me: 'Unbound variable: protocol/ssl3' <apteryx>it does if I 'guix build guile-gnutls'; curious <cbaines>apteryx, I think the update I pushed broke cross building <apteryx>ah, that must be it, I have a hurd-vm-service in there <apteryx>cbaines: I confirm the guile-gnutls update broke the i586-gnu cross build <andreas-e>The ninja/doxygen build failure by cuirass for aarch64 I mentioned in one of my emails is spurious; in fact the package is there, and just restarting the build adds a green dot to do dashboard. <andreas-e>Since the aarch64 machines of berlin are mainly idle right now, I will push the "Restart all builds" button now. <apteryx>reconfiguring node-129 locally worked <apteryx>I'm rebooting it to see if the networking change sticks <cbaines>haha, good job building that Cuirass :) <cbaines>substituter-succeeded /gnu/store/9nmzlkqy4zlqghshwwvxagk7crw99jmg-rust-1.67.1-rustfmt <efraim>guix weather rust --system=aarch64-linux shows success on berlin also <andreas-e>Exactly, it was already there, just not registered by cuirass. <andreas-e>I am not sure what the "Restart all builds" of cuirass button does. This time it added about 60 builds to the queue of 70. Does it only restart jobs that changed from the previous evaluation? <apteryx>andreas-e: if you find out, please document it to the cuirass.texi manual :-) <andreas-e>If this were true, it would have to be changed... <efraim>I always thought it restarted _ALL_ the builds, failed or not <andreas-e>Here I go from 73 to 136 with the latest evaluation of master. <andreas-e>However, there must be thousands of red dots for aarch64. <GNUtoo>Hi, my guix build is stuck in "po4a-translate is deprecated. The unified po4a(1) program is more convenient and less error prone." for several hours, is there a way around that? <andreas-e>This failed build dates from May 7 and has not been restarted by the button. And it is this spurious ninja failure. <andreas-e>So I am quite optimistic the build will go through. <andreas-e>GNUtoo: I do not know. When something like this happens to me I usually end up with a "make distclean" and a new configure run. These translation related things can take an awful lot of time, but rather minutes than hours. <GNUtoo>ACTION did git clean -dfx and -dfX <GNUtoo>Ah I see similar lines but now it seems to go through, thanks a lot <andreas-e>I think the lines are just harmless warnings. <GNUtoo>Yes indeed but it's the only way I have to refer to the blocking issue <GNUtoo>(something blocks and I don't know what) <GNUtoo>And what blocked seemed to be related to some translation stuff <GNUtoo>Though I also had a patch for the manual so maybe it's that patch that breaks things <GNUtoo>Hmmm, it blocks again, and after reverting it it still blocks <GNUtoo>Maybe I should wait a bit to be sure though <elevenkb>hello there, what is the recommended way to work on a haskell project using guix? <GNUtoo>hmmm it's just slow it seems, but not as slow as before <apteryx>andreas-e: ah, you bypassed tls auth via ssh, I see <andreas-e>apteryx: You mean for restarting builds? Yes, I use the ssh tunnel approach. <apteryx>since cuirass does not itself provide authentication, does it mean that I'm supposed to be able to do any action with my local cuirass instance if I haven't configured anything authentication related? <apteryx>berlin makes use of nginx configuration to force TLS client cert verification on the /admin pages/enpdoints <rekado>apteryx: yes, authentication is only done by the proxying server <apteryx>OK; strange, restarting things don't seem to work for my local instance. I'm accessing it remotely via wireguard (so not from localhost) <apteryx>is admin somehow block from remote hosts in its default config? <apteryx>no; I guess I'm looking at some quirk <apteryx>ah, Channel changes goes from guix -> a759cbf to None. They previously were shown as "Aborted" because of the guile-fibers bug fixed by the update earlier. <apteryx>doesn't look like they can be salvaged <apteryx>do I understand correctly that Cuirass is still taking care of the actual web service and simply proxied by Nginx? <chomwitt_>is there a page explaining the $PATH components .like /run/current-system/profile etc. ? <apteryx>the ssl_client_verify trick requires that the site be served via HTTPS, right? <jonsger>hm, the check phase of guile-g-golf seems to hang endless after `PASS: tests/gi.scm` <pmf[m]>I don't know whether this is officially condoned or not, but I still manage all of my emacs packages with straight completely separately from the rest of guix. That way I can bring emacs with me even when guix isn't available. Then you could have different init files for the different profiles and put them in place with guix home. <pmf[m]>I don't know much about multi-profile setups to be honest, so take what I say lightly! <eroesch>What are the main practical differences in the ways that Nix and Guix manage the stores? <janneke>eroesch: nix writes to /nix, guix writes to /gnu <jpoiret>eroesch: I don't think there are any differences that matter <jpoiret>maybe nix now has some fancy new features but in general they're the same, it's rather the things that produce derivations which differ greatly! <rekado>here’s a stupid idea for a change in Cuirass: don’t show all failed tasks but only newly failed derivations. <rekado>clearly the commits were bad, right? <rekado>no, 4 packages are new successes, and there are no new failures <rekado>when I look at the quick stats in the list of evaluations I usually have no idea if we’re making progress or regressing <andreas-e>I thought this was already the case, since there were only 31, and we have thousands of failed builds altogether. <rekado>31 failures that were affected by the pushed changes since the last evaluation <andreas-e>Maybe packages that were retried because of a changed input? So an "affected" package, although the outcome is the same? <cbaines>I think rekado is suggesting filtering it to only show entries where the "weather" in Cuirass speak is: "New failure" <andreas-e>We definitely need a way of comparing evaluations! <cbaines>the comparison functionality exists, it's just in the data service <cbaines>it doesn't take in to account ci.guix.gnu.org builds since it just doesn't know about them <andreas-e>Ah. I think I confuse build coordinators and data services... <andreas-e>Could the data service be made "meta" and treat ci also? <cbaines>it's not a "treat" issue, Cuirass simply doesn't tell the data service about builds <cbaines>the build coordinator does (ironically using the interface I implemented for Cuirass) <efraim>https-everywhere browser plugin? <apteryx>efraim: I have it but I disable it for the page, then globally <apteryx>so what happens to the authentication business when users consult the ci.guix.gnu.org over HTTP only? <efraim>it fails to authenticate somehow, it needs to be over https <apteryx>so the ssl_clietn_verify would fail by default when using HTTP in "if ($ssl_client_verify != SUCCESS) { return 403; } proxy_pass http://localhost:8081;" ? <chomwitt_>it seems .. that /run/current-system is like a 'variable' root . By changing to where its contents link to we 'could' get a different system <chomwitt_> '/run/current/system/etc/bashrc --> /gnu/store9x...-bashrc but the same file is in /etc/bashrc . i dont understand why the two copies <chomwitt_>except if what we see as root is an instantiation of /run/current <efraim>there are no emails stuck in the queue, I'm looking at the page now <mirai>it will interpret a totally bogus IP (like [1::2::3] and '/not-a/host_name::3') as a hostname <chomwitt_>why after a guix pull . guix describe show the same commit number as before? <jpoiret>chomwitt_: what's `command -v guix`? <rekado>guix pull updates ~/.config/guix/current/bin/guix <rekado>it also prints something about making sure to use that command by setting environment variables <jpoiret>civodul: are you looking into the cross-compilation issue with guile-gnutls? Don't want to duplicate effort but I can also work on it <jpoiret>it's blocking my investigation of our Hurd problems <civodul>jpoiret: i'm not! i proposed a solution in one of the issues about it <civodul>anyway, just: (define protocol/ssl-3 (and (defined? 'protocol/ssl3) protocol/ssl3)) <rekado>Python packages built with the pyproject-build-system sometimes don’t get their version right. <rekado>you can notice this only during the compile-bytecode phase <rekado>when it produces something like name-0+unknown.dist-info <rekado>wasted a lot of time just now with test failures in a downstream package, only because it used a version comparison and found 0+unknown to be old, and thus expected legacy behavior <rekado>this can happen when packages use versioneer or other means of computing the version string. <lilyp>yeah, python packages can be very stupid about their version string <lilyp>I guess we should needle the version as provided by Guix into the build <lilyp>(same goes for Emacs packages btw. which use arcane magic to determine their version atm) <apteryx>rekado: do you know if it's important that the certificate subject matches for the CA key and user certs? <apteryx>if it does, having an hard-coded "/C=DE/ST=Berlin/L=Berlin/O=GNU Guix/OU=Cuirass/CN=~a" in a general purpose script is less great :-) <apteryx>mirai: OK; my goal was not validating the input but telling apart IPs from host-names <apteryx>I have a feeling that trying to validate IPv6 is a can of worms to open ^^ <civodul>with qemu/9p, did anyone experience things like: "/gnu/store/fcr15x4qm7lxg08yxh70wscywpk9fmp7-bitlbee-3.6/sbin/bitlbee: error while loading shared libraries: libm.so.6: cannot open shared object file: Permission denied\n" ? <civodul>where the loader inside the VM randomly fails to load shared libs? <mirai>apteryx: you make it some else's problems i.e. getaddrinfo or inet_pton <apteryx>I'm fine with that for my use case :-) <jpoiret>civodul: sorry, just saw your answer, won't (eval-when (load) ...) also work? <jpoiret>I don't like that the variable can be set to #f, and eval-when seems like the more reasonable solution to me <civodul>thing is, at run-time the RHS will always be defined <attila_lendvai>cbaines, the curlpit is indeed my network connection. sorry about the noise! <chomwitt_>After installing xorg-server and xinit, i do $ startx , but xinit complains unable to run server /gnu/store/XXX-xinit/bin/X . But looking at xinit store file indedd no X server is there. Why xinit would look there? <janneke>jpoiret: just "found out" that you updated the hurd, amazing and thanks! <janneke>jpoiret: i noticed that you explicitly disabled rump, have you tried/considered building with rump? <bdju>FML. Sway crashed and now I'm in a login loop at the TTY, it just keeps making me log in again. <bdju>every TTY acts the same, can't login <bdju>please how can I fix my TTYs <bdju>after a rollback how do I go back to a future generation? <bdju>it is way too hard to stop a failing dependency from building when you don't know what it's a dep of <bdju>python-pyside-2 won't skiu <guixfren>a number of packages I need seem to be missing <guixfren>an unusual number that is, and it has been that way since yesterday <unmatched-paren>guixfren: the core-updates branch was merged very recently, meaning a lot had to be rebuilt <chomwitt_>ChocolettePalett, the xinit custom script worked! Packages: xf86-input-libinput xf86-video-fbdev were crucial . <jonsger>ACTION still working on updating telegram-desktop. It's a tricky one... <chomwitt_>well..almost. i dont have any input.. mouse or keyboard..