IRC channel logs
2024-04-18.log
back to list of logs
<lechner->sham1 / podiki / you have more than 11 million entries in a single store folder? <Kolev>gnucode: You run GNU/Hurd on hardware?! <podiki>lechner-: i don't remember exactly (and we've had some optimizations in guix since then), but I think /gnu/store/.links was extremely large for me and so i needed large_dir <lechner->my server is so hosed file name component is not a directory "/var/run/dbus" <futurile>Q: is there a clever command to try and build ALL the packages - I'm looking at core-updates and guess the only way to understand where we're at is to try and build the whole thing <lechner->that /var/run/ reference is not the guix i pulled, so i am not running what I think I'm running <freakingpenguin>futurile: You could try making a manifest w/ every package, using (all-packages) in (gnu ci) as a starting point. <freakingpenguin>I think (fold-packages (lambda (pkg result) (cons pkg result)) '() #:select? (const #t)) would get you a list of every known package. Not sure if it'll go nicely in a manifest without yelling. <jab>geez....guix shell -D --pure --check guix <jab>That's at least two hours! <jab>Kolev: thanks. The walk was fun! We found a solar system model. it was HUGE! <jab>Kolev: yes I run the Hurd on real hardware <gnucode>This is me running the Hurd on real hardware. <Kolev>jab: Can Hurd run on an X60s? <Kolev>gnucode: I would prefer if your code snippets had a lighter background. <gnucode>the blog that I use supports that, but I haven't figured out how to do it... <gnucode>I've even had the developer of haunt try to give me some pointers... <gnucode>and yes I believe that the Hurd can run on X60s. <gnucode>don't quote me on that though. It's best to ask bug-hurd@gnu.org <Kolev>gnucode: Do I have to use Debian to use Hurd, or can I use Guix? <gnucode>The T43 is a nice playground for me...I think it cost me about $50-75. The Hurd is currently stuck on 32 bit for the moment. The 64-bit port is REALLY close, but is not super stable yet. (An ARM port is actually making progress too). Basically I want to bug a 64 bit laptop with at least 8GB of RAM and run the Hurd on that. <gnucode>Kolev: use Debian GNU/Hurd at the moment...if you want to run the Hurd on real hardware. <gnucode>Guix has not packages X for the Hurd. (correct me if I'm wrong somebody). <Kolev>gnucode: I see. Well, Guix System on Hurd would be awesome for my 32-bit machine. <gnucode>Debian GNU/Hurd mostly works. Xfce works. 75% of the Debian packages work on Debian GNU/Hurd. <Kolev>gnucode: And I'm guessing Debian GNU/Hurd has been neglected, and I'll need to use your guide to get it running? <gnucode>Kolev: Guix System on the Hurd (on bare metal) doesn't currently support networking... <Kolev>GNUtoo: All I need is Emacs and a terminal, and maybe an image viewer. <gnucode>Hurd Guix System works great in a vm. <gnucode>Ask around. Only 1-5 guix developers run Hurd Guix system on bare metal. <Kolev>gnucode: So that's why your blog post was written on GNU but edited on GNU/Linux. <gnucode>Kolev: I wrote the blog post on the Hurd yes. Haunt is not packaged for Debian. <gnucode>I tried to install haunt from source on Debian....but I could not quite get it to work. <Kolev>gnucode: Debian has a guix package. <gnucode>I am talking to you right now from my Debian GNU/Hurd running on bare metal. <Kolev>gnucode: How do you use GNU when it doesn't have networking? <Kolev>gnucode: I thought GNU didn't have networking. <gnucode>If you really want to talk about it, I can throw up a jitsi meeting. <Kolev>gnucode: I'm about to have dinner; I can't have a conference right now, haha. <wakyct>hi guix, is there a way to run guix size and show what deps I already have installed for a given package? <gnucode>My T43 Debian GNU/Hurd that I run on bare metal...run emacs, pdf viewer, and I can read and write email. <Kolev>gnucode: So there is indeed networking. Ethernet only? <gnucode>Yes. Debian GNU/Hurd running on bare metal supports ethernet only. <gnucode>I think it is the T43, T60, and a couple other laptops that are known to work. <Kolev>wakyct: So it's Guix System on Hurd that does not support networking? <gnucode>but the Debian installer is a bit wonky. <wakyct>oh interesting, do you think an x41 might work? <gnucode>it works, but it throws weird warnings that make you think it is failing. <gnucode>Guix System on Hurd running bare metal does not support networking (last I heard). <Kolev>Now I really want to get my X60s's fan and thermal paste repalced, so I can run Hurd. <gnucode>wakyct: I don't actually know if the x41 will work. <gnucode>I edit the hurd wiki, so I really should put a spot on there that explains which machines are known to work. <wakyct>I think I might still have 32bit Guix on my x41, I haven't booted it in a while <Kolev>gnucode: I will try Debian GNU/Hurd on my X60s, when the fan and thermal paste replaced. <gnucode>wakyct: do you like plan9? I've heard that the filesystem occassionally crashes? <wakyct>I do like it, I never had issues but I didn't use it in agner <gnucode>Kolev: please do email bug-hurd@gnu.org when you try to install it. You will probably run into some issues. :( But it should work. <wakyct>getting it to pxe boot was about the extent of my use of it <freakingpenguin>gnucode: Regarding blog code blocks readability, are you able to give the pre element the background: <insert_color> element? That should solve it. <gnucode>freakingpenguin: yes I can change the css background color of code blocks to a lighter color if you think that would help <freakingpenguin>Up to you! :) I just was playing around with the browser's element picker, black on dark gray is hard for me to read. <gnucode>if I could get the silly code blocks to syntax highlight it would look a lot better! <gnucode>freakingpenguin: all of my blog posts are written in commonmark. <Kolev>gnucode: Yes, lighter color background on code blocks would help. <Kolev>freakingpenguin: Unfortunately, I recently switched from Haunt to kiln, because Haunt currently does not generate Gemini capsules. <Kolev>Adding support for gemtext to Haunt would be great. <Kolev>gnucode: Does your blog have a feed? <gnucode>maybe my blog doesn't have a feed...I thought I had one. whoops. <gnucode>I'm surprized mine doesn't have one. <Kolev>gnucode: Haunt blogs have a feed by default, I thought. <gnucode>Kolev: they do. I must be doing something wrong. <gnucode>woo hooo! 'guix shell --pure --check -D guix' worked! <gnucode>./configure failed....because "git" was not installed. <Kolev>gnucode: Are you saying my repo needs git in the manifest? <gnucode>Kolev: no. I'm trying to build guix from source on my linode server. <gnucode>and the ./configure step failed because i do not have git installed. <gnucode>it took me 4 plus hours just to get 'guix shell --pure --check -D guix' to complete... <gnucode>guix deploy to my server has stopped working for a while. <gnucode>my server is is running an outdated guix server. <bdju>is there a reason the guix package of yt-dlp doesn't seem to get updated anymore? it used to stay up-to-date very well <bdju>I'm on 2023.10.07 now and there's been 6 releases since then, the latest being 2024.04.09 <gnucode>hmmm, bdju patches are always welcome! :) <gnucode>Probably no one took the time to update it. <gnucode>also fun fact of the day, I am building guix from source... <gnucode>and I am seeing mes-boot, and tcc-boot. <gnucode>I didn't realize that building guix from source...built it from hex0 and M2 planet. <gnucode>podiki: yeah. I figured that I would have some substitutes though. <gnucode>I definitely have substititues working though...why would I have build everything from source? <gnucode>it is currently building binutils-mesboot0 <gnucode>is there not a substitue available for that? <podiki>What arch? And on a relatively recent commit? <gnucode>I should also really try to get offloading working. <gnucode>I can give you the config.scm if you're really interested. <podiki>Yes you should have substitutes assuming they are enabled <podiki>What does guix weather hello return, for example? <gnucode>I always felt like guix weather took a long time to return... <podiki>It shouldn't... Seems something is up <gnucode>./pre-inst-env guix weather I'm still waiting for it to return <podiki>Have you made modifications in your local checkout? What's the reason for using that over regular guix? <gnucode>so basically I am trying to update my guix system server for gnucode.me, which is currently stuck at August 2023 <gnucode>that was the last time it was updated. <gnucode>guix deploy doesn't seem to update it. <gnucode>then I tried updating gnucode.me via guix pull <gnucode>that failed. Probably because my server only has 1 GB of RAM and guix has a soft memory requirement of 2GB. <gnucode>Since guix pull seems determined not to work, then I figured that I would just update guix from source. <gnucode>it is currently trying to look at substitutes on bordeaux.guix.gnu.org <podiki>i don't see how going from a local guix will change this, but maybe i'm missing something <podiki>i would think guix deploy is what you want, but i'm not familiar with it <podiki>anyway, gotta run, good luck and i'm sure someone here in busier times can help <gnucode>podiki: lechner- is having the same problem. <gnucode>ok...it seems that guix pull might be working...on the server...maybe. <daviwil>any advantages to using btrfs over ext4 in a fresh Guix install? <daviwil>snapshots/rollbacks aren't quite as interesting when using Guix I suppose <gnucode>daviwil: I personally use ext4, because I had trouble setting up full disk encryption with btrfs on guix system. <gnucode>daviwil: are you going to try out bcachefs as soon as guix supports it in (operating-system (file-systems ...? <gnucode>oh really? It's trying to be the next greatest linux filesystem. <gnucode>Kent overstreet has been working on turning bcache (a linux kernel feature) into bcachefs for the last 10 yars pretty much on his own. <gnucode>it just finally got merged into Linux like 3 or 4 months ago. <Kolev>I would like to use btrfs but I'm not good at manual installs. <gnucode>Kolev: I do like the guix graphical installer. I don't think I could figure how to do encrypted drives without the graphical installer. <gnucode>also it's getting pretty late here. I'm no closer to updating my linode server, so it's time for me to go to bed. <adanska>whats the difference of specifying the `channels` field and using the `guix-for-channels` procedure in the `guix` field for the `guix-service-type`? shoud i do both like the manual says? or is it okay to just specify `channels`? <axioms>Hello, I am curious about the state of risc-v in guix. Has anyone got any experience or information on the Milk-V Pioneer? Would it be able to run guix? I don't know what the driver/firmware situation is as far as blobs or open source firmware are concerned <axioms>I've been looking for x86 alternatives to running guix, so far the most libre options I've come across are the Raptor Computing Talos and Blackbird IBM Power9 computers, or the new risc-v computers that are being released <Guest50>Hello. I am trying to generate some gif file with a python script in a guix shell -CF and it fails with the following error message that, I think, comes from the drivers not being found. The error is <Guest50>MESA-LOADER: failed to retrieve device information <Guest50>MESA-LOADER: failed to open i915: /gnu/store/cm7k3vgvmhq1cjcx1dd1wamyq2br2x23-mesa-23.3.2/lib/dri/i915_dri.so: cannot open shared object file: No such file or directory (search paths /gnu/store/cm7k3vgvmhq1cjcx1dd1wamyq2br2x23-mesa-23.3.2/lib/dri, suffix _dri) <Guest50>failed to open /dev/dri/card0: No such file or directory <dariqq>is it possible to say that a shepherd service conflicts with another one? <attila_lendvai>dariqq, conflict in which way? there are countless ways that two services can step on each other's feet... <dariqq>i am working on a service for the power-profiles-daemon. and it seems to be incompatible with other pm-services like tlp, etc <attila_lendvai>dariqq, oh, i see. so, you're looking for a way to formally record incompatibilities in the description of the service. i'm not aware of that. <dariqq>attila_lendvai: Thanks. Guess i'll ignore that problem for now. The whole thing feels like a bit of a hack as the systemd service is meant to be started via dbus but i get no problems just starting a shepherd service directly. <janneke>after running `guix pull', i hoped to `guild compile' the new definition of my laptop os to which i added the new guix-home-service-type, but i get <janneke>home-service.scm:8:11: warning: possibly unbound variable `guix-home-service-type' <janneke>it only works when using latest guix master and do ./pre-inst-env guild compile ... <janneke>what am i missing, (how) should i set GUILE_LOAD_* paths? <attila_lendvai>janneke, maybe you first need a guix system reconfigure to get the new guix, and only then add the home service related stuff to your config? <janneke>attila_lendvai: i'm sure that works, i don't want to do that <janneke>i'd like for guix's modules to be available to guile after a guix pull <janneke>sham1: i tried some time-machine curses, but if `guix' is included it will be the previous version guix-1.4.0-18.4c94b9e, not the version of the commit <janneke>ACTION might have to change their expectations... <dthompson>anyone up to date on the state of python stuff in guix around? we currently package 3.10 but 3.12 is the latest. curious if there's an upgrade planned or ongoing in core-updates or something <rekado>there's a python-team branch with WIP, but it doesn't touch the default Python version yet <dthompson>I want to use Blender 4.1, but it needs Python >= 3.11. guess I'll just keep my own local set of packages for the time being and try to remember to keep an eye on python updates <jakef>does anyone know how to get python's matplotlib to plot with TkAgg backend? <jakef>i've only got tornado / WebAgg to work <jakef>so it works if i use matplotlib.use("TkAgg") in the python script, but using export MPLBACKEND=TkAgg before calling the script doesn't work <lechner->Hi, is there a way to invoke 'sudo' for a system reconfigure from inside ./pre-inst-env from Git? <cbaines>lechner-, do you mean like sudo -E ./pre-inst-env guix system reconfigure ... <podiki>quick heads up: if we are going to push core-updates through, probably helpful to get berlin building "all" rather than "core" for that branch <podiki>(not sure if it is ready for that, but at some point we will need that) <cancername>Hello! I'd like to make a bootable system with "guix system image". I've tried the example from the manual: https://pastebin.com/ppRauAtW , however, that doesn't produce a system that will boot, and drops me into an emergency GRUB prompt. Could anyone share an example with me that I can base my image off? That would be appreciated :) <cbaines>cancername, I'm not sure how an example would help, it sounds like the image you made did start to boot and got as far as grub <apteryx>interesting, I'm newly getting makefile warnings <apteryx>such as Makefile:7400: avertissement : surchargement de la recette pour la cible « doc/stamp-vti » <cbaines>you should probably look at why it didn't get any further <cbaines>apteryx, I noticed those too: Makefile:7399: warning: overriding recipe for target 'doc/stamp-vti' <apteryx>I wonder what changed; it's not GNU Make <cancername>thanks, cbaines. I think it wasn't able to detect the file systems on the drive I flashed it on. I used "-t efi-raw", is that right? were you able to spot any obvious issues in the pastebin link? <apteryx>civodul: is (define-public gnurl (deprecated-package "gnurl" curl)) supposed to allow me to do './pre-inst-env guix show gnurl' ? <cbaines>podiki, I've gone ahead and changed that now as it sounds like people are interested in seeing CI at least attempt to build more of core-updates <cbaines>I've also enabled aarch64-linux and powerpc64le-linux in the systems <podiki>Great thanks! Hopefully that will make it easier to get some hands on <dariqq>it seems like mesa-opencl is failing to build (due to spirv-llvm-translator) after mesa updates got merged <cancername>Hey cbaines, I get "reboot and select proper boot device or insert a selected boot device and press a key" when booting this config: <https://pastebin.com/cPXpnY6B>. I've selected the correct device in my BIOS menu, which is also the only connected one. Could you help me learn why this is? <cbaines>cancername, that doesn't sound like grub. Are you now not able to get to grub, or is this the error you had previously? <cancername>When I search the web for this error, many recommendations come up, but none of them go into detail other than "missing bootloader" or similar <wakyct>hi guix, does anyone happen to know why Guix's Mousepad editor package doesn't seem to have plugin support? All the versions look up to date but I'm not familiar enough with it to see what's missing <vagrantc>cancername: is "secure boot" enabled? my guess is guix does not have signed bootloader from the evil empire. <cancername>vagrantc: seems like it's enabled, but the option in my BIOS is gr[ae]yed out and I don't see an option to disable it <cancername>consulting my mainboard manual now, will be back <cbaines>is it one of them that you're looking for? <wakyct>not any in particular, but I noticed there's no plugins tab in Edit->Preferences...perhaps that's left out if there's no plugins installed? I dunno <wakyct>thanks for that link, very helpful. <erikeah>Hi everyone! Today I have reconfigured my system and I found my self without my channels.scm, instead I got a new channels.scm pointing to a derivation on the store. This is caused by any change on guix system/ <cancername>disabling secure boot had no effect... trying MBR now <ieure>cancername, MBR really shouldn't be used unless you're on a computer that was made before, like, 2009. <cancername>ieure: I know, I'm just trying to figure out if the root cause is in some way related to UEFI. <cancername>I've posted the config I'm using above, perhaps you can see what's wrong with it? <ieure>cancername, It's installing the bootloader on a USB device, is that what you expect? /dev/disk/by-id/usb-Intenso_Ultra_Line_16090900000908-0:0 <ieure>I would expect it to install on an internal block device, not a USB-attached one. <cancername>It's the same device I'm booting from on the other machine. <cancername>By the way, that bootloader is installed while running "guix system image", right? <futurile>erikeah: there was something about this the other day I believe - you might find it in the backscroll - sorry I sound so vague <cancername>That seems like a footgun, since I'm "dd" ing that image onto the device after guix system image has already finished running <cancername>(and in fact, the device didn't even exist when I ran "guix system image") <ieure>cancername, Well, that'd be an issue with Grub after the machine loads it, and you're not getting to that point. <cancername>Wait, does "guix image" need any additional configuration, or can I just run it with what's in the pastebin? <erikeah>futurile: I think is a breaking change, operating system has an eleement to define channels <erikeah>But thanks, I will try to find the conversation <cancername>ACTION just wrote their first system scheme file with any deeper understaning of what anything does and is hoping for it to work <lechner->Hi, does anyone have folder named /var/run/dbus, or is it a symbolic link to /run/dbus? <sham1>Alright, so on one side, booting with /gnu/store as its own partition is totally possible. But on the other hand, apparently xfs doesn't like "defaults" as a mount option. So gotta rebuild the entire system again <sham1>Oh well, I at least vindicated myself from last night <cancername>( "mount --bind /path/to/your/var/guix /var/guix && mount --bind /path/to/your/gnu /gnu") <cancername>aaaaaaaaaaand when I boot the screen remains blank :/ <cbaines>vagrantc, QA is has rebased things post mesa-updates merge, so it's more behind than it was a few days ago <cancername>I guess I just killed my USB stick by bending it a bit too hard, awesome. <lechner->Hi, has anyone had any activation problems with "file name component is not a directory "/var/run/dbus""? <sham1>vagrantc: oh, once I get this working, I'll be sure to have loads of fun. It'll be one step closer to realising my personal ideal Guix setup <sham1>Someone else had already done the hard part of making it so that / can be tmpfs <cancername>that seems concerning for basically every program 🤨 <sham1>You explicitly mark what you want persisted <vagrantc>remember to not use the tmpfs defaults, which permit world-writeability :) <ieure>cancername, When I need to work with GPG keys, I boot Tails off a write-protected SD card on a machine with no HDD, so I know the keys cannot possibly go anywhere other than where I put them. <ieure>Probably overly paranoid there! But, it's nice to know absolutely 100% for certain that's the case. <ieure>Recently picked up a Ziploc full of older USB sticks -- going to check them out in the same way. <ieure>And I just removed the WiFi allowlist and unlocked the advanced BIOS on that machine (ThinkPad T440p), so I could even restore the BIOS in the exceedingly unlikely event that one of them was nasty enough to stash something there. <ieure>Too bad the T440p removed the physical WiFi killswitch. <cancername>intel ME and the UEFI network stack on its way to ruin your evil plan: <vagrantc>oh fun! guix system: error: profile contains conflicting entries for nss-certs <ieure>cancername, I haven't neutered the IME on that box... yet. Just have to dismantle it enough to get my programmer clip onto the SPI. <cancername>I need to get one of those... I've been learning to (de)solder but I suck at it, mostly because I lack a proper soldering iron and my hands are very jittery <ieure>cancername, The whole programmer was like $10. I haven't gotten mad enough to try hooking it up to my Data I/O Unisite, but it probably supports the part. <ieure>UniSite was the industry standard device programmer from the mid-80s up to 2003, when they ended support. Really terrific system. They were like $30k new, I got mine at a surplus place for $50. <ieure>Bought two others, refurbed them and sold for $150 each, which is still a great price. <ieure>Yeah, have well over $100k-if-I-bought-everything-new-at-the-time of equipment on my workbench. <cancername>what the hell? the message "no such device: Guix_image found" is flashing extremely rapidly on my monitor <Guest36>Since I now have a NAS, what do you use for creating backups of files on the GNU Guix system? <fnat>Guest36: BorgBackup, borgmatic, and restic are popular backup solutions, I think. <fnat>I have direct experience with BorgBackup and borgmatic - that have been working very well for me. <pret7>any reviewers around? I sent in a patch adding pass-import a couple <pret7> keepass -> pass a couple times <Guest36>fnat: Do you backup to a drive or nfs share, since I wonder how I can auto mount a nfs share <pret7>how on earth did I miss that <jab>well I am still trying to update my guix server... <jab>guix pull is currently trying to build glibc-mesboot0, which seems odd. <Guest36>that is for bootsstrapping mes, though I never needed to build that <Guest36>do you have substitutes enabled? could also be because someone sent commits and CI did not yet caught up <voroskoi>ekaitz: Do You work on updating zig for guix? I remember some build errors, but do not remember if You ware able to solve those or not. <sham1>noatime and such belong in flags, not options <sham1>...Should have read through the docs more carefully <sham1>Good thing the install is unattended... <ekaitz>voroskoi: hi! i was working on that but we have other kind of problems <ekaitz>voroskoi: zig has a bootstrapping problem that makes newer versions non-packageable in guix <ekaitz>the thing is zig added some wasm blob to the codebase for the bootstrap and we can't use that in guix, as we don't accept binary blobs <cancername>though, shouldn't you be able to use the C backend? <sham1>I thought they removed the C backend <ekaitz>but now they are doing some other process <ekaitz>all the info i have about this is they had a double implementation of zig, one in C++ and the other in Zig <cancername>yes, now we just use wasm to bootstrap the zig compiler <sham1>Can't really use the wasm since it's a binary that's not bootstrappable on its own <ekaitz>exactly the wasm file is not acceptable for guix <sham1>I really don't get why all of these more "modern" languages are built like this, where bootstrapping is just terrible <ekaitz>so the only way we have is to use older versions of zig to bootstrap newer versions of zig <cancername>sham1: I don't understand what the issue is with the WASM? <ekaitz>we need to track them down in the git history and find them by hand <ekaitz>cancername: the wasm file is a binary <sham1>The same problem as using any precompiled binary <cancername>it is auditable, since it's built from zig source code <sham1>I'd say it's more unfortunate to zig to be honest <sham1>How do we know whether the WASM binary is what comes out of the zig source? How would we prevent the "trust on trust" supply-chain attack? <ekaitz>cancername: is it auditable? to what extent? <ekaitz>you are forcing us to rebuild it and compare? <sham1>You can build the WASM binary yourself, with the WASM binary <sham1>That's a circular dependance <cancername>get a version of the Zig compiler and build the WASM binary, if necessary, an older one <ekaitz>cancername: in that case, where does that end? in the very beginning <ekaitz>cancername: take in account i'm one of the people working on Guix bootstrapping process <sham1>*insert Carl Sagan quote about apple pies and inventing the universe* <ekaitz>let's make this easy: if you have a clear route of versions from 0.10 onwards until we reach the current zig: open an issue mentioning them and I'll package it myself <ekaitz>but! no binaries are acceptable in the chain <cancername>if I am able to find that route, I will make an issue, thanks <ekaitz>it should be, but it's not obvious <sham1>But yeah, so many other language ecosystems also do this similar sort of annoying stuff. For example I do stuff in the JVM world. The bootstrap process for the JVM seems already like a rabbit hole and a half, and then there's the tooling. At least maven can be properly bootstrap... <ekaitz>cancername: if you open an issue please CC me (my email is in the guix repo in several places) <ekaitz>C is a pain in the balls to bootstrap (i'm doing it right now) <sham1>Although at least Mes exists <sham1>So you bootstrap to a scheme to a C compiler with Mes, you compile tinycc and then you end up with a similar bootstrapping problem with gcc since modern GCC requires C++, so you find the last non-C++ GCC and then build that, and then bootstrap the C++ and then slowly build up to modern GCC <vagrantc>or maybe i should have just submitted them as separate issues? although seems best if they would get merged more-or-less at the same time. <jab>ekaitz: C is a pain to bootstrap? Really? I thought it was one of the "easier" things to bootstrap. <vagrantc>cbaines: how can i convince it otherwise? :) <cbaines>vagrantc, using git sent-email usually works if you didn't <ekaitz>jab: if you want to start from source it is really complex ->mes->tcc->tcc->binutils->make->patch->gzip->gcc <ekaitz>also, i'm working in the riscv bootstrap, which is even worse because the architecture was invented after some of the compilers we use in the middle were written <sham1>I wonder just in the abstract whether it'd make sense to have the bootstrap seeds go to some kind of a F <jab>ekaitz: what riscv boards are you playing with? <sham1>And from there scheme -> C via some other stuff <cancername>okay, so no, the wasm gets translated to c and that gets compiled with a c compiler <vagrantc>sham1: this comes up ... all it takes is someone to do it :) <sham1>vagrantc: that's what I thought :P <cancername>translating the zig source to wasm to c is pretty much the same as translating the zig source to c, no? <vagrantc>sham1: it is also useful to take multiple paths to get to the same place ... though this is perhaps more appropriate for #bootstrappable <ekaitz>cancername: good question... zig has a wasm backed though <cancername>yes, it does have a wasm backend, as well as a C backend <cancername>from "bootstrap.c": cc, "-o", "zig-wasm2c", "stage1/wasm2c.c", "-O2", "-std=c99". and "./zig-wasm2c", "stage1/zig1.wasm", "zig1.c". <cancername>so yeah, let's see what it takes to generate that wasm <vagrantc>cbaines: thanks, seems to be seeing the patches as a series now! <sham1>Once the WASM can be generated then it should be fine, I'd imagine <cancername>it /should/ be possible to generate the wasm for incremental zig versions with zig 0.11.1 (which includes and builds with stage1), then finally compile the most recent wasm to c and use that as zig1. what a waste of time. <cancername>then we agree, and a package should use the wasm, since its provenance is clear <cancername>🤔 how, exactly, when the wasm can be reproduced with successive versions of the zig compiler <sham1>You'd think that with the Jia Tan incident, the difference would be clear <cancername>the jia tan backdoor did not rely on bootstrapping to work :P <sham1>It needs to be bootstrappable from the sources as they are. Period. <cancername>it is bootstrappable from the sources as they are, but why would you ever bother doing that <sham1>Because... that's the entire point of Guix? <lispmacs[work]>hi, where are the templates for .profile, .bash_profile, and .bashrc for a new user on Guix system? (using a regular guix profile, not guix home). I messed mine up and am having some issues with logins and paths <ekaitz>cancername: also, you are free to package stuff for yourself using binaries <ekaitz>in fact, i have zig-0.11 packaged if you want to reuse it <ekaitz>in any case, guix is a source distribution, and it doesn't provide binaries <cancername>bear with me as I am new to guix, but unless I am misunderstanding something, fixed-output derivations should allow for this kind of thing where the hash of the data is verified but not everything is rebuilt. right <janneke>but philosophically you're still building `from source' <cancername>so, a maintainer can bootstrap zig from source the slow way, verifying that `zig1.wasm` matches upstream, and use that hash to verify the upstream package, right <cancername>so that a user will not have to rebuild everything the slow way <jlicht>sure, but at that point, just have the default be building from source, and provide substitutes for the leaf-packages (e.g. zig@current-version) <cancername>I don't understand, one has to trust the guix maintainers either way, right <cancername>🤔 what's stopping guix maintainers from including a malicious repository in one of the packages <ekaitz>cancername: the fact that you can download the sources of the package yourself and check the hashes and all <janneke>if the maintainer can do it, they should encode their recipe in guix packages so that everyone can follow the same path if they like <ekaitz>in the end, here we are enabling being a paranoid and not trusting anyone <ekaitz>in zig i have to trust the wasm came from X place <ekaitz>and they don't let me be a paranoid about it easily <cancername>well, no, with the proposed system you wouldn't since the hash would change, right <janneke>it's a good practice to encode your recipes in guix packages anyway; it's one of the best ways to convince yourself you didn't fool yourself <cancername>okay, good, so the recipe is encoded in guix packages and the source and binary builds are verified against the same hash, right <cancername>what's the purpose of making the inconvenient slow source build the default here, then? <sham1>It's not like you'd have to do the inconvenient slow build as a user, substitutions exist for a reason <ieure>It asks you if you want them when you install GuixSD; not sure about on foreign distros. <sham1>Foreign distros also ask you <ieure>One side of this is trust -- since Guix builds everything from source, you can validate the chain of trust all the way back to the original developers. <ieure>The other is bootstrapping, most other distros require that you already have a working Linux that you got from... somewhere... in order to do anything, which opens you to a trusting-trust attack. Since you can build Guix 100% from source, you can validate that this isn't happening. <sham1>One of the point of this reproducibility is that you can be sure that the substitutions you download from the server are the same as what you'd get if you would build from source. In fact, this is exactly what guix challenge does. It builds a package and compares it to whatever the substitution server gives you <sham1>So you can verify that the build is, in fact, byte-for-byte identical <sham1>So then for a supply-chain attack, either a Guix developer could include malicious stuff into the package derivation, and assuming the challenge succeeds, the attack would have to be somehow visible in the package definition because otherwise substitution wouldn't match the from-source thing <cancername>guix maintainers can also change the from-source thing, right <sham1>Yes, but those changes are those "visible in the package definition" things <sham1>Another one is the Jia Tan approach where the malicious code is actually upstream, but since everything in Guix is from-source, you know that if there's an attack, it's coming from upstream <sham1>Assuming that the maintainer isn't being malicious <cancername>to be fair the Jia Tan backdoor shouldn't have been in Guix in the first place since that was in the tarball <vagrantc>guix builds some packages from upstream tarballs ... <cancername>vagrantc: that doesn't sound very "from source" to me <sham1>Although I suppose that this specific attack wouldn't have worked on Guix anyway since IIRC it very specifically relied on sshd linking libsystemd <cancername>after all, many tarballs include "configure", which is a binary filw <sham1>Upstream source tarballs are still, well, source <sham1>And yeah, ./configure might as well be binary although it is technically just shell. Of course, a distro can just choose to ignore the provided autoconf files and regenerate them <vagrantc>sham1: regenerating wouldn't have prevented against the xz attack <vagrantc>fortunately for guix, it was slow to even update to the potentially compromised versions :) <cancername>guix should do that, from the git source ideally <vagrantc>cancername: then you shift vulnerabilities into a more complicated git process <vagrantc>i suspect there are even more attack surface in git than in a tarball <cancername>not really, since git commits are immediately suspicious <cancername>"configure" (m4sh -> shell) is binary in the same way that "zig1.wasm.c" (zig -> wasm -> c) is <cancername>vagrantc: this isn't really about bugs and they are not relevant here <cancername>there is a reason jia tan didn't commit the malicious code to git directly <vagrantc>not sure it would have actually made a difference <cancername>it might not have, but I'm sure we all agree a git commit is more suspicious than a tarball with no known history or provenance <vagrantc>plenty of vulnerabilities get committed to git ... it's not magic. <vagrantc>the fundamental problem is a lack of sufficient resources for full review, this is just one way it happened this time. <sham1>Sometimes even by the authors themselves even without trying to backdoor it as with xz-utils. Xscreensaver comes to mind wrt. Debian <cancername>you're right, but would you not be more suspicious of an additional git commit including malicious code than one line more in the configure script in the tarball? <janneke>yeah, one person's honest mistake, is onother's backdoor <vagrantc>cancername: most of the vulnerability was actually included in git history. it was just the final trigger that went in via the tarball <cancername>but I'm arguing that git is transparent and it is much easier to detect wrong git commits than it is to detect a wrong line in a configure script <sham1>A problem is that despite free software greatly benefiting from the idea of "many eyes make all problems shallow", the reality is that for the vast majority of stuff, there aren't all that many eyes <cancername>especially since configure scripts vary by autotools version and so on and so on <vagrantc>i will agree less auto* would be overall a good thing, as they are hard to audit. <yewscion>Hello all, when running guix as a package manager on a foreign distro, do I need to specify GUIX_PROFILE in my home configuration (or specifically source GUIX_PROFILE/etc/profile there)? <vagrantc>sham1: apparently there was just enough eyes on this one to catch it ... even if just a little bit late. <sham1>vagrantc: luckily. The next time we mightn't be so lucky... <cancername>vagrantc: that's not my point, auditing the m4sh source is perfectly fine -- the point is that tarballs include binary code that can be modified <sham1>Ideally (for some definition of ideal), build scripts would be either Guix or Nix package definitions <sham1>Would also probably force devs to care about reproducibility more <janneke>that's why some of us are working on reproducible source tarballs <yewscion>I have recently created a VPS running Slackware 15, and for some reason my user account (running the same home configuration I use on Guix) is simply not sourcing that file upon login, despite that being the behavior I've seen on other distributions. <vagrantc>yewscion: you might need to log out and log back in again for it to take effect <vagrantc>yewscion: but i think it installs something into /etc/profile* that should set up various guix variables <vagrantc>yewscion: /etc/profile.d/guix.sh ... i think? <yewscion>vagrantc: I have done so multiple times, and it seems not to have changed anything. If I manually source ~/.config/guix/current/etc/profile it works, however it seems as though GUIX_PROFILE is being set to ~/.guix-home/profile somehow, and this is not setting all of the variables from ~/.config/guix/current/etc/profile. <yelninei>anyone using a childhurd? How much ram do you recommend? I have it currently at 1GB but if I try to build something more complex it hangs at sending store items <yewscion>vagrantc: for some reason, that file has not been installed. <yewscion>vagrantc: Oh wait, yes it has. `/etc/profile.d/zzz-guix.sh` is there. <yewscion>vagrantc: It just wasn't marked as executable for some reason, which is expected in Slackware's init system. <yelninei>janneke: thanks I'll try inceasing the ram of the childhurd and the ram of the guix vm it is running in and see if that helps <sham1>It's still not booting which is just ridiculous <sham1>Who would have guessed that "defaults" isn't an actual mount option you can actually use <sham1>But at least now I can merely chroot into the thing and system reconfigure instead of system init. Progress! <jab>sham1: are you trying to run the Hurd? <sham1>No, I just chose EXT2 for my /boot filesystem because it's like the simplest UNIX filesystem I could think of for it which is also supported properly by both Linux and Gru <sham1>`mkfs.ext2 -T small` just to make absolutely sure that Grub doesn't break itself trying to boot <tricon>ACTION does the same as vagrantc. <sham1>Well I tried that yesterday. Didn't work <sham1>Because I guess Grub just gets confused by ext4 and/or I'm just unlucky <vagrantc>possibly the defaults for recent mkfs.ext4 have changed and introduced problems? <yelninei>giving the childhurd more ram solved the issue :) <sham1>That's probably it, which is why I opted for xfs everywhere other than /boot which is ext2 <vagrantc>what are these childhurds ... are they anything more than "just" a VM running hurd? <vagrantc>sham1: i can't speak for it personally, but btrfs is popular with some guix folk <sham1>Yeah, I've used btrfs with guix before, but I decided that after my hiatus I wanted to try a different sort of configuration, a more traditional one <sham1>I do btrfs basically everywhere <jab>sham1: I feel like /boot being ext2 is going be a mistake. :) Grub supports ext4. <jab>I wonder what issue you ran into earlier <sham1>It just claimed that it was an unknown filesystem. I don't know what to tell ya <sham1>Fully default options for mkfs.ext4 last night (well aside from -L, but if that breaks grub then I'd be surprised) <sham1>Well rather, it booted off of ext4 just fine, but it couldn't do / or /gnu/store on ext4 for whatever reason, which is why xfs <jab>sham1: how many partitions do you want? <jab>or do you want more? <jab>lechner-: did you fix your guix deploy issue? <jab>I'm about ready to submit a bug for guix for mine. <jab>just to help me clarify my thoughts. <jab>Kolev: I have been trying to change the background color to light grey on my blog's code snippets for 30+ minutes? Apparently tweaking things is harder than I thought. <sham1>I currently have 6 partitions. 4 filesystems, one BIOS Boot, and one swap. I have /, /boot, /home, and /gnu/store <yelninei>vagrantc: not really, except that offloading to it is also set up. And its fun to play around with it <jab>sham1: putting a partition in /gnu/store will cause you a lot of headache. <jab>at boot, grub tries to find the kernel, which is normally in /boot right? <jab>on guix the kernel is in /gnu/store <ieure>Missed opportunity to call it /gnu/safe <jab>I would not have a seperate parititon for /gnu/store . That just makes life really hard. <sham1>It looks for the kernel in the correct partition <jab>hmmm. that's interesting. <jab>I've got to get going soon. You might try to write a bug report. Just writing out the issues I am having normally helps me. 