IRC channel logs


back to list of logs

<EternalZenith>Installing breeze-icons is failing for me
<EternalZenith>It seems to just be a failure with the tests
<apteryx>does someone understand how to use the guile-git module? I'm testing it in the REPL: ,use (git)
<apteryx>then (chdir "/tmp")
<apteryx>then (clone "" "libssh")
<apteryx>or (clone "" "libssh" (clone-init-options))
<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>)'.
<civodul>Hello Guix!
<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: s/wide/wipe/
<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
<civodul>does that make sense?
<snape>civodul: yes it does
<civodul>cool :-)
<civodul>would you like to give it a go? :-)
<snape>civodul: I don't have much time currently, so I'll first create a issue to keep track of it.
<civodul>sounds good, thanks!
<roptat>hi guix!
<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
<civodul>efraim: dunno!
<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>there should be one
<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 if I look at it ( it says "Please use the canonical form to link to this page." Should we use that, although it redirects to the former?
<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>URLs yes, but domain names no :-)
<civodul>so CRaN.R-PRoJeCT.oRG would work well
<demotri>civodul: You mean the other way around? URL=case-sensitive, HOST= case-insensitive?!
<roptat>yeah, that's what I meant
<civodul>yes, sorry
<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
<roptat>any idea?
<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/|
<roptat>oh, I didn't see that
<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
<civodul>mbakke may remember the details
<roptat>so (setenv "CPATH" (getenv "CPLUS_INCLUDE_PATH"))?
<roptat>and (unsetenv "CPLUS_INCLUDE_PATH")
<nckx>Good morning Guix!
<civodul>roptat: something along these lines, yes
<civodul>i think there are a couple of packages doing that
<civodul>good morning/afternoon nckx! :-)
<civodul>hello alezost!
<roptat>civodul: it seems to be working, yes
<roptat>ah, now it tries to run `cc`...
***astronavt__ is now known as astronavt
<alezost>civodul: hello
<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?
<efraim>that would explain it
<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: 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
<yrk>subtle points
<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: both licenses have to permit the combination, not just the gpl. see:
<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
<mbakke>yrk: That is correct.
<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)
<mbakke>yrk: Lol.
<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>nckx: thanks!...oh well :-)
<civodul>well congrats on fixing this issue!
*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>but then it was a relief
<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
*janneke -> zZzz