IRC channel logs
2015-11-01.log
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 <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>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 guix-devel@gnu.org. 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.. <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 guix-system.sh tests, skipped the guix-package-net.sh 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>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>i got guixsd installed, but it cannot find my / partition at boot. maybe you wont know cuz you ae on other distro? <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 tukaani.org <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>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 <iyzsong>Gxsdnewb: you can fetch the tarball from anywhere, when it have the same checksum, guix will use it. also hyadr.gnu.org host all the source talballs itself, you can use 'guix build -S xz' to get it. <iyzsong>for hydra.gnu.org, 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>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? <lfam>GUIX_PACKAGE_PATH=$HOME/pkgs <lfam>$HOME/pkgs/leo/packages/patches <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>ACTION is running 'guix gc', all IO is blocking.. <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>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 <efraim>that I don't know, i never got around to having encrypted disks/partitions <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". <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 <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>I have an encrypted luks partition and inside I use LVM, and have boot, deb-root, home and swap <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 directory.fsf.org 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>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 <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>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>davexunit: if there's only one entry for each variable, you could just use that no? <civodul>like: guix package --search-paths | cut -d = -f 2 <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>I have a private package for Dolphin, the gamecube/wii emulator <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 <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 <efraim>what about something like translate-shell? <efraim>cli interface to google translate <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. <efraim>youtube-dl supports many backends <efraim>i thought fsf-free was similar to debian main+contrib, but i never checked too closely <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. <karhunguixi>how are hashbangs for portable scripts (like bash) handled in GuixSD? <civodul>the only thing that can be relied on is /bin/sh <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>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/... <karhunguixi>i see, so generally one need to adjust the hashbang when the script is moved to another system <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 <civodul>ACTION pushed udisks & polkit things <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 <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>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>i can't believe that hasn't been fixed <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 <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 <rekado>(but I used Arch before Fedora.) <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). <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>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? <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? <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 <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 <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. <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? <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.. <paroneayea>ACTION just discovered that CLISP is free software because of GPL compliance <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. <davexunit>the understanding is that *only* the software they asked for is available <davexunit>check for (equal? command (list (getenv "SHELL"))) and change it to '("/bin/sh") <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. <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. <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 <davexunit>civodul: okay, I'll prioritize the 'guix environment' fixes. <paroneayea>ACTION struggles to get Activipy 0.1 out this week so he can join in the release fun <rekado>would it be possible to "pin" substitutes for releases? <rekado>it's unfortunate that users of 0.8.3 have to build stuff from source right now. <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 <civodul>i wonder if we should start a plan B <lfam>I'll try to get Lua working properly by Wednesday <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 <wingo>civodul: at igalia we could host a thing, dunno... <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>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>would be great if Igalia could help :-) <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>what could you do with what amount of euros <wingo>is it just hydra.gnu.org 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>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? <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>which could be less than 1200€ a year, roughly <wingo>customers have been asking for nixos recently <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 <wingo>but we just ordered a couple of spendy boxes for doing snabb benchmarks, maybe we can timeshare them... <civodul>for the front-end we'll need a dedicated machine though, going forward <civodul>i'm thinking we could even have a 2nd, separate build farm <wingo>plz mail me some specs at wingo@igalia.com 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? :) <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. <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>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 <wingo>which is mega-frustrating on many levels for continuous integration <wingo>like, "what ran this test? what software was involved?" <wingo>a colleague of mine contracted with nixos people to package all openstack things for nixos <wingo>on my recommendation about nix and i also mentioned guix too <wingo>but i think nix was somehow safer for him <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>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) <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 <wingo>now is a great time to do this <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. <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>seems that the tests only ever pass on my machine <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 <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>we can't just use "sh" because pure environments won't likely have it on $PATH <davexunit>but we can't use "/bin/sh" because the daemon doesn't mount a shell there <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.