IRC channel logs


back to list of logs

<roelj>Can I increase the default qemu memory size? (it defaults to -m 256..)
<OriansJ>roelj: Yes. there are many ways to do that. such as simply adding a bash alias to pass qemu the option of -m xxxxM
<roelj>OriansJ: Well, Guix sets it explicitly.
<roelj>OriansJ: I edited the source code, but I would like to have a command-line switch.. I guess I could try to add it myself
<OriansJ>roelj: It does have a command line switch and if a virtual machine is set up with libvirt, it can be configured through the virt-manager GUI.
<roelj>OriansJ: Oh really.
<roelj>OriansJ: What is the command-line switch?
<OriansJ>roelj: -m ###M sets qemu to use ###MB of ram instead of the default. It however does not change the qemu defaults.
<roelj>OriansJ: Oh. I guess I haven't expressed myself too clearly. I meant an option in Guix, so that 'guix system vm ...' can be told to create a VM with more than 256M of memory available.
<roelj>OriansJ: Sorry for the mix-up.
<OriansJ>roelj: No worries, sometimes we all use the wrong words.
<roelj>OriansJ: Thanks for your help!
<OriansJ>roelj: I thought the arguments given to the guix system vm script are passed to QEMU
<OriansJ>Since that is what the manual says:
<roelj>OriansJ: Yes, that is true. Now, I liked it when it would be possible to set a size that will then be adopted in the script automatically
***Emacsite is now known as calher
***calher is now known as Emacsite
<koosha>phant0mas: Hello
<koosha>I ran "bootstrap" and "config" without error finally but I got some through "make" . The vm's speed is very low and if I start the make process again it will take hours to finish .
<civodul>Hello Guix!
<koosha>I've got this from running make on Debian/hurd :
<koosha>"make[2]: *** No rule to make target 'gnu/packages/bootstrap/i586-gnu/bash' , needed by 'all-am'. Stop."
<civodul>koosha: 'master' lacks some of the bits to support GNU/Hurd
<civodul>you should use the 'wip-hurd' branch instead
<civodul>phant0mas: ↑
<rekado>hey Guix!
<civodul>hey hey, rekado!
<rekado>what do you think about making new releases whenever core-updates is merged?
<koosha>Oh , I have errors in bootstrap ...
<koosha>" warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its use is discouraged. "
<koosha>" You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead,"
<civodul>it's a warning :-)
<koosha>So , now problem ?
<civodul>maybe you're using Autoconf 2.69ish from Debian?
<civodul>no problem, yes
<civodul>er, 2.70ish
<civodul>i heard some distros ship an unreleased version of Autoconf
<koosha>I have autoconf 2.69-8 on Debian/hurd
<civodul>yeah we don't get this warning with the vanilla 2.69
<civodul>but anyway, don't worry about it :-)
<koosha>Okay , thank you :)
<koosha>And what's your comment about the errors that I've got from 'make' ?
<koosha>Oh , yeah you said .
<koosha>civodul: I'm using this repository,134901.15.html
<koosha>oops , sorry
<koosha>this one :
<civodul>yeah, maybe phant0mas can provide additional feedback later
<koosha>Okay , so I should wait , thank you anyway .
<koosha>phant0mas: Do you have time to help me ?
<Digit>mmm. guix on hurd. that's some enticing words there. ... i kinda wanna drop everything n go try that out. ... but barely got started with the last thing to have that effect on me. one geeking at a time. ... soon tho. hopefully.
<civodul>rekado: sorry i hadn't seen your question, but yeah, i think we should make a release once core-updates is merged
<phant0mas>hello there, is koosha here?
<phant0mas>koosha: when you are online ping me, so I can guide you step by step
<phant0mas>and in case you cannot find me here feel free to mail me at
<phant0mas>btw koosha always use qemu with kvm
<phant0mas>otherwise it will be really slow
<koosha>phant0mas: Hi :)
<koosha>okay :)
<phant0mas>koosha: now where did you stop? :-)
<koosha>well it seems my hardware doesn't support hardware virtualization .
<koosha>phant0mas: I got some errors in running make
<koosha>like this one : "make[2]: *** No rule to make target 'gnu/packages/bootstrap/i586-gnu/bash' , needed by 'all-am'. Stop."
<phant0mas>koosha: you need the bootstrap binaries placed in gnu/packages/bootstrap/i586-gnu
<phant0mas>let me upload them somewhere for you
<phant0mas>koosha: go to
<phant0mas>and download the bootstrap-binaries dir
<phant0mas>rename it to i586-gnu
<phant0mas>and place it in gnu/packages/bootstrap/
<phant0mas>then rerun make
<koosha>Okay , I'll report the result .
<phant0mas>koosha: thank you for trying :-)
<koosha>Thank you for helping :)
<koosha>some warnings ...
<koosha>"'dot' is missing on your system . "
<phant0mas>koosha: install graphviz
<koosha>phant0mas: Why is it downloading "guile.2.0.11" through running make ?
<phant0mas>koosha: are you sure it's downloading? I think it should just untar the one from the bootstrap binaries
<phant0mas>the bootstrap process in guix uses the bootstrap guile to download and prepare the rest of the bootstrap binaries so it can start bootstrapping the system
<phant0mas>or in other words create the bootstrap-toolchain
<phant0mas>(gnu packages bootstrap)
<koosha>phant0mas: yes it's downloading from ''
<phant0mas>aah it seems it download the bootstrap-binaries for other architectures
<phant0mas>well let it be
<phant0mas>if there is an error tell me
<rekado>having /gnu on NFS is unbearable
<rekado>I always think I've gotten used to it by now but then it just takes 10 minutes longer than usual
<jlicht>How can I easily get the sha256 of a git-based origin? Is this outside the scope of guix download?
<davexunit>jlicht: currently there's no automated tool
<davexunit>the hash of a git repo is simply the hash of the directory
<davexunit>sans the .git directory which is inherently nondeterministic
<jlicht>davexunit: that explains so much. I was thinking on how having a hash of a git repo would make sense XD
<jlicht>having thoughts about*
<davexunit>jlicht: if you looked at the source for git-fetch, you'll see that after cloning the repo, the .git directory is deleted.
<jlicht>I guess the source is usually the most up-to-date documentation ;-)
<davexunit>it would be nice for 'guix download' to handle git repos, svn repos, etc. but no one has made it do that yet
<civodul>rekado: i sympathize :-/
<civodul>rekado: did you try 'perf'?
<rekado>I'm thinking about hacking in a post-store-change hook.
<rekado>I'm thinking about moving the store to a local disk.
<rekado>whenever a store item is created I'd like to copy it over to a mirror on the slow fileserver
<civodul>would it work to server substitutes from the fast machine to the slow one?
<rekado>I previously tried to use inotify but it didn't work.
<rekado>substitutes aren't the biggest problem.
<rekado>what takes much too long is creating new profile generations
<rekado>especially when a profile contains many files.
<rekado>when I add a package (that's already in the store) to my profile it takes a very long time for the union build to succeed.
<rekado>just now a user added "r" and "r-genomation" to a profile already containing "python-matplotlib" and other Python things and it took about 8 minutes.
<rekado>no building or substituting involved
<rekado>I wonder if it would work if I mounted the store via Samba.
<rekado>not sure if it supports all the fs features the store needs.
<rekado>our weird ZFS appliance allows us to export the share via NFS or Samba.
<civodul>rekado: so users have direct access to the Guix commands?
<rekado>they do
<rekado>I made a wrapper that connects to the daemon remotely
<rekado>in this case I was looking over the user's shoulder and saw that it took about 8 minutes for the new profile generation to be created.
<civodul>ooh, ok
<rekado>I'll just try to switch to CIFS. I hear that read performance with CIFS might be about 10 times faster than with ZFS via NFS.
<civodul>since /gnu/store is append-only, perhaps caching can be made very aggressive
<civodul>but i guess you've already tried to tweak everything
<rekado>yeah, I made extensive tests with NFS caching and different mount options, but all I managed to do was shave off a couple of seconds.
<civodul>how do you connect client commands to the remote daemon?
<rekado>socat runs on the management node and accepts connections to the daemon.
<rekado>the wrapper starts socat where the user currently is, connects to the remote socat instance, and sets GUIX_DAEMON_SOCKET.
<rekado>it's not much more than that.
<rekado>I'm experiencing the same performance problems without all that, though.
<rekado>when I'm on the management node and run guix locally it's just as slow.
<rekado>everything points at the union build to take the most time.
<rekado>On Thursday I'm going to give a Guix workshop and I'm considering to set up a local toy Guix installation instead of using this very slow central installation.
<civodul>yeah, i was just wondering how you had achieved that part
<civodul>probably a good idea :-)
<koosha>phant0mas: It finished and I think had no error .
<civodul>rekado: i wonder if your particular NFS setup is particularly slow, or if NFS is bound to be that slow no matter what
<rekado>I'll eventually prepare a patch for the manual, showing the wrapper and everything.
<rekado>I don't know.
<phant0mas>koosha: nice
<phant0mas>now run make install
<civodul>rekado: on the client-side we could implement something that connects directly over TCP
<civodul>would be easier than having to write a wrapper etc.
<rekado>ZFS is a little slow already, NFS is slow too, and it could be that the NFS settings on the appliance are very conservative, too.
<phant0mas>koosha: and follow the instructions here
<phant0mas>so you can setup the daemon
<rekado>civodul: sounds like a good idea.
<civodul>rekado: anyway it's great that you're giving a Guix workshop at work!
<civodul>i'm far from doing that here :-/
<civodul>largely my fault i guess, but such is life
<rekado>I already have a couple of converts :)
<jlicht>is anyone doing anything with node on guix right now? I seem to have problems trying to run `npm` with the latest packaged version (6.0.0)
<jlicht>and rolling back to 5.10.0 does not have this problem
<koosha>phant0mas: guix installed successfully . I'm going to setup the daemon .
<civodul>rekado: heh good :-)
<civodul>jlicht: davexunit may be the right person :-)
<davexunit>jlicht: would be good to know what the exact issues are. I haven't used npm much since doing that upgrade
<rekado>another possible problem with the shared storage might be gzip compression. (Compression ratio is 2, but I don't think it's worth it if this turns out to be the reason why reads are so slow.)
<thomassgn>Curios,I've recently started using nixos, purely on a gut feeling it would be more... mature. But I'm kind of looking for guix to be "safe" enough to make the change for it. Anyone with experience running guix that can speak to its stability as a day to day OS?
<rekado>thomassgn: I'm running GuixSD on multiple machines.
<rekado>the primary issue with GuixSD is that it doesn't have as many packages as other popular GNU distributions.
<rekado>stability is definitely not an issue for me.
<rekado>if anything it's more stable as I cannot really break things anymore.
<rekado>(my workstation in the office is running Fedora and I break things often enough to find it annoying)
<thomassgn>nice, yes, that was my thought too. This way of managing a system is so much better/easier
<rekado>there are a couple of rough edges still.
<rekado>e.g. IBus doesn't really work well (at all?).
<thomassgn>are any of your machines laptops?
<rekado>two of them.
<rekado>one is a Thinkpad X200s, the other a T60.
<thomassgn>mm, kool
<rekado>obviously, the Thinkpads with Lenovo BIOS don't have WiFi.
<thomassgn>let's write a change for guix when I next have time for it then :)
<rekado>I'm going to try to replace the BIOS on the X200s with Libreboot soon, so that I can use an Atheros WLAN card.
<thomassgn>Do you know, is there tools for managing remote machines? (like nixoPs if you're familiar with it)
<davexunit>thomassgn: not yet.
<thomassgn>aww, well well
<davexunit>it's the thing I most want to write next.
<davexunit>nixops is sort of terrible
<davexunit>so I intend to do better for guix
<davexunit>I brainstorm from time to time and have done a few experiements with local virtual machines
<phant0mas>koosha: when you have everything ready, go back to the ftp server and get
<phant0mas>and run guix archive --authorize <
<thomassgn>hahaha,that qwould be awesome. It might be terrible, but so far it beats my old method of manual ssh management :P
<phant0mas>so you can fetch substitutes from my hurd machine
<civodul>phant0mas: oh you're serving substitutes, cool!
<davexunit>thomassgn: I read the nixops code from time to time. there's not tooo much to it.
<davexunit>a good portion of it is making sense of the nix->xml transformation that they have to do
<phant0mas>civodul: :-)
<davexunit>I intend to avoid the whole "state file" thing that nixops has.
<civodul>davexunit: it'd be nice to get funding or something for these things to happen
<thomassgn>huh, they send XML between the machines or something then? I've never looked at how or what it does, just tried it and it worked more or less as expected
<davexunit>thomassgn: they translate the nix expressions into an AST in XML form
<koosha>phant0mas: Okay , but about daemon setup , for build enviroment setup , guix-deamon is needed , is it installed ?
<davexunit>this is just a local thing. they do that to figure out what is being deployed and such
<phant0mas>koosha: did you run make install?
<davexunit>system configuration, etc.
<phant0mas>if yes, yes
<davexunit>civodul: yeah. I have been too short on time to make a serious dent in this.
<davexunit>and I'm in the midst of a big move and house purchase so I'm not exactly going to have more free time anytime soon
<phant0mas>koosha: is should be at /usr/local/bin/guix-daemon
<davexunit>so for now I just think and think and think about what I'd like to do
<thomassgn>ah, I see. Thanks a lot for the input all of you
<phant0mas>koosha: did you follow the instructions at ?
<davexunit>thomassgn: you're welcome. it's a feature we're definitely going to have at some point. so if it's a dealbreaker for you now, check back every once and awhile.
<rekado>here's an idea for speeding up
<rekado>...the case where one package is added to an existing profile.
<rekado>instead of going through the list of *all* files whose union path would collide we could just compare the paths of the latest generation with the colliding paths of the new package.
<rekado>IIRC new generations are created from scratch, ignoring the work we've done for previous profile generations.
<davexunit>I'm not sure if that optimization could be done such that the resulting profile would be exactly the same as if it were created from scratch
<rekado>hmm, I guess it would become order-dependent in case of conflicts.
<rekado>right now we always pick the first of conflicting files.
<davexunit>maybe there are other optimizations that could help here
<koosha>phant0mas: Yes it is installed and I'm following it .
<rekado>I guess it would still work if we made the order explicit (if it isn't already so).
<rekado>I wonder: doesn't deduplication in the store already figure out conflicts for us?
<rekado>if we could mark files as duplicates at the time they are added to the store we wouldn't have to figure this out each time on profile creation.
<davexunit>is that really the slow part?
<rekado>last time I checked I saw that we are actually reading files to see if they are identical.
<davexunit>or is unioning in general just slow?
<rekado>IIRC mark_weaver optimised unioning.
<civodul>rekado: as davexunit suggests, it wouldn't work well
<rekado>there isn't anything obviously bad about the way it's implemented
<civodul>it's undesirable, even
<koosha>phant0mas: It doesn't finish . 'guix-daemon --build-users-group=guixbuild' . I just copied the text in the manual into a file with the name guixbuild and the the command .
<rekado>the files in /gnu/store/.links are named after the hashes of the store paths of individual files, no?
<civodul>rekado: yes
<civodul>you could use that to do nasty optimizations, maybe ;-)
<civodul>ACTION makes 'guix lint -c cve' Fast Again
<rekado>I'm wondering if we could replace "file=?" in guix/build/union.scm by making a lookup in /gnu/store/.links
<davexunit>Make GNU Great Again
<civodul>rekado: no, because (1) we cannot access it from the build env, (2) it would be state-dependent, and (3) deduplication is optional
<rekado>I don't understand (2).
<civodul>it would be stateful, that is, a function of the current store's state
<rekado>it would just be a shortcut.
<civodul>that's how it start, and then we end up with dpkg all over again!
<davexunit>imperative shortcuts, like a pile of fresh baked cookies on the counter, you just can't resist.
<rekado>well, this collection of links just tells us that two files are in fact the same.
<rekado>without having to read them again.
<rekado>I see this as a cache of previous work
<civodul>ACTION has an idea
<civodul>rekado: in file=?, i'm pretty sure that if we check for (= (stat:ino st1) (stat:ino st2)), it'll be magically faster
<civodul>because deduplicated things have the same inode number
<civodul>so if you're using deduplication, this test is necessarily true for identical files
<rekado>will a change to this file cause rebuilding the world? I'm curious and would like to try this.
<civodul>no, no rebuild
<civodul>i'm committing it anyway, because it cannot harm
<davexunit>ooh that's a neat hack
<civodul>it's just like (define (equal? a b) (or (eq? a b) ...))
<davexunit>that's cool :)
<rekado>will stat:ino trigger another stat call? Or is this cached by Guile?
<rekado>we do (stat file1) in the let
<davexunit>it just accesses information of the result of stat
<davexunit>so no additioanl stat call, it's just a selector
<rekado>oh, yes, I see
<civodul>but actually that only helps for the case where files are identical
<civodul>which is often not the case
<civodul>so maybe you won't see a difference :-/
<davexunit>can inode numbers clash across different file systems?
<civodul>yes, but by definition, there's only one file system involved here
<davexunit>got it
<rekado>I'll time this tomorrow
<davexunit>profile creation slowness bit me when I accidentally installed texlive-texmf into my profile
<davexunit>because it contains so many files
<davexunit>and then I tried demoing 'guix package -i' at a talk...
<civodul>rule #1: only show things that work well ;-)
<davexunit>'guix package -i' works wondefully, if I didn't forget about that earlier goof
<davexunit>I wasn't expecting an issue, so rather than rolling back a generation I just moved on
<davexunit>rekado: ooh, recursive cran importer!
<davexunit>I should do the same for ruby. that would greatly simplify guixifying existing projects.
<koosha>phant0mas: Well the mistake was from my side .
<koosha>phant0mas: It's not going to end : "guix-daemon --build-users-group=guixbuild"
<phant0mas>koosha: I am back
<koosha>phant0mas: perfect :)
<phant0mas>are the guix-build users ready?
<koosha>I think so
<phant0mas>are you root?
<davexunit>koosha: it's a daemon process, so it's going to keep running. that's its job.
<phant0mas>exactly what davexunit said
<koosha>no , the command doesn't stop .
<davexunit>that is exactly what is supposed to happen
<phant0mas>it shouldn't stop
<davexunit>you started a server
<davexunit>it's going to run and serve clients
<koosha>davexunit: I didn't read your message , sorry :)
<koosha>But I can't work with shell . So I should run it in background ?
<phant0mas>koosha: I suggest you install screen
<koosha>Okay , I got it .
<davexunit>koosha: are you new to the command line?
<davexunit>if so, guix might be tough for you.
<lfam>I think it's a great opportunity to learn more :)
<koosha>davexunit: I'm not master but not noob too :)
<davexunit>good luck then
<koosha>davexunit: Thank you :)
<koosha>phant0mas: So now I should go to ftp , right ?
<phant0mas>yes get the
<phant0mas>and run guix archive --authorize <
<davexunit>koosha: if you use a distro that uses systemd, then you can install a service file for the guix daemon and manage it that way
<davexunit>which is nicer than leaving a terminal open with guix-daemon running in it
<phant0mas>davexunit: he is using guix on hurd ;-)
<koosha>davexunit: Intresting , thank you for advice :)
<koosha>But Debian has systemd
<phant0mas>hurd does not support systemd
<koosha>Oh , Sorry ...
<koosha>So noop :)
<lfam>Just FYI, our Git repo includes a systemd service file at etc/guix-daemon.service
<phant0mas>no worries, relax
<phant0mas>koosha: run screen guix-daemon --build-users-group=guixbuild -c 1 --substitute-urls=
<phant0mas>after authorizing the key
<phant0mas>so you can use my substitutes server
<phant0mas>and build locally as little as possible
<lfam>phant0mas: Are you running a mirror or are you running a Hydra server?
<davexunit>or 'guix publish'?
<lfam>Just curious :)
<phant0mas>lfam: davexunit I am using guix publish on debian/hurd :-)
<lfam>Wow, very cool!!
<phant0mas>and btw that debian/hurd machine is not a vm
<phant0mas>it's baremetal
<lfam>What hardware are you using?
<phant0mas>it's and old pentium4 processor with 1gb ram
<phant0mas>hurd works perfectly with it
<lfam>I have a processor from that era, although the machine has less than 1gb RAM. Maybe if I get more free time...
<phant0mas>that would be cool
<phant0mas>you could even get guix running on it with the help of my substitutes
<phant0mas>on hurd
<koosha>phant0mas: I use to run it like this "command &" , isn't good ?
<phant0mas>if you exit the shell the command will stop
<phant0mas>koosha: run screen `command` and then press ctrl a +d
<koosha>phant0mas: It doesn't exit
<phant0mas>you press ctrl a
<phant0mas>and then d
<koosha>done :)
<koosha>I come back soon ...
<koosha>phant0mas: So what is the next step ? maybe get familier with hurd and guix with manuals and reporting bugs ?
<koosha>Because I dont know enough about guix and hurd .
<phant0mas>koosha: well if you want to get familiar guix, I suggest using it first on linux
<koosha>phant0mas: Yes , I have guixsd installed .
<phant0mas>well you could try building packages you use on linux, on the hurd
<phant0mas>and report any problems
<koosha>Awesome m I do it :)
<koosha>Thank you for all of your helps
<koosha>And other dear friends
<jmd>Where's the function which generates the html list of packages?
<jin_>phant0mas, koosha i followed your steps provided!
<davexunit>jmd: it's in the guix-artwork repo that has all of the website code
<jmd>ahh. So not in the main source.
<davexunit>this code generates SXML
<davexunit>which is then converted to the HTML text for the final product
<phant0mas>koosha: :-)
<phant0mas>jin_: did you get guix running on hurd?
<phant0mas>try and build packages and report problems
<random-nick>will guix get a better package list page?
<davexunit>I don't know, will it?
<random-nick>if all packages are listed it takes a long time to load :/
<lfam>Yeah, it's really heavy. Sounds like a good project for somebody to take on :)
<davexunit>there's only so much you can do when the page is static
<davexunit>I think just generating pages would be enough for now
<davexunit>you wouldn't be able to search of course, but for that we would need a dynamic web application anyway.
<random-nick>well isn't the point of the package list to search?
<lfam>For me, the most important use case is being able to give somebody a hyperlink to the package information.
<lfam>I guess search is useful before you've got a working Guix installation
<davexunit>random-nick: search just isn't going to happen without a dynamic web application backing it
<random-nick>well, the current package list is easy to search :-)
<random-nick>but it might start freezing/crashing browsers when it grows in the future
<roelj>I believe some of the sluggishness comes from invalid HTML.
<roelj>Which I have on my long to-do list.. So I would be very happy if someone beats me to it.
<davexunit>that page should be 100% valid
<davexunit>we use SXML after all
<davexunit>it's not like we are missing closing tags or whatever
<koosha>Debian's hurd version is very old , It's 0.6 . Isn't it ?
<davexunit>that's SaaS
<roelj>Sorry.. The HTML that comes out of the lisp code is simply not valid..
<davexunit>they should be easy to fix
<davexunit>it's valid XML
<davexunit>but a couple minor things that make it not valid HTML
<davexunit>I have my own sxml->html procedure that should take care of these things
<davexunit>the non-void element thing for sure
<davexunit>so it's just some weird idiosyncracies with HTML having totally crazy rules
<roelj>I don't find an <a> tag without any text to click on being invalid a crazy rule.
<davexunit>it's valid xml
<roelj>In the context of a markup language, I find that pretty sane.
<davexunit>anyway, it's an easy fix.
<roelj>Cool :)
<davexunit>we can fix it easily because we use SXML
<roelj>Not sure how much it will speed up after it's valid HTML as well, because it's still a lot of data.
<roelj>At least it should help a bit
<phant0mas>koosha: you can run apt-get update && apt-get upgrade
<phant0mas>to update debian/hurd
<koosha>Does it update the hurd even ?
<koosha>What version do you need to I have ?
<phant0mas>it updates eveything
<phant0mas>the latest
<kraji>hello all! i used guix build to build a costumized package. how do I replace the package in base with the one I builted? I'm getting "collision messages" all the time
<bavier>I have a project that was released under gpl2+; later they decided to re-release under LGPL, but didn't change any of the source headers, which still read gpl2+. So, would I just need to list both licenses?
<lfam>kraji: If you mean what I think you mean by "collision messages", those collisions are in your profile (user's installed packages). So, uninstall the old package and keep the new one.
<lfam>Does that make sense?
<kraji>it makes sense
<kraji>I did that
<lfam>bavier: I'm not an expert, but I'd guess that unless LGPL and GPL2+ are compatible, then the state of the licensing is too ambiguous.
<kraji>the think is that it is a system package and I don't see the other one listed
<lfam>kraji: A system package on GuixSD?
<lfam>kraji: If so, how did you make the customized package. In the Guix source tree (using ./pre-inst-env) or in a separate tree (using GUIX_PACKAGE_PATH)?
<kraji>i just downloaded the tar file
<kraji>and used
<kraji>the guix build with source
<lfam>Ah, I don't know whether or not you can use --with-source with `guix system reconfigure`. You could try it.
<bavier>lfam: according it should be fine
<bavier>but yes, I might contact the author to point out the situation
<lfam>kraji: The way I handle custom packages on GuixSD is to put them in a separate tree (where they inherit from the Guix-provided package), and then reconfigure with GUIX_PACKAGE_PATH pointing to my tree.
<kraji>ok. thanks
<kraji>i will try
<lfam>kraji: If you've never made your own package tree, there are some examples listed here:
<roelj>Could any tell me how the GuixSD USB image is booted? How does the BIOS find the kernel image to start?
<paroneayea>I have reliable intarwebs again
<lfam>Welcome back :)
<paroneayea>thanks lfam :)
<CompanionCube>roelj, i'd guess that GRUB or something is in the MBR
<roelj>CompanionCube: Oh right.
<roelj>That's probably it..
<roelj>I suppose when doing 'guix system disk-image gnu/system/install.scm', at some point it must partition the disk image, right? Where is that code?
<roelj>Found it in gnu/build/vm.scm
<GNUtoo-irssi>hi, on x86_64 under parabola I did: guix pull; guix system vm ./my_config.scm
<GNUtoo-irssi>it failed when building qemu, is it known?
<GNUtoo-irssi>Note that I'm still struggling to get it use binaries packages.
<GNUtoo-irssi>should I reinstall guix or something like that to have a fresh start?
<GNUtoo-irssi>I can now have hello, if I build it
<GNUtoo-irssi>but not yet system images
<civodul>GNUtoo-irssi: you can check whether QEMU is known to build on
<civodul>and currently it's all green, except on ARM
<GNUtoo-irssi>I'll paste the error then
<roelj>civodul: I had to disable the tests for QEMU on a local build myself two days ago.
<civodul>oh, it could be that there are non-deterministic errors or something
<civodul>this is the error on ARM:
<GNUtoo-irssi>the error I have remotely looks like the ARM one
<GNUtoo-irssi>I'm rebuilding it to have the error again
<GNUtoo-irssi>The failure is not the same
<GNUtoo-irssi>I'll try again after moving TMPDIR to the disk instead of tmpfs
<GNUtoo-irssi>It failed again the same way, so it's consistent.
<GNUtoo-irssi>should I wait for it to be fixed?
<kraji>my store occupies 20gb. is this normal?
<bavier>I like the idea of this tool:
<bavier>it seems to me the implementation is a bit convoluted though
<bavier>and too bad it requires go
<davexunit>go is sooo terrible
<civodul>bavier: interesting tool
<davexunit>"Of course I'm looking at this from the perspective of deploying micro-services and immutable infrastructure." holy buzzwords batman
<suitsmeveryfine>Hi! I'd like to add a service for Guix SD but could need some help.
<bavier>civodul: LANL has quite a few interesting tools
<davexunit>I got a little fresh in a thread about GitLab creating a Docker image registry
<davexunit>which is where the above quote came from
<suitsmeveryfine>It's for "thinkfan" and I'd like this to happen:
<suitsmeveryfine># modprobe -r thinkpad_acpi
<suitsmeveryfine># modprobe thinkpad_acpi fan_control=1 ; because by default, it loads with ...=0
<suitsmeveryfine># thinkfan /path/to/config-file
<wingo>nuclear weapons and multi-processing in bash
<wingo>it's making multi-processing in bash look good ;)
<suitsmeveryfine>I understand, of course, that it's better to load `thinkpad_acpi fan_control=1` immediately.
<bavier>wingo: :)
<suitsmeveryfine>How can I check what's included in "%desktop-services"?
<davexunit>suitsmeveryfine: read the source or use the REPL
<suitsmeveryfine>davexunit: yes, I guess it should be easy to do from within Emacs
<suitsmeveryfine>Can I just open my system configuration in Emacs and find it from there?
<davexunit>suitsmeveryfine: to do that you need a REPL open so that you can evaluate that code
<davexunit>suitsmeveryfine: how about just using 'grep'?
<davexunit>the old fashioned way of finding where something is defined
<suitsmeveryfine>ah, smart!
<civodul>bavier: MPI-Bash looks fun :-)
<suitsmeveryfine>If I've grep'ed correctly thinkpad_acpi doesn't exist in any of the defined guix services but it's still loaded at boot. Why is this so?
<kristofer>suitsmeveryfine, it's a kernel moule
<suitsmeveryfine>kristofer: yes, but how does one control how they are loaded?
<kristofer>use grub :)
<kristofer>I'm really not positive how to do that with your system configuration
<suitsmeveryfine>yeah I haven't done it myself
<suitsmeveryfine>I'll look and see if there is any grub example in the manual
<suitsmeveryfine>there is the initial RAM disk of course
<suitsmeveryfine>Can I use that perhaps?
<kristofer>you'd use the linux line of the grub.cfg
<suitsmeveryfine>hmm, is it safe to modify GRUB this way? Will I still be able to load previous configurations?
<suitsmeveryfine>if I should make a bad modification I mean
<kristofer>it'd be something like added to the linux line
<suitsmeveryfine>added to linux-arguments that is
<suitsmeveryfine>there is actually a very good section on GRUB in the manual
<suitsmeveryfine>Hmm, it appears that I need to create custom GRUB menu entries and type in all the details manually if I want a different option like ""
<suitsmeveryfine>kristofer: do you think it will work to define the initial RAM disk instead?
<emyles>I deleted (with rm) some files from the store, not sure why, and broke my guix
<emyles>how can I fix it, or where can I start again from?
<emyles>sudo guix gc --verify gives ".drv still has valid referrers!",
<emyles>"disappeared, removing from database"
<emyles>and also, build failed: invalidating path `/gnu/store/longhash-uwsgi-2.0.12.drv'
<emyles>-uwsgi-2.0.12.drv' in database: FOREIGN KEY constraint failed
<kristofer>suitsmeveryfine, no I don't think so. You should pass the module arguments on the linux line of your grub.cfg
<suitsmeveryfine>OK, thanks. I'll try to figure out how I can do this. It seems that it would involve adding an addional GRUB menu entry