<Steap>and devstack is nice but well, it is always broken :D <isd>And also really only reasonable for development; you don't want to do production with devstack <isd>Of course, it's by far the most reliable way of getting a setup that actually works... <Steap>isd: it's already hard to do development with devstack :D <Steap>but yeah, maybe I could try and setup a devstack and see what happens <isd>I do not miss having to care about Openstack. <Steap>isd: did you use to work on OpenStack ? <isd>I found as many non-openstack things to occupy my time as I could, but... <isd>I mostly dealt with it from a sysadmin perspective. <isd>One should never resort to single stepping through a program when trying to *set it up* <fps>um, seeing how slow the install goes in qemu-system-x86-64 should i have chosen qemu-kvm? <civodul>Steap: i also made the PyPI updater less verbose <civodul>and there's a lot of Python stuff to update <Steap>see how he goes away after telling me "well, there's stuff to do" ? :p <Gxsdnewb>is the absolute pathname where guix-daemon stores logs configurable? i do not like the default behaviour of the install image to log to /var/log in unionfs... <Gxsdnewb>i want to save my logs to somewhere in /mnt just like my derivations and build successes & failures <Gxsdnewb>this way i can examine build logs across reboots or from other OS installs <bavier>Gxsdnewb: I don't think it's runtime configurable <bavier>the logs are put in $localstatedir/guix/log according to the manual <bavier>where $localstatedir is set at build time <mark_weaver>Gxsdnewb: looking at the code, it's possible that setting NIX_LOG_DIR in the environment where guix-daemon is run might work. <mark_weaver>see Settings::processEnvironment in guix/nix/libstore/globals.cc <Gxsdnewb>mark_weaver: thank you, when my build process downloads guix sourcecode i will examine this section <mark_weaver>I would be careful about setting most of those, or else you may run into problems, but I don't foresee any problems with setting NIX_LOG_DIR <mark_weaver>another option is to simply make /var/log/guix a symlink <Gxsdnewb>mark_weaver: i tend to set TMPDIR envvar because the chroot for packages as large as gcc for example do not fit in my RAMdo <Gxsdnewb>Bienvenidos Emulatorman! Let's bring Guix to Parabola GNU/Linux-libre!! :-) <Gxsdnewb>mark_weaver: it would be ideal to have logfile location and tempdir for chroot data directly configurable options for guix-daemon; do you agree? <Gxsdnewb>These options are especially important in the context of volatile root environments like live usb <davexunit>paroneayea: and that's only part of the API! <davexunit>now what about storage and other things? ugh. <paroneayea>davexunit: well, I think it's best to think of those as separate applications to keep sanity <paroneayea>davexunit: I was thinking "let's use the openstack api itself and connect with guile directly via http!" but <paroneayea>davexunit: I'm starting to think it'll be faster to use the python command line interface <paroneayea>davexunit: and maybe we can later refactor into real guile code <davexunit>but yeah we'll need a Guile interface for real. <davexunit>shelling out to a python tool will suck hard. <paroneayea>well, at least it's not shelling out to python itself, to the command line client <paroneayea>I'd be so intimidated I wouldn't know how to inch my way forwards <davexunit>it's fine to cut some corners to get a proof of concept working <paroneayea>easier to implement the shell version first and then iterate <davexunit>then once it works, we can write a Guile client <davexunit>a guile-openstack library would be super neat :) ***ljhms_ is now known as ljhms
<Gxsdnewb>guix edit is broken on both 0.8.6 and 0.9.0pre live usb img due to missing execlp <Gxsdnewb>Without examining the sourcecode (sorry), i am not certain how exactly the guix-daemon logfile dirs are named. The two characters do not appear to match the hash of the output they contain the logs for. <Gxsdnewb>It would be nice if they were organised chronologically, so that a large build involving multiple packages could be examined later with full understanding of the order of derivation & therefore the clarifying the build process for packages or enitire systems more intuitively. <alezost>Gxsdnewb: re "guix edit is broken": I think it happens for you because you didn't set EDITOR environment variable <fps>installing the bare-bones system in kvm failed <fps>iirc first it complained about not being able to write the compiled scm files for guix [.go files] <fps>for some reason it suddenly started to build guix which i didn't quite expect on an installer medium ;) <fps>and now the whole kvm froze.. <fps>that's the last lines <fps>oh the cursor still seems to live in the kvm.. <alezost>fps: apparently "make check" failed for guix. What "installer medium" do you use? <fps>qemu-kvm -hda guix.qcow -hdb Downloads/guixsd-usb-install-0.8.3.x86_64-linux -boot menu=on -m 4096 <fps>i do remember that almost all 0.8.3 packages were gc'ed on hydra <fps>i didn't expect it to go that far though :) <fps>uum, hostname lookup failure <fps>ok, restarting system init <fps>yeah on the second try it succeeded. rebooting right now <fps>um ok. tried changing the user name after installaton and am doing a guix system reconfigure... now <fps>i have a feeling everything will be built from source again :) <fps>cause it's pulling all dem tarballs <fps>gcc 4.8.3, gcc 4.9.3 <fps>well the virtual disk is only 6G <fps>i'll just let it sit <fps>glibc 2.18, glibc 2.22? um okaay.. <fps>ok, on the racket side of things i did: <fps> ./pre-inst-env guix package -i racket <fps>which is progress i suppose <fps>for some reason the newly installed system is listing all the files in the gcc 4.9.3 package without compiling anything <fps>oh it's the patchPhase <fps>so in summary: the 0.9.0pre image worked to get me a running system, but changing the username in the config.scm seems to trigger a complete system rebuild <fps>hmm, though i must admit i didn't see any compiler calls yes. just lists and lists of files in packages <alezost>fps: do you mean after changing the user name "guix system reconfigure" tries to rebuilt everything from source? <alezost>fps: this shouldn't happen, I think you changed something else, could you paste config.scm you use? ***tschwing_ is now known as tschwinge
<fps>alezost: i'll try to see if i can paste it. havin irssi running on a root server in tmux might turn out to be useful.. hold on <alezost>efraim: it works for me; is it the latest git checkout? <efraim>i wouldn't put it past to be only broken for me <efraim>i had a while where guix lint broke for me <fps>um, i have no ssh on that system nor scp <efraim>and now guix refresh -t py-pi seems to be working well <fps>no web browser, no emacs.. <alezost>efraim: it complains aboun /home/efraim/.cache/guix/http/cvs.savannah.gnu.org/gnupackages.txt. try to clean the cache, perhaps it will help <fps>i guess the only thing i could do is to shutdown the system, mount the qcow in some way and get the file out of it <fps>hmm, since i do have network i guess i might get something done with curl <Gxsdnewb>I am having more troubles with cmake downloading via https: using guix system init on 0.9.0pre ... i bootstrapping my toolvhain and many other packages on /mnt via 'guix build curl' <fps>ah drats, no netcat ;) <fps>and no curl or wget.. <fps>no, i cannot paste the file <fps>had to shut it down and mount the qcow2, what a hassle :) <alezost>fps: ok, "guix system build --dry-run <your-config>" hasn't displayed that anything will be built locally <alezost>try this ^^^ command and show the results please <fps>do i have to disconnect qemu-nbd before booting it again? <fps>i already unmounted it <alezost>sorry, I have no idea what "qemu-nbd" is <fps>i needed it to mount the qcow2 image to get to the file <fps>i'll just disconnect just to be safe <alezost>sorry, I am of no help here, as I've never used virtual machines <fps>and why do all the guix tools write everything to stderr? <cehteh>some may consider that a feature <civodul>karhunguixi: how did you install GRUB for GuixSD with encrypted root? <fps>cehteh: i'm not one of those :) <fps>anyways, the dry-run tells me it will rebuild everything <fps>i guess maybe a guix pull is in order again after the install? <fps>alezost: a long list following "The following derivations would be _built:_" [emphasis mine] <civodul>iyzsong: we'll have to back up on the encrypted root :-/ <alezost>fps: hm, "guix pull" will probably help; not sure why this happens though: I thought that 0.9.0pre contains "fresh enough" package definitions <civodul>yes 0.9.0 is supposed to contain fresh package definitions <fps>i have no idea how hydra works, but shouldn't it be possible to maybe "pin" some derivation results? <civodul>fps: so you're testing 0.9.0pre, right? <fps>civodul: yes and yes.. <civodul>it's normal that 'guix system init' reports a list of 15 or so derivations to build <fps>there were some network failures during the initial install though and i had to rerun guix system init <civodul>these are small derivations for config files etc. <civodul>but the packages themselves should be downloaded <fps>and networking works fine in the installed system <fps>08:32 < fps> uum, hostname lookup failure │ <fps>08:32 < fps> is hydra down? │ <fps>08:33 < fps> ok, restarting system init │ <fps>guix pull will take a while. brb <Gxsdnewb>civodul: still getting gnutls error for cmake download even tho i bootstrapped my toolchain & compiled dozens of other packages, including gnutls itself <civodul>fps: "hostname lookup failure" suggests a problem on the machine, not on Hydra <Gxsdnewb>and i tried changing url from http: to https: in the j156ja...cmake_3.3.2.tar.gz.drv <civodul>Gxsdnewb: what GnuTLS error? i need more context :-) <Gxsdnewb>did you change anything besides adding an 's'? <civodul>Gxsdnewb: no that's all i did, see 4ebdefc <civodul>it solves the issue, because then GnuTLS is available in the download environment <civodul>why did you disable substitutes anyway? <Gxsdnewb>civodul: i want to compile everything locally and run guix challenge on every package, because i see that as a huge value of this pioneering method of package management <civodul>so just adding the 's' or updating to git master (possibly with "guix pull") should do the trick <Gxsdnewb>it confirms local security and builds on hydra at the same time.. also i want to document all nonreproducable packages <Gxsdnewb>civodul: unfortunately adding 's' manually does not fix it, even after successful guix build gnutls <civodul>Gxsdnewb: which file are you editing? <civodul>files under /gnu/store must not be modified <civodul>what you can edit is gnu/packages/cmake.scm <civodul>which is the real source for the package recipe <fps>civodul: ok, so would a network failure during guix system init and a consequent second guix system init be a cause of rebuilding everything once the system is booted? <Gxsdnewb>sorry, i am still a newbie... what is the absolute pathname of this on the live image civodul? <civodul>there is no editable copy of this on the installation image <alezost>Gxsdnewb: I think the best bet for you will be "guix pull". The hard way is to use guix from git directly as described in the manual <alezost>"the best bet" is probably not a suitable phrase, sorry my English, please :-) <alezost>Gxsdnewb: an alternative to "guix pull" is to use a local guix repo with "./pre-inst-env guix" commands, see (info "(guix) Running Guix Before It Is Installed") <Gxsdnewb>when i guix pull, is it going to not change all of the hashes of my outputs? <fps>also note "guix environment guix" to get an environment to build the local clone of guix <Gxsdnewb>I am trying to compile as many packages as i can to match what is on hydra... <fps>which is pretty awesome. so if i want to work on a project before packaging it completely i could just create a package with just the required build inputs and use guix environment my-package to get a shell where i can work on it <fps>kinda similar to nix-shell <fps>btw: nix-shell has an even simpler variant: "nix-shell -p openjdk8 cmake boost" directly gives you a shell with those packages <fps>without having to create a package first <fps>i suppose one could hack that up using some shell scripts ;) guix-shell would create a temporary package definition and then just guix environment that temporary package <fps>but there's probably a cleaner and more lispy way <alezost>Gxsdnewb: if you did "guix pull" recently, then most of the packages didn't change, so you will not have to rebuild everything <alezost>fps: "guix environment --adhoc openjdk8 cmake boost" will do the same <fps>alezost: oh ok, very cool :) <civodul>efraim: what's up with libassuan? :-) <alezost>rekado: it was just an example as fps wrote "nix-shell -p openjdk8 cmake boost" <rekado>there's no icedtea release for JDK8 yet. But we do have some pre-release tarballs already. <efraim>no idea, i ran guix refresh a few hours ago and then just now and it popped up again <rekado>civodul: I have a fix for csound, which currently fails to build. Fix is simple: patch CMakeLists.txt to add "-lm". <civodul>rekado: i've committed a fix as well just a few minutes ago <rekado>nah, that's fine. Your fix is better. <rekado>and I wasn't bored on the commute, so it's all good. <fps>ok, after a guix pull the list of packages to be built has significantly reduced in size <fps>will reconfigure now <alezost>fps: are you sure you used 0.9.0 and not 0.8.3? <fps>i still have the qemu call here :) <fps>[fps@peach:~]$ qemu-kvm -hda guix.qcow -hdb Downloads/guixsd-usb-install-0.9.0pre.x86_64-linux -boot menu=on -m 4096 <fps>if you want to, i can redo it all once more.. <fps>but shouldn't there be a way to check the package hashes shipped with the 0.9.0pre and compare them to what's available on hydra? <fps>then you don't have to trust my words ;) <alezost>fps: since you did "guix pull" you have the latest package hashes anyway <fps>alezost: well, i mean to be able to know whether the 0.9.0pre is fresh enough <fps>trusting users can be a dangerous business. who knows what else i screwed up ;) <alezost>fps: 0.9.0pre is fresh enough, so "guix pull" should not be needed for it; I don't know why it happened for you <fps>erm ok. so i will redo all the steps, and document them, so you people believe it's happening ;) <fps>but not now. got garden work to do.. bbiab <Gxsdnewb>alezost: guix pull is necessary for me because of this gnutls error downloading cmake <majstro>hi,everyone, how to try guixsd on virtualbox? the usb stick is not the iso format and error while load <fps>majstro: i documented the process <fps>majstro: check the channel log. there shoulb be paste somewhere <fps>grep the log for fps, virtualbox and VB <toothbrush0>majstro: first thing is that the image isn't ISO (as in a CD) so you should rather add it as a virtual harddisk <toothbrush0>personally i also prefer using qemu-kvm, and if you like having a graphical interface, virt-manager makes everything really easy :) <fps>it is not too hard though. jyst convert tge image to vdi <fps>majstro: i cannot grep the log right now, as im on mobile <Gxsdnewb>Hmm, a guix pull after 0.9.0pre has me downloading some new packages with the same version numbers but new hashes, like gcc and gettext <Gxsdnewb>what is the recommended way to track changes between package versions? <fps>majstro: did you find the paste? <fps>you also have to add a second controller to hook up the vdi as disk <Gxsdnewb>because all of the derivation files have date set to epoch, and the hash is nonintuitive to correlate which .drv and -guile-builder belongs to the more recent package <toothbrush0>civodul: just installed a VM from the 0.9 image, LGTM :) <wkarhunguixi>civodul, on one computer i use Libreboot, which includes GRUB, so i didn't install GRUB there. On another computer, with BIOS, i let Guix install GRUB and also set up a unencrypted /boot partition <wkarhunguixi>for both grub.cfg i add "insmod luks" and "cryptomount <partition>" for the menu entry <fps>for later: where in guix are the kernel parameters assembled? <fps>i'd like to set vgamode.. i looked at the grub and linux packages, but i suspect ill have to find the definition of the bootloader procedure instead? <civodul>wkarhunguixi: so you use a manually-generated grub.cfg, right? <wkarhunguixi>civodul, it's auto-generated, i just add those two commands <civodul>wkarhunguixi: could you post your GuixSD config? <civodul>that's the GRUB config, but do you have the GuixSD config? <Gxsdnewb>does the flac package really need to test encode so many audio streams during compilation? <toothbrush0>civodul: `guix pull` does a compile, which is really slow in qemu, though :p. *complain complain* i need a faster computer :p <civodul>BTW, you owe me a bug report for the Hackage importer ;-) <toothbrush0>civodul: oh, i wasn't actually serious about the slowness, my computer is, in fact, slow, and i assumed it was worse because it was in a VM :) <toothbrush0>but yes, the hackage importer needs attention. I'll see if i can find a few examples of breakage <toothbrush0>surely it's just a bunch of Guile files being compiled? <civodul>we may switch to not compiling gnu/packages/*.scm <civodul>but i'd like to have feedback from wingo & mark_weaver <civodul>things like 'guix package' will be slightly slower and consume more memory <toothbrush0>stupid question: why can't guix-latest be provided as a substitute? <toothbrush0>civodul: oh, you know what else i'd love? A sort of global progress indicator, e.g. (2 / N) when N packages must be downloaded or built <toothbrush0>* (N/M) i guess, with M total packages in transaction, and N current package <civodul>we could provide a substitute for guix-latest yes <wingo>civodul: compilation speed is generally slower with guile 2.2 but you could compile packages with -O0 i guess, and who knows if other speedups would make e.g. the expander go faster... <wingo>so i don't know how an eventual switch to 2.2 would affect things :P <civodul>wingo: i'm guessing it still wouldn't scale well <civodul>on one hand, it'll be nicer with 2.2 because more things will be mmapped, startup time will be slower <civodul>on the other hand, that doesn't solve compilation time <toothbrush0>civodul: perhaps a stupid idea: split each package into a separate file, and only evaluate on demand? would that be feasible? I'm trying to avoid loading the entire package list on each invokation of `guix package` <wingo>maybe the macros themselves will be faster tho <civodul>toothbrush0: when you type 'guix package -i foo', you need to know whether "foo" exist <civodul>i don't want Nix style where "nix-env -i foo" is basically unusable <toothbrush0>can't you figure that out by `find gnu/packages | grep foo` or the equivalent, first? <civodul>so people have to lear "nix-env -Ai bar.foo" etc. <toothbrush0>i guess that's too ugly, but at least you'd get a quick negative answer <civodul>we're not gonna start a subshell to hack things around, no ;-) <toothbrush0>well, i said "or some such" -- i assume that somewhere in memory you have a list of all modules? <toothbrush0>i don't literally mean looking at files, but at that level of logical unit <toothbrush0>which is why i wondered if it would make sense to split package definitions into one-per-file <taylan>from what I understand, while compiling Guix's gnu/packages/*.scm which import each other a lot, you have this situation where many of the files get compiled over and over again from importing them for the compilation of other ones, is that right? if so, getting a single Guile instance to compile as many files as possible would probably be a big improvement? <civodul>taylan: i've thought about that (that's what 'guix pull' initially did), but it wouldn't scale either <civodul>currently we keep reloading things, but at least we can compile in parallel <toothbrush0>doesn't it use .go files when they exist and are up-to-date? <civodul>and the benefits of parallelism outweigh the slowness of reloading things <toothbrush0>..and doesn't that speed things up as opposed to using the .scm? <toothbrush0>hm, so it seems hopelessly inconsistent that ratpoison and xfce are in eponymous modules, but xmonad is in the `wm` module <civodul>toothbrush0: that part is fine; the only thing that's slow currently it 'guix pull' <taylan>(BTW what time complexity is that, where processing the nth item of a total m involves re-processing items n through m? (that would be if every package module imported every other package module.)) <toothbrush0>(reporting that as a naive user trying to get `guix system reconfigure ..` to work) <civodul>"time guix package -s . >/dev/null" runs in 4 seconds, which is OK IMO <civodul>'guix package -i foo' is slower, but it involves mostly things unrelated to package searching <toothbrush0> time pacman -Qi > /dev/null reports 0.28s user, but i guess that's unrealistically fast? <taylan>different idea: could we have a way to tell Guile to output a foo.go for every foo.scm it happens to compile due to being imported, just like when auto-compiling into the cache? but maybe that still prevents parallelism. <taylan>toothbrush0: well, it does that when caching auto-compiled files, but e.g. while compiling Guix, it neither caches them nor writes them to foo.go (the compilatino target), so you get this situation where some foo.scm might get recompiled 10-20 times because it's imported from 10-20 other modules which get compiled-and-written-to-.go first <civodul>toothbrush0: "time guix package -A > /dev/null" takes 1.4 second :-) <civodul>i'm guessing it's closer to "pacman -Qi", but i dunno <toothbrush0>you're right, i discovered that i should have done `pacman -Ss` but that gave a similar time <taylan>isn't -Qi "list installed packages" a la guix package -I? (haven't used Arch in ages) <taylan>at least package -I takes only 0.421s after caching by the OS (first run took 4s) <toothbrush0>is it a good idea to add a warning to `guix system reconfigure ..` if you're not running it as root? <civodul>taylan: -I might take close to 0s on an empty profile ;-) <taylan>oh yeah, I got only a measly 70 packages in my profile (using Guix on Debian) <taylan>civodul: BTW are you sure parallelism with the current "time complexity" beats linear time? I think the current way causes a fairly big explosion of number of compilations <taylan>maybe I can experiment a bit. have some free time ATM. <civodul>taylan: please do experiment with it, that'd be great! <Gxsdnewb>civodul: is it too late to make a feature request for guix-daemon logging options? I am doing another bare metal install and the log output is very important for mere mortals who cannot read scrolling gcc output so quickly :P <Gxsdnewb>It would ideally be a guix-daemon option of where to save logs (very important to save on persistent storage in case something happens) or at least envvar mentioned in manual. <Gxsdnewb>Also it is a strange dir structure, the logs. It wpould IMO ideally be grouped by date+individual call of the guix command (build, package, system, etc.) in directories, then inside said directories a chronological list of pckages in each file <Gxsdnewb>that way it would be very transparent what the order of compilation was of which packages based upon every invocation of guix <Gxsdnewb>right now the organization of the logs is just #confusing# <Gxsdnewb>also, the example for encrypted / in the manual should instruct users to add unencrypted /boot unless they have something like coreboot or libreboot with grub or linux payload that can handle fully encrypted / <civodul>davexunit: making progress, i've already tagged and such <civodul>now building the binary tarballs and all that <Gxsdnewb>also zile & nano should have word wrap enabled by default <civodul>Gxsdnewb: try using 'guix build --log-file foo', which is quite convenient <davexunit>civodul: oh you tagged? darn I had a patch for the guix-environment-container.sh tests. <Gxsdnewb>But mostly thank you for the amazing work, i am so happy to discover this software <civodul>davexunit: yeah, but that'll be fine <davexunit>hopefully users won't be too bummed about any test failures they get. <civodul>davexunit: we run into practical limitations where Wed is a day off for me, and i could hardly handle a release without it <Gxsdnewb>civodul, davexunit: do you run GuixSD as primary distro or just in a VM? <civodul>it wouldn't make sense to put so much sweat in a distro "just" to use it in a VM <davexunit>civodul: it's fine. releases are tough. there's always "one more patch" that we'd like to get in. :) <Gxsdnewb>Now that i understand a bit about how Guix works, i am trying to understand why i would install it on top of another distro instead of writing new package definitions in Guile <davexunit>Gxsdnewb: here's an example: at work, I cannot use GuixSD. I have an Ubuntu workstation. using Guix on top of Ubuntu gives me access to things like the Guix build of Emacs and all the Guix tools that help me do day-to-day development work. <Gxsdnewb>davexunit what do you run on yor nonwork machines? <Gxsdnewb>I am curious about Devuan as successor to Debian... if Devuan were to adopt Guix as package manager, why not just package for GuixSD? <Gxsdnewb>or is there something obvious i am missing? <civodul>davexunit: ignore it, i'm planning to write a blog post about 'guix challenge' and all that <civodul>ACTION thinks we should register software-that-works.org and list our friends there <davexunit>I'm only just hearing of it because NixOS was just added <civodul>i'm fond of their effort, they even invited me to a Reproducible World Summit in December! <civodul>but... the domain name makes me thing of kernel.org and libc.org <civodul>which sounds like they're self-proclaimed maintainers of the concepts at hand ;-) <davexunit>civodul: they posted on twitter and asked for people to let them know about projects that aren't listed on their site <davexunit>they asked for a page about the status of reproducibility <davexunit>all I could really link to was our "features" page <davexunit>and they asked again for a page about the status. <davexunit>so I asked if just working on reproducibility didn't count for them <davexunit>I'm not interested in having to persuade them into thinking our project matters <civodul>paroneayea: it's for GuixSD, of course! <toothbrush0>Why does a `guix system reconfigure /etc/config.scm` want to re-download so many files, such as cups, dmd, etc.? I guess it is because i did `guix pull` after installation? Should i (not) have done this? <bavier>toothbrush0: a `guix pull` may have brought updates to some packages, so a system reconfigure will want to bring those up-to-date <toothbrush0>somehow it keeps breaking my head that the package list is really part of the `guix` command, too... <toothbrush0>but more importantly, is it a bad idea to do `guix pull` in certain situations? <bavier>I think the worst that could happen is some package is currently broken on 'master' <bavier>the system reconfigure is atomic, so it won't break your system <Gxsdnewb>i ran guix pull after i ran into missing gnutls bug for downloading a tarball via https, and now a guix system init has even my inital toolvhain being bootstrapped and recompiled <Gxsdnewb>the biggest concern i have is 60+ empty .lock files in /mnt/tmp/guix-inst <davexunit>so fedora 23 was released yesterday and includes a new package manager whose big feature is using a SAT solver for dependency resolution, I guess. <davexunit>I'm happy that we don't need a SAT solver. ;) <civodul>we just need a Scheme implementation ;-) <taylan>ACTION doesn't know what a SAT solver is, checks Wikipedia, still doesn't know :P ***1JTAADXC5 is now known as cpbills
<fps>hmm, ok, there must be a way to find the definition of "grub-configuration" quickly :( <fps>oh, it's a data type, not a procedure <fps>somewhere, over the rainbow, the kernel commandline is built, lalala <fps>hmm, menu-entry allows extra parameters <fps>is foo->bar just a naming convention, too? <fps>or does that syntax carry meaning? <fps>staring at gnu/system/grub.scm <fps>which does export grub-configuration <fps>i guess grub-configuration-file is what i should be looking at.. <fps>civodul: there's the menu-entry form, but i have no clue what to choose for the linux kernel. i'm playing with editing the grub commandline directly on boot now. <fps>like defoptions=vga=775 <fps>has no effect though.. <civodul>fps: the 'menu-entry' form is used to add new menu entries, in addition to those that GuixSD automatically adds <fps>civodul: that's how i read it. i looked at the sources in gnu/system/grub.scm to find out a little more about how the default one is generated and where i could add a koonsole vga mode.. <fps>oh, in the grub edit of the boot entry, something like this might work? <fps>set gfxpayload=1680x1050 <civodul>you mean you want GRUB itself in text mode? <fps>civodul: nah, i installed a bare bones system and would like more characters on screen ;) <fps>80x25 or whatever it is is really meh :D <fps>so i checked the docs for any mention of anything remotely related to that and came to the conclusion that grub is my friend.. <civodul>it enters graphics mode automatically for me <fps>civodul: kvm and qemu, different vms. grub looks nice and splashy <fps>but the linux console afterwards is 80x25 <fps>sorry for being imprecise.. <fps>ok, so something like (kernel-argument '("vga=755")). that shows up fine in the grub menu but has no effect.. <civodul>ah yes, i get text mode in QEMU, not sure why <civodul>on the bare metal it's the appropriate graphics mode <fps>never seen it on the bare metal ;) <fps>maybe it's missing the good ole vga or framebuffer module <fps>it's been ages since i had to play with that kind of stuff :) <fps>civodul: does -vga=std help in qemu? <fps>i can't get qemu it to boot here at all on my desktop. <fps>ioctl(KVM_CREATE_VM) failed: 16 Device or resource busy <fps>might have to shutdown virtualbox <fps>civodul: btw. note that setting the console font succeeds.. i faintly remember this having to do something with the vga mode <fps>and yes, i had to shutdown virtual box to get qemu-kvm to start :) <fps>do you have the url for the 0.9pre image again? <fps>i made the mistake of using 0.8.3 and now the guix init compiles guix again ;) <fps>got it already from the logs <taylan>I just intuitively tried to search for a package by doing 'guix package -A foo' instead of 'guix package -A | grep foo', and it simply gave me no output, making it look like a failed search. I guess we should improve on error checking eventually... <fps>i always used -A foo <fps>no package match = empty output. what's the problem? <efraim>nice for scripting, not so much for user experience <fps>hmm, maybe check for interactive mode and in that case write a message "no packages matching `foo'" <fps>i don't think that any user trying guixsd would be unable to handle the empty output ;) <fps>it's just no the target audience at this stage or is it? ;) <bavier>on the other hand, we'd like to consider usability feedback <fps>for me the empt output always made perfect sense.. but different strokes for different folks i suppose.. <Gxsdnewb>if i do not want to install grub, what should i put in my bootloader line of my scm for system init? <fps>host name lookup failures again <fps>though i'm totally online <fps>oh, this time around guix pull needs to rebuild packages. <fps>oh, there was another netork failure in between <alezost>Gxsdnewb: you can use "guix system --no-grub ..." <fps>btw: what does guix pull compile? <fps>i.e. why does it take ages? ;) <davexunit>which includes a huge number of package modules <fps>ok, wouldn't it make sense to postpone the package module compilation? <fps>guile can execute scripts without compiling them, no? <fps>may i ask why it wouldn't make sense? <davexunit>but running, say 'guix package -A guile', will load all of the known package modules into memory in order to search through the full set of packages. <fps>ok, that does make sense. if they weren't compiled _that_ would be dog slow <davexunit>basically, running any guix tool will cause the package list to be inspected. <davexunit>now, there's certainly something that needs to be done about all of this, but it's not clear to me what that is. <fps>ok and the one thing that's hard in computer science is caching :) <fps>why not build it on hydra? <fps>and ship the built guix? <fps>and i suppose one could also create a cache of the package list upon the first -A run <davexunit>verifiability and security are at stake there. <fps>um, the computation is slow, not going through the result, or did i miss something? <fps>about reproducability and verifyability: how would this differ from any other binary substitution shipped by hydra. people can still do it manuall if they choose and verify <davexunit>it would be really bad to defer all compilation until the first time a guix tool is invoked. <fps>ok, sorry, mixing up things <fps>let's say we keep it like it is and compile everything on guix pull <fps>then you query the packages for the first time using i.e. guix package -A <fps>at that point in time a cache of the result could be kept to make subsequent searches much faster.. <davexunit>with the addition of new package modules to the guile load path <fps>that's orthogonal to the point about shipping the compiled result [which guix pull would produce] via hydra to make an update quicker <fps>ok, then forget about the caching of the package index.. <davexunit>the problem there is not asking user's to trust a central authority <bavier>this conversation makes me think of wingo's latest blog post <fps>davexunit: well, it could all be optional <davexunit>we just have to make it not the guix equivalent of 'curl | bash' <fps>when pulling the source we are trusting a central authority anyways.. <fps>it's less trust i suppose though since one can inspect the source.. <davexunit>anyway, we all know that 'guix pull' sucks. it's just a harder problem to solve correctly than it seems at first. <davexunit>now, I just symlink ~/.config/guix/latest to my git repo <fps>oh and i think i understand how it is different from all the other substitutions <fps>it's the source of all the hashes, right? <fps>so other substituted binaries do get verified against the build output of guix pull? <davexunit>yeah, you don't have a computed derivation in this case. <fps>make the new guix a package in the old one <fps>then you have a chain of trust once you did guix pull yourself once.. <davexunit>it's a bit like a bootstrapping problem though <davexunit>the hash of guix built with guix changes with the version of guix. <fps>forgive my abuse of terminology since i'm a guix noob <davexunit>but yeah, there is definitely *something* that can be done, but I'm not sure what it is. others probably have better ideas. <fps>if you trust a binary installer image, then you'd have an entry point.. <fps>and can chain from there.. <fps>the same does probably not hold for bootstrapping a particular revision of the guix source.. <fps>since the tools used might differ from user to user.. <Gxsdnewb>if i am in the live env and finished a system init to mounted internal ssd at /mnt <Gxsdnewb>...but now i want to build more packages to the new installation <fps>anyways, a binar installer gives you a known hash from which to work on. from then on users can build manually and should get the same hash as binary substitutions that started at the same starting point.. <fps>fuzzy ideas.. would have to study the problem some more <fps>i have a feeling that a chain of trust might work some way or another. oh well. <fps>i also have a feeling that it's pizza time, since guix pull takes _ages_ :) <fps>Gxsdnewb: via the config.scm? <fps>Gxsdnewb: edit it and do another init? <fps>Gxsdnewb: it won't redownload packages, etc.. <Gxsdnewb>if i run guix build under the live environment, do the packages get compiled and installed to /gnu/store unionfs? if so what is the best way to copy them to the guixsd install on ssd? <bavier>Gxsdnewb: did you set up the cow-store? <fps>crazy. now host lookup stopped working again.. weird.. reerunning dhclient <fps>ok, works again.. weird.. <fps>and for some reason i'm on 0.9.0pre but guix reconfigure pulls guix-0.8.3 [nar] <fps>oh well, there'll be a good reason <bavier>then I think anything you build/install will make it's way to the /gnu/store <Gxsdnewb>bavier: right, sorry i did that over 1 day ago... guix pull had me compile everything a 2nd time, so been looking at much gcc output <toothbrush0>fps: i was wondering about the 0.9.0pre vs `guix pull` using 0.8.3 too. doesn't make sense to me <fps>toothbrush0: um, just to be clear: i installed a 0.9.0pre then did a guix pull for good measure, then a guix system reconfigure <fps>and during the reconfigure it downloaded guix 0.8,3 for some reason <toothbrush0>fps: IIRC that was the same behaviour that surprised me. <toothbrush0>i don't win the award for clearest description, i admit ^^ <fps>toothbrush0: oh ok, i thought we had a misunderstanding :) <fps>could anything in 0.9.0pre depend on guix 0.8,3? <fps>or anything in the current guix tree? which should be in effect after guix pull <bavier>fps I believe its a bootstrapping issue <civodul>davexunit: i think we might end up not compiling gnu/packages/*.scm (at least in 'guix pull') <civodul>but we have yet to see how well that scales <Gxsdnewb>i also ran gux pull after installing 0.9.0pre and i am still in my live env... i see /gnu/store/...-guix-latest and ...-guix-source and ...-guix-0.8.3.b485f75 <Gxsdnewb>but on /mnt/gnu/store only the last dir is there <Gxsdnewb>so guix-latest was not actually installed to internal drive? any way to efficiently find out which other packages are missing from internal drive? <fps>bavier: which one precisely? my previous discussion with davexunit? <fps>oh, just stumbled about this: <fps>RacketCon 2013: Matthew Flatt - A Dinosaur's Thoughts on Programming Language Evolution <fps>and at ca. 17:00 minutes he makes the point about the base package of a packaging system [i.e. guix] not being too special compared to other packages.. <fps>kinda chimes into that previous discussion ;) <detrout>Hi. Is there a reason some packages use (arguments ... ( alist-cons-after 'phase ) and some use (modify-phases ... )? <bavier>detrout: the modify-phases form is newer <detrout>Is there any documentation other than finding the definition in the source? <civodul>detrout: this part is not documented in the manual, but you can look at the (guix build utils) module <civodul>there are docstrings too, which are easily accessible at the REPL or with Geiser <detrout>I was wondering if there a way to get something like ^H f while at a symbol in emacs? <civodul>damn i have muscle memory but i'm unable to spell out which keys i use <civodul>and there's M-. to jump to definitions, etc. <detrout>Hmm. no documentation available for 'arguments'. <detrout>I bet i need to go learn about customizing paths <avoine>In execvp of btrfs.fsck: No such file or directory <- I think I found my first package :P <civodul>avoine: yeah the Btrfs tools are missing <avoine>upstream name it "btrfs-progs" should I call it that? <civodul>i'll probably send the announcements tomorrow morning <davexunit>lol jk the trains are messed up so I'm gonna be online awhile longer <Steap>ACTION is just sitting here, working remotely <karhunguixi>i thought dave was running to/from work, that's what he says before he leaves ;) <civodul>Steap: "remotely working" you mean? ;-) <Steap>civodul: funny how the meaning changes :p <detrout>Is there anything like apt-file for guix? (so you can find what package provides a missing command?) <davexunit>and it's not clear how such a thing could be done. <davexunit>debian's centralized, binary-based design makes such a tool possible for them <detrout>hm. true. I was imaging since guixsd has a list of packages that are known to exists, it should be possible index what ends up in the /gnu/store directories <toothbrush0>i guess one could provide a search-string -> list-of-derivations that might hint at the origin of a command or file? <detrout>it'd probably have to be a feature of the build servers? so you could query multiple servers? <davexunit>detrout: yeah there's lots of complications there <davexunit>in order to compile a list of binaries, you need to build every single package in the system and inspect their /bin directories <davexunit>well, we have a build farm that does, but we strive to make sure that users do not need to depend on us for binaries. <davexunit>having a feature that required every single package to be built would encourage users to use a substitute server. <detrout>hm. so guix is really aiming for much more decentralization than classic distros <davexunit>whereas right now users would only have to compile the software they actually use. <davexunit>I'd like an apt-file equivalent, if possible. <detrout>I can think of an imperfect apt-file replacement. <toothbrush0>i guess it's still not very decentralisation-minded to host that on a web interface, like packages.debian.org does.. <toothbrush0>and indeed i don't see how one could provide correct answers to such queries, even given complete builds <detrout>various hydra processes watches what it builds and produces a structred document that gets stuck on the web, and crawlers index them <toothbrush0>i guess providing a list of derivations containing the queried file is still better than nothing <davexunit>toothbrush0: querying the server in such a way would work <davexunit>but it could only give derivations as output <detrout>apt-file gives you a list of package names and paths that match <davexunit>or store items. it couldn't tell you which packages. <davexunit>packages -> derivations is a one-way mapping <toothbrush0>davexunit: but their names would be telling, no? i envisage something like /gnu/store/$hash-mypackage-v0.1.2/thefile.h as an answer <detrout>also if you index during a build process you should know what package you're currently building is <davexunit>but it may be hard for an inexperienced user to translate that to a package name <toothbrush0>sure, it's more like a hairy if-all-else-fails approach <toothbrush0>ATM i use pacman -Qo to figure out where to look, did that with the ambiguously-named wireless-tools just today... :/ <toothbrush0>turns out that the package called `iw` doesn't correspond to `iwlib`, for example :( <davexunit>but I think you're on the right track of treating this thing as a query against a substitute server <davexunit>as opposed to being something that is generated as a build process and kept in the store <detrout>yeah most individual stores won't be complete enough <toothbrush0>argh, why does `guix system reconfigure` want to build guix-0.8.3.….drv from source :( <toothbrush0>i guess i'll just have to suffer throught the slow build on my VM <detrout>Though maybe a simpler question is... on guixsd what packages do you need installed in order to run ./bootstrap and ./configure <bavier>detrout: `guix environment guix` 