<mbakke>civodul: No worries! I'm AFK until ~thursday anyway. And also hoped to squeeze in a Meson build system patch (delete 'bootstrap). <bandali>that’s kind of subjective, but i suppose anything that works well with the linux-libre kernel <bandali>for one, older thinkpads come to mind <matt`>hey all. i'm getting a load of errors, "no code for module..." when i run guix pull <sneek_>Welcome back matt`, you have 2 messages. <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`>has anyone seen this before? <quiliro>matt`: 'which guix' might give a hint <quiliro>or maybe a previous generation might work <matt`>quiliro: i tried a previous gen and unfortunately i got the same error. which guix gives me .config/guix/current/bin/guix <matt`>~/.config/guix/current/bin/guix <quiliro>and 'ls -l ~/.config/guix/current/bin/guix' is good? <quiliro>did you try all previous generations? <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 <quiliro>i do not quite remember what is the exact syntax to '--roll-back' a generations or '--switch-generation' <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 <quiliro>is your installation a guix system or just guix on aforeigh distro? <quiliro>you can go back to #2 with '--list-generations' and then '--switch-generation' <quiliro>then you can execute guix pull from then on ...but you will loose later generations <matt`>just tried on all prior generations and i'm getting the same error <quiliro>did you not say it did a minute ago? <matt`>it did before this problem started occurring <matt`>and after the problem began reverting to prior generations hasn't seemed to help <quiliro>#2 does not work even when rebooting to it? <matt`>that was the first thing i triedd *quiliro is thinking because he is temporarily without ideas <matt`>i'm honestly new enough to setting this up that i could save my config and wipe my partitions and start over. but i'm worried this will just happen again <quiliro>well, if it happens again, you can trace the problem to the origin <quiliro>perhaps if you remember what you did that caused the problem, you will be able to reproduce it <quiliro>if it is reproducible, you can report a bug <quiliro>or maybe report what should not be done :-) <quiliro>if it is not reproducible, how can we know what happened? <quiliro>does what i am saying help in some way? <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 <matt`>s/i'm entirely/i'm not entirely/ <jonsger>oke, but its only one patch. So that is not a problem : <efraim>can I mount a directory as a tmpfs as a user or do I need root permissions? ***jonsger1 is now known as jonsger
<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! <nckx>Oh, OK ☺ More power to you! (Literally.) <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. <nckx>Shame. I was hoping for a documentation bug. <bricewge>A `--with-git-rev` could replace `--with-git-branch` and `--with-git-commit` as far as I understand git. <nckx>(Is ‘rev’ short for ‘revision’?) <nckx>bricewge: I agree that this should be added, so I've submitted a bug. I'll look into how this'd be added with libgit2, although it should be trivial (ha ha…). <amz3>hello, we (scheme doc people) are working on an awesome list to document and spread the awesomeness of schemers parens. <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>It is the GNU system, after all. <amz3>ok, I will paste the link to the awesome list once it is in better shape <amz3>aka. ready for contributions. *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. <rekado_>amz3: is this list going to be added to the Guile web site? <nckx>bricewge: That's deliberate. Makes things slightly less fragile when upstreams disappear, break, or do silly things. <nothingmuch>is there an idiomatic gexp equivalent of using subshell to isolate chdir? e.g. (cd foo; some_command) ? <rekado_>nothingmuch: I’m not sure I understand, but you can run a command in a sub-directory with “(with-directory-excursion …)” ***ChanServ sets mode: +o Sigyn
<civodul>bricewge: allowing --with-git-commit to handle tags Shouldn't Be Hard™ <civodul>in the meantime you can always file a report to bug-guix *civodul wonders if mumi could be extended to be used as a mailing list archive browser <nckx>civodul: Does that link work for you, right now? <nckx>Hm, must be an Icecat issue. *nckx restarts the Internet. <nckx>civodul: Why I asked? Because only lists.gnu.org failed here. <civodul>nckx: are you sure you're connected to the Internet? <z0d>not sure. maybe it's IP over carrier pigeons <nckx>Be glad I never bored you with the story of how I installed my first OS. <nckx>(Only my grandparents 20km away had dial-up, I had a bike and 2 boxes of 1.44M floppies and a desire for Slack.) <nckx>Why am I rambling? Because it's 33° and my CPU won't work fast enough. <nckx>o/ z0d, by the way, don't think I've seen you before. <rekado_>I wonder why “guix refresh” is so commonly misunderstood <rekado_>(reads the distrowatch article on Guix) <rekado_>the article concludes that Guix is “unpredictable” <roptat>I guess they tried to install stuff in parallel in the same profile? that can have difficult to predict results, no? <nckx>*doesn't read the manual* *complains about how it's too hard too use* <roptat>maybe we should prevent users from doing that? like with a lockfile or something? <rekado_>this “guix pull; guix upgrade –> says to run ‘guix pull’” issue is likely the usual old “hash guix” problem. <roptat>and a message "another operation is in progress on this profile, cancel the other operation or wait for it to finish before performing another operation on this profile." or something? <rekado_>roptat: yes, this seems like a good idea. <roptat>"hash guix" is annoying, can't we do something about it? <roptat>I know, but users shouldn't have to care... <rekado_>because ~/.config/guix/current does not exist at first <rekado_>so maybe we can get around this by having ~/.config/guix/current exist by default. <rekado_>or by setting the default PATH on Guix System to ~/.config/guix/current/bin/:$PATH <roptat>guix will load ~/.config/guix/current/etc/profile if it exists <roptat>but it doesn't set PATH otherwise <rekado_>we check if $HOME/.config/guix/current/etc/profile exists <rekado_>if it doesn’t we add $HOME/.config/guix/current/bin to the beginning of the PATH. <rekado_>ah… but this directory doesn’t hold a “guix” executable <rekado_>so “guix” would map to /run/current-system … <roptat>ah of course, so after guix pull, even if the right guix is in $PATH, you need to run "hash guix" <rekado_>I suppose we could add an executable link to .config/guix/current/bin, so that initially “guix” is found there <roptat>so that would be in skel, right? <rekado_>then the Bash executable cache doesn’t have to be updated once “guix pull” is done. <rekado_>to make sure that “guix pull” will still work <civodul>there are two bug reports: "guix pull" that suggests running "guix pull", and application menu not updated after "guix install" <civodul>and the start-up time of ten minutes, which sounds really weird <civodul>"I installed a few other desktop programs and then found Icecat had disappeared from my path again" ?! <roptat>that's the part that makes me think they installed a few things in parallel <roptat>so icecat was actually not in the current generation of the profile anymore <roptat>that's why I was suggesting to use a lockfile to only have one transaction at the same time <civodul>a lock file sounds like a reasonable thing to do <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) <pkill9>dunno why they needed to reboot though, i only have to restart gnome/xfce (don't need to logout in gnome, just restart gnome-shell in place) <joshuaBPMan>does anyone have a channel that has firefox packaged? I'm getting really tired of using iceweasel... <pkill9>joshuaBPMan: how is icecat not working for you? I though it was just a rebranded firefox with additional extensions installed and enabled by default which you could disable? <nckx>That's exactly what it is, plus a few privacy/freedom tweaks. <joshuaBPMan>pkill9: It works. But it's annoying. It flickers a lot (probably because I'm using sway). I haven't been able to get it to sign into firefox sync. <tune>looks like if I hold back adb, fastboot also fails to build <joshuaBPMan>It's also firefox version 60. So it's a little behind firefox. <joshuaBPMan>honestly, I want to try the latest version of firefox and check out it's wayland port. <roptat>I have a firefox recipe, but it's broken now... <tune>I also get the flickering sometimes with icecat on sway <roptat>but now that we have more recent versions of rust, I guess I could try to build it again <pkill9>joshuaBPMan: you could try wrapping the binary package of firefox that mozilla provides <pkill9>joshuaBPMan: patching the interpreter to point to guix-packaged glibc, and running it with LD_LIBRARY_PATH=<list of packages> <rekado_>civodul: “guix pull” suggesting “guix pull” is probably just because “hash guix” wasn’t run. <rekado_>civodul: we might be able to avoid the need for “hash guix” by including “.config/guix/current/bin/guix” by default; even if it’s just a link to /run/current-system/profile/bin/guix <tune>fastboot might fail because of adb being skipped. I don't really know <tune>the buildlog it refers me to still has adb in the name <joshuaBPMan>pkill9: sorry man. That went right over my head. What interpreter am I patching? <rekado_>pkill9: this is probably going to result in something that’s not usable. Too many dependencies that would need to be added to LD_LIBRARY_PATH and that might have a different ABI. <pkill9>joshuaBPMan: also i just tested it with my FHS-compatibility service and it worked <rekado_>tune: can you see what the log file for the failed build says? <tune>for the initial adb fail I posted the log further up, I'll grab the fastboot one too I guess <tune>ah I scrolled up and noticed it is just a dependency problem for fastboot <tune>cannot build derivation `/gnu/store/psw17p1kfwkphfszawkdqlialj7y3fqg-fastboot-7.1.2_r36.drv': 1 dependencies couldn't be built <rekado_>okay. Why can’t fastboot not be built then? <pkill9>rekado_: i dunno, i quickly tested it with guix dependencies and it ran <rekado_>tune: looks like incompatibility between android-googletest and android-platform-system-core <rekado_>android-googletest got upgraded indirectly because of an upgrade to googletest. <rekado_>if we aren’t ready to upgrade all of the android packages now we could override the source and version fields of android-googletest. <tune>I don't need the android stuff that badly so I've just held back both adb and fastboot for now so my updates can go through <rekado_>I’m trying to build an older googletest now ***jje_ is now known as jje
<civodul>rekado_: re avoiding "hash guix", your suggestion should work; we'd have to check if it breaks assumptions about ~/.config/guix/current being a profile <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? <civodul>dadinn: on Debian-based distros, it's just "apt-get install nscd" <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 <nckx>dadinn: .guix-profile is your user profile containing all your installed packages, including fonts. …aand here's civodul with the rest ☝ <dadinn>civodul: if instead of binary install, I rund the guix SD system, does it itself run this automatically, or it is not even needed there? <civodul>on Guix System, nscd runs by default <dadinn>civodul: what do you mean that .config/guix/current is just for Guix itself? do I still need to create .guix-profile manually for all users (root included)? <rekado_>dadinn: .guix-profile is for software you install with Guix <rekado_>dadinn: .config/guix/current is where “guix pull” installs new versions of itself <rekado_>the fact that this is a Guix profile is just an implementation detail <rekado_>(it allows you to recover from a bad pull) <dadinn>rekado_: I don't understand, .guix-profile and .config/guix/current are symlinks to /var/guix/per-user/profiles/... no? <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_>28% of omics tools are impossible to install <dadinn>rekado_: what I don't understand is the $HOME/.config/guix/current symlink, the docs say I have to create it manually, but does it automaticaly get created for new users? if so how? <rekado_>dadinn: no, I mean to just use ~/.config/guix/current-1-link/bin/guix <rekado_>dadinn: where do the docs say you have to create it manually? <rekado_>it’s created the first time you run “guix pull” <dadinn>rekado_: also I don't understand why the symlink used to be $HOME/.guix-profile, but now i see the docs changed to $HOME/.config/guix/current instead <dadinn>rekado_: ah, I didn't notice `guix pull` creates it :/ <rekado_>dadinn: can you please show me where in the manual it tells you to create .config/guix/current? <roptat>dadinn, we still use $HOME/.guix-profile <roptat>both are different profiles (you can see it with e.g. guix package -p $HOME/.guix-profile -I and guix package -p $HOME/.config/guix/current -I) <roptat>current only contains "guix" (it's the result of guix pull) <roptat>while .guix-profile contains the rest of the software you install as a user <dadinn># ln -sf /var/guix/profiles/per-user/root/current-guix \ <roptat>but that's only for root, not other user <roptat>.guix-profile will be created automatically if it doesn't exist <roptat>(and $HOME/.config/guix/current too) <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: <dadinn>export GUIX_PROFILE=$HOME/.config/guix/current <dadinn>export GUIX_LOCPATH=$GUIX_PROFILE/lib/locale <dadinn>and then i manually source it in the install script <rekado_>GUIX_PROFILE should not be set to the profile that “guix pull” uses. <dadinn>sorry I actually only used that profile for the install/configure script <dadinn>rekado_: are you saying that on a running system, after install, I shouldn't `export GUIX_PROFILE=$HOME/.config/guix/current`? <roptat>I think you should `export GUIX_PROFILE=$HOME/.guix-profile` instead <dadinn>rekado_: but it needs to be like that, because for every user, their profile should source the $GUIX_PROFILE/etc/profile, no? <dadinn>I don't understand what's going on <roptat>you're not sourcing the right profile <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 <Marlin[m]>gonna get back to working full energy when i'm home tomorrow <rvgn>rekado_ Should export any path after doing guix pull as root user? <Marlin[m]>also have some importers/build systems in mind <nckx>rvgn: Only if Guix tells you to. <rvgn>nckx I see. Currently, when I do "which guix" as root user, the output is /run/current-system/profile/bin/guix <dadinn>roptat: what is the difference between the directory $HOME/.guix-profile and HOME/.config/guix/current are pointing to? <rvgn>nckx should that be the case? <rvgn>nckx Hmm. Shouldn't it be /root/.config/guix/current/bin/guix <rekado_>dadinn: I’ve tried to explain this already. <rvgn>nckx Because that's what guix hints me to export each time I do guix pull as root user. <nckx>rvgn: Is this the machine on which you've pulled as root? <rekado_>again, $HOME/.guix-profile is where Guix installs your packages by default; $HOME/.config/guix/current is where “guix pull” installs new versions of Guix itself. <nckx>I've never pulled as root, so… <nckx>rvgn: Yes, it would be good to find out why that doesn't ‘stick’. <roptat>dadinn, .guix-profile is for user's (or in your case root's) packages (that's what guix install, guix remove, guix package and guix upgrade work with by default) <dadinn>rekado_: hmm, so you mean that .config/guix/current is a systemwide guix profile which is shared by all users, while .guix-profile is a per-user profile? *nckx pulls as root even though it feel wraaoung. <roptat>dadinn, current is a profile that only contains your latest guix <roptat>each user is able to use their own guix version if they want to <roptat>but sourcing current/etc/profile makes little sense, since there's only guix in the profile <roptat>you really want to source .guix-profile/etc/profile, since that's where your software is installed <rvgn>nckx Let me know whether you get an "hint" at the end of guix pull. <roptat>again, try to run "guix package -p $HOME/.guix-profile -I" and compare with "guix package -p $HOME/.config/guix/current -I" <nckx>rvgn: It's computing things. That's going to take a while in this weather. <roptat>(-p is for --profile, it allows "guix package" to act on a non default profile, so the first command is exactly the same as "guix package -I") *rvgn assumed nckx was using a super-computer xD <nckx>Doesn't sound like what you mean. I assume the ‘hash guix’ is because I've never pulled as root before. Nothing about exports. *Marlin[m] will start studying assembler language and driver programming in order to get into firmware reverse engineering <rvgn>nckx Exactly, shouldn't it automatically refer to `/root/.config/guix/current/bin/guix' after first guix pull? <nckx>Only your current shell might have cached (‘hashed’) the old location so it needs to be prodded into looking again. <rvgn>nckx What does 'which guix' as root user say for you? <nckx>rvgn: Note: ‘which’ does *not* tell you which command your shell will execute, as commonly misunderstood. <nckx>It told me: which -a guix <nckx> /root/.config/guix/current/bin/guix <nckx> /run/current-system/profile/bin/guix <nckx>It just tells you what ‘which’ found, using rules which it hopes are similar to your shell's. <rvgn>nckx I see. So for you, 'which guix' gives '/root/.config/guix/current/bin/guix' as output ??? <g_bor[m]>It seems that after som experimenting I got a minimal wayland-weston+Xwayland setup working. <nckx>But that doesn't mean that running ‘guix’ *in that shell* would run the new guix. <rvgn>rvgn Then why for me its '/run/current-system/profile/bin/guix' ??? How can I change it?? <nckx>The ‘hash guix’ *will* ensure that. <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`? <rvgn>nckx even hash guix is giving /run/current-system/profile/bin/guix <nckx>rvgn: I can only say that something is wrong, I can't think of what. <dadinn>roptat: cool, that means I start to get it :P <nothingmuch>dadinn: you can also source .config/guix/$profile_name/etc/profile for roughly the same effect <nothingmuch>am i correct in understanding that git-fetch does not preserve the commit date anywhere? (for setting SOURCE_DATE_EPOCH) <efraim>does openssh really need to have /gnu/store/...openssh/var/empty ? <efraim>I was looking at my .guix-profile and noticed that and a stray 'Makefile' <efraim>already took care of the Makefile <nckx>☝ warning: content-length: 20552684 <rvgn>nckx LoL. What about bleachbit? <cap>g_bor[m]: Nice to hear! :D <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. <rvgn>nckx Unnessary files getting clogged there bug me. :P <nckx>rvgn: I sympathise completely. I clean out those directories once in a while when I find time. I don't know of any automated solutions; they'd be based on heuristics anyway. <nckx>I often want to keep settings. <efraim>the only thing in my .guix-profile/lib/systemd is an emacs service <str1ngs>yeah as of 26.1 I thin emacs has been distributing that service file. IIRC <nckx>I have only a user/thunar.service. <nckx>emacs --version: emacsclient 26.2 <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 <jackhill>efraim: cool. I guess my main goal is just to compile some latex documents. What is the recommended way? <efraim>jackhill: sorry, for that I'm not sure, I think there's some minimal one, but if that doesn't work the full one should be able to handle anything <jackhill>efraim: no worries. With Guix it is easy enough to switch later without leaving cruft around ☺ <efraim>whats the difference between a deprecated package and a superceeded one? <efraim>oh, nevermind, I just checked guix/packages.scm <efraim>perl-base and perl-parent are both marked by guix-refresh --recursive as absorbed by perl core, but I can't find an announcement upstream <rekado_>jackhill: if you know what LaTeX packages you need you just need to install them into your profile. <rekado_>jackhill: things should just work then as we have a profile hook that generates the TeX Live configuration. <rekado_>you may find, though, that not all packages you need are available yet. <xavierm02>operating-system-firmware is not exported -.- ***jonsger1 is now known as jonsger
<rvgn>nckx Are librem devices compatible with guix ? That is, do their wifi etc support? <rvgn>rekado_ Thanks for the info. Did you try to remove any blobs after buying the product? <pkill9>has anyone fixed the issue with jack not running even though pam limits are set that allow realtime priority? <nckx>rvgn: Like you, I use a ThinkPad, not a Librem. <nckx>Guix should support all of them though, unless they lie about being free. <rvgn>nckx Don't they actually lie though? <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>s/microcode/proprietary &/ <nckx>Microcode itself isn't evilz. <OriansJ>plus the libresilicon project hasn't gotten past the 1micrometer node yet <rvgn>I see. But RYF certified devices comes with microcode removed right? <nckx>rvgn: You can't remove microcode. It's the ‘code’ that ‘runs’ your CPU. It's dead without it. <OriansJ>they just have no ability to modify the microcode thus it is treated as a hardware circuit <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) <rvgn>OriansJ I am gonna check out system76 <nckx>rvgn: I'm 93% sure the IME in recent Librems has been ‘neutralised’, you can't remove all of it or (sound familiar?) your CPU won't boot or will power off after n minutes. <Marlin[m]>using black and wood is just too much for my heart <OriansJ>nckx: essentially the Intel Management Engine has only gotten worse and more aggressive over time <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. <OriansJ>Marlin[m]: good if you have the budget and are willing to deal with compatiblity issues caused by PowerPC <Marlin[m]>Anybody knows how the bugfixing for linux libre refusing to load firmware going? *nckx drew the line at an X230 with me-cleaner. There's a line for everyone. <nckx>Marlin[m]: #linux-libre might be able to help you further, but AFAIK it's not been addressed… <Marlin[m]>i think they are trying to fix it, i think i saw something about it <nckx>Sure, but I don't know how actively that trying is. <Marlin[m]>running tux for 1 blob is annoying, i'd rather stick with freedo <nckx>Marlin[m]: Guix is slowly being ported to Power9, so that's nice. <OriansJ>well we as a community are always active in trying to expand user freedom, we however are competing against very aggressive market forces working in the opposite direction. <Marlin[m]>i hope i can get the firmware hacked if i study about reverse engineering <Marlin[m]>getting an affordable, but powerful model like the rx580 hacked to run libre would be wondeful <OriansJ>Marlin[m]: that is why we need more people to do the hard work for others that can't *rvgn gonna stick with RYF certified devices as they come with de-blobbed libreboot. <Marlin[m]>So it should be easier than the shitload of work nouveau has with nvidia <OriansJ>rvgn: thank you for choosing to financially support organizations that work to supporting user freedom <Marlin[m]>stallman told me he can present people who are also hacking gpus when i feel like i'm ready to start <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. *rvgn is envisioning Free Hardware Foundation (FHF). <OriansJ>it makes more impressive headlines when you kick the shit out of the problem you are working on <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 <rekado_>yeah, it’s not so much about available time in my experience, but about planning a route. <Marlin[m]>so at least trying to work on useful stuff for the community makes me feel great <rekado_>I worked on a DSP for which no free toolchain exists, but it had a datasheet. <rekado_>I tried to figure out how it boots and how I can trick it into loading a different binary. <rekado_>with GPUs you often don’t even *have* documentation, so a good first step is to gather information. <rekado_>if you publish your findings regularly this may help others in picking up your work should you lose interest or run into problems that go beyond your understanding. <Marlin[m]>wonder if some day we'll have a magical decompiler that takes any binary and reverts into perfect source code :P <rekado_>for the DSP I wrote a disassembler, but it only worked because the opcode format was documented in the datasheet. *nckx updates the important xcalc package and goes → 😴. Good night.