<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
<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.
<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.
<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?
<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
<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).