<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?
<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?
<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
<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"
<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
<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>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?
<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>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 ...
<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.
<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.
<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.
<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'
<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.
<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