<rekado_>M6piz7wk[m]: please only respond when you have something helpful to contribute <rekado_>asto: are you sure you’re using SDDM or GDM? Gnome is pretty tightly integrated with GDM. <M6piz7wk[m]>GDM -> Looks gnomey with GTK layout and top left menu that is same as in the gnome desktop <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? <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 ^^' *M6piz7wk[m] got defeated by school so instead he's working on his emacs for guix things <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 <apteryx>in your .emacs: (add-hook 'scheme-mode-hook #'guix-devel-mode) <apteryx>also: (add-hook 'scheme-mode-hook #'enable-paredit-mode) <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 <apteryx>(and it's to build adwaita-icon-theme) <sam_>it's going to get better soon, possibly, maybe <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 <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 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>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)? <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? <KE0VVT>apteryx: It is only avail. for x86 and ARM, it looks like. <apteryx>guix the package manager already runs on powerpc64le <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>although #52051 will be a blocker to merge in master <apteryx>it'll come at some point. for now it's still master <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 <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) <apteryx>yes, but our stack is much newer there; so I'm thinking geeqie expects older software <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>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? <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! :-) ***simendsjo is now known as simendsjo_
<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>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 <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 <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 ? <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 + ç <abrenon>yeah I think I know this one U+2660 or something ? <efraim>♥ is also compose + <, compose + 3 <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>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>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 <vivien>Maybe you have another version, as far as I know bépo existed before afnor <abrenon>efraim: that sounds confusing, yeah ^^ <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 ? <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_>I just booted the honeycomb build node into Guix System, started the wireguard service, and cuirass-remote-worker <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. <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]>/gnu/store/...-grub-2.06/sbin/grub-install: error: cannot find a GRUB drive for /dev/sda. Check your device.map. <dportnrj[m]>Why it is i386-pc platform, if installation image was guix-system-install-1.3.9.x86_64-linux.iso? <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. <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 ;-) <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 https://lists.gnu.org/archive/html/help-guix/2021-11/msg00118.html, 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 ci.guix.gnu.org? <rekado_>maybe some port needs to be opened on my router…? <mothacehe>rekado_: what's the build node ip on the 10.0.0.0/24 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 10.0.0.8/32. <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? <mothacehe>then it should be listed when running "sudo wg" on berlin <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 *rekado_ reconfigures berlin <rekado_>I’ve already done port forwarding on my router <mothacehe>10.0.0.8 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_>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 :) <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. <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? <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_>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 <apteryx>oh, neat! I had forgotten Gnus had support for RSS. <attila_lendvai>i'm looking for a complex service example, where complex means that it starts multiple processes, maybe even based on configuration values. <mothaceh`>rekado_: anything wrong in the new node /var/log/cuirass-remote-worker.log? it is indeed not listed in /workers <mothaceh`>ok could you try to restart it (sudo herd restart cuirass-remote-worker) <mothaceh`>it depends on the service "workers" parameter <apteryx>attila_lendvai: jami-service-type is also complex <mothaceh`>yup just optimized the query by a 900x factor <mothaceh`>with an index and a query tweak i don't fully understand <KE0VVT>Time to migrate all my files yet again. <rekado_>hmm, yes, I see it’s been 14 minutes now <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?) <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. <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 10.0.0.3 and .4 <rekado_>I changed the deploy file to (build-locally? #false) and now it’s doing stuff <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. <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). <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 <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. <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>nope; just looking at the Cuirass output (ci.guix.gnu.org) <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>zimoun: yes I saw! I'll merge it after I could test/review it locally, perhaps tonight <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>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) <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]>It was quite far down the list when I searched for ssh :^) thanks <lilyp>there might be other implementations though <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>(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>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>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. :-) <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. <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. <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? <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? <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 <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 <Noisytoot>I have (service tor-service-type (tor-configuration (control-socket? #t))) <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» :-) <KE0VVT>Noisytoot: Thanks, I'll try that. <apteryx>armhf and i586 must be in a simular situation ***mnhrdt_ is now known as mnhrdt
<zimoun>Maybe we could try to draw a logo ;-) ***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.) <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 ☺ <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/libfoo.so though <GNUtoo>when using profile-name=<profile name> I've got: guix pack: error: <profile name>: unsupported 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 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>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_>make sure make as-derivation still works <ngz>hmmm, make what ? :) <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 <rekado_>“guix deploy” takes a long time, because building the linux source tarball is offloaded to 10.0.0.3 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>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 <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 <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: 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>...and now i shall wait for it to fail spectacularly...rust stuff always has so many dependencies... <rekado_>(I’m only using tor without the control-socket? option) <KE0VVT>rekado_: shepherd: Service tor could not be started. <rekado_>KE0VVT: I wonder: does /var/run/tor/ exist? If so, is it writable by whatever user this runs as? <KE0VVT>rekado_: I do not know how Guix runs Tor. <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? <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>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_>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 <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' 