<NiAsterisk>from barebones? hm. not sure how to get there (yet), but something with startx and whatever desktop/window manager is available <calher|leela>I used barebones because that's what the guide said. It said I could do desktop later. <NiAsterisk>I started with a different setup and I am now working towards some custom configs <bavier>calher|leela: once you have an initial bare-bones installation, it's fairly safe to start adjusting your os configuration, e.g. incorporating aspects from the example desktop config in the manual <calher|leela>bavier: Do I have to reboot to apply the new config.scm? <bavier>calher|leela: yes, you should reboot <bavier>calher|leela: after `guix system reconfigure ...` that is <calher|leela>bavier: What if servers ran GuixSD? This would be bad news. <bavier>there's work being done to restart affected services after `guix system reconfigure`, but in the meantime restarting is a good idea <CompanionCube>I imagine restarting services and stuff is harder because of the different model and because of the fact that anything could've changed? <myglc2>calher|leela: I think they were in /etc/configuration during the install and prior to reboot, but then they dissappear, if you don't copy them to /mnt/etc/, which is what I did and why I ahve a copy on my HD. There is probably a more intelligent approach. <CompanionCube>every package contains a self-referential arrow which makes it look weird and adds no real information <myglc2>I spiffed up my bare-bones config and successfully did 'guix system build /etc/config.scm'. Is there a way to install and run what I built? Or do I have to do 'reconfigure' now? <GChriss> I made the mistake of specifying "America/New York" instead of "America/New_York" in config.scm during install <CompanionCube>zsh doesn't seem to pick up stuff in my guix profile's bin dir after setting the env var <Jookia>I'm reconsidering the idea of using btrfs now given all the tests that fail from it <Jookia>Ah, you should try btrfs some time <CompanionCube>using guix on top of arch, no obvious issues that I've noticed <Jookia>CompanionCube: I've been trying to compile Guix using Guix and unfortunately I'm having issues bootstrapping :( <CompanionCube>I recall 'guix pull' failing earlier now that you mention that <CompanionCube>and only then because my OEM used too much of the grub embedding area <Jookia>It may be that you're using succesfully built + checked binaries <Jookia>Unless you built it all yourself <Jookia>The Glorious Glasg(l?)ow Haskell Compiler <CompanionCube>ACTION is going to see how haskell packaging works with guix vs arch <Jookia>Eww Lisp, Haskell all the things. ;) <Jookia>I wish there was a good Lisp with some notion of static typing, even in the sense of a preprocessor <Jookia>I much enjoy the idea of my program being looked at compile time to look for obvious bugs <Jookia>Clojure is GPL-incompatible from what I know <myglc2>earlier I asked... I spiffed up my bare-bones config and successfully did 'guix system <myglc2>calher|leela: I thought maybe, but it turns out that doing 'guix system reconfigure /etc/config.scm' after the build just finds the build and installs it... in about 10 secs. WOW! <CompanionCube>so, how far exactly is the progress on reboot-less reconfiguration? <myglc2>FWIW, running guixSD, I just observed this: while in emacs, I added a big bunch of stuff to config.scm, opened a shell buffer and did 'guix system build /etc/config.scm' to check the build. Once that worked I did 'guix system reconfigure /etc/config.scm' which installed the stuf just built, no reboot required. Nice! <myglc2>These were all packages, not services, so maybe not so supprising <Jookia>Bootstrapping Guix is incredibly difficult <calher>Can someone link me to a copy of desktop.scm? <Jookia>Shouldn't it be in your Guix install? <calher>Jookia: It's in the installer, though. <Jookia>calher: It's in my copy of Guix- gnu/services/desktop.scm <Jookia>calher: $(dirname $(realpath $(which guix)))/../share/guile/site/2.0/gnu/services/desktop.scm <calher>Where is gnu/?! Nobody has told me. <Jookia>It's also in the root of the Guix repo <calher>How do I use SSH? There is no ssh or openssh package. <mark_weaver>Jookia: what do you mean? I've bootstrapped 2 out of our 4 architectures (mips64el and armhf), and I found it to be the easiest bootstrapping experience I could imagine. <Jookia>mark_weaver: I might not have much time left but I keep getting errors in tests involving sparse files, and glib's gapplication crashing the tests- At the moment I'm pinning it down to old kernel versions + Btrfs <Jookia>mark_weaver: Basically building Guix + guix package -i guix <Jookia>mark_weaver: So I'm now trying with a newer kernel and ext4. Should be noted I was running tests on a btrfs partition <Jookia>mark_weaver: If I still have troubles most likely I'll post to the mailing list about my experiences since the breakage is reproducible consistently <calher|leela>It would be satisfying to do guix package -i sicp && info sicp <mark_weaver>Jookia: those test issues should be reported to the upstream packages. <Jookia>mark_weaver: They should, but I wouldn't know where to start between glib, tar and coreutils <mark_weaver>test suites that fail intermittently, or on older kernel versions, or on kernels with different configurations, or different filesystems, are unfortunately a very common problem we've found. <mark_weaver>there are some kernel features that are needed for the test suites of some core packages when run within the build container. <mark_weaver>I think CONFIG_DEVPTS_MULTIPLE_INSTANCES=y is one of the things you need <mark_weaver>also, in general, if a test suite fails, retry the build. sometimes the failures are just intermittent. <Jookia>If the tests fail this time I'll try bumping the packages and then if that still fails I'll bug report upstream and disable the test <mark_weaver>I still consider those to be bugs, but it's useful to know if they are intermittent or consistent. <CompanionCube>ACTION was lazy and didn't run make check for his initial install <Jookia>mark_weaver: Was Trisquel, now using siduction <mark_weaver>Jookia: does your kernel have CONFIG_DEVPTS_MULTIPLE_INSTANCES=y set? <Jookia>calher|leela: Debian sid live CD <mark_weaver>that message mentions Python 3, but iirc other packages need working ptys within the build container as well <Jookia>mark_weaver: FWIW I'm not using build containers yet <Jookia>Either way I chmod'd it to 0666 for when I do <mark_weaver>Jookia: all builds in guix are done within build containers <mark_weaver>even if you don't use guix environment's container functionality. <Jookia>Ah, chroots if you don't have - Yeah <Jookia>Let's see how this all works out. :) <mark_weaver>if you show me some of the errors you're getting, it may trigger some recognition. I remember going through problems like this. <mark_weaver>e.g. on coreutils on my armhf and mips64el bootstrapping efforts <Jookia>Here's hoping all the errors disappear now that I'm using ext4 and a newer kernel and that devpts chmod :) <Jookia>I *do* have /tmp set to an ext4 filesystem though, rather than tmpfs which may be influencing the results with tests for filesystem-dependent stuff <mark_weaver>but if you were running builds without /dev/pts/ptmx world-writable, that's the most likely issue. <mark_weaver>(assuming you didn't set TMPDIR to something else in guix-daemon's environment) <Jookia>I have 'TMPDIR="/mnt/scratch/tmp"', so I do <mark_weaver>okay, then the filesystem of /mnt/scratch/tmp is where the builds are done. <mark_weaver>you should see 'guix-build-*' directories in there during the builds. <mark_weaver>we typically do builds on ext4 filesystems. tmpfs is not large enough for many of our packages. <mark_weaver>Jookia: it would be great if you could challenge hydra on the builds you're doing, to check for non-deterministic builds. <mark_weaver>(at some point, after you work through these problems) <Jookia>mark_weaver: Previously when I built coreutils the build was in fact non-deterministic, same with Guile I think. It was quite odd, and switching distros also changed the derivation hash (not just the files) <mark_weaver>we intend to address that, but it turns out to be non-trivial. <mark_weaver>but the coreutils non-determinism is definitely worth looking into. <Jookia>mark_weaver: If it happens again I'll see what I can do, it surprised me too <calher|leela>export PATH="/home/cal/.guix-profile/bin:/home/cal/.guix-profile/sbin" was recently added to my bashrc because it said to do it when I installed openssh <mark_weaver>calher|leela: on a GuixSD system, you don't have to do that manually. the problem is, you've removed the system-wide paths /run/current-system/profile/bin (and sbin) from your PATH, and that's where coreutils is normally included <Jookia>mark_weaver: Maybe that notice needs to be removed on GuixSD? hmm <mark_weaver>calher|leela: also, environment settings should go in .bash_profile, not .bashrc, because otherwise "guix environment" won't work as advertised. <mark_weaver>.bashrc is loaded by *every* interactive shell, whereas .bash_profile is only loaded by login shells. <mark_weaver>guix environment sets PATH and other environment variables and then spawns an interactive shell, and if .bashrc overwrites those variables then it doesn't work. <calher|leela>Do I need export PATH="/home/cal/.guix-profile/bin:/home/cal/.guix-profile/sbin" at all? <mark_weaver>the default dot files on GuixSD arrange, on login, to set the variables you need for the packages you have installed at login time. <calher|leela>What about the export GUILE_LOAD_COMPILED_PATH="/home/cal/.guix-profile/lib/guile/2.0/ccache" when I got Guile? <mark_weaver>hopefully you haven't blown away the bits that arrange for that. <calher>How do I poweroff? poweroff is not a command. <CompanionCube>ACTION wonders if it'd be better to try to continue to add guix packages to his arch <calher>How do I properly shut down in a bare-bones? <Jookia>I suppose limited internet connection or time <lfam>calher: on Guix poweroff is called "halt" <Jookia>If we all use GuixSD, who'll test Guix on Arch? ;) <Jookia>lfam: Ooh, we're back to those now? :D <lfam>We have an open fundraiser to replace hydra with a more powerful machine with faster hosting. We have raised enough to achieve that goal but I believe that donations will still be accepted :) <CompanionCube>It will of interest to see how haskell / python / ruby packages work and are used <lfam>It's also possible to do something like `for package in $(guix package -A); do; guix build $package; done` on a home server and then use `guix publish` to provide substitutes for yourself. At least one Guix user has done this (and also shared the "publisher" with us for a while). <lfam>It's not trivial computationally but it is possible and possible to automate <Jookia>CompanionCube: It is fascinating <Jookia>lfam: I plan to just provide substitutes for whatever I compile at home because self-sufficiency! <lfam>Jookia: Indeed, it is really easy to publish whatever substitutes a given machine has in its store. And if you `guix pull` regularly, it will serve as a local cache of the lower level packages that every machine needs to download when there is an update (bash, gcc, glibc, guile, etc) <efraim>if we can get substitutes over tor then it should be trivial to share from laptops even <lfam>If I build multiple rounds of a package to check the determinism of the build process, and it fails, what is a good approach for comparing the differences? It seems that "--keep-failed" does not preserve the "good builds", only the final build that demonstrates the non-determinism. <lfam>Right, the "good" build is, of course, in the store. <kristofer>I'm installing guixsd here! is it better to guix system init --no-substitutes? <Jookia>If you want to compile everything, yes. Otherwise no. gtg <kristofer>when I tried last night I had an error building cmake <lfam>kristofer: What was the error? <kristofer>I'm not sure now.. that's why I'm asking if it's better to use --no-substitutes. <lfam>If you choose not to use substitutes, you will have to build *everything* from source. This may take a long time. <lfam>Before you did `guix system init`, did you `guix pull`? <lfam>Did you install with the USB installer image/ <lfam>Okay, that image has package definitions from the 0.9.0 release in November. It's possible that the substitute servers no longer have some of the substitutes from then. `guix pull` is analogous to `apt-get update` and will update your package definitions to the current version. It's a good idea to do it before you initialize a new system. I don't know if this is related to your error or not. <efraim>"They" ran the garbage-collector on hydra yesterday before merging core-updates, so its likely the 0.9.0 substitutes were scrubbed <lfam>Normally you would not need to build cmake. However, even if substitutes are no longer available, Guix will transparently build the software from source. Although that could result in errors if some upstream software project moved their old source code. <efraim>we had this issue with the 0.8.3 substitutes also, but I don't remember if they instituted anything to prevent it from happening <lfam>I guess it won't be necessary to garbage collect the previous release when we have more storage for the substitutes servers <lfam>Once we have the hardware it would be good to keep the substitutes for the GuixSD USB installer and the binary Guix installer until the next version is released and built.. <lfam>kristofer: Also note that the Guix in 0.9.0 has a much slower `guix pull` than currently. So the next time will be faster ;) <efraim>I thought it uses the new code to compile the source when you pull <lfam>I actually don't know exactly how it works! There is also the question of `guix package -u guix` <kristofer>should I guix pull before I run 'deco start cow-store /mnt <lfam>I don't think it will have an effect on that step <kristofer>after guix pull should I restart the guix-daemon or anything? <lfam>No, that's not necessary. `guix pull` is per-user while unprivileged users usually can't do things like restart the daemon <kristofer>is there a place where system configurations are shared? <lfam>There are some simple examples in the manual <lfam>I have to go, good luck! <kristofer>is using --fallback ideal when the substitute server is slow? <rekado>kristofer: only if you want to build things on your own. <rekado>I don't recommend it, unless you have a small package that you know you can build in less time than it would take to wait for the substitute server. ***tschwing_ is now known as tschwinge
<divansantana>Guix looks really awesome. Would like to try it out. Though, as the docs state, it's missing many packages. virt-manager would be nice, to allow for easy running on VMs on there. Hopefully that's coming soon. <Jookia>divansantana: Packaging isn't that hard, you could try it yourself! <divansantana>Jookia: I should. Maybe could contribute it. Hopefully in the near future I can try. libvirt etc. Do I need to know guile or scheme? <Jookia>divansantana: A little bit, but you can probably pick it up just by looking at other packages <Jookia>divansantana: For an example, run 'guix edit <packagename>' to see what they look like <divansantana>Jookia: will do when compiling is finished. Or I have GuixSD installed. <NiAsterisk>hi! I've just read old issues I posted on github, seems like the bitmessage (the developer prerelease fork or whatever, works like the older version) developer now will work at some point on a setup.py, so I think why work on pybitmessage when I can just wait until they drop the setup.py themselves into their git <NiAsterisk>an offtopic question.. how's public transporation on saturdays in brussel? I don't know if collecting all the possible busschedules right now is too verbose.. I almost *guess* that it's easy to get to bruxelles-nord from ULB, it's a big city <davexunit>rebased a development branch of mine on master <NiAsterisk>I think I figured brussel bus schedules out, I won't get stuck there. if I do, I blame the internet. <kristofer>this GPT partition label contains no bios boot partition; embedding won't be possible <kristofer>guix system: error: failed to install GRUB on device '/dev/sda' <mark_weaver>kristofer: when using GPT, you need a bios boot partition. I don't have time to explain the details, but they can be found easily enough on the web. if you don't want to deal with this, just use MBR <myglc2>running ~ bare-bones.scm I don't have 'ssh', how do I enable it? <davexunit>we mean it when we say bare-bones. it's a config for you to add to, not use as-is. <myglc2>Ok, so I looked at that again, but don't see how to turn ssh on <myglc2>sshd is working but I can't ssh out <davexunit>do you want to use the ssh server or client? <davexunit>if you want the client, simply install 'openssh' or 'lsh' to your profile. <myglc2>So (packages (cons* openssh ...)) right? <alezost>civodul: did you plan to add the code from (guix records) to Guile? define-record-type* is so much better than define-record-type, I think it would be great to have it in Guile <civodul>some of the features are a bit baroque for mainstream though <civodul>alezost: BTW could you push the shepherd things in Guix if you haven't? <civodul>i wanna make sure that if i make a demo tomorrow, i can use 'herd' :-) <civodul>alezost: no, simply replace "/dmd/" with "/shepherd/" in both places <civodul>but yeah, just do this mechanical replacement in both places and everything will be fine <alezost>hm, ok, I hope it will not break the world :-) <civodul>this file is only used in these two places <alezost>I'll squash these 2 patches in a single commit as you told <davexunit>civodul, alezost: I wrote a much more minimal define-record-type* that introduces less syntax, but still allows for default values and inheritance <alezost>davexunit: oh great, could you give a link to your version? <davexunit>(define-record-type <foo> %make-foo make-foo foo? (bar foo-bar 'baz)) <alezost>ah, you used it in Sly, civodul: you see, it's a generally useful thing, it should be in Guile! :-) <davexunit>(make-foo #:inherit (make-foo) #:bar 'this-is-actually-pointless) <davexunit>it's *much* more simplistic than what we use in Guix <alezost>davexunit: thank you! I was just going to write the same thing for my script (also based on keywords, as it's simple) <davexunit>define* has the really nice property of evaluating the default argument forms <davexunit>so every call to 'make-foo' is actually inheriting values. <davexunit>if you don't specify #:inherit, it inherits from an object made of all the defaults. <davexunit>in other news, I was finaly able to build the Aseprite pixel art editor. :) <alezost>davexunit: I was thinking "What to choose: to use (guix records) in my script, or to write srfi-9's record and a keyword constructor?" Now I'll take your solution as it's really simple, thanks for sharing! <NiAsterisk>good night. see (some of you) at fosdem tomorrow o/ <alezost>sneek: later tell civodul ahem, something went wrong with renaming: I've just tried to boot a system (on commit 171a0a1) and got "kernel panic". The same system on commit 6d97319 boots successfully. I don't even know whether the problem in shepherd itself or I introduced a bug to guix source :-( <mthl>alezost: Keep calm, this is just software ***MatthewAllan93_ is now known as MatthewAllan93
<alezost>mthl: thanks, with GuixSD a broken system is not a disaster, but it's still very bad <GChriss>alezost: are you able to view the kernel panic output? append 'vga=755' or similar the boot line to adjust console text size if needed <davexunit>I'll have to remember that for the next time I get a kernel panic that I can't read <GChriss>you get the linux-libre penguins to boot (pun intended) <lfam>I guess the results of `guix environment guix` are cached by nginx, because they sure are downloading fast! <alezost>vga=755 didn't help (there was some message about gfxpayload but I couldn't catch it). <alezost>davexunit: heh, yeah, but at first I need to learn how to use a vm <myglc2>'guix system build ...' taking a long time and building a lot from source on a config I think I "only" added 'openssh' to. Is this normal? <myglc2>...on a 3.4 Ghz dedicated server <lfam>myglc2: Are your package definitions up to date? That is, have you run `guix pull` recently? The old substitutes were recently deleted to make room for the newest ones <myglc2>oooo no didn't do a pull. Should I stop the build and do this? <lfam>You might as well. If that is the issue, not stopping and doing guix pull will result in you building probably the entire system from source, which will take a long time. <davexunit>lfam: but you missed the part where he's already built a system once <davexunit>so it should only be building the part of the dependency graph that wasn't already available on the local machine <lfam>davexunit: You're right, I did miss that. <myglc2>thats true and my config was fine, I just wanted to add ssh... <davexunit>openssh's inputs list is small: groff, openssl, zlib <davexunit>but the resulting dependency graph is rather big <davexunit>myglc2: it would be helpful if you took a look at what guix said it was going to build from source. <myglc2>... oh I also added GUILE_AUTO_COMPILE=0 based on some warning I saw <myglc2>... It said it would build ~300 items and download about 300 <alezost>oops, "Could not access KVM kernel module: No such file or directory", so no 'guix system vm' for me :-( <CompanionCube>updated GNU Guix successfully deployed under `/home/samis/.config/guix/latest' <lfam>alezost: You can fix that. Copy the run-vm.sh script out of the store, and remove the part that enables kvm. <davexunit>myglc2: that's a lot, you *must* be doing more than just adding 'openssh' <davexunit>myglc2: I don't know what version of guix you are using, but substitutes may be unavailable for some of the things you want. <lfam>davexunit, myglc: Isn't it possible that myglc's first system build happened before 0.9.0 substitutes were garbage collected? In which case, `guix pull` would be relevant? <lfam>CompanionCube: It's done. There's nothing else to do <alezost>lfam: run-vm.sh wasn't generated so I can't copy it <alezost>davexunit: it is Athlon II from 2010 <lfam>Okay, then try `guix system vm-image`. <davexunit>alezost: if you can't do KVM then you're out of luck I guess. <CompanionCube>in the future, It'd be nice if there was a script emulating the pacman cli <lfam>alezost could edit the machinery and remove the kvm option. Is it just the one line in gnu/build/vm.scm? <lfam>alezost: That may or may not be sufficient, I don't know. <lfam>I actually think we have the nicest interface of any package manager I have used. It is by far the simplest. <myglc2>davexunit: correction, the only change from previous build was GUILE_AUTO_COMPILE=0 and repace 'lsh' with 'openssh' <myglc2>davexunit: guixSD from ~ 1 week ago <davexunit>myglc2: okay, well there's more to the story than that if Guix is really trying to build 300 derivations. <mark_weaver>myglc2, davexunit: we merged 'core-updates' into 'master' in the last couple of days <davexunit>mark_weaver: myglc2 is using a guix older than that, from what I can tell. <myglc2>I downloaded guixsd-usb-install-0.9.0.x86_64-linux on 1/25, never did a pull. doing it now. <lfam>myglc2: In that case, I think that `guix pull` should solve your problem. <Jhonny>does guix have a live usb version to try? <Jhonny>and that can be writable from windows xD? <myglc2>lfam: Thanks... and Its done! I'll try again. <davexunit>mark_weaver: is it okay to add licenses that aren't explicitly on the FSF's list of approved licenses. The Allegro 4 library (which is in Debian, others) uses a custom license they call the "giftware" license: http://liballeg.org/license.html <davexunit>it's similar to an expat-style license, but with some different text. <lfam>Jhonny: You can install the Guix package manager on another GNU / Linux distro. The full system, GuixSD, can be tested in a QEMU emulator, using images created by Guix. There is also the GuixSD live USB installer image, but that is just an installer image and not a whole lot of fun. <alezost>mark_weaver: ah, nevermind I got "kvm: disabled by bios" in dmesg <mark_weaver>alezost: after trying that, there might be relevant info in the output of 'dmesg' <mark_weaver>also, I've found mention that maybe it's disabled in your BIOS configuration. <alezost>CompanionCube: wow, thanks, you are experinced with this, aren't you :-) <kristofer>anyone have any experience/guidance installing guixsd on a macbook 1,1? <kristofer>I can successfully install guix, but it won't boot <kristofer>I used refind to chainload grub to boot up the usb disk <mark_weaver>kristofer: is it running Libreboot (out of curiosity) <kristofer>that would require some hardware modification <mark_weaver>someone recently installed GuixSD with full disk encryption on a MacBook 2,1 running Libreboot. but I have no experience with refind issues, and also I have to go now... maybe someone else can help. <lfam>I'm looking through security patches for jasper. I'm comparing patches from OpenSUSE and Debian and they are different! What to do about that? <lfam>The Debian patches appear to have originated in Fedora <lfam>Another jasper CVE issued yesterday! <mark_weaver>when I get there, I usually Ctrl-C and do "guix build texlive-texmf --no-substitutes", because building it locally is usually much faster than downloading it from hydra. <davexunit>but the best way to do that has been a topic of periodic discussion. <CompanionCube>doesn't texlive have the concept of collections or something <mthl>davexunit: Someone needs to do something about it®. <davexunit>anyone that knows a thing or two about latex is encouraged to take a look! <lfam>CompanionCube: `guix environment texlive-texmf -- guix build texlive-texmf --no-substitutes` <mthl>davexunit: does a “it's certainly not my wheelhouse” means the same thing than “it's not my cup of tea”? <lfam>I interpret "cup of tea" as a statement of preference, whereas "wheelhouse" is a statement of knowledge or authority. But that is just my interpretation. <davexunit>mthl: it means that it's not my area of expertise. <mthl>thanks everyone to explain it to me <mthl>s/to explain/for explaining <CompanionCube>Downloading 36wqhb
-texlive-20150523-texmf.tar.xz (1.76GiB installed). still O.o <lfam>Well, there's nothing we can do about upstream releasing a 1.76GiB tarball <mark_weaver>CompanionCube: set the TMPDIR environment variable when running guix-daemon <mark_weaver>CompanionCube: so TMPDIR is set in the environment of the guix-daemon process? <mark_weaver>oh, one thing: from within the build container, it looks like /tmp regardless of where it is in the outer system, so in the build output it'll still say /tmp <mark_weaver>but while the build is happening, you should see a $TMPDIR/guix-build-* directory <CompanionCube>10274* guix environment texlive-texmf -- guix build texlive-texmf --no-substitutes <lfam>CompanionCube: Is that TMPDIR declaration in the environment of the guix-daemon process? Usually the guix-daemon is started by root <mark_weaver>CompanionCube: you are setting that variable in the environment of 'guix environment'. <mark_weaver>it needs to be set in the environment of the 'guix-daemon' program.