IRC channel logs


back to list of logs

*taylanub is afraid to push it because it might trigger a core-update or something
<taylanub>going to bed, I hope we can afford master staying broken for a night :-)
<mark_weaver>taylanub: it builds for me
<mark_weaver>taylanub: what error do you see?
<mark_weaver>taylanub: where you did you send your proposed patch? I don't see it.
<rekado>later tell civodul Here's the error I get downloading texlive with guix:
<rekado>and here's the output of downloading with wget:
<rekado>I'm now copying the wget-downloaded file to the store and adjust permissions and timestamps as needed.
<rekado>hmm, regrettably guix wants to download the file again rather than accept the only I copied to the store.
<rekado>will copy and unpack
<rekado>ah, I should be using guix archive --import
<rekado>hmm, what I downloaded from hydra apparently is not something guix archive --import understands.
<taylanub>mark_weaver: are you around? I sent the patch to guix-devel; maybe it took long to arrive because it was >1MB? (the second attached patch, to update .po files, was big)
<taylanub>here's the log from running 'autoreconf -vif && ./configure && make' in a fresh clone of master:
<taylanub>make[3]: *** No rule to make target `../../guix/scripts/substitute-binary.scm', needed by `guix.pot-update'. Stop.
<rekado_>I can no longer make install guix.
<rekado_>can anyone reproduce this?
<rekado_>have already done "make clean" and bootstrap and configure and all that.
<taylanub>rekado_: I think po/guix should be in version control and isn't auto-generated, so if it got removed for some reason then none of make clean, bootstrap, and configure would regenerate it.
<rekado_>well, the problem seems to be that it enters po/guix and then wants to enter po/guix from within that directory.
<taylanub>some 'git reset' command should bring back the directory. if you're fine with a 100% clean directory with *everything* outside of version control irrecoverably deleted, you can run "git clean -fdx && git reset --hard". that should leave the git directory in a state as if it were freshly cloned.
<taylanub>rekado_: oh, then I don't know
<rekado_>po/guix exists.
<taylanub>the clean -fdx && reset --hard is likely to fix your problem in any case, but then master fails to build at the moment; see my patch in guix-devel
<taylanub>but as I said: it removes *everything* so careful
<rekado_>there's nothing wrong with my git clone, I think.
<rekado_>git status shows me only what I expect
<rekado_>couple of patches and stuff.
<taylanub>git status ignores some things as per .gitignore rules...
<rekado_>ah, true.
<rekado_>taylanub: re your patch on the ML: I understand the first patch, but these massive changes to the po files are a bit much, no?
<taylanub>rekado_: it's an automated change by the build system. users will have the files listed as "modified" without it. there's a previous commit of that nature in the logs as well.
<rekado_>I see. (I saw these files listed as modified in my tree before.)
<rabgulo>hello people
<rabgulo>*poeple :)
<rabgulo>who is the project leader of GUIX?
<wenderen>rabgulo: maintainer section: ludovic court├Ęs
<rabgulo>wenderen: ah, yes. i see this link, but i am "blind". thx.
<bavier>hmm... how to handle packages whose names are also guile keywords?
<bavier>e.g. I've packaged "catch"
<Sleep_Walker>"catch" catch-application ?
<Sleep_Walker>fortunately it is separated the name of the package shown and name of the variable
<davexunit>maybe in this case the version number could be used?
<bavier>davexunit: that would be an easy out.
<davexunit>or, there's already stuff like "gnu-gettext"
*davexunit finally submitted new 'guix publish' patches
<davexunit>writing tests is a real drag sometimes
***_`_ is now known as Gonbe
***Gonbe is now known as _`_
<civodul>Hello Guix!
<mark_weaver>hi civodul!
<mark_weaver>there have been multiple reports of master no longer compiling (when compiled from scratch)
<mark_weaver>taylanub posted a patch to fix it, subject "[PATCHES] Fix remaining references to substitute-binary."
<mark_weaver>but I wasn't comfortable reviewing it myself
<taylanub>hi both!
<mark_weaver><taylanub> here's the log from running 'autoreconf -vif && ./configure && make' in a fresh clone of master:
<taylanub>if you want you can ignore the second patch for starters; the changes in it are all done automatically by the build system (at least when building from scratch)
<taylanub>don't really know how exactly these .po files work
<mark_weaver>and: <rekado_> I can no longer make install guix.
<mark_weaver>yeah, I'm also ignorant of the po files
<civodul>taylanub, mark_weaver: it looks like is stale, right?
<mark_weaver>civodul: taylanub's first patch updates, but also and tests/guix-{daemon,system}.sh
<mark_weaver>taylanub wrote "the daemon seems unable to do substitution"
<mark_weaver>(I haven't checked)
<taylanub>it was trying to exec a path that doesn't exist I think. however, I had tested that after a simple 'autoreconf -vif && make && make install' without cleaning so maybe it was a different issue. (after that I did 'git clean -fdx && git reset --hard' and tried to rebuild from scratch, which failed)
<civodul>taylanub: i just replied to your patch
*civodul goes for dinner
<mark_weaver>thanks civodul!
<taylanub>pushed the first commit (which didn't have .po updates)
<civodul>taylanub: thanks!