*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: where you did you send your proposed patch? I don't see it. <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>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>make[3]: *** No rule to make target `../../guix/scripts/substitute-binary.scm', needed by `guix.pot-update'. Stop. <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>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 <taylanub>git status ignores some things as per .gitignore rules... <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>wenderen: ah, yes. i see this link, but i am "blind". thx. <bavier>hmm... how to handle packages whose names are also guile keywords? <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 ***_`_ is now known as Gonbe
***Gonbe is now known as _`_
<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." <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 <civodul>taylanub, mark_weaver: it looks like POTFILE.in is stale, right? <mark_weaver>civodul: taylanub's first patch updates POTFILES.in, but also guix-daemon.cc and tests/guix-{daemon,system}.sh <mark_weaver>taylanub wrote "the daemon seems unable to do substitution" <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 <taylanub>pushed the first commit (which didn't have .po updates)