IRC channel logs


back to list of logs

<suitsmeveryfine>civodul: maybe you know this: if I want to create a custom GRUB menu entry, are then all the fields necessary to specify, e.g. "linux" and "initrd"? For my purposes I'd only like to make this modification: (linux-arguments (""))
<suitsmeveryfine>It's not clear from the manual I think
<suitsmeveryfine>*in the manual
<civodul>suitsmeveryfine: i think you want to use 'kernel-arguments' instead, no?
<civodul>ACTION -> zZz
<suitsmeveryfine>civodul: yes, of course! THANKS!
<emyles>How do I empty the store to start again?
<kraji>how to erase the different configs?
<emyles>I rm'ed some things and now it's broken so I think it might be easier to start again
<emyles>sudo guix gc --verify shows errors and I can't find how to fix them
<lfam>Should we disable parallel-tests on qemu again? roelj, GNUtoo-irssi and I have all been unable to build it, due to similar failures in the test suite. It worked for me when I disable parallel testing for version
<roelj>I'm building now with #:parallel-tests? #f instead of #:tests? #f to confirm this solves the build problem for me.
<lfam>roelj: Thanks. Whether or not we disable it in our package definition, we should ask QEMU if they mean to support parallel testing or not.
<roelj>lfam: Indeed.
<roelj>This is going to take a while..
***samis is now known as CompanionCube
<suitsmeveryfine>rekado: the kernel option worked. Thank you!
<roelj>lfam: It works. Make complains about missing 'flex' and 'bison' commands, but it doesn't seem to affect the buid.
<roelj>So I can confirm building Qemu works with '#:parallel-tests? #f'
***Ulrar_ is now known as Ulrar
***grinhaus is now known as wgreenhouse
***sourcef_ is now known as sourcef
<efraim>I built and pushed the update to qemu, but on my machine isn't always fast enough to make use of parallel tests
***Digitteknohippie is now known as Digit
<davexunit>when I built qemu I ran out of RAM when running the tests
<davexunit>or at least that's what it said.
<Emacsite>Running Guix daemon in a Screen session owned by root. lol
<Emacsite>Using Guix to get Artanis.
***tschwing_ is now known as tschwinge
<notadrop>I'm going to install GuixSD tomorrow. Right now I need to go to bed, but I thought I'd come in and say hi
<rekado_>hi notadrop!
<notadrop>My machine runs Libreboot when I press the power button :)
<notadrop>so I would love to try GuixSD. And hopefully one day it will be GNU Guix/Hurd
***boegel|quassel is now known as boegel
<civodul>Hello Guix!
<notadrop>hello civodul
<notadrop>I'm installing Guix as soon as dd is done imaging my flash drive. Woohoo.
<notadrop>Actually: I'll read the docs tonight.
<notadrop>Install tomorrow. That's a more reasonable plan.
<notadrop>Emacsite, hey!
<notadrop>"In Guix, the package build and installation process is seen as a function, in the mathematical sense."
<notadrop>It's like somebody read SICP... and then designed an entire system based on what they learned from that book.
<notadrop>(that's a good thing, in my books.)
<Emacsite>Hehe, yeah.
<efraim>SICP is packaged in guix :)
<notadrop>:o :D
<notadrop>good, because I had to return it to the library.
<Emacsite>You're lucky to have a library copy.
<notadrop>Well, the local public library doesn't. But the university does
<notadrop>well, here goes nothing
<Emacsite>Don't schools require the use of non-free applications/JavaScript?
<notadrop_mobile>still here on my phone.
<Emacsite>Don't schools require the use of non-free applications/JavaScript?
<notadrop>yeah, most do, sadly
<Emacsite>I don't enter those contracts anymore.
***remi1 is now known as remi
<notadrop>How will I boot the GuixSD install image from Libreboot...
<notadrop>it needs a GRUB payload to boot from. hold on.
<Emacsite>Non-GRUB Libreboot? Weird.
<notadrop>well it has grub but
<Emacsite>I don't remember if it could detect it by running "Scan for external CBFS" or if I had to ls and poke around for initrd and vmlinuz.
<notadrop>oh okay
<notadrop>could you help me out with this?
<notadrop>I'll be maybe 5 mins
<notadrop>time for a snack, and the washroom.
<notadrop>you know what.
<notadrop>I better do this tomorrow.
<notadrop>good night everybody
<Emacsite>Good night :(
<notadrop>I'll probably see you around again Emacsite ;)
<rekado_>I'm having a little problem with "guix gc" removing stale links.
<rekado_>when I do "guix gc -d /path/to/profile" I expected only that profile to be removed.
<rekado_>but Guix also cleaned up a couple of automatically created gc roots.
<rekado_>the problem with that is that I ran this on a machine which didn't have all file servers mounted
<rekado_>so Guix would erroneously remove what it considered stale gcroots
<rekado_>these are links to profile generations stored on file servers that I don't necessarily have access to.
<efraim>well that doesn't sound good
<rekado_>yeah :(
<rekado_>I'd like to move this to a separate command or hide it behind a flag
<kraji>hello :) i just noticed that my /gnu/store occupies 20gb. is this normal? i just installed gnome and xfce (then removed gnome). am I missing something?
<kraji>oh and texlive
<rekado_>kraji: the store will continuously grow until you run garbage collection with "guix gc"
<brainiarc7>kraji have you ever ran the garbage collector?
<rekado_>removing gnome only creates a new profile generation which no longer links to gnome; gnome and all its dependencies are still in the store, though.
<kraji>@rekado. yes I ran the garbage collector
<efraim>my /gnu partition is at 21GB atm
<rekado_>did you install gnome as a user or with the system reconfiguration?
<rekado_>the garbage collector only removes items that are no longer referenced
<rekado_>if you still have a profile generation referencing gnome stuff it won't be removed.
<kraji>I installed as system reconfiguration
<kraji>i suspect that the problem is that
<rekado_>there's no command to delete old system profiles
<rekado_>but you can delete the links to previous versions manually
<rekado_>and then rerun "guix gc"
<kraji>where should I look?
<alezost>kraji: system profiles are placed at /var/guix/profiles/
<kraji>oh yeah right :d
<kraji>ok. so this saves me around 1.7gb
<rekado_>manually recreated all those gcroot links.
<rekado_>not sure how to fix this.
<rekado_>what the daemon does is completely reasonable
<rekado_>but the assumption that the gcroots point to files that are accessible by root on the host where the daemon runs is invalid.
<kraji>So now I am at 16.3gb. I just have installed xfce and texlive
<rekado_>civodul: thanks a lot for the inode comparison
<rekado_>installing "r" and "r-genomation" (already in the store) into my profile took 2m10s before.
<rekado_>now it's down to 33s.
<rekado_>so much better
<notadrop>Emacsite, hey! you still around?
<rekado_>I think I may need to disable "guix gc" for regular users in this shared installation.
<Emacsite>notadrop: Yes.
<efraim>rekado_: is the store and the profiles stored on the ZFS appliance? can you just run `guix gc` from there when necessary?
<rekado_>store and profiles are on the ZFS appliance (to which we have no console access) but mounted on a management node, which runs the daemon.
<rekado_>the daemon runs as local root
<rekado_>the node does not mount all the user's data shares.
<rekado_>and even if it would it probably would not have read access to these files
<rekado_>so it wouldn't be able to determine whether the links are valid
<rekado_>(because root privileges are squashed)
<roelj>rekado_: I thought you had an NFS mountpoint for the store.
<rekado_>we do.
<roelj>Ah. But the filesystem is ZFS.
<rekado_>the ZFS appliance hosts the share and exposes it via NFS or Samba.
<civodul>rekado_: great, thanks for timing it!
<civodul>rekado_: re your GC issue, i think you really have to arrange for guix-daemon to see all the GC roots etc.
<cbaines>Where can I find out more information about what happens if two packages provide the same files, and they are installed in the same profile?
<rekado_>cbaines: this case is dealt with in guix/build/union.scm
<rekado_>currently Guix will just take the first of conflicting files.
<cbaines>Ok, thanks rekado_
<Steap>civodul: btw I finally saw your message about the pypi importer, gotta take care of this ASAP :)
<jmd>Is there a general way to find out what package provides a particular file?
<cbaines>Another quick question, why do package inputs have labels?
<jmd>cbaines: I think it is so that one can specify alternate versions if necessary.
<cbaines>jmd, ok, how would that work?
<jmd>I can't remember of the top of my head. Maybe ludo can answer.
<civodul>Steap: cool :-)
<civodul>cbaines: the labels allow you to refer to the inputs on the build side, using the '%build-inputs' variable
<civodul>or using #:inputs
<civodul>gexps provide a better solution but it's not used yet for packages
<jmd>cbaines: So the answer seems to be that unless you intend to use %build-inputs then you can label your inputs as ""
<jmd>What package provides the lxc userspace tools?
<civodul>ACTION pushes a security fix for libxml2
<rekado_>oops, I accidentally sent along a cover letter with my latest patch.
<rekado_>I was just going to look what I need to do in order to package tensorflow and then stumbled upon this:
<rekado_>"Correct, reproducible, fast builds for everyone"
<rekado_>"Builds only use input files that are explicitly declared in the build specification. On Linux, Bazel runs tools in a sandboxed environment that contain only the minimum necessary files required. Even tests are run in sandboxes, which ensures predictable, environment-independent results."
<davexunit>sounds familiar ;)
<civodul>yes it's pretty cool
<civodul>the Google folks were at the Athens r-b summit
<avoine>what would be the better way to recover from an "invalid arch independent ELF magic" grub error?
<avoine>if I do a guix system reconfigure from a usb key will that work?
<civodul>avoine: uh, never seen that, may be a corrupt file?
<avoine>I had problem with the graphic driver from linux-libre 4.5.5 so I tried to downgrade
<civodul>you could have rolled back, first
<civodul>if you were short on disk space, perhaps you hit
<civodul>hence the corrupt file
<avoine>yeah I did that but I had some error with guix saying that the manifest was incorrect (don't remember the exact error)
<avoine>I don't mind reinstalling I just don't know how
<civodul>you should never need to reinstall
<civodul>so you cannot boot at all?
<avoine>I tried to chroot from an ubuntu live cd but I could'nt do reconfigure from there
<avoine>civodul: no
<civodul>none of the generations?
<avoine>I'm getting a grub rescue prompt
<civodul>were you short on disk space?
<avoine>civodul: I don't think so
<civodul>maybe you can boot from the install image, mount the root fs, and run grub-install manually with your root's /boot/grub/menu.lst
<civodul>er, grub.cfg
<avoine>I'll try that
<civodul>that is, just restore GRUB without reinstalling anything
<avoine>civodul: if that's not working, can I do a "guix system reconfigure" from the live-cd and then replace the /gnu and /var/guix/ directories on my target system, will that work?
<davexunit>avoine: you would need to do 'guix system init'
<civodul>yes, but 'guix system init' will wipe out everything (it will reset the database associated with the store)
<avoine>that will wipe the partition too?
<avoine>i.e /home/ , etc
<avoine>(guix is my main system)
<davexunit>at least I don't think so
<avoine>I'll do that I resetting grub don't work
<davexunit>it would always be a good idea to make backups ;)
<avoine>and backup first :P
<avoine>I have backup it's sure the trouble to transfering them
<habs>Hi -- not sure if this is the right channel for this, but how can I change my Shepherd "networking" virtual service to prefer network-manager over wicd? My understanding from reading the docs is I should have to change /etc/shepherd.scm, but my system doesn't have that file. Any ideas? And where is the "doc/examples" directory they talk about?
<habs>To provide context I'm running GuixSD on a Thinkpad X200
<gour>hello, i still need few non-free apps to run, tried with Nixos, but it didn't go well, considered Voidlinux and at the end decided to stay at Debian, so wonder about using Guix on top of the Debian? any pointer in regard?
<rekado_>gour: Guix on Debian should just work without problems. The manual includes the additional steps you need to perform to get Guix to run smoothly on a "foreign" distro.
<gour>rekado_: ohh, in the manual? thanks. let me check it out
<rekado_>gour: take a look at section 2.6 in particular
<avoine>habs: there is a network-manager-service that you could try:
<gour>found it, thanks ;)
<civodul>habs: if you're using %desktop-services, you need to delete the wicd service from that list and to cons (network-manager-service) to it
<civodul>however, i think network-manager doesn't quite work, though i forgot the details
<civodul>iyzsong might remember?
<rekado_>I think we need to do something about this bioconductor situation.
<rekado_>they only keep the latest tarballs and new releases happen very often.
<rekado_>all bioconductor packages are pushed to SVN, and there's a git mirror of all the SVN stuff.
<rekado_>the importer could be changed to use the latest commit in the current release branch at packaging time.
<rekado_>then all bioconductor packages would be built from git, not from the volatile tarballs hosted by
***kelsoo2 is now known as kelsoo
<lfam>Mention of Guix from the perspective of programming languages:
***kelsoo1 is now known as kelsoo
<cbaines>How would I go about packaging a Python library that I just have locally in a directory on my machine? I have tried writing a (package ...) but guix complains about the lack of the sha256 field. Im
<cbaines>*I'm not even sure what that would mean in the context of using a git-reference, and really don't want to have to update it every time I make a change to the package...?
<cbaines>Is there a way of getting Guix to not require this?
<lfam>To not require specifying the hash?
<lfam>cbaines ^
<efraim>what if you do (sha256 #f)
<davexunit>you *must* specify the hash
<cbaines>efraim, I just tried that, and it did not complain, but I'm not sure if the package was actually installed either...
<lfam>The whole system is a DAG of those hashes...
<lfam>From far away, anyways
***MightyJoe is now known as cyraxjoe
<cbaines>Ok, I had an error in the origin, but after fixing that I get another error when trying to run guix build -f
<cbaines>guix build: error: build failed: derivation `/gnu/store/q8gy93vpww4cwfcaf107g76ggrhcws51-example_library-1.drv' has incorrect output `/gnu/store/m2a3jywvq2b561qgsybpwmwfmylm4cqz-example_library-1', should be `/gnu/store/1w3kzk3g25qai4p2as5n5djyywhrl7fw-example_library-1'
<cbaines>This might be because I am using (sha256 #f)...?
<davexunit>cbaines: you need to specify a hash
<davexunit>there's no way around that. the integrity of the system depends on it.
<lfam>cbaines: If you think it's too onerous to update the package definition for each git commit, you could "cheat" and write some code to rewrite the package definition after each commit.
<lfam>You could even use a git hook to automate it
<cbaines>What do I hash? The origin is a git-reference.
<davexunit>cbaines: it's a hash of the directory that is created from a git clone, sans the .git directory.
<davexunit>the .git directory is nondeterministic so it is deleted.
<lfam>`git checkout $desired-reference && rm -rf .git && cd .. && guix hash --recursive $git-repo`
<davexunit>you'd do that on a *copy*, rather than your local checkout that you use for development. ;)
<lfam>Yes :)
<lfam>`guix hash --recursive --exclude .git` would be a friendly feature
<davexunit>lfam: yes indeed
<davexunit>wouldn't be hard to add either!
<lfam>I can't think of any other use cases, but this would save resources for very large Git repos
<davexunit>would be useful for any other vcs
<lfam>I *tried* to clone the Chromium repo the other day. I gave up after several gigabytes. I'd hate to make a copy of it, even on a COW filesystem
<cbaines>I've now added a hash, and I'm getting further, but the build process is having trouble cloning the repository:
<cbaines>fatal: repository '/tmp/example_library' does not exist
<davexunit>/tmp/example_library isn't a URL
<cbaines>I tried with the file:// prefix, and that did not work either
<cbaines>My best guess currently is that it is a permissions issue perhaps?
<davexunit>cbaines: builds happen in an isolated environment, so your local file system is not accessible
<cbaines>Ok, this little experiment of mine is getting really out of hand now
<lfam>How can I figure out which store item a setuid-program refers to?
<cbaines>So, at the moment, if I just want to package something on my local machine, I have to make it available on the loopback interface?
<lfam>cbaines: I'm not sure. Sounds like a good experiment :)
<lfam>I *have* packaged something from a local git repo though. It was a long time ago and I struggled to learn how to do it, and I don't remember exactly what I did
<lfam>I definitely didn't use the loopback interface
<davexunit>I always point to my remote git repo so that it's reproducible for others
<lfam>Actually, I think I made a release tarball from the git repo, and packaged that
<cbaines>Aha, so I've finally managed it. Had to run git update-server-info, then run python3 -m http.server 8000 and then change the package definition to point to that server, but it has now build :)
<efraim>bournish@(guile-user)> wc gpl-3.0.txt
<efraim>(674 5644 35147 gpl-3.0.txt)
<efraim>I'm going to have to rework the print-out to be less scheme-y and more bash-y
<lfam>efraim: :)
<lfam>Nice test file
<davexunit>efraim: awesome!
<efraim>much easier to type than 0001-gnu-Add....
<lfam>Next step, programmable completion ;)
<efraim>looks like the guix binary is failing to build:
<civodul>super weird
<efraim>i'm building it locally, i'll see how that goes
<ng0>for people in berlin who are interested in this, there's a meeting tomorrow in berlin: :)
<lfam>efraim, civodul: I built successfully from a fresh clone
<civodul>it looks like a parallel-build issue