IRC channel logs


back to list of logs

<zacts>howdy world
<rekado_>would it be acceptable for the CUPS package to create symlinks to the files created by the cups-filters package?
<rekado_>it's not only filters that the cups-filters package adds but also backends, configurations and so on.
<rekado_>filters are called dependent on the mime configuration (if the provided path is absolute), so I can avoid some of the trouble, but it seems that I have to actually link a few files across packages.
<rekado_>(the CUPS package depends on cups-filters)
<rekado_>is it at all possible for a package to read files from any of its input packages?
<rekado_>I want CUPS to create a symlink from out/backend/name to /gnu/store/xxx-cups-filters/backend/name
<taylanub>rekado_: yes, that's pretty standard .. gimme a sec
<rekado_>so far it's failing for me, saying that the file cannot be found.
<taylanub>in a phase procedure, if it takes a keyword argument 'inputs', then it gets an alist of the inputs, where you can assoc-ref "cups-filters" to get /gnu/store/xxx-cups-filters
<rekado_>I have that already. I do get the path to the filter. But when I pass that to (symlink oldpath newpath) it fails, saying that the file at oldpath does not exist.
<taylanub>creating a symlink doesn't require the target to exist ... maybe the parent directory of the symlink doesn't exist?
<rekado_>ah, good point. I guess this may be it. Will check again.
<taylanub>are you sure about the argument order? ln(1) has it reverse: ln symlink-path original-file-path
<taylanub>(no wait, I'm confused ...)
<rekado_>the docs say -- Scheme Procedure: symlink oldpath newpath
<rekado_>where newpath is the name of the symlink and oldpath is the file that it points to
<taylanub>yeah never mind, it's also that way with ln(1)
<rekado_>hmm, still get "ERROR: In procedure symlink: No such file or directory"
<rekado_>[symlink "/gnu/store/yds84ghqyygjhnyqd0s33sl57wyqrl3d-cups-filters-1.0.61/backend/parallel" ...]
<rekado_>that's the last line of the backtrace. The file does exist. Can it be seen at build time?
<taylanub>that's irrelevant because you can create a symlink to a file that doesn't exist. do all directories in 'newpath' exist?
<rekado_>they should.
<rekado_>this is an additional phase after 'install
<rekado_>the target directory exists (it contains files in a default installation)
<taylanub>currently it's the only reason for that error I can think of, that not all directories up to the filename in 'newpath' exist.
<rekado_>taylanub: works now. Wrong absolute target path. Thanks!
<taylanub>np :)
<Tsutsukakushi>should guix have a manual
<Tsutsukakushi>man fuix just say >No manual entry for guix
<davexunit>Tsutsukakushi: you need to run 'info guix'
<davexunit>GNU software typically uses info manuals rather than man pages.
<Tsutsukakushi>why isn't info one of the default packages?
<Tsutsukakushi>most has both
<Tsutsukakushi>at least what i've seen
<davexunit>well, I personally read info manuals in emacs.
<Tsutsukakushi>which package is info part of?
<davexunit>maybe info should get added to %base-packages, but you can just as easily add it yourself.
<Tsutsukakushi>guix package -i info says no package found
<davexunit>what is the output of 'guix package -A info'?
<Tsutsukakushi>you can change the pager for man too
<Tsutsukakushi>xan't see anything taht could be the right one
<Tsutsukakushi>it's on a different computer
<Tsutsukakushi>mp3info, shared-mime-info, texinfo xdpyinfo, xdriinfo, xvinfo, xwininfo
<davexunit>I don't have an up-to-date guix available to me right now, but there's surely an info reader available. I just always use emacs as my info reader instead of a cli program.
<Tsutsukakushi>having both info and man would be a good thing
<davexunit>well, maybe. man pages aren't very good.
<davexunit>if there is an easy enough way to generate man pages from our texinfo manual, then I guess we could do it.
<davexunit>but the format is fundamentally different.
<Tsutsukakushi>it's texinfo
<davexunit>I don't know if texinfo will provide you a reader.
<Tsutsukakushi>i like man format
<Tsutsukakushi>it's clear
<Tsutsukakushi>and less is a good as a default pager
<mark_weaver>Tsutsukakushi: the standalone 'info' reader is part of the 'texinfo' package.
<mark_weaver>but the info-reader in emacs is much better
<davexunit>mark_weaver: the more I know, didn't realize it was part of texinfo.
<Tsutsukakushi>mark_weaver: yeah, i already found that out
<civodul>Hi Guix!
<davexunit>hey civodul!
<civodul>hey, davexunit
<civodul>did you have a chance to investigate the problems you were having?
<davexunit>no resolution as of yet. haven't had much time. maybe tonight.
<davexunit>I'll be babysitting a 4 year old, so I may not get a chance.
<civodul>heh, ok, but take care of the kid ;-)
<davexunit>maybe in between games of UNO I can hack on it
<davexunit>though I'm not sure what to try next
<davexunit>I feel a bit stumped
<civodul>did you still have the problem with the store?
<civodul>or are you talking about the write-file issue?
<civodul>too bad we're on a different TZ
<davexunit>both issues remain :)
<davexunit>I need to fix my store, and figure out which directory it's trying to make
<davexunit>the error output doesn't specify
<civodul>bah, ok
<civodul>if you want me to look at the guix publish code or some reduced test case, i can do that
<civodul>BTW, i found what makes 'guix environment' so slow: it's derivation-prerequisites-to-build
<civodul>it may well be exponential or something
<civodul>i'll be trying to rewrite it
<davexunit>oh, cool! I never got a chance to profile.
<davexunit>how did you find it?
<davexunit>REPL profiling or...?
<civodul>yes: ,pr (guix-environment ...)
<civodul>and i knew there were a couple of XXX in that area of the code ;-)
<civodul>now i know they should have been FIXMEs :-)
<davexunit>a fast guix environment will be great
<davexunit>I still need to integrate guix system into that, for vagrant-like awesomeness.
<mark_weaver>civodul: looks like an issue from the libtool/libltdl split:
<mark_weaver>(when cross compiling guile)