IRC channel logs


back to list of logs

<pineapples>Can someone guide where I can find the code responsible for populating the "/run/current-system/profile/share/guile/site/3.0" directory?
<roptat>pineapples, it's a union of all the packages in the profile
<roptat>so, whatever package is in there that have a file in share/guile/site-3.0 will end up there
<pineapples>roptat: I see. I'm trying to figure out why it isn't populated with the modules of a third-party channel I'm using. I have to (add-to-load-path "~/xxxx/guile/site/3.0") in order to use them in my own Guile modules, which extend my system configuration.
<roptat>because the channels populate the profile at ~/.config/guix/current
<roptat>not your operating system's
<roptat>unless you add your channel as a package and add it to your os' packages field
<pineapples>This makes sense now. Thank you. Now I'm wondering if it would be wise of me to suggest guix-devel to add that directory to the $GUILE_LOAD_PATH env var. I guess this is not going to happen
<roptat>no, I do that when you configure your home with guix-home-manager, but it also causes some troubles, especially with provenance
<pineapples>roptat: So, if I understand correctly, adding a third-party channel as a package instead of exporting that env var or doing (add-to-load-path "~/xxxx/guile/site/3.0") will save me some troubles?
<pineapples>setting that env var*
<roptat>maybe, not sure
<roptat>setting the channel as a package doesn't feel natural either
<pineapples>I feel like I'm hitting the same wall, that one obstacle, which also happens to prevent our installer from accessing modules from third-party channels, again.
<pineapples>Would be nice if it were possible to declare channels in a system configuration
<pineapples>maybe that would allow us to easily make modules of third-party channels globally visible to guile at the same time
<rekado>pineapples, roptat: see also the discussion on GUIX_EXTENSIONS_PATH here:
<rekado>I think it would be good to have something like that, but not with the implementation I submitted for discussion.
<pineapples>rekado: Thanks. Do you think it could be adapted for adding Guile modules from online, third-party channels configured via the channels.scm file to the guile search path?
<ces>Is there a smart way to find the name of a package? Like, right now i need webkitgtk as an input, but i can't find out how to include it.
<ces>...I have downloaded it (guix install webkitgtk) btw
<mbakke>ces: 'guix show webkitgtk' will show the location of the package, from which you can find the variable name
<mbakke>webkitgtk is called 'webkitgtk'
<ces>mbakke: So it is the filename?
<mbakke>ces: no, the file name makes the name of the module, i.e. (gnu packages webkitgtk); the number following the file name denotes the line number in the file
<ces>mkakke: What is the actual disc location, i get gnu/packages/webkit.scm, but i can't seem to find it at /gnu... or .config/guix...
<roptat>ces, "guix show webkitgtk" shows "location: gnu/packages/webkit.scm:225:2", meaning it's in gnu/packages/webkit.scm, so the module name is (gnu packages webkit): you take the directories and filenames without extension. You need to include it in the file you define your package in, as in (use-modules (gnu packages webkit)), then you'll be able to use the variables defined in that module, which include webkitgtk
<mbakke>ces: the file name is relative to the guix source code tree:
<pkill9>i'm getting this error on *anything* guix tries to build unless I use --fallback: In procedure put-string: Wrong type argument in position 1 (expecting open output port): #<closed: string 7f916bfad850>
<pkill9>is anyone else getting this error?
<pkill9>it did it with guix pull aswell, but --fallback made me able to build guix
<lfam>pkill9: It sounds like a network problem if --fallback worked
*apteryx yawns (deleting `/gnu/store/trash')
<dissoc>does anyone use the stump-contrib packages? if so, how am i supposed to use them?
<dissoc>i installed them but i guess my stumprc file isnt working
<dissoc>previously i just used (set-module-dir ...) and then (load-module "something")
<samplet>Woah. I just wrote a phase and I had to stop myself from tacking a ‘#t’ on the end of it. :)
<elais>dissoc: when you do (require :swm-gaps) does that work?
<elais>also a number of the stumpwm-contrib packages are in guix, my advice is to install the ones you want alongside stumpwm+slynk
<elais>for instance cl-stumpwm-swm-gaps is packaged for guix
<luhux`>An unfortunate thing happened and my Guix System machine couldn't use guix environment --container after the update. What should I do?
<luhux`>guix environment: error: cannot create container: unprivileged user cannot create user namespaces
<luhux`>guix environment: error: please set /proc/sys/kernel/unprivileged_userns_clone to "1"
<luhux`>This happened on all my Guix System machines
<luhux`> commit: 635fefa0493af3f1e61f0780883ee0c2bd4c74cc
<Zambonifofex>hewwo gwix uwu
<Zambonifofex>So, I decided to make the changes janneke proposed to me in order to update the `netdde` package for Hurd (i.e. update the `gnumach` and `hurd` packages too). I have followed the steps in the “Building from Git” section in the manual, and I’m currently waiting for `make check` to finish running.
<Zambonifofex>Is that sufficient to determine that the build has been successful, or do I need to perform some other kind of verification to be certain that my changes are not problematic? (Note: I’m running it from Linux.)
<peli>Hello friends
<peli>I'm new to Guix. I just installed the Shadowsocks package, but I haven't changed anything. How should I work with it? What should I change?
<luhux`>peli: Can you provide more information?
<peli>I do not know much about Guix and Shadowsocks, I have not changed the config.scm file.
<luhux`>peli: Do you just need to use shadowsocks commands?
<peli>I have the same question, should not I change the config file?
<luhux`>If you only need to run it temporarily, you can use guix environment --ad-hoc shadowsocks - your command to run it
<luhux`>If you want to use it for a long time, you can write it in /etc/config.scm or install it in your user profile (guix package -i shadowsocks)
<luhux`>The difference is that config.scm is system global
<olivuser>good morning guix o/
<peli>luhux: Thank you very much
<peli>I'm checking this...
<olivuser>I'm still struggling with one issue on my newly installed (somewhat) guix system. I installed exwm as a window manager (emacs x window manager), which either uses dmenu or "read-shell-command" (s-&) to start programs. Now I have no problem installing programs, and I have no problem launching a program via command line (even vterm in emacs). BUT dmenu doesnt find any programs, s-& doesnt auto-complete (dunno if it does usually), and often when I try
<olivuser>to open a file I am prompted with the error that "searching program: git not found" even though I know that git is installed on my system. Does anyone know what the problem could be?
<olivuser>I tried sourcing /etc/profile via ~/.profile and ~/.bashrc to no effect
<olivuser>I am wondering if this is because my init.el (use-package) packages are not identical to my emacs-related packages installed via guix.
<olivuser>could it be that emacs is angry because I have not installed a git-related program, like tig, via guix?
<luhux`>olivuser: Starting exwm in ~/.xsession may solve this problem
<jeko>Hello Guixters!
<Zambonifofex>Hello, jeko! 👋
<jeko>Hey Zambonifofex!
<jeko>Someone knows why I recently get a SSH error to guix deploy to my VPS ?
<jeko>I am wondering if it can be connected to openssh-server on the machine from which I deploy
<jeko>but why ?
<Zambonifofex>So, apparently I fell asleep while `make check` was running. Now I am awake, and it has finished running. It shows two red `FAIL` lines for `tests/channels.scm` and `tests/publish.scm`, though. Is there any way I can get more information about the failed tests?
<janneke>Zambonifofex: there's test-suite.log and individua log files like tests/channels.log
<janneke>have you tried building and booting a hurd vm with your new changes?
<Zambonifofex>janneke: I assume `make check` built things before running the tests, given that it showed a bunch of compilation lines like `CC`, `CXX`, `GUILEC`, etc. I’m not sure how I can tell it specifically to build a Hurd image, though.
<janneke>Zambonifofex: i don't think that "make check" actually builds a hurd image
<janneke>gnu/system/examples/bare-hurd.tmpl has a comment on how to build and run an image
<new[m]1>How can I download Guix Hurd?
<new[m]1>This link does not download.
***ece7 is now known as ece
<Zambonifofex>new[m]1: Try using the “Build outputs” link in here:
<olivuser>luhux`, thanks for the suggestion, though I think I dont understand it.
<olivuser>because as it stands exwm is launched by gdm after logging in
<olivuser>what would be the difference if starting via ~/.xsessions?
<olivuser>would I shortcircuit the gdm login process?
<divoplade>Hello, when I run a guile program from my package in a shepherd forkexec service, the GUILE_LOAD_PATH is not set so my program cannot find its dependencies. Those dependencies are propagated inputs to my package though. Is this normal?
***apteryx is now known as Guest63572
***apteryx_ is now known as apteryx
<divoplade>Ha I see that cuirass has a 'wrap-program phase that seems to just do that: look up where the dependencies are and write them into the final program
<Zambonifofex>janneke: It seems to fail to build `glibc` on `#include <cthreads.h>`
<Zambonifofex>And I’m not sure whether this is related to my changes or not… I mean, I’d imagine probably, but I’m not sure.
<peli>luhux: I had this problem [] while running, what is the solution?
<iyzsong>divoplade: yes, propagated-inputs only useful when package are installed into a profile, or as input to build another package.
<divoplade>iyzsong, to me it would make sense to include them in a gexp input when the package is mentioned
<iyzsong>"include them" is not enough, at the end some environment variables must be set (profile and the builder set them, or we have to wrap them use wrap-program, etc.)
<divoplade>Is there a documentation for wrap-program?
<iyzsong>it's in 'guix/build/utils.scm', the 'wrap-program' procedure have inline doc. also, you can search other packages for usages..
<divoplade>I've found it used in cuirass but I did not understand it
<divoplade>The inline doc is better
<janneke>Zambonifofex: yes, it would be good to know if that's because of your changes or not
<pkill9>it's deffo not the build farm as my vps can download from it
<Zambonifofex>janneke: Maybe it’d be a good approach to clone the Guix repo to a different directory and try to build it fresh?
<Zambonifofex>It seems there has been a change removing `cthreads.h`, supposedly more recent than the last version of Hurd that was being used before:
<Zambonifofex>(This being the last commit regarding it.)
<Zambonifofex>I remember that the previous commit used for Hurd was considerably old, but I don’t remember how much so.
<Zambonifofex>Yeah, the previous commit was from January.
<janneke>Zambonifofex: yes, i'm using different worktrees a lot
<janneke>Zambonifofex: ah, so now your hurd is probably too new
<Zambonifofex>janneke: I see… Do you think it’s best to try to find an appropriate middle ground commit for it, or do you think it’d make sense to wait for `glibc` to be updated to reflect the changes in Hurd?
<guix-vits>idk what i doing wrong, but latest guixes not working for mine rockpro64. 81ea278 was last to work, somehow :)
<sneek>Welcome back guix-vits, you have 1 message!
<sneek>guix-vits, nckx says: ‘guix pull <bullshit argument>’ should be fixed on master.
<guix-vits>nckx: thank u
<pkill9>guix is broken for me and it makes me sad
<janneke>Zambonifofex: updating glibc is a big change, i would try an earlier hurd commit
<janneke>maybe you could ask on #hurd for how to find a matching netdde/gnumach/hurd on the glibc we have
<janneke>i think releases are tagged by date when debian makes a release
<atkka>I have a couple questions, new to guix
<janneke>my best guess would be to pick v0.9.git20200930
<atkka>I'm using it as a package manager on another distro, I installed icecat, fonts, fontconfig
<atkka>but icecat has no fonts, just boxes
<atkka>also no manpage or info page?
<atkka>installed the uft8 glibc locales as well
<iyzsong>atkka: after install fonts via guix, then maybe you need run 'fc-cache -fv', make sure run the guix 'fc-cache' binary.
<atkka>ok, I did use those commands but probably used the native system one
<atkka>how do you specify a guix program
<iyzsong>for manpage and info manuals, check MANPATH and INFOPATH, they should contain your guix profile paths.
<iyzsong>or via 'guix environment --ad-hoc fontconfig', if you not install it.
<atkka>oh will that just configure it then disappear?
<iyzsong>what disappear? the font cache is under ~/.cache/fontconfig, the env vars, well you should set them in your ~/.bash_profile or some places.
<atkka>the ad hoc command
<emys[m]>Is it normal that guix info pages don't show up when I start `info'?
<atkka>I will set the env vars in a script, i exported them manually for this session
<atkka>I have 22 fonts in my cache yet icecat still has no fonts
<iyzsong>yeah, i think on foreign distro, MANPATH and INFOPATH need to be setup manually.
<emys[m]>ah and another question, when using `git-download` for loading a third-package software, how does one deal with a polyrepo?
<iyzsong>emys[m]: for <git-reference>, set 'recursive?' to '#t' will let it also fetch submodules.
<emys[m]>not exactly what I meant. I mean a repo with 2 subdirectories A and B where you have A/ and B/ for example
<atkka>thanks for the help, I'll play around with it more tomorrow
<iyzsong>ah, okay. then that depends on what we want to do. if make two packages, then we can define A with a phase do '(chdir "A")', and B. if make one package, then figure out how to build it somehow...
<divoplade>Can someone briefly explain to me where the standard output and standard error of my running service is logged?
<divoplade>It seems that it is sent to a tty
<divoplade>But surely there should be a way to store it to disk, right?
<iyzsong>divoplade: unlike systemd, shepherd doesn't handle this. your service have to speak to syslogd, write to log file, or pipe its output via 'logger' or 's6-log', etc.
<divoplade>Thank you, how do you "speak to syslogd"?
<divoplade>"I want to speak with the manager of syslogd" x)
<divoplade>Google is confused by this request
<iyzsong>well, ship logs to syslogd can be done by write to "/dev/log"? I'm not sure...
<mdevos>divoplade: I'm not very familiar with syslog, but perhaps you can take a look at the syslog(3) man page?
<divoplade>There's no man page for syslog
<mdevos>divoplade: do you have the package man-pages installed
<mdevos>or look up syslog in the libc info manual
<divoplade>Oh I didn't understand it was implemented in libc
<Rovanion>Does anyone happen to know how to install Clojure? I've run `guix install clojure` but neither `clojure` not `clj` is present in my $PATH it seems.
<mdevos>rovanion: no idea, but you might want to try to create a pure enviroment with only clojure, then look at the environment variables
<mdevos>smaller environment --> less chance to overlook something
<mdevos>perhaps clojure is installed under an unusual name? I don't know, I'm only speculating
<Rovanion>As in `guix environment clojure`?
<olivuser>luhux, would you care to elaborate why starting exwm via ~/.xsessions (and not via gdm) would help with my problem? that would be lovely :)
<mdevos>rovanian: as in guix environment --ad-hoc clojure
<olivuser>other than that, are there any exwm users present?
<mdevos>otherwise you have an environment with clojure's dependencies instead of clojure instead
<dannym>Rovanion: Is it the first package you ever installed? Then you need to log out and back in for the guix user profile to be loaded.
<dannym>Rovanion: Does ~/.guix-profile/bin/clojure exist?
<dannym>Also, try echo $PATH |grep guix-pr
<dannym>The start script is called "clojure". "clj" is not present in Guix.
<dannym>Rovanion: Also, to find out what the executables installed are, try guix build clojure, then check the subdirectory "bin" of the directory whose name is printed by the former command
<Rovanion>mdevos: Thanks, didn't know that.
<olivuser>I forgot to mention that when in emacs, guix also fails to find guile when starting geiser
<olivuser>is that something someone can relate to? Hacking without geiser kinda sucks :D
<Rovanion>dannym: Not the first package, this is on a guix system. ~/.guix-profile/bin/clojure does not exist. guix-profile/{sbin,bin} exists in $PATH.
<Rovanion>dannym: There is no $(guix build clojure)/bin, only a $(guix build clojure)/share.
<cbaines>Rovanion, bin/clojure was only added recently, what revision of Guix did you install clojure with?
<Rovanion>Seems my guix was 18 days old :/. Running `guix pull`.
<cbaines>Ok, that makes sense, bin/clojure was added 16 days ago
<Rovanion>Thank you all!
<Rovanion>I've got a REPL now!
<ngz>sneek: later tell efraim: Hello. I think commit 063f6dfc37a674b24ca75fd20530a8039bddfd8f is going to break bat build, unless I overlooked something. I.e., it was not an omission on my side. Not sure how to handle it properly, tho.
<sneek>Will do.
<jeko>guix deploy: error: SSH connection to '' failed: Connection refused
<efraim>ngz: Indeed. It looks like bat needs libgit2 and pkg-config added
<sneek>efraim, you have 1 message!
<sneek>efraim, ngz says: Hello. I think commit 063f6dfc37a674b24ca75fd20530a8039bddfd8f is going to break bat build, unless I overlooked something. I.e., it was not an omission on my side. Not sure how to handle it properly, tho.
<efraim>sneek: botsnack
<divoplade>Is this a shameless advertisement for your website, jeko?
<divoplade>Too bad it's down ^^
<divoplade>I hope it will get back up soon.
<jeko>Haha no, I was deploying successfuly and know I am wondering why I get this error...
<ngz>efraim: OK. Let me try to build it with libgit2 as an input and pkg-config as a native input.
<jeko>The only thing I changed is I installed openssh-server on my Ubuntu. Maybe someone knows if it can be connected
<divoplade>Did you deploy a firewall update?
<jeko>I have no firewall configuration in the config I deploy
<divoplade>I guess that your main problem is you don't have an IPv6!
<jeko>in deed I disabled it
<jeko>on the VPS and in the machine conf I give to guix deploy
<jeko>should I enable it somewhere ?
*divoplade is giving jeko's address to "fix" the problem
<divoplade>(IPv4 address, of course ^^)
<divoplade>I don't know
<divoplade>I don't have a VPS
<jeko>(I call VPS the DigitalOcean droplet)
<divoplade>I don't know that either
<jeko>ok haha
<divoplade>I'm a little more pedestrian
<jeko>but if I can ping it should be OK ?
<divoplade>I have a computer, a router and an internet service provider
<jeko>I am also able to ssh to it !
<divoplade>Huh, I still get a connection refused
<divoplade>Maybe that's a network problem
<jeko>I will dive in the ipv6 direction tonight. Thank you divoplade to point me to something haha!
<ngz>efraim: I confirm bat builds with these inputs. I pushed the change. Thank you.
<kisaja[m]>i can't import
<divoplade>I have the same error, but maybe it's because tuxkart is not a GNU project.
<divoplade>Are you trying to install supertuxkart? If so, the command is guix install supertuxkart
<kisaja[m]>i want a to tweak some packge, to see whats the problem
<emys[m]>I get the error `guix build: error: regular file expected` when using `guix build --file=guix.scm`
<emys[m]>any idea what could be behind that?
<divoplade>kisaja, you can see the package definition of supertuxkart by running guix edit supertuxkart. From there, you can copy it to another file and tweak it there. Or, you can create a new package that inherits supertuxkart and tweak that inherited package (
<divoplade>emys, can you run head guix.scm?
<emys[m]>yes, I can also edit the file
<emys[m]>I have now started to add a couple of display statements and I think the error is not from reading guix.scm per-se but the follow up operations
<divoplade>emys, you can run guix environment --ad-hoc file -- file guix.scm to check for an anomaly
<emys[m]>reports ASCII text
<divoplade>No anomaly there :(
<kisaja[m]>how can i get proper use-modules for a package to install by guix package -f
<kisaja[m]>i copied from guix edit *
*kisaja[m] sent a long message: < >
<sss2>hi all, i have problem with build offloading
<sss2>any suggestions ?
<morgansmith>I'm thinking a commit 3 days ago broke containers for me. Can someone try guix environment -C on guix system real quick?
<sneek>Welcome back morgansmith, you have 1 message!
<sneek>morgansmith, wleslie says: do you have a `~/.guile` that configures readline? then you need readline in your environment, too
<morgansmith>I think that's from a really long time ago. What are you doing sneek?
<morgansmith>Oh, I think I might be running into bug # 45069 and 45066. Someone should really fix this :/
<morgansmith>(those bug reports are for the same thing btw)
<PotentialUser-67>I tried to send a patch to, but I did not receive a confirmation message. My patches are not in the archives of the mailing list. I tried using git send-email which usually works and icedove.
<PotentialUser-67>*three patches
<rekado>if this is your first email to the list it may take a little longer.
<PotentialUser-67>It's not my first email.
<PotentialUser-67>last time it just worked.
<gnutec>Guix is the best!
<mroh> /signed
<PotentialUser-96>Hi everyone ! Just to be sure, Guix only support ext4, btrfs, and JFS file systems, right ? Because F2FS seems to be supported when I look through the code
<gnutec>PotentialUser-96: The BTRFS is the best. I use and approve.
<morgansmith>f2fs is great until you git any problem and realize there is no software. Good luck trying to recover lost files on f2fs.
<PotentialUser-96>ok thanks, I'm reading the btrfs section in the manual
<nckx>PotentialUser-96: Your impression is mine as well. Did you encounter an error whilst trying to boot an f2fs system?
<narispo>aaaahh that's a lot of code for a single service:
<narispo>I see on the mailing that .NET Core wouldnt be packaged because not bootstrapable without proprietary software (or unreproducible binaries at least), but Fedora has it packaged and it's getting bootstrapped
<narispo>There is one politically interesting project (for the Free Software movement) that is Jellyfin, and it's made with .NET Core. Jellyfin is a multimedia server similar to Emby or Plex
<mbakke>narispo: do you know how Fedora bootstraps .NET Core?
<narispo>mbakke: I've looked briefly there:
<narispo>It has a "bootstrap" mode
<narispo>Otherwise it requires existing packages (previously compiled in Fedora)
<mbakke>narispo: if I read that .spec file correctly (unlikely), it looks like it first bootstraps using prebuilt sources, then when %bootstrap is false, it deletes those (see "Remove all prebuilts"), then builds again with the "bootstrapped" version?
<mbakke>that's not really "bootstrapping" in the sense of
<mbakke>Guix has a healthy aversion to any prebuilt sources.
<narispo>I don't see Fedora requiring proprietary software to grow the distro from scratch
<OriansJ>that is straight pile of blobs
<ngz>mbakke: I thought there was some tolerance for compilers. At least, at some point, there was. Did it change recently?
<narispo>mbakke: I can't find where it downloads any prebuilt binary so far
<mbakke>ngz: there is... if there really is no way to bootstrap .NET properly, we might just have to use those prebuilt binaries.
<OriansJ>ngz: especially zero tolerance for compilers
<OriansJ>as they are literally the basis of trusting trust attacks
<ngz>OriansJ: well, unless I am mistaken, some languages supported in Guix are not bootstrappable. Though, I agree this is an important goal.
<OriansJ>ngz: yes haskell and guile are 2 examples but they are in the process of being addressed.
<ngz>This is why I wrote "tolerance" instead of "acceptance".
<OriansJ>ngz: we can tolerate past mistakes but we need not tolerate future mistakes we know not to make
<narispo>mbakke: It uses that:
<narispo>Looks like the goal of the project itself is to comply with distro requirements
<narispo>"The key goal of this repository is to satisfy the official packaging rules of commonly used Linux distributions, such as Fedora and Debian. Many Linux distributions have similar rules. These rules tend to have two main principles: consistent reproducibility, and source code for everything."
<ngz>OriansJ: this is a strong stance. I'm not sure it is clear for everyone involved in Guix. Hence my (naive) question.
<OriansJ>ngz: well I am a radical side of guix; the #bootstrappable camp
<PotentialUser-96>nckx: Well last time I tried it didn't work, but it's probably not because of Guix
<ngz>I know only one side of Guix :)
<ngz>And no camp
<OriansJ>ngz: I know guix without substitutes
<narispo>Why would GNU Guile not be bootstrappable..?
<OriansJ>narispo: psyntax.pp requires a generated file to be run in the build
<nckx>PotentialUser-96: Do you remember how it failed?
<OriansJ>as one needs guile to generate that file.
<PotentialUser-96>OriansJ: Is a huge burden to use guix without substitutes ?
<narispo>OriansJ: Is that file arch-specific?
<OriansJ>PotentialUser-96: it just takes longer and things that break stay broken far longer.
<OriansJ>narispo: no
<OriansJ>it is essential for supporting of syntax-case in guile
<gnutec>PotentialUser-96: Try this after installation.
<PotentialUser-96>nckx: No but it was some months ago, I will try again now
<narispo>OriansJ: In what version was this file introduced?
<OriansJ>narispo: initial version
<narispo>OriansJ: How is that possible since devs would've needed a working GNU Guile to generate it? (which didnt exist yet) - Is bootstrap from version to version to the latest not possible?
<nckx>PotentialUser-96: Thanks!
<PotentialUser-96>nckx: It was in a vm, should I try on bare metal instead?
<nckx>gnutec: I'd probably recommend btrfs over f2fs too, but we should still support both if possible.
<nckx>PotentialUser-96: No, shouldn't matter.
<OriansJ>PotentialUser-96: for example someone who downloads guix 1.2.0 and follows these steps: will still not complete the guix pull because of gnutls-3.6.12 a known important issue:
<gnutec>nckx: Nice!
<OriansJ>narispo: they simply did steps to generate it prior to the first release and then cleaned out the supporting code.
<lle-bout>OriansJ: Urgh, what an horrible mistake
<PotentialUser-96>Well I will try to have a working system, will try without substitutes after
<OriansJ>lle-bout: shame about ugly code is usually the cause of these sorts of bootstrappable problems.
<lle-bout>There's no shame to have :-|
<OriansJ>lle-bout: you say that but wait until you get insults and death threats about the code that you release (or fail to release)
<OriansJ>because there are some toxic as shit people out there.
<lle-bout>Those people should be expelled from the community
<OriansJ>lle-bout: ideally but sometimes they aren't even part of the community. Like the people who were raising money to kill systemd's creator Lennart Poettering
<mdevos>oriansJ: you mean literally, like raising money to hire a murderer? Wouldn't that be flagrantly illegal?
*mdevos searches the web
<nckx>mdevos: Yes, yes it would.
<nckx>Hrm, openSUSE‌ Leap 42.3 < openSUSE Leap 15.2 ...?
<nckx>I'd ask jonsger to explain but they're off.
<OriansJ>mdevos: yes, it was and yes the FBI arrested people for it
<nckx>Buncha systemd fanboys.
<mdevos>OriansJ: ok, makes sense (the arrests, not the death threats)
<jonsger>nckx: I'm on
<jonsger>nckx: leap 42.3 is older then leap 15.2 :P
<nckx>Explain yourself young sir.
<OriansJ>nckx: honestly I never understood the hate for systemd; I might disagree with some of the engineering choices but this community runs on whoever does decides. And he did the freaking work.
<jonsger>nckx: "marketing" decisions back then when they jumped from 13 to 42...
<OriansJ>heck if the people who hated systemd put half as much work into any alternate init as they did in hating systemd; it would have been outclassed and replaced years ago.
<PotentialUser-96>Would be nice to have something similar to debian installer preseed
<OriansJ>PotentialUser-96: guix install scripts are a thing
<nckx>OriansJ: Sure. 's my opinion as well.
<nckx>So systemd is utter crap, but you just can't find the time to write something better? Cool. Go away.
<nckx>And take your s6/daemontools/openrc/... pamphlets with, please.
<PotentialUser-96>that doesn't partition the disk but yeah, I could curl a script of mine which does the job
<lle-bout>Their arguments often isnt that there's nothing better but that the better already exists, e.g. Alpine or Gentoo's OpenRC machinery - and that systemd is to ubiquitous in popular distros that things tend to assume systemd's the only thing that exists
<nckx>jonsger: Thanks for the explanation BTW ☺
<nckx>lle-bout: What does Alpine use?
<lle-bout>nckx: OpenRC
<OriansJ>Guix uses Shepard
<nckx>Wait. Is ‘shepherd’ a pun on *d names? I never considered that and now I can't unread it.
<nckx>Damn you, GNU and your mind games.
<civodul>nckx: of course it had to end in "d" :-)
<PotentialUser-96>nckx: It's alive !
<PotentialUser-96>Now I will read the manual, need to know how to send a patch to improve the doc
<kisaja[m]>is this plain-file syntax proper ?
<nckx>kisaja[m]: Looks like it. Why?
<kisaja[m]>i didnt see that kind of beautiful multi line config inside a config
<kisaja[m]>in other examples
<kisaja[m]>plus nano doesnt color it the way i would think its proper
<apfel>hi, is there a way to create the build environment of an already installed package? I checked the manpages, but there is no option like 'guix environment --build-environment linux-libre'. My goal is to then manually build it and play with different options, check generated files and so on.
<lle-bout>apfel: guix environment linux-libre ?
<lle-bout>then if you want the source: guix build -S linux-libre
<lle-bout>You can also insert a failing instruction at the point you want to start hacking in the package's recipe and use: guix build --keep-failed linux-libre
<OriansJ>nckx: now if the guile community wanted to do the ultimate troll; they could use systemd's modularity against itself by making it first scriptable in guile and then starting to replace the modules in scheme and then boom: SystemD is now Gnu Shepard and everyone is wildly confused.
<lle-bout>apfel: and then you can source the environment-variables file in the kept failed build dir: env -i bash - and then: source environment-variables
<apfel>lle-bout: yes, ok, to let the package build fail is one way of doing it, but this involves some work, i thought that maybe there is a simple generic option i am not aware of. Your first idea does not work though, because the sources i get from this command are unpatched, right? I would then need to apply the package ontop of the sources, at least some of the build steps.
<apfel>i mean, patching the shells scripts and so on
<PotentialUser-96>I'm looking at the source code and f2fs seems to be the only one missing in the doc
*nckx is AFK.
<mbakke>did someone say trolling? not sure whether systemd will accept a Guile scripting facility, but let's see...
<mbakke>perhaps start by implementing a DNS resolver in Shepherd? :P
<lle-bout>apfel: yes you need to patch, I would really like a package transformation option to interrupt build before and after a phase with a certain name. cc: civodul :-)
<lfam>I just pushed a branch 'alsa-updates' that does what it says. Notably it fixes the ALSA / Pulseaudio plugin system on foreign distros
<lfam>It would be nice to build it out and merge it son
<lfam>I'm not sure the status of the build farm, and if that's feasible
<mbakke>lfam: oh nice, I was just about to update ALSA myself for a new 'staging' round
<lfam>mbakke: We could make it the "staging" branch instead (I actually pushed staging:alsa-updates although I have nothing else for staging)
<mbakke>lfam: sounds good
<lfam>Do you think we can do it somewhat quickly? I'd hate for this bug to last for another 6 months
<lfam>It's a seriously usability regression on foreign distros
<mbakke>lfam: I hope this staging round will be quicker...
<lfam>Alright. I can help test / fix breakage this time
<mbakke>yay :-)
<mbakke>I already have a Qt update in the pipeline, those usually need some fixings...
<lfam>mbakke: I "renamed" the branch
<mbakke>great :)
<lfam>I still don't have a good sense of how to "do CI", so I can only help with x86_64
<lfam>I should read up on the GBC
<mbakke>civodul: did you do anything towards the "ungrafting" branch? otherwise I can start on that
<lfam>Anyways, anything besides Qt? I could make patches today and tomorrow
<lfam>Maybe we could start building on Friday?
<mbakke>lfam: sounds like a plan
<lfam>Okay, I'll send an email
<mbakke>lfam: I'm going to work on the "usual suspects" (Mesa and friends), but I don't expect any breakage apart from potentially Qt apps
<lfam>Email sent
<lfam>I saw the discussion about ungrafting more quickly. I think it's a worthy goal
<PotentialUser-96>What should I do to update the po files ?
<PotentialUser-96>there is a makefile but how should I use it?
<lfam>Can you clarify what you are trying to do, PotentialUser-96
<PotentialUser-96>Update the manual because guix system support F2FS
<PotentialUser-96>I've tried with label and uuid, both work
<lfam>For editing the manual, the main files are 'doc/guix.texi' and 'doc/contributing.texi'. Those are where you make your edits
<lfam>I don't know about the translations... somebody else should chime in with more info :)
<PotentialUser-96>Yes but the po files for traductions in po/doc/
<PotentialUser-96>ok thx
<lfam>The Translation Project will see your changes and submit revised translations
<lfam>You can do `make doc/guix.html` to build HTML files, or `make doc/` to build the Info manual
<PotentialUser-96>so I just send my (really) small patch to the mailling list, no need for me to update the other languages (I can for french)
<lfam>I'm not sure how translation process is supposed to work. I would mention that you can help with it in your email
<charles`>After I build guix, how can I get an iso to test?
<sneek>charles`, you have 1 message!
<sneek>charles`, raghavgururajan says: [1] ./pre-inst-env guix system vm my-config.scm [2] /gnu/store/… -m 1024 -smp 2 -net user,model=virtio-net-pci
<mbakke>lfam_: the ALSA_PLUGIN_DIR search path is "single entry", no?
<mbakke>in which case it should have (separator #f)
<PotentialUser-96>I've send a patch but I can't find it on
<ryanprior>How long ago did you send it? Is it the first patch you sent? It might be awaiting moderation.
<lfam>Does anybody know a way to list all packages that use the ruby-build-system?
<mdevos>lfam: git grep -F ruby-build-system maybe?
<lfam>Yeah, but it doesn't print package names. I'm sure there's a way to do it with Guix's Scheme interface
<mdevos>I suggest you look for something to iterate over all packages, and then filter based upon package-build-system?
<lfam>Right. I'm sure that somebody already has a snippet that does this :)
<lfam>I'll try to make it work with fold-packages
<mbakke>lfam: (fold-packages (lambda (package result) (if (eq? (package-build-system package) ruby-build-system) (cons (package-name package) result) result)) '())
<mbakke>lfam: did you see my message about ALSA_PLUGIN_DIR?
<lfam>Ah, I missed it mbakke. Good catch. I had simply adapted it from my work to implement GUIX_ALSA_PLUGIN_DIRS
<lfam>Looks like Savannah's Git server is offline
<lfam>Did you add any commits to the staging branch yet? Maybe I can rewrite history
<mbakke>when (separator #f), Guix will automatically create a single symlink union instead of a "proper" search path
<mbakke>lfam: no commits yet, rewriting is fine by me
<lfam>Fixed, mbakke
<mbakke>thanks lfam :-)
<lfam>mbakke: Which modules do you import to make that snippet work? I imported (gnu packages) and (guix packages) the ruby-build-system is still unbound
<mbakke>lfam: (guix build-system ruby)
<lfam>Thanks :)
<civodul>mbakke: re ungrafting, no sorry, i didn't do anything!
<civodul>i'm happy for you to start or i can start maybe tomorrow
<civodul>we'll manage :-)
*mbakke reverts 8bc5ca5160db3d82bd5b6b2b7ed80c96f42bd33e
<kisaja[m]>can i install packages to user from /etc/config.scm
<lfam>I was looking at the existing grafts and seeing which were appropriate to ungraft on the staging branch. It's weird that `guix refresh -l` doesn't properly report for gnutls and nghttp2
<lfam>They trigger a huge number of rebuilds via curl, but maybe it doesn't work correctly because curl is also grafted? Or maybe because the curl replacement is not public?
<lfam>kisaja[m]: I don't believe so
<lfam>mbakke: I think that json-c is okay for the staging branch. Did you have others in mind? Or are they all okay because they are "safe"
<mbakke>lfam: 'guix refresh -l' fails for GnuTLS because there is a newer public variant, so you need to use '-e (@ (gnu packages tls) gnutls)'
<lfam>Urgh, I tried doing that for gnutls/fixed
<lfam>I'm very rusty
<mbakke>lfam: we want to remove "all" the grafts, i.e. libx11, fontconfig, etc. It will be a huge rebuild, but since there are no other updates, it could go quickly.
<lfam>Yes. And we know they should not cause any new problems
<mbakke>I'm wondering whether to go as far as OpenSSL though.
<mbakke>lfam: indeed
<mbakke>by the way, there is a new OpenSSL security release announced tomorrow with "high" severity
<lfam>I think that there shouldn't be a big difference between ungrafting everything vs a subset. The total coverage is likely the same
<mbakke>it's probably serious because it was announced a week in advance :)
<lfam>Good to know
<lfam>Where is the pre-release advisory mbakke?
<lfam>I didn't see it on their site
<mbakke>oh it's not tomorrow, but tuesday
<lfam>Okay, but it's before Friday
<mbakke>lfam: I think we'll do the "remove grafts" rebuild in parallel with staging
<mbakke>so probably start it on tuesday then
<mbakke>and merge it to staging before friday :)
<emys[m]>can I somehow prevent from being redownloaded again and again after being deleted after `guix gc`
<emys[m]>as in can I pin it or something?
<lfam>emys[m]: Yes, make a symlink from that store item to /var/guix/gcroots
<lfam>E.g. `ln -s /gnu/store//lrj10gwk8i3ly69wrm6x3pxp9d7w9cmc-texlive-texmf-20190410 /var/guix/gcroots/texlive-texmf-20190410`
<lfam>mbakke: Do you mean you'll ungraft on a separate branch? I think it's okay to share the staging branch
<mbakke>lfam: I think a separate branch is better because staging might suddenly get "stuck" on something, but we know that ungrafting is safe
<civodul>emys[m], lfam: a conventional way would be to do "guix build -r ~/my-gc-roots/texlive texlive"
<lfam>Okay mbakke
<lfam>Aha civodul!
<mbakke>might need to do that both with and without '--no-grafts' though :-)
<lfam>Is this package exposed to the UI, though?
<lfam>I guess this is not the same as the texmf tarball I have made a gcroot for a couple years
<civodul>texlive-texmf is a dependency of "texlive" IIRC
<civodul>i wish all this were gone
<mbakke>we'll get there...
<lfam>I suppose I can remove my gcroot for 'texlive-20170524-texmf.tar.xz'. It appears to be obsolete!
<lfam>'20170524' no longer appears in our source code
<lfam>That's great
<civodul>you just saved 4 GiB!
<lfam>I was just thinking I could use another 4GB for testing the staging branch
<lfam>Or 2 GB... whatever :)
<lfam>mbakke: Can we set up a Cuirass job 'guix-modular-staging'?
<civodul>lfam: it's mostly unnecessary in practice because 'guix-master' builds Guix as well (for x86_64 only tho)
<lfam>Yeah, my `guix pull --branch=staging` finished more quickly than I expected
<mbakke>speaking of which, seems like Cuirass has given up on 'guix-modular-master':
<civodul>cbaines: i've sent a v2 of that fixes problems you encountered
<cbaines>civodul, cool, i'll try it out tomorrow :)
<civodul>mbakke: uh, that's interesting
<civodul>cbaines: coolio, thanks!
<jeko>Dear Guixters… I have trouble to `guix deploy` since yesterday. I don't know why… All my attempts abort with "guix deploy: error: SSH connection to 'localhost' failed: Connexion refusée"
<jeko>(localhost or any domain I can use)
<jeko>I can SSH to machines or VMs without error
***chrislck_ is now known as chrislck
<civodul>jeko: "Connection refused" means that there's no SSH daemon listening on that port of that host
<civodul>perhaps the port number or host name is incorrect?
*civodul -> zZz