IRC channel logs

<apteryx>yep, there a couple bin/sh shebanghs in lfs/hook.go

<apteryx>yay, orcus 0.19.0 fetched with lfs? #t passed its test suite! now to fix git-lfs detection in confifure.ac for the builtin:dowload-git counterpart

<apteryx>configure.ac*

<jaeme>tehboss: systemd is a factor when using guix on a foreign distro where the guix-daemon service has to be configured

<jaeme>I mainly use guix on a foreign distro and sometimes the interaction is funky

<TehBoss>jaeme: i'm planning on installing the guix distro

<TehBoss>i just think it'll be easier to use it on its own isntead of competing with another package manager

<Kolev>Can someone help me with this error? https://codeberg.org/csh/dotfiles

<adanska>happy gnome user, but was just curious: cinnamon exists as a package in guix, but there is no desktop-service associated with it. did someone just not have enough time to make it a full desktop-service and left the package in the repo in case someone else wanted to put the time in?

<lilyp>do we have a quick procedure to remove multiple configure flags?

<lilyp>adanska: more or less; we don't like removing packages that build, but cinnamon is quite outdated

<lilyp>someone would have to update it and also make a service

<adanska>fair enough! just saw the file as i was compiling guix and it piqued my curiosity :)

<isaneran`>sup guix

<adanska>nothing much! wbu?

<isaneran`>reading the fine manual

<isaneran`>for emacs guix

<adanska>its a manual! enough is documented i think

<adanska>speaking of, the new guix cookbook entry is really good! props ludovic!

<isaneran`>what's it about?

<isaneran`>hmm guix-all-packages just errors with geiser-repl--wrap-unfontify-region-function: Wrong type argument: markerp, nil

<adanska>'software development', basically how to get a dev environment for your own repos up and running

<isaneran`>maybe incompatible geiser version

