IRC channel logs


back to list of logs

<rekado_>M6piz7wk[m]: please only respond when you have something helpful to contribute
<M6piz7wk[m]>how is that not helpful
<rekado_>asto: are you sure you’re using SDDM or GDM? Gnome is pretty tightly integrated with GDM.
<M6piz7wk[m]>SDDM -> Looks white and stuff
<M6piz7wk[m]>GDM -> Looks gnomey with GTK layout and top left menu that is same as in the gnome desktop
<M6piz7wk[m]>rekado_: you scared him away :p
<zimoun`>apteryx: final fixes about Julia on core-updates-frozen
<apteryx>rekado_: I have /run/current-system/kernel/lib/modules/5.14.21-gnu/kernel/drivers/net/wireguard/wireguard.ko.gz
<rekado_>apteryx: yeah, I made a mistake in my custom kernel
<rekado_>it didn’t pick up the 5.14-arm64.conf, because it’s 5.15
<rekado_>so I’m now passing a variant of (@@ (gnu packages linux) kernel-config) that picks variant “5.14”
<cjtenny>does anyknowe know an example of a package that builds libraries, then loads them from guile? I'm not sure how to safely modify e.g. GUILE_EXTENSIONS_PATH before the guile compilation step
<cjtenny>s/anyknowe/anyone/, yikes, what happneed there
<Toto>Hello guix! I have installed the xf86-video-nouveau package, but "lspci | grep VGA" does not detect my dedicated NVIDIA GeForce 940MX. What should I do to activate? Any ideas?
<rekado_>cjtenny: better ask in #guile
<cjtenny>rekado_: ty, will do. I'm not sure if it was safe, but a simple (setenv) did the trick. Maybe I'll find out at review time O_o
***Myrcies is now known as myrcy
<apteryx>sneek: later tell civodul oops: 8a8e491258 vs fa35a5f649 ^^'
<sneek>Will do.
<M6piz7wk[m]>what's emacs-guix
<M6piz7wk[m]>goodies to make working with guix more efficient?
*M6piz7wk[m] got defeated by school so instead he's working on his emacs for guix things
<M6piz7wk[m]>and why is installing that package break my emacs
<M6piz7wk[m]>nwm just elisp files
*M6piz7wk[m] is reading
<apteryx>more comfy: C-h i m Emacs-Guix RET
<apteryx>(from the Emacs your are setting up)
<M6piz7wk[m]>> If you often work with Guix package files, you may want to see some
<M6piz7wk[m]>highlighting and to have some indentation rules specific for Guix
<M6piz7wk[m]>keywords. There is a minor mode to help
<M6piz7wk[m]>you—M-x guix-devel-mode.
<M6piz7wk[m]>amazing 🌟_🌟
<apteryx>in your .emacs: (add-hook 'scheme-mode-hook #'guix-devel-mode)
<apteryx>also: (add-hook 'scheme-mode-hook #'enable-paredit-mode)
<M6piz7wk[m]>why paredit O.o
<apteryx>takes care of the parens for you
<M6piz7wk[m]>i though geiser is doing the parenthesis management already
<apteryx>lilyp: oh, apologies, it's not inkscape that requires rsvg pixbuf loaders, it's gtk+'s gtk-encode-symbolic-svg
<M6piz7wk[m]>is there a way to make it do these helpful hints
<M6piz7wk[m]>but like for guix things
<apteryx>(and it's to build adwaita-icon-theme)
<apteryx>damn you rust: "However it was abandoned long ago and the only way to build a modern version of rustc is a slightly less modern version. This is exactly how works: it downloads the current beta release of rustc, then uses it to compile the new compiler." (c.f.:
<sam_>it's going to get better soon, possibly, maybe
<sam_>1. mrustc continues
<sam_>2. gcc rust
<apteryx>mrustc, the only existing tool to cleanly bootstrap rust from sources: "Supported target: x86_64" (c.f.:
<apteryx>sam_: gcc rust? is that even a thing
<sam_>the grsecurty people are funding it
<sam_>they do weekly reports iirc
<sam_>also, this isn't so helpful for the security/trust side, but Rust is gaining a libgccjit backend so that it can plug into gcc (but same rustc frontend)
<sam_>thsi will help with bootstrapping for other arches
<apteryx>I wish it was working already
<sam_>me too
<sam_>we have a lot of trouble with it in gentoo
<apteryx>rust is already making a mess of gnome on everything but x86_64
<sam_>lots of arches lack support
<sam_>yeah, librsvg is where it becomes really problematic. and spidermonkey needing rust to build.
<sam_>polkit will soon support duktape which is a tiny JS engine which is something at least
<apteryx>i packaged it recently to help coping with the situation
<sam_>fwiw a lot of people are using that patch in its PR state without too many issues
<apteryx>it's automatically used in place of the mozjs polkit on core-updates-frozen for non-x86_64 arches
<sam_>so i think it's fairly prod ready
<sam_>that's pretty reasonable
<apteryx>I don't get who had the idea to plug a JS engine in a thing such as polkit
<sam_>i know mate
<sam_>i really don't get the need
<sam_>i don't even hate polkit as an idea
<sam_>but needing a full blown JS engine kills it for a lot of uses
<apteryx>gcc-rust looks promising
<apteryx>oh, thank you, adwaita-icon-theme: "PNG versions of the SVG symbolic icons are generated in 16x16, 24x24, 32x32, 48x48, 64x64 and 96x96 sizes if the gtk-encode-symbolic-svg tool is found in $(PREFIX)\bin, and the SVG GDK-Pixbuf loader is properly installed, which is obtained by building GDK-Pixbuf and libRSVG. The PNG versions of the symbolic icons are necessary if your app is a GTK-3.x app and you
<apteryx>are not intending to ship the SVG GDK-Pixbuf loader nor the libRSVG DLL (which are both required otherwise)."
<apteryx>basically, to generate the PNG versions you need librsvg. If you don't intend to ship librsvg, you need the PNGs.
<KE0VVT>Using latest installation image.
<apteryx>how can I specify a particular package output for inputs in the "new style" (core-updates-frozen) ?
<KE0VVT>i3 users: There are certain features I expect, like auto-mounting flash drives. Is there a system declaration that solves this?
<apteryx>you probably just need the mount helper that knows the file system you want (ntfs-3g for example)
<apteryx>you can add them to the 'packages' field of your operating-system declaration
<gn00bie>any recommendations for a guix friendly laptop? I was thinking about MSI Alpha (free from NVIDIA but with an RX6600M)?
<KE0VVT>On IRC over SSH.
<apteryx>anything else than intel is probably going to give you trouble on Guix System if you are looking for a new laptop
<KE0VVT>Would I be able to pay someone to get Guix for POWER9?
<apteryx>what do you mean?
<KE0VVT>apteryx: It is only avail. for x86 and ARM, it looks like.
<apteryx>ah, you mean Guix System
<apteryx>guix the package manager already runs on powerpc64le
<apteryx>(power 9)
<KE0VVT>OMG, Guix has CHIRP! :D :D :D
<mala>so, how can I better understand why certain dependencies are being pulled down? I often get very strange packages being installed even as a result of a single, relatively innocuous-seeming install -- like, I'll end downloading subversion or the cups printing system for a command-line program. I'm curious as to what the closure is that requires these
<jackhill>mala: there's `guix graph --path package1 package2` to see how package1 came to depend on package2
<jackhill>depending on what you're doing you may have to download non-dependency stuf too sometimes such as the dependencies needed to build a profile containing your desired packages, but I don't if subversion or cups are ever needed because of that
<apteryx>10% to go, coverage wise
<apteryx>although #52051 will be a blocker to merge in master
<KE0VVT>master? Not on the main train?
<apteryx>it'll come at some point. for now it's still master
<KE0VVT>(I like saying 'main train'. )
<podiki[m]>Thanks people for the fixes to get wine building (and a lot more of i686 I think), all I had to do was stay away from the computer for the day 😆
<podiki[m]>I have nothing else not building on cuf that I use
<podiki[m]>I'll investigate the weirdness we saw with geeqie tomorrow
<podiki[m]>Unless it was figured out already?
<apteryx>it wasn't
<apteryx>I looked for clues upstream but there are none
<apteryx>perhaps it's just getting behind a bit?
<apteryx>or perhaps we do have a serious issue (other software suggests we do not though)
<podiki[m]>But the issues you noticed was on cuf only?
<apteryx>yes, but our stack is much newer there; so I'm thinking geeqie expects older software
<apteryx>dunno really
<podiki[m]>I'll report here of course if I find anything interesting
<podiki[m]>My guess is something with icons, icon loading, since we had changes/upgrades there too
<apteryx>clutter in geeqie is about gpu acceleration IIRC
<lilyp>apteryx: yeah, replacing rsvg by inkscape is not a great solution by any stretch of the imagination, but it's possible if all else fails
<xelxebar>Is there a complementary operation to the --no-bootloader flag of guix system reconfigure that _only_ installs bootloader stuff?
<apteryx>^C at the right moment
<apteryx>seriously though, I don't think so :-)
<cjtenny>huh, when downloading substitutes only for bluez, why does guix download all the native-inputs for bluez instead of just the inputs?
<cjtenny>I suppose that's a much broader question than just bluez, probably something in the manual I missed. e.g. maybe even if you're not building anything, you still download all the build inputs for reproducibility?
<zimoun`>apteryx: let me know about fixing all Julia stuff on core-updates-frozen :-)
<jbv1[m]>btw thanks zimoun for all the work on julia!!
<zimoun`>jbv1[m], yw! If you are Jean-Baptiste, you did the hard work when upgrading and adding new Pkg features. Thanks! :-)
<abrenon>hello guix
***simendsjo is now known as simendsjo_
<jbv1[m]>ahah thanks!
<simendsjo_>Hi, I'm having a problem with using guix on a foreign distro. When running `guix pull` as a regular user, I get "Updating channel 'guix' from ..", and then `guix pull: error: Git error: malformed URL ''`. Running guix pull as root is working, but then my user won't see these. After running, I get an empty /var/guix/profiles/per-user/simendsjo, but
<simendsjo_>~/.config/guix/current links to a non-existing current-guix file. Running `guix install hello` will install properly and give me a profile, but no current-guix. Setting verbosity and debug flags doesn't give any additional information. Any idea what might be wrong?
<vivien>Hello guix :)
<mothacehe>hey guix!
<vivien>simendsjo_, root and you aren’t using the same channels, maybe there’s a bug in yours
<simendsjo_>vivien: I know, but `guix pull` as my user gives the error. I've tried deleting all guix stuff I've found for the user without any luck.
<vivien>Look in ~/.config/guix/channels.scm
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, apteryx says: oops: 8a8e491258 vs fa35a5f649 ^^'
<vivien>Please excuse my slow typing I’m learning a new keyboard layout
<civodul>apteryx: oh indeed :-)
<simendsjo_>vivien: I've tried without any channels, and with the same channels as root. I get the same issue either way
<vivien>Maybe the system-wide channel (/etc/guix/channel) is broken and only root has a working one ?
<abrenon>vivien: ooh, new layout, cool ! which one are you trying ?
<vivien>sorry, /etc/guix/channels.scm
<simendsjo_>vivien: It doesn't work without any channels.etc either. Without /etc/guix/channels.scm and ~/.config/guix/channels.scm.
<vivien>abrenon, I was impressed with AZERTY afnor so I decided to give bépo a try :)
<abrenon>oh, good, I hope you like it, I find it very convenient
<abrenon>doesn't `guix describe` shows the URL of current channel ?
<abrenon>I wonder how yours could become empty, simendsjo_
<vivien>bépo is a government conspiracy to advance the the ☭ agenda to ☠ people with a fake ☣ spread by ✈
<abrenon>wait what ?! how do you type those with bépo ?!
<abrenon>is there a built-in way to input characters by their codepoint ?!
<vivien>altgr + shift + ^, d, 6, and altgr + ç
<vivien>I have a cheatsheet ^^
<abrenon>yeah I think I know this one U+2660 or something ?
<efraim>♥ is also compose + <, compose + 3
<vivien>altgr + shift + é
<abrenon>but it doesn't work here, there must be another layer involved than just the keyboard layout
<rekado_>cjtenny: Guix only downloads what it needs. In some cases a package will embed references to stuff that’s really not needed at all at runtime. Guix can’t know the difference. It will always get all the things that are referenced.
<abrenon>or there are several bépo layouts ?
<abrenon>I simply use (keyboard-layout (keyboard-layout "fr" "bepo" #:options '("ctrl:swapcaps")))
<abrenon>and none of the above works (I don't know how to setup the compose key)
<vivien>GNOME lists my layout as « French (BEPO, AFNOR) »
<efraim>I set my caps to compose
<efraim>oh this is interesting, in hebrew my right alt is altgr and caps isn't compose, in english right alt is alt and caps is compose
<efraim>I should probably fix that
<vivien>Maybe you have another version, as far as I know bépo existed before afnor
<abrenon>efraim: that sounds confusing, yeah ^^
<vivien>before afnor made its version
<abrenon>hmmm possibly, but I'm not using GNOME, so I don't know if there's a way to use the AFNOR version for all the system in guix ?
<vivien>I don’t know :(
<abrenon>doesn't matter, one day I'll be able to use ibus and then nothing will stop me, I'll be typing emojis all day long
<abrenon>simendsjo_: any progress in finding where the empty git URL comes from ?
<zimoun`>on master, chromium does not support anymore my webcam. Do I miss a trick?
<rekado_>odd, I’m also using an older variant. But that’s probably because my system’s on c-u-f.
<rekado_>(still haven’t rebooted)
<rekado_>I just booted the honeycomb build node into Guix System, started the wireguard service, and cuirass-remote-worker
<rekado_>do I need to do anything else to make it appear on
<rekado_>wireguard IP is
<abrenon>I don't know what happened but fumbling through xfce's keyboard settings was a bad move
<abrenon>it subtly changed the layout, unaffecting my current session, but apparently affecting xlock and I could never log back after locking my screen
<rekado_>abrenon: can you switch to another VT and then kill xlock?
<rekado_>it’s what I used to do for an uncomfortably long time on my Fedora workstation…
<NicholasvonKlitz>Is there a known way to get flatpak and nix packages to properly locate .desktop files? I currently always need to run the from the shell `flatpak run ...` which isn't the best experience.
<zimoun`>what do we do what tryton on core-updates-frozen? Because it is beautiful red block
<zimoun`>mothacehe: how can I filter x86_64 only here ?
<dportnrj[m]>hello guix.
<dportnrj[m]>$ sudo guix system reconfigure /etc/config.scm
<dportnrj[m]>guix system: error: '/gnu/store/...-grub-2.06/sbin/grub-install --no-floppy --target=i386-pc --boot-directory //boot/dev/sda' exited with status 1; output follows:
<dportnrj[m]>Installing for i386-pc platform.
<dportnrj[m]>/gnu/store/...-grub-2.06/sbin/grub-install: error: cannot find a GRUB drive for /dev/sda. Check your
<dportnrj[m]>Why it is i386-pc platform, if installation image was guix-system-install-1.3.9.x86_64-linux.iso?
<dportnrj[m]>And why boot-directory is //boot/dev/sda? Example from inet: sudo grub-install --recheck --no-floppy --root-directory=/ /dev/sda (
<dportnrj[m]>How to fix it?
<rekado_>zimoun: the sanity-check fails here:
<rekado_>there are just two packages that fail directly
<zimoun`>rekado_: thanks. I will try to give a look later if no one beats me. :-)
<rekado_>I don’t know why it’s not finding the module; if the sanity-check is wrong we could just delete it.
<rekado_>dportnrj[m]: i386-pc is correct
<rekado_>that’s not the system architectur
<zimoun`>yeah I think remove sanity-check for these packages is the easiest for now.
<zimoun`>roptat: another beautiful read block on core-updates-frozen about ocaml4.07-* :-)
<rekado_>dportnrj[m]: I don’t know why the boot directory is //boot/dev/sda
<zimoun`>roptat, because camlboot-0.0.0-1.45045d0.drv - timeout for ocaml4.07
<abrenon>rekado_: ahh, thanks for the tip, I didn't think of killing xlock directly (I had already rebooted when I wrote the previous messages)
<mothacehe>zimoun`: you can't directly filter but you can order by system
<zimoun`>mothacehe: thanks. Order by Name and by System :-) Hopefuly I am not lookip at i686 ;-)
<NicholasvonKlitz><NicholasvonKlitz> "Is there a known way to get..." <- I found the solution. Does anyone know why this isn't the default behavior?
<abrenon>help ! someone is asserting that notebooks are a tool for reproducibility, that pinning the versions in requirements.txt is enough to ensure reproducible execution of code
<NinjaTrappeur>0/ In the context of, ekaitz and I are trying to understand how gcc manage to find its libraries from within a guix shell. We came to the conclusion that unlike Nix, Guix is not wrapping GCC but directly ld (via make-ld-wrapper) to resolve the dependencies available in the shell. First of all, are we correct? Is this what's really
<NinjaTrappeur>And of course, could you point us to a direction to perform the same "magic" for lua-jit?
<NinjaTrappeur>civodul: running git-blame on "make-ld-wrapper" is screaming your name :)
<rekado_>mothacehe: the log at /var/log/cuirass-remote-worker.log on my new aarch64 build node is empty. Is there something I can do to test the connection to
<rekado_>maybe some port needs to be opened on my router…?
<mothacehe>rekado_: what's the build node ip on the subnet?
<rekado_>abrenon: version numbers are just a tiny fraction of what one would care about for reproducibility, so it is important to also include deployment in that story. There’s a jupyter kernel for Guix to help with that.
<rekado_>oh, /24? I gave it the wireguard IP
<mothacehe>uh /32 sorry
<abrenon>rekado_: yeah, roptat mentioned it to me
<dportnrj[m]><rekado_> "dportnrj: i386-pc is correct" <- thank you. I'll try to post a bug to issue tracker.
<rekado_>mothacehe: oh, do I need to reconfigure berlin with a new wireguard peer?
<rekado_>dportnrj[m]: thank you
<mothacehe>rekado_: you need to authorize the new host as described here:
<rekado_>ah, thanks for the docs
<mothacehe>then it should be listed when running "sudo wg" on berlin
<mothacehe>and hopefully start building stuff!
<rekado_>I’ll follow the instructions and report back
<jonsger>mothacehe: is there a simple way to get the logging for the remote-worker more verbose?
<mothacehe>i recently added a %debug parameter to make the logging more verbose
<mothacehe>however only cuirass-remote-server uses it for now
<mothacehe>but i plan to add more logs to the cuirass-remote-worker soon
<jonsger>nice :)
*rekado_ reconfigures berlin
<rekado_>hmm, ssh doesn’t connect
<rekado_>I’ve already done port forwarding on my router
<mothacehe> is not listed when running "sudo wg"
<mothacehe>it should be there regardless of the connection status
<rekado_>maybe I should restart wireguard-wg0 on berlin?
<rekado_>okay, it appears now, but says “no route to host”
<rekado_>guess it takes a little while
<mothacehe>looks like i can ping it
<rekado_>yup, ssh works
<mothacehe>ok cuirass can see it too
<mothacehe>it should pick builds if there are any
<rekado_>cool. cool cool cool.
<mothacehe>yup good job :)
<rekado_>the logs say “request work”, “no available build”
<mothacehe>we can restart failing arm builds to see if they are picked up
<mothacehe>great job connecting this new machine btw :)
<rekado_>thanks for pointing me at the docs!
<rekado_>I just restarted this:
<mothacehe>we could add the restart wireguard service instruction
<NinjaTrappeur>unping civodul: we figured out the wrapper blackmagic in the end :)
***smartin1 is now known as smartin
***jpoiret3 is now known as jpoiret
***herlocksholmes5 is now known as herlocksholmes
***dongcarl2 is now known as dongcarl
***brettgilio3 is now known as brettgilio
***gmodena_ is now known as gmodena
***MidAutumnMoon65 is now known as MidAutumnMoon6
***sneek_ is now known as sneek
***stryan_ is now known as stryan
<rekado_>it’s building something now, but it doesn’t yet appear on /workers
<rekado_>I’ll try installing the other nodes today
<mothacehe>the /workers is a bit broken now, i'm rewriting the underlying querying right now
<gyara>Hello everyone, when I run `guix home reconfigure`, package listed in packages are not installed.
<gyara>Is something I missing?
<cbaines>gyara, where are you expecting that they're installed? They should be available in the system profile.
<gyara>But I can list it in my home profile?
<cbaines>Your users profile is different
<gyara>That's fine. Thanks for your help!
<cbaines>There's no inheritance between profiles, but you can mix multiple profiles in your shell/environment
<jpoiret>gyara: if you want to list the packages installed in the system profile, use guix package -p /run/current-system/profile -I
<rekado_>this log doesn’t look right:
<rekado_>restarted a few more aarch64 builds but so far there are no new builds on this node
<apteryx>what do people use to follow the RSS feed of Cuirass? I tried emacs-elfeed, but it doesn't refresh by itself it seems
<mothaceh`>I used GNUS to follow it, worked fine
<apteryx>oh, neat! I had forgotten Gnus had support for RSS.
<mothaceh`>you can also follow the guix-ci gmane feed
<mothaceh`>via GNUS
<attila_lendvai>i'm looking for a complex service example, where complex means that it starts multiple processes, maybe even based on configuration values.
<rekado_>attila_lendvai: nfs is complex
<attila_lendvai>rekado_, yep, looks like it has what i'll need. thanks!
<mothaceh`>rekado_: anything wrong in the new node /var/log/cuirass-remote-worker.log? it is indeed not listed in /workers
<rekado_>there are four lines in that file
<rekado_>2x “Building … derivation.”
<rekado_>2x “Derivation … build succeeded.”
<rekado_>it’s terribly bored right now.
<mothaceh`>ok could you try to restart it (sudo herd restart cuirass-remote-worker)
<mothaceh`>oh i can see it :)
<rekado_>got another two lines now
<rekado_>only two builds at a time?
<rekado_>(don’t know where to tweak that)
<mothaceh`>it depends on the service "workers" parameter
<mothaceh`>the hydra-guix-X are passing workers=4
<apteryx>attila_lendvai: jami-service-type is also complex
<apteryx>spawns its own dbus session
<apteryx>mothaceh`: oh, is back :-)
<mothaceh`>yup just optimized the query by a 900x factor
<mothaceh`>with an index and a query tweak i don't fully understand
<rekado_>hmm, pankow doesn’t appear there
<mothaceh`>no it dissapeared :(
<apteryx>not sure what happened here:
<rekado_>I have ten lines in the log
<mothaceh`>last wg handshake was 12 minutes ago
<mothaceh`>with pankow
<attila_lendvai>apteryx, thanks, noted
<mothaceh`>while its < 1 minute with other wg nodes
<KE0VVT>Time to migrate all my files yet again.
<rekado_>hmm, yes, I see it’s been 14 minutes now
<mothaceh`>oh i think i know why
<mothaceh`>you are missing the keep-alive wireguard field on the pankow side
<rekado_>I copied this from the overdrive config
<mothaceh`>seems to me that overdrive.scm has the keep-alive field
<rekado_>(or do you mean on the berlin config?)
<mothaceh`>in berlin-peer variable
<rekado_>let’s see if I can use guix deploy to upgrade the system…
<rekado_>it’s been too long since I’ve done this…
<apteryx>mothaceh`: I've been meaning to add some wg restarter on remote IP changes too -- I'll get around it eventually
<apteryx>it'll make it much more reliable in cases an IP changes through dyndns for example
<apteryx>but I don't think we have such use case for the build nodes
<KE0VVT>Not used to GNOME 3. Hope 40 comes soon.
<mothaceh`>apteryx: is it really required? i'm not the sure peer IP matters
<KE0VVT>I just thought of something. Unlike other systems, you could cleanly uninstall KDE Plasma or GNOME.
<mothaceh`>it doesn't appear anywhere in the wireguard config at least
<KE0VVT>Noisytoot: Going to try Guix System for a while.
<KE0VVT>It has matured so much that most if not all of my laptop workflow can be reproduced on it.
<raghavgururajan>KE0VVT: +1 on the maturity of guix system. It's my daily driver now-a-days.
<KE0VVT>raghavgururajan: Yeah, I'm thinking of giving it a serious chance now. Rough around the edges, but quite mature and operational.
<raghavgururajan>KE0VVT: Also, performance on SSD is better with Btrfs.
<rekado_>I can SSH to pankow with pubkey auth; running “guix deploy” now.
<rekado_>but I keep getting this error: guix deploy: error: unexpected EOF reading a line
<civodul>rekado_: i'd suggest "strace -f -s 1000" sshd on that host to see what happens
<rekado_>the problem appears when offloading to and .4
<civodul>ah that's on berlin?
<rekado_>I changed the deploy file to (build-locally? #false) and now it’s doing stuff
<KE0VVT>raghavgururajan: I'm on HDD.
<civodul>does "guix offload test" pass for that host?
<raghavgururajan>KE0VVT: You could still opt Btrfs over Ext4. The repair tools of Btrfs comes in handy.
<KE0VVT>raghavgururajan: Too late. Not reinstalling for that. Just installed.
<KE0VVT>And just started migrating homes.
<raghavgururajan>Ah cool.
<civodul>mjw: congrats on the Valgrind release! :-)
<KE0VVT>I'm still really impressed by the graphical installer and the ease of setting up GNOME with disk encryption.
<mjw>civodul, grin. Thanks. funny thing is, it was released last month, we just kind of forgot to announce it... :}
<apteryx>mothaceh`: the keepalives allow refreshing the IPs but that only works while the connection is alive; if the connection is severed and the ip changes (which often happens at the same time for dynamic IPs), then wireguard doesn't recover as it keeps attempting to use the previous IP (it doesn't reattempt to resolve the host name).
<mothaceh`>oh i see, thanks for explaining
<apteryx>the common solution to this shortcoming is adding some cron job/script that checks for ip changes on a hostname and resets the wireguard interface
<apteryx>could be added easily to our wireguard service, I believe
<pingpongdull>can we add sway in guix
<raghavgururajan>pingpongdull: We have sway.
<pingpongdull>can we made it like manjaro-sway
<jpoiret>pingpongdull: what do you mean?
<jpoiret>i believe we have a pretty untouched upstream sway, if anything, it's manjaro's sway that's not standard (although I don't know what it looks like)
***dstolfa_ is now known as dstolfa
***piyo` is now known as piyo
<apteryx>mothaceh`: how do you refresh the RSS feed in Gnus?
<apteryx>oh, the usual way it seems 'G' from the *Groups* buffer.
<mothaceh`>yes I use 'g' in the Group view
<KE0VVT>Okay, how do I run "guix system reconfigure" with updates?
<KE0VVT>I added a user account to config.scm. How does the system know what the user's password is?
<KE0VVT>Wow, this is amazing: # dd if=$(guix system image my-os.scm) of=/dev/sdc status=progress
<apteryx>seems a bunch of k* things are failing to build o core-updates-frozen
<apteryx>also tryton* things
<KE0VVT>apteryx: Porting KDE?
<apteryx>nope; just looking at the Cuirass output (
<apteryx>neat, jami-gnome and jami-qt now build OK on i686-linux on core-updates-frozen
<apteryx>this helps spot the next big broken package to tackle on core-updates-frozen
<apteryx>for i686, that seems to be ghc (haskell)
<zimoun>apteryx, tryton is because new sanity phase and at least deep package is broken.
<apteryx>zimoun: julia was broken on i686, but the log didn't say why (at least that I could understand)
<apteryx>I've restarted the last build
<zimoun>apteryx, BTW I fixed all for x86_64
<zimoun>I am looking for i686
<apteryx>zimoun: yes I saw! I'll merge it after I could test/review it locally, perhaps tonight
<apteryx>well done :-)
<florhizome[m]><KE0VVT> "I just thought of something..." <- Yeah that’s a potential thing :)
<lilyp>mothaceh`: If the OR/AND thing really makes a difference, then it's probably due to shortcutting
<zimoun>apteryx: it rebuilds julia, then rebuild *all* the julia packages… it takes several hours. By several probably full night. :-)
<lilyp>e.g. the first clause already cuts off all negative responses or (due to reordering) the second clause cuts off all >= 2 responses
<apteryx>zimoun: Oh! in this case perhaps upgrading the point release of julia would make sense too
<apteryx>I tried but a new test was failing
<KE0VVT>florhizome[m]: ?
<apteryx>also, does upstream know about the lack of reproducibility?
<apteryx>if not, we should file an issue with them
<apteryx>LLVM at this point should produce reproducible binaries (it does for Rust)
<tricon>Say I need my webserver, which is a service, to have access to a Lua command. Is sub-packaging the web server with a dep on Lua still the best practice? Or should there be a way to define environments for services?
<KE0VVT>Waiting on the computer to add user and keyboard layout.
<rekado_>tricon: shepherd services can be given environment variables, so you could augment the PATH with that of a profile containing lua
<tricon>rekado_: Ah, that is a good idea. I had not thought of that. Thank ya!
<rekado_>(or you could give it specifically the lua package’s bin directory via a gexp)
<tricon>rekado_: Another good idea.
<apteryx>zimoun: julia on i686 seems to be libunwind-julia that fails
<zimoun>apteryx: I think upgrade Julia would probably introduce many failure of julia itself and probably many packages. When now all just work with 1.6.3 ;-)
<mothaceh`>lilyp: yes it makes a drastic difference, would you have some resources describing this shortcutting mecanism? i'm curious to understand these optimizations made out of luck
<lilyp>I don't have any specific resources, but it's the same logic as in C, I suppose
<lilyp>specifically, since you're trying to *limit* the number of results, a chain of ANDs is probably more effective
<mothaceh`>yeah i see but such a difference is strange plus it relies completely on indexes whereas the OR variant ignores them
<patched[m]>Which package is `ssh` in?
<lilyp>probably openssh
<patched[m]>It was quite far down the list when I searched for ssh :^) thanks
<lilyp>there might be other implementations though
<patched[m]>I'm going with openssh-sans-x
<zimoun>apteryx: ouch evaluation 48429 for i686. GHC and Julia.
<zimoun>I never do cross-compil. And I am always confused bt -s vs -t :-) What should I use to debugg Julia on i686 using my x86_64 machine?
<KE0VVT>Still waiting on new user and keyboard to be added.
<apteryx>zimoun: easy: --system=i686-linux
<apteryx>x86_64 supports it natively
<apteryx>(no need for a binfmt registration to go through qemu user emulation)
<apteryx>zimoun: is it so costly building julia packages? I would have thought it's a bit like Python
<apteryx>(e.g., very fast)
<apteryx>in the usual case
<apteryx>but sure, we can stick to 1.6.3. My gut feeling as that not much would break (it's following semantic versioning, right?)
<nckx>Hai Guix.
<nckx>zimoun: --system isn't really cross-compilation, if that helps, it's an emulated native build (…OK that might not help, but it is quite different :). You can't ‘build --system=aarch64-linux’ something on x86 unless you set up QEMU. You can always --target=, which performs a traditional cross-compilation.
<zimoun>apteryx, nckx thanks. Once I read it, it is clear. But each time, I ask. :-)
<KE0VVT>shepherd: Service tor could not be started.
<zimoun>apteryx: about julia-* packages, it is long because… guess what… their test suite. ;-) Most are run sequencial. Here the attempt to improve the situation. :-)
<apteryx>zimoun:; it's a patch release. no API change, just fixes (including in the test suite)
<zimoun>yeah, maybe… but I will not bet that it will work out-of-the-box. And seeing how long it is to debugg some weird or unexpected Julia behavior. Who knows? :-)
<zimoun>For instance “julia -p 1” raises failure by some packages because they do not work with 2 workers. When ’-p 1’ is specificy only one!
<zimoun>Or when JULIA_CPU_THREADS is not really honored. Or when network is set to off when it is available but not as usual (containerized). Etc.
<KE0VVT>Tor won't start after I did "guix system reconfigure"; I did not remove Tor from my system declaration.
<zimoun>apteryx: for instance Maybe it changes nothing, maybe not. :-)
<apteryx>seems like it'd make our life easier by automatically not running thread unsafe tests in parallel?
<apteryx>so you wouldn't need as many parallel-tests? #f if it works
<zimoun>in fact, setting threads “julia -t” raises many errors. And instead, it is “julia -p”
<zimoun>and “julia -p n” starts 1 main and n workers. But “-p 0” fails.
<zimoun>Anyway, to relax waiting compilation, LWN article about Concurrency in Julia. Nice read!
<jbv1[m]>in the future what do you think about having a "parametrized" julia package that compiles a system image with the packages in the profile ? and what form should that take in guix in your opinion ?
<zimoun>jbv1[m]: yeah, we already discussed that, right? And I do not know. This “system image” is not clear for me. :-) Maybe it is a good idea
<jbv1[m]>not with me ;) the system image is a so file that has functions that have already been compiled
<jbv1[m]>since julia is JIT compiled, without a system image just starting the REPL would take ages
<jbv1[m]>so what is done when you build julia is it runs some common functions and records the compilations I think this is called "recording precompile statements" or something like that
<jbv1[m]>and what we could do is when we run the test suite of a package, we can also record the precompile statements then and use them to create a more complete system image
<lilyp>jbv1[m]: with "system image" you mean something like emacs portable dump?
<zimoun>yes, more or less.
<KE0VVT>config.scm <>: herd: failed to start service tor
<jbv1[m]>huh I dont know enough of emacs
<rekado_>just installed the second of three new aarch64 build nodes
<jbv1[m]>thing is making a custom system image is quite slow so that's probably not something that we want to do by default
<rekado_>meanwhile the overdrives are *still* working on building the *source* derivation for linux
<rekado_>it’s *much* faster on the honeycomb boards
<zimoun>yes, Julia system image is more or less emacs dump, from my understanding of both. But I am not sure to well understand both. ;-)
<jbv1[m]>but for some packages, especially the plotting ones it would be nice to have this possibility
<lilyp>jbv1[m]: you could create a package, that just has a bunch of julia packages as inputs and creates a system image for them, no?
<jbv1[m]>if you want to know more, you could look here
<KE0VVT>I can't believe Tor won't start. :-(
<jbv1[m]>lilyp: yes that would work I think but then the user would have to define its own package and inherit from it to change the package selection no ?
<zimoun>jbv1[m], lilyp: it is my understanding of “parametrized” julia, non ?
<lilyp>well, true, but for one we could do so systematically for some selected huge targets and second the user could do so on their own without needing Guix support
<lilyp>further, we don't need to generate an image for each an every package since there's probably a bunch where that doesn't make sense and just wastes time + space
<jbv1[m]>lilyp: I think that would be useful, because you can expect that most users will always be installing some of the common plotting tools, debugger and so
<zimoun>Hum, ./pre-inst-env guix shell -s i686-linux -D -e '(@@ (gnu packages julia) libunwind-julia)' raises an ugly backtrace. Bah, it will work on that later. :-)
<jbv1[m]>and that provides a nice pattern to start from if somebody needs more
<lilyp>jbv1[m]: I'd first create one such "meta-package" similar to how we have guile-studio and then create a "system image" for it
<jbv1[m]>ok I'll think about it when I have some free time
<KE0VVT>tor :(
<tissevert>hi guix
<KE0VVT>I don't know what to do. Tor won't start. I did everything right, I thought.
<drakonis>what's the status of kde on guix right now?
<drakonis>i haven't heard news on it for quite some time
<apteryx>rekado_: woohoo! thanks for all the hard work getting these up and running
<KE0VVT>Noisytoot: Do you use Tor?
<Noisytoot>KE0VVT, Yes.
<Noisytoot>I have (service tor-service-type (tor-configuration (control-socket? #t)))
<Noisytoot>Which enables the control socket.
<zimoun>jbv1[m], lilyp: the issue with julia sysimages is the composition. It is not clear for me. Well, bytecompile Julia is quite fast, the long part is test suite. Therefore, we could build and check the packages by CI; as we do now. Then, installing julia-* packages would create on the fly this sysimages. As jbv1[m] said «I'll think about it when I have some free time» :-)
<zimoun>have a nice week-end!
<KE0VVT>Noisytoot: Thanks, I'll try that.
<apteryx>is someone testing powerpc64le? so far it's a catastrophe:
<apteryx>aarch64 is also a nice red wallpaper:
<apteryx>armhf and i586 must be in a simular situation
***mnhrdt_ is now known as mnhrdt
<zimoun>apteryx, it is art
<zimoun>Maybe we could try to draw a logo ;-)
<apteryx>zimoun: it's Christmas'y
<zimoun>on the other hand, it is not all green with master neither
***rgherdt_ is now known as rgherdt
<zimoun>apteryx I am killing my carbon budget, I am trying to upgrade Julia ;-)
<nckx>Sometime my Shepherd loses track of tor, so the service ‘fails to start’ whilst ‘pgrep tor’ still returns a thing. So I either let it run or kill it (follewed by ‘herd enable tor && herd start tor’) if I need to upgrade it
*nckx finally fixes ‘Dasboard’ jawohl.
<zimoun>apteryx build passes.  Waiting for check.  Keep you in touch.
***{Franciman} is now known as Franciman
<lilyp>zimoun: you mean as in a profile hook?
<cjtenny>rekado_: I thought the point of native-inputs was that they're only needed for building, allowing you to e.g. cross-compile substitutes. Does this mean that guix will always fetch all native-inputs even when substitutes are available?
<KE0VVT>Hm. I have Sway installed, but it does not show up in GDM.
<nckx>cjtenny: No, only if they are needed.
<cjtenny>nckx: I'm confused because installing bluez downloaded all native inputs including e.g. cups, even though no derivations were built, only substitutes were used
<lilyp>there might be a bug in which references to some native input are retained, but chances are it's for some semi-/unrelated thing
<nckx>No, I checked. There are no references retained in bluez to cups. It's probably not related to bluez indeed.
<cjtenny>hm, perhaps there is a non-native-input dependency. libical is the native input that leads to cups, and guix graph -t references shows no path from bluez to cups
<nckx>*inputs aren't relevant to the closure of packages, which is what matters when substituting (and GC'ing etc.)
<cjtenny>*-t references --path
<nckx>Maybe grafts can lead to unintuitive weirdness.
<cjtenny>nckx: inputs aren't relevant meaning... it's computed dynamically from FS references?
<nckx>Which is always a get-out-of-jail-free card when weirdness happens ☺
*cjtenny facepalm
<nckx>cjtenny: Yes.
<KE0VVT>Come on, "guix system reconfigure".
<cjtenny>that doesn't work well for guile FFIs, hah, which is the actual problem I was solving. this was just a curiosity along the way
<lilyp>Grafts feel less like "get out of jail" and more like "get into the mines", though.
<nckx>Only occurrences of /gnu/store/<blah> strings inside other /gnu/store/<foo> directories create a foo → blah reference.
<cjtenny>nckx: those are computed from elf, symlinks, and a few other sources, right?
<nckx>lilyp: It's like that scene in Shawshank Redemption where you fall into the sewer IIRC.
<GNUtoo>Hi, is it possible to create a profile with guix pack ?
<KE0VVT>Seems it's been on “check” phase for quite a while.
<nckx>cjtenny: Those are what lead to strings occurring, but Guix just scans files (and symlinks, which are just files), it does not parse or understand ELF sections etc.
<lilyp>haven't seen it, but from the sound of it it fits
<cjtenny>e.g. (load-foreign-library "libfoo") in a guile package won't create a reference to /gnu/store/<...>-libfoo/lib/ though
<GNUtoo>when using profile-name=<profile name> I've got: guix pack: error: <profile name>: unsupported profile name
<GNUtoo>*--profile-name=<profile name>
<cjtenny>nckx: is there a way to force a reference when defining a package that does e.g. (load-foreign-library some-string) ?
<cjtenny>i'll put the bluez<-->cups curiosity aside for another day :P
<nckx>cjtenny: You'd patch it to load-foreign-library the absolute path, or, if that's not supported (never actually used that), use a wrapper that will set BLAH_LOAD_PATH so it can only load that exact library.
<nckx>Then you get the reference as a side effect.
<cjtenny>nckx: wrapper like (search-paths '(search-path-specfiication...))?
<nckx>You can create a reference simply by writing /gnu/store/foo to a text file in <out> but that's often pointless. Yes, Guix will make sure to download /gnu/store/foo when installing your package. What use does that have if your package doesn't hard-code /gnu/store/foo anywhere else?
<nckx>And if it does, that will incidentally create a reference anyway.
<nckx>The point is that it's automatic.
<nckx>cjtenny: No, as in make-wrapper.
<nckx>* wrap-program, I mean.
*nckx not in Guix context.
<cjtenny>ah, must have missed that section of the manual
<nckx>wrap-program does not seem explicitly documented. It doesn't do anything magical to ‘create a reference’ though. You have to first understand that references are just occurrences of a string, then most else falls into place.
<cjtenny>right, in this case what I'd want is (wrap-program "guile" '("GUILE_EXTENSIONS_PATH" ....), or something.
<singpolyma>Ideally one loads directly. wrap-program is a hack when you don't want to fix the ecosystem to allow that first and they already support an environment variable
<cjtenny>I can't help but feel like this may be an omission in the packaging of guile. Guile has search paths for GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH but not GUILE_EXTENTSIONS_PATH
<singpolyma>I don't know enough about guile to know how hard loading from a path is
<cjtenny>and any library that installs into GUILE_EXTENSIONS_PATH should be findable by (load-foreign-library)
<cjtenny>it's not hard, but it feels like patching directly into the scheme feels wrong compared to using the env var
<singpolyma>cjtenny: search paths are just for when installing packages into a profile, they don't work for dependencies in the general case
<singpolyma>I'm writing a "linker" for ruby to do these replacements so we can hopefully stop pulling in lots of unused stuff by env var
<cjtenny>I should probably catch up on as well
<cjtenny>maybe when rekado_ is back they can comment their opinions on proper use of GUILE_EXTENSIONS_PATH for guix-packaged libraries as well
<Franciman>hi guix, if I want to load my patched driver, how do I tell guix about this?
<KE0VVT>Noisytoot: shepherd: Service tor could not be started.
<apteryx>lilyp: does 'guix-emacs-autoload-packages' works for you to discover a newly installed package? It used to, but perhaps with the subdirectiory entries it doesn't work the same anymore?
<apteryx>GNUtoo: 'guix pack' always create a profile in the pack
<fiesh>is there a preferred way to get certain function keys to control the display brightness? I guess I can hack together something with either xbindkeys or acpid, but of course I'd prefer to learn to correct Guix way if there is one
<podiki[m]>for the new swap syntax, if I had needed-for-boot on a btrfs subvol for swap, should that be replaced by the new swap definition dependencies?
<podiki[m]>same thing different place? or different functionality?
<lilyp>apteryx: it does exactly what it should, which is keeping old emacs as-is, but making newly spawned emacs use new packages
<lilyp>alternatively load subdirs.el
<rekado_>cjtenny: I don’t know about GUILE_EXTENSIONS_PATH. I only know about GUIX_EXTENSIONS_PATH.
<rekado_>the latter is for providing locations for implementations of “guix” sub-commands.
<rekado_>cjtenny: re native-inputs: it doesn’t matter where an input is added — if the outputs keep references to an input that input will be downloaded/installed.
<ngz>Nothing in the code base uses the pinned `asio-1.12' package anymore. Is it fine to remove it ?
<rekado_>when native inputs end up in outputs as references this is often an error.
<rekado_>but we don’t decide what ends up being installed by putting inputs in this or that bucket — the Guix reference scanner decides.
<rekado_>ngz: probably
<rekado_>make sure make as-derivation still works
<ngz>hmmm, make what ? :)
<rekado_>“make as-derivation”
<rekado_>if you’re worried that you might break “guix pull”
<ngz>Oh, that's a make target name.
<ngz>OK, will do before pushing.
<KE0VVT>Hm. (keyboard-layout (keyboard-layout "gb" #:options '("compose:caps")) works in GNOME but not Sway or i3.
<rekado_>it’s “guix pull” but with more letters
<civodul>apteryx: we have gnome -> gjs -> mozjs-78 -> rust, which means gnome is unavailable on i686
<civodul>problem is gjs won't build against mozjs-60
<civodul>what are our options?
<rekado_>“guix deploy” takes a long time, because building the linux source tarball is offloaded to or .4, which both eventually time out.
<rekado_>I’m building the derivation on the target machines now.
<rekado_>not quite how “guix deploy” is supposed to be used ¯\_(ツ)_/¯
<civodul>rekado_: perhaps you need to increase --max-silent-time because i think the tarball build processes spend a long time without writing anything, no?
<rekado_>yes. It’s faster on the new machines. .3 and .4 (overdrive1 and dover) are considerably slower.
<lilyp>civodul: apply duktape as with polkit?
<jackhill>be sad? Why do we have problems with rust on non-x86_64? suggests that it should work on i686, maybe we should open a bug.
<jackhill>and of course, as soon as I get annoyed with the trouble of packaging rust programs, I run into memory-safety crashes with C programs, so I'm leaning heavily into the being sad option :)
<lilyp>jackhill: the mrustc bootstrap thing
<jackhill>hmm, could we corss-build bootrap binaries from x86_64 rustc? The seems better than some things we have in the distribution like GHC, Chez, Chicken, etc.
<jackhill>where we don't have any control over the bootstrap binaries
<KE0VVT>IceCat says another instance is running. I do "killall icecat" but killall says no process found. O_o
<KE0VVT>I'm having a terrible day.
<lilyp>try killall .icecat-real
<lilyp>or pkill icecat
<lilyp>if that still doesn't work, you have a broken lock somewhere
<civodul>jackhill: yeah i figured it's mrustc that fails to build on i686
<KE0VVT>lilyp: Wow! It works! What in the world is ".icecat-real"?
<lilyp>.icecat-real is the "real" icecat program from upstream
<lilyp>icecat is a wrapper around it that sets up essential environment variables
<lilyp>there's a bunch of commands that follow this style
<lilyp>there's even observed sightings of ..command-real-real
<rekado_>(please report those as bugs)
<KE0VVT>This complexity is...
<lilyp>isn't this double-wrapping issue known already?
<lilyp>it's pretty common with glib-or-gtk-build-system for example
<unmatched-paren>i'm trying to package something in rust that depends on rust-anyhow, but even though i have (gnu packages crates-io) imported for some reason it tells me that it's an undefined variable?
<rekado_>KE0VVT: …necessary, sadly.
<rekado_>KE0VVT: it’s the result of using wrap-program. In some cases we can use wrap-script which avoids this extra file by prepending a ployglot header to a script file.
<lilyp>unmatched-paren: the variable is probably rust-anyhow-1
<lilyp>we use semver for rust variable names because that's what upstream forces as well
<unmatched-paren>ok right got it
<unmatched-paren>...and now i shall wait for it to fail spectacularly...rust stuff always has so many dependencies...
<KE0VVT>I am overwhelmed. (service tor-service-type (tor-configuration (control-socket? #t))) should work, according to <>.
<rekado_>KE0VVT: how does it fail?
<rekado_>(I’m only using tor without the control-socket? option)
<KE0VVT>rekado_: shepherd: Service tor could not be started.
<unmatched-paren>aaaaa it needs a later rustc >:(
<rekado_>KE0VVT: I wonder: does /var/run/tor/ exist? If so, is it writable by whatever user this runs as?
<unmatched-paren>is updating rustc a complex procedure? i'm guessing yes :(
<rekado_>could be that this is a regression
<KE0VVT>rekado_: /var/run/tor/ exists.
<KE0VVT>rekado_: I do not know how Guix runs Tor.
<rekado_>neither do I
<unmatched-paren>i suppose it's not as simple as just changing the version number, since it hasn't been done already
<rekado_>KE0VVT: does /var/log/tor.log tell you anything you don’t know already?
<KE0VVT>This is interesting.
<rekado_>according to the source code in (gnu services networking) the tor service creates /var/run/tor and chowns it to the “tor” user.
<KE0VVT>rekado_: There is no "/var/log/tor.log".
<rekado_>that’s what the service said it would log to
<KE0VVT>root@bender /home/caleb# ls -Fla /var/run/tor/
<KE0VVT>total 8
<KE0VVT>drwxr-x--- 2 tor tor 4096 Nov 26 11:11 ./
<rekado_>and nothing in /var/log/messages either?
<KE0VVT>I wonder what "Requires (user-processes loopback syslogd)." is.
<KE0VVT>rekado_: Nov 26 16:39:50 localhost shepherd[1]: Service tor could not be started.
<rekado_>these are other services
<rekado_>shepherd debugging is one of the roughest parts of Guix System… :-/
<rekado_>it doesn’t get nearly as much love as the rest of Guix
<KE0VVT>I feel like such a failure.
<rekado_>take a break
<rekado_>or treat yourself to some success by using just (service tor-service-type) for now.
<rekado_>I’m running into a few problems myself…
<rekado_>I’m using ’guix deploy’ to build the aarch64 systems, and it fails (after building a lot) with this error: while setting up the build environment: a `x86_64-linux' is required to build `/gnu/store/awniiw0r5qji4njhycpv4h3saa7dap6v-activate-service.scm.drv', but I am a `aarch64-linux'
<KE0VVT>My system declaration: