IRC channel logs

2021-06-13.log

back to list of logs

<yoctocell>ixmpp: btw, i have commit access to the rde repo. just a heads up: i am refactoring the ssh service, so things might break the next time you pull
<ixmpp>Oh ok
<ixmpp>Np
<yoctocell>ixmpp: just pushed the patch and the refactor, see if everything is still okay for you
<ixmpp><3
<solene>good night
<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
<Noisytoot>How can I fix it?
*Noisytoot tries guix gc
<pkill9>what is the contents of that file Noisytoot?
<Noisytoot>pkill9, I don't know because I ran guix gc
<ixmpp>It'd be nice if .drv files used s-exps instead of that weird nix syntax
<ixmpp>I would legit implement that myself tbh, cant be hard
<ixmpp>Its just the legacy nix code
<drakonis>ixmpp: it'd require migrating away from the nix daemon's remains
<drakonis>there's something in progress but it moves at a glacial pace
<ixmpp>Which we're doing anyway?
<ixmpp>Yeah
<vldn>i wanted to define with (make <service>) a service within my config.scm but it complains : error: make: unbound variable error: make: unbound variable
<vldn> error: make: unbound variable
<ixmpp>Its not like we track upstream
<ixmpp>Whats the damn harm
<drakonis> https://git.savannah.gnu.org/cgit/guix.git/log/?h=guile-daemon
<ixmpp>I saw.
<ixmpp>I even asked about it a few days ago, but nobody responded, cause idfk welcome to irc
<pkill9>Noisytoot: did your problem get fixed?
<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?
<leoprikler>How?
<Noclip[m]>leoprikler: Ah what mhh, let me look a the list ...
<Noclip[m]>leoprikler: Looks like the list tells the truth and they droped support for x86-32 in the past: https://access.redhat.com/discussions/1473003
<Noclip[m]>And Fedora also droped support for 32 bit architectures in the past.
<Noisytoot>pkill9, guix package -u is still running
<pkill9>how do i view jobs on guix data service for packages?
<pkill9>oh i may be thinking of wrong interface
<pkill9>need to go on hydra or whatrever
<cbaines>pkill9, the Guix Data Service can track builds, the data is only really availabile when the Guix Build Coordinator is the thing used for the builds though
<cbaines>there's this page for example http://data.guix.gnu.org/revision/0b73c5b89ad9ef630a4e82995ab2e6f087f4aca0/builds
<vagrantc>hah. i've struggled to find the URL for guix data service so many times ...
<cbaines>do you mean specific URLs, or just the data.guix.gnu.org one?
<vagrantc>just the overarching url ...
<vagrantc>easy to find the source code, but not the running instance :)
<cbaines>A link to data.guix.gnu.org could probably be added to the README
<pkill9>how did you get to that page cbaines?
<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>cbaines: oh, good point!
<vagrantc>for whatever reason, i have a hard time sending one-patch-per-email...
<vagrantc>it means if i sign the email, N signatures i guess as opposed to 1
<cbaines>once I've got the bordeaux.guix.gnu.org stuff over the "users actually use it" line, I'll hopefully be able to get back to looking more at patches stuff
<cbaines>I'm going to get some sleep now though, so good night o/
<vagrantc>oh, i should use in on aarch64 at least ... even if the coverage isn't great, there's some chance what's not on ci.guix.gnu.org will be there
<vagrantc>\o
<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
<ixmpp>yoctocell: having issues with your push
<ixmpp>Wont accept ssh-host args
<dissoc>how do i use a variable for listen inside of nginx-server-configuration. for example (string-append %host-ip ":80")
<dissoc>do i have to do something with g-expressions?
<drakonis>haha finally my build works
***terpri is now known as robin
<ixmpp>sneek: later tell yoctocell worked out the docs for your push are askew now, but also toplevel opts are injected under "*", should maybe https://git.sr.ht/~abcdw/rde/tree/bab0473f32f354dc0231cc96876a50c60e4e0b56/item/gnu/home-services/ssh.scm#L201 be #t, not #f?
<sneek>Got it.
<drakonis>hmm, how should i handle software that doesnt play nicely with symlinking?
<drakonis>do i use a guile wrapper to invoke gzdoom with its required files or a shell script?
<vagrantc>ok, guix riscv64 debian package is ... somewhat functional
*vagrantc watches it start rebuilding the world
<vagrantc>efraim: ^^ it's working i think :)
*vagrantc wanders off to read a book
<jackhill>has anyone else seen grafting get stuck when doing emulated armhf builds? It seems to be stuck like this for hours: https://paste.debian.net/1201040/
<jackhill>I know that emulated builds could be slow, but was surprised to see problems in grafting. This didn't happen with aarch64
<raghavgururajan>Like sleep-walking, have someone heard of sleep-packaging?
*raghavgururajan has sleep-packaged SlStatus (https://issues.guix.gnu.org/issue/48996)
<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
<brendyn>it might be what you want
<brendyn>and you can use GUIX_PACKAGE_PATH
<sarg>yeah, I do have my channel. I now want to contribute packages from it to the guix
<brendyn>can you not simply build guix? it shouldn't take too long
<sarg>in a fact I am currently building it. I think 15 minutes have already passed
<brendyn>after you build it the first time, you can make small changes and you wont need to rebuild it again
<brendyn>or only just those files that changed
<sarg>that's reassuring
<brendyn>i also use git work trees to work on multiple things in parallel
<soheilkhanalipur> https://unix.stackexchange.com/questions/654000/bridging-adsl-to-lan-in-guix-system
<soheilkhanalipur>Please answer my friend (he is a novice)
<bricewge>soheilkhanalipur: You got some answer about it yesterday, checkout the logs http://logs.guix.gnu.org/guix/2021-06-12.log
<soheilkhanalipur>bricewge: As I said he is a novice, please tell him on the site
<bricewge>I don't have a SO account
<bricewge>I don't see many dlang package
<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>Got it.
<efraim>sneek: botsnack
<bricewge>Let's go with d-foo then
<sneek>:)
<bricewge>It's strange that there is a dub-build-system, but no packages using it yet
<efraim>Grub didn't install cleanly for me
<cbaines>efraim, o/
<efraim>I should've reconfigured after it failed but I thought I had time and then my machine crashed
<efraim>Looks like I get to do some repairing today
<bricewge>In a build-system, inputs are only bags isn't it?
<bricewge>Is it possible to get an input's package name or version from there?
<cbaines>on the store side, inputs are just names (from the inputs bit in the package definition) and the store paths
<cbaines>why do you want the package name/version bricewge ?
<bricewge>cbaines: dub-build-system is unused, I'm trying to use it
<bricewge>dub expect to have the it's library to be named "name-version"
<cbaines>I don't know anything about that build system unfortunately
<bricewge>Do you know of another build-system doing something similar?
<ecbrown>would someone help me in the right direction of creating a make-introduction block? i am in unfamiliar territory, i believe it requires gpg (which i have a public key)
<ecbrown>(i.e. so i don't have to --disable-authentication)
<ecbrown>perhaps you can teach me to fish: is this "signing commits with gpg" territory?
<flatwhatson>ecbrown: https://guix.gnu.org/manual/en/html_node/Specifying-Channel-Authorizations.html
<bricewge>ecbrown: To sign a commit gpg commit -S $keyid
<ecbrown>flatwhatson: bricewge: thank you, thank section simply elided my eyes
<soheilkhanalipur>Is there a pppoeconf/like for GuixSystem?
<efraim>Any idea on 'efibootmgr failed to register the boot entry'
<bricewge>efraim: Last time I forgot the full path for -loader
<bricewge>Not more info with -v?
<bricewge>soheilkhanalipur: There is networkmanager, it's build with ppp so it shoud work for PPPOE. But I have never tested it myself
<zihao`>what prevents us from merging these PR that fixes qt wrapper from staging to master? :(
<zihao`> https://github.com/guix-mirror/guix/commit/2214b7b78d34a0e4d574b743dbeb8457356f6cff
<nckx>Morning Guix.
<sneek>nckx, you have 1 message!
<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
<nckx>why did ur hash ping me
<nckx>But yeah, that just means the file is empty because your box reset. Usually happens on ext4.
<nckx>Nothing more.
<nckx>efraim: Is this after the GRUB update to 2.06?
<efraim>Yes, but in my frankenrescueshell I can't downgrade either
<nckx>What does ‘efibootmgr -v’ print?
<efraim>Looks like it might be an nvram error
<efraim>Could not prepare Boot variable: No such file or directory
<dstolfa>nckx: cool, thanks. i'll aim to submit a patch today to update strongswan to the latest version, as we're at least a year behind now :)
<dstolfa>i'd also like to get docs going for it
<nckx>Yeah, that was one of my points. Minimal working services are fine, undocumented ones not so much :)
<nckx>ecbrown: You can also set commit.gpgsign = true in either your global git configuration or (probably?) per-repository if you want to sign by default.
<efraim>I'm back in!
<efraim>had to issue grub-install with the --removable flag in the end to make it take
<efraim>and of course now I'm afraid to upgrade my computer :/
<nckx>That just disables the EFI nvram update, though, no?
<nckx>So GRUB itself was correctly installed?
<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
<nckx>dstolfa: Documentation always included.
<dstolfa>alright
<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?
<nckx>If so, OK.
<nckx>It was more for readability anyway, and that readability was relative to begin with.
<roptat>nckx, user__ I don't remember honestly
<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
<nckx>dstolfa: OK! 👍
<ft>Is this where propagated-inputs come into play? If I need a dependency at runtime, it needs to go in there?
<nckx>No.
<nckx>The ‘other package’ is a native-input.
<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.
<ft>I guess I don't fully get it yet. :)
<nckx>Yes, exactly.
*dstolfa always forgets to run make authenticate locally
<nckx>The propagated-inputs field needs to be renamed to propagated-do-you-see-runtime-here-no-i-didnt-think-so-who-ever-implied-it-means-runtime-inputs 😉
<nckx>That's still too easy to type but it's a start.
<dstolfa>as an aside, does anyone know why linux-libre power saving doesn't work correctly on i915?
<dstolfa>it's completely broken
<nckx>What's the symptom?
<nckx>I use i915 but not Linux-Libre.
<dstolfa>nckx: it just fails to switch power states... not sure why
<nckx>But nor do I use any extra firmware AFAIK.
<zhu_zihao>inputs: Something will be embbed in the final build artifact(e.g. the dynamic library dependency, its full path will be embbed in ELF)
<dstolfa>yeah i compiled my own linux and it works fine
<dstolfa>also no extra firmware
<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.
<user__>nckx: It's what I needed, thank you
<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>It only shows explicit inputs.
<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.
<ft>How does that work with substitutions then?
<ft>Or is that recorded for each substitution?
<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.
<ft>Makes sense.
<nckx>ft: Package transformation options? (--with-input, etc.)
<zhu_zihao>when guix tries to substitute, it will query the server for a narinfo file
<nckx>Oh, dur.
<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.
<nckx>For an example of such a narinfo: curl https://ci.guix.gnu.org/j4bc5p39kfqq8p9kmn7y56p3fr3rai17.narinfo
<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>Straight from hell.
<zhu_zihao>if a propagates c-0.1, b propagates c-0.2, if you try to install a & b into one profile, guix will signal an error and leave the hot potato to user :)
<nckx>Said user will then have a bad day and schedule another rant against excessive propagation in #guix.
*nckx waves.
<ft>So better hope you don't need versioned inputs in your propagated-inputs. :)
<nckx>Or that the user is happy to upgrade (say) ungoogled-chromium even though they just wanted to upgrade tinyfoobarcli, because both propagate the same thing.
<dstolfa>nckx: is 83 col ok in the trade-off of better docs? :)
<dstolfa>the StrongSwan's charon IKE keying daemon for IPsec VPN. thing pushes the line to 83col, namely the ")))" part
<nckx>It's okay, but you can also add a newline after ‘description’ if it bothers you.
<nckx>That'll move " under d.
<dstolfa>yep, that's better
<dstolfa>thanks
<ecbrown>hello nckx question about your experience running a substitute server. if you make it public does it completely and totally annihilate your bandwidth?
<ecbrown>and cbaines too
<ecbrown>i have one at https://guix.ericcbrown.com, if anyone wants to lightly test it :-)
***apteryx_ is now known as apteryx
<user___>How do I access the logs of a service?
<hrnz>"it depends"
<hrnz>but at least it wasn't written by pennart löttering
<roptat>user___, usually the service is supposed to send its logs to syslogd, so they end up in /var/log
<nckx>hrnz: Then it would actually log things well 😉
<nckx>ecbrown: Surprisingly, no.
*dstolfa feels dirty doing `guix pull --disable-authentication --allow-downgrades`
<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
<ecbrown>(or something)
<zhu_zihao>because shepherd is not systemd, it is not interest in the log sent to stdout/stderr
<ecbrown>i guess openjdk for that crew ;-)
<nckx>ecbrown: I didn't really advertise it much and set some worst-case rate limits in nginx, but I'd be very surprised if they were ever hit.
<leoprikler>can someone explain to me the hate towards lenny? is it really just "me no like systemd"?
<ecbrown>nckx: ok, thanks. i don't think i'll advertise beyond what i just posted. i will keep an eye on it
<user___>My vpn-client fails after a few seconds of being (re)started, I'm using a simple config
<ecbrown>maybe it will be useful to help someone doing something similar to seed
<user___>It should work: https://paste.debian.net/plain/1201079
<roptat>user___, in that case I would suggest running openvpn manually with the generated config, so you can see what it's telling you on stdout/stderr
<roptat>(you can find the generated config either by looking at the derivations guix told you it would build, or with something like "guix gc -R /run/current-system | grep vpn")
<nckx>☝ that's a pretty embarrassing state of affairs.
*nckx cheers that Linux 5.12 is finally available; consistently dereferences a NULL pointer minutes after booting; downgrades to 5.11.
<nckx>Ah, sweet: https://github.com/koverstreet/bcachefs/commit/78779c3db9907ab30eb6db0705d307910a7b332c
<dstolfa>nckx: huh. thta's not great
<dstolfa>:(
<raghavgururajan>Hello Guix!
<dstolfa>raghavgururajan: \o
<raghavgururajan>> brendyn‎: raghavgururajan, maybe ill impersonate you and package some things just to confuse you
<raghavgururajan>LoL.
<nckx>dstolfa: To be fair, for context, a photo of my kernel: https://www.tobias.gr/mahkern.jpeg
<nckx>Hi Raghav.
<raghavgururajan>leoprikler: lenny?
<user___>Hello
<nckx>raghavgururajan: The lead author of systemd, and probably not a discussion we want to start at length in this channel.
<ecbrown>i like shepherd, it has stop/start/restart. i like my logs in /var/log
<nckx>It doesn't afraid of anything.
<raghavgururajan>nckx: Ah pottering. Cool!
<dstolfa>nckx: hah!
<nckx>Except std{out,err}.
<nckx>And threads.
<dstolfa>how do i view doc changes locally?
<nckx>dstolfa: make doc/guix.info && info doc/guix.info
<user___>roptat: Running the opvn config works fine. I found the error, I miswrote login.conf. vpn-client now starts properly but I can't access the internet
<dstolfa>cool, thanks
<nckx>In environment if needed of course.
<roptat>user___, mh what does "ip r" look like?
<ecbrown>user___: do you have iptables and bridge and whatever else?
<ecbrown>masquerading/nat
<ixmpp>> leoprikler wrote:
<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
<ecbrown>(well said)
<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...)
<ixmpp>nckx: he asked, i answered.
<nckx>And now I'm asking.
<ixmpp>leoprikler: you heard the guy, shouldnt have asked...
<leoprikler>tbph I still don't get it
*nckx wonders whether #systemd hath movèd too.
<leoprikler>people push their views of what Linux shall look like literally all the time
*nckx …it hath.
<ecbrown>i'm trying to remember, was there a time before systemd, when one had to manually mount thumbdrives?
<ixmpp>I thought we werent meant to discuss this? Or was that just me.
*ecbrown mutters something and moves on
<gnarlf>When this system wasn't managed by enterprises
<nckx>ecbrown: You don't? What does?
<dstolfa>nckx: i think it's good to go. just pulling locally and doing one last reconfigure without functional changes
<nckx>Oh, is that udisks?
<dstolfa>i'll send another patch after this is pushed that updates strongswan (i'd like this to work first...)
<ecbrown>nckx: if i insert a usb into a gnome session, it will mount the drive. i seem to recall that this was not automatic at one time, or that hot-swap drives was difficult with init scripts
<nckx>Neat.
<ecbrown>i mean, i don't have systemd anywhere now and i can do that, but i think there was a time when one had to trigger it
*raghavgururajan asks folks to give udevil a try (https://guix.gnu.org/en/packages/udevil-0.4.4/), as a udisks replacement
<ecbrown>that was in the days when i didn't have the experience to know what sda, hda, etc. meant
<raghavgururajan>The gnome hot-swap things was gvfs
<raghavgururajan>*thingy
<ecbrown>ahh, ok
<ecbrown>i see its loaded in guix desktop template
<user___>roptat: Here's output of "ip r" without vpn, with manual openvpn, and with guix config: https://paste.debian.net/plain/1201082
<raghavgururajan>yep
<nckx>Can I use uwhatever without GNOME? I mean I'm fine with typing mount once a week (if that) but there's no argument for having to do so in future.
<nckx>And if so which one should I try?
<raghavgururajan>nckx: udisks and udevil are DE agnostic.
<raghavgururajan>nckx: udisks deals only with local stuff. But udevil also deals with remote stuff.
*nckx has no DE tho.
<nckx>udisks it is.
<raghavgururajan>They both work without DE.
<raghavgururajan>Cool!
<roptat>user___, this looks a but out of order, but not too bad
<roptat>user___, can you ping 192.168.32.1?
<leoprikler>nckx: you can probably monitor them via dbus as well
<raghavgururajan>Oh btw, udevil works without systemd, consolekit, policykit, dbus, udisks, gvfs & fuse.
<roptat>user___, and if so, what about 10.xxx.xxx.1?
<nckx>raghavgururajan: Durr… but I already have (udisks-service) in my system.scm. It's never mounted a thing in its life. Do I need to configure something? There's no such field…
<nckx>OK, fine, I shall dance with the devil.
<nckx>The devil does not have a service.
<nckx>This makes sense, since his goal is to cause pain and suffering, but it is not convenient for easy system configuration raghavgururajan. What to do?
<raghavgururajan>nckx: Don't feel pushed ;-), as you are SpaceFM user, I though you would also like udevil.
<raghavgururajan>Hahahha
<nckx>I've regressed to text mode file management lately.
<dstolfa>nckx: i think i did the right thing with the patch i just sent...
<nckx>I wonder what's next.
<dstolfa>hopefuly :)
<raghavgururajan>Just a sec.
<dstolfa>email-wise anyway, i had a weird situation in my email threads
<nckx>raghavgururajan: Is ‘consolekit, policykit, dbus, udisks, gvfs & fuse’ a dependency list of udisks? Because, well, no, thanks, sorry.
<nckx>GVFS sounds like a Thing.
<nckx>Rather not.
<nckx>dstolfa: Thanks!
<user___>roptat: I can ping 192.168.32.1 but not 10.xx
<dstolfa>nckx: could you ping me when it arrives? i don't want it to end up in limbo since i had a malformed mutt macro and it did a really weird thing prior to sending this email...
<nckx>Sure.
<nckx>(Nothing yet.)
<roptat>user___, can you ping [VPN address]?
<dstolfa>thanks
<user__>roptat: Yes
<roptat>then I think something's wrong on the server side
<roptat>basically, your packets are reaching your VPN server, but they're dropped at that point
<user__>roptat: I'd prefer to see the logs of vpn-client and compare them with manually running openvpn
<roptat>maybe you're missing a firewall rule to allow forwarding?
<user__>Manually running openvpn is fine, but when I run vpn-client that uses the guix config, all connections time out, so there's something that's missing in my config, but I don't know what it is
<raghavgururajan>nckx: So for udevil, [1] Add udevil to setuid-programs [2] Add udevil to packages (provides devmon) [3] Add devmon to shepherd user services (https://paste.debian.net/plain/1201088).
<nckx>Thank you!
<raghavgururajan>Np!
<nckx>dstolfa: I just got 3 moderation prompts for 3 mails from you at 17:20 exactly. So all is well, and there was obviously some batching and/or delay going on.
<nckx>Actually reading & responding will have to wait; dinner guests arrive.
<dstolfa>nckx: thanks! though, 3 emails? i sent two...
*dstolfa feels like something went wrong
<dstolfa>also, enjoy your dinner!
<dstolfa>nckx: ah damn it, the commit message is wrong, it still has use-ipsec? even though i stripped it out
<raghavgururajan>nckx: Woah, I just realised something. Neither udisks service nor udisks program doesn't auto-mount. You need udiskie as user-service to monitor and auto-mount.
<nckx>You're right, there were 2 identical ‘is pythonistic’ copies. I might look into it later or I might forget. o/
<user__>roptat: I found something strange in the /var/log/messages: Bad LZO decompression header byte: 42 -- This line does not show up when openvpn is run manually
<user__>I will disable comp-lzo?
<user__>roptat: It works now, I had to disable lzo compression: "(comp-lzo? #f)"
<ixmpp>> dstolfa wrote:
<ixmpp>> ixmpp: did you manage to solve your problem from earlier?
<ixmpp>> the shepherd one
<ixmpp>No
<ixmpp>Questioning if its possible now
<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>(I'm not very experienced in Guix though.)
<vldn>@ArneBab do you know how to configure guix to use my wisp script (or load it within a scm file) to do my system config within wisp? :)
<vldn>or is it possible to guix system reconfigure blabla.w? i think not :D
<ixmpp>But it should be possible
<ecbrown>avp: i think you need TeX / LaTeX binaries as well
<ecbrown>those would actually create the pdf file
<ecbrown>e.g. pdflatex
<bricewge>vldn: I would like to know it too.
<bricewge>It would be fun to configure a system with wisp instead of guile
<ixmpp>Probably can import (guix scripts whatever) from wisp and run it that way?
<ecbrown>flatwhatson: bricewge: thanks again! i have my channel up and going
<vldn>and someone got a working cgit service example in his config with nginx? hell lot of options
<vldn>a bit confusing to setup :D
<ixmpp>Wow wait, guix made elogind?
<ixmpp>Cool
<nckx>I think that was Gentoo.
<nckx>Or perhaps a dapper coalition of wayward distributions.
<dstolfa>nckx: the elogind docs mention "GuixSD"
<dstolfa>by name
<dstolfa> https://github.com/elogind/elogind see README
<dstolfa>Elogind has been developed for use in GuixSD, the OS distribution of GNU Guix...
<dstolfa>relevant blogpost https://guix.gnu.org/en/blog/2016/gnome-in-guixsd/
<dstolfa>FWIW i didn't know thir either, just looked it up now
<dstolfa>this*
<Noisytoot>How long would ungoogled-chromium take to compile on a ThinkPad X200 with 4GB of RAM?
<dstolfa>excessively long i would assume
<dstolfa>as in, clear your week long
<itd>Hi. I'd like to try the `guix import json` example [1], but it fails: https://paste.debian.net/plainh/cbba906a [1]: https://guix.gnu.org/en/manual/en/html_node/Invoking-guix-import.html#index-JSON_002c-import
<vldn>better use a substitute noisy xD
<Noisytoot>Are there substitutes available?
<Noisytoot>When I ran guix package -u (yesterday), it started building it from source
<vldn>mhh a few months ago there were some
<vldn>pitty
<itd>(This kinda works https://paste.debian.net/plainh/37f171e1 but I'd rather not compute the sha256 myself.)
<dstolfa>Noisytoot: there's a race condition between you running `guix pull && guix package -u` and the time it takes for CI to build the substitute
<dstolfa>try again today
<dstolfa>it should work
<itd>there's also `guix weather ungoogled-chromium`
<raghavgururajan>dstolfa: I am having some issues with the same golang package that we discussed before. Are you available ponder it?
<dstolfa>raghavgururajan: i might be losing my memory... i genuinely don't remember looking at a golang package, but happy to look anyway
<dstolfa>got a reboot scheduled here for an update... brb
<raghavgururajan>dstolfa: Oops, I meant to ping flatwhatson
<raghavgururajan>But yeah, any help is welcome. :)
<raghavgururajan> https://share.raghavgururajan.name/rg/hoL812XNnmPlP47t/bitmask-patches.tar.gz
<raghavgururajan>Packages bitmask-next-1 and bitmask-next-2 are the packages in discussion.
<lfam>My "solution" (workaround) for <https://bugs.gnu.org/48910> has broken CTRL+SHIFT+U input of Unicode characters on my Guix/Debian sytsem
<lfam>I guess I will dig through the Debian /etc/X11/Xsession to see what useful parts I can extract
<ArneBab>vldn: I do not think it will work without preprocessing: Just use wisp2lisp /etc/config.w > /etc/config.scm
<ArneBab>wisp2lisp /etc/config.w > /etc/config.scm && guix system reconfigure /etc/config.scm
<ixmpp>Also, discord doesnt work with elogind instead, cant remember who suggested that
<dstolfa>seems like the server is not coming back up, back via ERC :)
*dstolfa checks logs
<raghavgururajan>dstolfa: So I get this error (https://paste.debian.net/plain/1201111) while building bitmask-next-2 in this patch-set (https://share.raghavgururajan.name/rg/hoL812XNnmPlP47t/bitmask-patches.tar.gz).
<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>Can i build something without sandbox
<roptat>ixmpp, you can restart the daemon with --disable-chroot, but that's dangerous
<ixmpp>Cant be done per-build?
<roptat>no, the only way is to use a fixed-output derivation
<roptat>it doesn't even disable the chroot, but it allows network acces
<roptat>mh... there are some exceptions too, like the file-like objects, they're not fixed-output derivations, but they end up in the store, not sure how it fits in the model
<roptat>I guess they're similar to fixed-output derivations, but with no explicit hash...
<dstolfa>raghavgururajan: will check soon -- currently in the middle of dealing with refactoring 18k lines of kernel C code
<dstolfa>in pain
<raghavgururajan>dstolfa: Ouch! Carry on.
<nckx><discord doesnt work with elogind> This is a normal sentence that is perfectly fine. You can't expect your IM app to support just any old *checks notes* desktop seat management daemon.
<ixmpp>👍 not in a state to argue with you.
<ixmpp>Have a nice day
<nckx>…argue?
<nckx>dstolfa: <GuixSD> Oh, thanks. TBH I thought I remembered it from years before I'd ever heard of Guix.
<nckx>ixmpp: It was a slight at discord, not at you.
<raghavgururajan>nckx: Would you be able to have a look at the issue I mentioned above, regarding bitmask-next-2?
<nckx>ixmpp: So it digs into systemd internals?
<raghavgururajan>I tried make-file-writable, didn't work.
<nckx>raghavgururajan: My guess (and that's all it is) is that you're looking at the w bit when you should be considering the x bit.
*raghavgururajan is lost
<nckx>make-file-executable 😉 (which doesn't exist but you get my point.)
<raghavgururajan>Oh.
<raghavgururajan>nckx: (chmod foo #o555)?
<nckx>#o755
<ixmpp>> nckx wrote:
<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
<raghavgururajan>Is there an argument to do it recursively to files inside a folder?
***iyzsong- is now known as iyzsong
<raghavgururajan>nckx: Is this syntax correct? (for-each (chmod #o755) (find-files "." "\\.qm$"))
<raghavgururajan>nckx: I thik this (https://paste.debian.net/plain/1201118).
<sarg>how can I tell guix to not build anything during `guix package -u`?
<sarg>without resorting to `--do-not-upgrade` of course
<cbaines>what would you want Guix to do instead?
<sarg>only download and install available prebuilt packages
<lfam>It's not possible sarg
<cbaines>right, there isn't currently an option for "please upgrade everything but don't upgrade things where that would involve building something locally"
<lfam>Guix is a build-from-source distro
<cbaines>out of interest sarg, what don't you have a substitute for?
<lfam>It is frequently requested, so eventually somebody will use the tooling of `guix weather` in a way that achieves it
<sarg>cbaines: the packages that I've installed with transformation options and some packages from my channel
<cbaines>sarg, ah, ok, have you got your own source of substitutes for them then?
<raghavgururajan>nckx: Nvm! It worked. Thanks! I am getting diff error this time. https://paste.debian.net/plain/1201119
<sarg>cbaines: no, I built them time to time, but for a daily update I would prefer to not doing that
<sarg>s/built/build/
<nckx>Great!
*nckx is still entertaining.
<nckx>raghavgururajan: I honestly have no idea what that's about. $tool is being fed XML and doesn't want XML or wants different XML. It's not a generic error but something specific to $package/Qt.
<raghavgururajan>Cool!
<itd>What does `hg-reference-recursive?` in guix/hg-download.scm do? (Looks like the import runs fine without it.)
<drakonis>its for repositories that reference other repositories
<itd>Thanks! I'm (clueless and) confused that I cannot find it anywhere in guix.git but inside an #:export statement(?). Would have expected it to be defined/imported somewhere.
<lfam>Good point itd
<lfam>I wonder what is going on
<lfam>I'm guessing that it is a mistake
<jackhill>I know that emulated builds could be slow, but was surprised to see problems in grafting. This didn't happen with aarch64
<lfam>That export was added in c4e48b68bdf41e7f6805473fc4f545b215251c6d, when guix/hg-download.scm was created
<jackhill>has anyone else seen grafting get stuck when doing emulated armhf builds? It seems to be stuck like this for hours: https://paste.debian.net/1201040/
<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)
<itd>lfam, nckx: Okay, thanks. :)
<lfam>jackhill: Hm... is the hamlib store item very large?
<lfam>You might try strace-ing the guix-daemon, too
<lfam>`strace -f $PID-OF-GUIX-DAEMON`
<jackhill>lfam: nope, 15M on x86_64
<jackhill>good idea
<lfam>The output will be huge so make sure to redirect it
<lfam>`strace -f $PID 2>&1 | tee log`
<jackhill>I'm assuming the PID is the one returned by herd status guix-daemon?
<lfam>Not sure
<lfam>I usually find it in `ps auxf`
<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?
<dstolfa>wow, that's a lot of btws
*dstolfa needs to read his message better
<nckx>More or less, although my ‘document all the things!’ or whatever wasn't entirely serious.
<nckx>But it's fine.
<dstolfa>hah, i did try to come up with something more "serious-sounding", but "Document all the things!" was actually the most sensible thing there
<dstolfa>i gave up after 5 minutes of trying to think of better wording
<nckx>It's a very nckx commit message 👍
<nckx>Your patch is fine, if I'd have to think of something to say it'd be to use ‘git send-email -v2’ next time (assuming you use git send-email).
<jackhill>lfam: I attatched strace and ran the build again and … this time it worked!
<nckx>That will prefix the subject with [PATCH v2] making it slightly more clear what's what in a busy mailbox.
<jackhill>yay, I guess?
<dstolfa>nckx: ah alright, will do
<lfam>jackhill: Oh no :)
<lfam>Something is weird about the program execution
<lfam>Congratulations on your discovery of this heisenbug
<jackhill>hehehe
<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
<lfam>Using `guix time-machine` or inferiors
<ixmpp>lfam: Exactly, im trying to find a solution not fallible by guix gc
<lfam>Hopefully someone else has better advice :)
<lfam>I'm sure this is possible, but my own Guix usage is pretty simple
<ixmpp>And 2 days ago i did ask how to prevent gc of .drv files, nobody knows
<ixmpp>Im reasonably sure too
<lfam>How to preserve derivations against garbage collection? Which ones?
<lfam>Like, all of them? A particular one?
<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
<nckx>That is absolutely incomprehensible so here, an example: https://paste.debian.net/plainh/9802737a
<ixmpp>That seems out of scope for guix *and* nix
<lfam>I'm not sure what you mean by that ixmpp
<lfam>Does the guix-daemon option '----gc-keep-derivations=yes' not do what you need?
<dstolfa>nckx: right i see. shall i send in a reformatted version? :)
<ixmpp>.drv files become outputs. Outputs depend on other outputs, and dras depend on other drvs. I want an output to depend on a drv, so the drv is kept even if not built
<nckx>dstolfa: No thanks, just keep it in mind for the next patch.
<ixmpp>.drv files become outputs. Outputs depend on other outputs, and drvs depend on other drvs. I want an output to depend on a drv, so the drv is kept even if not built
<dstolfa>nckx: will do, thanks
<lfam>In what context would the derivation exist ixmpp? If it was not built? Are you manually creating it with `guix build foo -d`?
<ixmpp>lfam: I am creating it with package->derivation
<lfam>I'm just not sure I understand what you are trying to achieve. You are asking about some low-level implementation details but it's not clear what your goal is
<lfam>And, did you read about inferiors and `guix time-machine` yet?
<ixmpp>Its kinda surprising to me that every time i ask a question here, the assumption is that im attempting to solve something by command-line, despite guix using a language as powerful as scheme...
<lfam>Most people use Guix from the command-line
<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?
<ixmpp>yes
<nckx>dstolfa: Looks good, thanks! Since the cellar was, er, thoroughly ravaged tonight I'm staging the patch for tomorrow. Wine or pushing to master, not both.
<dstolfa>nckx: sounds good, thanks!
<ixmpp>So that leaves invoking guix with a script generated to inferior the original guix
<ixmpp>Which would also work but means again, no passing scheme values
<ixmpp>Well, no scheme values not exported
<lfam>I also recommend this blog post: https://guix.gnu.org/en/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/
<lfam>It's very high-level
<lfam>I'm not sure if it's too basic for you
<ixmpp>Kinda, unfortunately
<ixmpp>I appreciate the effort
<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 guix-devel@gnu.org
***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 <guix-devel@gnu.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
<lfam>s
<ixmpp>Im sure. I'll use that as a last resort :) too slow a communication medium for my nature
<nckx>Chat only seems fast.
***cap2 is now known as cap
***Kimapr2 is now known as Kimapr
***yjftsjthsd2 is now known as yjftsjthsd
***lukedashjr is now known as luke-jr
***sneek_ is now known as sneek
<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.
<nckx>→ a fork from some time ago
<nckx>bdax: The plan is to wait for someone to rewrite it in Guile. We've tried to trick a few people into doing so and will continue unabated.
<nckx>bdax: What are you doing next week?
<danderson>lol
<ft>:)
<jackhill>nckx: have we considered a gradual re-write? Add guile as an extension language for the daemon, and then move functionality over?
<jackhill>I, too, look forward to Guile daemon, but my project stack is too tall
<bdax>ha! not rewriting nix unfortunately, apparently some other fortunate soul has that task
<nckx>jackhill: I don't personally think that's a shorter road (quite the opposite) and haven't personally considered it seriously.
<nckx>Dunno about ‘we’ though!
<danderson>I wish I knew enough Guile to be able to take a swing at that. It appeals to the weird part of my brain.
<drakonis>danderson: a fork from the dawn of time, raelly.
<drakonis>really
<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)
<drakonis>tbf
<bdax>danderson: I doubt you learning guile will be the most time consuming part of that project
<drakonis>rewriting the deamon in guile opens many possibilities
<drakonis>it also allows ditching drv files and just use even more scheme
<danderson>bdax: it's definitely the part that probably makes me the wrong person for the job though. Nobody wants a guix-daemon that's "My First Guile Program"
<bdax>haha I suppose so
<drakonis>guile is fairly simple though
<danderson>(quite aside from the whole having to work for a living, which doesn't leave much time for fun things like this :( )
<jackhill>danderson: yeah, that's the real problem for many I bet
<bdax>pesky food
<danderson>drakonis: I have experience in other lisps. My experience there is that the language is simple, but good practices and "style" can only be acquired through bitter experience
<drakonis>i see
<nckx>The daemon is definitely the junk DNA of Guix. C++, that .drv syntax, things.
<danderson>just like my first Go programs were embarassingly awful, in retrospect. I'm now very good at making good Go programs, but there was no manual for that other than "spend 10 years writing Go"
<drakonis>things that rewriting the daemon would open up: a beefier guix deploy command
<drakonis>because you can forego things like ssh daemons and such
<danderson>and the last thing I wrote in lisp was... a long time ago. I was trying to make a binary-to-source transpiler for Genesis ROMs.
<drakonis>better build coordination and all that shit
<danderson>it was amazing, and then I discovered that java doesn't have unsigned ints, and ragequit
<bdax>I have found that if you like refactoring, starting a decent project in a new language can work well
<drakonis>but again, this is a lot of work that comes after rewriting
<drakonis>lots of fabulous things that can be done with that
<ix>> drakonis wrote:
<ix>> it also allows ditching drv files and just use even more scheme
<ix>this is goddamn essential. I was amazed it's still used
<ix>I was tempted to do that myself
<ix>Ripping out the parser and just using guile sexps instead, cant be too intrusive
<danderson>Sounds like it needs to start with a 1:1 port though. Mixing a rewrite with new features is a path to terrible things
<dstolfa>it is a good amount of work. it's not just the daemon to rewrite, it's all of the other functionality in C++ too
<drakonis>if you dont rip the bandaid all at once, you're going to break something
<ix>But i forsee a bunch of mailing list arguments culminating in a stale branch, so im not sure i wanna bother
<drakonis>the wip-guile-daemon branch is what you want
<drakonis>ix: ehhh
<danderson>At least though, guix doesn't need the Nix language, right? That's a giant piece of C++ that can be completely ignored
<dstolfa>the daemon itself is easy, but all of the libstore/libutil/etc stuff is quite a bit of work
<drakonis>it doesnt, no.
<drakonis>it just uses the internal format consumed by the daemon
<drakonis>as well as interacting with the store i think?
<ix>Yeah, so why not change that format
<danderson>Right. So, a 1:1 port of that, followed by new things... "how hard can it be"
<drakonis>i don't think there's a lot left in there, the fork was done in 2012
<ix>Obvious target
<drakonis> https://git.savannah.gnu.org/cgit/guix.git/tree/?h=guile-daemon start here
<danderson>ix: so, again, feels like the first port should be 1:1, not trying to do new things. Then it can evolve from there once the C++ is gone
<drakonis>the current approach is exactly that
<danderson>otherwise it's mixing trying to be compatible with existing stores, and adding new features. Those feel safer to serialize, IMO
<ix>danderson: obviously the entire thing is a mammoth task already failed by many, so hence i suggest starting from the most obvious issue and most useful port target
<drakonis>it hasnt been failed by many btw
<drakonis>its just that it progresses sporadically
<danderson>makes sense. I figure this has been a discussion that's happened many times before. I'm just new around here :)
<drakonis> https://git.savannah.gnu.org/cgit/guix.git/log/?h=guile-daemon&qt=author&q=Caleb+Ristvedt
<ix>Last commit over a year ago
<ix>"sporadically"
<ix>More like glacially, and unlikely to ever conclude
<drakonis>sporadically means that it happens once a year
<ix>Caleb himself had a tantrum worthy of me on the mailing list. Think that demonstrates how hard a task it is
<dstolfa>i think there are other parts of guix that can be improved first before nix-daemon needs rewriting. sure, it would be nice to rewrite it in guile, but it's not an urgent task
<ix>Hence, maybe dont attempt it all in one?
<dstolfa>and again, there is quite a bit of work
<danderson>so, how do these past attempts fail? Is it just running out of steam before the whole thing is ported, or some deeper issue?
<ix>danderson: first
<danderson>(I say "just", that's a legitimate problem, I'm curious what else happens)
<dstolfa>danderson: i mean you can look at the C++ code, it's just a bunch of stuff
<drakonis>what tantrum?
<ix>Mainly cause the c++ code is insanity
<dstolfa>none of it is too difficult, it's just that you need to focus and sit down for at least 6 months and go hack at it
<danderson>that's fine, I lost my mind in terrible C++ many years ago, how bad can it be
<dstolfa>the best way to accomplish things like this is to pay someone to do it
<danderson>+1
<ix>drakonis: https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00267.html
<drakonis>hmm how is this a tantrum?
<drakonis>its basically "this wasnt possible to do within the allotted period"
<danderson>it's an unhappy conclusion to a project, which highlights some of the pain points a future attempt will hit. I'm glad someone wrote that up :)
<drakonis>it didnt go as planned
<ix>Massive frustration expressed via text, extreme emotions in a place not otherwise normal to express? If i did that, i'd trivially call it a tantrum, and ive done far worse
<ix>danderson: true
<dstolfa>ix: maybe your so called tantrums aren't tantrums after all? :)