IRC channel logs


back to list of logs

<calher|leela>OMG, this rocks!
<calher|leela>How do I get a desktop on here?
<NiAsterisk>from barebones? hm. not sure how to get there (yet), but something with startx and whatever desktop/window manager is available
<NiAsterisk>or slim
<calher|leela>Do you not have a desktop?
<NiAsterisk>i do
<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
<calher|leela>ACTION touches HotLava 
<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? But Unix doesn't have to reboot!
<calher|leela>bavier: What if servers ran GuixSD? This would be bad news.
<calher|leela>Uh-oh, there's no Info in bare-bones.
<bavier>there's work being done to restart affected services after `guix system reconfigure`, but in the meantime restarting is a good idea
<calher|leela>bavier: Oh, OK
<calher|leela>Hm... I can't find the example configs.
<CompanionCube>I imagine restarting services and stuff is harder because of the different model and because of the fact that anything could've changed?
<calher|leela>I can't get /etc/configuration/desktop.scm.
<calher|leela>Is it online anywhere?
<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>one quibble about the references graph
<calher|leela>I'd like to look at desktop.scm.
<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?
<calher|leela>Uh-oh, my computer thinks it's 1969e
<myglc2>isn't it?
<Jookia>You must be behind UTC then
<Jookia>It's 1970 Jan 1 for me
<calher|leela>I'm UTC-0600
<Jookia>That solves that mystery
<GChriss> I made the mistake of specifying "America/New York" instead of "America/New_York" in config.scm during install
<GChriss>...which leads to a kernel panic
<CompanionCube>zsh doesn't seem to pick up stuff in my guix profile's bin dir after setting the env var
<calher|leela>GChriss: I did Amerca/Chicago, though.
<Jookia>I'm reconsidering the idea of using btrfs now given all the tests that fail from it
<Jookia>tar of all things fails
<calher|leela>I don't use btrfs because I'm vegan.
<Jookia>What do you use
<Jookia>Ah, you should try btrfs some time
<CompanionCube>ACTION uses btrfs
<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>the only ext4 partition on this system is my /boot
<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
<CompanionCube>I believe I've compiled some of my stuff
<CompanionCube>want me to try guix pull again and grab the error?
<Jookia>Nah, it's fine
<Jookia>Thanks anyway
<CompanionCube>ACTION is currently installing ghc via guix
<calher|leela>what is ghc
<CompanionCube>haskell compiler
<Jookia>The Glorious Glasg(l?)ow Haskell Compiler
<CompanionCube>ACTION is going to see how haskell packaging works with guix vs arch
<calher|leela>ewww haskell
<CompanionCube>not my language of choice
<CompanionCube>but an app i'm interested in uses it so
<CompanionCube>4KiB/s. Excellent/.
<calher|leela>Guile all the things.
<CompanionCube>42.6MiB of docs and it's not even at a decent speed
<Jookia>Eww Lisp, Haskell all the things. ;)
<CompanionCube>heh, the irony
<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
<CompanionCube>your opinion of the jvm?
<CompanionCube>iirc clojure has a typed thing
<Jookia>Clojure is GPL-incompatible from what I know
<CompanionCube>O.o glibc locales is 450mib?
<Jookia>gotta have the locales
<CompanionCube>yeah but not 450mib of them
<Jookia>just get the utf8 ones then?
<myglc2>earlier I asked... I spiffed up my bare-bones config and successfully did 'guix system
<calher|leela> Jookia You're saying this in a #Guix channel?
<Jookia>calher|leela: sure
<calher|leela>myglc2: Don't you reconfigure and then reboot?
<calher|leela>Jookia: Make a Haskell version of Guix.\\
<Jookia>calher|leela: uhh why?
<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?
<calher> I hope it'll come soon.
<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 not.
<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|leela>Jookia: Thanks@
<calher>How do I use SSH? There is no ssh or openssh package.
<calher|leela>Ah, there *is* openssh.
<mark_weaver><Jookia> Bootstrapping Guix is incredibly difficult
<Jookia>mark_weaver: I know, I know
<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
<calher|leela>Can the Info version of SICP be a Guix package?
<mark_weaver>calher|leela: I don't see why not
<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.
<mark_weaver>Jookia: what architecture are you bootstrapping?
<Jookia>mark_weaver: x86_64 on a T400
<CompanionCube>ACTION was lazy and didn't run make check for his initial install
<mark_weaver>Jookia: on top of what distro?
<Jookia>mark_weaver: Was Trisquel, now using siduction
<mark_weaver>Jookia: does your kernel have CONFIG_DEVPTS_MULTIPLE_INSTANCES=y set?
<calher|leela>Jookia: siduction?
<mark_weaver>on debian derivatives, it's in /boot/config-*
<Jookia>calher|leela: Debian sid live CD
<Jookia>mark_weaver: Yes
<mark_weaver>Jookia: What are the permissions on /dev/pts/ptmx? See
<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>Okay, that's something helpful
<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.
<Jookia>That'd be great
<mark_weaver>e.g. on coreutils on my armhf and mips64el bootstrapping efforts
<mark_weaver>maybe tar also, I don't remember clearly
<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>yes, the builds are normally done in /tmp
<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>(assuming it's not an unusually large tmpfs)
<Jookia>Ah, I see
<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>Guile is definitely a non-deterministic build.
<mark_weaver>we intend to address that, but it turns out to be non-trivial.
<calher|leela>WHOA! ls: command not found!!!
<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
<mark_weaver>calher|leela: what is the output of "echo $PATH" ?
<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>calher|leela: not on GuixSD. I would remove it.
<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.
<mark_weaver>calher|leela: remove all of those things you added
<calher|leela>mark_weaver: removed
<mark_weaver>it's all handled by /etc/profile on GuixSD
<calher|leela>WHEW! I have ls now!
<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
<CompanionCube>or to try guixsd in a vm
<calher>How do I properly shut down in a bare-bones?
<Jookia>CompanionCube: Why not both?
<CompanionCube>Jookia: hm
<CompanionCube>why not
<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>on GuixSD, rather
<CompanionCube>true, especially given hydra's....variable speed.
<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
<CompanionCube>'guix import' l0ols
<CompanionCube>*looks fascinating
<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)
<CompanionCube>ACTION should redo guix pull at some point
<CompanionCube>I spotted an error last time but idk what
<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`?
<kristofer>should I do that?
<lfam>Did you install with the USB installer image/
<kristofer>I am currently, yes
<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.
<kristofer>very likely!
<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>are you sure?
<lfam>About `guix pull`?
<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?
<efraim>its not necessary
<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>Anywhere you like!
<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.
<divansantana>Should rather say GuixSD. Looks very cool.
<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
<divansantana>Jookia: cool.
<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.
<Jookia>What're you compiling?
<divansantana>Jookia: Installing guix via AUR on arch?
<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, so I think why work on pybitmessage when I can just wait until they drop the 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>ACTION re-downloads the world
<Jookia>jacking in so soon?
<davexunit>rebased a development branch of mine on master
<Jookia>ooh, which?
<davexunit>trying to package this
<davexunit>it's tricky to build, though.
<NiAsterisk>I think I figured brussel bus schedules out, I won't get stuck there. if I do, I blame the internet.
<kristofer>good morning!
<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'
<Pandachips>Did you remember to set the boot flag?
<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.
<davexunit>look at lsh-service.
<myglc2>I'm slowly catching on. Thanks!
<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>what do you mean?
<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.
<davexunit>or add it to the system profile
<myglc2>So (packages (cons* openssh ...)) right?
<davexunit>myglc2: yup
<myglc2>Cool, thanks!
<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>alezost: i don't know!
<civodul>i didn't plan to do it
<civodul>but why not
<civodul>some of the features are a bit baroque for mainstream though
<civodul>like thunked and delayed fields
<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' :-)
<alezost>civodul: sure, I'm just waiting for your reply to <> Should it be the same directory in both places?
<civodul>ACTION looks
<civodul>alezost: no, simply replace "/dmd/" with "/shepherd/" in both places
<civodul>it's purely cosmetic
<civodul>i'll reply to your message
<civodul>well i'll reply later :-)
<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
<davexunit>that may be more suitable for guile
<civodul>davexunit: probably, yes
<alezost>civodul: pushed
<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))
<davexunit>(make-foo #:bar 'quux)
<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)
<civodul>but it uses kw args!
<civodul>too few parentheses!
<civodul>ACTION has to go
<davexunit>I wanted to take very advantage of define8
<davexunit>ugh that was a mess
<davexunit>I wanted to take advantage of 'define*'
<davexunit>there. english. :)
<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!
<alezost>s/to write/to use
<davexunit>alezost: you're welcome!
<davexunit>glad you find it useful
<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 :-(
<alezost>ACTION is close to panic
<mthl>alezost: Keep calm, this is just software
<mthl>no kitten will suffer!
***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>ooh that's a useful tip
<alezost>GChriss: thanks, I'll do it
<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>Though now I'm almost sure that the problem is in shepherd: the following diff on commit d312a83 leads to a "kernel panic"-ed system for me:
<davexunit>alezost: try with a VM?
<davexunit>should give you something easier to read
<alezost>davexunit: heh, yeah, but at first I need to learn how to use a vm
<davexunit>alezost: 'guix system vm config.scm'
<davexunit>and run the resulting script
<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>By long I mean >1.5 hrs
<myglc2>...on a 3.4 Ghz dedicated server
<davexunit>myglc2: okay
<davexunit>what did it try to build?
<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
<davexunit>guix tells you this
<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.
<myglc2>OK thank you, will do!
<davexunit>lfam: but you missed the part where he's already built a system once
<davexunit>and then just added openssh
<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>... in the last build
<myglc2>... It said it would build ~300 items and download about 300
<CompanionCube>ACTION just randomly decides to run guix pull
<CompanionCube>guix is building
<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'
<davexunit>alezost: you don't have KVM?
<davexunit>how old is your processor?
<lfam>alezost: You can fix that. Copy the 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.
<davexunit>so I recommend 'guix pull'
<CompanionCube>so do I just add that dir to the path?
<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: 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>lfam: won't work.
<davexunit>uses the same machinery
<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?
<alezost>lfam: thanks for the advice!
<davexunit>CompanionCube: unlikely to happen.
<lfam>alezost: That may or may not be sufficient, I don't know.
<davexunit>every package has a different interface.
<davexunit>package manager*
<davexunit>pacman's UI is not particularly intuitive
<lfam>I actually think we have the nicest interface of any package manager I have used. It is by far the simplest.
<davexunit>so I wouldn't want to copy what they do.
<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
<CompanionCube>heh, guix just downloaded 3 copies of ncurses :)
<davexunit>myglc2: okay, well there's more to the story than that if Guix is really trying to build 300 derivations.
<davexunit>so how about you 'guix pull'
<myglc2>OK will do. Thank you!
<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.
<mark_weaver>well, nevermind then :)
<myglc2>so vintage guix?
<mark_weaver>myglc2: have you run "guix pull" recently?
<alezost>hm, strange, according to my CPU supports virtualization (I have "svm" flag in /proc/cpuinfo)
<mark_weaver>alezost: what CPU is it?
<CompanionCube>perhaps you're just missing the kernel module?
<alezost>mark_weaver: Athlon II X3 440
<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>without installing...
<Jhonny>and that can be writable from windows xD?
<myglc2>lfam: Thanks... and Its done! I'll try again.
<alezost>CompanionCube: might be
<Jhonny>noone can answer my question?xD
<lfam>Jhonny: Be patient :)
<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:
<mark_weaver>alezost: looks like you need the 'kvm-amd' module.
<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: thanks, I've just found it too (in <>) but now "modprobe kvm-amd" gives me: modprobe: ERROR: could not insert 'kvm_amd': Operation not supported
<CompanionCube>checked the BIOS settings?
<CompanionCube>sometimes virtualization support is a BIOS setting
<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>can you check?
<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 :-)
<CompanionCube>not really
<CompanionCube>just things you encounter / know
<mark_weaver>ah, CompanionCube beat me to it :)
<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>no I wish
<mark_weaver>oh, if you're using refind I guess not :)
<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.
<kristofer>mark_weaver: thanks! I'll hang out and see
<mark_weaver>okay, good luck!
<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
<kristofer>is gdisk not available in guixsd?
<mark_weaver>kristofer: our fdisk supports GPT.
<mark_weaver>see "man fdisk"
<lfam>Another jasper CVE issued yesterday!
<CompanionCube>texlive-texmf is 3GiB?
<davexunit>texlive is huge.
<davexunit>we've been trying to pare that down
<CompanionCube>do we really need all of it in a single package
<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.
<mark_weaver>and then I rerun the original command I was doing.
<davexunit>it needs to be broken up.
<mark_weaver>davexunit +1
<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
<mark_weaver>okay, now I really need to go... bah
<CompanionCube>they could easily be used as the units of installation
<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!
<davexunit>it's certainly not my wheelhouse.
<CompanionCube>is there anyway to *just* build texlive-texmf
<CompanionCube>while still using substitutes for the dependencies
<lfam>CompanionCube: `guix environment texlive-texmf -- guix build texlive-texmf --no-substitutes`
<davexunit>lfam: clever!
<lfam>I use it often :)
<CompanionCube>then I can use the built package in my user profile
<mthl>davexunit: does a “it's certainly not my wheelhouse” means the same thing than “it's not my cup of tea”?
<CompanionCube>I think it's an american expression or something
<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.
<CompanionCube>command is running
<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
<CompanionCube>the build filled /tmp
<CompanionCube>what's the option to select a build dir?
<mark_weaver>CompanionCube: set the TMPDIR environment variable when running guix-daemon
<CompanionCube>will that work for builds executed via guix environment?
<mark_weaver>CompanionCube: yes
<CompanionCube>did not work visibly
<mark_weaver>CompanionCube: so TMPDIR is set in the environment of the guix-daemon process?
<CompanionCube>likely, but I closed the terminal tab
<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
<mark_weaver>this is a well tested feature, many people use it
<CompanionCube>taken from my history
<CompanionCube>10272* export TMPDIR=/mnt/NAS/guixbuild/
<CompanionCube>10273* history
<CompanionCube>10274* guix environment texlive-texmf -- guix build texlive-texmf --no-substitutes
<mark_weaver>CompanionCube: okay, this is the problem
<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.