IRC channel logs


back to list of logs

<Gxsdnewb>where can i find proper checksums for gcc-4.9.3.tar.xz? or how can i invoke guix to check for me?
<lfam>Gxsdnewb: I don't get any errors running `tar xf` on the source derivation of the gcc-4.9.3.tar.xz in my store. If the file is truncated that means it is incomplete or corrupted. I'm not sure if `guix gc --verify=contents` can operate on a single store item (this would be useful)
<lfam>Gxsdnewb: what is the full path to your tarball? /gnu/store/...
<lfam>Gxsdnewb: Since your store is pretty new, `guix gc --verify=contents` probably wouldn't take too long. That will hash everything and make sure it is correct
<Gxsdnewb>it detects that my guix-0.8.3 store was modified
<lfam>Gxsdnewb: It would be useful is someone who runs GuixSD and has more experience than I do could help you with this. I would try to garbage collect the failing item and then do whatever you are doing again. If the input to tar ends unexpectedly, it usually means the file is incomplete. For example, if the download failed halfway through.
<lfam>Gxsdnewb: what is the path the failing tarball? I can try to verify the hash for you.
<Gxsdnewb>so can i force redownload of the inputs for a build?
<lfam>Gxsdnewb: try garbage collecting the failing store object: `guix gc -d /gnu/store/kw8jayl9jf4ckbgzcnm6ivb5l9izc8bm-gcc-4.9.3.tar.xz`
<lfam>Then, redo whatever failed in the first place
<lfam>Read the man page for `guix gc` so you understand what it does
<lfam>`guix gc -h`
<lfam>Not a man page, per se
<Gxsdnewb>what about the fact that gc --verify=contents shows guix package as modified?
<Gxsdnewb>isnt it worrisome that it calculates a different hash than expected?
<lfam>Yes, that is why I suggest you remove the errant file and redownload it
<lfam>Oh the Guix package
<lfam>I thought it was GCC
<lfam>Well, since this is a new installation, I would try to garbage collect and redownload anyways. Nothing to lose.
<lfam>BTW, what distro are you using, and what implementation of tar? My GNU tar from Debian 9 doesn't complain about the timestamps.
<Gxsdnewb>tar from debian wheezy, but i thought guix uses a pits own precompiled tar as part of the bootstrap binaries?
<lfam>Oh true. See, that's why you need someone with more knowledge than me ;) I just package things.
<roelj>In february 2016 I need to do an internship of about 20 weeks to finish my software engineering bachelor. I would love to make a substantial contribution to Guix, GuixSD or Guile. Is there some way I could get a mentor for my internship?
<roelj>And are there any 'projects' left to be taken care of?
<lfam>roelj: There is much work to be done! If none of the Guix developers respond on IRC tonight, you should ask on the mailing list at Or ask on #guile.
<roelj>lfam: Great, thanks. I think I should use the mailing list instead. I'm about to go to sleep as well.
<lfam>roelj: This channel is will be more active about 12 hours from now. And some of the users who would be active now are probably at Halloween parties ;)
<roelj>lfam: Are most people here from the U.S.?
<lfam>roelj: No, that's why I think you would have a better chance here on #guix when Europe wakes up.
<lfam>roelj: And most of us USA people are not on IRC tonight
<roelj>lfam: Oh sorry, I misunderstood you. I didn't realize Halloween was that big, but hey, I'm European..
<roelj>Well, I'll write an e-mail to the list. Thanks for your response though.
<lfam>Thanks for your interest!
<lfam>I hope you can find something useful and gratifying to do for your internship
<roelj>lfam: I really hope I can find a way to contribute these 800 hours of work to Guix or Guile..
<davexunit>ACTION is back from treat or treating
<Katari>Hello. I'm attempting to install GuixSD on a system (x64). I've made the environment as clean as I thought to make it (re-writing the image, re-writing the partitions, to be GPT with an EFI partition, swap partition, and a main file system taking up the rest of the disk), and then using the bare-bones configuration in the module with the installation instructions in 6.1.3 exactly, substituting enol for a real network interface, but am
<Katari>still having issues. I've made the output of guix system init redirect into a log file, with &>, and attempted to extract useful information from said log. Notably, it failed the nar.scm, store.scm, and tests, skipped the test. It then said a variety of check* failed, the builder failed, cannot build derivations ... build failed of system. In the upper log, there was spam about how the compilation of
<Katari>/gnu/store/...-guile-2.0.11/bin/guild failing, sauing it failed to create the path for the auto-compiled file said previously. This is all of the information that I've gathered. Any ideas?
<Katari>Wow, I didn't expect my message to become so long. Sorry for the poor grammar in places, I had forgotten what I had said at the beginning of my sentences by the end of them.
<Gxsdnewb>katari: this is with 0.8.3 alpha binary?
<Gxsdnewb>Did you try a guix pull after enabling cow store on your mounted root partition?
<Katari>Gxsdnewb: Yes, and-- wow, I guess I didn't. Genius.
<Gxsdnewb>i just installed guixsd myself, but it cannot find the root part
<Gxsdnewb>i am not sure where the fstab is...
<Gxsdnewb>also there is no /root/.guix-profile/ dir
<Katari>that isn't the case on mine, either.
<Gxsdnewb>katari you mean you have no profile dir also?
<Gxsdnewb>hello again lfam!
<Gxsdnewb>i got guixsd installed, but it cannot find my / partition at boot. maybe you wont know cuz you ae on other distro?
<Gxsdnewb>i am not sure where fstab equivilant is
<lfam>Gxsdnewb: Hello! Try searching this chat log for fstab:
<Gxsdnewb>wait a min.. grub configured itself with linux-libre 4.2.5 but i only have 4.0.8
<Gxsdnewb>in the live env i want to restart guix-daemon to use --no-substitutes --
<Gxsdnewb>ifan: thank for the link, because i find hthe device and title syntax confusing
<iyzsong>Gxsdnewb: you can stop the service by 'deco stop guix-daemon', and then run it as 'guix-daemon --build-users=group=guixbuild --no-substitutes' etc.
<efraim>substitues are enabled by default in guixsd?
<iyzsong>efraim: yes, the default guix-configuration enable it.
<Gxsdnewb>and i must run guix pull every time i boot into live usb env? or after running deco start cow-store /mnt can it detect my fresh guix install from previous boots?
<iyzsong>it won't detect what you have in /mnt, for guix to know, the store items need to register in a sqlite db. the db on the live usb won't contains any thing of /mnt after reboot.
<iyzsong>I wonder whether we can make a self-contained install media with a minimum system to be install without access internet. after install that, we can pull/reconfigure etc.
<Gxsdnewb>iyzsong: but i remounted my disk to /mnt and reran deco start cow-store /mnt
<Gxsdnewb>is not the sqlite db there for guix to find?
<Gxsdnewb>it seems after i did that, guix pull took much shorter time...
<Gxsdnewb>ah nevermind it failed with 403 error forbidden at mirror
<Gxsdnewb>another question: if i previously downloaded substitutes but after only ran guix-daemon with substitutes disabled, is there a way to see or flag which items in my /gnu/store are not locally compiled?
<Gxsdnewb>ok bad news
<Gxsdnewb>developer of xz has suspended downloads of the source tarball and put a notice on the website telling source distros to host their own tarballs
<Gxsdnewb>how can i continue building?
<iyzsong>Gxsdnewb: you can fetch the tarball from anywhere, when it have the same checksum, guix will use it. also host all the source talballs itself, you can use 'guix build -S xz' to get it.
<Gxsdnewb>that command tries again at
<Gxsdnewb>the hashing is all sha256?
<iyzsong>for, you need to enable substitutes ...
<iyzsong>I think it's base64-ed sha256, run 'guix hash' on a file will get it.
<iyzsong>to fetch the tarball from somewhere into the store, run 'guix download URI-TO-FILE'. uri can be http/ftp or file://.
<Gxsdnewb>so substitutes are for source tarballs as well?
<Gxsdnewb>so i can better un guix download for that one file instead of enabling subs
<iyzsong>Gxsdnewb: sure, you can. I agree we did rely on the substitutes server too much.. could you track the process and report any issue or suggestion to the mail list? that would be really useful.
<Gxsdnewb>i would like to help, so this is a good suggestion thnx
<lfam>Here is a mirror for xz:
<lfam>Does anyone patch source tarballs for packages in their personal load path (guix build -L)? I can't get it to work
<alezost>lfam: do you mean you want to have your local package with patches?
<lfam>alezost: Yes. I put the patch in a patches directory that is in the package directory. Like with gnu/packages/patches
<alezost>you can just use GUIX_PACKAGE_PATH and packages with patches will work
<lfam>alezost: That doesn't work either for me. I get the same "guix build: error: borg.patch: patch not found"
<alezost>lfam: could you tell what dir you put in GUIX_PACKAGE_PATH and what is the patch dir?
<iyzsong>if I read the gnu/packages.scm right, patches should just put in $HOME/pkgs.
<lfam>The Guix patches are in gnu/packages/patches
<lfam>And it doesn't find the patch there, either
<iyzsong>lfam: yeah, look '%patch-path' in packages.scm, it use $GUIX_PACKAGE_PATH.
<lfam>Even when I use GUIX_PACKAGE_PATH, and make the tree like $HOME/pkgs/patches it still doesn't find the patch
<iyzsong>no patches folder
<lfam>Thank you!
<iyzsong>ACTION is running 'guix gc', all IO is blocking..
<alezost>lfam: so does it work after all?
<lfam>alezost: Yes. I don't understand why it doesn't work with --load-path / -L. I thought that did the same as the env variable
<lfam>izysong: I've had that happen to me. My system load went up to 15 before I had to learn about btrfs maintenance...
<iyzsong>I use ext4, maybe my laptop's harddisk is too slow :-
<iyzsong>lfam: so the document for 'search-patch' is missing, could you send an email :-)
<iyzsong>or better a patch for the document, sorry I can't do that, I don't have confidence of my English.
<lfam>I guess that GUIX_PACKAGE_PATH does a lot more than --load-path. For example, enables the use of `guix lint`
<lfam>I need to read the source to figure out what the difference is.
<tyrion-mx>what are the drawbacks of using only guix instead of guixsd?
<tyrion-mx>guix on an existing minimal system as a package manager
<efraim>tyrion-mx: I don't know how easy it is to launch a desktop environment from just guix, and I have to launch the programs from the command line instead of the magic search box
<tyrion-mx>umh :(
<tyrion-mx>efraim, backup question: if I have a crypted system, why does guixsd have to know about it?
<tyrion-mx>I mean, couldn't I just setup grub correctly from a live system
<tyrion-mx>to decrypt the disks and start guixsd?
<efraim>that I don't know, i never got around to having encrypted disks/partitions
<tyrion-mx>thanks anyway
<efraim>sunday's normally pretty quiet on irc
<rekado>sneek: later tell lfam I'm using GUIX_PACKAGE_PATH and I have packages that need patches. The patches are located in the root of the directory, while the packages are in "my/packages/". This works for me. I don't use "--load-path".
<sneek>Will do.
<civodul>Hello Guix!
<karhunguixi>tyrion-mx, my fragile understanding of this is that grub will kick off the initial ramdisk (initrd) of the OS. Then initrd will have to decrypt and start the actual OS.
<tyrion-mx>karhunguixi, this is also my understanding. So I could create an initrd that decrypts the stuff and then calls the init
<karhunguixi>i think you could have a encrypted /boot partition, that grub decrypts. And the keys for the / partition could be readable in there which can then be used to decrypt the actual OS without user interaction.
<karhunguixi>this is something i want to have, currently i'm decrypting twice
<civodul>tyrion-mx: on GuixSD it suffices to declared one LUKS mapped-device for each encrypted device:
<tyrion-mx>karhunguixi, this is what I currently have (using debian)
<tyrion-mx>karhunguixi, I could link you a couple of blog posts if you want
<karhunguixi>hm, what was your original question about then; why GuixSD have to know about you having a encrypted system?
<tyrion-mx>basically I want to use guixsd with my current setup
<tyrion-mx>so I could choose to boot debian or guixsd
<tyrion-mx>I have an encrypted luks partition and inside I use LVM, and have boot, deb-root, home and swap
<tyrion-mx>I would like to add guix-root
<karhunguixi>i'm not sure if GuixSD support LVM
<civodul>it doesn't support LVM yet
<efraim>what do I enter for license if a package is MIT licensed
<civodul>so each partition needs to be encrypted separately, which isn't great
<civodul>efraim: if in doubt, check the URLs in (guix licenses) :-)
<efraim>build offloading, if I have 5 derivations to build I offload entire derivations to another machine, or it helps out like distcc?
<efraim>is network enabled while building from source?
<civodul>efraim: networking is unrelated to Guix, what do you mean?
<efraim>i think the tests are failing because its trying to download files from the internet
<efraim>or its trying to access files outside its sandbox
<efraim>i'm seeing ftp://host/file ; filesize=0 and the like
<efraim>ServerStat: set status ERROR for alpha (http)
<efraim>or my favorite so far: requesting PWD; recieved /path/to
<efraim>and then it tries to go there
<efraim>i think aria2 couldn't find libcares because it was looking in /gnu/store/...cares/lib/libcares and not /gnu/store/...c-ares/lib/libcares
<efraim>so time to try that again
<davexunit>civodul: tweaking the guix environment tests to account for the profiles. not sure what to do about some of the search path tests.
<davexunit>for the simple one with just bootstrap Guile, I checked that $PATH was set to .*-profile/bin and then tested that /gnu/store/...-profile/bin/guile exists.
<davexunit>but there are more complicated tests with the bootstrap binaries.
<davexunit>maybe I should grep the references list of the profile?
<civodul>davexunit: that, or you could, say, [ -f $profile/include/guile.h ]
<civodul>things like that
<civodul>our test suite is getting pretty big...
<civodul>davexunit: BTW the daemon actually produces archives deterministically
<davexunit>I guess I need to add a --profile option or something that prints out the profile store path
<civodul>see 320ca99
<civodul>davexunit: if there's only one entry for each variable, you could just use that no?
<davexunit>civodul: yeah
<civodul>like: guix package --search-paths | cut -d = -f 2
<civodul>something like that
<civodul>ACTION goes for a walk
<taylan>we don't have any NES emulators packaged. unbelievable! time to fix that.
<taylan>ACTION will try packaging Nestopia, FCEUX, higan (AKA bsnes), ZSNES, Snes9x, and Mupen64Plus
<davexunit>taylan: :)
<davexunit>I have a private package for Dolphin, the gamecube/wii emulator
<davexunit>not sure if its appropriate for upstream
<taylan>yeah, I might also look into Mednafen, Dolphin, DeSmuME, VBA-M, and MAME/MESS. going through the list on Wikipedia, there's just too many of these :P
<taylan>davexunit: license issues?
<taylan>Wikipedia says GPL2+
<davexunit>it's free software, yeah.
<davexunit>but it's an emulator for a proprietary system.
<taylan>we also have a DOS emulator FWICT
<taylan>free software gaming sadly seems to be a distant dream. a lot of art goes into games, so one can't simply make free software variants.
<davexunit>but that has nothing to do with whether or not an emulator for proprietary video games should be in a fully free distro
<davexunit>AFAIK Trisquel does not include such things
<efraim>what about something like translate-shell?
<efraim>cli interface to google translate
<davexunit>that is okay.
<efraim>debian has it in contrib, relies on non-free service to function
<davexunit>well, maybe they are aware of something that I'm not.
<davexunit>it seems similar in purpose to youtube-dl
<davexunit>but ah, it's different.
<davexunit>google translate is SaaS
<davexunit>youtube is not
<efraim>youtube-dl supports many backends
<davexunit>so yeah, no SaaS frontends.
<davexunit>but I'm not the authority on the subject.
<efraim>i thought fsf-free was similar to debian main+contrib, but i never checked too closely
<davexunit>only in some ways.
<davexunit>for example, documentation under the GFDL with invariant sections is in Debian contrib
<davexunit>so installing emacs in debian main doesn't get you the documentation
<davexunit>we don't see this is as an issue and include the docs
<efraim>emacs without documentation sounds hard
<efraim>and it IS called the gnu free document license
<davexunit>invariant sections are non-functional text that cannot be modified in redistributed copies.
<davexunit>so the Debian project views that as nonfree
<karhunguixi>how are hashbangs for portable scripts (like bash) handled in GuixSD?
<civodul>karhunguixi: they're not! :-)
<civodul>the only thing that can be relied on is /bin/sh
<civodul>which happens to be Bash
<civodul>however, that's usually not a problem
<civodul>packages built as with "guix build" have their shebang adjusted appropriately
<civodul>so it's only an issue with home-baked scripts not handled by Guix
<karhunguixi>right, it's home-baked scripts i'm thinking of
<karhunguixi>i'm making one right now, and don't know what to use for hashbang
<civodul>in practice i use #!/bin/sh for these
<civodul>and on some occasions, something like #!/run/current-system/profile/bin/...
<civodul>or #!/home/ludo/.guix-profile/bin
<karhunguixi>i see, so generally one need to adjust the hashbang when the script is moved to another system
<karhunguixi>(another system not running Guix)
<karhunguixi>it's not a problem for me, i was just curious :)
<civodul>yeah i've used NixOS and then GuixSD for ~7 years now and i've never found it to be a real issue
<civodul>at some point NixOS gained /usr/bin/env but i wasn't convinced
<karhunguixi>i usually ignore the hashbang and just run them like, "bash script.bash"
<karhunguixi>but i got curious when i thought of the hashbang in the realm of Guix
<karhunguixi>(i've been told you're not supposed to use .bash but i don't see the problem)
<fps>i guess i might try packaging radium
<paroneayea>hello #guix!
<civodul>good day Mr paroneayea! :-)
<paroneayea>hey civodul :)
<civodul>ACTION pushed udisks & polkit things
<civodul>testing welcome!
<civodul>especially from people using Xfce or similar GUIs
<karhunguixi>i'm using Xfce and willing to help, but i wouldn't know what to do :/
<efraim>plug in and unplug a usb device and see if it crashes your system ;D
<karhunguixi>Hehe, i can do that ;)
<taylan>we have the executable 'c++' in the gnu build environment but not cc. why the difference?
<civodul>taylan: gcc installs 'c++' but not 'cc'
<taylan>weird *shrug*
<taylan>hm, it seems this Makefile runs xdg-desktop-menu to install some stuff in $HOME. I guess I should just remove it from the Makefile?
<taylan>oh, it runs in "user mode" because the user isn't root. hmm.
<Sleep_Walker>I just found that I have first community user of guix on openSUSE \\o/
<taylan>hm, now it says "No writable system menu directory found." I'll remove it for now, ask on the ML for opinions.
<efraim>my impression was most people came from/are on arch or debian
<taylan>ugh, FCEUX has a hideous build system (worse than Nestopia), so I'll leave that be for now.
<taylan>hmm, how do we decompress .7z source code?
<wingo>civodul: what if guixsd installed a /usr/bin/env
<wingo>why bother with /bin/sh and not /usr/bin/env?
<wingo>/usr/bin/env is the best shebang interpreter
<taylan>if it provided a way to pass arguments, then it'd be perfect...
<wingo>lol yeah
<wingo>i can't believe that hasn't been fixed
<wingo>so sad
<karhunguixi>wingo, you seem to be missing color for body text on your blog. For all of us who have set default color for foreground to white and background to dark it becomes white text on white background ;)
<karhunguixi>(opening the style editor in dev tools and adding "color: #111;" to body{} in base.css makes it ok)
<wingo>karhunguixi: tx for the note i should fix it
<wingo>ACTION looks
<efraim>problem or ok to ignore? (during install phase): /tmp/nix-build-c-ares-1.10.0.drv-0/c-ares-cares-1_10_0/libtool: line 1723: ldconfig: command not found
<wingo>karhunguixi: done tx :)
<karhunguixi>sure, no problem :)
<rekado>efraim: I came from Fedora.
<rekado>(but I used Arch before Fedora.)
<karhunguixi>I come from Arch
<rekado>fps: I tried packaging radium. Then I gave up and decided to fork radium. Then I threw out all Mac and Windows and Amiga code, all dead code, everything annoying and I was left with a non-functional application. I don't recommend it.
<rekado>radium bundles libraries that have been forked and adapted for no good reasons.
<fps>rekado: true. i remember it being pretty straightforward to build on ubuntu, even with its weird bash build scripts..
<rekado>one of them is the visualization library. I went through a big diff for two days only to figure out that there has been an added class --- which didn't require a fork.
<rekado>it includes a heavily modified version of libpd (or similar).
<karhunguixi>Radium -- the internet radio player?
<fps>when i tried it it was even hard to get a pattern to loop :)
<fps>but it's been a few years
<karhunguixi>oh ok. I only found one application on wikipedia, and it's proprietary
<rekado>fps: also see this:
<rekado>I only wanted to package it to try it (because for me too it's been years since I last used it).
<fps>rekado: i guess the approach to put in the remaining build inputs and just run the build script might work?
<fps>might need up lots of fixing up of the script though?
<rekado>if you just want to use it on your machine that would probably work, but with this heavy bundling I don't think it would be accepted in Guix.
<karhunguixi>(them radium guys forgot to set body text color as well)
<fps>rekado: oh well, nothing stops people from setting up third party package collections, no?
<davexunit>ACTION tries to get mumble to build
<civodul>davexunit: could you add in guix.texi as a footnote the minimum kernel version required for containers?
<civodul>also what would you like to do for 'guix container exec'?
<civodul>and 'guix environment --container' vs. $SHELL?
<civodul>and a poney?
<fps>a slightly OT question (though with some relevance to guix): i considered moving away from boost spirit to parse asciichanges songs and learn me some scheme for greater good
<karhunguixi>yay for mumble!
<fps>guixsd has guile built in. but there's also other lisp implementations like racket, or common lips, etc..
<davexunit>civodul: yes, I've been meaning to handle all of those things.
<fps>sooo, any of you pro guile/schemers: for a lisp/scheme noob: what dialect/implementation would be best for a noob to learn to write a parser for a language that's not s-expressiony
<fps>albeit being a simple language:
<civodul>davexunit: cool, sorry for this not-so-nice "hello" (i happened to be going through my to-do just when you arrived ;-))
<fps>is guile's reader library a good start?
<davexunit>civodul: okay so, 'guix container exec' is basically ready to go. I can add that patch in with the modified disclaimer you proposed.
<davexunit>so we can work on making it a full-fledged tool later.
<civodul>sounds good
<davexunit>and the container shell thing... I suppose we can also expose $SHELL by default.
<davexunit>but I worry that it may not be sufficient for some shells?
<fps>and also a guix question: how can i tell xorg to use modes with higher res? running in a virtualbox though.. might qemu be easier?
<paroneayea>ooh mumble
<davexunit>don't get too excited. I can't get the damn thing to build.
<davexunit>currently I'm stuck using the Plumble android client :)
<karhunguixi>i think SHELL is your login shell, and it's unreliable as to find out what shell is currently running.
<karhunguixi>(not sure how relevant that information is to what you're doing though)
<davexunit>karhunguixi: the thing here though is that 'guix environment' uses $SHELL as the default command to run when no command is specified by the user.
<civodul>davexunit: i think it should be fine
<davexunit>civodul has proposed that we expose that shell binary inside of containers, to avoid a weird user experience.
<davexunit>okay, shall I do this unconditionally or only when (equal? command (list (getenv "SHELL")))?
<karhunguixi>Ok. I just remember having issues finding a reliable way to determine what shell is currently running..
<davexunit>yeah we don't try to do that
<paroneayea>ACTION just discovered that CLISP is free software because of GPL compliance
<paroneayea>pretty cool.
<davexunit>oh nice
<davexunit>maybe some vmware stuff will be some day ;)
<civodul>davexunit: maybe anytime COMMAND is an absolute file name? hmm
<davexunit>civodul: I think if the user specifies a command then they know what they are doing.
<civodul>yes, right
<davexunit>the understanding is that *only* the software they asked for is available
<davexunit>here's another idea:
<davexunit>check for (equal? command (list (getenv "SHELL"))) and change it to '("/bin/sh")
<civodul>yes, why not
<paroneayea>davexunit: here's the original exchange if you're curious
<davexunit>or, perhaps even better, change the default command to be some special value so that we know whether or not the user entered a command.
<davexunit>if it's say, #f, we use "/bin/sh" in containers, otherwise $SHELL.
<civodul>even better indeed :-)
<rekado>fps: I don't think the reader library would be a good fit for this. Maybe take a look at guile-json for a project where text is parsed. It's well-commented.
<fps>rekado: thanks
<davexunit>civodul: when do you want to release 0.9.0? real soon now?
<civodul>davexunit: yes i was thinking Wed, because that's when i have the most free time
<civodul>it could be the week after, but less convenient for me
<civodul>well it could be anytime Wed to Fri, but the hard work must be done by Wed
<paroneayea>guix releases and guile releases both?
<paroneayea>ohhhhh my
<paroneayea>it's gonna be a good week :)
<civodul>and don't forget the Hurd ;-)
<karhunguixi>is it christmas already?
<davexunit>civodul: okay, I'll prioritize the 'guix environment' fixes.
<davexunit>ACTION puts down mumble.
<paroneayea>ACTION struggles to get Activipy 0.1 out this week so he can join in the release fun
<davexunit>hmmm, do I have anything to release? ;)
<rekado>would it be possible to "pin" substitutes for releases?
<civodul>rekado: it is... but...
<civodul>we need more disk space...
<rekado>it's unfortunate that users of 0.8.3 have to build stuff from source right now.
<civodul>yes :-/
<rekado>it would be nice if this could be avoided.
<civodul>it's unfortunate that the FSF still hasn't responded regarding the Free Software Fund
<davexunit>ping them?
<civodul>yes, i can re-re-ping
<davexunit>oh... :/
<civodul>yeah :-/
<civodul>i wonder if we should start a plan B
<karhunguixi>i'm willing to donate directly to one of you guys
<lfam>I'll try to get Lua working properly by Wednesday
<sneek>lfam, you have 1 message.
<sneek>lfam, rekado says: I'm using GUIX_PACKAGE_PATH and I have packages that need patches. The patches are located in the root of the directory, while the packages are in "my/packages/". This works for me. I don't use "--load-path".
<civodul>karhunguixi: that's kind, but i think we need a neutral, community-controlled account
<civodul>if the FSF cannot handle it, we'll find something else
<karhunguixi>sure, just letting you know where at least one in the crowd is standing :)
<civodul>we could talk to the SFC, or register a non-profit in France or in the US, whatever
<civodul>karhunguixi: thanks, it's very useful and encouraging!
<civodul>ACTION wonders what davexunit & paroneayea would recommend
<civodul>given your experience with the FSF...
<efraim>who does debian use in the US? a whole bunch of projects use them
<civodul>it's SFC or SPI, i think
<wingo>civodul: at igalia we could host a thing, dunno...
<efraim>software in the public interest
<wingo>you just need like 4K or so, no?
<efraim>don't think they do hardware, just distributing the money
<wingo>2k for a machine and 2k for bandwidth/hosting, no?
<wingo>not sure what the deal is
<wingo>maybe more € would be more useful, like some e5-26xx machine or so
<lfam>rekado: Yes, I had thought that GUIX_PACKAGE_PATH and --load-path were equivalent but they are not. The env var is much more useful
<civodul>wingo: something like that, i guess
<civodul>would be great if Igalia could help :-)
<davexunit>SFC is a good option
<wingo>let's talk about it tomorrow, who knows what people would like to do
<wingo>so what's the ideal budget of guix next year?
<wingo>or, what are good budgets
<wingo>what could you do with what amount of euros
<wingo>is it just or what
<wingo>ACTION asks impertinent questions
<efraim>hydra build machines are distributed already, just need a hydra front-end and large storage + bandwidth for distibution of packages?
<lfam>Ugh. #lua sucks
<lfam>1 helpful person, 3 people throwing insults
<davexunit>civodul: where should the note about the kernel version go? underneath the first example of 'guix environment --container' in "invoking guix environment", or in the documentation item for the --container option?
<karhunguixi>zone in on the helpful guy and ignore the others :)
<davexunit>lfam: do those people think you are doing something the "wrong way"?
<lfam>Apparently they just hate GNU
<lfam>So they thing that GNU is doing something the "wrong way"
<davexunit>I find this to be typical treatment when I ask about issues that affect Guix
<lfam>I wonder why people feel the need to pile on like that.
<davexunit>do other distribution maintainers get this treatment?
<lfam>I'm pretty new to online software communities. I guess I got lucky that the project I thought was cool (this one) has friendly people
<civodul>davexunit: good question, maybe both in "Invoking guix environment" and "Invoking guix system"?
<efraim>still compiling, but I think I triumphed over pkg-config and it looks like I've finally managed aria2 with c-ares support!
<civodul>wingo: the most pressing need would be ~2K of hardware for the front-end
<civodul>then we need hosting
<wingo>ok i will make the case
<civodul>which could be less than 1200€ a year, roughly
<wingo>customers have been asking for nixos recently
<civodul>oh, fun :-)
<wingo>yeah in snabb they seem to be excited about nixos
<wingo>and it would be nice to redirect towards guix :)
<wingo>the services stuff recently has probably made that nicer
<civodul>but obviously it may not be directly usable for the customers need, unlike NixOS
<civodul>but we're getting there! :-)
<wingo>but we just ordered a couple of spendy boxes for doing snabb benchmarks, maybe we can timeshare them...
<civodul>could be useful
<wingo>two 2xE5-2620 systems
<davexunit>civodul: okay
<civodul>for the front-end we'll need a dedicated machine though, going forward
<civodul>but for the build machines, yes
<civodul>i'm thinking we could even have a 2nd, separate build farm
<civodul>for determinism issues
<wingo>plz mail me some specs at for the desired frontend (# cores, ram, storage, network)
<davexunit>civodul: would be awesome to have another build farm!
<efraim>for the build machines, would it be possible to create a hydra service and allow people to donate unused PC time to building?
<wingo>efraim: would you trust it? :)
<civodul>yes that's the problem :-)
<efraim>probably less than hydra, but we could do best-of-3 or something like that
<wingo>build machines are great remote-compromise material
<davexunit>we'd need to have a mass of machines and that can come to a consensus about a build result.
<davexunit>we're not there yet. :)
<karhunguixi>minifree is about to release a server board,
<davexunit>civodul: doc patch:
<davexunit>good or should I expound more?
<civodul>s/in order//
<davexunit>civodul: bleh, sorry.
<davexunit>had longer sentence
<davexunit>then truncated
<davexunit>but not enough!
<wingo>so fwiw from a commercial context it isn't that customers are asking for nixos, or at least not end users
<wingo>but people that deliver network applications like switches based on snabbswitch -- free software through and through --
<wingo>they are getting frustrated at the delivery process -- about how to install on hardware, about how to update, about how to provision over pxe
<wingo>about how to know that what is running at the remote site is what they planned on running
<wingo>so deployment is one thing
<wingo>the other is testing
<wingo>for example in the openstack context
<wingo>to test one component you might need to spin up a cluster of N vm's
<wingo>all running git upstream software from openstack
<civodul>oh, i see
<wingo>which is mega-frustrating on many levels for continuous integration
<wingo>like, "what ran this test? what software was involved?"
<civodul>yeah, i can imagine
<wingo>a colleague of mine contracted with nixos people to package all openstack things for nixos
<civodul>oh really?
<wingo>on my recommendation about nix and i also mentioned guix too
<civodul>Steap: ↑
<wingo>but i think nix was somehow safer for him
<civodul>yes, could be
<civodul>well NixOS, i'd say
<wingo>so end-users will accept whatever but the sweet spot that i have seen for nixos is specifying deliverables on the os-level
<wingo>which isn't really possible with anything other than nixos or guixsd
<wingo>from what i can tell
<civodul>ACTION .oO (Docker?)
<paroneayea>civodul: I can pester about it
<paroneayea>about the fund thing
<paroneayea>I'm good at pestering the FSF
<civodul>paroneayea: tell me everything :-)
<wingo>so the "market" is people creating deliverables that are packaged either as custom hardware with a bare-metal os or virtual machines
<civodul>yeah, so they need to automatically build the whole thing
<wingo>paroneayea: if igalia can contribute $xK towards guix things via the fsf we would be happy to do so
<wingo>but it would have to be targetted
<wingo>for both internal (selling it to colleagues) and external (having the funds actually matter to guix)
<wingo>civodul: so docker is ok and is a competitor. but the declarative thing is a strong sell, and docker doesn't have it
<wingo>not sure what the docker update story is either, besides hosting a custom apt repo (ugh)
<paroneayea>wingo: oh awesome
<paroneayea>wingo: yes we should do a matching funds thing.
<wingo>matching funds sounds cool :)
<paroneayea>wingo: civodul: they can set up a civicrm instance and I can give you the code we used to do the thermometer throbber
<paroneayea>in the GMG campaign
<paroneayea>so you could put it on the guix site
<wingo>now is a great time to do this
<wingo>for fiscal year reasons
<civodul>oh right
<civodul>paroneayea: actually, i was not planning to run a full campaign à la GMG
<paroneayea>civodul: I know, but if you're doing a matching thing
<civodul>though i'd encourage anyone else to do that :-)
<wingo>igalia's fiscal year is a calendar year but we have some surplus this year so yeah let's do it
<paroneayea>you might still want a thermometer to put on the site.
<civodul>wingo: ok, cool!
<civodul>paroneayea: yes, right
<davexunit>very exciting :)
<paroneayea>Steap: ping
<paroneayea>Steap: I wonder if you know how hard it would be to get GuixSD running on OpenStack type servers
<civodul>davexunit: i'll go afk a bit, but before that, i wanted to share a couple of test failures with current master... ;-)
<davexunit>these plague me to no end
<davexunit>seems that the tests only ever pass on my machine
<davexunit>I don't get it
<davexunit>civodul: where did you run these tests?
<davexunit>is the 'guix' package build process?
<paroneayea>wingo: civodul: I'll ping the FSF tomorrow (ping me if I forget) and mention the possible Igaliga matching thing, that also might help spur things into action, especially because it's a timed event :)
<civodul>davexunit: in the daemon, i was trying to update the guix-devel snapshot
<civodul>where /bin/sh is missing
<civodul>paroneayea: great, thanks!
<davexunit>civodul: how did -E ever work, I wonder?
<davexunit>I guess I need to do "sh" instead of "/bin/sh" ?
<davexunit>I'm surprised the build container doesn't have a /bin/sh
<davexunit>'make' refused to do anything without it when I first tried making these containers
<civodul>maybe we used to do execvp("sh"), and now execv("/bin/sh")?
<davexunit>will try that
<civodul>ACTION goes afk
<davexunit>grr, this test failure is a tricky thing
<davexunit>we can't just use "sh" because pure environments won't likely have it on $PATH
<daviid>davexunit: have a beer! :)
<davexunit>but we can't use "/bin/sh" because the daemon doesn't mount a shell there
<davexunit>and all this for a deprecated flag!
<davexunit>so what shell to use, anyway?
<davexunit>sneek: later tell civodul how about setting the SHELL env var in the guix-devel build script so that 'guix environment -E' will use it? Simply using 'sh' won't do in pure environments that don't have a shell on PATH.
<davexunit>damn it, now 'guix system container' doesn't work.