<cbaines>Is the thing you're trying to package trying to bundle and build some of it's dependencies as part of it's build process then?
<wehlutyk>I don't think so, as it does link to external libs later in the build process. The problem is again that the build config expects exactly 2 include folders for shiboken (which seems to be a preprocessing / code generation step): the qtcore folder, and the pyside2 source folder, so the headers for the external modules need to go at the right place in the pyside2 source
<civodul>are hard links to directories a thing nowadays?
<nckx>civodul: Not on (GNU/?)Linux, I thought. Why?
<efraim>Thinking how to save store space and time with gc?
<efraim>My simple tests showed 3:1 compression with deduplication from the daemon and 2:1 with zstd compression from btrfs for 6:1 total. I didn't do the math on no deduplication but I think it wasn't as good as 2:1
<efraim>I wonder if there's some filesystem flag that would do hard linking on identical files
<civodul>nckx: i was looking at the "guix system init" phases where it actually copies things from one place to another place on the same file system, thinking we could do better...
<zimoun>rekado: Roel did some work on the BioConductor update but it seems that our async work erase it on Savannah. Now they has almost everything ready locally but cannot push (even with -f). Configuration of the branch?
<dongcarl>Hi all, trying to search thru #guile logs here... Seems the search is down?
<nckx>zimoun: Force-pushing isn't possible, Roel needs to merge any relevant changes on the Savannah branch locally, delete it, then push.
<zimoun>civodul: yes, for sure --substitutes-urls do the job, I even time to time use guix.tobias.gr or guix.cbaines.net. But one has to know it. For example, the official bayfront.guix.gnu.org is not reported in the manual (fixable, I will see what I can do).
<zimoun>civodul: However, as a user, I expect “guix install gmsh” just works and not burn my CPU because I will never do C-c RTFM, “guix install gmsh --susbtitutes-urls=bayfront“.
<nckx>zimoun: <the official bayfront.guix.gnu.org> How ‘official’ is bayfront, was my question yesterday. It's more of a policy question I guess. Do we want to support it as such, and (ask users to) trust it.
<nckx>rekado: Did the goggles Xapian database get corrupted/reset/renamed/... on 12 Oct? No search results older than that.
<civodul>zimoun: i'm aware we have a CI problem, if that's what you mean :-)
<civodul>nckx: but CoW is a Btrfs thing in practice?
<civodul>at the syscall level, there's just link(2), right?
<zimoun>civodul: I am looking for a simple fix while waiting fixing the CI :-)
<zimoun>nckx: I agree, I did am asumption about the policy. And I do not know, I would say yes. :-)
<zimoun>roptat: the website is too much :-) Well, I would like to publish to linuxfr or something like that, so a win-win. Note that Spannish translation is not translated: http://guix.gnu.org/es/blog/2020/online-guix-day-announce-2/ So Maybe we could the opposite, serve a translation at fr/blog/blabla even if all the website is not translated; maybe just the front web page. Ok, I will see my motivation later. ;-)
<jonsger>hm, networkmanager and dnsmasq didn't like each other. They are spamming /var/log/messages heavily...
<dongcarl>mothacehe: I use clang-8 mostly for *redacted unfree fruit company* cross-builds, and we want reproducibility for that. Ofc I can just apply the patch on my own manifest, but was just wondering if it might be of interest for others who are using clang-8 or packages which may require clang-8 specifically in the future.
<jonsger>cbaines: while running it with strace it works, maybe it works with mcron-service as well...
<mdevos>Is there a policy for or against responding to closed issues? My issue #44199 has been closed recently for its dependency GNUnet not being considered "stable" and the patch being rather incomplete (closed with my approval). But I'm not waiting with hacking on it until GNUnet is stable enough, so ocasionally posting follow-up e-mails in case of significant progress seems more natural to me than keeping people in the dar
<mdevos>\me is pleasantly surprised with the complexity of writing a GNUnet DHT service
<jonsger>cbaines: I strace the complete mcron with all it's parameters as root and then it worked. Running mcron via shepherd it does not work and I have a `[mcron] <defunct>` process + the mcron process
<cbaines>jonsger, maybe try stracing mcron running via the shepherd then, maybe that'll reveal what's going wrong.
<guix-user>After removing dot-files, the plugins did not work for me either. :-(
<guix-user>I guess we should just remove the 'add-plugins-dir phase for now?
<nckx>raghavgururajan: Please ask upstream to reconsider. PLUGINS_OS is a horrible name. This is a global variable, or at least it will be in Guix. Every programme will now see a PLUGINS_OS variable set to .../share/gajim/plugins. It should be at least be prefixed with GAJIM_, like other such variables. ‘PLUGINS OS’ is just bad English compared to ‘PLUGIN PATH’ but fine, that's their problem. The missing GAJIM_ is ours.
<guix-user>That phase also affects PLUGINS_USER line in the code. So gajim plugins installed via internal plugin's installer is not working. But if I remove that phase, then it works.
<nckx>guix-user: Your plug-ins won't load because the gajim plug-ins in Guix aren't compatible with the gajim in Guix. Guix's gajim needs to be updated or the plug-ins downgraded so we no longer ship a broken combination to users.
<davexunit>has anyone ever done anything to integrate guix environment into projectile-mode or similar? would be cool to have emacs automagically handle enviroment variable setup for my projects that use guix to pull in dependencies.
<nckx>The fact that it now prints an version error implies the patch works.
<guix-user>Oh wait, yeah, we can downgrade the plugins.