<pancak3>is there a way to lint entire files instead of just a package? <kkebreau>pancak3: I don't know of any official way. <kkebreau>But also, `guix lint $(awk -F' ' '/define-public/ { printf $2 " " }' file-to-lint.scm)` <kkebreau>Cursed, likely error-prone, and not Guix-y, but it gets the job done for simple files. <leoprikler>For a less cursed way write a guile script that invokes guix-lint for-each of the package module's public interface. <pancak3>Well, I wanted to lint services and stuff. That script just makes a file of all packages right? <pancak3>yo, I can't seem to build guix right now do to some makeinfo errors. Is this just me? (It usually is) ***slyfox_ is now known as slyfox
<kkebreau>pancak3: My script makes a list of packages in the file you want to lint and lints those packages. <kkebreau>The documentation implies that linting is exclusively for packages. <leoprikler>Though someone could potentially extend this if wanted <leoprikler>otoh idk how much sense it'd make to lint a service or a procedure <pancak3>I could be wrong, but I think you can't build guix if /bin/sh != bash <nckx>I guess the question that begs is: why? <nckx>I mean, in theory that ‘should’ work, but you know there will be pain. <pancak3>bash is notoriously slow. Dash is built for speed. If you have a ton of scripts it's supposedly worth it. I probably would never notice the difference though. On arch linux I never had an issue with /bin/sh being dash *nckx lns /bin/sh to dash, puts on the goggles, bootstraps guix. <pancak3>Honestly, Guix is better prepared than most distros to set /bin/sh to something faster since we got a patch shebangs infrastructure. I still dunno about setting it to the default since normies want scripts they download from the internet to work. <pancak3>I think the first issue arises at doc/local.mk:100, but I'm really not confident about that <leoprikler>if everything else fails you can try building guix in a container where /bin/sh is symlinked to bash <pancak3>I can make a guix environment like that? That's super cool <pancak3>oh, guix environment --container seems to do it. Maybe there's a better way, but that seems to work <pancak3>successfully built in a container! I can keep my /bin/sh -> dash thing going! or it's quite possible I'm doing something else that's also stupid that's breaking it :P who knows <pancak3>Pine64 makes some good SBC. Not sure how they are on Guix but I'd image pretty darn good <nothingmuch>hah, i sent that right before my bouncer dumped a relevant backlog on me too =) <nothingmuch>yeah pine64 looks real nice, and beagleboard too, and i seem to have misplaced my shortlist from the other day, one sec... i got overwhelmed with options and it's hard to look up information on freedom and compatibility ***jonsger1 is now known as jonsger
***catonano_ is now known as catonano
<Noclip>nckx: npm seems to be available in guix. I'm very confused now! What's the issue with npm if it is actually available in guix? <Noclip>"$ guix environment --ad-hoc node -- npm --version <vagrantc>i think you can use npm the way npm is designed, but it doesn't integrate the packages it installs into guix so you do not get the benefits of guix when using npm that way <Noclip>vagrantc: Is there an easy but dirty way to let guix use npm for building packages? Or would this make everything just even more complicated? <apteryx>something pulls guile-1.8.8 during reconfigure. Perhaps genimage/u-boot-tools-2020.07. <str1ngs>sneek: later tell guix-vits. Hello, in regards to Nomad C-e issue with buffers and the minibuffer. Turns out this is a deeper problem then I thought. Originally I thought it was emacsy related but it's more related to (ice-9 gap-buffer) which is what emacsy underlying for buffers. I'll have to think more on how to best handle this. <xelxebar>Does anyone host a linux-libre-4.9 substitute I could pull from? <str1ngs>xelxebar: which guix hash are you on? <str1ngs>xelxebar: I'll build one on my substitute server I pulled today sometime should be okay to pull soon. <xelxebar>str1ngs: You are a life saver. I have been trying to build locally on my 10yo laptop and it's taking forever. Even had to restart once because /tmp ran out of space :/ <str1ngs>xelxebar: not sure how long it will take to build. but I'm assuming you have a low powered computer? <str1ngs>xelxebar: do you need i686 or x86_64? <xelxebar>Yeah. My laptop is super old, but it's x86_64 <str1ngs>I'll have something soon either locally or on my substitute server. best best is the substitute server because it's front facing https and you have the public key? <str1ngs>guix archive --authorize < gx.bufio.org.pub should do the trick <xelxebar>Great. Looks like I was able to add the key. Many thanks! <str1ngs>xelxebar: might take awhile to a bit to build. <xelxebar>That's fine. Will guix weather know when its done? <xelxebar>Beautiful. I will check periodically. What hardware are you running on? Just want to get a rough expectation of how long it might take. <str1ngs>xelxebar: my local machine is Ryzen 9 3900X the substitue is 8 core vps so it's performance is kinda meh <str1ngs>xelxebar: between the two I'll have something sooner then later. <str1ngs>xelxebar: I'll probably just let the substitute server finish so not to long now. since I always have a hard time getting guix archive to work in terms of transfer and using on the substitute server. <xelxebar>Oh dang. Your local machine already finished?? <xelxebar>No problem. If I built myself, it would take me until this evening... if the build didn't fall over again. <str1ngs>xelxebar: yes it took longer to decompress and patch then to build lol <xelxebar>str1ngs: Just sanity checking, but is this the correct guix weather invocation? guix weather --substitute-urls=https://gx.bufio.org linux-libre@4.9 <str1ngs>xelxebar: looks right, still building on the substitute server. <str1ngs>xelxebar: can you try guix weather now? <xelxebar>str1ngs: Showing that it's still unavailable <str1ngs>xelxebar: I use a cache so it takes a bit to generate the nar. <xelxebar>str1ngs: Okay. Does that generally take a while? Still not seeing it. <str1ngs>should be available by build atleast <str1ngs>I turned off cache for now to much of PITA someimtes haha <xelxebar>str1ngs: Sweet. The build command does pick it up. <str1ngs>xelxebar: okay drop the -n and that will download. and you should be okay for now <str1ngs>xelxebar: good stuff. ping me if you need any rebuild or anything else built. <str1ngs>I'll try to refine the cache server. let me know when you have that downloaded <str1ngs>or my understanding of --cache is not that good :( <xelxebar>str1ngs: Looks like the download finished. You saved me a lot of pain. Thank you. <xelxebar>str1ngs: Do you have a donation button somewhere? I'd like to buy you a coffee/beer/whatever. <str1ngs>xelxebar: now worries. keep the public key just encase. <str1ngs>xelxebar: on not at all. just pay it forward :) <xelxebar>str1ngs: I like your style. Will do! I will consider hosting a substitute server vps myself, perhaps one with a bit of beef. <str1ngs>xelxebar: though if you need anything built just ping me. I orginally set this up for qtwebengine substitutes when I created that package. because few people could test it <Kimapr[m]>Hello, I installed lxde in operating-system's packages field and I can't change icons in lxappearance <xelxebar>str1ngs: Thank you. I might end up taking you up on the offer in the near future. Am working on a kernel module and might need to test against other lts kernels. <Kimapr[m]>Interestingly though that i saw my choosen icon theme in .config/gtk-3.0/settings.ini <str1ngs>xelxebar: I turned cache back on. btw I don't provide many substitutes so I'd just cherry pick requests you need built. <str1ngs>xelxebar: I generally just run manifests through on the substitue server so certain are available. mainly large builds people might need. <xelxebar>str1ngs: That sounds like exactly the kind of niche I was looking for. Cheers, mate. For the most part I'll lean on ci.guix.gnu.org and hit you up if I need any one-off large builds. <str1ngs>xelxebar: no worries, that's why I set it up. though qtwebengine is now built on ci.guix.gnu.org so it has free cycles :) *guix-vits "Am guix-vits, and am ok, am have no X on ARM.." <sneek>guix-vits, you have 2 messages! <sneek>guix-vits, nckx says: I added (service elogind-service-type) to my system configuration and rebooted. System works fine. elogind is running. <sneek>guix-vits, str1ngs says: Hello, in regards to Nomad C-e issue with buffers and the minibuffer. Turns out this is a deeper problem then I thought. Originally I thought it was emacsy related but it's more related to (ice-9 gap-buffer) which is what emacsy underlying for buffers. I'll have to think more on how to best handle this. <str1ngs>guix-vits: disregard that I have a fix now. just need to test it out make sure it's okay. since it's a change to emacsy <guix-vits>sneek later tell nckx: Thanks. I need to try this again. *guix-vits huck with, i'll try Guixy-ARM again. In the worst case, i can just switch to that laptop for graphics. <str1ngs>guix-vits: hello, my ROCKPro64 still has not arrived nor my pinephone :( <str1ngs>GUI is overrated.. only need emacs and bash :P <guix-vits>str1ngs: Yes, (at least) standard delivery is a bit slow. <guix-vits>Interesting, if am will not manage to get X, if the framebuffer will work somehow? <guix-vits>all of those links-browsers, fbida-viewers :) <str1ngs>guix-vits: do you and nckx have a working declaration? <guix-vits>str1ngs: That is a question. nckx have not less than head-less config, and i had something, but elogind didn't worked for me last time i tried. <str1ngs>that's such a weird boot order. if emmc fails then does it fallback to sd? <str1ngs>I hope the SPI on rock64pro is better then pinebook. pinebook is terrible <guix-vits>I installed Armbian to SD, and formatted and mounted eMMC as /home <guix-vits>Didn't tried to dd the starting sectors, though. (but neither installed any boot-loader myself to there?) <guix-vits>str1ngs: No, i just used Guix installed on Armbian as a base for `guix system init`. <str1ngs>I don't like uboot seems so flaky compared to grub <str1ngs>I guess there are limitations due to SBC. mind you I only had experience with pinebook pro <guix-vits>Today i can try do `guix init` from this laptop, though. <str1ngs>oh uses qemu its easier. how powerfull is your laptop? <guix-vits>str1ngs: Pentium B960, 2 cores (2.2GHz, but trottling makes it worse), one thread a core. <str1ngs>guix-vits: do you have your declaration available? <str1ngs>guix-vits: btw can you make a git repo for this somewhere? <str1ngs>though I forgot these are kinda sensitive re user names <guix-vits>str1ngs: ah, Yes: sddm and alike aren't allowed me to log-in with 'guix-vits' username. Better safe than sorry, he-he. <str1ngs>apparently aarch64-linxu is not a thing haha ***guix-vits is now known as story-teller
<story-teller>... And then guix-vits changed his name to guix, and become guix, and dark times began .. ***story-teller is now known as guix-vits
<str1ngs>guix-vits: what part takes the longest to build guix pull? <ArneBab_>I still remember how annoyed I was to see "just get Guix". Now I have Guix and I say that myself, because Guix is just so convenient … :-) <str1ngs>guix-vits: oh that's not to bad. though on your laptop that could change. <guix-vits>I didn't measured this. Also i didn't ran into any substitutes for linux-libre-arm64-generic (again, that linux-libre didn't worked for _me_ isn't a thing). The making of .xz is near 1 hour. And so for compilation (if not more). Did not measured, though. <str1ngs>guix-vits: ah that's what I was looking for I can maybe provide substitute for that if you need it. <str1ngs>guix-vits: right now I'm running guix system build on that declaration encase you need substitutes. <str1ngs>guix-vits: also useful when I get my SBC <str1ngs>guix-vits: I have a substitute just like ci.guix.gnu.org <ArneBab_>Are you also missing substitutes for ungoogled-chromium? <guix-vits>ArneBab_: Try nomad. For what not working in nomad, use qutebrowser (a keyboard-driven chromium). Chromium isn't that good, no? <ArneBab_>Does nomad compile faster? Or do we have substitutes for it? <str1ngs>the nomad in guix needs updating too <ArneBab_>chromium isn’t bad — and I need it for testing stuff at work <str1ngs>yes it compiles pretty fast. provided webkitgtk is built <ArneBab_>ah, yes, webkitgtk also always takes ages to compile … <guix-vits>ArneBab_: nomad needs webkit2gtk, itself nomad compiles a lot faster, as it written in Guile. <str1ngs>ArneBab_: webkitgtk is not bad. I created the qtwebengine package I know lol <guix-vits>ArneBab_: qutebrowser is written in Python, and uses qt-webengine (or webkit2gtk). <ArneBab_>It’s mainly the rendering I need from chromium; the backend. <ArneBab_>It pains me to see how slow the compiles are of anything webkit related <str1ngs>qtwebengine is a nice backend. but I'd still thing webkitgtk is provides the best freedom <ArneBab_>str1ngs: is there a chance to get gecko support? Or is Firefox too unstable for that? <guix-vits>str1ngs: BTW, that plastic thing for applying a thermal paste is good to remove the eMMC from that board. <str1ngs>ArneBab_: the problem right now regards to gecko is it uses xulrunner. which is terrible to use as a widget. it's why nobody users it. though I do have hopes for servo which is like next gen experimental. <ArneBab_>the servo devs were just laid off by Mozilla (likely because most improvements got merged into FF) <str1ngs>ArneBab_: also I might consider CEF which is embedded chrome without QT. so could be GTK centrice <str1ngs>ArneBab_: as you can see I've done my research :) <str1ngs>ArneBab_: personally I would like to use firefox but it's clear they don't want people creating browser using gecko or dont' care to fix that ecosystem. so not very free in that regards. <str1ngs>ArneBab_: it's pretty bad when people would rather fork your whole project then use xulrunner <str1ngs>icecat for example. that's no dig at icecat. just firefox <ArneBab_>str1ngs: yes. The blog post gets into details how xulrunner seriously hurt FF development the past decade. <str1ngs>and its' even worst now because the intertwined rust into the mix. so so backing out of xulrunner is going to be long process. <ArneBab_>I’m using icecat fo rmy normal browsing, still waiting for the 78 update (some projects are starting to ship unofficial 78 versions) <ArneBab_>str1ngs: it sounds like the rust parts don’t support XUL stuff. <str1ngs>firefox has potential it was my daily driver but now I use Nomad. and now and again I need to use firefox because when Nomad is ambitious for one person to develop. so it still lacks features <str1ngs>like downloads only semi implemented because of an issue I need to track down in emacsy. <str1ngs>ArneBab_: thanks for the link this is insightful. <ArneBab_>I think so, too. It shows how completely sensible design choices (using a quick unrestricted API for extending) can have high cost later on. How important it is to design the extension API instead of just allowing access to all internals. <ArneBab_>I got the link in #freenet, because there we have a very similar problem: plugins have access to all internals, so any change we do can break any plugin. <str1ngs>ArneBab_: I'm reading this thing about addons. and I'm thinking to myself hmmm you can modify anything in Nomad while it is running. <xelxebar>How can I get a hold of the config used to build linux-libre? <ArneBab_>str1ngs: Emacs shows how such a model can work, but even there API changes are hard. I’ve had repeated config breakage. Still I wouldn’t want to lose it. <guix-vits>ArneBab_: addons in Firefox are silly: "Sorry. Your CSS will not work on this page, this is insecure!", "Your keybindings will not...". rrrr... <str1ngs>ArneBab_: after some philosophical thinking on that. I realized that it's okay for users to break things. I just need to becareful once I get out of alpha phase not to change API much. I'll probably have a version 1.0 API freeze <xelxebar>guix-vits: Oops. Forgot to mention that I am on a foreign distro. <ArneBab_>after reading the blog post I understand why they got there. Still I think FF forgot the importance of power-users. That these are the ones who drive your usage. <str1ngs>ArneBab_: meaning the internals might change but not the interfaces. with proper deprecation etc. <guix-vits>xelxebar: ls gnu/packages/aux-files/linux-libre/ <ArneBab_>str1ngs: I think the key factor is to only export stuff that make sense to change. <ArneBab_>(I have not used nomad yet; it failed to build the last time I wanted to try it) <str1ngs>ArneBab_: right and I plan to use parameters more why better then set! <str1ngs>ArneBab_: apologies Nomad is still pretty alpha and quite the moving target yet. currently there is a 0.2.0-alpha. which should build. also build from git on the devel branch has all the minor fixes for 0.2.0 series <ArneBab_>str1ngs: do you keep the guix package updated? <str1ngs>ArneBab_: I keep them updated at certain mile stones. the current nomad in guix uses g-golf is now 99% scheme. so that was a milestone. and I plan for a new point release soon. so submit a patch to update nomad then in guix. <str1ngs>ArneBab_: also I've been working on package for guix like qtwebengine and the later qutebrowser to switch to qtwebengine by default. as a side effect on looking for backends for nomad. <ArneBab_>what’s the difference between qtwebengine and webkitgtk? <guix-vits>ArneBab_: I think those are different engines: `guix show qtwebengine| recsel -p description` <str1ngs>qtwebengine use the blink render which is basically google chromes fork of webkit but as a QT widget. so it's pretty much like using chromium from QT also its C++. webkit is GTK fork of webkit but as a GTK widget, with other GLib classes for varies web related tasks it interface is C. <str1ngs>also use GStreamer all the things GTK related. <str1ngs>also little know fact Apples webkit was originally fork from khtml. so ya qtwebengine literally went around the block. <str1ngs>guix-vits: oh oh qemu: uncaught target signal 6 (Aborted) - core dumped <guix-vits>str1ngs: Pity. recsel is in recutils package. <guix-vits>takes the fields like "name: thing\nversion:thing" <guix-vits>so guix search X| recsel -p FIELD will "grep all the fields" <xelxebar>When creating roots with guix build --root, is it okay to move the generated symlink? My guess is no. <guix-vits>str1ngs: guix package -s '\<board\>' -s game| recsel -p name,description <str1ngs>xelxebar: I think the gc will check if the link exists if not it would be okay to gc. worse case you'll have a orphaned build <str1ngs>xelxebar: let me see if I can test that theory. unless someone knows for sure. <xelxebar>str1ngs: Well, the only way gc could check for a moved symlink is to scan the entire filesystem, no? My guess is that the symlink path is stored somewhere, and if missing, then the root is potentially available for garbage collection. <xelxebar>I just checked: /var/guix/gcroots/auto contains symlinks to the roots <str1ngs>it removes the stall link so you are okay <xelxebar>Yeah, but I want to prevent gc from collecting the build, so moving doesn't seem like an option. <str1ngs>I tested with guix build -r ./test make . the produces test-0 test-1 the link to /gnu/store/4k33n2nhsnnaxk2ip75gj7xiqdjns5hq-make-4.3. guix gc -d /gnu/store/4k33n2nhsnnaxk2ip75gj7xiqdjns5hq-make-4.3 removes the stall info and deletes the build <xelxebar>Is there a frontend for moving roots around? <str1ngs>normally you don't have to worry about roots they are used via profiles <str1ngs>either system guix-profile or current-guix <xelxebar>str1ngs: Well, I want to make sure the linux-libre build you gave me doesn't get garbage collected. <xelxebar>But I just don't like the location where I originally created the symlink <ArneBab_>str1ngs: ah, thank you! I knew that webkit came from khtml — back then I watched the fight of KDE to get Apple to release the code of their fork. Case in point: If it weren’t for the LGPL, we wouldn’t live in a world in which all relevant browser engines are free software. <guix-vits>xelxebar: if linux-libre isn't installed, it can be gc'ed <guix-vits>Like the things builded for `guix environment --ad-hoc PACKAGE` <xelxebar>guix-vits: Yeah. Sorry, my explanation was kind of scattered. <str1ngs>xelxebar: I see that is a good reason simply do. mkdir -p ~/profiles ; guix package -p ~/profiles/hold -i linux-libre@4.9 <str1ngs>xelxebar: this will ensure it's no GC'd and you can upgrade and work on ~/profiles/hold like any profile <str1ngs>xelxebar: plus you get all the goodies like --roll-back version history etc <str1ngs>linux-libre is kinda weird case for a user profile but it does what you need. <xelxebar>str1ngs: Oh. That's a nice option. Cool! <str1ngs>xelxebar: there could be a better way. I just hack my way through life :). ya know life finds a way. *str1ngs eyes up a herbivore <c4droid>I'm trying to create the user service for emacs --fg-daemon, and I have a question: the /run/user/UID/ directory is created by elogind-service? <c4droid>str1ngs: I can start my user daemon using sudo, but cannot start when I login with a normal user <c4droid>Using normal user start, shepherd report /run/user/1000/socket no such file or directory <str1ngs>you need to start your one user shepherd <str1ngs>I'm assuming you have services in ~/.config/shepherd/ ? <c4droid>str1ngs: ~/.config/shepherd have service definitions. <c4droid>And same for start user daemon, just exec shepherd they report same error <str1ngs>sure it says /run/user/1000/socket and not /run/user/1000/shepherd/socket <c4droid>str1ngs: I'm looking for what service is manage the /run/user/UID <c4droid>guix-vits: I run `shepherd' as the user, but still report /run/user/UID error <guix-vits>c4droid: IDK. But if You now run `herd status`, it will show that the instance is there :) <guix-vits>I get backtrace from `guix weather linux-libre-arm64-generic`: <guix-vits>ice-9/boot-9.scm:1669:16: In procedure raise-exception: <guix-vits>Throw to key `numerical-overflow' with args `("/" "Numerical overflow" #f #f)'. <kmicu>libx11 not patched yet, let’s notify Guix Security Team. <guix-vits>c4droid: What about that link? I didn't used user-services myself. <c4droid>I just follow that link to set up my user services <guix-vits>c4droid: Do Your config.scm has (elogind-service)? <guix-vits>Probably the app You want to use depend on it. <c4droid>guix-vits: Nope, maybe problem is from here. I'll add it to my config and reconfigure my system then try again <c4droid>guix-vits: I just reconfigure the system, and system created /run/user/UID/shepherd directory, the socket file it not exists <guix-vits>c4droid: and You getting an error when starting the user-services, after `shepherd` as user? <str1ngs>guix-vits: I have most of this system declaration built. I'll finish up in the morning. <xelxebar>I created a vm with guix system vm --expose=/foo/path. When the host creates new files under /foo/path, the guest sees these. However, when modifying files, the guest does not immediately see the changes. <c4droid>guix-vits: Sorry, it my fault, scandir typed sacndir.. <xelxebar>What's going on here? Caching of some sort? <guix-vits>I ran on my laptop a `guix system init -n --target=aarch64-linux-gnu rockpro64/config.scm /mnt`, just in case (and out of curiousity: if cross-thing will fail?). <guix-vits>str1ngs: am not sure if the initrd-modules should be (like in mailing list) be set to '() value. <guix-vits>"<xelxebar> I created a vm with guix system vm --expose=/foo/path. When the <guix-vits> host creates new files under /foo/path, the guest sees <guix-vits> these. However, when modifying files, the guest does not <guix-vits><xelxebar> What's going on here? Caching of some sort? <guix-vits><xelxebar> A reboot of the guest sees the changes" <ArneBab_>Can I use files from my store directly as substitutes? <ArneBab_>For example to check official substitutes, or to provide a substitute for ungoogled-chromium <leoprikler>guix won't build it twice if it already has one, but that check comes before substitutes afaik <leoprikler>I'm not sure about check, `guix challenge` is rather absolutist in that perspective <ArneBab_>If a substitute isn’t available, can I get substitutes from my own system and provide them somewhere? <leoprikler>you also can't just upload random stuff to berlin <Kimapr[m]>Why does "herd restart shepherd" say "You must be kidding"? <xelxebar>guix-vits: Thanks for catching the shadow! How did that happen? <ArneBab_>Kimapr[m]: because that would restart your system <ArneBab_>It cannot restart itself, because someone would have to start it then <ArneBab_>leoprikler: what I would like to do: If I had to build locally, create a substitute from the built file and upload it to guix.draketo.de <leoprikler>I'm not sure how the CI service works, but theoretically you could `guix copy` your local chromium to a substitute server you own. <ArneBab_>but only for derivations for which I could not get a substitute <Kimapr[m]>Doesn't 'herd stop shepherd' restart the system? I think being able to restart all services without rebooting would be nice <leoprikler>Kimapr[m]: you probably want `herd reload <script>` <ArneBab_>leoprikler: I see that I can copy packages from one guix to another with that. What I’d like to do is to make that into a usable substitutes server. <ArneBab_>I see something about single-item archives there <ArneBab_>guix-vits: that doesn’t create the format for a substitutes server, right? <ArneBab_>Can I do something like `guix copy ungoogled-chromium --to=guixtmp@localhost ; ssh guixtmp@localhost bash -c "for i in find */; do lzip $i --output=$i -9"` <guix-vits>ArneBab_: IDK. Probably it is for distribution to others. <ArneBab_>$ LANG=C guix copy ungoogled-chromium --to=guixtmp@localhost <ArneBab_>guix copy: error: failed to connect to `#<input-output: channel (open) 7effb4657a80>': Protocol error <guix-vits>ArneBab_: guix copy --help sais it uses ssh. <ArneBab_>ssh guixtmp@localhost works right now (I created the user) <guix-vits>ArneBab_: guix copy X --to=localhost? (without user) <ArneBab_>Do you mean I should change the login and pull from guixtmp? <guix-vits>IDK. Just if this not working from machine that should "to", why not try it from machine that should receive the files? <bluekeys>What does cannot determine provenance mean? <ArneBab_>… should have sent to help-guix, I think <sneek>nckx, guix-vits says: Thanks. I need to try this again. <nckx>str1ngs: I don't have an SBC, it was one of Guix's Overdrive 1000s. UEFI bliss and straightforward generic aarch64 kernel. <str1ngs>nckx: ah uefi would be a god send. though I've used uboot on pinebook pro. so could just be that SBC <nckx>guix-vits: Does adding the single (service elogind...) line really break your boot or are you adding more stuff at the same time (e.g., X)? <nckx>I guess even that single line could interact with another service you already have that I don't. <str1ngs>guix-vits: nope it has uboot and SPI <guix-vits>nckx: I tried with only elogind and %base-services, failed (at least yesterday). <guix-vits>str1ngs: I tried to say "pinebook was not eaten by uefi". Probably was failed epically. <str1ngs>guix-vits: I guess I should have google translated lol <str1ngs>guix-vits: btw iwd fails to build with --system=aarch64-linux using qemu <str1ngs>you can confirm that? on aarch64 system? <guix-vits>I'll go without Network Manager for a time, i think. <str1ngs>yep test-hmac-md5: unit/test-hmac-md5.c:58: hmac_test: Assertion `result == true' failed. <str1ngs>qemu: uncaught target signal 6 (Aborted) - core dumped <leoprikler>guix-vits: "Pinebook wurde nicht von UEFI gegessen." or "UEFI hat mein Pinebook nicht gegessen." <str1ngs>I thought it said does pinebook have UEFI? *str1ngs bow head in shame. <guix-vits>Sorry. Probably i better take a book instead of app, then :) <leoprikler>"will" is the verb "want". E.g. "Will ich Guix auf meinem Pinebook installieren?" -- "Do I want to install Guix on my Pinebook?" <apteryx>mothacehe: do you think it'd be reasonable to turn substitution off by default for the image record in (gnu image)? These are typically large files, and not so costly to generate anymore, right? <nckx>leoprikler: If you so desire. <jonsger>Ich will endlich mein Librem 5 bekommen :) *guix-vits word endly is brain-cracking, aren't it? *guix-vits (thruster-on? #f) (new-chair? #t) *jonsger works in the mean time on icedove 78 :) <guix-vits>ahh: gnu-tls fails on make check with --target=arm64-linux-gnu. <leoprikler>Thought so after recently bumping libhandy to 0.90.0 <sneek>Welcome back civodul, you have 1 message! <civodul>sneek: later tell vagrantc woow, congrats on the express guile-{l,}zlib packaging! <jonsger>okay, icedove/icecat 78 is blocked by missing rust-cbindgen-0.14 <apteryx>civodul: the validate job file commit broken offloading because of computed-file not using #:local-build? #t (it's checking for my user on a different machine :-). <apteryx>seems dagerously easy to override build-local? #t when using computed-file <apteryx>civodul: it fails even locally :-/. I guess because the computed-file is done in the build container. <apteryx>to reproduce, use the #:user keyword an any of your mcron jobs. <civodul>apteryx: ooh, i had overlooked this :-/ <civodul>i guess i tested only without #:user <apteryx>would you like me to revert it in the meantime? <guix-vits>Is that possible to `guix system init` for aarch64 from 86_64 now? I tried different combinations of --system and --target, but failed. <civodul>apteryx: i've pushed a fix that actually fixes the "mcron" system test <civodul>i guess i hadn't run it yesterday :-/ <civodul>i'm in a mood for validating more things upfront <apteryx>I'll report whether the fix works for my use case. <apteryx>I agree validating jobs before launching them is a nice thing to do! <apteryx>especially since there is no 'test' action to launch them at will. <apteryx>does it makes sense to offload that mcron-job computed file though? <apteryx>(i.e., should we set the #:build-local? #t bit on its corresponding computed-file) <apteryx>civodul: seems to work! thanks for the hot fix. <apteryx>mothacehe: I pushed 6a9581741e4ee81226aeb2f1c997df76670a6aab that disables offloading heavy weight image files. <civodul>apteryx: you're right, #:local-build? seems like a good idea for mcron-job <civodul>yeah #:local-build? #t is still the default <civodul>so normally no special action needed *zzappie just realized that `guix environment` setups inputs of a package only... Now I get the full power of --ad-hoc <pkill9>zzappie: i think that may change at some point, so by default it does --ad-hoc, there was talk on the mailing list <apteryx>civodul: it's the default, but if you supply your own list of options, it gets lost. <guix-vits>zzappie: Use profiles. First: "guix environment" can be garbage collected. Second: after guix pull You may wait before new version being maked. While in profile the old version will be there. <zzappie>thre could be ab ambiguous situation with -l. I once expected that ill get the package defined in file defined in environment and did not know that --ad-hoc has effect on -l flag <apteryx>civodul: in the case of the mcron-job computed-file, we pass #:options '(#:env-vars (("COLUMNS" . "150"))) as options, so the local-build? gets overriden to #f. <terramorpha>Hi everyone! I'm trying to create a package definition for a very small bash script I created. In theory, I wouldn't need to set the "source" field in the package definition because the script's content is embedded in the scheme file. However, when I run `guix build <script-name>`, guix complains that I need to set the source field. Is there a way to work arount that ? <apteryx>IMO, we should turn defaults into true when #f, so that if we pass the options parameter without overriding them, their value remains #f. <apteryx>as, in (build-local? #t)-> (offload? #f) <zzappie>guix-vits: "Use profiles". You mean create profiles and then use `guix package -p ...`? <PotentialUser-33>The substitutes server also fails to compile icecat 68.12.0-guix0-preview1. <guix-vits>zzappie: Aren't `guix package -p NAME` creates a profile, if it not exist? <guix-vits>zzappie: Am mean: When coding, one need the most actual environment (?). So guix environment. But if one need a tool (say, gettext?), why not just have it being ready-already (in profile)? <zzappie>guix-vits: I get what you mean :) I'm just juming from project to project recently so guix environment is handy when you just want to quickly build and test sumenting and trow it away *nckx replies to weird Guix bootstrapping FUD, is immediately drained of any positive energy for the day, comes here to recharge 🙂 <nckx>PotentialUser-33, we barely knew ye. Please come back. How did you query the substitute server? <guix-vits>nckx: boo! i've a bootstraping (bootloader-erecting, if You wish)! question! <leoprikler>terramorpha: g-expressions. They allow you to build files and directories from scheme code *raghavgururajan is playing with Cheese. 'nome heads will know what I mean <guix-vits>raghavgururajan: `cd cheese; meson build --march=native -O69 --funsafe-math`? <guix-vits>raghavgururajan: icons appeared, but manual now lacks 'G' in Gnome? *nckx welcomes fitzsim, who is interested in the fledgling Guix ppc64 port. <guix-vits>nckx: "whispers words of whisdom: let it beee" <terramorpha>do I just have to put the #~(...) bin in place of the origin statement ? <daemonspudguy>I'm trying to install GuixSD but can't get past the network connection part. I am on Wifi and need to type in a password. But the installer hangs on "Connecting to [SSID REDACTED], please wait". Any help? <Kimapr[m]>I think it would be much easier and faster (both in setup and download speed) if you connect it with ethernet if you can. <daemonspudguy>The router is in a whole other room and I don't yet have a Powerline adapter <daemonspudguy>The closest thing would be to tether the computer with my phone, but it would be even slower. <Kimapr[m]>Can you pastebin your wpa_supplicant config (with passwords redacted of course)? Did you make sure that password is correct and you use correct auth method? <daemonspudguy>I am trying to use the Guided Install, because this is my first Guix install. <Kimapr[m]>IDK about guided installation, my first install was manual installation <Kimapr[m]>i would say that the docs explain how to install it good enough <daemonspudguy>Yeah, but the real hiccup is the UDID for the drives. I can't remember that. <Kimapr[m]>You can actually install things in your profile on guix installation image, and if you don't start cow-store it will all go to ram <nckx>daemonspudguy: This sounds very much like a bug that might be fixed in http://guix.gnu.org/download/latest/ . No guarantees (not even of merchantability! or fitness for a particular purpose!) but it's worth a try. *nckx leaves for dinner anyway. <kmicu>Generally we should use stable (tested) iso. In this case the latest iso can help with the wifi issue (and potentially introduce other issues). <terpri>are maven-built java programs practically packagable in guix? can't remember if that's the one with the kotlin dependency or not <daemonspudguy>Will I be crucified for crimes against the state if I use some sort of proprietary software on my system? <terpri>more like if you *don't* use proprietary software :p <daemonspudguy>I use some proprietary software because with some things it works better for my needs. <kmicu>daemonspudguy: Guix is libre so it doesn’t prevent us from doing whatever we want but official Guix channels do not welcome any discussions about it. <daemonspudguy>I like the name Guix. It's entirely accurate to who would use it. <daemonspudguy>When I first saw the name, I thought it was pronounced like GOO-ICKS. <terpri>one of my irl friends still pronounces it that way <kmicu>terpri: one person works on introducing Maven into Guix with some success already iirc. ***nikita` is now known as ronja`
***ronja` is now known as nikita`
<terpri>ah, well there is a maven-build-system <terpri>oh right, gradle in the one with circular dependency issues *kmicu can neither confirm nor deny being from Hydra 🐙 *kmicu enjoyed Marvel’s Agents of E.M.A.C.S. <hacktivista>I have a few users I've deleted, but their profiles still exist (Im using guix as package manager, not guix system) <leoprikler>nah, if anything is still needed, it will be referenced by another gc root <sneek>I've heard ed is sed for children. <sneek>Its been said that guix is a functional package management tool for the GNU system <nckx>sneek: Who is leoprikler? <sneek>Someone once said leoprikler is love. <nckx>raghavgururajan: And 3.36.3 doesn't? <raghavgururajan>leoprikler: I tried launch epiphany in pure env with adwaita-icon-theme. <nckx>sneek: Who is raghavgururajan? <raghavgururajan>nckx: I wanted to ask you how to set a value for that, for a long time. <leoprikler>raghavgururajan is the authority on all GNOME packages. <leoprikler>sneek, raghavgururajan is the ultimate authority on all GNOME packages. <sneek>I've heard raghavgururajan is the ultimate authority on all GNOME packages. <nckx>I'm bootstrapping wip-desktop. <sneek>Last time I checked nckx is paid to infiltrate guix project to defame rms and destroy gnu $$ <leoprikler>raghavgururajan: @storedir@ should get replaced with the actual store dir <leoprikler>Hmm, apparently you're the only one who got sneeked in that drama. Consider yourself honoured 🙃️ <raghavgururajan>leoprikler, I was doubting it could be that. But not sure where is that variable @storedir@ resides. <Kimapr[m]>How do you replace packages in guix modules from other modules and is that possible at all? I want to have a module that wraps gcc in a script that constantly retries gcc command if it crashes with an internal compiler error <leoprikler>it should have a phase, that substitutes it with the actual value <leoprikler>Kimapr[m]: normally you'd use grafts, but in your case it's more likely you want to `guix environment --ad-hoc my-gcc-toolchain` <leoprikler>where my-gcc-toolchain has your gcc wrapper as bin/gcc <leoprikler>which internally calls the real gcc by full store path <sneek>Its been said that nckx is paid to infiltrate guix project to defame rms and destroy gnu $$ <nckx>That's supposed to be secret. <leoprikler>Yes, surely the GNU project will be destroyed once they *checks notes* acknowledge minorities. <Kimapr[m]>So can i replace variables in arbitrary modules from other modules? <hendursaga>So, I'm trying to package something and it fails, presumably because there are no tests. What's a nice shortcut to go to the source directory so I can manually check if there are any tests? I have Emacs-Guix installed, too. <zzappie>hey anyone got strange output with patch-shebang function? For some reason make's output and patch-sheebang output are mixed together... Even though they are invoked sequentially (first patch-sheebang then (invoke "make ...") <leoprikler>hendursaga: guix build -K; then cd to the directory that was created <nckx>I don't get the ‘x is paid to y’ meme. We're literally a movement built from nothing by people putting in hours and hours of hard work for free(dom), and for fun, but anyone disagreeing with me on the Internet must be getting a cheque in the mail, because I am important. <nckx>zzappie: Assuming they're both from the same build, it's possible they are buffered differently. <nckx>Kimapr[m]: I really doubt that. <leoprikler>part of it might be due to Microsoft et al. paying people to make free software worse (through various methods like patents etc.) <leoprikler>but also there's a nonzero amount of people believing George Soros pays protesters to *checks notes* ruin America. <lfam>Who taught that to sneek? <leoprikler>long time ago you just needed to say <x> is <y> for sneek to pick it up from general chat <leoprikler>so during the RMS drama days one person did that and sneek has probably remembered it since <lfam>Could be a sarcastic joke <leoprikler>well, you could grep the entirety of the logs to get the context, but... <sneek>vagrantc, you have 1 message! <sneek>vagrantc, civodul says: woow, congrats on the express guile-{l,}zlib packaging! <lfam>Fair criticism, vagrantc, but the discord has unfortunately continued <lfam>But, I'm not going to keep looking into it <nckx>Hm, you raise a point: does sneek listen to /msgs? <lfam>I'll just say, that kind of thing is not tolerated here and I'll ban whoever does it <nckx>vagrantc: Yeah, I realized I don't actually care. 🤷 <nckx>lfam: Please give them a fair warning first. <lfam>nckx: If I were you, I'd be quite angry that I hadn't been paid on time <lfam>If they were new, I would do that nckx <mothacehe>apteryx: Thanks for the image patch, looks fine! *vagrantc was happy to not hear as much about that drama lately but realizes it may continue on in other ways... <nckx>I know it sounds naive and changes no minds but some people actually listen & stop & start a more interesting convo. <nckx>Sure, no need to warn someone known every time they change their nick. <lfam>I agree that it's more valuable to talk to people and try to persuade them. On the other hand, it's equally valuable to know who is "just trolling". <lfam>But, I think it's even more valuable to keep this channel friendly. It's the first stop for many new users <nckx>vagrantc: It was used as an excuse for last week's spam attack. *vagrantc somehow missed it <lfam>So, it's a case of "some approaches are more equal than others" <raghavgururajan>nckx: I suspect that the recent spammer could set that to sneek. The person mentioned something about a blog post, this could be it I guess. <sneek>Someone once said lfam is a guix contributor <lfam>You can talk to sneek in private messages <nckx>Yeah (boy, for someone claiming to have a cause they're not very good at communicating what it is or, eh, general literacy? strange how that goes), I guess that's what they meant. <lfam>raghavgururajan: The problem that Guix has with Electron and NPM is that software like that is extremely hard to package with Guix. Although the source code is free, the dependency graphs have thousands of nodes, and there are cycles in the graph; Guix cannot handle cycles. I think that the Delta Chat team will probably not see this as a problem, so they will not be interested to port their software to another language ecosystem <lfam>I do think it's worth saying that, but not pushing them too hard <nckx>raghavgururajan: TBQH, I feel a bit put on the spot by asking to join in a conversation that I didn't start, about I client I'd never heard of before, using Electron which I just want to ignore until it quietly dies. <lfam>Bootstrapping is a hard problem, and it's not really fair to ask application developers to try solving it <nckx>It's also just the worst timing to ask me that. Not your fault. 🙂 <lfam>I believe there was a blog post or nice email about this subject in the past... I don't remember who wrote it <nckx>Big brain discussions on the Internet: I leave them to others. <lfam>Do you only step in at the galaxy brain level? *nckx has op privileges there. <raghavgururajan>nckx: Sorry about that. I wanted someone to explain them clearly, what the issue was. I could have done it, if I had understand the concept of electron/npm better. <raghavgururajan>lfam: True! I was not meaning to force them or anything. Just wanted to let them know what are struggling with. So that if they hear something same from other distros, they might consider porting. <pkill9>i don't understand how a cyclic depnedency can exist <lfam>pkill9: The world is messy :) <lfam>Basically, it's a situation where they don't build things like we do, step by step and from top to bottom <nly>sneek: later tell guix-vits best thing in your whole life! <lfam>And, they are probably more like run-time rather than build-time dependencies <lfam>Basically... read Jelle's emails about it :) <nly>nckx: привет, do you use any video call software? <nckx>nly: Believe it or not, even *points at 2020* now, I don't. <nly>wanna get away from traditional telephony <apteryx>nly: The gnome client of Jami works well in general, but sadly is still crashy on Guix. <apteryx>nly: other than that I use Linphone + a SIP service that allows me to reach POTS numbers, and do SMS. <pkill9>i can send and receive messages, haven't tested voice call <pkill9>but the interface is glitchy, though I am using wayland <apteryx>yeah, it needs more love to work well on Guix. <nly>sneek: tell later guix-vits "Tell me, Do you even geek?" You will! <sneek>later, nly says: guix-vits "Tell me, Do you even geek?" You will! <nly>sneek: later tell guix-vits "Tell me, Do you even geek?" You will! <nckx>That feature of sneek is truly the silliest. ‘Robert, tell Samantha I'm not talking to her.’ <nckx>civodul: Remember that patch you pushed in 2014? <Tirifto>Hello! Is the guix binary linked to in ‘~/.config/guix/current/bin’ supposed to be the one the user runs? <Tirifto>Thank you, lfam. I got into a funny situation where I added ‘/usr/local/bin’ at the front of my path, so that my programs would run in Firejail, but it turns out ‘guix’ is also linked to what appears to be the root’s binary there, so I guess I’m calling that one now. :) <lfam>Tirifto: Hm, yes, in some cases you might end up with '/usr/local/bin/guix'. I believe the binary installer script still does that (not sure!) In general, '~/.config/guix/current/bin' should come first <Tirifto>I might just alias ‘guix’ to ‘~/.config/guix/current/bin/guix’ then. Other options are always typing the full path or setting yet another symlink in a directory with higher priority. :P <leoprikler>what about option c: configure firejail to ignore guix paths? <nckx>Tirifto: /usr/local/bin/guix is there so any user can immediately run ’guix’ without manually mucking about with $PATH. But you can put it anywhere, no part of Guix (like guix-daemon.service) relies on *that* symlink. <nckx>sneek: what is the botsnack <lfam>It can only be understood by bots <nckx>Of course botsnack takes priority. <Tirifto>nckx: That means I can safely remove /usr/local/bin/guix, which shouldn’t break anything (for my user which has other links set up in PATH) and it shouldn’t come back again later? <nckx>Rename it to guix-local or whatever if you're worried but that should be correct. <nckx>Put differently: if you're already using Guix and ‘guix pull’, and you suddenly can't run ‘guix’ anymore because it was looking in /usr/local/bin, your system was *very broken* anyway and you should be happy you found out 😉 <Tirifto>There’s also ‘guix.old’ in there. I guess that’s no more important? <nckx>Hum. Is that something we create? <nckx>Is it as old as your installation? <nckx>git grep doesn't turn up any relevant guix\.old or \.old results. <nckx>Or do symlinks not have their own date. <Tirifto>Oh, right, yeah. It appears to be the same link. <Tirifto>I’ll just make it ‘guix-local.old’ then. <nckx><Tirifto> Happy 2022 all! What a shocking week: who would have thought *that* about Putin!? Anyway, I have a ‘guix-local.old’ file on my machine, why did Guix create it and is it important? *nckx needs some wake-up juice ☕, TTYL. ***zap1 is now known as zzappie
<Tirifto>It’ll be great if the system makes it that far! :P <Tirifto>Another question: is ‘hash guix’ supposed to return anything? <leoprikler>it may change the result of `which guix` when first running it <Tirifto>Oh, it looks like ‘hash’ then prints whatever you gave ‘hash [arg]’. <nckx>Sorry to nitpick, but this subtlety is exactly why it's all so confusing: ‘which’ will not be affected by hashing, it looks only at $PATH, so it may print something totally different from what your shell will actually run. ‘hash foo’ clears the shell's cached last-used ‘foo’ file name and looks it up anew. ‘type foo’ is a shell built-in and uses the same hash table, so it should always print what the shell would run. <leoprikler>I thought `which' was also confused by the hash but yeah, you're right <nckx>(All this to save a few milliseconds, if that, of looking up commands. I hope it's worth it to someone.) <leoprikler>Caching stuff to save lookup is an industry standard ;) <nckx>So is charging through the nose for legacy support contracts. <lfam>We could get rid of /gnu/store and only build stuff on demand <lfam>Each time it used, build from source <nckx>For extra fun: ‘which’, which is a stand-alone binary and could be called from other shells unlike bash's built-in ‘type’, just re-implements ‘the same algorithm as bash’ (man which). So it will still return subtly different results if you're lucky. At least the jank is portable! <lfam>Always use `command -v`! <nckx>Unix: it was elegant once, we promise, you should have been there that evening. <zzappie>nckx: I've dropped out for a while. Just wanted to ask what bufferring you were refering to? <nckx>I absolutely don't, sorry. *nckx closes HexChat for the day. Night all. <zzappie>:) You said buffering is the reason why I'm getting make's output and patch-shebang mixed in guix build output <str1ngs>sneek: later tell guix-vits. Yes emacsy-mode-line is ideal. We need something that truncates the uri to manageable length. I'll at it to my TODO list at latest. <lfam>zzappie: That's output buffering in the shell <lfam>In general, for programs that output information to the shell, it does not actually get printed when it's emitted <lfam>You can look into disabling the buffering <str1ngs>later tell guix-vits. also buffer-name for <web-buffer> is kinda meh. That's a hard one to figure out though. <str1ngs>sneek: later tell guix-vits. also buffer-name for <web-buffer> is kinda meh. That's a hard one to figure out though. <civodul>nckx: what 2014 patch? are you testing a feature of sneek or what? :-) <civodul>ah, maybe i pushed the freedink patches back then? <civodul>ah yes: bb3b71ce8799d848d327ec9a14ed4bb4c6977bca <civodul>nckx: ah well, i don't know why freedink is done this way <str1ngs>sneek: later tell guix-vits. another option is to remove uri from emacsy-mode-line generic method altogether. since M-x: current-url exists. Not sure how useful truncating is ultimately. <hendursaga>lfam: Does Rust/cargo has cycles in their dependency graphs? <lfam>hendursaga: Yes, but Guix "cheats" when dealing with it. It's kind of a problem, because it breaks a lot of features of Guix, but the status quo (the code has been added to Guix) tends to prevail <lfam>Rust is similar to Javascript in that the dependency graphs are incredibly large <lfam>And ridiculously sensitive to minor version updates <lfam>I don't really see a future for Rust on GNU/Linux distros unless that changes <hendursaga>Oh, yeah. The sensitivity. I haven't messed with Rust too much but that was a worry of mine. <lfam>We have a nifty "semantic version"-aware importer, and that's really the only thing that makes it possible to package Rust software in Guix <lfam>Otherwise... it would be a full-time job to package a single program <str1ngs>lfam: go language is kinda the same boat and I like go. <lfam>I worked on packaging the rav1e program and it required thousands of lines of new code, for ~250 new packages. Just for a video codec. If it was written in C it would have been a single package <str1ngs>lfam: I think they rely more on there own tooling and distro's are an after thought. <lfam>Go is similar but the scale is less, and there are no cycles <lfam>Go is older so they've had more time to mature. Hopefully Rust gets there <str1ngs>also with go mod. the philosophy is more inline with how guix works. though I can't speak for rust. <lfam>Go has basically recreated Guix :) <lfam>I'm still not sure how to integrate it, but they use a memoized cache just like us <str1ngs>yep, I had thought that. I was like this is a bit redundant on guix. <str1ngs>last I checked the go importer didnt use go mod. go mod was pretty new at that time. <lfam>I thought that maybe we could instrument their tooling to do things "the right way" for both Guix and Go, but ultimately I ran out of energy for it <lfam>Neither the Go importer or the go-build-system handle Go modules. We will need to deal with it soon, or scrap it completely <daemonspudguy>Error: build of ...-guix-1.1.0-20.537080f-checkout.drv failed. <msavoritias[m]1>Its so depressing to see rust and go and JavaScript not care about bootstrap stuff. Or fixing their dependency hell <msavoritias[m]1>I was wondering. Is there actually any system level language that is modern as rust but doesn't have the same problems? Also can be used on guix <lfam>Go has a simple bootstrap path <daemonspudguy>I'm incredibly lucky. GuixSD Stable freezes at the connecting to wifi screen during guided install, while GuixSD-Latest fails to compile a drv file. <kmicu>Ah yes, now I remember, there’s that freeze and to fix it we need to use manual installation process. <kmicu>I hoped the recent iso fixed that too. <daemonspudguy>I got past the wifi issue, but the latest iso fails to compile something labeled guix-1.1.0-20.537080f-checkout.drv <daemonspudguy>So I'm trying the stable iso again, but with USB tethering on my phone <kmicu>Switching to manual installation, mounting cow-store, guix pulling and then installing system should fixthat checkout error. <daemonspudguy>I love how it says error on finalization thread: success on boot up. <NieDzejkob>yeah, it's harmless so nobody bothered to fix it <civodul>it's bothered me for a while actually <str1ngs>msavoritias[m]1: how do you figure go does not care about "bootstrap stuff"? that seems a little off to me. <apteryx>me too. That and the pcspkr error, and the ntpd daemon trying to access the network before it`s up, and... ? :-) <civodul>apteryx: re disk images and #:local-build?, we'll have to monitor berlin as they'll now be built on the head node <guix-vits>nckx: while me, adding elogind to the (services, gets a cgroup: Unknown sussys name 'reezer'. <sneek>Welcome back guix-vits, you have 5 messages! <sneek>guix-vits, nly says: best thing in your whole life! <sneek>guix-vits, nly says: "Tell me, Do you even geek?" You will! <sneek>guix-vits, str1ngs says: Yes emacsy-mode-line is ideal. We need something that truncates the uri to manageable length. I'll at it to my TODO list at latest. <sneek>guix-vits, str1ngs says: also buffer-name for <web-buffer> is kinda meh. That's a hard one to figure out though. <sneek>guix-vits, str1ngs says: another option is to remove uri from emacsy-mode-line generic method altogether. since M-x: current-url exists. Not sure how useful truncating is ultimately. <raghavgururajan>apteryx: You mentioned that gnome-maps does not work outside gnome right? I have fixed it. Soon will be available in master. <apteryx>raghavgururajan: I asked because I was wondering if a ticket about it could be closed. Thanks for taking care of it! <apteryx>civodul: I was surprised to find reconfiguring my system trying to send gigabytes of data through my meager 10 Mbps uplink connection at home (the images were being generated for the hurd-vm service) to my offload machines. <apteryx>it was much cheaper to generate the images locally, I'd guess this should be true for the head node as well. <NieDzejkob>daemonspudguy: that checkout.drv failure is a problem on our side, I'll push a fix and write a comment so that it hopefully won't happen again <leoprikler>raghavgururajan: did you also have a look at 41058? <civodul>apteryx: yes that makes sense; just wondering how that'll affect the build farm <jsoo>Is the semantic versioning aware rust importer in master now?