IRC channel logs


back to list of logs

<jmd> (substitute* "" (("/opt/include") (string-append glibc "/include"))) fails when cross compiling
<jmd>... because glib is #f
<jmd>Shouldn't glib be declared as an input?
<Steap>jmd: did you do (let ((glibc (assoc-ref inputs "glibc"))) ?
<jmd>Steap: I didn't change anything. This is in existing code.
<Steap>jmd: which file ?
<jmd>in definition of libxml2
<Steap>jmd: indeed
<Steap>it fails when cross-compiling
<Steap>so that must be somehow linked to the cross-compilation
<jmd>It would seem so. Yes.
<Steap>On what architecture are you compiling, to what architecture ?
<jmd>I'm on i686 targetting to mips
<jmd>It would seem that libc is an implicit input. But not when cross compiling.
<Steap>I don't use the MIPS port myself
<jmd>I'm not using it either. I'm just interested in getting guix cross compiling.
<Steap>how are you testing this, then ?
<jmd>I'm not. I'm just building it.
<jmd>(or trying to)
<Steap>oh, ok
<civodul>Hello Guix!
<jmd>civodul: Hi Ludo,
<jmd>Do you have any idea why (glibc (assoc-ref inputs "libc")) returns #f when cross building ?
<civodul>hmm, no
<civodul>one second, while i finish the release...
<jmd>Oh! a release!
<Steap>civodul: I think you do not have /bin/sh on your NixOS machine ?
<Steap>(or anyone currently using NixOS)
<civodul>Steap: NixOS has /bin/sh and /usr/bin/env
<civodul>they are symlinks to the actual programs
<Steap>Do you think we'll do the same thing ?
<civodul>NixOS even has /bin/sh in the chroot, which we don't do
<civodul>for /bin/sh, yes
<Steap>oh ok
<Steap>But will we ever have it in the chroot ?
<jmd>Hah. There is a recursive dependency when building file.
<jmd>At least when cross compiling.
<jmd>To cross build file, one needs a native file already installed.
<jmd>However when I define such a thing, guile runs out of stack ....
<davexunit>happy 0.5!
<jmd>Ugg. Explicitly adding glibc to inputs doesn
<jmd>t help either.
<civodul>hey there
***civodul changes topic to 'GNU Guix --- --- 0.5 is out!'
<civodul>yay, it's out!
*jxself rejoices
<civodul>the new VM image works much better than the previous one, and has more space left, BTW
<jxself>♫ ♪ ♫ Join us now and share the software... ♫ ♪ ♫
<civodul>yoooou'll beeee freee, haa-ckers, yoooouu'll beeeeee...
<civodul>e-party time!
*davexunit has been too busy at work to celebrate guix 0.5
<davexunit>I need to try that QEMU image out.
<jmd>From where does the inputs alist come in package definitions?
<a_e>Hello, congratulations to us!
*jxself goes back to singing
<jxself>♫ ♪ ♫ Hoarders may get piles of money... ♫ ♪ ♫
<a_e>Nice unicode characters! Unfortunately, we do not have the necessary fonts yet in Guix, I think.
<jxself>Seems like an opportunity there.
<a_e>Yes, font packagers are welcome!
<a_e>GNU Unifont comes to mind; but they should switch to autoconf.
<davexunit>font packages *not* welcome. please add to /topic
<a_e>davexunit: What do you have against fonts?
<davexunit>I have no silly joke to respond with.
<civodul>howdy a_e!
<mark_weaver>is there any particular reason that we packaged bitstream vera, and not dejavu (which is derived from bitstream vera but supports more languages as I recall)?
<civodul>mark_weaver: no particular reason, i think
<civodul>i think i added Vera because that was the one i knew
<mark_weaver>I'm using dejavu, and it includes jxself's musical notes just fine :)
<civodul>ah, then that's interesting :-)
<civodul>my font lacks 266B but has the other one
<civodul>and yes, it's Vera
<civodul>so there's a font name dejavu?
<civodul>how are we gonna find it? :-)
<civodul>to me dejavu is the file format, hence my question
<mark_weaver>hmm, do we already have a dejavu package?
<mark_weaver>(for the file format support)?
<civodul>nothing called dejavu
<mark_weaver>yeah, too bad the name refers to two different things in the free software world.
<a_e>Do you know where icecat gets its fonts from?
<a_e>I did not add fontconfig as an input; maybe that is a mistake?
<mark_weaver>a_e: I would assume that it uses whatever fonts are specified by the web site, with the defaults specified in the browser's default CSS stylesheets.
<mark_weaver>but I don't really know for sure.
<civodul>also it's the kind of package that incorporates everything it needs
<a_e>In any case, it does not render many characters.
<a_e>If you look at a Japanese wikipedia page with the icecat in guix, you get a page full of placeholders
<a_e>Icecat does use fontconfig; when starting it, a fontconfig warning is displayed.
<civodul>good hint :-)
<a_e>Nothing serious, fortunately.
<a_e>Another warning is this:
<a_e>(icecat:7599): Gtk-WARNING **: Could not find the icon 'gtk-go-back-ltr'. The 'hicolor' theme
<a_e>was not found either, perhaps you need to install it.
<a_e>You can get a copy from:
<a_e>Should we add hicolor-icon-theme (which we have) as a propagated input to icecat?
<a_e>Should we add fontconfig as a propagated input?
<civodul>what the search rule for icon themes?
<a_e>No idea; what do you mean?
<a_e>As soon as I install hicolor-icon-theme, the warning disappears.
<civodul>but do you have $XDG_DATA_DIR set or something like that?
<a_e>Yes, XDG_DATA_DIRS=$HOME/.guix-profile/share
<civodul>that's probably the thing
<civodul>hicolor-icon-theme could be propagated in that case, but still, "guix package --search-path" doesn't tell you do change $XDG_DATA_DIRS
<civodul>*to change
<a_e>Indeed. Would it be something to add somewhere in the code?
<a_e>Fontconfig does strange things in my system. I installed gs-fonts (they end up in ~/.guix-profile/fonts/type1/ghostcript) and freefont-ttf (they end up in ~/.guix-profile/share/fonts/truetype).
<a_e>fc-cache; fc-list
<a_e>lists the former, but not the latter.
<a_e>fc-query .guix-profile/share/fonts/truetype/FreeMono.ttf
<a_e>seems to work
<civodul>didn't know these commands
<a_e>Me neither, so I am not sure to use them correctly; but they are part of the binaries of fontconfig, which all start with "fc-".
<a_e>Hm, in another profile I installed first the truetype fonts, then ran fc-list; then installed gs-fonts and ran fc-cache and fc-list. Now only the truetype fonts are found.
<a_e>It looks like cleaning the cache does not work!
<mark_weaver>I guess maybe there's some directory of fonts that needs to be merged when a profile is created.
<a_e>There might be a time stamp issue. fc-cache scans only new directories.
<a_e>But $HOME/.guix-profile/share/fonts/truetype is a symlink to /nix/store/ddvifpsm3yr99spi2bc6hy5x1ip6hnr7-freefont-ttf-20100919/share/fonts/truetype and has a date of 1 Jan 1970.
<a_e>I suppose this is considered old so that the cache is up-to-date.
<a_e>fc-cache -r
<mark_weaver>where does 'fc-cache' write its cache?
<a_e>rescans and finds the fonts.
<a_e>Hm, then it cannot be a timestamp issue.
<a_e>I am confusing with the -f option to force scanning regardless of time stamps.
<a_e>mark_weaver: I do not knowl accoding to the man page, into
<mark_weaver>'strace' could be used to find out.
<a_e>$HOME/.guix-profile/etc/fonts/fonts.conf contain
<mark_weaver>it seems like it would be good to handle this automatically somehow, if the cache can be put into the profile.
<a_e><!-- Font cache directory list -->
<a_e> <cachedir>/nix/store/2kwl0s2363mkw5p0bv5cgapm62m0r7pn-fontconfig-2.10.93/var/cache/fontconfig</cachedir>
<a_e> <cachedir prefix="xdg">fontconfig</cachedir>
<a_e> <!-- the following element will be removed in the future -->
<a_e> <cachedir>~/.fontconfig</cachedir>
<a_e> <config>
<mark_weaver>I wonder what "<cachedir prefix="xdg">fontconfig</cachedir>" becomes.
<mark_weaver>that seems the most promising, because I'd guess that it turns into $XDG_??/fontconfig
<a_e>I think it becomes $HOME/.cache/fontconfig. If I delete it, then files show up there after running fc-cache.
<a_e>fc-cache --verbose -r outputs (among others):
<mark_weaver>if so, it seems like it would be good to advise the user to set $XDG_?? to somewhere in the profile, and then arrange to create that font cache automatically when profiles are created.
<a_e>nix/store/2kwl0s2363mkw5p0bv5cgapm62m0r7pn-fontconfig-2.10.93/var/cache/fontconfig: not cleaning unwritable cache directory
<a_e>.cache/fontconfig: cleaning cache directory
<a_e>.fontconfig: not cleaning non-existent cache directory
<a_e>This corresponds to the three directories in the config file.
<mark_weaver>I suspect that $HOME/.cache is being used as a fallback if the relevant $XDG_?? environment variable isn't set.
<a_e>I think that is the default, indeed.
<a_e>It is okay to keep $HOME/.cache.
<a_e>But one should then, after creating a user profile, run "fc-cache -r" if the profile contains fontconfig.
<mark_weaver>that seems suboptimal to me.
<mark_weaver>ah, I think $XDG_CACHE_HOME is the relevant variable.
<mark_weaver>a_e: can you try setting that variable, and seeing if 'fc-cache' honors it?
<a_e>XDG_CACHE_HOME cannot be set to $HOME/.guix-profile/cache, for instance; it is a symlink to a user profile that belongs to root.guix-builder and that cannot be written by the user.
<a_e>$HOME/.guix-profile is a symlink, I mean.
<mark_weaver>well, the idea is that 'fc-cache' would be run when the profile was created, and the cache would be put there.
<a_e>fc-cache does honour XDG_CACHE_HOME.
<a_e>But this is not needed:
<mark_weaver>and if the user installs fonts outside of guix, then the cache for those would be in ~/.fontconfig/
<a_e>We can keep XDG_CACHE_HOME as it is, and add a line
<mark_weaver>but what would we put on that line?
<a_e>into fonts.conf.
<a_e>Then we need to run fc-cache at the creation of the profile.
<mark_weaver>well, that hardcodes ~/.guix-profile, whereas Guix allows each user to have multiple profiles.
<a_e>User installed fonts would be cached into $HOME/.cache as usual.
<a_e>Actually, we already hard-code the font directory with a line
<mark_weaver>although I admit that my proposed solution isn't perfect either.