IRC channel logs

2022-03-20.log

back to list of logs

<fnstudio>when guix importing python-halo (i.e. `guix import pypi halo`) i'm given back a definition that contains `python-backports.shutil-get-terminal-size` as a propagated input
<fnstudio>that seems to give problems further down the line, when i try to build it
<fnstudio>the syntax also seems a bit suspicious... the fact it has a dot...
<fnstudio>oh ok, this is weird... the build phase of a dependency fails... throwing a f-word a couple of times...
<civodul>fnstudio: looks like "guix import" got the identifier wrong
<fnstudio>not that that bothers me... but i'm curious to know where that comes from
<fnstudio>thanks civodul, talking about `python-backports.shutil-get-terminal-size`?
<fnstudio>oh... if i try and look for backports, that seems to be a wheel package, so i guess i'll have to go and get the sources manually
<fnstudio>but first i want to investigate the other odd error message
<civodul>actually there's already a package called python2-backports-shutil-get-terminal-size
<civodul>which makes sense, because according to its synopsis it backports a Python 3.3 function to Python 2
<civodul>so you don't need it on Python 3
<fnstudio>the fact it's marked as python2 was worrying me - ah i see, it makes sense then, ok great
<fnstudio>i'll rename it accordingly then and try to rebuild
<fnstudio>(thanks!)
<civodul>just drop it i think
<civodul>not sure if "guix import" should have figured it out
<fnstudio>ah ok, yes, i had commented it out already
<fnstudio>on a different note, here's the error message received when building dotty, another dependency
<fnstudio> https://paste.debian.net/1234964/ (contains an f-word)
<fnstudio>just for the sake of curiosity i'm having a look at where that comes from
<fnstudio>by looking at the repo, it doesn't seem coming from dotty
<fnstudio>i.e. https://github.com/pawelzny/dotty_dict/
<fnstudio>well, not only i can't find that string in dotty's repo, i can't find it in the entire github
<fnstudio>hm, still puzzled
<fnstudio>the issue can be reproduced by guix-importing qmk-dotty-dict and then trying to build it
<fnstudio>i'm gonna investigate a bit more tomorrow
<fnstudio>ok, i think i found it, it's a print statement in setup.py, that apparently is not part of the upstream repository but for some reason is in the PyPi sources
<fnstudio>that can be downloaded from here https://pypi.org/project/qmk-dotty-dict/#files
<fnstudio>which are also the sources retrieved by guix import
<fnstudio>well, should i say, guix build
<podiki[m]>sneek: later tell nckx the kernel option did the trick, can mount ext4 with casefolding now; thanks!
<sneek>Okay.
<the_tubular>The following derivation will be built:
<the_tubular>Was this always a different color ?
<Aurora_v_kosmose>So I'm getting an interesting error.
<Aurora_v_kosmose>oh. -_- nvm. guix-daemon crashed because of oom.
<Aurora_v_kosmose>Guess I'll have to give that VM some more.
<Aurora_v_kosmose>Not very impressed that a project is literally impossible to compile on 4GB of RAM. Ah C++...
<Aurora_v_kosmose>At least I can now confirm that was the only problem.
<atka>zram is your friend
<Aurora_v_kosmose>atka: Hm, I think it's enabled but worth doublechecking.
<podiki[m]>the_tubular: was a recent commit to add some colors
<the_tubular>Nice :)
*the_tubular Likes color in his terminal
*the_tubular Dislikes color in his logs
<apteryx>what does 'kernel-loadable-module-service-type' does that the 'kernel-loadable-modules' operating-system field doesn't?
<apteryx>in other words, what is its purpose?
<Aurora_v_kosmose>atka: I sadly can't say if your advice helped, so far it hasn't risen past 11G and I bumped it to 12 earlier...
<atka>can you elaborate a bit? are you running zram in the container or on the host?
<Aurora_v_kosmose>atka: In the VM. I bumped its internal memory up (before enabling zram when you reminded me of it) and it hasn't yet used-up enough for zram to prove its mettle.
<atka>oh, still having memory issues? yet free ram?
<Aurora_v_kosmose>atka: More common than you'd think when dealing with VMs. Goes double when using Qubes.
<Aurora_v_kosmose>(Everything is VMs)
<atka>is your swap priority correct?
<atka>aka hit zram first before any other swaps?
<Aurora_v_kosmose>Right now it hasn't crashed again yet.
<Aurora_v_kosmose>atka: Yeah. And I now see that it finally finished building successfully.
<atka>so zram worked then?
<Aurora_v_kosmose>atka: Can't say, I increased the VM limits first (after the initial crash, I got annoyed) and enabled zram partway through (which didn't get used)
<atka>oh so probably not then, just allocating more ram was it probably
<Aurora_v_kosmose>At least, it didn't get used according to htop's zrm & swap counters.
<atka>anyway, love me some zram
<Aurora_v_kosmose>Yeah.
<Aurora_v_kosmose>It had been somewhat a while since I bumped into this sort of problem.
<Aurora_v_kosmose>Used to be a constant concern with my previous one, so I got a chunker filled with memory after that.
<atka>its saved my butt a few times, still only rock 8gb and usually get a 2:1 or better compression ratio using zstd
<Aurora_v_kosmose>Not bad
<apteryx>I guess answering my earlier question; the purpose of 'kernel-loadable-module-service-type' is that is can be used to extend the 'kernel-loadable-modules' operating-system field through services.
<atka>apteryx: good to know, thanks for digging
<Aurora_v_kosmose> https://github.com/kaldi-asr/kaldi/blob/master/src/base/get_version.sh Should I just create the output file in Guile or should I replace mktemp with something else & invoke it?
<raghavgururajan>Hello Guix!
<efraim>o/
<atka>\o
<devmsv>\O/
<atka>|o|
<florhizome[m]><florhizome[m]> "how is shepherd supposed to be..." <- Good morning guix... Any takers ;)
<maximed>Time travel (and presumably pulling) from v1.1.0 --> current guix is broken, see <https://issues.guix.gnu.org/53496#4> for bug report + fix
<unmatched-paren>how could i install a 32-bit gcc-toolchain on a 64-bit machine with guix? i'm guessing there's some `--target` flag, but i can't see any in `guix install --help`
<florhizome[m]><florhizome[m]> "Good morning guix... Any takers..." <- I overlooked an error msg at the end of guix home reconfigure:
<florhizome[m]>(vague translation) here: exception error during the execution of „load“ with the service „root“
<florhizome[m]>In procedure fport_write: I/O error
<mike2376>How often should I run guix pull?
<unmatched-paren>mike2376: guix will start begging you to pull after a few days of not pulling
<itd_>nckx: a bit late (had to go, sorry), still: thanks for the feedback on the python-mypy patch :) (didn't manage to update bug#54376 in time, but will try to keep it in mind for next time)
<efraim>I reconfigure my machine once a week but update my packages daily
<Guest11>Hi guys, installing and using guix (as pkg manger) from fish caused me loads of headache, question is ... is it even supported? BTW, it works fine from BASH.
<efraim>using fish with Guix isn't as well tested as bash
<Guest11>It's actually close to being compatible with fish, the only issue I see is guix assumes bash syntax when generating profiles, and when fish tries to import it it fails, other stuff (hints thrown by guix) actually work by converting them manually to fish syntax.
<nckx>Hi Guix!
<sneek>nckx, you have 1 message!
<sneek>nckx, podiki[m] says: the kernel option did the trick, can mount ext4 with casefolding now; thanks!
<nckx>Great!
<Guest11>... Example when trying to import the below fails:
<Guest11># Source this file to define all the relevant environment variables in Bash
<Guest11># for this profile.  You may want to define the 'GUIX_PROFILE' environment
<Guest11># variable to point to the "visible" name of the profile, like this:
<Guest11>#
<Guest11>#  GUIX_PROFILE=/path/to/profile ; \
<Guest11>#  source /path/to/profile/etc/profile
<Guest11>#
<Guest11># When GUIX_PROFILE is undefined, the various environment variables refer
***ChanServ sets mode: +o nckx
<Guest11># to this specific profile generation.
<Guest11>export PATH="${GUIX_PROFILE:-/gnu/store/fh7x1rdxkksfxjl4yzj92rih13f8zd0c-profile}/bin${PATH:+:}$PATH"
<nckx>Guest11: Please use a pastebin for messages > ~3 lines next time :)
<Guest11>Thanks :-)
<nckx><guix assumes bash syntax> Hmm, can you give an example? I'm not aware of bashisms being required anywhere. The code generated by Guix should be compatible with any sane POSIX shell.
<nckx>Or maybe that's the problem, I don't use fish.
<Guest11>That's the problem, fish is not fully POSIX compliant.
<nckx>Well, files need to have *a* syntax…
<nckx>Does it have a ‘POSIX mode’?
<philofosser>If you're using fish, I'd recommend keeping dash or bash as your default shell so you can run scripts still.
<philofosser>You can still have fish set as your login shell.
<nckx>Yeah, dash is my go-to quick POSIX test shell. It's nice.
<Guest11>nckx: no posix mode!
<philofosser>I'm not a fish-convert yet, but I've given it a go. You can have dash as /bin/sh and the script's shebang should make sure it's evaluated properly.
<philofosser>If it's critical, there's a fish module that can call a script evaluated in another POSIX shell and then import its environment to fish.
<philofosser>Forgot what it's called, but it exists.
<Guest11>It fails when exporting a profile env variable.
<Guest11>which assumes posix shell.
<Guest11>e.g. curly braces
<philofosser>Yep.
<philofosser>which is why I mentioned there's a module which can accomodate.
<Guest11>> Forgot what it's called, but it exists.
<Guest11>Hmmmm, interesting, I'll try and find it
<nckx>There's no reason you have to use the same shell interactively as the one that's used to load configuration files.
<philofosser>Found it in my guix time machine. It's fish-foreign-env
<Guest11>but doesnt the guix command rely on those exported variables when doing certain actions?
<nckx>Nor should tools like Guix include/generate N configuration files for each weird shell the user *might* use. These files don't configure your shell, after all.
<Guest11>nckx ^
<nckx>They configure your environment, which is shell-independent.
<Guest11>philofosser: Thanks, I'll check it out .
<nckx>Guest11: Yes.
<nckx>You should make sure that they are set.
<Guest11>nckx: Hmmm, good point! I think I know why I messed up, I used .bashrc, maybe that's why.
<nckx>I'm not saying you messed up!
<nckx>Well, maybe you did, I dunno 😛
<nckx>I kind of get the assumption that ‘your’ shell has to load them because they are ‘shell’ scripts. Shell scripts, shell variables, environment variables, … are so closely associated in most people's minds that it's hard to separate them. But they are separate.
<nckx>itd_: That's all right, it was mainly a future suggestion anyway. Thanks!
<nckx>Hmm, the ‘all Firefox/IceCat tabs crash when swaylocks my screen’ bug is back after a two-month holiday.
<nckx>Does this happen to anyone else?
<nckx>I'll try updating FF to 98.0.
<MysteriousSilver>can multiple patches (0001, 0002 ...) be sent in a single email or are they supposed to be sent separately?
<lilyp>Supposed separately, but reviewers are kind and will accept attachments too.
<nckx>MysteriousSilver: Please send them separately, like ‘git send-email’ does.
<MysteriousSilver>will do
<nckx>($nobody sends these things by hand ☺
<nckx>)
*MysteriousSilver hasn't configured git-send-email yet
<singpolyma>MysteriousSilver: with guix, make sure you send a single email first to get the bug number, then you can git send-email do that
<MysteriousSilver>thanks
<nckx>If we're going to back up that far, please read <https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html> if you haven't yet.
<nckx>There are some other desired behaviourals there.
<MysteriousSilver>yup, i mostly send single commit patches so there wasn't a need to setup git-send-email but i'll do now
<nckx>It's not a requirement, to be clear, it just saves you trouble in the long run.
<joe153>why cant i install gimp? i get a error package gimp 2.10.30 dosent support i686-linux
<ngz>joe153: gimp relies on librsvg, which is Rust-based. And Rust doesn't support i686, I think.
<ngz>Since SVG support is optional, it may be possible to build a gimp-no-librsvg package and remove that dependency locally, using package transformations.
<maximed>ngz, joe153: look for 'librsvg-for-system'
<maximed>it points to a non-Rust version of librsvg on non-x86_64 systems
<ngz>Then gimp may need to use this.
<jlicht>guix home container is very nifty
<jlicht>also, hello guix!
<joe153>but gimp works on devuan just fine
<joe153>i686
<maximed>joe153: Perhaps Debian has configured Rust appropriately to make it work on i686 as well?
<maximed>See <https://github.com/thepowersgang/mrustc/issues/78> for the current status of i686 Rust on Guix
<joe153>why does guix pull take so long and it stalls?
<MysteriousSilver>nckx: turns out i had already configured git-send-email years ago but never used it
<maximed>joe153: Among other things, some slowness is caused by the large closure of (gnu packages base)
<maximed>joe153: Also, there was some issue with some rust-*.scm being ‘too’ large, preventing uses of fixnums, so if these rust package files were split off, there could perhaps be some performance increases in that area
<maximed>That happened on 32-bit arches, not 64-arches
<joe153>i dont know why but guix pulls stalls and cpu usage drops form 100%
<maximed>joe153: In my experience, it can be slow, but eventually it will succeed
<maximed>have a look at channels-with-substitutes-available
<joe153>how offten should i run it?
<maximed>* channel-with-substitutes-available
<MysteriousSilver>nckx: works smoothly :)
<maximed>If you use that (and enable substitutes), "guix pull" will be faster because it can reuse things from the build farm more often
<maximed>joe153: As often as you want updated packages, and when there are security updates or other important fixes
<maximed>I suppose once a week might be sufficient in practice, and more frequently when there are security fixes
<nckx>joe153: WDYM 'stalls'?
<nckx>MysteriousSilver: Thanks for the patches!
<MysteriousSilver>happy to help
<MysteriousSilver>in guix-days, there was a talk mentioning that the patch review system was being automated (ci and checks), is there any progress in that field?
<joe153>nckx cpu usage drops form 100% to 10% and its stuck at the same percentage
***sneek_ is now known as sneek
***f1reflyylmao is now known as f1refly
<civodul>o/
*civodul wrote a draft post introducing Guix Home: https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/home.md
<civodul>feedback welcome!
<fnstudio>hi, i'm trying to give qmk a go (tool to build custom keyboard firmware); i've followed these instructions https://docs.qmk.fm/#/newbs_getting_started
<fnstudio>after setting up my environment, i get "fatal error: avr/io.h"
<fnstudio>avr-libc doesn't seem to be reported as a dependency by the qmk folks, but it seems to me that that's the most sensible place to look for io.h
***rekado_ is now known as rekado
<fnstudio>now, i don't see avr-libc in guix, i think? any hints on how that can be packaged? is there a way of "importing" it as you'd do with a python package?
<nckx>joe153: Guile's CPU usage? I haven't seen that, if it's not waiting on random (which Guix likes) or network I/O.
***irfus- is now known as irfus
***yjftsjthsd30 is now known as yjftsjthsd3
<devmsv>Hi, Im installing guix on a Chromebook. Installers boots fine and I have manually install the system. The problem is, when booting it gets stuck with boot grub background.
<devmsv>I have disabled quiet on grub still no output
<fnstudio>civodul: not (yet) a guix home user here, but FWIW i read the post and it looks very good to me! i'll be certainly referring to it soon, step by step, so thanks for that
<fnstudio>re my question above, now reading this https://guix.gnu.org/manual/en/html_node/Invoking-guix-import.html
<fnstudio>hm no, i don't think guix import would help with avr-libc; but i guess i can take inspiration from a similar package, maybe avrdude
<vagrantc>is avr-libc it's own upstream?
<vagrantc>or do you just need a crossbuilt glibc for avr?
<vagrantc>fnstudio: there is an avr-libc in gnu/packages/avr.scm
<fnstudio>vagrantc: ouch... i'm not... sure - i get an error when trying to use qmk (a keyboard firmware builder) and i think there's this io.h file that's missing and i see it's in avr-libc
<fnstudio>vagrantc: oh thanks, let me see - although that's for avr-toolchain
<fnstudio>and avrdude
<fnstudio>which, apparently, are two other dependencies
<fnstudio>hey, you're right... i see avr-libc... it's there
<vagrantc>guix edit PACKAGE :)
<fnstudio>yeah... exactly
<fnstudio>i can see it
<fnstudio>but... if i guix install it i get an error: guix install: error: avr-libc: unknown package
<nckx>devmsv: Try adding ‘nomodeset’ to the same kernel command line.
<fnstudio>ah... i see it's defined with define as opposed to define-public
<jlicht>civodul: In case you did not read it, thank you very much for `guix home container'
<vagrantc>fnstudio: would think you could still include it in your package definition
***sneek_ is now known as sneek
<vagrantc>or there's some guile incantation to actually use that package if you're not using a package definition
<fnstudio>vagrantc: yeah, i'm shamelessly monkey-copying the definition in my personal file, shall i rename define to define-public?
<jlicht>fnstudio: it doesn't hurt, but it only makes sense if you are planning to put your personal files in 'proper' guile modules
<fnstudio>jlicht: oh i see, but then - purely out of curiosity - why i'm not able to guix install the definition that's in avr.scm? i thought that was because it's missing the define-public?
<devmsv>nckx: same result. I'm to try to configure the same kernel and initramfs as the installer iso
<jlicht>fnstudio: You could put your personal files into a channel, or put their location in GUIX_PACKAGE_PATH, or add their location via `-L` to some guix commands; Are you familiar with how guile modules work?
<fnstudio>jlicht: i wouldn't say familiar, no, but i've been creating some simple packages and i use -L to build them
<fnstudio>and yes, i have a personal channel for this
<nckx>devmsv: Which installer ISO?
<jlicht>fnstudio: In that case define-public might (should?) help! Sorry for adding to the confusion here
<fnstudio>i seem to need avr-libc (not even completely sure...) and i've just copied the avr-libc definition from upstream (avr.scm) to my channel
<fnstudio>jlicht: absolutely no confusion, contrarily, thanks for helping!!
<devmsv>nckx : the one from here https://guix.gnu.org/download/latest/
<fnstudio>ouch, so i was able to install avr-libc but that didn't help with my qmk error: fatal error: avr/io.h
<jlicht>civodul: RE the blog post, "ten-year birthday" seems a bit weird to me; I'm not quite sure how to improve it though ("10 year anniversary", "10th birthday", or perhaps just "Guix will turn 10")
***philofos` is now known as philofosser
<nckx>++, ‘Tenth birthday’ would be idiomatic.
<nckx>devmsv: Thanks. As you can see here <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/install.scm#n445> the installer doesn't use a custom kernel or initrd, so that's odd.
<nckx>Hmm, Chromebooks, they use Coreboot, right?
<nckx>There was a kerfuffle with the Coreboot framebuffer driver. It was added to the default kernel for a while, then (probably rightfully) removed because it was added in a way that was hard to maintain older kernels.
<nckx>This sounds like that, again. ☹
*nckx has to go.
***Noisytoot_ is now known as Noisytoot
<devmsv>nckx: I ser. There is no indicator of initramfs either which I added to my installation because of recommendation of system init of addding some modules
<nckx>I'd comment out that field. Unfortunately the initramfs is too fragile when it comes to non-existent modules (and it's easy to type a ‘non-existent’ name because Linux module naming is zany).
***robin__ is now known as robin
<fnstudio>lol i decided to connect to the qmk discord channel and the most recent exchange i found there is exactly about my avr/io.h problem from someone who's also on guix
<fnstudio>there even seems to be a guix qmk repository https://github.com/sigprof/guix-qmk (released under gpl3 apparently), so that's promising
<civodul>fnstudio, jlicht: thanks for taking a look!
<fnstudio>np!
<civodul>yeah that last sentence needs to be tweaked
<Haider>I have a LSP config in guix and whist using the clangd language server, I get this error whilst hovering over #include<iostream>: "In included file: expected ';' after class"
<Haider>This does not happen If I use the ccls server however. (yes I am using c++)
<devmsv>nckx: nothing. I will try again mirroring install.scm bootloader and kernel config
<nckx>When you boot the installer image, does it also spend a very long time displaying the GRUB background during boot? That's pretty, but here I think it indicates the same issue, that if the installer were to crash during boot it wouldn't be able to display errors.
<devmsv>Yeah it displays GRUB background for sometime. I start seen text of the boot in the middle of the process
<nckx>Probably after the initrd loads extra modules.
<nckx>Meh, I need to find a way to get Coreboot FB support back in new kernels in a way that doesn't break old ones. This is unacceptable. We're punishing people who don't use (wholly) proprietary BIOSes.
<devmsv>I'm my laptop with efi coreboot it works perfectly. But on this Chromebooks the only thing supported is seabios
<devmsv>But how can the installer boot and not the installed system? Isn't there a workaround?
<nckx>I don't know either. I too would expect the installed system to boot if it's not overly customised.
<devmsv>Well now I'm trying to chroot from the USB to the installed system and chroot is segfaulting >.<
<ngz>Hmm, I think I spotted two bugs in "guix home import"
<Haider>guix bug report.
<Haider>That would happen, guix home is very new
<ngz>Yes, of course. I was just thinking out loud.
<nckx>guix: bug: command not found
<balbi_>hi folks, got a question here: I couldn't seem to find `rustup' available in guix. I'm trying to package it up, but before moving forward is there a reason why it's not in guix other than "nobody sent a patch"?
<nckx>Is it useful on Guix? Does it encourage installing non-free software?
<balbi_>rustup is just a tool to manage rust toolchains
<balbi_>you can choose and install toolchains for different targets
<nckx>‘Manage’ is doing a lot of unexplained work in that sentence.
<nckx>Yes, I assumed it was a package manager for Rust, hence my questions above, sorry, should have been clear.
<balbi_> https://github.com/rust-lang/rustup
<nckx>Uhm: why does ‘guix system image’ care about my /var, and worse, crash: https://paste.debian.net/plainh/fe5cc607
<nckx>So since it is a package manager, those are 2 reasons it might not be in Guix. ‘Not useful’ being relative, but the set of people able & willing to package things for Guix is the same set that doesn't care much for language-specific package managers.
<balbi_>nckx: it's not a package manager, though. It's a toolchain manager. It allows you to setup toolchain for e.g. aarch64-unknown-linux-musl and have cargo use it
<balbi_>cargo is more of a package manager, and that's already in guix
<nckx>s/package/toolchain/ is a bit pedantic, but fine. Substitute everything I said above with toolchain manager if it helps. Everything applies.
<nckx>I was just guessing at possible reasons to begin with.
<balbi_>nckx: the real question though: if I were to send a patch, would it be acceptable by guix? Or is there a hard rule that would prevent its inclusion?
<nckx>No, wait, it's just a package manager: ‘Rustup installs The Rust Programming Language from the official release channels, enabling you to easily switch between stable, beta, and nightly compilers and keep them updated. It makes cross-compiling simpler with binary builds of the standard library for common platforms.’
<balbi_>nckx: yeah, just the toolchain :) you can't install e.g. ripgrep or bat with rustup
<balbi_>nckx: that's something cargo handles
<nckx>Nor can you install htop.
<nckx>With cargo.
<nckx>Anyway.
<balbi_>nckx: cargo is rust-only, though.
<nckx>> Is it useful on Guix? Does it encourage installing non-free software?
<nckx>Example (1) is certainly not a blocker, (2) is.
<balbi_>it merely installs rust toolchains and let's you setup cross-compilation. As long as rust toolchains remain free, rustup will never be able to encourage installation of non-free SW
<balbi_>unless, of course, MIT and ASL2 are not considered free sw licenses
<nckx>But as binary blobs, right? Also not a blocker, but another culture mismatch.
<nckx>ASL2?
<nckx>= Apache?
<balbi_>apache
<balbi_>yes
<nckx>That's Free AFAIK.
<nckx>Another reason could be that packaging anything non-trivial written in Rust is generally unpleasant busywork.
<nckx>But from what I've read about rustup during this very brief convo, I don't see a reason why such work would be rejected.
<balbi_>nckx: both asl2.0 and mit are part of guix/licenses.scm
<nckx>I thought you were joking.
<nckx>Yes, of course they are fine :)
<balbi_>nckx: it was sort of a joke, yeah... but since you asked ;)
<nckx>It could suggest zomg-faster-nonfree-linker or icky-proprietary-runtime, I dunno.
<nckx>The thing being Free doesn't mean it only downloads Free things.
<balbi_>nckx: as of now, it only downloads upstream rust toolchains. AFAICT, there's a single implementation of the rust language. Perhaps we reconsider rustup's suggestions of non-free SW if we ever come to that?
<nckx>Sure.
<nckx>BTW I was just asking, it wasn't an accusation.
<nckx>It's one of the common reasons is all.
*nckx → food o/
<balbi_>nckx: no worries :) didn't take it as an accusation :)
<balbi_>anyway, next question. rustup wants a very specific version of rust-home, in fact its Cargo.toml points to a very specific commit of the repository. This means that during build phase, cargo will try to fetch that git repository, which doesn't appear to be allowed during build. Is there a way around that? I'm assuming the only solution would be package that particular version of rust-home and patch Cargo.toml before build phase to refer
<balbi_>to that packaged version. Is that the right approach?
<unmatched-paren>why is guix home rejecting my ~/.config/sway/config? https://paste.debian.net/1235049/ it throws an error message "error: invalid character `\n' in name `<the entire file>'"
<unmatched-paren>ah -- i should have been using text-file
<unmatched-paren>sorry, plain-file :P
<maximed_>fnstudio: You cannot install 'avr-libc' because it is not exported
<fnstudio>maximed_: hey thanks
<maximed_>Even if it was exported, installing it probably wouldn't make much sense, unless you're on an avr system
<fnstudio>hm, i see...
<fnstudio>yeah as a matter of fact i tried but that didn't help, you're right
<maximed_>Basically, if you do "guix install foo", it will compile foo for the architecture on which you are using Guix
<maximed_>fnstudio: Have a look at 'avr-toolchain'
<maximed_>It is a GCC cross-compiler for avr, and apparently includes 'avr-libc'
<fnstudio>i'm having a look at this, who apparently should produce a working build of qmk on guix https://github.com/sigprof/guix-qmk/blob/main/guix-manifest.scm
<fnstudio>*which
<fnstudio>i had avr-toolchain installed already when i tried earlier but that didn't help
<fnstudio>although, my attempt was a combination of avr libraries installed via guix and the python qmk tool installed via pip
<maximed_>fnstudio: Question: do you _currently_ have avr-toolchain installed, and what does "echo $CROSS_LIBRARY_PATH" output?
<fnstudio>let me see
<maximed_>Also, do you have some more context for "fatal error: avr/io.h"? It doesn't look like an error message from GCC, IIRC GCC would say something like "header <foobar> not found in directories X, Y, Z, W ... included from A B C D ..."
<fnstudio>maximed_: avr-toolchain is installed, the env var is empty
<maximed_>fnstudio_: Try logging in and out again (environment variables cannot be defined retroactively)
<maximed_>Alternatively, instead of installing avr-toolchain and friends, you can work with "guix shell --pure avr-toolchain other-stuff ..." (the --pure avoids potential interference from stuff in ~/.guix-profile, like, say, non-avr libraries)
<fnstudio>maximed_: thanks for all your advice, here's the full error https://paste.debian.net/1235052/
<fnstudio>ah... interesting re the env var and logging in/out, let me try that
<maximed_>If that doesn't work, I suggest working in a pure environment (using guix shell or the like), to reduce the number of variables that might cause problems
<maximed_>hm, seems like "fatal error" comes from GCC anyway, seems like I misremembered
<fnstudio>yeah... with regard to guix shell that's what i usually do... but... i was worried that could be get in the way of my python virtual environment (as i said, after a first failed attempt at building everything, i thought of going for installing qmk from pypi)
<fnstudio>do you think i can still try guix shell even if using a python venv?
<maximed_>fnstudio: "python venv" probably uses environment variables, so probably not, unless you do the python venv stuff inside guix shell
<maximed_>though I'd think that using yet another package manager (pypi) would make things more complicated, not less
<fnstudio>yeah i totally agree re the venv; in fact, i was right in the middle of trying and building everything in guix
<fnstudio>so, i'll first sort the qmk stuff out, by creating the guix definitions
<fnstudio>then i'll try debugging the issue with the avr missing library, possibly trying the pure shell to see if that sets the env var that you mentioned
<fnstudio>i'll keep you posted if i see you around
<fnstudio>tx for now
<unmatched-paren>hm, i can't seem to figure out how to pipe my nvim config through fennel in my ~/.config/guix/config.scm
<maximed_>civodul: The mcron job specification mentioned in the draft is broken if $HOME contains a space
<unmatched-paren>so far i have this: https://paste.debian.net/1235054/
<unmatched-paren>but fennel tries to read from the real stdin, not the pipe
<maximed_>I think something like #~(job ... (invoke #$(file-append ...) "-o" (string-append (getenv "HOME") "/.idutils/src.db" ...)) is needed here, except for that (probably) being invalid mcron?
<maximed_>civodul: Would it be better for "rm" in "rm --one-filesystem" to be absolutised, to avoid depending on $PATH?
<maximed_>civodul: Does the 'home-redshift-configuration' support latitudes and longitudes passed as exact rational numbers? Does it properly error out in case of complex numbers or strings?
<unmatched-paren>(I am aware that using my text editor's plugin manager on Guix is heresay.)
<unmatched-paren>(I will remove packer.nvim Soon[tm], once i can be bothered to make a function that generates a package for a neovim plugin.)
*the_tubular Wishes he understood those new guix home commits
<unmatched-paren>i got it working :D
<unmatched-paren>i had to replace `read` with `read-string` and `write` with `display`
<ngz>civodul: I think first "+" in alias-rx should be non-greedy. Do you want me to change it?
<civodul>ngz: sure
<civodul>how would you change it actually?
<ngz>I assume it is +? instead of +
<ngz>I didn't check, I am just extrapolating Emacs knowledge here :)
<f1refly>can I define specific keyboard layouts per user account?
<the_tubular>Is that regex ? That would work
<civodul>ngz: "+?" is a thing?
<f1refly>I use an uncommon layout, but my girlfriend will share the machine for the next weeks and she needs a standard layout. So I'd need to have qwertz system wide, but something else for only my own user
<euandreh>IIUC, Guix the package manager runs on Raspberry Pi (ARM), but Guix System doesn't. Is that right?
<civodul>euandreh: the problem is that each ARM box has its own boot method, unlike PCs
<civodul>there are definitions for various boards, but i'm not sure about this one
<ngz>civodul: According to the Guile manual "there is no support for “non-greedy” variants of ‘*’, ‘+’ or ‘?’.". So I guess the answer is "no". Hmmmm…
<f1refly>or would I just set the layout in my X initialization script on login?
<civodul>ngz: ah, but actually, do you have an example string where the current regexp would fail?
<euandreh>civodul: ack, I'll go after some more info on that
<ngz>civodul: Certainly: alias ls='ls --color=auto'
<civodul>euandreh: you can check under (gnu system images *)
<civodul>ngz: i think that's fine, that's what the new test in tests/home-import.scm checks
<civodul>the 'grep' alias, specifically
<ngz>Oh. I tested a few hours ago and it failed. Hmmm
<euandreh>civodul: ty
<civodul>ngz: same here; i noticed the bug while preparing the blog post :-)
<ngz>civodul: OK. Fix confirmed. I have another strange issue, tho.
<ngz>civodul: I have (don't judge me) alias vi="emacsclient -t -a ''"
<ngz>civodul: It becomes ("vi" . "emacsclient -t -a '\\'''\\''")
*the_tubular judges ngz
<ngz>hehe
<civodul>ngz: yeah well, i think the code remains pretty naive
<civodul>it gets actual aliases from the output of "bash -c alias"
<civodul>and bash uses single quotes unconditionally, with these special escapes
<civodul>ideally, we'd parse the escapes or something
<civodul>but... that is left as an exercise to the bug reporter :-)
<ngz>I see :)
<unmatched-paren>can i manage my channels with my home config in any way except the obvious 'use `plain-file` with the channel configuration you want'?
<civodul>unmatched-paren: nope, so far it's as you describe
<unmatched-paren>ok
<unmatched-paren>couldn't we add a `home-channels-service-type`?
<civodul>yes, we could do that
<unmatched-paren>i'd probably be able to add that
<civodul>i thought we had that for Guix System, no?
<civodul>can't find it
<unmatched-paren>the only home-service that mentions channels is `home-provenance`, and i'm not entirely sure what it does from the description
<ngz>civodul: silly question: since Bash uses single quotes unconditionally, why do we match against " or ' in the alias-rx regexp?
<civodul>ngz: ah that's a good question; actually the previous regexp accepted double quotes, so i kept that
<civodul>it *seems* Bash uses single quotes unconditionally but i didn't check the code
<ngz>OK. It doesn't hurt anyways. It is just less pretty.
<civodul>yeah
<fnstudio>maximed, i've eventually managed to create a definition for qmk, and i can start it in a pure guix shell; i'm now fixing some missing dependencies (because of "--pure")
<fnstudio>which i think i can sort out
<fnstudio>but i read here https://github.com/sigprof/guix-qmk/blob/c247702c24c0129fbaa66c741c5a313ee0e606e5/guix-manifest.scm#L292 that this might be related to a broader problem, so i'm not very hopeful
<fnstudio>and this https://issues.guix.gnu.org/issue/39794#8
<maximed>fnstudio: I thought you were only using a single cross-compiler at the time?
<fnstudio>maximed: ah! it worked!! i'm so happy - i did how you said, i.e. i used "guix shell --pure <avr-toolchain-and-other-dependencies>"
<fnstudio>from within that env i can launch qmk to compile my keyboard firmware
<fnstudio>and i no longer receive the avr/io.h missing error
<fnstudio>this is incredible :)
<fnstudio>(easy to recognise a happy guix user when you see one ^)
<atka>how to search for a utilitie's parent package with guix?
<atka>s/utilitie's/utility's dummy
<atka>for instance, can I check what package contains dig
<ngz>It is not possible at the moment.
<atka>oh that's a bummer
<ngz>atka: well, using "guix search dig dns" will give you the correct answer