<HotLava>I'm trying to compile guix 0.9 on ubuntu 15.10 from source tarball, but it seems that the configure script fails to check for some required guile module? <HotLava>"ice-9/boot-9.scm:106:20: no code for module (json)" <detrout>HotLava: I believe guix needs guile json <HotLava>Then the installation instructions probably need an update, they pretty clearly say that it's optional <HotLava>but anyways, i think configure should check for the presence of guile-json in this case? <detrout>I think it became required when they released 0.9 <detrout>I don't know if that was intentional though <detrout>probably wont show up in ubuntu for several months though <HotLava>was just thinking i'd have to do it myself :D <detrout>its a pretty simple package so if you know how to use git-buildpackage it should build easily <HotLava>i'll admit that i always used debuild so far <detrout>for debuild you need to come up with the orig source. <detrout>you can grab it with pristine-tar or uscan or just download it <codemac>question about dmd + mcron -- does anyone use them together? <lfam>What's the best way to build from a local tarball? <lfam>I remember something on the ML about this recently <lfam>Oh, that was `guix build --file` which seems to be about locating a package definition. <lfam>Oh, just specify a "file://" URL. Easy enough. <lfam>sneek: later tell davexunit: I have lets-encrypt building and passing its test suite. There a few dependency bugs (filed) but it's time to whip the package definitions into shape. I'm curious about all the propagated inputs in the work you did. Do they need to be propagated or is that the approach you use for WIP packages? <mbuf>which distro do people here use with the guix package manager? <marusich>mbuf, I'm using GuixSD, but I think you can install the Guix package manager on any distribution, really. <mbuf>marusich, on which hardware are you using GuixSD? <marusich>mbuf, I am using an old Inspiron 1520 laptop <mbuf>taylan, and do you do Debian updates, or do you fully use only guix for package installs? <taylan>mbuf: I use Debian fairly normally, but when something is packaged for Guix too I'll usually install it from there <taylan>to have tested it, and often because Guix has newer versions <mbuf>taylan, which Debian do you use? <mbuf>taylan, I am currently using Ubuntu (not LTS), and I am not able to do any updates <mbuf>taylan, hence, thinking of moving to a distro that also supports guix <taylan>I often do dist-upgrade on Debian, generally doesn't cause me issues <mbuf>taylan, and you continue to get updates for stable? <taylan>Debian will even jump major versions when you do dist-upgrade. there's actually a lot that could theoretically go wrong but for a simple user and for my machine that doesn't do anything critical, it seems to be fine to just dist-upgrade. <mbuf>taylan, I'll try that on my Ubuntu system too <taylan>ah wait, that's not fully accurate, you have to edit /etc/apt/sources.list to get the packages for a different major release <ehvince>Hello there ! Is it possible to install from source without compiling all the 346 base packages ? (I tried, it's gonna take ages and I'd like only to try guix environment, container etc) Can I at least choose what to compile ? (I see the list of manifests in gnu/packages/ ) <marusich>I just followed instructions in the README of the Guix git repository and the Guix manual ("Building From Git"), and found that I needed to eventually invoke "./configure --with-libgcrypt-prefix=$HOME/.guix-profile/" instead of just "./configure". Any clue as to why I have to tell the configure script where libgcrypt lives, but I don't for any other libraries...? seems odd <jsgrant>marusich: I'm guessing it's because wherever your system is storing libgcrypt is not in the default path Guix is looking for? What distro are you using? <rekado>I thought a recent commit changed that. <fps>hmm, is the devel ML moderated or just slow? :) <jsgrant>fps: First post is just real slow, ime. <marusich>This is the first time I've tried building Guix. I've installed libgcrypt; I can see it when I do "guix package --list-installed". I don't know why the ./configure script failed without the additional option, but it did. It succeeded when I supplied the libgcrypt prefix option. <jsgrant>marusich: Well, I'm not sure what the issue would besides it being a problem with the path (I'm not very educated about autotools at all though) -- but I generally find it a bit odd that Guix wouldn't look for a default path like that. I remember doing such a thing (building Guix via GuixSD and having to use such a useflag) some time ago though too. Though, not via the local symlike and went directly to the /gnu/wha <taylan>needing to pass the libgcrypt prefix has been solved on the meanwhile I heard <jsgrant>marusich: Are you building from a git-release, or a release tag? <jsgrant>I don't even think the latter is the proper terminology. :^I <marusich>ehvince, as far as I know, it is only possible to request "no substitutes", in which case everything is built from scratch. If you don't specify that, then I think Guix just tries to use substitutes when possible, and builds otherwise. <taylan>AFAIK --no-substitutes can be passed per invocation of 'guix package' <taylan>ehvince: I think it should work when you first install those base packages with substitutes enabled, then use --no-substitutes for further installations <ehvince>Ok, just read the "substitutes" doc :) The make command wants to build everything, so I could tell it to use substituses instead right ? Is that doable ? <marusich>jsgrant, no, if git log is to be believed, I am looking at a recent commit, which is 7769 commits ahead of the commit tagged with "v0.8.3" <civodul>marusich: there's a "v0.9.0" tag on master <marusich>oh yeah, messed up my refspec stuff. It's actually "only" 122 commits. <ehvince>taylan: I do want to use substitutes at build time. marusich: apparently the make command will build everything. I do have the public hydra key. <fps>guixsd works fine in qemu-kvm, but not in libvirt's kvm.. it always crashes on net access there [libvirt that is, not guix] <taylan>ehvince: maybe I misunderstood what you wanted. what exactly do you want to compile from source? <ehvince>I try to install guix from the git repo. I ran ./configure, then make, but make will compile a lot of packages. I'd like to avoid that compilation but still use guix (for commands like environment, etc). <fps>oh, the good ole' "why is compiling all those package definitions so slow"? <taylan>ehvince: oh, do you just mean the compilation of the .go files? that's just byte-compiling the Scheme source code defining packages. <ehvince>ah :) because it took 45 to complete the letter 'a' , because I'm impatient ? :D <taylan>I have a patch which makes them compile a lot faster, but it's yet a dirty hack <marusich>civodul, using the commit at tag v0.9.0, I did not have to provide the --with-libgcrypt-prefix=$HOME/.guix-profile/ option to ./configure; the command succeeded without it. <fps>i saw parts of the discussion on the ML about it since signing up <ehvince>let's see :) But as you guys said, guix can use substitutes. Can we use them at this phase maybe ? I.e., download binaries from hydra instead of "just" byte-compiling everything. <fps>the quick answer is "no" <taylan>you can install guix from hydra ... when you have guix installed. :-) you can install an initial binary guix via the tarballs though. <ehvince>Ok, right for the tarball. But: maybe the compilation of those packages (python, zsh, abiword, haskell…) isn't needed to use guix (for commands like environment, container etc). Maybe I can keep that part (but couldn't make guix work yet). <fps>hmm, wasn't there lxc support in guix packages at one point? <taylan>ehvince: indeed, byte compilation of Scheme files is never necessary, strictly speaking. (they will be interpreted.) I'm not sure if there's a handy way to skip that phase of the build though. you could comment out some stuff in the Makefile in worst case. <marusich>I'm having trouble using geiser to find the place where certain procedures (or anything, really) are defined. For example, in $guix_git_repository_root/gnu/packages.scm, it seems that a procedure named "define-record-type*" is used to, I imagine, define records; however, I cannot seem to convince geiser to tell me where that procedure is defined. How do I do that? <taylan>ehvince: in the Makefile, there's a line starting with 'MODULES = ' and after a bunch of stuff it references $(GNU_SYSTEM_MODULES). if you remove that reference from there, then the .scm files from the gnu/ directory won't be compiled (including gnu/packages/). <ehvince>taylan- (i was saying:) I was afraid of that big Makefile, now I see lots of lines "gnu/packages/xxx.scm", so will try to comment that out, thanks. <ehvince>Do you think though that it can be a feature request to use hydra to download those packages with `make` ? Maybe we can build the minimal guix needed to fetch hydra, and then download packages. <civodul>marusich: yeah --with-libgcrypt-prefix is no longer necessary <fps>wow, the thunderbird has a hard time filtering on List-Id bug-guix.gnu.org <taylan>ehvince: that doesn't make much sense I think. the .go (Guile Object) files are part of the guix build, not stand-alone packages. a whole guix build can be substituted from hydra, but that requires a working copy of guix. the canonical way to avoid that chicken and egg problem is to use the binary tarballs. <ehvince>taylan "are part of the guix build, not stand alone packages" That may be part I was missing. I see better what you mean. I'm still confused, because "abiword", "haskell", "zsh" etc do seem like stand alone packages. <taylan>ehvince: those are just Scheme modules that define guix package objects. basically, the package database. <fps>taylan: just purely out of curiosity: is it hacky because compiling everything in one process takes a huge memory toll? <taylan>at first it's a bit unusual indeed :-) <taylan>fps: not really (compiling in parallel with several instances of Guile seems to take more collective memory). I'm bad at Makefile hackery and haven't sent that patch for review yet; still working on the one that will make 'guix pull' faster first of all. <taylan>well, I say I'm working on that one but I'm pretty clueless how to go forward actually :-) civodul ^ <taylan>I wonder why the firmware package needs to barebones compiler from the cross-base module... <fps>ok, maybe i'm still to ignorant though, but judging from the ML posts, that would solve the complexity explosion. maybe i just need to read more carefully ;) <civodul>taylan: the firmware in there is cross-compiled to Xtensa, which is why it needs cross-base <fps>so the hackery is the makefile, not the approach in itself.. <ehvince>Ok obviously I'm not comfortable here. But do we compile those scheme modules to build like a real abiword binary ? Is the final .go a binary ? In that case, why can we not take that binary from somewhere else ? (links to doc will be accepted ;) ) <fps>civodul: feedback on the gnunet talk: sent it along to buddies to watch, so they come to guixsd ;) <taylan>ehvince: nope, the .go is just Scheme byte-code that defines a module containing a couple "package" values (record types) in the Scheme programming language <taylan>ehvince: Guile compiles Scheme to byte-code for faster program execution. it can do that at run-time, but it's faster to precompile the byte-code into .go files ahead of time. like Python compiles .py files to .pyc, for instance. <taylan>or like how Emacs compiles .el files to .elc <civodul>taylan: re 'guix pull', maybe for now you could work around it by moving guix/scripts/*.scm compilation last? <rekado>ehvince: you don't need to compile the scm files to go files, but that would make guix quite a bit slower. <ehvince>aaaallright that makes better sense. Still, I'll check the docs on that because I don't get why we need abiword :) I'll try to tweak the makefile, and I may run 'make' tonight… <jsgrant>How big should a grub partition be? I'm trying to set up Luks for my root dir, and I'm pretty sure that means I'll need to istall grub to sda1 and have crypto set on sda2 and sdXY respectively thereafter. <taylan>ehvince: I think the confusion arises from the fact that guix's package database is just source code, and ships in the same repository as guix-the-program. in a conventional package manager, the program would be built, then it would download a package database from somewhere. in guix, the package database is baked into the source code so to say. hope that clarifies a bit :) <ehvince>taylan yes it clarifies again, well done. So isn't that a limitation ? Because some people, like me, are primarily interested in guix the program. I'll need packages, of course, to run my environments and containers, but not now. And not abiword^^ <jsgrant>Eh, forget it for tonight. I'm going to bed, and I'll mess with it later; Peace peeps. o/ <taylan>ehvince: after my patch, compiling those files won't take long. there's a couple reasons why the package database is shipped in the same repository. in particular it alleviates the burden of backwards compatibility. e.g. we could make the package description language nicer in some way, and edit all package recipes accordingly in the same git commit. <ehvince>taylan Interesting. I can be a tester of your patch if you wish :) An idea: what if we had a separate repo for the package list, but it would exactly follow the version number of guix ? (I'm ignorant of the other reasons) <taylan>something like that might solve some issues, but it could bring others, and would add some complexity... <taylan>my patch for the Makefile should land on the mailing list soon <Digit>oh, 0.9.0 was only out a week ago? nice. i've timed this well then. :) am @ 7.1.4 Proceeding with the Installation, at a leisurely careful pace. planning on playit safe, nothing too clever this time. (clevered myself out of making use of 0.8.0 around this stage.) .. will just continue with xfce & ratpoison when i wake up. no need to find other packages yet. bbiab, gni, zzz. <taylan>civodul: I now get the same error from the compilation of gnu.scm :\\ <alezost>marusich: geiser knows which variable is exported from which module, only for the "used" modules. So if you are working on a (guix packages) module, you can eval ',use(guix packages)' in geiser REPL, and Geiser will "learn" about the symbols used in this module <alezost>marusich: so you can use such commands as 'geiser-edit-symbol-at-point' or 'geiser-doc-symbol-at-point' on a symbol at point <marusich>I thought geiser automatically used the module I was browsing? <marusich>And what if there are tons of #:use-module (foo bar) lines in the file? <alezost>just use the current module, and those will be also available <alezost>marusich: btw did you also configure emacs stuff for guix with (require 'guix-init)? <alezost>if so you can use "C-c . u" to use the current module <marusich>I'm using GuixSD, which in /etc/emacs/site-start.el seems to do that already <fps>wow, that first post to the devel ML is really slow :) <alezost>marusich: yes, so in scheme files you can use "C-c . u" <civodul>taylan: so you build guix/* (minus guix/scripts), then gnu/*, then guix/scripts/*? <civodul>like what is currently done, i think <marusich>alezost, fantastic. now it works. I guess I didn't understand all the details. What is the syntax ",use(guix packages)"? I cannot find an instance of the string ",use" in the guile manual <taylan>civodul: well, with the default sorting that works, gnu.scm happens to be the first thing that's compiled <alezost>marusich: this is a guile repl command, you can write ",h" in a repl for the help <taylan>funny that it happens to work with the default/lexicographic sorting, since most other variants seem to fail <alezost>marusich: I think it is slightly documented at (info "(guile) Help Commands") <alezost>marusich: just in case: in emacs you can evaluate this (info "(guile) Help Commands") expression to get this manual page <andreoss>how do i fix suid on programms such as ping and sudo? <andreoss>and for guix in foreign environment i should just use system utiilities ? <taylan>civodul: moving only gnu.scm to the end seems to work, and fixes the progress-stalling-at-0 problem <civodul>andreoss: yes; files in the store must not be modified directly, but you could, say, make a hardlink to 'ping', and chmod +s that hardlink <taylan>ACTION posted the new patch to the ML <andreoss>civodul: i can't run services on foreign distro either? <civodul>andreoss: no, that's not a well-served use case <civodul>because running services requires integration with the init system, in general <civodul>and in the case of Xorg, there's some configuration involved <marusich>I ran "make check" after successfully running ./configure but some tests fail because guix-daemon fails with: "error while loading shared libraries: libsqlite3.so.0: cannot open shared object file: No such file or directory" <marusich>I notice that LD_LIBRARY_PATH is unset, and when I invoke "env LD_LIBRARY_PATH=/home/marusich/.guix-profile/lib /home/marusich/guix/guix-daemon --help" it starts up without the error. <marusich>I'm not sure why LD_LIBRARY_PATH is unset. Is that expected on a regular GuixSD install? <taylan>marusich: are you trying to run the guix-daemon in a newly built git repo without 'make install'? you should use ./pre-inst-env for that I think. <taylan>./pre-inst-env ./guix-daemon ... in the repo directory <civodul>marusich: you need to install "gcc-toolchain" for compilation, or simply use "guix environment guix" <rekado>LD_LIBRARY_PATH doesn't need to be set, usually. <marusich>I see. I have the git repo in /home/marusich/guix, and I was trying to follow instructions to package stuff. Which entails running /pre-inst-env, which seems to require ./bootstrap && ./configure && make check, which failed <marusich>I have guix already, so I guess I could have just done "guix environment guix" like civodul suggests <marusich>So, ultimately, I want to verify that my new package will build, without building it into my own /gnu/store, and my understanding is that the right way to do it was to run guix build via ./pre-inst-env <civodul>./pre-inst-env doesn't prevent it from using your own store <civodul>but there's nothing wrong with building to your store, nothing bad can happen ;-) <rekado>"without building it into my own /gnu/store" <-- a successful build will always be cached in the store. <rekado>you can remove it with "guix gc -d /gnu/store/....-the-output" <marusich>I'm reading "(guix) Packaging Guidelines". It seems to say I need to use pre-inst-env to test the build. Is that so? <rekado>pre-inst-env lets you use the source files directly. <marusich>Is that the only way? I'm not clear on the relationship between running ./pre-inst-env guix build ... and the "guix environment guix" command that civodul suggested <rekado>some of us have set ~/.config/guix/latest (?) to point at the git checkout. In that case there is no need to use pre-inst-env anymore. <rekado>"guix environment <pkg>" starts a shell session in which environment variables are set such that all declared development dependencies of <pkg> are available. <rekado>for "guix environment guix" you end up in a shell session where everything you need to build guix is available. <marusich>I see. So, I could do that to easily pull in all the dependencies I need in order to build guix and run pre-inst-env? <rekado>that's for the dependencies of the "guix" package. <rekado>you only need that to run "make", for example. <rekado>normally, I just do "./pre-inst-env guix build my-package" directly. <marusich>well, my fundamental problem was that I did not have a pre-inst-env <rekado>there is "pre-inst-env.in", which is turned into "pre-inst-env" after ./configure and make. <marusich>I had only a pre-inst-env.in, so I needed to build guix (or at least run ./configure; I'm not exactly sure when pre-inst-env gets created) to get pre-inst-env <marusich>It was a pain figuring out the dependencies. <marusich>From what I'm hearing, it would have been much less painful to run "guix environment guix" and then do the ./bootstrap && ./configure && make check <marusich>and then leave that shell session and then run pre-inst-env to do what I wanted <rekado>right. I think that's mentioned in the documentation, though. <marusich>I'm not so sure...I could have missed it, though./ <marusich>That's where I started, since I had a clone of the git repo. It doesn't mention anything about using guix environment if you happen to already have Guix available <rekado>The README has a "Requirements" section. <rekado>marusich: the README also talks about "Installing Guix from Guix", mentioning "guix environment guix" <ehvince>rekado yes yes thanks :) but I like to copy and paste a complete apt-get command. <marusich>Ah, yes, I saw that in the README. It talked about using my store, which I did not realize was "not a problem", so it was not clear to me that this was the way to do it without interfering with the Guix installation I already had, so it didn't occur to me that this was the right path. <marusich>Why exactly does it say to provide --localstatedir=/somewhere? This is the part that made me doubtful; I didn't want it to modify my system's stuff. <marusich>I just wanted to build the thing in isolation <rekado>$localstatedir/guix is where Guix keeps its state. If you just want to upgrade Guix from the binary release to latest from git you most likely want to keep the same localstatedir. <marusich>ehvince, that's a little different than what I want, but thank you for the link; it was still interesting to read. <marusich>rekado, I would like to build guix in my local checkout, and then use pre-inst-env to test the build for a package I want to add, without worrying about the pre-inst-env guix build command causing new stuff to appear in my actual local state dir (/gnu/store) <marusich>that seems to be at odds with what the README instructions suggest; it seems to be asking me to intermingle my newly built guix with the preexiting /gnu/store I already have. <marusich>I see from ./configure --help that --with-store-dir defaults to /gnu/store. I suppose I could pass in a path and perhaps the new guix that I build will simply think the store is empty, so it will either re-download and re-build all the things necessary to try building my new package, but perhaps it would be better not to worry so much and just let it use /gnu/store, where all the things are already. <rekado>if you used a separate store you'd have to download/build a lot of stuff anew. <marusich>I guess the worst that can happen is I successfully build stuff that has a unique base32 identifier in its path, which is orphaned and can be GC'd <rekado>all the inputs to your new package and their inputs and their inputs ... <rekado>when the build is successful you get a new directory in your store. <rekado>when the build fails ... nothing happens. <marusich>do I even need to use pre-inst-env to test my new package? <rekado>assuming that the package is located in the git checkout: yes. <marusich>why can't I just use the guix that's installed in my system already, but ask it to use the new package I've defined? <rekado>actually, that's what ./pre-inst-env does. <rekado>it just sets a couple of variables such that the guix in the current directory is being used. <rekado>if you had a separate guile module containing your package definition you wouldn't need ./pre-inst-env at all. <HotLava>is there a plan to separate guix itself and the guix packages into separate git repositories at some point? <rekado>you could add the path to your custom module to GUIX_PACKAGE_PATH and use guix without ./pre-inst-env. <rekado>HotLava: there is currently no good reason to do that. <marusich>My understanding is that pre-inst-env arranges for me to use the guix and all the modules from the checkout, rather than the system. If I run "guix build" without pre-inst-env, then I'll be using the guix that's installed locally, and it'll be relying on whatever package definitionsn are on the system, outside my checkout. <rekado>HotLava: anyone can create new separate "repositories" containing custom packages and use them by adding their path to GUIX_PACKAGE_PATH. <HotLava>faster build time would be one reason <rekado>HotLava: in many cases it makes more sense, though, to just contribute to guix upstream. <rekado>HotLava: only the first time around the build is very slow (that's soon to be fixed IIUC). <rekado>HotLava: the next time you update you'll already have a lot of compiled modules and you just need to compile the changes. <marusich>rekado, so if I wanted, I could make a module which defines my new package that looks similar to python.scm, add the directory where it lives to my GUIX_PACKAGE_PATH, and then do "guix build" to test the build using the local guix and the local /gnu/store. <marusich>Then I could move the change into python.scm. <rekado>if you want to add it to python.scm anyway, then I'd suggest just performing the change right there. <rekado>you could go the GUIX_PACKAGE_PATH route, but I fail to see what advantage this would bring you. <rekado>I only use GUIX_PACKAGE_PATH for stuff that I'm sure will not be added to guix upstream. <marusich>If I have a local checkout, and I modify python.scm, then set GUIX_PACKAGE_PATH to the directory in my local checkout containing python.scm, would that work, also? <rekado>I don't know. Why not use pre-inst-env instead (because that is known to work)? <marusich>Or, if I want to make the change to python.scm in my local checkout (e.g. to make sure what I submit as a patch will in fact work when built for real), will I have to use pre-inst-env to arrange for the new python.scm to be used by guix? <marusich>Sounds like that's probably the better option <marusich>Ultimately this is what the README and the Manual suggest, but it was not clear to me why it was the right thing to do. <marusich>I see now why it is, and why it is not really a problem for the newly built guix to use things from and deposit things into my local state dir <HotLava>rekado: sure, but as the number of packages continues to grow, the overhead will become bigger and bigger <rekado>HotLava: we'll worry about that when it happens ;) <rekado>there's nothing stopping anyone from having their own separate repository of package definitions, as Guix users can fetch it and add to GUIX_PACKAGE_PATH to use it. So far it hasn't been an issue to motivate such a development. <HotLava>i'm not concerned about having additional packages, i asked because it already increases the build time on a fresh checkout from like 5 minutes to several hours <rekado>HotLava: there's a patch in the works on the ML to fix this. <rekado>compile times are one of the reasons why few (if any) Guix developers use "guix pull". <wingo>ACTION really looking forward to gnome on guix <fps>how hard do you think would packaging KDE be? <wingo>ACTION does not know anything about kde <fps>afaik it's all cmake based these days. might give it a shot sometime soon <fromRaw2Iso>As my pseudonym may suggest, I'm willing to get a *.iso file from the raw partition image GuixSD. <civodul>fromRaw2Iso: it's a raw image that can be copied as-is to a USB storage device <civodul>so it includes a partition table, MBR, and a partition containing the system <fromRaw2Iso>Thanks for your response :) but actually I'm trying to get it mounted into a vm <fromRaw2Iso>hence my need for a way to get an mountable iso of GuixSD <civodul>with QEMU, you can run, say: "qemu -enable-kvm -hda the-image" <civodul>i think fps had put together instructions to do that but i can't find them <piyo>you mean you want to boot a vm with guixsd-usb-install-0.9.0.xz? <civodul>not sure what it's doing in "guix-non-free", it's talking only about free software AFAICS <karhunguixi|w>i think his idea is to have one wiki regardless of licensing issues <taylan>wingo: thanks for the help :-) new patch sent <wingo>ACTION was looking at the guix pull thing, thinking "hoo, mark is not going to like this" ;) <mark_weaver>ACTION is unhappy about "guix-non-free" being promoted here <wingo>dunno, you taught me not to use it <sneek>davexunit, you have 1 message. <sneek>davexunit, lfam says: I have lets-encrypt building and passing its test suite. There a few dependency bugs (filed) but it's time to whip the package definitions into shape. I'm curious about all the propagated inputs in the work you did. Do they need to be propagated or is that the approach you use for WIP packages? <mark_weaver>oh, well, there's nothing inherently wrong with "guix pull" as an interface. it's more about the current implementation. <mark_weaver>I suppose that Trisquel and Parabola haven't had to cope with the emergence of non-free stuff being promoted in their fora because of course there's Ubuntu and Arch. <civodul>nobody was really promoting it, it just happens the the useful doc is kept along with the non-free stuff :-/ <civodul>we should make it a section in the manual i think <davexunit>can we get that useful doc into our manual so we don't have to link to that other place? <civodul>i would put that after "System Installation", i guess <mark_weaver>well, fps was also recently promoting another IRC channel for discussion of non-free guix stuff. <davexunit>pretty sure that some of us discouraged such things after it happened. <civodul>davexunit: BTW, if could start looking into using profiles in 'guix environment', now that the release is behind us <civodul>so if/when you want to discuss it, don't hesitate <davexunit>civodul: okay. I already have a working patch. <davexunit>but the feature already works and I haven't noticed any regressions <civodul>so we'll figure out a way to update the tests <civodul>maybe just things like [ -f $LIBRARY_PATH/foo.h ] <civodul>instead of grepping through the output of --search-paths <andreoss>i/o error: /gnu/store/aa5rn82hxjh3rxmcc77vwjq6nkl0klhi-grub-image.resized.png: No such file or directory <civodul>andreoss: how did you get that error? <civodul>you need to provide a bit of context ;-) <civodul>people were too impressed to comment i suppose <andreoss>guix system init /home/andreoss/dev/guix-system.sch /mnt/ <taylan>heh, maybe we need more "propaganda" <civodul>andreoss: does the file in question exist? <andreoss>though i might be doing something stupid, i have /mnt/gnu binded to /gnu <mark_weaver>civodul, davexunit: I'm not sure if this is what you're talking about, but I would like an easy way to add the build dependencies of a package to a profile, e.g. to add everything needed to build 'guix' to my profile, or create a fresh profile for developing some package. <davexunit>mark_weaver: that's what we're working towards. <davexunit>the first step is a patch I've written but not submitted that creates profiles on-the-fly for 'guix environment' <davexunit>from there, we can add new features to save an environment profile somewhere, protect it from GC, etc. <mark_weaver>I would like there to be a way to add to an existing profile, not just creating a fresh profile. <mark_weaver>andreoss: bind mounting /mnt/gnu to /gnu sounds very wrong <andreoss>changing /mnt to something else didn't help either <civodul>andreoss: the bind-mount from /mnt/gnu to /gnu may have broken things <mark_weaver>andreoss: "guix system init" assumes that the /gnu/store on the target is a different store than the one on your current system. <andreoss>civodul: do you mean that /gnu not supposed to be bind-mounted at all? <mark_weaver>each store has its own sqlite database keeping track of what's present in that store, and the store items are copied, etc. <mark_weaver>it's really bad news to have them aliased to the same thing. <mark_weaver>I would be very surprised if that doesn't cause problems. <davexunit>andreoss: surely our documentation doesn't suggest to do this? <mark_weaver>I would delete everything in /mnt and rerun "guix system init" <andreoss>i thought /gnu/store is just a repo, and all system-dependend stuff go to /var/guix <andreoss>i can't keep /gnu/store on my current / because it to small <davexunit>the documentation recommends you start the cow-store service <andreoss>i'm still on debian, so i can't run that <mark_weaver>andreoss: you can bind mount it to somewhere on /mnt, but not /mnt/gnu <mark_weaver>/mnt/XXX where XXX is something that would never exist otherwise <andreoss>so basically i won't be able to use single shared /gnu/store for bunch of machines <mark_weaver>andreoss: /gnu/store could be shared read-only, but it can be only be written to from a single guix-daemon instance running on one machine. <mark_weaver>but that would mean that the people with only read-only access to the store can't even do things like modify their profiles locally, because modifying a profile (e.g. adding or removing packages from their profile) involve adding things to /gnu/store <mark_weaver>in theory it could be done by having a central server with guix-daemon running on it, and all the clients talk to the single daemon, but I'm not sure if that's currently working in practice. rekado might be able to tell you more about that. <mark_weaver>I seem to recall rekado was trying to do something like that, but I don't know what's the current status. <mark_weaver>andreoss: if your / is small, maybe bind mount /gnu to something in /home or /usr ? <andreoss>> Path `/mnt/ROOT/boot/grub' is not readable by GRUB on boot. Installation is impossible. Aborting. <andreoss>should i bind /boot to /mnt/ROOT/boot here? <rekado>yes, I'm doing something like that: one /gnu/store that's mounted on all clients via NFS as read-only. The localstatedir must be exported as read-write, though. Only one server runs the daemon and can write to the store. <mark_weaver>if /boot is Debian's boot partition, and you want to preserve it, then probably not. <rekado>clients can talk to the guix-daemon via socket. <mark_weaver>andreoss: can you think of a reason why GRUB would have trouble figuring out how to mount /mnt/ROOT at boot time ? <mark_weaver>rekado: do you know why localstatedir must be exported as read-write? that seems suboptimal, and I'm not sure why it would be needed. <rekado>mark_weaver: to allow users to modify their profiles. <mark_weaver>andreoss: is /mnt/ROOT running on LVM? is it encrypted? what filesystem type? <rekado>I haven't set it up like this right now, but I don't like the limitations we have in place. Maybe by the end of next week we'll actually have user-managed profiles from more than just one location. <mark_weaver>yeah, section 7.1.1 (Limitations) of the guix manual says "Support for the Logical Volume Manager (LVM) is missing." ***jgay_ is now known as jgay
<fromRaw2Iso>thanks for the links and your replies, I gonna read them. <fromRaw2Iso>hmm, weird, I execute that command: `qemu-system-x86_64 -hda guix.qcow2 -hdb GuixSD/guixsd-usb-install-0.9.0.x86_64-linux -boot menu=on -m 4096`, then I select second boot choice, grub appears and few seconds later the fonts and cli become... inconstistent then frozen <civodul>mark_weaver: right, no LVM support for now <civodul>fromRaw2Iso: look like this QEMU is broken <fromRaw2Iso>The CLI seems responsive however the display is... blur / not readible. <fps>wow, that ML is really super super slow <fps>i suppose the first post gets moderated maybe? <fps>oh this post on the ML of ladspa.org not being accessible anymore: maybe it would make sense to autocheck the DL links for packages via guix lint? <fps>or maybe it does it already <fps>should be a breeze in scheme <fromRaw2Iso>hmm, weird. It bugs with Qemu but once you turn it into a vmdk image, VirtualBox runs it smoothly (and without that annoying graphical bug) <bavier>fps: guix lint already has such a check <fromRaw2Iso>One may be willing to add that command in the doc: ` qemu-img convert -O vmdk guixsd-usb-install-0.9.0.x86_64-linux guixsd-usb-install-0.9.0.x86_64-linux.vmdk` <fps>bavier: ok, then it might be worth setting up a cronjob on a box that regularly checks all official package DL links? <bavier>fps: perhaps; at the moment I think we're relying on people to occasionally run lint manually <davexunit>it would be pretty easy to map over all packages to grab the source URIs and then HTTP GET the headers <fps>davexunit: or even download them and check the hashes <fps>doesn't have to happen daily (bandwidth) <davexunit>checking that all source URIs pass a very simple health check sounds worthwhile, though. <bavier>davexunit: this is what guix lint's 'source' checker does already <davexunit>but I'm talking about doing it all for *all* source URIs <fps>fromRaw2Iso: does the same happen with qemu-kvm? <bavier>davexunit: yeah, just don't give 'guix lint' a package argument <civodul>davexunit: in theory "guix lint -c source" does that, but in practice it stalls after some time, notably because there's no timeout when opening connections <fps>fromRaw2Iso: the freeze i mean <davexunit>bavier, civodul: I didn't realize that guix lint can operate on the entire package list like that <civodul>when we fix that timeout issue, i would like to have a job that generates an HTML report <civodul>so we could all look at it and fix things periodically <civodul>but yeah, the thing had to be robust enough <civodul>if we have a cron job that runs it every day, and if we guarantee that it won't take more than, say, 30mn, that's fine IMO <civodul>OTOH it's indeed embarassingly parallel <davexunit>oh, would this not download and check hashes? <davexunit>checking headers would be much cheaper, yeah. <fps>if you do it often enough you might get 302 not modifieds <fps>which has more info than just a 200 <civodul>davexunit: it's cheap, but it also misses some issues, as in the case of DNS squatting <davexunit>but a baseline test that we can improve with time sounds good <fps>some experience from working in web scraping: <fps>if many projects are hosted on the same hoster: <fps>the web server might stop responding to requests after a while <fps>and then you get into stuff like randomizing and distributing the queries over time <fps>which is not fun at all <fps>but i suppose that might be more of a problem for the news sites we usually scraped than open source software hosters ;) <rekado>seen on emacs-devel: "official Emacs Docker image" --- argh! <davexunit>guix environment --container --ad-hoc emacs -- emacs <rekado>must remember to reply to this thread tonight <fps>oh, my mail made it to the list. i just missed it.. all good.. <davexunit>fps: note that the archives are updated on a delay. <efraim>the libvpx update I pushed earlier seems to not be playing nicely with ffmpeg <HotLava>How would I go about debugging such an error? <HotLava>bennoe@hydra:~$ guix package -i hydra <HotLava>guix package: error: lua52-liblua-so.patch: patch not found <efraim>give me a sec to find the commit <efraim>the patch wasn't referenced when it was pushed, so that was fixed this morning, so you'll have to refresh through guix pull or git pull, depending on how you're running guix <fps>soo, if i have a build that just uses gnu make, should i use the gnu build tools and disable the unneeded phases? <fps>i suppose just deleting the configure phase is enough.. cool <taylan>fps: yeah, that's the best way to do it AFAIK <ehvince>Hi ! A second connection in a day, mmh I'm getting used to it :) I wanted to ask: is there a Debian package of guix (the program) underway ? Is that illusory ? <ehvince>Hi sirgazil :) I really wonder why, then. Guix's getting closer to v1 and still no debian package O_o <ehvince>Hell yes ! Because it's a pain to install guix by source or from a tarball. <sirgazil>ehvince: DId you tried the binary install? <ehvince>That prevents users from getting to it (it retarded me from several months and still, compilation didn't finish…) <davexunit>debian will not accept a guix package because we do not conform to the FHS <ehvince>I tried that a few months ago, with no success (dependency hell, guix daemon groups mess, also not wanting to install globally with make install). <ehvince>davexunit: we could at least have a .deb somewhere couldn't we ? <davexunit>it's not a priority for us because we use guixsd and don't know how to make debs <davexunit>but we'd definitely accept a patch that added a way to produce a deb or rpm or whatever else <ehvince>(and since I'm new to guix and I don't know the internals, it's gonna be difficult for me. I was hoping you had talked about it on the ML) <detrout>davexunit: My hunch was it'd be easiest to build a debian package around the guix source tree's make install <ehvince>Ah. Was there an interest or technical reasons not to do it ? <detrout>ehvince: I bet their busy making guix packages <davexunit>there just needs to be a motivated volunteer who wants that. <davexunit>I don't want it because the binary installer takes me only a couple minutes to do. <ehvince>no objections, no particular difficulty in view then ? Cool, I wanted to hear that. <davexunit>and I run guixsd on most of my machines so a deb is becoming increasingly useless to me. <ehvince>A couple minutes ? I should try it again then ! (would be cool than a debian installer could use the binary install then) <sirgazil>ehvince: Try installing guix again using the binary installer. It's quite easy. <detrout>ehvince: Debian ftp-master wouldn't accept something built from someone elses binary <detrout>out of curiosity why does the binary installer just install the guix command in the root profile? <detrout>Assuming the binary installer is for people not running guixsd <detrout>debian id very picky about only accepting things that have source available <ehvince>(davexunit: and be more active on Diaspora :) ) <davexunit>detrout: because we need a user profile to put the guix package into so that it doesn't get garbage collected <davexunit>the docs then recommend symlinking the guix binary to /usr/local/bin or wherever you want for other uses to bootstrap their guix profiles with. <bavier>I just did a binary install last night on trisquel and it only took a few minutes <bavier>I had tried building the daemon with gcc 4.6.3, but then thought I'd try the binary install instead <amz3>hello, with my x60, I can't run 'guix pull' the computer freeze because of overheating I assume <amz3>how limit overheating? I've read people use only one core to avoid issues <fps>amz3: do you get an error? <amz3>I had an error the time with the software having no tests, right now I' recompiling guix to be able to run the install properly <amz3>well, i did not test that package yet <amz3>but guix lint did not complain <fps>amz3: let's hope for the best, then :) <amz3>i started another patch, about python-cffi, but the thing is complicated <amz3>it's related to ffi in python <amz3>they changed how the cffi library works, and it has impacts on guix package <bavier>amz3: check argument alignment in the origin uri <bavier>amz3: also, the description is a sentence fragment <bavier>amz3: the synopsis could be more concise: "Optimize JPEG images" <codemac>anyone here have cert issues with git installed as a guix user? I can't clone anything with https because it complains about now having a CAfile. 
