IRC channel logs
2024-02-07.log
back to list of logs
<amano>Hello... how exactly does guix file layout differ from most linux distributions? <Goober_patrol66>it's a merkle tree, each package is installed in a directory prefixed with a hash of its contents + dependencies <vagrantc>amano: there's no /lib, /usr/lib, /bin, /usr/bin, etc. <vagrantc>amano: everything needs to explicitly declare it's dependencies <amano>Only libraries and executables deviate from other linux distributions? <vagrantc>maybe the only thing that is the same is basically /etc, /tmp, /var ... <amano>firejail and apparmor assume `man hier` and file hierarchy standard. <amano>I don't know how I can use firejail and apparmor on gnu guix. <vagrantc>you would have to make one for every user and system profile <vagrantc>and it would have to be changed with any updates to any of it ... <vagrantc>and probably have to resolve everything down to the paths in /gnu/store/* <amano>Unless I can whitelist /gnu/store/*/bin/grep, I can't whitelist grep. <vagrantc>and you wouldn't want to whitelist */bin/grep, because any user can build something that would match that path <vagrantc>it is possible, it is just certainly a lot of work. <amano>I want to create a firejail profile that doesn't require modifications whenever I change profile or user... <vagrantc>and probably prone to mistakes ... which might defeat the purpose <stikonas>indeed /gnu/store/../../home/user/malicious/bin/grep matches /gnu/store/*/bin/grep <amano>Does guix change the content of PATH? <amano>Then, firejail can centralize its operation on environmental variables like PATH and LIBXXX.... <stikonas>but PATH can be set up by any user too... <amano>firejail will inherit environment variables.... <vagrantc>but people can put whatever they want into path ... so you don't get meaningful firejailing <vagrantc>and LIBXXX is going to have to be /gnu/store/dsfglkjsdgfjkhs-libXXX-1.2.3.4/lib/libXXX ... <vagrantc>next update might need /gnu/store/fghlkfdhgdfsdfh-libXXX-1.2.3.4/lib/libXXX ... <vagrantc>basically, the only way to make this work is to not allow any user profiles, and only enable for the system profile, and autogenerate the appropriate rules <vagrantc>(or to only allow users to install specific categories of things that are not in the system profile) <amano>auto profile generation is not possible. <amano>It has to be written by hand... <amano>Can guix security container replace firejail and apparmor? <vagrantc>you write the rules you want, and then restrict them to the exact paths in /gnu/store ... and you do so programatically <vagrantc>e.g. if you install a web browser and you want to give that some sort of permissions, you generate the appropriate apparmor rules that match /gnu/store/xyz-somewebbrowser/bin/webrowser (and all it's library dependencies) <vagrantc>that's no different from a FHS system ... only that there are many more paths to consider. <vagrantc>like i say, not impossible, just way more difficult than people using those technologies are used to <vagrantc>amano: guix containers are not really intended for security <amano>Perhaps, /gnu/store/*/bin/webbrowser can be whitelisted by apparmor and firejail. * can specifically mean one directory. <vagrantc>but you have to only allow that specific instance of bin/webbrowser ... <amano>one directory which is not . or .. <vagrantc>if you allow older versions, you would allow the vulnerabilities of the old versions <vagrantc>yeah, if you don't care, then sure, you could also just allow * :) <amano>As I said, I don't care about that... you have been running without firejail anyway... <stikonas>most likely they don't even support globs <stikonas>cause if they did, anything with full glob would break security <amano>They can be made to support globs... <amano>You guys have been running without any sandbox.... <amano>Having something is far better than nothing.... <amano>Whitelisting /gnu/store/*/path/to/binary won't hurt.. <vagrantc>it might be a false sense of security, as any use can install whatever they want into bin/webbrowser <amano>But, you can control which one to execute.... <amano>You control which gnu store directory is used... <amano>firejail doesn't care which one you use. <vagrantc>then the majority of the benefits of guix are lost <amano>And, in many cases, firejail doesn't restrict executables and libraries. <amano>I think firejail can be made to support guix... <amano>The moment a firejail profile has to care which gnu directory is used, firejail cannot be used.... <vagrantc>i am slightly more familiar with apparmor, though not terribly familiar with either <amano>So, we only need to care about (/usr)/(s)bin and (/usr)/lib(64)? <vagrantc>there is no /lib, /usr/lib, /usr/bin, /bin, /sbin or /usr/sbin <amano>Okay, firejail can work with that.... I think <vagrantc>well, technically, i think there is /bin/sh <vagrantc>if you can usefully globally apply rules to /gnu/store/*/bin, /gnu/store/*/lib, etc. and you are not depending on a specific path ... <vagrantc>well, /bin/sh points to /gnu/store/HASH-bash-VERSION/bin/bash <amano>What does each gnu directory represent? <vagrantc>there might also be /usr/bin/env -> /gnu/store/HASH.../usr/bin/env <vagrantc>the specific instantiation of a specific package with a specific set of dependencies <vagrantc>(well, that's overly broad, but in general) <amano>So, each package has its own gnu store directory? <amano>Each version of each package? <vagrantc>each version of each package with the hash of all the dependencies of that package, recursively <vagrantc>so if anything in the dependency tree changes, so does everything downstream from it <vagrantc>hell is relying on ABIs that don't actually work ... this is more honest :) <amano>Does nix have a similar layout? <vagrantc>guix is very much inspired and informed by nix, although they have drifted a bit on some things <vagrantc>but the fundamental premise is basically the same <amano>Then, firejail can be made to support both without programmatic modifications to profiles. <vagrantc>apparently firejail is in guix as well ... <amano>That doesn't mean firejail is useable in guix or nix. <vagrantc>so firejail basically just puts each user into a sandbox ... or each application started by a user is in it's own sandbox ... or ... ? <amano>Each application in a sandbox... <amano>I have to execute `firejail firefox` to sandbox firefox in firejail. <amano>There's a lot of technical fire. <amano>Apparmor has a profile for each application, but apparmor is transparently applied to each application. <vagrantc>that sounds like where this might get tricky :) <amano>It's not tricky. apparmor profiles can just whitelist or blacklist `/gnu/store/*/path/to/bin-or-lib`. <vagrantc>curious what the benefits of a global allow list would be... <amano>The goal isn't to create airtight sandbox. Perfect security is impossible in the physical universe. <vagrantc>the question comes down to if the sanbox is too broad it is ... effectively putting every sandbox in every other sandbox ... but like i said, i am not terribly familiar with these <amano>So, both nix and guix assume that /etc, /tmp, and /var are shared by all packages? <vagrantc>no, each package has everything in /gnu/store/*-package-*/ <amano>What about /usr/include, /usr/libexec, and /usr/share? <amano>I'm confused. What you just wrote can mean both yes and no... <vagrantc>there is a global /etc for things that actually look there ... /tmp is generally available ... /var has some typically /var stuff <amano>Are /usr/include, /usr/libexec, and /usr/share shared by all packages? <amano>Are they split into each package? <alethkit>Does guix generate its own initrd, or does it use dracut? <vagrantc>if they are relevent they are in each package's directory ... but ... more importantly, there are no global search paths for binaries or libraries or such <amano>Are /usr/include, /usr/libexec, and /usr/share empty in your guix system? <mange>The only thing under /usr is /usr/bin/env, a symlink to the env binary in /gnu/store/...-coreutils.../bin/env <amano>That's going to break a lot of programs.... <mange>And even that is only for compatibility with scripts that are written to run elsewhere. Guix systems used to not have the /usr directory at all. <vagrantc>amano: there is a "guix shell --fhs program1 program2" to provide an FHS-like environment to program1 and program2 <amano>I don't like that workaround.... <vagrantc>amano: and yes, it breaks external third-party programs <amano>No third party compiled binaries... <vagrantc>guix is basically each package installed in a directory of /gnu/store/ and then user and system profiles that are symlinks to those directories, or symlinks of symlinks of symlinks ... so that you can have a meaningful PATH <mange>You can use third party compile binaries, but you need to either use a --fhs shell, or you need to patch them with patchelf/etc so they can find what they need. <mange>Both are pretty painful, though, so I try to avoid it. <amano>Can a system profile or a user profile have its own FHS structure? <vagrantc>i mean ... maybe you could do it ... but it breaks the functional package management model <amano>I guess I'm going to be on gentoo linux until firejail and apparmor support guix and nix. <vagrantc>so you loose the ability to revert to old profiles or have multiple things depending on incompatible versions of libraries, etc. <mange>Well, you can set up a system to be FHS-y. Like, you can put a symlink to the linker in the right place so that dynamic linking kind of works, but it's definitely going against the grain of how the system is built to work. <amano>Have you guys learned guile scheme? I read that guix is unuseable without guile scheme. <mange>It's fine to not use Guix/Nix if they don't suit what you need. If Gentoo works for you, then that's great. :) <mange>I knew scheme before starting to use Guix, so that was actually part of the appeal for me. <vagrantc>amano: i've been contributing to guix for years now, even given commit access, and i would not say i known guile. <vagrantc>amano: but ... not everyone here is a guy. <amano>Guys can include girls... actually.... <vagrantc>amano: aim for gender-neutral language, please. <amano>`guys` is an informal term that can refer to people regardless of gender. <vagrantc>amano: would you say "guys" referring to a group exclusively of women? <amano>I think this group is almost exclusively mjen. <amano>I can sometimes do that because it's a habit... <vagrantc>amano: anyways, try not to make a big deal of it, just try to adapt :) <amano>I sometimes use wrong gender words.... <amano>I sometimes use words that only women use in my own native language. English is my second language. <vagrantc>well, at least in the past, this channel encouraged geder neutral language so you don't have to worry about getting it right :) <mange>You're not in trouble, amano. :) We just try to watch out for unnecessarily gendered language to avoid perpetuating the (false) idea that "the only people using Guix are men". <amano>I think that's almost right.... <amano>Who's a woman or a girl here? <pkill9>is there a variable you can refer to within a build environment that says what the directory is named containing the source? <amano>I think guix is a masculine operating system? <mange>I believe there's an implicit input named "source". Do you mean in a build phase, pkill9? (assoc-ref inputs "source") or similar should do it there. <vagrantc>amano: well, for one, i do not identify as male :P <pkill9>when you use --with-source, the source directory is named 'source', which is different from when using without, atleast in the case of hedgewars <vagrantc>gotta head out anyways, see y'all later. <amano>You can definitely join women's UFC and crack their skulls... <vagrantc>amano: good luck finding your way around guix, and if it's not for you, that's finne too <pkill9>mange: no, I mean once it's unpacked <vagrantc>amano: though, uh, try to keep the topic on guix :) <amano>Is any in-house sandboxing solution on the horizon? <amano>Application security sandbox. <mange>pkill9: I don't fully understand what you mean. Can you show me code of what you have now, and what you're trying to do? <pkill9>if you look at the build phase 'install-icon' in the hedgewars package recipe, it refers to 'hedgewars-src-<version>' which is the directory that the source unpacks to in the build environment, but when using the --with-source package tranformation, guix copies the source into the 'source' directory, so that build phase fails <mange>Right. In guix/build/gnu-build-system.scm then unpack phase either (1) uses source directory in a dir like that, or (2) unpacks an archive and moves into the first subdirectory, assuming it contains the archive's contents. <mange>I don't think it's possible to really know what the name of that directory will be, without knowing the specific package/archive you're working with. I don't think there's a variable for it stored anywhere. <amano>Man, there's also user profile in ~/.guix-profile. <mange>You could add a phase after unpack that stores the directory name using setenv, then retrieve it later with getenv. That sounds a bit gross to me, though. <amano>How steep is the learning curve for guix? <amano>I may try this in a virtual machine. <amano>I think I wll just have to try it myself.... <mange>I would say "fairly". It does a lot of things differently to other distros, and some of those differences seem insane unless you're on board for functional package management. <mange>It's quite rewarding, though. I much prefer using my Guix systems over anything else, and it has enabled *practical* software freedom for me, because it's so straightforward to make my own modifications, both to Guix and to the software it builds. <amano>The cost of freedom is loss of security... for the foreseeable future. <mange>I've made patches to parts of my system that I wouldn't have attempted in Debian (which I used previously), both for fear of breaking my system and for fear of the maintenance burden. Guix is really good at mitigating both those fears. <amano>But, I wouldn't embrace it fully without application sandboxing. <bumble>hey everyone, I made a package I am using locally and am thinking of submitting to guix, but there are two potential variants of the package; 1) wayland and 2) xorg. Question: are there conventions for submitting packages that can be compiled differently to support either system? <mange>A quick look in the repo turns up things like rofi and rofi-wayland, or redshift and redshift-wayland. <bumble>mange: okay I will follow that convention <bumble>I guess it is working but it seems somehow, like a rough edge or a not-yet-solved problem where the solution is "make mutiple slightly different versions of the same package and affix some extra information in the name" <mange>I'm not aware of an implementation getting into Guix yet, though. There was a GSoC project for it last year, but I didn't follow what happened with that. <bumble>mange: interestig, thanks for sharing that with me <ulfvonbelow>we should change modify-phases so that it allows appending after a certain phase and prepending before a certain phase <ulfvonbelow>that way we can more easily do things like splice in the cargo build phases into a python package <dissoc>i thought you could do that with add-before and add-after? <ulfvonbelow>dissoc: you can add a single phase at a time with those <ulfvonbelow>it would also make it so that we could add multiple phases at once without having to repeat a bunch of (add-after 'a 'b ...) (add-after 'b 'c ...) etc. <jmes>It seems like guix shell could check whether the specified packages updates any paths whenever you use such a package. e.g. if I want a guile package I have to do `guix shell guile the-guile-pack` - couldn't guix shell (in theory) figure out that it needs to update the guile path with just `guix shell the-guile-pack`? <jmes>I don't know the internals at all so I'm asking out of complete ignorance. <lilyp>ulfvonbelow: I think the gain of that would be minimal compared to the overhead, both in parsing as a machine and as a human <lilyp>jmes: the only package that has this info is guile, tho <jmes>Well there are other examples, like if you install man/info pages as part of a package, they won't be accessible from your shell without adding texinfo or something that extends texinfo (like emacs). <ulfvonbelow>the problem there isn't that it's not recursing into all the inputs to find search paths, it's that it's not considering search paths from packages in an outer environment <ulfvonbelow>that is, it's a problem because you *do* have a guile you can use in an active environment, guix shell just doesn't know about it <jmes>Ah, makes sense. But in the case of guile-* and info pages, is it safe for guix shell to assume you want guile/texinfo? <jmes>Like maybe guile packages should depend on guile? Or is that sometimes undesirable? <ulfvonbelow>for computing the transitive search paths of a package, if I remember correctly only propagated input edges are followed, but I should check <jmes>Okay (good to learn the terminology here), so is it undesirable to have guile as a propagated input? <ulfvonbelow>yes, propagated inputs are usually hacks to work around situations where references can't be baked-in <ulfvonbelow>for example, suppose you wanted to get an environment with guile-fibers in it using a guile with a custom patch <ulfvonbelow>if guile-fibers propagated regular guile, you'd end up with that in your environment too <jmes>Okay, gotcha, good to know. Thanks for the free education :) <jmes>That clears things up for me <ulfvonbelow>the proper solution is to make it so that environments compose well <ulfvonbelow>there was some discussion about it on the mailing lists some time back, I don't remember how it ended up <jmes>And knowing I need to include guile or whatever in guix shell commands is good enough. I mean guix shell is already super-convenient. <bumble2>from inside a pure env `guix shell -D guix --pure --check` there is an error running `./pre-inst-env guix build --keep-failed test-package` ... <bumble2>guix build: error: failed to connect to `/usr/local/var/guix/daemon-socket/socket': No such file or directory <bumble2>does anyone know what I'm doing wrong? <bumble2>I tried using `sudo guix-daemon --build-users-group=guixbuild` per the documentation on "invoking guix-daemon" but the command hangs <bumble2>I needed to run this `./configure --localstatedir=/var` all is good again :) <futurile>Hmm we seem to be missing a lot of notes from Guix Days. <futurile>So far we have: Plenary notes (Efraim's overview); architecture; cli; governance; hurd; infrastructure <futurile>I think we did about 15 topics - so we're short by about 10 <chsasank5>Is there a straight forward way to package a deb using guix? That way I can reuse lot of debian based packages as deps <futurile>anyone seen gabber - I think he kept notes about guix home <efraim_>has anyone played around recently with cross compiling for arm-none-eabi? I'm running into problems with include_next and libc headers <viperML>how can I pass a specifications->manifest to a guix home config, are there any examples? <unwox>viperML: hi. what are you trying to achieve? <viperML>I can backtrack to multiple problems, for now just wanted to achieve that <viperML>1. installed guix on nixos via services.guix.enable <viperML>2. tried to do a guix repl, and it's not interactive (tab completions, colors not working) <viperML>4. instead of using commands, decided to go with guix home like so: <unwox>viperML: do you want to install a set of packages to your home profile? if yes then you may want to list them in "packages" field of "home-environment" record <viperML>and I don't know what are the bindings for guile-readline or guile-colorized <viperML>$ cat home.scm && guix home reconfigure ./home.scm <viperML> (packages (list guile guile-readline guile-colorized))) <viperML>hint: Did you forget a `use-modules' form? <viperML>$ cat home.scm && guix home reconfigure ./home.scm <viperML> (packages (list guile guile-readline guile-colorized))) <viperML>guix home: error: failed to load './home.scm': <unwox>i usually deduce exact imports from a result of "guix show ..." command <unwox>"guix show guile-colorized" outputs this location: gnu/packages/guile-xyz.scm <viperML>next step is activating readline and colorized... <viperML>(use-modules (ice-9 readline) (ice-9 colorized)) <viperML>guile: warning: failed to install locale <unwox>i would try installing glibc-locales <viperML>I guess I need to add the guix home install location into the guile load path? <viperML>ok, added glibc-locales to the guix home config but the stack trace seems the same <viperML>alright, it seems that preping the guix home profile seems to work at least for just guile: export GUILE_LOAD_PATH="$HOME/.guix-home/profile/share/guile/3.0:$HOME/.guix-home/profile/share/guile/site/3.0" <viperML>though I install both guile and guile-readline, shouldn't guile be automatically wrapped to exposed the other packages into its load path? or maybe some way to modify the guile package to wrap it manually? <mange>I'm getting an unexpected issue with "guix deploy": "SSH authentication failed". I've checked that using ssh with the same username/key and I can log in. Does anyone have any ideas what might be going wrong? <mange>Ha, just figured it out. Muscle-memory made me run it with sudo (like a system reconfigure), but of course deploy doesn't need root permissions on the local machine. All good now. <Argyro>Hi, is there an equivalent of 'home-files-service-type' for system configurations? I just want to have a config file available and cant figure that out. Feel like i am missing something obvious. <jpoiret>Argyro: is it for something in /etc? if so you have etc-service-type you can extend <mange>If it's not in /etc/ then have a look at "(guix) Base Services" in the manual. extra-special-file should do what you need. It extends special-files-service-type. <dariqq>hi, has anyone looked into building packages that require gtk + rust? Or is this just a nightmare because rust. <Argyro>jpoiret: Ahh, that makes sense for files in etc. thx. <jpoiret>dariqq: probably the latter, but you never know until you try <Argyro>mange: i didn't really get what is meant by "special files". So 'extra-special-file' can just be used like 'home-files'? <dariqq>well i am not sure where to start because the package is built with meson that then invokes cargo but if i choose meson-build-system the guix-vendor stuff of cargo-build-system is of course not set up so cargo wants to download everything and fails. <mange>The manual explains it. Adding (extra-special-file "/some/file/name" (plain-file "file.txt" "this is a file")) to your services would put a file at "/some/file/name" with contents "this is a file". <mange>You can use a different file-like object instead of the plain-file call, too. So you can use local-file or file-append or whatever else you need. <jpoiret>dariqq: you can combine multiple build-systems with some knowledge, it's not easy but you basically can just add a build-system's (guix build ...) module to the environment and use its support code from there <jpoiret>the things you are interested in might not be exported though, which is bad practice imo <dariqq>jpoiret: so you mean using the initial phases from cargo for setting up cargo and then the configure/build/install phases from meson? <jpoiret>there probably are some examples of this lying around but I don't know where they would be <jpoiret>it's a common enough pattern for some projects that incorporate only some rust code <dariqq>sounds doable, but I hate how much extra effort is needed just because rust/cargo. <Argyro>mange: Okay, thanks for the help. :) <dariqq>I think managed to cherry pick the phases but now the problem is that some of the meson specific arguments are missing and i cannot set them because cargo-build-system does not know about them. Any ideas? <efraim>newsboat mixes cargo and something else. also librsvg and I can find some other ones if you need <efraim>dariqq: I'd suggest looking at the gnu-configure phase of librsvg. It uses the #:configure-flags field, which isn't available in the cargo-build-system <miro`>Hello, I tried to add (recursive? #t) to my xmake package in the origin section, to recover everything, but I still got an error on the field. <rekado>miro`: the (recursive? …) needs to be part of the (origin …) expression, not the (source …) expression <miro`>so, origin should not be in source? <mrvdb>hi guix. how can i give 'guix shell --container' access to a package defined in a (local) channel? i have a local channel defining a package 'openssh-fix', visible normally and installed, but guix shell (using a manifest.scm) complains about it being unknown. What am I overlooking ? <mrvdb>ah, found it, '(use-modules (local-variants)) where 'local-variants' is the name of the defined module for the channel doest the trick. <rekado>miro`: no, it should be, but your (recursive? …) thing is a sibling of (origin …) right now. It should be a child. <miro`>Yet that’s what I did. recursive is indeed a child of origin <rekado>in the paste that you linked to above it is not <miro`> Guix expects a hash of 0paz.. and says the current hash is 1rz.. To invalidate my previous hash I had to create a guix xmake.scm hash which gave me the hash of 0paz.. <miro`>So, is it really the hash of the file that needs to be included in the package? Or should I clone the xmake repository and hash the clone? <jmes>miro`: You have to hash the source file that you put in your (package ...) spec. Usually it's a compressed archive. <jmes>i.e. yes go and download whatever your source is, then run guix hash on it <lechner>apteryx / glad you like the bot. Guix commit titles are still missing because Savannah's Cgit is too old. I mentioned it to FSF and they told me to clone the repo. <q9c9p>hello, has anyone a minute to help with a uefi installation going wrong? somehow I get grub command line, and there's no binaries in boot even if i wanted to boot manually, super weird <q9c9p>i went through installation, left the offered partition table, I have a /boot/EFI from older installation and with older stuff, a swap partition and a root partition <q9c9p>but when in the grub command line i do ls (hd0,gpt4)/boot is empty <q9c9p>i haven't formatted or touched the /boot/EFI partition but wiped everything else, the latter installation of ubuntu might have had also a boot partition of a 100megs, did I broke the uefi installation perhaps? <jpoiret>so /boot/efi as mounted during install was your efi system partition, correct? <q9c9p>i still have the windows, ubuntu and debian executable on it from older running installations <q9c9p>but on the installed filesystem the whole boot is not populated, there's nothing or it install nothing, but the install procedure never gave any errors <q9c9p>there's no ramimage, no vmlinux, nothing, only the grub folder <q9c9p>i even tried to re download the iso, validate it, and dd'it again on a usb stick of 4 gigs <q9c9p>thinking the iso might have been corrupted in download or something <jpoiret>q9c9p: that's normal, the kernel and initrd aren't put in /boot <q9c9p>may you point me where they are? <jpoiret>i'd wager you probably put the wrong partition uids in your config <q9c9p>oh yes, i left the original-generated one <jpoiret>they should be referenced by the grub configuration <jpoiret>ah, you used the graphical install? my bad <jpoiret>the generated config should have the right guids <q9c9p>oh yes, apology i should have pointed that out in the beginning <q9c9p>so you would suggest me to redo the install and double check the block uuids of the config file before running? <q9c9p>in the stage where is possible to edit the configuration. right? <jpoiret>no, i'm not sure if that's the cause for that error :/ <jpoiret>and no message from grub when you try to boot? <q9c9p>one sec, i'll light up the laptop, i have grub shell <q9c9p>i can mount and manually load the kernel, if i can find it xD <q9c9p>since grub shell is there i'm assuming i haven't broke the uefi, right? <jpoiret>can you do `configfile (hdX,gptX)/boot/grub/grub.cfg` replacing the X's with the proper ones? <jpoiret>ah, hang on. Might it be that you're booting Ubuntu's GRUB? <jpoiret>have you tried looking in the UEFI boot order and adjusting it to boot Guix's? <q9c9p>the grub.cfg in boot is the guix one not the ubuntu one <q9c9p>but there's no guix.exe in the EFI directory <jpoiret>usually it's called /EFI/Guix/grubx64.efi <q9c9p>in the EFI directory i have Microsoft/ Boot/ debian/ ubuntu/ <q9c9p>i'm gonna try a disk repair distro to mount it and remove the debian one to free some space <q9c9p>i cannot asses the free space from grub <jpoiret>in any case you'll have to reinstall grub <jpoiret>at this point you might just restart the installer ISO, and use the shell provided there for that <q9c9p>yes, but i've done that already a dozen times without realizing what's wrong <q9c9p>gonna try and check the uuid on config, thanks <jpoiret>did you check that you're booted in EFI mode? <jpoiret>and thus that in the generated config the bootloader is grub-efi <q9c9p>sorry, went to get coffe, no i haven't checked that <q9c9p>is it mentioned in the docs and i oversaw it ? <q9c9p>oh in the config, will check immediatly, i'm rolling through the install as i type <q9c9p>oh, not sure how and if it might an issue, but i have an unsupported internal wifi card, so i connected a usb dongle, it warns me in red that one of the cards is unsupported, but then immediatly switch to the other and let me auth and connect <jpoiret>you can check earlier by going to tty3 and doing `ls /sys/firmware/efi/efivars/` <dariqq>after creating a 10k lines of rust crate imports and tweaking things a bit it finally works. However crate that should be fetched via git is not being imported into guix-vendor? Does #:cargo-input only work for packages from crates io? <q9c9p>I'm at the configuration editior option screen, first i'll check if the bblk uuid are correct? <q9c9p>is there a way in the installer to activate a second term? <q9c9p>ohhh i found what you said, it says bootloader grub-bootloader, and it should be grub-efi-bootloader, am i understanding right? <q9c9p>thank you so much, the installer is running <dariqq>weird, i have to put the git package in both inputs and cargo-inputs for it be recognised <jpoiret>q9c9p: if it says grub-bootloader, you probably haven't booted in efi mode <jpoiret>have you tried the `ls /sys/firmware/efi/efivars/` command? <q9c9p>no i haven't yet, i press continue to quick <q9c9p>and i can't open another tty so i can't know <dariqq>but this is just a complete mess <q9c9p>i'm going to look in that directory <PotentialUser-72>Hello. Noob here. Is it normal for "guix pull" to take a very long time to run? <q9c9p>no there is no efi/efivars in sys <q9c9p>also i just noticed the grub i'm dropping into at boot is the debian one <q9c9p>how can it be this difficult? should i disable uefi? <q9c9p>i'm goint to follow the manual installation one last time before moving on <PotentialUser-72>How often do you run "guix pull" in your systems? Is it a pre-requirement to call "guix upgrade"? <lispmacs[work]>if you do not guix pull first, you don't have anything to upgrade to <PotentialUser-72>lispmacs[work] But you can still upgrade packages without calling "guix pull"? <lispmacs[work]>well, the upgrade option will upgrade to the latest version of guix you have pull'd to <lispmacs[work]>so, if you run guix pull, and the guix upgrade twice, the second time of running guix upgrade it will say "nothing to do" <futurile>grr - another set of patches where debbugs randomly decided to make new bug numbers for every patch I send <lispmacs[work]>PotentialUser-72: personally, I use the package -m (--manifest) option, where I have a list of packages I want defined in a file <lispmacs[work]>then, instead of running "package install" to install new packages, I run package -m on that manifest file <PotentialUser-72>lispmacs[work] But still limited by what is available on the channel, right? <lispmacs[work]>there are tricks where you can add additional channels from other projects <lispmacs[work]>and tricks where you can actually pull packages from a past guix checkout <jpoiret>q9c9p: you need to ensure you're booting into uefi, you probably have something like compatibility mode enabled in your BIOS <jpoiret>so that the usb key boots in UEFI for sure <PotentialUser-72>It seems to be that the default channel is lagging behind in some software, like Python and Python modules. I was wondering if there was another channel that provided newer packages or if the only option was for me to create my own packages from source. <lispmacs[work]>PotentialUser-72: anyway, normally when you run guix install or guix upgrade, you are limited to whatever packages (technically, package definitions) that are available from your last guix checkout pulled in by guix pull <lispmacs[work]>PotentialUser-72: one option would be to modify the existing package definition (to a newer version) and build/install that new package definition <lispmacs[work]>the command "guix edit <package>" will show you the package definition <PotentialUser-72>lispmacs[work] Totally the first thing I thought of trying. When I get this Guix thing better understood. <lispmacs[work]>PotentialUser-72: I believe "guix build" might have some helpful package transformation options for you <lispmacs[work]>yeah, check that section out. there are command line options for changing the package version <PotentialUser-72>lispmacs[work] Thank you. By the way, I could not find a list of Guix channels. Is one available? <q9c9p>thank for all jpoiret i changed some setting in the bios, will try one more time than move to legacy boot <lispmacs[work]>PotentialUser-72: I haven't seen such a list. guix only promotes their channel, but the mechanism allows anyone to create a channel <lispmacs[work]>PotentialUser-72: another trick is to use guix pull to checkout a specific branch or testing commit of the official guix channel <lispmacs[work]>and then in "Build Status" you can see what builds have been made, and what commits they came from <lispmacs[work]>you can, of course, also make a clone of the guix repository and look at what branches are available <dariqq>efraim: I think i found the issue: the git package needs to be included in cargo-inputs such that all rust-dependencies are also pulled in. However as the src is not a tarball it isnt unpacked in the configure phase (crate-src? fails as i fetch with git-fetch and not url-fetch) on the src. But as it is included in inputs the tar.gz exists in the store path and is then extracted during the unpack-rust-crates phase. A bit unintuitive thou <lispmacs[work]>"guix pull --commit=COMMIT" will allow you to pull a specific commit <lispmacs[work]>there is also the nifty "guix time-machine" tool if you want to experiment more safely <lispmacs[work]>allowing you to temporarily switch to a different commit just to build a specific package or profile <PotentialUser-72>Could you please clarify this: "guix build --with-latest=PACKAGE" will check the latest upstream release of PACKAGE available at the PACKAGE's repository. The limitations are, then, the authentication and it handles the chacksum too, I assume, but is not limited to the version available on the Guix official channel. Am I reading this correctly? <lispmacs[work]>PotentialUser-72: correct. Depending on the build system and source type of the package definition, there might be some way for it to fetch the latest release or repo commit, rather than the defined one <snape>PotentialUser-72: the other channel is nonguix <lispmacs[work]>that may or may not build successfully, is something radical has changed in dependencies or build scripts, etc <snape>I mean the other channel other people use <snape>(disclaimer: I don't because Guix is better ;-)) <PotentialUser-72>I wish there was a NIX to Guix package definition converter, sort of like debian's "alien" tool. But I suppose that would be too difficult to pull out reliably. <lispmacs[work]>PotentialUser-72: you can build/install Nix using guix, if that is helpful <ryan77627>PotentialUser-72: I'll be honest, I just have guix installed and have nix as a package. Surprisingly few things weren't available that I use, but in the event that they were I just augment my home profile with nix's home-manager. Best of both worlds ;) <ryan77627>If you do that however your space requirements go up quite a bit since they cannot share a store <snape>I used to do that too, then I packaged the missing stuff, now I don't need Nix anymore <PotentialUser-72>Thank you very much for all the info, nice people! I hate to "ask and run" but I have some things to do. <alethkit>what counts as a valid g-expression input for the purposes of identifying a filesystem? <ryan77627>snape: Yeah I try to as well, though some packages are just "out of reach" for my packaging skills xD <snape>the IRC logs search doesn't work very well it seems <snape>if I type my username I only find stuff from 2019, and very little stuff <rekado>it’s a known problem. The search db gets updated all the time, but the frontend is blissfully unaware of it. <civodul>rekado: you mean the frontend uses an old copy of the db for searches? <civodul>cbaines: hey! can you remind me since when bordeaux.guix has been keeping substitutes? <civodul>/gnu/store/vvhn7r1343mkyj291h13f3bk29n6m8j6-openssl-1.1.1g.drv from early 2020 isn’t there <snape>I get the libgit2 error "Could not find appropriate mechanism for credentials" while trying to download a git repo with a guile script. I wonder what I did wrong <apteryx>if so, you need an ssh-agent running <apteryx>then I'm not sure. Perhaps grepping for that error in libgit2 sources would yield a clE. <snape>yeah that's what I'm doing thx <alethkit>what's the recommended method of specifying filesystems? Guix seems to reject using UUIDs <snape>ok well with another link it works, nvm <dariqq>finally after way to much time everythings builds correctly. Should have just used the vendored sources in the release tarball <snape>apteryx: it means "binding" i guess <snape>or maybe you were talking about the below error <snape>ok I just didn't read well your message <snape>unrelated: I wonder if we should use security in our build fetch procedures, because I imagine a lot of people just build stuff and then corret hash based on the error message <snape>and those people may end up with tampered stuff on their computer <Guest96>How long does a patchset need to go stale before I should worry? Someone submitted a patchset to update Synapse (Matrix homeserver) which I manually applied to get mine working. However, that thread has been stale since August... <apteryx>Guest96: it's good to ping on the thread and here, and post your review/and or experience with the change <apteryx>did it fix some problem or it's just an update? <Guest96>It fixes a problem. The matrix homeserver as it is will not run. It will install (last I checked), but will immediately crash when launching it <apteryx>great. I'm a bit confused looking at bug#62389 as there as a v2, from a different person? <apteryx>also I'm not sure moving many of these packages to python-cryptography-next is safe, as now we'll have an unholy mix of python-cryptography packages propagated <apteryx>and currently the whole Python universe needs to agree on what it's using <apteryx>else clashes and problems will occur elsewhere <apteryx>there's a 5 months old python-team branch, with python-pycryptography 40 <apteryx>perhaps it should be rebased there and that branch then merged after being built <efraim>I have been tending python-cryptography as part of the rust-team branch <efraim>I have a couple of python packages that use the cargo-build-system <podiki>python-cryptography is at v41 on master currently <podiki>there were some WIP changes with updating some base pyproject build system stuff, but i haven't had a chance to look at it in a long time <podiki>Lars had their own branch they were working on <podiki>and i see now a message from sharlatan i never got (presumably another victim of not wide replying? how many messages were just never seen because of the expectation that debbugs emails anyone when you email a bug number address) <Guest96>podiki: I have certainly been the victim of that <podiki>poetry and yubikey-manager were both fixed on master via other means <ryan77627>Quick question. I have a package that I build myself that takes a while to actually compile, so naturally I want to avoid re-compiling most of the time. Whenever I GC, it gets recompiled. I've been talking to people and we narrowed it down to grafting, so i want to make a GC root of the non-grafted package so it doesnt et swept. is there a "guix-y" way of doing this? I know the command is `guix build <ryan77627>-r=dest package-name` but I don't know what to put for dest. <ryan77627>I _could_ make a folder in my home directory for these temporary roots, but if there's a proper place to put them that's out of the way I'm all ears. <podiki>i don't think there's any "proper place" if i'm understanding. guix keeps track of these roots (via database? or store links?) but doesn't matter where they are i believe <podiki>maybe there is some clever workaround? but you can put them anywhere i believe, just like profiles can be anywhere (i keep mine in .config/guix/profiles for instance) <podiki>maybe you can create a profile that has ungrafted packages just for keeping these roots. e.g. a profile created with --no-grafts i'm guessing <ae_chep>I am updating the package definition for CBQN and I need to choose between downloading bytecode files (they look like C headers). Is that something we are OK with? It will make for a simpler package definition. <ae_chep>*choose between pre-created bytecode files or using the Java implementation of the language to generate the bytecodes locally <ryan77627>podiki: Might be time for me to learn more about profiles, as that's one part of Guix I've not really touched yet. Thanks! <podiki>ryan77627: profiles are handy indeed! but unfortunately we could use some better tools to manage multiple if you want them all active (as in using them for your desktop, rather than ones for development in different projects). as it is i have a little bash to source all profiles, taken from the cookbook i believe <lilyp>sorry, hit some random keys as I was swapping out batteries <ulfvonbelow>when a package produces a binary using ocaml, do the input ocaml packages need to be propagated? <apteryx>is it possible to use a state monad within the store monad? <apteryx>or are these to be used without any overlap? <civodul>apteryx: you can do (run-with-state … xyz), where ‘xyz’ is a bunch of state-monad code <civodul>but that’ll leave in a “different world” <civodul>the two monads would not be composed <apteryx>I was looking at tracking visited packages in package->derivation via a state monad <apteryx>the motivation being that the current cycle detector doesn't detect derivation cycles <apteryx>but looking at package->derivation it's mostly monadic procedure/values so I was wondering if wrapping this code in a state monad would work; based from your reply it seems it wouldn't? (no composition possible)