<nckx>Xanderificnl_: Yes. Both will invoke different copies of guix, which may be at wildly different versions. <Xanderificnl_>Good to know. As per the manual, I'm guessing the user's $PATH is prefered? <nckx>‘sudo guix’ still invokes your regular user's guix, but as root. ‘sudo -i guix’ invokes the ‘system guix’, for lack of a better word. The one that provides the daemon, is available to newly-created users that haven't yet pulled their own guix, etc. <nckx>It is strongly recommended to always use your own Guix, yes. <nckx>Actually, no, ‘sudo -i guix’ will invoke root's guix if root has ever pulled guix. It just goes to prove my point that on this 5+ year-old system I've never pulled as root once and forgot that :) <Xanderificnl_>Good to know. Guix's documentation so far is amazing, and I haven't scratched the surface yet. It is super refreshing! <nckx>Thanks! It shines in places, but there's plenty of room for improvement too. <nckx>Please don't hesitate to ask if something is still unclear after careful reading. <apteryx>nckx: no, it seems fine, I was just confused that it's not 'linked' with it <apteryx>seems it mostly has to do with configure time checks, which then conditionally enables some code that only deals with a gpm daemon (outside of Emacs), so there's no refrence kept to a gpm library <apteryx>I found out that mailutils as an input is similar; it's useful during configure time, to ensure Emacs later looks for movemail from PATH instead of using its own fallback, which would be inferior and insecure. <nckx>Your understanding is 100% correct. <Xanderificnl_>Yes, that's how I interpreted the note in the manual, too. I'm still missing a few bits of information, but still many chapters to go. I'm surprised the recommendation isn't the other way around (i.e. using root's package definition for the global system configuration, and the user's definition for the user.). <nckx>(That was the consensus above, but I didn't verify.) <apteryx>not sure why but I've updated mailutils, and attempting to build the emacs collections it affects (via 'emacs' I think), I saw it attempting to rebuild the whole rust chain; retrying now, it seems to have gotten a substitutes for rust <apteryx>or at least it's not bothering me with it anymore <nckx>Sometimes it's your lucky day :) <Xanderificnl_>Discarded the prebuilt VM and starting from scratch to get a better feel/idea. I'm settling on manual installing, but the graphical installer in combination with QEMU are a bit in the way. Usually you can switch tty's via ctrl+arrow, but the graphical installer seems to be catching that. So I ended up ctrl+alt+2 (switch to Qemu console) and <Xanderificnl_>executing `sendkey ctrl-alt-f3` manually, and switching back to the machine via ctrl+alt+1. TTY2 and TTY3 can be switched via arrows. <Xanderificnl_>Perhaps this could be documented or the graphical installer can add a key mapping to switch to docs/terminal via `chvt`? :) <lfam>We should definitely add the QEMU incantations to the manual section Installing Guix in a Virtual Machine <nckx>Would you mind putting that in a bug report to bug-guix@gnu.org? If you don't have the time I'll do so to make sure it doesn't get lost, but I'm pretty clueless about QEMU. I figured out the same workaround as you but thought it was just me missing a more obvious way. <nckx>Yeesss, thank me for doing nothing and getting you to do it for me. <Xanderificnl_>(honestly, though: I think instead of working around Qemu, the real solution is to just add mappings like: F2 and F3 to `chvt` to the graphical installer, it'll be more universal. I'll suggest that in the bug report. :)) <lfam>"[...] it is worth noting that the fact that the defendant’s infringement was established in this case was because the violation of the GPL3.0 agreement led to the automatic cancellation of the GPL3.0 agreement, and the defendant lost the source code authorization protection under the GPL3.0 agreement, which constituted infringement." *nckx had to read that twice. <lfam>Hopefully it holds up on appeal <nckx>Is there an equivalent to ‘-U <context lines>’ for ‘git commit -p’? <lfam>Like, how many lines to consider as "making a diff" when interactively staging changes? Or just how many lines to show? <nckx>It's asking me about a hunk that is either vital or totally bogus depending on the context it's not showing :) <nckx>I can diff it in another window but thought I'd ask. <lfam>Not sure but this old discussion suggests "no" <lfam>I am sympathetic to the "multiple windows of Git" workflow *nckx 's never bought into magit or such. <nckx>Yeah, but you're an editor unbeliever. <nckx>lfam: No idea, it was a more general reply to your more general workflow statement. <lfam>I'm sure Git would take a patch for this <nckx>iskarian: I feel like the one kid at the party awkwardly waiting for the magit to kick in, but feeling nothing. <lfam>Who knows, maybe there is something buried in `man git-config` <yewscion>Hello all, I've been struggling with an issue for a few days now. I've recently made the switch to Guix as my daily OS. The only issue I've found so far is that EMMS will not play any of my MIDI files using timidity. It skips them, as though the file is complete, and simply cycles through the entire playlist. Anyone here have any ideas what might be causing that? <nckx>lfam: OK, I can try throwing it on top of the todo pile and listening for the clunk. It does sound easy… <lfam>I don't know about those programs but hopefully somebody can give some advice <nckx>yewscion: Does it log anything AFAYK? Or can it be made to? <nckx>EMMS is one of the many fine programmes I don't use. *nckx feels like they've said that alot today, promises that they do, in fact, use software sometimes. <lfam>Regarding the Git thing, maybe the config option diff.context? <nckx>Works but only for ‘git diff’. <excalamus>Looks like pressing e or E will get you to an ediff which shows the entire file <nckx>No, I don't use it at all. <nckx>But OK, point in the pro-magit column in that case! <excalamus>I have no skin in the race. Just use it because I have to use git <nckx>Which is probably as high as such praise tends to get. <yewscion>nckx: I've been looking for some way to log more verbosely than the default, but it doesn't seem to be something that's built in, unfortunately. I'll keep looking. Bongo works for now, but I do prefer EMMS. Either way, thanks for the warm welcome, lfam and nckx! <Xanderificnl_>Was away for a bit, but submitted it a couple of minutes ago. Haven't received a bounce or success mail back yet. So I'm guessing the bug will show up in the tracker at some point. If something went wrong, please let me know! <lfam>Xanderificnl_: If it's your first-ish mail to the mailing list, it might be held for a little bit for moderation. Subsequent emails should go through more quickly <lfam>Which list did you send it to? <Xanderificnl_>I sent it to the email adres mentioned above ( "bug-guix" <bug-guix@gnu.org> ) <iskarian>nckx, it's only magic insofar as it's integrated into emacs, it's interactive, and it adds a bunch of discoverability to git. If you already have your git workflow down, a lot of that isn't as useful. <nckx>Xanderificnl_: You're not in the queue, but it can sometimes take a while. <Xanderificnl_>So the reason I'm going for the manual install, instead of the graphical one, is because it asks for locale language: and afterwards region. What I *want* is to set my language to English but my region to the Netherlands, but that isn't an option. Any idea why? <lfam>iskarian: Regarding "Remove when updating", does that mean "Remove when updating the package in question? Or the default Go? <nckx>iskarian: Oh, that's actually an interesting and helpful view, thanks. <Xanderificnl_>Ah, that's fine. I figured there be a cron job or something running at some point! <iskarian>lfam, remove when updating the package in question as it's in master, so it'll be in the next version <lfam>Xanderificnl_: First messages to an ML sometimes take a little while. Sorry about that... it does improve later! <nckx>I consider myself very familiar with [my use of] git, warts inclusive, so maybe that's why I don't see the appeal. <Xanderificnl_>ah no worries. That makes sense from an anti-spam perspective, I suppose ;-) <lfam>Hey nckx, did the new ntfs-3g work for you? <nckx>lfam: Oh, yes, I forgot to report back. <lfam>Also iskarian, should go-github-com-keybase-go-ps get a comment like that? <lfam>Also, feel free to ask me to give feedback over email <iskarian>lfam, probably not: there's no fix in master and issues aren't enabled for the project so I'm not even sure how to report it <iskarian>(Sorry for the delay, was trying to track down a way to report it...) <lfam>Nothing to apologize for :) <lfam>It's awesome seeing all the work on Go <lfam>There's some really cool free software written in Go <iskarian>It does get frustrating that it seems like every time I want to install something, they want me to install a language-specific package manager first <lfam>Yeah... Guix to the rescue :) *iskarian dreams of One Package Manager To Rule Them All... <apteryx>iskarian: for me what is magical about magit is the ability to easily stage/unstage hunks or even parts of hunks <lfam>Parts of hunks... that is something I struggle with in `git add -p` <lfam>I can sometimes do it, sometimes not <iskarian>Yes, you can select certain lines of the patch to stage <lfam>If it's at all complex, I can never do it in a way that Git accepts <iskarian>I do fight with magit's rebase tooling, though <lfam>Complex rebasing is somewhat challenging with Git too. I've done it many times but you have to stay focused <lfam>I guess the "problem space" is not trivial <iskarian>Yeah, they said they didn't want to do a magit-style rebasing interface because of the complexity <lfam>You mean, Git doesn't want to do what magit does? Or vice versa? <iskarian>Or rather, I should say, a magit-style rebase conflict resolution interface <lfam>Magit doesn't want to try doing it in their style <iskarian>If there's a rebase conflict, magit just says "oops! There's a conflict you've got to resolve", and you resolve it with whatever merge tooling you have <iskarian>You don't get to use Magit's special hunk-based interface for it <iskarian>lfam, I sent a patch for the Go aarch64 bug based on the issue you linked. I have no idea if it'll actually fix it, but I guess it's worth a try? <lfam>Yeah, definitely worth a try <lfam>Are you able to test it? <lfam>Or do we need to facilitate something <iskarian>No, Go 1.4 doesn't build at all on qemu-aarch64 <iskarian>and I think it builds fine on native aarch64 already <Xanderificnl_>Does anyone save their configs w/ secrets in Git? I haven't been able to find an example online, or I'm using the wrong keywords. ;) <lfam>I guess if it contains a secret it probably won't go online ;) <lfam>Is there a specific type of secret you need an example of? <Xanderificnl_>I figured there might be a way to encrypt secrets (i.e. with (r)age) such as user passwords <lfam>But there are some caveats... <lfam>"Note: The hash of this initial password will be available in a file in /gnu/store, readable by all the users, so this method must be used with care. " <lfam>But that's not exactly what you're asking about, right? <nckx>Xanderificnl_: Both mails arrived & approved. <Xanderificnl_>Yeah, I'm more or less asking how I can distribute secrets (including user passwords) in my configs via Git, without secrets being exposed. <nckx>It is a rigorous process. <lfam>IIUC, that property does hold for the user passwords, since a salt and hash are stored, not the password itself. But this requires the program being instrumented to support being used this way <lfam>I'm not sure if anyone has considered how to do this generically in the context of Guix OS declarations <lfam>Well, it's not clear to me if that property holds for user passwords <blackbeard>It's been awesome!! and finally my project is super slow <lfam>Xanderificnl_: "If you do want to set an initial password for an account, then this field must contain the encrypted password, as a string." Sounds like what one would want? <blackbeard>If anyone knows any simple bug to start with let me know <nckx>I'm still swapping in ‘new’ happenings myself. <blackbeard>tomorrow I'll participate on haskell.love presenting speakers <old>Hey! Anyone know where I can find the complete man pages for pthread? I have `man-pages` installed, but there's a lot of pages missing such has pthread_barrier_* and pthread_cond_*. <Xanderificnl_>So amongst others, yes: also user passwords. It wouldn't be much work to actually just `passwd` manually, but I'm thinking bigger, i.e. everything that's confidential so I can quite easily get up and running on another machine. <nckx>blackbeard: That sounds fun. <nckx>Xanderificnl_: It makes absolute sense, but the general ‘secrets in guix’ topic is still an unsolved (and probably fun) problem. <Xanderificnl_>That's good to know. That explains why I wasn't having luck searching <lfam>So I guess we "just" need to copy agenix? :) <lfam>It might be nice to avoid the Rust dependency for now, but there are other options besides age <Xanderificnl_>lfam thanks though. I'm sorry I wasn't very clear to begin with ha, had some difficulty clearly conveying/translating from what my brain was thinking to what I was typing :) <blackbeard>I am gonna be installing Guix on my laptop and then I'll check some issues I can start with <Xanderificnl_>Age is written in Go I think. Rage is the Rust variant iirc. <blackbeard>I am gonna be using my work's laptop, let's nothing gets broken :p <lfam>Yeah, whether Go or Rust, I'm not sure we are ready to make Guix depend on those languages. We have support in Guix but it's somewhat dicey. But it should be possible to provide a basic and correct file encryption utility in Scheme or C <nckx>old: Unless you find information to the contrary, I think that's because those are nonfree. Sorry. <lfam>I did not say *who* would provide it <nckx>E.g. ‘The Institute of Electrical and Electronics Engineers and The Open Group, have given us permission to reprint portions of their documentation.‘ <nckx>‘us’ being notably different from ‘anyone’. <Xanderificnl_>Some GitHub repositories have a website link... you click it, and you'll end up with a new tab to the same repository. Man, how I dislike that. <lfam>Yeah I just noticed that... <lfam>I've been reading about age since filippo first started designing it but I wanted to find the design document <Xanderificnl_>It's really just one of many times that happens. Everytime I think: "why would you register a domain to advertise on GitHub just to return us right back to GitHub?" -- anyway /end of rant. <singpolyma>Is there a way to get guix build to leave the /tmp/guix-build-* directory in place for debugging build errors? <nckx>old: If you do find free copies of those pages anywhere else, let me know, I'd be interested in adding them. <lfam>I spent some time looking for a standalone AEAD data encryption utility. It's not a use case that's well-served <lfam>I added a bunch of esoteric encryption packages but none of them have the momentum of age <Xanderificnl_>Age is going pretty fast, given it was created a year ago iirc <Xanderificnl_>"Why: It was faster to write than remember how to use GnuPG and OpenSSL." <-- that just says it all doesn't it? <lfam>The quip about being faster to write is funny <lfam>Writing is definitely easier than reading, if you know what you want to do <lfam>The trick is making sure other people can understand what you wrote ;) <Xanderificnl_>I'm on the bandwagon. My weekend just started, so I might as well give Guix an actual try on my desktop. So far I'm impressed and excited. <old>nckx I see. Everything that's under man(3p) is not free copies because it's from the IEEE? <lfam>blackbeard: Weird video scaling? <nckx>old: That is my understanding. <blackbeard>lfam: oh no it is an screeshot, I was just happily sharing <blackbeard>right now I am downloading, seems like the server is kinda slow 20.00KB/s *nckx just noticed it's 4:30 in Europe and holy poops do I need to go to bed. Night all. <old>nckx Hmm yes. From the book The linux programming interface, it says that the IEEE has grant permission to quote portions of IEEE Std 1003.1 <lfam>I'm getting fairly high speeds from the US <lfam>Not sure what's up... sometimes it gets really slow for me too <lfam>I'd guess the datacenter that hosts us has something going on <Xanderificnl_>Does Guix have mirrors? i.e. local mirrors or is it supposed to geolocate a mirror or something? <Xanderificnl_>Searching Guix mirrors just gives me a lot of Git repositories <lfam>There is a mirror(s?) in China, but that will probably be slow if you are not there <lfam>We have two build farms ATM, maybe the new one bordeaux.guix.gnu.org is faster <lfam>It's recently been added as a default but I don't think that older installations will add it automatically <Xanderificnl_>Anyway, I'm going to boot into the installer. I'll be back after I'm running Guix! <blackbeard>lfam: yeah it went up!! I was getting 3.35MB/s and finished super fast <singpolyma>Anyone have a guess why (arguments) in a package definition might be seemingly ignored by guix build? I'm trying a #:phases modification, but even setting #:tests? #f seems to have no effect. Even putting full typos and whatever in there causes no change in behaviour... <lfam>singpolyma: It could be that the development dependencies if your Git checkout have been deleted <lfam>In that case, you'd need to do `guix environment guix -- ./configure --localstatedir=/var` again <lfam>When that happens, Guix can't recompile based on your code changes so you end up using stale compiled Guix <singpolyma>I'm not running inside a guix git checkout, just using guix build from my user profile <lfam>Oh, how are you testing your changes? <singpolyma>the first definition there is the one I'm working on at the moment (as you can see from the end of the file it is what is returned) <lfam>I think your ruby-concurrent-ruby package is being shadowed by the one in Guix <lfam>Oh, no, that's called something else <singpolyma>hmm, yeah, I would expect the one in guix to build without error, and also it's named ruby-concurrent looks like <singpolyma>that said, it means the importer just didn't find it and maybe I can use that :P <lfam>Your package builds when I name it something else <lfam>I mean, my changes are effective <lfam>I don't understand what's going on <singpolyma>oh really? if you just rename it then the phases starts working? <lfam>There are two definitions of ruby-concurrent-ruby in your file <lfam>I think that's the issue <lfam>The 2nd one is on line 472 <singpolyma>oh shit, I just found that too. bah. that's what I get for autogenerating my file <singpolyma>Is there a different "inputs" thing for dependencies only needed when running the tests? <lfam>It would be native-inputs <lfam>These are dependencies needed at build time. When cross-compiling, Guix needs to make them available for the "native" system rather than the target system, hence the name <iskarian>Hmm. `guix size' double-counts hardlinks <lfam>blackbeard: Hm... does something in your ~/.bash_profile or ~/.bashrc use lesspipe? <lfam>I don't have lesspipe available on my Guix System but `guix environment guix --pure` doesn't print that message <lfam>I wonder what is trying to use lesspipe... <blackbeard>Command 'lesspipe' is available in the following places <blackbeard>The command could not be located because '/usr/bin:/bin' is not included in the PATH environment variable. <lfam>I don't think anything in Guix relies on lesspipe <blackbeard>didn't work, anyway I'll try to build everything if Guix doesn't need lesspipe <blackbeard>running make right now, let's hope everything works <muradm>sneek: later tell civodul, after merging master, there is an issue with system tests, tests them selves are passing, something around them is crashing: https://paste.rs/6hd <muradm>sneek: later tell civodul, basically "make check-system ..." not working, i tried some tests under gnu/tests/*, they all fail the same, test executed, conditions pass, but something around them fails <dhruvin>sneek: later tell maximed I was able to add a profile with latest guix using (latest-channel-derivation). I'll symlink first generation of "/var/guix/profiles/per-user/build/current-guix" to it in the shepherd-service (the way guix pull internally does). With this development, the users of guix build image can safely install packages (via manifest.scm or guix install) and get latest packages from substitute servers or build from latest <dhruvin>definitions, without running guix pull first. <dhruvin>I'm working on pre-populating guix repo checkout in "~/.cache/guix/checkouts/<guix-repository>". So even if the users run guix pull, they recieve only the missing commits from guix's git server, and not the whole repo. I believe not downloading the whole guix repo will lower the burden on guix git server, and will save significant bandwidth (since the builders are run every commit). <dhruvin>context: I'm developing a guix build image for sourcehut. Currently, I am trying to build a latest guix image (for ci) with minimal recurring communication with guix servers. <attila_lendvai>nckx, random thought from yday: shouldn't guile.scm have a (define-public guile gule-3.0), to designate a reasonable default for simple stuff like wrap-script? <sneek>Welcome back civodul, you have 2 messages! <sneek>civodul, muradm says: after merging master, there is an issue with system tests, tests them selves are passing, something around them is crashing: https://paste.rs/6hd <sneek>civodul, muradm says: basically "make check-system ..." not working, i tried some tests under gnu/tests/*, they all fail the same, test executed, conditions pass, but something around them fails <PurpleSym>dhruvin: Pre-populating the checkout cache would be very useful imo. Running `guix pull` the first time is very painful right now, especially with lots of users on the same system. <civodul>muradm: thanks for testing & reporting the issue! i'll take a look <dhruvin>PurpleSym: Yes, that's the intention. Right now, I'm using a hacky way to do it. That is, tarballing the checkout in cache and then adding it to the store, to preserve the writeable bit of files. If you know of a better way of doing it, do share. :) <robin>gpu passthrough with virto-pci is such a pita, even with vendor-refresh. i can't wait til virtio-gpu or whatever it's called is a suitable replacement <robin>it did give me the opportunity to see a bright red kernel NULL dereference error for the first time, though (when the old driver lost control at an inconvenient time, i guess) <abcdw>Hi guix! A small question about channels: Which modules appears in ~/.config/guix/current/lib/guile/3.0/site-ccache/? <abcdw>Seems gnu/home-services/shepherd.go doesn't appear here until I import it in some other module, which is already here. <muradm>abcdw: this is not modules i suppose, it is related guile <muradm>so, when you run guile some.scm under your user, it's compiled some.go version will be cached there <muradm>on next run of "guile some.scm" if some.scm is not changed, guile will use cached some.go <muradm>if you use some "installed" module, most likely it's cache is comming with the package <muradm>or goes to current profile site-ccache <muradm>basically as a user, one should not care what is in site-ccache i suppose <muradm>in the end of the day it is disposable cache of precompiled scheme files <abcdw>muradm: I work on wip-guix-home branch right now and curious why one of the modules didn't get compiled until I import it in some other module. <muradm>no idea, may be not precompiled at build time, and/or other sources using it was always executed with "guile --no-auto-compile" option <muradm>and you import it and executed without "--no-auto-compile" option, so it is getting compiled into ccache <muradm>that could be intention of author maybe, dunno <abcdw>muradm: I'm the author of this module >< it's not my intention) <muradm>that gnu/home-services/shepherd.scm i suppose it is part of guix? <abcdw>If I import (gnu home-services sheperd) in (gnu home) for example, the sheperd.go starts appearing. <abcdw>But semantically I don't need to have this import in (gnu home). The question is how to get shepherd to be compiled and appear is site-ccache without importing it in the other module. <civodul>abcdw: hi! the reason is that (guix self) picks modules that are referenced somewhere <civodul>if (gnu home-services shepherd) isn't referenced anywhere, and isn't in one of the directories that (guix self) searches, then it's not picked up <civodul>BTW, (gnu home services ...) would seem more consistent to me :-) <abcdw>civodul: Hi! Yep, already realized it. Do you have any ideas how to get it picked?) <abcdw>Seems system service modules are get imported by test namespaces. <abcdw>(gnu home services ...) looks nice, but then it would be better to have (gnu system services ...) instead of (gnu services ...) <akib>Any Guix GNU/Hurd users here? <maximed>abcdw: (in case you are running guix home from ./pre-inst-env): Did you at the module to Makefile.am? <sneek>maximed, you have 1 message! <sneek>maximed, dhruvin says: I was able to add a profile with latest guix using (latest-channel-derivation). I'll symlink first generation of "/var/guix/profiles/per-user/build/current-guix" to it in the shepherd-service (the way guix pull internally does). With this development, the users of guix build image can safely install packages (via manifest.scm or guix install) and get latest packages from substitute servers or build from latest <abcdw>maximed: it works with ./pre-inst-env, now I tries to use wip-guix-home branch as a channel. <abcdw>Nope, it's added to gnu/local.mk only. Doesn't seems that there are any (gnu service ...) modules in Makefile.am <maximed>akib: not using GNU/Hurd myself yet, but I'm trying to make more packages cross-compilable to the Hurd (without a childhurd) <maximed>(in particular the graphical software needed for a desktop environment) <efraim>looks like I messed up my manifest, I have two copies of git and none of git:send-email <civodul>abcdw: we could/should add guix/home/services to the set of modules that (guix self) builds <civodul>abcdw: re namespace, i think it would be ideal if (gnu services ...) could be used by both Guix Home and Guix System, to some extent <civodul>akib: hi! yes, the Shepherd works on the Hurd <akib>But herd stops working after reboot on Hurd :( <akib>It say: error: connect: /var/run/shepherd/socket: Connection refused <abcdw>civodul: Added home-services to system modules in (guix self), seems working, thank you. <abcdw>About namespace naming: I'll try to remember the problems I had, when I tried to mix home and system services and probably will make a thread on guix-devel. <civodul>akib: so you run "reboot" and then "herd status" no longer works, but the machine hasn't rebooted yet? <civodul>i just tried on my childhurd: running "reboot" reboots it, and that's all <civodul>so the "reboot" command never terminates, so to speak <attila_lendvai>guix package --list-installed only lists what was directly installed. is there a way to see the "entire list"? <civodul>attila_lendvai: you mean including packages that were propagated? <civodul>attila_lendvai: so no, there's no way to get that from the command line <civodul>i'm not sure i understood correctly though <attila_lendvai>civodul, i'm trying to track down this error: pkg_resources.DistributionNotFound: The 'trezor[hidapi]<0.13,>=0.12.0' distribution was not found and is required by trezor-agent <akib`>civodul: no, not childhurd. i'm using the qemu image <attila_lendvai>civodul, some dependency must be missing, but i don't understand that "trezor[hidapi]" thing <civodul>attila_lendvai: when/how do you get this error? <attila_lendvai>civodul, when i run trezor-gpg init "user name <use@domain>". note that i'm working on updating the relevant packages. <civodul>that's a setup.py/setuptools kind of issue i suppose <attila_lendvai>civodul, it should be provided by the package python-trezor, and it's recorded as a dependency. hence my interest to see whether it's installed... and apparently it's not?! not present in: ll ~/.guix-profile/lib/python3.8/site-packages/ | grep trezor <zimoun>civodul: about SWH and 44187, I missed the new stuff on the SWH side. :-) What is new? <zimoun>efraim: thanks for <http://issues.guix.gnu.org/issue/50501>. I was fighting with manifest.scm for the website; puzzled about why all git outputs (send-email, svn and others) are fetched when only “git” was expected. You save me some time. :-) <civodul>zimoun: the vault can now cook "git-bare" archives <civodul>IOW, you can fetch complete repos, which was not quite possible before (there was git-fastexport, but it was discouraged) <akib>can someone help me with using guix gnu/hurd qemu image? herd doesn't work after reboot <efraim>zimoun: :) Hopefully we can make it work as expected now <robin>attila_lendvai, are your trezor problems with the regular guix package(s), or are you packaging something new? <attila_lendvai>civodul, FYI, it's most probably a bug in wrap-script. if i look at the wrapped file, i don't see references to the dependant python packages... while with wrap-program, it's there. <attila_lendvai>robin, i'm updating the trezor packages, but i think this is broken with what's in guix proper (e.g. trezor-gpg init) <attila_lendvai>i'll need to leave soon. i'll keep hacking at it at the following days <robin>maybe i'll take a look tomorrow fwiw; i have a trezor but never got around to guix integration <robin>though with my rate of virtio progress, "tomorrow" probably means "monday" ;) <jpoiret>just added sway to my globally installed packages, anything i have to do to make it appear in gdm sessions? <jonsger>doesn't look that bad on core-updates-frozen. Almost through... <muradm>rsync --rsh='ssh -p 2222' .... fails with: bash: rsync: command not found <muradm>rsync --rsh="$(readlink $(which ssh)) -p 2222" ... fails in the same way <muradm>problem with rsync how it calls command <muradm>any other way to specify custom ssh port? <jonsger>classpath-0.99-1.e7c13ee0c 10.0MiB 7.95GiB/s ^^ if my provider would know this :) <muradm>answer yes: in ~/.ssh/config: Host <address> \n Port 2222 provides default port <muradm>but rsync ... a.b.c.d:/some ./some still fails <muradm>oh man... remote should have rsync installed.. (face palm).. <hjklambda>Is there a way to make a package have an environment variable refering to its location in the store? <maximed>hjklambda: possibly relevant: wrap-script/wrap-program, search-paths, native-search-paths, possibly 'substitute*' to avoid an environment variable <maximed>It depends on what you are trying to do exactly <jpoiret>i've tried setting up geiser-guile to hack on the guix source tree, but trying to look up the definition of eg `modify-phases` hangs for a while and fails to find it, does anyone have any tips regarding that? (i'm using the melpa versions and the guix source is in `geiser-guile-load-path`) <blackbeard>yesterday building guix from source I got 3 errors <notnckx>blackbeard: Yes please! Be sure to attach the relevant .log files. <notnckx>Bug #s are cheap; reports are valuable. <civodul>jpoiret: hi! 'modify-phases' is a one of these cases where Geiser cannot guess <notnckx>This Libera-hosted Gamja gizmo is pretty spiff. <civodul>jpoiret: the reason is that Guix code is often "multi-staged": it contains code that's quoted (possibly as gexps), staged for later execution; Geiser doesn't know about that, and it doesn't know what modules this staged code imports <jpoiret>that's true, I guess geiser won't be that useful for most packaging then <civodul>jpoiret: there's still a lot of code in there that's not staged :-) <civodul>so for example, you can still benefit from Geiser to jump to package definitions, etc. <jpoiret>also, what's the best course of action to run pre-inst-env to reconfigure the system as root? <jpoiret>i keep getting `./pre-inst-env: line 55: exec: guix: cannot execute: Is a directory` when running pre-inst-env as root <yoctocell>civodul: Hi! Thanks for reviewing the generic-git updater! <yoctocell>I am still working on the tests, and discovered some issues with the updater regexps. I guess that's why we have tests. ;-) <civodul>jpoiret: did you configure & build your working tree? <civodul>i personally don't reconfigure from a local build; i prefer to use "guix pull" and "guix system reconfigure" as a normal user <jpoiret>the info page doesn't seem to instruct you to actually build the tree, only have the dependencies <jpoiret>civodul: but how would you test changes to the system before committing then? <civodul>jpoiret: changes to system services, for instance? i'd test in a VM with "./pre-inst-env guix system vm" <civodul>there are a few things that really need to be tested on the bare metal, like code that deals with kernel modules or file systems, but otherwise a VM is just fine <jpoiret>i'm testing using gdm to launch sway, since for now the session file for sway isn't patched with the hardcoded path <jpoiret>maybe a vm would work but i feel like setting up vms would be a hassle compared to just building the system with that one change (and it's just a simple session file so it should be fine) <jpoiret>i'll try setting them up later though, i'm not one to tinker with things that needs bare metal ***jonsger1 is now known as jonsger
<Xanderificnl_>Hi. I'm trying to figure out how I'm supposed to figure out the base32 of a sha256sum of a tarball. From what I read, it should be as simple as: "guix download http://url/to/tarball" -- however, after using the resulting base32 string, Guix will eventually tell me it's wrong. Is there a step, or something I'm missing? I also tried confirming a <Xanderificnl_>base32 string by comparing the output of the download command with a value already in gnu/packages/wm.scm. <Xanderificnl_>(it didn't match.) I'm guessing I must have overlooked something. <singpolyma>Xanderificnl_: I just put a wrong one and get the right one from the error message ;) <Xanderificnl_>I'm thinking that's really wasteful to do it by trial and error <Xanderificnl_>Yes, it's all about the tarbal. Let me check that out. I'm unsure what I did wrong with guix download then, I'll check the hash command. Thanks <jackhill>Ideally, you'd have some way to verify the authenticity of the artifact (but I know this can be difficult. Hopefully at least having multiple people who have different adversaries get the same hash works for the most part), and then run `guix hash` an a known authentic tarball <Xanderificnl_>There's a signature file with the tarball so that's better than nothing I suspect <jackhill>Often with signature files, I have no reason to trust the signing cert, but at least if I'm working on the same package over a number of releases and they use the same cert, I can keep using my same local cert copy to verify <Xanderificnl_>So i figured, guix download was the shortcut, to 1) download the file and 2) do the hashing. <Xanderificnl_>Fair enough; this is really just hour 12 for me on Guix, so I'm still learning the ropes. So the first real step is to get Sway updated to the last version, and if that works out, I'm going to be really happy. Then, I'll look more into verifying and the likes. <Xanderificnl_>(that is to say: I'm actually trying Guix out to see if it can be my daily driver!) <jackhill>your milage may vary I suppose. Recently I've mosting been working with packages that use git-download, and I already have the repo cloned in order to find the right tag/commit to use. <jackhill>Xanderificnl_: awesome, hope you enjoy it! <Xanderificnl_>So far, it's been a charm. My current 'actual' daily driver is Nix and I've ended up fighting with it, and its DSL more than I'd like. So far, I've felt more productive in these 12 hours than I did in double that time. <Xanderificnl_>It's pretty cool. Yeah, this package actually comes from Git, but I'm just updating the version values and base32 strings for now that are already provided in the default packages. <Errol-6946>I'm trying to configure dovecot. Anyone know the syntax of the "dict" parameter? I couldn't figure it out myself and can't find examples. <Errol-6946>I want something like (dict (dict-configuration (entries '(("quota" "psql:/etc/..."))))), but this doesn't work. <notnckx>Xanderificnl_: Maybe you were hashing the git repository Web UI's HTML? guix download is merely a shortcut for curl/wget + guix hash, and the result should be identical, but it's not clever enough to call git clone instead. Yet? <Xanderificnl_>Just ran `file ~/Downloads/wlroots*` and all .tar.gz's can back as gzip compressed data <notnckx>I seem to be confused by your use of -rx (intended for non-tarballs like VCS directories) and the world tarballs in the same context. <Xanderificnl_>I did a couple of things, i.e. first `guix download [url to tarball]` then `guix hash /path/to/tarball` and eventually cloned the repository and checkout the proper branch and ran `guix hash -rv` <Xanderificnl_>the first 2 commands resulted in: 1nv9i12jsr23wi0c3nf43jwbmb3v8ywh5sd4r1bh6a5cg7aq72j4 and the last in: 1sshp3lvlkl1i670kxhwsb4xzxl8raz6769kqvgmxzcb63ns9ay1 (this one being right.) <Xanderificnl_>So I'm actually guessing it was me making a wrong presumption. For the record, I'm referring to: wlroots version: 0.14.1 ***jonsger1 is now known as jonsger
<muradm>a bit offtopic, i did "certtool --generate-privkey --outfile some.pem ..." how do i do public key out of it? in openssl it was "-pubout der" <Xanderificnl_>the assumption being that `method git-fetch` would result in the same checksum as the tarball which is of course silly because the tarball is an archive. Extracing the tarball however yields the proper checksum. So that was my flaw in thinking. <Xanderificnl_>Looking at `man certtool` it mentions `pubkey-info` and options which you can combine to extract the public key. Is that what you're looking for? <muradm>i don't think so, it provides info on key as far as i understand <muradm>ok may be it is, now some public key info in output, near private key <Xanderificnl_>It does mention explicitely that it can extract the public key, i.e. the full text: "The option combined with --load-request, --load-pubkey, --load-privkey and --load-certificate will extract the public key of the object in question." <roptat>blackbeard, which version is this? a checkout of the master branch? <muradm>ah ok, now i got it.. --generate-privkey, then --load-privkey --pubkey-info --outder <nckx>Xanderificnl_: I think I understand now, thanks. <Xanderificnl_>nckx, yeah, I wasn't seeing what was right in front of me ha. :) | muradm, no worries. The man page has many examples I might add, in case it helps, try: man certtool - and you can use `/` to search for keywords. It's useful! <Xanderificnl_>Ah, haven't used `info` that much yet. Emacs: I've only just installed it (for the second time or so), and it's still a bit alien to me, but it seems to fit into this ecosystem by default so, I'm trying to assimilate ha ;) <Xanderificnl_>(or be assimilated, I'm not sure. English isn't my primary language) <maximed>Xanderificnl_: fwiw, the texinfo manual is available as HTML as well ***ChanServ sets mode: +o litharge
***notnckx was kicked by litharge (time to log out (by nckx))
***litharge sets mode: -o litharge
<roptat>ah, maybe you're using guile 2.2? <blackbeard>commit 63cc4dd5793b62802354a31d8e6913f065d3bcec (HEAD -> master, origin/master, origin/HEAD) <roptat>mh, what I see from the log is that a guile function doesn't exist, even though it's present in guix since 3.0 <blackbeard>what's the name of the function? do you want me to do something in the repl? <roptat>yeah, but I'm not sure it's the only reason it failed for you <roptat>(on my machine, with a newer guile, all tests pass on master) <roptat>great! not sure what we should do though, do we want to support older guile versions? <jonsger>wonder if I just can disable building docs for babl as it would require OpenSSH for scp <jonsger>I did as the docs weren't built before either... <jpoiret>has anyone successfully added sway (or any wayland compositor) to the possible gdm sessions? I modified the wayland-sessions desktop file to have Exec=/actual/store/path/sway but it still doesn't get picked up by gdm <blackbeard>roptat: sorry, I meant the newer guile, I am running the checks right now <jonsger>jpoiret: why not using sddm-service-type? <Xanderificnl_>GDM should be able to start Wayland sessions, I think fedora uses Gnome w/ Wayland by default. I'm actually updating Sway to the latest version and I did have some links in my notes, let me see if any will help. <dstolfa>AFAIK guix gdm currently lacks support for wayland <dstolfa>it's not that it can't do it, it's just that nobody's done the work i'd assume <blackbeard>roptat: ok this time I only got 2 fails, so a guix pull solved 1 <Xanderificnl_>Looking through git masters' gnome.scm, it does seem GDM is instructed to look for /run/current-system/profile/share/wayland - I wonder what's missing to make wayland work. <jpoiret>alright, i'll switch to some other display manager then instead <jpoiret>Xanderificnl_: iirc it should be wayland-sessions instead <aluaces>hi, I have the suspicion that emacs-next does not implement native compiling, is that right? <Xanderificnl_>grep "wayland" ~/src/guix/gnu/packages/gnome.scm # yields: "\"/run/current-system/profile/share/wayland") <dstolfa>Xanderificnl_: would be cool if you could get it to work, gdm is pretty nice for some things <jpoiret>Xanderificnl_i'll try simply replacing wayland by wayland-sessions <roptat>blackbeard, ok, which are the ones remaining? <Xanderificnl_>So, if I'm reading this right (I might not, I'm just starting with Guix/guile/scheme) there's a provision in GDM's definition to "substitute" wayland-session.c with x-session.c, does that sound like it's disabling wayland? <Xanderificnl_>i.e.: `(substitute* '("daemon/gdm-wayland-session.c" "daemon/gdm-x-session.c")` <jonsger>does Guix always have LC_ALL="en_US.utf8" in the build environment variables? <steggy[m]>Yep, substitute* is used for string replacement, usually on build <steggy[m]>If you want to see if you are on wayland or whatnot, I'd recommend consulting `$XDG_SESSION_TYPE` <Xanderificnl_>The real thing we're trying to figure out is how to get wayland sessions to show up in GDM. <steggy[m]>`The desktop environments in Guix use the Xorg display server by default. If you’d like to use the newer display server protocol called Wayland, you need to use the sddm-service instead of GDM as the graphical login manager. You should then select the “GNOME (Wayland)” session in SDDM. Alternatively you can also try starting GNOME on Wayland manually from a TTY with the command “XDG_SESSION_TYPE=wayland exec dbus-run-session <Xanderificnl_>I read that too, but I'm not sure why that is. It seems strange, i.e. if GDM supports Wayland then why would you need SDDM? <steggy[m]>So sounds like you'd want to add sddm-service and then doing something like ```(remove (lambda (service) <steggy[m]> (eq? (service-kind service) gdm-service-type) <steggy[m]>No idea to be honest, but I'm not very informed on desktop manager stuff - I just use exwm with slim <Xanderificnl_>Something (actually: just a thought) makes me wonder whether Gnome's actually just not aware of how to use Wayland on Guix. <Xanderificnl_>i.e. on my system the executable 'gdm-wayland-session' (shellscript & actual executable) just exist. <steggy[m]>It sounds that way based on being able to exec that gnome-session <Xanderificnl_>Yeah. It requires a bit more puzzling. I'm going to put it on the backburner for now and continue with updating Sway, afterwards, I'll take a deeper stab at it. <steggy[m]>What happens if you try to exec the way they describe? <Xanderificnl_>I'll come back to that in a bit if you don't mind. I really just want to finish this first ha, it already distracted me from what I was doing haha ;) <steggy[m]>Yeah no worries, you don't owe me anything :). I'm off and on but if you want me in particular can always nameping, though many of the devs hang out here and can likely give you better advice <Xanderificnl_>I do appreciate your help though! It's just that I got sidetracked, and need to get back to the main thing :) <roptat>blackbeard, ok, that's weird, both pass here... can you send the reports for these two tests to the bug you opened earlier? <steggy[m]>Yeah totally get that/can commiserate on going down rabbit holes and going "wait, no, I need to actually do this other thing" <jpoiret>Xanderificnl_found the culprit, the default gdm service in (gnu services xorg) has "EnableWayland=false" in its configuration file <Xanderificnl_>Your kidding. Is there any reason (i.e. in git log) for that? What happens when you enable it? <jpoiret>Xanderificnl_ i'm investigating it currently, my guess is that the service will have to change as well <steggy[m]>It looks purposeful: ```;; Enable me once X is working. <Xanderificnl_> git show 6e99c01b4d3ae6dfa467d83604484707f07f8e86 # 4 years ago <steggy[m]>So, possibly totally a thing you could just turn on <Xanderificnl_>So, _probably_ it's just technical debt and someone forgot to enable Wayland after they got GDM w/ X working on Guix. <Xanderificnl_>* gnu/services/xorg.scm (%gdm-accounts, <gdm-configuration>) <Xanderificnl_>(gdm-etc-service, gdm-pam-service, gdm-shepherd-service, gdm-service-programs) <Xanderificnl_>(gdm-service-type, gdm-service): New public variables. Not yet working. <dstolfa>Xanderificnl_: interesting -- it would be awesome if it just worked but it needed someone like you to figure that out :) <Xanderificnl_>Thank god for Git keeping track of things. jpoiret was actually the one who figured it out, I just looked up the git history <Xanderificnl_>Still waiting to hear back if it actually fixes it though. Let's hope for the best =) <jpoiret>just enabling it doesn't, it's still starting gdm with x <jpoiret>i'll look at how other distros package its service <Xanderificnl_>I'm sure at least the debug log will tell us where GDM is _actually_ looking for the desktop files. I'm guessing that's the "real" question at this point. Or, if you're feeling particularly adventerous use strace (but I'm guessing debug is waaay more readable.) <jpoiret>enabling debug doesn't help much, no mention of `wayland` in the whole log <jpoiret>what's weird is that XDG_SESSION_TYPE is explicitely set, but i cannot for the life of me find out where, grep doesn't find anything except in the docs <jackhill>Xanderificnl_, jpoiret: when last I looked into this, I learned the following: GDM will only offer wayland sessions if it is running in wayland mode. I couldn't get GDM to start in wayland mode. I could see in the logs that it was trying to launch a wayland gnome-shell, but that failed for some indeterminent reason, so it would fall back to x11. <jackhill>if I instead used sddm, which I think currently only support x11 mode, I could launch a wayland gnome session that mostly worked (in Guix at least screen locking doesn't work without GDM though) <jackhill>Apologies for not keepign detailed notes or having logs available. I had hoped to revisit it after the (long-awaited) gnome upgrade lands <jackhill>(the hope being it magically starts working 😀) <jpoiret>jackhill: do you remember in which log you could see that? cause it seems x starts right away for me <lilyp>Xanderificnl_: I think I saw a similar snippet (replacing wayland with X) in raghavgururajan's GTK4 patches. Chances are someone was overly eager trying to adjust tests and ended up adjusting features instead :P <jonsger>can someone search for a file named "fikparm.mf" on CI or another big /gnu/store. I'm trying to fix lilypond on core-updates-frozen... <lilyp>Or perhaps just adjusting defaults <iskarian>sneek, later tell maximed: If you're looking for things to optimize, maybe look at 'generate-checksums' in cargo-utils, that seems to take a *while* <podiki[m]>has anyone used pam-limits-service and set nice? I tried with -19 but seems like that resulted in max nice of 39... *raghavgururajan peeps in <podiki[m]>should it be "-19" or some way to ensure the sign? <jackhill>jpoiret: unfortunately not, sorry. I should have kept better notes. I do remember it being a fairly verbosel ong <jonsger>okay, found it. It's in the sources texlive-lh, but doesn't get installed/copied over anymore <Xanderificnl_>Good to know, thanks for the notes! If anyone finds anything else, please do drop it in the channel; it'll help ! <Xanderificnl_>holy o.O wlroots finally built after resolving a ton of dependencies \o/ <lilyp>Xanderificnl_: so I had a look at GDM's recipe and there doesn't seem to be anything to *replace* working functionality <lilyp>However, it does seem that there's no real care taken to patch in wayland paths or even have wayland as an input <Xanderificnl_>gnu/packages/patches/gdm-default-session.patch can you check that file? <Xanderificnl_>probably just all the random directories in which the wayland sessions can exist? <lilyp>Hmm, you're right, it should add wayland-sessions after xsessions <lilyp>the value of wayland_search_dir needs patching <lilyp>instead of DATADIR it probably ought to refer to /run/current-system/profile/share/ <Xanderificnl_>What is really confusing, at least to me, is that one the one hand we're patching and the other hand we're substituting in another file. It's really tough to see clearly see what's going on without having to run through it all. <jpoiret>seems it's both being patched and substituted <jpoiret>and at least 2 lines are both patched and substituted ***jess is now known as j
<Xanderificnl_>Isn't it easier/less error prone to set a hook somewhere that says: "if gnome isn't installed, rename the gnome session file so it won't be picked up"? <jpoiret>there's a third folder with `default` sessions iirc where gnome might be <Xanderificnl_>I wonder why it's even installed in the first place, if it shouldn't be there. GDM probably adds it by default? Seems silly, Gnome should provide it. <Xanderificnl_>Anyway can you test a sway session in /run/current-system/profile/share/xsession/ with this set: X-GDM-Session-Type=wayland <Xanderificnl_>If that _still_ works, it'd should force a wayland session. Probably? <jpoiret>by the way, patch > substitute right? <lilyp>Setting up a hook to do weird shit does not sound very functional at all. <Xanderificnl_>I'm unsure, my intuition says in Guix substitute should be preferred? <nckx>jpoiret: merely ≠ tools for ≠ jobs. <lilyp>In this instance adjusting the patch is to be preferred, since it's a simple modification to make <lilyp>So, does anyone have their quilt in hands? :P <jpoiret>does substitute* fail if it cannot actually find one substring? <jpoiret>but honestly even having EnableWayland=true still starts X11 gdm so i actually have no idea <Xanderificnl_>Not really. On another note, I'm getting "patch-shebang ... no binary ... 'python' in $PATH" while rebuilding Sway. Any idea? I thought I might be missing Python, but at least in my quix-env it's installed. *dstolfa is loving this wayland debugging and hopes it results in gdm + wayland! <nckx>It's seddish in that regard. <Xanderificnl_>jpoiret I did actually read somewhere, not sure if applicable to Guix, that GDM will write a temporary custom.conf and it'll have to be removed manually and until then GDM won't use the default/builtin. Not sure if applicable to Guix, or even still current! <Xanderificnl_>Might be worthwhile to `find` and check if that's happening. (i.e. I meant: GDM will have disabled wayland until the custom file is removed/expired. Generally it was kept in /run iirc.) 