IRC channel logs
2016-08-24.log
back to list of logs
<mark`>Does anyone have experience installing guixsd from the usb image? <lfam>efraim: Yes, something like that, but I will wait until the libtiff graft is on master. Those merges are a pain, so I'd rather just do one <lfam>efraim: I missed your message until now, as I read the logs <paroneayea>I have a 10 year old desktop running as my backup server, but it's falling apart. <paroneayea>I'm thinking of ordering something lightweight and guixsd compatible <paroneayea>also I'd probably need to switch my backup setup over to guix :) <habs>I think there is something gravely wrong with my GuixSD installation. Is there any way to do a more thorough check than 'guix gc --verify=contents'? Any new packages I install always segfault unless I run them with sudo, and I get several hundred "collision encountered" warnings when installing any package. <alezost>habs: I think you installed different packages in different times which may lead to multiple collisions, try to upgrade your profile: "guix package -u" <alezost>btw how many packages are in your profile? <efraim>i wonder if we should add an option to git-fetch for '--depth=1 --shallow-submodules' <efraim>it always seemed faster for me on my netbook to not have to compute all the tags <efraim>is lgpl2.1+ and openssl is ok? or should I switch openssl for gnutls <ng0>Hi. Some of us are at reddit, right? What do you think about doing an "Ask Me Anything I'm a Guix Developer" or something like that? I don't use reddit, but depending on the topic those are good to get some questions solved and to get answers out there which aren't already obvious, and I think there's some percentage of reddit users which are hackernews users... <efraim>we could try it, i'm not too sure how well I know some of the internals <ng0>it's not a one person operation, so I assume the "I" could be extended to "we are" and more than just one person answers? I'm not sure how this AmA thing usually works <efraim>#fsf says lgpl and openssl are incompatable <ng0>is texlive-minimal == pdflatex? <efraim>nows the time to get it in, while its still a new package :) <ng0>I think i wasn't clear <efraim>i'm running find on /gnu/store now for pdflatex <ng0>The optional dependency is there, it can beadded, i already do so on another system. I'm not sure though if it would require texlive or texlive-minimal or something entirely different, and I know many people here are protective about adding texlive to something <ng0>ACTION runs e-file to check where pdflatex actually is <efraim>so far i've found it in texlive and texlive-bin <ng0>ah. not in -minimal? <efraim>its still searching, i don't have it on my machine with an ssd so it takes a long time <ng0>saves me the time to boot a system which boots another system where I could run e-file, which queries a database of filestructures of applications of gentoo :) <efraim>in texlive, didn't see it in texlive-minimal <efraim>but i might not have texlive-minimal on this machine <ng0>if it is not in texlive-minimal, I will create a gnunet variation which inehrits this. I'm personally not so happy to add texlive as a dependency <ng0>s/which inherits this/which provides this <ng0>this is not my focus atm though, will be for later <ng0>thanks for searching :) <snape>hi, is there a way, with GuixSD, to avoid rebuilding the whole kernel when I change a little thing <snape>I mean, I need to debug something <snape>is there like a debugging workflow? <snape>well, I guess I can manually update the linux modules that are in the initrd, and recompress it <snape>make a fake /var/guix/system that points to the debugged linux/initrd <rekado_>snape: I'm not experienced with this but you can change the list of modules for your initrd in the operating-system declaration. <rekado_>this doesn't rebuild the kernel afaik <snape>it does not rebuild the kernel if none of its inputs are updated, but since I'm debugging the kernel, the source of the kernel is updated, and the build-initrd scm function will trigger a whole kernel rebuilding <habs>I tried running 'guix package -u' and it succeeded but now things are much worse as even the guix binary segfaults when run without sudo. Also I have 120 packages in my profile (GuixSD on a Thinkpad) @alezost. What can be done to further debug / fix this? <efraim>rekado_: thats what i'm thinking, didn't seem to be happy with it <efraim>i might need to add a patch phase after configure to fix something <efraim>wait, i take it back, apparently it magically built while I wsan't looking <efraim>it wasn't happy with ghostscript-gs, did like both, now to try with just ghostscript <efraim>well, with efl gobbling up all the other enlightenment libraries it's time to add another patch making efl the sole enlightenment input on a couple packages <habs>This is a quick example when I run /run/current-system/profile/bin/ls or any other newly-updated binary: http://sprunge.us/VZjB Can anyone help debug why they segfault? Is it a problem with my library paths? <iyzsong>habs: did you set LD_LIBRARY_PATH? it shouldn't load libcap from ~/.guix-profile <habs>iyzsong: My LD_LIBRARY_PATH is "/home/habs/.guix-profile/lib:/lib:/lib64" <habs>iyzsong: Ah, that fixed my problem! Thanks! <rekado_>LD_LIBRARY_PATH is a hack that tells the dynamic library loader to ignore what the binaries say they want and to load other libraries instead. <rekado_>in Guix all binaries contain the full paths to libraries they need to load. <davexunit>it would be cool if 'guix package --search-paths' printed out something that could be eval'd *without* clobbering the previous values of those variables <davexunit>for example, it will set PATH such that *only* the profile is searched. <rekado_>davexunit: isn't this the same as entering a sub-shell and then evaling the output? <rekado_>(or source $profile/etc/profile in a sub-shell) <davexunit>rekado_: oh yeah, forgot about /etc/profile! <muck>how would you guys log stdout on tty1 within qemu when debugging a wm build ? the wm doesn't start and clearly produces lua related errors (awesome-wm) but i can't read it fast enough thanks to slim restarting and no related logs being in /var/log <efraim>elementary is now part of efl, same commit to remove the now superfluous elementary or new commit? <efraim>i mean remove from other package inputs <efraim>hmm, new efl can't find pulseaudio or libsndfile <efraim>i might need to save the 1.18.0 bump for later, can't find a premade patch in their git tree <paroneayea>mark_weaver: btw, do you know if the latest update of linux-libre you pulled in fixes that attack we discussed recently? <paroneayea>ACTION wonders why coreutils is rebuilding on his machine <bavier>it might be nice for 'guix build' if one could specify the packages output, e.g. glibc:out, to optimize the case where substitutes are used <lfam>bavier: You mean, only build the specified outputs? <lfam>paroneayea: Maybe you were watching the installation process of some other package, which uses the `install` command from coreutils? That prints the store path of coreutils. I've been alarmed by seeing that in the past, until I realized what was happening. <paroneayea>let's update guix to have ascii boxes like this ;) <paroneayea>I'm sure everyone else will be cool with this :) <paroneayea>we'll use unicode box drawing characters instead! <lfam>Only one piece of information will fit on the screen at a time ;) <lfam>In seriousness, has anyone ever audited the ASCII art programs? I'd rather not add lines of code to our base system for frivolous reasons :) <lfam>Inkscape makes me nervous already <davexunit>and should be able to replaced in the future <paroneayea>render to PNG using inkscape, then render to PNG, and print to screen using aalib <lfam>Speaking of which, inkscape uses libtiff, which has a pending security update on the mailing list :) <paroneayea>davexunit: in this case since it's not requiring any major rebuilds, it's safe to just push this change directly to git master without review right? <paroneayea>the reaction you really want is "my god it's full of *s" <davexunit>detect the width of the controlling terminal and print more *s as needed <lfam>But I couldn't get it to build :/ <lfam>Yeah, I was going to present it as some great advance in the state of the art of free software <paroneayea>you know, even in its height, I could never find freshmeat manageable to read <paroneayea>vegetarians don't eat meat, but we do read meat like tea leaves <lfam>Back to serious topics, does anyone know why libarchive triggers 976 rebuilds? Is there some core package which uses it, or is it just an input to many leaf packages? <lfam>Hm, sees to only appear in a handful of package modules <bavier>lfam: I meant, when a 'guix build foo' results in downloading all outputs of foo from a substitute server, it would be nice to specify which you're interested in <bavier>if the 'guix build foo' requires a local build, you just build the whole thing anyhow <lfam>bavier: Ah, that would be nice <lfam>Right, I wasn't sure how my interpretation would be possible, but yours seems possible <bavier>e.g. 'guix build glibc' downloads the debug output, which I'm currently not interested in <bavier>so something like 'guix package' supports: guix build glibc:out <lfam>Especially bad for operating systems that *use* libarchive as part of the software update mechanisms <lfam>But, that's not us, AFAICT <lfam>Although, I shouldn't be the only person to look at this <lfam>Cmake uses libarchive :/ <lfam>A handful of other packages, too, but mostly cmake <efraim>libarchive is used in cmake, not sure what else <efraim>libcaca is also fun for ascii video watching <efraim>make sure it's a low res video though <socristotle>Hello. Is there any documentation on installing GuixSD on a libreboot machine with Full Disk Encryption? <lfam>socristotle: I'm not sure exactly. I think that Petter (in this channel) knows about it. There has also been some discussion on the guix-devel mailing list archives. <socristotle>Thank you very much lfam. I'll look into the information to see if it's possible. If not I can always install Parabola. <lfam>socristotle: I remember hearing that it's possible, but requires some manual steps. <lfam>Of course, supporting full disk encryption with or without libreboot is something we want for GuixSD <jmd>What kind of pattern matching applies to guix package -d ? <lfam>jmd: There's some documentation in the manual, section 3.2 Invoking guix package. Beyond that, I'm in the same boat as you: time to read the code :) <jmd>lfam: I'll have a look there. Thanks. <efraim>i normally call it with `guix package -d 1m' for 1 month <jmd>Anyone looked at getting torbrowser packaged? <lfam>jmd: Yeah, there's been some discussion here and on guix-devel <efraim>ng0 has been banging his head against that one for a while now <jmd>efraim: Why does 1m mean one month. I would have guessed one minute. <efraim>either ludo clued me in or I checked the code, can't remember <alezost>efraim: jmd: this string pattern is converted to a time interval by 'string->duration' procedure in (guix ui) module <alezost>anyway I think a minute would be a too small time interval to be used for --delete-generations <alezost>ha-ha, but there is "s" for seconds! <socristotle>Not the right irc channel, but does anyone here own a libreboot x60 tablet? <sankey>ACTION has an x60 runnin libreboot <sankey>but it's not a tablet, didn't know those existed <ngz>Hello. I'm currently struggling with a package definition (at http://paste.lisp.org/+6Y49), which throws the following error: ice-9/eval.scm:386:9: Throw to key `match-error' with args `("match" "no matching pattern" ())'. Any help is appreciated, since the package is otherwise finished. <bavier>ngz: idk about the match error, but the cmake-build-system already builds within a separate "build" directory <ngz>Ah. I'm going to get rid of that part then. <bavier>I'm not sure how useful that is to you here, because if you need to override the configure phase, it doesn't expose the location of the source directory <bavier>but you can usually approximate that with more ".."s <ngz>I'll add a temporary (display (getcwd)) to see my location, if needed. <ngz>bavier: Oddly I was able to successfully build that package at some point, but I'm not anymore. <bavier>steveeJ: it uses a combination of the gnu-maintenance module and the various import modules <steveeJ>bavier: I see. the package has to provide specifics for the updater <bavier>steveeJ: the packages provide only the source urls, which are examined by the updaters <ngz>Which module provides %current-target-system? I cannot find it grepping the sources. <bavier>ngz: it's defined in each derivation I believe <steveeJ>bavier: I'm very impressed that this is a native feature! <bavier>steveeJ: if you're interested in such things, there's more work to be done <bavier>e.g. it'd be nice to have a generic fallback updater <bavier>like, maybe it looks for later versions in the same web directory, or scrapes the project homepage for links, etc <steveeJ>I can probably find out somewhere on the webs ;) <steveeJ>besides that, another interesting project I've never heard of <muck>ohman finally got awesome 3.5.9 running \\o/ <bavier>well, no, the last build was a failure <bavier>paroneayea: there's a 1.61.0 version that I'm testing <bavier>paroneayea: so far just one package needs patching <paroneayea>I'm guessing a boost change, but that's without looking :) <bavier>both the last two builds on hydra used the same boost version <paroneayea>looks like it's something different in date/time stuff <paroneayea>though maybe in the way it's formatted or something, who know <bavier>paroneayea: do you use ledger much? <bavier>I just learned of it recently; wondering whether I should transition away from gnucash <bavier>but I share finances with others in the family, so a text- and cli-heavy approach might not be appreciated <paroneayea>same with hledger, but I hear beancount is more friendly