IRC channel logs


back to list of logs

<leoprikler>ah well, I had this weird thought in my mind that people were somehow instinctively familiar with gresource
<leoprikler>lesson learned
<merazi>ekaitz: So the issue is as follows: the icons on the tray are buggy, like if they were rendered in a wrong way or something. It happens on the GNOME3 session menu as well.
<ekaitz>merazi: I had issues with that in the past and I had to use some plugins that helped but if i recall correctly that's not an specific guix issue, but a GNOME one
<merazi>It happens on xfce4 as well, maybe I'm missing a package (?)
<merazi>I installed xfce4 using the config.scm file... Maybe I'm missing something, let me upload it to a pastebin
<ekaitz>i have this thing installed: gnome-shell-extension-appindicator
<ekaitz>i know it's related with system tray icons
<ekaitz>but I can't remember why did I package it
<ekaitz>*install it
<merazi>This is the config I'm using: I'm not on GNOME, I'm on XFCE4, the tray icons are still showing weirdly
<ekaitz>lol unable to connect
<merazi>What about plain text?
<ekaitz>leoprikler: but the python file you showed us ( is just making a list of resources, but it's not playing around with the files contents, is it?
<ekaitz>merazi: nope
<leoprikler>nope, just generating an xml, that later gets compiled (see
<ekaitz>yeah! just found
<merazi>ekaitz: lol weird, let me try something else
<ekaitz>ugh i can't understand this meson code... i need to know how is it actually compiling them...
<merazi>ekaitz: I have it on my codeberg too:
<ekaitz>merazi: it looks pretty standard to me... i don't see anything wrong
<merazi>Oh ok, then I have no clue why this happens :(
<iskarian>I have no idea if it has any relation, but the assets.txt is missing bullet-symbolic, check-symbolic, and dash-symbolic... but maybe because they're svg?
<bone-baboon>mdevos: Thank you that was the problem.
<ekaitz>i found the same thing...the assets.txt is only used for the rendering to .png files
<ekaitz>so i don't know if it's related
<ekaitz>i didn't find anything... I hope you are more lucky
<iskarian>ekaitz, I'm afraid I'm finding myself out of my depth as well... my last easy guess would be that perhaps it is svg icons that are not rendering correctly?
<leoprikler>oh, that might be the case
<leoprikler>sneek: botsnack
<leoprikler>still ded
<leoprikler>but it shouldn't: gdk-pixbuf+svg is propagated by gtk
<iskarian>I don't recall if it was posted yet, but if not, evince generates this message when started from command line: Gtk-WARNING **: 15:51:10.567: Could not load a pixbuf from /org/gtk/libgtk/theme/Adwaita/assets/bullet-symbolic.svg.
<iskarian>This may indicate that pixbuf loaders or the mime database could not be found.
<iskarian>of course, it also has a broken icon (a pencil icon) and that's not generating any error messages, so... *shrug*
<leoprikler>for the record, both icons work fine for me outside a pure environment
<leoprikler>so something within the gnome package makes things work
<leoprikler>(perhaps gnome-shell?)
<leoprikler>the bullet-symbolic was what ekaitz and I were investigating before with no real conclusion
<ekaitz>it's getting late for me but I'll try to run all this in gnome to see if the gnome shell changes anything
<ekaitz>I'll do that tomorrow
<ekaitz>but I think it always failed
<merazi>well, I did a workaround for xfce
<merazi>hide the tray icons, when you pull them back they're displayed correctly
<merazi>it's not the best solution, but it looks better than having the glitchy icons there
<raghavgururajan>Folks! I am trying to package using ant-build-system, but the build fails with the error "jar not found". Thoughts?
<raghavgururajan>Here is the diff,
<raghavgururajan>Hmm, targets are mentioned in build.xml. So should I do #:build-target #f
<iskarian>raghavgururajan, would you not want #build-target "init"?
<raghavgururajan>You mean to do #:build-target "init" ??
<iskarian>That was my first guess, since the "build" target builds a distribution archive... but it does not seem right after all
<raghavgururajan>Yeah, I tried "init" "build" "all" etc..
<iskarian>It would be roundabout, but as a last resort you could run "build" and then use the distribution archives it builds haha
<iskarian>probably the "real" solution involves messing with the build options as mentioned at the top of build.xml
<iskarian>It could be rather difficult... it looks like even gentoo downloads the dist releases
<raghavgururajan>I see.
<apteryx>what is the (gnu packages xdisorg) module meant to contain? What does 'xdisorg' mean?
<apteryx>Seems like a distribution of non-core x11 packages
<apteryx>perhaps it would be better named as xorg-xyz.scm for consistency
<apteryx>although if it stands for a 'disorganized collection of x11 related packages' I like the pun.
<apteryx>leoprikler: beware that if both gdk-pixbuf+svg and gdk-pixbuf (sans svg) are propagated, you can't really be sure which one will be picked. Better check with ldd what is being used.
<apteryx>(I see gdk-pixbuf propagation as a bug, if there are instances of it remaining)
<raghavgururajan>I now get "Exception in thread "main" java.lang.RuntimeException: Could not create parent directory for lock file /.gradle/wrapper/dists/gradle-5.5-all/66q2j3qadt42ygj9lkubqor18/"
<g_bor[m]>Hmm... does it really try to create /.gradle ?
***iskarian_ is now known as iskarian
<raingloom>okay, i can't figure this out. how do you run an executable inside a service with all the environment variables that would be set if you used it inside guix environment?
<ss2>hi! So I've got a package decleration, that inherits from another package decleration. How can I put it into the system profile to be widely available -- without needing to push into a local channel repository?
<raingloom>ss2: you can use the --load-path option or the GUILE_LOAD_PATH environment variable to use a local channel, or just whatever guile module tree you need
<leoprikler>apteryx: i think it's the pun
<leoprikler>and I agree with your assessment of the gdk-pixbuf situation
<leoprikler>okay, so regarding evince, one missing image is "view-sidebar-symbolic"
<leoprikler>the broken image is "document-edit-symbolic"
<leoprikler>another broken image is "outline-symbolic"
<leoprikler>whoever finds those, gets a (GDPR-conforming) cookie
<leoprikler>sneek: botsnack
<vivien_>raingloom, you should definitely make your program set up its environment variable with wrap-program. When that’s done, you can invoke the program in any environment, including in a service
<vivien_>There are tons of programs doing that, but this morning I thought of guile-hall first: guix edit guile-hall
<nckx>Morning Guix.
<nckx>document-edit-symbolic sounds familiar, is that the winged pen? I'll miss it when it's gone. It's become part of my visual memory.
<ekaitz>leoprikler: I'm back after a good sleep :) I launched GNOME and the icon error we were checking yesterday with iskarian is also there so gnome-shell doesn't fix it for me
***daviid is now known as Guest89136
***Guest89136 is now known as daviid
<abcdw>hey guix!
<abcdw>describe-package and list-packages for some reason doesn't show packages installed by guix. package-directory-list value equal to "/home/bob/.guix-home-environment/profile/share/emacs/site-lisp/elpa", which seems correct (the directory contains all symlinks to necessary packages).
<abcdw>Do anyone encountered the same issue?
<karthik[m]>Anyone using GNOME in guix?
<ekaitz>karthik[m]: yeah, what do you need?
<karthik[m]>ekaitz: hi, I just installed gnome+guix on bare metal
*karthik[m] < >
<karthik[m]>I use Lenovo x230
<karthik[m]>Is there any furthur config we need to change ?
<ekaitz>i dont think so... it depends on your personal taste
<karthik[m]>ekaitz: are you facing/faced any such issues I mentioned above?
<ekaitz>I lost the history so can't see them... can you repeat them for me?
<ekaitz>karthik[m]: forget about that, it's the irc client which did something wrong... I can see your message, yeah
<ekaitz>I have had a similar issue with the touchpad, and I configured it manually
<karthik[m]>ekaitz: could you please tell me how you fixed disappearing touchpad options?
<ekaitz>I think I didn't, I just configured the touchpad by a lower level interface, because I also wanted some extra configuration
<ekaitz>that's my current touchpad config
<karthik[m]>ekaitz: thanks! i will check it out
<Noclip>You might want to keep an eye on audacity from now on:
<brendyyn>Yeah just dont say anything rude about it to them. be polite
<pkill9>i found a sweet script that lets you search google from commandline, but damn python doesn't seem to recognise symlinks to run
<Noclip>brendyyn: I didn't plan to say anything to them xD
<brendyyn>im finding cmake is demanding perl for some reason...
<Noclip>pkill9: That sounds interesting. Would that also work with other search engines? Eventually even through TOR?
<brendyyn>today i read tor got so bad an attacker controlled around 30% of all exit nodes and was man-in-the-middling everthing. make sure you only use https
<Noclip>On the other hand I'm not sure if that would be usefull for anything. If you are limited to the command line it might be a better idea to use a command line browser instead.
<Noclip>brendyyn: I disabled http in my Tor browser using https everywhere.
<brendyyn>that plugin does not guarantee you wont use http
<Noclip>(I did the same in the normal firefox.)
<pkill9>Noclip: i think it just scrapes google search results, so i dont see why it wouldnt run through tor
<brendyyn>try going to my lovely governments site:
<Noclip>It does if you tell it to do so.
<leoprikler>karthik[m]: idk about suspend, but hibernation in Guix is a missing feature
<leoprikler>sound… prolly depends on the hardware, but it's fine for me
<leoprikler>touchpad: can't verify because I don't own one, but I trust you to make a correct report
<Noclip><leoprikler "karthik: idk about suspend, but "> Ohh, I always forget which one is which ...
<pkill9>hibernation would be good
<brendyyn>suspend should work. hibernation is poor because linux cant support it well due to all the crappy hardware in the world
<pkill9>then it would be encrypted
<pineapples>Isn't hibernation a matter of setting up a swap file/partition, and writing a value to a /sys interface?
<pkill9>i thought hibernation works fine in linux,
<brendyyn>suspend keeps the computer running and just tries to save power. hibernation means turning it off but saving the state and restorting it
<pkill9>its just guix isnt set up to uandle it
<brendyyn>depends on the hardware. its more buggy
<civodul>apteryx: yay for rc2! \o/
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, flatwhatson says:
<leoprikler>IIUC there is a patch for hibernate somewhere in the ML, but it gathers dust quickly and it's known to be a hack
<Noclip>Is it possible to use virt-manager from guix on a foreign distro?
<Noclip>It needs the libvirt service for that.
<pkill9>i would think so, since it could maybe connect to the foreign distro's libvirt
<pkill9>it's probably just througha socket or something
<Noclip><pkill9 "i would think so, since it could"> Looks like it can't.
<Noclip>I think it is hard linked to the version from guix.
<Noclip>But let me read the error message again.
<Noclip>Mhh, maybe it's working now?!
<Noclip>Didn't get an error anymore after starting virt-manager
<Noclip>How does guix handle stuff like adding new user accounts needed by specific packages?
<brendyyn>by making a service for it
<Noclip>So if the service is listed in the os definition guix will make sure that user exists after boot?
<pkill9>you can also have it add the package to the system's packages
<Noclip><pkill9 "you can also have it add the pac"> Ahh that makes sense.
<Noclip>How about guix environment? Will the user be available in it even if it is not installed as system package or service?
<Noclip>And with the container option (-C)? Should be technically possible inside a container, right?
<pkill9>is there a specific package you're thinking of?
<Noclip>pkill9: Currently I'm just trying to understand how guix handles this in general.
<Noclip>But apart from that I'm still thinking about libvirt.
<Noclip>(But I don't want to run libvirt inside a container ...)
<pkill9>did you find where guix's virt-maanager is hardcoded to use guix's libvirt?
<pkill9>i don't think it is hardcoded
<Noclip>pkill9: I think you're right. It seems to work with the host distro's libvirt service.
<pkill9>you may also need to add your user to the 'kvm' group
<pkill9>or configure libvirt to allow your user to access it however way
<Noclip>pkill9: When installing libvirt with apt I got automatically added to the new libvirt group.
<karthik[m]>leoprikler: Suspend options is not visible in GNOME for me. I wonder why. x230 is a well supported hardware
<leoprikler>I'm not sure how GNOME handles suspend normally. It's probably a systemd vs. shepherd issue
<pkill9>is there a guide on debugging?
<pkill9>like for noobs
<pkill9>i have an idea
<pkill9>assign a keybinding that when pressed, opens the currently focused application in a debugger
<pkill9>but i don't actually know how to debug, lol
<civodul>hey lfam!
<lfam>How is RC2?
<civodul>i found a bug! :-)
<civodul>but i have a fix, nothing serious
<civodul>we should test on foreign distros too, in particular the locale warning (or rather lack thereof!)
<lfam>I can test the installer script on x86_64 Debian
<lfam>I don't recall seeing the warning while testing RC1
<lfam>It's somewhat misleading that the latest installer scripts says that both civodul's and apteryx's keys are required, but that's very minor
<lfam>It's nice that it offers to fetch the keys for the user
<lfam>I'm a little annoyed that #47979 didn't make it in, but that we made other significant changes, like the Spice thing
<lfam>But, I understand that #47979 required new translations after the strings were frozen
<lfam>Why did we add wget to %base-packages instead of using `guix download`?
<civodul>lfam: re keys, the installer has to offer both because it can be used for any release in theory
<lfam>Right, it's unversioned
<civodul>and yes, agreed re #47979 :-/
<civodul>lfam: re wget, i think apteryx found it more convenient
<lfam>I guess it's a UX issue
<civodul>and it's true that users probably expect it
<civodul>it's more about being less surprising
<lfam>Re #47979, the second best time to plant a tree is today :)
<lfam>So it will save some bug reports after 1.4.0
<lfam>I notice that Berlin doesn't have a baked substitutes for gettext-minimal, although the derivation is built on
<civodul>re #47979, i think we should stick to the string freeze policy
<lfam>Maybe my substitutes cache got stale somehow
<lfam>Like, I'm running `guix pull` after installation and it wants to build the dependencies of Guix
<lfam>Yes, definitely
<lfam>I'm just expressing my disappointment. I knew it wouldn't be included
<civodul>yes, we missed a couple of useful patches
<civodul>we'll do better next time!
<lfam>Alright, I deleted the substitutes cache and now it's working better
<civodul>lfam: re "guix pull", i ran it in the 1.3.0rc2 VM and it didn't build anything
<civodul>substitutes were available
<lfam>I'm glad to hear you're testing the VM image
<lfam>No locales warnings, which is nice
<civodul>lfam: you're testing on foreign distro?
<lfam>Yes, Debian
<lfam>Re #48316, I'm wondering if somebody asked Filip to make this patch? If so, okay, but otherwise, I'm not sure we should document the ML moderation, which is totally ad-hoc
<lfam>It's not really correct to say that "Future acknowledgements should not be delayed". That really depends on the whims of the moderator
<brendyyn>can anyone merge bugs?
<lfam>Yes brendyyn. Anyone can do anything with the bugs, based on these instructions: <>
<brendyyn>and merge A B is the same as merge B A?
<lfam>I don't really know. Do the instructions say?
<lfam>"Merger is like equality: it is reflexive, transitive and symmetric. "
<lfam>I don't think there is a hierarchical relationship between merged bugs
<brendyyn>and i dont need a subject?
<leoprikler>no subject needed
<leoprikler>don't forget to say thanks
<brendyyn>> merge 39527 36508
<brendyyn>Unknown command or malformed arguments to command.
<lfam>I don't understand
<lfam>I don't understand your messages. Are you saying that it didn't work?
<brendyyn>yep thats the message i got back
<lfam>I sent a message containing only "merge 39527 36508" to <> and it worked as expected
<lfam>It should have worked for you, if you did the same
<lfam>I noticed you had an extra space between the bug numbers. I don't know if that affects it
<lfam>And, I don't know about the '>' character. I think you should not put that
<lfam>You can try again, but using unmerge, and then merging them again
<brendyyn>thats just from it quoting me in the reply
<lfam>Did you send it to the correct address?
<lfam>I would try again without that extra space
<brendyyn>might have been the space
<brendyyn>hopefully its idempotent
<lfam>I don't think the bugs can be merged more than once, in a meaningful way
<brendyyn>btw i wanted to CC them and say it was likely that issue, but im not subscribed so i cant get their email address
<lfam>Who is that?
<lfam>Btw, you can get the full emails with headers from the ML archives
<lfam>For example, click "download the archives in mbox format" on a page like this: <>
<raghavgururajan>Hello Guix!
<karthik[m]>raghavgururajan: (display "hi")
<raghavgururajan>Looks like some one was smoking scheme. xD
<raghavgururajan>karthik[m]: Since you asked for a task to get familiar with packaging, can you try packaging gnome-tour?
<karthik[m]>Will try
<raghavgururajan>karthik[m]: The contributing section ( of manual might be helpful. Mainly this sub-section packaging-guidelines (
<karthik[m]>raghavgururajan: just, curious what's the file extension of a guix package?
<mdevos>Hi guix
<mbakke>civodul: you have two 2021's in the copyright line of gnu/ :)
<mbakke>hi mdevos o/
<mdevos>Anyone interested in two new linters? --> two fresh patches on guix-patches
<lfam>I wonder if we can make (replace 'check ...) just do the right thing, rather than requiring (when tests? ...)
<mdevos>lfam: possible, but that would require special-casing 'check
<mdevos>afaik, all phases are treated the same
<lfam>It might be worth it. I always thought it was a subtle bug that (replace 'check) didn't respect #:tests? #f
<lfam>Or maybe there is some other way to approach this that improves the situation without requiring extra boilerplate from packagers
<mdevos>lfam: if you want to special-case 'check, the procedure gnu-build in guix/build/gnu-build-system.scm seems the right place to do it
<mdevos>(replace 'phases' with #{expression for filtering out 'check' if #:tests? is #f}#)
<mdevos>would need to be on core-updated, though
<raghavgururajan>Any java folks around?
<raghavgururajan>Exception in thread "main" java.lang.RuntimeException: Could not create parent directory for lock file /.gradle/wrapper/dists/gradle-5.5-all/66q2j3qadt42ygj9lkubqor18/
<mdevos>raghavgururajan: is that /.gradle/wrapper/..., or /some/directory/.gradle/wrapper?
<mdevos>I don't think the java program has write access to /.gradle
*mdevos not familiar with how gradle works
<leoprikler>there exist both $HOME/.gradle and $PROJECT/.gradle in a typical setup IIRC
<raghavgururajan>That was the exact message.
<iskarian>Is my ~/.guix-profile/lib supposed to be in LIBRARY_PATH, and if so, is it supposed to be first? For some reason gcc (from gcc-toolchain) is pulling crt1.o and crti.o from there
<raghavgururajan>mdevos, leoprikler:
<iskarian>ah, actually, LIBRARY_PATH in my user profile *only* contains ~/.guix-profile/lib
<iskarian>but that doesn't seem relevant: even when I set LIBRARY_PATH= GCC tells me that LIBRARY_PATH contains ~/.guix-profile/lib
<leoprikler>I'm p sure this package is one of many that would call for gradle-build-system
<nckx>leoprikler: Hibernation is 100% supported. Please report bugs!
<nckx>(It's also not a hack at all, unless we disagree on that point...)
<mdevos>raghavgururajan: Could you check what HOME is set to within the build environment?
<mdevos>maybe add a phase after unpack that does (pk 'home (getenv "HOME"))
<mdevos>as according to leoprikler, $HOME/.gradle is ‘typical’
<mbakke>oh, iproute2 is an input of gnutls on core-updates
<leoprikler>nckx: perhaps my memory is just shaky, but if it works, why is it not yet part of Guix?
<nckx>leoprikler: It is.
<leoprikler>Since when?
<nckx>Nov 5 2020. Admittedly not as long as I'd thought, but (like so many) I'd been carrying local patches for $years...
*nckx genuinely surprised it's that new.
<leoprikler>Interesting, guess I should read up on it then
<leoprikler>Seems weird, that it's not documented, though.
<nckx>Nothing about it is Guix-specific, so it would feel weird (to me) to document it in addition to all the Guix-specific things we do document.
<nckx>swapon /dev/stuff; echo disk > /sys/power/state; done
<lfam>Should we add a herd sub-command for it?
<leoprikler>did that on my other machine now, I'll tell you how it went in a few hours
*nckx 's opinion is probably obvious. :)
<leoprikler>herd support would be greatly appreciated
<leoprikler>also integration to gnome
<nckx>‘The purpose of an init system is to pointlessly brand® the shutdown experience™ with pointless aliases.’
<lfam>There should be something more than echo-ing to sysfs
<nckx>leoprikler: What needs to be integrated? That shouldn't be too hard.
<lfam>We have some integration for sddm (found in the manual)
<lfam>That's for reboot and halt
<nckx>My question was genuine.
<leoprikler>IIRC there's a gnome shell extension, that adds a suspend/hibernate button
<leoprikler>we ought to ensure, that this hibernate button works
<nckx>Why don't GNOME/SDDM use the standard interface, or call a dbus thingamajig that uses the standard interface?
<nckx>leoprikler: Of course. What needs to be done?
<leoprikler>I'm not sure, what you call "the standard interface" here.
<nckx>Well, the only interface.
<leoprikler>sysfs needs root, you don't get that in a GUI
<leoprikler>that's why branded shutdown commands exist in the first place
<nckx>* No.
<leoprikler>I just typed this on my other machine, sysfs really didn't like not having a sudo tee
<nckx>Of course.
<nckx>That's not the point. The point if that we add a NIH herd subcommand for it (knock yourselves out, seriously), GNOME still won't use it, it will use some dbus thing. Which appears to be upower.
<vivien_>There’s a typo in the guile manual, raise-exception is documented with #:continuable but in reality it’s #:continuable? with a question mark
<lfam>Thanks vivien_. Can you report it in the #guile channel?
<nckx>Hmm. Error org.freedesktop.DBus.Error.UnknownMethod: No such method “Suspend”
<vivien_>lfam, I’m not authorized in #guile, the channel says #guile :Cannot send to nick/channel
<lfam>Huh, weird
<lfam>I'll do it for you then
<nckx>Apparently that dbus method is obsolete. Surely the ‘modern’ way isn't to shell out to systemctl... right? Does anyone using GNOME happen to know how it initiates hibernation?
<lfam>I heard it uses a Javascript API to contact which then proxies your request for hibernation to the device manufacturer, where your hibernation license key is checked
*nckx answers self: ...using loginctl, of course. 🤦
<nckx>I just totally not by accident ‘loginctl hibernate’d my machine. It worked. So this sounds very much like a bug in (our) GNOME (package) if it can't even do that.
<nckx>lfam: Thanks, I hate it.
<lfam>"I wonder if this button works"
<lfam>I just swapped out my macchatobin's fan for a quiet fan. Now I can actually keep working on it
<nckx>leoprikler: Could you confirm that ‘loginctl hibernate’ works, and GNOME's ‘hibernate’ button doesn't?
<lfam>I can't believe anyone would manufacture such a noisy fan
<nckx>(Other combinations are also valid bugs, of course.)
<nckx>Now that I remember loginctl I can only double down on considering ‘herd foobar’ to be actively harmful. Let's standardise, not fragment, mandatory xkcd link, amen.
<lfam>It's a hard argument to make in a distro like Guix :)
*nckx forks Guix to make it standard.
<lfam>Not to mention, whatever Guix does IS the standard ;)
<lfam>All those other distros are holding it wrong
<vagrantc>lfam: i did upgrade a few more apm mustang boards to the latest firmware, although i suspect some of the boards have bad ram
<lfam>Nice vagrantc
<vagrantc>lfam: got some ecc error correction
<lfam>Hm :/
<lfam>At least the ECC works
<lfam>I have a Tianocore / UEFI bootloader installed now. So I think it should be easy to get GRUB working on top of that
<nckx>lfam: You're not wrong and it feels so right.
<vagrantc>lfam: but will try to triage and send you a couple of them sometime
<vagrantc>yeah, tianocore makes it pretty easy
<lfam>I also just learned about these magical wire connectors from 3M:
<lfam>You stick the wires in, squeeze, and a liquid sealant is released that then hardens and seals everything in permanently
<lfam>My day job will love this
<nckx>Oh I used some o' those last week. I wonder if they'll hold up.
<lfam>They better! 3M is like the last great USAmerican company
<vagrantc>too big to fail
<lfam>They actually invent useful things :)
<lfam>The "Command strips" product is amazing
<lfam>I'm being sarcastic. Obviously Uber and Wework are the future of humanity
<nckx>Oh, the humanity.
<lfam>vagrantc: So, is it accurate to assume that "GRUB will work" on tianocore?
<nckx>(Not vagrantc and only IME but) yes, or at least it's not GRUB <-> Tianocore that will break.
<vagrantc>lfam: probably
<lfam>Okay cool
<lfam>Here goes
<vagrantc>lfam: what you'll have fund with is initrd-modules
<vagrantc>lfam: or get to see why i usually use linux-libre-arm64-generic :)
<lfam>Ah, I have to pick the correct modules
<vagrantc>er, fun, not fund. :)
<lfam>That will be a good learning experience for me
<vagrantc>by hand, in the right order
<lfam>The right order???
<vagrantc>and manually resolve dependencies
<lfam>Well I'm going to start with Debian
<vagrantc>don't forget hiddent dependencies :)
<lfam>Once that boots, I'll try with Guix
<lfam>But I'm happy to use Guix on Debian if Guix System is too much work
<vagrantc>i did manage to get the mustang down to only two modules
<lfam>The goal is to get these cores into the build farm ASAP
<vagrantc>who would be crazy enough to run guix on debian?
<vagrantc>fwiw, i did test building 1.3.0rc2 on debian, but nothing really new so will wait till release to do another upload to debian experimental
<vagrantc>what's the syntax for referencing a specific part of info pages? e.g. if i want to reference info:guix ... on guix-daemon ?
<lfam>I've been building the arm64 linux-libre generic source tarballs "by hand" on the build farm central node. That way they offload to a real aarch64 machine instead of randomly selected an emulated builder which can't complete the task quickly enough
<jackhill>lfam: are you this leo?
<lfam>No :)
<jackhill>:) another Leo!
<vagrantc>lfam: i had a good run with linux-libre 5.11.18 ... but 5.12.2 and 5.11.19 don't appear to have successfully seeded the tarballs :/
<lfam>5.11.19 was built earlier today
<vagrantc>or i was too impatient
<vagrantc>apparently impatient :)
<nckx>☆New☆ ‘guix copy: error: failed to connect over SSH to daemon at 'w.x.y.z', socket /var/guix/daemon-socket/socket’
<lfam>5.4 and 5.10 are in progress
<lfam>vagrantc: IIUC there is not yet a linux-libre-arm64-generic package for 5.12
<lfam>(The default linux-libre package is still 5.11)
<lfam>5.4 should be built. 5.10 is in progress
<lfam>I'm trying to have Cuirass "retry" the builds so that the page on will show success, but I can't load the admin interface today for some reason
<nckx>lfam: Make sure you're connecting over HTTPS. If that doesn't fix it, I can try if you post the link.
<lfam>I'm using HTTP over an SSH tunnel to the port
<lfam>But, these are the public links:
<nckx>I'm using a TLS client certificate.
<lfam>This one is still building:
<lfam>I read the instructions for the TLS client certificate. The state of maintenance.git on is too confusing for me to feel confident reconfiguring the system
<lfam>I said this on guix-sysadmin and I hope it gets cleaned up
<lfam>Like, there are always a bunch of uncommitted changes, and I can't tell if it's "safe" to reconfigure based on it
<lfam>It's hard to be disciplined when using Git in this way. I struggle with it for my own Guix Systems too
<lfam>The first step of testing a new Guix installer is to understand and write sensible commit messages for the mess of unstaged and staged changes
<nckx>lfam: You need to reconfigure to create a client cert? I don't remember that at all.
<nckx>lfam: Sysadmins SHOULD su to root and yank the blessed command from root's history with ‘C-r reconfigure’. Anything else is trouble.
<lfam>Looking at 'doc/', setting up the TLS client cert got simpler
<nckx>lfam wait are you saying my current HEAD~4 of ‘f’, ‘f XXX’, ‘fuck’ and ‘XXX’ is not bestest practice
<lfam>I should do it sometimes. The SSH tunnel is unreliable. I have high latency to at all times
<lfam>No, nckx, it's merely better practice
<lfam>Best practice is to only use `git add -u && git commit --amend`
<nckx>‘At least I committed’.
<lfam>Multiple commits are an anti-pattern ;)
<nckx>‘Changes for May’ got it.
<lfam>At the end of the year, you can concatenate each month into an annual commit
<lfam>This keeps things tidy
<nckx>We joke like there isn't some ridiculously successful project out there that does this.
<lfam>I'm shocked to see an ncurses Git repo. I was going to point to ncurses as an example
<lfam>IIRC, historically, they only offered release tarballs, with no development repo available at all
<vagrantc>lfam: yeah, i've been trying to get the regular linux-libre working rather than -arm64-generic, as some packages (e.g. iwd) fail to build on -arm*-generic
<lfam>It fails to build on the wrong kernel? 😭
<lfam>That's "not supposed to happen"
<vagrantc>the pinebook pro should be working with linux-libre@5.10, @5.11 and in theory @5.12 with the patches i pushed yesterday
<vagrantc>lfam: surprise!
<lfam>I always warned people that the Guix build container could not account for the kernel, but I didn't have any examples in mind
<vagrantc>iwd is a pretty straightforward example
<lfam>I guess it makes sense based on the package description: "It optimizes resource utilization by not depending on any external libraries and instead utilizing features provided by the Linux kernel to the maximum extent possible."
<lfam>It's lacking the normal abstraction layer
<vagrantc>the test suites make use of kernel-specific features ... so fail when they aren't present
<civodul>mbakke: oh, wrong conflict resolution maybe?
*civodul tests fix for
<vagrantc>lfam: thanks for getting the linux-libre source tarballs built though, it was a huge help for some of my recent patches
<civodul>apteryx: FWIW i'll be busy all day tomorrow and haven't been able to help on NEWS & co today
<vagrantc>(though my recent commits messages really prove that i should've sent them through review)
<civodul>apteryx: so perhaps Tue or Wed would be more appropriate
<lfam>vagrantc: You're welcome. In the long run we have to stop using "SSH and `pre-inst-env guix build ...`" but for now it works
<lfam>It would be nice to mark certain packages or derivations as requiring "real hardware"
<vagrantc>lfam: oh, i also noticed that the deblob-check is where it tends to time out ... does adding --verbose help ?
<lfam>Even though we don't want to virtualize anything on the build farm, it will be a long time until we can stop doing that
<vagrantc>e.g. produce more incremental output, to reset the timer of build inactivity
<lfam>Maybe, idk
<lfam>It just works when building on real hardware
<vagrantc>it will of course spam the build logs then
<lfam>I don't think that matter
<vagrantc>or even --verbose --verbose
<lfam>Offloading on only uses "real hardware" so it's a handy hack for avoiding the slow emulated builders
<lfam>I've also started cancelling certain evaluations if I know they are going to tie up the emulated builders for no result. Like, for any changes to SBCL stuff
<vagrantc>so some builds are fine on the emulated builders, but some are problematic? otherwise ... would it make sense to not have the emaulated ones at all?
<lfam>The choice is between "having ARM substitutes" and "not having ARM substitutes"
<lfam>We have a grand total of 4 Cortex-A57 cores in the build farm right now
<vagrantc>i thought there was at least one aarch64 builder in service
<lfam>So, we can't really avoid emulation
<lfam>But, lots of things fail to build there
<vagrantc>ok, gotta get you some mustangs :)
<lfam>We are in the process of / trying to buy some newer machines too
<vagrantc>they really made a huge difference for teh reproducible-builds infrastructure
<lfam>Not super impressed by the companies involved though
<lfam>It's not that easy to actually buy anything
<lfam>The Avantek / Altra store is offline now, which is a bad sign
<lfam>And even ARM themself can't access these machines from what I've gathered
<cbaines>I'm hoping the Honeycomb I ordered will ship soon, last I heard was the first week of May
<lfam>Maybe the Mustangs are the best option in the short-term. Which would be an indictment of the entire ARM64 ecosystem, IMO
<drakonis>what's new in 1.3.0?
<lfam>It's easy to forget that there is a global pandemic in the USA these days. It's understandable that things are difficult now
<drakonis>oh, the NEWS file has been updated
<nckx>Shoots, too later.
<cbaines>What are the Mustangs?
<drakonis>it hadnt been up to date when i had last checked
<lfam>drakonis: A lot of long-standing annoyances have been fixes
<drakonis>this i gotta hear
<lfam>"Substitute installation has been optimized" is a major one
<drakonis>and y'all beat nix to the ipfs punch
<drakonis>oh my.
<drakonis>guix substitutes and narinfo
<drakonis>how interesting.
<lfam>A lot of important security fixes
<lfam>New translations
<drakonis>the new/updated packages counter isnt here
<lfam>cbaines: The Mustang is an older aarch64 workstation:
<drakonis>will it only get added it once the release is ready?
<lfam>All this stuff is already deployed on the master branch. So, if you've done `guix pull`, you have it
<drakonis>of course.
<drakonis>i'm aware of how it works
<lfam>It doesn't use a standard ARM design (i.e. a "Cortex" design)
<lfam>Oh, sorry drakonis. I didn't understand your question
<drakonis>1.3.0 isn't officially out, its still in the rc phases, is that why the NEWS file isnt updated with the number of new packages and updated packages?
<cbaines>lfam, thanks for the info :)
<admas>Does anyone know why I am getting a file not found error when requiring use-package in emacs when package and emacs installed in GNU Guix?
<drakonis>new services and noteworthy updates isnt in it either
<lfam>A few minutes ago civodul said that they hadn't been able to work on NEWS today. So maybe it's coming
<drakonis>oh i see i see
<drakonis>i suppose i missed that
<drakonis>welp, i'm ready to swap back to it
<drakonis>now that i'm in no rush to keep everything stable on my machine
<admas>The package is .guix-profile/share/emacs/site-lisp and this path is in load-path
<drakonis>and now that its time for 1.4.0 to begin, can't wait for guix home to get merged in
<lfam>I'm not sure I understand your question admas
<lfam>We'll have a lot of work to do after the release, between features like `guix home` and doing the core-updates cycle
<lfam>drakonis ^
<drakonis>of course.
<lfam>A busy summer!
<drakonis>its a significant feature
<civodul>drakonis: there are NEWS updates in the 'version-1.3.0' branch but it's incomplete
<rekado>lfam: turns out the poorly trained MDC spam filter ate the reply from SolidRun…
<drakonis>yeah, i've checked it out
<drakonis>i was wondering why it was incomplete
<civodul>lfam: when testing on Debian, did you try running 'guix pull' after the install?
<admas>@lfam, I am unable to require emacs packages in emacs config when installed with Guix system
<lfam>rekado: Gah
<lfam>At least you found it
<lfam>civodul: Yes, I did `guix package -m manifest.scm && guix pull && systemctl restart guix-daemon && guix package -u .` It worked well
<drakonis>i wonder whether guix home addresses the separation between user and system services in the same way home-manager does
<drakonis>which is not at all
<lfam>Any Emacs wizards around that can help admas?
<drakonis>all services had to be written with users in mind and that had some weird annoyances
<civodul>lfam: cool; do you know how many commits are authenticated on the first pull?
<civodul>there's a message that says that
<lfam>civodul: I can try it again and check if you like. I didn't notice
<civodul>that'd be great
<lfam>Alright it will take 5 or 10 minutes
<civodul>(should be 100s, not 17,000 or so)
<lfam>Anything else you'd like me to check?
<civodul>no, thanks :-)
<civodul>sorry for asking, i thought you might have it handy in a terminal
<lfam>No worries
<lfam>I'm around today and tomorrow to help
<rekado>…and I just tried paying for three Honeycomb boards again — and it worked this time.
<lfam>I told you that Paypal would inscrutable allow your purchase eventually
<lfam>I hope you meant for it to work :)
<rekado>yeah, I considered the possibility that it might work if I tried now.
<rekado>bit of a shock
<lfam>This exact same kind of thing happened to me recently when I had to update my bank details on my paypal account. An account that I opened more than 15 years ago
<lfam>Paypal is mysterious and extremely risk-averse
<lfam>They must have to contend with an absolute torrent of fraud attempts
<lfam>civodul: It authenticates "commits 9edb3f6 to 80c091e (889 new commits)"
<leoprikler>nckx: IIUC, GNOME should use the loginctl method
<nckx>leoprikler: Do you use GNOME? (I don't, and setting it up just to test this is a bit much.)
<drakonis>there's no cc symlink by default, right?
<lfam>Right drakonis
<drakonis>i see.
<leoprikler>Judging from the boot messages, the manual method did not seem to work
<drakonis>so i have to add it by myself then?
<lfam>drakonis: It's in a package definition?
<drakonis>hmm, right, i need to install gcc first
<nckx>leoprikler: Did you boot with resume=/dev/ice?
<drakonis>doing some ocaml stuff here and i need to use opam
<leoprikler>I booted with whatever Guix gives me as standard
<drakonis>dying to do something different after two whole years of nonstop nixos
<leoprikler>This brings me back to aforementioned lack of documentation
<leoprikler>and now I don't have any swap
<nckx>mkswap, swapon.
<drakonis>oh yeah, what else is coming up for 1.4.0?
<drakonis>all the work that ambrevar was doing a while back?
<jbv1[m]>Hi guix ! I think I finally managed to package julia 1.6.1, I am not used to work with git and email do you have some pointers I could read to submit my patch ?
<drakonis>or is that still not ready?
<leoprikler>why should I mkswap?
<leoprikler>and swapon failed
<nckx>leoprikler: ...did you mkswap?
<leoprikler>Why should I mkswap outside of installing the distro?
<drakonis>do you have a swap file or a swap partition?
<drakonis>or a zram device?
<leoprikler>I have a swap partition setup, but it's not found on boot
<lfam>jbv1[m]: If you aren't comfortable with Git, just send whatever files you made as an email attachment to <> and mention that you don't know how to use Git yet. The reviewer will clean it up for you
<civodul>lfam: excellent, thanks!
<jbv1[m]>thanks will do, I am used to git but not via email ;à
<drakonis>hmm, have you tried pointing to its uuid?
<nckx>leoprikler: That question does not make sense. mkswap to create a swap ‘file system’ on the device, so you can swapiton, or don't.
<lfam>jbv1[m]: If you do know how to use Git, read the instructions here: <>
<nckx>drakonis: It's none of that, the swap device is fine, it just needs to be formatted.
<lfam>If it's too annoying to set up `git send-email`, just use `git format-patch` to create patch files and send them as an attachment
<nckx>They wrote a hibernation image to it.
<drakonis>hmm, i see.
<leoprikler>which did not get restored, mind you
<lfam>jbv1[m]: The important thing is to send your code. It's not very important how you send it
<jbv1[m]>ok nice will do !
<lfam>jbv1[m]: For example, `git format-patch origin/master --stdout > julia.patch`
<jbv1[m]>it's sent ! looking forward for feedback
<jbv1[m]>cya !
<leoprikler>manually resuming worked out somehow, but UX=1/10
<nckx>leoprikler: I think the basic steps to go from zero to hibernation hero are (1) add your swap device as ‘resume=/dev/swap0’ to your kernel-arguments (2) reboot. You could add that to the manual somewhere. I'm a bit nervous about it: the possibility for data loss is real.
<nckx>Adding resume=<first swap device> by default is... risky. I don't remember off-hand which heuristic the kernel uses (I use my own fork), and it could easily suspend to a different partition instead.