IRC channel logs


back to list of logs

<KE0VVT>rekado_: Given a plain (service tor-service-type) in the above config, same result
<KE0VVT>shepherd: Service term-auto could not be started.
<unmatched-paren>huh gnu/packages/rust.scm doesn't look nearly as complex as i thought
<unmatched-paren>this will likely still be painful :p
<unmatched-paren>mostly because rust takes five decades to build itself...
<KE0VVT>Hm, I guess I can't have both Telegram and Gajim installed...
<singpolyma>unmatched-paren: more cores needed?
<unmatched-paren>I have 8 cores, i hope that's enough
<NicholasvonKlitz>does anyone have any guix emacs tips? I have geiser installed, but have trouble looking up symbols to better understand what different functions do
<unmatched-paren>wait no, 8 logical cores i think
<unmatched-paren>4 physical
<unmatched-paren>hmm when gnome settings says 'x 8' does it mean logical or physical? i'd guess physical...
<NicholasvonKlitz>`geiser-edit-symbol-at-point` just tells me that the symbol can't be found if it is guix specific, rather than guile in general
<slyfox_>even on 16 cores building the whole rust chain is very slow :( i had a mistake of tweaking libffi locally to find out :)
<rekado_>KE0VVT: huh, it works for me :-/
<KE0VVT>rekado_: There must be something wrong with my config.scm. :(
<unmatched-paren>slyfox_: sounds like a lovely experience :D
<unmatched-paren>wish me luck... i doubt this build will work since i think they added a few things in later versions to accommodate for rust 2021
***slyfox_ is now known as slyfox
<unmatched-paren>hmm no such file or directory: "vendor/jemalloc-sys/jemalloc"
<unmatched-paren>i'm guessing that's to do with them removing jemalloc
<unmatched-paren>i can't find the blog post about it :/
<unmatched-paren>The rust packages seem to all inherit from the last, and one deletes those directories; how would i remove that while still keeping the rest of the inheritance?
<KE0VVT>Noisytoot: I don't get how you can get Tor to work.
<rekado_>it just works for me. No extra setup was needed.
***sneek_ is now known as sneek
<KE0VVT>rekado_: maybe i can run your config
<rdrg109>[Q] I have installed guix using the guided graphical installation. Everything worked fine. I got the sucessfull screen with the "Reboot" button on it. However, when I reboot my system, the grub shell is shown and I don't know how to boot into Guix. What could I have done wrong? I'm asking because I'm going to try to install it again.
<rdrg109>Additional information: When I execute "boot" in the grub shell, I get "error: you need to load the kernel first"
<unmatched-paren>Try mashing F12 as your computer boots to enter the boot menu. Exactly this issue happened to me when I installed.
<unmatched-paren>I think it happens if you already have a gnu/linux in your system
<unmatched-paren>It doesn't format /boot/efi in the installer by default, so the old boot entry remains, but it doesn't go anywhere
<unmatched-paren>Thus the shell
<rdrg109>I had Ubuntu 21.04 installed so you might be right
<unmatched-paren>You'll need to install again, but this time in the graphical installer when the partition menu appears, select the /boot/efi partition and change 'format' to 'true' or something
<rdrg109>unmatched-paren: Ok, I'll try that
<unmatched-paren>Rustc is compiling... the suspense.....
<unmatched-paren>AAAAnd... errors do their errory things :)
<unmatched-paren>Luckily I know exactly what is going on here
<unmatched-paren>There's errors about iterators, because rust 2021 fixed a long-standing issue with iterators
<unmatched-paren>You could iterate over an &[] but not an []
<unmatched-paren>Since rust < 1.56.0 does not have 2021 as an option, the issue is still there
<unmatched-paren>So... i'd better compile 1.56.0 instead of 1.56.1 :)
<KE0VVT>When I install and run Tor as my own user, I get this message:
<KE0VVT>I mean
<lfam>Do we have any package definitions for C programs that don't have any Makefile or other build scripts?
<lfam>I'm looking to copy a package definition that invokes the compiler directory
<lfam>The compiler directly
<vagrantc>(replace 'build ... (invoke compiler arg1 arg2)) ?
<sneek>Welcome back vagrantc, you have 1 message!
<sneek>vagrantc, rekado_ says: I haven’t tried the guix.deb; I just use the script at — the key was to use separate partitions for source and target… :)
<vagrantc>rekado: oh, yeah thatd do it :)
<GNUtoo>apteryx: thanks. When cross compiling is it supposed to be the target profile or can it be (because of a bug) the host profile?
<lfam>vagrantc: Yeah... I'm just hoping to avoid coming up with values for arg1 and arg2 ;)
<vagrantc>lfam: you could alternately just patch it to include a makefile ...
<vagrantc>lfam: i mean, what are the instructions to build it? obviously it should have all the arguments you need to pass ...
<vagrantc>lfam: oh, you mean the guix-specific arguments and whatnot ...
<KE0VVT>Ate and drank tea. Still frustrated. :-(
<KE0VVT>Dumped a bunch of info to
<apteryx>lfam: look at the one for the program 'building' our nss-certs
<apteryx>it's a simple C program
<apteryx>GNUtoo: it should be the target profile; I've never tried though!
<apteryx>sneek: later tell civodul if you use the last commit of mrustc, it nearly builds on i686 but fails because librustc wants to use too much memory:
<sneek>Will do.
<TheNewGuy>Hello all! (Hopefully) potentially new Guix user here. I'm trying to install Guix from USB on a Librebooted Thinkpad X200 using the graphical installer, but it crashes to a black screen and loops right after selecting a guided partition, with or without encryption. I have tried a few different settings going through the installer and it doesn't
<TheNewGuy>seem to make a difference. I couldn't find anyone having the exact same problem on the issues page either. I'd appreciate any ideas!
<patched[m]>Have you tried the latest image rather than the stable? It solved another bug that made it impossible for me to install
<TheNewGuy>Hmmm, let me find it and report back.
<podiki[m]>apteryx: I think I found the fix for geeqie (at least the not starting clutter error)
<TheNewGuy>I'm back! Unfortunately I had the same problem with the latest .iso, after choosing to "Install everything in one partition," the screen goes black and takes me back tot the start of the installation process without actually doing anything :(
<TheNewGuy>Found an issue from May, it doesn't look like the problem was ever figured out.
<podiki[m]>sneek later tell apteryx I sent a potential source patch (from upstream) for geeqie, hope that fixes the clutter startup error
<sneek>Will do.
<podiki[m]>TheNewGuy: I also ran into the partitioning part being rather brittle in the summer
<podiki[m]>it was better behaved if i made sure the disk was completely wiped of partitioning information (some left over from previous failed install did not go well), and on a later reinstall I did the installation manually
<podiki[m]>(including partitioning)
<KE0VVT>Gonna smoke some pot. This Tor thing is grating on me.
<TheNewGuy>podiki[m]  I'll wipe the disk and try manual install then. Thank you!
<podiki[m]>TheNewGuy: good luck! manual install is not bad at all, the only tricky thing is doing the system configuration file if you are not as familiar
<podiki[m]>I'm not sure if you can just skip the partitioning step in the installer easily, maybe someone here knows
<KE0VVT>The thing that trips me up on the manual is the UUID.
<podiki[m]>given installer difficulties and how different someone may want to partition, I think having the ability to keep partitions as is would be good (unless I missed that option...)
<TheNewGuy>Hopefully I can figure it out through the documentation, otherwise I'll probably be back :P
<podiki[m]>you can always change the configuration later :-) as long as you have the basics to boot
<podiki[m]>so I'd focus on the filesystems and boot pieces especially. it is pretty readable and there are examples
<KE0VVT>Are you talking about keeping /home/ in place?
<TheNewGuy>Well I'll go give it another crack, hopefully third time's the charm. Thanks for the help!
<podiki[m]>good luck!
<patched[m]>You could also try to do a clean ext4 partition on the disk beforehand, and tell tell the installer to use that as /
<KE0VVT>podiki[m]: I saw you're the Arch guy that got on Hacker News.
<podiki[m]>hahaha "the arch guy" :-)
<apteryx>lilyp: why do you consider that "keeping the old emacs as-is" the correct behavior? I'd have thought discovering the newly installed Emacs packages (in the profile it's working from) could be automatically picked up by running our package loader entry point (guix-emacs-autoload-packages)
<sneek>Welcome back apteryx, you have 1 message!
<sneek>apteryx, podiki[m] says: I sent a potential source patch (from upstream) for geeqie, hope that fixes the clutter startup error
<podiki[m]>(my laptop and Pi homeserver are still on Arch still)
<KE0VVT>Do I need to put "tor" in "(use-service-modules)"?
<KE0VVT>podiki[m]: Tell me if the Pi goes OK. Maybe I could run a Kodi box with Guix instead of LibreELEC.
<podiki[m]>KE0VVT: I don't plan on trying it anytime soon, mostly because reproducing the set up would take some doing (since it is not a simple guix config.scm); also not sure how well guix runs if at all on a pi?
<podiki[m]>KE0VVT: on use-service-modules I would think so? or networking? (since that is where it is defined)
<KE0VVT>Yeah, I'm leary about putting Guix on a Pi.
<KE0VVT>I worried that it is in "networking". :-(
<podiki[m]>though you might not need to? since default %desktop-services has things from networking too
<vdv>do you plan to put guix system or just guix on the pi?
<KE0VVT>vdv: I always thought putting Guix on a Pi would be a scary thing, but now I'm thinking about it, and I wonder what it would be like.
<podiki[m]>for me I don't have a current plan with the Pi and guix; i guess first I would try as package manager and see how that goes
<vdv>don't think it would be scary, just don't let it build anything or it needs a few days to compile things :D
<vdv>you could run the daemon / guix system and deploy from your notebook via guix-deploy , so the config is build locally and sent via network
<vdv>but i haven't build a working sd-image. Let me know if you success in running guix system on it :)
<KE0VVT>podiki[m]: Can you use Tor?
<podiki[m]>KE0VVT: won't have a chance to try right now, but I'll let you know
<vdv>anyone knows how to use package-input-rewriting in a inherited package?
<vdv>or do i have to use alist-delete and then add it in inputs?
<vdv> (inputs (alist-delete "guile"(package-inputs gdb)))
<vdv>ah this :)
<KE0VVT>Hm, my mailing list message does now show up.
<vagrantc>might need to be moderated if you're not subscribed
<vagrantc>(at least for the first posts)
<KE0VVT>I thought I was sub'd, but maybe not.
*vagrantc refrains from making more wild guesses :)
<vagrantc>if it stll doesnt show in ~24 hours ask again
<Karthik[m]>vagrantc: thanks for the guix Debian package!
<vagrantc>Karthik[m]: glad it's helpful!
<apteryx>sneek later tell zimoun: -p, --procs {N|auto} Integer value N launches N additional local worker processes -> so it's zero based, not one based :-)
<sneek>Will do.
<apteryx>we have to (1- parallel-jobs)
<rdrg109>Third attemp to install Guix: Now I'm getting "Operating system not found" even though the installation was successfully completed. This time I did what some other used recommended me: reboot the efi partition. When I didn't format the efi partition, I was brought to the GRUB shell.
<M6piz7wk[m]>rdrg109: FWIW when that happened to me using the forsaken channel i just used the installer to generate the config.scm file and then ran `guix system init -f file /mnt`.. it's probably a good idea to also chroot in and run `guix pull` bcs the installer doesn't do that for some reason
<M6piz7wk[m]>oh `guix pull` prior to `guix system init` should make an updated guix install 🤔
<Karthik[m]>vagrantc: It literally saved many manual installation steps to go through, paving the way for guix adoption. Your work is great!
<rdrg109>M6piz7wk[m]: Are you sure the command is "guix system init -f file /mnt"? I'm asking this because my guix complain that "f" is an unrecognized option.
<rdrg109>M6piz7wk[m]: Oh, found it: guix system init my-os-config.scm /mnt from:
<M6piz7wk[m]>you just found it when i did x.x
<M6piz7wk[m]>sorry for giving you wrong command u.u
<M6piz7wk[m]>or.. i will hide by "it was intended!" so that you get used to reading the manual :p
<M6piz7wk[m]>so that i can maintain that i don't do mistakes~
<M6piz7wk[m]>also probably do `guix pull` prior to that command
<M6piz7wk[m]>so that you get up to date repos and stuff
<M6piz7wk[m]>as the installer images are by design outdated so that they are reproducible for issues
<vdv>i try to inherit a package and try to overwrite an input via (inputs (alist-delete "wayland" (package-inputs "wayland-new"))) but the compilation complains that a dependency of the inherited package is missing
<ns12>Hello, how do I automate binary installation of the Guix package manager? (
<vdv>it seems like the rest of the list is ignored
<ns12>./ needs manual human intervention to respond to at least two prompts.
<rdrg109> /b #gentoo
<rdrg109>Sorry for that message
<rdrg109>I have failed again with the installation. I have mounted the partition where "/" is supposed to be on to "/mnt". I executed "chroot /mnt", then I executed "ls", but I get "bash: ls: command not found". Is this an expected behavior?
<rdrg109>Additional info: I executed "find /mnt -perm /111 -type f -name 'ls'" and I got 2 lines: "/mnt/gnu/store/<<hash1>>-coreutils-8.32/bin/ls" and "/mnt/gnu/store<<hash2>>-coreutils-8.32/bin/ls".
<apteryx>is it me of 'guix build -f package.scm' is broken on core-updates-frozen?
<apteryx>ah nevermind
<apteryx>uh, why does this end up using python3 ?
<apteryx>(testing the case of someone on the guix-devel mailing list)
<apteryx>nevermind, it works now...
<ns12>Why am I getting these annoying messages every time I use Guix? "hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package and defining `GUIX_LOCPATH'"
<ns12>I have installed GNU Guix 1.3.0 Binary
<ns12>I have already set GUIX_LOCPATH and GUIX_PROFILE according to the documentation. And I have rebooted the computer. Why am I still getting these "hints"?
<ns12>And I have already installed glibc-utf8-locales.
<pingpongdull>what apllication run after login after booting linux
<xelxebar>pingpongdull: login to console? Whatever program the user's shell points to.
<xelxebar>pingpongdull: If you mean after logging in from a login manager, then it typically executes the window manager.
<cjtenny>hmm, emacs from guix is only using 16 terminal colors, even though it detects 256. emacs from debian (my guix host) is using all 256. this happens on the terminal emulator from debian and the same terminal emulator from guix. though the colors are *all* loading slightly different with debian emacs under guix vs debian terminal, probably due to slightly different terminal versions/builds. down the
<cjtenny>rabbit hole I go...
<pingpongdull>after login to desktop environment it takes lot of time to open screen
<apteryx>sneek: later tell civodul re gjs requirement mozjs/rust I'm sorry I do not know. I find the whole GNOME embraces Rust before Rust is bootstrappable on non-x86_64 thing rather frustrating too.
<pingpongdull>xelxebar after login to desktop environment it takes lot of time to open screen
<xelxebar>pingpongdull: You'll probably want to check the configuration of your window manager.
<lilyp>apteryx: because messing with running emacs sessions is a recipe for bug reports
<lilyp>also not very guixy
<apteryx>lilyp: it's as guixy as 'guix install x' and running it from PATH ;-)
<apteryx>without relogin into your session
<xelxebar>Anyone aware of work toward Guix on Pinephone?
<apteryx>lilyp: it used to work when everything was directly under EMACSLOADPATH, because nothing needed to be refreshed at the load-path level
<apteryx>now the subdirectories need to be added to the load-path, which Emacs takes care of it itself when it starts
<apteryx>perhaps we can isolate which function does this and and have guix-emacs-autoload-packages call it when it is invoked interactively (or alternatively the 2... times)
<apteryx>that'd give a hook people/modes such as emacs-guix can use to activate a newly installed package without a need for a full emacs restart
<ns12>It turns out that my LANG environment variable was set to C.UTF-8. Adding LANG=en_US.UTF-8 to ~/.profile solved the problem of the annoying "hint".
<apteryx>sneek: later tell civodul oh! it seems rust can be cross-built. So perhaps using our lonely x86_64 rust build, we can build the others? This Debian readme hints at the feasibility:
<sneek>Will do.
<apteryx>sneek: later tell civodul this is how debian bootstraps rust: "[...] it includes an extra orig-stage0 source tarball that contains the official stage0 compiler, pre-downloaded from so that your build daemons don't need to access the network during the build." Cool stuff! (c.f.
<raghavgururajan>KE0VVT: Didn't read the full backlog. I think you have to add "tor" to the `supplementary-groups` in your config.scm.
<lilyp>apteryx: all you really need to do is to load the subdirs file, perhaps followed by regenerating the autoloads using already existing guix-emacs procedures
<lilyp>if you want to, you can enhance guix-emacs by a procedure that does that
<apteryx>OK, I'll experiment when I get a chance. Thanks for the pointers.
<cjtenny>there's something funny where programs using readline only work properly if I have ncurses installed in the profile. I figured it was realted to setting search-path TERMINFO_DIRS but that's still not the cause of my emacs terminfo woes...
<cjtenny>the only similar mention I found is nckx answering somebody two years ago O_o
<cjtenny>going to see if emacs works properly with this term on my guix system machine
<podiki[m]>apteryx: the rust cross bootstrapping sounds promising!
<cjtenny>aand.... this only happens on debian. on guix system, it has no problem with the same terminal and terminfo.
<cjtenny>guix's emacs must be referencing something in debian at runtime
<apteryx>podiki[m]: but I have no idea if it's actually possible without downloaded binaries
<cjtenny>oh this is maddening, stracing emacs and it works
<apteryx>cjtenny: try it in a container?
<apteryx>guix shell -C ...
<cjtenny>apteryx: wouldn't that be similar to trying it on guix system?
<cjtenny>the weird thing here is that on debian, ~/.guix-profile/bin/strace -e trace=file ~/.guix-profile/bin/emacs exhibits different behavior than ~/.guix-profile/bin/emacs with respect to terminfo
<apteryx>yes; it's to verify that it's not an impurity of your debian system
<cjtenny>whether the terminal (foot) is debian's /usr/bin/foot or ~/.guix-profile/bin/foot
<cjtenny>apteryx: already verified that it is an impurity of debian, in that on my guix system machine, there's no bug
<cjtenny>but somehow running under strace hides whatever debian impurity it is
<raghavgururajan>sneek, later tell KE0VVT: This is my config,
<sneek>Will do.
<gyara>Is there something can use to format scheme?
<cjtenny>oh, I found the bug, I'm stupid. at least I found some cruft I can maybe clean up in emacs' packaging.
<apteryx>glad you found your problem!
<cjtenny>for anybody encountering later: a shell alias was preventing emacs from evaluating
<cjtenny>(add-to-list 'term-file-aliases '("foot" . "xterm-24bit"))
<cjtenny>has nothing to do with guix, is very separate from the way e.g. guile needs ncurses installed in profile to set TERMINFO_DIRS to have guile-readline work nicely under debian
<cjtenny>apteryx: thanks for the help :)
<raghavgururajan>gyara: You could use the `/etc/indent-code.el` script in the Guix's souce tree.
<avp_>Hello Guixers! I'm trying to package Univesal G-Code Sender (UGS) for Guix
<avp_>'guix build ugs' stops with the following error:
<avp_>Any hints how to solve this?
<avp_>Here's my patch:
<rekado>ns12: re just pipe “yes” into it.
<rekado>big GC lock is active; pankow and kreuzberg are idle
<raghavgururajan>avp_: The package either requires mockito v2 or some dependencies of mockito needs to be propagated.
<avp_>raghavgururajan: I suppose there's no Mockito v2 for Guix yet?
<raghavgururajan>Appears so.
<avp_>It seems that UGS requires mockito only for the test scope, is there any way to skip it altogether? I added arguments with '#:tests? #f' but it seems to have no effect against the error.
<raghavgururajan>avp_: There may be compiler flags.
<avp_>How do you pass the custom compiler flags to Maven in a Guix package definition?
<rekado>had to take kreuzberg offline to install grunewald (I don’t have enough ethernet cables). Now waiting for the big GC lock on berlin to be released.
<unmatched-paren>aaah nooo! rustc 1.53.0 build correctly but then one of its tests failed! >:(
<unmatched-paren>should i just remove the test?
<slyfox>probably depends on the test's failure reason. maybe it's legitimate and worth fixing. or reporting/fixing test upstream.
<unmatched-paren>"error: CHECK-NEXT: is not on the line after the previous match
<unmatched-paren> // CHECK-NEXT: ret void" is not really something i've ever seen in rust before :/
<unmatched-paren>And there's also a bit below that just looks like a bunch of types to me
<unmatched-paren>i'm not too familliar with the low-level bits of rust...
<slyfox>reading the full source test might help
<slyfox>it's probably a llvm's lit test driver that expects some llvm assemmbly output out of test
<unmatched-paren>looks like it
<unmatched-paren>the test file is ''
<unmatched-paren>and it says 'input file: /tmp/blahblah/alloc-optimization.ll', so that's an llvm file it's taking in
<unmatched-paren>i had to do another thing related to alloc (removing the part that deleted jemalloc since they have now removed it completely)
<unmatched-paren>could this be related?
<unmatched-paren>does this look like llvm ir?
<unmatched-paren>haha that's pretty funny: this is the failing test:
<unmatched-paren>it's tiny!
<unmatched-paren>all it's doing is creating a box and dropping it... not sure what those comment flags are doing
<unmatched-paren>i'm just not sure if it's appropriate to remove those tests...
<slyfox>looks like it checks for an allocation/free to be completely optimized away
<slyfox>if you run rustc on it with llvm output you should be able to see what is different about it
<slyfox>the comments are the test. it literally expects those 3 lines to be in sequence in generated llvm
<unmatched-paren>it existed in the previous version but passes there:
<slyfox>i think it's a reasonable test
<unmatched-paren>i can run rustc --emit=llvm-ir on it with 1.52.0, but i'm not sure how i'd do that with 1.53.0 since the executable isn't in the store because the tests failed
<unmatched-paren>i'll try looking at the logs
<slyfox>on llv i usually run lit with -v or -vv. it prints exact command it was running the tests.
<slyfox>i would expect rust to have something similar
<unmatched-paren>i'll 1. disable the problematic test and build/install 1.53.0 without it, then 2. use rustc --emit=llvm-ir on the file _with 1.53.0_, 3. do the same --emit thing with 1.52.0, then 4. run diff on the two
<unmatched-paren>since that's the only thing i can think of with my limited knowledge of the rustc build process
<slyfox>sounds reasonable
<avp_>There's no Gradle build system for Guix, I suppose?
<unmatched-paren>slyfox: before i started the only things i really knew about building rustc were: 1. it uses a python script called, 2. it's painful, and 3. it takes way too long :)
<unmatched-paren>it's so annoying how most rust packages just assume everyone has latest rustc
<slyfox>yeah, rust has very fast moving ecosystem
<unmatched-paren>and very a slow moving compiler :)
<unmatched-paren>* a very
<unmatched-paren>i guess you can't blame it, it has to do all sorts of checks and things
<unmatched-paren>but i don't understand why it uses like 15 different IRs
<slyfox>does guix also build llvm as part of rust build? or it's an expernal package to rust?
<unmatched-paren>surely LLVM is enough?
<unmatched-paren>External i think
<slyfox>that could be a large chunk of time spent
<slyfox>maybe rust's build system has a way of building unoptimized compiler to speed things up slightly?
<unmatched-paren>to be fail it doesn't actually take as long to bootstrap itself as i thought, it's just quite frustrating when i've been waiting an hour for it to bootstrap, and then it's nearly there, and then this tiny little test fails and brings the whole thing down
<unmatched-paren>(thank goodness llvm is external)
<slyfox>on other distros i usually try to master incremental way of building and fixing packages to shring 'fix / rebuild' loop
<sam_>note that Rust does not support external LLVM right now and it often causes test failures
<slyfox>On nix it would be 'nix develop -f. $pkg; unpackPhase; patchPhase; buildPhase; $hack; buildPhase'. Maybe guix provides similar mechanism?
<unmatched-paren>there's a patch mechanism in the recipes
<unmatched-paren>if that's what you mean
<slyfox>i mean that you can interleace attempts to patch the tree interactively and resume the build without starting from scratch
<unmatched-paren>i have no idea
<slyfox>basically, an equivalent of normal development with you do './configure && make' once and iterate with '$EDIT && make' a lot
<unmatched-paren>it does seem to be taking less long this time... the stage1 compiler is already built
<unmatched-paren>but this is just 1.53, so i'm still a long way from 1.56.1
<unmatched-paren>rustc 1.56.1 cannot be compiled with 1.52.0 because of changes made in preparation for edition="2021"
<unmatched-paren>lots of fun!
<raghavgururajan>Streaming youtube in pipe-viewer is better now with yt-dlp.
<unmatched-paren>hopefully 1.53.0 will be able to do it
<unmatched-paren>that's probably not going to happen though :)
<unmatched-paren>rustc has so many crates... that's one of the flaws of rust for me, there's too much of it :)
<unmatched-paren>i prefer simpler languages like go, but go is slower :(
<unmatched-paren>actually my favourite language right now is probably ocaml, which sadly does not have much of an ecosystem
<jpoiret>"simpler languages like go" you just picked the two most annoying languages to package on guix
<jpoiret>notwhithstanding julia & friends
<nckx>raghavgururajan: Does dlp support all sites that dl does? If so, how about dropping dl integration (if not the package itself) until it shows signs of (new) life?
<nckx>s/does/did/ I guess.
<unmatched-paren>simpler for developers i mean :) it was quite an enlightening experience seeing how integrated package managers are such a pain for packagers
<unmatched-paren>i don't like them nearly as much now
<raghavgururajan>nckx: It *supposed* to support all sites that dl does. I was planning on deprecating youtube-dl in favour of yt-dlp, if the former announced end-of-life.
<unmatched-paren>the 'just distribute compiled binaries and SOs' approach by C makes a lot more sense now
<jpoiret>yes, and it's a shame because the main consumers of an app and the ones who have to deal with deps the most are not devs but users and distro maintainers
<nckx>raghavgururajan: I fear they might never do so officially since the project looks abandoned (but I probably didn't dive as deep as you have). We're on the same page anyway.
<jpoiret>and i get that go for example is trying to make it easy, but they're even moving away from the only proper way we have of building go code now
<jpoiret>GOPATH-based installing is being phased out iirc
<unmatched-paren>is GOPATH where go looks for libraries or something?
<attila_lendvai>GOPATH is for source code, i think.
<raghavgururajan>Yt-dlp project page says "The main focus of this project is adding new features and patches while also keeping up to date with the original project.". So I assume they expect the youtube-dl to continue development. 🤷‍♂️️
<unmatched-paren>are there any languages that are basically just dialects of C with cleaner, more readable syntax? because if that existed i would 100% use it
<unmatched-paren>my problem with c is that it's so ugly
<nckx>raghavgururajan: I think that description predates ytdl being observably dead and wouldn't read too much into it, but sure: I hope that we yet hear knocking from the coffin.
<civodul>oooh new machines at
<sneek>Welcome back civodul, you have 4 messages!
<sneek>civodul, apteryx says: if you use the last commit of mrustc, it nearly builds on i686 but fails because librustc wants to use too much memory:
<sneek>civodul, apteryx says: re gjs requirement mozjs/rust I'm sorry I do not know. I find the whole GNOME embraces Rust before Rust is bootstrappable on non-x86_64 thing rather frustrating too.
<sneek>civodul, apteryx says: oh! it seems rust can be cross-built. So perhaps using our lonely x86_64 rust build, we can build the others? This Debian readme hints at the feasibility:
<sneek>civodul, apteryx says: this is how debian bootstraps rust: "[...] it includes an extra orig-stage0 source tarball that contains the official stage0 compiler, pre-downloaded from so that your build daemons don't need to access the network during the build." Cool stuff! (c.f.
<civodul>thumbs up, rekado!
***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!*betelgeus@*
***litharge sets mode: -o litharge
<civodul>apteryx: thanks for explaining!
<civodul>apteryx: so this is gcc as invoked by mrustc that eats too much memory; i wonder if we could pass it -O0 or something in the hope it'd use less memory
<unmatched-paren>urgh gnome-terminal crashed as the build was about to finish
<stikonas>trying -O0 with mrustc/gcc might work
<stikonas>I guess most of the memory is used by optimizers
<unmatched-paren>i see that others are also experiencing rust pain
<stikonas>the resulting binary would probably be slow but who cares
<unmatched-paren>i used to like rust until now :)
<stikonas>well, some ideas might be nice there, but I never liked lack of proper bootstrappability
<unmatched-paren>yeah exactly
<unmatched-paren>a shame that there's no language other than c that rivals it in speed
<unmatched-paren>(that i know of)
<stikonas>if not for Mutabah's work on mrustc, it would be even worse
<stikonas>most languages are more complicated than C
<stikonas>and C has been there long enough to have a good compilers
<unmatched-paren>so question: if i update rust, will it go into master or c-u-f? because the rust package will stay at 1.45, but there'll just be another few new rust versions
<civodul>unmatched-paren: c-u-f has 1.54.0
<unmatched-paren>o h
<unmatched-paren>soooo i've been wasting my time :)
<unmatched-paren>i guess i could update c-u-f to 1.56
<unmatched-paren>but i've been trying to get to 1.54 on master since the start of the day :D
<unmatched-paren>i really should have checked... oh well
<unmatched-paren>at least i only have 2 versions to do now
<civodul>oh too bad you were working on it
<civodul>but yeah, let's update to 1.56 on c-u-f, that won't be lost!
<unmatched-paren>is there a way i can use c-u-f's rust without switching my whole system to it?
<unmatched-paren>i want to be able to compile wezterm and helix
<unmatched-paren>which need c-u-f's version of rust
<unmatched-paren>actually helix requires 1.56
<civodul>apteryx: heretic thought: how bad would it be to reintroduce librsvg 2.40 to salvage things like xfce on i686?
<civodul>alternatively, ?
<unmatched-paren>gccrs: "Please note, the compiler is in a very early stage and not usable yet for compiling real Rust programs."
<KE0VVT>raghavgururajan: Okay, added users to group tor <>. Will reconfigure.
<sneek>KE0VVT, you have 1 message!
<sneek>KE0VVT, raghavgururajan says: This is my config,
<KE0VVT>guix pull && guix system reconfigure /etc/config.scm
<KE0VVT>Post did not appear on help-guix. Re-posted.
<unmatched-paren>guix's tests/channels.scm is failing for me
<nckx>KE0VVT: Alternatively, don't spam the list, and wait instead?
<nckx>Just a thought.
<KE0VVT>nckx: someone said to wait a day
<KE0VVT>oh well
<nckx>You waited less than half.
<nckx>(Only the first one, that is.)
<KE0VVT>thanks. sorry.
<nckx>KE0VVT: I forgot to ping you y'day; it sounds like what I described though:
<unmatched-paren>every other test succeeds: do i just ignore the failure?
<nckx>KE0VVT: What with ‘Could not bind to Address already in use. Is Tor already running?’
<KE0VVT>nckx: Great. :(
<KE0VVT>nckx: So i have to reboot.
<nckx>unmatched-paren: If it happens after a change you made, rather not :) What's the error?
<nckx>KE0VVT: Why? Just kill tor.
<unmatched-paren>nckx: i did not make any changes
<KE0VVT>nckx: How is Shepherd supposed to find it if I do "herd stop tor"?
<nckx>It won't.
<unmatched-paren>i've checked out c-u-f rn, but this also happens on master
<nckx>sudo pkill tor, etc.
<KE0VVT>ugh ok
<nckx>Life is hard & then you die yes.
<nckx>unmatched-paren: Which error?
<unmatched-paren>not sure, none have popped up yet
<unmatched-paren>just a FAIL: tests/channels.scm
<nckx>There are .log files, I forget the exact layout, but it might simply be tests/channels.log.
<nckx>The tests don't run in a sandbox so they are quite susceptible to environmental differences (which is probably a net good thing, if annoying).
<unmatched-paren>should i try some environment options like --container to try to sandbox it more?
<ouestbillie>hey all I just installed from iso, basic graphical install, just partitionned manually with luks and seperate home. It says it installed sucessfully but when I boot I get scrambled characters and some kind of prompt but I can't make sense of anything, looks like a firmware issue but I'm not sure how to investigate, any ideas (running on hp elitebook folio 9480m)
<unmatched-paren>can you tell whether it's a grub prompt?
<ouestbillie>unmatched-paren: no cause its really unreadble, not even random glyphs just scrambled... but it would be my first guess
<ouestbillie>i should mention i tried the manual install before graphical (switched as a sanity check) and those same scrambled characters appear before the outputs becomes legible, the first line is something modprobe pcrk, but the googlez said that was a harmless warning...
<unmatched-paren>can you try typing 'boo' and then pressing tab? if it's a grub prompt it should autocomplete to 'boot' i think
<unmatched-paren>if it isn't grub then i can't help you, i just have this one idea for what it might be
<unmatched-paren>i got a grub prompt when i first installed, but it wasn't scrambled...
<KE0VVT>nckx: Tor is now running. :-)
<ouestbillie>just did, some more scrambly stuff, tried both with and without autocomplete, impossible to tell if autocomp worked since the resonse is non legible
<KE0VVT>nckx: Now, let's see if "torsocks wget" works.
<ouestbillie>working in the dark here :)
<ouestbillie>unmatched-paren: so lets say its a grub prompt, what command could I try to rescue besides boot?
<janneke>ouestbillie: you could try the luks passphrase
<ouestbillie>i mean the best solution would be to add the missing firmware to the install config.scm
<ouestbillie>janneke: just did; more scramble
<KE0VVT>nckx: "torsocks wget" works! :-)
<ss2>Has someone got qemu-guest-agent working? Mine's failing with: guix system: error: #<<location> file: "gnu/services/virtualization.scm" line: 893 column: 18>: invalid G-expression input
<ouestbillie>janneke: I should mention each time I boot I have to manually select guix in the BIOS boot options, I've already disabled fast boot and secure boot and enabled uefi
<ss2>That happens when just adding the service without options. System is at a current checkout.
<unmatched-paren>ouestbillie: did you format /boot/efi when you installed?
<unmatched-paren>if you don't then you'll need to choose it in bios when you boot
<unmatched-paren>because the old boot entry remains
<unmatched-paren>nckx: the test that fails is the one at channels.scm:323
<unmatched-paren>something about channel-news
<unmatched-paren>actual-value: #f
<unmatched-paren>result: FAIL
<ouestbillie>unmatched-paren: no i'll make sure to do that next time, but thats just a minor inconvenience atm, rereading my config.scm when booting from usb in shell mode I see theres not password entry for the user I created, is that normal?
<unmatched-paren>if you didn't add a password then yes
<ouestbillie>pretty sure i did, anydoo
<jgeerds>Hi, I would like to patch a file from an emacs-xyz package. The "emacs-substitute-sexps" function seems not to work in my case because the REPLACEMENT is always considered a string (it uses emacs' "format" function). What I want is a quoted emacs list consisting of a string like '("my string") -- Can someone point me to the right direction?
<ouestbillie>unmatched-paren: can I pastebin my config from the installer, a little noob on rescue mode here?
<unmatched-paren>try wgetpaste
<unmatched-paren>guix install wgetpaste
<unmatched-paren>then wgetpaste /etc/config.scm
<unmatched-paren>make sure cow-store and networking is all set up
<ouestbillie>yeah thats all done
<unmatched-paren>you don't want to fill your ram with packages :)
<ouestbillie>makes sense :)
<ouestbillie>unmatched-paren: okay here it is:
***bandali is now known as mab
<unmatched-paren>looks fine to me...
<unmatched-paren>but i'm not really an expert
<unmatched-paren>especially in disk encryption, which i have not done
<unmatched-paren>looks pretty much like mine except for the encryption part
<unmatched-paren>and the use of xfce instead of gnome
<unmatched-paren>and the lack of a password
<unmatched-paren>sorry i'm out of ideas, you'll have to ask someone more experienced :/
<ouestbillie>unmatched-paren: thanks anyway!
<unmatched-paren>it's probably something horrific involving firmware
<unmatched-paren>sorry :(
<nckx>KE0VVT: Yay! Yeah, the Shepherd losing track of things is (1) not great (2) a known bug. I haven't looked into the cause myself.
<KE0VVT>nckx: I guess Guix is the first time Shepherd has actually been used.
<nckx>KE0VVT: Probably! And at ‘distro scale’? Certainly.
<nckx>I don't know if it was seriously used anywhere else back when it was GNU dmd, but I don't think so.
<nckx>unmatched-paren: make check TESTS="tests/channels.scm" returns all success & green over here.
<nckx>Are you on latest master? Could you pastebin the log?
<unmatched-paren> sure:
<unmatched-paren>my checkouted repo is on c-u-f, but this also happens on master
<unmatched-paren>actually technically it's on my update-rustc-to-1.56.1 branch, but that's based of c-u-f (I haven't made any changes yet)
<nckx>unmatched-paren: Gotcha, I said master because it's easier for people to reproduce things there.
<nckx>So I get an explicit ‘actual-value: #t’ where you get #f. Hmm.
<unmatched-paren>I get a mixture of 'Error 2' and 'Error 1' at the end of my log
<unmatched-paren>what do those numbers correspond to?
<nckx>Just nested make ‘levels’; they don't denote types of errors.
<unmatched-paren>ah ok
<nckx>I don't know the precise terminology.
<unmatched-paren>here's the end anyway:
<nckx>Could you make sure you're running the tests under an UTF-8 locale like ‘LC_ALL=en_US.utf8’?
<nckx>"Malnova?oj." be sus.
<nckx>In my successful log it's "Malnovaĵoj.".
<unmatched-paren>it works
<nckx>It's good that we test UTF-8 but it should probably be tested more explicitly first, so it's clear what's failing.
<unmatched-paren>is my locale set incorrectly or something, or is it because of the guix environment?
<nckx>Did you get no other test failures but this one?
<unmatched-paren>yep, no others
<unmatched-paren>just passes and skips
<nckx>unmatched-paren: Is LANG (or LC_ALL, although I think that's not bestest practice) set outside of the environment?
<unmatched-paren>it's set to en_GB.utf8
<unmatched-paren>which is correct
<unmatched-paren>LC_ALL is not set.
<nckx>Mine is en_IE.utf8 which also passes fine, so I don't *think* the US made the difference.
*nckx pretty sure there's already a bug report about running the tests with a hard-coded locale; goes digging.
<nckx>Like I wonder whether (suspect that, actually) this is really the same bug:
<nckx>The FAIL I mean, not the freeze.
<nckx>This almost certainly is:
<nckx>unmatched-paren: I've merged the identical-looking bugs. Feel free, if you want, to bump
<nckx>With your opinion, that is, not just ‘bump’ ☺
<unmatched-paren>thanks, now i can torture myself with the rustc update process again :)
<nckx>Happy to obliterate all obstacles to effective self-torture.
***unmatched-paren_ is now known as unmatched-paren
<GNUHacker>join #emacsconf
<apteryx>civodul: at this level of heretic idea, it may be better to bootstrap rust on non-x86_64 the way upstream wants us to do it (with a prebuilt binary bootstrap...), leaving a large FIXME in tho sources.
<apteryx>but your idea to build the first rust with mrustc and gcc -O0 sounds good to try
<Noisytoot>roptat, Gitile doesn't seem to support repository names containing '/' (for example, (cgit) works, but is a 404 error and the repo isn't shown on
<sam_>I would really encourage trying with the bundled LLVM copy just for test purposes
<sam_>it's quite common for test failures to occur as a result of using the system copy. they patch LLVM quite heavily at times with various patches not yet landed upstream.
<GNUtoo>apteryx: Thanks it worked, though sometimes some programs (like busybox) are compiled for the host architecture
<GNUtoo>but that's probably not related to the target but rather a bug
<roptat>Noisytoot, gitile assumes the repository name is the first element after the /, so in your case it assumes the user wants the repository named "noisytoot"
<roptat>that's because I use other URLs for the repo, like repo/tree to show files, repo/commits to show the log, etc. So how is gitile supposed to know you if you want a repository named "noisytoot/commits" and not the history of the "noisytoot" repository?
<Noisytoot>roptat, Wouldn't cgit have the same issue?
<Noisytoot>so "noisytoot/tree" could either mean the "noisytoot/tree" repository or the tree of a repository named "noisytoot"
<Noisytoot>if you disable the URLs ending with '.git'
<civodul>apteryx: dunno, it seems "less bad" and easier to use an ancient librsvg in xfce4-xkb-plugin (the only thing that needs it) than to use an opaque binary blob
*civodul adds a 'supported-systems' field to rust@1.39 so we don't let the build farm work for nothing
<civodul>means there are 5.7K our of 20K packages (28%) that are x86_64-only
<civodul>*out of
<rekado>pankow and grunewald are both ready now; missing a cable for kreuzberg. But: these machines could already get to work. What can I do to let push as many builds as possible to them?
<dissent>hey guix, i'm getting this message error in my build log when pulling
<rekado>I’d also like it to prefer these nodes over the overdrives.
<rekado>dissent: are you using channels other than the core Guix channels?
<dissent>rekado: yes unfortunately.
<rekado>then it’s probably the fault of that channel. The error says that it uses a package variable that doesn’t exist.
<rekado>you can report this to the authors of that channel.
<rekado>this log file is a rollercoaster ride:
<dissent>rekado: will do, thanks.
<KE0VVT>Guess I can use Ungoogled Chromium to run proprietary web apps.
<civodul>rekado: i should be happening already
<civodul>er, it should be happening
<civodul>(i'm happening too)
<civodul> shows some activity
<civodul>on /pankow too
<lilyp>unmatched-paren: there is Vala, which is pretty much fancy C for GLib folks
<lilyp>you can write very C style code with it if you forego classes and the such, but it also has all the OOP shit everyone craved back then/still craves to an extent
<lilyp>plus it compiles to ugly C :)
<singpolyma>Vala does not have any unique OOP to itself
<singpolyma>It's just syntactic sugar for GObject which is already OOP in C
<lilyp>yep, plus with newer versions you can drop the glib part and just use POSIX
<lilyp>but still, it's syntactic sugar for GObject which is nice
<unmatched-paren>How do you even add OOP natively to a language with no support for it? That seems like something you could do in Lisp, but I'd never assume it was possible in C
<lilyp>lots and lots of macros
<lilyp>like a metric fuck ton of macros
<lilyp>also technically, C++ has the same problem
<lilyp>that's why vtables exist
<dstolfa>unmatched-paren: absolutely doable, and absolutely horrible
<dstolfa>what lilyp said basically
<dstolfa>you essentially need to reimplement vtables, except it sucks
<unmatched-paren>that's horrific
<singpolyma>Doing oof in C isn't even hard honestly
<singpolyma>Just put a vtable on a struct
<singpolyma>Most oop languages are implemented in C anyway
<dstolfa>it's not like you can't do it, it's just horrible if you want to do anything more than have basic "methods" where you need to explicitly pass self
<lilyp>Even the almighty Rust needs C to bootstrap itself
<lilyp>dstolfa: look at Gtk tho
<dstolfa>lilyp: i have, and i wish i never had
<lilyp>like, you can argue all day that it's oh so ugly on the inside, but it works on a wide array of languages from C to Javascript
<dstolfa>lilyp: many things work, doesn't make them any less annoying to deal with
<dstolfa>seems to be generally true with computers, though
<lilyp>As much as I like Scheme, I wouldn't want to need to rewrite Gtk in it tbh
*dstolfa doesn't feel something like Gtk needs a rewrite in anything... it needs a rm -rf with a complete fresh start
<dstolfa>IMO, ofc :)
<lilyp>I see you're part of the hip "let's go back to ncurses" crowd
<singpolyma>Oof, ncurses is no better :P
<unmatched-paren>No, no, no! NCurses is bloat! Just use loads and loads of `printf()`!
<dstolfa>i'm a part of i like my computer to generally work with free software, and it's a hard life with anything GNOME+Gtk based
<lilyp>why use emacs if you can have ed, amiright?
<unmatched-paren>who needs ed if you have magnetic needles
<dstolfa>then again, it's a hard life with Qt+KDE too, since thunderbolt doesn't really work :(
<unmatched-paren>who needs computers, we have abac(-i? -uses?)
<lilyp>who need abacus, i have stick
<singpolyma>I mean, I use gtk emacs, but it abuses the fuck out of gtk
<unmatched-paren>pah, stick is bloat, i have finger and some sand to draw in
<dstolfa>i need to fix my emacs, my config is currently broken
<unmatched-paren>i wish i liked emacs right now, because nvim is being a pain to set up with it's tree-sitter dependency :(
<dstolfa>i mean... i am literally on vscode at the moment because i'm too lazy to configure anything and i need to finish up some stuff
<unmatched-paren>vscode? sinner! burn him!
<dstolfa>i *could* go fix my emacs, but that requires effort
<dstolfa>you had it right the first time, don't worry :P
<unmatched-paren>ed doesn't NEED configuration!
<dstolfa>(also pls don't burn me, i want to use emacs it's just that my config no worky)
<unmatched-paren>Come to think of it, neither does magnet!
<lilyp>singpolyma It's probably less bad with the pgtk branch, no?
<singpolyma>lilyp: not sure, I don't track emacs core closely
<lilyp>dstolfa: if you have time free, try to package vscode for guix
<unmatched-paren>dstolfa: do you mean vscode or vscodium?
<lilyp>vscodium is just binary distributions of vscode upstream with telephony disabled
<dstolfa>unmatched-paren: vscode, i wasn't even aware of any other distributions of it
<dstolfa>eh, i don't mind telemetry as long as it doesn't eat up traffic
<lilyp>good data source
<lilyp>we will value you
<dstolfa>hey, i keep my telemetry generally enabled for all free software! :P
<unmatched-paren>official binaries of vscode are full of proprietary stuff inserted by ms before the build i think
<lilyp>yeah, but those are not part of the git repo IIRC
<unmatched-paren>"When we [Microsoft] build Visual Studio Code, we do exactly this. We clone the vscode repository, we lay down a customized product.json that has Microsoft specific functionality (telemetry, gallery, logo, etc.), and then produce a build that we release under our license." said (proprietary) license is here:
<lilyp>so whenever someone's like "go package vscodium" we have to be like "no, we don't do blobs"
<dstolfa>unmatched-paren: makes sense that MS would do something like that
<dstolfa>but... isn't electron still problematic according to the FSF because nobody's been able to untangle things?
<unmatched-paren>electron is both technically and morally problematic
<cehteh>configuing emacs is like winemaking .. its an art, needs years to mature, and some bottles are just bad :D
<unmatched-paren>haha 2583% cpu usage!!!!
<singpolyma>dstolfa: that sounds kind of like the Debian position that Smalltalk might be nonfree because the source code isn't a text file
<dstolfa>singpolyma: i'm not saying i agree with this position, i've just heard it in the past.
<unmatched-paren>we were so desperate to write our app in javascript that we embedded the entirety of chromium in it
<singpolyma>Well if Mozilla hadn't made xulrunner unviable....
<dstolfa>unmatched-paren: i do understand where this came from though... portability has been a complete nightmare for native apps with phones and different operating systems available, and developers genenrally just wanted 1 source base across many platforms. hence, we have this mess now
<unmatched-paren>hence why language VMs exists i guess
<dstolfa>first we had java, now we have javascript + electron
<dstolfa>wonder what's next
<dstolfa>Guix runtime? :)
<singpolyma>No one learns JS to write electron, though. Front end web SPA is just so huge and the mills churn out people who can sorta do it trying to meet demand
<unmatched-paren>dstolfa: I guess a portable Scheme UI framework would not be the worst possible outcome :)
<singpolyma>unmatched-paren: racket has one
<unmatched-paren>racket looks alright, but i hate how when you install it drracket is automatically installed (at least, this has been my experience on both debian and guix)
<unmatched-paren>i also just generally prefer static typing personally
<singpolyma>Typed racket
<unmatched-paren>wait that exists?
<unmatched-paren>i might look in to that :)
<unmatched-paren>there's still the irritating forced drracket, but i guess i can pretend it doesn't exist
<lilyp>we should probably move drracket to another output or provide racket-minimal
<lilyp>similar to how we have gui-less pythong
<lilyp>snakes don't wear thongs, but lamias in stockings are sexy
<unmatched-paren>WOO rust 1.55 has compiled \o/
<cehteh>ship it!
<unmatched-paren>now i can compile 1.56.1 with that...
<unmatched-paren>it's so irritating how immediately after adding a new feature rust starts using it in its codebase, it makes bootstrapping so annoying
<cehteh>thats just the way rust evolves
<unmatched-paren>i hope the 1.56.1 build will be as painless as 1.55... probably not :p
<unmatched-paren>1.56.1 is building, let's hope it works...
<rekado> looks odd. It’s compiling GCC 7 now. This is a build for guile-static-stripped-3.0.7
<asdf-uiop>Hi! Trying to use a relative path for 'guix package --install-from-file' leads to this: "guix package: error: failed to load '~/local-guix-channel/my-packages/my-tools.scm': No such file or directory". If I replace '~' with '/home/username', it works. Is that to be expected?
<unmatched-paren>asdf-uiop: try $HOME instead of ~
<malaclyps>ohhh i have got my guix setup into a very broken state
<malaclyps>i guess there's no way to roll back the current installed version of guix *itself*. It seems to be very unhappy, even with the stable branch of guix.
<unmatched-paren>guix pull --commit=blah?
<singpolyma>malaclyps: should be possible to run an old version from the generation by specifying full path
<malaclyps>guix pull fails with this error message:
<lfam>If there is a previous generation of Guix to roll back to, it's definitely possible to use it
<lfam>`guix package -p ~/.config/guix/current --list-generations
<lfam>Then you can use --switch-generations to select an earlier generation
<unmatched-paren>rust 1.56.1 has built! \o/
<malaclyps>lfam, thank you, trying it!
<nckx>Is there any WIP on deloopyfying Gradle?
<nckx>That projects bundle(!) the Gradle binary(!!) in their ‘source’ is not promising, and I read etc.
<singpolyma>Usually projects bundle a script that downloads the Gradle binary, IME
<nckx>Well, if that's what gradle-wrapper.jar is, it's equally bad.
<nckx>Point is it could be doing anything, really :)
<nckx>It's 54K.
<malaclyps>lfam, it worked! thank you!
<lfam>That's the simple way to move between `guix pull` generations
<lfam>Of course you can also use `guix pull --list-generations`, but that command does more
<nckx>singpolyma: Do you know if there's any way to circumvent Gradle?
<singpolyma>nckx: seems to exist
<nckx>Ah, does it being in Debian imply being built from source?
<nckx>That'd be sweet.
<singpolyma>In main, yes for sure
<singpolyma>So pulling the source package from Debian or looking up the maintianer repo should give you some good clues anyway
<nckx>Hon hon.
<nckx>‘Kotlin is not in Debian yet.’ is even more promising. They can't cheat if they can't.
<nckx>Dec 20, 2017, fine I expected it to be ancient.
<nckx>This package wants distributionUrl=https\://
<asdf-uiop>unmatched-paren: it works with $HOME
<unmatched-paren>ok i'm going to send an email patch, i hope i'm doing this right
<unmatched-paren>should `git send-email --to="" HEAD^` while i'm on my branch work?
<singpolyma>unmatched-paren: normally yes, but guix-patches isn't mailing list so that only works for a single commit
<singpolyma>Oh, you said HEAD^ so yes
<lfam>If you want to know what it will send, run the command first as `git format-patch [...]`
<lfam>They take most of the same arguments aside from the email stuff
<unmatched-paren>that's what says to do, anyway
<unmatched-paren>there's a bit of junk in the patch, mostly me deleting .save files that vis(1) created. do i just leave those?
<nckx>Hmm, why are they in the *patch* in the first place?
<unmatched-paren>not sure
<unmatched-paren>oh yes of course
<nckx>Sounds like you accidentally commit them in a previous commit?
<unmatched-paren>there's two commits: rust 1.55 and rust 1.56.1
<unmatched-paren>i didn't notice the .saves until after i committed 1.55
<nckx>You'll have to amend the 1.55 one to not create the .saves in the first place.
*nckx AFK.
<unmatched-paren>how do i do that?
<unmatched-paren>actually i think it'll be easier to backup the rust.scm file and rewind to c-u-f
<lfam>Was it the latest commit that erroneously added those files? Or a previous commit?
<unmatched-paren>a previous commit
<lfam>I would approach this with an interactive rebase
<unmatched-paren>since i only changed one file, and i made a few mistakes with tmp-files, it'll be easier to just backup and redo
<lfam>`git rebase -i HEAD~10`, where "10" is the number of commits back that need to be edited
<lfam>Then, select "exec" for the commit you want to amend
<lfam>Git will dump you back in your shell, on that commit
<lfam>Use `git reset HEAD^` to "undo" the commit, putting your changes back in the tree
<lfam>Then, you can use `git add -p` to carefully select the changes for the commit, and then do the commit
<lfam>Finally, finish with `git rebase --continue
<lfam>It might seem tricky but if you want to do a lot of work in Git in the future, this skill will be essential
<lfam>My bad, it's "edit", not "exec"
<lfam>"use commit, but stop for amending"
<rekado>encountering gradle is my signal to do something else
<rekado>I haven’t found a way to circumvent it
<unmatched-paren>ok i've cleaned it up, i'm going to send the patch now
<unmatched-paren>huh, git send-email is not a git command??
*nckx ret.
<nckx>unmatched-paren: Did you install git:send-email, into the same profile as git?
<nckx>rekado: :(
<nckx>I understand that I barged in with the enthusiasm of the clueless.
<nckx>This is less a rabbit hole than a deadly well.
*nckx wonders whether to cut their losses and stop.
<unmatched-paren>It's a rabbit hole, but the rabbit is vicious
<nckx>The Holy Gradle of Caerbannog.
<unmatched-paren>git:send-email is installed... :/
<nckx>In the same profile as git? That matters.
<rekado>I don’t even know if it’s possible to just build with the included gradle wrapper.
<rekado>IIRC that just downloaded gradle
<nckx>unmatched-paren: Hm. Never happened to me. ‘Log out & back in’? I'm not really sure what's going on.
<unmatched-paren>logging out then back in worked :|
<lfam>That makes sense
<lfam>You could have used `bash --login` or `zsh --login`
<lfam>It's because Guix makes use of the login shell initialization machinery to make profiles effective
<nckx>Yeah, I believe sing polyma, it's a chubby downloader but probably a downloader.
<nckx>I'm not going to run it
<fancycade>Does anyone know to get passed missing linux/errno.h headers in guix? It seems libcmark uses that header
<nckx>fancycade: linux-libre-headers?
<nckx>It generally provides linux/ headers ☺
<nckx>Seems so.
<nckx>”cmark is the C reference implementation of CommonMark, a rationalized version of Markdown syntax with a spec.”
<fancycade>nckx: yeah ive tried that, but I still get the error.
<nckx>‘Rationalized’ here means ‘depends on kernel headers’.
<fancycade>granted im trying to build the chicken scheme wrapper and it requires sudo, so im wondering if that is the problem
<nckx>Then you'll have to lovingly set -I<linux-libre-headers>/include in (say) CPPFLAGS to make this apparently derpy build system see them.
<nckx>OK I'm not quite sure what you're doing TBH.
<nckx>*Building* requires sudo?
<fancycade>building this project
<nckx>And how?
<fancycade>yeah chicken default is a bit strange like that
<fancycade>guix is the only distro ive had this issue with
<nckx>I'm involuntary doing strange things with my eyebrows.
<lfam>Probably, Guix is the only distro you've tried that doesn't provide a "standard" environment for building
<nckx><guix is the only distro ive had this issue with> usually translates to ‘upstream hard-codes /usr, the end’.
<lfam>It does seem unreasonable that Chicken requires the build process to be run as root
<unmatched-paren>i've sent the patch :)
<lfam>Somehow I doubt that is totally accurate
<lfam>I'm guessing that root privileges are required to install the thing
<nckx>But really, what exactly is happening here, because chicken-cmark does not require linux-errno.h.
<nckx> returns 500 so I can't check that.
<nckx>You should never need to be root (or any prescribed user) to build something.
<fancycade>wtf convenient time for github to go down
<fancycade>there is a way to configure chicken builds to be not root, but it isn't default
<nckx>Holy wow… it is ‘GitHub’ 😮
<lfam>fancycade: Do you have a link to that info?
<lfam>Is it as described here?
<nckx>fancycade: Are you trying to build this package ‘by hand’?
<nckx>If so, why not package it for Guix? There's a chicken-build-system. Seems to even work.
<fancycade>lfam: yes that is the info
<lfam>Yeah, so it is the install step that requires privileges, which is expected on old-school distros
<fancycade>nckx: yes, I'm just trying to install that package so I can install a different program
<lfam>Maybe Chicken code tends to behave better than other languages, but I would avoid running the build as root.
<unmatched-paren>i guess it takes a while before emails appear on the web ui?
<nckx>I'm not entirely sure that will work, but I don't know enough about Chicken.
<nckx>Someone just approved a mail from under my nose, maybe that was yours :)
<unmatched-paren>oops i made a couple of mistakes in my commit :p i'll just fix those
<nckx>But yes, it takes a vaguely-defined ‘while’.
<nckx>lfam: If I ever catch them…!
<nckx>I will… thank them! Hard!
<fancycade>lets see if nonroot works
<nckx>If Chicken Scheme invokes GCC and doesn't misguidedly mess with environment variables, GCC should see C_INCLUDE_PATH which should point to $HOME/.guix-profile/include which should include the linux/ headers you previously installed.
<unmatched-paren>oh yes of course github is down :)
<unmatched-paren>does anyone know the latest version of cargo? i forgot to update it
<unmatched-paren>ok so 0.57.0
<nckx>GitHub's down errybody, the opensource is closed.
<raghavgururajan>GitHub got kaboom.
<nckx>Workflows will fall.
<nckx>Deployments will halt.
<nckx>Corns will pop.
<unmatched-paren>technically every single project where the source is only on github is now temporarily proprietary
<nckx>‘got’ is funnier.
<unmatched-paren>how do i get the checksum of something downloaded with (crate-url)?
<unmatched-paren>there's an issue on github about downloading a tarball from, but... you know.
<nckx>I guess, guix hash $(guix build --source SOMETHING)
<nckx><something downloaded with (crate-url)> But there's no such procedure so I am the confuse.
<unmatched-paren>sorry (crate-uri)
<unmatched-paren>but anyway works
<nckx>Fortune when I open a new terminal now: ‘You are permanently confused.’
<fancycade>well building as non root seems to have gotten me past the linux/errno. appreciate the help
<nckx>Probably because it preserved the variable(s) I mentioned above. Glad to hear it!
<unmatched-paren>ohno new cargo needs new crates
<unmatched-paren>this is going to be painful :)
<nckx>(If you until; do; done long enough you can still fetchFromGitHub, just saying.)
<jgart>raghavgururajan, damn, I can't package because its dependencies are on github
<Myrcy>shoot even git pull is down
<jgart>raghavgururajan, let's work on packaging something that doesn't depend on github...
<KE0VVT>Does "guix pull" update packages and not just package definitions?
<nckx>Only available packages and the guix command itself (the two are actually inherently bound).
<singpolyma>KE0VVT: no, it just updates the program named "guix"
<raghavgururajan>Looks like microsoft picked-up the pieces and put it back together.
<raghavgururajan>KE0VVT: guix pull is like git pull. It updates the distribution of guix. You then install/ugrade the packages.
<KE0VVT>I get a lot of package conflicts with Telegram Desktop.
<raghavgururajan>KE0VVT: conflicts?
<raghavgururajan>You'd get one. dconf
<slyfox>github is back
<KE0VVT>I guess I have to update BOTH gajim AND telegram-desktop, I see.
<nckx>Propagated-inputs are a plague.
<KE0VVT>Ah, "guix pull && guix upgrade".
<KE0VVT>nckx: Propagated inputs?
<nckx>And system reconfigure to update the system & system packages.
<nckx>KE0VVT: A kind of input that emulates traditional/legacy distro ‘dependencies’. I.e. ‘if I install A, also install B’. Fragile, unguixy things but some software all but requires it to run without invasive patching.
<raghavgururajan>KE0VVT: Gajim build fails on current master. Has been for few days.
<nckx>If package A propagates B and package C propagates B' (a different version or even build of B), there will be conflicts that need to be resolved, often by upgrading both A and C but sometimes not even that helps.
<KE0VVT>nckx: I'm guessing that is Telegram Desktop's fault, considering how hacky the software is to begin with.
<raghavgururajan>I am afraid you have to use time-machine to install gajim and telegram-desktop for now.
<KE0VVT>raghavgururajan: Oh no, will my Gajim not run now?!
<KE0VVT>Oh no, I've never used time-machine.
<raghavgururajan>If you already have gajim, then all is well, just don't upgrade.
<raghavgururajan>KE0VVT: To upgrade all packages in your profile, expect gajim and telegram, do `guix package --upgrade --do-not-upgrade={gajim,telegram-desktop}`
<KE0VVT>Too late. I ran "guix upgrade" a minute ago.
***Tirifto_ is now known as Tirifto
<KE0VVT>Where does Guix store Sway's default config?
<nckx>KE0VVT: You can always ‘guix package --roll-back’ to undo upgrades (see ‘guix package --list-generations’ for your profile's history).
<nckx>I have a /gnu/store/csn24vrwmn85p35i6kakn72xzln1gi02-sway-1.5.1/etc/sway/config but no clue if that's the ‘default config’ or an unused example file and the defaults are baked in. Both are plausible.
<nckx>However, Guix does not provide its own defaults anywhere else; whatever decides would be Sway upstream.
<nckx>check-system is broken because the (arbitrarily chosen) ddcci-driver-linux module is incompatible with Linux 5.15.
<KE0VVT>nckx: Why does Guix put the hash first? Makes it hard to "cd" into a dir.
<nckx>Because if it was put last people would ask why it wasn't put first.
<jgart>github down again
<lilyp>KE0VVT: there's a practical reason to it: store-path + hash are fixed length
<lilyp>so you can get the stripped file name quite efficientlly
<nckx>It has more advantages than disadvantages (even at the CLI).
<raghavgururajan>> ‎jgart‎: github down again
<KE0VVT>I can't see color emoji. I installed "font-google-noto", but no luck.
<lilyp>refreshed the cache?
<raghavgururajan>Couldn't be any happier. Hail decentralization.
<nckx>Here they work everywhere except in Emacs.
<nckx>Previously IceCat.
<lilyp>I think I also have them working in Emacs
<raghavgururajan>Wait. You see black and white emojis?
<jgart>github being down feels like witnessing a lunar eclipse on site
<raghavgururajan>If so, there is a setting in gajim.
<lilyp>well, at least some of them
<lilyp>First they took Facebook, next Github.
<jgart>when's the next eclipse? ha
<lilyp>Everyone can be next
<nckx>Savannah is next approximately every two weeks.
<nckx>Will that stop me from gloating? Absolutely not. GNUs uptime/staff(pay) ratio is proportionally stellar ☺
<KE0VVT>nckx: Cannot see color emoji in Foot.
<nckx>True, nor can I ('d never tried).
<unmatched-paren>yay i got latest cargo to compile :)
<unmatched-paren>now i'll amend my email
<nckx>I used to see them in alacritty. So if you can bear switching, there's a tip.
<nckx>KE0VVT: ?
<nckx>Seems to be DIY.
<jgart>nckx, do you happen to know what it means to patchShebangs a configure?
<jgart>or the equivalent in guix
<jgart>oops never mind
<jgart>this configure script has a shebang at the top
<jgart>so that's what's missing
<jgart>a reference to the store in the shebang
<nckx>Guix *should* do that automatically?
<jgart>I don't think it does for a configure script?
<jgart>This is the last state of trayer that I worked on with dissent
<nckx>Do you have the full file handy?
<jgart>I think I just need to substitute* it
<nckx>Saves a *lot* of time.
<jgart>one sec
<nckx>./configure is not somehow magically exempt from patching. But maybe there's something weird about it.
<unmatched-paren>ok i've submitted a v2 email. what do i do now?
<nckx>Submitted to?
<unmatched-paren>i needed to amend my rustc patch to update cargo
<nckx>Whereto have you submitted it?
<unmatched-paren>, with -v2 and --annotate on git-send-email. is that correct?
<nckx>Yes, but make sure to send it so you don't create a new unrelated bug number.
<nckx>You didn't? ☺
<nckx>That's OK; we can manually merge them.
<unmatched-paren>i was kinda blindly following, sorry :)
<nckx>This is specific to our bug/patch tracking system.
<nckx>Be sure to always read (guix)Submitting Patches alongside.
<nckx>However, since provides ‘distro’-specific instructions, I think they should be clarified as well?
<unmatched-paren>alright, thanks :)
<unmatched-paren>(back to treesitter)
<nckx>lfam: So shall we apply that patch to 0.4.1? Good for me.
<lfam>I guess?
<nckx>OK, will do.
<unmatched-paren>i'm reading nix-pills to try to figure out how to convert tree-sitter.nix to guix, and so far it is making me feel very relieved that i chose guix :)
<jgart>nckx, this is the failed build log:
<jgart>the last link is the package
<nckx>jgart: The shebang is fine (or configure wouldn't have run at all and you would have got the mysterious 127 error status).
<jgart>but guix is still better than nix-shorts ;)
<unmatched-paren>thanks :)
<nckx>It's a hand-written (non-autotools) ./configure script that doesn't accept the standard arguments or ignore unknown ones. So you'll have to write a custom configure phase that (apply invoke "./configure" configure-flags) only.
<jgart>nckx, why does the nix package definition patch the configure shebang?
<nckx>Maybe they don't patch shebangs by default like Guix does? Maybe it's obsolete cruft? I can't say.
<jgart>now that github is back up
<nckx>I saw ☺
<jgart>oh ok
<jgart>didn't realize
<jgart>ok cool
<jgart>so I'll write a custom phase for configure
<jgart>I'll try that
<unmatched-paren>hm looks like some of my patch didn't get sent
<unmatched-paren>what's the issue number of my patch so i can amend it correctly this time?
<unmatched-paren>i can't find it on the web gui
<nckx>I guess that Nix passes *only* --prefix to configure, whilst Guix passes all the arguments you see after ‘configure flags:’ in the log. Yes, that's a bit surprising, and maybe I'm wrong…
<nckx>unmatched-paren: ?