IRC channel logs

2020-06-03.log

back to list of logs

<nckx>Only master for x86_64-linux, since it's a personal cache.
<nckx>Oh, I also blacklist certain packages.
*civodul -> zZz
<nckx>Good night.
<nckx>That said the weather is currently >94%.
<cbaines>I've added guix.tobias.gr to the build servers list for data.guix-patches.cbaines.net, and begun fetching the narinfos for the revision I mentioned above
<cbaines>94% percent availability for substitutes is pretty good, assuming guix weather roughly matches the numbers the Guix Data Service reports
<cbaines>It's fetched 10% of the substitutes already, so it shouldn't be much longer
<nckx>cbaines: I'm curious 🙂 Very happy to see it being put to (more) good use as long as it doesn't affect me too much.
<cbaines>Interestingly, because all the build servers are currently used in the comparison, more data could cause the reproducibility to go down as well as up
<cbaines>raghavgururajan, have you had any luck with ssh yet?
<nckx>cbaines: Did I skim the backlog correctly that you serve (& hence fetch) nars, not just narinfos?
<cbaines>nckx, so the Guix Data Service stores derivations in the database, and it stores enough information about those derivations that it can actually generate and server nar/narinfo files for them
<cbaines>but in terms of fetching information from substitute servers, it's just fetching the narinfo files at the moment
*nckx .oO https://ci.guix.gnu.org/ has been down for some time. Known?
<nckx>cbaines: All right. Fetching nars would be totally fine but I'd appreciate a heads up. I'd probably have to tweak my cache size then.
<cbaines>ci.guix.gnu.org still seems to be serving narinfos https://ci.guix.gnu.org/a462kby1q51ndvxdv3b6p0rsixxrgx1h.narinfo so I guess it's just Cuirass
<cbaines>and maybe just the Cuirass web service
<davidl>as a quick debug info for tonight, regarding the segfault. I happens when upgrading to c45431a and appears to be regarding inferiors: ERROR:
<davidl> 1. &inferior-exception:
<davidl> arguments: (srfi-34 #<inferior-object #<condition &message [message: "gcc-boot-4.7.4.patch: patch not found"] 7f9242017300>>)
<davidl> inferior: #<<inferior> pid: pipe socket: #<input-output: string 7fcf19e62850> close: #<procedure close-pipe (p)> version: (0 0) packages: #<promise #<procedure 7fcf186ac100 at guix/inferior.scm:160:32 ()>> table: #<promise #<procedure 7fcf18ac5db0 at guix/inferior.scm:161:32 ()>>>
<nckx>An exception leading to a segfault? Aw jeez. ☹
<nckx>cbaines: Could that request've been cached? guix-publish on berlin is stopped.
<nckx>I'm a bit out of it and don't know if we still use nginx in front of it.
<cbaines>nckx, I think NGinx does cache narinfos, so that sounds right
<nckx>guix publish: error: bind: Address already in use
<nckx>So it probably is still running and Shep just lost track of it.
<nckx>That's exactly what happened.
<nckx>Cuirass is happily(?) consuming CPU and offloading and logging succeeded builds. I'm hesitant to restart it: will that lead to bogus failures that won't be retried?
<cbaines>I think there's two shepherd services for cuirass
<cbaines>is the cuirass-web service running?
<katco>for updates to a package that break dependencies, are the patches to fix the dependencies separate, or are they part of the same patch that modifies the parent?
<nckx>cbaines: Yes, but if that's ‘safe’ to restart at least I can try that. Thanks.
<nckx>Or strace it.
<Kozo>Hey Guix, I am attempting to try out Guix publish but I'm not understanding the import of the public key. 1) I've created the keys on my guix publish server. 2) I've sent the .pub to another machine 3) I've started guix publish on my server using (sudo guix publish --user=<blah>
<nckx>katco: If there's no order that doesn't break in between, combine them. DependencIES sounds ominous though.
<Kozo>I don't understand what prefix is supposed to be here: guix archive --authorize < prefix/share/guix/ci.guix.gnu.org.pub
<katco>it's just 2
<nckx>Kozo: it's not relevant here, just < path/to/your-key.pub here.
<Kozo>nckx: Thank you
<katco>and i think all 3 must be updated atomically, so i'll do one commit. thanks nckx !
<nckx>Kozo: It means ‘prefix to the guix git checkout’ otherwise.
<nckx>Well, prefix of. Whatever. It's a strange word choice but I don't know the context.
<Kozo>nckx: It is from 4.3.2 of the manual and is talking about ci.guix.gnu.org
<nckx>katco: Do these packages follow the same versioning scheme by any chance? It's fine to lock them in step with (version (package-version the-other-package)) if so.
<katco>nckx: one actually comes from the same repo, and i've moved it to inherit from the parent. the other is dependent on this, and i don't think it follows the same versioning scheme.
<Kozo>Now that the key is authorized, what do I do now? The manual talks about running guix-daemon to the new publish server but do I run that on the server or a client?
<nckx>katco: That's already perfect then. If this is something you think is going to happen every time consider adding a comment, so the next (less diligent) person doesn't break things, but that's up to you.
<nckx>Kozo: You add the URL of the substitute server to the daemon configuration and restart the daemon.
<nckx>That depends on your OS.
<lle-bout>nckx, hello! I need to run cuirass, do you think it's possible to run it without being on a GNU Guix System? Just when on top of a distro?
<lle-bout>powerpc64-linux Cuirass already compiles here
<lle-bout>Or run sheperd as non-PID1
<katco>nckx: comments are always good, will do! thanks again.
<nckx>lle-bout: This is where I shamefully admit I've never run or built Cuirass.
<lle-bout>nckx, well no shame! I'll figure it out and share the solution with the channel!
<nckx>There's no technical reason it won't run on a foreign distro.
<nckx>If you still have porting energy left you can certainly get it to work.
<marusich>dftxbs3e, sounds rough. Once we add the bootstrap binaries, it will be easier to track work by making bug reports for these things
<marusich>I'm still looking into why gcc isn't reproducible
<lle-bout>nckx, well it compiles so I'm guessing it's about finding the command line arguments and figure out how to ask it to build from a repo
<marusich>funny thing is, I reubilt it on my machine from scratch (after running a full guix gc), and it still has the same output as before.
<nckx>Kozo: To clarify: that would be on ‘your’ (client) machine.
<lle-bout>nckx, I do still have energy; I've been getting results so it's encouraging! It's been like almost a year I'm working towards it /LOL
<lle-bout>marusich, cool !!
<lle-bout>marusich, ohh.. so machine specific data?
<marusich>either that or i'm just confused
<marusich>it's easy for me to become paranoid that i made a mistake
<marusich>at least we know it's certain that gcc compiles differently for different people
<nckx>lle-bout: I expect the problems to be limited to things like Guile load paths and other assumptions about file names and locations. It would be great if you'd end up with a cuirass.service (or whatever) that could be added to the repo.
<Kozo>nckx: Thank you. I am looking at how I do that on the client. When I run the command out of the manual, it just seems to hang and not do anything
<marusich>but yes it seems like a machine specific issue
<marusich>but maybe it's reproducible...on the same machine? :/
<lle-bout>nckx, I use Gentoo for it right now so that would be openrc heh
<lle-bout>marusich, maybe ask the other people for their binary? So you can binary diff?
<marusich>yeah, i asked them in an email to provide that
<marusich>I also provided my own
<lle-bout>cool!
<nckx>Kozo: Which command exactly?
<nckx>If you're invoking the daemon ‘by hand’ that's expected; it's not doing nothing, it's listening for ‘guix’ invocations.
<nckx>But that's not really the intention beyond quick testing.
<lle-bout>nckx, someone already asked that here, about why guix-daemon would be idle :P - I suggest printing something to express what it's doing!
<Kozo>nckx: It would help if I add it to my services >>
<marusich>Maybe I can trace back the derivations and try to do "guix build --check" on each of them until i find one that differs?
<nckx>Kozo: You didn't say or I missed it: are you using Guix System?
<Kozo>nckx: I am using Guix system on client and server. The command in the manual is: guix-daemon --substitute-urls=http://example.org:8080
<Kozo>nckx: I am replacing the example.org with my own network info
<nckx>lle-bout: I have an instictive dislike of uselessly printing ‘Listening on blah’ to everyone's log (OK, you got me, I only care about my logs), but maybe we should just bite that bullet 🙂
<lle-bout>nckx, logrotate will save you from the verbosiness :P
<nckx>It'll just compress and rename it.
<nckx>BUT I WILL KNOW there is cruft somewhere on my disc!!!
<nckx>Kozo: Right. It's not really intended as a ‘run this command now’ suggestion.
<nckx>Let me paste my own daemon configuration.
<nckx> http://dpaste.com/2C2ZHQ0.txt
<lle-bout>nckx, heh
<Kozo>nckx: Thank you for the guidance
<lle-bout>nckx, I'll make a change while you don't look then sshh
<nckx>Don't thank me yet. Problem is I don't use %base-services and you probably do, so you'll probably have to use modify-services.
<cbaines>So, it turns out the Guix Data Service doesn't handle narinfo files where the file size isn't provided for URLs. I'll fix that tomorrow, and then I'll be able to load the data from guix.tobias.gr
<cbaines>Goodnight!
<lle-bout>good night cbaines !
<nckx>cbaines: Good night!
<lle-bout>marusich, what is your time zone?
<nckx>I can't really change that without baking, and I don't want to bake.
<marusich>Pacific Time
<lle-bout>I'm CET but I sleep hazardly
<nckx>CET represent.
<lle-bout>alright, I'll know what to expect now!
<marusich>I'm not usually on IRC around this time. I start a new job next week, so I happen to have a lot of time on my hands right now.
<marusich>Starting June 8th, I'll probably only be online during the evening or night Pacific Time
<lle-bout>marusich, oh wow, we better finish before that, jobs are evil at stopping people from contributing to actual *Free* Software
<nckx>Congrats.
<nckx>Kozo: I mean, I'm sure that's not hard & it's documented & all, but I can't write an example off the top of my head.
<nckx>lle-bout: Unfortunately they're great for buying non-free food.
<lle-bout>:-/
<nckx>Yay, Cuirass is back. I guess cuirass-web just decided not to serve requests anymore.
<nckx>Restarting it did the trick.
<nckx>There, now I have Cuirass experience.
<Kozo>nckx: I do indeed use %base-services. Looks like it'll be a fun night heh
<katco>is it ok to submit patches that are dependent on other patches? i have one that is dependent on 2 prior ones
<nckx>katco: Just mention it in the (non-commit-)message.
<katco>nckx: in the email?
<nckx>Or submit it as a series when that makes sense, but sometimes it doesn't.
<nckx>katco: Yes.
<nckx>You can add arbitrary text under ‘---’ if you use git-send-email.
<katco>that sounds good. yeah, this particular one doesn't make sense as a series. it's got two parent patches which are not at all related.
<nckx>Is anyone else getting ‘Throw to key `match-error' with args `("match" "no matching pattern" #<eof>)'.’ thrown in their face when offloading?
<nckx>I don't remember this happening quite as often — that is: constantly — when I last used it.
<marusich>lle-bout, well I'll have motivation when I have my own power9 desktop
<nckx>Offloading's basically useless since I can't fire off a command and go do something else.
<marusich>although, it's been over a week and I still haven't gotten confirmation from raptor computing systems about a shipping timeline, even though I called them on Monday...
<marusich>I've heard they can be slow.
<lle-bout>marusich, it's been really pushing my motivation to have one machine like it :P
<lle-bout>marusich, well in these times; you can't expect anything else than slow anywhere
<marusich>It'll come when it comes
<marusich>Anyone else have trouble starting readline with "guix repl"?
<jonsger>marusich: slow and expensive...
<marusich>indeed. but it's freedom-respecting, and that counts for something.
<lle-bout>jonsger, the actual machine has been of extreme high quality for me - impressive for a manufacturer of this size that builds everything from scratch
<lle-bout>designs motherboard, develops firmware, etc..
<lle-bout>assembles ready to use machines etc.
<raghavgururajan>cbaines: Sorry, was afk. Let me retry now.
<jonsger>lle-bout: that's true.
<clodeindustrie>hi there
<clodeindustrie>is startx a thing on Guix?
<clodeindustrie>I have set up i3-wm with base-services thinking I could start it with startx as I do on my other computer
<clodeindustrie>but it doesn't seem to be installed, do I need to have a login manager?
<marusich>You probably just need whatever package installs startx. Maybe xorg or something?
<clodeindustrie>I thought xorg was installed automatically when installing a wm
<clodeindustrie>mm
<marusich>maybe it is?
<raghavgururajan>cbaines: I get the same error. raghavgururajan@bayfront.guix.gnu.org: Permission denied (publickey).
<lle-bout>marusich, building a VM image now
<lle-bout>marusich, with config: http://dpaste.com/35MATKR
<lle-bout>marusich, I hopefully added the kernel config right
<lle-bout>in aux-files
<lle-bout>gnu/aux-files/linux-libre/5.4-ppc64.conf
<marusich>nice! how'd you generate the kernel config? If I were doing it, I guess I would have probably just tried bumbling around manually with the source from "guix build -S linux-libre" and run "make menuconfig" etc. to generate something
<lle-bout>marusich, I took the one from Adelie Linux because it supports ppc64
<marusich>oh ok. that's probably a fine place to begin
<marusich>it is possible you might need some VM-related things to make it work, but we'll see. The existing configs in guix probably have some things enabled like virtio or 9p fs
<marusich>they might just be nice to have rather than necessary
<lle-bout>marusich, okay! we will see!
<clodeindustrie>marusich: looks like I needed a login manager
<clodeindustrie>I can't do anything though, my fonts are all weird, but that's another story
<bdju>what should I install to monitor battery health/capacity? upower? and does it matter if it's system vs user profile?
***catonano_ is now known as catonano
<marusich>clodeindustrie, glad you were able to figure it out!
<bdju>how do I find the equivalent of /org/freedesktop/UPower/devices/battery_BAT0 on guix system?
<bdju>I'm running find on / and I found /bin/upower and /etc/UPower, but neither are what I need
<bdju>I'll install acpi and see where I can get with that
<lle-bout>marusich, build problem with flac, AltiVec/VSX issue
<lle-bout>it's power9's vectored instructions
<nckx>bdju: That sounds like a (redundant) interface to /sys/class/power_supply/BAT0, no?
<marusich>lle-bout, all of these problems are things other distros probably ran into before, i guess, right? I would imagine that checking their bug trackers might be useful
<marusich>like, if gentoo is working
<marusich>you'd think they would have that info chronicled somewhere
<bdju>nckx: I don't really know what I'm doing, just wanted to check current battery health + the health of a new battery I just bought
<nckx>bdju: acpi's good, most things like i3status just read from the /sys file directly.
<lle-bout>marusich, https://github.com/xiph/flac/issues/199
<bdju>alright, good to know
<nckx>bdju: Is acpi -bi enough info?
<lle-bout>marusich, most distros abandonned ppc64 big endian but yeah
<bdju>nckx: oh, yeah. that's probably enough info, says how much of original capacity is left, which was the main thing I wanted.
<bdju>thanks
<lle-bout>marusich, strange thing is that I do have vsx on power9 - that user was on power5
<nckx>bdju: Thanks for telling me about upower (I was aware of it but thought it was some GNOME GUI thing). ‘Neither are what I need’: really? upower -e → upower -i <…>/BAT0 gives some useful stats here. More than acpi. Thanks 🙂
<nckx>Dat precision: capacity: 99.3887%
<nckx>Not bad for an 8-year-old battery.
<nckx>bdju: I see that I have upower-service-type in my services. Maybe that's the trick.
<bdju>ah, thanks
<Kozo>nckx: Thank you for your help. The winning code is http://dpaste.com/3QPXWB9
<nckx>Kozo: Congrats!
<Kozo>nckx: =]
<bdju>nckx: I'm still struggling to figure out upower. I've got that service in my config now, made sure it was enabled/started with herd commands. do upower -e and upower -i both need a path after them? and how do I find that path?
<bdju> http://ix.io/2o8M seems like it wants to start a service, but I thought it was started already. perhaps now the issues is that "upower" is in my user profile, even though the service is still in my config.scm
<nckx>Kozo: You might want to set --max-jobs too. --cores only passes -jN to make. --max-jobs will build different packages in parallel, and including source downloads. If you have a 6-core CPU, you can probably afford to set --max-jobs=2 and --cores=6 (or 3 and 3, or… unfortunately there's no way to make Guix always load all cores efficiently, and there's much to be improved.)
<nckx>bdju: No, that's fine. Packages don't have to be in your system profile just to talk to a system service.
<bdju>ah
<nckx>bdju: I also have (dbus-service) in my system.scm, and launch my window manager through dbus-launch 🤷
<nckx>I don't know much about dbus.
<nckx>bdju: If you're using %desktop-services (dbus-service) is already included. Not in %base-services. Similarly, big desktops like GNOME do the equivalent of dbus-launch for you, it's only needed for ‘minimal’ wms.
<nckx>bdju: http://dpaste.com/04G3QQ6.txt Here's the output, so you can decide if getting this working is useful for you.
<Kozo>nckx: OK, thanks nckx. Am I understanding this properly that until I said that I ci.guix.gnu.org could be used as a sub server, I was compiling every program before?
<nckx>bdju: I was pleasantly surprised but maybe it's overkill for your usage.
<nckx>Kozo: No, it was defaulting to ci.guix.gnu.org.
<nckx>If you override the defaults (as you do now) you do need to explicitly include it. You did the right thing.
<Kozo>nckx: Very nice, thanks again!
<Kozo>Your config helped immensely
<nckx>bdju: Does ‘sudo herd status’ list both upower-daemon and dbus-system as started?
<nckx>Kozo: Any time.
<terpri_>imo icecat needs to ditch torbutton, it's broken, bad for privacy (fingerprinting), and tor browser is way ahead in terms of basic usability now: https://blog.torproject.org/new-release-tor-browser-95
<bdju>nckx: I do run (dbus service), not running %desktop-services. I do like that output it shows.
<nckx>terpri_: I doubt anyone here disagrees.
<terpri_>tor browser should be evaluated for packaging, either as-is or as a friendly fork (which must have minimal changes to prevent fingerprinting)
<terpri_>it has a security mode that blocks js, that could be locked on (or just set as default?) instead of using librejs, and i think discourages addons so may not have all the same freeness issues as regular firefox
<terpri_>(librejs should not be used with tor, again due to making fingerprinting trivial)
<bdju>nckx: okay, so weird situation. dbus was running, upower wasn't. enabled and started upower. ran the command again. same error. herd status shows upower back to disabled and stopped!
<bdju>nckx: oh, update. enabling it works, starting to actually makes it become disabled and stopped again
<terpri_>there's also micah lee's self-updating tor browser launcher, but for guix just packaging tor browser bundle directly is probably easier
<bdju>s/starting to/starting it
<nckx>bdju: That happens when a service fails immediately; the Shepherd disables in after n start attempts.
<bdju>ah
<terpri_>makes it hard to recommend guix to activists when basic privacy tools don't work/aren't available :/
<nckx>I wonder where upower logs (IMO shepherd logging is a bit of a mess).
<nckx>terpri_: Then why not package it? :-/
<terpri_>nckx, furiously working every hour on more basic local needs
<nckx>That describes most of us 🙂
<terpri_>this happened last night: https://twitter.com/bennykoval/status/1267325857892368384
<bdju>afk a bit, feel free to give me more stuff to check
<terpri_>probably :)
<terpri_>if my proposal sounds reasonable, i'll write up a bug report when i have more time
<apteryx>nckx: shepherd expects the service to do its own logging handling (e.g., use syslog), otherwise expects the service author to add a #:log-file argument, IIUC.
<nckx>terpri_: Not that the situation stateside isn't fucked up. Not that you don't have other things to do. But you were arguing so hard above against/for… something, it wasn't clear why. Nobody thinks adding LibreJS to Tor Browser is a good idea (???). Nobody needs to ‘evaluate’ it. It just needs to be packaged, not requested, unfortunately.
<nckx>I wish there was a crack team of packagers just twiddling their thumbs in #guix waiting for packaging idea men, but sadly everyone here is probably not doing as great as they'd hoped a year ago.
<terpri_>nckx, ok, maybe i'll just package it and work out any freedom issues later
<nckx>Unless it's fundamentally unfree (I wouldn't know why) that's a good approach.
<nckx>Sorry for my mini rant.
<terpri_>nckx, no, you're right, i was just assuming that guix was going with icecat+torbutton instead of tor browser for ideological reasons, when it's probably merely a lack of labor time
<terpri_>presently under police+military curfew and can't risk arrest, so maybe i'll start working on it tonight :D
<mroh>good morning guix!
<terpri_>i still have some custom vanilla-firefox package definitions for spidermonkey hacking, so it might be pretty easy if most of the dependencies (rust etc.) are up to date
<terpri_>let's see if i can push this boulder up the hill :)
<nckx>terpri_: I can't speak for everyone but I don't know why anyone would opposed a source-built, FSDG-compliant Tor Browser. And as you said, the FSDG part is probably mostly taken care of by upstream. I've heard upstream(?) tell off people who use anything but the precompiled binaries, and that's too extreme for me (and Guix), but if any distribution can make a reproducible TB it's us. Go for it. We have Chromium FFS. The bar is not sky-high…
<terpri_>nckx, yeah i think you're right. thanks for the words of encouragement :)
<nckx>(Or low, depending on your opinion of Chromium 😛)
<nckx>terpri_: I don't think I'll be of much help during this particular endeavour but I'll try to answer any non-where-is-foo-in-the-FF-source-tree questions you might have.
<nckx>apteryx: So it just throws away stdout/err if that's not set?
<apteryx>yes
<nckx>I'm all for encouraging good logging but that seems harsh and error-prone.
<nckx>OK.
<apteryx>the logging has been added ad-hoc to the make-forkexec-constructor thing that is used as a start procedure, it's not really integrated in the design of Shepherd
<apteryx>the good news is that Shepherd is about only 10 modules of Scheme code, so it's refreshingly light to hack on it.
<lle-bout>marusich, grub-efi failed to build, that should be normal since ppc doesnt have efi
<terpri_>nckx, sounds good, i'll ping you if i have any general questions
<marusich>lle-bout, shouldn't need an efi for vm anyway
<marusich>I'm still collecting info but at this point I know that final-gcc from (gnu packages commencement) is not reproducible, which could possibly be the cause of our non-reproducible bootstrap binaries (or maybe not)
<marusich>It's actually spelled gcc-final, not final-gcc.
<apteryx>marusich: I've run diffoscope on my gcc result vs yours, and it's too large to be useful
<apteryx>(the output)
<marusich>apteryx, yeah I saw a similar diff in my own build outputs while I was hacking around...still not sure where the nondeterminism is coming from
<Gooberpatrol66>do I need to run guix package -u as each user because they each use different packages
<Gooberpatrol66>?
<Gooberpatrol66>what about guix pull?
<apteryx>everything is per user exept for the Guix System, which is shared
<apteryx>you run guix pull to update Guix itself, which means the package definitions it knows about
<Gooberpatrol66>so that's a yes for guix package -u but a no for guix pull?
<apteryx>guix package -u or guix upgrade allows you to update a user profile, upgrading the software it contains to their latest versions (which information got refreshed by 'guix pull').
<apteryx>a yes for both
<Gooberpatrol66>ok thanks
<marusich>Hmmm, if a derivation has two outputs, like "out" and "lib", and if you GC "out" but "lib" remains live (so you can't delete it), will the "lib" output be overwritten if you rebuild the "out" output?
<lle-bout>hmm
<marusich>I don't know the answer but am in the situation where i can't easily get rid of the "lib" output and I want to
<lle-bout>marusich, delete /gnu/store entirely ?
<marusich>I don't need to know, since I guess I can just try harder to delete things and take longer to build them back, but it'd be nic to know
<marusich>well, not that extreme, but i will need to probably revert to an old version of guix, then gc it, then "guix pull" to get back to where I was
<marusich>just to make sure it doesn't get re-used
<lle-bout>marusich, on my end, I had an issue with shm related tests on util-linux-with-udev failing but I just disabled tests for now
<lle-bout>linux-libre built !
<marusich>awesome!
<marusich>does it boot?
<lle-bout>currently it's building python2 and python3 and guile-static
<lle-bout>marusich, well not yet, it still hasnt built the actual image
<marusich>ah, i see
<bdju>argh I can never remember where to go to view/search the mailing lists
<bdju>oh, I was closer than I thought. the page to sign up links to the archives
<bdju>I was looking for who last updated waybar to see if they'd update it again, but I think the info I want is hidden.
<bdju>I hit a bug on the current version, 0.9.1, which I suspect may be fixed in 0.9.2.
<boeg>is the tor browser available in the official channel? I cannot seem to find it
<nckx>boeg: No.
<nckx>Maybe you can join terpri_ to lead the packaging effort.
<boeg>nckx: alright, good to know
<boeg>terpri_: I'd be interested in helping out with packaging tor browser if help is needed
<nckx>bdju: Updating waybar is annoying because it requires a newer GCC (stc=c++17 IIRC) but that GCC then chokes on even the latest fmt version's include files. At least I think that's what happened.
<nckx>bdju: http://dpaste.com/24Y21X3.txt
<bdju>nckx: ah, okay. (I don't really understand that output you've pasted, but I gather that it's a demonstration of it being annoying to update)
<marusich>does guix have a command to show from which gc roots a live store item is reachable?
<marusich>I ask because I have a store item that is supposedly alive but is not present in any of the "guix gc --requisites" output for any of the roots shown under "sudo guix gc --list-roots"
<marusich>rebooting made it dead.
<marusich>maybe some process was still holding open a transient gc root? who knows
<reepca>marusich: the daemon can extract runtime roots from, among other things, the set of all open files and the environment variables of every running process IIUC
<marusich>i recall reading something about that but do not profess to understand all the details
<reepca>as well as which programs are currently running, etc
<marusich>i am happy now that i was able to take out the garbage, though!
<cbaines>I managed to fetch some narinfos from guix.tobias.gr https://data.guix-patches.cbaines.net/revision/86a03090afa711dfa2f141caee820b66d7942bc3/package-substitute-availability
<sneek>Welcome back cbaines, you have 1 message!
<sneek>cbaines, nckx says: …and huzzah! Guix again fails the daunting challenge of ‘installing the boot loader good’ so g.t.gr will be down today.
<cbaines>oh dear, anyway, I seem to have cached some substitute data
<cbaines>94% substitute availability for a single revision is pretty impressive!
<cbaines>That also pushed the matching percentage up from 82% to 87% https://data.guix-patches.cbaines.net/revision/86a03090afa711dfa2f141caee820b66d7942bc3/package-reproducibility
<cbaines>Where only 6% are now unknown
<bricewge>Hello Guix!
<marusich>hey there
<bonz060>How big is the guix build farm? I want to see if I can set up a local substitute server in my network...
<cbaines>bonz060, I think it's possible to build most things with a few machines
<lle-bout>marusich, still building by the way, the famous GNU Guile bootstrap phase
<marusich>nice.
<lle-bout>bricewge, hey! I figured you were on the GSoC program? amazing!!
<marusich>I wound up finally being able to GC the gcc-final, but it basically required me to GC everything else because it's used like everywhere
<marusich>so now i am reading about other things while waiting for it to finish
<lle-bout>marusich, hah
<lle-bout>okay! cool!!
<marusich>i will be able to take a peek at gcc-final's output and hopefully see why it is different, and i am hoping that after cross-building the gcc-static again, I will be able to say "yes, the derivations after gcc-final leading up to cross-built gcc-static are in fact different now, which is suspicious"
<bricewge>lle-bout: Yes, it's a great opportunity to spent even more time contributing to FLOSS
<marusich>s/the derivations/the output of the derivations/
<bricewge>lle-bout: I see the powerpc port is coming up nicely, great work!
<lle-bout>bricewge, I'm so glad you've got that!! GNU Guix is an **awesome** project to contribue to!!
<lle-bout>bricewge, yes!!
<lle-bout>marusich, heh so much time lost compiling .. crazy
<lle-bout>that's where the dev lag is, not actual work but waiting for compilers
<lle-bout>it would be nice to have a trusted network of machines as a build farm that any contributor could access and contribute machines to after minimum screening of the actual trustworthiness of those machines, in almost all cases a contributor of GNU Guix does so in good faith :P
<marusich>finally it's done
<janneke>lle-bout: yes, that would be great; certainly for work that tends to "rebuild world" a couple of times a week
<marusich>lle-bout, I obtained the exact same build result again...
<lle-bout>marusich, o_O
<marusich>even though my original gcc-7 differed
<marusich>that is to say, the gcc-final is different
<marusich>but the things it built are the same
<civodul>hey there!
<civodul>janneke: would you be available for a shepherd "make check" on the Hurd? :-)
<civodul>last one
<janneke>hey civodul, yes
<janneke>last one eh, well in that case right after i merge wip-hurd-vm ;-)
<janneke>just kidding, current shepherd master, or...?
<civodul>bargaining! ;-)
<civodul>yes, master
<marusich>hello civodul! I just read the article about the changes to grafts involving the use of delimited continuations
<marusich>Very interesting stuff! I am still trying to wrap my brain around it :)
<civodul>hi marusich! cool, glad you liked it :-)
<civodul>i hope it's understandable
<marusich>I'd be lying if I said I understood it all clearly, but I think I get the idea, and I'm learning more as I read more.
<marusich>I was a little confused when you talked about how you "provide a primitive to introduce parallelism" in build-accumulator and map/accumulate-builds, since it looks to me like they are not running code in parallel themselves.
<marusich>But I think the idea was that, by quickly collecting the "unresolved" builds, you can delay execution of the more time-consuming stuff until you can batch them all together.
<marusich>Is that basically right? The reason I was confused at first was because it looks to me like the code does not involve concurrency.
<marusich>(The guix-daemon of course may do things in parallel, though, if we ask it to do a bunch of builds in a batch.)
<janneke>civodul: shepherd/service.scm:499:15: warning: possibly unbound variable `raise-exception'
<civodul>janneke: that's ok (but it means you're using Guile 2.2)
<civodul>marusich: that's correct
<civodul>and you're right, there's no concurrency or parallelism in that code
<marusich>OK, glad to know I wasn't missing anything about concurrency
<civodul>by "parallelism", i meant that we need a way to explore different paths in the call graph
<janneke>civodul: ... (yeah...i'm trying on Debian/Hurd)
<civodul>alright :-)
<janneke>hmm, can i use a guix vm?...possibly
<janneke>yeah, i could try that as well if i create a tarball (/me forgets all the dependencies)
<janneke>civodul: first "results"...:
<janneke>FAIL: tests/basic.sh
<janneke>PASS: tests/replacement.sh
<janneke>[hangs...]
<janneke>...but, that's for v0.8 and master alike...
<janneke>(on Debian/Hurd, guile-2.2)
<janneke>could it be that we only ever cross-built the shepherd until now?
<janneke>C-c C-cmake[4]: *** Deleting file 'tests/respawn.log'
<janneke>Makefile:1548: recipe for target 'tests/respawn.log' failed
<civodul>janneke: oh, you didn't have these the other day, did you?
<civodul>or was it a cross build?
<marusich>Also, if I may greedily ask one more question, since I'm new to prompts... Consider the case when we are executing (with-build-handler build-accumulator (proc obj)) in https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c40bf5816cb3ffb59920a61f71bd34b53cac3637 , abort-to-prompt is called, and execution passes to the handler, which is build-accumulator here. If build-accumulator returns (unresolved things continue) without calling the
<marusich>continuation, my understanding is that the result (i.e., the <unresolved> object) will be used as the return value of (with-build-handler build-accumulator (proc obj)). Is that right?
<civodul>janneke: BTW, when cross-compiling to i586-pc-gnu, i see: checking size of sigset_t... 4
<civodul>does that make sense?
<civodul>marusich: correct!
<marusich>OK cool. That seemed like the intended behavior, but I wasn't sure.
<marusich>Thank you for the confirmation!
<janneke>civodul: that was a cross build: I only verified we didn't break wip-hurd-vm... :-/
<civodul>ah ok
<civodul>janneke: do you know if 0.8.0 builds natively without test failures?
<civodul>i'll spawn my VM and take a look at master
<janneke>civodul: it doesn't: master and v0.8.0 show the same problems
<marusich>OK, sleep time for me. Goodnight everyone! Good luck with your debugging :)
<civodul>night marusich! :-)
<civodul>janneke: ok
<civodul>it seems that system tests that rely on port forwarding often fail for me
<civodul>as if qemu failed to forward ports or something
<civodul>although it seems to work on ci: http://ci.guix.gnu.org/search?query=openssh+spec%3Aguix-master+system%3Ax86_64-linux
<civodul>anyone else seeing this?
<janneke>civodul: ah...v0.7 didn't even compile yet for the Hurd, so we (i?) have been in "yay, it works" modus or so it seems
<janneke>civodul: native configure also says: checking size of sigset_t... 4
<civodul>janneke: ah yeah i remember now, it's all broke :-)
<civodul>in the tests log, there's "call to primitive-fork while multiple threads are running"
<civodul>(which is bad)
<civodul>and there's: "hurd: Can't add a reference on Mach thread"
<civodul>(which is very bad)
<civodul>the latter is a Hurd/libc bug i guess
<civodul>"hurd: Can't add reference on Mach thread\n" is from hurd/hurdsig.c in libc, but an older version (that of Debian)
<civodul>it's not in 2.31
<civodul>(the message is not there)
<civodul>i can't find that message at all in the history of hurdsig.c in upstream glibc
<civodul>so it must have been a patch carried by Debian
<civodul>janneke: if you can run "make check" in a Guix VM, i'm curious what tests/*.log show!
<janneke>civodul: yeah...; i'll give that a try!
*janneke is looking to see why glibc-bootstrap-0 doesn't build in our VM atm
<janneke>hmm, i need to build a development vm
<xelxebar>So I have a channel pointing at a personal repo of mine for random packages I've thrown together. One of these requires an upstream patch which guix build finds with the right -L flag, but installing from the channel complains about a missing patch.
<xelxebar>Do I need to do something to create the effect of gnu/local.mk?
<janneke>hmm, shepherd needs gcc??
*janneke added that to devel-hurd.tmpl...but apparently the 64bit version :-/
<xelxebar>Rather, my personal repo has packages under foo/packages/ instead of gnu/packages, so patches are under foo/packages/patches. Is that why installing from my channel fails to find the patch?
<janneke>hmm, adding (with-parameters ((%current-system "i586-pc-gnu")) %bootstrap-gcc) to operating-system packages does not work :-(
<janneke>previously, we could hack anything, creating our own system profile directly...
<janneke>maybe i can inherit and use #:system or #:target
*janneke starts a "wip-hurd-system"-era Guix VM
<janneke>civodul: hmm, 'make check' reboots the Guix VM ...
<janneke>...make check-TESTS
<janneke>make[3]: Entering directory '/root/shepherd-0.8.0'
<janneke>make[4]: Entering directory '/root/shepherd-0.8.0'
<janneke>Connection to localhost closed by remote host.
<bricewge>It's me or guix don't verify the certificate name when using HTTPS?
<mothacehe>hey there! jumping in the discussing, janneke, the 0.8.0 release of shepherd has a bug that can cause to call "kill 0".
<mothacehe>What are you trying to test in that VM?
<janneke>mothacehe: i was trying to do civodul a favour by testing current shepherd master, running 'make check'
<civodul>janneke: now that's interesting :-)
<janneke>but...that seems a bit of a strech
<civodul>heya mothacehe
<mothacehe>hey civodul!
<mothacehe>oh if it's on master, then it's bad news :(
<janneke>i forgot that there's all kinds of work that we may need to do on hurd: glibc/kill, guile/sockets, etc...
<NieDzejkob>bricewge: What experiment made you conclude this
<civodul>xelxebar: in an external channel, patches are searched relative to the root of the channel
<civodul>so instead of (search-patches "foo.patch"), you prolly need to write (search-patches "a/b/foo.patch")
<civodul>janneke: are you running "make check" as root?
<civodul>mothacehe: most likely it's a Hurd bug and "not our fault"
<janneke>civodul: yeah... :-)
<civodul>ah
<janneke>mothacehe: no...shepherd master; and the cross build is probably fine
<xelxebar>civodul: Thanks. Is there a clean way to add foo/bar/ to %patch-path?
<civodul>janneke: it'd be interesting to see if it reboots when not running as root
<janneke>civodul: i'm on an ancient guix vm, we don't have account services there yet
<civodul>xelxebar: not really, no
<janneke>yeah
<bricewge>NieDzejkob: I was playing around with Guix and Tor, have a look http://ix.io/2oaz
<xelxebar>civodul: K. Thanks for the easy fix.
<bricewge>NieDzejkob: curl complains of an invalid certificate name while guix download the substitute as if all is well
<NieDzejkob>bricewge: .onion addresses might be a special case since the address is already a public key hash
<civodul>bricewge: we should fix that in our nginx config on berlin, but you can safely ignore that
<civodul>narinfos are signed, that matters more than X.509 certificates
<janneke>i'm wondering if trying to add some hack to add (with-parameters ((%current-system "i586-pc-gnu")) %bootstrap-gcc) to a current VM is worth it
<civodul>bricewge: also, it makes little sense to access an Onion address over HTTPS
<civodul>you should use use HTTP here
<civodul>(the Onion address provide authentication and encryption)
<civodul>*provides
<bricewge>I understand that the user will be able to verify that the content it requested wasn't altered. But still an attacker could log what software you are using
<civodul>no, not when accessing the Onion service over Tor
<NieDzejkob>They already have a good guess based on the sizes of narinfos
<bricewge>civodul: Yes, but I guess that's the case when not using Tor too
<NieDzejkob>It'd be best to verify such a guess...
<bricewge>NieDzejkob: Yes. Still defence in depth is always of good practice
<civodul>bricewge: accesses over HTTP without Tor are subject to eavesdropping
<civodul>but accesses to an Onion service over HTTP are not
<bricewge>civodul: I was trying to answer your email https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00291.html and using HTTPTunnelPort from Tor need HTTPS. See http://ix.io/2oaE
<civodul>yesterday i learned about the Onion-Location HTTP header, which is a way to tell Tor Browser that a web server is available as an Onion service
<mothacehe>civodul: just tested shepherd master with the "reproducers" I had for the race condition: everything seems fine.
<mothacehe>your commit factorizing the signal handlers is really great btw
<bricewge>civodul: You are right that using HTTPS trough Tor doesn't improve security, but in this case it is needed for the HTTP tunnel to make the “DNS” request
<civodul>mothacehe: woohoo, thank you!
<civodul>i'll go ahead with 0.8.1
<civodul>we've had enough spurious reboots ;-)
<civodul>bricewge: but there's no DNS request, just a .onion resolution
<civodul>or am i missing something?
<bricewge>civodul: Sure in case of a hidden service, but one may want to access a substitute server that does not present itself as a hidden service
<civodul>right, so the rule is https for "normal servers", and http for onion services
<civodul>does that make sense?
<bricewge>civodul: Yes. But Tor's HTTPTunnelPort don't work with http it only support https requests
<civodul>ah, oh!
<civodul>got it
<civodul>sorry for the misunderstanding!
<bricewge>Here I'm only using HTTP trough Tor http://ix.io/2oaJ
<bricewge>And when guix tries to access FTP or Git protocol ressource it won't go trough Tor
<civodul>weird
<civodul>yes, sure, that's only for substitutes
<civodul>hmm
<civodul>so you can use --substitute-urls=https://....onion
<civodul>that should work, right?
<civodul>because it ignores X.509 certificates
<bricewge>That's why I think a more generic and holistic way would be to able to wrap any service with 'torsocks'
<civodul>likewise you can do wget --no-check-certificates from that
<civodul>ah sure
<civodul>but that's a different endeavor
<bricewge>Yes it would work
<civodul>i think it's already useful in itself to be able to fetch substitutes over Tor
<civodul>even though, like you write, it's only substitutes
<civodul>i think there's documentation "out there" on how to route all traffic through Tor
<civodul>perhaps we could provide a service for that
<bricewge>Ok, I'll try to write the cookbook entry in a way that make it clear that only substitutes are getting proxies
<bricewge>I don't want people at risk thinking that it's just setting guix-daemon to use Tor.
<bricewge>Regarding the service part, I was thinking of "make-forkexec-constructor/container" but with torsocks
<janneke>bricewge: i would welcome any kind of documentation on tor, i've never really managed to get it to work for me
<janneke>(i haven't tried very hard)
<bricewge>janneke: I'll send a patch
<janneke>no browser (except for w3m) seems to work under torsocks, torbutton stopped working in icecat a couple of months ago and is now completely gone...
<bricewge>janneke: Do you have a tor-service running?
<janneke>when i start my emacs/exwm setup under torsocks, stuff "hangs", but how to run just some emacs processes ERC under tor?...
<janneke>bricewge: yes :-)
<bricewge>I have icecat using Tor
<janneke>great, that would be a start ... i'd like to learn some more about that
<bricewge>If you want a separate IceCat profile for tor, then "icecat --ProfileManager" and create a new profile
<madage>bricewge: I think FTP does not work with Tor and since HTTPTunnel only handles HTTPS, what people usualy do is to set a proper HTTP proxy with privoxy/polipo
<bricewge>Tenable tor proper: Hamburger Menu -> Preferences -> General -> (at the bottom) Network Settings
*janneke follows along
<bricewge>-> Settings (a button) -> Manual proxy configuration -> SOCKS Host: localhost Port: 9050
<bricewge>Enable Proxy DNS when using SOCKS v5
<bricewge>"OK"
<bricewge>And that's it
<bricewge> https://check.torproject.org/
<bricewge>madage: Does torsocks redirect FTP too?
<bricewge>We need a privoxy service then.
<janneke>bricewge: lovely, ty!
<bricewge>janneke: You're welcome :)
*janneke would *so* much *love* to be able to get these GUI folks (firefox/gnome) on board with declarative configuration
<janneke>i'm very happy it works, but this is madness :-)
<bricewge>Yes, too much menu and checkboxes!
<madage>I think it tries to, but fails.. Tor was designed to work with TCP only and FTP uses UDP and opens diverse ports so it's a mess to encapsule and make it work with tor
<janneke>it's probably me, but i'm terrible at "searching the screen" for menus and stuff
<janneke>M-x apropos would already be "heaven"
<madage>I've seen people claim to have done it recently, but did not follow through to see if it was workng
<bricewge>janneke: You're not alone here.
<bricewge>It could probably be done with about:config tho
<janneke>bricewge: yes, we're making amazing progress here :-)
<madage>everytime I've tried to access a FTP server with torsocks lynx/icecat it failed
<civodul>bricewge: yeah, you can add a prominent "@quotation Note" block in the cookbook to make sure there's no misunderstanding
<civodul>the Shepherd 0.8.1 is upon us!
<bricewge>civodul: It was my plan, I found out about "@quotation" a few days ago.
<civodul>awesome
<mothacehe>civodul: yay! congrats!
<janneke>civodul: \o/
<civodul>next step for Shepherd: Fibers (or similar) and socket activation
<civodul>and then 1.0
<civodul>how does that sound?
<mothacehe>civodul: really nice :)
<bricewge>civodul: That would be awesome!
<bricewge>civodul: This might interest you https://github.com/davmac314/dinit/blob/master/doc/COMPARISON there a quick comparison between dinit and shepherd
<bricewge> I find the part about init system robustness very interesting, but I'm not sure if we can get there as we are using Guile
<mothacehe>civodul: now that we have a poll loop for signalfd, it would maybe make sense to use an 'fd' based mechanism to communicate with services, I guess.
<bricewge>janneke: No more menus and checkboxes shenanigans: http://ix.io/2ob8
<Kozo>Neat
*janneke saves as torcat
<janneke>bricewge: that's great!
<rndd>hi everyone! why when i guix pull i need to connect to ci.guix.gnu.org?
<zimoun>Hi Guix!
<zimoun>What is the difference between svn-fetch and svn-multi-fetch?
<janneke>civodul: running shepherd under user "guix", in a current Guix VM, passes all tests
<janneke># TOTAL: 13
<janneke># PASS: 13
<janneke>GNU guixygnu 0.9 GNU-Mach 1.8/Hurd-0.9 i686-AT386 GNU
<janneke>iwbn if there were a better way to do https://paste.debian.net/1149948/
<civodul>janneke: yeah, that's excellent news!
<civodul>so i wonder what's up with Debian's libc
<civodul>mothacehe: what do you mean by "communicating with services"?
<janneke>yeah, i pasted "uname" because i could hardly believe it
<civodul>:-)
<apteryx>civodul: socket activation... is this related to the sdnotify thing we talked about yesterday?
<erikg>recently i found that gcc-8, gcc-9, and gcc-10 from guix aren't setup to support -D_GLIBCXX_USE_C99_STDLIB, resulting in problems like this https://github.com/simongog/sdsl-lite/pull/429#issuecomment-634946068
<erikg>the issue appears identical to this one http://freebsd.1045724.x6.nabble.com/base-gcc-and-GLIBCXX-USE-C99-td5781697.html
<erikg>if this hasn't been caught or discussed already, i can escalate to the guix-devel list
<nckx>Hullo everyone.
<nckx>rndd: You don't need to, but ‘guix pull’ itself is substitutable and will be a lot faster if you do.
<nckx>cbaines: Nice, looks like all narinfos were cached. This is fun! Minor bug: empty drop-downs at https://data.guix-patches.cbaines.net/revision/86a03090afa711dfa2f141caee820b66d7942bc3/package-derivation-outputs?search_query=&substitutes_available_from=1&substitutes_available_from=2&substitutes_available_from=3&substitutes_available_from=4&output_consistency=not-matching&system=x86_64-linux&target=none&after_path=&limit_results=100&all_results=on
<mothacehe>civodul: instead of blocking everything waiting for the pid file to appear, services could hand an inotify fd, that would be added to the shepherd's main event loop for instance.
<mothacehe>We could also use the new pidfd API instead of relying on SIGCHLD signals.
<civodul>apteryx: socket activation means that the service manager pre-opens sockets and starts whichever service cares about them on-demand (like inetd and later systemd)
<civodul>so not directly related to sd_notify, but it's one of the nice features of systemd
<civodul>mothacehe: re PID files, definitely!
<civodul>i'm also very fond of pidfd
<civodul>but i'd be more confident if all this were available on the Hurd as well
<civodul>in theory things like signalfd, pidfd, etc. would be "easy" to implement for the Hurd
<rndd>nckx: thanks
<nckx>bonz060: Currently 25 x86-64 machines (AMD EPYC 7551P), a few more disconnected; 4 aarch64 machines; and 2 armv7 machines.
<mothacehe>civodul: yes, we could always keep the backward compatibility as you did with signalfd, but it will make everything harder to maintain.
<mothacehe>nckx: I saw you had a "cross-compilation" fixing party :p Nice job!
<apteryx>civodul: I see. Thanks for explaining!
<nckx>mothacehe: Thanks! Now running & logging a cross-build-everything script so I can do more than just grep for obviously broken packages (but there are plenty of those, too, if anyone wants to join in).
<mothacehe>nckx: Great! Some (most) of them are broken because the build-system does not support cross-compilation in Guix (waf, scons, glib ...).
<nckx>Meson…
<mbakke>let's try to fix those for the next core-updates round :-)
<nckx>Is cross-building just not a thing that ‘modern’ (coughs up blood) build systems care about? Or is the problem only in our build-systems?
<mbakke>nckx: meson supports cross-builds, but meson-build-system does not
<nckx>Excellent.
<civodul>mothacehe: yeah, that's a problem, i'd be so much nicer to do everything through signalfd & co.
<mbakke>I have a WIP patch for meson cross-building somewhere, but it's complicated, because meson propagates Python, and wrapping it does not work.
<mothacehe>Would love it :) One target would be able to cross-compile the "desktop" os. This way we could cross-build desktop images for the aarch64 based laptops (MNT reform, pinebook ...)
<mothacehe>nckx: no the problem is just in (guix build-system *), almost all build-system support cross-compilation in reality.
<nckx>I'm very happy to hear that.
<mbakke>should we open tracking bugs for cross-compilation support in the various build systems? I suppose meson-build-system and python-build-system are the most pressing, perhaps also ruby-build-system (for texlive).
<mothacehe>mbakke: Yes we could do that, starting by meson if you have a WIP patch that you can share :)
<nckx>cbaines: I realised something. While g.t.gr itself doesn't pull anything from other substitute servers, I offload most of my builds to it. When a client that does use ci.guix offloads something [with a dependency] that hasn't been built on g.t.gr, it will be pushed, and this will artificially increase reproducibility numbers. I thought the window in which this could happen was limited, but suspicious results like this one are more common that I expected:
<nckx> http://dpaste.com/1VDQ1V2
***daviid is now known as Guest61703
<Kozo>What package replaces putty in Guix?
<mbakke>mothacehe: will do later :-)
***Guest61703 is now known as daviid
<leoprikler_>Speaking about "cross-building": I wanted to update the dvxk package, which now requires mingw. As soon as I add that package however, meson fails with "gcc can't produce outputs".
***leoprikler_ is now known as leoprikler
<leoprikler>If I read the package description correctly, it already does its own version of "cross-building", but I'm not sure how to get a mingw-toolchain rolling, so to speak
<leoprikler>Can anyone here give me some pointers?
<NieDzejkob>0x4001d8
<NieDzejkob>Sorry, I couldn't resist
<butterypancake>so alsa-firmware is something that wouldn't get accepted right? From what I can tell, it's mostly gpl, but it's made up of a bunch of .asm files which are there to load the hex files which I can only assume where pulled from devices and no-one actually has the source code.
<butterypancake>^ for adding to our package repo
<NieDzejkob>Anyway, this sounds somewhat familiar in that unicorn fails to build on x86 when I add (cross-binutils "i686-linux-gnu") to the inputs. I didn't figure out why...
<NieDzejkob>I decided to only provide the input on the more exotic architectures
<nckx>butterypancake: If your assumption is correct: nope.
<nckx>‘The loader for the blobs is GPL’ won't cut it.
<butterypancake>nckx: I'm the big sad. I want my audio interface to work :/
<cbaines>nckx, hey, I'll fix the issues with empty drop downs.
<cbaines>nckx, as for the issue where store items might sneak from one build server to another, I don't think that's too big of an issue, providing it doesn't happen lots.
<nckx>butterypancake: I know, it sucks ☹
<nckx>cbaines: Thanks!
<butterypancake>nckx: idk even know how to find a FOSS audio interface. It seems so niche to the point where there is a good chance it just doesn't exist...
<nckx>You're talking pro audio hardware, right?
<nckx>I've never needed firmware for audio but I'm happy with whatever Intel HDA junk's built into the machine.
<butterypancake>yep, basically I want a 3.5inch input jack to my computer. But that jack also needs a builtin amp because electric guitars and bass's send a tiny signal. So you generall end up with a little USB box that needs some firmware junk
<butterypancake>I could in theory just make one (and finally use my engineering knowledge :P) but that'd be a lot of work designing it. Maybe I could do a kickstarter but manufacturing is hard and it's so niche :/
<butterypancake>ok, if I reverse engineered the alsa firmware for my device, I can package that right? That's probably easier than building one myself....
<nckx>butterypancake: If you licence it freely and swear that it was a clean-room job, sure.
<nckx>I hope you didn't look at the blob contents. Don't.
<butterypancake>clean-room job? Like it can't be inspired by the blob? What? How on earth can you reverse engineer without the blob?
<butterypancake>How can I get the magic numbers?
<butterypancake>that's straight impossible!
<nckx>This isn't my world, but I'm pretty sure looking at (even compiled) code makes you legally tainted.
<butterypancake>all right. Time to join the US riots and burn down the copyright office
<butterypancake>seems like the logical next step
<nckx>A common work-around is a two-person team, where one has Seen The Code but never writes any. But again, not my world, and IA mos def NAL.
<nckx>butterypancake: That's why reverse-engineering is *hard* and we should worship those who share their gift freely with us.
<butterypancake>it sounds like at any moment I'd be approached by the FBI and thrown in jail. It doesn't sound hard, it sounds scary AF
<nckx>That happens.
<butterypancake>time to move to russia?
<butterypancake>Join snowden :P
<butterypancake>Now I can't even hide my identity and do it because there are chat logs. Also I wouldn't be able to put that work on my resume.
<nckx>I didn't mean to scare you, just advise you not to poke around looking at copyrighted until you decide what to do.
<nixfreak52>Thinking about putting guix on a Desktop system that I want to treat as a NAS , does it make sense to use guix for a NAS ?
<butterypancake>I was reading about Hutchins the other day. I'm already freaked out. I guess that story had a happy ending, but most don't
<nckx>And the FBI doesn't pay a visit because you're reverse engineering, they drop by because people saw you carry Things With Wires and using Devices In Ways Not Authorised By The Vendor (*why* would anyone ever do that???).
<apteryx>nixfreak52: It supports mdadm RAID or btrfs RAID (with some caveats), and has an ieasy way to setup an NFS server, so I guess yes? :-)
<butterypancake>nixfreak52: make sure you hardware has opensource drivers #1. Then 100% yes. guix is designed to be stable
<butterypancake>does guix supports ZFS? If not, maybe freebsd would be an option
<nckx>butterypancake: I think it does, but not as root.
<nixfreak52>Yeah I forgot about that since I have to use nongnu for wireless drivers on my laptop which has been solid
<nixfreak52>does anyone use zfs on guix ?
<butterypancake>I was about to do that, but I free wificard cost like $15 on amazon, so I did that.
<nckx>…efraim? Or did you just add it for the lulz like 90% of our Rust stuff 😛
<apteryx>k
<vagrantc>there were some licensing issues with running zfs on linux ... not sure where the FSDG stands on that
<nixfreak52>one of these days I will get a system that doesn't need any non free firmware
*apteryx lost a k
<nixfreak52>last I read they don't support it
<butterypancake>just buy a MNT reform. $1500 but you get FrEdOoM and a kinda shitty thicc laptop
<nckx>vagrantc: Guix has a zfs kernel module but it's up to the user to combine it with their GPL kernel. I guess that's an ‘out’ of sorts.
<vagrantc>nckx: i presume it's marked as not substitutible
<nckx>They're both free software, distributing them is fine, but distributing them as a pre-combined binary is dodgy.
<nckx>Yes.
<vagrantc>right
<nckx>Or it definitely should be. I didn't check.
<nckx>It would be stupid not to.
<nixfreak52>I thought zfs on linux got around that licensing issue
<nckx>vagrantc: It is.
<nckx>(Marked as not-.)
<vagrantc>nixfreak52: some distros have chosen curious interpretations of the licensing issues
<nckx>nixfreak52: Our zfs package is zfsonlinux, so I guess not (enough).
<nixfreak52>Thats too bad
<nckx>nixfreak52: ‘The ZFS kernel module should not be downloaded since the license terms don't allow for distributing it, only building it locally.’ (from our package).
<nckx>But there's nothing wrong with using it. That's why we provide it. We're still an FSDG distro, we don't ship things ‘you could use but shouldn't’.
<nckx>Well, apart from Chromium.
<nixfreak52>I guess I'm stuck with btrfs then , any word on BcacheFS
<vagrantc>hrm. feel pretty stalled out about updating linux-libre, but i have patches for 5.7.x ... still insufficient ability to review all the kernel configs on all architectures
<nckx>nixfreak52: I've been running Guix System on bcachefs for the past 7 months.
<nixfreak52>Oh very cool , how do you like it
<nckx>vagrantc: Has mhw been responsive/helpful?
<vagrantc>nckx: eventually got a response ... which pretty much came down to needing more help
<nixfreak52>not on guix right now but is the package available on guix or did you build it
<vagrantc>nckx: #40190
<nckx>nixfreak52: It's solid on its own, and I haven't had to reformat (compare that to not-so-long-ago btrfs, wow) at all, but I do still get the occasional scary backtrace/hang during ‘stressful’ things like hibernation.
<nckx>nixfreak52: Also, GRUB can't read it, so I have a hacky ‘copy the kernel closure to /boot/gnu’ script that runs on reconfigure.
<nixfreak52>did you write docs to install it correctly ?
<vagrantc>heh. looks like the kernel config for arm64
<vagrantc>linux-libre is the same as for a defconfig
*vagrantc thinks something got lost somewhere along the way
<nixfreak52>since guix doesn't support LVS , I'm going to have to reformat to install another FS
<nckx>nixfreak52: Not at all, sorry.
<vagrantc>my guile skills (if calling them skills is even appropriate) aren't sufficient to tackle this ... but i wonder if a defconfig + blacklist + whitelist + overrides approach wouldn't be more sustainable
<nckx>nixfreak52: Now that someone other than me is even interested, I'll take a look at my patches and bang them into shape to be upstreamed.
*nckx afkay.
<nixfreak52>very cool thanks
<nixfreak52>@nckx are you using bcache on your root also ?
*vagrantc wonders what the missing pieces for guix root on LVM look like
<ryanprior>I have a repo of packages I've contributed to Guix. I'd like to run a script every so often to `guix refresh` all those packages so I can stay on top of submitting patches for new versions. The hacky way I've done that so far is to grep in files for four spaces followed by "(name" which looks like a package definition.
<kamil_>Hi Guix o/ Anyone having nss stuck at the check stage for an indefinite amount of time?
<ryanprior>Is there a Guile API I should be using instead to get a list of packages defined in a given directory?
<civodul>ryanprior: can't you just pass the package names to "guix refresh"?
<mbakke>vagrantc: the missing LVM pieces probably look something like this: https://issues.guix.gnu.org/issue/41143
<mbakke>(reviews welcome :-)
<davidl>so I found the offending commit that causes a failed guix pull and subsequent segfault upon running the guix command: https://github.com/guix-mirror/guix/commit/ffd2cfc8627c9e37451f0bb7a4ff0edd664e094b
<davidl>I succeded to guix pull to guix commit 851a3a7, and then when running guix pull --commit=ffd2cfc it fails.
<davidl>which is the next commit in the git log history.
<zimoun>"guix weather" returns 'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out"). What does it mean? And how is it fixable?
<nckx>zimoun: It means that Cuirass on berlin is not responding to nginx on berlin.
<mbakke>davidl: there are 2156 commits between those two commits, including a rebuild-the-world merge
<nckx>zimoun: It happened last night & I ‘fixed’ it by restarting cuirass-web so I'm not surprised it has returned.
<zimoun>nckx: thank you for explanations. I am seeing that since a couple of weeks.
<nckx>davidl: I'm probably biased but I can't see how that commit could ever cause a segfault. Which architecture is this?
<nckx>zimoun: Hm, that's not it this time. Your =1000 query is legitimately timing out. https://ci.guix.gnu.org/api/queue?nr=1 works.
<mbakke>davidl: can you try pulling c81457a5883ea43950eb2ecdcbb58a5b144bcd11 from 851a3a7?
<zimoun>nckx: I do not know, it is the default value. I do not even know what it is about. :-)
<davidl>ok, I have obviously made a pretty major mistake in how I looked at the order of these commits, Im sorry :/ I will do some further testing in trying to find when the guix pull fails.
<davidl>mbakke: yes I will try that.
<zimoun>since a couple of weeks, I just run: "guix weather <package>" and this 504 returns.
<nckx>zimoun: 1) That request should be entirely optional (my servers don't implement the Cuirass API but guix weather works fine), if it causes guix weather to fail for you I think that's a bug 2) it's asking Cuirass for a list (max 1000) of queued jobs 3) judging by how long it takes to return a single entry (=1) it's no wonder that it can't handle 1000 before nginx gives up.
<nckx>zimoun: Is this a fatal error for you? Honestly, you can just ignore it otherwise.
<zimoun>nckx: thank you for the explanations.
<zimoun>nckx: fatal, no. I can live with it. :-) It is annoying.
<davidl>nckx: its x86_64, qemu VM, btrfs filesystem.
<nckx>I don't know Cuirass at all, but for context, ci.guix is 91% CPU Idle (that's 64 idle cores) reading ~300 KiB/s and writing ~5 MiB/s to disc. There is no reason this should take so long.
<nckx>zimoun: ☝
<zimoun>does another default value make sense? does an option at the CLI to change this value make sense?
<zimoun>nckx: I am lost in the South of France with a poor connection, maybe it is the reason. Well, thank you for the explanations. I will see if it persists when I will be back at work.
<nckx>This has nothing to do with your connection. 504 means it's not you.
<nckx>If only it were 502, that would rhyme.
<davidl>mbakke: yes that pull worked fine. Im now pulling 4bdf418
<zimoun>nckx: what other see? I mean if everyone sees 504 with nr=1000 maybe the default value should be changed. I do not know.
*nckx would give large amounts of cash to be lost in the south of France right now.
<nckx>zimoun: I see 504 too (and even if I didn't the code is clear that it's a server-side problem). I just don't know what the output is supposed to be, it never appears when I query my own servers, so I can't have an opinion about its value.
<zimoun>nckx: :-)
<zimoun>nckx: thank you for the explanation. So I will ask on guix-devel.
<zimoun>nckx: I mean, I do not know neither what it is supposed to do and I do not know if it could be considered as a "bug".
<nckx>👍 bug-guix, even, IMO.
<cbaines>I recently did some attempted optimising of some queries in Cuirass
<cbaines>but I didn't look at this one
<nckx>A 72-core server is timing out while asking for 1000 json bits. It's a bug 😉
<zimoun>nckx: ok, I will go for bug-guix. :-)
<cbaines>I'm not sure the server has fast storage though, that'll probably be the bottleneck
<zimoun>cbaines: cool for the optimization. Do you see too 504?
<cbaines>zimoun, I haven't checked now, but I've seen it in the past
<cbaines>I've been looking at this bit so far https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00416.html
<nckx>cbaines: That was my guess too, but I/O is really low. That doesn't rule it out but it would be a very sick RAID array. Sicker than mine, and that's baad.
<nckx>It's never exceeded 10M in or out, although I didn't look at anything fancy with iops & suck.
<nckx>Er, such.
<nckx>(◍•ᴗ•◍)
<cbaines>at least with bayfront, it really struggles with I/O http://mago.cbaines.net:3000/d/rYdddlPWk/node-exporter-full?orgId=1
<zimoun>cbaines: thanks for the pointer
<cbaines>Oh, this reminds me, I'm not sure if raghavgururajan got access to bayfront yet
<nckx>cbaines: Not without your help. I don't have access myself.
<vagrantc>mbakke: thanks for the link regarding lvm
<nckx>cbaines: That is slick. Is there something like that for berlin?
<zimoun>cbaines, nckx: yeah! :-)
<nckx>cbaines: Backlog says no access, pubkey still not accepted.
<nckx>cbaines: Was this the profile bug thing whatsit again?
<cbaines>nckx, once the Prometheus node exporter service is installed, it's just a matter of scraping it with Prometheus, and then looking at the data through Grafana
<cbaines>I'm happy to scrape it with the Prometheus instance I have, but I don't have access to install the node exporter
<nckx>That ‘once’ looks like it's doing a lot of work but cool.
<cbaines>There's a Guix service for the Prometheus Node Exporter, so its just a one line change and reconfigure :)
<zimoun>BTW "guix weather guix --substitute-urls=http://bayfront.guix.gnu.org" return 504 too
<cbaines>zimoun, in terms of working out why that's slow, the first step is to work out what bit of the Cuirass code is related
<nckx>cbaines: Your hint is my command. Unless there were objections.
<cbaines>zimoun, do you happen to have the URL it accesses?
<davidl>mbakke: so the commit for that large core-updates merge is the problem
<zimoun>cbaines: what the 'it' in "URL it accesses" refers to?
<cbaines>zimoun, guix weather
<cbaines>I'm being lazy, I've found it in the channel history now: https://ci.guix.gnu.org/api/queue?nr=1000
<nckx>cbaines, anyone: There's already a ‘zabbix’ service under ‘Monitoring’ on berlin. Is that relevant?
<cbaines>zimoun, I think I've found the relevant bit of code now
<zimoun>cbaines: well, I do not know. The derivation is jgf74ss3y0864ihf317b2nbm7v2ic553-guix-1.1.0-4.bdc801e.drv if it is what you mean.
<cbaines>zimoun, also, regarding Guix weather, the Guix Data Service can do something similar http://data.guix.gnu.org/revision/4960a955f8f77cc4c35d0db749cd6f3de8787bff/package-substitute-availability
<cbaines>here's the code http://git.savannah.nongnu.org/cgit/guix/guix-cuirass.git/tree/src/cuirass/http.scm#n416
<cbaines>Ah, interestingly it uses db-get-builds, which is what I'm trying to improve here https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00416.html
<cbaines>reviews welcome :)
<cbaines>nckx, if you're interested in Prometheus/Grafana, that's also how I've been monitoring guix.cbaines.net: http://mago.cbaines.net:3000/d/gMq2pj3Wk/guix-cbaines-net?orgId=1&refresh=30s
<nckx>nixfreak52: Yes. My laptop SSD has a FAT32 EFI partition, an ext2 /boot partition, and all of / on one bcachefs partition. I haven't tested multi-device bcachefs roots yet.
<zimoun>cbaines: the package-substitute-availability is nice for a global overview. However, I am going via https://data.guix.gnu.org/repository/1/branch/master/package/guix/output-history to see the avaulability of a specific package.
<cbaines>Ok :)
<nckx>cbaines: My interest so far was simply ‘oh, wow, that's pretty’ 😉 But I will try it out. It's less trouble than packaging munin and looks better.
<nixfreak52>nckx thanks for the info, I'm getting curious about it now
<cbaines>nckx, my only caution is that Grafana is awful to package. Prometheus just has the typical Go problems, but Grafana has lots of NPM added on top.
<nckx>cbaines: …oh… that's not a Guix System?
<cbaines>nckx, it is, but I'm running Grafana in a screen session
<cbaines>Prometheus at least has a package and server, but I haven't done that for Grafana
<cbaines>doing so properly is also going to take more than a few months...
<nckx>Heh. I hosted nodejes webmail like that for a year, I understand.
<nckx>Never mind.
<zimoun>nckx, cbaines: so I will open a bug about the issue. Except if you beat me. Have a nice evening.
*nckx .oO do I look like a cop.
<nckx>Reconfiguring berlin is stuck at ‘warning: SQLite database is busy’.
<cbaines>nckx, also, I've just realised that this won't work immediately due to the firewall in front of ci.guix.gnu.org
<cbaines>since I doubt port 9100 is open at the moment
<nckx>cbaines: I thought about that but wasn't sure if the whitelisting was per-IP or per-port/IP.
<nckx>Hence the giving it a go anyway.
<nckx>Until this.
<nckx>Something is definitely afoot with berlin I/O.
<nckx>cbaines: I also found this and wtf'd right back out. https://github.com/prometheus/prometheus/wiki/Default-port-allocations
<nckx>Those… others are internal ports… right?
<cbaines>what do you mean internal?
<nckx>Local.
<cbaines>well, probably not, seen as Prometheus needs to access the exporter to record the data
<cbaines>If you're running Prometheus on the same machine as the exporter, then just local access is fine though
<nckx>OK. So all we'd need to whitelist is the ‘node exporter’ port, right?
<cbaines>Yeah
<nckx>I say we, I mean yet another thing for Ricardo to follow up on.
<cbaines>It doesn't need to run on that port though, so another port is fine, or you could use NGinx to reverse proxy
<nckx>Oh, it's HTTP?
<nckx>(Sorry, I really don't know this software at all.)
<cbaines>Yeah: http://bayfront.guix.gnu.org:9100/metrics
<cbaines>Just a bunch of text
<cbaines>I'm starting to form a somewhat working Guile library for Prometheus inside the Guix Build Coordinator https://git.cbaines.net/guix/build-coordinator/tree/guix-build-coordinator/metrics.scm
<cbaines>I'll hopefully pull it out at some point
<nckx>Yeah, nginx should be able to proxy that just fine assuming proper Host: headers &c. Thanks.
<nckx>cbaines: Neat-o.
<ryanprior>civodul: that's what my script ultimately does is pass the package names to guix refresh. But how do I get the package names? Right now I grep for them in files, which is hacky and I'd like to be more precise.
<ryanprior>I just pushed the script so you can take a look: https://github.com/ryanprior/guix-packages/blob/master/bin/refresh
<ryanprior>It works, but I could easily introduce code that would break it, so I'd prefer to figure out how to use Guile to read the files and get the names of packages defined there.
<bricewge>ryanprior: It would it be useful to get contributed packages from "git log --author"
<cbaines>ryanprior, fold-packages is probalby as useful example: http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages.scm#n237
<cbaines>ryanprior, in fact, it takes the modules as an optional parameter, so you'd just need to specify the desired modules
<ryanprior>I'm defining my modules as (testing foo), (proposed bar), (contributed baz) - so can I specify eg "proposed" as a module and get all the packages within>
<cbaines>ryanprior, yeah, I think you can get the representation of the module to pass in using https://www.gnu.org/software/guile/manual/html_node/Module-System-Reflection.html
<cbaines>ryanprior, something like (resolve-interface '(foo bar))
<ryanprior>Specifically I don't want my script to have to know about foo or bar. I'm adding new packages regularly and prefer not to have to maintain a separate list of them just for refresh purposes.
<ryanprior>If I already had "foo bar" I could just call "guix refresh foo bar" and be done.
<efraim>I added zfs to try to quell the bikeshedding about if it was OK or not but I don't actually use it
<cbaines>ryanprior, specifically to your use case, you'd be doing something like (resolve-interface '(proposed pantheon))
<cbaines>It should also be possible to load all the modules within proposed automatically
<civodul>cbaines: so http://bayfront.guix.gnu.org:9100/metrics is the raw data that Prometheus consumes?
<cbaines>civodul, yeah
<civodul>nice
<civodul>which reminds me: at the Guix Days, wasn't someone working on a monitoring tool?
<cbaines>The Guix Build Coordinator produces these metrics: https://coordinator.guix.cbaines.net/metrics
<civodul>ooh, and these are custom metrics, right?
<civodul>really cool
<cbaines>Yeah, I was saying earlier that I'll extract out the code to a guile-prometheus library at some point https://git.cbaines.net/guix/build-coordinator/tree/guix-build-coordinator/metrics.scm
<civodul>does Grafana know how to represent that?
<civodul>neat
<civodul>hey your cgit syntax-highlights Scheme!
<cbaines>You need to tell it how to display the data
<cbaines>I've got the config for cgit somewhere if you're interested, I'm using the Guix servicew
<cbaines>I also taught cgit how to render orgmode README files: https://git.cbaines.net/guix/build-coordinator/about/
<cbaines>(it's just very slow)
*janneke may have found a way to create /hurd/ during activation, i.e., boot without /hurd/
<civodul>cbaines: fun, we should tell the Savannah folks about it
<civodul>janneke: i hadn't thought about that, when is the first time it's needed?
<nckx>efraim: I had my suspicions. That's a valid reason in itself.
<davidl>civodul: that segfault I had I managed to fix. Im pretty sure that something in my ~/.bashrc wasn't liked by the core-updates merge-commit as I was able to guix pull up to the commit before that. Can I assume this segfault is not interesting to bug-guix anymore?
<davidl>i.e. I moved the .bashrc and then I was able to guix pull past the core-updates merge.
<janneke>civodul: well, mothacehe suggested this on my latest "let's maybe almost merge?" mail
<janneke>i.e. symlinking during activaton
<civodul>davidl: sure, if you think it comes from your end, that's fine :-)
<civodul>janneke: ah yes
<rekado_>status update: we’re still preparing the replacement server for berlin.guix.gnu.org
<civodul>janneke: is there a fixed first batch of patches we could focus on?
<rekado_>we got a spare HBA card to connect the storage, but we will need to order a riser card to install it
<rekado_>so it’s going to take a little longer than expected… :(
<civodul>hi rekado_!
<civodul>thanks a lot for working on it
<rekado_>civodul: hi!
<civodul>it's kind of a thankless task
<civodul>we all benefit from your work
<rekado_>I hope it’ll be worth it
<cbaines>rekado_, out of interest, what's the local storage like on the new server?
<rekado_>local storage on the new server is less than on berlin.guix.gnu.org
<rekado_>it’s one of the new build nodes
<janneke>civodul: a fixed first set: not really: this /hurd/ symlink is one of the first
<cbaines>rekado_, do they use SSDs or hard drives?
<janneke>and...if i get this going, then i need to do some rewrites...
<janneke>civodul: except for maybe your qemu-image series at the bottom, i still suggest merging those...
<rekado_>cbaines: two SSDs in RAID-0
<cbaines>rekado_, that's good :)
<rekado_>we want to also install fiber channel cards to connect our SAN via iscsi
<rekado_>this would allow us to migrate data a little more conveniently should we run out of space again
<civodul>janneke: i can always merge the qemu-image series, yes
<civodul>re /hurd, it's also okay maybe to have a first pass where /hurd is created during image creation rather than during activation
<civodul>actually on the first boot is tricky, right?
<janneke>civodul: well, mothacehe does not like it
<civodul>ah
<civodul>if mothacehe starts nitpicking as much as i do, we'll have to stop hacking
<janneke>hehe
<civodul>lemme see the latest messages
<janneke>i was trying to show them why it cannot be done...but it seems it could work
<janneke>i'll send a diff to discuss when i have cleaned it up, "it works" is not always enough
<civodul>ok
<Kozo>Hey Guix, which service do I modify to add a static ip if I am using Gnome as a DE?
<Kozo>Modifying %desktop-services gave me "invalid field specifier"
<cbaines>Kozo, assuming you're using NetworkManager, I'd handle that through the Gnome system settings
<Kozo>cbaines: Make sense, thank you.
<Kozo>Makes*
<Kozo>cbaines: Makes sense it doesn't work as the config isn't in config.scm and on reboot, it nukes the manual ip
<cbaines>Kozo, so did changing the network settings through Gnome help? I'm confused.
<marusich>Does Guix currently have a POWER9 server in the build farm?
<mbakke>marusich: no
<nckx>marusich: Not yet.
<nckx>There's an 8-core ppc64le VM for OSUOSL that can be hooked up once Guix knows what to do with it.
<nckx>*from.
<mbakke>cuirass-web seems to be struggling, I can load a page 1/5 times
<sirmacik>hey guix!
<sirmacik>anybody here doing some nodejs/js development on guix system?
<mbakke>it looks like berlin is actually running two different cuirass processes concurrently 🤔
<nckx>mbakke: I can't even SSH in anymore.
<mbakke>nckx: that must be something else, I can ssh just fine
<mbakke>and the system is not under particularly high load
<nckx>It never is, even when it's crawling.
<mbakke>I hope reepcas patches in https://issues.guix.gnu.org/issue/41658 will make a difference wrt the daemon slowness
<Kozo>cbaines: No, the gui settings did not change the IP. It reverts after a reboot
<ryanprior>sirmacik: I'm interested in doing that but the support for nodejs seems pretty modest in Guix.