<nckx>raghavgururajan: Ehm, this *is* libmesode. Of course you won't be able to link to a library you haven't built yet. Nor does libmesode require linking against itself, so what are you *actually* trying to do?
<ngz>rekado: There's a RSS feed, its gwene counterpart, and a mailing list already.
<morgansmith>Aurora_v_kosmose: oh ok. Being a "source based" distribution would be cooler if we gave command line options to make it really easy to see the source. I think it could get hard when we do git clones in the inputs (I think we only do this for a few packages though), but it'd be cool.
<Aurora_v_kosmose>morgansmith: Walking all the inputs and the origin and just putting it in an arbitrary directory shouldn't be too hard.
<morgansmith>Aurora_v_kosmose: well the problem there is we'd have to execute it right up to (but not including) the build phase. I can't remeber where I saw it, but there was a package that did a git clone in the input and then used a phase to copy it into source directory
<morgansmith>bavier[m]: That's certainly handy! I still kinda want a way to get a folder that is the state right before building though. Like the state after patches, after copying and deleting things, but before building. Actually I guess it doesn't have to be before building. Is there a way to access a packages build folder after it's built?
<bavier[m]>no, anything like that would be more invasive. E.g. inserting a failing phase somewhere, then capturing the build directory with `guix build -K`.
<morgansmith>bavier[m]: I guess making a tool to bail out a certain phase would be too niche to add to the CLI right? Doing that from the REPL certainly seems possible though
<morgansmith>bavier[m]: actually the more I think about it the more I think I could justify it. Not really for end users but for packagers. I often do a guix build that I know will fail just to make sure my regex is correct for a substitute phase I'm working on. Or I want to only run bootstrap stuff so I can inspect the generated configure script so I can pull out the flags. Although now that I'm thinking even harder about it, if I
<morgansmith>then I could just paste in a failing phase. I don't know why I never though to do that before...
<morgansmith>Speaking of guix environment, the manual says to do gui stuff in a container you just have to expose the display environment variable but I found that I also have to expose /tmp. I guess some of my X stuff is going there. Ex: `guix environment --preserve='^DISPLAY$' --expose=/tmp --pure -C --ad-hoc emacs -- emacs -Q`
<Aurora_v_kosmose>So at the moment I'm generating binaries. I'd originally wanted to deploy a statically-linked binary to simplify remote deployment on a machine I don't have access to... but that's difficult to get working with SBCL
<morgansmith>I don't claim to know a damn thing about common lisp but wouldn't something like `#!/usr/bin/sbcl --script` work?
<Aurora_v_kosmose>Unfortunately no, it's an image-driven ecosystem. So you could have a binary stub that runs (load whatever), but you'd still need to generate a Lisp binary stub for that in the first place.
<Aurora_v_kosmose>That's essentially what the Guix tooling for asdf binary generation already does. It just lacks straight-forward usage examples.
<Aurora_v_kosmose>There is however a program which does work exactly as you describe, cl-launch. Which does allow you to just make an executable text-file containing: #!/usr/bin/cl -sp my-package -E main
<Aurora_v_kosmose>The path patching stuff Guix does might not interact well with shebangs though, so I'm not sure how I'd package it.
<heloaoban>hey guix: quik sanity check, on a machine running Guix System, should all the guile modules in the current checkout of Guix be available to the current install of guile (/run/current-system/profil/bin/guile)
<lfam>Regarding the license of midicomp, if the author says that it's licensed a certain way, I think we should take them at their word. It's definitely not as good as if they included a license file, or even used license headers
<leoprikler>for the record, they do mention the AGPL in more than one place as their license, but they also include built sources and what not
<lfam>I think it's okay. It would be a violation of the license for distributors to include built/generated "sources" without the real source. But the copyright owner can do whatever incoherent thing they want
<lfam>For us, it's a question of risk. Will the owner decide we did the wrong thing by distributing midicomp? Will they use copyright law to retaliate? etc
<lfam>They might not really understand the licensing situation very clearly
<fnstudio>hi, i'm looking into alternatives to have guix on a cloud server, but i'm afraid there's something kind of fundamental that i'm missing
<fnstudio>one of the options, if i got it right, is to choose a provider that allows custom iso image
<fnstudio>in some cases that seems to refer to the option of booting from an installation media
<fnstudio>in other cases, it seems that the installation process is not needed?
<fnstudio>my ideal workflow would be: to create an image with guix locally; to upload it to the cloud provider; to boot from it and use it with no need to go through the installation step
<fnstudio>(i'm aware that i may be missing something and that the workflow above might actually not make that much sense)
<apteryx>we are not equipped to face go modules yet, are we?
<lfam>Some cloud hosters offer that workflow, fnstudio. But it's more typical that a distro has to work with the hoster in order to guide in creating their own distro image and offering that to customers
<lfam>apteryx: It depends what you mean by "face go modules". Almost everything we package is supposed to use Go modules, but our go-build-system doesn't use them. Sometimes the package can be built with the old system, still
<fnstudio>lfam: got it, thanks; so, when i thought that some provider allow you to upload a custom image and use it straightaway (eg vultr) i was missing something
<lfam>fnstudio: That's another way to do it. It works too
<apteryx>lfam: I see; still possible perhaps, it depends of the package. And it's not ideal.
<jackhill>I've also used Guix on a provides (ramnode) that allows custome iso upload. I've also tried building a qcow2 imagage with guix system and running that directly (at ramnode). That works, but I think ti still needs more polishing (around file system selection, integration with guix deploy).
<fnstudio>jackhill: although i was hoping there could be a more straightforward workflow
<lfam>fnstudio: Yeah. There's a reason VPS hosters just create the images themselves. They need a lot of tweaking
<jackhill>fnstudio: yeah :/ Linode has some … restrictions that require that. On the plus side, at Linode, it is possible to follow that workflow to create a Linode image, and have an easier time in the future.
<fnstudio>lfam: right, that makes sense, i knew i was being a bit naive! :)
<lfam>No worries :) I went through the same thing a couple years ago
<jackhill>Other providers like ramnode make some stuff easier (with different tradeoffs).
<cbaines>Regardless of that though, I think working on packaging guidelines is great
<ngz>The situation doesn't look fluid in the case of Fractal packaging, tho ;)
<cbaines>Consistency is also good, but it's often essential to comprimise consistency so things can improve more easily and quickly
<efraim>you can also look at librsvg-next if you need to mix cargo and other build systems
<ngz>cbaines: I'm not sure to see how the inconsistency here helps improving anything. What I know, however, is that the #:skip-build? path is painful, consumes time and resources. Of course, it may be important for Guix, but, again, it would be nice to decide if it is so.
<cbaines>ngz, well, inconsistency is just deferring to the judgement of the individuals involved. It would be better to come to consensus at some point, but doing so requires experience and information
<cbaines>I don't have much experience or information, so it's hard for me to form an informed opinion at least
<ngz>There was a discussion in the ML about it recently.