<NiAsterisk>or is #arguments only for build instructions? where in this case, I find in python.scm : python-pytest there's a (snippet) which looks like it could/would do such a replacement.
<lfam>NiAsterisk: I think the python-pytest example is usually called an origin snippet because it is some Scheme procedure applied to the source "origin" of the file. So, if you did `guix build -S python-pybitmessage`, the resulting tarball would incorporate the effect of the origin snippet. If you performed the substitution in #:arguments, then it would be applied during the build process. I don't know which is more appropriate here.
<davexunit>lfam: origin snippets should only be used for things that aren't Guix-specific changes to make them build in a container
<lfam>I don't think you'd be able to refer to the build inputs (like the python interpreter) in the origin snippet
<lfam>davexunit: Right, I think the only times I've used them were to work around upstream bugs that hadn't been fixed yet
<davexunit>it sounds like what NiAsterisk wants is to patch the makefile dynamically.
<davexunit>via adding a new build phase before the 'build' phase
<lfam>It it correct that you can't refer to build inputs in the origin?
<NiAsterisk>and that they continue to provide build bashscripts for distros is weird
<NiAsterisk>so it sounds like some kind of manual, copy-move install instructions to pass if not in the makefile (i don't have it open anymore). is there an example i can look at tomorrow? else I'll just go through the sources until i find one
<lfam>Anyways, the bin/pybitmessage is a wrapper to a hidden file that is probably autogenerated by the nix python build system. The hidden file cd's to the 'share' directory and executes share/pybitmessage/bitmessagemain.py
<lfam>I hope we never let our user-facing tools get as bad as nix's. They are really inscrutable
<NiAsterisk>it's run by one developer who is or is not (bitmessage forums said he's now part of the main dev team) working hard on contributing and fixing things, as merges to Bitmessage/PyBitmessage took very long
<NiAsterisk>so there is Bitmessage/PyBitmessage and mailchuck/PyBitmessage
<NiAsterisk>the one behind mailchuck runs mailchuck.net or something. which imo is a weird, unnecessary service and introduces all kinds of email related stuff into bitmessage ecosystem, but for those who need it it can be good i guess
<NiAsterisk>https: // wiki.c3d2.de/EDN , I could explain more but I guess this is were it would get too offtopic for a guix related channel. I'm (slowly) in the progress of translating and writing subtitles for one of the videos back in november about EDN, but afaik there should be videos on gnunet.org or youbroketheinternet.org about it, more recent videos. they had sessions at 32c3 i couldn't attend
<davexunit>the documentation could include a note along the lines of "Since the above spawns a daemon, you should use a different terminal session to perform the rest of the tasks, or consider integrating with your distribution's init system"
<rekado_>is this because of the "fix" to keep the build from retaining references to the build directory?
<mark_weaver>rekado_: iirc, regardless of where the directory exists in the main system, within the build container's namespace it is located at /tmp, to avoid leaking unnecessary system-specific details into the build logs.
<df_>artistic movements (sometimes) don't have a business case
<civodul>rekado_: in France there's the "université populaire", which unfortunately is often a bit elitist
<rekado_>(partial contradiction of my statement above: we do have libraries offering free access to books)
<rekado_>civodul: thanks for the pointer! I didn't know about this one.
<NiAsterisk>teachers are often locked into closed source software, the few which use free software probably got interested before studying and the ones who want to use free software later on get problem with exchanging documents in their workflow if other schools they communicate with are using incompatible software. I went through this with one school and their head staff
<rekado_>(got to tell my like-minded mates about it; maybe some ideas can be copied)
<NiAsterisk>plus depending on school and country, the privileges and integration of administration and computers are bad
<NiAsterisk>one district close to me, and possibly all others, have seen this in another federal state too, have external contractors managing all the IT infrastructur, giving teachers about 0 privileges.
<NiAsterisk>talking about free software usually involves talking about how things work first, i had to explain the internet to them (technically) when we tried to move their website or do changes to it.
<NiAsterisk>it's a businessmodel based on this, and it works. but I think one could also make some sort of "business" in trying to deconstruct these businesses, and teach free software to pupils and students, the basics, hands on, which could involve guixsd or guix as an example unit.
<NiAsterisk>there was a longer thread last month on the fsfe-de maillinglist, serving as an perfect example of lock-in in one federal state of germany.. it involved MS and other accounts + forcing parent(s) to buy laptops or tables with the latest windows.
<NiAsterisk>there are many bad service providers out there once you actually read the ToS & related terms. after some months of ping pong emails I'll get the EFF to do something about change.org this year, hope it'll be worth to report about.
<tsyesika>ugh, github is not a force for good in free software >.<
<davexunit>tsyesika: this is the mentality we fight against :/
<tsyesika>hey, I'm just wondering if anyone in here has any suggestions for fixing the bug I'm having with guix 0.9 install image on my macbook, the keyboard just doesn't function it does in trisquel and every other linux distro
<lfam>davexunit: I saw your criteria of good software installation mechanisms in the log. I think it's an important issue. I'm pretty new to this but the last few months of packaging have convinced me that if users cannot figure out how to compile your "free" software from scratch, then it's not really free software.
<rekado>This is almost certainly not what you want. This is mostly
<rekado>useful for embedded applications or simple keyboards."
<davexunit>lfam: that's exactly the point I'm trying to make
<rekado>tsyesika: according to dmesg when booting GuixSD, the HIDBP driver is used for the keyboard.
<rekado>tsyesika: this could be why it isn't working
<lfam>There's more to it than just words in COPYING
<davexunit>lfam: in my talk next week, I want to contrast Guix against other tools and show why Guix is the only one that satisfies all of the categories.
<lfam>Did you make any progress on figuring out how to record the talk?
<lfam>paron_remote: Even better, how about a distillation of the blog post for the manual!
<paron_remote>lfam: how about blogpost first, then I can worry about cleaning it up for the manual after :)
<lfam>Heh, okay :) I'll be happy to help. I like getting things into the manual. I remember how useful the blogs and pjotr's git repo were for me, but OTOH, it's annoying to have the information scattered around the net
<davexunit>gotta get the bulk of it done over the weekend
<lfam>When explaining Guix to people I have been trying to draw a parallel between inscrutable build processes and reproducible science like rekado is working on. They are directly correlated and help lay-people understand what's at stake more clearly, since most people don't even realize there is a free software movement.
<lfam>Most people see the problem of poor software practices making scientific experiments unreproducible