IRC channel logs


back to list of logs

*civodul is getting CI sp^W notifications like in good'ol Hydra days \o/
*nckx back
<leoprikler>which one is the failing test again?
<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?
<leoprikler>tests_test_hash_LDADD = $(MESODE_LIBS)
*nckx leaving, I'll read (further back in) the backlog later.
<leoprikler>so yeah, that'd be a noop
<leoprikler>try adding $(SSL_LIBS) to that
<ngz>civodul: yes, notifications are great. I'm going to add the RSS feed to Gwene.
<raghavgururajan>> leoprikler‎: which one is the failing test again?
<ngz>What about ""?
<civodul>ngz: sounds good!
<civodul>we're gonna fill Gwene's disks :-)
<ngz>heh :)
<ngz>Depending on the POV, with Guix, you either feel good or fill good.
<civodul>(i suspect native speakers can't really get that joke)
<ngz>The gwene thread will be available in a couple of minutes
<raghavgururajan>> leoprikler‎: tests_test_hash_LDADD = $(MESODE_LIBS)
<raghavgururajan>Where should this go?
<leoprikler>this already exists in the
<ngz>civodul: Bah. RMS puns are worse
<raghavgururajan>leoprikler: I am seeing "-static". Should that be changed too?
<leoprikler>meh, linking tests statically should not be an issue since they're discarded anyway
<Aurora_v_kosmose>Is there any option to "guix build" that'd keep the build directory around after it successfully completes?
<Aurora_v_kosmose>The resulting lisp wrapper program fails and I want to see why, but for that I need the generated source file.
<ngz>Aurora_v_kosmose: could you add an error at the very end of the build process and use -K ?
<dongcarl>Hi all, is the umask pinned to 0022 inside guix-daemon's build containers? Perhaps the same should happen for `guix environment`? or at the very least `guix environment --container`?
<Aurora_v_kosmose>ngz: So adding a build-phase that invokes
<leoprikler>(add-before 'install 'haha-no! (lambda _ (throw #t)))
<Aurora_v_kosmose>asdf build phases delete install though.
<raghavgururajan>leoprikler: Same errors even after appending $(SSL_LIBS)
<ngz>Maybe (add-after ,(last %standard-phases) 'throw (lambda _ ...)). Untested, of course.
<leoprikler>read the and try all the libs
<leoprikler>last yields a pair
<ngz>Are you sure?
<leoprikler>pretty sure
<ngz>Here, (last '(1 2 3)) => 3, not '(3)
<leoprikler>now try it with an alist
<ngz>Ah, %standard-phases is an alist?!
<leoprikler> (let-syntax ((phases (syntax-rules () ((_ p ...) `((p . ,p) ...)))))
<leoprikler>(append (modify-phases ...) (phases ...))
<leoprikler>might work
<Aurora_v_kosmose>So, I added a false call after my custom phase that produces a build. Error successfully attained
<ngz>You successfully failed.
<leoprikler>That's surprisingly difficult, see Rust.
<mothacehe>the Cuirass mastodon account was suspended for ... spamming, lol
<Aurora_v_kosmose>I guess they nuked every other bot on their server then.
<mothacehe>maybe I need to find a more permissive instance
<morgansmith>If I want to view the source code for something, is there a way to tell guix to just download and extract the origin of a package for me to explore?
<raghavgururajan>leoprikler: I tried all. "tests_test_hash_LDADD = $(MESODE_LIBS) $(SSL_LIBS) $(PARSER_LIBS) $(RESOLV_LIBS)"
<raghavgururajan>Same error.
<leoprikler>then it's somewhere entirely else?
<Aurora_v_kosmose>morgansmith: I think you might have to use the repl if you don't just feel like running wget on the source.
<rekado>where can I see that CI spam, though? Are you sending emails already?
<raghavgururajan>You mean outside
<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
<civodul>rekado: it's already spamming like crazy!
<morgansmith>Aurora_v_kosmose: not the package I was originally thinking of but icedove seems to be an example of what I'm talking about
<Aurora_v_kosmose>morgansmith: I see
<bavier[m]>morgansmith: you're looking for `guix build -S <package>`
<Aurora_v_kosmose>My bad.
<morgansmith>bavier[m]: Thanks! Personally I'd rather it extract it to, but I could see how that would be up to personal preference.
<morgansmith>also guix build -S icedove gives you the icecat origin, but it's still probably a pretty good tool. I can't imagine there are too many edge cases like that
<bavier[m]>morgansmith: there's also `guix build --sources <package>`
<bavier[m]>which will also get the `thunderbird-sources` from icedove's inputs
<bavier[m]>see the `guix build` documentation
<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
*raghavgururajan is sick 🤒️
<rekado>civodul: oh, neat! New mailing list!
<bavier[m]>adding that to the cli would require a solid argument, yes :)
<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...
<Aurora_v_kosmose>Was there something equivalent to guix environment but with the actual named program included as "installed" in the environment?
<andreas-e>guix environment --ad-hoc name-of-the-program
<Aurora_v_kosmose>andreas-e: Ah, thanks.
<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>Xorg puts a few files in /tmp
<Aurora_v_kosmose>That might have to do with it.
<Aurora_v_kosmose>Namely its socket.
<civodul>rekado: see? the first package Cuirass complains about is pigx
<morgansmith>Aurora_v_kosmose: So my issue likely isn't just due to my odd X setup and maybe we should tell people to expose /tmp in the manual?
<Aurora_v_kosmose>morgansmith: I don't know enough to affirm so, but I would suspect as much.
<morgansmith>I use startx directly which is a little tricky in guix. I was thinking maybe login managers don't do that so most people wouldn't have an issue
<Aurora_v_kosmose>owo I think I finally got my project working. Hurrah for environment --ad-hoc debugging.
<Aurora_v_kosmose>It's almost a shame it's a small private project, because there really needs to be a simple example somewhere for how to generate Lisp executable programs.
<Aurora_v_kosmose>I might just make a "hello world" program to serve as such. Should I?
<morgansmith>I think we have a hello package don't we?
<Aurora_v_kosmose>For Lisp?
<Aurora_v_kosmose>The issue is basically that getting Guix to produce an executable for Lisps isn't quite as straight-forward as it ought to be.
<Aurora_v_kosmose>Being somewhat used to asdf, I'd thought merely telling :build-operation :program-op in my .asd file would be enough, but it very much wasn't.
<morgansmith>oh, the hello package is like an actual program written in C
<Aurora_v_kosmose>GNU hello
<Aurora_v_kosmose>A decent example of how to get translation working using GNU tooling, among other things.
<morgansmith>what's your project? Is it a guile script gexp thing? Like my startx script is an installed gexp script file
<Aurora_v_kosmose>It's a common lisp chatbot for a small private irc channel.
<Aurora_v_kosmose>It basically just queries the related community site for some data and returns it on-demand.
<morgansmith>Don't you just have to get the shebang right then? And shouldn't guix patch the shebang for you?
<Aurora_v_kosmose>Guix doesn't package cl-launch yet afaik.
<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>(And documentation that it even exists.)
<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.
<morgansmith>are we talking about this?
<Aurora_v_kosmose>morgansmith: I think so yes.
<Aurora_v_kosmose>Yeah, cliki has same link, you have the right thing.
<Aurora_v_kosmose>Well, there is a documented hack in cl-launch docs that might work anyway, with the caveat of using the Guix host's base /bin/sh
<amadeus->hello I'm trying to run guix pull in a vm but I keep getting this error
<raghavgururajan>leoprikler: Both libstrophe and libmesode tests fail in same way, with --without-static.
<raghavgururajan>*with --disable-static
<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)
<leoprikler>meaning it's probably the same patch for both
<heloaoban>event outside of a Guix context (ie running guix [command]).
<leoprikler>definitely worth investigating the situation
<raghavgururajan>but I tried with all $(FOO_LIBS)
<heloaoban>I can't seem to access a guix module (gnu packages python-build) from guile, even though I know it exists in my latest checkout of Guix (fresh guix pull).
<heloaoban>that module however is not in my $GUILE_LOAD_PATH, which is currently pointing to /run/current-system/profile/share/guile/site/3.0
<heloaoban>what I don't know is if $GUILE_LOAD_PATH is missing a path, or if that module should be in /run/curr.../site/3.0 but for some reason is not.
<raghavgururajan>leoprikler: I'll investigate more. Btw, the nextcloud-client patch-set is good to go right?
<heloaoban>(use-modules (gnu packages python-build)) throws a 'no code for module'.
<leoprikler>I haven't had the time to review it completely yet
<morgansmith>I seeing how hard it is to package cl-launch but I'm being stumped by this bit of shell. What on earth does this syntax mean? ${@:-cat}
<nckx>morgansmith: ‘All arguments, as separate strings, or "cat" if there are none’.
<nckx>For example: foo() { echo "${@:-cat}"; }
<nckx>then run "foo a b" vs. "foo".
<nckx>Unless they wrote it as "${@:-cat}" (with double quotes) they fail at shell.
<morgansmith>ah, that explains the shift 2. Thanks a ton!
<morgansmith>Aurora_v_kosmose: I packaged cl-launch super quick and dirty. I don't know if it works or how to use it.
<ngz>I'm not sure is free software. There is no LICENSE file, no License header in source code files. There is only a mention to AGPL3.0 in the WDYT?
<morgansmith>ngz: the guy look somewhat active on github. you could open an issue and ask
<ngz>Indeed. I'm not fond of interactions on GitHub, tho.
<alextee[m]>ngz: his email is on the README file
<alextee[m]>my monitor keeps popping up its menu today (i upgraded my system yesterday), could this be a linux bug?
<morgansmith>ngz: I thought there was a better resource somewhere but I think this is the page you're supposed to send the author:
<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
<ngz>Fair enough.
<lfam>We take this risk with *every* package we distribute. What if some github account took nonfree software they didn't own and uploaded it with a copy of the GPL?
<lfam>We might think we have the right to distribute it, and only find out we were mistaken later
<Aurora_v_kosmose>Unless the company has a public claim to the software, it's their word against the "thief" as to whoever actually created it.
<Aurora_v_kosmose>We have no way to know unless they already mentioned its existence prior.
<lfam>I was offering a vague scenario, to illustrate that we can only do our best. I agree that it could play out in a variety of different ways.
<lfam>This question has come up before. "But 1% of the files are missing the license header! It must be proprietary, even though the author says it's free."
<lfam>That's a straw-man argument, I know :)
<lfam>It happened with Chromium
<Aurora_v_kosmose>I honestly don't have such a header for any of my personal projects. I could easily see forgetting to run sed on the repository before uploading it.
<raghavgururajan>nckx: You got any ideas regarding libmesode?
<lfam>Right, and it's not required! At least in my jurisdiction, the courts put a lot of emphasis on intent
<dftxbs3e>hello! :-D
<leoprikler>I too always forget license headers on stuff that I intend to publish under the (L)GPL.
<lfam>It's really not that important
<lfam>It's something that giant corporations should do, so nobody wonders what's going on
<leoprikler>In the days of meson etc. where you can declare a license as part of the build system, people care less and less about headers.
<raghavgururajan>dftxbs3e, o/
<yoctocell>I am playing around with store monads and g-expressions, the manual says that I can run `,enter-store-monad` in the repl to make it automatically run things through the store. But when I run `,enter-store-monad` I get a big error message: <>. Any ideas?
<raghavgururajan>leoprikler: I wonder how tests passes without --disable-static
<leoprikler>idk either tbh
<leoprikler>you could try stripping -static just for funsies
<raghavgururajan>lol i did that already
<leoprikler>same result?
<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
<nckx>raghavgururajan: OK.
<nckx>raghavgururajan: ?
<lfam>fnstudio: Like, when you go to the hosting interface, and they offer you a list of OS's, those are all custom images created by the hoster, tweaked to work in their setup
<lfam>apteryx: Nobody has addressed them yet
<raghavgururajan>nckx: yeah
<apteryx>lfam: does it mean it's not possible to package them currently? Or can the current go build system we have be twisted to achieve it still?
<jackhill>fnstudio: there is a recipe for running Guix at Linode:
<apteryx>lfam: I'm looking at this specifically:
<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).
<lfam>apteryx: Someone offered to do the work recently: <>
<lfam>See the end
<jackhill>The tip about the virtio_scsi kernel module in the Linode recipe is probably relivant in other contexts too.
<fnstudio>jackhill: great, i'm going through it now, thanks
<lfam>apteryx: It's extremely far from ideal. If we don't address it soon, we'll end having to run unsupported versions of Go
<lfam>And in that case it would be better to remove Go entirely
<lfam>It would be a shame
<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).
<fnstudio>jackhill: that's a good point
<lfam>It's why I added a release artifact of a "VM image" that could be uploaded to hosters that accept uploads. It included instructions for post-boot tweaking, and it worked
<lfam>But, it was messy and we don't offer it anymore
<nckx>Oh dear.
<apteryx>lfam: thanks for the hints
<nckx>/tmp/guix-build-libmesode-0.10.1.drv-0/source/tests/test_hash.c:62: undefined reference to `hash_new'
<lfam>Now, we offer something else called a "VM image" :)
<jackhill>Guix integration with cloudinit would probably help make it more "normal" for providers
<lfam>Exactly, jackhill
<jackhill>I guess the takeaway here is that it is going to be a little awkward in different ways everywhere, but that's only because there is more work to do and not a fundimental limitation.
<nckx>raghavgururajan: So the problem is that the tests assume static linking and are otherwise broken?
<jackhill>fnstudio: ask here or on for help with a particular provider. I've done Linode and Ramnode, but others probably have experience with different providers
<nckx>That's an upstream problem (thanks for opening a bug report there), I don't think there's much we can do to fix that.
<lfam>jackhill, fnstudio: See commit 4b236c88eaa690a045bc57b9c4d2acf44ae91f17 for an example of the most very basic thing that will work
<lfam>It assumes a web console for the initial setup
<fnstudio>jackhill: cool, thanks, i think linode will actually be perfect :)
<fnstudio>lfam: super, let me have a look
<nckx>raghavgururajan: If you run ‘nm -D’ on you'll see that those symbols aren't exported at all, so of course nobody will be able to use them. That includes the tests.
<nckx>raghavgururajan: Obvious non-solution is shit but it does work:
*nckx just comes for the software gore, and is seldom disappointed.
*nckx away again.
<fnstudio>lfam: great, when you say "It assumes a web console", would you have any provider in mind that fit the bill?
<lfam>I tested it on, but most providers will offer a web console
<fnstudio>so, one creates the image locally (eg with the provided template as per your commit) and then the image is uploaded via the web console
<lfam>The image is uploaded via whatever image upload interface the hoster offers.
<raghavgururajan>> nckx‎: raghavgururajan: So the problem is that the tests assume static linking and are otherwise broken?
<lfam>The web console is like, literally, a web-based serial console
<lfam>So you can login to the system and configure it
<raghavgururajan>> ‎nckx‎: raghavgururajan: Obvious non-solution is shit but it does work:
<fnstudio>lfam: configure it as in partitioning, etc?
<lfam>Yes, partitioning and remote access are the main things
<fnstudio>lfam: ok, understood, thanks, very helpful
<lfam>Enable the network, etc
<lfam>There's just so many things that can't be set up in advance, from a default
<leoprikler>With every patch I hate rust more.
<ryanprior>What do you hate?
<cbaines>From the context, I guess the subject of the hate is rust...
<lfam>I would guess... the incredibly large number of versions that must be packaged
<lfam>Combined with dependency cycles
<lfam>Making it impossible to reason about
<mdevos>I wonder if it is possible to delegate a part of the "parent" file system to the childhurd to use as root file system? Then I wouldn't have to worry about choosing a partition size
<cbaines>I forget how many painful hours I spent packaging fractal, but it was too many
<cbaines>I'm not sure when I'm going to make another pass at it
<mdevos>It's technically possibly of course, as it is *the Hurd*, but someone still needs to have written an appropriate configuration and relevant utilities
*mdevos afk for a while
<leoprikler>cargo-build-system just added the package I'm trying to package to guix-vendor...
<leoprikler>and cargo imploded onto itself
<lfam>It's interesting to hear arguments about the choices made by Go and Rust, from a distro-maintenance perspective
<dftxbs3e>leoprikler, hey! can't see the paste!
<linus1>So, I haven't done a guix pull in about 500 days. How long will this take? :D :D
<linus1>(found an old laptop that I haven't used in a while)
<lfam>It's unpredictable. It depends on how fast the computer is
<leoprikler>oh, sorry, gnome pastes are 30m per default
<lfam>Since it is old, it will probably take hours, but less than a day
<lfam>(I'm assuming you'll have to compile things)
<linus1>oh, it is compiling allright
<linus1>It is doing some lalr stuff right now
<lfam>I recommend updating at least once a year ;)
<lfam>I hope it's an old and fast laptop, and not old and slow
<linus1>it is about 8 years old, and actually still plenty fast
<raghavgururajan>> cbaines‎: I forget how many painful hours I spent packaging fractal, but it was too many
<raghavgururajan>That looks cruel than telegram. Glad you made it though. :-)
<leoprikler>wait wat?
<raghavgururajan>*that pack-def
<leoprikler>all my precious effort...
<raghavgururajan>leoprikler: Yeah! I was *for it* :-)
<raghavgururajan>I think I confused you more.
<raghavgururajan>I mean that the dependencies of fractal looks more cruel than dependencies of telegram.
***linus1 is now known as bjoli
<cbaines>does anyone know how to list filesystems on the Hurd? I'd use fdisk, but that fails to build.
<leoprikler>Trust me, you don't want to package fractal ever.
<leoprikler>You have to seriously hate yourself to even entertain the thought.
*raghavgururajan is now tempted to try
<cbaines>leoprikler, why do you say that? I don't really have an opinion myself beyond the self-inflicted suffering I've put myself through so far, I haven't even used fractal.
<cbaines>so I'm interested to hear yours
<cbaines>part of the pain is just that there's a bunch of rust things not packaged yet, hopefully things will get easier
<raghavgururajan>I am not fond of Matrix, as I am with XMPP. But if there are guixers looking forward to Fractal, then I am willing to give it a try.
<raghavgururajan>Leo probably whispers "Amen!"
<ngz>Naive question: what is the difficult part of packaging Fractal? Importing crate returns around 5 non-packaged Rust dependencies. I assume there is a substantial non-Rust part in it?
<leoprikler>btw. cbaines can you cross-check w.r.t. the licenses you've used for the imports?
<terramorpha>Hi guys, I'm trying to run an appimage (which is open source, but depends on electron which hasen't been packaged yet) and it crashes with the following message:
<leoprikler>I feel like I might have misdeclared some that the importer couldn't resolve
<cbaines>ngz, at least when I tried a few months ago, I ended up adding many packages
<nckx>raghavgururajan: Oh, get well soon; I missed that part.
<terramorpha>fusermount: mount failed: Operation not permitted
<raghavgururajan>nckx: Thanks!
<leoprikler>ngz: there's no crate, so you can't import it, plus you have to mix in meson
<cbaines>leoprikler, I wasn't packaging things properly, more trying just to see if I could get something to build and run
<raghavgururajan>oh ... the meson shenanigans are another story ...
<ngz>Ahhh. I'm talking about another Fractal…
<leoprikler>I trust meson over cargo every day any time.
<ngz>So I can import fractal, but not the one you're talking about :)
<leoprikler>Apart from the bug that doesn't let you compile Guile meaningfully with a single-directory it's a decent system.
*raghavgururajan likes packaging stuff that requires persistence ;-)
<leoprikler>raghavgururajan: try packaging osu
*raghavgururajan looks
<leoprikler>A usable backtrace.
<leoprikler>(Of course, it's spawned by meson-build-system, not Rust.)
<ngz>cbaines: You are not using #:skip-build? #t for your Rust dependencies. Pain will ensue.
<cbaines>ngz, I'm not yet convinced by the arguments to not build rust packages by default. While the outputs may not be used, the build process and tests can mean something.
<leoprikler>Neither am I.
<leoprikler>Using #:skip-build? #t masks errors
<leoprikler>I know, because I'm only using it to mask errors.
<cbaines>I'm not sure why you'd have a package if you don't do something in that derivation. If you just want to download some stuff, you can just use the (origin ...) bit
<ngz>Ah. Then I think it would be nice to make a decision once and for all in Guix.
<ngz>I.e., actually define and follow Rust packaging guidelines.
<cbaines>Why commit to a decision once and for all? This situation is fluid as far as I can see, and flexibility is essential for it to change (and hopefully get better)
<ngz>Hmmm consistency?
<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.
<dftxbs3e>leoprikler, what about it?
<leoprikler>did you see the paste?
<dftxbs3e>leoprikler, yes
<leoprikler>that's our error
*leoprikler is close to getting fractal to build.
<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.
<ngz>There was plenty of information in it.
<leoprikler>do you have an archive link?
<leoprikler>i feel like hating on rust harder
<ngz>Sorry, I don't at the moment. I remember it was stemming from Hartmut Goebel.
<leoprikler>do you remember which ML? devel?
<ngz>I'm not sure. Probably devel.
<leoprikler>okay, I'll look it up later
<leoprikler>gotta go now, I'll be back in an hour to see horrible cargo output once more
<ngz>There's a thread from Dec. 18th 2020 named "Discussion: How to package rust crates now and in future?"
<dongcarl>sneek: later tell vagrantc why did you switch from Guile 3.0 to 2.2 for the debian Guix package in db204bf310fe11a2d2fa92b7afabafe6b0c6565f?
<sneek>Will do.
<dongcarl>sneek: botsnack
<nckx> probably.
<nckx>dongcarl: ☝
<ngz>sneek: later tell leoprikler <>
<dongcarl>nckx: Thanks!
<pkill9>how does openbsd compare with guix system for those who use openbsd?
<pkill9>specifically for server use
<civodul>dongcarl: see also for the gory details
<dongcarl>civodul: Oh... Guile 2.2 doesn't suffer from this?
<cbaines>congratulations on getting back to the g-exp build systems civodul :) I haven't had a look yet, but it sounds exciting!
<civodul>dongcarl: Guile >= 2.2.7 suffers from this but Debian didn't notice
<civodul>cbaines: exciting, but i also feel i should perform as well as the current code
<civodul>and we're not quite there yet
<zimoun>civodul: thanks for the fix of relative load-path. Better than my proposal using canonicalize-path. :-)
<civodul>heh, yw!
<mbakke>looks like cuirass has stopped processing jobs:
<civodul>mbakke: not entirely though:
<dongcarl>civodul: Argghhh
<civodul>yeah, i know that feeling
<mbakke>civodul: the workers page has not moved in a comparable time :)
<civodul>mbakke: i think that's because there's a hard limit on the number of jobs per arch or something
<civodul>wild guess
<cbaines>civodul, hmm, perfect can be the enemy of good though, personally I don't think small performance regressions when refactoring are blockers
<jonsger>good evening Guix...+
<civodul>cbaines: yeah, you're probably right
<civodul>plus there are higher-level optimizations to be done afterwards
<civodul>like creating fewer -builder files...
<jackhill>civodul zimoun: thank you both for the help with relative load paths. I'm happy to not be tripped up by that again in the future :)
<alextee[m]>great news! the vital synth is now free software:
<alextee[m]>should be ported soon under a different name due to trademark issues
<pkill9>what is vital synth?
<alextee[m]>will package it when it's ported :D
<alextee[m]>pkill9: pretty much the best synth ever created
<pkill9>is it some killer app kind of thing?
<alextee[m]>it's even better than leading proprietary ones
<rekado>wow, this looks nice!
<rekado>I really don’t like to use computers for music, but for synthesizers beyond analogue subtractive synths it’s hard to beat good software.
<alextee[m]>the amount of modulation you can do with soft synths is unbeatable :D
<dongcarl>civodul: With the scm_install_gmp_memory_functions = 0 workaround, is performance worse than 2.2.6? Or the same?
<zimoun>jackhill: yw :-)
<leoprikler>sneek: botsnack
<sneek>Welcome back leoprikler, you have 1 message!
<sneek>leoprikler, ngz says: <>
<civodul>dongcarl: should be about the same, but you'd only see the difference on bignum-heavy applications, which are rare
<maxxcan>hello everyone
<maxxcan>I'm new with guix
<bavier[m]>hi maxxcan
<maxxcan>Anyone could give me a guide or something to fix packages that it don't install correctly?
<maxxcan>hello bavier[m]
<leoprikler>"It's our responsibility to protect the earth! Yes to #:skip-build #t". I'd rather say "no to cargo, please find a sane way of compiling rust, tyvm".
<leoprikler>Of course, Rust was not built on a foundation of compiling sanely.
<maxxcan>sorry for my lack of education
<maxxcan>the first is to say that I love guix and I think that have a great community
<leoprikler>maxxcan[m]: What's missing from the installation and which package?
<maxxcan>leoprikler: I have problems with two packages: freecad and pigx
<graingertaa>/!\ this chat has moved to #pp /!\
<kondor>sneek: botsnack
<thisisbillyQp>/!\ this chat has moved to #pp /!\
<maxxcan>leoprikler: I see the drv files and only say make return a status 2 error
<kondor>cheeky sneeky
<lispmacs[work]>has anybody here used qucs in the past? I really want to install it, but every guix commit I've tried so far has qucs or a qucs dependency broken
<leoprikler>there should be a log file, but error 2 in make means something recursive went wrong IIRC
<maxxcan>leoprikler: I think maybe a python problem
<leoprikler>According to CI, the failure is in vtk-8.2.0.
<maxxcan>leoprikler: I really need a guide to study the problem myself
<leoprikler>Okay, so first step: Figure out the package that fails.
<leoprikler>In this case I told you it's vtk.
<leoprikler>Next, figure out when it fails (build, check, etc.)
<maxxcan>ok. the package is freecad, the first, and fail when build it at 78%
<leoprikler>now inspect the full logs. You should get compiler warnings and build system stuff intermingled with everything.
<leoprikler>The first "error" is the one you want to look at. Everything else probably follows from there.
<leoprikler>Note, that due to parallel builds, this can be at a vastly different location from where it's reported.
<leoprikler>I had packages, that fail at 20% but compile up to 80% for instance.
<maxxcan>leoprikler: ok
<leoprikler>after that it mostly comes down to your knowledge of the programming language the breaking stuff is implemented in.
<leoprikler>for C++ it really helps if you are used to its weird diagnostics
<maxxcan>leoprikler: the main log file is the drv file I suppose
<leoprikler>no, the drv is nothing
<leoprikler>the main log file is a log.bz2
<leoprikler>guix tells you to bzless it
<bavier[m]>lispmacs[work]: I've not used qucs in the past, but `guix build qucs` worked for me just now: /gnu/store/jj1r6aanzxfyk9zdd9b290q432gqc0jy-qucs-0.0.19-0.b4f27d9
<leoprikler>(that's a bit of a lie, the .drv is not nothing, but it's no build log)
<lispmacs[work]>bavier[m]: can you send me your guix commit number please
<lispmacs[work]>from guix describe or something
<cbaines>lispmacs[work], the data here suggests it's possible to build it successfully
<bavier[m]>lispmacs[work]: I'm on commit 892d395