<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 <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! <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. <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? :-) <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 <KE0VVT>How do I go about running Syncthing? Do I need to add it to config.scm? <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) <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? <TheOwlLady>hey everyone I'm sure this is going to sound like a super simple question. <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>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. <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>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>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 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>this doesn't work: pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $(which thunar) ***KM4MBG is now known as jackhill
<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>LoadError: Could not open library '.gems/gems/sassc-2.4.0/ext/libsass.so': libstdc++.so.6: cannot open shared objec <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 <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>actually it seems like both use a cargo build for building and then a custom build.rs invokes cc to create the libraries <unmatched-paren>but there's no clear separation even though libtree-sitter is useful without tree-sitter-cli <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 <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 reads about quicklisp <fcw>Yes, a package manage for Common Lisp libraries. <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. <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 <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 <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>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 <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>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/remote_command.sh that i use like so: remote_command.sh "herd restart cuirass-remote-worker" <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 <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? <civodul>or maybe it's just that we gc more often because of the core-updates churn? <mothacehe>but gc used to complete around 8 am (4 hours duration or so) <zimoun>civodul, did you pushed the 70% “deletion unused links”? <civodul>mothacehe: so that would hint at an unoptimized sqlite database issue <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 <civodul>maybe we'll have to stop it all for maintenance and try VACUUM? (that's the command we need, right?) <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 <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>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 <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 <cbaines>performing a checkpoint will block writes, but shouldn't require stopping/restarting anything <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>so i guess we can try that once gc is over <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: 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? <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 <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 gtk.so 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) <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 ? <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? <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 <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>at first I've installed pass and pass-otp for my user only <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") <jlicht>sirmacik: and `guix shell password-store pass-otp -- pass otp <some-otp-you-have>`? <jlicht>sirmacik: Did you <some-otp-you-have> with an actual otp entry in your password store? <jlicht>and if you do the same command, but with pass show instead of pass otp? <sirmacik>it worked, just started complaining about pinentry stuff missing :D <jlicht>then there must be something going wrong in your env <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>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 'libportaudio.so.2': libportaudio.so.2: cannot open shared object file: No such file or directory <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 ? <Guest58>OOSError: cannot load library 'libportaudio.so.2': libportaudio.so.2: cannot open shared object file: No such file or directoryOSError: cannot load library 'libportaudio.so.2': libportaudio.so.2: 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? <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 <jlicht>it should make any additions to the store be written to /mnt/gnu/store, instead of /gnu/store ;) <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> File "<stdin>", line 1, in <module> <Guest58> File "/run/current-system/profile/lib/python3.8/site-packages/sounddevice.py", line 72, in <module> <Guest58>OSError: cannot load library 'libportaudio.so.2': libportaudio.so.2: 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 libportaudio.so.2 directly <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 help-guix@gnu.org mailing list is a place to ask for help too <Guest58> 9 (primitive-load "/gnu/store/bnd59pchdyyrf7s10kkkxj5808l…") <Guest58> 838:2 7 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #) <Guest58> 1736:10 6 (with-exception-handler _ _ #:unwind? _ # _) <Guest58> 857:16 5 (every1 #<procedure 7ffff0bd7060 at guix/build/gnu-bui…> …) <Guest58> 619:8 3 (_ #(#(#<directory (guile-user) 7ffff1baff00>) (# # …))) <Guest58> 735:19 2 (with-atomic-file-replacement "sounddevice/__init__.py" #) <abrenon>ah, sorry I had missed the message showing that you knew about it <abrenon>well, it's helpful for stack traces too : ) <Guest58>i just want that python package installed <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>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-)? <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. <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 <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 <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>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 ? <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 <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 ? <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 <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>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>as well as ~/.config/guix/current/bin <roptat>if that's the case, you should be good :) <florhizome[m]>> <@florhizom:matrix.org> 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]>it’s a fork of sway doing some eyecandy, for now rounded borders as an option. <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 <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! <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 <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 <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>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 <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 <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 "...") ...) <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 <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. <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 <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) ? <jpoiret>I think a generic thing to tell people would be to run `dbus-update-activation-environment WAYLAND_DISPLAY/DISPLAY` inside their WM config <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. <zimoun>roptat, for ocaml4.07-variant, yeah for sure. I miss the ’properties’. <zimoun>roptat: for the variant, I did not want to upgrade ocaml4.07- to avoid breakage. <Guest58>not a single package i imported from pypi using `guix import pypi` worked lmao <Guest58>the only thing it gave me is headache <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>i get an error on every package i attempt to install <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. <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>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? <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 <rekado>it’s a quirk of the xapian indexer <vivien>My issues 51948 and 52009 do not appear :( <roptat>so I switched to core-update-frozen. python-codacy-coverage is failing for me, in the sanity-check phase. What should I do? <rekado>is it a false positive? If so: remove the phase. <roptat>what's the usual solution to this kind of issue? <apteryx>roptat: adding the missing input in this case <rekado>vivien: 51948 didn’t mention core-updates-frozen in the subject(s) <rekado>vivien: when you retitle the bug it will appear <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><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) <vivien>I wish magit supported changelog-style git commits <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 <apteryx>I had that feeling when I learnt I could do proper copy/paste in xterm <vivien>rekado, thank you for the command. <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>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>I’m not sure that’s related to what you’re investigating <jpoiret>i mean, icons in gdm are my new hobby <unmatched-paren>it's a dependency for the latest version of neovim, which i really really really need <unmatched-paren>and rust bindings, which should be seperate from libtree-sitter, right? <jgart>I want tree-sitter also for helix editor <jgart>but I also need rust 2021 edition 1.56.0 <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 <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 <jgart>If I can get lsp and tree-sitter with vis I'd be happy... haha <jgart>just set up lsp with vis a few days ago <jgart>I haven't tried to get it to work with nvim <jgart>I think vis API's will be fun to hack on <unmatched-paren>you need either aniseed.nvim or hotpot.nvim, neither of which i could get to work <jgart>no third party package needed :) <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>is there a way to change it to use bash regardless of the login shell? <rekado>there’s one instance of (getenv "PYTHONPATH") left (in python-sadisplay), but the package doesn’t build successfully anyway. <unmatched-paren>that's the only part of fish that drives me insane, it has strange glob semantics <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 <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. <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 emacs.info 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>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>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 ;-) <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 <apteryx>mentat: you are talking about a file under /usr/local, right? <apteryx>yay for inventing another release concept <unmatched-paren>so all projects that still use 2015 will still compile under the latest versions <apteryx>then guix doesn't touch anything there; the install script may, but that's a one time deal <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? <mentat>lrwxrwxrwx 1 root root 60 Nov 20 20:13 dir -> /var/guix/profiles/per-user/root/current-guix/share/info/dir <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? <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 <mentat>I was just trying to figure out if that would persist <jgart>why does the ram not matter? <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>My CPU is Intel i5-2520M (4) @ 3.200GHz <jgart>good for building rustc and friends? <apteryx>it'd work on my main Q6700 main desktop, just much slower, so don't fear *jgart brews a cup of coffee and begins the long journey to build rustc from sources <jgart>unmatched-paren, ideally yes <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 <jgart>unmatched-paren, they're disabled in both nixpkgs and void-packages <jgart>void template builds libtree-sitter with make <apteryx>mentat: 'sudo unlink /usr/local/share/info/dir' ? <jgart>unmatched-paren, not sure about using trivial-build-system <jgart>It's called gnu-build-system <jgart>unmatched-paren, I have a feeling that tree-sitter will be a difficult package <jgart>have you worked on other packages? <jgart>might be good to build yourself up first by doing some package maintenance first <jgart>unmatched-paren, get in touch with Raghav <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 <lfam>I agree, that's a good way to stay motivated <jgart>boostrapped crystal would be a package that could benefit from lfam's suggestion/strategy <unmatched-paren>- uses an ugly makefile invoked by a build.rs for building the c libs <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) <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>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?) <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 <apteryx>./pre-inst-env guix build rust -K -> fails. cd /tmp/guix-build-rust/ && . environment-variables -> hack, then call ./x.py 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 <jgart>Thanks a bunch! Much appreciated :) <jgart>apteryx, thanks for clarifying <lfam>jgart: Also, my mail client uses <jgart via Guix-patches via <guix-patches@gnu.org> 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>well, as glue code for cargo I guess *jgart hasn't checked in the rust repo for python scripts <jgart>lfam, that would be awesome! <lfam>Great. It's some weird problem with my Mutt setup that it does this sometimes <jgart>although I've collected a few of the former ones also :) <lfam>Years of Guix development have made me a master of Git <lfam>Especially years of code review <lfam>Many complicated and lengthy rebases <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>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 <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. <jpoiret>build systems are completely isolated and run by someone else, so they're not what you're looking for <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 <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 <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>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>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? <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 … <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 <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. *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. <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 <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>There are other packages that depend on Rust, but librsvg is probably the one that is deepest in Guix's overall dependency graph <lfam>However, I'd expect to something about librsvg in that build log, in that case <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" <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 <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 <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 <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 <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...) <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) <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 <unmatched-paren>looks like upstream (in git) they've changed it to use exactly 0.14.1 <M6piz7wk[m]>why are we not doing any expected build time measurements through using user-reported times? <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
<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 <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. <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 <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 <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. <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? <cyberbanjo>just seen about --debug=4 im gonna see if that tells me more <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>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) <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... ;) <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 <apteryx>it's test/proxy that fail for guile-git with libgit2 1.3.0 <jgart>lfam, thanks for reviewing and merging sc-im! <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 <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$