<brendyn>Yeah. But that's the only way to find out what files are in the package
<str1ngs>roptat: I think I understand why it's like this. this helps either way
<roptat>if substitutes were available for the package, we could implement something to ask for a file list, but I don't think there's much gain
<roptat>and if there's no substitute, you have to build it to know what it installs anyway
<str1ngs>another thing, my notebooks is taking a beating from guix. I have tried to offload building an publishing on my powerfull workstation. sometimes package -i seems to do the right thing. other times it wants to randomly build things. it's kinda frustration
<civodul>i'm trying a patch to disable 3 of these git-svn tests that show up in build failures
<civodul>it may that test parallelism was not to blame after all
<str1ngs>I have a personal project using autotools. its still in development. its uses pkg-config to set CFLAGS. gdk pulls in wayland-protocols.pc but wayland-protocols.pc is found in PROFILE/share/pkgconfig and not in PKG_CONFIG_PATH. seems kinda wrong to me
***pksadiq_ is now known as pksadiq
<civodul>rekado: i was thinking that we could mention berlin.guixsd.org under "Substitutes" so that people can try
<civodul>do you think that'd be OK or should we wait?
<str1ngs>I have a very alpha project, that I was thinking of creating a package.I'm the author of the project
<lfam>Guix makes it pretty easy to package things "out of tree". In general, we prefer to only include upstream releases that are marked "final", "done", or whatever other term the upstream uses to distinguish from "beta", "alpha", "release candidate", etc
<str1ngs>out of tree is not a big deal. it's just that it's guile project. and guix is the closest thing to guile package management
<lfam>But in practice we have to evaluate it on a case-by-case basis
<str1ngs>the project is C and guile. it's a web browser
<ng0>literally what I wrote. like I do this: I create a package definition in the source code tree somewhere. preferably in the root of it, but sometimes contrib or anything similar. then I use this file with guix package -f or guix build.. etc
<ng0>see GNUnet, gnURL, python-pycanberra and so on
<ofosos>ng0: I've picked up your krita patch from earlier this year, and am trying to build it now, had to overcome some problems :)
<ng0>even a simple scripts collections is build like this for me
<ng0>oh it was just identifying dependencies, right
<ng0>nice that you made progress, however small or big my patch was :)
<daviid>trying to compile gnutls, on debian buster, configure does not report any error, but make fails: verify.c:40:10: fatal error: supported_exts.h: No such file or directory ... anyone knows what package holds supported_exts.h on debian ?
<ofosos>The only problem is, I had to throw out OpenEXR support, I think there's something fishy happening with ilmbase and openexr conflicting, they're both part of the same upstream and apparently everybody (besides guix) builds them as one package
<myglc2>ng0: OK, I see I took your comment too literally.
<ng0>I have 5 changes in guile-wm I'll be sending in tomorrow morning or evening
<vagrantc>hrm... so experimenting with setting up a local caching proxy for berlin.guixsd.org and mirrors.hydra.gnu.org ... and now guix pull seems to be redownloading all the bootstrap binaries, even though guix is still building the exact same git commit ... how's that work?
<vagrantc>hrm... and on a second run of the same command, it didn't do much