<nckx>jeko: I strongly prefer (and recommend) the first approach. <nckx>Approach 2 is good as a last resort, but you can run into obscure bugs caused by old remnants of the old distribution (including failure to boot). <jeko>nckx: cool thank you, I had kind of same intuition but lack of experience to be sure... so lets do (1)! I want my guix ready before FOSDEM! 🤩🤠🤓 <drakonis>is there any indicator of which guile version guix is running on? <oriansj>guix search really should given an option to search by name and its current search by synopsis should be case insensitive <sirgazil>I just got bitten by another problem when trying to report a problem :) <pkill9>oriansj: you can search by name with 'guix package -A' <pkill9>though yea a --name flag would make more sense i think <pkill9>or have it search the name by default, and add a flag for search the descriptions as well <pkill9>i think that would make more sense <sirgazil>While in my GNOME session, I switched to TTY2 by pressing Ctrl+Alt+F2, but then I couldn't go back to the GNOME desktop by pressing Ctrl+Alt+F1 nor Ctrl+Alt+F7. <oriansj>pkill9: yeh that isn't obvious at all <leoprikler>Even if your gnome-shell is fubar'd, you can still try to `loginctl kill-session` before rebooting. <sirgazil>leoprikler: You mean Ctrl+Alt+F1 is not supposed to get you back to the GNOME desktop? <sirgazil>Oh, It was F7 in previous distro I used. <leoprikler>Either way, I just recovered from a similar problem (although that one is completely my fault), by killing my session through SSH. <drakonis>hmm i'm having some bytecode weirdness right now <nckx>jeko: Same here. I was going to (re)install my laptop at FOSDEM but then I remembered the packet loss there. <sirgazil>But the other problem I was going to report is that when I change to say, TTY2, and log in (or even without loggin in) my interactions get disturbed by a flood of messages like: <sirgazil>Jan 25 17:55:46 localhost vmunix: [ 2583.020737] pcieport 0000:00:1c.7: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID) <nckx>sirgazil: That's a real (hardware) error as far as the kernel is concerned. <nckx>If you're sure your hardware is OK you can try booting with pci=noaer on the kernel command line. <nckx>If you're lucky your hardware is just buggy and they are safe to ignore. <sirgazil>nckx: I'm not sure if the hardware is ok, but the computer is almost new. <nckx>Well, IMVHO, if you've been ignoring/unaware of the errors with no (known) ill effects, asking the kernel to ignore them for you isn't a step back. <sirgazil>But is that pci=noaer permanent. I haven't used kernel command line. I don't even know what that is... <nckx>sirgazil: It's like the command like of any other programme (ls --foo --bar). You can specify it and change it at any time with (kernel-arguments (list "foo" "bar" …)) in your operating-system configuration. <sirgazil>nckx: Ah, in my system config?! Ok, thanks. <nckx>If you just want to test, you can hit ‘e’ at the GRUB entry you want to boot and add it to the end of the ´linux …’ line. It's really just [presented as] a command line, you'll see. That will not be saved at all. <jeko>nckx: damn I was hopping I could do that... :( <nckx>jeko: I was probably unlucky last year. Still, might not want to stake you computing for the day on downloading around a gigabyte of software over con wi-fi… <jeko>nckx: haha you're right ! <adfeno>Tried `guix pull' today on x86_64 foreign distro, it pulled from commit d63e0ee78d00ff1ccef9f74307b237b7e46ea15d from Guix main channel, tried package updated and seems to fail on module-import-compiled (even with --fallback), it fails with: … <adfeno>ice-9/boot-9.scm:752:25: In procedure dispatch-exception:; re-exporting local variable: iota <numerobis>adfeno: I have exactly the same issue with "guix install jupyter" <adfeno>I'm right now trying to bisect this issue <adfeno>It should take roughly 10 steps (unknown time, since it depends on whether the module-import compilation will succed) <adfeno>How do I force only that derivation to be built, without using `guix package -u' (I accept having to use `guix package' but not do a whole update to test that). <PotentialUser-52>hi guix! I'm looking for a login manager recommendation. Slim works as expected (if I add it to services, it shows)... but gdm-service-type does not (if I use that, dhcp, and %base-services, it doesn't show a login screen). Does gdm-service-type require more services to work? Is there a simple non-slim (maintained) option? <PotentialUser-52>alternatively it'd be great to use startx/xinit... but last time I asked/tried it seemed complicated and I wasn't able to get it working <raghav-gururajan>I believe there is an on-going issue between recent linux kernel and gdm. Also, there is simple yet maintained alternative to SLiM. But you can try sddm. <raghav-gururajan>jackhill I assume so. I was reading today's messages from gnutec in the IRC log. <PotentialUser-52>jackhill: is there something like guix bisect to figure out the last known good/first bad commit? just out of curiosity after reading your bug report <raghav-gururajan>jackhill "gnutec09:00:49Now with kernel 5.4.14 and I still need kill gdm to login with g-desktop. :( is not a big problem so I can wait until they fix :)" <raghav-gururajan>jackhill May be the issue with gdm is different from what gnutec was talking about. Good thing that you reported :-) <PotentialUser-52>raghav-gururajan: sddm not picking up input in the vm... is there a simpler suggestion? I really just need to start xmonad.. nothing fancy <jackhill>raghav-gururajan: ok, just wanted to make sure I was aware of all the information that is out there. <jackhill>I'm plannin on doing a "manual" bisect with git bisect and a clone of the guix repo and pre-inst-env. But that is going slowly because my computer is slow, and rebooting to test each revision is a little disruptive <jackhill>PotentialUser-52: ah, no unfortunately, guix bisect is not a thing. It's no big deal, since I can do it with plain git tools and ad checkout, but the integration would make it nicer. <jackhill>I found the commits because after reconfiguring and rebooting I had the problem. I then rebooted and selected an older generation at the grub menu <jackhill>I got the commit from /run/booted-system/channels.scm each time <spk121>hello all! where do I look for instructions on how to make a more reproducible tarball file? <jackhill>PotentialUser-52: yeah, I this point I'm just to the tedious steps of reconfiguring and rebooting a bunch to test different version. It is quite nice that git has a bisect feature, which keeps track of the good and bad versions, so I don't have to do it by and, and make a potential mistake and confuse myself. <jackhill>I was happy to find at least one other person on #guix that was having the same problem. That helped convince me it probably was a more general problem rather than something else (I had been wondering if my incredibly slow disk just couldn't beat a timeout or something) <reepca-laptop>is there an easy way to tell gdb where the source is? Would it be looking in /tmp/guix-build... by default? I tried 'directory /home/reepca/Programming/xorg-server-1.20.7' but it still can't find the source files unfortunately. It sort of works if I specify each source subdirectory manually, but that's a bit of a nuisance (what if there are further subdirectories within them?). ***sneek_ is now known as sneek
<apteryx>if you built it yourself, it seems the binaries should keep a reference to the sources path that were used to build them. This is perhaps not done in the guix build code (for purity?). <apteryx>reepca-laptop: looks like you want 'set substiute-path', described in 'info gdb' <apteryx>it seems more adapted to rewrite a complete source tree location. <gnufr33d0m>I've having trouble a locale message any thoughts on how to fix? <bandali>hi folks, i’m trying to package pasystray, but i get the following error during the bootstrap phase: <bandali>./bootstrap.sh: ./configure: /bin/sh: bad interpreter: No such file or directory <bandali>any thoughts on what i’m doing wrong? <reepca-laptop>bandali: well, looking at %standard-phases in (guix build gnu-build-system), it looks like patch-source-shebangs comes after bootstrap. I'm not sure why. <reepca-laptop>you'd think that if that's the case, the bootstrap phase should really just invoke it directly with bash instead of trying to use the shebang... <reepca-laptop>ah, it looks like the bootstrap phase actually patches the bootstrap script itself <reepca-laptop>although of course if the bootstrap script invokes another script, that shebang will still be wrong <gnufr33d0m>yes, I followed the instructions for GUIX_LOCPATH <reepca-laptop>bandali: ah, looks like the bootstrap script tries to run configure. I have no idea why. You could substitute* it out I guess. <bandali>so it appears that guix does actually change the shebang in bootstrap.sh, but i wonder if/where are the other references? <reepca-laptop>of course, guix needs to split those up so that the generated files can be patched <reepca-laptop>(and because it allows for finer control of options and such) <bandali>ha, so how can i make guix ignore bootstrap.sh? remove it the file afte runpacking? <reepca-laptop>are you packaging a release or a development version? bootstrapping may still be necessary <bandali>this is a devel (-git) version for personal use. i may submit a stable release version to guix proper at some point <reepca-laptop>if it's fine to ignore bootstrap.sh, you could just remove that phase entirely. Personally I'd use substitute* or similar to comment out the last two lines of bootstrap.sh, and the phases can proceed as normal from there. <bandali>ha, do we have an example of that somewhere in guix.git? <bandali>i mean specific example of commenting a few lines as cleanly as possible <reepca-laptop>grep -R "comment out" ~/.config/guix/current/share/guile/site/3.0/gnu/packages <reepca-laptop>they all do it a little differently, but there should be enough examples there to see how substitute* works <Blackbeard[m]>gnufr33d0m: can you copy paste your .bash_profile or where did you set the variables? <efraim>gah, I'm using package-with-explicit-python in a channel but it's not exported from (guix build-system python) <zorka>Hi Guix! How do I access directory in /gnu/store for running specific binary for my service? Like (system (assoc-ref inputs "foo") "/bin/foo") but without inputs. <efraim>using (guix gexp) you can use #$(file-append foo "/bin/foo") <zorka>efraim Thanks! Works like a c. <g_bor[m]>I was wondering if we could alter the defaults of operating-system a bit. <g_bor[m]>One annoying thing I noticed is that the default keyboard-layout, which is #f is not handled gracefully if used in a bootloader. <g_bor[m]>One way to solve that is to fix bootloader, another would be to default it explicitly to for example (keyboard-layout "us") <g_bor[m]>Another thing is that we could default timezone to "Etc/UTC". <g_bor[m]>Accorgin to the docs the keyboard layout should work... I will test it once mode. <raghav-gururajan>I'd say UTC can be used by default, as it also the default for hardware time. <g_bor[m]>the bootloader issue might be that the user-partitions->configuration does not handle it gracefully, so it might be an installer limitation. <g_bor[m]>From the code it seems that bootloader is ok with it. <g_bor[m]>raghav-gururajan: I got an error that there is a type mismatch. <g_bor[m]>I will run a simple test to see what it does. <g_bor[m]>It did not surface beacuse the installer always sets the keyboard-layout... <g_bor[m]>maybe defaulting the bootloader to #f would also make sense, I believe I have seen a request on that for the ml. That is not needed for containers. <g_bor[m]>yes, it would. But containers don't need that. You would still have to explicitly specify a bootloader for other kind of systems. <g_bor[m]>In a system container the starting process is shepherd. <pkill9>does `guix gc --delete-generations` delete generations from all profiles? <navik>Is there any way to get more verbose information on what could be an error in `/etc/config.scm`? I only get `error: invalid field specifier` <navik>no matter what `-v<number>` I provide <navik>The workaround would be to revert to the default one provided and then adding line by line my modifications again. <navik>raghav-gururajan: no - I'm trying to do the first installation, with some custom configurations. <navik>I guess I have to try the vanilla one and see where it gets me, and then apply whatever changes I want to do until it works :) <navik>it's a bit slower, than having proper error msgs, but it works. <raghav-gururajan>I see. What does your 'v' represents ? and in which part of system config? <DamienCassou>I should get a new computer soon and I intend to install Guix on it <navik>raghav-gururajan: nah, the `-v` is provided in `guix system init /mnt/etc/config.scm /mnt -v100` for an example. <navik>The thing is, I had to make a lot of educated guesses on how to use the configuration keywords, and the probability that I would get it correct is 0, so I was hoping for some debugging info, but will have to do with trial and error until it works :) <leoprikler>use Emacs to indent it, that usually highlights an error <raghav-gururajan>navik Try with '--verbosity=2'. It works for guix build, bot not sure for guix system. <DamienCassou>the graphical installation method seems to work really well and is easy to use. Good job guys <navik>leoprikler: you are certainly correct! <raghav-gururajan>navik `--on-error=backtrace` . That's the option for guix system command. <DamienCassou>I'm familiar with Nix and Lisp but not with Scheme and especially not with Guix API. Which documentation should I start with to feel confortable writing my configuration file and packages? <navik>raghav-gururajan: that `on-error=backtrace` gives much more output! thanks <navik>this will get me going further, thanks raghav-gururajan and leoprikler ! :) <navik>also found `--dry-run` which will be nice in testing the config <DamienCassou>it seems all the documentation is available as info. Is there a way for me to download the info files to my Fedora system to I can confortable read them from Emacs while Guix is installing? <raghav-gururajan>I think you can download the HTML and convert to format of your choice using Calibre and read it in emacs. <numerobis>Hi #guix! I'm experiencing an issue with weechat on guix: running '/script' - in order to install some plugins - returns 'script: error downloading list of scripts: curl error 60 (server certificate verification)', although 'curl' works fine in command line. Does anyone have a similar issue? <numerobis>And another question: at present 'guix system reconfigure' does not work because one of the packages (jupyter) does not build. My reason for reconfiguring, however, is just so that I can update an Nginx server, and I am happy with the currently system-wide install of jupyter. Hence my question: is there a way of uploading my nginx config without loosing the already-installed version of jupyter? <nckx>numerobis: weechat: Command-line curl honours $CURL_CA_BUNDLE, while libcurl doesn't (and upstream refuses to change that). We could patch libcurl ourselves, but haven't yet. I don't know the recommended work-around in the meantime. <numerobis>nckx: and thanks for your answer regarding curl! <nckx>If you don't care about updating the version of any system-wide packages and just want to apply configuration changes, you can ‘guix pull --commit=<known-good-commit>’ and reconfigure. <numerobis>nckx: I'm trying to 'guix pull --commit=' to a working commit at the moment, and hopefully this will work. <numerobis>nckx: all right, it seems that I can't go back to a commit where jupyter builds, strangely. Maybe this is because the working version I have came from a substitute, and it's no longer available there, or something like that. Can things ever improve by rebooting? <numerobis>nckx: Many thanks for your answers and suggestions in any case! :) <DamienCassou><raghav-gururajan "I think you can download the HTM"> I decided to install Guix on Fedora. This installed the info pages <adfeno>Hi there, how to see which package updates would trigger a rebuild (or download of substitute) of "module-import-compiled"? <adfeno>Or how to rebuild module-import-compiled by myself? <adfeno>s/how to rebuild/how to rebuild *just*/ <nckx>numerobis: ‘By rebooting’: not really. ‘from a substitute’: substitutes should be completely transparent. If you installed it from a substitute then, Guix is guaranteed to build the *(bit-)exact* same sources again, but it's always possible that a flaky build or test passed on our build farm and is failing for you. <nckx>numerobis: And you're always quite welcome 🙂 ***dddddd_ is now known as dddddd
***deesix_ is now known as deesix
<adfeno>I tried `guix build -d module-import-compiled' but it says that no package was found. <mbakke>adfeno: the module-import-* derivations are plenty and automatically generated, why do you want to rebuild one? <adfeno>There is an error that occurs in x86-64 foreign distro, both when downloading substitute and when rebuilding "module-import-compiled". <adfeno>It happened somewhere between commit f825476c858413828a163e4aa0a931d102419460 and df6ce9fcb455ac59372f1025e450005ea3190614 <mbakke>adfeno: what is the error? can you upload it somewhere? <adfeno>It's rather short message. I cannot send it by email to Guix bug tracking mailing list due to TLS incompatibilities in the base FSF/GNU email setup (because the email provider I use enforces more updated TLS 1.2). But I can host the log in my temporary webserver. <mbakke>adfeno: maybe upload to paste.debian.net? <mbakke>or just paste it here, if it's very short <numerobis>nckx: Thank you very much! It takes a while to get used to how guix works, but very much worth it so far! :) <lafrenierejm>When attempting to build a package I'm getting an error "Invalid cross-device link" due to trying to rename a file into (string-append (assoc-ref outputs "out") "/lib"). Any ideas on why that is wrong? <mbakke>lafrenierejm: I'm guessing you have /tmp and /gnu on separate partitions, and rename-file (or whatever you are calling) tries to hard link under the hood <NieDzejkob>spk121: what do you mean by a tarball? Your question is quite vague... <lafrenierejm>mbakke: Hmm. My /tmp and /gnu happen to be on the same partition, but I'm intending for this to be a generic package so it shouldn't depend on my specific setup at all. <lafrenierejm>Where should I be putting .so files generated during a package's build process? <adfeno>Backtrace: In ice-9/eval.scm: 191:35 19 (_ _) In system/base/compile.scm: <adfeno> 152:6 18 (compile-file "/gnu/store/csccwg383ab92b22mwjh8h6ghp0a?" ?) 43:4 17 (call-once _) In ice-9/boot-9.scm: 841:4 16 (with-throw-handler _ _ _) In system/base/compile.scm: 59:11 15 (_) 155:11 14 (_ #<closed: file 7fffefdd8690>) … <mbakke>lafrenierejm: can you show the code that triggers the error? <mbakke>generally .so files go to $out/lib, indeed <NieDzejkob>nckx: "We could patch libcurl ourselves, but haven't yet" We have, on core-updates <adfeno>Sorry for last message, the back trace is too big, so I stopped printing it before it was finished <NieDzejkob>navik: have you ran a guix pull? I thought a patch landed that improved this error <adfeno>mbakke: I'll paste the module-import-compiled error in the paste service you told me about. <NieDzejkob>ah, the core-updates commit has already been mentioned in the backlog, I see <adfeno>(but I must advise that I don't save/remember pastes, so please take it whenever possible) <adfeno>numerobis: Yes, that is the exact same error I have <adfeno>mbakke: ^ (I no longer need to paste mine, as numerobis already did reproduce the same issue) <mbakke>lafrenierejm: probably /gnu/store is a separate mount in the build container, which also prevents hard linking. I think your best bet is to use install-file and then delete-file. <adfeno>numerobis, mbakke: I did a wdiff of numerobis' "module-import-compiled" error and the only difference is the command that numerobis used (`guix install …') and the hash mentioned in #<close: file …> (as well as other iterations of the same hash). <mbakke>adfeno: no idea what that is about, sorry :/ <mbakke>do you get the same error with any operation, e.g guix upgrade? <adfeno>It happened somewhere between commit f825476c858413828a163e4aa0a931d102419460 (good) and df6ce9fcb455ac59372f1025e450005ea3190614 (bad), all of these commits from the master of guix channel. <adfeno>If I do `guix package -u', I get the errror. It also appears with the `--fallback' in the same command line. <adfeno>(Actually, this was the only step I did to test/trigger this error so far, but in numerobis' case, it is triggered by a package install) <adfeno>I'll try installing a package just to test too. <adfeno>NieDzejkob: `guix pull' seems to work fine. <adfeno>… no matter the commit I chose to pull from. <adfeno>I do want to point out that I'm testing the guix commands as my normal non-root user. If I can't find the problem this way (or if you request me to do so) I'll change to testing only with pulls and installs from my root profile. <adfeno>However, the last root profile update-and-upgrade worked fine. <adfeno>But It *doesn't* have the same packages as my non-root user. <adfeno>mbakke, NieDzejkob, numerobis: `guix package -i hello' worked fine. <adfeno>mbakke, NieDzejkob, numerobis: `guix package -i python-testpath' gave the same error as numerobis described. <adfeno>Also, thanks numerobis, I now know how to test the module-import-compiled error without having to do a full upgrade :D <adfeno>That will greatly speedup my bisect attempts <adfeno>I'm testing commit df6ce9fcb455ac59372f1025e450005ea3190614 again, to see if it really has the bad state <adfeno>OK, that commit is good/works fine. <adfeno>Or not, wait a second… I must reorganize myself <lurch>but I do not understand how it works in practice - it sounds like it will end like my early papers with no version control <lurch>ie will there be bash, bash-fixed, bash-fixed-again, bash-another-fix, etc? since security patches at low level happen quite often <lurch>or does it mean there are always 2 versions and the old bash-fixed gets replaced? but in the sources I couldn't spot an instance of that <adfeno>Sorry, commit df6ce9fcb455ac59372f1025e450005ea3190614 is indeed in bad state. <mbakke>lurch: packages can only have one replacement, so in your example, "bash-fixed" would get fixed "again" if a new security patch comes around <mbakke>lurch: one example is cURL, which is almost always grafted, and we keep "updating" the graft when new security problems are found <lurch>thanks, I see, "curl-7.66.0" - do I understand correctly, that as soon as ci did its job, curl's definition can be replaced by curl-7.66.0? <mbakke>lurch: grafts happen on the client actually. <mbakke>what happens is that Guix will look for any of your installed packages that reference curl, then rewrite all those references to reference curl-7.66.0 instead. <mbakke>that was a lot of referencing, but hopefully you got the gist :) <iv-so>hi there, what should I use as a source, git repo or tarball? <mbakke>iv-so: tarballs are generally preferred, unless they are generated like the GitHub "archive" downloads, because then the hash may change in the future <mbakke>git checkouts have a little more overhead, but it's up to you, really :-) <mwette>Should GUIX_PROFILE be set to $HOME/.guix-profile or $HOME/.config/guix/current/etc/profile ? <mwette>Or that is $HOME/.config/guix/current/ <sirgazil>mwette: On the Guix System, Guix tells me to do this: GUIX_PROFILE="/home/sirgazil/.guix-profile", so $HOME/.guix-profile <mwette>sirgazil: thanks. Then, unless you install guix, guix is /usr/local/bin/guix, which is fine, I guess. I'm on "foreign distro". I will go with that. <sirgazil>raghav-gururajan: What is the next phase of your GNOME work? <bandali>sirgazil, i liked the new logo you proposed for guile btw :-) maybe post it to one of the guile lists? <g_bor[m]>I just did a fresh reinstall, and I see some warning along the lines: In procedure load-thunk-from-memory: incompatible bytecode kind <g_bor[m]>I guess this is related to the guile3 migration. <bandali>ha yeah i see those warnings upon system reconfigure as well <g_bor[m]>I also see a warning related to the shadowing of core binding delete, but I hope that it is intentional. <NieDzejkob>bandali, civodul: %base-packages still contains guile-2.2 <g_bor[m]>should guile3 be injected into the packages then? <g_bor[m]>or is it safe to ignore this and it will go away as the base-packages are updated? <g_bor[m]>anyone has a working example with postgresql-config-file extra-config? <NieDzejkob>bandali: well, I was under the impression that it was there to help guix do its job somehow <bandali>NieDzejkob, right; but how does that relate to the incompatible bytecode kind that g_bor[m] mentioned? <mwette>sirgazil: thanks -- going with that <g_bor[m]>ok, I've found out the extra-config thing. <NieDzejkob>bandali: the incompatible bytecode is provided by the guile-{colorized,readline} packages in %base-packages <civodul>bandali, NieDzejkob: when do these warnings occur? <sneek>civodul, you have 1 message. <sneek>civodul, reepca-laptop says: ran as "sudo -E guix system reconfigure /etc/config.scm" <bandali>civodul, for me, when doing system reconfigure <civodul>bandali: does "guix system build whatever.scm" show these warnings? <civodul>NieDzejkob: "guix repl" is "expected"; try "guix repl -q" or install guile3.0-{readline,colorized} <civodul>bandali: it builds the system without doing anything beyond that <bandali>civodul, ah. let me try it on my config.scm <bandali>civodul, doesn’t look like it. it successfully built the /gnu/store/…-system.drv <bandali>i did that without the usual sudo -E, btw <civodul>so "sudo -E guix system build ..." gives you the warnings? <bandali>to have guix system use my environment rather than root’s? <civodul>i know what -E does but it's not clear to me why you'd use it for here :-) <bandali>ah :-) i think originally because of some locale-related errors and warnings <bandali>also, it looks the system build with sudo -E went without any warnings too <bandali>so i guess it’s the actual reconfiguring that causes it ? <bandali>civodul, btw, can i get your help with packaging pasystray? i’m getting a bootstrap-related error <bandali>on an unrelated note, i’d appreciate some eyes on my pasystray package attempt, and hints as to why it’s failing <civodul>bandali: mostly likely their bootstrap.sh script tries to run ./configure right after autoreconf has succeeded <civodul>however, ./configure starts with "#!/bin/sh", which doesn't work in the build environment <civodul>one solution is to override the 'bootstrap' phase to run "autoreconf -vif" instead of "bootstrap.sh" <bandali>civodul, ah, right. i tried to comment out their call to configure using substitute* but it doesn’t seem to have succeeded <bandali>which of the two approaches you mentioned are preferable? <civodul>NieDzejkob, bandali: so these warnings are annoying but harmless; they'll disappear when shepherd is on Guile 3 <civodul>in general i choose the option with as few lines of code as possible <raghav-gururajan>sneek later tell jackhill: I just guix pulled and reconfigured my system. GDM worked fine for me. I did get those warning messages during system reconfiguration. <raghav-gururajan>sirgazil That would the steps I outlined in outreachy proposal email few weeks ago. But I can update you once I sort-out somethings. <sirgazil>raghav-gururajan: I'll check the archives then, thanks :) <raghav-gururajan>civodul The warnings come up once 'module-import-complied' starts during system reconfigure. <bandali>any thoughts on what could be causing this error? <bandali>./configure: line 3474: syntax error near unexpected token `GTK,' <bandali>./configure: line 3474: `PKG_CHECK_MODULES(GTK, $GTK_VERSION )' <leoprikler>raghav-gururajan: If I'm not mistaken, module-import-compiled gets compiled with 2.2, but guix uses 3.0 to interpret them <civodul>bandali: mostly likely you're lacking pkg-config as an input <bandali>whatever i’d do without y’all’s help :p <bandali>okay i think the package is nearly ready to be submitted to guix-patches :) <bandali>quick question: what’s the policy when a package on github doesn’t have release tar balls and relies on github’s generated archives? do we use those? <bandali>or do we prefer to pin it to a release commit? <leoprikler>bandali: if there's a tag, use that as commit in git-reference <bandali>leoprikler, raghav-gururajan, thank you both <bandali>unrelated question: is there any way to have guix use emacs-next instead of emacs for all emacs packages? (without me having to create alternative versions for each package one by one) <bandali>where/how would i use that? is there a way to do that declaratively for a manifest or something? <bandali>basically, i’d like guix to use emacs-next as “emacs” for all intents and purposes on my machine <leoprikler>in a manifest, you'd use package-input-rewriting <leoprikler>I just checked, they should normally have (native-inputs `(("emacs" ,emacs-minimal))) <bandali>DamienCassou, heya! nice seeing you here :-) <bandali>right… so i’m not sure what the best way would be <PotentialUser-52>if my mariadb install is failing @ the check stage with "input length mismatch"... is there a workaround? <leoprikler>for those packages using something other than emacs-build-system, you can rewrite package inputs <leoprikler>for the other ones, you'd have to adapt package-with-explicit-python to emacs-build-system <bandali>ah, i see. will look into that, thanks <DamienCassou>I've installed guix system in a virtual environment. I can ssh to the box. However, As soon as I install my public ssh key there (with ssh-copy-id), ssh stops working <NieDzejkob>DamienCassou: what error on the client? Anything in the server logs? <NieDzejkob>oh, and try running ssh with some verbose or debug flag <NieDzejkob>PotentialUser-52: Could you please report this as a non-reproducible build to bug-guix@gnu.org? <DamienCassou>NieDzejkob: it seems patience is enough to solve the problem. It takes something like 20s to be connected. From what I see in the logs, guix takes quite some time before refusing authentication with a key, then the client tries another one and it works immediately <PotentialUser-52>NieDzejkob: is there a web interface to report bugs? or does it have to be email? my setup is kind of in flux as I'm trying to switch to guix now <NieDzejkob>PotentialUser-52: There's no such interface as far as I am aware <NieDzejkob>L29Ah: what do you mean by "the Guix qemu image"? <L29Ah>i mean the file that contains the "operating-system declaration" <nckx>sirgazil: …new Guile logo (idea)? Where? 🙂 <L29Ah>it's /etc/config.scm, thanks <nckx>sirgazil: Why mirror the bottom λs? <sirgazil>nckx: I'm not sure I understand what you mean :) <nckx>sirgazil: In the bottom left ‘×’ version, the bottom lambdas aren't just rotated but mirrored too. <drakonis>hmm, as it stands i'm getting some bytecode weirdness involving ice-9 <nckx>sirgazil: Never mind I guess, I wondered if it was a deliberate ‘γuile’ pun. <drakonis>there's some migration weirdness right now <L29Ah>does Guix provide binary builds of the official packages, or do i have to build everything myself as in Gentoo? <sirgazil>nckx: Ah, right, about the rotation. I didn't noticed that :) <nckx>L29Ah: The Guix build farm continuously builds the most recent packages, and Guix transparently falls back to local compilation when no binary substitute is available [yet/anymore]. <L29Ah>nckx: it's interesting that the qemu image rebuilds everything locally on `guix system reconfigure` then <nckx>I don't know enough about the image to guess why. <NieDzejkob>L29Ah: perhaps the substitutes haven't been authorized? <drakonis>it seems that guix still pulls in guile 2.2 bytecode <drakonis>its causing some weirdness that i cant figure out right now <L29Ah>is it ok that /etc/guix/acl is empty? <L29Ah>guix archive complains about acl being () when i try to authorize the build server <L29Ah>ok rm /etc/guix/acl did the trick :D <nckx>L29Ah: Yep, it should either not exist or be a valid sexp; never empty. <NieDzejkob>how secure should I expect `guix environment --container' to be? <nckx>As secure as any other Linux container. I.e. not at all. <NieDzejkob>aren't Linux containers at least supposed to be secure? <drakonis>they are, yes, if you configure them to be so <nckx>NieDzejkob: Because Linux containers weren't designed for security. They're a convenience feature for nicely grouping processes for easier administration, later teh securities were bolted on. How much you trust that development model is up to you, I just gave you my opinion 🙂 <drakonis>they're constructed off building blocks, not a secure abstraction <drakonis>lxc attempts to produce secure containers by default <nckx>They are as secure as Linux itself, I guess. Just not more, which is how they're sold, and often (due to human error + the sheer complexity of getting everything just right) less. <nckx>It's like rolling your own crypto but slightly less likely to blow your leg off. <nckx>Guix containers specifically were not, AFAIK, ever audited for security. <drakonis>there's no container services right now, right? <nckx>drakonis: Not ‘service’ in the lxc sense. <nckx>‘guix system container’ stacks the blocks. <drakonis>i was thinking about imitating 'systemd-nspawn' <drakonis>but not restrict usage to just creating containers like nixos does, which only uses packages from the store <drakonis>because there's a service for deploying containers, but it takes away a lot of power <nckx>drakonis: So more ‘systemd-nspawn for Shepherd’ than ‘systemd-nspawn for Guix’? <nckx>Cool. Shepherd needs love. <NieDzejkob>drakonis: well, then how come it doesn't work? :P (see paste) <drakonis>guix can drive nspawn for its unique purposes <drakonis>while shepherd can provide nspawn for regular container usage *nckx hasn't Nixed in ages, not familiar with ‘Nix-style containers’. <nckx>But I can guess what you mean. <drakonis>its basically spawning a container with a nix profile inside <nckx>So really ‘guix system container’ (pretty sure we were first, or at least that Nix-style gives them too much credit :-p). <nckx>Well, boring is often good. But sure. <drakonis>i mean, its boring feature wise, you declare what packages and services you need in the container and it'll create one, but it doesnt provide enough flexibility to use systemd's container services <L29Ah>can i ask guix to install a package system-wide (for all the users at once)? <leoprikler>L29Ah: There's a packages field in the operating-system record. <nckx>L29Ah: The most Guixy way to do that is ‘system packages’, which is the (packages …) field in your operating-system. <leoprikler>Only works if you're using Guix System, though. Guix, the package manger, does not do that. <nckx>Where all the packages go to sleep. <nckx>You can manually create and manage more or less global profiles that are shared between users, but that's not out-of-the-box anymore. <drakonis>so, there's a configuration file used to define all containers, nix's modules provide only a subset of that featureset like bind mounts and ip addresses <drakonis>you cannot modify container capabilities with their setup <nckx>leoprikler: I've never seen anyone eat out of a manger, pretty sure that's a myth. Annnyway. drakonis: Interesting, will take lookings. <drakonis>so, its worth looking into including this for shepherd and guix <drakonis>having the ability to use containers that arent just store packages is a thing i would like to use <Blackbeard[m]>I was thinking on trying to reproduce a few bugs, there are some I think I am not having <drakonis>there's a roadmap that would be worth taking a look at <nckx>Yeah you definitely want all the bugs. You're missing out otherwise. <nckx>Blackbeard[m]: Anything in mind…? <leoprikler>nckx: It's because "manger" is French for "to eat", but now I just learned, that "manger" in English is a thing that animals eat out of. Huh. <Blackbeard[m]>nckx: if you have anything in mind I'll appreciate the help :) <drakonis>Blackbeard[m]: check the roadmap for some inspiration <drakonis>these tasks are a bit more on the heavier side of things <drakonis>actually there's a talk on the perfect setup <drakonis>those two and magit for managing the git repository <leoprikler>although I do have both geiser and magit ready in case that I need them <leoprikler>oh and electric-pair-mode, always forgetting on that one <nckx>Blackbeard[m]: I use geiser, paredit, electric-pair, magit and of course emacs-guix (which is not just for developers). <nckx>I used to use rainbow brackets or whatever they're called but that's more eye candy than anything. <Blackbeard[m]>I would like to start contributing so I can eventually apply to Google Summers of Code <nckx>Switch them on before a con; you will attract people and can tell them about Guile. <nckx>Blackbeard[m]: I hope you like networks, because P2P substitutes are really something I'd love to see. <nckx>It's the most untimidating project I know. <nckx>I mean, they even let me in. <Blackbeard[m]>I just need someone to teach me how to move around the big code and understand how it works <L29Ah>how do i tap into the build logs of the currently building package? the docs suggested i should have used --verbose, but it's too late now <NieDzejkob>if that makes you feel better, I also learned programming all by myself <NieDzejkob>I've been sending patches to Guix every other day, on average, for the past month <sirgazil>Blackbeard[m]: I haven't touched any Guix code yet. I'm learning Guile (functional) programming myself little-by-little. I hope to help fix bugs someday instead of just reporting them. <sirgazil>Blackbeard[m]: I use Emacs with paredit, rainbow parens and geiser. <sirgazil>geiser could do better in autocomplete and autodoc (compared to same features in IDEs) <sirgazil>rainbow parens helps me read structure better. <sirgazil>drakonis: I think geiser uses company. The thing is you have to evaluate the buffer everytime you import new modules for their symbols to be available in autocomplete and autodoc. At least in my experience. <sirgazil>But I can be wrong, because I'm fairly new to geiser. <drakonis>you have to evaluate the buffer to actually import the modules <L29Ah>does guix have anything like Gentoo's USE flag dependency specification? i see the "package outputs" thing but that doesn't seem to be suited for multiple toggle'able features that can be depended on by other packages *L29Ah is a gentoo fan trying to figure guix *joostvb is a debian developer, lurking here <drakonis>that email makes me want to waltz into gentoo's channels and link it <lfam>Which channel, drakonis? <drakonis>i think gentoo's main channel is a support channel ***ChanServ sets mode: +o lfam
*nckx , ex-Gentoo user, can't wait for Pierre to come up with something better than USE flags. <nckx>lfam gonna ban you all for talking about Gentoo. <drakonis>i would appreciate gentoo a bit more if there wasn't so much janitoring <drakonis>this would bring the best parts of gentoo into guix <lfam>Please go wild making Guix meet your goals :) <drakonis>pierre seems to want to work with nix and debian on the tagging effort by the way <nckx>I'm weary of package specifications becoming their own (shitty) DSL, but I need to first catch up on the paramegathread. <rupicapra>Whenever I'm running "system reconfigure" i get the following warning at the end: <rupicapra>WARNING: (guile-user): imported module (guix build utils) overrides core binding `delete' <nckx>Sounds like a 3.0 thing? <lfam>We should file a bug report so we don't forget about it, to make sure it's not a real problem in practice <L29Ah>> I think Tobias suggestion is a good solution to this: make parameters first class, global objects. A package can only use globally declared <L29Ah>parameters. This way we have a limited set of well-defined parameters under control (understand: no duplicates, consistent naming). <civodul>the 'delete' warning is a 3.0 thing (totally harmless but totally annoying) <drakonis>say, ice-9 is still pulling 2.2 bytecode <drakonis>there's a warning about incompatibilities <L29Ah>nckx: most of Gentoo use flags are fine tunings of concrete packages, like features provided by a library/program; they can't be boiled down to a global set <L29Ah>because they often have unique semantics <nckx>Unique semantics should be minimised. <nckx>I'm sure there are edge cases though. Such as? <civodul>drakonis: i'm reading the backlog but i didn't quite get it: what do you think is missing from "guix system container"? <drakonis>nothing in the command itself, there is however no service for generating containers <leoprikler>"Global" use flags such as gtk, which apply to a wide variety of packages in pretty much the same way, and "local" ones, which are fine-tuning of inputs or compilation flags. <slyfox>they are not fundamentally different <drakonis>nix has a service similar to "guix system container" but it lacks flexibility <L29Ah>i don't see, say, pipelight and vkd3d being used anywhere outside wine, but they pull additional packages and can be depended on <civodul>drakonis: you mean that a service that would spawn a container at boot time? <nckx>L29Ah: The overuse of ‘unique semantics’ is what makes Gentoo USE flags dead-end technology to me. <civodul>drakonis: it's a very low-hanging fruit actually, would be fun to add <drakonis>i'd like to run containers from other distributions as well <L29Ah>so either you always pull extra stuff almost no one actually uses or leave a crippled compromised build like binary distro folks <drakonis>without requiring docker nor podman for such a task <drakonis>its for practical purposes like testing code for deployment <nckx>L29Ah: I don't really understand this example. Both ‘pull in & use pipelight’ and ‘pull in & use vkd3d’ are perfect examples of non-weird semantics. Just because only 1 package uses that combination of use+pipelight doesn't change the semantics. <drakonis>cleanly executing fhs dependent code and such. <leoprikler>in my opinion, USE flags (or parameters as they are proposed for guix), are just a weird way of saying "please add this extra input" most of the time <nckx>I'm trying to make up a unique semantic but am failing. Something like ‘use Bob's cool algorithm in foo.c’? <L29Ah>nckx: this is unique semantics <nckx>L29Ah: What are the semantics? <leoprikler>nckx: there are some exceptions to this rule, like "hardening", which tweaks compilation flags instead of inputs <L29Ah>there are also semantics like "build against X vs build against Y" <nckx>leoprikler: One could conceptualise those as an input and see how far that takes us. <L29Ah>say openssl/libressl/gnutls/nspr <nckx>Not seriously suggesting that but it's interesting. <leoprikler>You don't have to add inputs for config flags tho? <leoprikler>drop-in replacements can already be done with input rewriting <tsmish>Is there a nice way to modify guix/gnu folder? <L29Ah>btw my guix system buils a kernel(?) (multiple linux{,-libre} packages) for an hour already thru qemu-kvm even though the host system was able to build defconfig in four minutes, and i can't even see the build log T_T <drakonis>another thing i took issue with nix's container setup is that it exposes a fairly small subset of systemd's container features, so, i thought it'd be an interesting thing to provide it to shepherd <lfam>L29Ah: Does your system allow the QEMU process to use KVM? <L29Ah>leoprikler: can you depend on input rewriting in another package? <nckx>leoprikler: And why not? They're just inputs to the big hash grinder, just treated & implemented differently. That's the point of my thought experiment: what if forced an unfortunate soul to use the same syntax for both, what elegant or monstrous thing would emerge. <lfam>Check that it has permissions to access /dev/kvm <lfam>It shouldn't be significantly slower in that case <L29Ah>otherwise qemu wouldn't even run i think, and i'm running it as root atm <lfam>No, QEMU works without KVM <leoprikler>nckx: because package-with-extra-configure-variable exists and is cleaner imho <lfam>Do you know for sure your system supports KVM? <L29Ah>i ran the system from the system itself through qemu a couple of days ago <leoprikler>L29Ah: you can do input rewriting at any depth, the question is how far are you willing to nest your code? <nckx>L29Ah: I think we'll need some kind of way to specify (or at least error out on in)valid combinations, to say that for example the ‘wayland’ feature conflicts with the ‘qt’ feature because the latter still needs porting [random fictional example]. Saying ‘you must choose one of gnutls/libressl/openssl’ could just be an application of that. <L29Ah>gentoo has a way to specify the valid sets of USE flags for a package <leoprikler>Resolving USE flag inconsistencies, my favourite past time. <nckx>leoprikler: If you mean that therefore package inputs and configure flags are fundamentally different and this needs to be reflected in the parameterisation at all, I don't agree. But I don't really understand your point. <nckx>L29Ah: That's what I meant. <mehlon>I was thinking of installing gentoo <sneek>mehlon, efraim says: I don't mind if you work on the gnunet package. As long as the tests pass. We don't have a service for it yet. <mehlon>I heard it fixes all my computer problems when I delete system32 <nckx>There isn't a difference between ‘use foo’ & ‘use bar’, and ‘baz={foo,bar}’ under the hood. <nckx>(Literally, that's how it used to be implemented at least.) <nckx>So these are not 2 different types of flags. <leoprikler>nckx: I might have misunderstood you. My statement was, that adding configure variables through inputs would be weird. As far as parameterization is concerned, I prefer explicit Scheme rewriting over magic. <leoprikler>For arbitrarily complex operations like "build with foo, bar, and baz, also add --yes-experimental-features, and brew some coffee while you're at it", there exists package-mapping. <nckx>We definitely agree on that last point. My ‘inputs’ was abstract hand waving (packages are like, a function, dude) that had nothing to do with the field of that name, which probably wasn't clear at all. <nckx>Personal opinion: Guix is better off without flags (or any other Gentooism). <lfam>Any advice on runpath validation issues for packages built with waf? <leoprikler>Fair enough. I agree with you in spirit, that changing configure flags is not too different from adding inputs (even with the current implementation). I was just confused by the wording. <lfam>Oh, I see that the aubio package might have the answer <nckx>Definitely could have been clearer. <drakonis>nckx: there's a couple things that can be done with it though, handling packages that have drop-in replacements <Blackbeard[m]>A DHCP client written in scheme seems like an awesome thing I would Like to do <leoprikler>drakonis: In those places where it's really necessary, you can wrap the package in a function and call it a day. <L29Ah>Blackbeard[m]: it's too useless i'd say <drakonis>leoprikler: there's the impending replacement of pulseaudio with pipewire and it can be used as a drop-in replacement for alsa, jack and pulseaudio <L29Ah>Blackbeard[m]: what problem would it solve? <L29Ah>you depend on your homebrewn code instead of someone else's, so what? <L29Ah>i don't see why would a lisp program be cheaper to run than a C one <L29Ah>drakonis: pipewire doesn't plan to implement audio drivers, so it's not an ALSA replacement <Blackbeard[m]>I don't think I am at the level of solving enterprise problems to be honest <leoprikler>drakonis: So? None of these packages are ever implicit inputs. You're just one (package-input-replacement ...) away from using it in your manifest right now. <drakonis>plug into alsa using software to be able to use pipewire instead <L29Ah>i find it really disappointing that all those interfaces (oss, alsa, arts, nas, pulseaudio, jack, rsound, phonon, and now pipewire) just can't agree on a single protocol or API, and almost never provide an usable compatibility frontend <drakonis>pipewire isn't only for sound mind you, it does video as well <drakonis>it is providing a usable compatibility frontend <L29Ah>OSS is understood by everyone in UNIX-like world, but for some reason no one creates OSS-compatible device nodes, forcing to adjust all the shitloads of existing software to the new, essentially equivalent, API <drakonis>OSS is understood by every minor unix at this point <L29Ah>yeah since Linux with its ALSA won the popularity contest <NieDzejkob>I'm distributing a project and I want to provide a Guix manifest for use in `guix environment -m <NieDzejkob>anyway, one of the packages I need is not available, and it's just a small Python library <NieDzejkob>guix import pypi works fine. There's no point in submitting that upstream to Guix, right? <leoprikler>But check if all fields are fine before submitting. <drakonis>there were far more factors than a popularity contest <L29Ah>drakonis: it's no different from OSS from the application programmer's point and could have provided the same API if the devs were a little less wishing to write code for the sake of writing code <bandali>are there any examples of a guix package installing udev rules? <bandali>the ‘light’ program requires them to function correctly <leoprikler>Specifically the license field might be empty (at least it is when importing from melpa last I checked) <L29Ah>and yes, i'm aware there's an OSS frontend for ALSA, but it doesn't provide user-controllable mixing like OSS did (not sure if it even provides any mixing in fact since it's done in the user mode while the frontend is a kernel module) <leoprikler>Adding a udev-service with the light package might be what you need. <bandali>leoprikler, how can i add a service with a package? <leoprikler>If I'm not mistaken (simple-service 'light-udev-rules udev-service-type (list light)) is the code you'd have to add to your services. <L29Ah>so now when you ask "how do i lower the volume of app X" the answer is "install pulseaudio", even if the hardware is capable of doing it itself <adfeno>mbakke, numerobis, NieDzejkob: Re: error with module-import-compiled. Doing a git bisect, I found the possible bad commit, it is 8234fe653e61d0090138cbd4c48d877568355439 . <leoprikler>I really have no problem with using PulseAudio for volume control, now that I've patched flat-volumes away. <bandali>leoprikler, thanks, will see if i can learn more about that <adfeno>mbakke, numerobis, NieDzejkob: Re: error with module-import-compiled: however, I don't know how to fix that. <NieDzejkob>adfeno: Ouch, what was the reproducing command, again? <adfeno>NieDzejkob: Any `guix package -i' or `guix package -u' that would cause module-import-compiled to be either built or downloaded. <L29Ah>leoprikler: i have problems with my system consuming extra CPU cycles doing useless stuff on battery and adding unnecessary latency when i'm making music, but in fact my biggest problem is that i never managed to make pulseaudio work w/o problems <adfeno>For example, I tested with this one: guix package -i python-testpath <adfeno>I tested so far in a x86-64 foreign distro as non-root user. <leoprikler>Does anyone know, where the module-import-compiled code is at? <leoprikler>That package needs to be built with guile-next, simple as that. <pkill9>what do people do to increase battery life? <adfeno>I cannot. GNU/FSF email setup doesn't accept email providers which enforce updated TLS versions. So this is why I'm reporting it here, so others can do that in my place. <adfeno>(also, I'm trying to find a way to help GNU/FSF improve their email setup for updated TLS compatibility) <adfeno>(or, alternatively, convince the email provider I use to be a little lax on that matter) <L29Ah>pkill9: powertop --auto-tune, powersave governor, SIGSTOPing the browser, fixing bugs in software that wakes up excessively frequently ***calher1 is now known as calher
<L29Ah>also making sure ASPM works, PSR is enabled if present, unused radios are off and so on <pkill9>i want to reduce CPU usage to as low as possible to squeeze my crappy battery as much as possible, it gets 2 hours 20 minutes streaming youtube in chromium at full screen brightness with headphones <pkill9>without putting in any effort to save battery life, i can stream one movie basically <pkill9>i'm wondering how few CPU calls can be made <pkill9>plus running it in the 'cage' wayland compositor <adfeno>leoprikler: Re: module-import-compiled error: The issue started in 8234fe653e61d0090138cbd4c48d877568355439 <NieDzejkob>leoprikler: /gnu/store/jpk9w01q6f7hd4xrhwh5bw00631pkh1q-module-import-compiled.drv <NieDzejkob>triggerred by `guix environment --ad-hoc python-testpath` and `guix package -i python-testpath` <pkill9>which software shows which processes use the most battery? <L29Ah>also i found aftermarket laptop batteries to contain crappy cells, now waiting for a dozen of good 18650s to arrive to recell my X210's battery to hopefully get 80% more runtime <leoprikler>NieDzejkob: I'm pretty sure that (@@ (guix derivations) %compiled-modules) and (@@ (guix gexp) compiled-modules) both use nothing else than %guile-for-build, and I'm not sure whether that's guile-next. <lfam>Buying aftermarket batteries is such a drag <L29Ah>expect to have 16 hours in reading/coding/chatting mode <pkill9>is the thinkpad x210 the modded x201? <L29Ah>yes, it's X201 with a gen8 Intel and modern screen <pkill9>is there a benefit over modding an x230? <L29Ah>pkill9: faster and less power-hungry CPU, NVMe slot, sturdier case, better keyboard *L29Ah also has a X230 that is kinda messed up by the FHD mod <L29Ah>pkill9: i ordered the mobo and display and fitted them into my X201 <pkill9>i'm interested in possibly doing something like this <L29Ah>only some photos on a chinese forum <L29Ah>and the support is crap, if you have the money you may want to buy a complete machine instead <L29Ah>check forums.thinkpads.com, i think the most of discussion on such modded thinkpads in English is there <pkill9>you mean a pre-modded one, or a whole different laptop? <L29Ah>sadly no mass produced laptop nowadays seem to strike the optimal point between sturdiness and ergonomics that Lenovo did with X6{0,1} and X20{0,1} *mwette has made a little progress w/ SElinux <mbakke>roptat: the python-argh, -watchdog and -pathtools you added recently already existed in Guix since ~December ***calher is now known as KE0VVT
<civodul>roptat: looks like you changed signing keys, right? <civodul>could you email us the details and/or update git-authenticate.scm? <NieDzejkob>Wouldn't git-authenticate.scm be only updatable by Ludovic according to the docs on verifying the checkout? <apapsch>Hi, is it safe to run guix pull while guix build is running? I'm trying out gccgo based on gcc-9 and it's taking a while :-) <nckx>You'll need enough RAM (but that goes for anything) and enough build slots (--max-jobs) configured to allow building gccgo + guix at the same time. Should be fine in the default configuration. <jeko>nckx: I am guix pulling on my digital ocean droplet ! <jeko>but I can't ssh to it :/ <nckx>jeko: Congratulations! So you're using the console? Is openssh-service-type part of your operating-system's services field, and are you trying to log in as a regular user (not root)? <jeko>nckx: yep lucky me there is the console haha! <jeko>nckx: Holy crap you make me look my system config and realized I ssh on the wrong port...