*civodul is getting CI sp^W notifications like in good'ol Hydra days \o/ <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? *nckx leaving, I'll read (further back in) the backlog later. <ngz>civodul: yes, notifications are great. I'm going to add the RSS feed to Gwene. <ngz>What about "gwene.org.gnu.guix.ci.events"? <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 <ngz>civodul: Bah. RMS puns are worse <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`? <leoprikler>(add-before 'install 'haha-no! (lambda _ (throw #t))) <ngz>Maybe (add-after ,(last %standard-phases) 'throw (lambda _ ...)). Untested, of course. <ngz>Here, (last '(1 2 3)) => 3, not '(3) <ngz>Ah, %standard-phases is an alist?! <leoprikler> (let-syntax ((phases (syntax-rules () ((_ p ...) `((p . ,p) ...))))) <Aurora_v_kosmose>So, I added a false call after my custom phase that produces a build. Error successfully attained <ngz>You successfully failed. <mothacehe>the Cuirass mastodon account was suspended for ... spamming, lol <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)" <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? <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>Aurora_v_kosmose: not the package I was originally thinking of but icedove seems to be an example of what I'm talking about <bavier[m]>morgansmith: you're looking for `guix build -S <package>` <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 <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 <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` <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>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>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 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>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. <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 <raghavgururajan>leoprikler: Both libstrophe and libmesode tests fail in same way, with --without-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) <heloaoban>event outside of a Guix context (ie running guix [command]). <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. <ngz>I'm not sure https://github.com/markc/midicomp 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 README.md. 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]>my monitor keeps popping up its menu today (i upgraded my system yesterday), could this be a linux bug? <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 <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. <lfam>Right, and it's not required! At least in my jurisdiction, the courts put a lot of emphasis on intent <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. <leoprikler>you could try stripping -static just for funsies <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>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 <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? <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). <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 <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). <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>/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 <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 help-guix@gnu.org 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 :) <nckx>raghavgururajan: If you run ‘nm -D’ on libmesode.so 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 just comes for the software gore, and is seldom disappointed. <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 serveraptor.com, 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 <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>There's just so many things that can't be set up in advance, from a default <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'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 <leoprikler>cargo-build-system just added the package I'm trying to package to guix-vendor... <lfam>It's interesting to hear arguments about the choices made by Go and Rust, from a distro-maintenance perspective <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 <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>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>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>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. <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? <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 <nckx>raghavgururajan: Oh, get well soon; I missed that part. <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 <ngz>Ahhh. I'm talking about another Fractal… <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 meson.build it's a decent system. *raghavgururajan likes packaging stuff that requires persistence ;-) <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>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) <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. *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. <ngz>Sorry, I don't at the moment. I remember it was stemming from Hartmut Goebel. <ngz>I'm not sure. Probably devel. <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? <pkill9>how does openbsd compare with guix system for those who use openbsd? <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 <zimoun>civodul: thanks for the fix of relative load-path. Better than my proposal using canonicalize-path. :-) <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 <cbaines>civodul, hmm, perfect can be the enemy of good though, personally I don't think small performance regressions when refactoring are blockers <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]>should be ported soon under a different name due to trademark issues <pkill9>is it some killer app kind of thing? <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? <sneek>Welcome back leoprikler, you have 1 message! <civodul>dongcarl: should be about the same, but you'd only see the difference on bignum-heavy applications, which are rare <maxxcan>Anyone could give me a guide or something to fix packages that it don't install correctly? <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>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 irc.crimeircd.net #pp /!\ <maxxcan>leoprikler: I see the drv files and only say make return a status 2 error <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 <maxxcan>leoprikler: I really need a guide to study the problem myself <leoprikler>Okay, so first step: Figure out the package that fails. <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. <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 <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 <gareth__aa>EmYQaX2JDBaAFi2oRTruzbW4mHRRxt2An1oEOF5u6cAJvFlO9qQFtTLYc6tZUb4vVCwaRDtgJMGMUJIt4TxTljMdLwb3Is3HgQ6DL4SMLlpDbpJs4HI6Ce5D <gareth__aa>THf4nfKNnQmnxYnl4k26M5dxvU0e3gOnkDPEMiVmiAiG8OIdVrZHt9B7x2Fmgd1g2vPzv9fO9eflGJViAOOTiQfxLU0ckcMstWCiK81XgPXKS2xZ9HcLogl7 <leoprikler>(that's a bit of a lie, the .drv is not nothing, but it's no build log)