<Noisytoot>My computer shut down when running guix pull, and after I ran guix pull again, I get "guix package: error: error parsing derivation `/gnu/store/3nckx3s0j1dgynd7an0agwhc5x4yk1r4-pipewire-0.3.22-checkout.drv': expected string `Derive(['" when running guix package -u
<oriansj>ixmpp: it hard to provide a response when one doesn't have productive one to give. Sometimes the answer to why somethings are done a certain way is simply because the few people doing all of the work decided to do it the way they wanted.
<oriansj>if enough people are willing to put in enough effort, guix will turn on a dime to support that improvement. (see how hard Guix changed on their original stance in regards to bootstrapping Guix after janneke and I did a boatload of work.)
<oriansj>So when the question is why didn't they do "thing that probably requires a volume of work" the answer is usually because no developer wanted to work on it and/or they had something more important to deal with first.
<oriansj>and sometimes the answer to why this bug/error/issue hasn't been fixed is because they didn't know about it yet or haven't figured out how to solve it yet.
<pkill9>yea, I guess since the daemon is working and there aren't immediate benefits to rewriting it in guile, people haven't been working on it
<leoprikler>Noclip[m]: Wait a sec, Red Hat doesn't even support x86?
<vagrantc>cbaines: i think i struggle reading your updates and still failing to find such things
<cbaines>pkill9, I just put the URL in. I should probably just add a link to it, and hide the absent ci.guix.gnu.org data
<vagrantc>cbaines: i probably also mash various different projects you're working on together in my mind ... e.g. data service, build coordinator, patchwork, etc.
<oriansj>leoprikler: well the last 32bit only x86 CPU (excluding Intel's Quark which is just a micrcontroller) was Intel's Tulsa from 2006; So it has been 15 years and dropping support wouldn't be unreasonable
<vldn>someone got a simple example how to create a simple herd service that runs a executable within my systemconfig.scm?
<cbaines>vagrantc, right, I can't remember sending a recent update about the Guix Data Service, but you're right that they are all somewhat related and interconnected
<vagrantc>but yeah, documenting at least all the ones on guix.gnu.org domains seems like a good idea
<cbaines>vagrantc, I did see your message on IRC about a couple of patches not being processed, and it probably was to do with them being attachments
<drakonis>linux-libre is weird with loading free firmware lol
<drakonis>its breaking power saving on intel hardware
<vagrantc>cbaines: that's what i get for not quite following the recommended process, i guess. :)
<vagrantc>cbaines: though curiously, patchwork seems to see the patch just fine
<cbaines>vagrantc, well, I think patchwork may have only picked up one of the two attached patches
<vagrantc>now i have three strategies to fix booting from NVMe on pinebook pro ... get a different NVMe device (apparently this is not an issue with all NVMe), figure out how to fix the issue in u-boot itself, or figure out how to support split /boot on guix: https://issues.guix.gnu.org/48172
<vagrantc>for u-boot with extlinux.conf ... it really comes down to copying the relevent /gnu/store/*-linux-libre-*/ and /gnu/store/*/initrd-cpio.gz into /boot
<vagrantc>for grub*, you would also have to copy relevent grub bits to the store
<brendyn>raghavgururajan, maybe ill impersonate you and package some things just to confuse you
<sarg>Let's say I have a local guix checkout and I've a package with several dependencies spread between many scm files. Is there a way to test how it works without building the guix itself?
<sarg>I mean, I've added a new package and want to test it. With simple packages I usually just `guix package -f`, but here changes touch multipe files
<efraim>I sometimes will just open an extra screen tab and run 'guix environment guix -- make && exit' in it to compile guix itself in the background while working on other stuff
<efraim>I haven't found a good way to use files which evaluate to packages as dependencies for other packages so I'll sometimes just grab them into the main file I'm building. Otherwise I try to work within a repository so I can pass '-L /path/to/repo' so I can add all the definitions to the path
<brendyn>not exactly. youd have to copy paste the changes into one scm file to make it work with -f
<sarg>what if I make a directory with all the changed files (preserving structure) and then do `guix package -L ~/guix-overlay some-package`?
<brendyn>one thing i do thats is create my own channel
<bricewge>What's the nameing scheme for dlang libraries, d-foo, dlang-foo?
<efraim>go gets go, not golang, so 'd-' should probably be fine
<efraim>if you're the first then you more or less get to choose :)
<efraim>sneek: later tell vagrantc how'd you make the debian image for the hifive unmatched? I'm convinced there's something wrong with my base image so I was going to start with a fresh one and I'd rather use debian
<sneek>nckx, dstolfa says: i've been planning a few more changes to strongswan, some of which depend on the service patch landing, others don't. should i wait and focus on getting this sorted first, or should i submit a few that don't (e.g. updating the version)
<nckx>Cool. I'm looking at the service now. Submitting both kinds is fine; add a clear note (with its issue URL) to the ones that depend on the service.
<nckx><Noisytoot> My computer shut down when running guix pull, and after I ran guix pull again, I get "guix package: error: error parsing derivation `/gnu/store/3nckx3
<efraim>I'll have to look into it more to see exactly what it did. GRUB was installed, I'm back inside my system
<nckx>I'm mainly interested in whether it's related to the 2.06 bump or just an unfortunate coincidence. I don't see how it would be related: the efibootmgr invocation in grub-core/osdep/unix/platform.c was last changed a year before even 2.04.
<nckx>dstolfa: If you're using the submitted service successfully it LGTM with the comments I just sent.
<dstolfa>nckx: yep, i've been using it for the past week and a half or so. i'm writing a reply regarding some of the comments & will write the docs. does it make sense to send the docs in as a separate patch from this, or should i send it as a part of it?
<user__>I'm trying to configure openvpn, how do I properly set up the names, addresses and port of the remote servers?
<user__>I'm new to Scheme, so I don't know how to create openvpn-remote-configuration
<user__>It's strange that openvpn-remote-configuration does not have a parameter for the address, at least that's what I see in the documentation
<nckx>If you've not configured OpenVPN before (=me) it's not really clear. Is ‘server name’ a domain name? Maybe roptat can be summoned.
<user__>nckx: name parameter probably means address and not its label
<dstolfa>nckx: regarding the 2 ifs and 2 strongswan-dirs, would you still prefer me to refactor it, or are you happy for it to stay like this for now and then if the "else" branch is not really necessary to be this way when i've done swanctl to do it then?
<user__>There's one last thing, reading the docs, openvpn-client-service is in the same category as *-service-type, right? If so, I've added openvpn-client-service [#:config (openvpn-client-configuration)] to the list of services in my config but apparently "#:config" has the wrong type to apply. What am I missing?
<nckx>user__: I can only find examples of it using a (working) domain name, not an IP address, but the latter should probably work too. It's just turned into a ‘remote <name> <port>’ line in the openvpn configuration file BTW.
<nckx>user__: Remove ‘[’ and ‘]’, they are synonyms for ‘(’ and ‘)’ meaning you're trying to call (=apply) #:config as a procedure. I guess you copied them from some docs by accident.
<nckx>dstolfa: I'm having trouble parsing ‘then if the "else" branch is not really necessary to be this way when i've done swanctl to do it then’ but I think you mean to wait & see whether adding swanctl will remove this part entirely, and if not, factor it out then?
<ft>Hm. I got a package definition, that depends on another package for build purposes (running the test-suite). It's in the dependencies list of the package for that reason, and for building from source that's true. But once the package is built, the other is not required anymore, and I suppose it could be removed in a gc run. Does guix have a notion of this, or does it require all dependencies always?
<efraim>It's unlikely it's related to the grub update. I tried to reconfigure with an older generation which still had grub 2.04 and I got the same error
<dstolfa>nckx: yeah, i'm basically unsure what the whole thing will look like after i write the EDSL for swanctl so this is a rough outline of the service anyway
<ft>Hm. I thought native-input is for packages I need in the version of the build-host for cross-compilation purposes.
<nckx>Inputs mean ‘inputs into the build function’, and are availabe for use during the build. ‘Native’ inputs are always the same architecture as the one you're building on and can run during the build, but maybe not afterwards. Regular inputs are the same architecture as the one you're building *for* and might not be able to run during the build. That matters when cross-compiling.
<dstolfa>but i'd like to use linux-libre if possible, but my battery life is literally half of what it should be with it lol
<zhu_zihao>propagated-input: Something we need it but we can't embbed into artifact, we will locate it at runtime by some other method(e.g. environment variable)
<nckx>ft: If your final build results mentions the string /gnu/store/hash-that-other-package anywhere, Guix will keep it as long as ‘package’ is live. Otherwise, ‘other package’ is subject to GC'ing immediately after the build.
<dstolfa>i feel it might be a linux-libre bug with the deblobbing script... possibly their sed is stripping out something that it shouldn't
<dstolfa>maybe it thinks an array of control bytes is a blob or something
<zhu_zihao>native-input: generally the things we only need in build time(e.g. compiler, doc-generator, patches)
<user__>nckx: Sorry, but I'm unable to make it work with "openvpn-client-service #:config (openvpn-client-configuration)" -- Where did you get those config examples? I couldn't find any
<ft>nckx: I see. Thanks! Some of these dependencies might be heavy, like pandoc and texlive for generating documentation. So it's good to know they are going to be removed on systems that don't use them otherwise. :)
<nckx>user__: In a local collection of git repositories that I encountered over the years and keep around for inspiration. I don't keep track of licences or feel like asking the owner for permission so here's an anonymised example: https://paste.debian.net/plainh/f12ffd88
<nckx>zhu_zihao's checklist is good too, if (necessarily) a bit lossy.
<nckx>ft: Yep. If you don't build ‘package’ locally, and ‘package’ doesn't refer to texlive (=embed that store string), Guix literally *won't know* ‘package’ ever used texlive. It literally doesn't track that or care.
<ft>nckx: "guix show foobar" does show native-inputs in the "dependencies" field. That's about the overall dependencies then? (I have a strong debian background, and there is a distinction between dependencies and build-dependencies in their query output. Maybe this is confusing me. :))
*dstolfa notes that while modern laptops are terrible in many ways, they are also literal workstations
<zhu_zihao>yes, it'll show native-inputs, but not all, some are hidden in the build-system (or you'll see gcc make everywhere!)
<nckx>ft: I really wish ‘guix show’ had never used the term ‘dependencies’; it only ever confuses people. They *always* think of Debian. The danger of metaphor. It was a mistake.
<nckx>It should just say ‘inputs’ but that would break Jeb-Bob's script now.
<nckx>I don't even know what ‘overall dependencies’ means. Is that a Debian term?
<dstolfa>hmm, why does my local build (without any changes) fail on some tests, namely cpan, builders, elpa, build-utils, challenge, etc
<ft>nckx: No, I just made that up to combine all the inputs fields. :)
<ft>But yeah, using an operating system for like 25 years will tie some terms to a certain meaning in your head. :)
<nckx>They might have a different CPU architecture or be propagated, that's it. There's no x-time sometimes-input on a Sunday.
<nckx>Every kind of input is thrown into the build environment. The build system does its thing. Then the environment is destroyed and all inputs become subject to GC, unless the build output keeps a reference to them.
<nckx>‘guix show’ operates on package definitions (objects), it doesn't have access to built packages. It can only show the explicitly declared *inputs fields. It has no idea what might end up as a reference or not.
<zhu_zihao>that file will contains some metadata, and the references of package
<ft>Ah okay. I think my mental model is now clearer. Thanks guys! :)
<nckx>ft: A substitute is just an archive of a /gnu/store/… directory. Whilst it's true that the .narinfo metadata from the server includes a References: field as a time-saving optimisation, it's just that. Guix *could* download the opaque substitute, unpack it to /gnu/store, then scan it for missing /gnu/store/… references and substitute those in turn.
<nckx>I just think it's important to point out that Guix in no way saves the list of inputs after building something. There's no out-of-band inputs/dependency/whatever list.
<ft>Yeah. That last point is hard for me to wrap my head around. I don't really get how you'd calculate the dependency of, say, some Perl module to another without an explicit statement of such a fact.
<ft>This does seem a little magical to me, in the general case at least.
<nckx>Heh, Perl modules aren't the general case, they unfortunately use propagation for that and that *is* exactly that. A hacky note that says ‘when installing perl-some-module, install perl-some-other-module behind the user's back’.
<ft>Hehe, I see. Well, the general case in my head is the case that works in general. But I guess that is next to impossible to do, given the nature of software.
<nckx>But the real general case (compiled binaries) is: we know that Mesa needs to be installed when installing IceCat, simply because /gnu/store/…icecat…/bin/icecat contains /gnu/store/…mesa…/lib in its ELF headers.
<nckx>rpath or runpath I always forget which is which.
<zhu_zihao>so there's a conflict detector for propagated inputs.
<nckx>I haven't monitored the bandwidth for a while since the farm's still down and the nginx caching front end, for what little of value it still contains, in unmetered, but it was pleasantly unmurderous.
<roptat>user___, but if the service instead sends its log to the standard output, it's lost forever :/
<ecbrown>nckx: that's good to hear! i had fears of fortune 500's using me for their texlive
<ixmpp>> can someone explain to me the hate towards lenny? is it really just "me no like systemd"?
<ixmpp>The guy constantly tries to push his image of what linux should look like, which is very different to what most people want(ed). Most of his ideas are just copying shit from OSX, and all of them led to pain for those of us who wanted to opt-out but reasonably couldnt because they spread like viruses
<nckx>Can we please not? This ritual play has been performed to death elswhere, and that's where it belongs.
<roptat>it happened to me when the server was advertising its internal network, but it was the same range as my local network, so I could not reach the gateway (it was trying to send to the same IP on the other side of the VPN, and that needed to send the packet to the gateway, etc...)
<avp>Hello Guixers. I have the following problem in Guix: when I try to `make distcheck` a program with Texinfo documentation, it fails with "You don't have a working TeX binary (tex) installed..." -- although I have Texinfo installed both for the system profile and my personal profile.
<avp>ecbrown: Thanks, you were right -- I installed Texlive and that solved the error. Seems that I seen that error before but forgot how I managed to solve it, and the error message is somewhat misleading.
<ixmpp>> ixmpp: So it digs into systemd internals?
<ixmpp>It loads libsystemd.so without being linked against it. Without running it through radare, i have no clue what flavour of bullshit it does with the library, but when i tried tricking it into using elogind instead it threw SIGILLs at me again, like it did when it couldnt find systemd
<nckx>itd: It's probably just an accidental remnant of code that was never pushed upstream.
<lfam>jackhill: Hm, it doesn't seem right that it would take hours
<lfam>Does the problem recur if you stop it and try again?
<nckx>[good first patch] to remove the unused export for anyone who's interested.
<jackhill>lfam: yes. I've tried guix build ….drv on the offload machine (I was using offloading) and it still happens. Redoing it did help with some, but this hamlib one seems to be persisten (or I'm really unluckly)
<lfam>There may be children so pick the lowest number / parent
<dstolfa>nckx: is the patch in a sensible format btw, or would you like me to change something obvious btw? i didn't really understand fully what you meant with the guix commit message, but i assume it was just to actually put in the thing you said. correct?
<ixmpp>Can anyone think of a way for me to programmatically store a "build instruction" e.g. store that i want to build this custom modded htop, exactly as would be built right now, so that it can be built later, regardless of any channel changes or guix pulls?
<ixmpp>Tried doing it in scheme, no luck, shepherd is insanity. If i just invoke the original "guix", i lose the ability to pass scheme values. What do?
<lfam>The "build instruction" is the derivation (.drv file)
<lfam>So, if you don't garbage collect it, you can do `guix build /gnu/store/...-name-version.drv`
<lfam>But, I think there is probably a more idiomatic way to do this
<nckx>dstolfa: Ah, well, this is a bit more finicky but: the commit message is what will be used as, well, the commit message by ‘git am’. It's everything before ‘---’ in the mail and shouldn't have leading spaces. You can write the more conversational part of your mail (that won't end up in git history) under ‘---‘ where git will ignore it.
<ixmpp>I.e. depend on derivations from built packages
<lfam>Not all of us are Scheme wizards :) Many of us are just regular computer users
<ixmpp>Inferiors might work. Worth a try, but then i run into the boundaries of function of shepherd again
<lfam>Based on what you wrote, the intro of the Inferiors manual section makes me think it's relevant:
<lfam>Sometimes you might need to mix packages from the revision of Guix you’re currently running with packages available in a different revision of Guix. Guix inferiors allow you to achieve that by composing different Guix revisions in arbitrary ways.
***hrnz is now known as hrnz[m]
***hrnz[m] is now known as hrnz
<ixmpp>For sure, but ive previously tried to build packages in a shepherd script and failed, with nobody able to help
<lfam>Like, you wrote a service to build packages?
<lfam>But it kind of highlights the "happy paths" of package management with GUix
<lfam>I'm not sure that writing a custom service to build packages is something that anyone can support with, like, a link to the manual
***jonsger1 is now known as jonsger
***form_fee- is now known as form_feed
<jackhill>ixmpp: I'm also not clear on what exactly you're trying to achive, but if changing what gc conciders garbage is it, then perhaps look at the --gc-keep-outputs adn --gc-keep-derivations guix-daemon options.
<jackhill>Otherwise, I may be a question for email@example.com
***Kimapr5 is now known as Kimapr
<ixmpp>I'll work it out myself or just not do it, if nobody has any clues
<lfam_>If you can describe your goals succinctly, a message to <firstname.lastname@example.org> may be more efficient
<lfam_>Well, IRC is kind of crapping out for me now
***MidAutumnMoon2 is now known as MidAutumnMoon
***dongcarl6 is now known as dongcarl
<lfam>ixmpp: There are a lot of skilled Guix hackers who don't hang out on IRC
<lfam>You're more likely to get help with complex subjects on the mailing list
<bdax>out of interest, is the nix-daemon that guix relies on getting rewritten in guile, or are the guix developers planning on continuing to use the nix-daemon?
<danderson>+1 to that question. I've been reading the (very educational, thank you!) blog posts on Guile's implementation, and it wasn't clear to me if Guix is using the unmodified Nix daemon, or a fork from some time ago, or what.
<danderson>I guess it's still mostly the same as Nix, because there's still derivation files, nars and other very nix-centric implementation things floating around.
<jackhill>nckx: we, the Guix Community™ :) Yeah, that may be so, I definitely don't know enough yet, but get the general sense that replacing a working thing can be more difficult than creating new functionality.
<jackhill>Do we have a specification for what the daemon should do?
<danderson>That part seems easier to me: make the new daemon build all of guix from scratch, verify that the output is bit-identical to the old daemon
<danderson>(within whatever deviations are expected from not being 100% reproducible)