<apteryx>does someone understand how to use the guile-git module? I'm testing it in the REPL: ,use (git) <apteryx>and it gives me: git/clone.scm:41:8: Throw to key `git-error' with args `(#<<git-error> code: -1 message: "invalid Content-Type: text/plain; charset=UTF-8" class: 12>)'. <snape>hey civodul! What do you mean with "i think Cuirass should register GC roots for its evaluations under /var/guix/gcroots"? How many such evaluations should be registered? If all are registered, we'll run out of space won't we? So would it be like the last 15 or something? <efraim>that's actually what I was thinking about for that <efraim>seems like it'd be better to try to figure out which derivations are older and GC those first <efraim>'git grep "archive/v" | wc -l' 299 :/ <civodul>snape: i think we'd register all of them and use (guix cache) to automatically wide old ones periodically ***rekado_ is now known as rekado
<rekado>efraim: I’ve been removing a bunch of these from bioinformatics.scm, but there are many more to go. <civodul>snape: when there's a release we could manually stash important evaluations away so they won't be deleted <civodul>so i'd just create one subdir for each eval say in /var/guix/profiles/USER/cuirass/evaluations <civodul>and that'd contain a bunch of symlinks to both the .drv and the outputs <snape>civodul: I don't have much time currently, so I'll first create a issue to keep track of it. <efraim>the 'et' package in ssh.scm, is that an unstable tarball? <efraim>looks like it, 'guix build --no-substitutes -S et' failed with an invalid hash <efraim>Now I just need to check the source method is url-fetch <civodul>from an archival perspective, i was thinking we could have code that produces tarballs bit-identical to those produced by GitHub today <roptat>weird, I get this error when running guix build inside the gnu/packages directory: "no code for module (texinfo)", but no error outside of the directory <roptat>ah nevermind, that was my GUILE_LOAD_PATH ending with : <demotri>Is there a CVE database for 2016? fetching CVE database for 2018... fetching CVE database for 2017... fetching CVE database for 2015...?! <roptat>maybe databases for 2015 and 2017 were updated and you still had the unmodified 2016 database cached? <civodul>indeed, that's probably what happened <civodul>unmodified databases are not re-downloaded <demotri>Ah, OK. I didn't know that. I assumed there was a cache-timeout, maybe of a day or so. But that was totally speculation. Thanks. <civodul>there's both: a local cache timeout, and then the HTTP client uses If-Modified-Since to avoid re-downloading things when the cached copy is up-to-date <demotri>I should have just looked into the code :-) <civodul>ideally the UI would be clear enough that you don't need to look in the code ;-) <roptat>how do I replace an input when I inherit a package? <efraim>Normally add and remove separately, qt@4 has alist-remove, otherwise you're looking for 'fold' <demotri>I'm currently looking at Laura's last patch and noticed one thing, maybe a bit too picky, but still I'm interested for myself: <demotri>She gave a http url, but there is a https URL. Should that be changed in general? <demotri>(And that in the context that the URL just came from the importer) <roptat>I think we should use https whenever possible <roptat>but the linter will not agree with using the "canonical form" if it's a redirection page <demotri>roptat: Exactly that's what I was thinking. Still the site-owner claims that one is "better" (canonical). <civodul>demotri: i think in this case what matters most is to be consistent among CRAN packages <roptat>aren't URLs case-insensitive anyway? <civodul>so CRaN.R-PRoJeCT.oRG would work well <demotri>civodul: You mean the other way around? URL=case-sensitive, HOST= case-insensitive?! <roptat>I'm building a c++ package with gcc6 and get this error: /gnu/store/wx733picjbp5x5yybjw771853ndwzczs-gcc-6.4.0/include/c++/cstdlib:75:25: fatal error: stdlib.h: No such file or directory <demotri>roptat: But I don't get what case-sensitivity has to do with that here. Ah, I see, in the HOST part. In my head, I equalized that already, the main difference is at the end: s|package=|packages/| <demotri>The cran.scm packages usually take the form with /package/<PACKAGENAME>, i.e. the non-canonical, non-redirecting. So we should maybe stick to that. <demotri>roptat: I think I saw that error message already, but I can't remember where. <civodul>roptat: sounds like the CPLUS_INCLUDE_PATH vs. CPATH story <civodul>i.e., CPLUS_INCLUDE_PATH is no longer treated correctly by GCC > 5 <civodul>so you need to put everything in CPATH <roptat>so (setenv "CPATH" (getenv "CPLUS_INCLUDE_PATH"))? <roptat>and (unsetenv "CPLUS_INCLUDE_PATH") <civodul>roptat: something along these lines, yes <civodul>i think there are a couple of packages doing that <roptat>civodul: it seems to be working, yes ***astronavt__ is now known as astronavt
<pkill9>has anyone tested linux-libre 4.19 for guix? does it build fine with the guix's 4.18.15 package definition? <efraim>Mark normally takes care of the kernel upgrades, my GuixSD laptop overheats before it could possibly compile a kernel <civodul>yeah Mark is likely looking into it right now ***pkill9_ is now known as pkill9
<efraim>hydra web interface is timing out <mbakke>efraim: Hydra is currently down for maintenance. <nckx>Does a bundled .h file (that is included during the build but not installed) warrant a separate LICENSE entry? <nckx>In this case, ISC in an otherwise GPL2+ package. <yrk>nckx: no need for a separate LICENSE file in my opinion; simply preserve the license and copyright notices in the ISC-licensed file <yrk>nckx: this is since the work, as a whole, is indeed licensed under GPLv2+ <mbakke>nckx: Using GPL2+ causes the entire work to become GPL2+ regardless of individual licenses. <yrk>mbakke: ...as long as those individual licenses are gpl-compatible <yrk>mbakke: and in any case, it isn't the GPL that is causing this. it is the fact that the other licenses are lax and allow themselves to be overridden <mbakke>yrk: I don't think it's so subtle, the GPL is very explicit that it covers all of the work even if portions are licensed differently (see the second paragraph). <nckx>yrk: I meant (license ...), not a LICENSE file, silly uppercase habit. <nckx>^ anyway so yeah this is why I've given up on trying to understand license combinatorix. I just ask IRC and let them fight it out. <nckx>gpl2+ it is. Thanks all. <yrk>mbakke: so it implying that just the gpl matters in this case gives the wrong impression that the gpl can somehow force other licenses to do something that they don't <yrk>mbakke: I'm sorry; this is IRC. you can't agree with me. we need to at least make a semblance of a persnickety argument over minutia <yrk>mbakke: (joking of course) <nckx>TIL: cute. "The name ‘cute’ stands for “‘cut’ with evaluated arguments”." Cute. ***nlyy is now known as nly
<janneke>civodul: i found the problem with my core-updates-next, will push to savannah <janneke>it was real silly: the new bootstrap-mes package I copied from bootstrap-gcc and it included search-path variables <civodul>oh, and those were interfering somehow? <janneke>civodul: yes, those were injected for packages that use %boot*-inputs, behaviour: pretty fu :-) *janneke is very happy \o/ <nckx>janneke: Of course *now* I spot a typo, in d0bb7ed61: s/writen/written/ — it was already in the original text. *janneke pushes typo commit <janneke>thank you, and thanks for your help! <nckx>civodul: Wow. Thanks for the quick wavemon review! I haven't forgot pdns, promise. <janneke>i'm quite happy that building the main mes seeds now is not a manual process anymore, but scripted in guix <civodul>yup, that reminds me the initial make-bootstrap.scm which took days or weeks to get to binaries that would actually work :-) <civodul>nckx: yw! i was trying to do something "productive" <janneke>civodul: when i read bootstrap-gcc, i imagined something like that! *janneke likes to do the `standing on shoulders of giants' thing