<isaneran`>oh nice, I guess it's basically an adaptation of the blog post?

<efraim>lilyp: normally some combination of remove, cut, string-match and regex. no syntatic sugar yet

<adanska>iseneran: yeah i think so? iirc

<lilyp>is cut available for configure-flags?

<isaneran>will give it a read cuz I think it would be great to start using those features more

<lilyp>normally, srfi-1 and srfi-26 are not available IIUC

<efraim>got to pull those in

<efraim>although it depends on how much you're removing if you need everything

<lilyp>yeah, I'll just do nested delete

<adanska>isaneran: yeah, it will help a lot with packaging too, sometimes i feel getting the environment correct is not as nice and ergonomic as id like, probably because im not using the guix tooling proplerly :p

<isaneran>yeah takes a little while to learn I think

<isaneran>I have the same feeling but the more I learn to use new features it starts to click together better

<isaneran>but I also have some weird habits that are probably compensating for things there are a better way to do

<isaneran>for example when I am making a package and I depend on some other package and don't know what module to import, I use guix edit to find the file and scroll up to the module definition or guess it from the file name haha

<adanska>yeah for sure. before i really knew how to leverage guix shell i was just updating file in my local guix repo and doing ./pre-inst-env guix build whatever

<isaneran>I know I can also use the package-spec->package thing but I feel like it's more robust to depend on the package object directly

<adanska>yeah def

<isaneran>yeah I still haven't figured out how to do that stuf haha

<isaneran>I just run guix build on the file and then guix package -f on the file

<isaneran>haven't even set up a channel yet

<adanska>yeah theres def much more ergonomic workflows that guix offers but its hard to discover them without completely understanding the system and all its tooling

<adanska>i guess im learning so thats a given haha

<adanska>but it/is a steep learning curve, especially compared to something like debian

<adanska>its just that the system provides many many benefits after you learn it

<lilyp>I wouldn't classify debian packaging as simple, but you do you :)

<adanska>oh yeah for sure its not simple, arguably guix's approach is far easier

<adanska>i mean more so using the environment ect

<adanska>theres less to think about (and more to bite you in the backside later, fwiw)

<isaneran>yeah I guess I can see what you mean adanska

<isaneran>like if I were to put a new person on debian I can just tell them to run update and upgrade once in a while and don't install packages outside of debian repo and they hopefully won't shoot themselves in the foot

<isaneran>but I guess here I have to tell them to run guix pull, guix upgrade, guix system reconfigure, oh and once in a while remember to delete package generations and system generations and run guix gc cuz you'll accumulate harddrive space

<isaneran>you get amazing benefits for learning all that for sure though

<isaneran>but it's more to take in

<isaneran>especially for someone a bit less technical

<adanska>in that respect guix is pretty user friendly, but gets complex as soon as you want to do anything that modifies your system outside what guix provides for you

<isaneran>however we should be able to solve that with a beginner friendly GUI for basic guix tasks

<isaneran>for a person who just wants to run it and install programs and keep their system up to date basically

<adanska>in that respect it makes the 'hacking' aspect of a linux distro a little harder. you need to consider a lot more before you can update an etc file somewhere or modify a service

<adanska>if theres one thing i wish there were more tutorials and blog posts about, it would be guix services. the naming is confusing and writing them requires a lot of knowledge about the whole guix setup

<adanska>one of my projects at the moment is writing a home-onedrive-service-type, and that is proving to be a far greater undertaking than i was bargaining for

<adanska>same with auto-cpufreq

<adanska>the way services interact with your system becomes a lot more complex than youd otherwise think

<isaneran>yeah I mean, on my other computer I was fighting with auto starting sheperd in my bashrc manually because I hadn't discovered home environments yet

<adanska>i guess i just have to do a lot more reading and tinkering, eventually i'll understand i hope

<isaneran>but I think once it clicked for me what services in guix are it was kind of a genius generalization

<isaneran>it's like a system lego component

<adanska>mm its a more abstract meaning of 'system' than that we are generally used to

<adanska>*service

<lilyp>yeah, the lack of a GUI is something that irks me too

<adanska>does nix have a gui frontend?

<isaneran>we should hack a simple one together with the guile bindings for gnome

<isaneran>sorry gtk or whatever

<lilyp>there is already a project for that out there but idk about its status

<lilyp>it's definitely not packaged in guix tho :)

<adanska>guile-gi right?

<isaneran>tried to update postgresql to version 16 but can't figure it out haha

<isaneran>or at least it wasn't as simple as updating the version number and hash

<isaneran>another thing that would help a lot would probably be an easier graphical frontend for info manuals

<isaneran>if it comes installed with the default gnome system as an application called Guix Manual or something that just invokes that graphical reader with the guix manual open

<isaneran>hmm emacs-guix's guix-edit doesn't find files from other channels like guix edit does

<isaneran>maybe having a flag to get `guix edit' to print the path and line number etc would make it easier to get full parity? Though I dunno how emacs guix works, seems to use a guile repl and stuff so maybe that wouldn't help

<lilyp>the ironic thing here is that yelp should be able to find info and man files but doesn't tell you how

<isaneran>yelp?

<isaneran>something like printing the path to a package would help people implement emacs-guix like frontends for other editors though

<adanska>isaneran: the gnome help program

<isaneran>ahh yeah

<isaneran>yeah it only gives you help with gnome :/

<janneke>ACTION notices https://issues.guix.gnu.org/66472

<janneke>"we need a better fix" :)

