<patched[m]><hnhx[m]> "I dont understand who would ever..." <- It's mostly because other people already use it. People generally use what they need to talk to their contacts before other considerations.
<Noisytoot>For small servers onion authentication may be enough.
<Aurora_v_kosmose>We need to switch over to Gnunet at some point, given how the internet only seems to get more broken day by day... but that's sadly still WIP
<hnhx[m]>patched[m]: Well I deleted my Discord even though I had people there who I talked to. If they REALLY want to keep in touch with me they will create a Matrix account anyway.
<hnhx[m]>and well just ignore those who wont contact you because they need to download a new app and create an acc lol
<hnhx[m]>because clearly you wont matter to them if they wont do such a simple task for you
<hnhx[m]>You should always tell people to switch to FLOSS, don't let them force you to use spyware.
<littlebobeep>everyone in #scummvm is using Discord and they say it is easier and better or something I don't know why they don't use Matrix
<ulfvonbelow>is there a pre-inst-env equivalent for multiple channels? Does setting GUIX_PACKAGE_PATH work? It's irritating to have to 'guix pull' every time I want to rebuild my system configuration, adds a lot of time between iterations
<nckx>I forgot I'd started a ‘guix weather’ to bordeaux earlier today. “87.2% substitutes available (19,665 out of 22,552)” is a nice result.
<kaelyn>ulfvonbelow: you should be able to do something like 'guix system -L /path/to/your/channel build your-system-config.scm' (I do that to test changes to my shared system definition, etc)
<nckx>But unexpectedly, I get “87.5% substitutes available (19,739 out of 22,552)” for ci.guix.gnu.org!
<KarlJoad`>Can wrapping a program "permanently" change flags passed to a program on the command line? Or can wrapping only modify the environment the wrapped program runs in?
<patched[m]><hnhx[m]> "You should always tell people to..." <- I do, but most people don't even know about the free software movement. They use the software that gets the job done of contacting their friends, which will inevitably be what their friends are using. We must keep these network effects in mind when we try to tackle these issues.
<Aurora_v_kosmose>Corposcum spend a lot of money on acquiring user mindshare and locking them in.
<patched[m]>E.g., it is easier to get people to switch if you've nurtured a small kernel of friends who use a free replacement actively. Then you have some network power to get people over.
<nckx>KarlJoad`: That's not the intended use of the current wrap-program/wrap-script helpers, which only set environment variables. There's nothing stopping you from writing your own phase instead, if you think it's the right thing to do. It's so likely to violate POLA that I'd be very cautious to do so, but it's possible.
<atka>I'm not sure either, everything works and nothing strange has been done, no extreme use cases or anything
<atka>guix pull --list-generations works, same with guix package, guix system reconfigure works, but list-generations is broken
<KarlJoad`>apteryx: I found something in the guile manual. Can be done with SRFI-1 or using (rnrs enums (6)).
<apteryx>ok, and with that I could find the example in Guix: the ntp-server-type field of the <ntp-server> record in (gnu services networking) accept an enum
<atka>apteryx: so I was able to switch generations to 10 generations ago and that worked, guix system list-generatins still failed so I ran guix system delete generation 1 and now the broken link is gone and list-generations works again
<atka>so easy fix, I'll be on the lookout to see what causes it if it happens again
<KarlJoad`>apteryx: Thanks! That will really make some of this coding more resilient.
<emacsomancer[m]>sort of figured out the mutter issue: it seems that if I've installed gdm with wayland, the build of mutter fails unless gdm with wayland is already installed (given current ci substitutes issues)
<emacsomancer[m]>(so I had to revert to a previous generation where gdm-with-wayland was installed in order to reconfigure - didn't matter whether I was trying to reconfigure with or without wayland; build fails unless I'm on a generation with gdm+wayland)
<unmatched-paren>hi guix :) anyone having any problems with wifi or is it just me? the system isn't recognising my ath9k wifi dongle
<littlebobeep>Well ath9k_htc dongles might get theoretical 150Mb/s if I am not mistaken
<littlebobeep>unmatched-paren: did you test your throughput to another machine on LAN?
<unmatched-paren>anyway, that's not the problem here; it literally is not functioning right now, i was wondering whether anyone else was experiencing difficulties, perhaps with updates of certain packages
*sheertj is sad that unmatched-parens is disappointed.
<hnhx[m]><unmatched-paren> "searxes 802.11n" <- I dont like searx. I hosted it for a while but i hate that you need idk how many third party python libs and frameworks and whatnot. So i just made my own meta search engine in PHP without any 3rd party php libs or js. https://github.com/hnhx/librex
<nckx>pashencija[m]: So are we all when we get the tenth such COMPLETE bug report of the day (I'm responsible for that bit, but only because people were reporting the same ‘bug’ with no info). There's a patch suggestion to make it print more useful info, I think. Anyway, probably a network error, just try again, and accept this apology from Guix Inc.
<nckx>zeta_reticuli: No, it's more than a recommendation, it's a ‘no, really, don't’. The store is read-only; even if you can technically hack around that fact, it won't bring you pleasure.
<littlebobeep>tbss[m]1: Wifi/BT no work, also some proprietary firmware for keyboard and stuff, also no USB-C video output, but interal display GPU I think supports OpenGL 3.x
<nckx>zeta_reticuli: My /etc/guix/system.scm configures tor as (service tor-service-type (tor-configuration (config-file (local-file "torrc.moloch")))) with my configuration file in the same directory.
<nckx>‘guix gc’ should notice the dead links in /var/guix/profiles and collect unreferenced store items.
<koszko>nckx: well, it's a bit complicated... When running on a foreign distro I executed 'guix pull' as normal user. It created '~/.config/guix/current'. I later noticed that 'pull' is meant to be run as root. And so I realized the 'current' profile is unneeded. I then unlinked '~/.config/guix/current' but 'guix gc --list-roots' still shows a few ones with 'current' in the name
<nckx>I'll address the most important thing first:
<nckx>”I later noticed that 'pull' is meant to be run as root.” — no, actually. What made you think that? A strange message about git checkout ownership perhaps?
<koszko>No. What made me think that were some doc instructions regarding the installation of Guix. All examples I saw seemed to be using 'guix pull' to update the global profile
<nckx>(OK, good, because that message was bogus and has since been fixed.)
<nckx>‘guix pull’ as root (either when logged in as root, e.g., with su, or with ‘sudo -i guix pull’ but never ‘sudo -E guix pull’) is useful on foreign distributions because it's the only way to update the system-wide daemon. However, you don't need to do that often, and the vast majority of pulls (to update available packages) should be done as you.
<nckx>The left-over --list-roots aren't harmful in any way, but if you want to reclaim a tiny bit of space or they just bug you (I sympathise) you can run, I believe, ‘guix pull --delete-generations=1s’.
<nckx>‘I believe’ because honestly I just clean up my /var/guix/profiles by hand to this day.
<nckx>Then guix gc, but don't expect huge savings.
<nckx>But as you've already removed ~/.config/guix/current, these left-overs can't ‘do’ anything, so they are harmless.
<koszko>thanks, it's more clear to me now (also, it was my mistake in the first place since I missed some of the information on the 'guix pull' doc page)
<nckx>I don't blame you. It's an unexpected shift coming from most package managers (sudo apt), and whilst our docs aren't shabby there's always room for improvement.
<Guest11>gcc-cross-sans-lib seems to be failing to build. cuirass reports that a "version 1.4" built fine. how can i build that "version 1.4" on my local guix?
<tbss[m]1><littlebobeep> "tbss: Wifi/BT no work, also some..." <- Its better chose purism or have other computers?
<tbss[m]1>My requeriment is the support distro,not spoke about bios
<pashencija[m]><nckx> "pashencija: So are we all when..." <- > probably a network error
<nckx>I mean, there's your problem, put it back. (?)
<nckx>--system doesn't cross-compile, --target does, but why would you be against cross-compiling in the first place?
<ennoausberlin>Hello. Today I introduced guix to my colleagues at my workplace. Most of my own projects are already managed by guix. We usually ship docker containers. So I mentioned the guix pack command and emphasized the reproducibility using guix. It was common reasoning (of my co-workers) to avoid the additional guix steps, because the result is already a
<ennoausberlin>docker container and the images are stored for a long time, so it is kind of reproducible already. I could not argue against it during my presentation. Any thoughts on that?
<nckx>How is it reproducible, i.e., how would I reproduce your Docker container (or you reproduce a 5-year-old one)?
<rekado>ennoausberlin: that’s like saying you don’t need to keep source code, because you compiled a binary and copied that to a floppy disk.
<rekado>the Docker thing is an opaque binary blob, an output of a process. The process itself should be repeatable.
<nckx>Maybe they don't know what ‘reproduce’ means? Is there a misleading German translation?
<bourfronti>hello guix. is anybody here running emacs through guix home? when i run it as a shepherd service i cannot use browse-url (sway), but it works if i run it through a terminal as emacs --fg-daemon. what could be causing this?
<rekado>it’s like knowing that the answer is 42 without having the question and the steps that were taken to arrive at the answer.
<nckx>rekado: So there's nothing like, er, ‘docker --extract-manifest < i-dont-know-anything-about.docker | docker --create > new.docker’?
<rekado>the Dockerfile can be under version control, but the internet is not under vnersion control
<rekado>so all of that volatile state of the apt repos, myspace, etc, is not captured by the Dockerfile
<rekado>you’re expected to either ignore this or have managed proxies for everything
<rekado>but most people don’t expect the pipeline from Dockerfile to Docker image to behave reproducibly in the first place
<rekado>it’s just supposed to produce some archive that is probably all right
<ennoausberlin>rekado We do not ship that often and I'd like to be reproducible. But common opinion here is, that we don't need to be reproducible, because we store every shipped container. I don't like to waste that much space, but they do not care. Storage is cheap was the answer.
<rekado>and people keep around previous images for some form of roll-back.
<rekado>ennoausberlin: personally, I would drop it if I was in an environment where people didn’t care about source to binary transparency.
<rekado>chances are that it really does not matter to them
<rekado>source to binary transparency is nice in theory, because it lets *you* decide how you want to disturb the output (e.g. by changing some inputs in a certain way)
<rekado>for science this kind of functional mapping from input to output does make a difference as it unlocks the ability to understand *why* the binary blob looks and behaves a certain way
<rekado>others might simply not want to know anything about this; building container images would be done automatically on every push, for example, so using Docker is a matter of simplifying the deployment pipeline
<rekado>especially when using a cloud platform that is built around Docker and can automatically fetch from a Docker registry there may simply be no utility in reproducibility — the main feature is deployment convenience and leveraging exist infrastructure for automation.
<koszko>furrymcgee: true, I believe many people using docker (and other popular technologies...) are silently violating some licenses
<nckx>Ah, the supply chain is a chain of signed blobs with which you are supplied. These blobs be *fresh*.
<koszko>furrymcgee: btw, I'm wondering how to properly utilize this 'guix system' functionality you mentioned. 'guix system docker-image' seems to reject any operating system definition with no 'bootloader' defined
<koszko>but bootloader seems useless for docker systems. Perhaps we should be using 'guix pack' for building docker images?
<ennoausberlin>rekado I was not in for a change of our deployment process. I like the guix way to build software and wanted to introduce it to others. I could not create an enthusiastic response, though :)
<rekado>nckx: yes, it’s just signatures (which are optional and not all widely used).
<rekado>ennoausberlin: I empathize. Even in an environment that is primed for reproducibility concerns the most common response I heard is along the lines of “you ain’t gonna need it”.
<nckx>koszko: The boot loader is simply ignored. Set it to whatever (see gnu/system/examples/docker-image.tmpl). ‘guix pack’ and ‘system’ docker images serve different purposes, the latter is a full-blown half-OS (shepherd, services, …).
<nckx>Cross-compilation on M1s might not be necessary, but it doesn't hurt (apart from a bit of storage used) and we'd have to maintain two separate code paths otherwise, IIUC all this byzantine image stuff.
<pashencija[m]>nckx: Oh, I stripped it from the docs. Docs describe armhf board. Check the link
<nckx>I trust you more than I trust my reading of docs which may or may not apply to your hardware.
<pashencija[m]>nckx: It does hurt. That was already discussed here before. GUIX fails to prepare cross-compiler on aarch64
<GNUtoo>Replicant also relies on other distributions in practice
<nckx>zeta_reticuli: You downloaded a generic ‘for GNU/Linux’ binary? Those won't run easily on Guix Systems, because they hard-code file names like /lib/ld-linux-x86-64.so.2 which Guix lacks. I strongly recommend guix installing icecat. There should be substitutes (=binaries) from Guix.
<pashencija[m]>I mean GUIX is not really helpful on low-end arm devices with <2gb of ram
<nckx>If Guix matures a bit more in the area its value in supporting old (esp. ARM) devices will probably lie in easy and reproducible image creation on your workstation, not in self-hosting on the old device.
<GNUtoo>I probably need to switch to LVM or something like that then
<GNUtoo>In my case I'm using Guix to run automatic tests on a library I'm working on, that library interacts with the modem, and so it would be nice if I could run everything on the device with the modem instead of splitting the tests on several devices
<pashencija[m]>Our Respects Your Freedom (RYF) certified products page lists products certified by the FSF to do as much as possible to respect your freedom and your privacy, and ensure that you have control over your device. You can find a list of motherboards that use 100% free boot firmware, with no blobs, here. For those that require nonfree microcode blobs, see coreboot.org.
<GNUtoo>About RYF so far the ME firmware has been completely removed
<GNUtoo>There is usually a ROM that is supposed to load that firmware that remains, but the same is true for most ARM devices where there is a bootrom too.
<GNUtoo>As for Purism they have lot of nonfree software (Intel FSP, part of the ME firmware), but it's still better than off the shelf latops where you can't even choose the way they boot (you can't recompile the UEFI and choose to add grub inside the flash for instance).
<apteryx>is it me or fill-column doesn't work with paredit in Emacs 28.1? I have it set to 78 (per the Guix checkout .dir-locals.el file) yet my 'paredit-reindent-defun' (bound to M-q), doesn't honor it
<unmatched-paren>it's not: (1) the usb port (it recognises a flash drive plugged in) (2) the network in general (ethernet works) so that only leaves either (3) the dongle is broken, (4) something something drivers, or (5) the laptop is somehow broken itself (i really hope not :P)
<nckx>You've asked me often enough by now, but as I've already told you I don't even have a Pinebook. I don't have an ‘aarch64 host’. I barely started ‘guix system image guix/gnu/system/images/pinebook-pro.scm’ (on x86_64 by the way) to see if it looks bogus or not.
<nckx>Also, manually downclocked because summer 👍 sigh. It's building the arm64-generic kernel now.
<nckx>Someone like vagrantc might know off the top of their head what the ‘right’ way to generate the image is. Alas, they aren't here.
<nckx>pashencija[m]: ‘guix system image gnu/system/images/pinebook-pro.scm’ is absolutely the way to go. The (@ …) command looks wrong to me just based on the fact that you're building for armhf, not aarch64, and I don't see any "pinebook-pro" in gnu/packages/bootloaders.scm.
<nckx>But the whole point of pinebook-pro.scm is to wrap that all away, so you don't need to know all the right values for a long command line.
<apteryx>pashencija[m]: you should abstain from using fancy matrix features on this channel, as it doesn't behaves well with IRC (such as the reply that copy pastes the whole thing again, or the edit that also does that)
<nckx>With ‘fancy’ being anything beyond typing a message and pressing ‘send’/return :)
<nckx>What really confuses me is: what bizarre Matrix misfeature makes it necessary to escape a *backstroke* of all characters? As you can see from the logs, on IRC it just shows up normally & breaks your link.
<nckx>pashencija[m]: Soo… I'm running ‘guix system image --system=aarch64-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "pinebook-pro-rk3399")'’ on a remote aarch64 machine now. It didn't immediately error out and is now deblobbing the kernel, which means it will take a while.
<nckx>Thanks for the SSH offer. The project does have a few aarch64 boxes hooked up to the build farm, they're just a bit of a pain to use.
*nckx groans as the build fails with a bogus error merely to prove that.
<bjc>does anyone have a hint on how i might build a system image with a known path to init? i'd like to run guix in a systemd-nspawn container, faking a real install (so it'd start from a pid 1 shepherd), but that's tough to do if the path to init changes on system reconfigure
<unmatched-paren>bjc: there's probably some way to symlink the init binary to /sbin/init on reconfigure
<nckx>OTOH (I'm just thinking out loud here) maybe someone has a use case for a GRUB-bootable disc image that is also nspawnable… Although it's not like you can combine image types either, while some day (bootloaders (list grub-bootloader grub-efi-bootloader)) could actually be made possible…
<nckx>So you could write (bootloaders (list grub-efi-bootloader init-bootloader)). But getting ahead of myself here.
<unmatched-paren>idk, it just sounds to me like how a five-year-old would insult something "hahaaaha, LOSEdows!!!111!!1"
<unmatched-paren>(I am 100% for making fun of proprietary software, for the record, but not like that :P)
<zacchae[m]>I like the 5-year-old asthetic, because it means I can use it in a more casual context. At the end of the day, "mean names" are just that. If I really want to let others know that windows is bad, I would do it in a serious conversation without pejorative language and mean nicknames.
<zacchae[m]>"winblows" is just bait for people to ask "but what's wrong with windows?"