<lfam>myglc2: I just do `guix environment guix` <myglc2>Hmm... So do stay in that state all day/week? Or in/out all the time? <lfam>No, just when I need to use it <myglc2>lfam: OK, thanks, thats what I have been doing. But I was thinking it might be better to install (being impatient & hating to wait ;) <lfam>Yeah, it's just slow enough that it's sometimes annoying. But I'm a little constrained for disk space so by not putting those packages in my profile history, I can reclaim them with `guix gc` <myglc2>lfam: OK thanks. My thinking is that disks & such are a lot cheaper than my time (even, with how little it is worth ;) <lfam>Yeah, I should buy more storage <myglc2>lfam: but then again, it is always a bad idea to open up your computer ;) <myglc2>lfam: Do you think that if I look at "*Guix Package Info: guix-profile*" and install all the 'Inputs' that is all I need, or do I need 'Native inputs' too? <lfam>`guix environment guix` works by creating a new profile. So, you can run it, and then inspect the extra profile that is on your $PATH. <lfam>I think the list of packages is documented in the manual, though <myglc2>lfam: Very cool, I'll try the profile. The manual is really good, but I hate reading instructions and if I can get the computer to tell me I like that better. <myglc2>lfam: BTW do you know what happened to the '[ENV]'? I kinda liked that. <lfam>It still works for me on GuixSD <myglc2>lfam: I recently switched to Guix/Debian, maybe that explains it. <lfam>Yeah, I never had it on Debian, but I'm also not using Bash on Debian, so I don't think I would have seen it anyways <ajgrf>lfam: i have build output i want to send you to help you fix beets, but i think it's too big for the mailing or a paste service <lfam>Oh, I should have read more than the tail of hydra's logs. I figured the error would be at the end but I see it farther up <lfam>I'll try to reproduce on GuixSD <ajgrf>ok looks like my message went through to the mailing list now. not sure what the delay was, if not the attachment <lfam>ajgrf: I just replied to your mail. Can you try building with '#:parallel-tests? #f'? <lfam>Oh, actually, I don't think python-build-system has that <lfam>ajgrf: What filesystem is your $TMPDIR (where the daemon builds things) using? ext4, btrfs, something else? <lfam>Okay, I built successfully on that <lfam>It looks like their test suite has some sort of concurrent test thing. I should figure out how to disable that. <lfam>Else why would all the build logs fail amidst different lines? <lfam>Weird that the file is always 987 bytes <ajgrf>i see sequential methods right alongside the parallel ones, but i'm not a python guy so i don't can't tell where in the code the tests first start executing <lfam>I asked on their IRC channel. If nobody responds in a couple hours, I'll file a bug with them <lfam>I like how GNU Parallel does output: the output is delayed until the job is done, so that logs make some sense. <lfam>Huh, this is what my successful build log says: "test_nonexistent_file (test_library.FilesizeTest) ... could not get filesize: coercing to Unicode: need string or buffer, NoneType found" <ajgrf>weird. my build logs also have a bunch of other failed tests and error messages that were apparently not fatal either <lfam>Maybe this is one of those test suites that nobody pays attention to <ajgrf>looking at the nixos beets package now, they have lots of special build logic and patching that we don't <lfam>A lot of that is handling optional plugins that I didn't package <lfam>That 'preCheck' hook is worth a try <lfam>Oh, that's not a pre-check hook, it *is* the test <lfam>I'll try invoking the tests with something like that <davexunit>finally figured out why you can't C-c in 'guix environment' <davexunit>we've been using the 'system' syscall, and the man page for 'system' says that SIGINT is ignored. <jmarciano>yesterday, I have seen new guix behavior, it asked me to set PATH to: /var/guix/profiles/per-user/admin/guix-profile/bin and not like usually to: .guix-profile/bin, and X, or startx programs were installed in /var/guix.... and are not available in ~/.guix-profile/bin -- so something looks wrong <jmarciano>like: guix package -I | grep xorg, shows xorg-server as installed in my profile. But it is not in ~/.guix-profile/bin <jmarciano>just installed package evince, and is not installed in .guix-profile/bin <jmarciano>I have removed .guix-profile and by hand, linked: ln -s /var/guix/profiles/per-user/admin/guix-profile .guix-profile, now I have the programs. But something failed, I should not be doing it by hand. <jmarciano>which package to install to get cc c compiler? <jmarciano>cannot compile software, to test to include it in guix <jmarciano>I guess that process to include package in guix, involves first checking out if it compiles, and how. <rekado>jmarciano: do not install "gcc", install "gcc-toolchain" instead. <rekado>for that you should set "CC=gcc" if the build system checks CC. <rekado>jmarciano: about "per-user/admin/guix-profile": are you doing this as the user "admin"? <rekado>guix should create the symlink by itself. <jmarciano>I did not choose to have multiple .guix-profile-X-link(s), but I do have 3 of them. It seems not logical. <jmarciano>I hope that maybe later I bind guile to that one. But I cannot compile it <jmarciano>In Debian I can, but with the guix environment, I cannot <alezost>jmarciano: any error during comilation? <alezost>jmarciano: this is horrible: this project doesn't use a proper GNU Build System; instead it uses its own "./configure.sh" script which includes "./configure.inc" file which has this line for example: <ac_default_path="/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin"> I'm afraid this is just the beginning of problems. I think it may become really difficult to make a package for this program <rekado>jmarciano: the .guix-profile-X-link things are links to particular generations of the profile. <rekado>they are also generated automatically. <rekado>you can view generations with "guix package -l" <rekado>jmarciano: re gcc-toolchain: I actually suggest starting with a package expression, then try to build that, then upon failure enter a guix environment. <rekado>it's better than installing all dependencies into a profile. <mkoenig>hi. guix system init returns error: in procedure make_object_from_file: bad header on object file: .... <alezost>mkoenig: could you paste the whole backtrace and the system config you used <jmarciano>alezost: I will tell to programmer to simply change it <jmarciano>is it policy of Guix to get only such packages from original authors, or could be from forks? <ng0>try this and exchange gnurl with curl, and add a torify or whatever: <ng0>should work with tor <ng0>if you have never visited gnunet.org either and have some thoughts about confusing elements, text etc to share, send it to me. one of my goals is to change the website at some point. <jmarciano>curl: (60) server certificate verification failed. CAfile: none CRLfile: none <ng0>do you now have gnurl *and* curl in your profile? <ng0>oh, you try to read a file from pastebin <ng0>i thought you wanted to paste <ng0>that's my function for pasting to ptpb.pw <ng0>it's also documented if you open it in a browser <jmarciano>how indecent is the developers conflict, I read about curl <jmarciano>Somebody releases "free software" and then for others doing that for what it was released, call them stupid and shortsighted. <mkoenig>shall i paste it to another service? <ng0>no, gnurl does not depent on curl <jmarciano>aha, you asked me "do you have curl in path", and gnurl gives curl messages, so I wonder... <mkoenig>sorry, connection lost. did you say something? <alezost>mkoenig: you have a typo: "moint-point" <alezost>but it looks like you didn't come to the point where the bugs in your config are reported by "guix system ..." <alezost>the backtrace is weird. How do you install a system? Did you write an image to usb? <mkoenig>i've used dd to write the image to a flash drive <alezost>mkoenig: try to run "guix pull" before running "guix system ..." <mkoenig>trying gpt together with csm (uefi seems not to be supported yet) <alezost>jmarciano: I don't think there is a policy to not use forks, the original sources are probably preferable though. Anyway fork/original source would be discussed in the mailing list when a patch is sent <alezost>mkoenig: might be, no one have ever reported such a problem with the image <alezost>mkoenig: btw what image did you use? <alezost>ftp://alpha.gnu.org/gnu/guix/guixsd-usb-install-0.9.0.x86_64-linux.xz ? <alezost>I don't think so, we don't provide an iso <alezost>mkoenig: could you try to "dd" it to usb one more time and try again? <alezost>mkoenig: if you'll have the same problem, please send a message to bug-guix@gnu.org <alezost>don't forget to run "guix pull" before "guix system", otherwise your computer will compile many old versions of programs <rekado>sneek: later tell lfam The python-pyechonest package description says "open source". <rekado>sneek: botsnack for you, botsnack for me. <jmarciano>if I understand well, the GuixSD is encouraging developers to come to standards, like I see on discount markdown example. <jmarciano>it could be GNU standards, but also others, for packaging, and that packages can be included in per-user profiles <davexunit>hey #guix, I fixed that annoying bug where C-c didn't work in 'guix environment' <janneke>yeah, it may take a while to get `C-c C-z kill %1' out of my system again :-) <janneke>ACTION 's first @ build-succeeded /gnu/store/a813hl15qzgk1a0ia61bnxjr173izz8z-gcc-cross-sans-libc-i686-w64-mingw32-4.9.3.drv - <jlicht>janneke: that seems cool. What is it exactly that you built? <janneke>jlicht: first stage of a mingw32 cross compiler <davexunit>could someone running guix on a foreign distro try something for me? <davexunit>guix environment --container --network --ad-hoc hello -- hello <davexunit>the bug I'm trying to reproduce has been around for awhile <davexunit>on my Ubuntu machine at work, the above command fails <jlicht>I'm running elementary right now, based on Ubuntu 14.04, and I get status code 1 <davexunit>but ludo is dubious about why the patch works ;) <jlicht>Something about practice being when things work, but no one knows why ;) <fhmgufs>Hello, I'm finally installing GuixSD. But it fails because of Hydra ... :( <janneke>guix environment: error: cannot create container: unprivileged user cannot create user namespaces <janneke>guix environment: error: please set /proc/sys/kernel/unprivileged_userns_clone to "1" <davexunit>jlicht: if you were to 'strace -f' that command, you would see that there's EPERM error for /etc/resolve.conf or something <davexunit>janneke: that's a different error that we catch, as you can see. <davexunit>on ubuntu machines, it's a permission error for an unprivileged user to re-bind /etc/resolv.conf as read-only <davexunit>I don't understand this, but both jlicht and I can reproduce it <jlicht>davexunit: I get the /etc/resolv.conf as well, so it's probably the same issue you are experiencing <davexunit>my patch is simply just to not remount these files read-only. <davexunit>an unprivileged user can't write to them anyway <jmarciano>mkoenig: I am sure it works, I want to run it too, but due to foreign distro here, well.... <janneke>mkoenig: i tried & failed until now...hoping for mwitmer to come back <janneke>yeah, my desktop has been sh*t since i had to drop sawmill/sawfish <davexunit>I fixed a thing or two in guile-wm quite some time ago <kristofer>mkoenig: I've been trying to figure out how to get slim-service to recognize my ~/src/guile-wm so I can hack on it <janneke>i couldn't get it to run on ubuntu, it does start on guixsd <davexunit>I would connect to its REPL with Geiser in Emacs and live hack it to make it do what I wanted <davexunit>that was my blocker. if that could get fixed I think we'd be in good shape. <janneke>davexunit: yes, i didn't feel i had enough for a bug report yet <janneke>davexunit: you know where mwitmer is? <davexunit>he hasn't been involved in guile stuff for years <janneke>guix is a great reason to come back ;-) <janneke>not sure if putting effort in *-wm makes sense though, when wayland is coming <janneke>i heard wayland does not support window managers <kristofer>davexunit: my lack of experience here is really apparent. slim-service automagically finds potentential sessions in /usr/share/xsession - but that doesn't work in guix <davexunit>kristofer: our slim service finds things in the system profile's xsession directory <kristofer>janneke: guile-wm should work fine, just need to build guile-wayland in the likeness of guile-xcb afaik <kristofer>it's an xml specification, seems more tedious than it does difficult <davexunit>guile-xcb is implemented as a language on top of guile that reads the spec as source code and compiles it to Scheme <mkoenig>i'm getting "[drm] Failed to open DRM device for pci:....." with nouveau driver and gtx 980 ti <kristofer>how can I use autoconf as an input to guix environment guile-wm? to be clear, "aclocal-1.14 is missing on your system" <kristofer>so it might just be a version issue. the environment is using aclocal-1.15 <davexunit>kristofer: guix environment guile-wm --ad-hoc autoconf <kristofer>davexunit: thanks. that pulls in aclocal-1.15, I guess I need automake-1.14, but no version found <kristofer>I'm examining gnu/packages/guile-wm; I doesn't appear to specify the automake version or patch any configuration files to work with automake-1.15 <davexunit>kristofer: you don't need automake/autoconf to build guile-wm from a release tarball <davexunit>but you do need it to bootstrap the build system when you are building from a git checkout or something that doesn't have it <davexunit>doesn't have the configure script and makefile already generated, that is. <davexunit>this is standard practice for everything that uses the gnu build system <kristofer>aha! the configure script is included in the git clone. I need to autoreconf before configure <jlicht>what would be the proper procedure for packaging two modules, lets call them A and B, with A having a depency on module B, when the latest release of B has a problem which prevents it from being built, but the current git version of B (as of yesterday) has fixed this problem? <fhmgufs>Does the GuixSD installation image include utilities for wireless network access? <fhmgufs>I tried to make an image mounted at /mnt for installing it later, but Guix fails to install GRUB on it. <fhmgufs>Oh, there's s disk-iamge, too. Maybe I should use that. <fhmgufs>Is the image I get from 'guix system disk-image' the same as I would get using 'guix system init'? <fhmgufs>So how can I get an image for my hard disk to write it later? <fhmgufs>I mean make the image using my old operating system and write it to disk later. <rain1>I don't think guix hassupport for that <davexunit>you can create disk images using 'guix system disk-image' <janneke>/gnu/store/5y252qkblhpj639g3bnrc671mz8x920w-profile/bin/wine /gnu/store/hm06bl6lajz5zfy69dg1l9ylpsyr7pfy-hello-2.10/bin/hello.exe <fhmgufs>davexunit: And they would be the same later as using guix system init? <kristofer>you could hypothetically dd the resulting image to a hard disk assuming the system configuration works on the resulting machine.. a disk-image doesnt use the file-systems declaration though, so i dont think it would be bootable <davexunit>a disk image should use the file systems that you declare... <davexunit>I don't see how it could possibly work otherwise <davexunit>our installer image is defined using the same OS config interface as any other GuixSD system <fhmgufs>I'm back now and still need a solution for my problem: I can only connect to the internet using wireless a connection. Because of that I either need to create an image on my old operating system (it's the same computer) that can be dd'd later using a live system or be able to etablish a wireless connection using the installer. How can I do this or that? I'm not interested in breaking my system because it's the only one I've access to at the moment. <davexunit>fhmgufs: you can use 'guix archive --export' to export some working wireless tools <davexunit>and run 'guix archive --import' to import the archive <davexunit>and then try to use the tools directly from their store paths <mark_weaver>fhmgufs: from the installer, run "wpa_passphrase [SSID] [PASSPHRASE] > wpa_supplicant.conf" and then "wpa_supplicant -i [DEVICE] -c wpa_supplicant.conf -B" and "dhclient [DEVICE]" <fhmgufs>mark_weaver: So, these tools are part of the image? <mark_weaver>actually, the guix manual in our git repo has a section on this <davexunit>I thought there was a system already installed that needs some rescuing <fhmgufs>Great, so I'm going to install the system now. <fhmgufs>Great, so I'm going to install the system now. <paroneayea>I admit I feel quietly thrilled with the discussion of using Guile as a system to bootstrap other languages, if that's really a sane and feasible direction, and if it means more language implementations sitting on top of Guile <paroneayea>I'm not sure I feel it's likely to happen? but I really like the idea :) <jlicht>I just finished my first two packages for guix (yay). One was simply a dependency of the other, so should I send the two patches in one mail to guix-devel? Or is one thread per patch preferred? <paroneayea>jlicht: send two mails, see the [PATCH 1/6] type emails people send on list as reference <paroneayea>I haven't figured out how to get it to work with mu4e <davexunit>ACTION pushes some minor updates to SDL packages <jmd>paroneayea: I'm sure it'd be possible to write a C compiler in guile. <jmd>At least the front end. <mark_weaver>paroneayea: for purposes of my larger goal of minimizing our bootstrap, a C compiler on top of Guile is not quite sufficient, because a C compiler is needed to build Guile itself and several of its dependencies. rather, I'd like either a simple C compiler or maybe even just a C _evaluator_ written in something like portable R5RS scheme <paroneayea>davexunit: will my extremetuxracer be even more extreme with these new patches??? <mark_weaver>the idea being that perhaps later, we'd use a much simpler scheme implementation running on bare metal to bootstrap the GNU toolchain and then later Guile itself. <mark_weaver>however, this restriction would only be useful for languages needed to bootstrap Guile. <paroneayea>mark_weaver: so if we had that, *then* we could build all the other languages on top of guile? ;) <mark_weaver>for other things that we want to bootstrap like GHC, Rust, Go, or MIT/GNU Scheme, that are not needed to bootstrap Guile, I see no reason not to make use of full Guile for their implementations. <jlicht>I tried explaining this problem (bootstrapping binaries) to some researchers at my uni, but they did not really get the problem <mark_weaver>it's okay, there are enough people who *do* understand <jlicht>the general opinion here seems to be that having a bootstrapping compiler is actually a plus (here meaning, without a path to do it from e.g. C) <fhmgufs>Hm, my computer dan't find an operating system on the usb stick. <paroneayea>mark_weaver: maybe you can make it a GNU project, and it can have an appropriately GNU style bad pun <paroneayea>mark_weaver: GNU Cleric (CLEansing RItual for C) ***ee is now known as Guest20523
<mark_weaver>well, there are several independent projects here that would fit together. e.g. the C evaluator in a simple portable scheme is one project, the compilers built on top of Guile are other projects <jlicht>paroneayea: but what exactly would these Guile-based bootstrappers need to support? I assume you would not want to implement and maintain X full-featured compilers, where X++ for every new bootstrapping compiler added to the system <Digit>listening to library libreplanet talk again, mentioning the virtues and advantages of running tails in libraries, thinking it'd be nice to see a live secure tails-alike for libraries based on guixsd ***Guest20523 is now known as eek
<mark_weaver>and then the implementation of Scheme that runs on bare metal and can be bootstrapped from a tiny, easily auditable bit of machine code, is another project. ***eek is now known as eeq
<paroneayea>jlicht: I think mark_weaver just replied appropriately to your question ***Basstard1 is now known as Basstard`
<jlicht>maybe my confusion is not really confusion at all then, but just me being dizzy from how large of an effort this seems to be ;) <mark_weaver>my immediate concern is bootstrapping the GNU system itself without relying on a huge amount (too large to audit) amount of pre-existing binaries. <mark_weaver>jlicht: are you familiar with the "trusting trust" attack? <fhmgufs>Is it normal that the disk image is using ext4? Will my PC be able to boot from it? <mark_weaver>i.e. viruses that can exist only in the object code of the OS or assembler or compiler, which propagate themselves without existing in the source code at all? <fhmgufs>mark_weaver: So why could my BIOS fail to boot? <jlicht>mark_weaver: I am familiar with this concept. It still gives me shivers when thinking about it too long though <paroneayea>jlicht: well I have empathy with your feeling about just how large of an issue to engage it seems like <mark_weaver>well, our USB installer is a bit unusual, because it's a normal disk image (as one might find on a hard disk), instead of an ISO image, which is what is usually done. <paroneayea>however I trust mark_weaver's judgement about how something could be feasibly accomplished <paroneayea>and if we can get excuses for people to play more with the complier tower <mark_weaver>fhmgufs: if your BIOS can't boot the USB installer, the easiest solution would be to load it from an existing GRUB that you *are* able to run. <rekado>ran out of space again because I only use a fraction of my disk for the store. The rest is a big LVM partition. <jlicht>paroneayea: Of course! How usable is the documentation of the compiler tower for someone who does not have any significant experience with hacking on compilers? <rekado>can't just shrink that and resize the plain partition without moving the partition around. <rekado>so, what is needed to get LVM boot support? <rekado>re compilers: I'm working on porting Yale Haskell to Guile. But it's an interpreter only, not a compiler. <mark_weaver>fhmgufs: my knowledge on this is not fresh enough to be able to reliably tell you. I'd probably have to play around a bit. but I think the basic idea is to go to the GRUB command line by typing 'c' from the menu, and then "set root=(" and hit TAB to get a list of grub devices and pick the USB device, and then using the "configfile" command to load the grub.cfg on the USB drive. <paroneayea>jlicht: so, what I will say is that reading up on Guile's compiler tower was my entry way into an interest in compilers <paroneayea>the documentation is readable enough for someone who knows nothing of compilers, and you can get the idea of it even if you don't understand it <paroneayea>and from there I went on to read The Little Schemer (you build an interpreter in the end of the book) and then read and watched the Structure and Interpretation of Computer Programs lectures <mark_weaver>for the last few years I've run Libreboot, which includes GRUB and its own grub.cfg burned into the boot flash, and it contains an easy menu item to find other devices with grub.cfg and to load them, so my knowledge on doing it manually is a bit rusty. <paroneayea>I've also contributed to Hy a bit but only in the simplest ways, and that's only vaguely a compiler type thing <mark_weaver>(also, I haven't had to install GuixSD from scratch in a long time) <paroneayea>jlicht: I havne't really made any substantial compiler contributions but <paroneayea>I was able to understand enough to annotate bipt's elisp work with changelog style commits <paroneayea>jlicht: so if you're interested in exploring these directions, I can say that the compiler tower docs won't get you far enough along to do anything, but there's some paths towards discovering compiler things <paroneayea>which seem fairly in parallel with other Guile peoples' experiences <paroneayea>jlicht: not sure if useful or not. there you go though! <paroneayea>or maybe that all fell on deaf-disconnected ears anyway :) <mark_weaver>rekado: the scheme code that runs in the initramfs to boot guix, starting with loading the modules and mounting the root FS, is 'boot-system' in gnu/build/linux-boot.scm. also see 'mount-root-file-system' in there. I guess that's the code that would need to be modified to cope with the root partition being on LVM. <mark_weaver>also note that the root device is communicated to the initramfs by means of the --root kernel command line option, which is put in the grub.cfg. for an LVM device, I'm not sure what that string would be, or if it would be enough. more option(s) could be added for LVM-on-root systems, if necessary. <mark_weaver>note that the kernel apparently ignores command line options it doesn't understand, and our initramfs finds them using (linux-command-line) and 'find-long-option' in the 'boot-system' procedure. <rekado>mark_weaver: thank you for the hints! <mark_weaver>rekado: if you need to change how the grub.cfg is generated, search for "--root" in guix/scripts/system.scm and gnu/system.scm. Unfortunately there's some duplicated code there. <mark_weaver>(two copies of the code that generates the kernel command line) <mark_weaver>rekado: you might also want to take a look at Jookia's proposed patches to our grub handling code, so that you don't duplicate efforts or try to make incompatible changes. <eeq>Hi folks. Spectacularly failed at installing GuixSD on VirtualBox :-( <eeq>In this day and age, the inability to avoid re-downloading 800+MB of wrong dependencies is probably a bigger put-off than the wrong dependencies themselves. <fhmgufs>mark_weaver: I already booted into the installer. But now the problem is that my wifi device requires non-free firmware. <fhmgufs>I promise that I will replace it soon. :( <fhmgufs>Anyway, it says that non-free firmware loading is disabled. <efraim>I relized now I hardly move my laptop and I'm thinking of just using an old cellphone for wifi access <eeq>Maybe I am spoilt by a decade of Debian, but it can't be rocket-science for installers to figure out that what they want is already there! <efraim>linux-libre prevents the loading of non-free binary blobs, you'd have to use your own mainline kernel <mark_weaver>fhmgufs: sorry, I'm not interested in helping you do that, and to be honest I don't even know how do it easily. <jmarciano>it's better not to use non-free binary blobs <fhmgufs>mark_weaver: Sure, I'll do that, but for now I don't have one. :( <efraim>I found a usb wifi device in the $15 range from Amazon that should work, and some half-height mini-pcie wifi cards in the $15 range <mark_weaver>fhmgufs: can't you just use a wired ethernet connection for now? <efraim>will get to try them out in about a month <eeq>@efraim are you saying a cellphone can be used as a modem? <efraim>I'm saying if you use a cellphone and enable tethering you should be able to use the equivelant of usb0 for network access <eeq>I'd like that ... what usually happens is that the cellphone can either drink off WiFi or provide cell date over USB ... not both at the same time? <efraim>i physically tether with a usb cable <eeq>OK ... your data source is the cell n/w ... <efraim>it has the side benefit of keeping the phone charged :) <fhmgufs>Ok, I'm not able to do an ethernet connection. <eeq>Rank newbie here ... but are you on real H/W or a virtual machine like I was? <mark_weaver>fhmgufs: well, sorry, I don't have any other ideas to share. <eeq>May I rant about GuixSD installer? <efraim>please do, it'll help us improve it <eeq>I'm a Debian user since Potato, just wanted to try out GuixSD on a VM ... <eeq>I tried this on VirtualBox, which I know from limited experience to crash now & then <eeq>So, its like the machine went down on the GuixSD installer, but VirtualBox kept the state ... <mark_weaver>guix provides a command to build vm images for running within qemu. it's called "guix system vm" <eeq>Ah ... I missed that (not enough of RTFM, you could say) but ... <eeq>... wouldn't that require me to first install Guix as a package manager on my existing machine (the VirtualBox host)? <mark_weaver>yes, but it should be noted that Guix only modifies a few directories: /gnu, /var/guix, /var/log/guix <mark_weaver>and when you install packages, a ~/.guix-profile symlink is made, and "guix pull" makes a ~/.config/guix/latest symlink, and that's it. <jmd>I'm having problems starting the daemon. What is the correct way to do it these days? <eeq>OK. That sounds vaguely like what 0install does too. <mark_weaver>if you don't set environment variables to access those things from those non-standard locations, Guix is basically invisible to the host system. <mark_weaver>so, you needn't worry about it messing up your system or being difficult to remove cleanly. <eeq>I was more worried about my VirtualBox host system not being free software :-( <mark_weaver>jmd: it's described in the "Installation" chapter of the Guix manual. Within that chapter, see the "Setting Up the Daemon" and "Invoking guix-daemon" sections. <mark_weaver>eeq: it's true that VirtualBox has a freedom issue: its BIOS can only be compiled with a non-free compiler. <eeq>I was seeing about putting GuixSD on my main box, and trialing it the same way in a VM first (on my not-main laptop). <eeq>Yes, I saw that ... wanted to use qemu directly, but was scared off by how much manual work it meant. <eeq>I'm not queasy; if it is an approachable task, I'd try qemu. <eeq>Anyway, the GuixSD experience on VirtualBox does show it up against other installers ... <mark_weaver>eeq: if you want to try GuixSD in a VM, I would install Guix using the "binary install" method on your existing system, use it to run "guix pull" and then "guix system vm", which creates not only the image but a little shell script to launch qemu with the right arguments. <mark_weaver>eeq: out of curiosity, what problem(s) did you run into? <eeq>OK. I can do that on my main box, copy over the image & the script to my laptop & run qemu. <eeq>More observations ... <eeq>0) I had to manually type into zile in tty0, whatever I read in tty1. That terminal mouse daemon (gpm) working in the installer would help. <eeq>1) I copied the typical desktop configuration, replacing "xfce ratpoison" with "enlightenment"; before VirtualBox crashed on the installer, it had downloaded ... 830MB of packages! Glaring things were stuff like httpd & WIndowMaker being downloaded! <eeq>2) Of course, the downloaded stuff was there in /mnt/tmp/guix-*/ ... when I re-ran the installer, it started download WindowMaker again! <eeq>That's where I have given up for now ... <mark_weaver>eeq: regarding (0), that change has already been made in our git repo, and will be in the 0.9.1 installer. <eeq>As an aside ... how do you guys maintain motivation to get all this done & talk about it too? <mark_weaver>regarding (1), windowmaker is a hardcoded dependency of our default 'slim-service' configuration. that should probably be fixed at some point. <eeq>I have been using Free Software as much as possible for 15 years ... I'm a software developer, and haven't yet contributed in any real sense so far (beyond evangelizing FS to people I know, maybe 1 or 2 converts) <eeq>OK. slim had that as per my recall too. <eeq>I can take a peek (I am not sexp shy!) <mark_weaver>the only package I see that depends on httpd is libsoup, but I gues that should only be needed at compile time, maybe to test it. <mark_weaver>one issue that's biting current installs is that I suspect the binary substitutes for 0.9.0 have been garbage collected, and so you may end up needing to build a lot of stuff from source, which is a serious problem indeed. <mark_weaver>I think we failed to arrange for that not to happen, and in the past our releases were frequent enough that it didn't come up. <eeq>I didn't see source builds happening (are you saying hydra.gnu.org is building them on the fly)? <mark_weaver>if it wasn't going to build libsoup from source code, then I'm not sure why httpd got pulled in. <eeq>OK. Guix is downloadinfg sources, it needed compile-time dependencies too, which would be bloat if binaries were available. <davexunit>run 'guix pull' before proceeding with the install <mark_weaver>yeah, davexunit's suggestion is a good one, I think. <mark_weaver>it may help work around the lack of 0.9.0 binary substitutes. <mark_weaver>I think maybe we didn't put that in the manual because it might result in more builds from source code if our build farm was behind in its work, etc. <eeq>davexunit: Would guix pull work before 'guix system init' <eeq>OK. So the installer has just enough of the package manager itself initialized ... <eeq>[ reading up on 'guix pull' right now ] <mark_weaver>"guix pull" will probably need to download and build some things, so be patient, but I guess it will still be better than trying to install an old 0.9.0 version of the entire system. <mark_weaver>eeq: make sure to start the cow-service before "guix pull" <mark_weaver>eeq: the guix installer is a real GuixSD system, although quite minimal and running fully in a ramdisk. <eeq>OK. Got it ... 'guix pull' is 'apt-get dist-upgrade' for the package manager. <Acou_Bass>guix pull is 'apt-get update' and 'guix system reconfigure' is dist-upgrade... right? XD <mark_weaver>but it doesn't just download data, it compiles a new version of guix from the master git repo. <mark_weaver>and that in turn means it also needs the build dependencies for guix. <mark_weaver>which are newer than the ones used in the 0.9.0 guix on the USB disk, hence the expected package downloading and building by "guix pull" <mark_weaver>Acou_Bass: right, or at least those are the closest analogues <eeq>I realize the project is by GNU & Scheme hackers ... but wasn't Lua also a choice? <eeq>sexps are not for everybody. <Acou_Bass>i think guile was long ago decided as the extension language for the GNU project hehe <mark_weaver>eeq: well, we are scheme hackers here, but aside from our personal preferences, code-as-data is a big win for something like Guix. <davexunit>yes, code-as-data is a pretty crucial for our system. <cehteh>that'll work in some other programming languages as well <Acou_Bass>i personally dont like lua very much... its fairly easy to pick up as a guy whos never done any real programming (ie. me) but scheme isnt bad either <mark_weaver>our package objects generate code that will be run within the build containers <cehteh>lua is basically a scheme .. just with a more common syntax <eeq>The OCaml people claim syntax pre-processors are pretty powerful (I know a little about Lisp macros, even less about Camlp4 or its successor) <mark_weaver>and that means that being able to generate scheme code easily from within scheme is important. <cehteh>isnt my idea a lot people called it so <eeq>If sexps don't put one off (didn't put me off), Lisp syntax is pretty much a pleasure ... <mark_weaver>anyway, that ship has obviously already sailed... :) <mark_weaver>but fwiw, I still think Scheme was the right choice for this project. <eeq>Would native compilation in Guile help GuixSD any more than execution speed? <eeq>I ran it in a VM; I'd be more pleased ;-) <eeq>The linux-libre requirement ... isn't it a bit harsh? <mark_weaver>I run it on a Lemote Yeeloong 8101B, so I might be even more pleased than you, actually. <eeq>ah .. real MIPS instead of bogomips. <Acou_Bass>eeq: considering its a free software distro, no i dont think its harsh at all xD if you want proprietary garbage then a fully free distro isnt really for you <eeq>I try to run as free a system I can (non-free is disabled in my Debian install). <mark_weaver>we are aware that some people don't like that, but this is an ethical stand that we make. <Acou_Bass>isnt guixSD created by the gnu foundation? or is it the FSF, i forget <eeq>But basic stuff may not work! I don't mean "peripheral" concerns like wifi ... my AMD fusion chip's graphics won't be of any use without proprietary firmware. <jlicht>eeq: AMD is the one who can fix that issue in an ethical way ;) <Acou_Bass>bingo - GNU project = no proprietary blobs - freedom over everything else :P <eeq>Well, until AMD does (not holding me breath) ... what am I to do? <mark_weaver>eeq: you can fix that by using a computer that can function without nonfree software being included in your OS. <Acou_Bass>there are free AMD drivers... in fact AMD's latest drivers have an open source component (though i dont know if it is 100% ree) <eeq>Well, I can run VESA drivers, but how do I drive my TV with it? <eeq>Acou_Bass: I use the Xorg free driver (not the AMD binary one) ... it needs firmware to run. <Acou_Bass>doesnt the xorg ATI free driver work for that? it used to for me when i had an AMD card.. <mark_weaver>eeq: the only way this situation is going to improve is if people consider freedom in their purchasing decisions. <eeq>Earlier AMD cards didn't need firmware ... new ones do <eeq>I did; what are my options? even today ... <mark_weaver>and the only way that's going to happen is if OSes don't "just work" on hardware that doesn't respect our freedoms <mark_weaver>eeq: I can heartily recommend the Libreboot X200 laptop. <Acou_Bass>i would hope that the ATI free drivers figure out a way to reverse-engineer said firmware <eeq>Well, laptops ... more choice nowadays (even ignoring the fact that I don't live in the US of A). <Acou_Bass>my cheap crappy laptop runs guix absolutely perfectly, and i didnt even purchase it with free software in mind <eeq>My requirement was not to let proprietary software in my home any more that it already has ... <jlicht>eeq: I know it sucks, I was in your situation as well (becoming interested in GNU/linux after getting my previous laptop) :/ <mark_weaver>eeq: for wifi, atheros produces some devices that work with free software. <Acou_Bass>some hardware will just work, even if its not necessarily 100% free like a yeolong, it might still work with a libre distro <mark_weaver>eeq: for graphics, the choices are: intel graphics, or some nvidia cards work well with nouveau. <eeq>... so I didn't want a smart TV ... I have a simple dumb panel, and a mini-ITX board running Debian driving it <eeq>intel graphics are a little weak to be an entertainment PC, but it'd have been a worthwhile trade-off <Acou_Bass>intel graphics are plenty powerful enough as a media centre.. if i can run mine off a raspberry pi im sure an x86/intel could do the job just fine.. <eeq>Availability & price are a factor ... not too many small form-factor boards going around <mark_weaver>having said all this, Guix is about the most easily hackable distro there is, so you can do your own thing if you really want. <eeq>Believe me, I don't want to be running firmware on an otherwise free software syste <mark_weaver>I run Guix directly out of a git checkout, on my own private branch, which almost always includes patches that aren't yet pushed upstream. <eeq>I have punted on a Wifi dongle until I can find one with libre drivers, for that very reason <mark_weaver>and I periodically use "git rebase" to rebase my branch onto the upstream master. <mark_weaver>(or you could merge upstream into your branch if you prefer) <Acou_Bass>like i said earlier - even if you choose to run a libre OS like guix, with linux-libre kernel... SOME hardware will still take to it fairly well <Acou_Bass>linux-libre doesnt necessarily suggest that you need a 100% free bios and microcode and everything <mark_weaver>eeq: in Guix, we actually build the firmware that runs on those dongles from source code! <eeq>Like I said, I'm not in the US of A ... I am not sure those are available to me <eeq>yep, I get that options exist <mark_weaver>eeq: regarding "I am not sure those are available to me", do you think it's worth asking before assuming they are not? <Acou_Bass>quite a lot of laptops come with intel or atheros wifi chips which run fine with linux-libre <Acou_Bass>it snot necessarily something you have to specifically shop for <Acou_Bass>obviously its something you have to look out for, but its not like there are 500 laptops running proprietary chips then one running a free one... probably half of the ones on the shelf in your local best buy will work <eeq>I live in India ... there is a store in north-western India that does stock assorted libre H/W, but nothing as powerful as a mainstream PC board. <Acou_Bass>i live in the UK and have not yet come aross any computer that cant run off linux-libre <Acou_Bass>obviously some of them dont run quite as well as they would with eg. a proprietary gfx driver, but they boot and they work <eeq>Since it is a board driving my TV, I'd want the graphics to work as well as they could ... GFX and wireless (WiFi/cell radios) seem to be the least free. <eeq>OK. If the H/W goes kaput, I'd have a tough time, eh? <Acou_Bass>why do you think intel gfx wont push media well enough? what sort of media are you pushing? <eeq>Hey, nothing demanding at all ... maybe 720p if that. <Acou_Bass>the newer intel intergrated gfx can even source games at good FPS, let alone movies <eeq>this is just my TV made "smart" and "as free as feasible" <mark_weaver>eeq: if the H/W goes kaput, then you'd have a tough time, but I'm not sure how that relates to whether the hardware respects your freedoms or not. <mark_weaver>eeq: it seems to me that you are searching for excuses <mark_weaver>I've used a Libreboot X200 running GuixSD to watch 1080p videos on a large TV, and it works great. <eeq>It'd relate to feasibility ... I'm not searching for excuses ... I ran Debian for a decade on an Athlon CPU + ATI card that had free drivers, no issue <Acou_Bass>i wouldnt say searching for excuses - just thinking its a lot harder than it is hehe <Acou_Bass>i mean, yeah going free from he very bottom like on those lemotes is difficult - but just booting a libre distro like guixSD is far from insurmountable <eeq>Today, given how much CPU I'd need to, say compile C++11 code or run JS-heavy sites or run lots of Scheme code, I'd look for something beefier ... has ended up at AMD Fusion. <eeq>mark_weaver: You hook up your laptop to your TV? <eeq>I guess I was hung up on the form factor; I wanted a neat little beefy board. <Acou_Bass>what about those intel NUC's? can you run libre on those? (ive never tried) <Acou_Bass>but there are loads of them, surely one of them must work XD <mark_weaver>eeq: anyway, I'm suggesting machines that can run a free initialization program as well, but that's not required to run GuixSD. <eeq>This mini-ITX board is maybe 20-30% less expensive ... those NUCs are less powerful. <eeq>Free BIOS ... less hope there. My Athlon PC probably didn't have a free bios. <mark_weaver>eeq: to run GuixSD will accelerated graphics, it is sufficient to purchase a machine with Intel graphics (or an Nvidia GPU that is known to work well with Nouveau). <mark_weaver>and the Wifi issue can be addressed by getting a USB dongle if needed. <eeq>WiFi, I am not concerned about (I work off cell data on a phone tethered to the board) <eeq>Let's not go into whether the phone is free S/W <eeq>The router isn't free S/W (no hardware specs, it has enough juice to be able to run libreCMC but I can't). <Acou_Bass>i dont think there ARE any fully free phones are there? even ones that can run replicant/moko have blobs especially for baseband <mark_weaver>it's okay, I'm not trying to purify you. the immediate issue is getting GuixSD working for you. <eeq>I tried the Jolla phone (Sailfish OS) ... <Acou_Bass>i run sailfishOS on my phone (though its not a jolla) it is a REALLY nice OS... but quite a lot of it is blobified still hehe <mark_weaver>it's not like it's hard to find GPUs that work well with free OSes. <eeq>if you ignore the proprietary UI they layer on top ... and the networking & GFX drivers below ... its a pretty free <Acou_Bass>so... basically everything except the linuxey bit in the middle <eeq>yeah ... just that my investment in this board is down the drain, unless I can use it headless for some other purpose. <eeq>Acou_Bass: Yes, but it doesn't feel alien to Linux-ers like Android does ... <mark_weaver>maybe you could sell it to someone who is hopelessly committed to running non-free software anyway, e.g. a Windows user. <eeq>I'd rather run VESA graphics on it (use its PC output rather than HDMI). <mark_weaver>i.e. someone who is no where near close to considering running a fully free OS, and thus won't be thwarted but the AMD GPU. <Acou_Bass>eeq: if you like sailfish, you shouldve tried a nokia n900... it was just debian underneath xD (sailfish was based on the OS from the n900 but has since gone thorugh lots of changes) <eeq>I'd rather run it like a PC (and forget about the entertainment PC part). <eeq>n900 ... I missed it by about a year. I worked with a guy who worked for Nokia ... he was very happy with the test piece he got to use when working at Nokia <Acou_Bass>sailfish is the successor but yeah its nowhere near the same... though i think a lot of that is because of the wayland layer that doesnt have the xwayland compatability <Acou_Bass>n900 ran gtk apps and everything so really was just like a mini PC <eeq>If I haven't taken up too much o' your mental bandwidth already ... <eeq>... how does Guix try to provide packages? Only upstream packages, or Debian-like modifications to almost everything? <eeq>I liked the 0install ability ... to be able to just point to upstream + instructions to build. <eeq>And how does hydra.gnu.org work? Can I volunteer my H/W over the network? I have this board with proprietary graphics which I am about to behead to make headless ... <eeq>Thanks for your time, Guile hacker! <Digit>ACTION ponders a lispfest system, using guix, emacs, and clfswm <rekado>bleh, no space left to hack on guix :( <mark_weaver>rekado: regarding root-on-LVM support, it occurs to me that our GRUB configuration might also need some tweaking, since the kernels and initrds are in /gnu/store and must be loaded by GRUB. <mark_weaver>I know that GRUB has LVM support, but maybe some other commands need to be run first, dunno. <mark_weaver>efraim: yes, just look in guix/licenses.scm and it's in the export list <efraim>ok, I hadn't seen it before, and nix labeled boinc lgpl2+ <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, rekado says: The python-pyechonest package description says "open source". <lfam>Digit: See `guix system vm` as a starting point for a locked-down reproducible operating system. It gives you a QEMU image with an immutable file system. You could mount stateful directories in RAM and reboot for each library guest. <lfam>You'd need to find some way to feed entropy to the system, however. Currently one must play the piano for a while to make it boot <lfam>We need to promote the `guix system` QEMU tools more <lfam>So many people are coming to IRC with problems in VirtualBox, even though we have a working virtualization system *built in* <lfam>It's a bad first impression <kristofer>virtualbox doesn't require command-line proficiency <rekado>oh, that was a comment to some message way back... <lfam>kristofer: True, but `guix system vm` is about as simple as it gets right now. <lfam>It could be easier to do `guix system vm-image` <lfam>rekado: Regarding disk space: could you set up a nearby caching mirror? That made it much less painful for me to do `guix gc` <jmd>kristofer: Perhaps not. Instead it requires proficiency in black magic. <rekado>lfam: I just deleted 20 past system profiles and gc'd. Should be okay for a few more weeks :) <lfam>Yesterday I had to build texlive-texmf for something, so I built it, stopped, made it a gcroot, gc-ed its tarball, and then kept going ;P <lfam>Time to dust off the LVM guide <kristofer>so I'm kind of struggling here. I can build guile-wm in a guix environment, but since slim-service isn't "inside" the environment, it can't find the necessary modules to load up the window manager <kyleschmidt>I'm running the binary installation on linux mint. Can anyone recall how long this step took: `~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild` <lfam>kyleschmidt: That's a daemon, it never returns <kristofer>it's a daemon, so that command will never terminate.. <lfam>You should run it with your service manager <lfam>I believe we ship a systemd service file if that's your thing <lfam>If you keep that daemon running and open another terminal and do something like `guix build hello`, you can see the daemon working <kristofer>kyleschmidt: temporarily, you could Ctrl-z, and then # bg 1 to put the process in the background <kyleschmidt>:) thanks. @ifam you recommend I drop ~root/.guix-profile/lib/systemd/system/guix-daemon.service in /etc/systemd/system ? <lfam>kyleschmidt: Exactly! Read it first, of course :) <str1ngs>I have a script that boot straps if you want it <str1ngs>anyways you dont need gccgo to boot strap the reference compiler <rain1>I just had a very specific way i wanted it done <rain1>people have been talking about trust chains an bootstrapping a compile off series of earlier versions <rain1>so I wanted to test that out <kyleschmidt>guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub <str1ngs>all you need is gcc though. you dont need gccgo <str1ngs>before you try to install and substitutes ***Basstard1 is now known as Basstard`