<jackhill>Oh interesting I can't roll back now because that tries to rebuild the grub image. Since I don't need a grub image, I guess I could turn that off… <lfam>You can reboot and select a previous generation from the GRUB menu <nckx>Happy to explain the reasons some other time. *raghavgururajan popped some Zopiclone <kozo[m]>Hey, does anyone know specifically what kernel-argument I need to force the loading of amdgpu or mesa? Thank you <bone-baboon>I was using "linux-arguments" and that was not working but "kernel-arguments" does work with a system reconfigure. I was using "linux-arguments" because that is what is in the Guix manual. "kernel-arguments" is not mentioned in the bootloader configuration section of the Guix manual. <nckx>kozo[m]: mesa isn't a kernel module, so I'm going to ignore it. Linux loads drivers based on hardware; why would you need to force amdgpu to load? *nckx .oO wait, is that free software? <nckx>bone-baboon: Because it's not related to the boot loader. <nckx>Not sure how you ended up with ‘menu-entry’ in the first place. <kozo[m]>nckx: I have an AMD card in my machine and I have a display using i3. However, using lshw -c video, I get no specific driver shown "unclaimed" and ksmod list shows me that amdgpu is there but it's not being used by anything. <kozo[m]>I'm seeing a graphical display, I just don't know what driver it's using or how to switch it to amdgpu <nckx>Menu entries are for defining extra kernels to load, besides your operating system. Your operating system's kernel and kernel-arguments are both properties of that system, so they are top-level fields. <nckx>That's not a kernel module either. <kozo[m]>Then I must be going down the wrong path for this <nckx>If there's a separate kernel module called amdgpu, and it's listed in lsmod, it's loaded. It can't be loaded harder; that's the end of its story. <nckx>Note that lshw is a third-party tool. It's probably great, but it's still just a tool to aggregate some system information to post in forums etc. <nckx>Now I wish I could help you with the positive side of the answer but I've not owned AMD hardware for about a decade now. <nckx>Note that (at least!) some modern AMD cards *simply don't work* without blobs, end of. <rekado>I just tried a newly guix-pack-generated Docker image on AWS and it keeps complaining that /bin/sh does not exist. I created the image with ‘guix pack -f docker -S /bin=bin bash’. <nckx>kozo[m]: Which card do you have? <rekado>a much older image that was also generated with ‘guix pack’ works <rekado>the new image that fails on AWS does seem to work locally when run with ‘docker run’ <kozo[m]>nckx: I was so amazed when it loaded up from fresh guix boot using i3 <rekado>do you know what might have gone wrong? <rekado>I see that the old image has the manifest type ‘application/vnd.docker.distribution.manifest.v2+json’ <rekado>the new one claims to have the type ‘application/vnd.oci.image.manifest.v1+json’ <rekado>‘scanning’ the image for vulnerabilities also fails with ‘(UnsupportedImageError: The operating system and/or package manager are not supported.)’ <rekado>so … is there a way to generate the docker-specific manifest? <lfam>The image creation system was recently revamped. Maybe this is fallout from that <nckx>kozo[m]: lsmod's ‘Used by’ only shows dependencies between kernel modules; it's normal that amdgpu isn't used by any other modules. xf86-video-amdgpu is an X11 driver, that talks to the underlying amdgpu kernel driver. TL;DR: lsmod ‘Used by: <nothing>’ doesn't mean it's not used. 😉 <nckx>You can check /var/log/Xorg.N.log to figure out what Xorg detects and which drivers it decides to use. <nckx>It's chatty but should be easy to follow. <nckx>X may unload drivers after trying them, so keep reading. <bone-baboon>nckx: Thanks I just booted without having to manually add "nomodeset". <nckx>Now I really have to go. Good night, Guix. <rekado>lfam: perhaps. I just sent an email to guix-devel about this. Let’s see what comes of it. <kcurtet>Hi im trying to create my derivation of node but when i build the source i get this error: In procedure bytevector-u8-ref: Argument 2 out of range: 31 <bone-baboon>I am using an encrypted root partition. When I boot it immediately outputs: <bone-baboon>However this prompt is not respecting the keyboard layout from my config and instead is using a qwerty layout. <bone-baboon>Grub is also using a qwerty layout. I am not expecting this behavior as I have the keyboard layout in the bootloader section of the configuration. <bone-baboon>After grub this prompt works with my configured keyboard layout: "Enter passphrase for <partition>:" <bone-baboon>User login and the console terminal works with the configured keyboard layout. <vagrantc>bone-baboon: sounds like a bug worth reporting <vagrantc>not sure how to configure keyboard layout for grub specifically <vagrantc>seems odd to have to configure it separately... <bone-baboon>Looking at the bootloader configuration section of the Guix manual there is a keyboard-layout section. It has a note "This option is currently ignored by bootloaders other than `grub` and `grub-efi`. My config is using the bootloader `grub-efi-bootloader`. However it also ilsts the supported bootloaders and `grub-efi` is not listed. <lfam>I got it to work with other services, but not this one <lfam>I wonder if the difference is that this is a simple-service <lfam>Oh, I'll try modify-services <lfam>modify-services accepts a service type, but I'm not sure that applies in this case <lfam>Or, I don't know how to write it <lfam>The examples are not relevant <lle-bout>lfam: I think they are, in what group is that sysctl-service-type included? %base-services? <lfam>The service I'm trying to modify is a simple-service. I don't think I can refer t a type here <lfam>Yeah, I'm hoping that somebody else might have some ideas <lfam>I will try to make it work with modify-services <leoprikler>for simple-service you can do config => (match config ...) <lfam>I don't know Scheme well, so I don't know how to use match and can't really read things that use it <lfam>Alright, I have to go. If anyone solves it, I'll be reading the logs later <lle-bout>efraim: /gnu/store/73lipqvfpii2fn230xagm4111nc2gipa-coreutils-8.32.drv <lle-bout>efraim: trying again to see if it's deterministic <bone-baboon>If I run `sudo guix system --no-subsititutes reconfigure config.scm` and the config has just the base packages and services will this create a system where all the software of the current guneration has been built from source locally? I then plan to incrementally add more packages doing further reconfigures with no substitutes. The goal is to create a system that has been entirely built from source locally. <lle-bout>bone-baboon: you would need to entirely wipe the store first <lle-bout>to ensure no substitutes are used, you must not configure them at any moment <lle-bout>bone-baboon: substitutes, when downloaded, are kept in the store, and then there's no distinction between substitutes and store items, therefore, you must not download any of them in the first place to be sure there's none in the store. <bone-baboon>lle-bout: Is there a guix command to entirely wipe the store? If so would it leave the system in a state usable enough to run a system reconfigure? <bone-baboon>lle-bout: So there is no way to see what store items where built from source locally and what store items where downloaded as substitutes? <i1l>bone-baboon: you can just switch subs OFF, and wait for updates. one day all will be built locally. any user can pass --substitute-servers (or something) option to `guix` and override the default (both list of servers and "no"), if i remember right. <i1l>* updates are fairy frequent. was pain on aarch64 due to scarce subs. <lle-bout>bone-baboon: you can't wipe the store because it's currently being used <lle-bout>bone-baboon: your only way is to never configure substitutes and reinstall your system, a bit of a recovery operation, but with GNU Guix System it's rather easy *i1l Guix considered harmful due to STATEFUL store *i1l reduced Guix bootstrap: mesboot now manages store to reduce STATEFULNESS <lle-bout>bone-baboon: backup your home directory then reinstall without substitutes <lle-bout>reinstall using your current configuration (which should in combinaison with your /home directory give you the pretty much the same system) <i1l>but anyway some "binary seed" will be used.. just wait for updates, maaan. <i1l>user will need to first bootstrap an Free perfocard, and an Free CPU? <i1l>then use cosmic rays to copy compiled Source bootstrapped apps to non-free machine, and use same rays to check the sums (sha256)? <i1l>as user cannot believe to prop CPU. <i1l>cmon. i sure mr. bone-baboon will just waste electricity, basically. <i1l>another way if that was some university facilities. but PC and alike today? <lle-bout>i1l: Full Source Boostrap is progress but it does not remove the need for an already functional machine with hardware and firmware <lle-bout>hardware, firmware and a working input device <lle-bout>but for the case of the Talos II, we may be able to recompile those afterwards and reflash/confirm their hash in various flash areas <lle-bout>but only afterwards, doesnt remove trust in your hardware vendor, you cannot do that <lle-bout>Recent SiFive RISC-V may also give us something similar <bone-baboon>I was just looking at the invoking guix package section of the Guix manual. I think it would be nice if there was a flag like "--list-installed-substitutes" that listed the installed packages that were substitutes. <ptrkriz>Hey. Can Guix use os-prober as of yet? I have an SSD with Windows 7 installed, and I want to install Guix on the other half of it that is unpartitoned. <ptrkriz>Or should I pass --no-bootloader and do it manually somehow? <lle-bout>efraim: doesnt look like the failure is reproducible <ptrkriz>I see. Is there a way to figure out the menuentry for Guix so I can grub-{install,mkconfig} myself? <lle-bout>ptrkriz: run a GNU Guix VM from published qcow2 images and see for yourself in there, I don't know from the top of my head here <ptrkriz>I got the menuentry for Windows from the current system I'm on, so that shouldn't be much of an issue I suppose. <lle-bout>FossGuy[m]: follow the instructions as root then reboot <lle-bout>cons-this[m]: hello! you are using GNU Guix System? <lle-bout>cons-this[m]: do you get that option on other distros, if so which? <lle-bout>cons-this[m]: what's your GNU Guix System configuration? <bavier[m]>anyone know if there's a good way to redirect glibc's getprotobyname lookup to use a different database than `/etc/protocols`? <bavier[m]>I guess? probably too much work to get a package's tests running... <lle-bout>cons-this[m]: by the way, %desktop-services already includes pulseaudio and alsa <cons-this[m]><lle-bout "cons-this: by the way, %desktop-"> Ah, lol, that explains it. <marusich>bavier[m], oh, i see, it's for packaging. yeah I dunno. It wouldn't be a crime to disable a specific test if it is known not to function well in the build environment and you can't figure out exactly how to make it work. You could always ask upstream, too, if you are curious to hear their opinions. <bavier[m]>marusich: thanks, I'll see how many tests are affected, probably all. I've not had many successes when explaining to upstream things like my desire to run tests in the absence of /etc/protocols ;) <marusich>Can a dummy /etc/protocols be created for the tests? Maybe that's more work than is reasonable, but perhaps it might work. <bavier[m]>I tried creating a symlink to net-base, but Permission Denied :( <cons-this[m]>Cool, do you think it would be a good idea if the manual did? Or adding a link in the info pages might be helpful. <cons-this[m]>Cool, do you think it would be a good idea if the manual did? <lle-bout>cons-this[m]: there's so many things to do in GNU Guix, not sure that's a priority now but one day, documentation has to be written but not many people have knowledge of all these areas of GNU Guix to write some. <marusich>In the meantime, the sources are pretty accessible. "git grep define.*foo" almost always finds the place where foo (e.g., my-awesome-daemon-service) is defined, even if it isn't documented in the manual. <cons-this[m]>lle-bout: Yeah, I was thinking of just going through the list and writing it myself since this has been pretty helpful and some other people probably have issues like that. <cons-this[m]>marusich: Yeah, I have been really enjoying that. I use emacs-guix and being able to just look at the package source instantly has been really awesome. <cons-this[m]>Just sometimes where to look in the source code is unclear, unfortunately. <bavier[m]>or fire up a repl with `guix repl` and print variables. <marusich>Some automation exists in some projects to automatically make docs. I know guile does something fancy to sync up its manuals. Doing that for the service docs and other stuff could be a fun project, I suppose <marusich>Yes, that's true. If you aren't used to the source tree already it can be non-obvious. Still, it is good to explore. <lle-bout>marusich: I really think doc should be written within the code, inline, and have a very simple format, I don't know 'texi' <marusich>Well, the motivation for texinfo is that it is standard GNU documentation format, so anyone familiar with GNU development will probably know it, and it can be converted to lots of different formats with little effort, and it produces pretty good looking manuals, even when printed. <marusich>At least, that is how I understand the motivation. It isn't a complicated markup format; the texinfo manual is helpful and looking at existing example texinfo code makes it pretty easy to get what you want when you write it. It's fine, I think. <lle-bout>marusich: would be nice if we could at least have texinfo format inline within GNU Guix code and render some kind of GNU Guix Internals manual kind of <marusich>The challenge is writing good docs...and keeping it in sync. It is a pain to write the documentation for procedures etc. two times. <marusich>You can embed texinfo in package descriptions, at least. Perhaps in other places, too. <marusich>Some would also argue that manually maintained documentation for APIs tends to encourage easier to understand, higher-quality documentation. It can include examples and tutorials more easily, when compared to a lot of automated documentation systems. <marusich>But having absolutely no automation to sync the docs, is no fun :( <lle-bout>marusich: Rust can include code in embedded docs and also use this code as tests so the examples are always tested to work <marusich>The automatic documentation system I'm most familiar with is probably Javadoc. It's fine. It's honestly very nice for documenting APIs. But not so much for manuals; you can't really write a tutorial or a manual. I mean, you can, but it's not really designed for that. Texinfo leans more toward the free-form prose end of technical documentation, I feel. <lle-bout>marusich: did you see Rust? It uses a combination of embedded docs and some markdown site renderer <bavier[m]>Haskell/GHC has a similar thing for embedded docs. <marusich>That's cool. There is a lot about interactive/dynamic documentation I don't know. <cons-this[m]>I have been really enjoying literate programming with org mode recently for config files. It's actually a pretty cool concept (though one I don't think GUIX would benefit from). <bavier[m]>marusich: I discovered an undocumented environment variable that can be set to avoid this test problem. <marusich>also, excitement, i am now attempting to build /gnu/store/zr1d57il906nmfraylmhbmshba9il9m7-guix-1.2.0-16.e8a237c.drv for powerpc64le-linux on the wip-ppc64le-for-master branch... fingers crossed! my desktop has been crunching numbers all day to get to this point. <lle-bout>marusich: it's running the tests for me :-) <marusich>(commit e8a237c is not in savannah; it's the patch i submitted which fixes the tests) <marusich>it might pass because it's in the build container <marusich>it means there was at least one test case skipped; others might have passed. <marusich>inside the build container, perhaps the /proc/self/mountinfo looks like the buggy code expected. <lle-bout>cons-this[m]: what do you mean? is it possible to have the config.scm file be an org file and self-document <marusich>I'm half surprised that guix's documentation isn't written in some Guix-specific DSL written in Guile <lle-bout>marusich: I run powerpc64le-linux tests on Fedora <lle-bout>marusich: next step we also need some kind of baremetal config to boot GNU Guix System <marusich>If the /proc/self/mountinfo looks like the one you posted to me yesterday, then the "mounts" test case in tests/syscalls.scm wouldn't fail even if it ran. <marusich>it looks different on my fedora and debian machines, not sure why. <marusich>Right, guix system will be another fun challenge. <lle-bout>marusich: we still have that guile-static@3 issue I believe? <marusich>My understanding is that on POWER9 systems like the ones produced by RCS, you basically just need to provide a grub configuration that points to a kernel and initrd that can be kexec'd <lle-bout>There's a config we can make that supports both at the same time <marusich>So we might have to do something to convince guix not to install the bootloader, but perhaps that is simple. it's already possible to ask it not to do that when running "guix system reconfigure". <lle-bout>We can install the bootloader, so pSeries is also supported <lle-bout>Debian has a config that supports both, and other distros that support ppc64le also do <marusich>I'm not familiar with pSeries and PowerNV. What are these? <lle-bout>marusich: they are platform names, basically pSeries is POWER8 (also earlier?), and PowerNV is POWER9 and later, pSeries was kept as a platform for QEMU/KVM, so we need to support both for modern support <marusich>Hm, OK. Like, the low level devices and stuff? <marusich>I will have to read up on it a little, but I think I get the idea. <lle-bout>PowerNV is SBE, Skiboot, Hostboot, Petitboot, .. <cons-this[m]>lle-bout: Yeah, using org-babel-tangle and noweb it's actually pretty easy to make files. `(info "(org) Working with Source Code")` (entered via M-:) section should give you an overview. But basically the `:tangle` header argument followed by a filename or path allows you to export source code when you execute the `org-babel-tangle` command. You can then copy this to your config.scm file if you have a systemwide one, or <cons-this[m]>just directly generate the code at the relevant location. <cons-this[m]>The cool features IMO are exporting multiple files from one file, so you can shove all your `.desktop` files and `mimeapps.list` in the same file for example, and the ability to execute code in the emacs kind of like jupyter notebooks. <marusich>So qemu makes it seem like the hardware is pseries stuff, but on blackbird/talos II it's actually powernv? <lle-bout>marusich: GRUB has payloads for pSeries already, it pretty much works <lle-bout>marusich: yes PowerNV is baremetal but pSeries is QEMU/KVM right now on your Blackbird/Talos <lle-bout>QEMU/KVM doenst use SBE/Skiboot/Hostboot/Petitboot/.. <lle-bout>There is some QEMU fork with PowerNV support but it's largely unfinished, pSeries is what's mature, it's also very sufficient <marusich>by the way, another naive question maybe, but it is my understanding that kvm does work to hardware-accelerate the VM using qemu on power9. Is that right? <marusich>I was not quite sure if kvm was not supported on power9 <marusich>but it's just that you can't use kvm to emulate another arch <marusich>I learned that the hard way when I tried to make a multi-core x86_64-linux VM in my ppc64le debian machine and found out it was slower than my x200 laptop :P <lle-bout>marusich: yes KVM is only for restricted set of archs compatible with host (ppc64, ppc64le) <marusich>but ok, getting back to the topic of guix system. we will need to arrange for it to provide a grub config that works on both pseries and powernv (or at least, support both and spit out the right one depending on the situation) <marusich>What did you say about the guile-static@3 issue? Which issue was that? <lle-bout>marusich: erased glibc eeeee reference in binary <marusich>BTW my build of guix succeeded; it's packing the tarball now. <marusich>I'll try installing it on a vm and doing 'guix pull' if it works out.. <marusich>since i had it working before on a branch derived from master, i am optimistic <marusich>lle-bout, oh yeah. Hm, I dunno. I guess we'll see. If it's a problem, is it the kind of problem that would require rebuilding the bootstrap binaries, or is it something we could hopefully fix without doing that? <lle-bout>marusich: we checked earlier it wouldnt require changing bootstrap <lle-bout>marusich: it's just the guile-static@3 package we need to modify <lle-bout>marusich: basically guile-static@3 on powerpc64le-linux is not static at all for some reason <marusich>the guix release binary was built successfully! <marusich>sweet. I guess that means the issue with the mounts procedure in (guix build syscalls) won't prevent guix from being built. <lle-bout>efraim: guix built for me on your wip-ppc64le-for-master branch :-) <marusich>thank you for taking the time to rewrite some of the changes for master, efraim <lle-bout>marusich: I am curious to see how they did, but no time to look yet <lle-bout>I am updating things in gnu/packages/webkit.scm now <marusich>My guess is that /proc/self/mountinfo looks "as expected" in the build environment, but that's just my guess. <marusich>Cool. Now I'm installing Guix into a fresh Debian VM. <lle-bout>marusich: I asked Vincent for their SSH public key, waiting <lle-bout>that was a little while ago now but still waiting <marusich>It'll probably take another whole day to confirm that "guix build hello" and "guix pull" works in the VM, anyway. <marusich>I suppose I could try to set up my desktop as a substitute server... <lle-bout>marusich: just guix publish --advertise! <lle-bout>change the VM to bridged mode somehow on your LAN interface and you're done <marusich>Did they actually add mDNS support to guix publish? <marusich>Do I have to do anything special to tell guix-daemon to use it? <lle-bout>marusich: you will also need to exchange archive signing keys <lle-bout>marusich: hmm maybe an option to look for mdns, check the devel manual <marusich>I remember talking about that back at the first fosdem i went to, and we were like, "yeah, that'd be amazing." It's great that it's been added! <lle-bout>marusich: without exchanging signing key, it works for caching ci.guix.gnu.org substitutes which is still quite nice <marusich>Huh, I dunno why, but I get a Bad Read-Header-Line header: #<eof> when it tries to substitute. not sure if it's a problem the way I set up the substitute server or what. <marusich>I guess I'll just let it build from source for now and see what happens. <marusich>maybe i'll just try disabling compression. <marusich>BTW I decided not to use mDNS because it kept trying to fetch substitute info from ci.guix.gnu.org <lle-bout>if you retry it ends up working, it's non-deterministic <marusich>...which is fine, but it was doing it a lot, and I was impatient <marusich>--compression=gzip:0 didn't fix it; it still happens. bummer <marusich>Guess I'll just build from source, after all. <marusich>or i could grab a04aef2430645357d7796969d4b6453478ff8a3f i guess <lle-bout>marusich: the bug's still not fixed apparently, ludo still needs to update the guix package itself <marusich>which i can do, probably, privately in my checkout <marusich>anything to keep myself from rebuilding the world... <lle-bout>marusich: I think you can try again and again until it works, the issue is non-deterministic <marusich>it happens so often, i would need to do it al ot <lle-bout>marusich: "while true; do guix pull && break ; done"? <lle-bout>it's terrible but what else do we have here <marusich>It happens for basically every attempt. I'll just build from source. <marusich>I am about to head away from the computer for the night anyway <marusich>glad to know it wasn't a power9 specific problem <marusich>Well, at least the builds are proceeing smoothly. Goodnight! :) <sakalli>hi all. building a box where i have a minimal arch as base and then most of the packages with guix on foreign system. would it be ok you think to run xorg through the guix? any guides anywhere, thinking just installing the xorg-server from user might not suffice? or would it? <i1l>sakalli: try install GUI on Arch, then install something GUI with `guix`. if it will perform well, then.. performance was bad last time i tried on aarch64. <i1l>idk why, and idk the current state. <lle-bout>sakalli: hello! you can for sure run xorg-server but the question is for services now <lle-bout>sakalli: I think it's possible to run shepherd as non-PID1 and still benefit from the services infrastructure, but not sure how. <lle-bout>sakalli: shepherd simply takes a config, so <leoprikler>you just configure your services inside ~/.config/shepherd/init.scm <i1l>well, service is executable + config + "supervisor"? <lle-bout>I have the feeling that since last update GNU Guix commands run much faster o_O *i1l systemd on Arch can probably do the trick. PATH can be set inside units. <lambdanon>It's not secure to put a UUID on a git repo, and if I were to do a fresh install, the UUID would change. Is it possible to pass a UUID as a parameter to a config.scm? <lambdanon>I could just sed -i 's/LUKS-UUID/<my-uuid>/g' on config.scm, but that seems a little clumsy <mdevos>lambdanon: how secret is the UUID? <lambdanon>I have to type it in plaintext into my config.scm <mdevos>I mean, would it be problematic if it ends up in the store, or is just not making the UUID visible in the repo good enough? <lambdanon>Just not making it visible in the repo is all I need <lle-bout>UUID would be visible in /proc or something anyway <lambdanon>Not just for security reasons, but also because if I have to reinstall, the UUID made by encrypting a new partition will have changed <mdevos>If the latter is the case, just define a file "the-uuid" or something, and let "config.scm" read the UUID from "the-uuid" or something like that <mdevos>(Configuration files are Scheme code) <lambdanon>I might as well not do UUID and just do /dev/sda <i1l>i remember LUKS has labels, aren't it? <lambdanon>i1l: The UUID is for /dev/sda, not for the decrypted partition <lambdanon>I've moved on from that issue and found another: I've got my config.scm sorted, it's on a private git repo. I tried booting into my guix SD installer, only to find it doesn't have wget, git, or curl installed. Is there some official way of putting my config.scm onto the .is? <i1l>inside installer: alt + F3 <i1l>setup wifi if needed. run `guix install wget` <i1l>if you have at least 4gb RAM, it should work <i1l>(did not tested with less RAM) <lambdanon>I seem to have a problem, where 'services' is an unbound variable. I have included (gnu), (gnu system nss), the service modules xorg and desktop, etc. <lambdanon>Ah, found the problem. I did (services gnome-desktop-service-type by mistake) <i1l>ye, use Sway. Gnome is mistake <i1l>from here for starting the holy shitballs feastival. <nckx>Aw, they left, how can I kickban them :'( <nckx>It's half past three in the afternoon here. <nckx>And I'm eating St.-Nicholas chocolates. Time is an illusion. <Noisytoot>Why is WeeChat from Guix compiled on Jan 1 1970? <nckx>Jan 1 1970 == UNIX timestamp value ‘0’ (or ‘1’, depending on the second). <nckx>If a programme reports when it was compiled, that means the timestamp is stored somewhere inside it, and two otherwise identical compilations at different times would differ. <nckx>i1l: We're to hand out free kickbans due to budget cuts, please kick yourself. <Noisytoot>nckx: You can't kick yourself if you're not an op <i1l>autojoin makes it inefficient. <nckx>Do it enough times & you'll get kickbanned for join/part spam, simples. <i1l>i want to be opressed to join an liberal party to make a political carrier. <i1l>ooressed minority, that is. easy money. <leoprikler>I think you'd find yourself having a harder time making money or succeeding in your political career as a member of an oppressed minority. Statistically speaking. <bone-baboon>Does running `guix pull` add substitutes to a system? <Noisytoot>And the oppressed minority you are part of is: people who are banned from #guix? <nckx>bone-baboon: ‘guix pull’ builds several distinct store items, each of which can be substituted like any other if you have substitution enabled. <bone-baboon>nckx: So I would not need to do anything special to turn off substitutes for `guix pull`? It's default is not to use substitutes? <nckx>Ah yes, the oppressed minority of people with lots of money. <nckx>bone-baboon: It simply follows your global settings. If you haven't authorised ci.guix.gnu.org's key in /etc/guix/acl, or don't run the daemon with the default --substitute-urls=, no substitutes will ever be downloaded. <nckx>If it happens, bug report time. <nckx>After double-checking your settings. <morgansmith>hey in commit c05ceaf2b650d090cf39a048193505cb4e6bd257 a comment near the top of tests/lint.scm (line 64) should have been deleted but was not. It's a super quick and easy thing so I'm hoping complaining here will fix it. <nckx>morgansmith: The ‘Avoid collisions with other tests.’ one, yes? <morgansmith>previously there was a line below it that set a port number or something <katco>i'm working with a few local-only package (i.e. they are not checked in anywhere), and i have them defined as guix packages for use with `guix environment -f`. is there a way for 1 local package to refer to the other without defining a module? something like this? `guix build -L../pkg-a -fpkg-b.scm` <nckx>morgansmith: ☝ not katco. <i1l>'add-to-load-path, then? <katco>i1l: is that in reference to my question, or something else? <i1l>Guile has some proc like that. <nckx>katco: Without editing the files themselves? I don't think so. <katco>i1l: i'm not sure that would help, that's what the `-L` flag does, and guix complains that it doesn't know about the package defined in `pkg-a.scm` <nckx>And if you are, as you mention, you might as well make them proper modules then. <nckx>You may be a Guile module. <katco>nckx: maybe they should be modules? right now my scm files just define a top-level `package` because my main use case is `guix environment -f`, but now i want one guix environment to refer to the other package. am i describing something that should probably be a module? <nckx>I personally think so, yes. <nckx>IMO -f is for quick tests/hacks; inter-hack dependencies outgrow that by definition. <katco>nckx: well, it's quite nice to provide a `guix.scm` file for devs to build an environment <bone-baboon>nckx: There is only one entry in /etc/guix/acl with a public key Ed25519 and a tag of "guix import". Is that authorization for ci.guix.gnu.org? <morgansmith>nckx: Thanks for removing the comment :D. It was bugging me :P <morgansmith>is there a way to re-queue things in the CI? Openscad seems to have failed in 2 seconds due to some network issue and I don't want to build it myself... <nckx>katco: Well, you can still define inputs to the final package (the one returned by the file) above it, and use them inside the same file. <nckx>Is that not enough for that use case? <katco>nckx: yeah i thought of that, but then i'm redefining things <katco>i'd like the `guix.scm` files to live with their code <katco>nckx: i'll have a go at defining an ephemeral package for these package files in the hopes that adding their `pwd` as a load path allow guix to reference them <nckx>bone-baboon: If you never want substitutes ever, simply delete that acl file. (The entire file; an empty one is not valid!) <nckx>katco: The guix.scm not a practice I'm familiar with, so I can't say more. I never even use -f. <katco>nckx: yeah, this is outside of guix package maintenance and within the realm of utilizing guix as a dev environment, so the standard path for packages doesn't necessarily apply <katco>obviously as a guix lover, these packages will eventually make their way into guix proper, but their `guix.scm` development files will always live on <i1l>katco: try the proc. i think i swa it in nomad-browser in guix.scm. <katco>nckx: correct, just for local development <katco>for example, if you were building up 2 projects simultaneously, you'd want your local copy of A to reference your local copy of B <katco>but when you checked the `guix.scm` into their repos, they'd have to be changed to `specification->package` or something since everyone's local environment is different <nckx>That's pushing a lot of magic into the ‘guix build’ invocation itself. <nckx>If a ‘guix build’ command line that needs to be copy/pasted, not remembered/deduced, is no objection: you're aware of ‘guix build -e’, right? <katco>it's the same sins everyone commits when hacking locally. i'm just trying to utilize guix instead symlinks and stuff :p <katco>nckx: yes, i'm aware. i'm utilizing this for `guix environment` though <katco>e.g. `guix environment -fguix.scm` <-- i want the local copy of my sibling project to be included in the environment <nckx>Oh. Weird that it supports -f and not -e; I don't immediately see a Design reason for that. <katco>it's nice that it supports both, so you don't have to rely on weird shell stuff to pipe in file contents <katco>err i'm confusing `build` and `environment` for `environment` i'm using `guix environment -lguix.scm` <katco>but `environment` also supports `-e` <i1l>katco: similar (btw, devel is the master branch) <katco>i think the issue isn't that it can't find the code, it's that the code is just defined as a package and not a module, so guix doesn't know how to reference it <i1l>ah, dependency isn't a module. then 'load should do. <katco>i1l: hm, `load` does allow it to find the package symbol, and if i add that to `guix.scm` it works (thank you!), but i'd rather this be a command-line thing. kind of like how gcc linker options can point to specific libs. still, this opens up new possibilities. <bone-baboon>I would like to know the packages that are included in %base-packages but when I run `guix edit %base-packages` it gives the error "%base-packages: unknown package". How can I explore the contents of %base-packages? <nckx>For a machine answer: echo "(use-modules (guix packages) (gnu system)) (map package-name %base-packages)" | guix repl <nckx>katco: I think those GCC options are practically never used interactively, but scripted? ‘-e’ seems like the better general interface for ‘my command is becoming a programme of its own’. No need (to wait) for upstream to add options for each specific use case. <katco>nckx: so i tried `-e` with `(load "../pkg-a/guix.scm")` but it looks like guix places this in a temporary module, and the sibling package can't find the reference <nckx>And (string-append (getcwd) ...)? <katco>nckx: i just tried that, and i get the same error suggesting i load a temporary-sounding module name to resolve the symbol <katco>guix is being very helpful in suggesting the name! <katco>eh, i'm within edgecases now :) but thinking about how people might use `guix environment`, i think this is definitely one of them: stringing together local copies of packages you're hacking on in tandem <nckx>katco: I'm only sceptical about adding command-line options; I definitely agree it should be (made) possible in actual Scheme. <katco>nckx: well, except i think the use case of pointing disparate packages at one another is a CLI concern. users could use `-e`, but then they have to know the function to call. a flag is discoverable. <nckx>katco: Are we talking about combining different files that are proper modules now? I don't see how it would work at all otherwise. <nckx>I.e. how would foo.scm refer to bar.scm's value without any explicit binding. <katco>nckx: no, just files that contain packages. the use case is such: (1) two projects provide `guix.scm` files (much like projects provide `Dockerfile`s) to aid their devs in getting a repeatable/quick environment (2) two such projects, A and B are often worked on in tandem (3) alice has both A and B checked out locally and has made changes to both. B depends on A. (4) alice wants to `guix environment -lguix.scm` from project B but <katco>switch the reference from guix proper (or nothing at all) to her local copy of A <katco>nckx: i don't know the specifics, but i think your answer can be found with another question: how does `guix build -f` know how to reference a package if it's not in a module? <katco>i think a hack to describe what guix _might_ try doing is: `$ guix build -f<(cat ../prj-a/guix.scm ./guix.scm)` <katco>just sort of create a temp module (as it appears to be doing), and dump everything into it for the command. i dunno. <katco>maybe a TLDR is: `guix environment` deals in packages, and so its flags should too? <leoprikler>If you need more than a simple guix.scm, you can always tinker with your load path. <leoprikler>you might even want to write a snippet, that fetches a git repo and loads its guix.scm if you're really desparate :) <lambdanon>Hey there, I have a question for those who use libreboot. I currently have to decrypt my drive twice, and go through two grub boots. I've already got the firmware configured to decrypt my drive, so if I were to remove the bootloader declaration from my config.scm, will that solve the problem, or will it brick my box? <mdevos>bone-baboon: we would need the build log of llvm <mdevos>(See ‘View build log at '.....'’ line) <lambdanon>Got a problem with the guix emacs interface: package-names*: unbound variable <bone-baboon>lambdanon: How is the Guix experience on a Librebooted machine? How does the hardware you have Liberbooted do with `--no-substitutes`? <nckx>bone-baboon: One common explanation is you ran out of RAM. Can you check your dmesg for any out-of-memory (OOM) killings? <nckx>mdevos: Does paste.gnome.org use trackers/track users? <mdevos>IceCat reports paste.gnome.org ‘connnects to third-party resources’ at www.google.com <bone-baboon>nckx: It looks like you are right. "/var/log/messages" says "oom_reaper: reaped process (cc1plus)" which is the process mentioned in the llvm build log. <mdevos>(which looads loader.js or something. There are no futher requests to google.com) <nckx>bone-baboon: Run as few simultaneous things as possible (pass -{M,c}1 to Guix), but [building] LLVM is known to be a memory hog. How much RAM do you have? <bone-baboon>Can I add a swapfile after the inital install of Guix? If so is it the same process described in the Guix manual? <nckx>mdevos: OK, I was aware of that. I didn't consider it a problem because the site works fine without it... <nckx>...since I'm thinking about this too much, back we go to Debby Downtime's Sometimes Pastebin. ***nckx changes topic to 'GNU Guix | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
<lfam>I wasn't able to remove the service from %base-services, and I couldn't figure out how to use modify-services. This is likely because I don't know what I'm doing. Help wanted! <lambdanon>bone-baboon: I'm still trying to learn guix. it's the first distro I've tried with FDE, so I'm flying by the seat of my pants <lfam>The important thing to understand about Guix is that it is a build-from-source distro that can transparently "substitute" the results of compiling, if you've set that up. So, there is no difference between things that you build yourself, or things built elsewhere, from Guix's point of view <lambdanon>I'm wondering why define-syntax-rule is used so often for things that could be functions? <lambdanon>At least, things that I guess could be functions, if not for some factors I don't know about <nckx>bone-baboon: It's more than I expected, but one can't argue with the kernel holding the OOM gun 🤷 You can build only LLVM more slowly but using less RAM, with ‘guix build -{M,c}1 /gnu/store/5wgpkavvf5k4r163f5b64k0yh2dmw9jc-llvm-10.0.0.drv’. When that's finished, repeat the command that originally failed. <nckx>Which apparently was sudo guix system reconfigure ... . <nckx>(It will take a while, bring a book.) <lfam>bone-baboon: I recommend also setting the --timeout and --max-silent-time options to a very high value <lfam>Otherwise the build may be killed due to taking too long <lambdanon>I've installed guix-emacs, but I still get unbound variables? <lambdanon>at the top of my .emacs I have: (add-to-list 'load-path <lambdanon> (expand-file-name "~/.guix-profile/share/emacs/site-lisp")) <nckx>Both --max-silent-time and --timeout are disabled by default. <lfam>nckx: Oh? I thought they had a default value <lfam>Do you know where it is set? <nckx>bone-baboon: So don't interrupt the build just to add them, they have no effect (and you'd actually be *setting* a timeout, even if it was implausibly high). <nckx>lfam: In code? Not off the top of my head. Otherwise: in the daemon, where it's 0, and the client by default doesn't send an override. <nckx>Reason I don't know is because C++ is scary. <nckx>I think lfam: libstore/globals.cc <nckx>rm -rf nix/ && git commit -am '\o/' && git push -f upstream <lfam>Why didn't I think of that yet <lfam>We'd also have to rewrite guix-install.sh <nckx>Sometimes my own genious amazes me. <nckx>(echo '(system "'; cat guix-install.sh; echo '")') > guix-install.scm <lfam>Noisytoot: Parts of it have been, and the full rewrite is a goal <pkill9>so now i'm thinking, as an addition to using firejail to keep application data in separate sandboxed directories, i could have those diretories be sshfs mounts <lfam>nckx: You should use INVOKE instead of SYSTEM <Noisytoot>Doing that also makes editing it more difficult (no syntax highlighting) <nckx>It does not do its own tokenising (well, call the shell to do so) or variable expansion. <nckx>Which means the obvious choice is to embed a minified version of gash in the shebang which is extracted at run-time to interpret the rest of the script. <lfam>Is that the black hole you've disappeared into <lfam>Has your brain become so large that it collapses space-time <nckx>I am become the round peg. <Noisytoot>nckx: You should rewrite (echo '(system "'; cat guix-install.sh; echo '")') > guix-install.scm into Guile! <nckx>Noisytoot: Hm, you're right, we'll have to scrap that idea. <lambdanon>Heya, how do I go about fixing deep-rooted demendency problems? I'm currently in dependency hell because different emacs packages want different versions of the same packages <nckx>Noisytoot: OK, but can we rewrite *that* into bash afterwards? For portability? <lfam>I like the word "demendency" to describe this :) <lfam>lambdanon: In Guix, it's possible to have different versions of packages, and use them in different places <lambdanon>I tried guix pull && guix package -u, but that's failing for the exact same reason <lfam>I might be able to give more specific advice if I understood the details of your situation more <nckx>Noisytoot: (Seriously) Yes. <nckx>We assume Guile everywhere is a given, from the bootstrap to the initrd. <nckx>Very-very-early bootstrap excepted, but that's a weird primordial oozefest anyway. <lambdanon>lfram: Overarching problem: I want to know what packages to put in my guix manifest. Middle problem: emacs-guix has a whole bunch of unbound variables, so I can't use it all. Potential solution: upgrade my emacs packages? Maybe that'll fix it? <lfam>Second, I don't have much experience with Emacs so I can't offer very specific advice. But it sounds like emacs-guix is out of date for current Guix <lfam>I'm *sure* that somebody else can offer expert advice about emacs-guix :) <lfam>Don't worry about the name. It just meant that I wouldn't get notified if you mentioned me <lambdanon>lfam: Tried guix upgrade emacs-guix. Nothing to do <lfam>Hopefully someone can clarify what's going on <lfam>It's a little frustrating as an outsider. emacs-guix used to be part of Guix, so this didn't happen. But the author decided to remove it from Guix, and then it was abandoned, so it's being slowly reintegrated into the project <nckx>Noisytoot: An Emacs interface for Guix. <lambdanon>Noisytool: Yeah, it lets you list packages the same way that MELPA packages are displayed in emacs, i.e. in a table <lambdanon>Are there any other ways to list what packages are installed in guix? <nckx>Is it possible that emacs-guix just works without me adding anything to .emacs? I mean, I never use it, but I have emacs-guix & emacs installed into my user profile and ‘M-x guix’ simply works. <lfam>Yes, the actual Guix tools, lambdanon. E.g. `guix package --list-installed` <nckx>grep guix ~/.emacs returns nothing relevant-looking. <nckx>lambdanon: You can do everything (and more!) just using the ‘guix’ commands. <nckx>lambdanon returnal: You can do everything (and more!) just using the ‘guix’ commands. <lfam>Right, emacs-guix is an "extra" <lambdanon>apologies for the frustration, it's a little overwhelming having to put out all these fires at once <lfam>For people who live in Emacs <lfam>You think you'll do one thing, and next thing you know you're juggling have a dozen different tasks <lfam>What a strange typo. I am really getting dumber <nckx>‘One problem? Have a dozen.’ -- computers <lambdanon>Step 0: Wow, this guy has a git repo with their guix config in! I can just look at that to see how it's done <lambdanon>step 0.1: wait, how does scheme's hygenic macro system work? <drakonis>having to know guile to do anything slightly more advanced than filling in the blanks is something <lambdanon>I quite like guile, I'm just more of a CL person <lfam>It's a little tough for me <midnight>I use strictly XFS. I would use JFS, but the maintainer seems to have permanently checked out. <pkill9>how do you do incremental backup with it? <pkill9>becausse from wha ti see it effectively saves snaphosts of every change <lfam>I'm not using incremental backups <lfam>The snapshots are deduplicated, so the space usage is incremental, IIUC <lfam>I think that truly incremental backups are not considered a first-class backup strategy anymore. Maybe for tape systems <pkill9>i want to use Btrfs due to it's copy-on-write <mdevos>Has anyone been working at shepherd recently? <pkill9>if it makes backups save the changes ot files as opposed to copying htem all the time <lfam>It would be nice to truly integrate filesystems, device management, backups, snapshotting, and deduplication <lfam>For now, it's not really there <lfam>The filesystem is reliable, in my experience, and assuming a recent kernel <lfam>It's deployed widely in SOHO / SMB NAS products <lfam>People on workstations choose their own FS. I meant that giant corporate profits are being bet on btrfs <lambdanon>Weird. Some of my installed packages are missing when I do guix package --list-installed, even when I source ~/.guix-profile/etc/profile <lfam>That's really weird lambdanon <mdevos>lambdanon: what happens if you add an --profile=??? argument? <lambdanon>I tried installing emacs-doom-themes (even though I already installed it and I'm currently using it), I then did guix package --list-installed, and no change <nckx>lambdanon: What does ‘which <command provided by such an installed package>’ return? <lambdanon>mdevos: I've never messed with profiles at all <pkill9>i should just look for a backup utility that does deduplication in userspace and makes snapshots <lfam>That would be borg, pkill9 <lfam>Choose your fighter: Python or Go <lfam>They have some different features, too <nckx>And probably others, but if you want your backups to be done by heavily-used and presumably-tested products, use one of those. <lfam>I still wish it was all built-in to the kernel <lambdanon>nckx: emacs-doom-themes doesn't provide a `which`, as it's not an executable. My $PATH includes ~/.guix-profile/bin, and that's it <nckx>I agree with you on many things, lfam, but what the actual heck. 😃 <lambdanon>as well as the usual stuff like /sbin/ , /usr/bin, ... <lfam>nckx: Well, kernel or userspace... it should be like on Apple <lambdanon>but that's because I'm using mint as a foreign distro on my PC <nckx>lambdanon: I didn't know the nature of the package when I sent that. <lfam>I don't like the unix philosophy <lfam>I want a fully integrated system <mdevos>lambdanon: "which" can be found in the "which" package <nckx>...then you can do a whole lot better than Apple. <lfam>Mainframes for the desktop <lfam>Right, but on Apple, at least there is concession to "flexibility" or "choice" <lfam>Their backup system is kind of hacky but they are free to change it <lfam>I mean, there is no concession <nckx>Still, I agree in spirit. Non-unix philarsarphy Lisp machines for the home plz. <lfam>IIUC, the Apple backup system is basically still a rsync / hardlink type thing. But it is built-in to the OS and well-integrated *nckx still hasn't closed emacs-guix... uh oh. <lfam>The other day I was talking to somebody who works at a library archive about the absurd mismash of different software "solutions" they have to integrate "by hand" in order to do their work. Their 70 year old boss is always asking, "why can't it just do X useful thing". And it really struck me that desktop computing has failed to serve us <lfam>Why can't they just have a "library in a server" all-in-one thing <lfam>There is still so much room to improve <pkill9>what do you mean library in a server? <lfam>Like, from initial contact with donors, to serving researchers, and managing the collection, they have to use a dozen different programs <lfam>(It's an "archive" library, not like a book lending library) <cons-this[m]>I think one of the issues is that software as a whole, tends to not really have or comply with standards, and the standards that are made are often made post-hoc from hacks people did before. The POSIX standard is a really good example of that as is XML and (to an extent) JS. <lfam>There is a huge amount of time spent copying and pasting between the programs <lfam>The can spend months talking to their vendors to integrate a single field of data between the programs <lfam>It's such a waste of human potential <lfam>And I thought about "do one thing and do it well" <lfam>And it really seems lacking <lfam>I'm not sure it's ever lived up to its potential <lfam>So... viva Guix! Viva Guile! Viva monorepos <lfam>Let us write services that do everything in one codebase <cons-this[m]><lfam "And I thought about "do one thin"> In that case it just sounds like a lot of the problem is a lack of good APIs mixed with a lack of programmers. (or a lack of people willing to bust out selenium) <lfam>Yeah, that's definitely one way to look at it <lfam>But it seems that, these things never get all the way there <lfam>There are APIs for these programs, and there are programmers on staff at the vendors, and the support contracts are measured in tens of thousands of dollars <lfam>(Libraries won't ever be able to pay millions) <cons-this[m]>Well yeah. But of course the end user can't really modify it easily or alternatively lacks the know-how. <lfam>I think about shell scripting, and how it's fraught with peril <lfam>If anything should be "done" yet, it should be the Unix shell. And yet it's still really hard <lambdanon>I'm sick of havng to resolve these conflicting entries in my guix profile. Going to temporarily switch to doom emacs and just reinstall guix entirely <lfam>Well, I'm on a rant :) Sorry everybody <zazzi_>Hello, how install dnstools like dig <lfam>zazzi_: `guix install bind:utils` <PotentialUser-41>Hello friends, following last night's discussion, is the website (https://samfrew.com) trusted to download firmware? And in general, are such websites and firmwares trusted? <lambdanon>Trying to rm -rf /gnu. There's a lot of read only file systems. <lambdanon>Is there an official way to remove GUIX? All I can find is an obscure mailing list entry <efraim>Back to btrfs for a bit, I get 3:1 compression from built-in store deduplication and 2:1 from btrfs compression, leading to about 5:1 space savings overall. <mdevos>lambdanon: there should be no reason the delete /gnu or reinstall guix. Just delete the original profile <nckx>lambdanon: The entire thing is read-only. It's bind-mounted that way, you need to unmount it first. I think we bind-mount it using gnu-store.mount on systemd systems, so remove that from /etc/systemd/system, along with guix-daemon, and reboot. <nckx>Oh, you want to reinstall. Then I agree with mdevos: removing /gnu is a pointless waste of time. <nckx>You're not going to replace it with shinier, bug-free™ bytes. <lfam>That's really nice efraim <nckx>efraim: Which algorithm? <efraim>With the default 3, haven't figured out how to change it <lfam>I recently recompressed my btrfs /home with zstd, and got >10% savings, even though most of the data is in compressed file formats <lfam>It was significant savings considering the partition is almost 1 TB <Noisytoot>I had a strange issue with Guix stopping other stuff from working, and reinstalling fixed it <lfam>Really impressed with zstd <nckx>lambdanon: I don't think there's an official ‘how to remove Guix (it's never been called GUIX) guide’. <mdevos>How should profiles be deleted btw? <lfam>`guix package --delete-generations` <Noisytoot>lfam: Can you compress it without deleting data (or moving it from another drive and back)? <mdevos>lfam: not only old generations, but also the latest? <lfam>You can't delete an active generation mdevos <nckx>efraim: Should be just mount -o compress=<algo>[:<level>]. <lambdanon>nckx: Okay. I wanted to reinstall because I feel like I got something wrong early on. Going to try something else, but I don't really know what. <lfam>Noisytoot: You can "defragment" the filesystem after remounting with the compress algo set <lfam>It will recompress the entire thing and you can use the filesystem while it works <zazzi_>lfam, why bind:utils not searched through "guix search"? <efraim>I guess it's worth a try, my machine is faster enough now <lfam>The only caveat with defragmenting a btrfs filesystem, Noisytoot, is that extents can become unduplicated. So if you made a lot of COW copies, they maybe duplicated afterwards <mdevos>lfam: Why not? Aside from messing up the current session, which logging in again should fix? I'll try rm ~/.guix-profile, see what that gives (in the childhurd) <lfam>mdevos: Well, deleting the current generation of programs that you are using could cause some trouble... not allowing it seems reasonable to me <lfam>If you want, just create a new generation without any packages in it <lfam>Then, you can delete the previous one <nckx>It's very different on a foreign distribution though. <nckx>There it feels very ‘why would you ever want to uninstall BonziBuddy??? Let me help you not do that.’ <lfam>It's a really vague question PotentialUser-41 <lfam>If you trust it, then you can consider it trusted <lfam>Also, I don't think it's relevant to Giux <Noisytoot><PotentialUser-41> Hello friends, following last night's discussion, is the website (https://samfrew.com) trusted to download firmware? And in general, are such websites and firmwares trusted? <nckx>And it was really vague. <lfam>Personally, I would choose to download firmware from the manufacturers' or vendors' website <nckx>PotentialUser-41: That looks like the most dodgy Web site ever, if you insist on my opinion. You have no way of knowing what's in those non-free files. <lfam>You don't have to be sorry. I'm just explaining why you didn't get any replies <zazzi_>lfam, thanks, just install dig and other tools <mdevos>Or the linux-firmware git repo. It's non-free, but at least it is upstream and isn't dodgy <sss2>hi all, is here any package writing tutorial for cpmplete beginners for guix ? <nckx>PotentialUser-41: Which discussion was that? I don't see the relation to GNU Guix. <sss2>i am coder, but unfamiliar with lisp <mdevos>sss2: There's the guix cookbok and the guix manual <lfam>I recommend reading that <sss2>can you share link to coockbook ? <mdevos>sss2: "info guix-cookbook" if guix is installed <lfam>I would say that, if you trust it, it is trusted <nckx>mdevos: I only see telephone operating system images, not the kind of ‘firmware’ in linux-. I don't know more, because the rest is censored by Cloudflare. <sss2>also, from some time ago i am often facing network errors from guix <lfam>sss2: Yes, we see these errors too and have a but ticket for working on them <Noisytoot>nckx: That makes sense, as someone was talking about Heimdall/Android/Replicant yesterday <sss2>lfam, noted, ok, if this is known problem <mdevos>PotentialUser-41: Convince the relevant people to free the source code of the firmware, verify the source code & build it yourself? <lfam>Specifically, this kind of thing: Bad http-version header component: _'$Àçv7$H? <mdevos>lfam: I noticed that in the childhurd <sss2>lfam, yes, looks similar <lfam>I think we are all seeing it recently :/ <sss2>but what is it exactly ? <sss2>wrong responses from http server ? <lfam>It looks like some memory corruption somewhere <nckx>PotentialUser-41: I don't think you'll receive the answers you expect in a place so diametrically opposed to what that site seems to offer. You cannot trust the proprietary software from vendors like Samsung or Google by definition, so it doesn't matter if that site tampers with it or not. <lfam>I don't know why else those bogus values would be appearing <sss2>so it might be local problerm ? <lfam>Not sure, maybe the bug report has more info <lfam>It has nice features, for sure <lfam>Probably the worst thing about btrfs is being worried about people telling me I shouldn't use it ;) <sss2>i have quite some testing with filesystems on relatively large datasets (~50tb) <sss2>most noticerable problem of btrfs is - speed <pkill9>why would people tell you you shouldn't use it lfam? <sss2>for many workloads it's just tooo slow <sss2>i found it stable enough, and it does have good recovery tool <lfam>pkill9: About 10 years ago, it had bugs that caused dataloss, and it's reputation never recovered <pkill9>I wouldn't be working on large datasets <lfam>But, that was the early stage of development <pkill9>yea i got that sense of it not being safer <sss2>it's perfect for os root <lfam>At this point I'm confident in it <sss2>especially with a lot of dup data <nckx>pkill9: It was widely used before it was ready (regardles of whether that was upstream's ‘fault’ or not) and got a very bad reputation from which it is barely recovering now. <lfam>I haven't seen any reports of dataloss in the last several years with recent kernels <pkill9>well why would it be released if it wasn't ready? that's just ridiculous <lfam>Also, it's used in production at facebook. They have been able to support the kernel development with reports about problems for many years now <lfam>That's just how linux works :) <PotentialUser-41>Sorry friends, this will be the last question: Does not user get freedom by rooting their Android device? <lfam>It happened for every filesystem in linux, pkill9 <sss2>so, today for dataset without large io and large files btrfs is cool <nckx>It also has pathological cases different from ext4 (e.g. extreme fragmentation of large VM images, databases, ...) and because ‘ext4 is the standard’ btrfs is obviously ‘inferior’, even though it outperforms ext4 elsewhere. <lfam>I think that the timeline of btrfs being introduced overlapped with the rise of social media, so memes about "btrfs is bad" were able to spread in a way that they could not for ext2/3/4 <nckx>pkill9: Linux file systems aren't ‘released’. <sss2>because of it's limitations <mdevos>PotentialUser-41: well, yes, but I don't know what these "firmware images" (it's probably just software IIUC) have to do with rooting? <lfam>They aren't crazy sss2. The extN filesystems have evolved for decades. They are not "designed" in a meaningful sense <lfam>It's more a long process of reacting to bugs and new workloads <nckx>sss2: And fixed inode count is irrelevant for the vast majority of its users, regardless of whether it annoys you. <sss2>i just want to say what all extX is deprecated from my point of view <mdevos>Also, there currently isn't much of a point of running guix on Android <lfam>Yes, and your point of view is shared by the extN developers, too <lfam>I know that T'so sees ext4 as the final iteration <nckx>It's not a controversial opinion :) <sss2>nckx, xfs is similar to ext by overall features set, but also have reflinks support and dynamic inode count <sss2>i see no reason to use ext <sss2>maybe, just MAYBE xfs have a little slower delete operation for a lot of inodes <sss2>but it's tolerable, especially for datased with large files <lfam>Speaking of ext4, I have a personal wishlist item to do something about the warning message "ext4 filesystem being mounted at fs supports timestamps until 2038", which pops up in some Guix use cases <sss2>lfam, it's vfs problem, not fs specific <lfam>Well, whatever it is, now is a good time to fix it <sss2>[193840.013893] xfs filesystem being remounted at /newroot/var/data supports timestamps until 2038 (0x7fffffff) <lfam>We should start creating filesystems that last longer <sss2>i think data field must be extended <sss2>probably it's hard to do for already existent fs <lfam>I'm talking about fixing the places where Guix creates filesystems <sss2>i see more critical problems in guix as host os <sss2>unfortunately in current state guix does not fit as host os for me <nckx>sss2: I don't see why you brought up XFS. What you say is all true, but again, completely uncontroversial. Just use whatever Linux file system suits your use case best -- that's why there are several! <sss2>i am not able to install it with separate boot partition and luks2 + argon encryption for os partition <vagrantc>yeah, it would be nice if *somebody* wrote code for guix to support a split boot partition <sss2>nckx, you are rigth, but xfs have very similar to ext feature set without ext limitation, this is what i wanted to say <lfam>I was talking about fixing a bug in Guix... not adding features <nckx>Somebody who's very keen of having separate /boot, for example 😉 <vagrantc>or ... get grub2 to support luks2 ... also ... "not it!" <sss2>lfam, maybe i will look at it in future, but...., i have toooo large todo for future, so this future may come nvere ( <lfam>I know what that is like <vagrantc>are there installations with multiple machines sharing /gnu/store ... and how does one go about making that work? <vagrantc>as it seems they would need to also share /var/guix/ database and such... <Noisytoot>PotentialUser-41: I don't think any of this is relevant to GUix <mdevos>PotentialUser-41: I'm not familiar with Android rooting. Also, not relevant to Guix <vagrantc>i remember one of the early things i wanted to do when i first got involved with guix was to support network booting (such as ltsp.org) ... but that fell by the wayside ... then someone started working on it a while back <vagrantc>but never really dove into hacking the initramfs (wow, guix really is guile all the way down!) or figuring out the shared store problem <Noisytoot>PotentialUser-41: Android has it's own IRC channel: #android <Noisytoot>And other Android distros might have their own <PotentialUser-41>noisytoot: Because I do not know where people care about software freedom! <Noisytoot>But your phone doesn't support Replicant, and is probably impossible to make entirely free (at least now) <Noisytoot>The best thing is either use something with blobs, or get another one <nckx>sss2: ext was there from the start (and developed iteratively) whilst XFS wasn't added until 2005 IIRC, so it's not like someone made a stupid choice. History is what it was. <nckx>PotentialUser-41: Try #fsf or #replicant. <lambdanon>Currently trying to get a function working in my guix repl. The repl is telling me (guix git-download) isn't loaded, but it is. I added #:use-module (guix git-download) to the define-module <Noisytoot>nckx: It's too late, but I suggested #replicant <mdevos>lambdanon: I don't know what's wrong, but use a tracker-free pasta in the future, e.g. paste.debian.net <mdevos>Also, guix error reporting is crappy sometimes. What's the exact command used for starting the REPL <lambdanon>I then switched to the repl it automatically started. I'm trying to do things through geiser <nckx>Bad Read-Header-Line header: #<eof> <mdevos>How can you start a Guix REPL with emacs-guix? <lambdanon>I have no idea, it just does. To be honest, it's the first time I'm using geiser outside of SICP <mdevos>M-x guix c gives me ’No prompt found!’ <Noisytoot>lambdanon: This may be because you didn't select it, but the parentheses don't match <mdevos>M-x geiser won't work, if that's what you were doing <mdevos>(the load path probably needs to be adjusted to include guix' source code & compiled modules) <lambdanon>Noisytool: I know, I forgot to paste the first paren. In my file on my machine, the first paren is there <lambdanon>Noisytoot: I know, I forgot to paste the first paren. In my file on my machine, the first paren is there <lambdanon>That's weird, when I try to manually use-modules, I'm getting "No code for module X" for all the modules <mdevos>lambdanon: does the same happen if you start the repl with "guix repl"? <mdevos>I'm suspecting a load path issue <lambdanon>Restarting my emacs solved the issue, but now I'm missing a git module <sss2>nckx, i was afk, i know fs history, and ext earned and completely deserve all kind of respect, and what it's still alive today and even used - very cool, but, for now in practical sense it's just deprecated <roptat>resuming my work on guile netlink :) <lambdanon>When I try looking up 'The perfect setup' on the guix manual, they talk about a guix checkout? Where do I find that? <mdevos>IIRC that's for hacking on guix. It's a git clone of the guix git repo <lambdanon>ah, that entry on the perfect setup is for people contributing to the guix project <nckx>Why does ./pre-inst-env guix not find guile-zlib when it's in my system profile? <lambdanon>mdevos: So how do I set up my guix load path? When I try to echo $GUIX_LOAD_PATH I get nothing <nckx>*And* I'm in a guix env guix? <mdevos>lambdanon: I mean I guess guix isn't in *guile*'s load path <mdevos>the "guix repl" commands automatically adds the required paths <mdevos>but geiser doesn't. idk about emacs-guix <lambdanon>Looks like geiser doesn't add /gnu/store/...-guix-module-union/share/guile/site/3.0 <lambdanon>re-enabling the guix daemon has added a couple more entries into my load-path, but none have the git module? <mdevos>... how can restarting guix-daemon modify the environment of an unrelated proccess? *roptat managed to create and remove network addresses from guile :) <nckx>Oh, I wondered what the reason was. <pkill9>"Linus Torvalds Went Six Days Without Electricity, Swears Smaller 5.12 Kernel Is Co-Incidental " <pkill9>has guix been run on freebsd? I can't remember <nckx>I doubt it, although if it's been run on one BSD it would be that one. <nckx>After some searching (including in my old #guix logs) I doubt it to the point of nodom. <lambdanon>After resetting my profile and setting up emacs through a manifest... <lambdanon>...emacs is now segfaulting unless I launch it from a terminal. <OriansJ>meaning guix can start eliminating pregenerated files from builds and actually build things entirely from human written sources. <Gooberpatrol66>Is there a way to tell the guix graphical installer to not attempt to use EFI? <nckx>Gooberpatrol66: Possibly with a hack like ‘sudo mount -o bind /var/empty /sys/firmware’ before starting the installation. <nckx>The installer checks whether /sys/firmware/efi exists, there is no way to disable that. <nckx>Gooberpatrol66: But if this is masking a bug (why boot using EFI now if you'll switch to CSM later?), please report it. <nckx>OriansJ: Ah, that explains the ‘human-written’ wording :) <OriansJ>nckx: well generated code really shouldn't be considered source code in the 4 freedoms sense of the words <nckx>Obviously, but some rando called Jeremiah disagreed. <OriansJ>and it is finally possible to eliminate the need for pregenerated files with Guix and only use source code. 