IRC channel logs
2024-07-12.log
back to list of logs
<spenc>that was my original problem in debian, though im looking now to show you , and i think maybe the original problem was caused by not upgrading gnat correctly <freakingpenguin>g++ is part of the gcc-toolchain package, which conveniently is packaged multiple times for different versions (14.1.0, 13.3.0, etc) in one Guix commit. <spenc>ok gotcha, and then if thats specified in a manifest, then using shell -m with it would set it to the right version for the shell scripts in there? <freakingpenguin>In the case of gcc-toolchain, you can specify the version via e.g. (specification->package "gcc-toolchain@13.3.0"), and when put in a manifest that should get you the correct version in your shell. <spenc>sweet, thanks! ok i think i get it a lot better now what the workflow should be - <spenc>manifests for lightweight things like getting dependencies selected for local dev <freakingpenguin>Note that if a commit is made to Guix that updates gcc to a future 13.4.0 version and you pull said commit, that will no longer work. You would need to use an older Guix using something like time-machine. <spenc>so in general, is a manifest and guix shell -C comparable to developing inside a docker container? <freakingpenguin>Similar enough. I use shell -C for development on my projects and it's pretty well isolated. <spenc>sweet hell yeah thank you all so much this will be super useful <spenc>i love how with docker containers everything is pre-set up and it works everywhere but it sucks that you can only do it through a weird port interface and proprietary vscode plugins <lfam>Or, a new side of the same old gun <lfam>"Changing the URI of a fixed-output derivation does not cause it be downloaded again" <lfam>Adding (recursive #t) doesn't mean you will clone the source again <sturm>anyone else getting some occasional issues with windows not coming to the front under Gnome/Wayland? For example, I have an icedove-wayland window behind a terminal, click on icedove but it stays behind <dtx>hello everybody. Just curious does anybody know of a way to use "shell --container --emulate-fhs" when using guix time-machine from a time before the emulate-fhs option? <dtx>My system's guix command supports the option, but not the shell command at the commit I need. <dtx>Nevermind my question I just installed the requirements using inferiors in a manifest. <mehrad>Hi all; on a foreign distro, is there a place that Guix modifies the PATH env var?I have checked in my .bashrc and .zshrc and I don't have any config there <civodul>mehrad: hi! PATH and other variables are set in ~/.guix-profile/etc/profile <mehrad>that file is never sourced in my .zshrc or .bashrc <civodul>when you install Guix on a foreign distro with the install script, it offers to modify .bashrc to do that for you <mehrad>Thanks, but I already checked those and they do not contain anything related to Guix. <mehrad>Basically I cannot update AUR packages because guix is on the way and I get the ld error "undefined reference to" everywhere. <mehrad>and the ld is from guix store. So I want to get rid of it in PATH but surprisingly in all the shells on my computer, PATH is modified although nothing is in my .zshrc or .bashrc <mehrad>I also suspected guix daemon and I stopped the process, but that didn't improve the situation. That's why I though there must be something that is actively changing PATH even before .bashrc. <mehrad>I even put `echo $PATH` in the first line of .bashrc and the guix is still in my path <PurpleSym>Afaik Guix also installs a script in /etc/profile.d, mehrad. <PurpleSym>Depending on your distro that might get merged into or sourced by /etc/profile, which is sourced by shells on startup. <rickame>is guile the perfect config lang? kinda seems like it because any sufficiently complete config lang is just a shitty programming lang, so we don't want something like yaml or json for config, but we also don't want a full blown programming lang. then right in the middle is guile that's very simple even tho it can mix data and code in 1 format <mehrad>jackpot! Thanks. `cat /etc/profile.d/* | grep --ignore-case 'guix' | wc -l` returns 51. I think this would be it. Thanks again PurpleSym and civodul <attila_lendvai>rickame, "but we also don't want a full blown programming lang" -- why? also note that guile, a scheme implementation, is a full blown programming language. <attila_lendvai>rickame, IOW, there's no such thing as a "config lang". there are programming languages, some are turing complete, and some are more comfortable to think in and write for human brains. and that's pretty much the end of the story. <rickame>ya but what i mean by full blown is a lang with a huge api surface. but because of how guile is a dsl of dsls, it has very few rules that compose up to a full lang <attila_lendvai>rickame, yeah, it's a general property of lisps: relatively few atoms that can be combined with more freedom (as compared to other programming languages). <rickame>well i dunno about that, but for config purposes itmakes the most sense <attila_lendvai>code = data = code, on a very fundamental level. if you think something is data, then i can show a perspective where it's an interpreted language, where the interpreter is the code that processes -- interprets -- the data. <attila_lendvai>put another way, the distinction between code and data is merely a narrative that we humans weave around the facts. on a fundamental level there's no difference (and BTW, this was the big insight of the Turing architecture) <jpoiret>attila_lendvai: that's not exactly true though, some data is too simple to be code <rickame>jpoiret can you think of a type of config file that guile isn't great for? <dariqq>after a lot of troubles with selinux i now have a working guix package for fedora :) <jpoiret>rickame: very flat, freeform config files are a bit of a pain in guile imo <jpoiret>not that it's terrible but it's def not the best either <rickame>what do you use in that situation jpoiret? <jlicht>any competent guix+emacs hacker around? I've finally confirmed that the issue with overriding built-in packages such as jsonrpc has to do with native compilation <civodul>jlicht: i guess lilyp is the one who knows it best <cbaines>I guess I applied the patche correctly as libfaketime builds at least <rickame>would kubernetes be better if it was rewritten in guile? <cbaines>I'm having a go building nss with datefudge <rhuijzer>I've used a cheap hardware DMX controller this week and it sucked. So i'm trying to getting a DMX workflow working in Guix. So far I've packaged python-sacn, updated the Open Lighting Architecture (OLA) and I'm now trying to package the Open Lighting Console. Sacn is already accepted so that's great. <rhuijzer>The problem is that for OLA (the updated and current version) to work I need a newer libusb cuz it now just segfaults but that requires rebuilding of too much packages to be just accepted in master. <rhuijzer>It's been suggested to wait until core-updates is merged. So what's the correct workflow for this action, after the merge update libusb in core-updates and fix all broken packages ? <rhuijzer>Guess the first step is to subscribe to the mailing list(s) <avalenn>I tried to package a perl script and some dependencies. When I launch the script I have an error. <avalenn>Can't locate Term/ReadKey.pm in @INC <avalenn>The prl file is in $GUIX_ENVIRONMENT/lib/perl5/site_perl/5.36.0/x86_64-linux-thread-multi/Term/ReadKey.pm <avalenn>s/The prl file/The "missing" Perl file/ <avalenn>Ok. Adding perl to the same profile does the trick. <avalenn>Now it seems I have choice between using some propagated-inputs or some wrap-program for it to work every time. <avalenn>How can I debug something like "guix import: error: failed to download meta-data for package 'Net::LDAP'" ? <rekado>adding Perl is necessary because the PERL5LIB search variable is defined on the "perl" package itself. Guix will only set the search path when the package is available in the profile. <avalenn>rekado: you mean I *must* add perl as propagated-input ? <Deltafire>latest error was: "guix substitute: error: TLS error in procedure 'write_to_session_record_port': Error in the push function." <rickame>would kubernetes be better if it was rewritten in guile? <civodul>the implementation language of a tool is just one criterion <civodul>the overall architecture probably matter most <attila_lendvai>yes, but the overall architecture usually tuns out worse when the engineers need to spend too much of their attention on the implementation (i.e. less remains to be spent on understanding the domain) <PotentialUser-56>hello is there a reason an arm64 iso isn't available on the guix website? <efraim>as a vm image or as an installer? <ieure>PotentialUser-56, ARM hardware is very different from x86, it varies much more from system to system. So you can't really have an "ARM" installer, you need a "RockPro64" installer, a "Raspberry Pi 3B" installer, etc etc. One installer per system, basically. <efraim>I suppose the answer to either is there hasn't been a lot of demand for an aarch64 vm image and an aarch64 installer image would likely only work on systems using UEFI <ieure>And that's a very high maintenance burden and nobody has decided it's worth their time to do. <PotentialUser-56>I have heard about arm needing specific builds because there is no standard uefi system but how do distros like debian do it then? <PotentialUser-56>I am on apple hardware and wanted to try guix but it looks like the only option is to use it as a package manager in another distro <ieure>PotentialUser-56, I haven't used them, but I see there's a single installer; it probably only works on a subset of machines. <efraim>apple macs, just about the only machines powerful enough to actually use an aarch64 VM :) I think that's when it first came up ever actually <efraim>I wouldn't be opposed to having an aarch64 vm image. I'll see how possible it is to just build our VM image for aarch64 <ieure>PotentialUser-56, Yeah, I believe you're correct; Guix doesn't run natively on macOS and likely never will. Running on bare metal would require proprietary software blobs. So I agree with your direction, another Linux on the metal, Guix on top of that. <ieure>Or, you can get an eminently daily-driveable used ThinkPad off eBay for $150-$250 all day long. <ieure>Big fan of the eBay ThinkPad. <ieure>L390 / L390 Yoga are two models with excellent value, they're 8th gen Intel quads with two SODIMM sockets, and run $100-$150 on US eBay. <PotentialUser-56>Currently running linux in a VM but there's a project called asahi linux which brings linux to apple arm hardware and it's fully open source <spenc>is there a guix channel for free software that, due to reproducability, is not up to the standards of guix's main channel? <spenc>specifically trying to find gnat <PotentialUser-56>I agree about the thinkpads but they are somehow expensive even used where I live <ieure>PotentialUser-56, Ah, yeah, they're very very cheap in the US and a lot more expensive elsewhere. <PotentialUser-56>I bought the macbook in the US for that exact reason, they are up to 50% more expensive here <ieure>PotentialUser-56, I don't believe Asahi Linux is fully Free Software, you're still going to need binary blobs to run the WiFi. I think they've reverse engineered the graphics enough to drive them with a Free driver, but I'm not sure how well it works or where it's at. <ieure>I have an M1 MacBook Pro I have to use for work, I'd way rather be using a five-year-old ThinkPad. <erty>these days, we can also get a RISC-V laptop, not powerfull enough but still, it's opensource <PotentialUser-56>I hope RISC-V laptop advance, it's even better than arm from what I've seen. <ieure>PotentialUser-56, Linux, upgradeability/repairability, keyboard is vastly better than any MacBook, I like and use the TrackPoint, matte screen. I have not been impressed with the M1 hardware, battery doesn't last a day, and macOS is very buggy and intolerably constraining and irksome to use. <jackhill>I guess there's some kind of distroboot spec for arm hardware, but I don't fully understand it. <jackhill>it may be debian specific and just how the manage to build the plethora of different images. <ieure>This MacBook machine cost like $3300, if I'd paid my own money for the experience it delivers, it'd be getting returned. It is very bad. <efraim>spenc: I know of guix-science for science sofware which meets that criteria, and I think guixrus also meets that criteria <spenc>gotcha cool, thanks - ill check those out <spenc>also, i feel like this has to be on guix main somewhere but i couldnt find it under g++ or gpp, <PotentialUser-56>I agree about the keyboard and repairability. But the screen and trackpad on the macbook and the overall aluminum build are so much nicer than some thinkpads with plastic material. Also the battery life should be incomparably better than on the thinkpads. Also the processor is much much better and there's no fan noise. <efraim>I'd like a macmini for playing around with asahi linux and guix on top :) <efraim>the guixrus search only lists my channel when searching for gnat, but I can tell you I don't have it <freakingpenguin>There is a growing standard for the ARM boot process, "Embedded Base Boot Requirements" or EBBR. That being said I only know one manufacturer that advertises support for it. <efraim>I know there was a patch posted to the mailing list using debian's gnat as a bootstrap, I'd have to search for the bug number <spenc>yeah, that was the email i was looking at earlier, hadn't considered using it directly, good point <spenc>oh hey, whereis toy lists efraim :) <spenc>i'll grab your channel then <3 <efraim>I have it in WIP, so I don't think it works <efraim>plus it looks like I was still trying to bootstrap ada95 (93?) on gcc-2.7 <spenc>oh rip, oh well, willl just keep using the apt-get one then <efraim>I have no actual use for it but I'd love to bootstrap it one day <spenc>it does seem a little silly on priciple that a fsf project isnt in guix <jackhill>oh, cool, glad to see you're thinking about it at least. Thanks! <spenc>oh! other problem i had a hard time web searching: <spenc>i was trying to expose the apt gnat and gcc using --expose=/usr/bin/gnat --expose/usr/bin/g++ and it gave <spenc>guix shell: error: symlink: File exists: "/usr/bin" <spenc>at which point I gave up and stopped trying to run in a container <spenc>is there a better way to do this? <civodul>spenc: maybe thatâs because youâre already using --emulate-fhs/-F? <civodul>right, so you cannot âaddâ to that /usr/bin, i guess <spenc>otherwise the shell script inside seemed to be getting confused looking for /usr/bin/make <civodul>that said, in general i would recommend against mixing compilers/libraries from Guix and from the host distro <erty>I have recently installed guix, and my wifi is not working. "nmcli" shows my wifi is enabled, but no wifi networks are shown. Even running "sudo nmcli device wifi" command doesn't list any networks. Can someone help me with problem? <spenc>civodul, aw, thats a shame fair enough <spenc>the script seemed to be getting confused anyways even with -F <spenc>me@kalonian:~/Documents/genode$ guix shell -CPF make flex bison pkg-config ncurses texinfo expat gmp gcc-toolchain <spenc>me@kalonian ~/Documents/genode [env]$ ./tool/tool_chain <spenc>make: bash: No such file or directory <spenc>make: bash: No such file or directory <spenc> Need to have 'flex' installed. <spenc>i guess docker it is for now, thank yall for the help <spenc>erty, im a beginner so take this with a grain of salt <spenc>but is it possible that your wifi chip lacks free firmware? if so, best bet is to get a dongle <erty>no its inbuilt wifi, no dongle <spenc>right, guix system removes some non-free firmware that most other linux distros have <erty>so was it wifi drivers that were removed <erty>and if so, will it be possible to get new wifi drivers <spenc>if this is the reason, then no it's not possible to get a new free software version, or else it would be in Linux-libre already <civodul>spenc: maybe explicitly add âbashâ to the âguix shellâ command line above <spenc>civodul, that did it! (well, that and which) <spenc>didnt think to add normal gnu packages in thank you <civodul>spenc: yeah itâs quite surprising at first because we sort of take these for granted, but here we have to explicitly list every software package thatâs needed <erty>Is it possible to use reboot andhalt without root <erty>since I am using window manager, It would be nice to add a keybinding to them <dariqq>erty: if you use logind you can use loginctl reboot/poweroff,etc commands which work without root <erty>I tested and it It worked. Thanks for help đ <erty>I have one more issue. I was also trying to get brightness controlled through a command, so I installed "light" package and then added myself to "video". But unfortunately, it didn't worked. I followed the same procedure on Ubuntu and it's working there. Thanks! <zeropoint>hi guix, looks like some of the recent python upgrades broke docker-compose again <spenc>so far i've tried adding it to guix/gnu/packages as gnat.scm , running guix shell -- make , and then ./pre-inst-env guix shell gnat <spenc>it finds the file, but complains about a lack of (define module <ieure>spenc, That's not a patch, it's a standalone package definition. Easiest is to slap a (define-module) call at the top and stick it in your source tree somewhere. gnu/packages/gnat.scm would be my suggestion, which gives the (gnu packages gnat) module. <spenc>it's giving errors such as this though: error: perl: unbound variable <spenc>hint: Did you forget a `use-modules' form? <spenc>relatedly, is there an easy way to hack something into guix just for personal use? For example things that are in apt but not guix yet due to lack of sources <spenc>obv the one i need right now is gnat, but presumably there will be others later <spenc>it seems a shame if the only options are to package it fully, or give up and use a different package manager and isolation model (apt inside of docker, presumably) <dariqq>erty: Do you have the light udev rule? I have something like (udev-rules-service 'light-add-udev-rules light) in my services <erty>dariqq: Thanks, I did have a udev rule: (udev-rules-service 'light light) <erty> I think I need to replace with your one <dariqq>thats the same one, the middle part is only a name afaik. I also have the udev rule for brightnessctl because i was switching between light and brightnesctl for a while. It seems to work for me :) <erty>I think I need to restart my pc to make it work. lemme check <erty>Unfortunately, It didn't worked.I tested the command "light -U 5", nothing happened. "light -P" also reported 0 <dariqq>erty: hmm, Do you get an error when using light? does light work as root? maybe 5% is to low of a value (for my display on an old thinkpad i need at least 7 because it has only 15 levels of brightness) <erty>dariqq: using light as root worked! Now the problem, how can I avoid using root đ <dariqq>ok then it seems like a permission issue. <dariqq>erty: are you sure you are in the video group and /etc/udev.d/90-backlight.rules exists? <erty>dariqq: no nothing like that exists in /etc/udev/rules.d/ <dariqq>ok then the needed udev rule is not there. Did you reconfigure your system after adding the udev service? <erty>dariqq: yes, I ran "sudo guix system reconfigure /etc/config.scm " after adding udev rule <erty>and after that restarted my system <bigbookofbug>if you're looking to not use root so that you can keybind, a workaround is to echo your root passwd as part of the command the key is bound to <erty>One thing I noticed is that after reconfiguring guix, the grub entry still shows the version 6.9.8 and is not updated. I don't know if its relevant. <erty>bigbookofbug: ok I'll look into that to run command as non root <bigbookofbug>but for example, i launce some root commands by binding the key to "echo (password-here) | sudo -S -E -s (command)" <dariqq>erty: then i have no idea why the udev rule is not showing up. Can you check the udev light service is there the saved config file from the output of guix system describe? <erty>dariqq: I ran the said command, but nothing related to udev is shown <dariqq>check the file under configuration file: and if there is the udev rule there <dariqq>in other words have you been editing /etc/config.scm file or some other file? <erty>and then reconfigured guix and restarted my system <erty>"sudo guix system reconfigure /etc/config.scm " <dariqq>erty: sry i gave the wrong path earlier; the rule should be at /etc/udev/rules.d/90-backlight.rules <erty>dariqq: I did checked that path but nothing related to backlight or light is there <dariqq>i am sorry but i am out of ideas now <erty>dariqq: no worries, Thanks for the help. I think I should delve into this problem sometime later <erty>I now have a functioning guix system, and I think I should start reading guix manual to understand its superpower <RavenJoad>Is there an ETA for the plasma 6 stuff? I saw the KDE team had it mostly packaged modulo some random dependencies failing. <redacted>I need a password in the borgmatic config on the server I manage with guix deploy. How do I keep that password out of the world-readable store? <RavenJoad>redacted: If borgmatic allows you to put a shell command instead of a raw password, you can read the password from a file you manually manage outside of the store. <fnat>redacted: You could tell borgmatic to read the password via pass? And then you set pass and the password entry statefully? <redacted>I'd like to avoid having a separate script for managing secrets on the remote machine. Is there any way to extend guix deploy to copy files to the remote machine? <ieure>redacted, I've been thinking about some of these issues for a while, I have some ideas, but no great solution quite yet. <fnat>(Something that I haven't been personally using yet, but what you said about secret management brought the blog post back to mind.) <redacted>fnat, yes, I actually came across that article this week. I forget why I didn't use it, but I'll have another look. <ieure>I think something like shipping encrypted secrets in the store and having a service which runs at startup and decrypts them with the machine's secret key, sticking them in a tmpfs somewhere. <ieure>Something like that is probably close to what you'd need. <fnat>Unrelated, how do I do something like (package '((name . "less")(version . "608")...)) instead of (package (name ...) ...)? <fnat>In other words, how does one create a record (a define-record-type* one) from an alist as opposed to individual fields? <ieure>Oh, the thing I said is pretty much exactly what SOPS-Guix does. Nice. <gnucode>well, geiser-reload-definition...is no longer working. grrr. <jaft>Is TypeScript bundled, any, for Guix or should I use NPM (if anyone knows)? <jaft>Thanks, singpolyma and spenc; those're both really helpful. <spenc>how would you reccomend packaging a project that uses fossil instead of git? (if it's even possible) <spenc>last I saw on the mailing list it wasn't possible to get a url fetch since the zip urls aren't permanent, and ofc git-fetch doesn't work since it's not git <jackhill>spenc: yeah, I noticed that too. would be nice to have a fossil-fetch :) <jackhill>"Cool! Yes, we have similar solutions for other SCMs, so doing the same for Fossil would be pretty cool (but I'm making no promises about implementing it though âș)!" Well, good thing I didn't promise. I think a fossil-fetch would be possible though. <spenc>do you think this would be a feasable project for someone new to guix? the nix version's only 20 lines <jackhill>yeah, I think it should be. I remember finding good documentation on the fossil wire protocol <spenc>gotcha, i'll look into it for a little bit. would you imagine that it would use the guix fossil package itself, ala running as a shell script <spenc>or reimplementing the protocol itself <jackhill>spenc: my brainstorm was the re-implement the protocol in scheme. Two reasons: avoid bringing in another dependency to Guix, and our fossil package currently uses the unstable zips <spenc>unrelated question, but one I've wondered about coming from npm-y style package places <spenc>is it reccomended for upstream pacakgers to auto-update packages via something like github actions whenever a pull happens <freakingpenguin>spenc: Do you mean making an official release automatically every time a PR/MR is merged? <spenc>mistyped, meant tagged not pulled <spenc>but yeah, basically is it upstreams responsibility to notify that the version has changed, or the packager's responsibility to notice or some mix <spenc>npm its essentially exclusively the dev doing the packaging, either by hand or via some build pipeline <spenc>that doesn't seem like the philosophy here, I assume so that the changes can be reviewed/tested externally first, but I wanted to make sure <ieure>Honestly don't understand the question here, but also wouldn't look to NPM for anything other than examples of how not to manage software. <spenc>i guess rephrased: in npm, the usual way to get a package added/updated is to push it there yourself (unreviewed by anyone) often as part of a CI/CD action <ieure>Guix exists more or less independently of the upstreams of the software packaged for it. There's no expectation that an upstream developer will coordinate with Guix. `guix refresh' can assist in both surfacing new upstream versions to be packaged, and in automating some of the mechanical drudgery of doing so. <spenc>i don't think that this is the way guix is doing it at all, but is there any place for automated actions to notify when a new tagged release of a package is out