<paron_remote>well "dragged into" for a client that pays well and demands that I only write free software, and because I'm going to a conference in a few weeks so I need to make up hours, not the worst circumstance ;)
<davexunit>crocket: you can install your own packages that aren't in upstream guix easily, though.
<davexunit>we don't have the same notion of a repo that traditional distros do.
<mark_weaver>the package descriptions are maintained together with the support infrastructure, in the same git repo, just like linux (the kernel) maintains drivers together with the support infrastructure.
<crocket>There will be people whose packages are not accepted due to lack of manpower or guix policy.
<mark_weaver>crocket: guix policy, that's the crux of this, I think.
<mark_weaver>so that the drivers and the functions that drivers use to interface to the kernel can be evolved.
<mark_weaver>the alternative is to try to maintain stable internal APIs, which turns out to be a nightmare over time.
<codemac>To put it lightly - arch lasted a long ass time without decent support for these kinds of things, and GUIX_PACKAGE_PATH + setting up you're own source for alternates (like is done with hydra today) is probably good enough(tm) to do what you want.
<davexunit>it serves 'substitutes', which are pre-built binaries, the results of building one of our package recipes.
<davexunit>however, guix is *not* a binary-based distro, but guix will let you authorize hydra.gnu.org (or another server) to download pre-built binaries if they are available.
<davexunit>when a substitute is unavailable, guix builds it from source.
<mark_weaver>supporting alternate build farms is no problem at all. we intend to do that.
<mark_weaver>but guix (the package recipes plus the support code for those package recipes) is a monolithic project, in one git repo.
<mark_weaver>if you want, you can create your own branch or fork of guix, in another repo.
<mark_weaver>linux also has lots of branches for different subsystem maintainers to work on things before upstreaming to the main repo.
<mark_weaver>but one way or another, the packages stay together with the support code for those packages, so that we can evolve it all together and make changes to the way packages are written. that's flexibility that we would be foolish to give up, especially at this early stage in our project.
<mark_weaver>I myself have my own private branch of guix, and that's the one I use.
<sir123>Since it's been running multicore, I can't tell which exact file caused the failure
<taylanub>rekado_ & others: it sounds like Guitarix are uninterested in changing their project page; they will continue to refer to all GNU/Linux distributions as "Linux flavours". in that case should GuixSD be listed there at all?
<sir123>but, first guess is the file '/icecat-31.7.0/content/svg/content/src/nsSVGViewBox.cpp', but I can't see the error itself
<rekado_>sir123: try to search the output for "error". Since compilation is done in parallel by default, the actual error could be further up.
<rekado_>(This is where shell-mode in Emacs is extremely useful, as the console output is just text in a regular buffer, so it can be searched easily.)
<sir123>a 'Find' search in xfce4-terminal only reports the -Werror flags passed to g++, which is useless
<sir123>i'm running the build in the emacs shell, but it takes an hour to compile unfortunately
<rekado_>you could also write the logs to a file with "tee".
<rekado_>and maybe you could get the build log with "guix build --log-file icecat", but I've never used that and I'm just guessing.
<sir123>Alright, I found the issue. Trying to compile GNU icecat 31.7.0 fails because of the file VP8TrackEncoder.cpp in /content/media/encoder fails because it has undeclared variables. What should I do?
<sir123>The variables seem to be PLANE_Y, PLANE_U and PLANE_V. They are undeclared. I cannot compile IceCat 31.7. What should I do?
<sir123>What is the bug severity on a package like IceCat failing to compile?
<sir123>I can report that my GuixSD system is failing to build GNU IceCat 31.7 because of the file icecat-31.7.0/content/media/encoder/VP8TrackEncoder.cpp complaining about not having IMG_FMT_I420, PLANE_U, PLANE_Y, PLANE_V.
<sir123>When given the command 'guix package -i icecat --no-substitutes'
<davexunit>we're running on paper cups and string in comparison
<taylanub>civodul: hi! Guitarix seems intent on calling GNU/Linux distributions "Linux flavours". would it be better for GuixSD not to be listed at all on their project page, instead of as a "Linux flavour"?