***tschwing_ is now known as tschwinge
<Gxsdnewb>hi all, trying to install guixsd for my first time, but guile failed to compile <Gxsdnewb>i changed my config.scm, but now 'guix system init /mnt/etc/config.scm /mnt' returns an error: source expression failed to match any pattern <lfam>Gxsdnewb: I'm not a Scheme expert but in my experience that means that the source expression is malformatted. <lfam>Are you using something like Paredit to automatically balance the parentheses, quotations, etc? <lfam>Also, how about sharing config.scm on a paste site like paste.lisp.org? <Gxsdnewb>hmm well i am booted into guixsd live env so not sure how to upload easily <lfam>Unfortunately I am not running GuixSD, only Guix on a "foreign distro", so I won't be able help you get online. <lfam>This channel is usually more active earlier in the day (from my perspective of "day"). If you come back at the right time there will be more people around to help you. <lfam>Alright, I'm getting there with Lua. 5.1 and 5.2 both provide liblua.so, and can both load shared Lua libraries. The next task is set up Lua's search paths so that it can find shared libraries, and I'm not sure how to best accomplish this. <davexunit>lfam: add a search path to native-search-paths <lfam>davexunit: When I was working on this a few days, I remember finding some limitation with that technique, but now I can't remember what. I guess I'll pick that up where I left off and see how it goes. <lfam>Search paths can be configured at build time for Lua. If I understand it correctly, we wouldn't have to set any environment variables, which would be nice. <davexunit>okay, I was under the assumption this was an environment variable <lfam>They can be environment variables. But you can also configure a default search path when building. <davexunit>this works now: guix environment --ad-hoc -e '(@ (gnu) %base-packages)' <Gxsdnewb>WARNING: compilation of /gnu/store/xxx-guile-2.0.11/bin/guild failed <Gxsdnewb>ERROR: failed to create path for auto-compiled file <Gxsdnewb>i get this after hundreds of GUILEC gnu/packages/xxx.go <Gxsdnewb>hmmm, store.scm and nar.scm are the 2 tests that fail, preventing Guix compilation <davexunit>Gxsdnewb: are you compiling guix from git or from a release tarball? which distribution? which version of guile? <davexunit>Gxsdnewb: so you're running a guixsd system? <Gxsdnewb>trying to do a first install, but i did not run any git commands <davexunit>I think you are running into an issue that the binary substitutes for 0.8.3 are no longer available <davexunit>and thus you are compiling the entire system from source <Gxsdnewb>then it downloaded many tarballs and derivatives and started compiling everything <davexunit>Gxsdnewb: try running 'guix pull' to get the latest guix first. <Gxsdnewb>should i delete the downloaded tarballs and other data from my target first? <davexunit>but you should be able to do 'guix pull' and then proceed. <Gxsdnewb>so guix pull will upgrade guix in the live env, not the installed system, right? <davexunit>the idea is to get an up-to-date guix in the live env, and then install <davexunit>so all I can say now is good luck, happy hacking. <Gxsdnewb>it seems my / unionfs mount is full during GuixSD live system init <iyzsong>Gxsdnewb: oops, did you start the 'cow-store' service? and I think setup a swap may be helpful. <Gxsdnewb>oops i forgot that this time... how can i clear the cache (not sure it is called that) <iyzsong>Run 'deco start cow-store /mnt' will make /gnu/store copy-on-write, write to /mnt instead of memory. <Gxsdnewb>i have many duplicates cuz i tried guix system init & ewatchded it fail, then guix pull <iyzsong>run a 'guix gc' may help, but I'll just reboot.. <Gxsdnewb>now on second guix system init it appeared to download many newer tarballs that i have older versions already in unionfs ramdisk <Gxsdnewb>hah you suggest starting from zero? there is no way to detect duplicate tarballs and purge the older versions?? <iyzsong>do the install after 'guix pull', no tarballs (for build) is need. if you have a good connection to hydra.gnu.org, that should be easier -; <iyzsong>Gxsdnewb: run 'guix gc' will garbage collect all unused things in store. <iyzsong>yeah, you're right, that will delete all the tarballs, not only the old ones.. <fps>rekado: um, i think you better fix it :) still getting my feet wet with guix <fps>ERROR: now code for module (src guix build-aux build-self) <fps>guix build -L . -L ~/src/guix renoise <fps>that does something new :) <fps>hmm, and i cannot get rid of a "warning: source expression failed to match any pattern" <fps>since i still can't ssh into the vm ;) <fps>had some braces wrong,too <fps>oh, ok, the order might matter.. <fps>guix build -L ~/src/guix -L . renoise <fps>gives me a different error. that's progress i think <fps>and sometimes i'm just dense :) <fps>that's the output of guix build <fps>and this is ~/nonfree/packages/audio.scm <fps>also: there's no altruism. it's all rooted in egoism <fps>some people just think that cooperating and being more gentle makes the world a better place for themselves, too <davexunit>sneek: later tell avoine 'guix environment -e' works with lists now! <davexunit>now the big change is to make it so that you can choose which output to use. <davexunit>I guess I should just use the format for packages->manifest <davexunit>and that will pave the way to actually making profiles for environments. <davexunit>alright, got outputs under control in guix environment -e. now "out" is used by default, but users can specify additional outputs as well. <davexunit>I think I can just modify the last test I wrote <davexunit>civodul: there seems to be some limitation in 'lower-inputs' that prevents 'guix environment' from downloading *just* a specific output of a package. <davexunit>I have a tuple like this: ("qt" #<package qt-4.8.7 gnu/packages/qt.scm:236 342ee40> "doc") <davexunit>yet both the "out" and "doc" output were downloaded from hydra. <civodul>this is why we'll build a profile, eventually <davexunit>I now have the data in such a format that I can run it through packages->manifest and build a profile from it <civodul>the problem is that there's no way to tell the daemon to build just a specific output <civodul>it builds all the outputs of the derivation <civodul>but if you make a profile derivation, that derivation refers to specific outputs of its dependencies <civodul>so when you build the profile derivations, it will end up downloaded just those outputs <civodul>ACTION ponders again whether to keep syncing the C++ code with Nix <civodul>i was thinking that this may be post-0.9.0 though <civodul>but it's great if you can look into it anyway! <civodul>the main difficulty is that tests that looked at the output of --search-paths will need to be adapted <davexunit>I was hoping to do this without changing anything user-visible <civodul>yeah well, give it a try and we'll know ;-) <civodul>the only visible change is that --search-paths will show a single entry <civodul>that's not really a problem for users, normally <civodul>i mean just CPATH=/gnu/store/...-profile/include <civodul>instead of CPATH=foo/include:bar/include:baz/include <iyzsong>yeah, dbus-update merged, thanks civodul! <iyzsong>I have think about how to write importer and updater for GNOME packages. most GNOME projects have a XML doap file, it include the synopsis, description, etc. but for to get the latest tarball I think some ftp-list, walk is needed. <civodul>iyzsong: i was planning to generalize the FTP scanner that is used for GNU packages <civodul>Steap: BTW did you have a chance to look at a PyPi updater? <Steap>civodul: yeah, gotta merge some stuff first <Steap>was a bit sick this week, sleeping 12 hours a day did not help with that <Steap>got better, then got drunk to celebrate, and you should not use git when not sober :) <vanila>is there any plan to get full disk encryption into guix? <davexunit>vanila: guix master branch has support for it <davexunit>civodul: is it possible to build a profile for a given system type? <davexunit>it's looking like the answer is "no," but I want to check. <davexunit>'guix environment' currently lets the user build inputs for an arbitrary system type. <davexunit>I guess it could be made to work if the 'profile-derivation' procedure were to accept a #:system argument to pass to 'gexp->derivation' <civodul>davexunit: yes you could add a #:system there <davexunit>wee, 'guix environment' works with profiles now. <davexunit>there's clean up to do, but I hacked it in there. <karhunguixi>oh, ok. The wikipedia article for GuixSD says it's under development, so i figured it could be put in along with Arch and Nix. <davexunit>I think it would be good if the GUIX_ENVIRONMENT variable were a counter for how many environments deep you were. I frequently create environments within other environments. <davexunit>alright, now how to make a package from a bootstrap binary <efraim>guix environment --bootstrap as a starting point? <davexunit>efraim: that is the code that I'm working on bow <davexunit>now that I'm using profiles, I need the bootstrap bash in package form. <rekado>openblas built fine on mips. But the tests were skipped (why?), so we should not celebrate just yet. <lfam>fps: I took a look at Renoise. Of course, you should try a free alternative to proprietary software like this. I learned this the hard way years ago when I could no longer access "my music" that I had created with Reason. Never again. <lfam>fps: Anyways, you should not use the gnu-build-system for that. Take a look at trivial-build-system. <lfam>fps: And I think you will need to patch 'install.sh' to change FHS paths like usr/ to whatever the store path is <lfam>Damn it, I just ran `guix gc /gnu/store/m896vb8z529zakgcfsbgrh7s5gcqfvy0-Renoise_3_0_1_Demo_x86_64.tar.bz2` instead of `guix gc -d [...]` <lfam>Now Renoise is really on my shit list <lfam>I stopped it pretty quickly, thankfully. <efraim>28 minutes after the build phase, turns out aria2 has an undeclared dependency on cpptest for the tests <rekado>gah, this azr3 C++ stuff looks like gibberish to me. <lfam>efraim: Annoying! I usually contact upstream to ask them to declare these dependencies. Guix and Nix can help all the package managers in this way. <efraim>its on github, putting in a pull request will look good for my stats ;) <rekado>current status: learning C++ by randomly changing things and looking at the error message changing... <rekado>fixed(?) one error, created many more. <rekado>"error: void value not ignored as it ought to be", followed by a piece of code that is nowhere to be found in the sources. <Sleep_Walker>I didn't try to read whole context, but from my experience clang was generating much better error messages for C++ <rekado>bleh, I really cannot fix this. I know nothing about gtkmm nor do I understand what's wrong. There's pages of type disambiguity errors, but they are in expanded templates. <rekado>I think I know what the error means (namely that a value is returned when the function is declared void, or something like that), but that's caused by the "call_it" function in sigc's slot.h. <civodul>i'm not even convinced %azr3-build-error-patch helps <civodul>i think it was less verbose before that <davexunit>civodul: I'm trying to wrap the bash bootstrap binary in a package for use with a profile-based 'guix environment --bootstrap'. should the package I make be a special-purpose thing that lives in (guix scripts environment) or should I add it to the bootstrap packages in (gnu packages bootstrap)? <civodul>does it really need to be a package object? <davexunit>civodul: if I want to add it to a profile it needs to be, right? <civodul>but /bin/sh is not part of the profile, no? <civodul>yes, i think it shouldn't be in the profile <civodul>because /bin/sh is something "outside" what the user asks for <davexunit>but I couldn't find a nice way to deal with it. <davexunit>I changed 'build-inputs' to 'build-profile', but I think I'll change it to include the manifest and a list of additional derivations <davexunit>unless lower-object can lower a manifest for me <davexunit>which doesn't make sense to me, but I haven't looked at the code. <civodul>lower-object cannot lower a manifest <civodul>a manifest can only be passed to profile->derivation <davexunit>so I'll get that derivation, then cons it onto a list of other derivations <davexunit>which will usually be the empty list, unless it's a container <davexunit>works like a charm. just need to take of the --system option and address the --search-path tests. <civodul>i found a non-determinism issue in the daemon, an opendir/readdir thing <civodul>but writing the test turns out to be tricky <davexunit>we can still hold off from adding this to the 0.9.0 release if you want. <rekado>just installed libchop; when I run "chop-backup --help" bad things happen. <rekado>ERROR: Unbound variable: libchop-version <rekado>and it tries to compile itself (shouldn't this be done at build time?) <civodul>rekado: could it be that GUILE_LOAD_COMPILED_PATH doesn't point to $HOME/.guix-profile? <rekado>civodul: yes, that's probably the cause here. It's GUILE_LOAD_COMPILED_PATH=/run/current-system/profile/share/guile/site/2.0 <rekado>guix package --search-paths does not tell me that I should set GUILE_LOAD_COMPILED_PATH. I've set it now to include "$HOME/.guix-profile/share/guile/site/2.0". <fps>lfam: yo, i even once started writing my own tracker ;) <fps>lfam: but decided i'd rather make music while writing my custom software on the side than being competely unproductive <fps>lfam: anyways, that's a choice everyone has to make for themself <fps>lfam: on a different note though. renoise is good enough that it might be worth investigating if the community could free it :) <fps>i also considered moving away from a "UI" at all and did some experiments in that direction.. <fps>i.e. a directory hierarchy of text files, etc.. <fps>anyways, renoise is fun even if non-free <fps>lfam: thanks about the pointer about trivial-build-system. that's what i looked at first but it quickly led me to G-Expressions which i didn't want to tackle yet ;) <fps>lfam: but on a different note: what free tracker style software would you recommend? <Gxsdnewb>hello, i am trying to install my first binary guix setup with no substitues enabled, but gcc fails to unpack <lfam>Gxsdnewb: "xz: (stdin): Unexpected end of input" <lfam>Gxsdnewb: sounds like the file is truncated <Gxsdnewb>lfam: shouldnt it checksum the tarballs during download process? <Gxsdnewb>more importantly how can i fix this... i need to install my first packages <lfam>Try unpacking the file yourself and see what happens <Gxsdnewb>lfam i get many errors about an implausibly old time stamp 1970-01-01 00:00:00 <Gxsdnewb>when i run tar xvf on the /gnu/store/...-gcc-4.9.3.tar.xz file <Gxsdnewb>strange that i also have a ...-gcc-4.9.3.tar.bz2?? <lfam>Guix (and I assume Nix,too) sets all the timestamps back <lfam>Gxsdnewb: I assume in order to make the store more deterministic. <Gxsdnewb>so tar and xz fail at the exact same point in the file 