<janneke>in other news, tonight my first `guix pull --url=$PWD --branch=hurd-team' succeeded on my x60

<lilyp>yelp info:guix#Top

<isaneran>oh what it can actually read info?

<isaneran>that said, it doesn't render it very readably

<isaneran>but that can be patched probably

<lilyp> http://logs.guix.gnu.org/guix/2023-10-12.log#085747

<isaneran>ship guix with a .desktop file that runs that command?

<lilyp>I think we should rather not depend on even more graphical libraries in Guix itself

<isaneran>ah, I mean in the gnome configuration

<isaneran>it comes with yelp installed

<isaneran>so we're not adding any dependency by having a package that adds the desktop file for calling yelp to open up the guix manual

<lilyp>sure, but I think it'd be better to communicate our need to display info manuals more clearly to yelp

<isaneran>oh yeah

<isaneran>I agree with that

<isaneran>I just don't think they are mutually exclusive

<isaneran>we can help people discover the manual today without any changes to yelp, and yelp helping people find info manuals will help them discover better how to use all sorts of gnu progra

<isaneran>like the coreutils etc

<civodul>Hello Guix!

<efraim>o/

<isaneran>\o

<rekado>the compiled info files include hard line breaks and strip most of the information we have in the texi files, so yelp probably can’t do any better.

<janneke>o/

<isaneran>oh

<isaneran>what are they compiled to?

<isaneran>the way info compiles should probably be fixed then

<rekado>isaneran: texi -> info

<rekado>it’s not something you can fix without breaking compatibility

<isaneran>ah I never realized they were different lol

<lilyp>texi can also compile to docbook, though, right?

<isaneran>texi = TexInfo?

<efraim>it seems after stopping the qemu-binfmt service suddenly its much harder to cross-compile rust apps

<civodul>heh, were they *really* being cross-compiled? :-)

<efraim>more of once I turned off qemu emulation I wasn't able to run all the scripts, so I think it was more native than I had planned for

<efraim>in an interesting turn 'rust-sysroot-for-<arch>' is probably the same regardless of starting architecture, so in theory it could be #:target #f and I wonder if it could be used as an input for rust itself

<efraim>nope, still links to the cross-compilers

<efraim>/gnu/store/ypksqgiiddjrhajbb2xq49zpx82b0c33-exa-0.10.1/bin/exa: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /gnu/store/3vz4r4q3n1is3f63m7c2xwqbpfhm0ais-glibc-cross-i686-linux-gnu-2.35/lib/ld-linux.so.2, for GNU/Linux 2.6.32, stripped

<efraim>but of course x86_64 -> i686 is easy

<civodul>cross-compiling to i686 from x86_64 is questionable :-)

<lilyp>"cross" "compiling"

<janneke>ACTION whistles casually and looks away

<phf>Hello #guix! I've implemented enough of gnu/packages/elixir.scm, guix/build-system/mix.scm, guix/build/mix-build-system.scm for things like `guix shell -C elixir -f elixir-jason.scm -- elixir -e "import Jason"' to work as expected.

<phf>where `guix import hexpm jason > elixir-jason.scm' for the most part.

<phf>The objective is to have mix-build-system included in Guix. At what point should I bother the developement list with my patches ?

<lilyp>I mean, if it works for some projects, you could start writing an RFC patch, if not an actual one

<phf>right now, I'm looking at elixir packages that depend on C extensions and the likes, not only Elixir code.

<phf>lilyp: Ok, I will look at `RFC patch' then, thanks.

<lilyp>if there are any caveats to be aware of, you should just state them in your cover letter; probably others interested in elixir will be happy to chime in

<phf>Great!

<isaneran>where do I find patches discovered by search-patches?

<snape>isaneran: gnu/packages/patches

<isaneran>thanks !

<snape>they should also be referenced in gnu/local.mk isaneran

<isaneran>great

<isaneran>have to figure out how to modify a patch

<isaneran>or make a new version of it

<isaneran>postgresql has a patch that disables symlink resolution but it isn't valid on postgres version 16 since that file it's patching has changed

<snape>well either the patch is now upstream, in which case you just remove it

<snape>either it doesn't apply anymore, in this case you need to produce a new patch

