IRC channel logs
2023-11-28.log
back to list of logs
<PotentialUser-96>if anyone cares running those additional steps fixed my environment setup <civodul>i restarted cuirass on berlin after deactivating the ‘hurd-packages’ jobset <civodul>like cbaines i reproduced the “Hurd bug” locally <civodul>and it does eat all available memory <A1ice>anyone using GUIX on powerpc machine? I wanna start but no idea to use it on such architecture <PotentialUser-96>I'm trying to submit my first patch and am struggling with git send-email. I've made a commit to my local clone of guix and tried to create a patch email with "git send-email -l -a --base=auto --subject-prefix='PATCH' --to=guix-patches@gnu.org" but that tells me that the "-l" flag requires an integer value. I tried giving it 1 to see what happens <PotentialUser-96>Wait nevermind, it looks like it works when I remove the --subject-prefix <lechner>yeah, that trips up everyone the first time around <lechner>it allows us to test your vision, your patience, your IRC skills, and your politeness all at the same time! <avalenn>we could change the documentation to use `HEAD^` instead of `-1`, it would avoid this confusion <lechner>love it! i may start using it too. please send in a patch <lechner>is the -1 actually needed, or is one the default? <PotentialUser-96>Ok I think I successfully sent my first patch. I really appreciate the help. <city-slicker>Now I have to learn now to create my own channel I suppose <lechner>running your own guix is the only way to fix stuff you don't like without going crazy <city-slicker>Thanks!! I'll check it out. I'm still pretty new, learning a lot, but but guix is very different from any other distro I've used <oriansj>city-slicker: think of it like gentoo but the builds are guile'd <PotentialUser-96>roughly how long should it take to get confirmation of a successful patch submission? I submitted a little over an hour ago and got a 250 result from git send-email, which seems to indicate a successful send but I'm not seeing my patch show up on https://issues.guix.gnu.org/ and I haven't received a confirmation email <PotentialUser-96>I'm not in a rush or anything, just curious to make sure I didn't mess something up. The docs do say it might take awhile for a first patch submission, so maybe it's still in a new submitter queue <lechner>it should be faster. what was the subject please? <PotentialUser-96>The docs say "Expect some delay when you submit your very first patch to guix-patches@gnu.org. You have to wait until you get an acknowledgement with the assigned tracking number. Future acknowledgements should not be delayed. " <PotentialUser-96>so I wouldn't be surprised if there's some sort of manual intervention for new submitters <lechner>i don't think so, but there have been report of delay. i normally get a response in one minute. it's fifteen at debian <PotentialUser-96>well like I said I'm not in a rush, and I know there have been some infrastructure issues the past 24 hours <lechner>it's not in the debbugs db, for whatever reason <PotentialUser-96>is there some other log you'd recommend I check on my end? I see "Result: 250" in my terminal so my understanding is everything succeeded on my end <lechner>i just checked issues.g.g.o which shows the latest submission, with #67500 being the most recent <lechner>then I checked the gap to my own #67497 <lechner>with #67498 and #67499, which are for different gnu projects <lechner>i also checked #67501, which does not yet exist <lechner>the checking i did by going to debbugs.gnu.org/X <PotentialUser-96>I guess I'll just keep an eye on the issue tracker and see if it ever comes through. <ieure>Is there some way to tell `guix build' that I want it to try rebuilding a package, even though it's in the store? <ieure>n/m --check is what I was after. <ieure>Okay, no, that doesn't work at all for no reason I understand. <ieure>Okay, so here's the situation I find myself in. I'm hacking on a package for Librewolf, which I want to contribute to Guix. I checked out a copy of guix and built it and have a working pre-inst-env to test everything out in. <ieure>Since this is a pre-inst-env, when I try to build my package, it has to build all its dependencies, recursively. <ieure>One of those is node 10.24.1, which has been EOL for >2 years. I guess it's needed to bootstrap node 18. <ieure>In any case, node 10.24.1 has no substitutes now, and the build appears to be broken. <ieure>Tried this 4-5 times, failed consistently every time. <ieure>Maybe the pre-inst-env can't use substitutes, idk <ieure>Either way, it's trying to build it, and can't, and I can't do what I want because of that. <ieure>On Guix commit 2410a30f6c06d56b5589e0ad685bcdf09bb144bf <podiki>ieure: substitute server has been having difficulties lately, but I do see node@10 as built, though not if you modified something that would cause it to differ from master <ieure>podiki, Don't think so. I updated icu4c from 71.1 to 73.1, other than that, it's all new packages. <podiki>what is the store hash of node or the derivation hash? <podiki>e.g. ./pre-inst-env guix build node@10 -n <Kolev>Does anybody here use gpg-agent for SSH authentication? ssh-add -L returns my SSH fingerprint but it refuses to authenticate to any servers. <ieure>Kolev, I do. What's your SSH_AUTH_SOCK set to? <ieure>If the agent is setup correctly, it should be something like: SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh <Kolev>It is set to /run/user/1000/gnupg/S.gpg-agent.ssh <podiki>and those servers have your key added? <ieure>Try `ssh -vvvvv user@whatever-host' and it'll show you what keys it's offering and whether the server accepts them or not. <ieure>podiki, The following derivation would be built: /gnu/store/f3p7srx4jkr6xk4xzna2d7dgiavq4zyb-node-10.24.1.drv <Kolev>podiki, servers have my key. <podiki>ieure: is it the same as in non-pre-inst-env? <ieure>podiki, I get different-looking output that I don't know how to interpret, it just prints "/gnu/store/p4w8fn9ky4mrv65v6c5w3l7kcsxmp1ap-node-10.24.1" <podiki>means it is already in your store <podiki>you can try /pre-inst-env guix graph --path -t derivation <pkg1> <pkg2> to see if there is a dependnecy you updated <ieure>podiki, `guix build node@10 -n --check --no-grafts' gives me "The following derivation would be built: /gnu/store/51q0xc2rf8shby5j3a90hki8a41qhwyp-node-10.24.1.drv" <podiki>no grafts could be a different derivation since there are so many grafts now, in fact probably guaranteed to be different <ieure>Without --no-grafts, it says "The following graft would be made: /gnu/store/aplz8f3nv2l3q130gmnq9i5y4s3dqqjr-node-10.24.1.drv" <podiki>ah that last one is the one I have locally too <ieure>`./pre-inst-env guix graph --path -t derivation librewolf node' prints two lines, "/gnu/store/4js37m8zz7mn4h740qr6xcad9yrzzqx3-librewolf-120.0-2.drv" and "/gnu/store/59nk5wpx8mfqlsv0v679zwg648win4m3-node-18.18.2.drv" -- which I guess means it's a direct dependency. <ieure>My librewolf package depends on node-lts, which inherits from node. <ieure>I guess it's that, even though the output isn't clear. <podiki>node depends on icu4c so if you updated that <ieure>I'll just change that back to 71.1 <podiki>icu4c has a ton (18k+) dependents <podiki>so that would change nearly everything in your checkout <ieure>How can I show packages that take icu4c as an input? <ieure>What a bizarre place to put that. <podiki>I started adding | head --bytes 100 to make the output manageable if i just want the number, i'm sure there is a fancier way to just get the first line <podiki>refresh tells you about updating a package <podiki>--list-dependent is the long form <ieure>That's why I think it's bizarre. The inputs of a package are a property of the package, same as the outputs. I'd expect it under something more directly package-related. <podiki>you can get it from guix graph stuff too <podiki>this is handy to know when updating something what it will touch <Kolev>podiki, ieure : servers have my key. I ran `export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)`. <ieure>I agree you'd want to know this when you refresh, but other than the time relationship, it seems to have nothing to do with refreshing. <ieure>Kolev, What does the `ssh -vvvvv` tell you? <podiki>ieure: I would say the only time I care is when updating/changing a package. guix graph has this sort of thing too, if that's more your speed <PotentialUser-96>lechner looks like the patch did end up making it through after 3 hours like you thought it would <ieure>Kolev, Also, dumb question, is your username the same on both ends of the connection? My work manages all that junk on my work laptop, so my username is ian.eure there, but ieure everywhere else. Always tripping me up (yes I know I can do config stuff to make it smoother) <Kolev>ieure, it's looking in .ssh/ 🙁 <ieure>Kolev, It's going to try multiple keys, possibly from multiple locations. <ieure>You should see lines like "debug1: Will attempt key: ..." "debug1: Offering public key:" etc <ieure>"Will attempt..." is every key ssh knows about; "Offering..." is the client sending that key to the server to see if it accepts it. <ieure>If it's talking to the agent, you'll see lines like "debug3: ssh_get_authentication_socket_path: path '/run/user/1000/gnupg/S.gpg-agent.ssh'" and "debug1: get_agent_identities: agent returned 1 keys" <ieure>Kolev, Every message starts with that. <ieure>Kolev, Can you paste the output? This is going nowhere. <Kolev>ieure, debug3: ssh_get_authentication_socket_path: path '/run/user/1000/gnupg/S.gpg-agent.ssh' <ieure>Kolev, I think this is your issue: sign_and_send_pubkey: signing failed for RSA "(none)" from agent: agent refused operation <ieure>Likely the key you have added to gpg-agent is missing the S (sign) capability, and you don't have a separate signing subkey. <Kolev>ieure, yes. I've looked up solutions to that error and could find nothing. I've tried restarting gpg-agent and everything. <ieure>I've never done SSH auth with GPG keys, only with a hardware token accessed via gpg-agent. <podiki>i do both :-P (signing subkey on hardware token via gpg-agent) <ieure>Kolev, Restarting gpg-agent won't help, the issue is the key you have loaded into it. <Kolev>I should mention, I'm doing this inside a Guix System container. <ieure>Kolev, That's your problem. It has (E) (encrypt) and (A) (authorize) bits, but lacks (S) (sign). So it cannot be used to sign anything. <ieure>You need to generate a new key, with the (S) bit enabled. <ieure>You need to edit the key to add a signing subkey. <ieure>You don't need to generate a new key. <podiki>i refer to the link I sent earlier, though about yubikey (or other cards) it is a nice guide to things like subkeys and gpg with ssh <ieure>Yes, lots of overlap between that and what Kolev wants. <podiki>sneek: later tell efraim thanks for helping with mesa-updates, I finally merged it (thanks for fixing php too!); hopefully recent berlin troubles don't cause issues for anyone on subs (though bordeaux seems good too) <efraim>Yay! I'll be at my computer in an hour or so <sneek>efraim, podiki says: thanks for helping with mesa-updates, I finally merged it (thanks for fixing php too!); hopefully recent berlin troubles don't cause issues for anyone on subs (though bordeaux seems good too) <podiki>probably barely squeeking in before mesa updates again, the version I ended up using turned out to get stuck without more releases from upstream <podiki>there's always another branch to do :) <Kolev>podiki, do I need to delete my [A]? <podiki>no you can have A, E, and S subkeys <podiki>i think you can also just add that capability to another? but might as well use a separate one if you are using subkeys <efraim>Sneek later tell civodul would it help if I poked the zabbix instance a bunch and got it set up to actually collect metrics? Re Berlin OOM <podiki>efraim: is that what has been hounding Berlin, memory issue? <efraim>Looks like make as-derivation for i586-gnu was using all the memory until it crashed <Kolev>gpg: Key generation failed: No pinentry <podiki>efraim: I see, thanks for checking. Guilty of making it work hard last few weeks, libx11 ungrafting touched everything <efraim>Kolev: gpg and pinentry are a bit fiddly, I'd suggest adding some sort of path for pinentry in your gpg-agent.conf <ieure>Kolev, Are you using Guix Home? <Kolev>pinentry /run/current-system/profile/bin/pinentry <efraim>podiki: it always starts out seeming easy, everything already built before! Then when you keep on fixing issues people suggest adding more and more patches <Kolev>ieure, no. I'm using a Guix System container. No Guix Home. <ieure>Kolev, Okay. Guix Home has a service that helps a bit to manage this. <Kolev>ieure, you can't use Guix Home inside a container. <efraim>I think we have a patch to help look for pinentry at $HOME/.guix-profile/bin/pinentry <podiki>efraim: I know. "let me just do some X-related ungrafting with mesa, it'll be easy!" (I'll still take it over tackling previous core-update merges) <efraim>There's a reason bash is still at 5.1. I haven't gotten any upgrades to build on all the architectures yet <efraim>Short version, sed from gash-utils needs to be able to parse more recent versions of autoconf output <podiki>so that means unraveling all the core stuff with some updates <Kolev>gpg: decryption failed: No secret key <podiki>ACTION goes about finally closing all those bugs/patches with mesa-updates merged! <f1refly>I'm trying to add a wireguard vpn to my configuration.scm, using a preshared key. I added the psk to the (wireguard-peer), but when I insespect the generated config in the store, the preshared-key is added verbatim (lowercase and with the dash) to the [Interface] and not to the [Peer] section. wireguard reports an error when instructed to read the configuration file. <f1refly>I believe guix does not assemble valid wireguard configs from the handed configuration expression when trying to use preshared keys. <f1refly>When not using preshared keys everything is fine. <f1refly>I believe this is because preshared-key is added to the keys list in gnu/services/vpn.scm on line 781 <efraim>do we have a bug report about llvm-15 and i686? <futurile>Blog post day for me today - finally going to start writing about packaging <sneek>civodul, you have 1 message! <sneek>civodul, efraim says: would it help if I poked the zabbix instance a bunch and got it set up to actually collect metrics? Re Berlin OOM <civodul>so we were getting OOM due to the ‘hurd-packages’ evaluation, ridiculous <efraim>yep, I just pre-seeded rust from rust-team there before pushing the updated rust-team branch <efraim>and by pre-seeded I mean I made it build there so cuirass wouldn't try to build it 50 times concurrently <civodul>it only builds it 50 times concurrently if there’s no associated job though <civodul>in this case there should be one, no? <efraim>I didn't check. There is a public rust package, but I think since it's referenced in the cargo-build-system and not in the packages cuirass thinks it isn't an input that's needed to build the rust-* packages <efraim>plus it meant I could make sure it built before handing over several thousand packages to CI <sarg>how long does it take for a substitute to be available after being built by CI? E.g. qtwebengine-6.5.2 has been built half an hour ago and still when I reconfigure my system it tries to build the same derivation <efraim>for some of the larger derivations it can take up to 10 minutes to 'bake' the substitute <efraim>you can clear your cache at ~/.cache/guix/substitute and /var/guix/substitute/cache to force your machine to check again for substitutes <sarg>the latter is for `guix system` invocations, right? <civodul>that should not be needed though :-) <efraim>shouldn't be, but will force it to check faster :) <sarg>nope, clearing cache didn't help <cbaines>civodul, negative lookups are cached for 10 minutes though <sarg>and here is what guix tells me: <sarg>The following derivations will be built: <sarg> /gnu/store/4sv7y53fflgcv0w7s92zdkcdkd1apjnh-python-pyqtwebengine-6.6.0.drv <sarg> /gnu/store/dz9x9gaqrjlxl0g3csdi1za96b7dkq9j-qtwebengine-6.5.2.drv <sarg>what is this baking please? <cbaines>generating a nar from the files in the store <civodul>so it should be available in a few minutes <sarg>not familiar with this process. It is only for published stores, right? I don't have nar files on my system <civodul>cbaines: this one has “Cache-Control: max-age=300”, which is 5mn :-) <civodul>i wouldn’t recommend clearing the cache in general because that’s not supposed to improve anything <sarg>ok, baking is explained in `Invoking guix publish` info section <civodul>it might be useful for us developers smoetimes, but that’s about it <cbaines>I struggle with it far to often unfortunately, I think it's been discussed though, and I probably need to set lower cache times in various places <cbaines>I spent some time yesterday even helping bayfront substitute some derivations <sarg>civodul, what are guix financials? Is there a public report somewhere? I learned that nix's cache costs $9000/month (being hosted on S3). <efraim>IIRC Guix Europe (did we rename it?) has the financials public <zilti>Good morning! I am trying to build Hyprland on Guix, and I am *almost* there, just - I have an issue with Meson's dependency detection. It successfully detects everything, except wlroots. I have wlroots as a package dependency, and I even added a pre-configure phase running a "pkg-config --list-all" to confirm it can see wlroots. But Meson then says "Run-time dependency wlroots found: NO (tried pkgconfig and cmake)". <efraim>maybe we should actually get a logo and not just use 'Logo' <zilti>The line in the meson.build file is `dependency('wlroots')`, same format as the other dependencies which do work. <sarg>oh, how cool is that, the financials are in a Ledger file <cbaines>civodul, I can look a bit more at the hurd stuff today <cbaines>one interesting observation is that compute-guix-derivation doesn't set %file-port-name-canonicalization <sarg>zilti run `guix build` with `--keep-failed`, get into the build dir, source the env file and debug it from here <zilti>sarg: well, I did that, and `pkg-config` clearly shows that wlroots is there. Just Meson refuses to acknowledge that. <efraim>is pkg-config in the native-inputs? is there a wlroots.pc and/or wlroots.cmake (or whatever the file is)? <zilti>It is in the native-inputs, yes <sarg>can you run meson with increased verbosity / debug flag? You need to know what exact command it is running to detect the dependency <zilti>No, seems I can't. Because when I want to create an empty build directory (which meson insists I do) by running "meson setup ../build", it prints out the previous configure run that it cached god-knows-where including the error about wlroots not having been found, and refuses to create a build dir. <zilti>I can't find where it caches that stuff. <efraim>looks like no cross compiling rust to mips64el-linux <cbaines>civodul, I think I've made some progress with the hurd derivation issue <cbaines>using glibc-utf8-locales/hurd in (%standard-patch-inputs) seems to help <cbaines>the infinite loop seems somehow related to patching perl <cbaines>which probably explains why loop detection here is difficult, as it's not at the gexp level <cbaines>patch now sent as #67507, let's see what QA says <gabber>i have a couple of gnus questions. 1. is it possible to change the status / request a status change directly via the gnus interface? <bienjensu>Where can I find `finger`? Tried `guix locate` already. <gabber>(this is in regard to #63530 which i think can be closed - the issue had been fixed some time ago) <gabber>2. i am unable to see some entries in debbugs, e.g #66870 or #63065. i start debbugs with no severities given (which disbles the filter) - so i guess i should see all non-archived bugs? <nckx>lechner: Thanks for the ping. <lechner>where do you go to get the missing parts? <civodul>cbaines: awesome! i haven’t been as efficient <civodul>janneke provided patches adding ‘libc-locales-for-target’, which may be cleaner longer-term <civodul>yes i applied them this morning to take a closer look <civodul>but that hasn’t been fruitful yet :-) <futurile>bienjensu: wow that's a blast from the past - finger! Looks like it's not packaged, or did you find it? <bienjensu>futurile: it's not packaged! It should probably be in `inetutils` but it's not. <futurile>bienjensu: oh interesting, what is it in? I tried searching for netutils which is what Debian has it as <bienjensu>Yes it used to be in GNU Inetutils. I assume it was removed for security reasons but I can't find a changelog. <lechner>bienjensu / does pinky in coretutils do someething similar? <bienjensu>lechner: yeah haha, I just found it while googling. <bienjensu>It's making a comeback on the small internet. <lechner>how about 'write', 'wall' and 'talk'? <futurile>lechner: the obvious reason being that the finger protocol has no security whatsoever? <bienjensu>Emacs still has a ‘finger’ implementation, but sdf e.g. refuses to serve finger requests. <lechner>there is probably some way to get make it work. maybe it needs RPC or a dedicated daemon like fingerd. i haven't used finger since 1993 and never missed it <futurile>yeah SDF is running finger internally - but not allowing external connections. So 'finger futurile' works for me from one of the hosts, but you can't do 'finger futurile@sdf.org' <bienjensu>Some people still respond to finger requests although I assume its with a modified/pared down fingerd, ([user]@lilysthings.org, from a lobste.rs comment). <futurile>does seem bizarre - but what do I know I read guix-dev via NNTP! <bienjensu>It seems fingerd has been the source of multiple vulnerabilities historically. <lechner>futurile / so your handle is aspirational? <bienjensu>Wow, I had no idea. The first major exploit of a buffer overflow vuln was in 1988 and targeted fingerd. <futurile>lechner: hah - I think I crossed over the point where everything in the future looks shiny, to the stage where learning a different set of commands for broadly the same outcome is just fracking irritating <lechner>he had just gotten canned at Cornell for the worm <futurile>hah wow - funny to be 'infamous' for that accident (I guess not that famous these days) <lechner>that repeat looks like a bug in the bot <PotentialUser-66>Hello, does anybody know how to use a local git repo as a source for a package for testing purposes? I assume with local-file, but idk how to exactly lay it down <lechner>PotentialUser-66 / i have seen it done but cannot remeber how. maybe just a file URL in git-reference's url field? <lizog>it seems that it tries to run an aarch64 grub-mknetdir binary and failed <lizog>would like to know if it's possible of init a file system for raspberry pi 4 on a x86_64 machine? <lechner>probably easier than on bare metal, but i have no experience with embedded devices <lechner>lizog / i have spent some time with grub in Guix and am looking at grub-efi-bootloader-chain-raspi-64. do you have an error message? <lechner>lizog / cannot execute looks like a permission issue to me, but again i have never even seen a Pi <lechner>it could be ELF vs COFF, or something like that <lechner>can you do file /gnu/store/7y12k8z6gwdyfnfz6hs32ng038hb9zs0-grub-efi-2.06/bin/grub-mknetdir <lizog>yeah the last two lines of the paste is the 'file' result <lizog>oh sorry the error message i pasted is an attempt to replace the (inputs (list grub-efi)) with (native-inputs (list grub-efi)) in "make-grub-efi-netboot", but the results are just the same <cow_2001>i am writing a guile-build-system package definition and i don't know how to get the executable script into the /gnu/store/*/bin directory <cow_2001>where do i.. uh.. define it as executable? <cow_2001>right now it goes deep into a /share/ directory <gabber>lizog: try native compilation on aarch64 (you need qemu-binfmt service up and running and must pass the --system=aarch64-linux option to the $(guix system init) command) <gabber>cow_2001: i'd have a look at other packages that use guile-build-system *and* provide some script exposed to the user. you should find a bunch in (gnu packages guile-xyz) <gabber>i expect that it all relies on guile-hall, which i believe is the underlying mechanism for creating and packaging guile-based projects <lizog>gabber: thanks i'll give it a try <trnry>So I just installed gtkwave and it seems totally unstyled in Guix. Is there some gtk think I would need to install to get that to be themed properly? Stuff like gnome-calculator look fine so I would have expexpected it to just work <cow_2001>how did you define the package inside the git repository?! <cow_2001>wouldn't changing the hash change the hash? <Guest24>how can I create a user in the Libera chat? <gabber>should have all the answers ready for you ;) <ieure>> Developers may find it useful to include such a guix.scm file in the root of their project source tree that can be used to test development snapshots and create reproducible development environments (see Invoking guix shell). <ieure>cow_2001, I think the answer is that the source repo isn't also a Guix channel (which seems to be what you thought), but defines an environment which is also used to run the code in a somewhat ad-hoc fashion. <gabber>do i send debbugs control messages to NNNNN@debbugs.gnu.org, control@debbugs.gnu.org or both? <davidh38>If I write "Guix install emacs". Will I get I new revision, that I can rollback to at restart? <ieure>davidh38, Any change to the set of installed packages creates a new generation, which you can see with `guix package -l'. They persist across reboots, so you can switch to any previous generation at any time. (Rolling back is a special case of switching generations) <ieure>I agree. I messed up my xorg config recently, in a way that made X fail to start and also rendered the console unusable. I ssh'd in and rolled back and had a working system again in seconds. It's terrific. <avalenn>but it is also acceptable to do both <avalenn>> You can CC it with your human-friendly reply after the 'thanks'. <gabber>you don't happen to know whether there's an emacs-debbugs internal thing ready for this? i seem to be unable to find that <gabber>(but i'm somewhat sure this must exist) <cow_2001>ieure: i am reading the source and it makes sense now. i will give it a shot! <sarg>hey guix, so shepherd is now implementing inetd partly? I see that openssh service is started on demand when a request comes to the 22 port. I have a host where this doesn't work - ssh attempts hang and on the server I see RECV-Q increasing <cow_2001>ieure: i am confused about the guix.scm file's sha256 field. if it's part of the package's git repository, changing the sha256 will also change the sha256 itself. how do you produce the sha256, then? <cow_2001>but guix build -f guix.scm demands a correct sha256, no? <gabber>cow_2001: it's an open secret that only the most skilled of GNU magicians actually know how to calculate the sha256sum (in the correct format) that is needed by the guix build process. everybody else just opts for doing it twice (copying the "actual value" from the error message to the package definition) <trnry>gabber: Thank God it's not just me <cow_2001>can i somehow tell it to use the local repository while doing so without needing to clone the repo from some git forge? <cow_2001>the guix.scm file points at the forge's url, not the local repository <gabber>cow_2001: yes. use (local-file #:recursive? #t) or similar <ieure>cow_2001, The commit in the source definition is an earlier commit than the one containing that reference and its sha256. <gabber>look up (local-file) in the guix reference <cow_2001>so it's always a pair of commits, really - a more recent one with a guix.scm pointing at the one right behind it <sarg>lechner: irc logs are not updating. Is it done by peanuts or some other bot? <lechner>sarg / nckx is the restarter of goggles-bot <gabber>Kolev: maybe pinentry needs to be installed in your profile as well? <gabber>you could try with $(guix shell pinentry -- gpg --list-secret-keys) <gabber>what happens if you do $(guix shell pinentry -- pinentry) ? <sarg>Kolev check ~/.gnupg/gpg-agent.conf, it should have your pinentry declaration <Kolev>pinentry-program /gnu/store/rfy36kapnhx9djhxdi3a54x5p2n097xv-pinentry-gtk2-1.2.1/bin/pinentry-gtk-2 <Kolev>pkill gpg-agent && gpgconf --launch gpg-agent <sarg>Kolev: great, though now your agent is managed by shepherd, so `herd restart gpg-agent` <ieure>j2rm, Guix doesn't include any non-free software, but most WiFi hardware requires binary firmware blobs. <gabber>j2rm: i usually opt for an ethernet cable (possibly on a USB dongle) for the installation process <ieure>j2rm, What kind of WiFi hardware do you have? <j2rm>@ieure: qualcomm atheros ar9462 wireless wifi adapter <Kolev>j2rm, if you don't have Ethernet but have a mobile device, you can tether over USB. <lechner>j2rm / what are vendor id an product id, please? lspci -vmmnn <nckx>lechner: Thanks for the ping. <lechner>where do you go to get the missing parts? <nckx>lechner: My own logs, and an ancient technique I call 'log forgery'. <lechner>but aren't those produced by goggles-bot? <nckx>Read the last few lines of my link attentively. <elevenkb>Hello there people, I'm having trouble installing guix. <elevenkb>I've installed successfully on the computer that I'm typing this from... <nckx>lechner: So I just copy-pasted the timeframe from my ZNC logs into the text file on bayfront. <elevenkb>the issue is that when I boot, grub doesn't find my LUKS partition. <elevenkb>I do believe that it may be specified through UUID and that one can determine the UUID through cryptsetup luksUUID right? <nckx>GRUB doesn't support LUKS2, which (I think) is the cryptsetup default. Did you create it with LUKS options? <elevenkb>it supports the PBKDF2 key derivation function with LUKS2. <nckx>See (guix)Keyboard Layout and Networking and Partitioning <elevenkb>nckx: what would make it flaky (in your experience)? <zilti>Oh man, Guix's documentation is awesome <nckx>elevenkb: I don't know! Someone followed the Guix manual's instructions to a tee and it still didn't work, so I treat it with some suspicion. <nckx>(And reformatting it as LUKS1 with no other changes made it work, so it was something related to the terrible two.) <lechner>what is the hurdle to supporting v2? <elevenkb>that other machine in ancient,,, dual core pentium <nckx>It's just mostly unimplemented. <nckx>(This is Savannah world, so the most recent comment is at the top. Yes, really.) <lechner>looks like elevenkb's old equipment doesn't have AES-NI, which results in another hash being picked <nckx>Your Savannah rewrite is almost finished, right? I expect it to be live by Christmas. <lechner>i'm getting there but my wife had a baby <gabber>(sorry, congrats from me as well) <elevenkb>lechner: how could I know what the hash is? <lechner>now that is definitely above my pay grade <lechner>ACTION has never used LUKS and encrypts user data instead <elevenkb>are you referring to the hash of the main "keyslot"? <elevenkb>ok, let me give up on this... it is a bit of a distraction tbqh. <lechner>One thing that I haven't seen mentioned anywhere (not in the commit that added LUKS2 support, not in ArchWiki or other places) is that not only does the keyslot need to be PBKDF2, but it also needs to use a sha256 hash and/or the keyslot hash has to be equal to the AF hash. Keyslot=sha512, AF=sha256 didn't work. I didn't try with both as sha256, but someone reported it worked for them: <nckx>You *should* be able to convert LUKS1 to LUKS2 in place, so creating a LUKS1 volume ‘for now’ might be an option. <nckx>But I can't say I've tested that claim. <nckx>I'm sure there are limitations. <elevenkb>thanks for the help ya'll's I might try again later... but gotta apply to finish undergrad (senior year is a seprate degree in my home country) <futurile>Q: if I do `guix build --cores=2 --max-jobs=2`, am I telling guix to use (a) 2 cores in total, and there will be a maximum of 2 parallel builds, or (b) 2 parallel builds in the daemon, of which each gets to use 2 cores ?? <nckx>lechner: Executable as in guix pull? Add --roll-back. <j2rm>@lechner: al lanzar lspci -vmmm <futurile>the manual page for `guix build` and the one for `guix daemon` are slightly confusing me <nckx>If you use -{M,c}8 you need to be prepared that there might be 64 threads at some point in time. <lechner>nckx / how may see the generations, please? <nckx>guix pull --list-generations (see --help). <j2rm>@lechner: vendor Intel Corporation <futurile>nckx: ah intersting! this totally explains a frustration I've been having about builds taking so much space on my laptop - thanks for clarifying. <gabber>is the x in xvnc-service-type an indication for the service to be incompatible with wayland? <nckx>futurile: I didn't read the manual, but if you think it can be improved, patches are always welcome. <zeropoint>hello, guix. I have a bit of a problem. I've used an (include "file-systems.scm") in my system configuration and lost the changes that I had made to that file. Is there any way to recover that file from the store? <nckx>How does an X server be ‘compatible with Wayland’? <nckx>Wayland applications can't run under X. <gabber>yes. but vnc could also serve wayland applications, no? <ieure>The VNC protocol is able to serve any graphical application, sure. But that doesn't mean that xvnc *can*. <nckx>VNC is just a protocol to send screenshots & input over the network. Xvnc is an X server that ‘renders’ to a VNC client instead of to a screen, and accepts input from a client instead of from a keyboard/mouse. <lechner>zeropoint / maybe via the information provided by 'guix system describe'? <nckx>VNC can ‘serve’ Microsoft Windows. That doesn't mean that Microsoft Windows supports Wayland. (I'm not mocking you; that's the exact same reasoning and might help clarify the confusion.) <gabber>soooo, if i have on my server machine xvnc-service-type running and i sit on my laptop (wayland) with xwayland installed, it should still work? since xvnc spins up its own x window server? or am i mistaken? <nckx>Xvnc is an implementation. Someone might already have written Wvnc but it wolud be a different daemon & service. <nckx>gabber: It *is* an X window server. <nckx>Xvnc does not ‘connect’ to Xwayland. They would be 2 separate X servers on one machine. <zeropoint>lechner: the configuration file from guix system describe doesn't have any reference to the file-systems.scm <lechner>vnc is like a movie format. it sends pixels <zeropoint>I tried using guix gc to see if there's any connected files in the store <gabber>i understand the sending pixels part. following that logic it should not matter *what i have locally* -- as long as i get vncviewer up and running it should happily serve whatever xvnc-service-type produces <nckx>gabber: If you connect a client to Xwayland it would render to your screen, if you would connect a client to Xvnc it would show up to VNC clients, but they would not interact. <nckx>But wayland clients can't interact with Xvnc. <gabber>and just as i thought i had my head wrapped around things you got me confused again (: <lechner>zeropoint / maybe you can guix system roll-back and then piece together the info you desire <lechner>zeropoint / you have to look for the configuration in the past generation (with list-generations) but the include is probably not filled in <lechner>i'd rollback and rewrite filesystems.scm from /etc/fstab or whatever <nckx>zeropoint: Unless you used (local-file …) or so to explicitly intern your file-systems.scm, it won't have ended up in the store. <nckx>Guix doesn't magically resolve includes or dependencies like that. <gabber>nckx: by "wayland clients" you mean graphical (wayland) programs, right? <gabber>ok, but if i have xvnc-service running on *that* machine and do the example from the manual - ssh -L5910:localhost:5910 my_host -- guix shell xclock -- env DISPLAY=:10 xclock - this should still be accessible from my laptop through vncviewer <nckx>Yes (conceptually, I didn't vet the command line). <nckx>But not if you'd run ‘wayclock’ or whatever, regardless of whether you happen to be running Xwayland. <gabber>turns out i did the ssh-with-port-forwarding-command from the terminal window which was already on *that* machine <gabber>ACTION figures it's not hackey time anymore <lechner>wow guix pull --list-generatins is "indexing objects" <gabber>is that the only output you see? <lechner>no, it showed two generations from January <gabber>i got my first few entries rather quickly but now it seems to garble up stuff (and it is pretty slow) <gabber>maybe it got somewhat broken (and you're the first to notice it) <lechner>well, that's why i mentioned it. thanks for confirming <gabber>i actually see 3 (really old ones) and then some seemingly interesting information (1 new channel; 2 channels removed, etc) but the process now seems to hang <lechner>i sawa few more but am still in january <lechner>maybe the search for 'news' is slowing it down? <futurile>Q: I have openssh installed. If I want to `guix challenge openssh` I first need to build it locally. When I do `guix build openssh` it informs me that I already have it installed ofc. The only way I know is to find every reference to openssh in my profiles and delete it (probably using `gc referrers`). It's pretty problematic removing SSH from my system. Is there any other way to build openssh <futurile>locally and do guix challenge without first removing openssh everywhere? <gabber>what are you actually trying to figure out? <gabber>$(guix challenge openssh) renders some nice output on my machine <futurile>and it says "could not challenge: no local build" <futurile>which makes sense, because I would have used a substitute when I installed it <gabber>i think the "no local build" means there is no build on ci.guix.gnu.org <futurile>oh - not that I don't have one locally, so it can't compare what I have versus what it has on ci.guix.gnu.org <gabber>if you omit the --substitute-urls part you see it compares the version from bordeaux.g.g.o and ci.g.g.o which are identical <gabber>and for your original question: if you $(guix build openssh --no-substitutes --no-grafts) i think you will rebuild the whole darn thing locally <gabber>which might make you able to compare to one single build server. <gabber>you might want to build openssh-sans-x tho, just to save some compilation time <darkexior>hello, i want to run guix on a computer i have: motherboard is MSI Creator TRX40, the GPU is Nvidia GTX 670 and i have msi for memory. Can I run gnu guix completely free in this setup? <gabber>darkexior: i have my doubts about your graphics card but i am not sure. is it listed on h-node.org? <gabber>so guix will run - free as always - but it might not make good use of your graphics card <darkexior>oh darn i think it is but it's a mobile version i think of the same gpu? <darkexior>NVIDIA Corporation GF114M [GeForce GTX 670M] (rev a1) <darkexior>but, what about firmware in my motherboard? doesn't that interfere with guix being 100% free? <darkexior>if it's ethernet then i shouldn't worry about that? <futurile>gabber: yeah it's weird. I have no idea what that 'no local build' part is supposed to mean. I just build 'cbonsai' locally, and then did `guix challenge` with/without the substitution servers - and it always says 'no local build'. <gabber>futurile: did you actually *build* locally, or did you just $(guix build cbonsai) and it fetched a substitute online? <gabber>darkexior: do you mean firmware as in BIOS? <gabber>i haven't had issues with motherboard/on-board ethernet and the likes -- but i am not an expert in the field either <gabber>usually it's graphic cards and WiFi that wouldn't work with free software <futurile>gabber: no definitely built it locally: guix shell --container --nesting --development cbonsai --network nss-certs; guix build cbonsai --no-substitutes --no-grafts. I even `gc --delete <blah>` and check the directory was no longer in the Store, and then rebuilt again. <futurile>gabber: and each time you do 'guix challenge cbonsai' (with our without substitution servers) it says 'no local build' <gabber>the `;' might have tricked you, though. i think execution *inside the container* would have been with a `--' <darkexior>gabber I see, okay cool. So you're telling me that AMD processors or Motherboard BIOS don't have spooky software that guix can detect? like some sort of spooky root access that can transmit information through internet to the manufacturer? <gabber>darkexior: there is absolutely no guarantee for any such a thing, maybe ever. <darkexior>only if you deliberately buy libre hardware i guess <gabber>not that i want to spook you but somewhere among the billions of transistors and the thousands of miles of wire connecting them there might as well be a (hardware) trojan that transmits every detail of your private life to i-don't-know-whom <gabber>it goes a little deeper than that, unfortunately. as long as we rely on processes that are impossible for single people (or small, trustable organizations) to verify (from planning through blueprints to actual hardware) we rely on unprovable trust <futurile>gabber: ack - well most problems are user error - not seeing it right now - sleep and try again tomorrow <gabber>darkexior: it is all not that bad™ if you mostly share memes and gifs of cats online ;) <darkexior>aren't lenovo libreboot thinkpads more thoroughly tested for that kinda stuff? <gabber>darkexior: yes: with relying on free software you choose not to deliberately feed adversarial networks and other observants with your data, which is quite something in a time like this ;) <gabber>libreboot (iirc) is a replacement for the proprietary BIOS firmware, so there is less blind vendor-trust involved <futurile>gabber: actually got it - if you build locally and do `guix challenge` outside of a container it works; if you do guix challenge inside a guix shell container, then it gives the no local build thing 
