<EuAndreh[m]>marusich: I couldn't you it either even with `/nix` already created, it says that `/gnu/store/...` is not in the Nix store <marusich>EuAndreh[m], so, it's not really satisfactory, but I have done this in the past to get an idea of what's inside the .drv files: <marusich>cat /gnu/store/svr913zcivi2h8qj3sgnwxprnldfbfw4-nix-2.0.4.drv | tr , '\\n' <marusich>For system tests, is it guaranteed that expressions evaluated via marionette-eval will be evaluated after all the services are up? Is it possible that if I check to see if a service is running using marionette-eval, it might sometimes say the service is up, and sometimes say it is not, depending on the timing of marionette-eval? <mbakke>marusich, EuAndreh: Try opening it in emacs :) <marusich>mbakke, that doesn't do anything special for me; it's just one huge line. <marusich>Are you using some sort of pretty-printer? <mbakke>Oh. You'll probably need emacs-guix. <mbakke>EuAndreh: Oh, I see. Don't think we have that, but looks useful. <a4969>I have a problem: guix package error hint: Try upgrading both gtk+ and libglade or remove one of them from the profile. <a4969>I issued guix pull, then guix package -u <mange>Do you have both gtk+ and libglade installed in your profile? Or did it give you some output as to the root cause of the issue? <a4969>Hi mange. I have both installed. <mange>From memory, -u just checks based on version numbers, so you can have two different builds of the same version of something (so they have a different hash in the store). This is fine, except that they can't both be installed into the same profile. To fix that you should be able to run guix package -i gtk+ libglade. <mange>Do you need both installed in your profile? I feel like they would usually be pulled in by software that needs them in a way that won't conflict like this. <a4969>I may need to have both but need to test to be sure. Is the current state of the profile blocked from updating because of this? <a4969>IOW -- what are the consequences? <mange>You can use --do-not-upgrade to leave them as-is. <mange>Or you can use guix package -i gtk+ libglade, then guix package -u. <a4969>The above cmd installs the packages. But they are already installed! <mange>Yes, but it will install the current version of both, which will be consistent. <mange>At the moment it's trying to upgrade one, and not the other, which is causing a conflict. <mange>I would need more details from the error message to tell you exactly what the conflict is. If you post a paste (see the channel topic), I can try to interpret it for you. <a4969>Does guix log its output somewhere? <mange>Build logs go into /var/log/guix, but the stdout of running guix at the command line won't be saved for you. <a4969>TFTInfo... standy by for more details. <a4969>May take some time, I had started guix pull. <a4969>profile contains conflicting entries for gtk+ // first entry: gtk+@3.22.30 <a4969>... propagated from libglade@2.6.4 <a4969>I need to keep 2.24.32 though <marusich>a4969, I don't think you can have multiple versions of the same software component in a profile. If you need another version, put it in another profile. <mange>Yeah, so libglade isn't being upgraded by guix package -u (because it's version is the same). You should be able to fix it with guix package -i libglade -u. <marusich>See the "--profile" option. Manual section: (guix) Invoking guix package <mange>Oh, wait, sorry, I misread. What I said is wrong. <a4969>I would like to remove gtk+@3.22.30 and keep gkt+@2.24.32 and libglade. <mange>Yep! `guix package -r gtk+` will remove 3.22.30, and `guix package -u` should then work. <a4969>Argg, that removed the gtk+@2.24.32, which I wanted to keep. <mange>libglade should bring in gtk+ itself. <mange>You shouldn't need to manually install it to your profile. <a4969>I had installed both gtk+2 and libglade as deps for geany. <a4969>my geany build is able to run, so it seems that mange is correct <a4969>I have many warnings about collisions encountered. Is this expected? <mange>You shouldn't have to install dependencies to get programs to run. Installing a package should pull in everything that it needs. <a4969>mange -- there is no package for geany, I want to create one. first, I needed to be able to compile and run. <mange>Ah, right. That makes sense. <mange>If you build a package for geany you should be able to compile it so you can install it without needing to have libglade or gtk+ in your profile at all. <vagrantc>wow. 'guix pull -l' just started reporting the new/upgraded packages <atw>hey mange, didn't know you did clojure too! <marusich>a4969, consider creating a separate profile for your development of the package. <mange>atw: I thought we talked about it back in February? Since then I have got a job in Clojure, though! <marusich>a4969, you can do something like "guix package -p custom-profile -i libglade" to install libglade into the profile. Then you can do something like 'eval "$(guix package -p custom-profile --search-paths=prefix)"' to "activate" the environment for your development purposes. <mange>marusich: Is using --search-paths the normal way to do that? I usually source $profile/etc/profile (which is the same thing, I assume?). <marusich>Alternatively, you can put the package definition into a file like "my-package.scm", and load it with "guix environment -l my-package.scm" <marusich>If you use "guix environment" like that, you can create an environment from the inputs of the package definition therein. <marusich>This is similar to using "guix package --search-paths" with a custom profile, except that it doesn't leave a persistent profile around for later use. <marusich>Another alternative is to just run "guix environment --ad-hoc libglade" to put yourself into an environment where libglade is available. <atw>mange: did we meet at FOSDEM? Where are you working? <mange>Yep! I wasn't there for FOSDEM itself, but I was at the Guix day the day before. I'm working for a "martech" company with a small-ish Clojure team with lots of .Net teams around me. <atw>funny coincidence, there are a number of C# devs at my work <vagrantc>(and generally, how would one find out?) <vagrantc>looks like it's in glibc ... but not available from my user profile? <mange>Yeah, I think it's in glibc. <mange>As for how to find that out, in general... I don't know. Ask here? <vagrantc>i've definitely had ldd available in my user profiles on a different system, butnot idea what pulled it into the profile <mange>I think gcc-toolchain pulls it in, too. <vagrantc>what exactly is the hash in /gnu/store/HASH-PACKAGE-VERSION ... hashing ... i know it's somehow a hash of all the inputs (propegated inputs and native-inputs too?) <mange>It's the hash of everything that's included in the build environment. That means {,propagated-,native-}inputs, which also includes the build system. <vagrantc>a hash of the entire diretory tree of *inputs ? <mange>It's actually the hash of the recipe to build the build environment (so the hash can be calculated without having to actually build anything). <mange>I don't actually know. :P I'm not familiar with the details, just the concepts. <mange>My assumption is yes, but that shouldn't be relied upon. <vagrantc>yeah, i have a rough conceptual idea ... but trying to get a little better grasp of the details as i'll be presenting about guix at the debian conference next week :) <vagrantc>and it's nagged at me not knowing in the past <blu3r4d0n>Hey you guys whenever I reboot I have to reconfigure for ssh to become availible onthe machine <vagrantc>blu3r4d0n: there's at least one bug about sshd not starting <mange>vagrantc: Looking at the code, it looks like the hash is the hash of the .drv file, but with each of the input deriviation files replaced by their hashes. See derivation-hash in derivations.scm. <blu3r4d0n>I see I've been having the issue since I first started using guix which was approx a week and a half ago <Digit>some day, i hope to have myself managed by guix... such that if should some calamity befall me, i can rollback, to being alive n well. <Digit>~ or worded better. ~~sleepy thoughts~~ <buenouanq>if only I could roll back this hard drive failure ;~; <vagrantc>mange: thanks for looking into it for me :) <mange>I was curious myself, so thanks for giving me a reason to look into it! <aerth>how to recompile 'st' in guixsd? needs some libraries <mange>What do you mean, aerth? As in the Guix package should be built with more libraries? <aerth>like i need x11 headers or something? <aerth>whats the guix way to compile 'st' <mange>It works fine for me. I just did `guix package -i st`, then I can run `st` and it pops up a terminal. <aerth>ok now try git recompiling after modifying config.h <mange>`guix build st` will compile it and place the result in the store. The last line of the output will be its store location. <mange>Oh, so you're compiling it yourself? Right, that's a different story. <mange>That's how suckless tools work, hey? <aerth>how do i build x11 programs in this <mange>Okay, I just tested and it's pretty straightforward. <mange>Basically, `guix package -i st --with-source=/path/to/st`. <mange>That will install it in the way that guix most expects, and will take care of your dependencies for you. If you really want to compile it yourself, you can use `guix environment st`, then run your usual compile commands within that shell. <mange>`guix environment st` will put you into something similar to a python virtualenv, but with all the dependencies you need to build st specifically. <mange>I also don't know how the --with-source trick will interact with package updates. It's possible if the st package gets updated, you'll have to re-run the installation using --with-source. <mange>The "most correct" way to do this would be to write a package definition for your version of st, with your config file. <aerth>k i havent gotten to defining packages yet <mange>Yeah, I just thought I'd flag it so you know for future. --with-source is the easiest way to go for now, I'd say. <aerth>'guix environment st' allows me to 'CC=gcc make' and now theres a binary <mange>Yep, but it's a binary outside of Guix's environment. That's probably fine, but you'll have to manage it (and potentially its dependencies) yourself. <aerth>i will copy/modify an existing package to figure it out <mange>You can even copy the existing st package, and point its source to a local directory with `local-file` (see "(guix) G-Expressions" in the manual). Or if you keep your st package in a git repository you can use that as the source (see "(guix) origin Reference" in the manual). <efraim>I really need to get a GuixSD shirt to wear to conferences <jonsger>efraim: got another suse shirt to day. But I also lack a Guix one :( <roptat>I'd like to have a Guix shirt too <sneek>civodul, you have 1 message. <sneek>civodul, snape says: done :-) You can reconfigure <civodul>wow quite a lot of commits this week-end :-) <roptat>e2fsprogs failed one test on armv7: "d_loaddump: debugfs load/dump test: failed" <roptat>ah rekado_, does berlin build substitutes from arm7 or aarch64? <efraim>rekado_: I'm getting connection refused when trying to connect back into my server, I can take a look at it when I'm actually at home later tonight <rekado_>roptat: berlin tries to offload to the two Overdrive hosts, which build for armv7 and aarch64. <rekado_>roptat: one of the Overdrive machines had a damaged power supply (don’t know if it’s back up again); the other had some network connectivity problems. <rekado_>efraim: hmm, has this ever worked? IT did update the firewall rules as requested. <g_bor[m]>Just a short status report: snape got involved in the Cuirass Web Interface project, that work is ready to merge. We did a database scheme migration on Cuirass, to facilitate the changes snape proposed. wip-java8 is also ready to merge to staging, waiting for feedback to mbakke if they does the merge, or I should. Not sure about the state of staging. Some errors still slip from ant-build system causing picard to claim that is <g_bor[m]>builds, failing dropseq-tools. roptat fixed some stuff in ant-build-system. <rekado_>this week I’d like to take berlin.guixsd.org offline for an hour or two to install the HBA cards and attach the storage. <rekado_>g_bor[m]: have you looked closer into why picard fails to build? I could do this later this week, I guess. <g_bor[m]>Actually not yet, I was also on vacation :) It looks like there is an issue with the manifest. <g_bor[m]>rekado_: I also have one more question regarding java8. The current patchset changes icedtea to icedtea8, but we also have ant. <g_bor[m]>I think we should also change that to ant/java8. WDYT? <rekado_>yes, the build system is only used after having built the last of the JDKs, so it makes sense to use the latest JDK for the default ant as well. <efraim>rekado_: got kicked off the network I was on, back on now, I have to believe it's worked in the past <g_bor[m]>rekado_: ok, I will leave that for the next round, so that we can make one change at a time. I will have a look at picard now. <efraim>civodul: from guile-gdbm-ffi build phase: wrote `/gnu/store/mcbikln71wpxs3fc6v0g4n4qzaz11551-guile-gdbm-ffi-20120209.fa1d5b6/lib/guile/2.2/site-ccache/./gdbm.go' <efraim>is the '/./' supposed to be like that? <roptat>is there a reason why e2fsprogs is still 1.43.6 instead of the current 1.44.3? <roptat>other than noone worked on it yet? <efraim>i see it 'looks nice' in the store and shouldn't matter, ignore the noise :) <rekado_>roptat: ISTR that an update somewhat recently led to a problem with initing systems…? <rekado_>or maybe this was something other than e2fsprogs <roptat>ok, it our version fails to build on armhf, so I thought it would be a good excuse to update to current version <jlicht>lots of interesting stuff happening with cuirass I see \\o/ <jlicht>the new guix pull is amazing and all that, but I still get the good ol' "missing interface for module (gnutls)"-message from time to time. I seem to recall this does not indicate any serious issue, but is there a way to hide this spammy message? <rekado_>efraim: ah, right. That was the one I thought of. <rekado_>jlicht: are you using Guix from ~/.config/guix/current/bin or some other (e.g. from a git checkout)? <jlicht>rekado_: ~/.config/guix/current/bin <demotri>I have a problem with icecat: "The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression." Any idea? Page: https://www.gnu.org/. Command: guix environment -C -N -u usr$RANDOM --ad-hoc coreutils findutils less grep icecat gzip --share=/tmp/.X11-unix/ <demotri>usr28822@host /tmp/x [env]# DISPLAY=":0.0" icecat <jlicht>rekado_: After issuing guix pull, and I think when compiling guix/ui.scm (from memory) <pkill9>demotri: you probably need the nss-certs package installed to the system profile <pkill9>(unfortunately due to limitations the path to the certs is hardcoded to /etc so it needs to be added to system profile) <demotri>pkill9: But I can see the green lock. Certificate is OK. Strange: www.fsf.org works. Now after restart in the container, everything works. Hm. Strange. <pkill9>oh whoops, i didn't notice you are opening it ina guix environment contianer <pkill9>installing nss-certs to system profile wouldn't have helped <demotri>pkill9: I'm on Ubunut and wanted to be extra sure to be in a clean and defined browsing environment. <g_bor[m]>rekado_: ISTM that we should change the manifest generation code in picard. It seems like the manifest and echo tasks don't work nicely together. It also seems that we need more control in this manifest than it is provided by the mainfest class, so we should stick to echo, essentially replicating the old functionality of the ant-build-system. WDYT? <civodul>efraim: the extra "/./" is not pretty but it doesn't matter :-) <civodul>improving it is left as an exercise to the build log reader ;-) <civodul>roptat: you can see home page issues with "guix lint -c home-page", no SaaSS! <rekado_>g_bor[m]: do we even need all the manifest generating code? Is generating the index not sufficient for recording classes? <rekado_>g_bor[m]: I thought the manifest now only needs to record the entry class for executables. <rekado_>jlicht: I think the messages are fine when compiling Guix. They are not okay when using, say, “guix import”. <jlicht>rekado_: The point is that I would like to hide these messages when using guix pull. Is this already possible via some environment variable? <jlicht>civodul: What is up with the "\\n" at the end of the description string for guile-pfds? Is this required for properly parsing the embedded texinfo commands in there? <rekado_>jlicht: I’d like to hide *all* compilation messages. <rekado_>we have two commits that add a colorizing soft port to guix/ui.scm that can be used to hide compilation output when using “guix package”. <rekado_>we might use something similar with “guix pull”. <jlicht>makes sense, and seems like an improvement if properly done. <civodul>jlicht: it's not required, i just find it "nicer" <civodul>mbakke: do we have an xorg-server upgrade in staging? <civodul>or actually we can prolly upgrade it in master, no? <efraim>i made some improvements to the qt-updates branch <efraim>maybe this time when I get fdroidserver building I'll submit it <mbakke>civodul: I'm not aware of newer xorg releases, but you should be able to patch it on 'master'. <civodul>mbakke: ok, i'll try the patch from the above bug report <mbakke>Ooh, only 44 files are not reproducible in Python 3.7. Down from ~500. <mbakke>efraim: Do you think we can merge qt-updates? <efraim>mbakke: I think qt-5.11.1 is a big improvement from 5.11.0 which was a mistake <mbakke>What are the problems with 5.11.0? <efraim>I saw python-scipy failed to build, not sure of that on master <efraim>5.11.0 removed one of the macros that many packages relied on <mbakke>Scipy has a habit of failing non-deterministically though. I just restarted the build. <demotri>efraim: Do you know if kxmlgui works again? <efraim>demotri: I don't remember, and I currently can't access the machine I was testing it on <efraim>before my latest update yesterday or so it wasn't, but I didn't check after that <mbakke>efraim: Do you know if python-poppler-qt5 is fixed? <efraim>mbakke: yes, that should be working now <mbakke>efraim: The branch looks ready to me :) <mbakke>Maybe coordinate a merge with civodul to stop the queue runner first. <mbakke>Nvm, Hydra seems fine. Are you around to merge it efraim? <efraim>androguard wants pyperclip, but install_requires only mentions it for a GUI <efraim>mbakke: I'm at a conference tethering from my phone, best not be me :) <mbakke>efraim: Oh, let's do it later then. Hydra still has some catching up to do for x86 anyway :) <roptat>when running ./pre-inst-env, I get line 8: /root/.config/guix/current/bin/guix: Permission denied <jlicht>roptat: did you perhaps build your git-checkout of guix using root (or maybe sudo?) <roptat>I'm running ./pre-inst-env as root too <jlicht>and the guix-command pointed to by /root/.config/guix/current/bin/guix exists and is executable? <roptat>./pre-inst-env guix build hello works <roptat>./pre-inst-env guix build e2fsprogs doesn't work <jlicht>what happens with when you try `<pre-inst-env> guix build --check hello' <roptat>it got the source from a substitute server though <roptat>while e2fsprogs doesn't (because I changed its definition to try and update it) <jlicht>very confusing. Maybe send your issue to help-guix? <efraim>primary or not, I don't see it as that much different than having mame in our repo <roptat>efraim: (find-files "." ".*\\\\.apk$") maybe? <efraim>rekado_: nope, but it doesn't take any time or give any output <efraim>no change in runtime with '.*' added <efraim>for sure there is in examples/tests <rekado_>“Unfortunately, the fundamentalist FOSS mentality we encountered on Reddit is still alive and well. Some Linux blogs and Podcasts simply won’t give us the time of day. This is not a problem with the mainstream tech blogs and is a problem unique to Linux. Thankfully, many publishers are OK with closed-source, paid-for software.” <efraim>find-files: examples/tests: No such file or directory <rekado_>efraim: check that you are in the directory that you expect to find yourself in. <jlicht>rekado_: I love how one paragraph ends with saying that there would not be enough things to offer support for, continued by the paragraph that it would take too much time and money to support different kinds of packages <jlicht>props to them for properly using (at least) the term proprietary, instead of mistakenly using the term commercial <efraim>ok, it looks like the pypi release stripped all the apks and tests ***ocharles_ is now known as ocharles
<roptat>efraim: I think our policy with binaries in sources would have lead us to strip them anyway <roptat>do you have a way to rebuild them though? <efraim>actually they show the location where they got a bunch of the apks from, so I could in theory download them from there instead <efraim>github.com/androguard/androguard/tree/master/examples/tests <jonsger>smfoo: that repo contains a lot of intersting slides/talks as well :P <smfoo>rekado_: oh, could i get them? :) <rekado_>I must have forgotten to push them to the maintenance repo. <smfoo>great! much appreciated rekado_ <rekado_>sorry about the delay. I thought I had pushed them back then. <jonsger>nice talk,btw. watched some parts of it :) <rekado_>when “guix challenge” says that it cannot challenge something because it has no local build, how can I create that local build? Is it enough to run “guix build --check --no-grafts”? <efraim>If there's no local build you shouldn't need --check <snape>rekado_: guix build --no-substitutes <mbakke>rekado_: Is it okay to delete the existing python-updates branch? <mbakke>It's tempting to simply remove the 44 .pyc files that are not reproducible in Python 3.7. <mbakke>Oh wait, I noticed PYTHONHASHSEED is not set. I wonder if that makes a difference. <efraim>I guess I should test python-3.7 on aarch64 <mbakke>efraim: I can submit the patch later. Or push a new python-updates. <efraim>Yeah, did it fail a second time? <efraim>I assumed it was an anomoly, it built fine on aarch64 <roptat>I've finally succeded in running guix system init on my arm machine \\o/ <roptat>it boots but it doesn't seem to do anything though <roptat>I just see some kernel messages, and my keyboard doesn't seem to be recognized <roptat>PotentialUser-93: yes, but the syntax for file system configuration has changed a little <roptat>guix will warn you though, so it should be alright <roptat>actually his configuration is for a bios system, not an efi one <mbakke>efraim: I built that commit much further than Hydra on the staging branch a while back. Don't know what's up. <divansantana_>guix gc results in error: build failed: executing SQLite statement: FOREIGN KEY constraint failed <PotentialUser-93>for creaing a efi one you need to create an EFI system partition with the disk partitioning programs lik cfdisk you need to execute the command parted /dev/sda set 1 esp on, mkfs.fat -F32 /dev/sda1 but how you do to mount the EFI SYSTEM partition to /boot/efi <roptat>mount /dev/sda1 /boot/efi I guess <roptat>janneke: it doesn't go very far... <roptat>and I don't have any debug output, so I have no idea what's going wrong <janneke>roptat: i got an arm account from a friend and i found binaries segfault, it's an armv7l <janneke>i'd like to get some more grasp on it and am glad OriansJ is doing some arm work <roptat>any idea what could be wrong or how I could get more debug output? <janneke>ACTION only now reads ... "keyboard doesn't seem to be recognized...' oops <pkill9>yeah just `mount /dev/sda1 /boot/efi` is what i do <roptat>maybe it's too early in the boot process for the keyboard <janneke>roptat: i think vagrantc did some uboot/arm work, but they're not here atm <roptat>I don't think it's a uboot issue though <roptat>I initialized the system with a newer e2fsprogs, maybe that's part of the issue <roptat>I mean I used a git checkout where I updated it because the current version doesn't build on arm <PotentialUser-93>for creating an EFI PArtitn you just need to create a 100M EFI System type partiton with cfdisk execut the commands if the EFI Patition is in sda: parted /dev/sda set 1 esp on, mkfs.fat -F32 /dev/sda1 and mount /dev/sda1 /boot/efi and if you encrypted root partiotn how do you set up the configuration template? <efraim>janneke: if its armv7 on scaleway it's not compatible with guix's armhf-linux <roptat>PotentialUser-93: decomment (mapped-devices ...) from the template <PotentialUser-93>can someone give me a listo f the changes i need to make to the configuration template for my case? <janneke>efraim: yes, scaleway -- is there a way [for me] to get a grasp on this? ARM support is dressed in magic for me <roptat>I think there's a template fro disk encryption <roptat>(it's the last template in this page) <roptat>with (mapped-devices ...) and (dependencies mapped-devices) in the configuration for the root partition <roptat>janneke: so I think I'll reflash the uboot from the distro I had and try again :) <PotentialUser-93>The configuration for a typical “desktop” usage, with an encrypted root partition, the X11 display server, GNOME and Xfce (users can choose which of these desktop environments to use at the log-in screen by pressing F1), network management, power management, and more, would look like this: <roptat>janneke: so with the origin uboot, it still boots the guix kernel, but still no luck <janneke>roptat: maybe post your story to guix-devel, efraim? <roptat>so it's probably not uboot's fault <efraim>janneke: wasn't too exciting, I fired up a scaleway armv7 server and used the binary install method and it quickly failed <efraim>turned out they don't have neon support, one of the few armv7 machines like it <efraim>their arm64 servers work for aarch64, but they don't have armhf support <efraim>that one is easier to check, 'linux32 uname -a' I think it was to test 32-bit support on machines <efraim>not sure fire, 'linux64 uname -a' doesn't error out on my rpi1 <PotentialUser-41>creating an EFI PArtitn you just need to create a 100M EFI System type partiton with cfdisk execut the commands if the EFI Patition is in sda: parted /dev/sda set 1 esp on, mkfs.fat -F32 /dev/sda1 and mount /dev/sda1 /boot/efi and if you encrypted root partitio0 and the root partiton is in sda2 do you use the second configuration template in this p <g_bor[m]>mbakke: What is the current status of staging? <kballou>is there a resource for looking up what packages have been requested and/or are being worked on? For example, is XFS(progs) package/support in progress? <kballou>furthermore, what's the state of targeting guixsd to LVM devices? the RAID support looks like it _should_ work... <PotentialUser-41>creating an EFI PArtitn you just need to create a 100M EFI System type partiton with cfdisk execut the commands if the EFI Patition is in sda: parted /dev/sda set 1 esp on, mkfs.fat -F32 /dev/sda1 and mount /dev/sda1 /boot/efi and if you encrypted root partitio0 and the root partiton is in sda2 do you use the second configuration template in this p <PotentialUser-92>creating an EFI PArtitn you just need to create a 100M EFI System type partiton with cfdisk execut the commands if the EFI Patition is in sda: parted /dev/sda set 1 esp on, mkfs.fat -F32 /dev/sda1 and mount /dev/sda1 /boot/efi and if you encrypted root partitio0 and the root partiton is in sda2 do you use the second configuration template in this p <snape>civodul: in your last email you were talking about having a "big timeout". So you think we need a timeout? I thought we could just wait for the request to be processed <snape>in the "client" side. And during that time the scheduler would schedule other fibers <civodul>snape: ah sure, we can wait (an infinite timeout, then) <snape>haha ok np :-) thanks for you replies <rain1>I want to package autocrypt for guix <bavier>rain1: I think it's an empty password <snape>sorry ;) what you said just made me think about it <snape>and it's a movie we can talk about here, because they use Emacs <snape>probably with GuixSD, though it's not explicitly said