<OriansJ>Finally finished the hex compiler that only depends on a 93 byte Monitor bootstrap [Nop padding and Bootloader magic number make it 512 bytes], I need only to manually convert it to hex. <efraim>Qtbase with examples disabled, python-wrapper instead of python2 and parallel builds enabled, dropped my build time from 6 hours to 80 minutes <marusich>civodul, have you noticed any emails go missing from the archives for help-guix before? I seem to have emails in my inbox with help-guix in the CC list, but they don't show up in the archive. <marusich>These are the two ends to the two split ends of the thread: <marusich>I guess they're both there. The archive tool doesn't seem to make the split very obvious, is all. <civodul>do they both appear in threads.html? <civodul>threads.html is not very helpful for deep threads <marusich>It seems to show the threading for one path through the conversation <marusich>In Threads.html, you see A -> B -> C, but it's possible that if you click on C, you might not see B <marusich>I'm not making much sense, but at least the emails are all there :) <civodul>this interface is sometimes confusing, especially with deep threads! <marusich>But yeah, it's all there, so I guess it's OK. <marusich>Thanks for entertaining my question. sorry for the distraction! <ArneBab_>civodul: would it be feasible to adjust guix to work without setup? i.e. starting a daemon on demand and using ~/.local/gnu/… and the currently active user if it’s missing the daemon? <ArneBab_>I know that it would lose protections that way <ArneBab_>but it could provide graceful degradation <ArneBab_>(I don’t mean if someone would do that for me, but rather whether that would be something I could hack when I have some time) <civodul>the (half-)solution to that would be user name spaces in the daemon <OriansJ>civodul: There is also the potential problem that some people don't want to ever build any packages and thus desire a minimized version of guix that simply provides the end user facing features via say ~/.guix or something similiar <civodul>OriansJ: that'd be nice, but since binaries are not relocatable, i don't see any easy way to achieve this <civodul>0install does that, but it relies on the ability to make packages relocatable, IIRC <rekado>is it necessary to use the full path to dependencies in the RUNPATH? <rekado>could this be relative to the current location of the package instead? <rekado>or would it be an option to have a separate lookup table, implementing some sort of ld cache? <rekado>wouldn't this give us an easily relocatable store? <roelj>rekado: Do you mean the path that is embedded in a binary? <civodul>rekado: relative to the current package location wouldn't help <civodul>but anyway, the main issue is that build systems and software would need tweaking all around <civodul>for instance, it is commonplace to embed installation file names in binaries <civodul>so RUNPATH is just one instance of the problem <rekado>I'm currently updating R packages again. The most time-consuming part is to write the commit messages. I think I should write a little Emacs command that does the work for me. <civodul>it would make sense to automate this kind of thing <civodul>ideally a patch queue manager would take care of merging things automatically <rekado>I have a couple of patches that add recursion to the CRAN importer. <rekado>cosmetic question: my patch enables this feature when the "--recurse" option is added. Is this a good name for the option or should it be something else? <rekado>also: can we provide short options as well? <civodul>i guess this would be applicable to many/most importers <civodul>but let's make it R-specific to begin with <wingo>whoops, meant for that to be to guile <wingo>it's a scheme implementation of ports <wingo>i meant for it to go to (ice-9 ports) but there's something else there in master <avoine>if I used guix build --with-sources=transitive ... a "guix gc" will remove the source of the packages? <davexunit>avoine: that has nothing to do with what the GC will do <ArneBab_>civodul: so it wouldn’t be possible to use binary packages when the files were in ~/.local/gnu instead of /gnu? <ArneBab_>so, going there would mean that people who don’t have /gnu would always have to rebuild everything? <ArneBab_>that would be quite a degradation, but it wouldn’t void the packaging features of guix <civodul>but then people would build with little or no isolation, which would be pretty bad <ArneBab_>“if you don’t have it setup right, it will build every package from scratch. To make that faster, follow the setup in …” <ArneBab_>it would be as unsafe as building from source locally, right? <civodul>right, but it would void your warranty, basically :-) <civodul>that is, i don't wanna have to deal with bug reports of things that don't build correctly in such an environment <ArneBab_>“in case you experience bugs, write to WARRANTY_VOIDED, follow the setup on … before reporting any bugs” ☺ <davexunit>if more distros would enable unpriviliged user namespaces by default, it would at least be easier for users to get build isolation <davexunit>they'd still have to build everything from source because the store directory is different <davexunit>but they'd have build isolation, so in theory the only real issue that could arise is if the store directory name is too long <ArneBab_>The core reason why I’m thinking about this is that having the option to run the daemon on demand would allow using guix as a no-setup distribution system. <ArneBab_>that would for example have helped a lot for lilypond right now: instantly working recipe for building a Guile dev environment. <ArneBab_>civodul: if I were to do something along these lines (along with WARRANTY VOIDED notices), would it have a chance to get accepted in Guix? <civodul>it's already possible to run "guix-daemon --disable-chroot" <civodul>it just that then you start building the world, and at some point it fails to build ;-) <rekado>looks like the cached python2 binary is broken: <rekado>could be a local network problem <rekado>it aborts after 10.2MiB transferred <rekado>I'll ask the fileserver person to disable ZFS compression. Maybe that'll make things fast enough. <rekado>I wonder if access via Samba would be possible and better. <avoine>i'm having random gzip corruption errors here not sure if it's related <civodul>avoine: could you paste the command and log? <efraim>you can also run `guix package --fallback -u guix' <ArneBab_>civodul: along the lines of “when I run guix environment and there is no daemon, just spawn a daemon without chroot” <ArneBab_>(or rather: just spawn a daemon with options which make it work without setup) <ArneBab_>(but with big warning messages which tell the user to setup Guix cleanly for any serious work) <civodul>ArneBab_: no, this would be impractical, too many issues <civodul>avoine: ooh, this one is interesting <avoine>civodul: it's an old guix setup on an ubuntu machine, maybe I should just delete the /gnu and start over <avoine>yeah, I got weird error with --fallback: while setting up the build environment: executing `/gnu/store/9w0wjz9svag6pmcji1p9xwk1f7fccf82-bash': Permission denied <avoine>builder for `/gnu/store/sjxy8sqdrwyclbx5axi2x338qkc8bvxs-guile-bootstrap-2.0.drv' failed with exit code 1 <avoine>civodul: guix gc --verify output nothing should I try with: --verify=contents ? <avoine>civodul: found it, it was my ~/.config/guix/latest that was pointing to my old guix fork, sorry for the noise <avoine>what would be the best way to test a guile module before submiting it as a patch? I tried: guix environment --ad-hoc -l g-wrap.scm -- guile and in the repl: ,import (g-wrap) but no luck <davexunit>without it, you won't get the proper search paths set <avoine>davexunit: should it work like that? guix environment guile --ad-hoc -l g-wrap.scm -- guile <davexunit>what that command is saying is that you want the *dependencies* guile + the package that g-wrap.scm evaluates to <avoine>I forgot native-search-paths ... <avoine>I must have forgotten something else because I can't get it to be in guile's %load-path <avoine>I'm testing it with: guix environment --ad-hoc guile -l g-wrap.scm -- guile -c "(display %load-path) (newline)" <daviid>avoine: g-wrap is usually installed in guile/site, not guile/site/2.0, as and aside gnome-2.scm, cairo.scm ... iirc, g-wrap, guile-cairo and guile-gnome compile fine with guile-2.2 <daviid>avoine: not sure why you have all these replace 'configure 'rules'? are these really necessary? <kraji>hello! what is the most popular de/wm in GuixSD <kraji>ratpoison, i3, guile-wm, gnome, enlightenment, windowmaker <kraji>openbox, fluxbox, bspwm, dwm <avoine>hi daviid! yeah, there was too much rules but I need the "/bin/sh" substitution because I get this error otherwise : configure: error: cannot run /bin/sh build-aux/config.sub <avoine>now I have the module in ...-1.9.15/guile-g-wrap/share/guile/site/g-wrap/ but it's still not showing up when I do: guile -c "(display %load-path) (newline)" <avoine>I mean /gnu/store/zvgdd2d0318di8x98p3mm29az46rf42x-guile-gwrap-1.9.15/share/guile/site/ <daviid>avoine: I don't understand that sh bug, it does not happen here [without guix]. then the location is not 'standard' [not sure this is imposed by guix], it should be installed in guile's subtree <daviid>avoine it should be installed here: guile -c "(display (%global-site-dir)) (newline)" <daviid>if you change that, you have to read note (3) [of the g-wrap website] <daviid>"G-Wrap's modules will be installed in $prefix/share/guile/site. If it differs from Guile's global site directory, then this path must be aded to Guile's load paths before to use G-Wrap and compile Guile-Gnome or Guile-Clutter" <avoine>I've put it in share/guile/site/ but guix should do the rest and add it to %glocal-site-dir I think <daviid>avoine you have to check the $prefix <avoine>maybe this is related -> /tmp/nix-build-guile-gwrap-1.9.15.drv-0/g-wrap-1.9.15/libtool: line 1085: ldconfig: command not found <daviid>if the $prefix is _not_ the one where guile is installed, then it won't find g-wrap [this is expected] until you augment the %load-path <avoine>the prefix is : /gnu/store/v83p9qljhwk7jh1g63mxpfrnslhwhkin-guile-gwrap-1.9.15/ <avoine>or this sh: indent: command not found <daviid>avoine: that prefix is _not_ the one guile itself, so, you have to read the 3rd note of the website and choose one of the 3 methods at your disposal to augment guile's %load-path <daviid>avoine: what you just wrote here above, you may ignore <daviid>sh: indent: command not found this can be ignored <daviid>the libtool error, that's not good <daviid>but that's guix, I mean some deps are not satisfied maybe? here [debian] the tarball pass the autool danse: ./autogen.sh --prefix=/opt [using the source, or ./configure --prefix=/opt if you start using the tarball ]; make; make install <daviid>avoine: ^ of course the --prefix=/opt is optional I just use this one so it's a bit automatic for me to write the configure call this way... <daviid>ok. does it pass the configure step in guix then? or does it report a missing bit, libtool... <daviid>avoine: I'm recompiling from the tarball here to make sure everything is fine here <avoine>daviid: it report the missing ldconfig but the build successed anyway <daviid>avoine: you should fix the missing tool first, distclean and try again <daviid>you should not have special configure rules, imo, or report and I 'll change the source code <daviid>making a guix package for g-wrap should really be easy, if I may say so <kyamashita>I've managed to manually build a few of the android-tools binaries. Namely, mkbootimg and adb. <kyamashita>I'd like to package this for Guix while waiting for a stable Tor Browser bundle version 6, but it requires a bunch of arbitrary gcc and g++ invocations. <kyamashita>I'm not sure what the best practice is for this in Guix. <bavier>kyamashita: are the gcc invocations to work around bugs in the build system? <kyamashita>bavier: The gcc invocations /are/ the build system. Every android-tools package I've seen manually calls gcc and g++ and links the binaries together. <kyamashita>bavier: I noticed that crossguid (from kodi.scm) does this, but only for putting together a small test binary. <bavier>kyamashita: oh, then that's probably fine <bavier>ISTR other instances of the same <daviid>avoine: what does return guile -c "(display (%global-site-dir)) (newline)" on your guix installation? <avoine>daviid: /gnu/store/hyk2i7b8mwbrbiyqk5sgrfgds9zvcrn5-guile-2.0.11/share/guile/site <daviid>avoine: imo, that is where you want to install the guix g-wrap package, so guix user won't have to worry about guile's %load-path <daviid>avoine: and the g-wrap guix package _must_ make sure the user has all dpenencies satisfied, so the g-wrap package should fail to install otherwise <kyamashita>bavier: And I assume I'd either be using the trivial-build-system, or modifying gnu-build-system phases. <daviid>avoine, grabbing this ' guile -c "(display (%global-site-dir))' in a 'special configure' guix package 'rule' to pass it as the g-wrap $prefix value would be a good default, imo <LnL>I'm trying to setup guix with a local clone but I can a whole bunch of "source file ... newer than compiled" messages, is that normal? <LnL>is there som way to use a local dir for the compiled files (guix is trying to use *.go file from the store) <avoine>daviid: I think guix supports only putting modules in .../share/guile/site/2.0" <daviid>avoine: that does not make sence to me. then, these '.../' should be, by default, the guile installation prefix ***kelsoo1 is now known as kelsoo
<bavier>kristofer: currently guix supports ARM only as a package manager on top of another distribution <kyamashita>IIRC, the Google's official Android SDK is not free software? <avoine>I suspect the --with-modules-dir to not be working for setting the module path <daviid>avoine: yep this is not correct indeed <daviid>avoine: what does this exands to? (string-append "--with-modules-dir=" <daviid>avoine: the g-wrap configure option is --prefix=, not with-module... <avoine>daviid: something like /gnu/store/flzw33596y2ayb088905s9jd3fbzi2i6-guile-g-wrap-1.9.15/share/guile/site/2.0/ <daviid>avoine: so, once more, this is _not_ what you want <daviid>in your package, why don't you immediately refer to the guile function? <daviid>(string-append (%global-site-dir) "/" ...) <daviid>put that in prefix, and remove with-module... <avoine>my %load-path looks like this: /gnu/store/facm7k3fwzcgfy8f69l0p94lfb4nfm4s-guile-json-0.4.0/share/guile/site/2.0 /gnu/store/8nc54gwad0ilz8kywrmd71ichxn09a2l-gnutls-3.4.5/share/guile/site/2.0 .... <avoine>so I think guix is adding the path there at the installation <daviid>avoine: I don't know, you'd have to ask guix folks. but, I don't se why you are not doing this: <daviid>(string-append "--prefix=" (%global-site-dir)) <daviid>just that, remove (string-append "--with-modules-dir=" ... <daviid>hum, sorry that would be too 'big'. you need to grab the $prefix of guile, the prefix only, which is guile-2.x-pc <daviid>pkg-config guile-2.0.pc --variable prefix <daviid>that must become the prefix value for g-wrap <davexunit>but I don't quite understand what you're talking about <davexunit>I would just compare GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH to where the g-wrap package is installing its modules to <daviid>which you should set to pkg-config guile-2.0.pc --variable prefix <daviid>or pkg-config guile-2.2.pc --variable prefix <daviid>depending on which guile version of course