<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 <KE0VVT>Hm, I guess I can't have both Telegram and Gajim installed... <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>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 :) <KE0VVT>rekado_: There must be something wrong with my config.scm. :( <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>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>It doesn't format /boot/efi in the installer by default, so the old boot entry remains, but it doesn't go anywhere <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 <unmatched-paren>There's errors about iterators, because rust 2021 fixed a long-standing issue with iterators <unmatched-paren>Since rust < 1.56.0 does not have 2021 as an option, the issue is still there <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 <vagrantc>(replace 'build ... (invoke compiler arg1 arg2)) ? <sneek>Welcome back vagrantc, you have 1 message! <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 help-guix@gnu.org. <apteryx>lfam: look at the one for the program 'building' our nss-certs <apteryx>GNUtoo: it should be the target profile; I've never tried though! <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 <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 <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 <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! <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. <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 :) <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))) <KE0VVT>Hm, my mailing list message does now show up. <vagrantc>might need to be moderated if you're not subscribed <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 <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 :-) <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. <M6piz7wk[m]>or.. i will hide by "it was intended!" so that you get used to reading the manual :p <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 <vdv>it seems like the rest of the list is ignored <ns12>./guix-install.sh needs manual human intervention to respond to at least two prompts. <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>(testing the case of someone on the guix-devel mailing list) <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. <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 <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 <apteryx>lilyp: it's as guixy as 'guix install x' and running it from PATH ;-) <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". <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>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 <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 <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. <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 <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_>Any hints how to solve this? <rekado>ns12: re guix-install.sh: 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? <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. <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! >:( <slyfox>probably depends on the test's failure reason. maybe it's legitimate and worth fixing. or reporting/fixing test upstream. <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 <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>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>all it's doing is creating a box and dropping it... not sure what those comment flags are doing <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>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 <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 <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 x.py, 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>i guess you can't blame it, it has to do all sorts of checks and things <slyfox>does guix also build llvm as part of rust build? or it's an expernal package to rust? <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 <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? <slyfox>i mean that you can interleace attempts to patch the tree interactively and resume the build without starting from scratch <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>rustc 1.56.1 cannot be compiled with 1.52.0 because of changes made in preparation for edition="2021" <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>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 <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? <unmatched-paren>simpler for developers i mean :) it was quite an enlightening experience seeing how integrated package managers are such a pain for packagers <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 <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 <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. <sneek>Welcome back civodul, you have 4 messages! <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. ***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!*betelgeus@*
***litharge sets mode: -o litharge
<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 <stikonas>I guess most of the memory is used by optimizers <stikonas>the resulting binary would probably be slow but who cares <stikonas>well, some ideas might be nice there, but I never liked lack of proper bootstrappability <unmatched-paren>a shame that there's no language other than c that rivals it in speed <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 <unmatched-paren>but i've been trying to get to 1.54 on master since the start of the day :D <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? <civodul>apteryx: heretic thought: how bad would it be to reintroduce librsvg 2.40 to salvage things like xfce on i686? <unmatched-paren>gccrs: "Please note, the compiler is in a very early stage and not usable yet for compiling real Rust programs." <KE0VVT>guix pull && guix system reconfigure /etc/config.scm <KE0VVT>Post did not appear on help-guix. Re-posted. <nckx>KE0VVT: Alternatively, don't spam the list, and wait instead? <KE0VVT>nckx: someone said to wait a day <nckx>You waited less than half. <nckx>(Only the first one, that is.) <nckx>KE0VVT: I forgot to ping you y'day; it sounds like what I described though: <nckx>KE0VVT: What with ‘Could not bind to 127.0.0.1:9050: Address already in use. Is Tor already running?’ <nckx>unmatched-paren: If it happens after a change you made, rather not :) What's the error? <nckx>KE0VVT: Why? Just kill tor. <KE0VVT>nckx: How is Shepherd supposed to find it if I do "herd stop tor"? <nckx>Life is hard & then you die yes. <nckx>unmatched-paren: Which error? <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) <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... <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>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 <KE0VVT>nckx: "torsocks wget example.net" 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. <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? <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? ***bandali is now known as mab
<unmatched-paren>sorry i'm out of ideas, you'll have to ask someone more experienced :/ <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>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. <nckx>Just nested make ‘levels’; they don't denote types of errors. <nckx>I don't know the precise terminology. <nckx>Could you make sure you're running the tests under an UTF-8 locale like ‘LC_ALL=en_US.utf8’? <nckx>In my successful log it's "Malnovaĵoj.". <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? <nckx>unmatched-paren: Is LANG (or LC_ALL, although I think that's not bestest practice) set outside of the environment? <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>The FAIL I mean, not the freeze. <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
<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 <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>so "noisytoot/tree" could either mean the "noisytoot/tree" repository or the tree of a repository named "noisytoot" <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 <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 ci.guix.gnu.org push as many builds as possible to them? <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? <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. <KE0VVT>Guess I can use Ungoogled Chromium to run proprietary web apps. <civodul>rekado: i should be happening already <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>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>like a metric fuck ton of macros <lilyp>also technically, C++ has the same problem <dstolfa>unmatched-paren: absolutely doable, and absolutely horrible <dstolfa>you essentially need to reimplement vtables, except it sucks <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 <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 <lilyp>I see you're part of the hip "let's go back to ncurses" crowd <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? <dstolfa>then again, it's a hard life with Qt+KDE too, since thunderbolt doesn't really work :( <lilyp>who need abacus, i have stick <singpolyma>I mean, I use gtk emacs, but it abuses the fuck out of gtk <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 <dstolfa>i *could* go fix my emacs, but that requires effort <dstolfa>you had it right the first time, don't worry :P <dstolfa>(also pls don't burn me, i want to use emacs it's just that my config no worky) <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 <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 <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: https://code.visualstudio.com/license <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? <cehteh>configuing emacs is like winemaking .. its an art, needs years to mature, and some bottles are just bad :D <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 <dstolfa>first we had java, now we have javascript + electron <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 :) <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>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>it's so irritating how immediately after adding a new feature rust starts using it in its codebase, it makes bootstrapping so annoying <unmatched-paren>i hope the 1.56.1 build will be as painless as 1.55... probably not :p <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? <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. <singpolyma>malaclyps: should be possible to run an old version from the generation by specifying full path <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 <nckx>Is there any WIP on deloopyfying Gradle? <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 :) <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? <nckx>Ah, does it being in Debian imply being built from source? <singpolyma>So pulling the source package from Debian or looking up the maintianer repo should give you some good clues anyway <nckx>patches/disable-Kotlin.patch <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\://services.gradle.org/distributions/gradle-5.2.1-bin.zip <unmatched-paren>should `git send-email --to="guix-patches@gnu.org" 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 <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>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? <nckx>Sounds like you accidentally commit them in a previous commit? <nckx>You'll have to amend the 1.55 one to not create the .saves in the first place. <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? <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 <nckx>unmatched-paren: Did you install git:send-email, into the same profile as git? <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. <nckx>The Holy Gradle of Caerbannog. <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. <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. <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>”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>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 <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>You should never need to be root (or any prescribed user) to build something. <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? <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. <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. <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! <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. <nckx>GitHub's down errybody, the opensource is closed. <unmatched-paren>technically every single project where the source is only on github is now temporarily proprietary <unmatched-paren>there's an issue on github about downloading a tarball from crates.io, 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. <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! <nckx>(If you until; do; done long enough you can still fetchFromGitHub, just saying.) <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>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. <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". <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. <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>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. <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). <KE0VVT>I can't see color emoji. I installed "font-google-noto", but no luck. <nckx>Here they work everywhere except in Emacs. <lilyp>I think I also have them working in Emacs <jgart>github being down feels like witnessing a lunar eclipse on site <lilyp>First they took Facebook, next Github. <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). <nckx>I used to see them in alacritty. So if you can bear switching, there's a tip. <jgart>this configure script has a shebang at the top <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>./configure is not somehow magically exempt from patching. But maybe there's something weird about it. <nckx>Whereto have you submitted it? <unmatched-paren>guix-patches@gnu.org, with -v2 and --annotate on git-send-email. is that correct? <nckx>Yes, but make sure to send it --to=52149@debbugs.gnu.org so you don't create a new unrelated bug number. <nckx>That's OK; we can manually merge them. <nckx>This is specific to our bug/patch tracking system. <nckx>Be sure to always read (guix)Submitting Patches alongside. <nckx>However, since g-s-e.io provides ‘distro’-specific instructions, I think they should be clarified as well? <nckx>lfam: So shall we apply that patch to 0.4.1? Good for me. <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>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 ;) <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>so I'll write a custom phase for configure <unmatched-paren>what's the issue number of my patch so i can amend it correctly this time? <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…