<lfam>Linux 5.7 asks what endianness to configure the kernel for on aarch64 <lfam>Wow, I had no idea that ARM is bi-endian <ryanprior>lfam: I didn't realize that either, but I guess I'm not surprised since it's such a customizable architecture ***ezzzc2 is now known as ezzzc
<bdju>anyone know if I'll be able to use an M3D 3D printer on guix system without packaging additional things? ***ezzzc0 is now known as ezzzc
<singpolyma>Hello all! I am trying to build the latest version of alacritty, by starting with the definition already in guix and pointing it at the latest version. I have taken terminals.scm and removed all definitions for other terminals and un-package-wrapped it so I can feed it to guix package -f -- I get this error: "error: rust-serde-1: unbound variable" -- this variable does not seem to have been set in term <lfam>singpolyma: That link says "Unauthorized" <lfam>Why exactly you got that particular error, I don't know. But I would take another approach overall <str1ngs>singpolyma: probably use need to use the (gnu packages crates-io) module <singpolyma>lfam: I am open to suggestions on approach for sure :) <str1ngs>singpolyma: it's defined in that module <singpolyma>str1ngs: I understand that. But for some reason even though I use the module, guix package -f reports that error <lfam>singpolyma: I would follow the instructions in the Guix manual section "Building from Git" to get a Guix development environment set up. Then, I would proceed with updating the package <lfam>The rust-serde package variable was renamed recently (see commit 271161db255304804b4aeabcba246686e76cf1b3). It's possible that whatever modules are being used when you do `guix package -f` are too out of date <singpolyma>lfam: right. that sounds like what I expected the issue to be. But should guix pull not fix that? <lfam>It should, yes. I don't have much experience using `guix package -f` or the -f option in general, so I'm not sure how it does these lookups <str1ngs>singpolyma: also add alacritty at the end of the file. -f works of of the package the file evaluates too <singpolyma>I'm looking at the "building from git" page and that seems like an incredible amount of overhead just to build one package <str1ngs>singpolyma: does guix show rust-serde work? <singpolyma>str1ngs: since the file is just a single package definition expression it shoudl evaluate to that, es? <lfam>singpolyma: Yes, but it's a powerful tool once you have it. And if you are trying to update this package... it would be very nice if you contributed the update back to Guix :) And for that you'll need a development environment to test your patch <singpolyma>str1ngs: yes, guix show rust-serde shows reasonable looking output <str1ngs>singpolyma: no, because the packages is a define. you need to have it evaluate that's what adding the name at the end of the file does. <lfam>singpolyma: What is the 'location' shown in the `guix show` output? <lfam>We want to figure out which copy of Guix is being used here <str1ngs>singpolyma: yes it is. add alacritty to the end of the file so it evaluates <lfam>singpolyma: And we also want the output of `guix describe` <singpolyma>str1ngs: read the first link I pasted, please. There is no define of a name alacritty in it <str1ngs>singpolyma: oh nevermind, this is still convoluted <singpolyma>hmm. guix describe say: guix describe: error: failed to determine origin <singpolyma>hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version string is 1.1.0. <lfam>Right, that's out of date <singpolyma> /usr/local/bin/guix -> /var/guix/profiles/per-user/root/current-guix/bin/guix <lfam>You don't want to have /usr/local/bin/guix <lfam>It should be ~/.config/guix/current/bin/guix <lfam>Hm, that's a good question! <lfam>I suppose it creates it for the "first run", before you do `guix pull` <singpolyma>I installed this guix using the installer script maybe an hour ago. never had guix on this machine before <str1ngs>~/.config/guix/current/bin/ should be first in your PATH <lfam>Basically, after you do `guix pull`, it should automagically change your environment so that your PATH is right <lfam>You may need to start a new login shell for it to take effect. So, you could log out and back in, or just do `bash --login` <singpolyma>lfam: ah, yep. bash -l has PATH set right already. So I just tried to use it too quickly after running the installer :P <str1ngs>singpolyma: it's a little easier to work in the git tree. with ./pre-inst-env guix. when upgrading packages. if you plan to send patches. <str1ngs>also if the declaration has not changed much. you can just inherit the original package and update the version that way. <str1ngs>this ensure if there are any changes to the package declaration your custom version will also benefit <singpolyma>Ok. I should read the manual about the inherit feature probably for the future <str1ngs>-f is nice thought if you are just starting out. not wanting to deter you here :) <singpolyma>The idea of sending a patch sounds fun. At this point I just want to see if it will build, etc <singpolyma>I'm trying to convince myself that guix is the "right way" to run any software not in my main distro. Which may not even be a thing guix wants to convince me of, but I have a suspicion it is close <lfam>My main computer is Debian with Guix. I try to let Guix provide everything I use directly that does not require setuid <str1ngs>singpolyma: it does work well in that case. I have certain user land programs I only manage with guix. on foreign distro <singpolyma>Why not GuixSD if you get everything from Guix anyway? <lfam>Familiarity, mostly, But I do prefer systemd / journald to shepherd and /varlog <str1ngs>I have work related obligations so I use another distro. I do though at times boot guix system to test some software I maintain. <str1ngs>singpolyma: the new term is guix system. and I recommenced it as well. <singpolyma>the main thing that makes me a bit uncomfortable about using Guix on Debian (as I am attempting to do here anyway) is that all dependencies that a guix program has that are already on my main system will be there twice. But I think I'm supposed to pretend my hard drive is of infinite size <str1ngs>singpolyma: I use it on both Debian bullseye and Ubuntu 20.04 LTS and 18.04 LTS works great. <lfam>Yes, and it is! As long as you don't add new software too quickly <lfam>Storage keeps getting cheaper :) <str1ngs>that and guix is a great cache. need the source for make. no problem just do guix build -S make. no need to find GNU mirrors :) <singpolyma>str1ngs: well, apt source make will do that for me as well :) <str1ngs>singpolyma: you need deb-src for that. and my point was how the gnu store makes a great cache. despite using a *little* space :P <str1ngs>singpolyma: for example apt source would be hard pressed to do something like this. guix build -S guile@1.8.8 :) <singpolyma>guix import is officially my new favourite thing <lfam>And it's only getting better! <lfam>The recursive Rust crate importer is crazy useful <apteryx>is a pkg-config .pc file listing deps as Requires.private means they should all be propagated? <lfam>apteryx: Yes for the "Requires" field. I'm not sure how Requires.private is different <str1ngs>Requires.private could be interpreted that way. but it really depends on the package. <str1ngs>most cause in guix you want to avoid propagation. I'd say if the package can build by using the dependency in the inputs. use inputs. <lfam>Yes, propagation should be avoided when possible and convenient <str1ngs>pkg-config will check the dependency and complain. both autotools and meson will bail. so should be easy to determin. <apteryx>I guess they don't need to be propagated, because Requires would be used to transitively search for packages via pkg-config, while Requires.private will not expose those dependencies to dependents, so it's really just a mean for flag dependencies used for *this* library (no transitive pkg-config search involved, so no propagation required) <apteryx>thanks for helping me understanding this :-) <singpolyma>Ok. Build logs being in a compressed file instead of on my terminal is not my favourite thing. But I think I can live with it <str1ngs>but I thought you liked drive space! :P <singpolyma>I do. My terminal output takes no drive space ;) <str1ngs>oh use guix build -f ./foo.scm not package :P <str1ngs>I never install packages that I'm just wanting to test build :P <lfam>When you do want verbose output from `guix package` you can pass "--verbosity=9" <str1ngs>in guix package as in install. is like GNU stow. if you build the package is technically physically there already. <str1ngs>so installing after building, is trivial. ***retropikzel_ is now known as retropikzel
<lfam>I hate to suggest that you use a different editor but Vim should read the bz2 compressed files transparently <lfam>Guix commands are designed to compose in a Unixy way, so you can do things like `vim $(guix build --no-grafts --log-file alacritty)` <lfam>(--no-grafts is required because otherwise you would just get the log of the grafting operation, assuming that package is grafted) <lfam>(Grafts are a security update mechanism) <str1ngs>we should rename grafts to band-aid! :P <lfam>"Graft" is a fine name, and no user should ever notice it or have to think about it :) <singpolyma>oh fun, guix import crate -r does not generate a definition for a package already in guix (good) but does not use the new name-with-version style <lfam>If it doesn't do the right thing, then definitely! <singpolyma>I just did grep for the names it used in arguments in the guix git, and then added the `-0.2` etc as needed <singpolyma>but if it could generate the exported names obviously that would be cooler <lfam>It's been a few months since I used it, but I don't remember having to add those <lfam>But, I used a work-in-progress version of the importer, and I'm sure some things changed since then <lfam>It was a pretty major contribution for the person who wrote it, but not a ton of testing outside of my packaging of rav1e. So I'm sure there is room for improvement <lfam>The mind of the beginner has the most salient observations! <lfam>Later we all just learn to work around bugs, and that is not good <singpolyma>So far I'm loving this workflow where I can just `guix import crate -r thing`, copy the output into my scm file, and add a line, fix up the names, and rerun <singpolyma>I know that'll produce a basically garbage scm file in terms of contribution <singpolyma>oh, hmm. now I have one where it doesn't need a package not in guix, but a newer version of the dependency <singpolyma>probably I should copy the guix def for that instead of using the importer again <singpolyma>Oh! I was correct originally. The version in guix of glutin is too old, but the error message does not show the version it wants, only the version I have <singpolyma>additionally, a grep for "tseq" in the guix source does not show anything promising <bandali>oh hey singpolyma, nice seeing you here :-) <singpolyma>I need to go sleep. I will keep chasing these dependencies next time I hack. Thanks so much for all the help everyone! I think I'm on a path to making it compile eventually <str1ngs>for the very adventurous. I've released a new version of nomad. It's now 99.9% written in guile scheme. has improved emacsy support for modeline and echo area. it's now in guix so if you have pulled today guix show nomad. should be @ version 0.2.0-alpha . you can give it a quick run with guix environment --ad-hoc nomad --nomad. please let me know if there are any blaring problems! <str1ngs>nomad is a extensible web browser written in guile scheme FYI <jgart[m]>str1ngs: Awesome!! I'm looking forward to giving it a test run. <str1ngs>correction to run without installing use guix environment --ad-hoc nomad -- nomad . <str1ngs>jgart[m]: it's still early days. so any feedback is appreciated <samplet>str1ngs: I tried '0.2.0-alpha' and it errors out trying to apply 'string-split' to '#f'. <samplet>In the backtrace I see that '#f' is passed to 'g-name->name' in g-golf.... <str1ngs>samplet: thank you for letting me know. does this happen when you use guix environment --ad-hoc nomad -- nomad ? <str1ngs>samplet: what is your guix describe? <str1ngs>samplet: I assume nomad builds okay? <samplet>str1ngs: I tried it from a checkout at a987f128b568a4981136d55741cb77e7eb2a544c. <str1ngs>samplet: I'm using a987f128b568a4981136d55741cb77e7eb2a544c as well. <str1ngs>samplet: can you try guix install nomad. you can always guix package --roll-back after <str1ngs>samplet: start a new terminal. then call nomad <str1ngs>unfortunately nomad is very environment dependent right now. due to how GI works <samplet>str1ngs: Trying to install it in a separate profile gave me more errors, so I’m now trying to install it in my usual profile. <str1ngs>samplet: okay, I need to recall how to run a graphical program in a container <str1ngs>samplet: I can't seem to replicate this. though I get close with guix environment -C -E DISPLAY --share=/tmp --ad-hoc nomad -- nomad <samplet>str1ngs: Hm... I might have try again another time. I’m having hard disk problems that are keeping Guix from updating, and there are raccoons in my yard. >:( <str1ngs>samplet: no worries, thanks for letting me know about this problem. ***hji- is now known as hji
<samplet>str1ngs: Even with it installed, nomad gives “Unbound variable: <gtk-source-view>”. <str1ngs>sneek: later tell samplet. thanks for letting me know will look into it. <luhux>Has anyone successfully run buildroot on Guix? ***apteryx is now known as Guest39705
***apteryx_ is now known as apteryx
<fnstudio>hi all, it seems that `guix install guile` gives me version 2.2.7; is there a specific reason for it not being v3? (sorry, i'm learning, not even sure if i need v3...) <smileyface>I'm trying to reconfigure a guix install from a chroot within the live-CD. When running "guix pull" I get "guix pull: error: failed to connect to '/var/guix/daemon-socket/socket': Connection refused". I assume this is because the daemon was started outside the chroot by the live-CD. How should I go forward to make changes to the chrooted system? Just start guix-daemon again from inside the chroot? <fnstudio>oh interesting... i knew font-ibm-plex was part of debian contrib - i think as a result of the font build process requiring non-free tools <smileyface>In reply to my own question above: Running "guix-daemon --build-users-group=guixbuild &" seems to have done the trick <leoprikler>fnstudio: does contrib mean "non-free" in debian parlance? I only used debian for a short while, but I vaguely recall there being a "non-free" qualifier <efraim>an example of 'contrib' would be our translate-shell package. It interacts with non-free services, which is a problem for the DFSG but not a problem for the FSDG <efraim>not sure how it works with fonts though <leoprikler>also our font-build-system does not actually build fonts IIRC, so if the tarball includes already built ones, we simply copy those <leoprikler>(by building fonts I mean generating ttfs from svgs for example) <fnstudio>leoprikler: no, you're right, contrib and non-free are two separate debian categories <fnstudio>efraim: understood re that slight difference between dfsg and fsdg, interesting thanks <rovanion>NieDzejkob, jlicht: The DNS resolution in IceCat seems to have been fixed, at least for this boot, by the command you gave. Do you know why `sudo herd invalidate nscd hosts` would have this effect, and is it possible to incorporate as a post-install trigger to the IceCat package into Guix? <pkill9>i don't think the fold-packages procedure gets packages from additional channels <leoprikler>pkill9: you can manually pass the modules to it, but it should search all of %package-module-path <leoprikler>I have the uneasy feeling, that something broke emacs <sneek>I think I remember vagrantc in #guix 3 days ago, saying: guix could have dependency packages for recommended package sets, such as the way gcc-toolchain pulls in several dependent packages ... that could be where you include the "default" font. <tissevert>anyone using LXDE and/or specifically lxterminal with Guix ? <leoprikler>okay, so after some debugging, I found, that it segfaults while creating X windows ***jonsger1 is now known as jonsger
<pkill9>leoprikler: funciton like (specification->package) find my channel's package definitions though <leoprikler>if so, then you probably did something wrong in your code <pkill9>looking at specification->package, i don't think it is <pkill9>i don't understand how it searches the packages though <leoprikler>d7d85c6412f6c2077ea930c7e525371912100193 is the bad commit, just as I thought ***jonsger1 is now known as jonsger
<tissevert>is LXDE known to work out of the box, especially on the session side ? (access to hibernation, lxappearance, default-applications settings…) ***jonsger1 is now known as jonsger
<leoprikler>okay, now I'm really, really sure, that 256d2b2e8461565a865edc127b9dfd4e8e8e523d is the last good commit <leoprikler>which is what I expected, but getting there was harder than I imagined <bdju> http://ix.io/2sY0 got this error doing a reconfigure after a pull, I don't think my actual config changed recently. <bdju>oh. I just tried again and it worked. maybe that info is still helpful. <leoprikler>got that too, it seems someone recently added debugfs to %pseudo-file-systems <raghavgururajan>sneek, later ask nckx: If I do `./pre-inst-env guix build foobar --root=foo/bar`, will the dependencies of foobar that are built, be conserved in gcroot as well? <christianbundy>It looks like the current version of nodejs is was released in 2018, is there a package for more recent versions? <leoprikler>it's a soft error as I can see; the service is correctly started on reboot <leoprikler>perhaps some incorrect logic in the upgrader, though <tissevert>guix-vits: nope, I'm running in circle, maybe my config is wrong but I have no idea since I've found absolutely no information about how things are supposed to be run under Guix and apparently no one else uses this DE <guix-vits>tissevert: Why no LXQT? Aren't LXDE abandoned by upstream? (I'm sorry for off-topic, just curious). <tissevert>no particular reason, except I never managed to get a Qt input method handler <tissevert>and I didn't want to have both GTK and Qt apps on my box <roptat>can anyone record audio with audacity? When I press the record button, it stops immediately, recording nothing. I see it's set to alsa, but I can't change it to anything else, like pulse, i wonder if it's related? <pkill9>why does this just return "open-zwave" in guile?: (fold-available-packages (lambda* (name version result #:key outputs location supported? deprecated?) name) <roptat>I remember I used to be able to record myself with audacity not so long ago... <tissevert>I loved the ~6 months I used LXQT, if that works with GuixSD and you know how to handle ibus without having to have a GTK app for it, I'm all for it <guix-vits>tissvert: IDK, but i'd just read a few years ago that the upstream abandoning the LXDE in favor of LXQT. Thought that not mean that LXDE shouldn't work.. <tissevert>I didn't even know LXDE was to be abandonned ^^' that's important news, if that's confirmed thanks ! <roptat>yeah, and the mic is working in icecat for instance <pkill9>roptat: can you set it to pulseaudio? <roptat>pkill9, no there's only alsa in the list <pkill9>ah i see, result is the resulting 'thing', in this case list <pkill9>i don't get why `guix package -A` shows packages from my channel, but fold-available-packages doesn't <pkill9>in guile: (("/run/current-system/profile/share/guile/site/3.0" . "gnu/packages")) <pkill9>running guix repl adds more to that <pkill9>it adds all the guix repos in my guix channels <butterypancake>so I'm really struggling to make this package :/ I'm really starting to thing that the parallel-tests? flag doesn't work when using the emacs-build-system <stikonas>last release of lxde was 3 years ago, so it is abandonned in favour of lxqt <butterypancake>ya, I cannot set parallel-tests? to #f in the emacs build system. I replaced the check phase with a phase that just prints out that variable and it's always #t <butterypancake>is there a good way to debug the build system? I can turn the derivation into a gexp or something and print it out? gexps honestly go right over my head <leoprikler>what exactly do you mean by "debug the build system"? <leoprikler>the scheme code itself? the underlying build system it invokes? <butterypancake>idk, I'm just trying to figure out why the build system is throwing aways parallel-tests?. I can replace phases so it's obviously not throwing away everything. So I'd like to look at the package object to see what arguments are actually in it <leoprikler>You can read the check code in build-system/emacs to see whether it passes it to the underlying build system <leoprikler>if it does (and imo it should), you need to debug that build system <butterypancake>the check function uses the variable so I'm pretty sure that's fine. I'm really not sure how to debug the build system itself <leoprikler>guix build -K, then experiment with the directory that you get <leoprikler>if you want to inject a stop at a specific point, use (lambda _ (error "stop")) or anything similar <butterypancake>no, the problem doesn't show there. The build system is running the command "make -j 12" and I need it to not. So I set parrallel-tests? to #f and it's still running make -j 12. So then I replace the check phase with my own lambda that prints the value of parallel-tests? and it says it's #t <leoprikler>hmm, how about you generate a stack trace instead of printing the argument? <butterypancake>that error thing looks nice but in the backtrace none of the arguments are filled in for some reason :P <leoprikler>I think it might be a terminal-related variable, either way Guile pretty-print and backtracing respect it <leoprikler>also it's ALL CAPS and you need to restart your guix-daemon with it, so yay, fun <butterypancake>ugh, I can't put a (display args) in the gnu-build system without it trying to rebuild everything <leoprikler>I think if you guix-build from the repl, you can backtrace interactively <Jacob_>pkill9: I'm sorry about the late reply, but thanks for confirming that I'm not the only person who has experienced it. May you fill a bug report? I know I'm not in a position to request that, but I find Guix's email-based workflow daunting, and impractical in my case and, at the same time, I don't want to leave this issue unaddressed <butterypancake>I'd just like to throw in that the problem with my package wan't fixed by setting paralell-tests? to #f. I still have to finish troubleshooting my original package :P <pkill9>Jacob_: all you need to do is post to bug-guix@gnu.org, and when replying use reply-all <greenrd>How do I define custom outputs? It doesn't seem to be documented <nly>ungoogled-chromium can't use microphone <sneek>Welcome back nly, you have 1 message! <sneek>nly, guix-vits says: hello again. <greenrd>leoprikler: ok, so I create an output - then what? how do I assign files to it? how do I do conditional building, or is that not supported? <leoprikler>I don't know what you mean by "conditional building", but you can refer to the output during your builds using (assoc-ref outputs "output") <leoprikler>you would use that to either assign stuff statically by passing it to a build system or just move files there using the vast array of install/copy functions guix has <ThomasAlbers>Hello! Quick question, is it possible to use NetworkManager's nmtui without root privileges? <lle-bout>ThomasAlbers: via polkit yes, but unsure if it's available or configured on GNU Guix <butterypancake>I can control my ethernet without root, but not my wifi. interesting <ThomasAlbers>I do have polkit installed but I am still unable to connect as a normal user <greenrd>by "conditional building" I meant "only build this part of a package if it is needed by an output" <lle-bout>ThomasAlbers: polkit needs rules to work with, so maybe they arent in place for NetworkManager and nmtui <ThomasAlbers>is it possible to install them without them getting overwritten on each reconfigure? <leoprikler>greenrd: that's not possible, guix always builds all outputs <leoprikler>if you really don't want something to be built, you'd need a second package, but that only makes sense in rare cases like linux-libre vs headers ***jonsger1 is now known as jonsger
<greenrd>sounds good actually - I never found the USE flags concept in Gentoo/Exherbo very useful, and I see that Guix has a better way to recursively transform a package dependency tree if you really need to do that for a small system <leoprikler>indeed, but it may come at the minor inconvenience of not having an easy way of choosing gtk or qt for packages that can be built with either, but not both <greenrd>oh yeah, I can see how that would be awkward <greenrd>good thing there's no packages that can be built either for emacs or vi, that would cause a holy war ;) <leoprikler>I think there are one or two, like editorconfig, which aim to supersede (parts of) both. Those fools. <pkill9>there is talk of parametarized packages which is supposed to be equivalent to use-flags <greenrd>I am not sure it is worth the extra packaging effort tbh - how many users would actually gain a tangible benefit out of it, as opposed to a warm fuzzy feeling from making their system a bit more lean? <pkill9>that's what i thought, but apparently people want it <greenrd>but I suppose if the majority of the work could be delegated to the build-system support code in guix, the packaging effort could be quite low <roptat>I'm trying to make ibus work. ibus is running and when I hit Super+Space, I see a window where I can switch keyboard between French and Anthy (Japanese), however it doesn't affect anything. Am I missing something? <roptat>oh yes I am, the GUIX_GTK3_IM_MODULE_FILE has ~~ in it, which is incorrect <roptat>ok, I fixed that and rebooted but still no Japanese input, even though I can select it in ibus <butterypancake>like a work profile that can access a work channel, but you don't want your guix search to show work stuff unless you're using that profile <nefix>is there any way to setup a docker container or something like that as a server for building derivations? ***daviid is now known as Guest52359
***Guest52359 is now known as daviid
<roptat>I can't open the anthy preferences from ibus-setup <roptat>and when I run the anthy preferences directly from the store, I get org.freedesktop.IBus.Config.SetValue: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._dconf_5ferror.Code2: The operation attempted to modify one or more non-writable keys <roptat>from strace, it looks in the store path of ibus instead of ibus-anthy <NieDzejkob>nefix: it shouldn't be too hard to offload to a containerized build machine, but I am not aware of anyone doing so. Maybe you should ask on help-guix@ <nefix>NieDzejkob: what's help-guix@? <nefix>Because, how is the ci.guix.gnu.net made? <roptat>ok, so actually I see anthy is kinda working because deadkeys act differently when i select anthy, so it's probably a matter of being able to run the preferences and change them <nefix>Could I use something like that? <roptat>nefix, yes ci.guix.gnu.org is run by cuirass <roptat>for which there is a service in Guix ***calher is now known as KE0VVT