<snape>(I mean: it doesn't apply but is still required)

<isaneran>I don't think it is upstream since it just puts a return 0 at the beginning of the function

<isaneran>so yeah I'll have to make a new patch

<snape>to produce a patch, you have basically 2 solution

<snape>- you can have 2 src directories, you modify one of them and run 'diff -u dir1/.../your-file dir2/.../your-file

<snape>- you have 1 src directory, you run 'git init', you commit everything, and then you do your modification as another commit and 'git format-patch'

<isaneran>I guess it's option 1 then since the source is in a tar ball

<isaneran>hmm is it really so bad that it resolves the symlinks for exec paths?

<isaneran>ie it takes the symlink and converts it to an absolute path

<isaneran>so probably into the store and stuff

<snape>isaneran: it comes from https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c336567dad48c5cdae0b442b58fae70a83b03e9b

<snape>so whatever you do, you need to check if it doesn't break "finding extensions"

<lilyp>don't forget about quilt

<isaneran>ahh ok

<isaneran>makes sense

<snape>isaneran: running "git blame" helps ^^

<isaneran>yeah :D

<snape>lilyp: how would you use quilt in our case?

<lilyp>quilt new name-of-your-patch.patch

<lilyp>quilt edit the-file-to-patch

<lilyp>quilt refresh

<lilyp>you can also quilt add the-file-to-patch and edit it in another editor

<snape>ACTION reads in the doc about "--no-index" and "-pab"

<snape>nice, I like it, thx lilyp

<isaneran>hmm this might be a bit too hard for me at this point

<isaneran>I decided to just try and get it building first and not worry about the symlinks thing for now but it can't find icu4c and I saw another database had a workaround for that in its arguments, but I don't wanna write the arguments straight in the package since I don't want to override the one from the parent package

<isaneran>also, postgres is mission critical software for a lot of people, so I don't think I can be the one who submits the patch to get it to version 16 haha

<isaneran>don't wanna break people's pg

<lilyp>IIUC we have versioned pg, plus there's a review process ;)

<snape>so you can add postgres-16 without linking postgres to postgres16

<isaneran>true

<isaneran>atm I'm just kinda copy and pasting things into my postgresql-16 from 15 to tinker with easier

<isaneran>since I don't know all the fancy things to modify inherited stuff other than very basic

<snape>and you can send the patch to the ML anyway, some ppl will do the review

<isaneran>ok, I'll hack on it bit by bit and read up on how to submit

<isaneran>maybe someone will beat me to it but I'll aim for it

<snape>isaneran: you can start by copying postgres15, and just changing the bits you need, and later do the inheritance stuff (so that postgres 15 inherits from postgres 16) indeed

<civodul>sneek: later tell phf Guix appears to be on code.gouv.fr: https://code.gouv.fr/public/#/repos?q=guix

<sneek>Got it.

<lilyp>We are backed by INRIA after all :)

<civodul>heh :-)

<civodul>“backed” is a bit strong actually

<civodul>except for me that is ;-)

<isaneran>oh that was easier than expected, I just needed to add pkg-config to native inputs rather than modifying environment variables haha

<civodul>cbaines: hey, any idea what happened to dover?

<isaneran>eyy it built!

<isaneran>though the loading extensions thing might be broken

<cbaines>civodul, nope, both dover and monokuma are offline and I haven't got around to investigating yet

<civodul>cbaines: ok, thanks

<bost1>I use Guix as my main OS and I need to buy myself a new laptop. Do you have HW recommendations?

<snape>I've pre-ordered https://frame.work/

<bost>snape: do you have any specific reasons for https://frame.work/ ?

<snape>bost: it encourages an economy that builds things that are made for lasting

<bost>snape: Ah, Ok. I meant something like should I go for more RAM or faster SSD or specific processor etc.

<janneke>snape: does that have a free bios and wifi?

