IRC channel logs


back to list of logs

<jlicht>roptat: that will probably be the biggest "tech bro"/HN-crowd pleaser come the 1.4 release!
<roptat>I'd like to improve the output though, because right now everything is interleaved and unreadable
<drakonis>roptat: noiiiiiiiiiice
<singpolyma>jlicht: my source tells me that installing custom software on modern Tesla requires desoldering/flashing/resoldering the eMMC. Unless someone finds an unpatched flaw in the OTA which has not happened yet
<jlicht>singpolyma: A man can dream. Thanks!
<KE0VVT>My config.scm:
<Guest58>is it possible in my config.scm to tell if the config file is being run using system reconfigure or system init or another type of command?
<nckx>Guest58: You are abusing Guix in a way it's not meant to be abused, but I feel morbidly obliged to point out that, yes, you do have access to the ‘(command-line)’ in your file, and it will be that of the evaluating guix command.
<nckx>I feel like I've just told a child where to buy crack.
<KE0VVT>I think I just ran 'guix system reconfigure' on the file I did not edit.
<drakonis>nckx: hahaha
<jackhill>jpoiret: well, the hide/show password in gdm works for me (although it doesn't seem to find the right icon). However, the wayland gdm session is failing to start so it is falling back to x11
<jackhill>show/hide and the icon work on the lock screen
<apteryx>when cuf reaches the coverage of master (41% vs 53%); let's merge? :-)
*vagrantc waves
<podiki[m]>I'm ready!
<podiki[m]>though I think i686 is missing a lot (rust chain never finished?)
<apteryx>there's no rust on i686 (mrustc doesn't yet supports it -- almost but no)
<podiki[m]>I have everything for my system on x86-64 pending a patch I sent and the i686 stuff for wine
<KE0VVT>Hm. When did Guix start using (specification->package "dmenu")?
<podiki[m]>KE0VVT: I like to use that in my system config to not include modules just for a package
<podiki[m]>(for the like 4 i have in there)
<KE0VVT>How do I go about running Syncthing? Do I need to add it to config.scm?
<apteryx>gnutls may need a bigger timeout (it failed during its test suite on aarch64:
<podiki[m]>KE0VVT: add it to your system config as a service
<KE0VVT> (service syncthing-service-type)
<podiki[m]>yes, but with a configuration (there is an example in the manual, I use exactly that with my username and that's it)
<podiki[m]>(or maybe you don't need a username, seems like you do though)
<KE0VVT>podiki[m]: This is what I got: <>.
<podiki[m]>looks right to me
<podiki[m]>then after you do a reconfigure, maybe restart or tell herd to start the service, you will be all set
<KE0VVT>Is there no way to run Tor Browser or OnionShare on Guix?
<KE0VVT>pranavats! :-)
<TheOwlLady>hey everyone I'm sure this is going to sound like a super simple question.
<TheOwlLady>But how do I get SSH working on GuixSD
<TheOwlLady>I install openssh but can't seem to find how to start the daemon
<KE0VVT>TheOwlLady: You probably have to add SSH stuff to your config.scm and do "guix system reconfigure".
<KE0VVT>TheOwlLady: See the SSH stuff in my config at <>.
<podiki[m]>TheOwlLady: this is probably what you want too
<KE0VVT>podiki[m]: For user-installed apps, do you have to reinstall after each system install?
<podiki[m]>not sure what you mean, where you install apps (user profile or system) is just who can access them
<podiki[m]>when you do a system reconfigure that just changes or updates the system profile and services
<podiki[m]>and that is separate from what you have installed as a user, if that's what you mean
<apteryx>TheOwlLady: guix system search openssh
<KE0VVT>I wish I could run VMs so I can test my system before I deploy it to production.
<apteryx>guix system vm your-config.scm?
<KE0VVT>apteryx: I'm on a Libreboot X200. :-(
<apteryx>what does libreboot have to do with it? no kvm?
<dstolfa_>i know this is probably not helpful for guix system, but xen supports virtualization without virt extensions in hardware
<dstolfa_>if you can get xen to run, you can virtualize.
<TheOwlLady>apteryx, I know sshd exists
<TheOwlLady>i take it you don't run it with hurd start sshd though
<apteryx>OK, so you have already configured your system with the openssh-service-type in your services field?
<apteryx>the daemon should then be running from boot
<apteryx>(it will also be started upon 'guix system reconfigure'ing it for the first time
<TheOwlLady>oh shoot, no I did not
<TheOwlLady>thank you for your help, sorry for the simple question
<apteryx>we've all been there, no worries :-)
<jackhill>KE0VVT: our onionshare package works (at least I used it a few months ago). We don't have torbrowser (browsers are hard enough without worring about fingerprinting), but if you download somthing someone has onionshared, torsocks and wget together do work.
<jackhill>*if you need to download
***jackhill is now known as KM4MBG
<fcw>What does it mean when I get lots of "Gtk-CRITICAL **: 10:30:58.558: gtk_drag_source_set_icon_pixbuf: assertion 'site != NULL' failed" messages? Is it possible that I forgot to include a dependency of the package?
<Gooberpatrol66>how does one run thunar as root in guix?
<Gooberpatrol66>this doesn't work: pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $(which thunar)
<apteryx>sudo -E thunar
<Gooberpatrol66>that worked, thanks
<apteryx>happy to help!
***KM4MBG is now known as jackhill
<apteryx>good night/day, guix!
<easbarbosa>hey, i am setting up rails w/ guix environment, and as it compiles a lot of c files
<easbarbosa>then it needs to know where are the runtime libraries in $GUIX_ENVIRONMENT/lib,
<easbarbosa>and dont know how to do it. LD_LIBRARY_PATH wont fix it as gcc-toolchain will complain.
<easbarbosa>thats a direnv file
<easbarbosa>LoadError: Could not open library '.gems/gems/sassc-2.4.0/ext/': cannot open shared objec
<easbarbosa>t file: No such file or directoryp
<easbarbosa>i know about $LIBRARY_PATH, but rails still cant find those
<podiki[m]>easbarbosa: a bit quite in here and I don't have an answer, other than to try guix shell, give it the things you need visible in the profile or a package where you want the inputs (dependencies) available might help
<easbarbosa>sure, let me try
<jane>hello. is there a way to not use a display manager? i am happier with startx
<fiesh>I remember there was some mailing list discussion thread that detailed how to do that, but would need to search for it as well
***unmatched-parent is now known as unmatched-paren
<unmatched-paren>how would i go about packaging something that has two pieces of software that really should be separate in the same git repositary?
<unmatched-paren>the software in question is, which has its (Rust) cli and (C) libraries in the same repositary...
<unmatched-paren>actually it seems like both use a cargo build for building and then a custom invokes cc to create the libraries
<unmatched-paren>but there's no clear separation even though libtree-sitter is useful without tree-sitter-cli
<unmatched-paren>oh looks like there's a makefile in the root for building the lib
<fcw>I am trying to package the Shutter screenshot tool ( I managed to package it to the point where it is able to take screenshots. However, some Gtk-related error messages always appear when I start the program:
<fcw> Does anyone know the cause of these errors?
<Guest58>nckx why shouldnt i use (command-line)
<Guest58>i wanna use it to auto partition my destination drive when using `guix system init` to install guix on a new drive
<Guest58>btw is there a way i can include 3rd party channels in config.scm its a pain running `guix pull` on every fresh installation
<abrenon>hello guix
<fcw>abrenon: Hi, does it make sense to package Quicklisp in Guix?
<abrenon>fcw: uhh I must admit I have absolutely no idea
<abrenon>maybe you mistook me for one of the many people on this chan who are more familiar with lisp ?
<fcw>abrenon: Sorry, that question wasn't specifically directed at you. I meant to ask everyone.
<abrenon>ahhh that's a relief ^^
*abrenon reads about quicklisp
<abrenon>hmm so it's a package manager ?
<fcw>Yes, a package manage for Common Lisp libraries.
<abrenon>what would be the use case ?
<fcw>As of this moment, Guix has about 530 Common Lisp libraries. Quicklisp has 2000+. Just wondering if it makes sense to include Quicklisp in Guix.
<kittyblam>Hadnt heard of this quicklisp tbh
<abrenon>hmmm in that case we'd probably want an importer to be able to reuse those packages directly in guix
<jpoiret>jackhill: yes, i was talking about the icon specifically
<jpoiret>it's very weird, launching the same widget in the same GJS works well
<jpoiret>hello guix by the way
<vivien>Hello guix :)
<kittyblam>yknow, on the topic of lisp
<abrenon>hi jpoiret and vivien
<kittyblam>would be funny someday if something like hurd (but written entirely in a lisp) was made and something like guix was thrown together lmao, the true lisp system
<kittyblam>throw it on a modern lisp machine
<jpoiret>use the sectorlisp implementation :)
<jpoiret>although the problem is that with those ~512 bytes, you can't read a partition to chainload something
<abrenon>fcw: do you think the metadata provided by quicklisp would be enough to generate a guix package definition ?
<civodul>Hello Guix!
<civodul>the 4AM GC process is still running on berlin :-/
<mothacehe>hey civodul! it ran for 24 hours from saturday to sunday before i killed it :(
<mothacehe>the good news is that cuirass managed to build c-u-f
<mothacehe>at least for intel archs
<civodul>mothacehe: howdy! yes, i restarted cuirass-remote-worker on most of the build machines on Sat., apparently it was stuck or something
<civodul>as soon as i had restarted it on a machine, it would start processing new builds
<civodul>re GC, not sure what to do
<civodul>it's currently in the gc-lock-taken phase, so that's not good
<civodul>maybe we could run the optimize pragma or whatever it's called on the sqlite database
<mothacehe>regarding cuirass-remote-worker restart, i have a handy script in /home/mathieu/ that i use like so: "herd restart cuirass-remote-worker"
<mothacehe>but i have no idea of the problem cause
<civodul>good to know :-)
<civodul>to workers send a heartbeat?
<jpoiret>TIL (_ ...) also matches nothing, not just one-or-more things
<civodul>so they were still alive, just not receiving messages or something?
<mothacehe>when the remote-server has no news from them, they are removed from the workers table
<mothacehe>and should not appear anymore in the /workers web page
<civodul>jpoiret: right, ... is zero-or-more, but there's also ..1 for one-or-more
<civodul>mothacehe: in this case they were still listed on /workers, just not taking orders
<civodul>because they were on /workers, i initially thought the problem was elsewhere
<civodul>but restarting the workers definitely solved the issue, the effect was immediately visible
<jpoiret>maybe I should read the manual more carefully next time (:
<mothacehe>ok, i already observed that without taking the time to investigate. Running an strace on a stuck remote-worker should help here.
<civodul>IIRC they were in read(2) or something
<civodul>i didn't investigate further tho
<mothacehe>i've added a %debug parameter on cuirass to have more verbose logging, i'll add a few logs here and there in the remote-worker to help us the next time it happens
<civodul>am i right that gc performance degraded on berlin even though the store didn't grow?
<mothacehe>thanks for restarting them anyways
<mothacehe>yes completely right
<civodul>or maybe it's just that we gc more often because of the core-updates churn?
<mothacehe>we still have around 10TiB available
<mothacehe>but gc used to complete around 8 am (4 hours duration or so)
<civodul>hey zimoun
<mothacehe>hola zimoun
<zimoun>civodul, did you pushed the 70% “deletion unused links”?
<civodul>mothacehe: so that would hint at an unoptimized sqlite database issue
<zimoun>maybe it affects Berlin GC…
<civodul>because that's what it's going right now, browsing the database
<civodul>zimoun: yes it's deployed on berlin but the problem is elsewhere :-)
<mothacehe>oh, i thought we were done investigating sqlite performance issue :p
<zimoun>ouf! :-)
<civodul>maybe we'll have to stop it all for maintenance and try VACUUM? (that's the command we need, right?)
<jlicht>hello guix!
<mothacehe>yes vacuum could help us here, but we would need to stop the guix-daemon and the publish server right?
<cbaines>if this is like it looks, it's probably a problem
<cbaines>cbaines@berlin ~$ ls -lh /var/guix/db/db.sqlite-wal
<cbaines>-rw-r--r-- 1 root root 8.1G Nov 22 10:37 /var/guix/db/db.sqlite-wal
<mothacehe>ush 8 GiB WAL file :(
<sirmacik>looks like I'm not able to use pass otp plugin. I have both pass and pass-otp installed but pass otp show command says that otp is not in store :o
<eonn>I have a quick question- I'm installing the Guix System on a partition cut-out from my other GNU/Linux installation, so I already have GRUB installed on an efi partition. When I go do `guix system init`, should I pass `--no-bootloader`? If so, should I omit the bootloader-configuration section from config.scm entirely? If I want to wipe the other
<eonn>GNU/Linux installation, what is the philosophically sound way to go about telling guix that it's now charge of installing the bootloader?
<jpoiret>if you want to overwrite the other bootloader, do not pass --no-bootloader
<jpoiret>is it an EFI machine?
<eonn>Yes, it's EFI
<jpoiret>if so, Guix will install its own GRUB separately and add an EFI var that points to that GRUB. You'll still have the other Grub on the EFI partition, which you can remove manually if you want to remove your other distribution
<jpoiret>having Guix manage the bootloader is important, as the kernel + initrd are not simply in /boot/, but somewhere in the store, and the easiest way is to let Guix tell GRUB where it is
<eonn>I was thinking Guix would need to manage the bootloader, because of the reproducible nature of the system
<eonn>Should I then create a grub-configuration proper, and then just pass --no-bootloader to prevent overwriting the current installation?
<zimoun>civodul: does Guix compute somewhere SWHID? I do not find something and maybe I am missing it.
<civodul>cbaines, mothacehe: what's your suggestion for this WAL file?
<civodul>ISTR we "did something" in the past about it, but not sure why
*civodul is an eternal newbie
<civodul>zimoun: no, only Disarchive does
<cbaines>I believe you can ask SQLite to perform a checkpoint from SQL
<cbaines>If you use the TRUNCATE argument, the file should be truncated after the checkpoint
<civodul>zimoun: well, that's not quite true: (guix swh) can deal with SWHIDs, but it does not actually "compute" them
<mothacehe>i flushed that stuff from my brain where switching to pgsql but i think the bottom file is that we do not want this file to grow too much
<mothacehe>*when switching
<mothacehe>*bottom line
<cbaines>performing a checkpoint will block writes, but shouldn't require stopping/restarting anything
<civodul>what's "schema." in the doc above?
<zimoun>civodul, thanks.
<civodul>like, what should we type at the sqlite prompt? :-)
<cbaines>civodul, I think schema in SQLite is more like "attached database", so I think you can leave it out, since the database is implicit
<cbaines>you would type this: PRAGMA wal_checkpoint(TRUNCATE);
<civodul>cbaines: heh, thanks :-)
<civodul>so i guess we can try that once gc is over
<civodul>that might take a while tho?
<cbaines>given the WAL is ~1/2 the size of the database, I don't really know...
<cbaines>I'd be quite interested in how much the database grows by, and how long it takes though
<mothacehe>we could copy the database elsewhere and test how much time it requires before proceeding on the real database
<jpoiret>eonn: you'll definitely need the bootloader to be managed by guix if you want to load the system. But since you're on EFI, it's all right, you can just have 2 GRUBs installed in different directories of your efi partition
<jpoiret>unless your other system installs grub in /EFI/Guix/ as well :)
<civodul>mothacehe: yes, good idea
<civodul>mothacehe: do you want/are you able to give it a try?
<jpoiret>and if you want to choose between both systems, just use whatever key your EFI firmware wants you to use to change the boot option
<mothacehe>stopping the ci is not a huge deal but stopping the publish server is
<cbaines>copying SQLite databases can be quite difficult, I've generally found that copies of in use databases are corrupt
<eonn>Well, that solution is a lot nicer than I thought. I was fearful that guix system was going to wipe whatever I pointed at, so very nice. Thank you for the advice
<mothacehe>cbaines: maybe stop the daemon and run the copy to prevent corruptions?
<cbaines>mothacehe, that should work
<mothacehe>civodul: yes i can have a look but not atm :)
<civodul>cbaines: why does it grow this much though? the WAL file is empty on bayfront (surprisingly)
<cbaines>stopping the daemon would stop the GC process though
<cbaines>I'd first probably just try the wal_checkpoint
<jpoiret>jackhill: just saw your mail about gnome-terminal. Can you try launching /gnu/store/xxxxxx-gnome-terminal/libexec/gnome-terminal-server manually?
<mothacehe>in cuirass i tweaked the sqlite parameters to make sure that the wal file didn't grow too much, as it resulted in terrible performances, i could browse the cuirass git history
<civodul>cbaines, mothacehe: yeah, maybe we can just wait for gc completion, and later today we run wal_checkpoint live
<cbaines>civodul, there can be a few factors, I've generally encountered it with long queries that block the automatic checkpointing, or my broken code that kept around live statements
<mothacehe>commit 65e3624bf8356e3a42297a118814b7e4c6d9783c seems interesting
<jlicht>sirmacik: did you try logging out and back in again? Or did you see a message about some environment variable not being set after installing pass?
<eonn>jpoiret: Other quick question: guix system init failed when installing the bootloader- and I realized that /sys/firmware/efi/ didn't exist. However, my system is indeed EFI and the directory exists in my other GNU installation. Do you know how I could troubleshoot this?
<jpoiret>maybe your computer booted in legacy bios mode. You can often disable this option in the EFI firmware prior to booting
<jpoiret>it should boot in EFI mode by default though I reckon, that's weird
<fcw>abrenon: The metadata in and in individual library ASDF files might be enough to automatically generate package definitions. I have little experience in this area.
<vivien>Would you recommend me to switch my server to core-updates-frozen, or keep it on master in case a new version of the updated static networking service needs to be tested?
<eonn>jpoiret: Ah, you were right. For some reason my firmware was configured to boot in legacy mode. Some fiddling fixed it. Never would've thunk.
<jpoiret>fun fact of the day: the whole GDM interface is not in the gdm project, but in gnome-shell :) i'm liking the gnome project even more every day
<mothacehe>jpoiret: heh, it did drive my crazy when updating to GNOME 40
<jpoiret>i'm trying to find why an icon compiled into the doesn't want to load inside GDM on c-u-f. Now i'm just looking at javascript code using GObject. I think i'm lost :(
<fcw>Hello, I need some advice. I'm packaging a screenshot tool that relies on 20+ Perl libraries that are not yet in Guix. Should I submit patches to add those 20+ libraries before submitting a patch to add the screenshot tool?
<abrenon>fcw: I think the patch can contain all the new libraries at once ? or maybe submit a set of patches, there are regularly series of related patches on the mailing list (like PATCH 1/15, PATCH 2/15)
<abrenon>about quicklisp, what I understand from is that it's rather an initiative for provide an actual repos, following the packaging conventions of ASDF
<mothacehe>jpoiret: i had a missing icon issue that was caused by hicolor-icon-theme not being part of GDM inputs if it can help
<Guest58>how do i get the hash for a pypi package?
<jpoiret>mothacehe: but the GDM package has no GUI components
<fcw>abrenon: I am still having problems with packaging the tool. There are plenty of error messages printed when the tool is run. Perhaps it should be a WIP patch series, so that someone in the future can refer to it?
<jpoiret>everything is handled in gnome-shell
<fcw>Guest58: Use "guix import pypi <package-name>"
<jpoiret>also, I still don't understand what hicolor-icon-theme is :( it's empty, while all the icons I see are compiled as gresources inside the gtk shared library
<abrenon>Guest58: if you imported like fcw suggests it should be there, if it's wrong the error message will tell you the right one, you can attempt to predict it from a copy of the repos with guix hash -rx .
<jpoiret>mothacehe: do you have the same issue on c-u-f? the show password/hide password icon being missing in the GDM login prompt
<abrenon>fcw: I may be wrong because I don't have a lot of experience with guix but I don't think people really do WIP patches
<abrenon>maybe you should try to fix those errors before submitting your patch ?
<Guest58>thanks guys
<fcw>abrenon: Doesn't "guix hash -rx ." differ between the repository and the pypi package, since pypi packages only contain a subset of the files in the repository?
<mothacehe>jpoiret: yes that was this icon missing on c-u-f, I think I fixed it with 129875d648b2c263404e09b90911ca4f68eed554 by adding hicolor-icon-theme, see:
<Guest58>oh wow wtf guix import is awesome
<Guest58>wtf it even displays the lisp code
<jpoiret>mothacehe: I have this very issue on a `guix system vm`
<jpoiret>i think it has to do with profile hooks, maybe if i `guix system reconfigure` inside the vm it will go away
<mothacehe>yes the icon cache might be corrupted / missing somehow ?
<jpoiret>let me reconfigure my current machine, I also have this behaviour on the host
<fcw>abrenon: Regarding the patches, how/where can I get help if the final product is somewhat broken?
<jpoiret>where is the logic for the icon caches? i'll look into it
<jpoiret>the thing is, the gdm UI doesn't even use Gtk widgets directly in the JS code, but rather something in St (St.PasswordEntry). I can't find any references to what that thing is, except some very light documentation in the gjs docs
<mothacehe>jpoiret: you can search for gtk-icon-themes in guix/profiles.scm
<mothacehe>i followed the same debug steps without being able to understand anything on how gjs/shell/gdm interact sadly :(
<jpoiret>the switch to gtk 4 seems to have made it even more of a nightmare
<jpoiret>(the example GJS code given on the official gjs website doesn't even run...)
<ss2>speaking of icon caches. Doesn anyone use qt5ct? And has managed to configure it so that qt5 apps will have icons?
<jpoiret>mothacehe: still the same issue, and i don't have the spinning thing either when i mistype my password (totally did that on purpose)
<civodul>cbaines: interesting; it's curious that we observe the bad WAL behavior on berlin only (AFAIK), there must be something about the workload
<civodul>mothacehe: that Cuirass commit has interesting tricks indeed
<civodul>there's this unused settings.useSQLiteWAL boolean in guix-daemon
<civodul>perhaps we should clear it on berlin?
<civodul>there's also "pragma wal_autocheckpoint = 40000;"
<florhizome[m]>what is a search-path-specification object? Gets referenced in the manual without further clarification
<florhizome[m]>Or: how do I look it up?
<florhizome[m]>guess in the source code...
<abrenon>fcw: good point about guix hash, if the repos contains files which aren't distributed with pip, then hashes are going to differ
<abrenon>about help, I suppose the devel mailing list for guix is a good start, but I don't really get what you mean by "final product"
<Guest58>is it possible to run `guix system init` without installing stuff to the mounted root's /gnu/store?
<Guest58>and only install the desired software on the destination root?
<sirmacik>is anybody here using pass-otp package with success?
<sirmacik>it worked for me before, doesn't work now
<sirmacik>jlicht: I did. many times
<sirmacik>reboots incuded
<sirmacik>at first I've installed pass and pass-otp for my user only
<sirmacik>moved it to global config
<sirmacik>still no change
<jlicht>sirmacik: What does `guix shell --container password-store pass-otp -- pass otp personal/gitlab-otp' give as output you?
<jlicht>(it should complain about personal/gitlab-otp "passfile not found", not "otp is not in the password store")
<sirmacik>passfile not found
<jlicht>sirmacik: and `guix shell password-store pass-otp -- pass otp <some-otp-you-have>`?
<sirmacik>same message
<jlicht>sirmacik: Did you <some-otp-you-have> with an actual otp entry in your password store?
<jlicht>did you *replace
<jlicht>and if you do the same command, but with pass show instead of pass otp?
<sirmacik>oh, I had a typo
<sirmacik>it worked, just started complaining about pinentry stuff missing :D
<sirmacik>so I have something wrong in my env
<jlicht>then there must be something going wrong in your env
<sirmacik>will look into it
<sirmacik>thanks for help with narrowing it down
<abrenon>Guest58: not sure what you mean, stuff in /gnu/store isn't installed, it's just stored there for convenience but notions of "install" only stem from profiles through symlinking
<Guest58>ye but i have a 16gb usb running guix as a backup system and when running `guix system init` it just doesnt go well because it has limited space
<abrenon>if you don't have the space on a destination, I suppose you could connect it to another guix daemon on another machine with the storage
<Guest58>i do have the space on a destination i just dont have the space on the source
<Guest58>which is the live installation system
<Guest58>running on a usb
<Guest58>im trying to build a python package which uses portaudio as a dependency and even tho i did include portaudio in the inputs it gives me this error
<Guest58>OSError: cannot load library '': cannot open shared object file: No such file or directory
<Guest58>oh that doesnt work here oh well
<abrenon>haven't tried that use case but I thought the destination media's storage would be used in that case ?
<Guest58>ye used but guix installs stuff into the source's /gnu/store before installing to the destination
<abrenon>did you get errors due to the USB system's store filling up ?
<abrenon>ah sorry I didn't know that
<Guest58>all g xd
<Guest58>OOSError: cannot load library '': cannot open shared object file: No such file or directoryOSError: cannot load library '': cannot open shared object file: No such file or directory
<abrenon>I wonder how installation from live ISO is even possible, the store must then fit in RAM ? how can that be expected to work in the general case ?
<Guest58>any idea why im getting this even tho i included portaudio in propagated-inputs?
<jlicht>Guest58: Did you run the cow-store step?
<Guest58>no whats that
<jlicht>specifically the line 'herd start cow-store /mnt' in the installation instructions
<florhizome[m]>Seems like guix is installing gdk pixbuf without svg support
<Guest58>uh no i never used that
<jlicht>it should make any additions to the store be written to /mnt/gnu/store, instead of /gnu/store ;)
<Guest58>oh lol
<jlicht>Check, it might really be the sole instruction you missed XD
<florhizome[m]>florhizome[m]: See
<abrenon>Guest58: also, the default installer does all that directly, it's a good entry point to learn the basics and see how it's supposed to be done
<Guest58>anyone knows why im getting that portaudio error :(
<jlicht>Guest58: without some further context, not really, sorry.
<Guest58>sec lemme copy the package definition
<Guest58>when importing it in python i get this error
<Guest58>`Traceback (most recent call last):
<Guest58>  File "<stdin>", line 1, in <module>
<Guest58>  File "/run/current-system/profile/lib/python3.8/site-packages/", line 72, in <module>
<Guest58>    _lib = _ffi.dlopen(_libname)
<Guest58>OSError: cannot load library '': cannot open shared object file: No such file or directory
<jlicht>Guest58: I have to leave, but perhaps you need to patch the sources to refer to directly
<Guest58>that sounds complicated
<Guest58>thanks tho
<jlicht>Have a look at `guix edit python-pymediainfo`, specifically the patch-libmediainfo phase
<jlicht>don't give up so easily, the first steps are always the hardest. There are usually folks available here to help out when you get stuck, and the mailing list is a place to ask for help too
<Guest58>           9 (primitive-load "/gnu/store/bnd59pchdyyrf7s10kkkxj5808l…")
<Guest58>In ice-9/eval.scm:
<Guest58>   191:35 8 (_ #f)
<Guest58>In guix/build/gnu-build-system.scm:
<Guest58>    838:2 7 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
<Guest58>In ice-9/boot-9.scm:
<Guest58>  1736:10 6 (with-exception-handler _ _ #:unwind? _ # _)
<Guest58>In srfi/srfi-1.scm:
<Guest58>   857:16 5 (every1 #<procedure 7ffff0bd7060 at guix/build/gnu-bui…> …)
<Guest58>In guix/build/gnu-build-system.scm:
<Guest58>   847:30 4 (_ _)
<Guest58>In ice-9/eval.scm:
<Guest58>    619:8 3 (_ #(#(#<directory (guile-user) 7ffff1baff00>) (# # …)))
<Guest58>In guix/build/utils.scm:
<Guest58>   735:19 2 (with-atomic-file-replacement "sounddevice/" #)
<Guest58>In unknown file:
<abrenon>Guest58: it's more convenient to post stack traces in dedicated tools like
<abrenon>ah, sorry I had missed the message showing that you knew about it
<abrenon>well, it's helpful for stack traces too : )
<yewscion>Good Morning, Guix!
<Guest58>god damn it lol
<Guest58>i just want that python package installed
<excalamus>good morning, guix
<fcw>Hello, I wonder if anyone knows the meaning of these error messages: I am trying to package the "Shutter" screenshot tool. This is the package definition used:
<civodul>mothacehe: GC lock released \o/
<mothacehe> civodul: wohoo, i'll pause the guix-daemon just a few seconds to copy the sqlite files
<apteryx>hmm, the network manager plugins don't work, right? I guess we need to update those.
<apteryx>or perhaps I just need to reconfigure my system and reboot (user profile updated to core-updates-frozen but haven't reconfigured system yet)
<apteryx>rekado: jami-gnome seems crash happy with the latest webkitgtk indeed; I've opened a ticket to track it here:
<apteryx>not sure it's related to the one you experienced (it'd guess not, webkitgtk is used to render the 'chat view', e.g. the UI for messaging - your crash was on the Media settings page)
<zimoun>Could someone give a look at #51870 (Remove leaves python2-)?
<wigust>hi guix
<vivien>apteryx, I’ve sent a patch in 52009 for resolv.conf not being written, maybe that’s the issue?
<mothacehe>civodul: done, there's an sqlite snapshot at /home/mathieu/db_save_22_11_2021, i've unpaused the daemon.
<mothacehe>i'll try to vacuum it later on
<apteryx>hmm, python-eventlet fails on _proto_tcp = socket.getprotobyname('tcp')\nOSError: protocol not found; on debian that's mediated by installing the 'netbase' package, which installs /etc/protocols
<apteryx>netbase is a debian-specific thing, it seems:
<abrenon>I'm going to follow a MooC which recommends to install a certain number of python library and distributes dataset and I was wondering what the best way to prepare this in guix was
<apteryx>oh, we have net-base too: realpath /run/current-system/etc/protocols -> /gnu/store/zfbbn61ij7w0bl4wbrwi87x5ghqx968c-net-base-5.3/etc/protocols
<abrenon>define a package which propagates the libs, and which only content would be those data (simply copied to the store) ?
<apteryx>so it's probably just a problem for the sanity-check phase of anything using python-evenlet
<apteryx>(because in the build environment such configuration is missing)
<abrenon>there are a couple jupyter notebooks as well, should I perhaps define a package for the data, a package for the notebooks, and then a manifest to group all those packages together inside a profile ?
<abrenon>there are also some environment variables to define, how can they be defined automatically when entering an environment ?
<florhizome[m]><florhizome[m]> "Seems like guix is installing..." <- Oh wow this could be the beginning of uncovering a lot of issues :O
<florhizome[m]>I used gdk pixbuf w/o svg in my packages so far (one that propagates it in the system profile)
<florhizome[m]>many packages just want librsvg but it doesn’t integrate when pixbuf isn’t configured right
<apteryx>vivien: not sure, seems to work now; I guess my openvpn connection had gone stale, had to down & re-up
<apteryx>I'm not in GNOME though
<ekaitz>hey I need some help with cmake, I just sent an email to guix-devel, if anyone is free and wants to help, i'll be here too
<roptat>hi guix!
<vivien>Hi roptat :)
<roptat>abrenon, maybe use guix-jupyter (or jupyter-guix I don't remember)
<roptat>so you can define the notebook environment
<pseudonymous>Hey, is there a more gentle getting started guide for guix ? Specifically, I've managed to install guix on top of Ubuntu, to clone a custom software channel and install emacs and setup my shell's GUIX_PROFILE, but then I'm stuck not knowing how to run what I installed. The handbook goes into rolling a whole system etc.. I just want to get a sense of whether this is worth bothering with. Any shorter reference ?
<abrenon>hi roptat ! thanks for the answer
<roptat>and yeah, that environment would be constructed with packages that contain the libraries and the datasets
<roptat>pseudonymous, congrats on installing guix :)
<roptat>pseudonymous, if you're really in a hurry there's the guix reference card, let me find it for you
<pseudonymous>roptat: ?
<pseudonymous>Heheh :)
<roptat>the cookbook also has a nice entry:
<abrenon>yeah, I'm reading that one
<roptat>the manual talks both about guix on a foreign distro and guix system, and of course guix system is taking a big portion of it because there is so much to explain
<roptat>but don't worry, guix on a foreign distro is a perfectly supported use-case :)
<roptat>pseudonymous, just setting GUIX_PROFILE won't help, you need to source the profile. But I think the installation script does it for you, though you might have to log out and in again for changes to take effect globally
<roptat>or ubuntu is doing something weird with the shell's profile scripts
<abrenon>yeah, I remember seeing a message telling that when I installed guix on devuan
<abrenon>roptat: about guix-jupyter, I'm not sure I understand what it does: wouldn't a "guix kernel" be meant to allow me to write guile code for guix in a notebook ?
<abrenon>I already have a set of notebooks
<roptat>right, it gives you commands to load an environment in the notebook
<abrenon>I have no problem opening them from jupyter's web interface when I spawn one from guix shell
<roptat>you just add a cell at the beginning that creates the environment, and the rest will execute inside it
<abrenon>but wouldn't creating an environment that contains jupyter and the required python-libs work ?
<abrenon>wouldn't that be the recommended way to do it ? After all, that would allow me to keep everything in a simple .scm file
<pseudonymous>roptat: I kind of stumbled trough this: - I note that my GUIX_PROFILE points to one /gnu/store/HASH while the emacs I installed resides in /gnu/store/OTHER-HASH .. can I create a profile from the other store where emacs resides or...? RTFM what.. I guess :D
<abrenon>pseudonymous: your profile contains several links, each pointing to the various pieces of software you've installed
<roptat>pseudonymous, each package resides in a different store path. A profile is a collection of packages, and it also resides in a separate store path, so that's correct
<roptat>oh I wasn't aware of that article, nice :)
<abrenon>so probably, in there, in /gnu/store/.../bin, there is an emacs entry, which you'll find is a symlink to… the actual binary in the store folder with the OTHER-HASH you've noticed
<abrenon>roptat: I don't understand, mustn't I write python code in a cell at the top of a python notebook ?
<abrenon>how could I use that to load packages to an environment ?
<abrenon>I don't know how to do it except from the shell with guix shell or guix environment
<roptat>abrenon, iirc, with the guix kernel, you write guix commands, and one of them loads a different kernel, and the following cells are for that kernel
<roptat>I don't remember too much about it, so I guess you can also just use a guix shell to get your notebook and its dependencies
<pseudonymous>From what I can see, $GUIX_PROFILE ($HOME/.config/guix/current) points to a store whose bin dir only has guix and guix-daemon, not the emacs (and related binaries) of the store where emacs is installed.
<abrenon>ok, I'll try that
<abrenon>thanks for the hint that datasets should be packages as well
<abrenon>I'll try and find an example of environment variable definition from another packages
<roptat>pseudonymous, right, there are two profiles: ~/.config/guix/current and ~/.guix-profile. guix doesn't care about $GUIX_PROFILE, so its value is just the last one that was set and that's ok
<roptat>pseudonymous, the two profiles need to be loaded. ~/.config/guix/current contains your latest guix (the one you got with "guix pull"), and ~/.guix-profile contains the package profile (the one you get with "guix install" and friends)
<roptat>if you remember the article says "GUIX_PROFILE="$HOME/.guix-profile"" and ". "$GUIX_PROFILE/etc/profile"". $GUIX_PROFILE is only used in that second command, never after. So what we do is define that and something similar to also load ~/.config/guix/current
<roptat>if you've logged out and in again, you should check that your $PATH contains ~/.guix-profile
<roptat>~/.guix-profile/bin even
<roptat>as well as ~/.config/guix/current/bin
<roptat>if that's the case, you should be good :)
<florhizome[m]>> <> Oh wow this could be the beginning of uncovering a lot of issues :O
<florhizome[m]>> I used gdk pixbuf w/o svg in my packages so far (one that propagates it in the system profile)
<florhizome[m]>> many packages just want librsvg but it doesn’t integrate when pixbuf isn’t configured right
<florhizome[m]>should I commit sway–borders sometimes, bc it builds now :)
<florhizome[m]>unsure if it fits upstream
<florhizome[m]>it’s a fork of sway doing some eyecandy, for now rounded borders as an option.
<florhizome[m]>I‘ll be damned if that means gala will build now too
<apteryx>I'll share this again while there are more people active in the channel:; in case you had missed it. tl;dr you can use a freely available jami rendezvous point for your video/audio conferencing needs by calling to 'rdv-jami-guix'.
<pseudonymous>roptat: it seems GUIX_PROFILE is indeed respected. Reading the /etc/profile scripts, setting GUIX_PROFILE means running `source ~/.guix-profile/etc/profile` (not sure if correct way) won't take unless GUIX_PROFILE is not even defined.
<jackhill>jpoiret: when trying to run gnome-terminal-server directly, it runs for a little while, and then exits 0. No process call gnome-terminal is left running.
<apteryx>is there a reason to do "socket.getprotobyname('tcp')" (python-dnspython) when it's the default?
<apteryx>it causes problems in the build environment
<roptat>pseudonymous, again, $GUIX_PROFILE is just an implementation detail, you shouldn't have to care about it, just make sure your $PATH is correct
<jackhill>jpoiret: I has the idea to try install gnome-terminal in my user's profile rather that only having it in the system profile, but gnome-terminal (via dconf probably) propogates glib@2.62.6 and I have gstreamer in my profile which propagates glib@2.70.0
<apteryx>it probably needs an update to use glib@2.70
<pinoaffe>hi guix! could someone take a look at ?
<apteryx>the problematic getprotobyname call is at line 69 here
<jackhill>apteryx: yeah, you're probably right, looks like bothe gnome-terminal and dconf could be upgraded. We probably should to get them in line with the rest of gnome on core-updates-frozen, but touching dconf at this stage seems scary!
<zimoun>roptat, ’guix import opam biocaml’ fails but Before investigating, any idea?
<jackhill>jpoiret: also, whith gdm, it works with wayland on a laptop, but not on my primary desktop with 3 monitors and intel graphics. There, it crashes with signal 5 and falls back to x11. I haven't found the debug logs to be that helpful.
<roptat>zimoun, this is an issue: "available: arch != "x86_32" & arch != "arm32""
<roptat>the format is correct for opam, but unexpected for the importer
<jpoiret>jackhill: did you set (debug? #t) in the gdm configuration?
<jpoiret>hmmm. Problem is, we don't get a lot from mutter in that configuration too
<jackhill>I guess I should create a bug and post the log
<jpoiret>tbh, i'm getting pretty sick of all those gnome things, they're a nightmare to debug
<jpoiret>and the architecture is often dubious at best, eg gnome-terminal
<zimoun>roptat: ah. Does it deserve to open a bug report?
<roptat>sure, I'll see what I can do about it...
<roptat>I already tried to fix our grammar, but it's... very tricky
<jackhill>re: nightmare: yes indeed. I'm suspicious that it's a timing issue since this setup seems to take a long time for the monitors to settle. I have to run sway with WLR_DRM_NO_MODIFIERS as well, so I wouldn't be surprised if there was some bug between mutter and my graphics as well
<jackhill>yeah, but I still feel very much aligned with GNOME's goals and don't know where else to find a similar solution. I'm happy with sway, but would like to find something with braod appeal an polish for the other folks who use the computers I manager
<jpoiret>it's true that for an end-user perspective, when it works it's the best linux has to offer
<jpoiret>re: gnome-terminal, I wonder if those requests go through the session or user bus (i think user), and if so, where/how is dbus supposed to find those services?
<jackhill>apteryx: oops, I was looking at the wrong `guix` when I thought dconf and gnome-terminal were older than they should be
<jackhill>jpoiret: and also what changed about how it works between master and core-updates-frozen
<apteryx>jpoiret: they'll be looked in ~/.guix-profile/etc/dbus/* I think; it's hard-coded in the guix system configuration to looke them in the user profile
<apteryx>(as well as system profile I think, but nowhere else)
<apteryx>so it won't work if you're not in your default user profile
<apteryx>that's known as issue 48538
<jackhill>ok, installing gnome-germinal in my user's profile doesn't seem to help
<apteryx>and your system is reconfigured with the matching gnome stack?
<jackhill>apteryx: yes! (I double checked this time)
<jpoiret>hmmm, but user dbus is launched through gnome-shell
<jpoiret>not system dbus
<jackhill>well, this is sway. gnome-terminal works with gnome-shell
<jpoiret>anyways, jackhill's problem wasn't that dbus couldn't find the .service file, otherwise it would've said so... i've got no clue what that gnome-terminal-server error means tho
<jpoiret>sorry, i meant to say gnome-session *
<hiruji>Hi Guix, trying to package something that fetches from github as part of it's build process and getting:
<hiruji>fatal: unable to access '': Could not resolve host:
<hiruji>So it's not really happy with that, are build containers shielded from the network?
<jpoiret>builds run in namespaced environments and isolated from the rest of the system/network/etc
<hiruji>Gotcha. So I package up Cleavir and feed it as input?
<jpoiret>then patch the build script so that it uses the input instead
<hiruji>It's gonna be a bit hairy removing out all those calls to git, but I guess I'll do it
<hiruji>Better this way anyways
<abrenon>it was hairy to put them in first : )
<jpoiret>jackhill: i can't seem to find the exact issue you had with gnome-terminal, would you mind reposting it?
<abrenon>if I understand correctly, search-paths will allow to customize some variable with the meaning of being a PATH for some language or interpreter
<abrenon>but I can't find the standard way for a package to declare a set of variables to set when that package is installed in an environment, is there such a thing ?
<jlicht>abrenon: native-search-paths might be what you are looking for, there should be many examples in existing packages
<abrenon>yeah I've found those but I don't understand why it would expect a list and what the "search-path-specification" function at the top could be
*apteryx shamelessly patches out getprotobyname calls in python-pythondns
*abrenon is reading guix/search-paths.scm
<abrenon>thanks jlicht !
<jlicht>abrenon: why a list: because you can have many of such things ;)
<jlicht>abrenon: and search-path-specification is a record constructor, similar to package in (package (name "...") ...)
<abrenon>that makes sense now ! : )
<roptat>I noticed yesterday it wasn't documented
<jpoiret>jackhill: looks like gnome-terminal-server wants to open a gui itself, so it wants the WAYLAND/Xorg env vars
<rekado>apteryx: I worked on eventlet recently. You can sometimes get around this problem with (setenv "EVENTLET_NO_GREENDNS" "yes").
<jpoiret>can you try WAYLAND_DISPLAY=1 dbus-run-session sway
<jpoiret>WAYLAND_DISPLAY=wayland-1 *
<pseudonymous>OMG. So... I still don't know half of what is done. But I respect the results. I got guix, got someone's custom channel, installed a bleeding edge copy of emacs with nativecomp and pgtk and... it's simply beautiful. If I understand right, guix allows sandboxing of apps and their dependencies right ? Seems like a quantum leap compared to the messy state of distribution packaging today.
<jpoiret>if this works then we'll need to think a bit about how to approach dbus-update-activation-environment sanely
<rekado>“sandboxing” — not in the security sense
<jackhill>jpoiret: `WAYLAND_DISPLAY=wayland-1 dbus-run-session sway` doesn't allow sway to start: Could not connect to remote display: No such file or directory
<pseudonymous>rekado: ah, no. Yea, just.. isolate the dependencies of one app from another.
<jpoiret>rekado: `guix shell --container` begs to differ :)
<rekado>pseudonymous: it installs every package to its own prefix directory, so you can’t accidentally install different things into the same location. This avoids a lot of conflicts and problems you would have in a traditional distro — and it adds a couple of its own problems, too :)
<jpoiret>jackhill: ah, sorry, then please try instead inside of the sway session, `dbus-update-activation-environment WAYLAND_DISPLAY` then retry gnome-terminal
<pseudonymous>rekado: compared to the castastrophe that is general distro packaging, I'll take it(!) :D
<rekado>pseudonymous: building things is also done in complete isolation, which is great.
<jackhill>jpoiret: that worked!
<rekado>but eventually we always hit reality when “installing” (= symlinking) things into the same profile.
<rekado>that’s where the wave function collapses and you can only really have one variant of each package
<rekado>(a way around it is to use separate profifles then, easy!)
<rekado>pinoaffe: this looks good to me. I’ll apply it in a moment.
<jpoiret>so, the idea is that gnome-terminal doesn't do anything on its own, it just asks DBus to communicate with org.gnome.Terminal. However, it isn't started yet, so DBus proceeds to start it. The problem is, dbus didn't have any of the needed env variables for it to launch anything graphically, and so gnome-terminal-server just couldn't properly start
<jackhill>in other news, the manpage for dbus-update-activation-environment seems wird to me. It has a bunch of .SH .HP .PP markers, like all the markup didn't get rendered to completion
<jpoiret>mhmmm, great
<apteryx>rekado: the 'update' yasnippet template seems unwieldy on core-updates-frozen; I'm guessing due to changes as to how packages can now be defined (guix style) ?
<apteryx>(great tool by the way!)
<jpoiret>I think a generic thing to tell people would be to run `dbus-update-activation-environment WAYLAND_DISPLAY/DISPLAY` inside their WM config
<abrenon>see you
<jackhill>jpoiret: ah, I see, thanks. Yes that sounds reasonable
<roptat>zimoun, in your utop patches, please add a ocaml4.07-variant property to each package you add with such a variant
<jpoiret>dbus: "i am a standalone program, totally not a systemd underling"
<jpoiret>also dbus: "i have a --systemd option to also update systemd --user env variables"
<roptat>zimoun, also have you checked whether (package-with-ocaml4.07 the-package) works for the packages you added, instead of adding the variant?
<rekado>apteryx: not only on core-updates-frozen; since a while it sometimes just picks the wrong package name. Odd.
<rekado>apteryx: we have etc/committer.scm, so maybe we could remove the snippets and call out to parts of etc/committer.scm instead?
<rekado>bah, I can’t push any more: git/bindings.scm:66:8: In procedure git_libgit2_init: Function not implemented
<Guest58>does guix package --install-from-file actually install the package and the binaries in it?
<Guest58>cuz i did run it and i didnt get the binaries lol
<rekado>vtk-8 is broken. There are a lot of “undefined reference” errors — they all point to symbols defined by the vtk libraries, so perhaps it’s just a matter of adding some directory to the linker invocation.
<rekado>Guest58: it does, yes.
<zimoun>roptat, for ocaml4.07-variant, yeah for sure. I miss the ’properties’.
<rekado>(vtk-8 is needed for freecad)
<zimoun>roptat: for the variant, I did not want to upgrade ocaml4.07- to avoid breakage.
<zimoun>but, yeah, let me try.
<Guest58>not a single package i imported from pypi using `guix import pypi` worked lmao
<Guest58>the only thing it gave me is headache
<rekado>what do you mean by “work”?
<apteryx>rekado: perhaps 'rm guile && ./configure ... && make'
<rekado>it is expected that the importers are only as good as the metadata provided.
<rekado>with pypi that’s usually pretty mediocre
<Guest58>literally nothing installs
<rekado>“import” never installs anyhing
<Guest58>i get an error on every package i attempt to install
<Guest58>i know
<rekado>also note that you may need “--recursive”
<rekado>because the importer will not automatically import missing inputs
<rekado>apteryx: worked around it with a new pure env
<apteryx>rekado: re etc/committer.scm I don't know, I've yet to try it :-) but sounds promising
<rekado>apteryx: it’s better! It looks at the diff, finds the changed s-exps and then works on that.
<pinoaffe>rekado: sweet, thanks!
<rekado>the yasnippts are much less powerful
<rekado>etc/committer.scm also adds changelog lines for changed inputs
<rekado>(and this may have to be updated with the advent of “guix style”)
<odd>does anyone here know how i can get rust-src installed from the guix rust package?
<odd>i need rust-src in order for rust-analyzer to work
<apteryx>this has been asked before
<odd>how do i fix it?
<apteryx>I'm not sure if the person who had asked the question is around, perhaps has a solution?
<kitzman>hm. anyone else having trouble building weston?
<apteryx>odd: I don't know, but you could possibly workaround manually by extracting the rust sources somewhere and point the tool to it?
<apteryx>guix build -S rust
<apteryx>to get the sources
<mmmmm_coffee>hi does the installer check whether there is enough free space on a device? i dont get any warnings but at some point it just says that there's not enough space gives me an error
<sneek>mmmmm_coffee, you have 1 message!
<sneek>mmmmm_coffee, nalaginrut says: Thanks for telling me about formlet, I've printed the paper and been researching it. It looks a nice thing, I'll put it in TODO
<odd>hmm ok, i'll give it a shot
<roptat>zimoun, thanks!
<vivien>rekado, you mean right
<vivien>Oh no
<rekado>it’s a quirk of the xapian indexer
<vivien>My issues 51948 and 52009 do not appear :(
<vivien>Oh sorry 52009 does
<roptat>so I switched to core-update-frozen. python-codacy-coverage is failing for me, in the sanity-check phase. What should I do?
<apteryx>fixed locally
<rekado>is it a false positive? If so: remove the phase.
<apteryx>roptat: I'll push shortly
<roptat>apteryx, oh thanks
<roptat>what's the usual solution to this kind of issue?
*rekado checks if has some packages that still need fixing
<apteryx>roptat: adding the missing input in this case
<rekado>vivien: 51948 didn’t mention core-updates-frozen in the subject(s)
<vivien>Yes that’s my fault :(
<rekado>vivien: when you retitle the bug it will appear
<vivien>How do I do that?
<rekado>vivien: I noticed something about your commit messages (such as the one in 52009). You don’t need to repeat the file name on every line.
<rekado>in this case “* gnu/packages/dns.scm (openresolv)” only needs to appear once. Also: no space after the closing paren.
<rekado>vivien: there’s an email command to be sent to the control address
<rekado>I don’t recall
<rekado><nckx> [17:16:55] kaelyn: Send ‘retitle NUMBER The new subject line’ as the body to control at debbugs dot gnu dot org.
<apteryx>rekado: recent changes to the GNU changelog disagree (they put spaces between each [ ] ( ) < >'d items)
<apteryx>but I don't mind much
<apteryx>roptat: pushed with 318b9f19b7
<roptat>apteryx, great, thanks!
<vivien>I wish magit supported changelog-style git commits
<rekado>oh. “recent” you say…?
<apteryx>they do, press C
<apteryx>rekado: I'm not sure, but it wasn't like this when I first read it in 2016, else I'd have pointed that inconsistency ;-)
<apteryx>vivien: C on a hunk in a COMMIT buffer in magit adds a changelog entry; it's not perfect but it helps nonetheless
<vivien>I was looking for that for ages
<vivien>Thank you so much
<apteryx>haha, np
<apteryx>I had that feeling when I learnt I could do proper copy/paste in xterm
<vivien>rekado, thank you for the command.
<podiki[m]>oo nice tip
<zimoun>roptat, done in v2. :-)
<roptat>zimoun, great, I'll have a look tonight
<jpoiret>is anyone running on master right now?
***unmatched-parent is now known as unmatched-paren
<jpoiret>if so, can you check if `grep eye-not-looking /run/current-system/profile/share/icons/hicolor/icon-theme.cache` gives you a match or not?
<vivien>jpoiret, no line
<jpoiret>are you using gdm?
<vivien>That’s my server, technically it’s using gdm but the mesa is so old the screen is just frozen
<jackhill>I confirm that there is no line on relatively-recent master with gdm
<vivien>jpoiret, the virtual keyboard on gdm also lacks icons
<vivien>for enter, control, shift and another modifier I can’t identify
<vivien>(it’s right shift)
<vivien>I’m not sure that’s related to what you’re investigating
<jpoiret>i mean, icons in gdm are my new hobby
<unmatched-paren>tree-sitter looks like it'll be a pain to build :(
<unmatched-paren>it's a dependency for the latest version of neovim, which i really really really need
<unmatched-paren>it has a C library and rust CLI
<unmatched-paren>and rust bindings, which should be seperate from libtree-sitter, right?
<unmatched-paren>but for some reason the builds them both at the same time
<unmatched-paren>no cmake/meson/autoconf, just an ugly makefile
<jgart>unmatched-paren, maybe the nix package would give some clues:
<jgart>I want tree-sitter also for helix editor
<unmatched-paren>i can see why people like scheme better than nix :/
<unmatched-paren>*some people
<jgart>but I also need rust 2021 edition 1.56.0
<jgart>in order to build helix
<podiki[m]>is rust 1.56 in c-u-f or only 1.54 or something?
<podiki[m]>well that's only 0.02 away, that's pretty close
<apteryx>I've added in code... building it
<unmatched-paren>helix/kak look like neat editors, but i have a lot of plugins in nvim that i don't really want to give up
<jgart>alot of the third party plugins that one would want that come with vim just come "out of the box" with helix
<jgart>I think the biggest cognitive dissonance is learning different bindings froms standard vim/vi
<unmatched-paren>i'll try it once latest rust is added
<jgart>If I can get lsp and tree-sitter with vis I'd be happy... haha
<unmatched-paren>it's a shame rustup doesn't work on guix/nix though
<jgart>just set up lsp with vis a few days ago
<jgart>this is my vis config
<jgart>in fennel
<unmatched-paren>ooh fennel
<unmatched-paren>could never get that to work in nvim :(
<jgart>I haven't tried to get it to work with nvim
<jgart>I think vis API's will be fun to hack on
<jgart>It's a simpler API
<jgart>smaller code base overall
<unmatched-paren>you need either aniseed.nvim or hotpot.nvim, neither of which i could get to work
<jgart>with vis you just need the following
<jgart>no third party package needed :)
<unmatched-paren>looks good actually, i'll try it
<jgart>just start putting some fennel in your vis config
<jgart>let me know if you run into any bugs
<jgart>It's very much a WIP at the moment
<unmatched-paren>gah it doesn't like fish very much
<unmatched-paren>fish: No matches for wildcard '':'*'. See `help expand`.
<unmatched-paren>is there a way to change it to use bash regardless of the login shell?
<unmatched-paren>but it has a sane default colourscheme \o/
<rekado>there’s one instance of (getenv "PYTHONPATH") left (in python-sadisplay), but the package doesn’t build successfully anyway.
<unmatched-paren>i suppose the wildcard thing is fish's fault really
<unmatched-paren>that's the only part of fish that drives me insane, it has strange glob semantics
<unmatched-paren>as in: it can only match filenames with *
<unmatched-paren>want all vim-* packages? nope! we can't find any files named vim-*!
<rekado>hmm, I just read a comment stating that PureOS is the most popular of all the FSF-endorsed distros (on distrowatch). And it’s true. 45 (PureOS) vs 133 (Guix System).
*rekado doesn’t understand how distrowatch ratings come to be.
<mentat>So I'm pretty new to guix. I'm wondering what the best way to resolve this problem with Info is. The Info directory no longer includes entries for Emacs, Elisp, or Stump. This is caused by Guix overriding the /usr/local/share/info/dir file to a symlink under the current profile. How can I resolve this? I have both Emacs and Stump built from source. I know I can solve it by installing Emacs or StumpWM with Guix, but there has to be a way
<mentat>to do this without that.
<unmatched-paren>i mean it is preinstalled on purism's hardware
<apteryx>mentat: perhaps add a trailing ':' at the end of your INFOPATH
<mentat>In the past, I've never set INFOPATH. It's just worked
<mentat>Will that load the things in /u/r/i/?
<apteryx>I think so; it causes it to expand to the default (hard-coded) locations
<unmatched-paren>the reason 99.99% of people use windows is because it comes preinstalled on stuff, so honestly i don't find that statistic surprising
<vivien>rekado, just wait for the viral marketing campaign for 1.4 with GNOME 41 ^^
<mentat>apteryx: (getenv "INFOPATH") returns a path with a trailing colon...
<zimoun>roptat, it is annoying to repeat ’properties’ when using ’package-with-ocaml4.xy’. It is prone error, IMHO. However, I do not find the way to tweak ’package-with-explicit-ocaml’ and remove ’variant-property’. Have you tried before?
<apteryx>mentat: the trailing column is interpreted by info-reader, I believe.
<roptat>zimoun, no never tried
<apteryx>or the equivalent thing in Emacs
<jgart>would it be ok to package lilypond stable and unstable release in master branch?
<mentat>aptexyx: Just as I thought. I can still access using `info emacs` from the command line. The problem is the dir file
<jgart>I imagine that one could inherit from the other
<mentat>The dir file which represents the top level info node doesn't have them in there because its been pointed at the guix profile which dosent know about emacs et al
<jgart>the reason for this is that the abjad music composition python library, for example, is usually tested against lilypond unstable
<zimoun>roptat, thanks. The transformation layers give me each time headache! :-)
<jgart>so it would be nice to have it
<mentat>So the problem isn't with INFOPATH but with the modified dir
<jgart>and lilypond usually has both releases available in parallel
<mentat>Is there any way to make guix aware of this kind of "installed by other" software?
<apteryx>rekado: MX Linux is the most popular distro, yet I've never heard about it. Seems legit.
<unmatched-paren>next they'll be saying qubes is the most popular distro
<unmatched-paren>everyone has suddenly become enamoured with virtual machines
<unmatched-paren>and are oblivious to the sounds of pain and dispair coming from their cpu and ram
<apteryx>mentat: you could remove this dir entry if it annoys you more than helps? that's on a foreign distribution?
<hackeryarn>I am loving the new shell command added to guix. As someone coming from nix, I have a workflow question. When I use nix shell, I have arbitrary bash commands that need to execute when I setup a shell environment (provided by postShellHook). Is there a good way to accomplish something similar using guix shell and a package definition?
<apteryx>jgart: I tried this but it failed building 1.57
<apteryx>err, 1.56
<apteryx>the first two: error: unknown lint: `rust_2021_incompatible_or_patterns`, next error: cannot find a built-in macro with name `panic`
<apteryx>I'll let the rust amateurs debug ;-)
<apteryx>I hope it gives you the idea
<unmatched-paren>rust_2021_incompatible_or_patterns is to do with this rust 2021 change:
<mentat>apteryx: Well GUIX actually overwrote the old one :/. And wouldn't that only work until I installed something else with guix and it modified it again? I'm reinstalling Emacs right now to see if it modifies it in a persistent way.
<mentat>I had emacs installed prior to guix, so it wouldn't surprise me
<apteryx>are they moving to a yearly LTS release or something? else I don't see how calling this release "rust 2021 edition" makes sense
<unmatched-paren>rust has two release systems: releases and 'editions'
<apteryx>mentat: you are talking about a file under /usr/local, right?
<unmatched-paren>editions are the way they do breaking changes
<unmatched-paren>you can specify the edition in cargo.toml
<apteryx>yay for inventing another release concept
<unmatched-paren>so all projects that still use 2015 will still compile under the latest versions
<mentat>apteryx: Yea
<apteryx>then guix doesn't touch anything there; the install script may, but that's a one time deal
<unmatched-paren>explanation of editions:
<mentat>It definitely has a bunch of symlinks generated by guix
<unmatched-paren>it's a pretty ugly system imo, but it guarantees backwards compatibility
<jgart>apteryx, cool! I'll look into it. How long does it take you to compile rust?
<unmatched-paren>ugly because old behaviors must remain in the compiler's code
<mentat>lrwxrwxrwx 1 root root 60 Nov 20 20:13 dir -> /var/guix/profiles/per-user/root/current-guix/share/info/dir
<jgart>This line might be something to add to our rust package also:
<apteryx>1h30 for the mrustc build, 10 minutes per intermediate build; 20-30 for the leaf one IIRC
<mentat>this is under /usr/local/share/info. Nothing has been touched in /usr/share/info
*jgart remove uninstall script
<jgart>apteryx, cool! that's not too bad. What specs does your cpu have for those times?
<jgart>if you don't mind sharing
<apteryx>it's a ryzen 3900x thingy
<jgart>16GB RAM?
<jgart>or more
<jgart>ok cool
<apteryx>but it doesn't matter
<mentat>Like I said, I installed emacs and stump before well before I had guix installed, so if it overwrote it on install, I have no issue just reinstalling them. It's literally ljust add * Emacs (emacs) to the dir file
<jgart>ohh ok
<mentat>I was just trying to figure out if that would persist
<jgart>why does the ram not matter?
<unmatched-paren>because you could just download more anyway
<apteryx>I don't think you need more than 10 GiB of RAM to build rust things; rustc is not very good at parallel compilation
<jgart>ah ok
<jgart>good to know
<apteryx>you should try it ;-)
<jgart>My CPU is Intel i5-2520M (4) @ 3.200GHz
<jgart>good for building rustc and friends?
<jgart>in under 2 hrs
<apteryx>it'd work on my main Q6700 main desktop, just much slower, so don't fear
<unmatched-paren>for tree-sitter, should the grammars be seperate packages?
*jgart brews a cup of coffee and begins the long journey to build rustc from sources
<unmatched-paren>i'm frankly not sure what's going on in this nix file :/
<jgart>unmatched-paren, ideally yes
<jgart>s/most probably yes
<unmatched-paren>okay i can see that the nix script uses 'PREFIX
<unmatched-paren>*PROFIX=$out make install
<unmatched-paren>i hit the enter key :)
<unmatched-paren>what's the equivalent of $out?
<unmatched-paren>or rather how do i get the installation/output location?
<jgart># tests require generating fixtures from remote repositories
<mentat>apteryx: Doh. /usr/local/share/info/dir is read-only because it's managed by guix. I should have anticipated that
<jgart>I think tests might need to be disabled for tree-sitter
<unmatched-paren>(tests? #f)?
<jgart>unmatched-paren, they're disabled in both nixpkgs and void-packages
<unmatched-paren>or something?
<jgart>unmatched-paren, yup
<unmatched-paren>nix has something something isDarwin, do we care about mac?
<jgart>void template builds libtree-sitter with make
<unmatched-paren>so trivial-build-system for libtree-sitter, i guess
<jgart>unmatched-paren, nixpkgs packages all the grammars individually:
<apteryx>mentat: 'sudo unlink /usr/local/share/info/dir' ?
<unmatched-paren>and then cargo-build-system for cli
<jgart>unmatched-paren, not sure about using trivial-build-system
<unmatched-paren>ok looks like nix runs its own primitive replacement tests
<unmatched-paren>jgart, is there a make-build-system?
<jgart>unmatched-paren, yup
<jgart>It's called gnu-build-system
<unmatched-paren>so there's a way to turn off the automake stuff, then?
<jgart>probably with custom phases
<jgart>unmatched-paren, I have a feeling that tree-sitter will be a difficult package
<jgart>have you worked on other packages?
<unmatched-paren>only one...
<jgart>might be good to build yourself up first by doing some package maintenance first
<unmatched-paren>should i leave it to someone else then
<jgart>upgrade a package here
<unmatched-paren>yeah okay
<jgart>package a few small ones
<unmatched-paren>i'll do a few of the gnome apps
<jgart>unmatched-paren, get in touch with Raghav
<unmatched-paren>see the thing is i kind of need tree-sitter though
<unmatched-paren>for nvim
<jgart>he's been working on GNOME 40 stuff and could use some help
<unmatched-paren>jgart: i've already done the wike wikipedia reader, haven't submitted it yet
<jgart>unmatched-paren, maybe use nix package manager for now to get tree-sitter
<lfam>No reason not to try packaging something, even if it seems hard. I have got several dozen "work in progress" packages that I come back to periodically, as my knowledge grows
<jgart>unmatched-paren, what lfam said is way to go about it for sure
<jgart>I just meant maybe do some other things first to keep the flow going instead of getting stuck with treesitter and only doing that
<unmatched-paren>tree-sitter is a really weird case since it:
<lfam>I agree, that's a good way to stay motivated
<unmatched-paren>- uses both c and rust
<jgart>boostrapped crystal would be a package that could benefit from lfam's suggestion/strategy
<unmatched-paren>- has multiple apps in one repo
<unmatched-paren>- uses an ugly makefile invoked by a for building the c libs
<jgart>small steps:
<unmatched-paren>160 stages!
<unmatched-paren>sounds fun!
<lfam>Not sure if this would help, but the rav1e package seems to use both Rust and C, and it does work:
<jgart>lfam, would you happen to have time to check this one out?
<jgart>no worries if not
<jgart>I think it will be an easy one to review
<jgart>v6 patch set contains the latest sc-im
<unmatched-paren>lfam, this one is annoying not because it FFIs into C, but because it's a group of interwoven packages that all get built at the same time, one c, two rust
<jgart>Ryan's ok with moving visidata to spreadsheet-apps.scm. I spoke with him and we thought it was a good idea to put sc-im and visidata together since they are both spreadsheet apps
<lfam>unmatched-paren: Yeah, those packages can be kind of annoying... they usually require some extra work from the packager
<jgart>unmatched-paren, see how nixpkgs is packaging all the grammars
<lfam>But, certainly not impossible!
<jgart>there might be some clues there
<lfam>jgart: The patches LGTM. The only thing is that I would prefer my earlier suggestion for the module name, (gnu packages spreadsheets) or (gnu packages spreadsheet)
<unmatched-paren>jgart: ok (frantically searches 'how to read nix files')
<lfam>Although, there are other *-apps modules, so I guess it fits a pattern :)
<jgart>lfam, ok, which one would you like me to push?
<jgart>I'm ok with both
<jgart>lfam, > Although, there are other *-apps modules, so I guess it fits a pattern :)
<jpoiret>hackeryarn: we don't have this kind of facility (yet?)
<jgart>yup there are haskell-apps
<unmatched-paren>yeah latest nvim/nvim nightly is going to be a pain
<lfam>And also rust-apps
<jgart>and others I think...
<lfam>Well it's not an exact science, coming up with names
<lfam>Merely a "hard problem" ;)
<apteryx>jgart: also about slower CPUs, you can often get more productive by dropping into a failed build (the -K switch), sourcing the environment-variables file there and trying stuff at this level
<jgart>> trying stuff at this level
<lfam>I'm in the middle of a major Debian upgrade. It's quite interesting to see what happens as the shared libraries are overwritten while the system is in use
<jgart>apteryx, could you unpack that slightly
<jgart>lfam, yolo
<apteryx>./pre-inst-env guix build rust -K -> fails. cd /tmp/guix-build-rust/ && . environment-variables -> hack, then call ./ build or whatever
<lfam>jgart: To clarify, do you only need a review on #47852, or would you also need me to push it to guix.git?
<jgart>lfam, if you think it's fine I would greatly appreciate it if you could push it also since it's been stagnant for a while given we couldn't decide where to put it
<lfam>Okay. I just wasn't sure if you were a committer or not
<jgart>I'd like to have sc-im in guix before tax season comes around again haha jk...or not
<lfam>Fair enough!
<jgart>lfam, I'm not
<jgart>Thanks a bunch! Much appreciated :)
<jgart>apteryx, thanks for clarifying
<lfam>jgart: Also, my mail client uses <jgart via Guix-patches via <> as your Git author email address. Would you prefer I use the email address in your copyright line?
<jgart>apteryx, does rustc use a python script to build something?
<apteryx>yes, to build itself
<apteryx>well, as glue code for cargo I guess
*jgart hasn't checked in the rust repo for python scripts
<jgart>apteryx, cool!
<jgart>lfam, that would be awesome!
<lfam>Great. It's some weird problem with my Mutt setup that it does this sometimes
<jgart>if it's not too much work
<lfam>Not at all
<jgart>although I've collected a few of the former ones also :)
<lfam>Years of Guix development have made me a master of Git
<jgart>haha, I bet!
<lfam>Especially years of code review
<lfam>Many complicated and lengthy rebases
<jgart>lfam, I'm hoping to finish up bower soon:
<jgart>new release will be out soon
<jgart>it's a pretty cool notmuch client
<jgart>I use it with msmtp for sending, offlineimap for retrieving, vis for composing
<jgart>I got lisp (fennel) in my vis config now recently so I guess it's like emacs.........................................
<drakonis>so, 1.4.0 tomorrow?
<drakonis>does fennel run in guile lua yet?
<jgart>hmmm don't think so
<jgart>I might be wrong though
<jgart>maybe it's just that no one has tried
<jgart>that was the case with configuring vis with fennel
<apteryx>drakonis: still haven't caught up with master in terms of coverage
<apteryx>but getting close
<unmatched-paren>i'll do,, and, and then submit a 'GNOME Circle Apps' patch :)
<hackeryarn>jpoiret: It would be neat to handle that type of shell setup via a shell phase in the build system. We could set it up so that build phase only runs when the package gets invoked using guix shell.
<unmatched-paren>hopefully that should keep me busy
<podiki[m]>do we mostly care about x86-64 coverage?
<jpoiret>build systems are completely isolated and run by someone else, so they're not what you're looking for
<unmatched-paren>maybe too
<pseudonymous>Playing around with guix a bit more. I came across . I am hoping I can create a profile from a custom manifest ( ), but the package I want also requires a custom channel. Can I set it up such that I have a channel definition in a scm file and my manifest and somehow populate a new profile from that ?
<jpoiret>i'd be more inclined to make guix system definitions able to be modified and booted from user-space too (be it with pid namespaces)
<jpoiret>pseudonymous: unfortunately, channels become part of the guix program when using `guix pull`. You need the channel files to already be a part of guix for `guix package -m ` to work properly
<lfam>podiki[m]: In practice, I would say yes. It's the most used platform and more performant than the next most popular platform, aarch64. That's an important factor for a build-from-source distro like Guix
<unmatched-paren>is there any way to change the search engine in icecat? for some reason it seems to be locked onto duckduckgo
<unmatched-paren>i want to change it to
<dissent>hey guix, was something every implemented to launch the xsession without a display manager?
<podiki[m]>dissent: not as far as I know, other than discussions here and on the mailing list before. it comes up enough that it should be in the cookbook, I would say
<podiki[m]>but some people do have it work? I'm not sure the current status
<podiki[m]>lfam: got it. That's what I'm on, so works for me, other than some packages that rely on i686 (wine; seems rust hasn't gotten built on i686)
<dissent>I know someone has managed it startx and I'm attempting now with sx. Perhaps I'll send in a patch to get the ball rolling.
<lfam>I don't think that Rust has ever worked on i686 in Guix
<apteryx>it almost works, but librustc uses too much memory while building on i686:
<podiki[m]>lfam: ah, interesting. wonder why rust is being called on in i686, maybe the librsvg change...I'll have to take a look (for wine, specifically)
<lfam>In my experience, the signature effect of major Debian upgrades is that fonts look different in Hexchat :(
<nckx>Morning, Guixoids.
<vivien>Good morning to you, nckxoid
<vivien>(here I would say good night)
<jgart>the source code for clangd language server is in this directory
<jgart>I was pointed to it from here
<nckx>vivien: One would here, too. It's half nine & I just got home from work & think I will head bedwards. Possibly with a laptop, possibly not.
<unmatched-paren>um this is a lovely error:
<unmatched-paren>Invalid keyword: #{199sz1dr9sx3n82n6gplsg0rx2l3x1wb8sdx43gzdkpz8i0c1n45}#
<vivien>Laptops aren’t great to help sleep
<lfam>unmatched-paren: I'd guess that a hash was entered incorrectly
<vivien>unmatched-paren, maybe a display instead of a write?
<vivien>In generated code
<jgart>Does anyone know if there are there any other packages in guix that have a similar situation?
<nckx>vivien: ‘Redshift is magic.’ —the little devil upon my shoulder.
<vivien>Redshift does not work with my graphics card :(
<nckx>That's definitely a hash.
<unmatched-paren>i imported some python packages from pypi with guix import that are needed for dialect, should i look into those?
<lfam>unmatched-paren: Double-check that you've written your code in the exact same way as an existing package
<nckx>I don't actually use Redshift (because Wayland), I forget what it's really called.
<nckx>vivien: It's *GPU*-specific though? That's odd!
<jgart>> Laptops aren’t great to help sleep
<lfam>unmatched-paren: For the pypi importer, make sure to wrap it's output in a (define-public $PACKAGE_NAME)
<unmatched-paren>huh oops i accidentally pressed 'paste' in nano while i had the hash in my clipboard :p
<jgart>This is my alarm clock `guix shell sox snooze -- snooze -H10 -M30 play -n synth noise`
<vivien>I don’t know if it’s redshift, it’s the default thing shipped with GNOME
<nckx>Oh, mine is more primitive. sleep $*; exec ogg123 --repeat …
<unmatched-paren>hash mismatch for git-checkout hm
<lfam>What's the right way to deal with ambiguous use of 'which' in a package definition?
<lfam>WARNING: (gnu packages spreadsheet): `which' imported from both (guix build utils) and (gnu packages base)
<vivien>And I didn’t know it used a specific thing in the graphics card until I noticed it didn’t work after I dropped the nonfree driver
<vivien>Anyway, I sleep better at night knowing I don’t have nonfree blobs in my kernel anymore :)
<jpoiret>lfam: you shouldn't really use which in package builds, directly use inputs' store directories instead
<lilyp>lfam: drop whih from guix build utils and use search-input-file :P
<jpoiret>also, you don't need to (use-modules) something from (guix build), as you want to import those modules from the builder, not the host code
<jgart>lfam, I think that error might have occured when I merged visidata AND sc-im into the same module
<podiki[m]>vivien: there's also blueshift, but not packaged for guix; which I prefer normally
<lfam>I noticed that no other package module imports (guix build utils
<lfam>Or, almost none
<podiki[m]>all of wine's deps show as built, yet it fails trying to build rust (for what?):
<jgart>lfam, (guix build utils) was in the visidata module that I moved over to the new spreadsheet-apps module
<lfam>It doesn't seem to be used, so I'll remove the import
<apteryx>you'll have a fun time tracking down the source, given the rust-build-system's funny use of inputs as argument thing.
<apteryx>podiki[m]: ^
*nckx looks up snooze, strange un-unixy looking thing.
<podiki[m]>apteryx: it is a change in c-u-f at least, so I'd guess librsvg somewhere? but very confused how all the listed inputs are built for wine but still tries to build something when it doesn't use rust in any of those or for itself
<nckx>lfam: The more general answer is #:hide.
<nckx>When importing.
<unmatched-paren>ok, what are propagated inputs? python-googletrans build is failing because of python-httpx, which is in propagated
<lfam>Indeed, wine depends on librsvg
<nckx>unmatched-paren: If X has Y as a propagated input, when you create a profile with X in it, Guix will place Y in it (as if it were explicitly installed) as well.
<nckx>I think it's transitive.
<lfam>unmatched-paren: First, the build will not succeed or fail based on whether or not an input is propagated. Propagation is something that effects what happens *after* the build
<podiki[m]>unmatched-paren: generally python inputs go into propagated to be available in the profile
<nckx>lfam is very right.
<podiki[m]>except testing ones that are often native-inputs
<lfam>For build-time problems, you can consider propagated-inputs to be the same as regular inputs
<lfam>It's basically a kludge to work around languages that lack the ability to record the locations of their run-time dependencies
<nckx>The opposite could be a problem (an input being non-propagated when it should be propagated), but that wouldn't affect the package having it as input — only dependents of that package.
<podiki[m]>okay, so that means some package on i686 pulled in librsvg instead of the non-rust one, right? since librsvg is only where we have rust?
<lfam>Could be podiki[m]
<lfam>There are other packages that depend on Rust, but librsvg is probably the one that is deepest in Guix's overall dependency graph
<podiki[m]>and the big change in c-u-f if I remember
<lfam>However, I'd expect to something about librsvg in that build log, in that case
<lfam>To see something
<unmatched-paren>right ok so it's just an issue with that package in general
<lfam>But who knows
<lfam>Yeah unmatched-paren
<unmatched-paren>so it's looking @, which 404s...
<lfam>Regarding wine, it's almost certainly caused by mozjs@78, which uses Rust
<lfam>And *is* mentioned in the build log
<f1refly>sorry if this is a dumb question, but I'm currently trying to install guix on a second partition from my arch system which I'm trying to transition from. I installed guix (the package manager) and using it i installed shepherd. when I start it and try to run 'herd start cow-store /mnt' like in the manual it's telling me "service cow-store not found"
<f1refly>what am i doing wrong?
<podiki[m]>lfam: and which looks like doesn't have an i686 build; okay progress!
<lfam>f1refly: I think you need to be working as root (or with privileges)
<jpoiret>no, the cow-store service is only present on the install image
<lfam>Oh, I misunderstood
<lfam>jpoiret is correct
<jpoiret>it's defined in gnu/system/install.scm
<vivien>cow-store is only needed in the installation image because the store is read-only there
<lfam>When you install Guix as a package manager on another distro, there is no concept of services, and additionally, the cow-store service only exists on the installer
<f1refly>hm, can I install it for this purpose or am i out of luck?
<vivien>You don’t need that step if you’re not in the installer
<f1refly>okay, that's good
<lfam>Yes, using Guix on another distro to installing Guix System is definitely possible
<jpoiret>you don't really need cow-store, as long as you have enough space on the current partition to let guix put a lot of things in /gnu/store (you'lle be able to delete this one after installing)
<f1refly>i thought it could be important that the stuff gets saved in /mnt/gnu/store, hence my question
<vivien>It will be copied there when you do guix system init
<f1refly>I'll go ahead then, thank you!
<jpoiret>ehm, i have better
<jpoiret>hang on
<lilyp>it's semi-important, because you can't really download into a read-only medium like a CD :P
<lilyp>and RAM is typically limited outside of extreme server setups
<f1refly>i think it'd just go into overlayfs(ram)
<jpoiret>ah no, the code i wanted to use needs %store-directory
<podiki[m]>(re: wine) and polkit depends on mozjs-78 where rust is used (not on earlier versions)
<unmatched-paren>aha! googletrans wants httpx exactly ==0.13.3 for some reason, and our httpx is a later version
<unmatched-paren>i think?
<podiki[m]>so this goes back to the polkit/duktape discussion, which I think will be resolved with using the right package based on arch (so I guess nothing for me to do...)
<unmatched-paren>so i guess i just add an httpx-0.13 package???
<podiki[m]>you may need to make one if it doesn't exist, or patch the package to accept a newer version if it doesn't break it (or check if upstream has addressed this)
<M6piz7wk[m]>how long does it take to build linux on guix?
<podiki[m]>I will hold for the polkit/duktape patch for nonx86-64 systems, I think that should do it for wine (and all the gnome etc stuff needed)
<vivien>M6piz7wk[m], I would say at most 4 hours
<M6piz7wk[m]>vivien: 4 hours for 1 thread?
<unmatched-paren>looks like upstream (in git) they've changed it to use exactly 0.14.1
<vivien>Mmh maybe not
<unmatched-paren>s o not worth switching to the git repo
<M6piz7wk[m]>oh it just built for me yay
<M6piz7wk[m]>why are we not doing any expected build time measurements through using user-reported times?
<M6piz7wk[m]>to provide more helpful output
<M6piz7wk[m]>e.g. starting a build with a timer and then reporting how long it took to build with cpu info
<jackhill>where does guix look for terminfo files? Asked another way, how can I get less and friends to be happy with the foot terminal out of the box?
<apteryx>M6piz7wk[m]: that'd be a fun feature, but it'd need to be opt in (it's privacy sensitive)
***TheOwlLady is now known as myrcy
<M6piz7wk[m]>well wouldn't say fun.. rather functional
<apteryx>at least we could start by outputting the total time it took for a build at the end
<M6piz7wk[m]>since i need those times to do better time and resource management
<M6piz7wk[m]>e.g. if i knew that guix would be building 2 weeks on my 1 core system then i would rather spent time figuring out offloading
<M6piz7wk[m]>apteryx: yep
<drakonis>M6piz7wk[m]: depends on the hardware building it
<drakonis>it takes me around half an hour on my current 8 threaded cpu
<jpoiret>sneek, later tell mothacehe: if you're also experiencing the gdm icon issue on c-u-f, i'll reopen the bug on the gnome-shell gitlab as after all my investigations, everything seems to be in place for it to work.
<sneek>Will do.
<roptat> /quit
<roptat>oops :)
<jpoiret>sneek: botsnack
<jpoiret>here you go, good night guix :)
<myrcy>good night jpoiret :p
<civodul>vivien: hey! i was applying the meson patch but found that "guix shell -e '(@@ (gnu packages build-tools) meson)' -- meson --help" works
<civodul>(i was expecting a module-not-found error)
<vivien>civodul, I know, but some use cases won’t work. In GNOME builder, the environment is unset, as if you did guix shell gcc -- /gnu/store/xxx-meson-0.60.0/bin/meson build
<vivien>Sorry, guix shell --pure gcc -- meson
<vivien>You’ll find the error there
<civodul>vivien: ah got it: that's because... python is a propagated input (!)
<civodul>so GUIX_PYTHONPATH is set when running the command above
<civodul>anyway, i'm applying the patch, and i'll move python out of propagated-inputs for meson-wrapped
<vivien>Good idea, thank you :)
<jgart>civodul, ambrevar, guillaume, (see bottom)
<jgart>Common Music Notation got successfully merged into Guix today:
<jgart>On the way to packaging slippery-chicken
<jgart>CMN is a dependency of slippery-chicken and a classic lisp package first developed at CCRMA (Stanford University) in the early 90s.
<jgart>CMN is still used today :)
<cyberbanjo>is "GC Warning: Out of Memory! Trying to continue..." a guix message? It did come from a `guix package -f go-cockroack-db.scm` but maybe `go build` said it?
<podiki[m]>jgart: cool stuff!
<cyberbanjo>just seen about --debug=4 im gonna see if that tells me more
<jgart>The original author, Bill Schottstaedt, helped with the efforts on our issue tracker :)
<podiki[m]>nice connection, loving seeing lisp kept alive
<civodul>cbaines: trying the wal_checkpoint now...
<civodul>cbaines: it completed instantly and the wal file is now empty
<civodul>go figure
<civodul>PRAGMA wal_checkpoint(TRUNCATE);
<civodul>jgart: nice! (both the actual package and the plug ;-))
<podiki[m]>happy almost birthday to guix! (I guess already the day in a good number of time zones)
*M6piz7wk[m] created and submitted it to guix-devel
<jgart>civodul, Thanks! Guillaume Le Vaillant sent a patch to Bill fixing the asd file which allowed Bil to publish a new release. I then sent an updated patch for cmn and Guillaume merged it. The new release is what's packaged in Guix now. ambrevar also help with the asd file.
<apteryx>a guile-git test apparently fails after I updated (locally) libgit2 to v1.3.0
<jgart>That's guixy teamwork y'all! Let's do more of it with rust packages... ;)
<apteryx>the rest seems mostly OK
<rekado>pseudonymous: yes, you can do this. Here’s an example:
<rekado>when USE_GUIX_INFERIOR is set the manifest will use the provided channels to look up the package specifications to install.
<vivien>I don’t understand why this fixed issue with python-poppler-qt5 has been renamed to D-Bus services not working on foreign distributions/non-user profiles
<lfam>sneek: later tell nckx: I'm looking at turning CONFIG_GCC_PLUGINS on for the kernel 5.10 package, like we discussed. I was able to do this for 5.15, 5.14, 5.13, 5.12, and 5.11. But the option is not offered with 5.10... Even using `make defconfig` in a 5.10 source tree with the Guix toolchain, this option does not appear
<sneek>Got it.
<apteryx>it's test/proxy that fail for guile-git with libgit2 1.3.0
<jgart>lfam, thanks for reviewing and merging sc-im!
<apteryx>guile-git issue
<cbaines>civodul, that's good. As far as I remember, the size of the file is an upper bound for the size of the WAL, but at least this should mean we'll know if it gets to large again in the short term
<M6piz7wk[m]>the notebook has been successfuly OS-liberated
<civodul>cbaines: good to know
<M6piz7wk[m]>it has CPU bugs though u.u
<civodul>in GDM there's a missing keyboard icon next to the password field
<civodul>dunno where that should be coming from
<jackhill>civodul: jpoiret has been working on that, but, like all things gnome, it's a real labyringht. (I think the icon is actually an eye with a slash through it)
<jackhill>I believe there have been reports of missing icons on the gdm on screen keyboard as well
<M6piz7wk[m]>are there any GNU Guix stickers that i can put over the w$