IRC channel logs


back to list of logs

<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
<civodul>Hello Guix!
<janneke>Hello civodul!
<marusich>Now using GNOME shell 3.20.1! \\o/
<civodul>yay! :-)
<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>This thread appears to be missing subsequent posts from me:
<civodul>ACTION looks
<marusich>I might have the wrong view somehow. The thread split into two after this post:
<civodul>seems has roughly the same as my inbox
<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>I dont think so
<marusich>It seems to show the threading for one path through the conversation
<marusich>but not the other
<marusich>I take that back
<marusich>they are both present
<marusich>but it's all flattened
<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>The confusing part is that this view shows nothing beyond the post shown:
<marusich>But this view shows all the posts, I think:
<marusich>But yeah, it's all there, so I guess it's OK.
<civodul>there's no such thing as Gnus :-)
<civodul>there's no Gnustitute ;-)
<marusich>Thanks for entertaining my question. sorry for the distraction!
<marusich>I'm going to get some sleep.
<civodul>sleep well!
<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?
<civodul>short answer: no :-)
<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>ah, right.
<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>heh, indeed :-)
<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>-r/--recursive maybe?
<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>-> #guile :)
<davexunit>wingo: is (ice-9 sports) intentional? :D
<wingo>yes :)
<wingo>for now anyway
<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
<davexunit>ah I see
<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_>(just wanting to understand the issue)
<civodul>ArneBab_: exactly
<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>the last paragraph at hints at that
<ArneBab_>(just running ./configure; make)
<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>along which lines? :-)
<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>NFS is so terribly slow :(
<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.
<civodul>rekado: "wget -O - | bunzip2 -c > /dev/null" Works For Me™
<avoine>i'm having random gzip corruption errors here not sure if it's related
<civodul>avoine: could you paste the command and log?
<avoine>I'll if I get an other one
<avoine>I also have: guix substitute: error: download from '' failed: 410, "Gone"
<avoine>with guix package -u guix
<avoine>or guix pull
<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
<civodul>the the "?id=" thing?
<avoine>civodul: it's an old guix setup on an ubuntu machine, maybe I should just delete the /gnu and start over
<civodul>can you try 'guix pull --fallback'?
<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
<civodul>'guix gc --verify' maybe?
<civodul>this is suspicious
<avoine>civodul: guix gc --verify output nothing should I try with: --verify=contents ?
<ArneBab_>civodul: ok
<avoine>civodul: found it, it was my ~/.config/guix/latest that was pointing to my old guix fork, sorry for the noise
<civodul>avoine: np!
<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>avoine: include guile in that environment
<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>avoine: --ad-hoc should go before guile
<davexunit>what that command is saying is that you want the *dependencies* guile + the package that g-wrap.scm evaluates to
<davexunit>dependencies of*
<avoine>I forgot native-search-paths ...
<avoine>oops no that's just for guile
<avoine>I must have forgotten something else because I can't get it to be in guile's %load-path
<avoine>this is the package:
<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
<random-nick>kraji: well there aren't too many to chose from
<kraji>ratpoison, i3, guile-wm, gnome, enlightenment, windowmaker
<kraji>maybe more
<kraji>openbox, fluxbox, bspwm, dwm
<kraji>wwhich one do you use?
<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"
<daviid> <- see the Notes: ... 3.
<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: ./ --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...
<avoine>I'm using the tarball
<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: that's not good
<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>Hello all!
<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
<kristofer>is there an arm image for guix?
<kristofer>erm, an arm image of guix
<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>daviid: davexunit: I'm giving up for now on guile-g-wrap this is what I got so far: but still nothing in %load-path
<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> out "/share/guile/site/2.0")
<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
<avoine>it must be a regex or something
<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>avoine: you need this
<daviid>pkg-config guile-2.0.pc --variable prefix
<davexunit>avoine: there's no regex involved.
<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
<davexunit>and track down the discrepancy from there
<avoine>it's the 2.0 at the end
<daviid>avoine: no that's not the case
<daviid>it is the prefix
<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
<avoine>ACTION going home