<lilyp>depens on whether you want to compile things on your own, play games, or mine bitcoin (please don't do that last one)

<janneke>(best to avoid all of those ;)

<snape>janneke: it seems it's going to support Coreboot: https://community.frame.work/t/responded-coreboot-on-the-framework-laptop/791/86?page=6

<snape>janneke: and https://frame.work/fr/en/blog/open-sourcing-our-firmware this article

<aldum>I'm really hoping for a proper 3rd party ThinkPad-style keyboard

<snape>"We’re continuing to invest in open source firmware development, with the goal of replacing other proprietary firmware we’re currently stuck with in the future too."

<janneke>snape: thanks, pretty interesting to follow that

<rekado>FYI: the guix-science channel now has a bazel-6 package. If someone would like to package a more recent version of Tensorflow by building it with Bazel in Guix, feel free to try this in guix-science.

<bost>There's the FSF recommendation https://ryf.fsf.org/categories/laptops I'll have look on the laptops listed there.

<snape>^ this list is out of date

<snape> https://minifree.org/ is the source

<janneke>ACTION has been using a dell xps-13, thinkpad x230 and current daily driver is a thinkpad x270, all with atheros wifi card

<snape>I used to own such a X200. It was good except for suspend-on-ram, boot time and power

<snape>and when suspend-on-ram doesn't work, it's annoying that boot takes so long, with a 2h battery

<snape>maybe now things have improved though

<janneke>ACTION never had any troubles with those

<civodul>rekado: yay, congrats!

<janneke>well, boot times are long, but yeah, don't run windows

<snape>probably because I had full disk encryption with LUKS

<snape>(I ran GuixSD at that time)

<snape>and the free bios was slow at doing the crypto stuff

<luke-jr>got glibc-locales to build, now trying to move on to making an install image, but it fails immediately: https://paste.centos.org/view/bdbb8276

<oriansj>snape: all bios are slow at doing the crypto stuff because the bootloader did not create an optimized crypt module

<oriansj>and probably because of the hardware limits on x86 in real-mode;

<PotentialUser-69>I've just installed the fontawesome package to get icon support in waybar. but i'm only getting about 2/3rd's of the icons appearing anyone have any idea what would cause this?

<bjc>i had the same problem, and it's not even guix specific. so i stopped using font-awesome and just use normal unicode stuff

<bjc>building infrastructure around the private use area is definitely a choice

<oriansj>guix has python-esptool but no ability to compile or assemble ESP32 binaries from source code

<snape>ACTION is eager to read the new "Software Development" chapter in the docs

<PotentialUser-57>Hi! I want to reinstall guix system. Can I just delete the 'gnu' folder from the disk?

<mirai>civodul: could you weight in on #62056? I'm wondering whether it makes sense for (erase-current-line …) to have an extra parameter instead (i.e. using (parameterize …) to set its newline behavior)

<mirai>instead of duplicating the definition of (erase-current-line …) everywhere

<civodul>ACTION considers redirecting civodul to ChatGPT or M-x doctor

<civodul>seriously though, i’ll take a look when i can!

<jaeme>PotentialUser-57: yeah just delete the /gnu directory and remove the guix-daemon.service assuming you are on a foreign distro with systemd

<bovid-19>Hello guix! How can I restart the audio system? I could not see any service that looks like it is responsible for it. I need to restart it because it shows the HDMI audio channel as unavailable. I assume restarting the right service would help because reconfiguring the system did. But it seems like a bit of overkill just to avoid a restart of the

<sneek>Welcome back bovid-19, you have 1 message!

<sneek>bovid-19, nckx says: ‘guix refresh -u’ more or less (but mostly more) assumes you're running it as ‘./pre-inst-env guix refresh -u’ in a writable Git checkout. The error message could be clearer.

<bovid-19>whole system.

<PotentialUser-57>jaeme: thank you!

<podiki>bovid-19: if you are using pulse audio I think you can just kill the process and it will get restarted by the next audio request. otherwise you can restart it from e.g. the pulseaudio tray icon if you use that

<mirai>thanks

<bovid-19>podiki: thank you. I have currently disabled pulseaudio in my configuration. Restarting it did not always help. But I just checked and pulseaudio is actually a running process. Killing it did not help. There are a couple of other things that don't seem normal with my system. I probably should just try and reinstall it.

<podiki>Well you'd need to know what the audio system is if you are going to restart it or figure out what's wrong. If you share your system config someone can help look (I'm away now)

<apteryx>hm, where was that change-id patch I've sent

<luke-jr>still looking for a way to run a script in the chroot post-unpack (to abort if there's any ELFs)

<apteryx>our aarch64 machines on berlin are overwhelmed

<podiki>how do you show closed bugs in debbugs? i answered the prompt about showing archived bugs and also set debbugs-gnu-suppress-closed to nil as well

<podiki>but still don't see closed bugs on guix-patches

<podiki>well you can just go to the direct bug number at least with debbugs-gnu-bugs

<panosalevro>anyone looked at this package conflict? looks like a straightforward fix to me. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66033

<podiki>i see arch calls it "helm-synth" what about that?

<clarkf>is there a trick for getting `guix home` to update `EMACSLOADPATH`? i see the packages under ~/.guix-home, but that's not been added to the path

<rrobin>~/.profile should have something to set it up.

<clarkf>~/.profile sources `$HOME_ENVIRONMENT/{setup-environment,on-first-login}` but neither modify EMACSLOADPATH :/

<clarkf>grepping ~/.guix-home for EMACSLOADPATH yields nothing

<lilyp>does your guix home profile have emacs?

<clarkf>no

<lilyp>that's the issue

<clarkf>i'm using exwm, so it's managed by guixsd

<clarkf>:( is that how it has to be?

<lilyp>you still need to add emacs to your home profile for the search path

<clarkf>ahhhhh, weird

<lilyp>there is an emacs service in the works but I'd suppose it does the same internally

<clarkf>huzzah! it works!!! :D

<panosalevro>podiki: doesnt matter to me, as long as the conflict is resolved

<podiki>panosalevro: okay. i think i'll go with helm-synth; will take care of it later today

<panosalevro>podiki: super, thanks!

<boo_>Hi! I've configured a couple of services for a user on one of my headless systems. The services work well but I would like for them to automatically start on bootup. Is there any way I can get a user's Shepherd daemon to start without having to manually login as that user? loginctl enable-linger <user> doesn't seem to work as it would on systemd

<podiki>for renaming in this case (two packages with same name) can't use a deprecation? or how do we handle that?

<lilyp>boo_ you could start it as a shepherd service maybe?

<boo_>lilyp: Do you mean running the user's shepherd daemon as a service?

<boo_>Or running the service as a system service?

<podiki>panosalevro: I just realized after failing to find "helm" that it is from another channel

<podiki>so i'll fix there

<civodul>rekado: Cuirass upgraded on ci.guix! lemme know if things work as expected

<rekado>civodul: thanks! Unfortunately, I get a 502 when visiting https://ci.guix.gnu.org/download/1078

<civodul>argh

<civodul>In procedure open-file: No such file or directory: "/gnu/store/0yb96ks4fa6781817ala5w706f945zq4-guix-binary.tar.xz"

<civodul>how did you get that URL?

<rekado>it’s a redirect from https://ci.guix.gnu.org/search/latest/archive?query=spec%3Atarball+status%3Asuccess+system%3Ax86_64-linux+guix-binary.tar.xz

<boo_>I've looked around the code and documentation and it seems reasonable that I could run the user's home shepherd as a service of system shepherd, the problem is that I don't know how to specify whose home shepherd to run. Any pointers?

<civodul>hmm i thought Cuirass commit 5e3e49c351f94a63dbea004333a1ac1fe4f43982 would give us 404 to begin with

<civodul>“selected 2453352 build logs to remove” <- builds logs more than 9 month old on berlin