***lh_ is now known as lh
***_ctb_ is now known as _ctb
***richardhuxton_ is now known as richardhuxton
***reyman_ is now known as reyman
***johnhamelink_ is now known as johnhamelink
***alethkit_ is now known as alethkit
***the-porcupirate is now known as porcupirate
***kodmin_ is now known as kodmin
***monadgauge_ is now known as monadgauge
***rheaplex_ is now known as rheaplex
***Fd9a_ is now known as Fd9a
***colbyhub_ is now known as colbyhub
***\f_ is now known as \f
***sleepydog_ is now known as sleepydog
***fluffyballoon_ is now known as fluffyballoon
***dominicm_ is now known as dominicm
***fnurkla_ is now known as fnurkla
***tom42_ is now known as tom42
***chipb_ is now known as chipb
***raghavgururajan_ is now known as raghavgururajan
***f1reflyylmao is now known as f1refly
***kir0ul0 is now known as kir0ul
***theothornhill_ is now known as theothornhill
***englishm_ is now known as englishm
***unmatched-paren_ is now known as unmatched-paren
***jfred_ is now known as jfred
***timmy_ is now known as timmy
***voroskoi_ is now known as voroskoi
<rekado>apteryx: i just checked with my colleague; Rocky-8.5-XFCE-GuixFarm should be bootable for our IP range. <rekado>apteryx: glad you figured out how to work around the texlive problems! <jgart>see how janet links to community docs with examples of the library functions being used in a coding context <jgart>not sure at the moment how to propose something similar to revamp the guile docs to do that but I'd like to <jgart>for example, (mkdir "foo-dir") <jgart>A new user won't know the type for [mode] <jgart>They'll have to play with mkdir in trial and error <jgart>or search for extant code that uses mkdir with the [mode] optional argument to see how to call it <jgart>also, I couldn't link you directly to mkdir but only to the beginning of that manual page <jgart>it would be nice if the API had links to particular functions so that we can link docs easily <jgart>Should we modernize texinfo to handle this or explore some other approach for guile docs? <lilyp>jgart: that's why you don't only look at the function signature, but its description though? <mitchell>I am trying to understand the pinebook-pro os template. Specifically the part where the bootloader targets "/dev/vda". What is this device? It doesn't seem to exist on my pbp but the image build with `guix system image -t pinebook-pro-raw --target=aarch64-linux-gnu` boots correctly. How is this possible? <jgart>lilyp: What if I look at both and I'm still confused as a beginner to guile? <jgart>I'd like to make guile's docs more accessible to everyone overall <apteryx>rekado_: ah, there was a submenu! it's booting :-) <vagrantc>sneek: later tell mitchell the /dev/vda in the pinebook-pro image is because it is built in a virtual machine ... on an actual installed system you would use the appropriate device for your computer <apteryx>rekado_: and then I'm left trying to login or access single mode which doesn't exist on Rocky Linux... <jgart>misc-error #f "no setup.py found" () #f <mitchell`>If I build packages with --system=X --target=X will they end up with the same derivations as if build naitively on X? I ask because I would like to avoid building as much software on my pinebook as possible <sneek>Welcome back mitchell`, you have 1 message! <sneek>mitchell`, vagrantc says: the /dev/vda in the pinebook-pro image is because it is built in a virtual machine ... on an actual installed system you would use the appropriate device for your computer <mitchell`>and i would like it to hit substitutes available on my build machine <mitchell`>vagrantc: so if i wanted to do a `guix deploy` i would use the appropriate /dev/mmcblkX in the operating system declaration? <vagrantc>mitchell`: sometimes the X in /dev/mmcblkX is prone to change ... i'd reccomend using a stable /dev/disk/by-*/ symlink by-id, by-partuuid, by-path, etc. ***cwebber` is now known as cwebber
<apteryx>rekado_: Rocky Linux has a 'liveuser' which is passwordless. Can sudo as well :-) <apteryx>hmm, in a chroot as explained in info '(guix) Chrooting into an existing system', the daemon doesn't seem to be able to accomplish much; 'guix pull' seems to hang for example. Ideas? <apteryx>it just says "accepted connection from pid 4202, user root" <apteryx>perhaps it's just somehow not directing the usual standard output to the terminal; the guix process seems busy doing stuff <apteryx>oh nevermind, it works. just took a while to show something ***vlorentz1 is now known as vlorentz
<unmatched-paren>lechner: thanks! not sure they'll get back, though. it seems abandoned. <unmatched-paren>lechner: btw, it wasn't the most recent commit, it was the most recently tagged version ;) ***risu is now known as piannetta
***mark is now known as mjw
<jpoiret>i'm replying to your email with more info <jpoiret>for some reason adb and fastboot are both shown as having substitutes, but they're never substituted <cbaines>jpoiret, you can directly test if you can substitute something if you try to build the output, so guix build /gnu/store/... <cbaines>note that guix weather will show substitutes as available, even if you haven't authorised the relevant signing key <davidl>how can I use the new style for package inputs when referring to a package's "bin" output? <davidl>I did like this: (inputs (list `(,pcre "bin) ..)) but when referring to it in the build phase I get the /gnu/store path for pcre's "out" output instead of the "bin". I used (string-append "export BCUPCREGREP=" #$(this-package-input "pcre") "/bin/" library) to refer to it and also tried some other variants that failed. <ulfvonbe`>davidl: sounds like what you want is #$OBJ:OUTPUT, or (ungexp OBJ OUTPUT) <davidl>ulfvonbe`: yeah something like that, but I am not finding what I need or an example thereof. <davidl> #$(this-package-input "pcre") - does that refer to the pcre "out" output even when its written like this in inputs: (inputs (list `(,pcre "bin") <ulfvonbe`>hm, seems you've run into an implementation incompleteness. 'lookup-input' (which all the 'this-package-*' forms use) hasn't been updated to use package names instead of input labels. In short, the switch from specifying inputs as (label package <optional-output-label>) to (package <optional-output-label>) has left this-package-input nonfunctional with the new style. <ulfvonbe`>or perhaps I'm missing an implementation detail and the new form is somehow translated to the old internally <ulfvonbe`>at any rate, this-package-input ignores the output label; it only returns the package object. <davidl>for now Im using the old style and putting that specific package in native-inputs field. <ulfvonbe`>do note that even if using the old style, 'this-package-input' will still ignore output labels. The old-style way of getting at that particular output would be to use a label like "pcre-bin", then in whichever phase you need it, you include (#:key inputs #:allow-other-keys) in the lambda list, and refer to it with (assoc-ref inputs "pcre-bin") <ulfvonbe`>if it happens outside of a phase - for example, it's evaluated to produce #:configure-flags - then you'd use the hacky %build-inputs variable <PurpleSym>civodul`: Aw, I was going to comment on the rocm patchset and propose a small change. <cbaines>civodul, hey, I see problems with that page too <cbaines>I probably broke that when introducing table partitioning, which is pretty cool, and helped with a different problem, but I may have removed some indexes which are needed <mekeor[m]>hello guix! how can i specify the option "fancontrol=1" for the kernel module "thinkpad_acpi" in my system declaration? *mekeor[m] cleaned the laptop fan today <mekeor[m]>ah, oh, do i maybe have to use the kernel-module-loader-service-type? <mekeor[m]>btw, i didn't follow recent developments tightly. do i guess correctly that data.guix.gnu.org holds something like the list of packages or so? <apteryx>civodul: you should have access to node 129 as 'civodul' if you are interested to have a 2nd Berlin-like machine (141.80.167.186) to experiment with <mekeor[m]>wait, i think, it's possible to specify module-options in /etc/modprobe.d/foo.conf, as described in an example in the manual for kernel-module-loader-service-type <unmatched-paren>mekeor[m]: iiuc, data.guix is a service for statistics and analysis of the package set and ci (e.g. reproducibility stats) <kefir> is there way to connect to guix machine using vnc or rdp? <unmatched-paren>could we close this? seems like a patch addressing it has been since applied ***califax_ is now known as califax
<jgart>not sure what happened there <jgart>that was supposed to be a patch for updating janet <jgart>or does someone happen to remember the debian control code for changing the title <jgart>and haven't been able to dig around to find the page listing the control codes again <jgart>not sure why that happened though in 56006 <jgart>I have an automated script to send the patch so I didn't make that typo I'm pretty sure <jgart>and Maxime replied to that ticket <unmatched-paren>look at the title of their message: Re: bug#56005: "write_wait_fd: unimplemented" during downloading substitutes <unmatched-paren>retitle 56006 "write_wait_fd: unimplemented" during downloading substitutes <jgart>I guess mumi is not immune to it either <unmatched-paren>mumi shows control messages operating on a ticket T, even if they weren't sent to T <unmatched-paren>jgart: just `retitle 56006 "[PATCH] gnu: janet: Update to 1.22.0."` to control@debbugs.gnu.org :) <jgart>can't remember when I document things <unmatched-paren>jgart: would you be able to review one of the patches i linked to, btw? :) <jgart>sure, I'll take a look at it tonight <jgart>I don't have commit access so I won't be able to merge but I'll take a look and help out with what I can if I spot anything <catern>dear lazyirc: does guix support loading/installing/upgrading new emacs packages while emacs is still running? without restarting emacs, I mean? <catern>(i currently use nix and it does not which is annoying) <unmatched-paren>catern: i don't use emacs, but i'd think it was likely. guix, as you might expect, has good emacs support :) <lilyp>catern: you have to reload subdirs.el, then it works (maybe) <lilyp>the maybe part is the important thing here, because emacs can break things between version upgrades <ulfvonbe`>it depends. I know the way emacs package loading was done has been changed around in the past. <lilyp>(though plain rebuilding ought to be fine) <catern>lilyp: the subdirs.el you're referring to is one in ~/.guix-profile I assume? <catern>(and I guess you need to do some emacs thing if you want to reload a package) <ulfvonbe`>in general, if your EMACSLOADPATH is set to point into ~/.guix-profile, and you have at least one package installed already, you can probably install a package and it just werks. If your EMACSLOADPATH is set to point into /gnu/store/...-profile, you'll need to relogin, execute from a fresh login shell, or just source the proper etc/profile. <catern>ulfvonbe`: that contradicts lilyp a bit though, do I need to reload subdirs.el or not? <catern>i'm tempted to use guix just for emacs <lilyp>%load-path expands store directories <catern>and cleverly use the same nix-daemon and store for both guix and nix... although maybe guix has changed the nix daemon protocol in incompatible ways since forking <ulfvonbe`>it's worth noting that at least some time back, if you upgraded your emacs while it was running, it could get pretty messed up because the directory containing its elisp sources was stored in a versioned path, and it didn't resolve symlinks before setting load-path, so after upgrading ~/.guix-profile that directory no longer existed. <ulfvonbe`>I think there was a bug report about that, don't recall what the outcome was <ulfvonbe`>guix gc: error: executing SQLite statement: FOREIGN KEY constraint failed <ulfvonbe`>is there a way to set --debug for 'guix gc'? <whereiseveryone_>unmatched-paren would be cool to extract the geiser guile specific code and create a language server from it <unmatched-paren>it would require translating the elisp code to scheme or something, wouldn't it? <unmatched-paren>shouldn't be too hard to write a lsp library for guile. (let's move to #whereiseveryone :)) <unmatched-paren>jpoiret: hmm. there's our project idea out the window :P nice that rekado is working on one though. <jpoiret>my reaction would've been: "oh thank god someone else is doing that instead of us" ***arjan_ is now known as arjan
<fosskers>Hi there, I just installed Guix (the tool) on my non-Guix OS <fosskers>I just ran `guix pull` too, which seemed to work just fine <fosskers>Although it's telling me to set my GUIX_PROFILE, assuming I'm a bash user, which I'm not. <fosskers>I use fish. Is there a way to properly set my env vars? <unmatched-paren>the Guix Home system sets that all up for you if you use its home-fish-service-type <unmatched-paren>you can do `guix home import ~/path/to/where/you/want/the/guix/home/config` <fosskers>Do you have a recommended path for that? <unmatched-paren>> Note: It is highly recommended that you manage your shell or shells with Guix Home, because it will make sure that all the necessary scripts are sourced by the shell configuration file. Otherwise you will need to do it manually. (see Configuring the Shell). <fosskers>So I can ignore what `guix pull` told me, for now? <civodul>apteryx: hi! looks like tests/services/telephony.scm would need to be updated