<apteryx>mbakke: thanks for the links; I'll read the later <mbakke>yay, 'python hello.py' worked with an updated python-on-guile \o/ <bonz060>janneke: Mucho thanks for all the help <lispmacs[work]>I told shepherd to restart itself, and it said "You must be kidding." <lispmacs[work]>I was wondering though if there was some trick to restart all the services after an upgrade, since guix doesn't tell you which ones need to be restarted after a reconfigure. <dissoc>when developing packages i use --install-from-file and push it to a channel when done. what about testing services? it would get annoying pushing changes to a channel every time to test it out. is there a better way to try it locally? <mbakke>dissoc: there is a handy './pre-inst-env' script in the guix source that you can prefix any guix command with to run it from the checkout, i.e. './pre-inst-env guix install foo'. <mbakke>see "Running Guix before it is installed" in the manual <mbakke>dissoc: for system services, the best way to test them is to write a "system test" though :-) <mbakke>look into gnu/tests for examples, and you can run a test with "make check-system TESTS=my-test" <dissoc>mbakke: thanks. i didnt know about the tests. i will give that a try <dissoc>the tests are really cool. i didnt think it would be that easy ***jonsger1 is now known as jonsger
<viaken>I just unset all the env vars and things started working. <terpri>raghav-gururajan, anecdotally, i was able to use fsf's jitsi meet service under chromium on solstice night (pre-ffmpeg-update) with no major issues, on a box with 64gb ram <terpri>(under X11, on non-libre linux 5.6.7 using an amd vega64 gpu iirc) <sneek>Welcome back nly, you have 1 message! <sneek>nly, str1ngs says: thanks for merging emacsy. ***jonsger1 is now known as jonsger
<jackhill>Can I have both an openssh-service and an lsh-service? I guess I need to rename one of them to avoid the guix system: error: service 'ssh-daemon' provided more than once error <gnutec>viaken: For now! Back to the 5.4 until Hurd ready. <gnutec>viaken: If 5.6 come to guix before Hurd, I say here. :))) <gnutec>Just see right now in TV that AMLO, president of México, is incompetent and let corruption take over. But Argentina with Alberto is doing a great job. :) <manzerbredes>Hi, I am facing to something strange. When I run guix from tty (out of a terminal emulator) as a regular user (not root) everything works fine. However, if a try to run guix from a terminal emulator (I am on ArchLinux) I have the following error: /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: error while loading shared libraries: libX11.so.6: cannot open shared object file: <manzerbredes>gnutec: I search again, but actually it was working fine since today. I do not which mistake I since despite doing some guix pull. I just tried to add libX11 to the LD_LIBRARY_PATH and it work now, but I never had to do this before... ***tim is now known as Guest71065
<gnutec>manzerbredes: "I never had to do this before..." This is wear but something like this happed to me. When I upgraded my icecat, the numbers gone. Then I ask here and told me that I haved to install "font-gnu-freefont". I use Guix System, installed by ISO guix-1.0.1 and I had to add environment variable like I was a user of other distro. We just need to pay atention, but guix always solve ours problems. <efraim>sneek: later tell civodul I'll test the JamVM patches on aarch64 but I don't want to be responsible for breaking other architectures :) <dmbaturin>If there a way to only apply configuration changes from /etc/config.scm , without also updating the packages? <janneke>dmbaturin: if the only thing you change is /etc/config.scm, no packages will be updated <janneke>dmbaturin: a package update is a two stage process <janneke>you update guix, usually using "guix pull" <dmbaturin>I mean if I edit /etc/config.scm and only add a user and then run "guix system reconfigure /etc/config.scm", it should not do anything with packages? <janneke>it won't as long as you are using the exact same version of guix <janneke>as the previous time you ran guix system reconfigure <dmbaturin>So if updates are available, it's expected to forcibly trigger an update? <janneke>after updating guix, any new package installation uses the new, updated packages <janneke>(guix install, guix system reconfigure, guix environment, etc.) <dmbaturin>janneke: I mean, if I want to change the configuration but don't want to update any packages, can I do it? <janneke>guix pull == apt-get update; guix system reconfigure / guix package -u == apt-get upgrade <dmbaturin>Don't get me wrong, I like Guix so far, but waiting for it to "rebuild the world" _just_ to add a user is... not exactly a nice UX. <janneke>dmbaturin: most probably yes. verify that "guix system describe" and "guix describe" show the same commit <janneke>dmbaturin: well, that's part of the deal <janneke>i think most of us would agree that part of the UX is bad <htgoebel3>I'm (still) working on a downloader/importer for hex.pm. <htgoebel3>Curiously, I get an derivation with an empty output, like "Derive([],…" <janneke>it's lovely UX to just edit /etc/foo/bar.conf, but it's terrible UX having to setup a backup infrastructure, test, setup backups. i prefer no backups, and guix system init, ymmv <janneke>dmbaturin: and as i said, you don't need to update packages or rebuild world, that's really up to you <dmbaturin>janneke: Well... how do I _prevent_ the system from upgrading anything right now when I run "guix system reconfigure"? That's the part I fail to understand so far. <dmbaturin>What should I do or avoid doing to say "regenerate the config but don't touch the packages". <janneke>dmbaturin: not using guix pull in between two reconfigure's, or traveling back using guix time-machine --commit=<previous-reconfigure-commit> system reconfigure ... ***htgoebel3 is now known as htgoebel
<janneke>dmbaturin: you did't share with us if you ran guix pull, or if your guix describe / guix system describe commits match <janneke>htgoebel: can you share a package description that produces that? could it be that 'outputs' is empty? <htgoebel>janneke: The package builds find when using e.g. git-fetch (as the ones around). <htgoebel>janneke: And the importer is model like the one for git, bzr or hg. ***sneek_ is now known as sneek
<janneke>htgoebel: hmm, and guix build --source erlang-getopt works? <htgoebel>janneke: No "guix build --source erlang-getopt" does not even try the fetch the source - which is the curious point on this. <htgoebel>janneke: "guix build --source erlang-getopt" will create a .drv file as expected, but this file starts with "Derive([],…" (which I assume means: no outputs are defined). <htgoebel>janneke: Contrary some .drv file for a package using "git-fetch" start with "Derive(["out","/gnu/strore/…", …" <kenogo>Hey, I just installed GuixSD for the first time, and I have to build GNU Icecat myself. This may take a couple hours on my underpowered laptop. If I understood it correctly, this means that probably the build process failed or isn't done yet on CI, so I have to build it myself, right? <kenogo>And my main question: Is this kind of situation I'm in the norm or did I just get unlucky? Just so I know what I'm signing myself up for. <mbakke>kenogo: I think you got unlucky, probably because the CI is currently down <civodul>kenogo: i've just restarted the web interface <bonz060>Btw, I saw talk of a hackathon on the mailing lists. Has it been officially announced? <zimoun>bonz060: if you are speaking about Repro Hackathon, I am working on preparing the announce. :-) <bonz060>zimoun: Yeah that's what I was looking for. It'd be my first hackathon though. I've been using GUIX for about 3 months now and I really like the ecosystem(I want to work my way to hacking around hurd in it) \o/. <bonz060>I also want to get people in my community interested in it, so I reckon the hackathon would help a bit <zimoun>civodul: since you restarted the web interface, then "guix weather" works again; it was raising 504. <mothacehe>janneke: hey! I'd like to proceed with the Hurd CI serie civodul has reviewed recently. The next step is maybe to make a Hurd image available on the website. Not sure how to make the instructions available on how to run it though. I wonder if a standalone "run-vm.sh" would be more appropriate. <janneke>i guess it would be OK to add advice/instructions to the manual too, even without/before having run-vm.sh <mothacehe>Ok, I'll see if I can add some manual/cookbook link to the download page as a first step <mothacehe>Other topic, "guix gc --list-failures | grep web-site | xargs guix gc -D" this command takes ages on berlin, any other faster way to do that? <civodul>mothacehe: "guix gc -D" runs the GC, so that takes ages, don't do that on berlin :-) <civodul>what you want is "guix gc --clear-failures" <civodul>if you clear all the failures, cuirass will spend days rebuilding things known to fail <efraim>civodul: the jamvm patches worked great on aarch64 <htgoebel>civodul: Look like you are my last resort ;-) <htgoebel>civodul: I've implemented a `hexpm-fetch` function, modelled like git-fetch. <htgoebel>civodul: Now when running "guix build --source" on a package using hexpm-fetch, I get a .drv file with *no* output: "Derive([],…" - and the source is not fetched. <htgoebel>civodul: Any idea what could be the cause? <civodul>htgoebel: probably means the gexp passed to gexp->derivation does not refer to #$output <civodul>so that leads to a derivation that produces nothing <rekado_>why is the cuirass web interface failing so often on ci.guix.gnu.org? <rekado_>also: the web interface getting stuck should not affect “guix publish”, so users really should not have any problems getting substitutes. <htgoebel>civodul: Looks like this being the cause. I used `outpur` not `#$output`. Will check later today, thnx for now <zimoun>civodul: do I commit to guix-hpc/website? Or do I fork and send you a "merge request"? BTW, guix.scm fails to build because old share/guile/2.2 instead of 3.0. <bdju>looks like there was a big update to nheko 10 days ago in case someone feels like updating the package <bdju>probably not without some help, to be quite honest with you. <bdju>Does anyone know if Riot in a web browser needs webrtc for a 1-on-1 call? I think it's technically using Jitsi. <bdju>I'm in IceCat, my friend and I can't hear each other <raghav-gururajan>bdju: Matrix uses WebRTC for video calls. IceCat is built without WebRTC support. Best bet is using ungoogled-chromium. <NieDzejkob>bdju: Oh, I can walk you through it if you want, it's not hard. You'll need a git checkout of the repository, see info '(guix) Building from Git' <bdju>raghav-gururajan: just doing audio calls if taht matters <NieDzejkob>bdju: then you can change the version field and run ./pre-inst-env guix build nheko <bdju>NieDzejkob: ah, thanks. I'll take a look at that <NieDzejkob>you'll need to update the hash of the source, which will be shown when the comparison fails <bdju>I can never remember how to get around in `info`... <bdju>I'm using M-x info in emacs actually <bdju>bit stressed at the moment so might just come back to this later <Noisytoot>Does anyone know which package provides libgcc_s.so.1? <lfam>Noisytoot: It's in the "lib" output of a GCC package <lfam>The GCC packages are split into multiple outputs after building <Noisytoot>lfam: GCC is a hidden package, how can I install it? <lfam>Noisytoot: If you want to use GCC in a Guix context, you install the gcc-toolchain package. That will provide a full development environment <lfam>bonz060: You manage Guix itself with `guix pull` <lfam>The part of the manual you linked to is about this case <lfam>If you want to upgrade the packages you installed with Guix, you can use `guix package --upgrade [...]` or `guix upgrade` (the latter is an alias of the former) <lfam>You usually need to pass an argument of what to upgrade, for example `guix package --upgrade=.` <lfam>It accepts a regex so the dot means "upgrade everything" <lfam>`guix upgrade` should do that by itself but is less flexible <bonz060>lfam: thanks. Also, once I finish running `guix pull`(still running it, I'm on slow internet), I should no longer have to run `guix search <pkgname> | less` to get all the results right? <bonz060>lfam: thank btw for clearing that up <lfam>I haven't followed the development around that issue, but if that change was really made, then you should get the new Guix after opening a new terminal window <zimoun>lfam: basically, now "guix search foo" does what "guix search foo | less" was doing. <lfam>Hopefully everyone is happy now :) <lfam>People seemed to care very deeply about that issue <zimoun>not totally. ;-) Soemthing like "guix search --format=online foo" could nice, displaying something like "aptitude" or similar tool. <janneke>hmm, "suddenly" getting fortify-related errors: <janneke>i686-w64-mingw32-ld: sed/sed-compile.o: in function `sprintf': <janneke>/gnu/store/062fs654qwdxi5n84g0k38r7rc3bkv0n-mingw-w64-i686-7.0.0/include/stdio.h:366: undefined reference to `__chk_fail' <janneke>...or did i just misremember this already worked? <htgoebel3>civodul: '#$output' did the trick. Thx again. <bonz060>That ^^ error went away after a removing channel I use. <NieDzejkob>the variable got renamed to rust-rayon-1, you might want to prod (read: PR) the channel upstream to update it <zimoun>bonz060: rust-rayon-1.3 hs been renamed to rust-rayon-1 in a56305 <htgoebel3>civodul: Now my quest continues: Even after adding "(gcrypt hash)" to source-module-closure, module-import-compiled.drv fails to find this module. <zimoun>so if your channel still depends on it, it fails. <zimoun>bonz060: the rename is from Monday 22, so the channel is not yet updated. <janneke>for the archives, using: ((#:configure-flags flags ''()) `(cons "LIBS=-lssp" ,flags)))))) fixes __chk_fail/__memcpy_chk for mingw <janneke>but that currently means: more *-mingw package exceptions :-( <gnutec>bonz060: "guix pull" then "sudo guix system reconfigure /etc/config.scm". This will upgrade the system without upgrade the packages installed. <zimoun>bonz060: since efraim commits on both repos, it should happen soom. :-) <Noisytoot>lfam: I have installed gcc-toolchain, but libgcc_s.so.1 does not seem to be in my profile. <NieDzejkob>Noisytoot: are you trying to run binaries from other distros? <Noisytoot>NieDzejkob: I am trying to run Rust installed from rustup, I am running a foreign distro (Debian). <NieDzejkob>Debian should already be providing all the libs you need, though... <bonz060>zimoun: I've actually updated it. I'm currently testing the rust-rqtreaper install out(it depends on rust-rayon). I have write access to that repo :) <zimoun>bonz060: so you need to rename rust-rayon-1.3 to rust-rayon-1 in the channel genenetwork. However, I am not sure about libgcc_s.so.1. Well, I have to go. Cheers. :-) <Noisytoot>NieDzejkob: Guix seems to override something, because it (Rust) works in a user without Guix. <Noisytoot>In a user without Guix, rustc finds libgcc_s.so.1, but not in a user with Guix. <NieDzejkob>Noisytoot: that's not what my experience has been. What's your $LD_LIBRARY_PATH? <NieDzejkob>Noisytoot: weird. What if you try to run it in a `guix environment --pure`? You'll need to provide the full path to the binary... <Noisytoot>NieDzejkob: It still fails/does not find libgcc_s.so.1. <lfam>It will be easiest to debug by inspecting the full results of `env` <aadcg>I'm trying to run some python code blocks in org-mode. My issue is that in Guix python is actually python3. I have set an alias in bashrc, but it didn't work. I also tried (setq python-shell-interpreter "python3") and didn't work. Maybe someone who uses literate programming in org-mode can give me an hint? Thanks. <lfam>aadcg: You can use the python-wrapper package instead <lfam>It provides Python 3 called 'python' <kmicu>Pleasent to see here a fellow tangler. <NieDzejkob>I'd like to merge #40957 soon, could someone take a look and review it? <cbaines>I don't think substitute* supports that kind of functionality <cbaines>There's a find-files procedure that uses regular expressions (not shell globs) to match files <cbaines>You could use that incombination with substitute* <cbaines>If you search for "(substitute* (find-files", that seems quite common <gnutec>Can I create any file with "tar -cfv" or there is something more for each of formats? I did with tar.lz and the gnome told me the package created is a "x-lzip-compressed-tar". <hendursaga>Has anyone gotten Guix to work on a Raspbery Pi? <nckx>hendursaga: I'm not aware of any rPis that don't need proprietary blobs to boot, but I'm not aware of all rPis. <lfam>That being said, Guix System does support 64-bit ARM so something must be possible <nckx>CompanionCube: Good point, Guix == Guix System in my world. Guix on Raspbian should work a treat, if slowly. <bdju>has anyone tried to run Guix System on the PinePhone yet? <aadcg>On a similar note, is any work being done to use the guix package manager in Android (similar to Nix-on-droid)? <nckx>lfam: I think the problem (and this is a *very* rough understanding) is that the ARM ‘CPU’ is really a co-processor to the GPU, and booted through the GPU firmware. <hendursaga>bdju: I saw there was a Nix port but that's about it <nckx>The GPU maker had some space for an ARM core and plonked some transistors in that spot, voila, super-cheap ARM board that can't boot without blobs. ☹ <CompanionCube>the blobs are easily replaceable, but the free replacement has some rather big missing features, so... <mbakke>nckx: Oleg submitted an autofs patch just hours before yours, can you take a look? <nckx>mbakke: [Who] is Oleg in #guix? <mbakke>wigust: nckx submitted an autofs patch just hours after you, can you take a look? <nckx>Thanks. I never would have guessed that (although the nick's familiar). <nckx>Well, I'm obviously biased, but I think mine's a lot cleaner… 😳 wigust: Did you include binutils deliberately? It's almost certainly a mistake, and the STRIP trouble below might have been self-induced because of it. It seems like you had a lot more trouble with paths in general than I did; I think --with-path=$PATH doesn't do what it should if it does anything at all. <nckx>#:validate-runpath? #f is right out. By the number of problems you had to solve (and I never encountered) it seems like you made a wrong turn early on and got some very unhelpful error messages thrown at you. <nckx>All those setenvs can't have been fun to write/debug. <nckx>wigust: Have you used the --enable-force-shutdown functionality in practice? Is it safe? I wasn't sure. <wigust>nckx: I just convert a Nix expression to Guix :-) that's why it's not as clean as yours <wigust>nckx: no, i didn't use --enable-force-shutdown <rekado_>janneke: hey, I’m very grateful for your childhurd service, the improvements, and the build node configuration changes! <nckx>‘This option enables the use of the USR1 signal to force an unconditional unlink umount of all mounts at shutdown.’ <nckx>It's probably safe if you think it can be useful. I'll take a look at the Nix expression, but their quality bar is lower than ours (I'm allowed to say that because they gave me commit access, which is proof). <rekado_>janneke: I really wanted to review the changes and test this all, but magic smoke has been escaping my brain for some days now; hard to focus <janneke>rekado_: thanks for the headsup, no worries! <janneke>rekado_: this has been so much work, also for civodul and mothacehe, i'm very glad we are past the biggest troubles <janneke>rekado_: it's fine to take our/your time with this! <wigust>nckx: my recipe has a problem with automount for sshfs, which could be work around by symlinking ssh and sshfs to bin. <civodul>nckx: wait, you also have commit access here, so that's proof of what? <rekado_>janneke: I hope my unfiltered curiosity about whether it’s possible to run more than one VM with the childhurd service didn’t come across as demanding <nckx>wigust: I think that explains the presence of ‘--with-path=$PATH’. I don't think that does what you think it does in Guix, although to be honest I didn't check. <janneke>rekado_: no, it sounded like "oh great, can i have more?" <janneke>and i know how committed and helpful you are, no worries! <rekado_>I’m really excited about the Hurd work and impressed by how effective the collaboration has been. <nckx>wigust: To which bin exactly? /gnu/store/…autofs…/bin? <rekado_>I hope I can rest my brain enough to regain some of my occasional sharpness to contribute soon <janneke>well, of course we gotta finish the Hurd soon, right <nckx>In either case, sounds like it's trivial to substitute*, I'll take a look. My package may well have the same problem, I haven't used it with sshfses. <wigust>nckx: Actual /bin/ssh and /bin/sshfs <janneke>yeah, didn't you hear -- there's talk of this new kernel freexx or so <nckx>If ‘meta.executables = [ "automount" ];’ is Nix's solution to our missing ‘guix which’ functionality let's not follow suit. <mbakke>phew, it's weird how patch review is more exhausting than writing [the same amount of] code <wigust>nckx: Didn't try /gnu/store/...autofs/bin/{autossh,ssh} <cbaines>I'm looking at some patches, and the author is "XXX via Guix-patches via <guix-patches@gnu.org>", should that be tweaked before committing? <rekado_>janneke: I hurd it won’t be anything serious, though. It will just be a hobbyist Unix clone. <janneke>rekado_: guess you're right, let's take our time and do it right <cbaines>Cool, I'll try to tweak the author metadata <cbaines>It looks like some commits with that lengthy author have already snuck in: git shortlog -s | grep "via Guix" <nckx>wigust: But… the autofs output directory doesn't contain the strings "sshfs" nor "/bin". I wonder if it's using that glibc-get-broken-default-search-path thing whose name I forget. <mbakke>cbaines: yes, it's easy to forget to check the commit header when applying patches on behalf of others :-/ <mbakke>I wonder what causes that "via" address in some patches but not others <civodul>it's something in the mailing list settings <civodul>having to do with one of these 4-letter acronyms that denotes an anti-spam protocol <jonsger>I have `(map specification->package+output (list "transmission:gui")) in my config, but it's not installed? what am I doing wrong <wigust>nckx: I straced automount invokes "mount -t fuse -o rw,allow_other,debug sshfs#user@host: /mnt" <nckx>civodul: Hmno, there's no obligation to mangle the display name like that. Which doesn't mean it wasn't a well-meaning author's/admin's motivation of course. <jonsger>it's not in /run/current-system/profile/bin/ <nckx>You can send mail as ‘Ludovic Courtés <was-ludo-at-gnu-org-now+somethingelse@gnu.org>’. <nckx>wigust: So the real bug is in mount? <nckx>I think that's worth a bug report. I can't send mail at this time (remodelling the ol' server), would you be willing to wigust? <nckx>And sorry for trampling all over your patch. What were the odds. <NieDzejkob>jonsger: that's weird. Would you mind pasting your `guix describe' and config? <jonsger>NieDzejkob: I cannot paste all of them due to freedom stuff, so only parts <jackhill>Their current state is that they've been reviewed and improved some, and need someone with more experience to find more improvements, or if non are found to push them. <cbaines>I can hopefully make some time to look at the go update over the next couple of days <cbaines>efraim and I ended up looking at it recently to improve things for aarch64-linux <NieDzejkob>jackhill: I only skimmed the thread so far, but I'm confused as to why you're specifying (outputs '("out")) explicitly <jackhill>NieDzejkob: I think that's a side effect of my suggesting that one part of the software might make sense as another output, and the original submitter of the patch thinking about that, but deciding not to do it right now. <jackhill>I missed that in the updated patch, good catch. <jsoo>NieDzejkob: hey there. Do you think the features argument in the new cargo build system can just be specified by the cargo-build-flags argument? <NieDzejkob>jsoo: This was discussed on the guix-patches thread. No, it can't, as the features must also be passed to cargo install, which doesn't accept the --release flag. <jsoo>NieDzejkob: Ah I see. I did get one compile error recently when compiling alacritty. It seems that the --features flag is not supported on projects with workspaces. Can the features be omitted entirely when not specified? <jsoo>Umm I patched it so it would not do it but let me see if I can find an example <nckx>wigust: By the way, how did you install sshfs? Using ‘guix install’ or a user manifest, or as part of your system packages field? <jsoo>I'm sorry I cant get the exact error message ***sneek_ is now known as sneek
<NieDzejkob>jsoo: anyway, I think it is reasonable to omit the features argument when an empty list is passed, these should be equivalent. Do note that the patch to the build system will have to land on staging, though <jsoo>Ok sounds good. What issue number is the patch set? <jsoo>Or is it already in staging? <NieDzejkob>the patch set for omitting the features argument? I haven't written one <jsoo>Oh just the features argument for cargo-build-system <jsoo>Oh is it? Cool. I'll do some research later <jsoo>Sorry I thought that patch was only on your fork <NieDzejkob>the one I linked for rust 1.44? that branch was through a few rebases... <mbakke>apteryx: thanks for taking care of the lib2geom tests <mbakke>apteryx: can you update inkscape on staging? it was more involved than I had thought :P <mroh>nckx, wigust ty for the autofs patches! <jsoo>NieDzejkob: yeah that branch. Ok. Well any case I will submit a patch <nckx>mroh: Were you the ill-remembered someone on IRC? <raghav_gururajan>cbaines: I just had a live chat with Danny. We wanted to ask you if you could set cuirass to build substitutes for wip-desktop as well. <cbaines>raghav_gururajan, on what instance of Cuirass? <nckx>raghav_gururajan: Did you see my messages about wpewebkit? I didn't find any response. <raghav_gururajan>cbaines: I am not sure. An instance that geographically closer to me (Toronto) would be better. <raghav_gururajan>nckx: Shoot! Yes, I didn't respond as you mentioned you will be back only on Friday. For now, I am putting wpewebkit on hold. Will be working on it later. <cbaines>raghav_gururajan, if bayfront would work, I can potentially look at setting that up tomorrow <nckx>raghav_gururajan: True, today was unexpected (and tomorrow I will keep my promise 🙂). <cbaines>otherwise, maybe someone else could look at building that branch on ci.guix.gnu.org <nckx>raghav_gururajan: Er, OK, then, I guess. <nckx>At least start from the working recipe so that work doesn't go to waste. That was a lot of computer time. <nckx>berlin *is* ci.guix.gnu.org, bayfront is independent (and intentionally so as it's currently used for reproducibility stats). <raghav_gururajan>nckx: Btw, I was not able to use bayfront effectively. The guile references generated during ./bootstrap, kept getting deleted by gc process. :( <rekado_>raghav_gururajan: you can keep these references from being deleted <nckx>raghav_gururajan: You can create a GC root. <raghav_gururajan>nckx: The recent build of wpewebkit still hepled to make necessary changes to pack-def. :-) <nckx>raghav_gururajan: I thought your main issue with bayfront was the eternal GC lock. Has that been mitigated recently? <nckx>raghav_gururajan: Great. <nckx>So you actually used it? Me happy. <raghav_gururajan>nckx: That's there too. When ever I login, there is gc process still gc lock. <nckx>Ah, OK, I'd misunderstood. All's well then. <nckx>raghav_gururajan: And does it continue eventually, and if so after how long (on average)? Or does it just hang ‘forever’ (until you give up)? <raghav_gururajan>nckx: That's why Danny thought interating it cuirass is better. It automatically build as per new commits in wip-desktop. <raghav_gururajan>Also, occupancy (size) gonna be same. Doesn't matter if I build some thing manually or built by cuirass, right? <nckx>Oh, I thought Cuirass would have to fight the same lock issues. <raghav_gururajan>Yeah, atleast cuirass can wait and start building when I am sleeping. Haha <nckx>raghav_gururajan: Yes, as long as you don't accidentally push a core-updates-level change to wip-desktop. <raghav_gururajan>rekado_ | nckx: As cbaines mentioned, would any of you be able to setup wip-desktop on ci.guix.gnu.org?