IRC channel logs


back to list of logs

<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?
<sirgazil>guix repl tells you
<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
<pkill9>but anyways
<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.
<sirgazil>Had to reboot.
<leoprikler>Actually, you don't.
<leoprikler>Unless you killed GDM somehow.
<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.
<leoprikler>Assuming you still get into a TTY or have SSH.
<sirgazil>leoprikler: You mean Ctrl+Alt+F1 is not supposed to get you back to the GNOME desktop?
<sirgazil>I don't understand
<leoprikler>I'm pretty sure it's Ctrl+Alt+F8
<leoprikler>F7 is GDM.
<sirgazil>Oh, It was F7 in previous distro I used.
<sirgazil>In Debian
<sirgazil>And Ubuntu
<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
<leoprikler>I'm on DISPLAY=:2
<leoprikler>and F9
<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.
<sirgazil>Oh, really!
<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.
<sirgazil>The computer works fine though.
<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…
<adfeno>Hi there,
<jeko>nckx: haha you're right !
<jeko>adfeno: hey !
<jeko>bye all!
<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
<adfeno>Sorry, got a connection problem
<numerobis>adfeno: I have exactly the same issue with "guix install jupyter"
<numerobis>(And I did a guix pull earlier today)
<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).
<raghav-gururajan>Hello Guix!
<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>*there is no
<raghav-gururajan>PotentialUser-52 ^ ^
<jackhill>raghav-gururajan: oh, is the gdm problem known about? I didn't know what was going on, so I opened
<raghav-gururajan>jackhill I assume so. I was reading today's messages from gnutec in the IRC log.
<PotentialUser-52>raghav-gururajan: thanks, giving sddm a shot. good to know about gdm
<PotentialUser-52>what about cdm or any of these? are they not packaged?
<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>PotentialUser-52 I had no idea that existed. Gonna have a look
<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
<raghav-gururajan>Oh :/ Other than lightdm, I do not have any other suggestions.
<jackhill>raghav-gururajan: ok, just wanted to make sure I was aware of all the information that is out there.
<raghav-gururajan>jackhill Cool!
<PotentialUser-52>raghav-gururajan: thanks. doesn't look like a greeter. I'll read
<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
<PotentialUser-52>ohh so there's no automated guix command for it?
<jackhill>PotentialUser-52: guix bisect?
<PotentialUser-52>is that a command?
<PotentialUser-52>just curious how you found the commits... or did you git bisect?
<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?
<PotentialUser-52>jackhill: got it. thanks for the info. seems involved
<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>./ ./configure: /bin/sh: bad interpreter: No such file or directory
<bandali>here’s my attempt:
<bandali>any thoughts on what i’m doing wrong?
<Blackbeard[m]>gnufr33d0m: did you set any environment variables?
<terpri>gnufr33d0m, do you have GUIX_LOCPATH set up as described in ? guix uses its own locale packages rather than the foreign distro's
<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
<bandali>reepca-laptop, hmm, here’s the full build log:
<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, but i wonder if/where are the other references?
<reepca-laptop> it's trying to do the whole ./bootstrap && ./configure && make sequence all at once
<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 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, you could just remove that phase entirely. Personally I'd use substitute* or similar to comment out the last two lines of, 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
<bandali>will do, thanks :)
<reepca-laptop>they all do it a little differently, but there should be enough examples there to see how substitute* works
<bandali>ha, i see one instance in rust.scm
<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]>hello guix!
<raghav-gururajan>g_bor[m] o/
<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.
<raghav-gururajan>Regarding keyboard-layout, I think fixing bootloader is better.
<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.
<raghav-gururajan>Could you detail me on the gracefully part?
<raghav-gururajan>Not sure what you are referring to.
<g_bor[m]>raghav-gururajan: I got an error that there is a type mismatch.
<raghav-gururajan>Ah I see.
<g_bor[m]>I will run a simple test to see what it does.
<raghav-gururajan>Sounds good.
<g_bor[m]>ok, this is an installer limitation.
<g_bor[m]>It did not surface beacuse the installer always sets the keyboard-layout...
<raghav-gururajan>I see.
<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.
<raghav-gururajan>But wouldn't that completely skips installation of bootloader?
<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.
<raghav-gururajan>Ah, got it now.
<raghav-gururajan>Yeah, no bootloader unless specified seems like a good default.
<pkill9>does `guix gc --delete-generations` delete generations from all profiles?
<raghav-gururajan>pkill9 Yes, all user 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
<pkill9>ah nice, that's helpful to have
<raghav-gururajan>navik Are you trying to set version for kernel?
<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.
<DamienCassou>hi everyone
<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.
<raghav-gururajan>DamienCassou Hi o/
<raghav-gururajan>navik Ah I see.
<raghav-gururajan>> I should get a new computer soon and I intend to install Guix on it
<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>navik, you probably borked your config
<leoprikler>use Emacs to indent it, that usually highlights an error
<leoprikler>otherwise paste it and let us handle that
<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
<leoprikler>has it been updated since the previous version?
<navik>leoprikler: you are certainly correct!
<navik>raghav-gururajan: will try
<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
<raghav-gururajan>navik Welcome!
<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
<raghav-gururajan>DamienCassou In my experience, I started off with tweaking the configuration based in options provided in manual. But this might help -->
<DamienCassou>thank you
<raghav-gururajan>*based on
<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 pipe the man page/manual of guix to emacs
<raghav-gururajan>Oh wait, on a different syste.
<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.
<nckx>numerobis: ‘upload’?
<numerobis>nckx: sorry, I meant 'update'
<raghav-gururajan>nckx Morning o/
<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
<raghav-gururajan>That's even better ;-)
<mbakke>nckx, numerobis actually cURL has been patched to respect SSL_CERT_FILE and SSL_CERT_DIR on the 'core-updates' branch:
<nckx>mbakke: Great news!
<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 🙂
*nckx → afk
***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
<mbakke>or just paste it here, if it's very short
<adfeno>It has multiple lines though
<adfeno>(it's a backtrace)
<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?
<numerobis>adfeno: I remember you were experiencing an error similar to mine yesterday, so I'm pasting it here: (You might be talking about something different now, though)
<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)
<lafrenierejm>mbakke: is the pastebin for relevant part of my #:phases. LMK if you want my entire patch.
<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).
<lafrenierejm>mbakke: install-file seems to work. Thank you!
<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.
<NieDzejkob>does guix pull trigger it? guix install hello?
<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>hey I just read
<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.
<adfeno>I'll resume the bisect
<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
<lurch>ah ty
<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 :-)
<raghav-gururajan>Woah! Woah! Woah! I was just reading about Dragora GNU/Linux. Their package management design+function look kinda similar to guix/nix.
<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
<sirgazil>and then: . "$GUIX_PROFILE/etc/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>mwette: More information about it (including Guix on foreign distro):
<sirgazil>near 7th paragraph.
<sirgazil>raghav-gururajan: What is the next phase of your GNOME work?
<g_bor[m]>hello guix!
<bandali>sirgazil, i liked the new logo you proposed for guile btw :-) maybe post it to one of the guile lists?
<bandali>g_bor[m], howdy
<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]>bandali: howdy
<g_bor[m]>I guess this is related to the guile3 migration.
<bandali>ha yeah i see those warnings upon system reconfigure as well
<bandali>civodul, any thoughts? ^
<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]>ok, thanks.
<bandali>NieDzejkob, and?
<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?
<sirgazil>bandali: about the logo, I will.
<bandali>sirgazil, great :-)
<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
<bandali>i see
<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?
<NieDzejkob>civodul: guix repl for me
<bandali>what’s guix system build do?
<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>with no warnings or anything
<bandali>i did that without the usual sudo -E, btw
<civodul>(why "-E"?)
<civodul>so "sudo -E guix system build ..." gives you the warnings?
<bandali>to have guix system use my environment rather than root’s?
<bandali>let me try
<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
<NieDzejkob>ran a reconfigure now to get a datapoint:
<bandali>^ is similar to what i see
<bandali>in terms of the warnings
<bandali>on an unrelated note, i’d appreciate some eyes on my pasystray package attempt, and hints as to why it’s failing
<bandali>my attempt: build log:
<civodul>oooh, i see
<civodul>bandali: mostly likely their 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>hence the error
<civodul>one solution is to override the 'bootstrap' phase to run "autoreconf -vif" instead of ""
<civodul>or remove
<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>bandali: the simplest one :-)
<bandali>civodul, ah, cool :-)
<civodul>in general i choose the option with as few lines of code as possible
<bandali>i’ll try removing then
<bandali>thank you
<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.
<sneek>Got it.
<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 :)
<leoprikler>same here on one of my systems
<leoprikler>that system does have an SSD though
<raghav-gururajan>civodul The warnings come up once 'module-import-complied' starts during system reconfigure.
<raghav-gururajan>sirgazil :-)
<leoprikler>this is likely a guile vs guile-next problem
<raghav-gururajan>leoprikler hi o/
<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>$GTK_VERSION seems weird inside m4
<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
<raghav-gururajan>leoprikler That can certainly be the cause.
<bandali>civodul, i was indeed!
<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?
<DamienCassou>does anyone know how to enable the spice vdagent?
<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
<leoprikler>if there's none, use a commit and git-version
<raghav-gururajan>bandali the latter. commits or tags along mentioning git-fetch
<bandali>leoprikler, raghav-gururajan, thank you both
<raghav-gururajan>bandali For your reference ( :-)
<bandali>thanks :-)
<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)
<leoprikler>or is emacs not an explicit input?
<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
<DamienCassou>bandali: hi :-)
<leoprikler>I just checked, they should normally have (native-inputs `(("emacs" ,emacs-minimal)))
<bandali>DamienCassou, heya! nice seeing you here :-)
<leoprikler>ah, only some built with gnu-build-system
<bandali>right… so i’m not sure what the best way would be
<bandali>an example would be great
<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
<NieDzejkob>PotentialUser-52: paste full error
<leoprikler>for the other ones, you'd have to adapt package-with-explicit-python to emacs-build-system
<leoprikler>(i.e. create package-with-explicit-emacs)
<bandali>ah, i see. will look into that, thanks
<PotentialUser-52>NieDzejkob: will build curl... few mins
<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
<PotentialUser-52>NieDzejkob: here's the last 300 lines (the whole thing wouldn't paste):
<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
<PotentialUser-52>NieDzejkob: yeah
<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
<L29Ah>where can i find the file described at in the Guix qemu image?
<NieDzejkob>L29Ah: what do you mean by "the Guix qemu image"?
<L29Ah>NieDzejkob: this one
<NieDzejkob>(you're talking about the templates, right?)
<L29Ah>i mean the file that contains the "operating-system declaration"
<nckx>sirgazil: …new Guile logo (idea)? Where? 🙂
<NieDzejkob>L29Ah: try /etc/configuration-files
<NieDzejkob>wait, no, /etc/configuration-templates
<L29Ah>it's /etc/config.scm, thanks
<nckx>sirgazil: 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?
<drakonis>it provides binary builds, yes.
*nckx prefers <>, because IMO you resolved the overlap nicely with the subtle white ‘u’ outline. Also, λogos are over-used, not your fault 😛
<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].
<sirgazil>nckx: Thanks for taking a look.
<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>real quick question
<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>"I.e. not at all." why?
<drakonis>oh man, kde is slowly getting included.
<drakonis>this pleases me.
<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>so you have to secure it yourself.
<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.
<drakonis>because their model is a full system
<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>its really bothersome
<drakonis>because there's a service for deploying containers, but it takes away a lot of power
<NieDzejkob>how can I make X11 work in a container? --share=/tmp/.X11-unix should do it according to, but it doesn't:
<drakonis>that's how you do it
<NieDzejkob>drakonis: are you responding to me?
<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>ie: do nix style containers
<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
<drakonis>its honestly pretty boring
<nckx>So really ‘guix system container’ (pretty sure we were first, or at least that Nix-style gives them too much credit :-p).
<NieDzejkob>ah, I had to --share=~/.Xauthority too
<nckx>Well, boring is often good. But sure.
<drakonis>NieDzejkob: connect to :1
<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
<nckx>What are those?
<L29Ah>can i ask guix to install a package system-wide (for all the users at once)?
<drakonis>system rebuilds i think?
<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.
<Blackbeard[m]>Hi :)
<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
<nckx>o/ Blackbeard[m]
<leoprikler>nckx: s/sleep/eat/ 🙃️
<nckx>Mais alors.
<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
<Blackbeard[m]>nckx: hi ٩(◕‿◕。)۶
<drakonis>having the ability to use containers that arent just store packages is a thing i would like to use
<Blackbeard[m]>I am looking on what can I work on for guix
<drakonis>ho ho.
<drakonis>we have a lot of these
<nckx>Blackbeard[m]: \(^o^)/
<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
<Blackbeard[m]>But I would like to actually write code
<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.
<nckx>Oui oui.
<drakonis>you mangy dog!
<Blackbeard[m]>nckx: if you have anything in mind I'll appreciate the help :)
<Blackbeard[m]>To be honest I feel a little intimidated
<drakonis>Blackbeard[m]: check the roadmap for some inspiration
<drakonis>these tasks are a bit more on the heavier side of things
<nckx>Blackbeard[m]: There's also, mostly packaging requests but that's also writing code and often an easy way in.
<Blackbeard[m]>Ah yes
<Blackbeard[m]>Both the roadmap and wishlist seem great
<Blackbeard[m]>Thank you both nckx and drakonis
<Blackbeard[m]>Let me see
<Blackbeard[m]>What modes do you use with emacs to develop for Guix ?
<drakonis>actually there's a talk on the perfect setup
<Blackbeard[m]>I think geiser, paredit
<drakonis>those two and magit for managing the git repository
<leoprikler>just electric-indent-mode for me
<leoprikler>although I do have both geiser and magit ready in case that I need them
<nckx>Blackbeard[m]: There are at least two tasks that could be done as part of an Outreachy internship if you qualify:,
<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
<L29Ah>> No repositories found
<nckx>Switch them on before a con; you will attract people and can tell them about Guile.
<L29Ah>ah, a typo
<Blackbeard[m]>Although I told a girl I know who codes about outreachy
<Blackbeard[m]>ROADMAP - guix.git - GNU Guix and GNU Guix System
<nckx>Blackbeard[m]: Ah, that's great!
<nckx>See the link there.
<nckx>More ideas!
<Blackbeard[m]>Yes awesome ٩(◕‿◕。)۶
<Blackbeard[m]>I want to learn as much as possible
<nckx>Blackbeard[m]: I hope you like networks, because P2P substitutes are really something I'd love to see.
<Blackbeard[m]>I've been using Guix for a few years
<Blackbeard[m]>But coding for guix always intimidades me
<drakonis>well now!
<Blackbeard[m]>But I really want to help
<nckx>Blackbeard[m]: Why?
<drakonis>that's nice.
<nckx>It's the most untimidating project I know.
<drakonis>it shouldnt be intimidating tho
<nckx>I mean, they even let me in.
<Blackbeard[m]>Because I learned on my own with books
<Blackbeard[m]>The little schemer, land of lisp, how to design programs
<drakonis>that's not a problem.
<Blackbeard[m]>But real projects are hard
<Blackbeard[m]>But I will try
<Blackbeard[m]>Worst case scenario I learn a bunch of stuff right?
<Blackbeard[m]>I just need someone to teach me how to move around the big code and understand how it works
<drakonis>that we can do
<drakonis>all help is always welcome
<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
<Blackbeard[m]>Awesome ٩(◕‿◕。)۶
<Blackbeard[m]>Well let me start by checking ideas and projects
<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>I think paredit is really great.
<sirgazil>geiser could do better in autocomplete and autodoc (compared to same features in IDEs)
<sirgazil>rainbow parens helps me read structure better.
<drakonis>company mode maybe?
<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.
<Blackbeard[m]>NieDzejkob: awesome :)
<drakonis>you have to evaluate the buffer to actually import the modules
<Blackbeard[m]>Yes I was wandering about something like jump to definition
<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
<drakonis>L29Ah: soon
<drakonis>this is going to be beautiful.
<drakonis>time to annex the gentoo fans
*L29Ah is a gentoo fan trying to figure guix
*joostvb is a debian developer, lurking here
<rupicapra>Hey everyone
<drakonis>that email makes me want to waltz into gentoo's channels and link it
<drakonis>because it'd be a very exciting thing
<lfam>Which channel, drakonis?
<drakonis>#gentoo and #gentoo-chat
<drakonis>i think gentoo's main channel is a support channel
***ChanServ sets mode: +o lfam
<drakonis>wait why did you just go on op mode
*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
<lfam>Not related!
<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'
<drakonis>oh yeah that's a thing right now
<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
<drakonis>this would be my first bug report
<drakonis>someone else do that one
<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).
<L29Ah>this sucks
<civodul>the 'delete' warning is a 3.0 thing (totally harmless but totally annoying)
<nckx>L29Ah: Ah, cool!
<drakonis>its very misleading though
*nckx == Tobias.
<rupicapra>oh okay
<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"?
<leoprikler>Gentoo USE flags come in two flavours.
<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>nckx: for instance, wine has those flags:
<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.
<nckx>L29Ah: Thanks, reading.
<civodul>drakonis: it's a very low-hanging fruit actually, would be fun to add
<civodul>also a service to run an OS in a VM
<drakonis>also great
<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
<civodul>ah, that's another thing,
<civodul>but surely doable
<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.
<nckx>What'm I missing?
<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
<L29Ah>since it's unique to wine
<nckx>leoprikler: Agreed.
<nckx>L29Ah: What are the semantics?
<L29Ah>ah, got it
<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?
<drakonis>drop-in replacements for software
<drakonis>that's also useful
<tsmish>Hi guixers.
<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
<L29Ah>lfam: yes
<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>It's just very slow
<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.
<L29Ah>a part of curl ebuild, for example:
<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, you have 1 message.
<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.
<slyfox>worth a try :)
<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.
*nckx → foodz.
<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
<Blackbeard[m]>Is it too hard?
<leoprikler>drakonis: In those places where it's really necessary, you can wrap the package in a function and call it a day.
<leoprikler>Hint: It's most likely not.
<Blackbeard[m]>P2P substitutes would be great too
<L29Ah>Blackbeard[m]: it's too useless i'd say
<Blackbeard[m]>L29Ah: why?
<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?
<Blackbeard[m]>Well I don't know
<drakonis>cut down on the dependencies maybe?
<Blackbeard[m]>Maybe cutting down server costs
<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
<drakonis>let 'em have their fun
<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
<Blackbeard[m]>So doing something useless is probably better
<Blackbeard[m]>That way I won't create trouble and I'll learn
<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>its for the api
<Blackbeard[m]>So maybe the only problem it will solve is teaching me
<drakonis>plug into alsa using software to be able to use pipewire instead
<drakonis>same with jack and pulseaudio
<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
<drakonis>three of them actually.
<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>alsa, jack and pulseaudio.
<drakonis>OSS is understood by every minor unix at this point
<drakonis>it practically doesnt matter.
<L29Ah>yeah since Linux with its ALSA won the popularity contest
<drakonis>rsound is a racket library lol
<NieDzejkob>I'm distributing a project and I want to provide a Guix manifest for use in `guix environment -m
<NieDzejkob>uhh, premature enter
<NieDzejkob>anyway, one of the packages I need is not available, and it's just a small Python library
<drakonis>L29Ah: that's very reductive.
<NieDzejkob>guix import pypi works fine. There's no point in submitting that upstream to Guix, right?
<leoprikler>Yes, there is.
<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)
<leoprikler>bandali: have a look at udev-service-type
<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
<NieDzejkob>indeed, happens on my side too
<adfeno>I tested so far in a x86-64 foreign distro as non-root user.
<NieDzejkob>adfeno: Have you sent anything to bug-guix yet?
<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?
<leoprikler>GNOME uses too much battery, console it is.
<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)
<NieDzejkob>leoprikler: I wouldn't be so sure of that, considering the error log for that derivation:
<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
<L29Ah>kill chromium, use mpv
<pkill9>running gnome desktop as well
<pkill9>yea, it's more of a baseline
<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
<leoprikler>NieDzejkob: which derivation is that?
<drakonis>can't wait for kde to be available.
<pkill9>plus running it in the 'cage' wayland compositor
<pkill9>from the console
<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
<pkill9>did you mod it yourself?
*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>do you have a link to a guide?
<L29Ah>there's no guide
<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, 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?
*civodul -> zZz
<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>apapsch: Absolutely.
<apapsch>nckx: Great!
<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...
<jeko>nckx: better right now