<sneek_>matt`, nckx says: We don't use grub-mkconfig (thank god), you might be thinking of ‘grub-install’. If not, grub.cfg is assembled in (gnu bootloader grub). You're right that GRUB_ENABLE_CRYPTODISK is set, but could you explain why cryptomount would be needed?
<sneek_>matt`, nckx says: We don't use grub-mkconfig (thank god), you might be thinking of ‘grub-install’. If not, grub.cfg is assembled in (gnu bootloader grub). You're right that GRUB_ENABLE_CRYPTODISK is set, but could you explain why cryptomount would be needed? Your setup sounds like something we might not even handle…
<matt`>it points me to a guix-command in the store. i'm not sure how to test if that's good. i did try to run guix from diff profiles under /var/guix but no success. i tried 2 of 3 previous gens. #2 worked fine when i was using it previously
<matt`>i just rebooted to them in the grub manual, but i can check the manual. also i checked the symlinks for other profiles in /var/guix and they point to different directories in the store but all give the same error
<quiliro>regarding going to the store and executing the full path of the exectuable, i have only done for testing...it is better to roll back
<matt`>it does... i'll try it over and see what i get. i think the problem started when i began using desktop-services but i believe that ropes in a lot of code so i'm entirely sure where to start. i'm also not convinced it's that
<bricewge>Is there a way to overwrite part of a package from the cli? Trying to build old version of zsh thanks to `--with...` flags, I wan't to disable the package test.
<nckx>bricewge: Er, kind of: you can ‘overwrite’ any package ‘from the cli’ by writing an (inherit …) expression by hand with -e, even though that's not what you mean. There's no ‘--disable-tests’ flag.
<bricewge>nckx: No that what I was looking for actually, I didn't knew what the keyword was use to overwrite a package. Thanks!
<bricewge>A flag that I'm missing tough would be `--with-git-rev` to use git tags.
***emyles`` is now known as emyles
<nckx>bricewge: (git-reference (commit …)) in packages already accepts tags and branch names, so ‘--with-commit=’ should do the same. I'm honestly surprised that it doesn't, at least according to the manual. Have you tried it in practice?
<nckx>(‘COMMIT must be a valid Git commit SHA1 identifier’ was news to me.)
<nckx>Also insanely git-specific for a generic ‘--with-foo’ option.
<amz3>guix was added to the intial list, but I think the description is missing. Going throught the website, there seems to be no "tag line" or "catch phrase". I intended to replace 'Guile packages' with 'Functional Package Manager and Operating System Distribution'
<amz3>do you think "Functional Package Manager and Operating System Distribution" is good?
***emyles`` is now known as emyles
<nckx>amz3: The ‘tag line’ in source files is ‘Functional package management for GNU’. I think adding the notion of OS is a very good idea.
*nckx looks forward to discovering new Guile things.
<bricewge>Is it the expected behaviour that if a source from a mirror can't be found it fallback to use the sha256 value to download it? It feel weird that trying to build, by error, `my-hello-2.7777777` succeed.
<pkill9>the application menu doesn't update for me with gnome or xfce either, but it doesn't when i add .desktop files to ~/.local/share/applications, which leads me to believe that gnome/xfce "watch" the store path of the profile, rather than the symlink to the profile (e.g. /gnu/store/...-profile/share/applications rather than ~/.guix-profile/share/applications)
<dadinn>I am trying to configure my guix binary install according to the docs, and a question came to mind about point 2.6.2 Name Service Switch: it explains why it is needed but not how to do it... would I need to add a systemd unit for that?
<dadinn>also I noticed that in 2.6.3 X11 Fonts the paragraph refers to $HOME/.guix-profile which I suppose is wrong, as it seems to have been changed to `$HOME/.config/guix/current` istead, or am i wrong?
<civodul>~/.config/guix/current is just for Guix itself
<dadinn>rekado_: I see that /var/guix/per-user/profiles/guix/current-guix is a symlink too, as expected. I suppose what you mean by recovering from a bad pull is to change this /var/guix/.../current-guix to an older folder under the ../per-user/username/* dirs
<rekado_>tune: I managed to build fastboot after downgrading android-googletest to 1.8.0. Will push this to the master branch in a minute.
<dadinn>roptat: why do you need that even for the root user? `guix pull` should be run later on anyway, and for all that you would only need `export GUIX_PROFILE=/var/guix/profiles/per-user/root/current-guix`, no?
<roptat>it's for convenience I think, so you don't have to temporarily export something
<dadinn>roptat: what I was doing in my script is create a /etc/profiles.d/guix script, which does the following:
<rekado_>(hint: roptat and rekado_ are different people) ;)
<rvgn>Looking at the recent conversation, I too encountered to export a path after guix pull as root user. But for past few days, it doesn't ask me so.
<rekado_>dadinn: yes, $GUIX_PROFILE/etc/profile should be sourced to set environment variables relevant for the software in the profile. However, GUIX_PROFILE should not be $HOME/.config/guix/current but $HOME/.guix-profile.
<roptat>I think, you should source $HOME/.guix-profile/etc/profile, but add $HOME/.config/guix/current/bin to your $PATH
<dadinn>roptat: somewhere else in the docks it recommends to symlink the guix binary under /usr/local/bin, but if I add .config/guix/current/bin to the PATH, that should do it too, no? I assume this so that all users, ones which have no guix profile yet, can access it to do a `guix pull`?
<nckx>Your dotfiles in .config, .cache, &c. I assumed it was a bit of a joke; are you really worried there's something that sensitive there? I'd reconsider the software you use or how you use it, then (mounting [parts of] ~ as tmpfs, &c.). LUKS at the least. Once data hits ‘modern storage’ it's impossible to guarantee its deletion.
<efraim>I was going to suggest we don't install it but I'm guessing some guix-on-foreign people might like it
<efraim>I have a .guix-profile/lib/python3.7/site-packages/_version.py that we probably don't need though
<efraim>well, it seems that python-configobj does ship and reference that file
<jackhill>What's the recommended path for getting a latex environemnt. I know there was some work to make the packages more modular, but if I'm not worred about diskspace, is texlive still ok, or is it no longer recommended.
***Tirifto_ is now known as Tirifto
<efraim>not recommended if you're planning on submitting something upstream
<rvgn>Boot firmware and processor comes with blobs right?
<OriansJ>rvgn: there is a reason why there is the RYF certification process
<OriansJ>absolute freedom isn't yet technically possible but we want to encourage steps in the correct direction
<rvgn>OriansJ Yes, I bought by device based on that :)
<nckx>rvgn: I shouldn't have used such a loaded term, I don't have an opinion on that (never even held a Librem), I just meant ‘unless they blatantly ship WiFi/GPU/… chips that demand to be fed evil firmware’, which I'm quite certain they don't.
<OriansJ>essentially there are no processors available without microcode (unless you are willing to pay $20K to make your own
<nckx>rvgn: You can refuse to ship updates for the (proprietary) microcode, which is what GNU does, which is a sad compromise (the user still runs the proprietary microcode, just the old copy in CPU ROM, which may have bugs).
<OriansJ>right now unless you are willing to limit yourself to 64MB of ram; you will be running on proprietary hardware
<rvgn>OriansJ Damn! I am reconsidering my choice of buying RYF device over librem.
<OriansJ>rvgn: librem is just a different compromise point; neither is perfect and we just hope you know what you are agreeing to when you invest in a technical future
<rvgn>nckx OriansJ Btw, RYF devices comes without IME right? Where as librem does?
<nckx>rvgn: A Librebooted X200 contains objectively fewer blobs that other machines, but no (affordable, consumer, performant) machine has 0. So as OriansJ says, it's just a line you have to draw and live with.
<OriansJ>for some people (gnome developers I am looking at you), you "need" a high end CPU to be productive and librem tends to be the more appropiate choice (system76 is also good)
<nckx>System76 has slightly more good will than Purism amongst the Free folk, although I'm not sure how much of that is technical. They make great machines though. And they invest in hardware manufacturing, even though they're still tied to Intel chips.
<nckx>The problem is — and I'm not saying this to discourage you at all, Marlin[m], take this as a general statement — that reverse engineering takes time, and ‘market’ forces conspire to give you very little of that. Bought our previous GPU? Well it's crap now buy our new one.
<OriansJ>Marlin[m]: everyone here is willing to help people start becoming productive members of the community
<Marlin[m]>although i have the habit of trying to bite more than i can chew
<Marlin[m]>i end up trying to learn too much at the same time
<nckx>Marlin[m]: You're certainly ambitious, but there's nothing wrong with that.
<Marlin[m]>hacking two or three amd gpu models would open a whole new selection for us
<rekado_>Marlin[m]: I suggest trying to set smaller goals initially to better understand the problem you’re attempting to solve. It’s hard to act on a big goal because you don’t really know how to make progress.
<OriansJ>Marlin[m]: and we want you to succeed; make sure to make failure cheap
<Marlin[m]>for instance, getting the rx550, rx 580 and vega64 blobs hacked would result in modern entry level, medium level and high level gpus working with free drivers and firmware
<rekado_>for a GPU this might mean to first learn what the firmware *does* to the chip.
<Marlin[m]>rekado, it's not like i'm busy with anything else tbh :P