IRC channel logs


back to list of logs

<vagrantc>how and when is generated? it seems a bit out of date
<vagrantc>and ... is there what consumes to list packages in guix?
<vagrantc>no, seems to be consuming something ancient ... it's got diffoscope at 199 and updates are up to 220 with a couple releases per month
<cbaines>the packages page is part of the website, which is in guix-artwork I think, which is served by berlin
<vagrantc>seems like there was also a discussion on guix-devel in early june
<vagrantc>oh, it's due to *something* blocking russia
<cbaines>given that bayfront is or at least has been building the website, switching to serving it from bayfront might be a way to avoid these networking restrictions
<emacsomancer[m]>getting an error on "guix pull" - error: commit cea708413dd9d2d794b022f0f7bcfaba0bac97d7 not signed by an authorized key: A420 7B56 C255 109F 2CB3 157E 4990 97AE 5EA8 15D9 - is this a known issue?
<KarlJoad>Can I see what this sendmail file(?) looks like somewhere?
<FriendFX>Dear experts, I installed the `opencv` package a while ago (I think it came as a dependency of `python-imageio`) and it's kind of a pain because every time I do a `guix package -u`, `opencv` thinks it needs to be updated. This wouldn't be so bad if it didn't want to re-build itself including a lengthy 'check' phase. Looking through `guix package -l
<FriendFX>|grep opencv`, I see that the version has always been 4.5.4 for me, but the `/gnu/store/` prefix is different every time. Is this normal? Can I somehow tell Guix to only update if there's a substantial change/improvement of this package?
<apteryx>are trained models OK to be packaged? I guess these are more like nonfunctional data per the FSDG?
<podiki[m]>I would think so, basically it means their parameters have been set
<vagrantc>nonfuntional data?
<vagrantc>data that completely changes how the software behaves?
*vagrantc finds trained models to be very dubious from a free software rights perspective
<vagrantc>you can't reproduce it, you don't even know what went into it, and you can't change it
<vagrantc>FriendFX: if guix is rebuilding it, there is almost certainly a reason
<clever>vagrantc: i would just write a package that trains the model and have all of the data as inputs!
<vagrantc>FriendFX: you can choose not to update some packages, but sometimes that will result in other issues
<clever>problem solved :P
<vagrantc>clever: sure, it is *possible* to create a trained model that would comply, though my understanding is it would not be possible to build it reproducibly
<vagrantc>but i got the impression apteryx was talking about just using a pre-trained model
<clever>vagrantc: just make sure your training algo is also deterministic
<clever>only prng, no true rng
<vagrantc>yes, there are corner cases, but i get the impression that is... not the common case
<apteryx>to be concrete, I had on mind these:
<apteryx>is this in debian?
<FriendFX>vagrantc: I would hope there is a reason for it, but I get the horrible feeling that the package definition points to a master dev branch somewhere instead of a release branch, which would explain (a) why it wants to be rebuilt frequently and (b) why the version number doesn't change.
<apteryx>our tesseract package is useless without it
<vagrantc>apteryx: i do see a bunch of tesseract-ocr-* packages on debian
<FriendFX>vagrantc: Also, it is odd that the server never seems to have a pre-built substitute available, which makes me even more suspicious that what I'm getting something different from the rest of the world.
<vagrantc>apteryx: claims everything is apache-2.0 ...
<apteryx>yes, the trained models data is licensed Apache 2.0
<FriendFX[m]>atka: Sorry, just testing my mobile nick. Still green wrt IRC :-p
<clarity_>woah, guix runs on arm?
<efraim>and on a couple of other architectures :)
<clarity_>I'm tempted to buy an apple m1 now
<clarity_>eh, nvm, proprietary gpu...
<singpolyma>clarity_: not for much longer
***Xenguy_ is now known as Xenguy
<FriendFX>Does anyone else see the issues I'm having with the `opencv` package?
<acrow>So, is lcsync going to be committed in the near future?
<acrow>It looks to be a pretty cool tool.
<vagrantc>acrow: in futures past
<vagrantc>acrow: it's still very rough around the edges
<vagrantc>in the past's future?
<apteryx>singpolyma: how about the bootloader? apple things must be as locked as it gets
***devmsv_ is now known as devmsv
<apteryx>nckx: oh wow! no need for fancy fonts:
<apteryx>see #57151 if you'd like to play with it
***LispyLights is now known as Aurora_v_kosmose
<unciv>hi all :)
<unmatched-paren>unciv: Hello :)
<ekaitz>hi guix!
<unciv>hi :)
<unciv>can a new phase be installed for variant packages for pre-configuration ?
<ekaitz>unciv: what do you mean?
<unmatched-paren>unciv: do you mean something like:
<unciv>so, I have created a package, but I wonder if it would be possible to add an extra step to add config files and directories with preinstalled data.
<ekaitz>unciv: if I understood correctly it's perfectly possible
<unmatched-paren>(package (inherit old-pkg) (name "my-variant") (arguments (substitute-keyword-arguments (package-arguments old-pkg) ((#:phases old-phases) #~(modify-phases #$old-phases (add-before 'configure 'add-configuration (lambda _ ...)))))))
<unciv>nice :)
<ekaitz>unciv: where do you have that preinstalled data?
<unciv>so, at the moment we use docker-compose and we keep it in a repo
<unciv>but now I've taken the framework that we use which didn't have a guix package and I have created one in a new channel
<unciv>so the actual app works, but I want to add extra steps to create a config file, and add our custom modules from another repo
<unmatched-paren>where does the config file go?
<unciv>hmm, that's a good question, I actually just run the binary and point it to a config file in my home dir at the moment
<unmatched-paren>does it accept an env variable for the config file?
<unmatched-paren>or an option?
<unciv>no, at the moment there's only a share/doc directory
<ekaitz>unciv: the home dir is not writable from a package
<unmatched-paren>nothing is, except the package's outputs and /tmp
<unmatched-paren>and the build directory, but that's in /tmp
<ekaitz>unmatched-paren: sure
<unciv>ok, so if I created a new dir called config in the /share ?
<unmatched-paren>you'd have to point the binary to the directory you create in some way
<unmatched-paren>whether that's wrapping the program or patching the source
<unmatched-paren>or using a search-path
<unciv>so it should be easy to just make a new .sh that calls the binary with flags
<unmatched-paren>well, yes
<unmatched-paren>but it'd be nicer to patch the source directly
<unmatched-paren>then you wouldn't have to use something like a .real binary
<unmatched-paren>like we do with wrap-program
<unciv>hmm, that's an interesting idea
<unciv>the one I created does have a .-real as well
<unciv>odoo and .odoo-real - both from Jan 1 1970 :) (lol)
<unmatched-paren>Yeah, we reset dates to the Unix epoch for reproducibility :)
<unciv>the .odoo-real file is just the normal start script for odoo - the odoo file is a bunch of export GUIX PYTHON PATH
<unmatched-paren>ah, that makes sense
<unmatched-paren>i think we have to wrap python scripts so they can find libraries
<unmatched-paren>because python doesn't provide a search-path variable by default
<unmatched-paren>so we patch it to accept GUIX_PYTHON_PATH
<unciv>I'm just amazed that it works, because I have no idea how it worked
<unciv>but if I can get it working automatically with all the configs, it would be cool to generate a new .scm every time when we merge
<nckx>apteryx: What a difference! Thanks for testing it out. Pity we have to choose between worse OCR and hundreds of megabytes of very dubious ‘data’ :-/
<cizra>Hi, are other bootloaders than GRUB supported in Guix? Or am I on my own, if I do that?
<cizra>Ah, I found
<pkill9>cvreated first iteration of guix wrapper \o/
<pkill9>plsu it means you can make other small changes like deleting .desktop files you don't use without rebuilding the entire package
<unmatched-paren>sektor[m]: Hello
<devmsv>hello, I have my own running guix system. I want to install another system onto a USB stick so I can have a guis system on the go. I can't run ~herd start cow-store /mnt~ (it can't find the service) any tips on how to proceed?
<unmatched-paren>devmsv: That is very odd. Are you on 1.3?
<unmatched-paren>As in, does the USB stick contain Guix System 1.3.0?
<devmsv>Maybe I haven't explain my self. I have my own gyix system on my laptop I want to isntall another guix system directly on the USB without another USB withguix installation USB iso (I don't have two USB sticks)
<unmatched-paren>So you're using your laptop to install a full-fledged live Guix onto a USB?
<devmsv>unmatched-paren: yes!
<unmatched-paren>I think you might want `sudo guix system image` for something like that, though it better be a large USB.
<unmatched-paren>Guix takes up a lot of storage space, are you sure you can fit that in a USB?
<devmsv>Its a 128GB USB, at least I want to try
<unmatched-paren>Yeah, that'll be large enough :P
<nckx>cow-store is a service specific to the installer image. It is not part of every normal Guix System.
<nckx>cow-store redirects writes to /gnu/store, that would be writes to a very limited RAM drive (tmpfs) when installing from the installer USB/ISO, to the target partition /mnt.
<nckx>It is not needed if you're noot booted from RAM.
<nckx>Noot noot.
<nckx>So: simply skip that step, devmsv; it is not related to the success of the installation.
<nckx>devmsv: Another point of note is to use the ‘grub-efi-removable-bootloader’ boot loader.
<devmsv>unmatched-paren: nckx: Thanks. I'm doing ~dd if=$(guix time-machine -C channels.scm -- system image config.scm) of=/dev/sdb~
<nckx>I'd have gone with ‘guix system init’, but good luck!
*nckx flies away.
<unmatched-paren>Huh, yeah, guix system init *would* be a better way...
*unmatched-paren feels dumb
<devmsv>well I have cancel the other process and found it now with system init
<abrenon>hi guix
<devmsv>for some reason grub is not correctly installed.
<devmsv>this is the bootloader de claration:
<efraim>lilyp: your gobject-introspection patch on core-updates seems incomplete
<abcdw> /part
<sneek>abcdw, you have 1 message!
<sneek>abcdw, nckx says: — but perhaps we should coordinate a time where a Savannah admin's on duty before we try again, if feasible, just in case.
<some-one>Hello everyone. Is where any intentions to complete the idea of `guix git log`? How do you find the old versions of packages that are no longer in the upstream? Via git blame? Why we don't keep old version of packages in the guix channel? Is it really hard to support?
<pkill9>because it's extra work for little payoff I guess, especially now you can build packages using an old version of guix
<unmatched-paren>some-one: "... old versions of packages ..." <- Yes, keeping everything would be impossible. Also, security problems.
<unmatched-paren>And you can just use `guix time-machine` to get old packages.
<unmatched-paren>`guix time-machine -- package -m my-ancient-manifest.scm
<abrenon>how does guix capture the value of packages' fields to make them available to define other fields ?
<abrenon>why can I apparently reuse version transparently to define commit in a git-reference, but not home-page in the url ?
<abrenon>don't tell me it's about lines order…
<abrenon>ok, lines order seem to be the explanation… -_-'
<abrenon>then why isn't home-page usually found above the origin ? are there so few packages which have do not have another home page but the one of their repos ?
<unmatched-paren>abrenon: "-.o.-" and "no" :)
<abrenon>I must find examples to see how they handle it
<abrenon>I can't believe they all duplicate the url
<abrenon>maybe a let variable right before the package declaration itself ?
<tschilptschilp23>Hi guix!
<abrenon>hi tschilptschilp23
<nckx>unmatched-paren: Not dumb. There are probably more people who mistakenly use ‘init’ when they'd be better off with ‘image’ than vice versa. This is a rare exception.
<abrenon>ok, that's the approach taken by casync
<abrenon>so I guess if it's good enough for it it's good enough for my package
<unmatched-paren>maybe we should modify (guix records) to allow referencing later fields
<abrenon>would there be a way ?
<unmatched-paren>not sure how you'd do that though, other than literally traversing the literals to resolve dependencies
<abrenon>I thought it was already the case when I saw "version" being reused like that
<abrenon>I thought it was one of the cool features of "yeah, it's declarative, it's a fixed point or something"
<abrenon>actually, I think I'd prefer no capture of properties at all (having to declare everything in a let in order to be able to share it later) than this stateful weirdness
<unmatched-paren>that would make reuse of `name` and `version` extremely annoying
<unmatched-paren>but i suppose reuse of home-page is already that annoying :)
<abrenon>yes, which is why I'd prefer having the whole thing stateless and being able to refer to any field from any other, but the overall behaviour would be less surprising and look less "dirty"
<nckx>That's why it's the way it is now.
<abrenon>to look dirty ?
<abrenon>(hi nckx)
<abrenon>(oh, right, you can't hear me if I write like this)
<nckx>Being able to use future fields would be surprising and dirty. Exactly like (foo "hello") (…lotsa code…) (define (foo …))
<nckx>I thought that was your point.
<abrenon>ohhh, no, quite the opposite in fact
*tschilptschilp23 wonders which package in my home-config pulls in half kde on a gnome-system
*nckx hears strange whispers without origin.
<abrenon>I'd prefer being able to refer to any field from any other because I feel that in a declarative system, no field should be understood as "future" to any other
<nckx>Hi to everyone!
<abrenon>which is why we're giving names to them
<apteryx>is anyone having "guix substitute: error: connect*: Connection timed out" with berlin today?
<nckx>Sure, I guess this-package-input etc. already do so.
<tschilptschilp23>Hi nckx!
<abrenon>(point (x 7) (y 2)) should in my opinion refer to the same point as (point (y 2) (x 7))
<nckx>At least conceptually.
<abrenon>if not, then I'd rather have it (point 7 2), no name, then I know that only position can be meaningful
<abrenon>here, I thought I was using a beautiful functional programming abstraction, when I'm in fact executing imperative statements of a language less readable than C
<nckx>That's not really what's going on here though. (package (name …) (version …)) is the same as (package (version …) (name …)).
<abrenon>(set-version "something")
<nckx>You're confusing two things.
<abrenon>(set-home-page "otherthing")
*unmatched-paren not really sure about "less readable than C" but okay :)
*nckx thought this was serious; flies away again.
<abrenon>yes, less readable, because the attributes names don't convey the information that they are indeed performing a side effect
<abrenon>it is serious, I'm honestly disappointed to find such a bug in guix
<abrenon>but I can understand that few people are ready to see this as a bug
<unmatched-paren>tbh, it would be nice if guile's records could be fleshed out such that we could just kill off (guix records)
<unmatched-paren>i think implementing guix-style records in guile might make declarative-style easier to implement, possibly?
<abrenon>because you're right, I'm mistaking two things, and the fact that I've been able to mistake them up to now is a proof that until now I've been lucky enough to handle well-designed, unsurprising languages which are simpler and don't require to make an unneeded distinction between them
<nckx>Because it's not a bug, you just wish it were so you wouldn't have to argue why your suggestion is better (which you've so far failed to do with the misleading (point…) example).
<abrenon>absolutely : )
*unmatched-paren tries something...
<nckx>And I'm not going to join in if it's about winning at any cost. Sorry.
***daviid`` is now known as daviid
<abrenon>winning at any cost ?
<Lumine>I tried something today too, and failed. But I learned!
<unmatched-paren>it is a little unintuitive
<abrenon>I'm not trying to win anything, I'm perfectly fine with the fact that people can see it as the best design choice
<unmatched-paren>like several other problems with guix: annoying, but very difficult to elegantly fix
<abrenon>is it a guix thing ? isn't that how records work in guile in general ?
<unmatched-paren>(guix records) the module
<unmatched-paren>it implements (define-record-type*)
<unmatched-paren>guile has srfi-9 but its records aren't fleshed out enough
<nckx>abrenon: OK, fair. ‘Surprised to find such a bug in guix’ is pretty loaded language to me, is all.
<abrenon>that's the second time you've used this expression, what do you mean "fleshed out" ?
<nckx>Playful winks over text are dangerous at the best of times.
<abrenon>ohh, I'm sorry it was so aggressive
<abrenon>especially since, as I've written above I thought it was a guile thing and not a guix thing
<unmatched-paren>abrenon: something is considered "fleshed out" if it supports a wide range of useful features
<abrenon>oooh I see, thanks
<abrenon>nckx: amazing ?!
<unmatched-paren>Anyway, the guile records are constructed like so: (package "hello" "1.2.3" (origin ...) build-system ...)
<nckx>Me? True.
<unmatched-paren>note the lack of field tags :P
<abrenon>: )
<unmatched-paren>so, quite ugly
<unmatched-paren>and they don't support things like (thunked)
<unmatched-paren>which are used all over guix
<unmatched-paren>so guix defines its own kind of records
<unmatched-paren>which support many more features, and have sane constructor syntax
<abrenon>I guess I was just live-IRCing my disappointment at getting slightly less ignorant about how scheme languages can work and having to understand how deeply they differed from the other functional programming languages I'm more used to
<unmatched-paren>Scheme is a victim of its simplicity :)
<abrenon>it would appear so
<unmatched-paren>hmm, wait
<unmatched-paren>it looks like srfi-9 records don't support self-reference at all :P
<abrenon>I was wary from the start for the lack of types, but it's even closer to Javascript than I originally thought ; )
<unmatched-paren>yes, lack of types is annoying
<abrenon>unmatched-paren: ah, that's better, now that's pure and unsurprising : )
<unmatched-paren>...but they're still ugly :P
<unmatched-paren>also for some reason you have to declare fields twice
<abrenon>of course they are
<abrenon>twice ?
<abrenon>now, surely that's a bug
<unmatched-paren>(define-record-type <foo> (make-foo bars bazzes quuxen) foo? (bars foo-bars) (bazzes foo-buzzes) (quuxen foo-quuxen))
<nckx>abrenon: I can actually sympathise. There were a lot of dreamy (and almost certainly internally inconsistent) ideas I had about Lisps when I switched to Guix. Like everything would somehow magically know everything it would need to and somehow do the right thing and… This was coming from Nix, where attrsets do have that property sometimes, but unpredictably and poorly. Still took me a while to adjust to the reality, even though it didn't end up disappointin
<nckx>g me at all.
<unmatched-paren>note the constructor definition
<nckx>It's not a bug, just a wart.
<nckx>I guess the difference is it's part of you and you still love it and feed it and oh god ew ew ew.
<unmatched-paren>"You fed it" too literally.
<nckx>I'm so sorry.
<unmatched-paren>where did that finger go? O_o
<apteryx>nckx: on berlin, the sshd process doesn't start on login (it's delayed too). points to a inet/pam problem, perhaps?
<unmatched-paren>abrenon: the equivalent guix record would be
<abrenon>I'm glad you can sympathize, and I like where you draw the line between bug and wart
<unmatched-paren>(define-record-type* <foo> foo make-foo foo? (bars foo-name) (bazzes foo-bazzes) (quuxen foo-quuxen))
<nckx>apteryx: Everything kind of points to that, no? I'm not really sure where to look, though. TBQH, I tend to opt out of debugging networking/IPC stuff when I can get away with it…
<unmatched-paren>but the guix records support many additional attributes in the field declarations
<nckx>I'm also just not good at it.
<unmatched-paren>(quuxen foo-quuxen (thunked)) for example, thunks the quuxen field
<unmatched-paren>and you can define "sanitizers" that are applied to the field's value
<Lumine>nckx: did you figure out the missing bind package in emacs?
<unmatched-paren>which modify it
<nckx>Lumine: It's not even ‘missing’, it's right there, bundled with use-package by the way.
<unmatched-paren>they're used to turn new-style inputs into old-style AIRI
<Lumine>So somehow use-package is not acknowledging it?
<unmatched-paren>also, guile records don't support inheritance
<unmatched-paren>which would be pretty problematic for guix :)
<nckx>PSA, and why I was briefly here in the first place: if you run Tor, you should stop it, run ‘guix pull’ instead, update Tor and make sure you're running Even if you updated Tor yesterday.
<unmatched-paren>they're far too bare-bones for our use cases, basically
<nckx>Byee o/
*unmatched-paren guesses and looks up 'tor cve'
<unmatched-paren>...or i could just look at
<Lumine>I'm drinking coffee and pretending I understand Guix
<abrenon>apteryx: so a login must be performed physically on the machine before sshd starts ?
<unmatched-paren>Lumine: what are you struggling to understand? :D
<abrenon>unmatched-paren: thanks for the explanations about records
<unmatched-paren>abrenon: no problem!
<abrenon>though I still have to look thunks up
<abrenon>redex ?
<apteryx>abrenon: sorry, I wasn't clear. There's a problem on berlin currently that delays SSH login by about 30s.
<unmatched-paren>thunking something = wrapping the thing in a lambda to stop its evaluation
<unmatched-paren>to thunk (display "foo"): (lambda () (display "foo"))
<abrenon>ohhh, but sshd is already up
<Lumine>unmatched-paren: I basically hopped unto Guix wagon when I was still learning Linux, and I also happen to be very slow in learning :D
<Lumine>So I'm just slowly taking everything in
<unmatched-paren>Lumine: Well then, you won't have to unlearn things about traditional distros :P
<apteryx>abrenon: sshd is now using an inetd style service, which fires it on demand
<nckx>apteryx: Actually, no, another hypothesis that occurred to me y'day was that sshd was looking up PTRs for new connections and they were somehow being blocked on the MDC network (even though that would make no sense) and timing out. So sshd not starting does rule that out. Thanks.
<Lumine>You could say that I'm a regular user that wants to learn Lisp but is having problems with basic concepts
<unmatched-paren>abrenon: There's also r6rs records, which are a bit better:
<unmatched-paren>Lumine: Which ones? Many of them look complex and mind-bending but are really simple once you get into them.
<Lumine>Elisp and CL after that
<nckx>Lumine: <I'm drinking coffee and pretending> That is most of us here though, we just have various levels of pretending.
*nckx really flies away now.
<unmatched-paren>Except for call/cc, which *is* mind-bending.
<Lumine>See ya!
<unmatched-paren>The only person who actually 100% understands guix is ludo, probably :)
<abrenon>ok, so port 22 open, but daemon off, and spawned when packets arrive
<Lumine>But I did learn how to change default shell today in Guix to something other than bash, just haven't figured out how to manage and make it co-exist with bash inside guix home yet
<apteryx>abrenon: yes, excepts there's some unexplained 30 s delay between both (connection established to port 22... time passes... sshd launched)
<abrenon>30s sound like a timeout
<abrenon>has anyone already logged in been able to strace the process spawning sshd ?
<abrenon>couldn't it be some sort of reverse DNS misconfiguration or something ?
<abrenon>it sounds like a symptom I once had in a VM, but that was an ugly systemd mess IIRC
<pkill9>some people seem to think guix is some kind of virus, seeking to take over the world, but that's wrong, guix is just a tool... a tool for guile to take over the world
<rekado>pkill9: The Selfish Guile
<abrenon>pkill9: ^^
<rekado>etc/committer.scm has some code to edit S-expressions, whereas the updaters use text-based editing.
<rekado>perhaps we should move some of that editing code from etc/committer.scm
<rekado>and then there’s the stuff used by “guix style”
<tschilptschilp23>Does anyone know what the 'checkout' in ~PACKAGE-VERSION-checkout~ tells?
<unmatched-paren>tschilptschilp23: that the output path you're looking at is a source checkout, not a package output
<tschilptschilp23>unmatched-paren: thanks! I obviously once more forgot about guix-weather ;)
<lilyp>efraim: how so?
<efraim>lilyp: it doesn't actually update the pacakge to 1.72.0, just adjusts the patch
<lilyp>oh... someone else already updated it and I didn't notice
<lilyp>sorry for the noise
<apteryx>abrenon: the process spawing it is PID 1 (shepherd); I tried stracing there but it's noisy
<abrenon>of course… : (
<abrenon>so it's not a pam module directly spawning it ?
<abrenon>does it somehow message shepherd ?
<abrenon>no I'm still confused about this, how can PAM be called before sshd ?
<apteryx>it uses a near-vanilla openssh-service-type from (gnu services ssh)
<apteryx>and has a new enough Shepherd version to leverage the make-inetd-constructor
<abrenon>oh, so inetd is the one asking shepherd to spawn sshd
<apteryx>I think the way it's implemented by Shepherd, shepherd does what initd would normally do
<apteryx>it listens to the port itself and spawns itself
<apteryx>there's no running inetd process
<abrenon>oh, ok
<apteryx>so it could be a bug in Shepherd
<abrenon>well seen from the outside, yes, it would appear so
<apteryx>the constructor used is this:
<apteryx>it listens for any interface on both IPv4 and IPv6
<apteryx>shepherd immediately accepts the connection and writes "Service sshd-5188 has been started."
<apteryx>and then it hangs for 30 s
<apteryx>(with no actual sshd process spawned)
<apteryx>hmm: 12.9g 12.3g 100.0 6.5 1:12.88 R shepherd
<Not_Leader> is this free software?
<Not_Leader>wondering so i know if it should go in the main guix channel
<nckx>Not_Leader: I see no reason why it wouldn't be, barring hidden blobs in one of the many source files (which I didn't audit). Have you already packaged it?
<Not_Leader>nckx nope but i like doing things out of order
<Not_Leader>anyway thanke
<nckx>Well, I asked because it's .NET, which can't be the best mode of Guix packaging fun. We do have mono. We have mono from 2016. Go mono.
<nckx>I don't know if mono is even close to being all you need to package .NET.
<apteryx>oh, the 13 GiB process is mumi
<alethkit>Would it be a weird idea to mix Guile and Dhall together? Having guaranteed termination does sound very appealing.
<unmatched-paren>alethkit: How on earth would that work?
<unmatched-paren>(Also: on first sight, Dhall is (1) not extensible, (2) extremely complex, and (3) has yucky Haskell-like significant whitespace, all three of which aren't anything like Guile :)
<unmatched-paren>s/aren't/mean it isn't/
<apteryx>nckx: and it's built from binaries. perhaps we should drop it
<apteryx>yes, there's a bug about it
<unmatched-paren>nckx: Yes, you need C# to build the mcs compiler
<unmatched-paren>but the VM is written in C
<nckx>No objections from me.
<unmatched-paren>theoretically, you could use dotgnu to build msc
<unmatched-paren>although there's probably some complication somewhere :)
<unmatched-paren>There always is.
<nckx>Right. There's usually a theoretical path forward, but…
<nckx>janneke: Any comments on ?
<nckx>At your leisure, of course.
<apteryx>the issue didn't come up during review:
<nckx>Anyway, big ups from me on dropping it as it is now. We pretend not to notice binaries when they are critical to the graph. Mono never has been that. Although it's not the leaf I expected it to be, either, seems like we'd lose a handful of mostly IM & gaming-related packages. Nothing major though.
<apteryx>seems it can be worked out via some manual hacks (Debian apparently does so)
<apteryx>kind of yuck:
<apteryx>Any other opinion about including trained data models from tesseract? It's licensed Apache 2.0.
<nckx>I don't get this 6.x/4.x discrepancy, but can't rule out that the description isn't simply wrong:
<nckx>Random .*mono.* dependencies of that are anywhere from 4.x/5.x/6.x.
<nckx>Ah, 4.0 is the ‘CLI [run time] version’.
<apteryx>oh, is mumi down?
<apteryx> doesn't work for me
<apteryx>wouldn't surprise me after reaching 13 GiB
<nckx>One would expect a 50x, not a connexion error if that were the case.
<nckx>And indeed, won't load either.
<davidl>nckx: hi, any status update reg. bash-bcu?
<nckx>apteryx: Are you SSH'd in, at least?
<nckx>davidl: Not right now.
<nckx>apteryx: I'm getting ‘no route to host’ errors.
<apteryx>I can't anymore, got kicked out
<ggoes>yeah i just checked the channel because i'm getting the same error
<podiki[m]>sites were slow in last several minutes, just noticed it went down
<davidl>unmatched-paren: thx for your help with packaging tern (node package): I got a bit further - now Im stuck again :-( node-deno fails in the install phase with: "npm ERR! enoent ENOENT: no such file or directory, chmod '/gnu/store/0nkx2qm0b1k9lbhfajn4jd48nlxk8593-node-deno-0.1.1/lib/node_modules/deno/try-deno'". There's a bin file mentioned in package.json but Idk how to make it appear basically,
<nckx>I'm at the serial console but can't get a prompt.
<apteryx>shepherd is probably busted
<nckx>apteryx: OK to hard-reset?
<unmatched-paren>davidl: Looks like it wants you to have installed try-deno so that it can... uh, perform the installation phase...
<unmatched-paren>very strange
<apteryx>nckx: OK!
<nckx>Is this a Node parody package?
<nckx>apteryx: Roger.
<unmatched-paren>nckx: Poe's Law too often applies with Node packages.
<davidl>unmatched-paren: hmm. Here's the latest tern.scm:
<nckx>Server power operation initiated successfully.
<unmatched-paren>davidl: I don't understand where that try-deno binary is from.
<nckx>davidl: I've been kind of disappointed by the lack of feedback I got from the folks I pinged (I understand it's a weird package and we might be trying too hard to get things just right, but still).
<nckx>I think I'll just finish up ‘our’ version and push. I'm in that kind of mood.
<davidl>unmatched-paren: me neither, but it's mentioned in package.json, and if it's not significant, maybe I can just substitute* it away. However, i don't know if it's significant or not :/
*unmatched-paren looks at npm docs for package.json's "bin"
<dirtcastle>I'm trying to hack on guix home. but andrew tropin's repo is not geiser compatible - meaning geiser -edit-symbol-at-point doesn't work because of the way the directories are structured. I'm emacs , lisp, scheme and guix noob btw and trying to learn thank you very much.
<davidl>nckx: ok, thanks for letting me know what's going on.
<unmatched-paren>dirtcastle: are you trying to hack on rde?
<unmatched-paren>the rde guix home?
<dirtcastle>yeah and gnu directory if possible
<unmatched-paren>because it's been merged into main guix
<apteryx>nckx: fyi I sent an email to guix-devel + mono issue about my proposal to remove the packgae
<apteryx>in 2 weeks time
<unmatched-paren>you don't need to touch the rde repo to modify guix home :)
<unmatched-paren>davidl: Looks like that "bin" form is wrong, anyway...
<unmatched-paren>it's supposed to be
<nckx>apteryx: Boot failed: Guix
<nckx>Of course.
<unmatched-paren>"bin": { COMMAND-NAME: SCRIPT-FILE-PATH }
<unmatched-paren>but this looks like "bin": { INSTALL-SCRIPT: COMMAND-NAME }?
<dirtcastle>I am interested in implementing features. unmatched-paren
<apteryx>nckx: neat. so you boot in pxe boot image and copy things by hand?
<unmatched-paren>dirtcastle: What features do you want to add?
<nckx>apteryx: Basically. I'm booting Ubuntu as we speak.
<dirtcastle>like way to configure application through guile uk
<apteryx>nckx: so I guess it was reconfigured :-/
<unmatched-paren>dirtcastle: oh, you want to add support for a new application configuration?
<unmatched-paren>okay, that's fairly easy
<davidl>unmatched-paren: offending commit:
<unmatched-paren>what you'll want to look at is gnu/home/services/*.scm in the guix repo
<unmatched-paren>that contains things like shells.scm
<unmatched-paren>which will show you how to construct a dotfiles service with configuration
<apteryx>nckx: would you mind keeping the commands used to send to guix-sysadmins in case someone else need to do it next time?
<davidl>unmatched-paren: do you think itremove it then
<nckx>Sure, if I can remember them.
<unmatched-paren>davidl: Try it and see!(TM)
<davidl>'s safe to remove* it
<dirtcastle>do I have to clone the repo or does it come with guix
<unmatched-paren>dirtcastle: git clone
<dirtcastle>got it.
<unmatched-paren>then have a look at the contributing guidelines
<unmatched-paren>oh, right, the contributing guidelines are down
<unmatched-paren>s/contributing guidelines/websites/
<unmatched-paren>dirtcastle: you'll have to look at `info "(guix)Contributing"`
<unmatched-paren>there's a commit message format that you need to adhere to
<unmatched-paren>and you need to send your patches with git send-email: <>
<devmsv>nckx: I know you are fixing berlin server. the web is down worldwide or just in Europe (I can't access right now)
<unmatched-paren>make sure to read the contribution guidelines *thoroughly* to minimize pain :)
<nckx>devmsv: World-wide baby.
<ggoes>guix ghost, coast to coast
<unmatched-paren>i don't think it's possible for a single server to be up in one region but not in another.
<unmatched-paren>of course, if the server is actually a distributed network...
<nckx>None of that fancy big-city nonsense for us peasants.
<unmatched-paren>dirtcastle: There is one particular pain point to take note of:
<nckx>apteryx: There are no missing files on the boot drive. I need to think, and I won't be liveblogging here whilst I try stuff. TTYL.
<unmatched-paren>If you have multiple patches, you'll need to send one email to <>, then wait for the debbugs (bot|daemon|mailer) to respond with the issue number
<unmatched-paren>and then send the rest of the patches to <>
<unmatched-paren>if you send them all to <>, you'll create an issue for each one
<unmatched-paren>a good way to do it is to use `git format-patch --cover-letter`, and send that as the first mail
<apteryx>nckx: OK :-/
<unmatched-paren>which provides a summary of the patchset and allows you to write an introduction
<unmatched-paren>and then you can send the actual patches :)
<unmatched-paren>also, there's apparently a better way to use `git send-email` than that recommended by instead of HEAD^~<number>, use -<number>
<unmatched-paren>to send the last <number> patches
<nckx>apteryx: Have you ever successfully pressed the virtual F11 to enter the ‘Boot Manager’? It doesn't do anything. I can enter the firmware setup with another Fn key (I forget which, but that one).
<nckx>This 👏 is 👏 the 👏 GNU 👏 system 👏 welcome
<dirtcastle>I have rudimentary knowledge of git, programming, guile. but I noted Everything you said. and the future (hopefully) Knowledgeable me will definitely look into everything you said , after coming up with something useful enough to make a pull request and get it merged.
<unmatched-paren>dirtcastle: s/pull request/patchset/ :)
<nckx>Web sites should be back up.
<dirtcastle>ahhh seee . TIL
<unmatched-paren>Git does have a notion of sending "pull requests" over email, but that seems to be an advanced feature that isn't often used.
<unmatched-paren>`git request-pull` allows you to send an email that literally requests that the maintainer pull some commits from your repo into theirs.
<nckx>Linux uses it, it's ‘advanced’ in that it happens between subsystem maintainers, not randos like on GitHub.
<dirtcastle>everybody uses GitHub web client.
<unmatched-paren>But that requires you to have published your repo.
<unmatched-paren>(request-pull does.)
<nckx>dirtcastle: Not really.
<unmatched-paren>there is the `hub` CLI
<unmatched-paren>but it requires some authentication token, i think
<unmatched-paren>so it's not an escape from the GitHub JS :(
<nckx>apteryx: I think it's a timing issue.
<nckx>At boot.
<unmatched-paren>dirtcastle: The `send-email` and `format-patch` "patchset" features allow you to send some emails containing .patch files in the universal format, which the maintainer can then apply with `git am` or `git apply`.
<dirtcastle>nckx: most ppl I know irl do. emacs YouTubers introduced me to sourcehut. i didn't know u can do it through email until then
<dirtcastle>what does am stand for. my guess is apply modification
<nckx>Apply mail.
<dirtcastle>ah okok
<unmatched-paren>funny/terrifying how github successfully became the only way to use git that many people know
<nckx>dirtcastle: ‘Most people’, numerically, sure. Big difference.
<unmatched-paren>dirtcastle: It allows you to take a `.mbox` (mailbox) file full of emails containing patchsets and apply it to a repo.
<nckx>dirtcastle: You seem to assume all projects use GitHub.
<dirtcastle>no no no
<unmatched-paren>dirtcastle: I would advise you read about Git's more advanced features, it's actually a really cool and elegant system once you get to know it
<nckx>Lots of huge projects (and many more small ones) don't. That's why git is designed for e-mail in the first place, because it's mainly used over e-mail.
<unmatched-paren> <- read through this :)
<dirtcastle>unmatched-paren: I was committed to reading through git manual fully. my friends told me it's not worth the time.
<unmatched-paren>The manual, maybe not. But your friends are mistaken if they think getting to know git properly isn't worth the time.
<unmatched-paren>s/The manual/The *entire* manual/
*nckx → work, ping me if needed.
<unmatched-paren>git is full of neatness like <>
<unmatched-paren>a lot of people don't seem to know `git rebase` even exists!
<nckx>dirtcastle: Keep in mind that your friends might not know what they are talking about.
<unmatched-paren>Yet! :D
<dirtcastle>nckx: I thought github and gitlab are most used.TIL I know gnu uses Savannah.
<unmatched-paren> and are growing fast
<unmatched-paren>i think the software freedom conservacy is actually urging people to get rid of github now (because of copilot)
<dirtcastle>nckx: true!
<unmatched-paren>and gitlab isn't ideal either
<unmatched-paren>because it uses google cloud stuff (so there's tracking) on the site, and uses the proprietary version of gitlab (called "GitLab EE")
<apteryx>gitlab won't even let you sign it without the right user-agent, yay
<nckx>dirtcastle: Oh, I'm sure ‘most used’ is true, I'm sure! Doesn't mean other things are automatically true because of it.
<unmatched-paren>obviously, *if you can afford it*, self-hosting something like cgit is probably best :)
<nckx>I haven't been able to sign into for years.
<nckx>So they seem to be doing great 👍
<dirtcastle>I like selfhosting. but I don't have the skills. guix is the best tool a sysadmin can have.
<nckx>apteryx: Are you SSH'd in?
<nckx>Just saw a ‘ocalhost sshd[6785]: error: kex_exchange_identification: Connection closed by remote host’ and want to make sure.
<unmatched-paren>dirtcastle: There have been attempts to add services to guix
<unmatched-paren>but it's a pretty large project
<apteryx>nckx: in icecat, using the User-Agent Switcher plugin, I choose Linux / Firefox 83 for that site (, then it works
<dirtcastle>GitHub copilot was not a good move at all.
<nckx>apteryx: Appreciated.
<unmatched-paren>the horrific thing is that most people won't actually do anything about it
<apteryx>nckx: I'm not curretnly connected, but perhaps I had an ssh pending
<nckx>Or it was a random bot or anyone else on earth.
<nckx>apteryx: WTF.
<nckx>I just SSH'd in… stantly.
<apteryx>so, shepherd's operation degrades over time
<nckx>I am the greatest fixer of all things. Bow before me in puny submission.
<apteryx>and eventually it stops working altogether
<nckx>apteryx: …or that.
<apteryx>nckx: thanks a lot for fixing it!
<apteryx>reminds me I should hack that standalone? flag
<apteryx>but that wouldn't have helped here.. hm
<apteryx>so what was the issue? do we know? :-)
<apteryx>(about the boot not working the first time)
<nckx>I'm OK with the degradation hypothesis, but it was pretty consistently ~30s from when it started till when it crashed.
<apteryx>ah really?
<apteryx>I don't recally it was slow when we first had it working
<apteryx>freshly booted on the new drive
<nckx>I didn't mean that, just that there's no report of any point where there was a 1…29s delay. Nor did the delay increase today, whilst Shep was presumably dying.
<apteryx>it was at like 40 s per the last strace I sent
<dirtcastle>unmatched-paren: what is this services you are talking abt? the way to selfhost them?
<apteryx>so it did increase (it was more like 25/30s earlier)
<unmatched-paren>dirtcastle: Yes.
<nckx>The first day it was reported here I got results 27s…33s.
<unmatched-paren>System services for self-hosting on a Guix System serve.
<nckx>‘Like 40s’ is certainly longer but I'm sceptical that it's significant at all. But I certainly don't know more than you.
<nckx>Actually it was more like 27s…35s at the long end.
<nckx>It's very hard to test because of the ‘brute force’ iptables filter.
<dirtcastle>they have packages for it right? writing package definitions for them is hard?. I'm too noob to understand why it's a hard problem? unmatched-paren
<nckx>s/because of/without disabling/
<unmatched-paren>dirtcastle: There's no packages for it yet
<unmatched-paren>it's quite a complex system
<dirtcastle>recommendation for resources to learn guile scheme? I'm currently reading the reference manual.
<unmatched-paren>you have to set up various core services before you can get things like and up
<unmatched-paren>dirtcastle: <- is good
<unmatched-paren>the reference manual is okay for figuring out specific procedures and macros, but it's better to use a guided tutorial for getting started
<unmatched-paren>like, it tells you what proc X does, and what purpose module (foo bar) serves
<unmatched-paren>but it won't guide you through actually learning the language
<dirtcastle>I tried to learn how to setup email server. they say it's hard because of lots of moving parts. is this like that?
<unmatched-paren>Although trial and error is a good introduction to many things, that's how i learned guile and guix :)
<nckx>Is there even a ‘’ (you know what I mean) *package*?
<unmatched-paren>nckx: I don't believe so.
<singpolyma>It would be a suite of packages / a manifest / a set or services
<nckx>= (you know what I mean)
<unmatched-paren>There's things like (provides the stuff that appears at,,,,,,,,,, and
<nckx>unmatched-paren knew what I mean. We r best buds.
<dirtcastle>I suspect a docker container already exist for it
<unmatched-paren>and probably more
<unmatched-paren>i think is a seperate package (gamja) that isn't developed as part of
<unmatched-paren>dirtcastle: Using a docker container entirely circumvents Guix's services
<unmatched-paren>Also, I've heard Things about docker on this channel.
<unmatched-paren>Oh, yes, there's also
<unmatched-paren>And, but that's getting deprecated and eventually removed.
<apteryx>nckx: to test, I just 'ssh localhost' locally on berlin
<unmatched-paren> <- All the sr.hts :)
<nckx>apteryx: Duh. I forgot that it happened everywhere.
<unmatched-paren>Ah, yes,,, and
<alethkit>unmatched-paren: By not being Turing-complete
<unmatched-paren>alethkit: I don't believe that would help guix much.
<unmatched-paren>If at all.
<alethkit>It wouldn't, no
<alethkit>It's just that I needed something to model g-expressions with
<unmatched-paren>Without Turing-completeness, we couldn't execute arbitrary build code :)
<alethkit>G-expressions are Turing complete?
<unmatched-paren>Nix's language is turing-complete, too, apparently.
<unmatched-paren>alethkit: Sure, they're just Scheme code.
<alethkit>Well, in theory, yes
<dirtcastle>I think native package preferably managed by guix is superior to containers
<unmatched-paren>alethkit: Executed at build time, sure, but still turing-complete Scheme.
<alethkit>I guess I'm going to have to muck about for a while
<unmatched-paren>alethkit: Have you read "Code Staging in GNU Guix"?
<dirtcastle>alright,it's 2:30 am here. gotta sleep. good night folks. learnt a lot today. thanks for your time folks. thanks to guix. <3
<nckx>apteryx: Pretty sure the firewall applies to localhost too (didn't check, not going to debug it now).
<nckx>Nighty dirtcastle.
<unmatched-paren>dirtcastle: \o
<alethkit>unmatched-paren: I have, yes. The issue is that I have non-Guix tools to integrate with
<alethkit>dirtcastle: Guten nacht!
<unmatched-paren>alethkit: Oh?
<alethkit>unmatched-paren: The Greek helmsman, to be precise.
<unmatched-paren>Oh, k8s.
<alethkit>Otherwise, I would be in Guile all day long
<unmatched-paren>I wish you luck.
<pkill9>guile is too powerful for humans
<pkill9>the gods themselves accidentally dropped it into the mortal world
<nckx>For his crimes, Prometheus was chained to a rock and forced to write npm packages.
<jab>nckx: hahaha!
<oriansj>odd guix has greetd but no greetd front-ends